[PHP] Object geörienteerd - database select

[Barryvdh]

Verwijderd schreef op vrijdag 11 november 2016 @ 22:25:
Ik lees veel terug over Laravel, en heb zelf ook even op het internet gekeken.
Maar is het voor een zeer simpele webshop of website wel handig om zo'n heel framework erbij te pakken?

Ik gebruik het de afgelopen 4 jaar voor elk maatwerk project, maar het ligt eraan hoe 'simpel' je website echt is.

In mijn ervaring begint alles heel simpel en blijf je het vaak uitbouwen, totdat je eigenlijk grote delen aan het namaken bent. Laravel bevat gewoon veel zaken out-of-the-box die het makkelijk maken. En waarschijnlijk denk je die nu niet eens nodig te hebben.

Nu is het leuk om zelf je database classes te schrijven, maar dat wordt gewoon steeds complexer. Een voorbeeldje wat je nu hebt, is bijna zonder custom code te schrijven, op basis van 2 simpele Models:

PHP:

<?php

class Product extends Illuminate\Database\Eloquent\Model
{
    public function getPriceWithDiscountAttribute()
    {
        return $this->attributes['unit_price'] - ($this->attributes['discount'] / 100);
    }

    public function category()
    {
        return $this->belongsTo(Category::class);
    }
}

class Category extends Illuminate\Database\Eloquent\Model
{
    public function products()
    {
        return $this->hasMany(Product::class);
    }
}

// Create project from array
$product = Product::create([
    'name' => 'test',
    'description' => 'Test',
    'unit_price' => 6.84,
    'discount' => 5,
]);

if (!$product->exists){
    echo 'Product is niet toegevoegd!';
}

// Get all products
$products = Product::all();

if ($products->count() > 0) {
    foreach ($products as $product) {
        echo $product->name .': ' . $product->price_with_discount;
        if ($product->category) {
            echo $product->category->title;
        }
    }
} else {
    echo 'Geen producten gevonden';
}

// Find by id, update attribute
$product = Product::find(3);
$product->name = 'New name';
$product->save();

// Or delete
$product->delete();

// Use query builder
$foodProducts = Product::where('unit_price', '>', 10)->orderBy('name')->paginate(50);

$category = Category::find(2);
foreach ($category->products as $product) {
    echo $product->name;
}

En je gaat gegarandeerd tegen dingen aanlopen als routing (nette urls, hoe krijg je die parameters netjes naar de goede controller), templating (hoe hou je presentatie overzichtelijk en escape je output goed), authenticatie (inloggen etc), caching, notificaties, background taken (queues), cli commando's, verschillende configuraties, validaties, etc etc. Lees maar gewoon een keer de docs door als je je verveelt https://laravel.com/docs/5.3/

[Verwijderd]

Barryvdh schreef op vrijdag 11 november 2016 @ 22:52:
[...]

Ik gebruik het de afgelopen 4 jaar voor elk maatwerk project, maar het ligt eraan hoe 'simpel' je website echt is.

In mijn ervaring begint alles heel simpel en blijf je het vaak uitbouwen, totdat je eigenlijk grote delen aan het namaken bent. Laravel bevat gewoon veel zaken out-of-the-box die het makkelijk maken. En waarschijnlijk denk je die nu niet eens nodig te hebben.

Nu is het leuk om zelf je database classes te schrijven, maar dat wordt gewoon steeds complexer. Een voorbeeldje wat je nu hebt, is bijna zonder custom code te schrijven, op basis van 2 simpele Models:

PHP:

<?php

class Product extends Illuminate\Database\Eloquent\Model
{
    public function getPriceWithDiscountAttribute()
    {
        return $this->attributes['unit_price'] - ($this->attributes['discount'] / 100);
    }

    public function category()
    {
        return $this->belongsTo(Category::class);
    }
}

class Category extends Illuminate\Database\Eloquent\Model
{
    public function products()
    {
        return $this->hasMany(Product::class);
    }
}

// Create project from array
$product = Product::create([
    'name' => 'test',
    'description' => 'Test',
    'unit_price' => 6.84,
    'discount' => 5,
]);

if (!$product->exists){
    echo 'Product is niet toegevoegd!';
}

// Get all products
$products = Product::all();

if ($products->count() > 0) {
    foreach ($products as $product) {
        echo $product->name .': ' . $product->price_with_discount;
        if ($product->category) {
            echo $product->category->title;
        }
    }
} else {
    echo 'Geen producten gevonden';
}

// Find by id, update attribute
$product = Product::find(3);
$product->name = 'New name';
$product->save();

// Or delete
$product->delete();

// Use query builder
$foodProducts = Product::where('unit_price', '>', 10)->orderBy('name')->paginate(50);

$category = Category::find(2);
foreach ($category->products as $product) {
    echo $product->name;
}

En je gaat gegarandeerd tegen dingen aanlopen als routing (nette urls, hoe krijg je die parameters netjes naar de goede controller), templating (hoe hou je presentatie overzichtelijk en escape je output goed), authenticatie (inloggen etc), caching, notificaties, background taken (queues), cli commando's, verschillende configuraties, validaties, etc etc. Lees maar gewoon een keer de docs door als je je verveelt https://laravel.com/docs/5.3/

Bedankt voor je reactie!
Ik heb het geïnstalleerd, en even gekeken in de documentatie.
Ik ben niet overtuigd dat dit mij helpt in ontwikkeling. < In tegenstelling tot dit ziet het er wel interessant uit. Maar hoe zit het met de snelheid? Wordt die erg (negatief) beïnvloed door Laravel?
Toch ben ik nog niet heel erg overtuigd, omdat ik wel afhankelijk ben van andere code nu. Wat als er een grote update is, werken dan mijn apps oppeens niet meer?

[ Voor 5% gewijzigd door Verwijderd op 12-11-2016 01:19 ]

[Barryvdh]

Verwijderd schreef op zaterdag 12 november 2016 @ 00:38:
[...]


Bedankt voor je reactie!
Ik heb het geïnstalleerd, en even gekeken in de documentatie.
Ik ben niet overtuigd dat dit mij helpt in ontwikkeling. < In tegenstelling tot dit ziet het er wel interessant uit. Maar hoe zit het met de snelheid? Wordt die erg (negatief) beïnvloed door Laravel?
Toch ben ik nog niet heel erg overtuigd, omdat ik wel afhankelijk ben van andere code nu. Wat als er een grote update is, werken dan mijn apps oppeens niet meer?

Meer code die meer doet is langere laad tijd ja. Qua boilerplate code is het trager dan plat php, alleen kan zich dit weer terug winnen door dingen als queues, cache en eager loading. Maar voor simpele dingen kan het langzamer zijn.

Al is het dus niet alleen snelheid, maar ook snelheid van ontwikkeling en veiligheid.

Code gaat niet 'ineens' kapot. Laravel heeft releases van 5.3.x bijv, waarbij die reeks compatibele is. Bij 5.4 is er meestal wat breaking changes. Maar je bent niet verplicht te updaten natuurlijk, dat doe je zelf handmatig met Composer.

[Verwijderd]

Barryvdh schreef op zaterdag 12 november 2016 @ 07:25:
[...]

Meer code die meer doet is langere laad tijd ja. Qua boilerplate code is het trager dan plat php, alleen kan zich dit weer terug winnen door dingen als queues, cache en eager loading. Maar voor simpele dingen kan het langzamer zijn.

Al is het dus niet alleen snelheid, maar ook snelheid van ontwikkeling en veiligheid.

Code gaat niet 'ineens' kapot. Laravel heeft releases van 5.3.x bijv, waarbij die reeks compatibele is. Bij 5.4 is er meestal wat breaking changes. Maar je bent niet verplicht te updaten natuurlijk, dat doe je zelf handmatig met Composer.

Bedankt voor je reactie Barry!
Voorlopig blijf ik nog even alles zelf schrijven, en ga ondertussen bezig met het verkennen van laravel en uitproberen!

[Cartman!]

Er zijn natuurlijk veel meer frameworks dan Laravel; Symfony (mijn favoriet maar wellicht meer gericht op high end en enterprise dan andere frameworks), Silex, Lumen, Phalcon... ga de boel rustig verkennen en kies wat bij je past. Coden zonder frameworks of libraries is anno 2016 imo ondenkbaar, als je zelf iets gaat maken ga je alle fouten maken die anderen allang voor je hebben opgelost. Je levert wat in op snelheid van uitvoer van code maar het ontwikkelen is zoveel sneller en onderhoud zoveel makkelijker.

Barryvdh schreef op zaterdag 12 november 2016 @ 07:25:
Code gaat niet 'ineens' kapot. Laravel heeft releases van 5.3.x bijv, waarbij die reeks compatibele is. Bij 5.4 is er meestal wat breaking changes. Maar je bent niet verplicht te updaten natuurlijk, dat doe je zelf handmatig met Composer.

Licht offtopic misschien maar hier moet je wel enorm opletten, standaard volgen packages altijd semver waarbij 5.4 backwards compatible hoort te zijn met 5.3. Laravel houdt zich hier blijkbaar niet als je 5.3 niet veilig kunt updaten naar 5.4 aan dus moet je het goed vastzetten op 5.3.x ipv 5.x.

[ Voor 87% gewijzigd door Cartman! op 13-11-2016 20:23 ]

[Barryvdh]

Cartman! schreef op zondag 13 november 2016 @ 19:18:
Licht offtopic misschien maar hier moet je wel enorm opletten, standaard volgen packages altijd semver waarbij 5.4 backwards compatible hoort te zijn met 5.3. Laravel houdt zich hier blijkbaar niet als je 5.3 niet veilig kunt updaten naar 5.4 aan dus moet je het goed vastzetten op 5.3.x ipv 5.x.

Klopt, maar in principe staat dat standaard ook gewoon zo ingesteld in je composer.json als je de applicatie cloned of installeert met composer create-project of de laravel installer.
Het is inderdaad wel anders dan de meeste ki ratjes (is dan ook geen library maar framework)
Heeft wel als voordeel dat Taylor iets meer vrijheid heeft om dingen te veranderen om te sneller te verbeteren.

[Cartman!]

Barryvdh schreef op zondag 13 november 2016 @ 21:23:
Heeft wel als voordeel dat Taylor iets meer vrijheid heeft om dingen te veranderen om te sneller te verbeteren.

offtopic:
Wat mij betreft misschien wel het grootste nadeel van Laravel: een 1 man show van een gast die niet goed met kritiek kan omgaan maar dan gaan we wel n beetje off topic

Overigens staat semver los van snel dingen kunnen verbeteren natuurlijk, je kan dat ook backwards compatible doorvoeren.

[ Voor 19% gewijzigd door Cartman! op 13-11-2016 21:40 ]

[Barryvdh]

Cartman! schreef op zondag 13 november 2016 @ 21:27:
[...]

offtopic:
Wat mij betreft misschien wel het grootste nadeel van Laravel: een 1 man show van een gast die niet goed met kritiek kan omgaan maar dan gaan we wel n beetje off topic

Overigens staat semver los van snel dingen kunnen verbeteren natuurlijk, je kan dat ook backwards compatible doorvoeren.

Klopt, daar is grote Laravel topic voor en volgens mij hebben we daar die discussie al paar keer gevoerd

On topic, ik ben er zelf ook voorstander voor om libraries te gebruiken wanneer mogelijk voor productie, maar ook om het zelf te doen om te leren (of als je denkt dat het beter kan). Maar van frameworks en libraries kan je ook veel leren natuurlijk.

[Verwijderd]

Cartman! schreef op zondag 13 november 2016 @ 19:18:
Coden zonder frameworks of libraries is anno 2016 imo ondenkbaar, als je zelf iets gaat maken ga je alle fouten maken die anderen allang voor je hebben opgelost.

Dat is natuurlijk niet waar, je kan nog steeds goede webapplicaties ontwikkelen zonder het gebruik van een framework of librarie, hoeveel ontwikkelaars doen dat wel niet. Fouten maken hoeft niet persé als je goed ontwikkeld, al is het natuurlijk wel waar dat de meeste fouten in een framework opgelost zijn.

Bedankt voor je tip, ik ga zeker ook andere frameworks proberen

[ Voor 21% gewijzigd door Verwijderd op 13-11-2016 22:46 ]

[Cartman!]

Verwijderd schreef op zondag 13 november 2016 @ 22:43:
[...]
Dat is natuurlijk niet waar, je kan nog steeds goede webapplicaties ontwikkelen zonder het gebruik van een framework of librarie, hoeveel ontwikkelaars doen dat wel niet.

Professionele: ik gok 0... Niet-professioneel: vast een hoop.

Fouten maken hoeft niet persé als je goed ontwikkeld, al is het natuurlijk wel waar dat de meeste fouten in een framework opgelost zijn.

Ik acht de kans dat je zonder framework fouten maakt zo'n 99,99%. Denk aan zaken als SQL Injection, XSS en CSRF qua security maar ook aan simpelweg onderhoud en het up to date kunnen houden van al je projecten. Stel jij vindt een bug in een stukje code, ga je die met de hand doorvoeren in al je vorige projecten en uitrollen? Met bestaande libraries worden zowel de (meeste) bugs voor je gespot, gefixt en beschikbaar gesteld middels een "composer update vendor/package" command en klaar ben je.

Bedankt voor je tip, ik ga zeker ook andere frameworks proberen

Er zijn een hoop voors en tegens oor diverse frameworks, gebruiken waar jij t meest productiefst in bent is uiteindelijk het belangrijkst

[Verwijderd]

Cartman! schreef op maandag 14 november 2016 @ 09:45:

Professionele: ik gok 0...

Niet helemaal goed gegokt...

[Cartman!]

Verwijderd schreef op maandag 14 november 2016 @ 10:28:
[...]

Niet helemaal goed gegokt...

Ik neem aan dat jij dan op jezelf doelt dan? Kun je dit toelichten? Wat versta jij onder professioneel?

edit: Misschien had ik er "Ik hoop 0" van moeten maken.

[ Voor 10% gewijzigd door Cartman! op 14-11-2016 10:38 ]

[Verwijderd]

Cartman! schreef op maandag 14 november 2016 @ 10:32:
Ik neem aan dat jij dan op jezelf doelt dan? Kun je dit toelichten? Wat versta jij onder professioneel?

Ja, ik doel op mezelf - 30 jaar ontwikkelaar waarvan de laatste 13 als zelfstandig webdeveloper.

En toelichten? Ik gebruik geen framework. Ik heb zelf wel in de loop van de tijd een CMS opgebouwd dat ik meestal inzet, maar soms kan ik dat i.v.m. eisen omtrend intellectueel eigendom niet inzetten, en dan gaat het gewoon van scratch af aan.

[Cartman!]

Verwijderd schreef op maandag 14 november 2016 @ 10:40:
En toelichten? Ik gebruik geen framework. Ik heb zelf wel in de loop van de tijd een CMS opgebouwd dat ik meestal inzet, maar soms kan ik dat i.v.m. eisen omtrend intellectueel eigendom niet inzetten, en dan gaat het gewoon van scratch af aan.

Maar geen framework...ook geen libraries? Ik was er heilig van overtuigd dat PHP-developers toch ondertussen van het Not Invented Here-syndroom af waren. Ik ben oprecht verbaasd en kan hier totaal niet bij.

[Verwijderd]

Cartman! schreef op maandag 14 november 2016 @ 10:44:
Maar geen framework...ook geen libraries?

Een PDF-library of zoiets wel, maar niet vaak.

Ik ben oprecht verbaasd en kan hier totaal niet bij.

Kun je zo hebben, met meningen!

[Cartman!]

Met alle frameworks, libraries en tools (composer, phpunit, behat) die er tegenwoordig zijn zou je jezelf denk ik een hoop tijd kunnen besparen. Ik kan me geen type project voorstellen waarbij het niet zou lonen ieder geval. Heb je specifieke redenen om geen gebruik te maken van bestaande frameworks?

Ik vind het een interessant onderwerp, misschien maar eens vragen of we dit moeten afsplitsen - Inmiddels gedaan.

[ Voor 12% gewijzigd door Cartman! op 14-11-2016 11:08 ]

[Verwijderd]

Cartman! schreef op maandag 14 november 2016 @ 10:55:
Ik kan me geen type project voorstellen waarbij het niet zou lonen ieder geval.

Och...de meeste webprojecten hebben dezelfde onderdelen nodig, dus als je dingen als databasetoegang, toegangsrechten, etcetera geregeld hebt, ofwel via het CMS of door hergebruik van een bestaande module, dan zijn de spannendste dingen wel gedekt.

Heb je specifieke redenen om geen gebruik te maken van bestaande frameworks?

Ik ben een (PHP-)programmeur, en dat wil ik blijven. Ik wil geen Symphony/Laravel/WordPress/whatever specialist zijn - dat zie ik als een beperking.

En als ik iets nieuws nodig heb zoek ik een library op, of maak ik er zelf een in mijn vrije tijd.

[Ventieldopje]

Verwijderd schreef op maandag 14 november 2016 @ 12:49:
[...]

Och...de meeste webprojecten hebben dezelfde onderdelen nodig, dus als je dingen als databasetoegang, toegangsrechten, etcetera geregeld hebt, ofwel via het CMS of door hergebruik van een bestaande module, dan zijn de spannendste dingen wel gedekt.


[...]

Zoals de onderdelen in Zend en Symfony die te herbruiken zijn bedoel je?

Verwijderd schreef op maandag 14 november 2016 @ 12:49:
[...]

Ik ben een (PHP-)programmeur, en dat wil ik blijven. Ik wil geen Symphony/Laravel/WordPress/whatever specialist zijn - dat zie ik als een beperking.

En als ik iets nieuws nodig heb zoek ik een library op, of maak ik er zelf een in mijn vrije tijd.

Je hoeft geen specialist te zijn om gebruik te maken van frameworks (of delen er van). Dit klinkt meer is "ik vind het wiel opnieuw uit omdat ik mijn eer hoog te houden heb"

[Cartman!]

Verwijderd schreef op maandag 14 november 2016 @ 12:49:
[...]
Och...de meeste webprojecten hebben dezelfde onderdelen nodig, dus als je dingen als databasetoegang, toegangsrechten, etcetera geregeld hebt, ofwel via het CMS of door hergebruik van een bestaande module, dan zijn de spannendste dingen wel gedekt.

En die onderdelen zijn allemaal voorzien van unit tests? Wel eens een security scan laten doen? Makkelijk te updaten als je een bug vindt? Goede documentatie?

Ik ben een (PHP-)programmeur, en dat wil ik blijven. Ik wil geen Symfony/Laravel/WordPress/whatever specialist zijn - dat zie ik als een beperking.

Je denkt dat je geen programmeur meer bent als je een framework gebruikt, waarom precies? Sinds ik frameworks ben gaan gebruiken (jaaaren geleden inmiddels) heb ik juist zo ontzettend veel geleerd ervan op gebied van OOP/schaalbaarheid/uitbreidbaarheid dat ik ervoor allemaal niet wist en in m'n eentje ook niet snel had uitgevonden. Niks houdt je tegen om meerdere frameworks te kunnen overigens.

Waarschijnlijk verschillen de soort (type/grootte) projecten die we doen ontzettend van elkaar maar zelfs voor simpele dingetjes pak ik altijd een framework, er zijn geen nadelen bij mij bekend. Je kan simpelweg direct van start en elk component wat je gebruikt kun je min of meer op vertrouwen dat het werkt.

Ik zou er niet aan moeten denken dat ik dingen als StackPHP, DBAL, Monolog en/of Twig zelf zou moeten gaan maken. Die tijd besteed ik liever aan het maken van de projecten zelf. Het is je goed recht overigens, daar niet van...ik ben vooral benieuwd naar de beweegredenen van alles zelf willen doen.

Interessant leesvoer over waarom een framework handig is: http://symfony.com/why-use-a-framework en dit is een heel mooie post die laat zien hoeveel zaken een framework voor je kan oplossen: http://symfony.com/doc/cu...flat_php_to_symfony2.html In beide gevallen is dit gericht op Symfony maar in feite geldt hetzelfde voor elk ander bekend framework (Silex, Laravel, Lumen, Yii, CodeIgniter).

[ Voor 10% gewijzigd door Cartman! op 14-11-2016 13:59 ]

[Bee.nl]

Cartman! schreef op maandag 14 november 2016 @ 13:45:
Je kan simpelweg direct van start en elk component wat je gebruikt kun je min of meer op vertrouwen dat het werkt.

Precies. Het scheelt zo veel tijd dat je niet zelf bezig hoeft te zijn met het uitvogelen van componenten. Als devver wil je immers zo veel mogelijk feature-gericht bezig zijn. Dus op 'hoger' niveau componenten combineren/configureren/uitbouwen in plaats van low-level alles moeten uitpluizen en debuggen, terwijl andere mensen dat al voor je gedaan hebben.

Je hoeft niet een compleet framework als Symfony/ZF te integreren, ze hebben alles in reusable components opgedeeld en je kunt zelf bepalen wat je gebruikt en wat niet. Console nodig? Hop, symfony/console in de composer.json en gaan met die features. Ik ben ook wel benieuwd naar de beweegredenen om bestaande packages niet te omarmen.

_{Waar blijft het afgesplitste topic}

[Verwijderd]

Cartman! schreef op maandag 14 november 2016 @ 09:45:


Ik acht de kans dat je zonder framework fouten maakt zo'n 99,99%. Denk aan zaken als SQL Injection, XSS en CSRF qua security maar ook aan simpelweg onderhoud en het up to date kunnen houden van al je projecten. Stel jij vindt een bug in een stukje code, ga je die met de hand doorvoeren in al je vorige projecten en uitrollen? Met bestaande libraries worden zowel de (meeste) bugs voor je gespot, gefixt en beschikbaar gesteld middels een "composer update vendor/package" command en klaar ben je.

SQL injections en XSS kan je zelf makkelijk tegen gaan. CSRF wordt een iets lastigere, maar dat is ook te doen.

Overigens ken ik genoeg professionele programmeurs die geen gebruik maken van frameworks

[Ventieldopje]

Verwijderd schreef op maandag 14 november 2016 @ 19:00:
[...]


SQL injections en XSS kan je zelf makkelijk tegen gaan. CSRF wordt een iets lastigere, maar dat is ook te doen.

Overigens ken ik genoeg professionele programmeurs die geen gebruik maken van frameworks

Nee, je kent toevallig programmeurs die werken aan projecten waarbij geen frameworks worden gebruikt. Als je als programmeur structureel de keuze maakt geen framework te gebruiken leent óf het project zich er niet voor (lijkt mij zeer zelden voorkomen, maar goed) óf vind je telkens het wiel opnieuw uit.

Overigens laten we duidelijk zijn, een eigen framework is ook een framework

[Verwijderd]

Ventieldopje schreef op maandag 14 november 2016 @ 19:11:
[...]


Nee, je kent toevallig programmeurs die werken aan projecten waarbij geen frameworks worden gebruikt. Als je als programmeur structureel de keuze maakt geen framework te gebruiken leent óf het project zich er niet voor (lijkt mij zeer zelden voorkomen, maar goed) óf vind je telkens het wiel opnieuw uit.

Overigens laten we duidelijk zijn, een eigen framework is ook een framework

Ah, ja uiteraard. Dan neem ik mijn woorden terug!
Want ze gebruiken wel eigen frameworks!

[Cartman!]

Verwijderd schreef op maandag 14 november 2016 @ 19:00:
SQL injections en XSS kan je zelf makkelijk tegen gaan. CSRF wordt een iets lastigere, maar dat is ook te doen.

Het kan allemaal als je goed genoeg bent maar waarom zou je al die tijd erin willen steken als anderen dat allang voor je opgelost hebben en getest en gebruikt hebben in productie?

Overigens ken ik genoeg professionele programmeurs die geen gebruik maken van frameworks

Dan hebben we een verschil in interpretatie van wat professioneel is denk ik. Tenzij het developers zijn bij Facebook of Twitter die dusdanig in grote schaal moeten werken dat gewone frameworks niet voldoen. Maar zelfs daar maken ze eigen frameworks (denk aan bijvoorbeeld React) om dingen op te lossen en hebben ze daar de resources het echt goed door te testen en security scans te doen (en stellen ze t weer open source beschikbaar).

Ik ben echt benieuwd wat voor soort projecten er dus gemaakt worden door diegenen die jij kent en geen gebruik maken van frameworks.

Ventieldopje schreef op maandag 14 november 2016 @ 19:11:
Overigens laten we duidelijk zijn, een eigen framework is ook een framework

In absolute zin heb je gelijk maar ik acht de kans zeer klein dat die frameworks van hoge kwaliteit zijn dus of dat een verbetering is...ik denk dat het ontzettend tegenvalt.

[ Voor 18% gewijzigd door Cartman! op 14-11-2016 19:22 ]

[Ventieldopje]

Cartman! schreef op maandag 14 november 2016 @ 19:17:
[...]

Het kan allemaal als je goed genoeg bent maar waarom zou je al die tijd erin willen steken als anderen dat allang voor je opgelost hebben en getest en gebruikt hebben in productie?

[...]

Dan hebben we een verschil in interpretatie van wat professioneel is denk ik. Tenzij het developers zijn bij Facebook of Twitter die dusdanig in grote schaal moeten werken dat gewone frameworks niet voldoen. Maar zelfs daar maken ze eigen frameworks (denk aan bijvoorbeeld React) om dingen op te lossen en hebben ze daar de resources het echt goed door te testen en security scans te doen.


[...]

In absolute zin heb je gelijk maar ik acht de kans zeer klein dat die frameworks van hoge kwaliteit zijn dus of dat een verbetering is...ik denk dat het ontzettend tegenvalt.

Tsja, maar dan zitten we in ieder geval weer op één lijn wat betreft frameworks. Een eigen framework is overigens ook niet per definitie 100% eigen code. Laravel is ook gewoon grotendeels Symfony

[Cartman!]

Ventieldopje schreef op maandag 14 november 2016 @ 19:22:
[...]
Tsja, maar dan zitten we in ieder geval weer op één lijn wat betreft frameworks. Een eigen framework is overigens ook niet per definitie 100% eigen code. Laravel is ook gewoon grotendeels Symfony

Daar heb je een punt maar dan bouw je je framework weer met library code (componenten, hoe je t noemt) en het gaat juist om frameworks maken zonder libraries omdat liever zelf het wiel wordt uitgevonden.

[Verwijderd]

Cartman! schreef op maandag 14 november 2016 @ 19:17:
[...]

Het kan allemaal als je goed genoeg bent maar waarom zou je al die tijd erin willen steken als anderen dat allang voor je opgelost hebben en getest en gebruikt hebben in productie?

[...]

Dan hebben we een verschil in interpretatie van wat professioneel is denk ik. Tenzij het developers zijn bij Facebook of Twitter die dusdanig in grote schaal moeten werken dat gewone frameworks niet voldoen. Maar zelfs daar maken ze eigen frameworks (denk aan bijvoorbeeld React) om dingen op te lossen en hebben ze daar de resources het echt goed door te testen en security scans te doen (en stellen ze t weer open source beschikbaar).

Ik ben echt benieuwd wat voor soort projecten er dus gemaakt worden door diegenen die jij kent en geen gebruik maken van frameworks.

Ik heb het over software engineers die informatica (wo- en hbo-niveau) gestudeerd hebben.
Het gaat over webapplicaties voor diverse grote ondernemingen.

[Ventieldopje]

Cartman! schreef op maandag 14 november 2016 @ 19:25:
[...]

Daar heb je een punt maar dan bouw je je framework weer met library code (componenten, hoe je t noemt) en het gaat juist om frameworks maken zonder libraries omdat liever zelf het wiel wordt uitgevonden.

Dan ben ik bang dat je in 99% het wiel opnieuw uitvind. Niets mis mee mits om goeie redenen, ego of "professioneel" is er daar geen van.

Verwijderd schreef op maandag 14 november 2016 @ 19:25:
[...]


Ik heb het over software engineers die informatica (wo- en hbo-niveau) gestudeerd hebben.
Het gaat over webapplicaties voor diverse grote ondernemingen.

Ehh, gefeliciteerd

[Cartman!]

Verwijderd schreef op maandag 14 november 2016 @ 19:25:
Ik heb het over software engineers die informatica (wo- en hbo-niveau) gestudeerd hebben.
Het gaat over webapplicaties voor diverse grote ondernemingen.

Wat voor soort webapplicaties dan en in welke talen wordt dat gemaakt? Ik kan me werkelijk waar niet voorstellen dat die lui allemaal t wiel opnieuw aan t uitvinden zijn. Aan de andere kant heb ik genoeg sollicitatiegesprekken gedaan met (hoger opgeleide) mensen die ook niet wisten wat bijv. XSS was en wat ze er tegen moesten doen...

Ventieldopje schreef op maandag 14 november 2016 @ 19:27:
Dan ben ik bang dat je in 99% het wiel opnieuw uitvind. Niets mis mee mits om goeie redenen, ego of "professioneel" is er daar geen van.

Zeker, daarom zou ik dit als developer ten alle tijden willen vermijden. Meestal wordt het wiel namelijk vierkant uitgevonden. Ik denk dat professionaliteit daar zeker een rol in speelt, ken je eigen beperkingen en ga zo spaarzaam mogelijk om met je tijd. Ik heb de zelfkennis dat ik niet een betere logger dan Monolog ga maken, of een betere template engine dan Twig (geen uitnodiging deze twee voorbeelden te bediscussieren ) en verwacht dat iedere developer dat heeft. Ik besteed die tijd liever aan het zo goed maken van m'n project voor de klant.

[Verwijderd]

Wauw... O.o

[Tjolk]

Cartman! schreef op maandag 14 november 2016 @ 19:37:

Zeker, daarom zou ik dit als developer ten alle tijden willen vermijden. Meestal wordt het wiel namelijk vierkant uitgevonden. Ik denk dat professionaliteit daar zeker een rol in speelt, ken je eigen beperkingen en ga zo spaarzaam mogelijk om met je tijd. Ik heb de zelfkennis dat ik niet een betere logger dan Monolog ga maken, of een betere template engine dan Twig (geen uitnodiging deze twee voorbeelden te bediscussieren ) en verwacht dat iedere developer dat heeft. Ik besteed die tijd liever aan het zo goed maken van m'n project voor de klant.

Op zich heb je gelijk, maar toch kan het zeker geen kwaad om zelf ook eens de moeite te nemen om een framework te bouwen. Gewoon voor jezelf en niet voor productie. Je leert daarmee toch een hoop zaken zelf te bekijken en zo weet je gewoon beter wat er allemaal gebeurd onder de motorkap.

[Cartman!]

Ger schreef op dinsdag 15 november 2016 @ 08:00:
Gewoon voor jezelf en niet voor productie.

Precies maar dan is het doel anders Overigens besteed ik m'n tijd liever aan nieuwe dingen maar dat is dan een persoonlijke keuze.

Verwijderd schreef op dinsdag 15 november 2016 @ 00:12:
Wauw... O.o

Ik ben nog steeds benieuwd naar je beweegredenen om alles zelf te willen doen.

[ Voor 52% gewijzigd door Cartman! op 15-11-2016 08:57 ]

[Hydra]

Verwijderd schreef op maandag 14 november 2016 @ 19:25:
Ik heb het over software engineers die informatica (wo- en hbo-niveau) gestudeerd hebben.
Het gaat over webapplicaties voor diverse grote ondernemingen.

Ik ken genoeg HBO-informatica 'ontwikkelaars' die bij dat soort shops werken en dat zijn m.i. geen van allen professionele developers.

Als je als developer niet inziet dat het in vrijwel alle situaties beter is om een ander zoveel mogelijk werk te laten doen ben je gewoon een prutser. Dit zijn de types die vinden dat ze prima zelf een SHA-1 based password hash kunnen bakken i.p.v. gewoon een standaard framework te gebruiken dat wel battle-tested is.

Cartman! schreef op dinsdag 15 november 2016 @ 08:50:
Ik ben nog steeds benieuwd naar je beweegredenen om alles zelf te willen doen.

Arrogantie. Niks meer. Niks minder. Een groot probleem onder developers die meestal alleen / in kleine teams werken.

[ Voor 21% gewijzigd door Hydra op 15-11-2016 09:34 ]

[ThomasG]

Hydra schreef op dinsdag 15 november 2016 @ 09:33:
[...]


Arrogantie. Niks meer. Niks minder. Een groot probleem onder developers die meestal alleen / in kleine teams werken.

Dat, en omdat er een hoop broodje aap verhalen de ronde doen. Een argument wat ik vaak gehoord heb, is dat zo'n framework traag is. Terwijl ze relatief snel zijn wanneer je ze niet constant in debug mode draait, en de caches hun werk laat doen.

[jbdeiman]

ThomasG schreef op dinsdag 15 november 2016 @ 10:00:
[...]
Dat, en omdat er een hoop broodje aap verhalen de ronde doen. Een argument wat ik vaak gehoord heb, is dat zo'n framework traag is. Terwijl ze relatief snel zijn wanneer je ze niet constant in debug mode draait, en de caches hun werk laat doen.

Dat is tegenwoordig wel waar, maar er zijn veel ontwikkelaars die al meer dan 5 jaar PHP ontwikkelen. De laatste jaren zijn er verschillende (en echt vollwassen) frameworks ontstaan maar als je dan al zelf een basis hebt geschreven waar je op voort kan borduren, waarom zou je dan opnieuw beginnen op basis van een Framwork, anders dan dat je tegen dusdanige problemen aanloopt, dat een herschrijf actie benodigd is?

Ik vind het persoonlijk te kort door de bocht om te stellen dat je niet professioneel bent als je geen framework gebruikt. Wel ben ik het ermee eens dat de voordelen van een framework veel meer waard zijn dan enkele nadelen.
Professionaliteit is voor mij te halen uit enkele zaken:
- De basis begrijpen/ kennen (dus ook weten wat er onder de motorkap gebeurt). D.w.z. niet blind alleen maar van een framework uitgaan maar ook een (gezonde!) nieuwsgierigheid naar hoe e.e.a. werkt, ipv het alleen maar te gebruiken.
- Een vertaling kunnen maken van gewenste functionaliteit naar te gebruiken stukken van een framework + bepalen hoe/ wat je aan gegevens nodig hebt om aan de functionaliteit te voldoen. Welke objecten met welke parameters/ velden zijn nodig en hoe ziet het datamodel eruit (dit kan ook op basis van je code gecreëerd worden)
- Weten waarom je bepaalde functionaliteiten wel of juist niet gebruikt, keuzes kunnen onderbouwen, dus niet "omdat iedereen het doet" of "omdat ik ervan uitga dat deze functionaliteit goed werkt of het framework dit vast perfect kan" zoals ik een paar keer terug denk te lezen in dit topic, maar ook snappen wat er dan gebeurt en waarom dit dan een goede optie is. Dit kan uiteraard door te proberen e.e.a. uit de code te halen, maar kan in veel gevallen ook op basis van ervaringen van anderen en documentatie over frameworks.

[Hydra]

jbdeiman schreef op dinsdag 15 november 2016 @ 10:22:
Dat is tegenwoordig wel waar, maar er zijn veel ontwikkelaars die al meer dan 5 jaar PHP ontwikkelen. De laatste jaren zijn er verschillende (en echt vollwassen) frameworks ontstaan maar als je dan al zelf een basis hebt geschreven waar je op voort kan borduren, waarom zou je dan opnieuw beginnen op basis van een Framwork, anders dan dat je tegen dusdanige problemen aanloopt, dat een herschrijf actie benodigd is?

Omdat wat je zelf geschreven hebt hoogstwaarschijnlijk gewoon vrij bagger is t.o.v. wat er in de markt beschikbaar is. Het is arrogant te denken dat jij in je eentje iets neer kan zetten met iets in de buurt van de kwaliteit en flexibiliteit van een groot OS framework.

Ik vind het persoonlijk te kort door de bocht om te stellen dat je niet professioneel bent als je geen framework gebruikt.

Wat is professionaliteit in jouw ogen? Je wordt betaald om goeie software op te leveren, niet om wielen opnieuw uit te vinden. Een eigen 'framework' schrijven en onderhouden kost op z'n minst tijd die je nuttiger kunt besteden. En in de worst case zitten er gewoon ernstige security bugs in.

Professionaliteit is voor mij te halen uit enkele zaken:
- De basis begrijpen/ kennen (dus ook weten wat er onder de motorkap gebeurt).

Het gebruik van een framework sluit niet uit dat je de interne werking ervan goed kent. Ik heb zelf veel Spring kennis. Dat is onderdeel van m'n marketability zelf. Hoeveel bedrijven denk je dat geïnteresseerd zijn in mijn kennis van het home-grown Coldfusion framework waar ik in m'n vorige (korte) baan mee gewerkt heb? Dat is exact 1.

[ Voor 14% gewijzigd door Hydra op 15-11-2016 10:34 ]

[Barryvdh]

Hydra schreef op dinsdag 15 november 2016 @ 10:34:
[...]


Omdat wat je zelf geschreven hebt hoogstwaarschijnlijk gewoon vrij bagger is t.o.v. wat er in de markt beschikbaar is. Het is arrogant te denken dat jij in je eentje iets neer kan zetten met iets in de buurt van de kwaliteit en flexibiliteit van een groot OS framework.


[...]


Wat is professionaliteit in jouw ogen? Je wordt betaald om goeie software op te leveren, niet om wielen opnieuw uit te vinden. Een eigen 'framework' schrijven en onderhouden kost op z'n minst tijd die je nuttiger kunt besteden. En in de worst case zitten er gewoon ernstige security bugs in.

Al is het natuurlijk zo dat Laravel en Symfony in de eerste instantie ook gewoon 'interne frameworks' waren. En Laravel is grotendeels door 1 persoon geschreven (Taylor Otwell). Toen werd het natuurlijk wel populairder en meer mensen die meewerkten met pull requests ed. Dus dat had wel degelijk iets wat 'beter' (of iig anders) dan bestaande frameworks was.
Toegeven, hij gebruikte bijv. wel de HttpFoundation van Symfony, maar het Eloquent ORM en de Blade templating code zijn volgens mij gewoon vanaf scratch geschreven.
Ook alle andere componenten/libraries van alle frameworks zijn ooit ontstaan als alternatief voor bestaande code. Al is het in 99% niet zo dat nieuw == beter.

Maar ik heb zelf ook nog steeds een eigen CMS wat ik heel soms gebruikt. Is lang niet zo flexibel/uitgebreid als Laravel of Drupal/Wordpress, maar dat hoeft ook helemaal niet. Het is snel op te zetten voor bepaalde sites, snelle requests (doet bijna niks) en simpel. Het kan best zijn dat je intern in een bedrijf met je team gewoon een goed framework hebt wat gewoon werkt. Maar hoe meer ik met libraries/frameworks werk, hoe meer ik probeer bestaande onderdelen stapje voor stapje te vervangen (bijv eigen DB class -> Eloquent, templates -> Twig, router/http foundation erin etc.).


Grote voordeel van Laravel ed. is dat, als het een keer afwijkt van je standaard project, je niet alsnog alles zelf hoeft te doen. Er bestaat al gewoon zoveel, veel use cases zijn al voorbij gekomen en geïmplementeerd door anderen. Of iig rekening mee gehouden zodat je het alsnog zelf flexibel kan inbouwen.

[jbdeiman]

Hydra schreef op dinsdag 15 november 2016 @ 10:34:
[...]


Omdat wat je zelf geschreven hebt hoogstwaarschijnlijk gewoon vrij bagger is t.o.v. wat er in de markt beschikbaar is. Het is arrogant te denken dat jij in je eentje iets neer kan zetten met iets in de buurt van de kwaliteit en flexibiliteit van een groot OS framework.

Je moet wel de tijd investeren om de boel opnieuw op te bouwen met een framework en je daarin te verdiepen. Soms kan dit gewoon niet uit, of is dit niet mogelijk doordat een baas/ manager zit te pushen. (nu kan je je afvragen of de manager dan een professional is, maar dat is een andere discussie.)

[...]

Hydra schreef op dinsdag 15 november 2016 @ 10:34:
Wat is professionaliteit in jouw ogen? Je wordt betaald om goeie software op te leveren, niet om wielen opnieuw uit te vinden. Een eigen 'framework' schrijven en onderhouden kost op z'n minst tijd die je nuttiger kunt besteden. En in de worst case zitten er gewoon ernstige security bugs in.

Maar als de software werkt op basis van een (wat ouder) eigen geschreven systeem, dan is daar in mijn ogen niets mis mee, of er hoeft niets mis mee te zijn. Het is ook de aard van de applicatie waar je mee te maken hebt. Is het een simpel CMS om content op een website te toveren, zie ik er niet veel problemen in.

Ik stel ook niet dat het nu goed is te beginnen zonder framework, maar ik vind het te kort door de bocht om te zeggen "een ontwikkelaar die geen standaard framework gebruikt is geen professional", omdat er ook oude(re) applicaties zijn uit de tijd dat die standaard frameworks (of de 1e die er toen was) niet volwassen genoeg was om te gebruiken, of daadwerkelijk overkill voor iets wat gewenst is.

Hydra schreef op dinsdag 15 november 2016 @ 10:34:
[...]


Het gebruik van een framework sluit niet uit dat je de interne werking ervan goed kent. Ik heb zelf veel Spring kennis. Dat is onderdeel van m'n marketability zelf. Hoeveel bedrijven denk je dat geïnteresseerd zijn in mijn kennis van het home-grown Coldfusion framework waar ik in m'n vorige (korte) baan mee gewerkt heb? Dat is exact 1.

Dat stel ik ook niet, ik definieer alleen wanneer ik iemand een professional vindt. Dat jij een framework (of meerdere) kent en kan gebruiken is 1 ding, maar dat je begrijpt wat die doet en waarom dat framework gebruiken een goede keuze is is minstens net zo belangrijk in mijn ogen.

[Cartman!]

jbdeiman schreef op dinsdag 15 november 2016 @ 11:05:
[...]
Je moet wel de tijd investeren om de boel opnieuw op te bouwen met een framework en je daarin te verdiepen. Soms kan dit gewoon niet uit, of is dit niet mogelijk doordat een baas/ manager zit te pushen. (nu kan je je afvragen of de manager dan een professional is, maar dat is een andere discussie.)

Als je die tijd blijft investeren in je eigen bagger of in bestaande en bewezen technologie dan is dat toch een makkelijke keuze?

Maar als de software werkt op basis van een (wat ouder) eigen geschreven systeem, dan is daar in mijn ogen niets mis mee, of er hoeft niets mis mee te zijn. Het is ook de aard van de applicatie waar je mee te maken hebt. Is het een simpel CMS om content op een website te toveren, zie ik er niet veel problemen in.

Dat zijn meestal juist de soort projecten die vol zitten met lekken.

Ik stel ook niet dat het nu goed is te beginnen zonder framework, maar ik vind het te kort door de bocht om te zeggen "een ontwikkelaar die geen standaard framework gebruikt is geen professional", omdat er ook oude(re) applicaties zijn uit de tijd dat die standaard frameworks (of de 1e die er toen was) niet volwassen genoeg was om te gebruiken, of daadwerkelijk overkill voor iets wat gewenst is.

Het is ook erg kort door de bocht natuurlijk maar in mijn ervaring is er wel een zeer grote correlatie tussen die twee.

Dat stel ik ook niet, ik definieer alleen wanneer ik iemand een professional vindt. Dat jij een framework (of meerdere) kent en kan gebruiken is 1 ding, maar dat je begrijpt wat die doet en waarom dat framework gebruiken een goede keuze is is minstens net zo belangrijk in mijn ogen.

Dat is zeker belangrijk. Ik ben er redelijk van overtuigd dat je door het bestuderen van framework code je veel meer leert dan zelf vierkante wielen uit te vinden. Als je een framework op de verkeerde manier gebruikt (ook daarvan iemand in t team gehad) dan kun je er ook flinke bagger mee produceren

Niet onbelangrijk: de doorlooptijd van mijn projecten wisselt een beetje van een week tot 6 maanden, op die manier kun je natuurlijk makkelijker switchen van dingen dan als je aan een legacy project zit wat al jaren live staat. Maar ook in dat geval (wel een paar keer gezien) is het vaak lonend om delen stukje bij beetje te vervangen om een betere/veiligere code base te krijgen.

[jbdeiman]

Cartman! schreef op dinsdag 15 november 2016 @ 11:25:
[...]

Als je die tijd blijft investeren in je eigen bagger of in bestaande en bewezen technologie dan is dat toch een makkelijke keuze?

[...]

Dat zijn meestal juist de soort projecten die vol zitten met lekken.

[...]

Het is ook erg kort door de bocht natuurlijk maar in mijn ervaring is er wel een zeer grote correlatie tussen die twee.

[...]

Dat is zeker belangrijk. Ik ben er redelijk van overtuigd dat je door het bestuderen van framework code je veel meer leert dan zelf vierkante wielen uit te vinden. Als je een framework op de verkeerde manier gebruikt (ook daarvan iemand in t team gehad) dan kun je er ook flinke bagger mee produceren

Niet onbelangrijk: de doorlooptijd van mijn projecten wisselt een beetje van een week tot 6 maanden, op die manier kun je natuurlijk makkelijker switchen van dingen dan als je aan een legacy project zit wat al jaren live staat. Maar ook in dat geval (wel een paar keer gezien) is het vaak lonend om delen stukje bij beetje te vervangen om een betere/veiligere code base te krijgen.

Ik kan mij prima vinden in je redenatie. Het ging mij er vooral om dat er zo kort door de bocht gezegd wordt dat je niet professioneel bent als je geen framework gebruikt.
Natuurlijk wil je op den duur overstappen op gebruik van een goed framework.

Wij hebben de keuze gemaakt de oude applicatie "uit te dienen" (gewoon te onderhouden), en een volledig nieuwe applicatie te bouwen met alle inzichten die we in de loop der jaren hebben opgedaan t.a..v. de sector waarvoor we ontwikkelen.
Dan ga je niet meer investeren in het volledig ombouwen van de bestaande applicatie (10 jaar oud), maar blijf je die onderhouden. Om de mensen die daar (nog steeds) mee werken dan geen professional te noemen gaat mij te ver, en daar is het in mijn reacties om te doen.

[Cartman!]

jbdeiman schreef op dinsdag 15 november 2016 @ 12:18:
Om de mensen die daar (nog steeds) mee werken dan geen professional te noemen gaat mij te ver, en daar is het in mijn reacties om te doen.

Ik mag voor die mensen hopen dat ze niet enkel in die oude bende hoeven te werken en daarnaast ook kunnen meewerken aan nieuwe code die wel gebruik maakt van moderne libraries en frameworks. Zoniet? Dan doen ze zichzelf best te kort qua werk (ik neem namelijk dan aan dat t extreem goed betaalt ).

[jbdeiman]

Cartman! schreef op dinsdag 15 november 2016 @ 12:20:
[...]

Ik mag voor die mensen hopen dat ze niet enkel in die oude bende hoeven te werken en daarnaast ook kunnen meewerken aan nieuwe code die wel gebruik maakt van moderne libraries en frameworks. Zoniet? Dan doen ze zichzelf best te kort qua werk (ik neem namelijk dan aan dat t extreem goed betaalt ).

De betreffende mensen worden omgeschoold in een nieuwe ontwikkeltaal (van PHP naar C# (ASP.NET v 4.5) ) en een nieuw Framework. Dus ja, ze worden langzamerhand omgeschoold en werken niet enkel in die oude bende.

Maar het is voor ons wel een noodzakelijk kwaad de oude bende voorlopig nog te onderhouden, al doen we echt de minimale (wettelijke) wijzigingen in de applicatie en praktisch geen nieuwe / gewijzigde functionaliteiten meer, tenzij de klant daar heel goed voor betaald.

[ Voor 3% gewijzigd door jbdeiman op 15-11-2016 12:52 ]

[Hydra]

jbdeiman schreef op dinsdag 15 november 2016 @ 12:18:
Ik kan mij prima vinden in je redenatie. Het ging mij er vooral om dat er zo kort door de bocht gezegd wordt dat je niet professioneel bent als je geen framework gebruikt.

Moedwillig. Dat leek me duidelijk. Dat je als junior dev in een organisatie weinig in de melk te brokkelen hebt lijkt me evident. Men ageert hier tegen devs die shit produceren, niet tegen de devs die die shit op moeten ruimen.

[Castor385]

Ik ben eigenlijk nog steeds geïnteresseerd in de overweging om alle code zelf te schrijven. Mijns inziens is er veel te zeggen over het zelf schrijven van al je code:

• je hebt amper last van known vulnerablities
• je kent je code door en door
• je hebt veel invloed
• je hoeft compontenten/frameworks niet zelf door te lichten op security risks

Maar het heeft ook nadelen:

• Je zult je zelf moeten wapenen tegen security risico's (bijvoorbeeld: XSS, CSRF, session handling, authentication, authorisation, direct object references, input validation)
• Je schrijft code, wat al door talloze voorgangers is gemaakt
• Je schrijft meer framework code zelf (wat ik zelf veel minder interessant vind dan de functionaliteit van je applicatie)

Hebben jullie nog andere overwegingen die ik nu niet heb opgenoemd?

[ Voor 13% gewijzigd door Castor385 op 15-11-2016 15:05 ]

[Woy]

Modbreak:

Zo is het wel genoeg geweest. We gaan hier niet op de man spelen.

Ik heb off-topic reacties verwijderd!

[Cartman!]

Castor385 schreef op dinsdag 15 november 2016 @ 14:56:
Mijns inziens is er veel te zeggen over het zelf schrijven van al je code:

je hebt amper last van known vulnerablities

Security through obscurity is nooit een goede reden. Dat je code niet bij anderen bekend is betekent niet dat er geen exploits gevonden zullen worden en misbruikt zullen worden. Dit kunnen zelfs hele simpele dingen zijn waar je niet bij stil hebt gestaan (zo ben ik in het verleden met een eigen framework eens nat gegaan op null byte injection).

je kent je code door en door

Eens maar dat kan bij frameworks ook natuurlijk. Door en door kennen kan ook betekenen dat je weet waar de zwakke plekken zitten die je eigenlijk zou willen verbeteren.

je hebt veel invloed

Zeker, maar daar staat tegenover dat (bijna) niemand je tegen houdt om slechte code te schrijven of bad practices toe te passen.

Zelf denk ik dat het grotendeels gebaseerd is op onzekerheid, het is nieuw en het gaat tijd kosten er mee om te kunnen gaan.

[ Voor 12% gewijzigd door Cartman! op 15-11-2016 15:09 ]

[Castor385]

Mee eens dat Security through obscurity op zichzelf geen goede reden is, maar het maakt jouw applicatie wel net ff iets minder makkelijk te hacken dan dat van je buurman. Uiteindelijk gaat de hacker daar naar waar het slot het zwakst is (of waar de deur open staat). Je zult zelf natuurlijk wel moeten zorgen dan er geen exploits in je code zitten, anders staat de spreekwoordelijke deur gewoon gigantisch open met een neon reclame bord ernaast.

[Cartman!]

Castor385 schreef op dinsdag 15 november 2016 @ 15:19:
Mee eens dat Security through obscurity op zichzelf geen goede reden is, maar het maakt jouw applicatie wel net ff iets minder makkelijk te hacken dan dat van je buurman.

Ik vind dat wel wat naief eigenlijk, je gaat er dan een beetje vanuit dat een kwaadwillende een keuze maakt op basis van de fouten van een ander. Dat werkt misschien bij scriptkiddies zo maar niet bij iedereen. Als er bij jou (danwel de server waar jij op zit die je misschien deelt met anderen) dan kan het totaal geen verschil maken.

Uiteindelijk gaat de hacker daar naar waar het slot het zwakst is (of waar de deur open staat). Je zult zelf natuurlijk wel moeten zorgen dan er geen exploits in je code zitten, anders staat de spreekwoordelijke deur gewoon gigantisch open met een neon reclame bord ernaast.

Daar gaat het dus om... als jij iets zelf maakt dan ga je niet weten of er wel of geen exploits inzitten omdat je immers gelimiteerd bent door je eigen kennis van exploits. Ik ben ooit eens (in een security scan) gewezen op null byte injections in een oud framework wat ik had gemaakt waar ik nog nooit van gehoord had... Als je het niet kent kun je je er ook niet tegen wapenen terwijl als je met heel veel mensen open source iets maakt de kans dat iemand het spot en fixt veel groter is dan jij in je eentje.

[Hydra]

Castor385 schreef op dinsdag 15 november 2016 @ 15:19:
Mee eens dat Security through obscurity op zichzelf geen goede reden is, maar het maakt jouw applicatie wel net ff iets minder makkelijk te hacken dan dat van je buurman.

Juist niet. Home grown stuff is een prime target juist omdat daar vaak nog wat te halen valt.

Je zult zelf natuurlijk wel moeten zorgen dan er geen exploits in je code zitten, anders staat de spreekwoordelijke deur gewoon gigantisch open met een neon reclame bord ernaast.

Euh tja. "Gewoon geen fouten maken". Was het leven maar zo simpel

[ Voor 26% gewijzigd door Hydra op 15-11-2016 15:31 ]

[Castor385]

Hydra schreef op dinsdag 15 november 2016 @ 15:30:
[...]


Juist niet. Home grown stuff is een prime target juist omdat daar vaak nog wat te halen valt.

Ik heb mijn beredenering niet goed geformuleerd denk ik. Wat ik bedoel:
Als je twee applicaties hebt, die beiden van dezelfde techniek gebruik maakt, dan is degene waarbij security through obscurity wordt toegepast, net iets minder makkelijk te hacken dan de applicatie die dat niet heeft.

Ik bedoel hier niet dat security through obscurity op zichzelf voldoende is. Verre van dat!


Overigens ben ik zelf van mening dat je beter gebruik kan maken van goed aangeschreven frameworks omwille van security risks en productiviteit, maar ik kan me voorstellen dan niet iedereen dezelfde mening heeft en misschien een uiterst slechte ervaring heeft gehad, juist door frameworks te gebruiken.

[ Voor 20% gewijzigd door Castor385 op 15-11-2016 15:36 ]

[Cartman!]

Dat hangt er nog steeds vanaf of de rest van het systeem al niet zo lek is als een mandje. Je kan dingen wel obscuur maken maar als ze fundamenteel onveiliger zijn dan heb je daar helemaal niks aan. Het zou enkel opgaan als beide systemen identiek zijn en je bij 1 van de 2 daar nog extra dingen aan toegevoegd hebt.

[Hydra]

Castor385 schreef op dinsdag 15 november 2016 @ 15:34:
Ik heb mijn beredenering niet goed geformuleerd denk ik. Wat ik bedoel:
Als je twee applicaties hebt, die beiden van dezelfde techniek gebruik maakt, dan is degene waarbij security through obscurity wordt toegepast, net iets minder makkelijk te hacken dan de applicatie die dat niet heeft.

Je misbruikt de term. "Beveiliging door middel van onduidelijkheid" is compleet wat anders dan "extra beveiliging dankzij obfuscation". Security through obscurity is het eerste, niet het tweede. Niemand bestrijd het nut van obfuscation als extra maatregel.

[Castor385]

Je hebt gelijk, ik heb inderdaad de term niet goed gebruikt.