Posts by DirkZz

    Sindskort is Laravel 5 gereleased en Jeffrey Way van Laracasts.com heeft een gigantisch uitgebreide filmreeks gemaakt welke bijna het hele framework behandeld.


    Deze is gratis te bekijken op
    Laravel 5 Fundamentals


    Wat mij betreft voor de meeste developers hier eigenlijk een must watch, want naast Laravel 5 worden ook designpatronen binnen jouw applicatie en dergelijke behandeld.


    :thumbup: Veel kijkplezier.

    Ouch: "rijstijden"


    Kan helaas de enquête niet invullen omdat ik niet vanuit huis werk en ik geen 0 dagen kan invullen, maar mijn opdrachtgever zou dit wel toelaten.


    En heel sporadisch maak ik hier gebruik van wanneer het voor mij fijner is om me even compleet af te zonderen. Aangezien ik op mijn werk vaak wordt aangesproken door collega's over nieuwe ideeën en bug meldingen.


    Of er wordt mij gevraagd dingen uit te zoeken of snel tussendoor een klein tooltje te maken.


    Hier heb ik geen last van wanneer ik vanuit huiswerk, aangezien ik dan enkel en alleen met de directeur, een manager en afhankelijk van de opdracht mijn directe collega van doen heb.


    Ondanks deze voordelen kies ik er toch voor om op het bedrijf te zitten, vooral ook omdat zoals jullie waarschijnlijk weten in development ook veel research en documentatie gaat zitten. En aangezien ons bedrijf development niet als corebusiness gezien wordt lijkt het mij op de lange termijn ingewikkeld om precies te verantwoorden wat ik allemaal heb gedaan om aan 8 uur op een dag te komen.


    Wanneer je op het bedrijf zelf zit dan is dit allemaal wat transparanter en daar voel ik me zelf prettiger bij.


    Zou voor zowel de werkgever als de werknemer wel fijn zijn om iets slims te verzinnen om verrichte werkzaamheden naar beide kanten toe transparant te maken. Dingen die ik de afgelopen week heb onderzocht en gedaan kan ik nog wel verantwoorden, maar op de vraag wat heb je in de afgelopen maand allemaal gedaan wordt al een stuk lastiger.

    Terwijl jij het typt vind jij het handig ;)


    Maar wat als je het over een paar maand terug moet lezen omdat er een fout in zit? Of wanneer een andere programmeur er naar moet kijken omdat er iets mee is?


    Wat is dan beter denk je? Jouw voorbeeld of iets als dit;

    Het kan wel in één regel maar waarom zou je dit willen? Je code wordt er heel onduidelijk van.


    dan zou ik het nog eerder zo doen;



    of zo



    Qua classes zit je wel in de richting ja. Hoe je het zou kunnen zien, je hebt Users en Administratoren.
    Maar een administrator is net zo goed een gebruikers, alleen heeft deze extra functionaliteit rechten.


    dan krijg je zo iets



    (Het forum vernaggelt al mijn inspringingen, sorry daarvoor)



    Wat betreft namespaces, deze gebruik je om bijv. Class namen meerdere keren te gebruiken in je code en om deze op een logische wijze te structureren.


    Je maakt dan een folderstructuur aan die er zo uit kan zien;


    ToonData/Csv/Genereer.php
    ToonData/Xml/Genereer.php


    met als code voor die 2 php bestanden bijv;


    PHP
    <?php namespace ToonData\Csv;
    
    
    class Genereer 
    {
        public function toon()
        {
            
        }
    }


    PHP
    <?php namespace ToonData\Xml;
    
    
    class Genereer 
    {
        public function toon()
        {
            
        }
    }


    En op de plek waar je het gebruikt;



    ( Zoals het in dit voorbeeld is gebruikt is het ook handig zijn om het tegen een interface aan te gooien )

    Misschien zou het ook handig zijn om ergens de mogelijkheid hebben om een blog onderwerp aan te vragen, of een voorstel te doen voor een blogitem om te checken of er animo voor is.


    :thumbup:

    @DirkZz je hebt bijna overal gelijk, behalve bij het afzonderlijke van elkaar commite. Neem als voorbeeld die commit (678b800c1817cc28f5c580e5924ef53cc6e36e2a), jij zegt dus bijvoorbeeld crimes en hospital los van elkaar commite. Bijde pagina's hebben veel bestanden waar ze samen in komen. Dus twee pagina's waar bijde met drie andere bestanden praten. Hoe zou jij het dan doen?


    Precies op dezelfde manier alsop waarop jij het hebt ontwikkeld, waarschijnlijk heb je.


    1. de nieuwe style gemaakt -> commit
    2. deze style toegepast op de crime pagina -> commit
    3. de stijle toegepast op de hospital pagina -> commit



    Als er technische wijzigingen zijn die voor problemen kunnen zorgen, nieuwe branche maken, wijzigingen doorvoeren, comitten -> push.
    En daarna mergen.


    Git branch | Atlassian Git Tutorial

    Klopt inderdaad dat van database wachtwoorden niet helemaal lekker ging, had ik een aantal vergeten niet mee te sturen. Steeds als dat gebeuren maakte ik wel een nieuwe database account aan. Voor de rest begrijp ik volgens mij niet helemaal wat je met het 2de puntje bedoeld. Tenzij gebruiker gebruik moet zijn. Als dat zo is doe ik dat al (denk ik), zoals je hier kan zien. Als je naar het commit commentaar kijkt. Dit doe ik wal pas sinds gisteren.


    Vind het persoonlijk allemaal nogal vrij globaal, neem aan dat de reden is waarom het op Github staat is zodat iemand anders eventueel ook kan helpen.


    "New functionality" bijvoorbeeld zegt mij helemaal niets


    Die omschrijving is al een heel stuk beter:


    "New pages: family list, family profile and house market.
    Updated pages: crimes (add better Captcha), hospital, jail, airport (all three new layout)
    Big changes: New captcha (only at crime at the moment)
    Small changes: some icon updates and more user profile info
    Bug fixes: admin user update, you can now update users without specifying groups"


    Persoonlijk zou ik die elementen afzonderlijk van elkaar hebben gecommit dan krijg iets in de richting van:


    "updated crimes adda better captcha"
    "updated layout for hospital, jail and airport pages"
    "added list and profile functionality to family feature"
    "added house market feature"


    met per onderdeel een beschrijving van wat het normale verwachte gedrag is van deze wijziging/toevoeging.


    Maakt het terug lezen voor jezelf en voor anderen veel eenvoudiger, als jij/iemand anders vermoedt dat er een bug zit in de functionaliteit dan kan deze terug vinden met welke gedachte dit gecommit is.

    Ik weet zelf niet waar je osBanditi 1.7 kan downloaden/vinden. Wel heb ik nog ergens de beta versie van 3.0 (zonder theme, dus een rommeltje) op mijn pc staan. Ook is het misschien interessant om naar osFighter te kijken. Dit is een projectje waar ik mee bezig ben. Deze is inmiddels best ver. Ik zou met de eerste release, waar nog niet extreem veel bij zit, al over maximaal een maand klaar kunnen zijn. Mits school niet in de weg zit.


    Denk aan: heel inlog en registratie systeem, berichten, gebruiker wijzigen, familie's, aanvallen, shoutbox, forum (niet uitgebreid), misdaden, auto's stelen, bank, gevangenis, winkel, vliegveld, ziekenhuis, woningmarkt, kraak de kluis, (admin functie's:) pagina's aanmaken, menu's wijzigen, instellingen (hoofd instellingen, ranks, steden/landen, thema's), andere gebruikers wijzigen, misdaden aanmaken/wijzigen. Alles wat dik gedrukt is is al af.


    Ook vind je in dit topic meer info


    Paar kleine tips wat betreft je git gebruik;


    - Gooi aparte features op een aparte branch.
    - Gebruiker namen die duidelijk omschrijven wat er is toegevoegd, is voor jezelf later ook makkelijker.
    - Gebruik enviroment variabelen voor zaken als database wachtwoorden en dergelijke, die horen niet in de repo ;)

    Als dit je opties zijn;


    Voor Python gaan als je echt iets nieuws wil leren, voor PHP gaan wanneer je gewoon makkelijk punten wil binnen hengelen.

    Probeer het voor de grap eens met

    Code
    <?PHP usleep(50000);  ?>

    in de lus.
    En kijk eens of je verder komt/het hele script loopt.


    Anders telkens iets hoger zetten.


    En zet ook je errorreporting aan, en zorg dat de timelimit op 0 staat.

    En mocht dat niet werken, heb je ssh toegang tot je server?


    dan zou je dit kunnen proberen;
    1. mysql -u<gebruikersnaam> -p
    2. Vul je wachtwoord in
    3. CREATE USER 'KiesEenGebruikersNaam'@'localhost' IDENTIFIED BY 'KiesEenWachtwoord';
    4. GRANT ALL PRIVILEGES ON * . * TO 'JeGekozenGebruikersNaam'@'localhost';
    5. FLUSH PRIVILEGES;


    Die Grant all gaat er vanuit dat deze gebruiker alle rechten heeft, mocht je dit niet willen dan kan je het beste even in de documentatie kijken;
    MySQL :: MySQL 5.7 Reference Manual :: 13.7.1.4 GRANT Syntax