Profesjonell webutvikling i 2013

[siDDis]

Enige med GeirGrusom (igjen).

 

Å jobbe utan versjonskontroll er direkte uansvarleg! VPS hosting idag kan fåes for 6kr månaden idag, så det er ingen unnskyldning

[Sokkalf™]

Enig i at man må ha versjonskontroll, men ser ikke helt hvor det quantum sier utelukker dette. Han sier jo at man MÅ ha versjonskontroll - men at man ikke nødvendigvis kan unngå FTP.

 

Det ene utelukker ikke det andre, man bruker isåfall versjonskontroll lokalt, på github, på en egen server, whatever, og pusher til produksjonsserveren med FTP.

[GeirGrusom]

Enig i at man må ha versjonskontroll, men ser ikke helt hvor det quantum sier utelukker dette. Han sier jo at man MÅ ha versjonskontroll - men at man ikke nødvendigvis kan unngå FTP.

 

Det ene utelukker ikke det andre, man bruker isåfall versjonskontroll lokalt, på github, på en egen server, whatever, og pusher til produksjonsserveren med FTP.

kanskje jeg som er dårlig til å lese. Det virket bare som "enten FTP eller GIT" som er litt merkelig må jeg innrømme.

[The Jackal]

FTP og GIT løser vel 2 helt forskjellige problemer spør du meg i alle fall Det som ikke er blitt nevnt så vidt jeg har fått med meg, og som i alle fall jeg mener er et must når det gjelder profesjonell (web) utvikling i 2013, er CI (Continuous Integration), CD (Continuous Deployment), og (som nevnt) kildekode systemer. Alt bør egentlig være på plass, og kan eliminere feil før ting kommer seg helt ut i produksjon. Samtidig gjør det hele prosessen fra, skriving av kode, testing og ut til produksjonsmiljøer rimelig kjapt og enkelt når ting kjører som det skal/bør.

 

Edit. Kan nevne at kunden jeg er hos nå, bruker Team City for CI (og bygging av NuGet packages), Octopus Deploy for deployment og SVN som kildekode system. Funker veldig bra når flere ting skal ut samtidig. Vi snakker java, .NET, stormaskin, CRM systemer++.

Endret 12. august 2013 av The Jackal

[tomsi42]

Jeg tror det kan være vanskelig å forstå nytten av et godt kildekode system, før man har brukt et og fått reddet ræva si et par ganger.

 

Jeg tror gjerne at noen bruker ftp mot server som en sikring; men da er det fordi de ikke vet bedre.

[Left Blank]

Jeg mente det iaf ikke som git vs ftp. jeg tenkte bare når man først arbeider i git, så kan bruke diverse deployverktøy, og komme inn i den rytmen. For noen år siden så var det ofte at man arbeidet med individuelle kildekodefiler, for så å opplaste med FTP, de to metodene henger litt sammen. Forskjellig though. Og ja, shared hosting firmaer kan gjøre mer for å støtte forskjellige verktøy. Selv ville jeg alltid heller hatt en billig VPS, uansett. Shared er helvete.

[The Jackal]

Jeg mente det iaf ikke som git vs ftp. jeg tenkte bare når man først arbeider i git, så kan bruke diverse deployverktøy, og komme inn i den rytmen. For noen år siden så var det ofte at man arbeidet med individuelle kildekodefiler, for så å opplaste med FTP, de to metodene henger litt sammen. Forskjellig though. Og ja, shared hosting firmaer kan gjøre mer for å støtte forskjellige verktøy. Selv ville jeg alltid heller hatt en billig VPS, uansett. Shared er helvete.

 

Nå støtter i alle fall Octopus Deploy, og jeg vil tro de aller fleste continuous deploy applikasjoner, scripting. Poenget er å automatisere selve deployment slik menneskelige feil i stor grad blir luket vekk. Selve opplastingen kunne man da scriptet om ønskelig. Som en nice feature kan man da også rulle tilbake til en tidligere versjon om man mot formodning skulle klare å få ut noe som totalt feiler.

[quantum]

Til de som lurte på dette - jeg mente altså ikke "enten git eller ftp". Kan ikke helt se for meg hvordan det ene skulle utelukke det andre ... ftp er ikke spesielt ønskelig protokoll for filoverføring, og det var det jeg mente man noen ganger ikke kan slippe unna.

Endret 12. august 2013 av quantum

[quantum]

Nå støtter i alle fall Octopus Deploy,

Men det er for .Net, er det ikke? Hvordan velger egentlig php-utviklere å gjøre dette på en profesjonell måte, altså kontinuerlig integrasjon, deployment osv.?

[The Jackal]

Men det er for .Net, er det ikke? Hvordan velger egentlig php-utviklere å gjøre dette på en profesjonell måte, altså kontinuerlig integrasjon, deployment osv.?

 

Nja...i bunn og grunn funker det nok best med .NET, men det baserer seg egentlig på NuGet packages. En NuGet package kan egentlig inneholde hva som helst, også PHP filer for eksempel. Du kan dermed i teorien i alle fall bruke det til PHP også, men jeg vil nok tippe det finnes stacker som i alle fall potensielt passer bedre. For å være helt ærlig så kjenner jeg ikke til så mange Continious Deployment tools bortsett fra Octopus Deploy og Redgate Deployment Manager (som jeg ikke har brukt). Jeg merker uansett en stor fordel ved i bruke et Continious Deployment tool i utviklingen, så det bør absolutt flere bruke.

[rockPaperScissors()]

Men det er for .Net, er det ikke? Hvordan velger egentlig php-utviklere å gjøre dette på en profesjonell måte, altså kontinuerlig integrasjon, deployment osv.?

 

Tja. Phing og Jenkins kan brukes for eksempel. Har ennå tilgode å møte php-utviklere som prater mye om kontinuerlig integrasjon og deployment. Men det skyldes nok at jeg har for det meste vært borti legacy prosjekter som fortsatt bærer preg av praksis som ligger noen år tilbake. Utviklingen går heldigvis framover, så du finner helt sikkert mange hederlige prosjekter også.

[quantum]

så du finner helt sikkert mange hederlige prosjekter også.

Ja det gjør man helt sikkert, for ikke å si hederlige utviklere :-) Men jeg opplever det slik at .Net og Java-plattformene nyter godt av hverandres konkurranse, de har hver sine fortrinn/forsprang som konkurrenten anstrenger seg for å ta igjen. Mens PHP bare dilter etter. Har andre plattformer tatt opp i seg noen innovasjoner fra PHP i det heletatt?

[rockPaperScissors()]

Play Framework trekker i alle fram share nothing arkitekturen som en av sine viktigste egenskaper om ikke annet. Men alt i alt kommer det meste av ny innovasjonen i PHP som inspirert fra andre miljø enn PHP. Men det er ikke noe negativt i at gode løsninger tas i bruk andre steder enn der de ble oppfunnet.

[quantum]

Men det er ikke noe negativt i at gode løsninger tas i bruk andre steder enn der de ble oppfunnet.

Neida, snarere tvert imot, men innovasjonene må jo komme fra et sted også ...

[rockPaperScissors()]

Det skjer nok innovasjon i PHP miljøet også, men kanskje på ett mer "grasrotnivå". Web rammeverk dukker jo opp som gresstuer på ett jordet. Det er sunt for innovasjon at konvensjoner rives ned og bygges opp igjen, og at man tar det beste fra tidligere erfaringer. Jeg er ikke sikker på at Ruby er ensbetydende med webutvikling med Rails, eller at C# er ensbetydende med webutvikling med ASP.NET MVC, fører til mer innovasjon i alle henseendelser. Det virker som at det er lavere terskel for å lage nye rammeverk i PHP verdenen, på godt og vondt..

[GeirGrusom]

eller at C# er ensbetydende med webutvikling med ASP.NET MVC,

 

Det er et titalls programmeringsspråk som kan brukes med ASP.NET, og MVC er ikke det enese tilgjengelige web rammeverket (Nancy, Web Forms, OpenRasta).

 

Men i motsetning til PHP så er det massevis av alternativer til templatespråket som følger med ASP.NET. Templatespråk og codebehind er ikke det samme der.

 

Kulturen per nå er derimot C# på ASP.NET med MVC og Razor som templatespråk. Men det er ikke så mange år siden ASP.NET Web Forms var det som gjadt (som er noe drit).

 

Har lett rundt nå, og det er massevis av alternativer for MVC på .NET.

Endret 14. august 2013 av GeirGrusom

[rockPaperScissors()]

Men i motsetning til PHP så er det massevis av alternativer til templatespråket som følger med ASP.NET. Templatespråk og codebehind er ikke det samme der.

 

Her er noen eksempler på template motorer; Twig, Rain.tpl, og Smarty. Det kryr av forskjellige initiativer i PHP verdenen, det er ikke så lett å holde oversikt.

 

Du velger også selv hvordan du organiserer koden. Det finnes mange MVC (og HMVC) rammeverk så det er ingen unnskyldning for å blande logikk og visningsmaler for prosjekter større en én side. Det finnes også rammeverk som kommer med kommandolinjeverktøy som genererer dine kontrollere og modeller for CRUD operasjoner ogsåvidere..

 

Jeg synes det er litt morsomt at det finnes endel interessante rammeverk (om man gidder å lete) og at prosjektet kan "kastes" på en billig webhost som knapt koster vekslepenger, og du er good to go.

[GeirGrusom]

Her er noen eksempler på template motorer; Twig, Rain.tpl, og Smarty. Det kryr av forskjellige initiativer i PHP verdenen, det er ikke så lett å holde oversikt.

 

Du velger også selv hvordan du organiserer koden. Det finnes mange MVC (og HMVC) rammeverk så det er ingen unnskyldning for å blande logikk og visningsmaler for prosjekter større en én side. Det finnes også rammeverk som kommer med kommandolinjeverktøy som genererer dine kontrollere og modeller for CRUD operasjoner ogsåvidere..

 

Jeg synes det er litt morsomt at det finnes endel interessante rammeverk (om man gidder å lete) og at prosjektet kan "kastes" på en billig webhost som knapt koster vekslepenger, og du er good to go.

 

Det er faktisk ganske komisk at det blir laget templatemotorer på toppen av PHP da PHP er lite annet enn en templatemotor.

 

edit: når det gjelder publisering så er Amazon og Azure faktisk temmelig rimelig, og du kan bruke akkurat hva svarte du vil.

Endret 14. august 2013 av GeirGrusom

[rockPaperScissors()]

Det er faktisk ganske komisk at det blir laget templatemotorer på toppen av PHP da PHP er lite annet enn en templatemotor.

 

Vedr. templatemotor. Så veldig komisk er det vel ikke. Er det komisk at Microsoft pusher Razor når WebForm View Engine gjør samme nytten?

[GeirGrusom]

Vedr. templatemotor. Så veldig komisk er det vel ikke. Er det komisk at Microsoft pusher Razor når WebForm View Engine gjør samme nytten?

 

Forskjellen er at i ASP.NET så er System.Web.WebFormsViewEngine en plug-in til ASP.NET; og man kan enkelt erstatte den.

C# er ikke et templatespråk, og kan ikke uten videre brukes som det (i motsetning til PHP). Dermed har man WebFormsViewEngine, og RazorViewEngine i tillegg til andre.

 

På vårt system har vi nå lagt inn RazorGenerator som er en View engine som bruker koompilerte Razor views. Altså når man trykker Build Solution, så kompileres en Razor view til MSIL. Fordeler er at vi kan luke ut alle syntaks og en del programmeringsfeil i compile time.

 

Det oppfordres også til å skille view fra codebehind, noe som overhode ikke er tilfellet i PHP, og bare her på forumet så er mesteparten av koden som postes for det meste en salig blanding av SQL og HTML templating.