Programmere alt sjølv, frå botnen av. Gamaldags?

[Gjest Slettet+9871234]

Drupal nevnes ofte som CMS systemet for programmerere. Det er fleksibelt og de fleste typer siter kan lages med Drupal. Studer boktitlene: http://www.packtpub.com/books/drupal

 

Dersom du skal bruke browser (client) skripting, anbefaler jeg deg å lære deg jQuery som abstraherer bort mye lav nivå koding som browser sniffing etc.

 

Mer om Drupal og jQuery her: http://www.oopschool.com/phpBB3/viewforum.php?f=24

 

Merk at der er et eget Drupal samfunn i Norge: http://drupalnorge.no/

[dahuff]

Så hvis du skriver god, strukturert og vel kommentert kode som også andre (eller deg selv om et par år) klarer å lese så kan "hjemmesnekret" kode være minst like bra som et rammeverk, er vel da altså konklusjonen

Kommer også an på hvor mange etasjer du skal bygge på huset. Har du skeiv grunnmur eller ett hus som siger i ett hjørne så er det ikke like lett å bygge videre. Dessuten er det ikke så lett å rive og starte forfra heller når noen har flyttet inn i huset.

 

Og hvor ofte skal man skrive ny inndatavalidering, skrive webform fra bunnen, strukturere kode rett og slett, inntil man innser at det finnes rammeverk der ute som ikke bare er skrevet av smarte folk, men at det også er tusenvis av andre programmerere som deg som bruker det samme rammeverket? Å lukke øynene for rammeverk er greit når man lager små løsninger, men vokser prosjektet sitter du igjen med 100% kode du må vedlikeholde selv og ingen andre forstår. Alternativt kan du sitte igjen med ett prosjekt med 50% egen kode og 50% rammeverk med hundrevis av aktive eksterne utviklere. Hvilket alternativ er da mest framtidsrettet?

 

Om jeg er i ett miljø med mange utviklere og det kommer inn en ny kar som bygger alt fra bunnen av ville jeg lurt på om han er smartere enn alle andre eller om han ikke har interesse av å lære noe nytt. Ingen av alternativene er positive. Jeg vil heller foretrukket å jobbe med noen som kjenner noen alternativer og jeg ville nok hatt masse å lære av en person som tar seg tid til å utforske mulighetene som finnes, helt sikkert.

 

Og, man må skal ikke bruke rammeverk til alt selv om jeg snakker varmt om det her. Det viktige er å finne det beste verktøyet til jobben.

[JohndoeMAKT]

Ditt syn på hvordan man koder uten rammeverk er ganske snevert.

 

Kommer også an på hvor mange etasjer du skal bygge på huset. Har du skeiv grunnmur eller ett hus som siger i ett hjørne så er det ikke like lett å bygge videre. Dessuten er det ikke så lett å rive og starte forfra heller når noen har flyttet inn i huset.

Dette er akkurat like gode argumenter for å ikke bruke rammeverk.

 

Og hvor ofte skal man skrive ny inndatavalidering, skrive webform fra bunnen, strukturere kode rett og slett, inntil man innser at det finnes rammeverk der ute som ikke bare er skrevet av smarte folk, men at det også er tusenvis av andre programmerere som deg som bruker det samme rammeverket?

Hvorfor skal man skrive ting på nytt om du ikke bruker rammeverk? Tusenvis av andre utviklere betyr også tusenvis av use cases som kan hindre spesialisering i systemet som gjør at din løsning blir suboptimal om basert på det.

 

Å lukke øynene for rammeverk er greit når man lager små løsninger, men vokser prosjektet sitter du igjen med 100% kode du må vedlikeholde selv og ingen andre forstår. Alternativt kan du sitte igjen med ett prosjekt med 50% egen kode og 50% rammeverk med hundrevis av aktive eksterne utviklere. Hvilket alternativ er da mest framtidsrettet?

Hvorfor skal ingen forstå kode ikke basert på et rammeverk?

Med hundrevis av aktive utviklere "på prosjektet ditt", hvordan håndterer du da programvare i supportmodus? En applikasjon med et par millioner unike brukere i uka som har stått i brakk i to år som du så skal oppdatere, oppdaterer du da samtidig koden fra tredjepartsutviklere? Går du da gjennom hver eneste endring siden utviklingsavbruddet eller skriver du et par tusen linjer unit tests?

Lager du enda større prosjekter igjen kan IMO det å ikke bruke et rammeverk være en fordel og mest fremtidsrettet.

[dahuff]

Ditt syn på hvordan man koder uten rammeverk er ganske snevert.

 

Kommer også an på hvor mange etasjer du skal bygge på huset. Har du skeiv grunnmur eller ett hus som siger i ett hjørne så er det ikke like lett å bygge videre. Dessuten er det ikke så lett å rive og starte forfra heller når noen har flyttet inn i huset.

Dette er akkurat like gode argumenter for å ikke bruke rammeverk.

 

Og hvor ofte skal man skrive ny inndatavalidering, skrive webform fra bunnen, strukturere kode rett og slett, inntil man innser at det finnes rammeverk der ute som ikke bare er skrevet av smarte folk, men at det også er tusenvis av andre programmerere som deg som bruker det samme rammeverket?

Hvorfor skal man skrive ting på nytt om du ikke bruker rammeverk? Tusenvis av andre utviklere betyr også tusenvis av use cases som kan hindre spesialisering i systemet som gjør at din løsning blir suboptimal om basert på det.

 

Å lukke øynene for rammeverk er greit når man lager små løsninger, men vokser prosjektet sitter du igjen med 100% kode du må vedlikeholde selv og ingen andre forstår. Alternativt kan du sitte igjen med ett prosjekt med 50% egen kode og 50% rammeverk med hundrevis av aktive eksterne utviklere. Hvilket alternativ er da mest framtidsrettet?

Hvorfor skal ingen forstå kode ikke basert på et rammeverk?

Med hundrevis av aktive utviklere "på prosjektet ditt", hvordan håndterer du da programvare i supportmodus? En applikasjon med et par millioner unike brukere i uka som har stått i brakk i to år som du så skal oppdatere, oppdaterer du da samtidig koden fra tredjepartsutviklere? Går du da gjennom hver eneste endring siden utviklingsavbruddet eller skriver du et par tusen linjer unit tests?

Lager du enda større prosjekter igjen kan IMO det å ikke bruke et rammeverk være en fordel og mest fremtidsrettet.

 

Du skal ikke skrive unit tests for rammeverket, api'ene pleier ikke å endre seg så mye, dessuten er man ikke nødt å oppgradere til siste signifikante versjon om du ikke skal utvikle videre.

 

Å lage ett eget rammeverk er som å skrive en dagbok med alt det du opplever underveis. Jeg utvikler på ett stort system hvor alt startet med å utvikle rammeverk og CMS fra bunnen av. De som skrev den opprinnelige løsningen har i dag mange kunder hvor vi er ett av dem. Løsningen fungerer greit for brukerne men å jobbe med det som utvikler er tungvindt fordi rammeverket knapt har ett definert API etter mange år med klattekoding og for få øyne som har studert koden. Det er lite hjelp fra rammeverket fordi det er laget for interne behov, og jeg er bare en ekstern utvikler.

 

Jeg ser ikke hvorfor noen frivillig velger å gjøre det slik, men det er nok lettere sagt enn gjort i etterpåklokskapens navn når kjellerprosjektet er blitt ett enterprise.

[JohndoeMAKT]

Å lage ett eget rammeverk er som å skrive en dagbok med alt det du opplever underveis. Jeg utvikler på ett stort system hvor alt startet med å utvikle rammeverk og CMS fra bunnen av. De som skrev den opprinnelige løsningen har i dag mange kunder hvor vi er ett av dem. Løsningen fungerer greit for brukerne men å jobbe med det som utvikler er tungvindt fordi rammeverket knapt har ett definert API etter mange år med klattekoding og for få øyne som har studert koden. Det er lite hjelp fra rammeverket fordi det er laget for interne behov, og jeg er bare en ekstern utvikler.

«Ikke bruk dårlige rammeverk».

Joda, men her var sammenligningen å ikke bruke rammeverk.

[torbjørn marø]

Vi snakker om hvilke abstraksjoner vi skal ha her. Vi baserer oss alltid på "rammeverk", men alle rammeverk/abstraksjoner tar bort noen muligheter samtidig som det gjør andre ting enklere. Utfordringen er å finne riktig nivå for ditt prosjekt.

 

I bunn har vi maskinkode.

Som et rammeverk over det har vi abstraksjonen assembly, som omdannes til maskinkode

Over der har vi C, som kompilerer til assembly

Over der har vi PHP, som kompilerer til C

Over der har vi f.eks. Drupal, som gir ytterligere abstraksjoner over PHP

Over der kan vi legge enda flere abstraksjoner.

 

Det gjelder altså å finne det nivået hvor man til enhver tid kan være mest mulig effektiv for et gitt prosjekt.

[siDDis]

C kompilerer til maskinkode, ikkje assembly.

Og PHP blir kompiliert til bytekode også er det ein PHP VM som oversetter dette videre til maskinkode.

Merk at grunnen til at PHP er treigare er ikkje fordi det brukar ein VM, men fordi det er dynamisk typa og dermed får kvar variabel ein overhead med at det må type sjekkes heile tida for å ikkje få ein runtime type error.

[dahuff]

Å lage ett eget rammeverk er som å skrive en dagbok med alt det du opplever underveis. Jeg utvikler på ett stort system hvor alt startet med å utvikle rammeverk og CMS fra bunnen av. De som skrev den opprinnelige løsningen har i dag mange kunder hvor vi er ett av dem. Løsningen fungerer greit for brukerne men å jobbe med det som utvikler er tungvindt fordi rammeverket knapt har ett definert API etter mange år med klattekoding og for få øyne som har studert koden. Det er lite hjelp fra rammeverket fordi det er laget for interne behov, og jeg er bare en ekstern utvikler.

«Ikke bruk dårlige rammeverk».

Joda, men her var sammenligningen å ikke bruke rammeverk.

Ser ikke for meg hvordan noe som er laget fra bunnen av ikke til syvende og sist også ender opp som ett rammeverk.

 

Når det gjelder valg av rammeverk så er det en sjelden luksus at man gjør dette selv i min erfaring.

[torbjørn marø]

C kompilerer til maskinkode, ikkje assembly.

Og PHP blir kompiliert til bytekode også er det ein PHP VM som oversetter dette videre til maskinkode.

Jeg går derimot ut ifra at PHP VM'en er skrevet i C, og at den orginale C-kompilatoren startet som assembly.

 

Ja, jeg innrømmer litt unøyaktigheter i det jeg skrev, men poenget er likevel det samme. Programmererens oppgave er å lage riktige og gode abstraksjoner, og å benytte seg av eksisterende abstraksjoner der det er hensiktsmessig.

[GeirGrusom]

C kompilerer til maskinkode, ikkje assembly.

Og PHP blir kompiliert til bytekode også er det ein PHP VM som oversetter dette videre til maskinkode.

Den vanlige implementasjonen gjør ikke dette etter det jeg vet, men det finnes løsninger som ordner det for deg.

Phalanger kompilerer til .NET CIL istedet for den vanlige PHP opcoden, og CIL kompilerer til maskinkode igjen. HipHop som Facebook folka utviklet kompilerer til C++ som igjen kompilerer til maskinkode (åpenbart).

 

Men den vanlige PHP run-timen kjører en interperering av PHP bytecode etter det jeg vet.

[dahuff]

C kompilerer til maskinkode, ikkje assembly.

Og PHP blir kompiliert til bytekode også er det ein PHP VM som oversetter dette videre til maskinkode.

Den vanlige implementasjonen gjør ikke dette etter det jeg vet, men det finnes løsninger som ordner det for deg.

Phalanger kompilerer til .NET CIL istedet for den vanlige PHP opcoden, og CIL kompilerer til maskinkode igjen. HipHop som Facebook folka utviklet kompilerer til C++ som igjen kompilerer til maskinkode (åpenbart).

 

Men den vanlige PHP run-timen kjører en interperering av PHP bytecode etter det jeg vet.

 

Hva menes med interperering av bytecode?

Jeg forstår det også slik at php-skript blir oversatt til bytecode/opcode som så blir tolket av en virtuell maskin.

 

http://php.find-info.ru/php/016/ch20lev1sec1.html

How the Zend Engine Works: Opcodes and Op Arrays

 

The Zend Engine executes a script by walking it through the following steps:

 

1.

 

The script is run through a lexical analyzer (often called a lexer) to convert the human-readable code into machine-digestible tokens. These tokens are then passed to the parser.

 

2.

 

The parser parses the stream of tokens passed to it from the lexer and generates an instruction set (or intermediate code) that runs on the Zend Engine. The Zend Engine is a virtual machine that takes assembly-style, three-address instruction code and executes it. Many parsers generate an abstract syntax tree or parse tree that can then be manipulated or optimized before being passed to the code generator. The Zend Engine parser combines these steps into one and generates intermediate code directly from the tokens passed to it from the lexer.

 

From the point of view of someone authoring PHP extensions or embedding PHP into applications, this functionality is wrapped into a single phase: compilation. Compilation takes the location of a script and returns intermediate code for it. This intermediate code is (more or less) machine-independent code that one can think of as "assembler code" for the Zend virtual machine.

 

This intermediate code is an ordered array (an op arrayshort for operations array) of instructions (known as opcodesshort for operation code) that are basically three-address code: two operands for the inputs, a third operand for the result, plus the handler that will process the operands. The operands are either constants (representing static values) or an offset to a temporary variable, which is effectively a register in the Zend virtual machine. In the simplest case, an opcode performs a basic operation on its two input operands and stores the result in a register pointed at by the result operand. In a more complex case, opcodes can also implement flow control, resetting the position in the op array for looping and conditionals.

 

3.

 

After the intermediate code is generated, it is passed to the executor. The executor steps through the op array, executing each quad in turn.

Endret 7. oktober 2011 av dahuff

[GeirGrusom]

Hva menes med interperering av bytecode? Jeg tolker også at php skript blir oversatt til bytecode/opcode som så blir tolket av en virtuell maskin.

Ja, det var det jeg mente. Bare jeg som rotet litt.

[Gjest Slettet+9871234]

Vi snakker om hvilke abstraksjoner vi skal ha her. Vi baserer oss alltid på "rammeverk", men alle rammeverk/abstraksjoner tar bort noen muligheter samtidig som det gjør andre ting enklere. Utfordringen er å finne riktig nivå for ditt prosjekt.

 

I bunn har vi maskinkode.

Som et rammeverk over det har vi abstraksjonen assembly, som omdannes til maskinkode

Over der har vi C, som kompilerer til assembly

Over der har vi PHP, som kompilerer til C

Over der har vi f.eks. Drupal, som gir ytterligere abstraksjoner over PHP

Over der kan vi legge enda flere abstraksjoner.

 

Det gjelder altså å finne det nivået hvor man til enhver tid kan være mest mulig effektiv for et gitt prosjekt.

 

C kompilerer til maskinkode, ikkje assembly.

Stort sett er det en 1 - 1 relasjon (isomorfi) mellom maskinkode og assembly. Assembly kode er laget for mennesker. Bruker du C kompilatoren som følger med http://www.embarcadero.com/products/cbuilder kan du velge om du vil ha .asm filen

 

Ytterligere informasjon: Back to assembly from C

Endret 8. oktober 2011 av Slettet+9871234

[TheClown]

Og totalt med eventuelt vedlikehold som kan komme med årene, hva tror du ville vært den mest lønnsomme løsningen? Da med tanke på hvor mye produktet mot hvor mye det kostet.

Med tanke på mange av de skreddersydde funksjonene vi måtte ha, så tror jeg det lønte seg å lage det fra bunnen, i stede for å modifisere og lage workarounds i de uendelige.

[torbjørn marø]

Og totalt med eventuelt vedlikehold som kan komme med årene, hva tror du ville vært den mest lønnsomme løsningen? Da med tanke på hvor mye produktet mot hvor mye det kostet.

Med tanke på mange av de skreddersydde funksjonene vi måtte ha, så tror jeg det lønte seg å lage det fra bunnen, i stede for å modifisere og lage workarounds i de uendelige.

Det eneste almenngyldige svaret i softwarebransjen: It depends!

[Terrasque]

 

er fra en Django konferanse, men uttalelsene der jeg linket til er vel generelt for alle frameworks

 

Hele keynote'n der er forsåvidt verdt å få med seg, selv om man hverken bruker Django eller Python.

Endret 11. oktober 2011 av Terrasque

[blackbrrd]

Personlig mener jeg at å hele tiden skulle lage ting fra bunn av på mange måter kan sammenlignes med å dra fram øks og sag og se seg om etter noen passelig store trær når man skal bygge seg et hus.

 

Spørsmålet bør være hvor mange ferdiglagde biter man kan bruke. Hvis jeg skal dra huseksemplet litt videre, så har vi følgende eksempler:

1) spesialtegnet av en arkitekt hvor man ikke tar hensyn til vanlige vindusstørrelser osv.

2) arkitekttegnet, men med hensyn til vanlige vindusstørrelser

3) ferdighus hvor du plukker designelementer, men bygger på normal måte

4) ferdighus hvor du vegger osv leveres som moduler

5) ferdighus hvor alt du gjør er å sette det sammen (rør ferdig montert i modulene osv)

 

Hva som lønner seg kommer så an på hvilke krav man har. Ting å tenke på er:

- Skal noen andre enn jeg vedlikeholde systemet?

- Hvem skal drifte det?

- Hvor viktig er oppetid?

- Hvor viktig er det å unngå datatap?

 

Av og til er riktig løsning å bare snekre sammen noen superenkle greier på 10 timer og så se hvor langt det holder. Hvis det stadig blir behov for nye features så kan det godt være det er greit å bytte til et ferdiglaget system som har disse (eller mange av disse) featurene.

 

Angående valg av rammeverk så er vel det noe som er helt svært vanskelig. Første gang man ser på et rammeverk så kan det se ut som det er blitt kodet av 100 aper på amfetamin. Grunnen er gjerne den at komplekse systemer er vanskelig å forstå uten god tid til å sette seg ned med dem. Samtidig kan de spare ufattelig med tid.

 

På jobben min så trengte vi f.eks et dokumenthåndteringssystem. Greit nok at jeg kunne hevet sammen noe greier som fungerte sånn passe greit, men jeg så med en gang alle de featurforespørslene som kom til å komme. Etter en stund endte vi opp med Alfresco (http://www.alfresco.com/), og det er et valg som har spart meg for mange hundre timer med arbeid.

 

Greit nok at ikke alt er akkurat som jeg ønsker det, men 95% er bra nok og firmaet er overhodet ikke interessert i at jeg skal sitte i et år for å lage noe som er bedre på de siste 5% og dårligere på de første 95%-ene.

 

Samtidig så har jeg vært ansvarlig for å utviklet et komplett serviceordre/lager/bestilling /faktura/osv -system og der fantes det rett og slett ingenting som gjorde det vi ønsket uten at det kostet millioner (og det hadde kun vært grunnfunksjonene). Grunnen til at det var verdt å bruke årevis på å lage dette var at firmaet fikk en logistikkavdeling på seks personer, mot den like store konkurrenten som hadde en logistikkavdeling på 20 personer. Denne konkurrenten er nå konkurs btw...

 

tl;dr

Se an jobben, se på valgene og se på de potensielle resultatene før du bestemmer hvor små eller store byggestener du skal bruke.

Endret 16. oktober 2011 av blackbrrd

[blackbrrd]

 

er fra en Django konferanse, men uttalelsene der jeg linket til er vel generelt for alle frameworks

 

Hele keynote'n der er forsåvidt verdt å få med seg, selv om man hverken bruker Django eller Python.

Veldig bra innlegg, likte spes sliden som vises ved 19:25, stemmer veldig bra.