7 Ferdigheter for IT Fame and Fortune

Webapplikasjonsdesign:

Jeg har en lidenskap for god produktdesign og folk som vet hvordan man gjør dette veldig bra. Å designe en flott webapplikasjon er svært forskjellig fra å designe et flott nettsted. De kunne ikke være mer annerledes i boken min. De fleste brukergrensesnittdesignere må kunne jobbe under utfordrende omstendigheter. De fleste rundt dem vil ikke forstå hva de gjør, hvordan de gjør det, når de skal hentes, hvilke opplysninger og ressurser de trenger, og hvor mye jobber det tar for å skape ikke bare et brukbart brukergrensesnitt, men også en nyttig. Du må være en ressursfull person, noen som kan sette seg inn i samtalene mellom arkitekter, utviklere, brukere, QA, test, produktstyring og alle andre der ute som tror de kan designe et bedre UI-musefelt. UI-design er som NFL-fotball: Alle kan gjenkjenne et godt spill når de ser det, men svært få kan faktisk spille spillet. Og vi har alle en mening om det. En av de beste kritikkene jeg mottok fra en kunde som så på produktet mitt, var: "Dette brukergrensesnittet ser ut som en utvikler designet det." Det ganske mye sa alt om hva de trodde om brukervennligheten av den applikasjonen. Nå, hvis du er en utvikler som tror du kan ha et øye for UI-design, kan det være en ganske fornærmende uttalelse fra en kunde. Kanskje du er en utvikler som er en god, anstendig eller tilstrekkelig UI-designer, men du er langt det sjeldne unntaket. Hvis du tror UI-design er enkelt og ikke forstår hva alt oppstyret handler om, trenger du definitivt hjelp fra en UI-designer.

Hvis du ønsker å utvide dine ferdigheter som en UI-designer, kan du søke etter brukergrupper i informasjonsdesign, bygge opp noen menneskelige faktorer, lære å planlegge og utføre brukerintervjuer, utvikle brukerpersoner og utføre veldesignede produkttestinger med brukere. Viktigst er å begynne med å vite hvem brukerne er for programvaren du bygger. Det er utrolig hvor ofte svært lite er kjent om den sanne brukeren av et produkt eller IT-system.

Webapputvikling:

Hvis du skriver programmer som er avhengige av en tung eller installert klient, må jeg tro på deg ' re sannsynligvis ikke i forkant av hvor applikasjonsutvikling er på vei. Webapplikasjoner er hvor programvaren er på vei, med et dash av SaaS og PaaS (platform-as-a-service) for å starte opp. Levering av applikasjoner via nettleseren er hvor den mest interessante applikasjonsutviklingen skjer, enten det er med ASP.NET-applikasjoner, Sharepoint-portalapplikasjoner, LAMP (Linux Apache MySQL PHP), Java eller Ruby on Rails. Legg til de mulighetene som tilbys av PaaS-leverandører, for eksempel Amazon, Salesforce / Force.com og Google, og ting blir ganske interessante. Webgrensesnitt i applikasjoner kan være en morsom ting. Er webgrensesnittet noe som er plopped på toppen av et godt designet program? Gjør Web UI design resten av applikasjonsdesignet? Hva er designet først, back-end eller front-end brukergrensesnitt? Vel, det er sannsynligvis en blanding av begge, med en svært betydelig drivende faktor. 7 Vaner produktivitetsguru Steven Covey sier, "Start med slutten i tankene." Slags ideen om at du ikke kan gå seg vill hvis du ikke vet hvor du skal. Jeg har tilpasset Coveys ordtak:

Start med sluttbrukeren i tankene. Å skape den effektive balansen mellom front-end og back-end design i et webprogram, er en kunstig ferdighet som blir verdsatt av de webapputviklerne som har oppdaget, ikke bare hvordan man finner det balansere, men også hjelpe andre i teamet å se, sette pris på og verdsette det. Antall webappsene vi skal skape i månedene og årene som kommer kommer bare til å øke. Lag og tekniske ledere som kan gjøre det bra, er verdt deres vekt i gull. Gjør det bra, og du vil ha ditt valg av prosjekter og bedrifter til å jobbe med.

Virtualiseringstangivelse:

Jeg snakket akkurat med andre kolleger om de økonomiske driverne bak virtualisering. Det er et par måter jeg liker å demonstrere dette, og det første jeg vil si er; Virtualisering er CFOs beste venn (Jeg snakket om dette på podcasten en stund tilbake.) Den andre tingen jeg sier er: Det er tre typer CFOer: de som spør IT hvordan virtualisering kan spare penger, de som har blitt vist av IT, hvordan virtualisering kan spare penger, og til slutt, de som ser etter deres neste IT-leder. Ønsker du å score poeng med virksomheten? Gjør store fremskritt i maskinvare-, datasenter, programvare og fasiliteter besparelser ved å utnytte virtualisering overalt, du kan. Det er ikke alltid ledig, spesielt for å få styringsfunksjonene du trenger for å distribuere virtualisering i en hvilken som helst skala, men de harde kostnadsbesparelsene over bare de vanlige maskinvarekjøpene bør enkelt begrunne programvarekostnadene på et konsolideringsavkastning. Nå tar du det neste nivået, og viser hvordan du kan få lastbalanse, failover, katastrofeoppretting og andre evner gjennom virtualisering, og CFO vil gjøre deg til en æres

Holder of the Golden Spreadsheet ved neste Green Visor regnskapskonvensjon. Virtualisering er ikke bare for datasenteret. Som en applikasjonsutvikler planlegger du hvordan du kan utnytte virtualisering i applikasjonsarkitektur, distribusjonsalternativer, enhetstesting og QA-testing. Virtualisering gir en god sandkasse når du tester designideer, simulerer nettverks- og serverkonfigurasjoner, og laster opp et stort antall simulerte sluttbrukermaskiner. QA-fordelene alene gjør like tvingende argument for virtualiseringens kostnadsbesparelser som det gjør i datasenteret. Hvis QA og laboratoriemiljøene dine blir større i stedet for mindre, gjør du noe galt.

Hvis du leter etter et sted å begynne å synke tennene i virtualisering, kan du laste ned de gratis versjonene for Hyper-V, Xen, og VMware. Du vil raskt se behovet for ekstra styringsfunksjoner, men de gratis tingene er gode å begynne med.

SaaS multi-leietaker og skalerbarhet:

SaaS er hvor det handler om, uansett om du snakker om bedriftens on-demand applikasjoner eller produkter og tjenester levert på nettet. Det er en av de hotteste områdene i vår bransje akkurat nå. Men SaaS bringer noen nye utfordringer som ikke tidligere ble møtt, noe som førte til mangel på ferdigheter på nye områder. Det mest sannsynlige er det som er referert til som multi-tenant: muligheten til å fullt ut støtte flere kunder (bedrifter) innenfor en nettbasert online applikasjon. Hva er den store avtalen, sier du? Vi støtter allerede komplekse organisasjonsstrukturer i våre applikasjoner? Vel, husk at du sannsynligvis gjør dette innen ett foretak, eller SME / SBM. Forestill deg nå de komplekse kravene til hundrevis eller tusenvis av selskaper. Eller hvis tjenesten din blir solgt til enkeltpersoner, handler det om å håndtere disse kravene til tusenvis av små kunder. Multi-leietaker betyr også at alle konfigurasjonsalternativer kan byttes av brukeren. Det er ingen systemstandarder som fungerer for alle brukere fordi vi ikke er alle en stor, lykkelig bedriftsklasse. Mange flere konfigurasjonsalternativer må utsettes for at brukerne skal kunne tilpasse seg for å oppfylle sine egne individuelle eller organisatoriske behov. Den tredje utfordringen jeg ser i multi-tenant miljøer er skalerbarhet. Imaging du kjører alle de kundene på programvaren din. Den samme databasen, klyngedesign, transaksjonsadministrasjonsdesign (for å nevne noen få problemer) fungerer kanskje ikke i omfanget av en SaaS-tjeneste.

Hvis du forstår disse problemene og bedre ennå, har løst dem i en distribuert SaaS-applikasjon, er du blant de elite få. Selv om du ikke har gjort det som en SaaS-applikasjon, er de samme system- og programvarearkitekturferdighetene og opplevelsene grunnlaget for å bygge fra å flytte inn i SaaS-miljøet. Hvis din neste generasjon applikasjoner er webapplikasjoner og kan inkludere en SaaS-komponent (eller vil være fullstendig SaaS), er det nå på tide å finpusse disse ferdighetene og la andre få vite at du har dem. Det vil gjøre deg så mye mer verdifullt.

Skrive sikker kode:

Hver utvikler skriver kode, men ikke alle utviklere skriver sikker kode. Selv om det ikke er en ferdighet, forstår mange ledere (eller andre, for det saks skyld), utviklere som ikke bare kan skrive sikker kode, men også veileder og lærer andre utviklere hvordan man oppretter sikker kode kan være et uvurderlig lagmedlem. Skrive sikker kode er mer enn bare å bekymre seg for obskure buffer-overflow-angrep eller raseforhold. Du har tydeligvis sett nå mitt tema at flere og flere applikasjoner er webapps, og i økende grad blir de også i SaaS-applikasjoner i mange tilfeller. Webangrep er i forkant av risikoer der gode, sikre programvareutviklingspraksis må brukes. SQL-injeksjon, krypteringsskripting, magiske nettadresser og skjulte skjemaer, datalekkasjeforebygging, sikring av webtjenester og dårlige implementeringer av SSL er alle eksempler på sikkerhetsproblemer som programvareutvikling må vurdere og imøtekomme når du skriver sikker kode.

Hvis du Jeg leter etter gode ressurser for å komme i gang nedover veien for å skape sikker kode, jeg vil anbefale to bøker 19 Deadly Sins of Software Security av O'Neill, Howard, LeBlanc og Viega, og Web Services Security.

QA-automatisering og beregninger:

Hvis du er en QA-person, har du et spesielt sted i mitt hjerte. Hvis du er en QA-person som lever for å automatisere QA-testing, fanger opp beregninger og bruker dataene for å forbedre programvareutvikling og QA-praksis, så har du et spesielt sted i himmelen! Som du kan fortelle legger jeg stor vekt på QA-ferdigheter av høy kvalitet, spesielt de dyktige utøvere som ikke bare finner alle de ekle programvarene før noen programvare kommer ut døren, men vet også hvordan man skal automatisere testing og bruke kunnskap som er oppnådd for å forbedre hvordan programvare opprettes i prosessen. Programvareutviklere kan være ledende sangere og gitarister i bandet, men som noen erfarne musiker vet, er det trommer og bass som gjør eller ødelegger bandet. Jeg liker å si; elsker utviklere, og stol på QA. (Egentlig, jeg elsker QA-folk også.) Vil du gjøre deg uunnværlig som en QA-person? Automatiser, automatiser, automatiser. De beste prosjektene jeg har jobbet med, hadde tester automatisert godt inn i over 90%, og tester ble kjørt hundrevis og hundrevis av ganger før programvaren ble levert. Nå, det er det jeg kaller regresjonstesting! Ny funksjonalitet kan testes manuelt, men tester ble alltid automatisert før design ble gjort på neste programvareutgivelse. Det handler om den eneste måten CTOs og ingeniørvitenskapsskapere noensinne kan få søvn. Nå, ta det ett skritt videre og gi dine kolleger, tekniske ledere og ledelse med learnings og innsikt du får fra alle de testene, og du vil nå nirvana status i boken min. Kunnskapen som finnes i alle disse testresultatene kan ta selv de beste utviklingsorganisasjonene til nye høyder.

CERTS, alle velkommen:

Jeg liker å si; Du kan aldri gå galt med CERTS. Det gjelder både pustemynter og tekniske sertifiseringer. Alle liker å argumentere for verdien av sertifiseringer: om A + -sertifiseringen er verdsatt; hvis det er verdt å få en MCTS vs å gå for full MCSE; hvis å ha en cissps bærer den samme vekten det en gang gjorde; og hvor mye ledere verdsetter noen sertifiseringer over arbeidserfaring. Men på slutten av dagen, kan det gjøre forskjellen mellom at du får jobben over den andre endelige kandidaten. Å få den sertifiseringen sikkert, kommer ikke til skade! CERTS viser at du har oppnådd noe som viser at du har noe ferdighetsnivå, og det har blitt demonstrert ved å oppfylle kvalifikasjonene til sertifiseringen. De trenger ikke nødvendigvis å la deg fly flyet, men du kan få et bedre skudd når du setter deg på plass med en IT-organisasjon. Du vil helst heller være for verdifull å miste enn utgifter når de økonomiske tider er tøffe.

Hvis du vil lære mer om Microsoft-sertifiseringer, kan du gå til læringsdelen av Microsofts nettsted for sertifiseringer. Jeg vil også anbefale noen sertifiseringsopplæringsbøker fra Microsoft Press, for eksempel Windows Server Administration Training Kit av McLean, Konfigurer Windows Vista Client Training Kit av McLean og Internet Information Services (IIS) 7.0 Resource Kit av Volodarsky.