De zin en onzin van frameworks, deel 2

maandag 12 november 2012 21:19

mie noow noooothing ...

Avalaxy schreef op maandag 12 november 2012 @ 21:11:
Zoals je het nu opschrijft ben ik het zelfs met je eens Op je punt over MVVM na dan, dat vind ik niet echt groot/complex/ingewikkeld, maakt het simpelweg makkerlijker om je code te testen.

Omdat ikzelf niets van MVVM ken, heb ik even gegoogled en was ik verbaasd het volgende te lezen:

A criticism of the pattern comes from MVVM creator John Gossman himself,[13] who points out that the overhead in implementing MVVM is “overkill” for simple UI operations. He also states that for larger applications, generalizing the View layer becomes more difficult. Moreover, he illustrates that data binding, if not managed well, can result in considerable memory consumption in an application.

Acties:

Avalaxy

Mja, simpel als in 1 view. Zodra je iets bouwt wat ook maar iets groter is zou ik het wel doen

Zeker met bv. MVVMLight is het allemaal helemaal niet zo spectaculair.

maandag 12 november 2012 21:37

Acties:

maandag 12 november 2012 21:42

Topicstarter

Avalaxy schreef op maandag 12 november 2012 @ 21:11:
Zoals je het nu opschrijft ben ik het zelfs met je eens

Dank je

Op je punt over MVVM na dan, dat vind ik niet echt groot/complex/ingewikkeld, maakt het simpelweg makkerlijker om je code te testen.

Leuke link van edeboeck. Dat wist ik ook niet.

Het interessante aan WPF is natuurlijk 3D en Silverlight, en het idee dat je daarmee nu wel op een simpele manier mooie en complexe controls mee kunt maken. Het 3D deel is heel cool maar beperkt, en alhoewel user controls heel aardig zijn, is het echt heel lastig om je control precies goed te krijgen. Vooral borders en padding zijn echt een crime.

Maar als je dan meer wilt en voor een complete custom control gaat, dan gaat de complexiteit door het dak.

De meest complexe die ik heb gemaakt was een grid van checkboxes die zichzelf aanpast aan de input, en "complex" is een understatement.

Het enige wat ik nog mis is wat je doel is met dit topic. Probeer je ons te overtuigen, hoop je tegenstanders te vinden om mee te discussiëren, ...?

Ik wil er voornamelijk eens over discussiëren, kijken wat jullie er van vinden. En misschien kunnen we samen uitvinden wat nu het beste compromis is.

Acties:

maandag 12 november 2012 21:44

Topicstarter

Avalaxy schreef op maandag 12 november 2012 @ 21:19:
Mja, simpel als in 1 view. Zodra je iets bouwt wat ook maar iets groter is zou ik het wel doen Zeker met bv. MVVMLight is het allemaal helemaal niet zo spectaculair.

Het interessante aan MVVM is (denk ik) de "live" data-binding. Maar daar die via XAML gaat, is alles een string en kun je het niet debuggen, omdat je je context verliest. Je zit ineens in een andere thread. En dat geld ook voor je converters.

En XAML zelf is leuk als je iets simpels wilt, maar je hebt al snel een heleboel bestandjes, die allemaal weer een stukje overriden. Binnen de kortste keren ben je het overzicht kwijt.

En styles lijken geweldig en zien er supergelikt uit, totdat je ze moet implementeren.

Acties:

maandag 12 november 2012 22:07

Het begint echter lastiger te worden, als de klant komt met moeilijke vragen voor nieuwe functionaliteit waar je geen rekening mee hebt gehouden. Voor je het weet, moet je je in allerlei bochten wringen om die functionaliteit mogelijk te maken, het framework aanpassen of "nee" zeggen.

Wat betreft de frameworks ben ik het toch niet met je eens. Als ik naar de huidige frameworks kijk(voornamelijk php i.vm. werk) dan zitten die degelijk in elkaar en zijn ze over het algemeen aardig flexibel. De kracht van deze frameworks is juist dat al die simpele dingen die je in elke website opnieuw moet maken al voor je gedaan zijn, maar dat ze goede mogelijkheden bieden om zelf het framework uit te breiden. Dankzij dingen als OO met overerving kan je op die manier heel makkelijk over al de basis functionaliteit beschikken en daar zelf op voort bouwen.

Ik snap niet echt hoe jij dit voor je ziet. Als je bij elke nieuwe klant vanaf nul begint ben je mijns inziens heel veel werk dubbel aan het doen. Zodra je zelf dingen gaat generaliseren ben je eigenlijk het werk aan het doen dat de frameworks al eerder gedaan hebben. Daarnaast zijn frameworks er in allerlei soorten en maten. Als je een minimalistisch framework wil dat flexibel is kan je dat doen, maar je kunt ook een full-stack framework kiezen met veel abstractie als je dat liever hebt.

Ook vind ik het zeer belangrijk dat je applicatie zo leesbaar en begrijpelijk mogelijk is. Niet door goede documentatie te eisen, want dat gebeurt in de praktijk toch nooit. Gewoon door dingen zo duidelijk en logisch mogelijk op te zetten. Je kunt achteraf altijd profilen om die paar functies die alle tijd kosten te optimaliseren.

Hier spreek je jezelf volgens mij juist tegen. Een framework kan juist heel veel duidelijkheid bieden. Ten eerste zit een heleboel boilerplate code in het framework, dus dat is code die je niet hoeft te schrijven, testen en onderhouden. Daarnaast zijn frameworks eigenlijk altijd met een bepaald paradigma ontwikkeld en daardoor wordt je geforceerd om code te schrijven die aan deze sctructuur voldoet. MVC frameworks kunnen op deze manier onwijs helpen om je codebase eenduidig te houden.

Dat er altijd frameworks zijn die teveel willen lijkt mij wel duidelijk en wat dat betreft ben ik het wel met je eens. Je moet geen framework kiezen omdat deze zoveel mogelijk functies heeft. Een framework moet je helpen jou doel te bereiken, het moet niet een doel opzich zijn.

Acties:

maandag 12 november 2012 22:31

Topicstarter

7laurens7, ik ben het helemaal met je eens. Dat is de "zin" van frameworks. Ik zeg ook helemaal niet dat je geen frameworks moet gebruiken. Wel: met mate.

Ik heb vooral mijn bedenkingen tegen het geforceerd worden om dingen op de manier van het framework te doen. Klanten hebben daar geen boodschap aan; die komen met dingen die in hun ogen heel simpel zijn, maar soms heel moeilijk te implementeren zijn omdat het framework het niet toestaat.

Ok, je wilt natuurlijk niet dat iedereen alles op zijn eigen manier doet, want dat is ook geen optie.

Ook de uitbreidbaarheid (OO) is een tweesnijdend mes: zolang je altijd een nieuwe class afleid van de laatste en compleetste, sleep je steeds meer overtollige bagage mee. En als je steeds afleid van een base-class of interface, werken je "generieke" functies maar op een subset en moet je ze steeds opnieuw maken.

Het is dus vaak beter om je base-class aan te passen en de methods daarvan uit te breiden. Context en viewstate zijn vooral gevoelig voor die afwegingen, omdat je er maar 1 hebt. Je wilt ook geen viewstate waar alles in zit, dus een set hapklare containers met lazy-loading zijn dan een goed alternatief.

Acties:

maandag 12 november 2012 22:41

Ook de uitbreidbaarheid (OO) is een tweesnijdend mes: zolang je altijd een nieuwe class afleid van de laatste en compleetste, sleep je steeds meer overtollige bagage mee. En als je steeds afleid van een base-class of interface, werken je "generieke" functies maar op een subset en moet je ze steeds opnieuw maken.

Dit is natuurlijk het hele probleem van OO. Hoe verdeel je de verantwoordelijkheden? Dat kan in sommige situaties best even denken zijn. Eerlijk is eerlijk, ik vind OO een godsgeschenk, maar net als met elke technologie moet je het wel goed gebruiken. ook OO kan onwijs misbruikt worden en dan kun je inderdaad gedrochten van applicaties krijgen.

[quute]Het is dus vaak beter om je base-class aan te passen en de methods daarvan uit te breiden. Context en viewstate zijn vooral gevoelig voor die afwegingen, omdat je er maar 1 hebt. Je wilt ook geen viewstate waar alles in zit, dus een set hapklare containers met lazy-loading zijn dan een goed alternatief.[/quote]

Hier ben ik het niet mee eens. Ik zou niet uit gemak een base klasse maken met te veel verantwoordelijkheden. Een klasse hoort niet verantwoordelijk te zijn voor dingen waar hij eigenlijk weinig tot niets mee te maken heeft. Wat dat betreft moet je, vind ik, de structuur van je klasse dan ook uitdenken zonder bezig te zijn met de code. Je moet de verschillende verantwoordelijkheden binnen je applicatie juist zo logisch mogelijk om te zetten in een structuur van klassen en tot nu toe heeft mij dat altijd een goede structuur opgeleverd.

Acties:

maandag 12 november 2012 23:00

Topicstarter

7laurens7 schreef op maandag 12 november 2012 @ 22:31:
Dit is natuurlijk het hele probleem van OO. Hoe verdeel je de verantwoordelijkheden? Dat kan in sommige situaties best even denken zijn. Eerlijk is eerlijk, ik vind OO een godsgeschenk, maar net als met elke technologie moet je het wel goed gebruiken. ook OO kan onwijs misbruikt worden en dan kun je inderdaad gedrochten van applicaties krijgen.

Mee eens. OO is geweldig, maar je moet er wel bovenop blijven zitten.

Hier ben ik het niet mee eens. Ik zou niet uit gemak een base klasse maken met te veel verantwoordelijkheden. Een klasse hoort niet verantwoordelijk te zijn voor dingen waar hij eigenlijk weinig tot niets mee te maken heeft. Wat dat betreft moet je, vind ik, de structuur van je klasse dan ook uitdenken zonder bezig te zijn met de code. Je moet de verschillende verantwoordelijkheden binnen je applicatie juist zo logisch mogelijk om te zetten in een structuur van klassen en tot nu toe heeft mij dat altijd een goede structuur opgeleverd.

Dat heeft zowel voor- als nadelen. Want, op die manier beperk je de mogelijkheden aanzienlijk. Je kunt dat gedeeltelijk oplossen door functionaliteit in de "parent" te stoppen, maar een taal als C# met zijn Garbage Collector vind dat niet leuk.

Je beste alternatief wordt dan om voor alles een interface te maken. Dat kan heel goed werken, maar dan moet je nog steeds alle classes aanpassen die die interface implementeren als je functionaliteit toevoegt.

Uiteindelijk komt het dan neer op: hoe kunnen we zo goed mogelijk reageren op verzoeken om nieuwe functionaliteit waar we geen rekening mee hebben gehouden?

Goede vraag. Ik zou het niet weten.

Acties:

Barryvdh

Een goed framework is juist toch makkelijk uit te breiden? Ik kom vooral met PHP in aanmerking, en een CMS is inderdaad heel goed in een bepaald ding, maar zodra je iets anders wil dan standaard, wordt het veel aanpassen.
Maar een framework, zoals Symfony2, is er toch juist op gebouwd om flexibel te zijn qua functionaliteit, maar je toch een beetje te forceren om extra functionaliteit op een standaard manier te doen, zodat het voor andere ontwikkelaars ook meteen duidelijk is.

En als je 9 van de 10x hetzelfde maakt, maak je inderdaad een boilerplate voor bepaalde modellen/views/functionaliteit, maar dan sleep je toch niet overtollige bagage mee? Als je het logisch opdeelt, hoef je alleen de delen te bewaren die je nodig hebt toch?

maandag 12 november 2012 23:20

Acties:

maandag 12 november 2012 23:43

Quia Ego Sic Dico.

SymbolicFrank schreef op maandag 12 november 2012 @ 22:41:
[...]

Dat heeft zowel voor- als nadelen. Want, op die manier beperk je de mogelijkheden aanzienlijk. Je kunt dat gedeeltelijk oplossen door functionaliteit in de "parent" te stoppen, maar een taal als C# met zijn Garbage Collector vind dat niet leuk.

Wat heeft functionaliteit in de parentclass stoppen (even los van of dat per definitie een goed idee is of niet) te maken met de GC?

Je beste alternatief wordt dan om voor alles een interface te maken. Dat kan heel goed werken, maar dan moet je nog steeds alle classes aanpassen die die interface implementeren als je functionaliteit toevoegt.

Ehm...interfaces maak je over het algemeen niet voor jezelf maar voor anderen en bovendien niet in de context die je hier nu omschrijft.

Al met al klinkt het hier alsof je een idee hebt opgebouwd over wat je denkt dat OO inhoudt en onderbouwd met weinig tot geen feitenkennis heb je op basis daarvan een mening over frameworks gevormd. Een goed opgezet framework (of elke goed opgezette OO-structuur) beperkt juist de problemen die je hier omschrijft.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

Acties:

maandag 12 november 2012 23:44

Topicstarter

Barryvdh schreef op maandag 12 november 2012 @ 23:00:
Een goed framework is juist toch makkelijk uit te breiden? Ik kom vooral met PHP in aanmerking, en een CMS is inderdaad heel goed in een bepaald ding, maar zodra je iets anders wil dan standaard, wordt het veel aanpassen.
Maar een framework, zoals Symfony2, is er toch juist op gebouwd om flexibel te zijn qua functionaliteit, maar je toch een beetje te forceren om extra functionaliteit op een standaard manier te doen, zodat het voor andere ontwikkelaars ook meteen duidelijk is.

Ieder framework heeft zijn beperkingen (zoals de CMS-en), en daar loop je tegenaan als de klant met zijn eerste setje wijzigingen komt. Hoe goed het ook is, die klant is veel beter in het vinden van "onmogelijke" dingen die hij heel simpel en essentieel vind.

En als je 9 van de 10x hetzelfde maakt, maak je inderdaad een boilerplate voor bepaalde modellen/views/functionaliteit, maar dan sleep je toch niet overtollige bagage mee? Als je het logisch opdeelt, hoef je alleen de delen te bewaren die je nodig hebt toch?

Uiteraard. En na een tijdje groeit dat uit in een framework.

Acties:

R4gnax

Klinkt eerlijk gezegd alsof er iemand niet heel erg op de hoogte is van SOLID. Als je je een beetje aan die pincipes houdt, dan zal de software die je produceert over het algemeen zeer goed te overzien en zeer modulair wijzigbaar zijn.

WPF is een overgecompliceerde bende, dat zullen meer mensen met je eens zijn. Maar; dat wil niet zeggen dat alle frameworks dat zijn. ASP.NET MVC is bijvoorbeeld zeer flexibel, overzichtelijk en uitbreidbaar.

Daarnaast is de architecturele insteek van WPF nog zeer helder, het zijn de enorme hoeveelheid details die het geheel moeilijk te hanteren maken. (Van de andere kant gemeten: graphics code schrijven is nou eenmaal moeilijk. Als je ervoor pleit om meer lagen abstractie weg te smijten, dan zit je dadelijk lekker met de hand pixel buffers rond te schuiven in Direct2D; doe je dat dan liever? ... )

[ Voor 3% gewijzigd door R4gnax op 12-11-2012 23:45 ]

maandag 12 november 2012 23:55

Acties:

dinsdag 13 november 2012 00:03

Topicstarter

NMe schreef op maandag 12 november 2012 @ 23:20:
Wat heeft functionaliteit in de parentclass stoppen (even los van of dat per definitie een goed idee is of niet) te maken met de GC?

GC's vinden het niet leuk als "children" een pointer bijhouden naar hun "parent", want dan worden ze nooit opgeruimd zolang de "root" nog bestaat.

Je geheugen loopt snel vol.

Ehm...interfaces maak je over het algemeen niet voor jezelf maar voor anderen en bovendien niet in de context die je hier nu omschrijft.

Al met al klinkt het hier alsof je een idee hebt opgebouwd over wat je denkt dat OO inhoudt en onderbouwd met weinig tot geen feitenkennis heb je op basis daarvan een mening over frameworks gevormd.

Dat is dan bij deze wederzijds

Een goed opgezet framework (of elke goed opgezette OO-structuur) beperkt juist de problemen die je hier omschrijft.

In theorie wel. In de praktijk ervaar ik dat toch anders.

Misschien als iedereen altijd vooral bezig is om het framework te verbeteren, maar normaal gesproken hebben ze taken en deadlines. Snel is beter, de impact zien we wel.

Ik ben wel de laatste om te zeggen dat ik de waarheid in pacht heb, alhoewel ik misschien nogal zelfverzekerd overkom. Ik heb dit topic voornamelijk gepost om wat feedback te krijgen: ik denk nou wel dat het zo is, maar is dat ook echt zo? Ik krijg heel wisselende feedback hierover op mijn werk. Alhoewel mijn vrienden met IT kennis mij altijd het voordeel van de twijfel geven. Maar ze kunnen natuurlijk gewoon aardig willen zijn, dus dat zegt niet zo veel.

Acties:

dinsdag 13 november 2012 00:17

Quia Ego Sic Dico.

SymbolicFrank schreef op maandag 12 november 2012 @ 23:55:
[...]

GC's vinden het niet leuk als "children" een pointer bijhouden naar hun "parent", want dan worden ze nooit opgeruimd zolang de "root" nog bestaat.

Waarom zou je in een derived class een pointer moeten bewaren naar de parent, behalve als je een vorm van recursie nodig hebt? Een afgeleide class is z'n parent en kan alles van die parent aanspreken. Als je een soort van recursie wil dan kan dat ook, want zo'n grote performance-hog is het opslaan van een pointer naar een ander object ook niet, als je maar zorgt dat je je references goed opruimt indien de taal dat vereist. Maar nogmaals, in de meeste constructies ga je weinig tot nooit moeten verwijzen naar de parent en gewoon je class afleiden als er overerving nodig is...

Dat is dan bij deze wederzijds

Dat mag je denken, maar vergeet niet dat ik niet degene ben met de onorthodoxe ideeën over hoe een framework zou moeten werken.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

Acties:

dinsdag 13 november 2012 00:29

Wat ik denk dat hier het probleem is dat TS de verkeerde frameworks bekijkt.

In wezen is zo ongeveer alles wat je hergebruikt al onderdeel van je eigen "frameworkje".
Daarom heb je ook Frameworks in alle soorten en maten.

Persoonlijk vind ik ook elk groot (van het internet gedownload) framework "waardeloos" totdat wij er ons eigen miniframeworkje bovenop hebben gezet die exact doet wat wij willen en imho kan dat ook niet anders, wij hebben nu eenmaal op sommige punten een andere filosofie als de maker van het grote framework.

Dat is wmb nu net de truc, als een custom control veel extra code vergt dan zorg je dat die code in je eigen mini-frameworkje beland en jij / je collega kan daarna die custom control gewoon gebruiken net zoals alles in de rest van het framework.

Zonder mini-frameworkje zou ik ook "vloeken" op het algemene framework als ik voor de 10e keer kan copy/pasten met net 2 aanpassingen voor een custom control, maar imho is het grote framework slechts een uitbreiding van de basis van de taal en niet het eindresultaat waarin je al je code maar moet kloppen zonder je eigen framework.

Vergeet niet, naast het framework heb je altijd nog de basis-taal om in je eigen mini-frameworkje te gebruiken.

Zo vind ik Xaml ook een draak bij grotere projecten, maar ik ken concullega's die daarvoor gewoon classes hebben die weer XAML schrijft zodat dat voor hun ook weer geextraheerd wordt en hun dus niets van het draken-resultaat zien

Acties:

dinsdag 13 november 2012 00:37

Topicstarter

R4gnax schreef op maandag 12 november 2012 @ 23:44:
Klinkt eerlijk gezegd alsof er iemand niet heel erg op de hoogte is van SOLID. Als je je een beetje aan die pincipes houdt, dan zal de software die je produceert over het algemeen zeer goed te overzien en zeer modulair wijzigbaar zijn.

Ah, SOLID! (I had to look it up, it didn't ring any bell

)

Ja, wij hebben ook stand-up meetings op mijn werk omdat wij blijkbaar Extreme Programming doen. Maar volgens mij is onze manager de enige die dat denkt. En het weerhoud mijn collega's niet van het opzetten van ellenlange discussies.

Als ik al een methodologie volg, dan is het een kruising tussen KISS en Defensive Programming. Het is zo gegroeid. Ik heb geen opleiding behalve mavo, dus ik kan kiezen

Niet dat ik tegen zulke dingen ben, ik moet er alleen nog 1 tegenkomen die ook echt werkt en niet al te religieus klinkt.

WPF is een overgecompliceerde bende, dat zullen meer mensen met je eens zijn.

Dank je

Maar; dat wil niet zeggen dat alle frameworks dat zijn. ASP.NET MVC is bijvoorbeeld zeer flexibel, overzichtelijk en uitbreidbaar.

Ja, dat zeggen alle frameworks van zichzelf. En dat klopt ook, zolang je klanten geen dingen vragen waar ze geen rekening mee hebben gehouden.

En ik vind het wel al erg abstract.

Daarnaast is de architecturele insteek van WPF nog zeer helder, het zijn de enorme hoeveelheid details die het geheel moeilijk te hanteren maken. (Van de andere kant gemeten: graphics code schrijven is nou eenmaal moeilijk. Als je ervoor pleit om meer lagen abstractie weg te smijten, dan zit je dadelijk lekker met de hand pixel buffers rond te schuiven in Direct2D; doe je dat dan liever? ... )

Mijn huidige privé-project heeft alleen OpenGL als visuele output. Maar het is dan ook niet erg mainstream, of web-based. En, zo moeilijk is het niet, alleen veel werk als je bijvoorbeeld een tekstje af wilt beelden. Want je moet eerst al die tekens maken of ergens vandaan halen.

Alles lijkt moeilijk als je het nog nooit hebt gedaan. Alles is simpel als je weet hoe het werkt (en de bijbehorende bibliotheek aan functies en resources hebt).

Dat wil niet zeggen, dat het niet heel veel werk kan zijn. En daar heb je dan die frameworks voor. Maar zelf doen is op de langere termijn beter en sneller, denk ik.

Acties:

johnkeates

Zelf doen is op de lange termijn juist niet beter en sneller. Je zal nooit tegen een team dat aan een framework werkt kunnen opboksen in je eentje. Als er 100 mensen 50% van hun tijd in steken is dat altijd meer dan jij die het in je eentje 100% doet. Ook als het gespecialiseerd is.

De enige situatie waarbij dat niet zo is, is als je een omgeving hebt waarbij je geen framework kan gebruiken. Bijvoorbeeld als je custom hardware hebt waar de software niet op draait, of als je een licentiemodel hanteert dat het niet toestaat te integreren met andere soorten licenties.

Het idee achter een framework is niet alleen dat je het wiel niet opnieuw hoeft uit te vinden, maar ook dat je niet de enige bent die er aan werkt, die er mee werkt, en die uitbreidingen onderzoekt.

Zelf een framework maken is ook niet heel zinvol, want om het nuttig te maken zal je moeten abstraheren naar een hoger niveau, of juist een lager niveau, wat er voor zorgt dat het inzetbaar is bij projecten met andere vereisten. Maar dan heb je gewoon 'nog een framework'. Daarbij is het ook nog eens stom dat je dan als enige verantwoordelijk bent, want dan heb je dus ook nog alle onderhoud, beveiliging e.d. die je zelf moet doen. Daarnaast heb je weer het 'standaardiseren'. Soms is een framework voor een project niet de beste oplossing, maar voor het onderhoud, samenwerken en documenteren wel, want een framework houdt er meestal wel een of meerdere standaarden op na. Zelf een nieuwe standaard verzinnen levert je waarschijnlijk niks op, en kost ook nog eens veel tijd. Bovendien zijn er zo veel standaarden en frameworks, dat het bijna onmogelijk is om geen passende bestaande versie te vinden.

http://xkcd.com/927/

dinsdag 13 november 2012 00:38

Acties:

dinsdag 13 november 2012 00:40

Quia Ego Sic Dico.

SymbolicFrank schreef op dinsdag 13 november 2012 @ 00:29:
[...]

Dat wil niet zeggen, dat het niet heel veel werk kan zijn. En daar heb je dan die frameworks voor. Maar zelf doen is op de langere termijn beter en sneller, denk ik.

Beter...misschien. Hangt ervanaf of je daarbij zélf ook een framework bouwt dat op maat gemaakt is aan jouw wensen. Sneller...hetzelfde. Als je een simpele applicatie met formuliertjes of een statische website moet bouwen hoef je niet zelf eerst een compleet framework uit de grond te stampen en kun je net zo goed respectievelijk met .NET of het Zend Framework aan de slag. Zit je aan ingewikkelder spul of heb je vaker projecten die een op maat gemaakte structuur nodig hebben, dan kun je eraan denken je eigen framework te bouwen.

Bouw of gebruik je in het geheel geen framework of mini-framework zoals Gomez12 het noemt, dan zit je doorgaans te werken aan redelijk logge, niet-modulaire code die in the long run alleen maar meer tijd kost.

Interessante leeskost trouwens: Wikipedia: Not invented here. Of zoals het in onze branche ook wel genoemd wordt: Not Developed Here.

[ Voor 8% gewijzigd door NMe op 13-11-2012 00:39 ]

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

Acties:

dinsdag 13 november 2012 00:49

Topicstarter

NMe schreef op dinsdag 13 november 2012 @ 00:03:
Waarom zou je in een derived class een pointer moeten bewaren naar de parent, behalve als je een vorm van recursie nodig hebt? Een afgeleide class is z'n parent en kan alles van die parent aanspreken. Als je een soort van recursie wil dan kan dat ook, want zo'n grote performance-hog is het opslaan van een pointer naar een ander object ook niet, als je maar zorgt dat je je references goed opruimt indien de taal dat vereist. Maar nogmaals, in de meeste constructies ga je weinig tot nooit moeten verwijzen naar de parent en gewoon je class afleiden als er overerving nodig is...

Niet in de base-class of een derived class, maar in de parent: de instance van de class die dat object creëert. Bijvoorbeeld:

code:

class SomeObject
{
    public SomeObject Parent;
    public List<SomeObject> Children;
    
    public SomeObject(SomeObject parent)
    {
        Parent = parent;
        Children = new List<SomeObject>();
    }
    
    public void SomeMethod()
    {
        ...
    }
}

Je kunt dan (semi-recursive) vanuit "Children" functies van de parent aanroepen: Parent.SomeMethod ...

Alleen moet je dan een Dispose maken en aanroepen, anders word het geheugen niet vrijgemaakt door de GC als hij out-of-scope gaat.

Dat mag je denken, maar vergeet niet dat ik niet degene ben met de onorthodoxe ideeën over hoe een framework zou moeten werken.

Fair enough.

[ Voor 3% gewijzigd door SymbolicFrank op 13-11-2012 00:42 ]

Acties:

dinsdag 13 november 2012 00:54

Topicstarter

johnkeates schreef op dinsdag 13 november 2012 @ 00:37:
Zelf doen is op de lange termijn juist niet beter en sneller. Je zal nooit tegen een team dat aan een framework werkt kunnen opboksen in je eentje. Als er 100 mensen 50% van hun tijd in steken is dat altijd meer dan jij die het in je eentje 100% doet. Ook als het gespecialiseerd is.

De enige situatie waarbij dat niet zo is, is als je een omgeving hebt waarbij je geen framework kan gebruiken. Bijvoorbeeld als je custom hardware hebt waar de software niet op draait, of als je een licentiemodel hanteert dat het niet toestaat te integreren met andere soorten licenties.

Het idee achter een framework is niet alleen dat je het wiel niet opnieuw hoeft uit te vinden, maar ook dat je niet de enige bent die er aan werkt, die er mee werkt, en die uitbreidingen onderzoekt.

Zelf een framework maken is ook niet heel zinvol, want om het nuttig te maken zal je moeten abstraheren naar een hoger niveau, of juist een lager niveau, wat er voor zorgt dat het inzetbaar is bij projecten met andere vereisten. Maar dan heb je gewoon 'nog een framework'. Daarbij is het ook nog eens stom dat je dan als enige verantwoordelijk bent, want dan heb je dus ook nog alle onderhoud, beveiliging e.d. die je zelf moet doen. Daarnaast heb je weer het 'standaardiseren'. Soms is een framework voor een project niet de beste oplossing, maar voor het onderhoud, samenwerken en documenteren wel, want een framework houdt er meestal wel een of meerdere standaarden op na. Zelf een nieuwe standaard verzinnen levert je waarschijnlijk niks op, en kost ook nog eens veel tijd. Bovendien zijn er zo veel standaarden en frameworks, dat het bijna onmogelijk is om geen passende bestaande versie te vinden.

http://xkcd.com/927/

Op zich ben ik het daar mee eens.

Maar...

De eerste 80% van het framework kost 20% van de tijd. En als je de hoeveelheid mensen op een IT project verdubbelt, verdubbel je ook ruwweg de tijd die het kost om het af te maken ("The mythical man-month").

Dus, als je maar 10% van de functionaliteit van het framework gaat gebruiken, ben je heel snel klaar. En je verdient die tijd terug omdat je niet heel moeilijk hoeft te doen als je om de limitaties heen moet werken.

Acties:

dinsdag 13 november 2012 01:01

Topicstarter

Gomez12 schreef op dinsdag 13 november 2012 @ 00:17:
Wat ik denk dat hier het probleem is dat TS de verkeerde frameworks bekijkt.

In wezen is zo ongeveer alles wat je hergebruikt al onderdeel van je eigen "frameworkje".
Daarom heb je ook Frameworks in alle soorten en maten.

Persoonlijk vind ik ook elk groot (van het internet gedownload) framework "waardeloos" totdat wij er ons eigen miniframeworkje bovenop hebben gezet die exact doet wat wij willen en imho kan dat ook niet anders, wij hebben nu eenmaal op sommige punten een andere filosofie als de maker van het grote framework.

Dat is wmb nu net de truc, als een custom control veel extra code vergt dan zorg je dat die code in je eigen mini-frameworkje beland en jij / je collega kan daarna die custom control gewoon gebruiken net zoals alles in de rest van het framework.

Zonder mini-frameworkje zou ik ook "vloeken" op het algemene framework als ik voor de 10e keer kan copy/pasten met net 2 aanpassingen voor een custom control, maar imho is het grote framework slechts een uitbreiding van de basis van de taal en niet het eindresultaat waarin je al je code maar moet kloppen zonder je eigen framework.

Vergeet niet, naast het framework heb je altijd nog de basis-taal om in je eigen mini-frameworkje te gebruiken.

Zo vind ik Xaml ook een draak bij grotere projecten, maar ik ken concullega's die daarvoor gewoon classes hebben die weer XAML schrijft zodat dat voor hun ook weer geextraheerd wordt en hun dus niets van het draken-resultaat zien

Mee eens.

De afweging die je dan moet maken: kost het meer tijd om de gevraagde functionaliteit zelf te implementeren dan om een heel framework om dat andere framework heen te schrijven dat al die sourcecode en XML bestanden genereert on het zover te krijgen dat het doet wat je wilt?

Acties:

dinsdag 13 november 2012 01:41

Topicstarter

NMe schreef op dinsdag 13 november 2012 @ 00:38:
[...]

Beter...misschien. Hangt ervanaf of je daarbij zélf ook een framework bouwt dat op maat gemaakt is aan jouw wensen. Sneller...hetzelfde. Als je een simpele applicatie met formuliertjes of een statische website moet bouwen hoef je niet zelf eerst een compleet framework uit de grond te stampen en kun je net zo goed respectievelijk met .NET of het Zend Framework aan de slag. Zit je aan ingewikkelder spul of heb je vaker projecten die een op maat gemaakte structuur nodig hebben, dan kun je eraan denken je eigen framework te bouwen.

Bouw of gebruik je in het geheel geen framework of mini-framework zoals Gomez12 het noemt, dan zit je doorgaans te werken aan redelijk logge, niet-modulaire code die in the long run alleen maar meer tijd kost.

Interessante leeskost trouwens: Wikipedia: Not invented here. Of zoals het in onze branche ook wel genoemd wordt: Not Developed Here.

Uitgaande van de regel dat dingen heel moeilijk lijken als je het nog nooit hebt gedaan, maar dat alles simpel is als je het wel een keer hebt gedaan, pleit ik er voor om het zelf te doen.

Want, dat iemand anders het heeft gedaan, bewijst dat je het zelf ook kunt. En dat is een goede investering.

Acties:

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

SymbolicFrank schreef op dinsdag 13 november 2012 @ 00:29:
[...]

Ah, SOLID! (I had to look it up, it didn't ring any bell )

Ja, wij hebben ook stand-up meetings op mijn werk

Waar heb jij die definitie van SOLID gevonden of mis ik iets? SOLID heeft niets van doen met stand-up meetings e.d. SOLID slaat op de 5 basisprincipes van OOP en als je dat moest opzoeken, with all due respect, dan ontbeer je dus de kennis om goed OO te werken (en dat verklaart ook veel van je onorthodoxe gedachtengang(en)).

SymbolicFrank schreef op dinsdag 13 november 2012 @ 00:29:
Als ik al een methodologie volg, dan is het een kruising tussen KISS en Defensive Programming.

SOLID, KISS en Defensive Programming hebben evenveel met elkaar te maken als blauw, dinsdag en banaan. Geen idee hoe jij een kruising tussen KISS en DP ziet. Een goed opgezet OO stuk code kan prima KISS én "defensive" zijn én aan alle SOLID's voldoen.

SymbolicFrank schreef op dinsdag 13 november 2012 @ 00:40:

SymbolicFrank schreef op dinsdag 13 november 2012 @ 00:49:

SymbolicFrank schreef op dinsdag 13 november 2012 @ 00:54:

SymbolicFrank schreef op dinsdag 13 november 2012 @ 01:01:

Gebruik a.u.b. de "wijzig knop" (rechtsboven je bericht(en)) als je iets toe te voegen hebt; je topic herhaaldelijk omhoogschoppen is niet nodig en die melding staat er niet voor niets:

[ Voor 53% gewijzigd door RobIII op 13-11-2012 01:52 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

dinsdag 13 november 2012 08:54

Acties:

dinsdag 13 november 2012 10:01

Niet om lullig te zijn, maar ik zou eens een goed book OO programmeren doorlezen. Het bovengenoemde stukje code spreekt denk ik boekdelen. Overerving in OOP is totaal wat anders dan een "parent" klasse die een lijst van "children" bij houdt.

Ik denk dat het probleem meer zit in het feit dat je niet goed weet wat OOP is en niet goed voor je hebt wat een framework nu precies doet. Het feit dat een framework namelijk niet flexibel genoeg zou zijn slaat wat mij betreft nergens op. Als we naar een MVC framework kijken als Yii (PHP), zou ik wel eens een voorbeeld willen van functionaliteit die zo anders is dat deze niet in een MVC structuur gegoten kan worden.

Nogmaals. Dit is niet om lullig te zijn, maar ik heb het idee dat je het jezelf ontzettend moeilijk maakt om de simpele reden dat je niet goed weet hoe bepaalde technieken in elkaar zitten. Ik zou aanraden om eens een goed boek te kopen over bijv. OOP, dat zou enorm kunnen helpen. Voor advies over boeken hebben we hier zelfs een speciaal topic in de devschuur.

EDIT:

Uitgaande van de regel dat dingen heel moeilijk lijken als je het nog nooit hebt gedaan, maar dat alles simpel is als je het wel een keer hebt gedaan, pleit ik er voor om het zelf te doen.

Want, dat iemand anders het heeft gedaan, bewijst dat je het zelf ook kunt. En dat is een goede investering

Dat iemand anders het al gedaan heeft bewijst alleen dat je geld aan het weggooien bent als je het zelf nog een keer gaat doen. Ik vraag mij af waarom ontwikkelaar altijd denken dat zij het beter zelf kunnen doen, het is gewoon geld weggooien. Daarnaast kan jij mij niet wijsmaken dat je(zelfs met een team) het beter kan doen dan een framework waar honderden mensen en nog veel meer manuren inzitten. En laten we het maar niet hebben over de tijd die het kost om het beter te doen dan de rest...

[ Voor 28% gewijzigd door Tarilo op 13-11-2012 09:06 ]

Acties:

Barryvdh

SymbolicFrank schreef op dinsdag 13 november 2012 @ 00:49:
[...]
De eerste 80% van het framework kost 20% van de tijd. En als je de hoeveelheid mensen op een IT project verdubbelt, verdubbel je ook ruwweg de tijd die het kost om het af te maken ("The mythical man-month").

Dus, als je maar 10% van de functionaliteit van het framework gaat gebruiken, ben je heel snel klaar. En je verdient die tijd terug omdat je niet heel moeilijk hoeft te doen als je om de limitaties heen moet werken.

Bedoel je dan dat je alleen de eerste 80% maakt, en die laatste 20% laat zitten, omdat je die toch niet nodig hebt? Want zo werkt het natuurlijk niet

dinsdag 13 november 2012 10:08

Acties:

woensdag 14 november 2012 16:29

SymbolicFrank schreef op dinsdag 13 november 2012 @ 01:01:
[...]
Uitgaande van de regel dat dingen heel moeilijk lijken als je het nog nooit hebt gedaan, maar dat alles simpel is als je het wel een keer hebt gedaan, pleit ik er voor om het zelf te doen.

Want, dat iemand anders het heeft gedaan, bewijst dat je het zelf ook kunt. En dat is een goede investering.

Heb je dan ook je eigen programmeertaal gebouwd, compleet opgebouwd in assembler met processor-specifieke optimalisaties om het enigszins te laten lopen?

Of gebruik je toch weer een framework van een OS met daarbovenop een framework van een programmeertaal.

Ik krijg heel sterk het idee dat je leidt aan het NIH-syndroom.
Het is geen goede investering om maar dingen zelf te gaan maken die er al zijn, het is een goede investering om dingen op te pakken die er zijn en die dan te gaan verbeteren / veranderen naar jouw smaak.

[ Voor 11% gewijzigd door Gomez12 op 13-11-2012 10:10 ]

Acties:

woensdag 14 november 2012 16:37

Tarilo schreef op dinsdag 13 november 2012 @ 08:54:
Niet om lullig te zijn, maar ik zou eens een goed book OO programmeren doorlezen.

En daarna terugkomen als je die kennis toegepast hebt in een groot team dat samen een complexe webapplicatie bouwt.

Sorry hoor maar ik blijf bij m'n vorige standpunt: er is gewoon een enorm kennisgat bij de TS en dan zijn dit soort discussies complete tijdsverspilling.

https://niels.nu

Acties:

woensdag 14 november 2012 16:42

Quia Ego Sic Dico.

RobIII schreef op dinsdag 13 november 2012 @ 01:41:
[...]

en als je dat moest opzoeken, with all due respect, dan ontbeer je dus de kennis om goed OO te werken (en dat verklaart ook veel van je onorthodoxe gedachtengang(en)).

offtopic:
Oi! Ik kende die afkorting ook niet!

Na wat leeswerk zie ik wel dat ik het altijd goed toepas, maar de term is nieuw voor me.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

Acties:

woensdag 14 november 2012 23:33

*zucht*

SymbolicFrank schreef op dinsdag 13 november 2012 @ 01:01:
[...]
Want, dat iemand anders het heeft gedaan, bewijst dat je het zelf ook kunt. En dat is een goede investering.

Denk je ook wel eens aan omgevingen waar je niet in je eentje werkt? Waar andere mensen verder moeten met de code die anderen hebben geschreven? Dat je in een bedrijf werkt waar je continu van project wisselt?

Het laatste wat je dan wilt is custom frameworks. Je wilt een basis hebben waarvan iedereen weet hoe het werkt en die je tijd uit handen neemt. Ja, de curve is in het begin wat groter dan zelfgeschreven code, maar dat verdien je op iets langere termijn en met grotere teams eenvoudig terug.

En dat is een goede investering.

Acties:

woensdag 14 november 2012 23:49

Topicstarter

Ok.

Zoals ik al aangaf, ik heb geen opleiding in de IT (alleen mavo), dus ik heb alles geleerd door het zelf uit te proberen.

Besturingssystemen zijn niet zo moeilijk, die heb ik wel meerdere gemaakt, het probleem zit hem vooral in de ondersteuning van externe hardware. Dat kun je zelf niet allemaal schrijven, dat moet je overlaten aan de fabrikanten.

Ik heb heel lang geleden wel eens een uitgebreide macro-assembler gemaakt in QBasic, die debug.exe gebruikte om het te assembleren, en wat geëxperimenteerd met Lex en Yacc, maar nog nooit zelf een complete programmeertaal gemaakt. Dat lijkt me wel leuk om eens te doen.

OO programmeren gebeurde vanzelf, maar ik wist toen nog niet dat het zo heette: je had toen ook nog geen classes, alleen objecten.

En ik heb inderdaad zelf heel wat frameworks gemaakt, de eerste was een UI in C, in 1986, voor een groot, commercieel C project. Het had toen al windows en menu's. Muizen kenden we nog niet.

En ik heb ook heel wat (web-)applicaties gemaakt in een team, de ervaring daarmee over de jaren is net waarom ik dit topic heb gemaakt.

Maar, ik geef toe dat ik inderdaad wel regelmatig de persoon ben die het framework bouwt. Dus die kritiek is ook wel gebaseerd op mijn eigen ervaring.

Misschien is een vraag hier beter op zijn plaats: hoe zou jullie favoriete framework er uit moeten zien?

Acties:

Verwijderd

Een framework moet de universele bouwstenen bevatten die je kunt gebruiken in een project.
Je eigen project moet zoveel mogelijk alleen de business logic bevatten, zodat je je bezig kunt houden met de specifieke toepassing voor je klant zonder je bezig te hoeven houden met geneuzel dat min of meer altijd hetzelfde is voor iedereen.

Voor een webapplicatie betekent dat dus dat er goede bouwstenen moeten zijn om data in te voeren (formulieren, CSV import, whatever), te notificeren (mail, SMS, Twitter, SOAP, syslog, whatever), enzovoorts.

En alles moet zo in elkaar zitten dat je het ofwel makkelijk kunt uitbreiden, ofwel makkelijk kunt vervangen. Ik zou het liefst zien dat zoveel mogelijk wordt gewerkt met goed uitgedachte interfaces, zodat je heel eenvoudig een andere class kunt gebruiken die zonder problemen in de rest van de applicatie te pluggen is. Dat valt niet altijd mee. Er wordt heel vaak ontworpen voor een specifieke situatie en dat is wat een goed framework juist niet moet doen.

Je moet worden aangemoedigd bestaande code te gebruiken, zonder dat je verplicht wordt alles te gebruiken. Tenzij je het zo goed maakt dat je niets anders meer nodig hebt. Maar ik denk dat iedereen wel weet dat dat een illusie is.

Uiteindelijk gaat het om tijd besparen. Saai werk dat al heel vaak door anderen is gedaan, en dus tot in den treure is getest, bijgeschaafd en geoptimaliseerd. Minder bugs introduceren, minder code schrijven die anderen allang veel beter hebben geschreven.

woensdag 14 november 2012 23:50

Acties:

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

SymbolicFrank schreef op woensdag 14 november 2012 @ 23:33:
OO programmeren gebeurde vanzelf, maar ik wist toen nog niet dat het zo heette: je had toen ook nog geen classes, alleen objecten.

Euh, objecten zijn geinstantieerde classes

Een class is een "blauwdruk" of "mal" van een object.

quote: http://en.wikipedia.org/wiki/Class_(computer_programming)
In object-oriented programming, a class is a construct that is used to create instances of itself – referred to as class instances, class objects, instance objects or simply objects.

Zonder classes dus geen objecten

SymbolicFrank schreef op woensdag 14 november 2012 @ 23:33:
Misschien is een vraag hier beter op zijn plaats: hoe zou jullie favoriete framework er uit moeten zien?

Hoe ziet je favoriete vervoersmiddel er uit?
Nou, dat depends nogal. Wil je van huis uit naar 't eind van de straat, wil je naar de andere kant van 't land, wil je de oceaan over, wil je naar de maan of wil je interstellair reizen? En wil je dat zo comfortabel mogelijk, zo snel mogelijk, zo goedkoop mogelijk of ... Ik hoop dat je snapt dat je vraag niet te beantwoorden is als 'ie zo breed is? Een "framework" is ook niets anders dan een omschrijving voor een "iets" waar je op voorborduurt, dat je werk uit handen neemt, dat je een rode draad / houvast geeft, dat zaken voor je wegabstraheert zodat je je er niet meer druk om hoeft te maken of...

Neem 't .Net framework. Aardig compleet, behoorlijk universeel en goed doordacht. Daar bovenop kun je het ASP.Net framework stapelen waarop je weer het MVC framework stapelt dat vervolgens weer het Entity framework gebruikt. En het .Net framework zélf is op zijn beurt weer niets anders dan een abstractie van 't onderliggende systeem dat OS-specifieke zaken wegabstraheert enzovoorts. En zo kun je nogal wat frameworks op elkaar stapelen, in elkaar klikken, met elkaar gebruiken. Net LEGO™

En als je al die blokjes nu slim en goed met elkaar combineert hoeft jij je alleen nog maar druk te maken om 't autootje dat je probeert te bouwen en niet om hoe je al die onderdelen op elkaar afstemt / met elkaar laat werken behalve in de grote lijnen; waar ze met elkaar interfacen/in aanraking komen.

Mijn favoriete framework is daarom niet te beschrijven behalve, zoals Cheatah hierboven doet, in erg abstracte termen. Het moet generiek zijn, het moet makkelijk in mijn project te "klikken" zijn, moet consistent zijn en het is fijn als 't een flinke userbase en goede support heeft. Other than that kun je er weinig meer over zeggen denk ik; het is erg afhankelijk waar dat specifieke framework op gericht is. Een XNA framework is heel iets anders dan een Entity framework is heel iets anders dan een BCL is heel iets anders dan een WCF framework.

Ik heb 't even, om verwarring over platformen etc. te voorkomen, specifiek bij MS gehouden omdat me daar zo snel de meeste frameworks van te binnen schoten en die 't beste de onderling goed van elkaar te onderscheiden zijn maar toch die onderlinge consistentie hebben. Bovenstaand verhaal kun je ook toepassen op een ander platform, op een andere taal, op een andere <younameit>

[ Voor 51% gewijzigd door RobIII op 15-11-2012 01:22 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

donderdag 15 november 2012 00:57

Acties:

donderdag 15 november 2012 08:43

SymbolicFrank schreef op woensdag 14 november 2012 @ 23:33:
Maar, ik geef toe dat ik inderdaad wel regelmatig de persoon ben die het framework bouwt. Dus die kritiek is ook wel gebaseerd op mijn eigen ervaring.

Tja, wellicht moet je je dan afvragen of je TS niet voornamelijk op je eigen frameworks van toepassing zijn ipv frameworks in het algemeen en of je je eigen frameworks wellicht niet verkeerd opzet.

Misschien is een vraag hier beter op zijn plaats: hoe zou jullie favoriete framework er uit moeten zien?

Simpel antwoord : zodanig dat ik in 100 regels elke klantwens kan regelen zonder dat ik flexibiliteit inlever.

Simpel voorbeeld : Ik wil gewoon een export maken, of die naar csv of naar xls of naar een db-server of naar een xml moet dat interesseert mij niet dat is het pakkie aan van het framework (dit is niet moeilijk) maar dan wel op zo'n manier dat ik in die 100 regels die dit mag kosten wel kan regelen dat bij xls een van de beschikbare bedrijfstemplates gekozen kan worden en dat ik er wel een grafiekje in krijg en dat ik wel cel x/y/z aparte kleurtjes geeft en dat ik bijv over een half jaar als de klant het wil ook de xml van annotaties kan voorzien.

Ik vermoed dat hier ook gelijk jouw probleem zit, jij zal wellicht je data outputten in een excel formaat en die desnoods downdumben voor csv en dan krijg je over dat half jaar een probleem met de wens van de klant om de xml van annotaties te voorzien.
Terwijl als je het in een framework zou moeten zetten dan moet je business-code enkel maar outputten naar een intermediate formaat van data + metadata en dan kan je een xls-template opbouwen die specifieke xls metadata oppikt uit het intermediate formaat en over een half jaar moet je enkel een xml-template opbouwen vanuit je intermediate formaat richting xml.
Op deze manier verander je aan je business-code niets als je een nieuw output formaat nodig hebt, terwijl als je vanuit je business code direct naar xls exporteert je alles mag gaan afvangen voor je neiuwe formaat.

Dus een framework moet geen export naar xls (of xml) hebben, maar moet enkel aanbieden dat je plugins etc kan maken die het intermediate formaat op kunnen vangen.
Het vereist een andere denkwijze en het is zeker langzamer dan als je het zelf direct naar xls gaat schrijven, maar het is wel 1000x onderhoudbaarder en uitbreidbaarder dan direct naar xls schrijven en dan problemen hebben als de klant een andere export wil.

Acties:

donderdag 15 november 2012 08:46

SymbolicFrank schreef op woensdag 14 november 2012 @ 23:33:
Besturingssystemen zijn niet zo moeilijk, die heb ik wel meerdere gemaakt, het probleem zit hem vooral in de ondersteuning van externe hardware. Dat kun je zelf niet allemaal schrijven, dat moet je overlaten aan de fabrikanten.

...

OO programmeren gebeurde vanzelf, maar ik wist toen nog niet dat het zo heette: je had toen ook nog geen classes, alleen objecten.

Het lijkt mij vrij duidelijk dat er een onwijs kennis tekort is bij te TS en tot overmaat van ramp heeft hij dit zelf niet door.

Zolang je niet weet dat objecten zonder klassen onmogelijk zijn, maar wel beweert dat een besturingssysteem makkelijk is. Heeft het weinig zin om überhaupt deze discussie te voeren.

Acties:

Verwijderd

Wikipedia: Prototype-based programming

donderdag 15 november 2012 09:58

Acties:

donderdag 15 november 2012 10:30

Verwijderd schreef op donderdag 15 november 2012 @ 08:46:
Wikipedia: Prototype-based programming

Volgens mij kunnen we aan de hand van de door de TS gegeven informatie en het stukje voorbeeld code veilig aannemen dat het niet om prototype-based programming gaat.

Acties:

donderdag 15 november 2012 11:03

SymbolicFrank schreef op woensdag 14 november 2012 @ 23:33:
Besturingssystemen zijn niet zo moeilijk, die heb ik wel meerdere gemaakt

*Post dan niks.*

[ Voor 5% gewijzigd door MueR op 15-11-2012 11:06 ]

https://niels.nu

Acties:

donderdag 15 november 2012 11:59

Hydra schreef op donderdag 15 november 2012 @ 10:30:
[...]

*knip*

Hij zegt niet dat hij de hardware ondersteuning gemaakt heeft, dus hij wacht nog steeds tot intell komt met het x86-stuk om het daadwerkelijk op hardware te draaien...

[ Voor 2% gewijzigd door MueR op 15-11-2012 11:06 ]

Acties:

donderdag 15 november 2012 13:13

mie noow noooothing ...

SymbolicFrank schreef op woensdag 14 november 2012 @ 23:33:Ok.

Zoals ik al aangaf, ik heb geen opleiding in de IT (alleen mavo), dus ik heb alles geleerd door het zelf uit te proberen.
...
OO programmeren gebeurde vanzelf, maar ik wist toen nog niet dat het zo heette: je had toen ook nog geen classes, alleen objecten.

Ik heb de indruk dat je zelf uit de praktijk een heleboel geleerd hebt, waarvoor petje af.
Anderzijds zou ik je toch héél sterk willen aanraden om, wat het OO-gedeelte betreft, een goed boek te lezen of (imho beter, maar ook duurder) er een degelijke cursus over te volgen (of nog beter: cursus en boek(en) combineren... om die kennis vervolgens in de praktijk te kunnen toepassen. Naar mijn mening is OO toch iets dat je niet zomaar zelf leert (tenzij je natuurlijk door veel op internet te lezen aan dezelfde kennis komt als uit een boek, maar mijn gevoel zegt me dat dat laatste toch wat meer consistent is).

Acties:

Verwijderd

Tarilo schreef op donderdag 15 november 2012 @ 09:58:

Volgens mij kunnen we aan de hand van de door de TS gegeven informatie en het stukje voorbeeld code veilig aannemen dat het niet om prototype-based programming gaat.

Dat is waar, maar wat je daarvoor zei was dus niet waar

zondag 18 november 2012 18:52

Acties:

zondag 18 november 2012 19:19

Topicstarter

Verwijderd schreef op woensdag 14 november 2012 @ 23:49:
...
En alles moet zo in elkaar zitten dat je het ofwel makkelijk kunt uitbreiden, ofwel makkelijk kunt vervangen. Ik zou het liefst zien dat zoveel mogelijk wordt gewerkt met goed uitgedachte interfaces, zodat je heel eenvoudig een andere class kunt gebruiken die zonder problemen in de rest van de applicatie te pluggen is. Dat valt niet altijd mee. Er wordt heel vaak ontworpen voor een specifieke situatie en dat is wat een goed framework juist niet moet doen.

Dat is inderdaad de kern van het probleem.

Je moet worden aangemoedigd bestaande code te gebruiken, zonder dat je verplicht wordt alles te gebruiken. Tenzij je het zo goed maakt dat je niets anders meer nodig hebt. Maar ik denk dat iedereen wel weet dat dat een illusie is.

Uiteindelijk gaat het om tijd besparen. Saai werk dat al heel vaak door anderen is gedaan, en dus tot in den treure is getest, bijgeschaafd en geoptimaliseerd. Minder bugs introduceren, minder code schrijven die anderen allang veel beter hebben geschreven.

Ja, en dus moet je overal zoveel mogelijk proberen om het zo eenvoudig te maken om dingen toe te voegen / te wijzigen. Ouderwetse functiebibliotheken hebben nog steeds hun plaats in zo'n framework, omdat je daar gemakkelijk overal gebruik van kunt maken.

RobIII schreef op woensdag 14 november 2012 @ 23:50:Euh, objecten zijn geinstantieerde classes Een class is een "blauwdruk" of "mal" van een object.

Zonder classes dus geen objecten

In Borland Pascal 5 (iirc), had je wel het datatype "object", maar niet "class". Je gebruikte dus gelinkte lijsten om je classes in elkaar te zetten (wat we toen objecten noemden). Referentie van een veld was ook niet:

instance.field

maar

instance^field

Je derefereerde dus rechtstreeks een pointer naar je object (wat we toen een instance noemden).

En een method was gewoon een functie die als eerste argument een pointer naar de instance kreeg.

DIY OO, zeg maar.

Mijn favoriete framework is daarom niet te beschrijven behalve, zoals Cheatah hierboven doet, in erg abstracte termen. Het moet generiek zijn, het moet makkelijk in mijn project te "klikken" zijn, moet consistent zijn en het is fijn als 't een flinke userbase en goede support heeft. Other than that kun je er weinig meer over zeggen denk ik; het is erg afhankelijk waar dat specifieke framework op gericht is. Een XNA framework is heel iets anders dan een Entity framework is heel iets anders dan een BCL is heel iets anders dan een WCF framework.

Denk je dat een framework met die specificaties ooit zal bestaan?

Gomez12 schreef op donderdag 15 november 2012 @ 00:57:Tja, wellicht moet je je dan afvragen of je TS niet voornamelijk op je eigen frameworks van toepassing zijn ipv frameworks in het algemeen en of je je eigen frameworks wellicht niet verkeerd opzet.

Terechte opmerking.

Maar ik had vooral de huidige, commerciële frameworks in gedachten. Ik probeer de frameworks die ik zelf maak altijd zo simpel mogelijk te maken, zowel in grootte als toepasbaarheid. Het doel is dat je het gebruikt omdat het dan makkelijker word, niet omdat het nou eenmaal zo moet.

Simpel antwoord : zodanig dat ik in 100 regels elke klantwens kan regelen zonder dat ik flexibiliteit inlever.

"Elke" klantwens? Dat gaat niet gebeuren. De "initiële" (en vaak vereenvoudigde) klantwens? Dat is het streven van de meeste frameworks.

Ik vermoed dat hier ook gelijk jouw probleem zit, jij zal wellicht je data outputten in een excel formaat en die desnoods downdumben voor csv en dan krijg je over dat half jaar een probleem met de wens van de klant om de xml van annotaties te voorzien.

Klopt helemaal.

Terwijl als je het in een framework zou moeten zetten dan moet je business-code enkel maar outputten naar een intermediate formaat van data + metadata en dan kan je een xls-template opbouwen die specifieke xls metadata oppikt uit het intermediate formaat en over een half jaar moet je enkel een xml-template opbouwen vanuit je intermediate formaat richting xml.
Op deze manier verander je aan je business-code niets als je een nieuw output formaat nodig hebt, terwijl als je vanuit je business code direct naar xls exporteert je alles mag gaan afvangen voor je neiuwe formaat.

Dus een framework moet geen export naar xls (of xml) hebben, maar moet enkel aanbieden dat je plugins etc kan maken die het intermediate formaat op kunnen vangen.
Het vereist een andere denkwijze en het is zeker langzamer dan als je het zelf direct naar xls gaat schrijven, maar het is wel 1000x onderhoudbaarder en uitbreidbaarder dan direct naar xls schrijven en dan problemen hebben als de klant een andere export wil.

Helemaal mee eens.

Verwijderd schreef op donderdag 15 november 2012 @ 08:46:
Wikipedia: Prototype-based programming

Dat is een heel interessante, vooral vanuit commercieel oogpunt.

Een goed vooronderzoek is het halve werk, letterlijk. En dat vereist na de inventarisatie en de architectuur ook een functionele demo, want dan weet je pas waar je allemaal tegenaan gaat lopen.

Je manager verwacht echter van te voren een tijdsinschatting, zodat hij een offerte kan maken. Als die er al niet ligt.

Je opdracht is heel vaak: dit hebben we met de klant afgesproken, realiseer het maar. En het moet op die datum klaar zijn. Begin maar snel!

En dan ga je zoeken naar frameworks, die dat mogelijk kunnen maken.

edeboeck schreef op donderdag 15 november 2012 @ 11:59:
Ik heb de indruk dat je zelf uit de praktijk een heleboel geleerd hebt, waarvoor petje af.
Anderzijds zou ik je toch héél sterk willen aanraden om, wat het OO-gedeelte betreft, een goed boek te lezen of (imho beter, maar ook duurder) er een degelijke cursus over te volgen (of nog beter: cursus en boek(en) combineren... om die kennis vervolgens in de praktijk te kunnen toepassen. Naar mijn mening is OO toch iets dat je niet zomaar zelf leert (tenzij je natuurlijk door veel op internet te lezen aan dezelfde kennis komt als uit een boek, maar mijn gevoel zegt me dat dat laatste toch wat meer consistent is).

Ik doe voor mezelf altijd een gedegen vooronderzoek, wat dus ook inhoud dat ik me verdiep in wat er op de markt is. Als boek 1 zegt dat het A is, boek 2 B en boek 3 C, dan weet ik in ieder geval waar ik uit kan kiezen.

Acties:

zondag 18 november 2012 19:32

Topicstarter

Gomez12 schreef op donderdag 15 november 2012 @ 11:03:Hij zegt niet dat hij de hardware ondersteuning gemaakt heeft, dus hij wacht nog steeds tot intell komt met het x86-stuk om het daadwerkelijk op hardware te draaien...

Een computer heeft verschillende onderdelen. Een CPU, chips of een chipset om de overige hardware te kunnen benaderen, die overige hardware, zoals een toetsenbord en een harddisk, en een BIOS of firmware.

Heel lang geleden kreeg je een boek bij je computer (of kon je dat kopen), waar uitgebreid in beschreven stond hoe al die onderdelen werken. Sinclair deed dat heel goed met de ZX-81 en ZX-Spectrum, voor een IBM PC/AT kon je een meter boeken kopen die alle IC's uitvoerig beschreven. En voor microcontrollers kun je dat downloaden. En voor al die computers heb ik wel minstens 1 besuringssysteem gemaakt.

Een besturingssysteem is niet meer dan een programma dat geheugenbeheer doet, zorgt dat je meerdere processen tegelijk kunt laten draaien (time-slicing en/of SMP), de input en output generiek maakt en een command (terminal) interface heeft. Zo ingewikkeld is dat niet.

Alle onderdelen van de computer moet je zelf invoegen en ondersteunen. En daarbovenop heb je protocols zoals chipselect, DMA, serieel (UART) en block-devices. Het is vaak best complex om uit te vogelen hoe die dingen aan te sturen zijn.

Daarboven heb je dan een driver-laag, waar je bijvoorbeeld het standaard toetsenbord, USB en HID devices ondersteund, en het mogelijk maakt om drivers toe te voegen. Dan kunnen mensen standaard bijvoorbeeld een USB harddisk of toetsenbord gebruiken.

Maar randapparatuur waarvoor je een driver moet installeren, daar is geen beginnen aan. Dat zijn er veel te veel.

Ik maak voor de meeste microcontroller-toepassingen een custom besturingssysteempje. En als je denkt dat dat veel eenvoudiger is als een besturingssysteem voor een "echte" computer, dan raad ik je aan om eens een datasheet van een willekeurige microcontroller te downloaden.

Acties:

zondag 18 november 2012 19:58

SymbolicFrank schreef op zondag 18 november 2012 @ 18:52:
[...]
Maar ik had vooral de huidige, commerciële frameworks in gedachten. Ik probeer de frameworks die ik zelf maak altijd zo simpel mogelijk te maken, zowel in grootte als toepasbaarheid. Het doel is dat je het gebruikt omdat het dan makkelijker word, niet omdat het nou eenmaal zo moet.

Daar maak je dus de denkfout. Je denkt niet na over hergebruik, en tja dan kom je dus in de knoei als je het moet hergebruiken.

Je opdracht is heel vaak: dit hebben we met de klant afgesproken, realiseer het maar. En het moet op die datum klaar zijn. Begin maar snel!

En dan ga je zoeken naar frameworks, die dat mogelijk kunnen maken.

Dan zit je op het verkeerde moment te kijken, maar dat komt waarschijnlijk omdat je idee van frameworks simpelweg verkeerd is. Het is geen kant-en-klare oplossing voor exact jouw probleem, het is een "framework" wat het je makkelijker kan maken, maar wat ook tegen je kan werken als je het verkeerd gebruikt.

[...]
Ik doe voor mezelf altijd een gedegen vooronderzoek, wat dus ook inhoud dat ik me verdiep in wat er op de markt is. Als boek 1 zegt dat het A is, boek 2 B en boek 3 C, dan weet ik in ieder geval waar ik uit kan kiezen.

Tja, als ik kijk naar hoe jij frameworks ziet dan zal je vast je vooronderzoek doen, maar als je dat vanuit het verkeerde oogpunt doet dan is het nut twijfelachtig...

Acties:

zondag 18 november 2012 20:01

Topicstarter

@Gomez12:

Huidig praktijkvoorbeeld: ASP.NET -> CSLA -> MVC, SQLMETAL, Aspose, meerdere zelfgemaakte frameworks (niet door mij) met alle te gebruiken baseclasses voor views, controllers, documenten, etc. Dit zijn allemaal black boxes (geen sourcecode, niet wijzigbaar).

Hierbovenop is een class "Document" gemaakt, waar alles (en dus ook de business logic) in zit. Samen met de CSLA Rules en de MVC views bepalen die die wat er mogelijk is.

Nou is die Document class erg traag en inflexibel, dus is er besloten om die niet meer te gebruiken: als je wat wilt doen, dan moet je een custom class schrijven, zelf de benodigde data uit de database ophalen, zelf je selectie maken, zelf de berekende properties implementeren, zelf zorgen dat je gegevens ook valide zijn, etc.

En natuurlijk moet je bij het valideren van de data de CSLA Rules afzetten en het zelf doen.

WOW! Waarom deze drastische maatregelen? Wat is er mis met de bestaande opzet en de gebruikte frameworks?

Helemaal niets. Het voldeed prima voor de vorige projecten. Alleen, alhoewel het huidige project begon als een uitbreiding van het vorige project, is ondertussen bijna alles gewijzigd of nieuw. Het paste dus niet, en het bestaande bouwwerk is flink uit zijn voegen gebarsten. En we hebben een deadline!

Nou is dat voorbeeld verre van uniek in mijn ervaring. In het begin was iedereen er heel blij mee en werden er meters gemaakt. Maar na een paar jaar verder bouwen, is het nu toch heel lastig (en vooral heel veel werk) geworden. En moet heel veel buiten de regels om, gewoon om het er in te krijgen.

Het voorstellen van structurele oplossingen brengt mijn manager in ademnood.

Dus gaan we gewoon verder.

Nogmaals, dit is niet uniek, zelfs niet uitzonderlijk in mijn ervaring voor grote projecten die al jaren bestaan. Eerder regel dan uitzondering.

Acties:

zondag 18 november 2012 20:09

Quia Ego Sic Dico.

Misschien is jouw ervaring niet zo heel erg representatief als jij denkt.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

Acties:

zondag 18 november 2012 20:15

Topicstarter

NMe schreef op zondag 18 november 2012 @ 20:01:
Misschien is jouw ervaring niet zo heel erg representatief als jij denkt.

Ik denk dat ik niet zo'n representatieve programmeur ben

Acties:

Verwijderd

Dat denk ik ook. En ik denk dat als je een betere programmeur wilt worden, je moet stoppen met je huidige baan en bij een bedrijf moet gaan werken waar ze wel de juiste keuzes maken. Overigens zul je dan een tijdje genoegen moeten nemen met het feit dat je nog een hoop moet leren en dat je mogelijk verkeerde gewoontes hebt aangeleerd.

Je verhalen zijn weinig samenhangend en je springt van de hak op de tak. Je haalt er allerlei zaken bij die niet direct relevant zijn en die je misschien wel aan je management moet uitleggen, maar niet aan ons.

zondag 18 november 2012 22:11

Acties:

maandag 19 november 2012 09:11

Topicstarter

Verwijderd schreef op zondag 18 november 2012 @ 20:15:
Dat denk ik ook. En ik denk dat als je een betere programmeur wilt worden, je moet stoppen met je huidige baan en bij een bedrijf moet gaan werken waar ze wel de juiste keuzes maken. Overigens zul je dan een tijdje genoegen moeten nemen met het feit dat je nog een hoop moet leren en dat je mogelijk verkeerde gewoontes hebt aangeleerd.

Je verhalen zijn weinig samenhangend en je springt van de hak op de tak. Je haalt er allerlei zaken bij die niet direct relevant zijn en die je misschien wel aan je management moet uitleggen, maar niet aan ons.

Ik heb nu een hele leuke vacature lopen voor een baantje bij ASML.

Als Eindhoven al de autisten hoofdstad van de wereld is, dan is ASML het centrum. Daar zitten inderdaad ook mensen die slimmer zijn dan ik.

Maar, inderdaad. Ik heb in de laatste twee jaar al twee keer eerder voor ASML gewerkt, op het hoofdkwartier, en daar was weinig eer te behalen aan de projecten. En dat vind zo'n beetje iedereen met dezelfde ervaring.

Dus, alhoewel daar de creme-de-la-creme van slimme techneuten zit, het is een groot en oud bedrijf, dat vaak meer aan ambtenarij doet denken. Je moet daar ook echt weer in het midden van de techniek terechtkomen voordat het echt leuke wordt.

Acties:

maandag 19 november 2012 09:29

mie noow noooothing ...

Verwijderd schreef op zondag 18 november 2012 @ 20:15:(...)
En ik denk dat als je een betere programmeur wilt worden, je moet stoppen met je huidige baan en bij een bedrijf moet gaan werken waar ze wel de juiste keuzes maken. Overigens zul je dan een tijdje genoegen moeten nemen met het feit dat je nog een hoop moet leren en dat je mogelijk verkeerde gewoontes hebt aangeleerd.
(...)

Het probleem is natuurlijk dat het niet evident is om op voorhand te weten of een bedrijf effectief de juiste keuzes maakt (nog los van de vraag wat juiste keuzes dan wel zijn)... Als ik van een collega hoor hoe het bij hem in het bedrijf allemaal scheef loopt (indien mogelijk zouden sommigen daar nu nog in VB6 werken), dan moet je al heel sterk in je schoenen staan en de nodige kennis hebben om tegen de stroom (lees: de baas en "senior" developers) in te gaan.

Acties:

maandag 19 november 2012 10:06

edeboeck schreef op maandag 19 november 2012 @ 09:11:
[...]
Het probleem is natuurlijk dat het niet evident is om op voorhand te weten of een bedrijf effectief de juiste keuzes maakt (nog los van de vraag wat juiste keuzes dan wel zijn)... Als ik van een collega hoor hoe het bij hem in het bedrijf allemaal scheef loopt (indien mogelijk zouden sommigen daar nu nog in VB6 werken), dan moet je al heel sterk in je schoenen staan en de nodige kennis hebben om tegen de stroom (lees: de baas en "senior" developers) in te gaan.

Kleinere bedrijven die zich specialiseren in technieken die nu current zijn, daar zou je terecht willen komen. De vraag is alleen of ze daar trek hebben in een oude bok die vastgeroest zit in zijn methoden. Dan heb je als programmeur van 40+ opeens te maken met een team lead van in de twintig die het gewoon beter weet dan jij.

Tja, ik weet niet of je een dergelijke switch nog wil maken. Ik denk dat de TS beter door kan gaan bij het soort bedrijf waar hij nu ook werkt. De meeste developers zijn op hun 50e ofzo geen developer meer. Wij hebben er wel een, en hij is enorm goed in wat hij doet (C++) maar je moet hem echt geen andere dingen gaan proberen te leren ofzo. Wordt 'ie alleen maar ongelukkig van.

[ Voor 10% gewijzigd door Hydra op 19-11-2012 09:30 ]

https://niels.nu

Acties:

dinsdag 11 december 2012 03:30

mie noow noooothing ...

Om even terug wat meer on-topic te gaan (zin en onzin van frameworks... of eerder: de relativiteit ervan): een voorbeeldje uit eigen huis: reviews: Tweakers 7: waarom een eigen Java-back-end? (dit linkt door naar de 3^de pagina uit het artikel)

Acties:

dinsdag 11 december 2012 03:43

Topicstarter

Hydra schreef op maandag 19 november 2012 @ 09:29:
Kleinere bedrijven die zich specialiseren in technieken die nu current zijn, daar zou je terecht willen komen. De vraag is alleen of ze daar trek hebben in een oude bok die vastgeroest zit in zijn methoden. Dan heb je als programmeur van 40+ opeens te maken met een team lead van in de twintig die het gewoon beter weet dan jij.

Nou dit is iets dat uitnodigt tot discussie

Ik wordt er altijd uitgetrapt door de gevestigde orde, die mij ziet als een bedreiging. Ik heb niet alleen "belachelijke" ideeën, maar ze moeten er nog naar luisteren ook, als hun eigen visie stuk is gelopen. Dan helpt "bek dicht en doen wat je gezegd wordt" niet meer, en komt de botte bijl tevoorschijn.

En ik ben 46. Dus dat heeft veel minder met oud of vernieuwing te maken, dan met begrijpen hoe dingen werken. Nieuw is niet automatisch beter. Het is gewoon "nieuw".

Dat leer je niet op school. Sterker nog: als je vanaf het begin alles zelf hebt uitgevogeld, heb je minder de neiging om botweg te doen wat je op school verteld is hoe het moet.

Tja, ik weet niet of je een dergelijke switch nog wil maken. Ik denk dat de TS beter door kan gaan bij het soort bedrijf waar hij nu ook werkt. De meeste developers zijn op hun 50e ofzo geen developer meer. Wij hebben er wel een, en hij is enorm goed in wat hij doet (C++) maar je moet hem echt geen andere dingen gaan proberen te leren ofzo. Wordt 'ie alleen maar ongelukkig van.

Ik denk dat ik maar weer een eigen bedrijf begin. Ik ben helaas niet erg commercieel; ik heb niet dat instinct dat zegt: "Die andere mensen hebben geld, hoe krijg ik ze zo ver dat ze dat aan mij geven?" Ik ben veel te klantgericht.

Acties:

dinsdag 11 december 2012 04:34

Topicstarter

Tussen haakjes, wat vinden jullie belangrijker als je ergens voor wordt ingehuurd: dat je zo goed mogelijk het perfecte radertje bent wat ze wilden hebben, of dat je er voor zorgt dat het project waar je aan werkt een succes word?

Op mijn laatste baan (zie TS) werd het een steeds grotere puinhoop en paniekvoetbal. De lijst met bugs werd steeds langer. En het criterium van het management werd steeds meer: hoeveel bugs heb je gefixed, en hoeveel regels code heb je geschreven?

Als je alleen de kwantiteit belangrijk vind, moet je niet gek opkijken als de kwaliteit steeds verder afneemt. En op een gegeven moment helpt niks meer en is het einde zoek.

En de architect (die mij dus niet mocht) had zoiets van: "Ja, dat is toch normaal? Dat gebeurt altijd bij projecten."

Misschien bij ZIJN projecten. Maar bij die van mij gaat dat toch heel anders.

Acties:

Verwijderd

Mogelijkheid 1: je paste niet binnen de groep en je collega's wilden je -terecht of onterecht- weg hebben.
Mogelijkheid 2: je werkte te langzaam en/of inefficiënt.

SymbolicFrank schreef op dinsdag 11 december 2012 @ 03:30:

Ik wordt er altijd uitgetrapt door de gevestigde orde, die mij ziet als een bedreiging. Ik heb niet alleen "belachelijke" ideeën, maar ze moeten er nog naar luisteren ook, als hun eigen visie stuk is gelopen. Dan helpt "bek dicht en doen wat je gezegd wordt" niet meer, en komt de botte bijl tevoorschijn.

Ik word er nooit uitgetrapt. Als je er meerdere keren wordt uitgetrapt is daar meerdere keren een reden voor. Misschien is er iets mis met je ideeën, misschien met je houding. Het zegt in elk geval iets over je talent om het juiste bedrijf voor jezelf te vinden.

En ik ben 46. Dus dat heeft veel minder met oud of vernieuwing te maken, dan met begrijpen hoe dingen werken. Nieuw is niet automatisch beter. Het is gewoon "nieuw".

Hier kan niemand iets mee. Ik zie geen geldige argumenten.

Dat leer je niet op school. Sterker nog: als je vanaf het begin alles zelf hebt uitgevogeld, heb je minder de neiging om botweg te doen wat je op school verteld is hoe het moet.

Aha, dus je zit bij een bedrijf met iemand in dienst die het allemaal op school heeft geleerd en waarnaar jij moet luisteren. Vervolgens doe je dat niet (omdat je niet kunt of wilt) en vervolgens is het jouw schuld dat een project misloopt. Maar als je zo goed bent, waarom ben je dan voor dát bedrijf gaan werken? En als je er niet meer werkt, wat boeit het jou dan nog hoe zij werken? Jij bent toch wel zo goed dat je gewoon ergens anders gaat werken waar ze het wél snappen? Er is zoveel vraag naar goede developers dat werk vinden echt geen enkel probleem is. Als je het maar kunt. En als je maar kunt samenwerken.

Ik denk dat ik maar weer een eigen bedrijf begin. Ik ben helaas niet erg commercieel; ik heb niet dat instinct dat zegt: "Die andere mensen hebben geld, hoe krijg ik ze zo ver dat ze dat aan mij geven?" Ik ben veel te klantgericht.

Doe maar niet dan.

dinsdag 11 december 2012 09:36

Acties:

dinsdag 11 december 2012 10:00

*zucht*

SymbolicFrank schreef op dinsdag 11 december 2012 @ 03:43:
Tussen haakjes, wat vinden jullie belangrijker als je ergens voor wordt ingehuurd: dat je zo goed mogelijk het perfecte radertje bent wat ze wilden hebben, of dat je er voor zorgt dat het project waar je aan werkt een succes word?

Dat is twee keer hetzelfde. De juiste persoon is een team player, die zowel individueel goed wil/kan presteren, maar ook de drive heeft om met het team iets goeds op te leveren, binnen de beschreven criteria (tijd, geld, etc).

Dat betekent dat je soms moet compromitteren, en soms juist vast moet houden aan je mening en mensen moet overtuigen. Er is niet één manier om te werken, de juiste manier is een goede balans.

Acties:

dinsdag 11 december 2012 12:33

SymbolicFrank schreef op dinsdag 11 december 2012 @ 03:30:
Nou dit is iets dat uitnodigt tot discussie

Na bijna een maand?

Ik wordt er altijd uitgetrapt door de gevestigde orde, die mij ziet als een bedreiging. Ik heb niet alleen "belachelijke" ideeën, maar ze moeten er nog naar luisteren ook, als hun eigen visie stuk is gelopen. Dan helpt "bek dicht en doen wat je gezegd wordt" niet meer, en komt de botte bijl tevoorschijn.

En ik ben 46. Dus dat heeft veel minder met oud of vernieuwing te maken, dan met begrijpen hoe dingen werken. Nieuw is niet automatisch beter. Het is gewoon "nieuw".

Je klinkt als een verzuurde 40er die het niet goed kan hebben dat sommige jonkies het gewoon beter weten. Je komt met bovenstaande tirade niet echt als een teamspeler over.

Dat leer je niet op school. Sterker nog: als je vanaf het begin alles zelf hebt uitgevogeld, heb je minder de neiging om botweg te doen wat je op school verteld is hoe het moet.

Wat een onzin. Op een goeie informatica opleiding leer je gewoon een hoop dingen die praktisch toepasbaar zijn. Hoe je dat toepast leer je vooral in de praktijk. Daarom heb je ook stages en projectopdrachten. Als je daarna het bedrijfsleven induikt als junior heb je gewoon een goeie theoretische achtergrond en kan je dan de praktijkkant leren.

Jouw verhaal slaat als een tang op een varken. Ik heb veel samengewerkt met autodidacten en heb bij die mensen juist vaak gezien dat ze hele simpele zaken niet 'konden' gewoon omdat niemand ze op het idee gebracht heeft. Op een opleiding krijg je die theorie mee. Als wat jij zegt waar zou zijn zou niemand nog een opleiding volgen en zouden artsen ook gewoon aan de slag gaan zonder hiervoor gestudeerd te zijn.

Als je niet accepteert dat een arts, automonteur of rechter een gedegen studie achter de rug heeft met daarbij een flinke zut ervaring, waarom zou je dat van een ITer wel accepteren?

Ik denk dat ik maar weer een eigen bedrijf begin. Ik ben helaas niet erg commercieel; ik heb niet dat instinct dat zegt: "Die andere mensen hebben geld, hoe krijg ik ze zo ver dat ze dat aan mij geven?" Ik ben veel te klantgericht.

Wat een gelul

Met klantgericht zijn verdien je ook gewoon geld. Ik ben nu consultant en per 1 Jan ben ik sales bij een ander bedrijf, en in beide hoedanigheden krijg ik meer werk juist omdat ik klantgericht ben. Klantgericht zijn betekent dat je het beste voor je klant wil. Het beste is niet gratis.

SymbolicFrank schreef op dinsdag 11 december 2012 @ 03:43:
Tussen haakjes, wat vinden jullie belangrijker als je ergens voor wordt ingehuurd: dat je zo goed mogelijk het perfecte radertje bent wat ze wilden hebben, of dat je er voor zorgt dat het project waar je aan werkt een succes word?

Zoals de rest ook al aangeeft: beide natuurlijk. Het is niet het een of het ander.

Op mijn laatste baan (zie TS) werd het een steeds grotere puinhoop en paniekvoetbal. De lijst met bugs werd steeds langer. En het criterium van het management werd steeds meer: hoeveel bugs heb je gefixed, en hoeveel regels code heb je geschreven?

Als je een goeie opleiding had gehad was je aangenomen bij een goed bedrijf dat z'n projecten op orde heeft. Werk je bij Peak-IT toevallig?

Als je alleen de kwantiteit belangrijk vind, moet je niet gek opkijken als de kwaliteit steeds verder afneemt. En op een gegeven moment helpt niks meer en is het einde zoek.

En de architect (die mij dus niet mocht) had zoiets van: "Ja, dat is toch normaal? Dat gebeurt altijd bij projecten."

Misschien bij ZIJN projecten. Maar bij die van mij gaat dat toch heel anders.

Ik krijg de indruk dat je je verhalen nogal aandikt.

[ Voor 20% gewijzigd door Hydra op 11-12-2012 10:03 ]

https://niels.nu

Acties:

dinsdag 11 december 2012 12:54

SymbolicFrank schreef op dinsdag 11 december 2012 @ 03:43:
Als je alleen de kwantiteit belangrijk vind, moet je niet gek opkijken als de kwaliteit steeds verder afneemt. En op een gegeven moment helpt niks meer en is het einde zoek.

En de architect (die mij dus niet mocht) had zoiets van: "Ja, dat is toch normaal? Dat gebeurt altijd bij projecten."

Misschien bij ZIJN projecten. Maar bij die van mij gaat dat toch heel anders.

Hoe gaat het dan bijvoorbeeld bij jouw projecten?

Heb je daar backlogs van 10.000'en punten oid en een klant die zeurt over het feit dat iets een maand geleden opgeleverd had moeten worden terwijl jij nog in assembly de webserver aan het bouwen bent?

Heel simpel feit : Deadlines zijn realiteit en vereisen soms slechtere (maar wel snellere) kwaliteit.

Acties:

dinsdag 11 december 2012 14:35

*zucht*

Gomez12 schreef op dinsdag 11 december 2012 @ 12:33:
[...]

Heel simpel feit : Deadlines zijn realiteit en vereisen soms slechtere (maar wel snellere) kwaliteit.

Dat ben ik niet met je eens, maar gaat wel enigszins off-topic.

Als de deadline zo krap is dat je blijkbaar moet inboeten op kwaliteit, dan is er ergens in het proces iets misgegaan bij het verwachtings- of projectmanagement, of bij het team dat niet goed heeft aangegeven waar de knelpunten liggen. Of, in het ergste geval, is het misgegaan bij sales (helaas te vaak het geval...).

Al met al is juist dat iets wat je met goed management en team zou moeten kunnen voorkomen. Het maakt in dat geval ook niet uit of je inboet op kwaliteit, tijd (verlopen deadline) of geld (over budget). Het komt allemaal neer op een proces-fout. Waar je uiteindelijk op inboet is puur een keuze (respectievelijk afraffelen, doorgaan of resources bijschakelen)

[ Voor 21% gewijzigd door Bosmonster op 11-12-2012 12:56 ]

Acties:

Suepahfly

Bosmonster schreef op dinsdag 11 december 2012 @ 12:54:
[...]

Dat ben ik niet met je eens, maar gaat wel enigszins off-topic.

Als de deadline zo krap is dat je blijkbaar moet inboeten op kwaliteit, dan is er ergens in het proces iets misgegaan bij het verwachtings- of projectmanagement, of bij het team dat niet goed heeft aangegeven waar de knelpunten liggen. Of, in het ergste geval, is het misgegaan bij sales (helaas te vaak het geval...).

Al met al is juist dat iets wat je met goed management en team zou moeten kunnen voorkomen. Het maakt in dat geval ook niet uit of je inboet op kwaliteit, tijd (verlopen deadline) of geld (over budget). Het komt allemaal neer op een proces-fout. Waar je uiteindelijk op inboet is puur een keuze (respectievelijk afraffelen, doorgaan of resources bijschakelen)

Helaas ligt het in de praktijk vaak anders met name in teams waar nog geen agile wordt toegepast maar die nog steeds op de waterval methode werken. Daarnaast wil management zich ook nog al vaak bemoeien met zaken waar ze eigenlijk geen verstand van hebben.

Het niet halen van deadlines (in mijn ervaring) komt 9 van de 10 keer door inmening van boven af waardoor requirement wijzigen of de scope wordt vergroot (en budget en deadline uiteraard niet). Gevolg is code van slechte kwaliteit.

dinsdag 11 december 2012 22:23

Acties:

donderdag 13 december 2012 11:26

mie noow noooothing ...

SymbolicFrank schreef op dinsdag 11 december 2012 @ 03:30:
[...]
En ik ben 46. Dus dat heeft veel minder met oud of vernieuwing te maken, dan met begrijpen hoe dingen werken. Nieuw is niet automatisch beter. Het is gewoon "nieuw".

Tot zover ben ik het met je eens. Anderzijds geldt natuurlijk ook: nieuw is niet automatisch slechter. Daarnaast is leeftijd geen garantie voor meer of minder inzicht in hoe dingen werken (ik heb al met jongere ontwikkelaars samengewerkt die een pak beter waren... en al met oudere die dat helemaal niet waren).

Dat leer je niet op school. Sterker nog: als je vanaf het begin alles zelf hebt uitgevogeld, heb je minder de neiging om botweg te doen wat je op school verteld is hoe het moet.

NOFI, maar toen ik begon te werken (bij IBM) werd ik bij een klant geposteerd waar we de code op Y2K-issues moesten scannen (ja hoor, ik ben van die generatie

). Alle resultaten moesten opgeslagen worden in een databank die de plaatselijke DBA'er gemaakt had. Blijkbaar had die nog nooit van een genormaliseerde DB gehoord: alles in 1 tabel, duplicaten à volonté, etc... Tezamen met een freelancer eerst dan maar zelf een toepassing gebouwd met wèl een degelijk genormaliseerde DB erachter.
Moraal van het verhaal: ik was toen net afgestudeerd, maar wist al meer van DB's dan hun ervaren "DBA'er" (die het allemaal zelf geleerd had). Door de samenwerking met die freelancer, had ik na dat project al helemaal jaren voorsprong op die "DBA'er".

Ik denk dat ik maar weer een eigen bedrijf begin. Ik ben helaas niet erg commercieel; ik heb niet dat instinct dat zegt: "Die andere mensen hebben geld, hoe krijg ik ze zo ver dat ze dat aan mij geven?" Ik ben veel te klantgericht.

Als je écht klantgericht bent, dan verkoop je juist wel je zaken. Mensen gaan voelen dat het jouw doel niet is om geld uit hun zaken te slaan en zullen dat appreciëren. Een trouwe klantenkring zal het resultaat zijn (als je kwaliteit levert natuurlijk).

Acties:

donderdag 13 december 2012 11:32

Ziet er naar uit dat de TS weer ff een maandje niks van zich laat horen

https://niels.nu

Acties: