Share
Så du er allerede en ganske god webutvikler.
Du har noen killer CSS-kutter (kryss-nettleser selv), kanskje du har vært en Photoshop-ekspert i årevis, og du har nok jQuery kunnskap for å gjøre nesten hvilken som helst kjede animasjon gå jevnt.
Men sikkert spør du deg selv, hva blir det neste?
Faktisk er et av de mest stilte spørsmålene om webutvikling, "hvordan holder jeg på forkant?" Chris Coyier presenterte nylig et fantastisk snakk om emnet, og det er nettsteder dedikert til å holde seg oppdatert om de nyeste webdesignnyhetene. Addy Osmani er på vei til å bli en bedre front-end ingeniør setter noe flott innhold ut på tavlen for at du skal vurdere om emnet; Unødvendig å si, mange smarte mennesker tenker på dette emnet, så du er på vei i riktig retning.
Space Ghost tapet, av Mads Frantzen I denne artikkelen vil vi snakke om en svært viktig måte å sette deg fra hverandre og bli en bedre utvikler: å bli en effektiv rask samhandling utvikler.
Raskt samspillingsutvikling er et uttrykk vi bruker i dag for å beskrive praksisen om å raskt lage noe for nettet som en bruker kan samhandle med, spesielt med en intensjon om å raskt iterere og polere samspillet. Dette er ikke det samme som å designe flate dokumenter; I stedet omfatter dette å bygge noe som har en eller flere storylines av interaksjon.
Dette kan for eksempel omfatte en widget som brukeren kan skrive inn og søke, eller en rullegardinmeny som lar en bruker velge et undermenyelement. Disse interaktive stykkene er byggeblokkene til en større historie av brukerens full erfaring med å bruke et nettsted, og dermed er de utrolig viktige for å kunne iterere gjennom og "føle". Ved utforming av et nettsted kan disse samspillene gjøre eller ødelegge brukerens opplevelse, og dermed kunne gjøre eller ødelegge nettstedets effektivitet som helhet.
Interaksjoner har ikke alltid "bevegelige" brikker; Faktisk er rask samspillutvikling ofte avhengig av innholdshierarkier og hyperkoblinger så mye som noe annet. Interaksjonsutvikling tar hensyn til menneskets fulle samspill med datamaskinen, inkludere intuksjoner om brukerbasen, grunnleggende forståelse av menneskelige faktorer og kunnskap om meldingen og bildet av organisasjonen eller individet som representeres av samspillet.
Hvis jeg ansetter en front-end webutvikler (eller noen for den saks skyld), tenker jeg på fem primære ting.
Disse spørsmålene er svært viktige for enhver del av ansettelsesprosessen. Det første spørsmålet er vanligvis bestemt basert på interaksjonskjemi - ikke noe vi skal dekke i denne artikkelen. Den femte er vanligvis bestemt fra tilfelle til sak, og er også noe som ikke er omfattet av denne artikkelen. Men når de tre spørsmålene besvares, spiller to primære faktorer inn i dommen: hastighet og nøyaktighet. I tilfelle av webutvikleren er hurtig samspillutvikling en måte å bevise at du har tatt håndverket av samspillutvikling veldig alvorlig.
Raskt samspillingsutvikling faller ikke ved et tilfelle når en mus rammer (som det kan være tilfelle med en mer kunstdrevet grad). I stedet er rask vekstutvikling en ferdighet som er utviklet av utvikleren. Denne ferdigheten viser effektivitet og talent, og gir større tillit til utviklerne evne til å oppnå konsistens. For å kunne utvikle interaksjoner raskt, må utvikleren ha de to magiske ingrediensene: hastighet og nøyaktighet.
En ansvarsfraskrivelse: Det kan være at noen blir ansatt fordi, selv om de ikke er så talentfulle som andre, er de ekstremt konsekvente og har en god personlighet. Dette er på ingen måte en veiledning for hvordan man får en jobb som utvikler.
Med forståelsen av betydningen av rask samspillutvikling, kan vi nå forstå hvordan du kan umiddelbart begynne å finpusse denne ferdigheten. Noen av disse tipsene tar en enkel forandring i tankegangen, mens andre tar en investering for å lære eller endre mønster. Alle disse kan imidlertid hjelpe deg med å bli en bedre, raskere og mer verdifull webutvikler.
Har du vedtatt et CSS-rammeverk? I så fall forstår du verdien av gjenbrukbar kode. Du har mest sannsynlig tatt mønstre uten å innse det. For å bevise dette, spør deg selv, "Når jeg begynner å bygge et nettsted, hva er mitt første skritt?" Hvis svaret ditt er "Jeg vet ikke", så er det på tide å finne ut det. Hvis svaret ditt er "først åpner jeg tekstredigeringsprogrammet mitt", så har du vedtatt minst ett trinn i et mønster.
Så, hvordan optimaliserer du et mønster? Disse kalles ofte arbeidsflyter, men det er ikke en tilstrekkelig beskrivelse, da arbeidsflyt ikke inneholder alt vi vil snakke om her. Noen vanlige verktøy for å hjelpe deg med å strukturere mønsteret ditt er CSS og JS "rammer" som Twitter Bootstrap, Foundation eller Topcoat ...
... preprocessing verktøy som SASS eller mindre ...
... kanskje full optimalisering og prosessor verktøy som CodeKit ...
... starte Wordpress temaer som Bones, og til og med muligheten til å bygge tilpassede skript drevet av en kommandolinje. Hvis du er en mer avansert JavaScript-utvikler og ønsker å flytte inn i et nytt rom, bør du vurdere å se på Backbone, Ember og andre (MVC-orienterte JavaScript-rammer) [http://todomvc.com/]; Det vil også bli anbefalt å se på Node, som gir JavaScript til server-siden. Det kan ta litt tid, men å hente og lære noen av disse verktøyene øker produktiviteten i det lange løp.
Anbefaling: bestemme hva slags HTML-boilerplate / gjenbrukbart "index.html" -dokument og tilhørende filstruktur som følger allment aksepterte konvensjoner, er bygget med semantisk markering, og gir en "blank skifer" for å jobbe fra (tenk HTML5 Boilerplate). Kanskje hvis du jobber primært med Wordpress eller et annet verktøy, vil du finne en lignende boilerplate med grunnleggende funksjonalitet for det verktøyet.
Hvis du er litt mer avansert, plukke opp noen Yeoman ferdigheter for rask prosjekt stillas og veiviser-basert boilerplate generasjon. Bestem på et CSS og / eller JS-rammeverk (Bootstrap, Foundation, Topcoat), og begynn å bruke en preprosessor for CSS før heller enn senere. Å lære en preprocessor er vel verdt tiden investering, og vil ikke redusere produktiviteten som mindre og SASS kan både håndtere vanilje CSS. Prøv å bygge en full wireframe av en grunnleggende layout helt med en rammeverkets innebygde klasser. Du vil sannsynligvis bli overrasket over hvor lite kode du trenger å skrive for å gjøre en funksjonell oppsett skje veldig raskt. Dette reduserer overhead for å skrive repeterende kode og har også den ekstra fordelen av å trekke fra mye mer omfattende testing og kryss-leser hensyn enn en person kan gjøre på egenhånd.
Det er helt viktig å adoptere en livsstil for læring som utvikler. Å vedta nye verktøy og ferdigheter som de som er diskutert ovenfor, er en del av livsnerven til enhver vellykket utvikler. Teknologien vi bruker hver dag endrer seg raskere enn noe annet; For å være på eller over vår nåværende plass i bransjen, er det viktig at vi lærer kontinuerlig.
Men - Det er også like viktig å forstå det lære ny teknologi vil sakte deg ned - først. Av denne grunn bør du ikke lære et nytt rammeverk når du praktiserer rask interaksjons-iterasjon. I stedet vil du forsiktig ta litt tid ut av uken din og dedikere den til å lære det rammeverket gjennom et kjæledyrprosjekt, weekend hacknatt eller ved å implementere stykker av det nye verktøyet i et prosjekt som absolutt behov de nye funksjonene som tilbys av den løsningen. Dette vil tillate deg å opprettholde din fart, og løse problemer flytende heller enn i en stopp-go Google og StackOverflow binge. Viktigst, denne hensiktsmessige segregeringen gjør at du kan fokusere på det som betyr noe: løse designproblemer i stedet for kodebugs.
Som et sekundært notat, når du forsiktig lærer, hjelper det også med å løse problemer som allerede har kjente og veldokumenterte løsninger; selvfølgelig trenger verden ikke en annen enkelt å gjøre søknad. Men å skape et gjøremålsprogram kan hjelpe deg å forstå JavaScript mye mer, og kan hjelpe deg i fremtiden når du syntetiserer informasjon for å løse nye problemer. Byggeløsninger for problemer som allerede har godt dokumenterte løsninger hjelper deg å sammenligne og kontrastere løsningen, og gjør det lettere å søke etter hjelp når du sitter fast. Hvis du er i ukjent territorium og prøver å lære på samme tid, er det mye mer sannsynlig å gå seg vill, og vil forringe målet med læringsprosessen.
Hvis du har hørt ordet "smidig", kan du få en ide om hva en sprint er. Sprints er korte, forhåndsdefinerte arbeidsperioder hvor utviklere bestemmer seg for et sett med mål, og "sprint" for å fullføre disse målene innenfor den tildelte tiden. Fordi vi snakker om rask interaksjonsutvikling, er en sprint velegnet til denne diskusjonen. Her er det grunnleggende.
I den tradisjonelle, smidige tilnærmingen er sprints basert på å hjelpe med teamsamarbeid og varer vanligvis flere dager eller uker. Her snakker vi om selvforvaltning og hyperfokuserte mini-sprints. Disse mini-sprintene kan til og med rett og slett fokusere på en enkelt oppgave eller samhandling, og de tilhørende målene. Prosessen med å definere og prioritere oppgaven eller delene før du drar inn i arbeidet, og deretter ta tid til å reflektere over prosessen og tilpasse arbeidsflyten eller mønstrene (husk at det er viktig å optimalisere mønstrene), vil hjelpe deg å bli mer objektiv oppmerksom på din hastighet og produktivitet, og vil tillate deg å være mer bevisst på hva som kan brukes forbedring på et mikronivå.
Anbefaling: Definer to 3 timers sprints for en dag, hver med en primær oppgave. Formålet med sprinten (som med en fysisk sprint) er å kjøre hjernen din så hardt som mulig for de 3 timene. Etter de 3 timene vil du trenge en hjerneskade; kanskje dette er lunsjpause, eller kanskje du har valgt å vedta en alternativ tidsplan for å tillate en uavbrutt hyperfokusert tidsblokk (mer om det senere). Uansett, vil planlegging av disse sprintene skille fra hverandre, hjelpe deg med å lade opp hjernen din. Det er verdt å prøve helt motsatte typer aktiviteter (som å ta en tur eller lese fiksjon) eller til og med en lur - mer på det her. Hvis du jobber for et byrå, er kanskje pause i mellom den tiden du legger til side for møter, administrative oppgaver eller mindre skattleggingsutviklingsoppgaver. Noen anser dette som den beste måten å jobbe hver dag, og noen kan velge å gjøre denne typen "sprintintervalltrening" sporadisk. velg hva som ender opp med å gjøre deg mest produktive, og øker hastigheten på samhandlingsutvikling.
Hvis du er som de fleste, har fingrene muskelminnet; Når du åpner en nettleser, er det instinkt å umiddelbart skrive inn Hacker News, Tuts + eller Twitter? Hva er nettstedene som får deg til å utsette?
Hacker News har angrepet dette problemet på en bestemt måte, og tilbyr signerte brukere muligheten til å sette opp en "noprocrastinate" restriksjon. Det er noen interessante verktøy som også tilbyr slike restriksjoner, men hvorfor ikke gjør det selv? På en Mac, kjør følgende kommandoer fra terminal:
sudo nano / etc / hosts # skriv inn passordet ditt når det ber om det. # Dette vil åpne en fil i en terminalbasert kodeditor; # Ikke bekymre deg! Du vil ikke gjøre mye her inne. Skriv inn følgende linjer. 0.0.0.0 twitter.com 0.0.0.0 facebook.com # trykk Ctrl + C (exit), Y (ja jeg vil gjerne lagre), og skriv inn (lagre som eksisterende filnavn)
Du kan redigere den samme filen på Windows (se denne forklaringen).
Dette vil blokkere deg fra å bruke Twitter eller Facebook, og vil omdirigere deg til ditt lokalehost (0.0.0.0 er en snarvei til maskinen din). For å komme tilbake til sosiale nettverk, følg bare de samme trinnene, men fjern linjene du la til.
Anbefaling: Skal du blokkere Facebook og Twitter hele tiden mens du jobber? Vi sier nei. Det er fornuftig å kunne ta små pauser mellom oppgaver for å holde seg unna. Imidlertid, under en sprint, hvis disse nettstedene tilsynelatende får deg til å kaste bort tid, er det viktig (i hvert fall til du bryter den muskelminnede drevne vanen) for å sette dem på pause. Det viktige notatet her er, kontroller utsagnet ditt, selv om det betyr planleggingstid å kaste bort. Å være klar over tiden du legger inn i en gitt aktivitet, vil hjelpe deg å være mer bevisst om hvorvidt den tiden glir bort fra din kontroll.
Avbrudd har lenge vært kjent for å redusere produktiviteten til kunnskapsarbeidere. (Se her, her, her, her - og det er mye mer tilgjengelig via et raskt Google-søk.) Programmører (og derfor webdesignere) er utsatt for potensielt bare å få en uforstyrret 2 timers økt på en dag. I fleksibel metodikk er det begrepet kjernetimer som innebærer at sterkt fokus skal opprettholdes i 5 totale timer per dag. Dette er et langt hopp fra de to timene som programmene kan forvente å oppnå på et normalt kontor.
Det er mange typer forstyrrelser, men vi vil se på to konkrete aspekter av avbrudd i dag. De første er velkomne eller "selvforsynte" forstyrrelser, den andre er eksterne eller "påtrengende" forstyrrelser. Begge typer er skadelige for produktiviteten, og begge typer kan administreres noe på ulike måter.
Selvpåførte forstyrrelser oppstår fordi du på en eller annen måte har opprettet plass for dem å skje. Disse kommer vanligvis i form av programmerbare varsler (telefon, datamaskin osv.).
Intrusive avbrudd oppstår fordi andre mennesker trenger deg til å ta hensyn til dem. Frakoblingen er timing og følelse av haster. Du må styre din egen tid, og du må sette på plass måter å omgå de negative effektene av avbrudd så mye som mulig.
Så hva gjør du for å lindre avbrudd? Hvordan oppnår du Zen Zone Time? Her er noen av våre anbefalinger.
Hva gjør "hackathon" hendelser så produktive? Hvordan slår folk ut levedyktige produkter i løpet av 48 timer? Kanskje det er en blanding av egenskaper.
1. Forventet, beskyttet, planlagt tid for fokusert rask utvikling
2. Konkurranse med andre
3. Kontantbelønninger
Hackathons break fra "normal flyt" av hver dag arbeid. Sikkert, vi vil ikke jobbe 48 timer på rad hele tiden. Men produktivitetsinnsatsen som oppstår av dette, er ekstremt viktig. Vi har allerede påpekt hvor viktig fokus og uavbrutt tid er. Det er imidlertid en verdig innsats å vurdere hvordan å skape noen personlige konkurranse- og belønningssystemer kan bidra til å øke effektiviteten i utviklingen. Dette hjelper til med å sette benchmarks og naturlig trener hjernen din for å tilpasse seg atferdene som er givende.
Anbefaling: Hvis du jobber med en annen utvikler, bestem deg for en konkurranse med klare mål, og gjør det tidsorientert. Spiller ingen rolle hva disse målene er. Ta deg tid til å jobbe gjennom dem. Kanskje du kan konkurrere mot deg selv; trene ved å bruke sprints som konkurranse, og sett målene dine til øke effektiviteten din med litt tid. Sett belønninger opp både for når du er i en konkurransedyktig modus, samt for når du fullfører en fokusert sprint av arbeid. Dette vil bidra til å holde deg fokusert under sprinten selv. En belønning kan være en fysisk ting (som en kopp kaffe) eller noe mindre betong (som en VIP-parkeringsplass i en uke eller "fritid").
Vi vil holde dette tipset kort, fordi fordelene her vil være åpenbare. Open Source World er full av fantastiske og talentfulle mennesker som bygger ting som hjelper andre med å gjøre jobben sin bedre hver dag. Eksempler som rammene vi nevnte ovenfor bare knapt skrape overflaten. Her er noen av fordelene ved å jobbe og kommunisere med open source-fellesskapet.
Dykking i open source-samfunnet og læring å bruke verktøy som tilbys kan umiddelbart øke produktiviteten, men gjør det også mye mer sannsynlig at en annen person kan hente prosjektet og fortsette å utvikle seg på det prosjektet. Open Source gjør det mulig for folk å samarbeide rundt en bestemt standard og eksisterende dokumentasjon. Dette reduserer kognitive overhead for overføring av prosjekter, og gjør deg til en mye mer litteratør utvikler; dette oversetter umiddelbart til høyere effektivitet.
Anbefaling: Få en GitHub-konto, og start å bygge ting med verktøy som er tilgjengelige på GitHub.
Dette er noe av en gjentagelse av det vi sa tidligere - bruk åpen kildekodeverk for å løse problemer på forutsigbare, mønstrede måter, og delta i fellesskapet til andre som gjør det. Samarbeid og diskusjon er svært viktige nøkler til læring.
Dette er på ingen måte en komplett liste over ting du kan gjøre for å bli en rask samhandlingsutvikler. Legg igjen noen notater i kommentarene til ting du har prøvd som har jobbet, mislyktes, eller har hatt liten eller ingen effekt!
Accentsconagua