Profesjonell webutvikling i 2013

[Gjest Slettet-Pqy3rC]

Ingen. Det er en absolutt sannhet, alltid, i alle sammenhenger.

...

Dette bør du ta hensyn til når du leser alle innlegg her inne, også mine.

Jeg er enig med deg og det gir en del bastante påstander i denne og andre tråder et lett humoristisk preg. Den eneste sannhet er at alle ting har sine fordeler og ulemper og at ting ofte koker ned til personlig preferanse. Selv bruken av et og samme verktøy kan jo skape endeløse diskusjoner om hvordan ting "skal" gjøres.

 

Om ikke annet skaper diskusjonen iallefall tips om hva som finnes der ute, aldri så galt at det ikke er godt for noe.

[Alex Moran]

Har du sett på Grunt?

Ja, og Make er overlegen på alle måter.

[Feh]

Det er vel bortimot bare PHP som ikke har noen innebygget støtte for asynkron behandling av requests. Når jeg søkte på det så drev folk og opprettet sockets. Dobbeltveteeff.

 

Det er riktig at PHP ikke har noen innebygd funksjonalitet for asynkron behandling av requests, men om man bruker 5 minutter på å se på dokumentasjonen til jQuery har man alt man trenger med $.ajax().

 

 

Ellers har jeg jobbet som webutvikler i litt over 2 år med PHP/HTML/CSS/JS(jQuery)/My+MSSQL og utvikler web-applikasjoner/systemer som vi selger til kunder samt vedlikehold av nettbutikken vår. Gikk 3-år på skole før dette hvor vi lærte helt basic stuff + java/systemutvikling. Resten har jeg måttet finne ut av selv.

 

Uansett har jeg møtt få eller ingen begrensninger for hva jeg kan lage med de språkene jeg behersker. Det er overraskende hvor enkelt det ofte er å få de til å spille sammen hvis man bare holder tunga rett i munnen, tenker logisk, og klarer å forenkle de prosessene man prøver å lage mest mulig. Ha semantikken i orden, skriv ren, konsekvent kode, holdt abstraksjonsnivået høyt og kommenter ALT du gjør så fungerer det ganske godt til tross for hvor svartmalt PHP er i manges øyne.

 

Ser mange snakker om hva som er fremtiden og jeg tror at de som er best rustet for fremtiden er de som lærer seg flere forskjellige språk og teknologier samt vet når de skal brukes. Verdens største nettsamfunn, Facebook, benytter såvidt meg bekjent både Java, PHP, Perl, C++ og Python i backend og mest sansynlig velger de språk ut fra oppgave og tar det som er mest passende. Hvilket språk man velger bør også baseres på hva man skal lage og hva man trives med. Akkurat nå jobber jeg som potet. Jeg prototyper, utvikler front-end, back-end, designer databaser, utvikler UX og UI, content-creation og har egentlig alle rollene som normalt er bygget opp av et helt team. I det lange løp er det en ganske uheldig greie fordi jeg aldri får tid til å bli virkelig god til noen av delene, men til gjengjeld vet jeg litt om alt, som i prinsippet er hva jeg er ute etter ift. videre karrierevei som om noen år forhåpentligvis ikke lenger innebærer å skrive så mye som en linje kode, men heller lede de som gjør det.

[tommyb]

I tillegg til jQuery så har man også andre rammeverk som scriptaculous, som implementerer asynkrone requests. Man trenger ikke jobbe med å opprette sockets om man ikke absolutt vil. :B

 

 

Hvis man koder i en IDE som supporterer navigering (tror jeg) at man ofte lager horisontal kompleksitet med unødvendig mange klasser / gettere og settere. Fordi dette er så "lett" å navigere mellom.

Programerer man i en editor som ikke supporterer dette vil man få lengre klasser.

Hva som er mest komplekst å lese av dette kommer vel ann på hva du er mest vant til.

 

Jeg er ikke direkte uenig. Men hva som er "unødvendig" er subjektivt, og da kan det hjelpe godt å ha en felles policy på hvordan man ønsker å ha det, på abstraksjonsnivåer, navngivning, etc. Set og get-funksjoner bruker man heller ikke bare fordi det er lett å navigere mellom, men fordi at man ønsker standardisering i hvordan ting virker. Når man har 2000+ php-filer ønsker man at ting fungerer noenlunde likt på tvers av filene. Den mer naturlige tilfallsmetoden koster seg i lengden. Tror ikke man skal trenge så veldig mange utviklere på et prosjekt før det kan lønne seg å utnevne en som skal fylle rollen som arkitekt.

[quantum]

Dette er illojalt, og en usynlig kostnadsdriver

 

det høres det jammen ut som dreamweaver er også :o) jeg tror nok de fleste er ganske bevisst hvilke verktøy de jobber raskest med. hvis man ikke er det og isteden skal være showoff med vi så blir det nok temmelig raskt litt pinlig når leveranser taaaaaar såååååå laaaaang tiiiiiid åååå fååååå feeeerrrrdddddiiiiigggg. tror nok også de fleste har god nytte av ide-verktøy, men når det en sjelden gang dukker opp en luring som kan utnytte kommendolinjeverktøyene (altså da snakker vi klassiske unix-shell-verkøty a'la sed, awk, grep, vi osv) så er det faktisk ganske effektivt.

 

har også ganske laber tro på å standardisere på ett bestemt ide-verktøy, man må ha et felles opplegg for bygg, integrasjon, versjonering, deployment etc. men det er sjelden mye å hente på å tre operativsystem og ide-verktøy nedover hodet på utviklerne, om man føler det er nødvendig er det fordi et eller annet ikke er som det skal.

[Gjest Slettet-Pqy3rC]

det høres det jammen ut som dreamweaver er også :o) jeg tror nok de fleste er ganske bevisst hvilke verktøy de jobber raskest med. hvis man ikke er det og isteden skal være showoff med vi så blir det nok temmelig raskt litt pinlig når leveranser taaaaaar såååååå laaaaang tiiiiiid åååå fååååå feeeerrrrdddddiiiiigggg.

Min erfaring er at den absolutte tidstyv mest av alt finnes i dårlig forarbeid. F.eks. kunder som i utgangspunktet ikke aner hva de skal ha og hvor prosessen må starte bortimot på nytt opptil flere ganger fordi folk ombestemmer seg underveis.

 

Er forarbeidet godt tror jeg det vil være mindre variasjoner i tidsbruk grunnet verktøy. Alt med måte selvfølgelig, skal en starte med å lage operativsystemet først vil jo ting ta tid.

 

Jeg er forøvrig tilhenger av at ulike ting har sine respektive styrker og svakheter, så det er jo ikke noe i veien for å mikse verktøy så lenge en har klarlagt og dokumentert arbeidsrutiner. Utfordringen er en høyere kunnskapsterskel for bedriften sett under ett.

[tommyb]

Dårlig forarbeid er den absolutte tidstyv. Alternativet til dårlig forarbeid er å ikke få oppdraget. Stein, møt hard plass.

 

Ellers sies det mye jeg ikke kan være uenig i i de to forrige innleggene.

[obergeru]

2000+ PHP filer hørtes ut som et prosjekt som burde splittes opp ;-)

Å ha flere utviklere som jobber på samme kode koster også ganske mye.

Man må standardisere byggerammeverk, kodestil, branching og mergeing strategi osv.

Hvis utviklerene i tillegg sitter i et annet land (som India) synker produktiviteten per utvikler ytterligere.

Endret 6. august 2013 av obergeru

[tommyb]

Jeg vil ikke snakke om min arbeidsgiver eller vårt hovedprodukt, men det er altså étt produkt som har mange årsverk bak seg og stadig videreutvikles på fulltid av flere utviklere.

[Feh]

Jeg vil ikke snakke om min arbeidsgiver eller vårt hovedprodukt, men det er altså étt produkt som har mange årsverk bak seg og stadig videreutvikles på fulltid av flere utviklere.

 

Jeg tipper CMS eller e-commerce

[The Jackal]

Ja, det er det. Nei, det er ikke bra. Da har de for eksempel valgt bort å få informasjon om syntax-feil for eget egos skyld, noe som er illojalt mot arbeidsgiver og gir unødvendige feil, kostnader og redusert kvalitetsopplevelse. Dessuten er disse verktøyene tregere å manøvrere i enn en god editor med code collapse, bedre søkeoptions, og ofte bruker de heller ikke støtte i highlighting. Det er også mye vanskeligere å finne feil i nøsting i slike verktøy. Det kan likevel være at de er bedre utviklere, men de tar på vegne av bedriften en avgjørelse om å stole mer på eget ego enn den støtten som er tilgjengelig. Dette er illojalt, og en usynlig kostnadsdriver.

 

At noen foretrekker en måte å jobbe på skal ikke diskvalifisere dem til en jobb, men man skal naturligvis forholde seg til bedriftens policy, hva den enn er. Hos oss spesifikt blir vi skeptisk heller enn imponert over at folk skriver de helst programmerer i notepad.

Nå bruker vel folk editorer som VI for eksempel nettopp fordi blant annet navigering, editering osv er ekstremt kraftig i forhold til en vanlig IDE. I tillegg har de fleste editorer en form for syntaxhighlighting og muligheter for plugins av forskjellige sorter. Hele avsnittet ditt virker som bare tull fra ende til annen spør du meg. Du vet kanskje ikke om alle mulighetene som finnes i editorer som VI, notepad++ osv? Bevares, jeg personlig bruker Visual Studio for jobben min og hadde følt meg rimelig naken uten, men å påstå at folk er ineffektive fordi de bruker andre verktøy blir bare sprøyt.

[tommyb]

Sprøyt lager du selv, når du tolker ting som ikke er sagt. Du går til angrep på person. Det er ikke måten å gå i en tråd som er til for å hjelpe folk til bedre kunnskap om verktøy.

 

Jeg har ikke sagt at folk er ineffektive fordi de bruker andre verktøy. Jeg har heller ikke sagt at Dreamweaver er det eneste gode verktøyet. Jeg har sagt at folk som anser Dreamweaver først og fremst er en WYSIWYG-editor, tydeligvis ikke har peiling på hvilket kraftig verktøy Dreamweaver er. Jeg har sagt at Dreamweaver, og andre IDEer for den saks skyld, har en rekke støtteverktøy som gjør deg mer effektiv, og at å la egoet komme i veien for å bruke tilgjengelige støtteverktøy ikke er bra. Og så har jeg nevnt en del av funksjonaliteten i Dreamweaver som jeg benytter og delvis eller helt mangler eller er dårligere i andre verktøy jeg har prøvd. Det er strengt tatt det viktigste av det jeg har skrevet her. "Slutt å tro at Dreamweaver er for designere, den har en rekke gode verktøy som støtter utvikleren. Mange av disse mangler eller er dårligere i andre verktøy jeg har prøvd."

 

Jeg vet ikke om alle mulighetene som finnes i editorer som VI, notepad++, osv. Du kjenner ikke til alle mulighetene som finnes i editorer som Dreamweaver. Ingen kjenner til alt.

 

Jeg bruker som sagt Notepad++, det er et flott verktøy til småjobber. VI har ganske høy terskel så jeg har holdt meg til nano der VI har vært aktuelt. Jeg kjenner ikke til navigeringsmulighetene i VI så de kan jeg ikke uttale meg om. Jeg kjenner VI ekstremt dårlig, og har tenkt å la det forbli slik. Det er en pain å bruke slike editorer, for meg personlig, og såvidt jeg kan se for mange andre også. Selv halvparten av Linux-guruene skyr VI og jeg er ikke masochist. Men jeg kjenner Notepad plus plus og søket i Dreamweaver er mange ganger bedre enn søket i Notepad++. Notepad++ har naturligvis andre ting det er bedre enn Dreamweaver på også.

 

Jeg har ikke sagt et ord om hvorvidt VI er et bra verktøy eller ikke, det vet jeg ikke engang. Men Notepad++ når ikke Dreamweaver til knærne når det gjelder søk, navigering, kodemarkering, code collapse, og ikke minst serverstøtte. Det er et primitivt verktøy i forhold, mer et suverent alternativ til MS Notepad. Notepad++ har syntaxhighlighting, men det er rett og slett et absolutt minimum av hva man må ha for å kunne regnes som et utviklingsverktøy.

 

Dreamweaver har feil, at det utvikles i mikrosteg av late, grådige Adobe er en vesentlig sådan, men det tilbyr masse utviklerstøtte som f.eks. notepad, notepad++ eller ultraedit ikke gjør. Jeg har testet Eclipse for PHP men det fungerte dårlig. Jeg har kjørt en trial av Zend Studio, og det virket ikke dårlig, sikkert bedre på PHP-syntax etc. Men den manglet også endel som Dreamweaver har.

 

Jeg burde sikkert bare holde kjeft, men folk som velger bort syntaxhighlighting, code collapse, mulighet til å velge filutvalg å søke gjennom, flerserverstøtte, etc, fordi de stoler mer på egen fortreffelighet, ER illojale, og det går ut over effektiviteten. De kan likevel være gode programmerere, for all del. Folk som derimot velger et tilsvarende sett med støtteverktøy men i en annen editor er vel heller MER effektiv siden de tydeligvis har funnet et verktøy som passer dem bedre. Men dersom avgjørelsen tas fordi Dreamweaver har et WYSIWYG-modus, så henger nok ikke begrunnelsen helt på greip.

Endret 7. august 2013 av tommyb

[siDDis]

Når ein blander inn Javascript/jQuery som eit val til manglende støtte for asynkrone requests i PHP så har eit totalt misforstått kva det er!

 

Men asynkrone requests er heller ikkje så veldig verdifullt som mange skal ha det til. Men i nokre tilfeller så er det sjølvsagt ein betre løysning enn vanlege requests.

 

Og når dykk snakke om IDE'ar, kvifor er det ingen som snakke om Jetbrains sine produktar. Meg kjent så er dei overlegen til Java, HTML, Javascript, Python, Ruby, PHP osv enn alle dei andre alternativa du skulle finne. Eg digge at min IDE automatisk kommentere og foreslår endringar på kodebasen der koden er dårleg eller rett og slett tullete

[tommyb]

Personlig har jeg ingen kunnskap om Jetbrains, så da er det vanskelig for meg å vurdere det i noen særlig grad.

 

Edit: se bold.

Endret 7. august 2013 av tommyb

[Sokkalf™]

Og når dykk snakke om IDE'ar, kvifor er det ingen som snakke om Jetbrains sine produktar. Meg kjent så er dei overlegen til Java, HTML, Javascript, Python, Ruby, PHP osv enn alle dei andre alternativa du skulle finne. Eg digge at min IDE automatisk kommentere og foreslår endringar på kodebasen der koden er dårleg eller rett og slett tullete

 

Bruker IntelliJ Ultimate selv (hovedsaklig til Java, Ruby og Python, men har kikket litt på Groovy, Scala og Clojure også). Knallgodt produkt!

[rockPaperScissors()]

Når ein blander inn Javascript/jQuery som eit val til manglende støtte for asynkrone requests i PHP så har eit totalt misforstått kva det er!

 

Det er vanlig å ha cron jobb kjørende som håndterer en arbeidsliste fra databasen om man skal gjøre noe av tyngre karakter som ikke er naturlig å utføre samtidig med ett svar på klientforespørsel. PHP fungerer jo som kjent som shell skript også.

[GeirGrusom]

Det er vanlig å ha cron jobb kjørende som håndterer en arbeidsliste fra databasen om man skal gjøre noe av tyngre karakter som ikke er naturlig å utføre samtidig med ett svar på klientforespørsel. PHP fungerer jo som kjent som shell skript også.

Det har ingenting med det å gjøre.

 

Asynkron kode i C# 5:

Task<int> foo = Foo();

var bar = Bar();

return bar + await foo;

 

Foo() og Bar() kan være webtjenester, eller lesning fra filer på disken eksempelvis. Det er ikke noe poeng at webserveren din skal sitte og tvinne tommeltotter mens dette foregår.

 

Men i motsetning til bortimot alt av andre verktøyer, er det ikke noen innebygget støtte for asynkron behandling i PHP.

[tommyb]

Ah, jeg forsto det opprinnelig slik at det var snakk om asynkrone requests.

[siDDis]

Det er asynkrone requests, men det er på serversida og ikkje på klientsida.

[rockPaperScissors()]

Det har ingenting med det å gjøre.

[...]

Men i motsetning til bortimot alt av andre verktøyer, er det ikke noen innebygget støtte for asynkron behandling i PHP.

 

Jeg forstår det. Men jeg synes det er en renere løsning å bruke cron til bakgrunnsoppgaver og gjøre noen kompromisser framfor å hacke seg rundt begrensingene i PHP. Vi er vel alle klar over at programmeringsspråk foo ikke er bar og vil aldri bli bar, så man lærer seg å gjøre foo.