Profesjonell webutvikling i 2013

[Dundas]

Jeg kjenner VI ekstremt dårlig, og har tenkt å la det forbli slik.

 

Dette er en holdning jeg ofte møter, når det gjelder vi, og jeg hadde den en gang selv. Til jeg bestemte meg for å "bite i det sure eplet". Det tok meg vel 5 minutter å bli komfortabel, og siden har jeg aldri sett meg tilbake.

[tommyb]

Jeg har nok brukt mer tid i VI enn 5 minutter, og ble ikke komfortabel. Det var heller direkte smertefullt. Nettopp derfor ser jeg ingen grunn til å velge det verktøyet. Det er ikke en holdning, det er en vond erfaring.

[Sokkalf™]

Jeg vil ikke anbefale vi hvis man skal lære seg vi - prøv heller vim (VI iMproved). Den er betydelig mer komfortabel å jobbe med.

[etse]

Dette er en holdning jeg ofte møter, når det gjelder vi, og jeg hadde den en gang selv. Til jeg bestemte meg for å "bite i det sure eplet". Det tok meg vel 5 minutter å bli komfortabel, og siden har jeg aldri sett meg tilbake.

det tar gjerne 5-10 minutter å først klare å bruke programmet, men da kan du ikke nok om programmet til at det faktisk har noen nytteverdi over andre editorer. Med mindre du kan mange av hotkeyene og kommandoene er det ingen grunn til å velge VIM over ting som SumblimeText, kate eller Gedit - og flere av disse editorene har støtte for mange av de samme funksjonalitetene.

[tommyb]

I situasjoner der jeg bruker VI har jeg ikke tilgang til VIM (eller nano). Da er det typisk ganske barebone miljøer.

[quantum]

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.

 

Siden du nå engang nevner det så ja, det du sier her stemmer som regel ikke og kunne derfor godt vært usagt. Bygg, CI, test, versjonering osv. håndteres som regel utenfor ide og man kan stå fritt til å velge personlig verktøy, å ha som grunnholdning at det primært fører til ineffektivtitet og ikke effektivitet synes jeg er ganske merkelig. Det er ihvertfall helt i strid med min erfaring. Hvorfor tror du noen kan tre et verktøy nedover hodet på deg og si at dét, det er du mest effektiv med? Sånn er det ikke i virkeligheten. Det kan være nødvendig i organisasjoner med veldig lav kompetanse, dog.

[tommyb]

Hvorfor tror du noen kan tre et verktøy nedover hodet på deg og si at dét, det er du mest effektiv med?

 

Jeg har ikke sagt noe som i det hele tatt ligner på den påstanden.

 

Det jeg har sagt er at å ha et verktøy som gir deg utviklerstøtte godt integrert i verktøyet er effektivt, og å velge bort støtte er lite effektivt. Det er snakk om utviklere som bruker notepad. Hvis du bruker notepad velger du aktivt bort å få syntax testet. Det er snakk om å laste opp filer med en FTP-klient. Dette gjøres mye raskere ved at man rett og slett ikke trenger å gjøre noe aktivt for å laste opp. Det er snakk om at sammenligning av filer mellom servere startes opp med ett museklikk, integrert fra det samme verktøyet du sitter i. Jeg påstår ikke at DreamWeaver er det eneste programmet som kan gjøre det, jeg påstår at det er ett av mange verktøy som gjør en utvikler mer effektiv, og at DreamWeaver har en del slike verktøy.

 

Og de to siste linjene der synes jeg du bør slette. Det er vel ikke sånn du ønsker å framstille deg selv?

[quantum]

@tommyb hvilke linjer snakker du om som burde slettes?

 

mye av det du hevder er fordeler med et ide kan man likegodt få via et passelig utvalg shell-verktøy, men da må man vite om og kunne disse, akkurat som man må vite om og kunne funksjonene i et ide.

 

du kan likegodt snu på det, et ide har en masse funksjoner som likegodt kan virke mot sin hensikt, ta f.eks. kodegenerering - hvor enkelt er det egentlig å forstå og vedlikeholde generert kode? refactoringfunksjonalitet som får masse utilsiktede sideeffekter?

 

hovedinnvendigen min mot det du hevder er at det nettopp *ikke* er illojalt å ta ansvar for egen effektivitet ved å bruke de verktøyene man vet man jobber mest effektivt med.

 

om du prøver å være showoff ved å bruke bare vi eller verdens mest blingbling wysiwyg-ide-gui så blir du, som nevnt i forrige runde, tidlig avslørt.

 

siden denne tråden handler om profesjonalitet; profesjonalitet er å ta ansvar, ikke å være lojal mot dysfunksjonelle standarder.

Endret 7. august 2013 av quantum

[tommyb]

De linjene der du antyder at de som har andre synspunkter enn deg ikke lever i virkeligheten og jobber i organisasjoner med lav kompetanse. De har ikke noe i en diskusjon om utviklingsverktøy å gjøre.

 

Edit: De to siste linjene er/var:

Sånn er det ikke i virkeligheten. Det kan være nødvendig i organisasjoner med veldig lav kompetanse, dog.

Endret 7. august 2013 av tommyb

[quantum]

De linjene der du antyder at de som har andre synspunkter enn deg ikke lever i virkeligheten og jobber i organisasjoner med lav kompetanse. De har ikke noe i en diskusjon om utviklingsverktøy å gjøre.

jaha, og i hvilke linjer antyder jeg det? det jeg sier er at folk må ta ansvar selv, å være "lojal" og tro det er det mest effektive fordi organisasjonen man jobber i vet bedre enn hver enkelt hvilke verktøy som er mest effektivt for hver enkelt er ikke profesjonelt, og det synes jeg spesielt er verdt å nevne i en diskusjon om profesjonalitet.

 

Edit: Lav kompetanse kan være en faktor som gjør det nødvendig å standardisere, at man er låst til et verktøy på grunn av teknologiplattformen man har valgt er et annet. Skjønner ikke hva som er så provoserende med dette?

Endret 7. august 2013 av quantum

[Dundas]

Denne skitttkastingen vitner iallefall ikke om profesjonalitet.

[quantum]

Denne skitttkastingen vitner iallefall ikke om profesjonalitet.

Kan du ikke heller prøve å være litt mer konkret hvis det er noen du er uenig med?

[DarkSlayer]

Jeg har ikke vært et sted hvor jeg kunne velge IDE.

 

Man har felles IDE fordi de implementerer felles formatering av koden. Det gir minst støy i versjonering som svn/git.

Man har felles IDE fordi vi utviklere ofte parprogrammerer. Det er en god måte å introdusere nye medarbeidere i kodebasen, kunnskapsdeling, og gir mer effektiv programmering, og bedre kode med mindre feil.

Man har felles IDE fordi det da er lettere å hjelpe naboen når de står fast med et eller annet. Bare se på Eclipse vs IntelliJ, de har jo forskjellige shortcuts og det kan få den beste utvikleren til å gå i frø. Tenk deg Eclipse vs VIM ... omg.

 

Man velger felles verktøy fordi man jobber sammen med noen i et team.

 

Man trer nedover huene på folk felles verktøy så alle kan bli bedre. De som kan velge selv jobber antagelig alene. Da er jo diskusjonen død om hva som er best.

[Sokkalf™]

Jeg jobber i team, og vi kan velge verktøy selv. Kan ikke si jeg har annet enn gode erfaringer med det. Var også slik i den forrige jobben jeg hadde.

 

Felles IDE fordi man kan hjelpe naboen? For totalt nybegynnere kan det jo ha en verdi (men da velger de sannsynligvis samme verktøy som den som fungerer som en type "mentor" for dem uansett) , men ellers ville jeg være litt skeptisk til en utvikler som lar seg stoppe av at han ikke finner ut av IDE-shortcuts..

 

Ser ikke helt argumentet med parprogrammering heller. Alle IDEer jeg har vært borti har da hatt koden i fokus - som bør være det eneste som teller i en sånn situasjon.

 

Når det gjelder formatering av koden, så kan vel omtrent samtlige IDEer konfigureres mtp tab/spaces, spaces per tab, kodestil o.l - så jeg ser egentlig ikke det som noe problem heller.

[siDDis]

IntelliJ støtter jo dei shortcutsa du er vane med, eg brukar IntelliJ med Eclipse shortcuts.

[siDDis]

Og dette med kodestil, bruk ein IDE som viser tydeleg skille på whitespaces og tabbing. Samt ein IDE med kodeanalyseverktøy som sørgje for at kodestilen følgje ein convention som PEP8 eller Java

[quantum]

Det fins standarder for kodeformateringsinnstillinger som man kan importere/eksportere på tvers av verktøy. Hvordan en utvikler kan bli forvirret av en annen utviklers keybord-shortcuts forstår jeg ikke helt.

 

Verktøystandardisering er ikke noen ulempe i seg selv, ofte er det en fordel eller nødvendighet, men jeg mener gevinsten ikke er så stor på IDE-nivå. Dermed er ikke noe stort poeng å være lojal mot standarden heller. Spesielt ikke hvis standarden ikke er optimal. Å blindt følge en slik standard synes jeg ikke er profesjonelt.

 

Utviklingsstandarder i organisasjoner har en tendens til å utdateres og behøver et kritisk blikk. Aller helst skal jo organisasjonen ha prosesser som ivaretar dette, men slik er det ikke alltid. Da må noen andre ta ansvar og være "illojale" om nødvendig.

[Left Blank]

Sånn til OP angående FTP.

 

Jeg vil anbefale å droppe FTP, det er lite fleksibelt å opplaste filer sånn. Det er bedre å bruke f eks Git til versioning, det er bare så mye bedre når man får dreisen på det. Om man bruker sånn index1.php, index2.php, index-ny.php, og generellt arbeider med filer, så blir det utrolig uoversiktlig. Lag en symlink som apache vhost til en 'current' mappe, som blir en fresh mappe du kan deploye til, og du kan også gjøre rollbacks til alle andre gamle versjoner. Når du skifter hvor symlinken peker, får du instant switch av websiden, istedenfor å opplaste 5 minutter over FTP, etc.

[quantum]

enig i at git er bedre til versjonering enn ftp, som ikke er et versjoneringsverktøy men en filoverføringsprotokoll. og helt enig i at man bør (les: må) ha et versjoneringssystem, git er utmerket, svn fungerer også bra. problemet er vel heller at man ikke alltid kan velge bort ftp, fortrinnet med php er ofte rimelig hosting og da har man noen ganger ikke annet valg enn ftp.

 

med i "professional pakka" skal det også være enhetstester og ikke minst et system for kontinuerlig integrering/integrasjonstester. det er spesielt viktig med php hvor det ellers ikke er noe som hindrer en i å legge ut til og med kompileringsfeil i produksjon.

[GeirGrusom]

enig i at git er bedre til versjonering enn ftp, som ikke er et versjoneringsverktøy men en filoverføringsprotokoll. og helt enig i at man bør (les: må) ha et versjoneringssystem, git er utmerket, svn fungerer også bra. problemet er vel heller at man ikke alltid kan velge bort ftp, fortrinnet med php er ofte rimelig hosting og da har man noen ganger ikke annet valg enn ftp.

 

Skjønner ikke hvordan det skal hindre deg fra å ha et git repository... Jeg vil påstå at det er litt uansvarlig å jobbe uten å bruke versjonskontroll.