1. Dec 04

    Ti ting webutviklere må gjøre for deres kunder

    Tanker 0 kommentarer »

    Når jeg surfer på nettet kommer jeg ofte over mye genial skriving og gode poeng. I går kom jeg blant annet over en god artikkel på WsG. Det er en liste over det som de mener webutviklere må gjøre for kundene sine. Jeg var veldig enig i mye av det de skriver, så jeg bestemte meg for å lage en egen liste. Mye vil være likt, men også noe som jeg mener burde gå fremfor andre emner.

    1. Stå til hjelp med det kunden lurer på

    Det er ofte slik at du også bestiller webhotell til kundene dine. Da er det viktig at du øker servicen din til å hjelpe de med problemer som kan oppstå i senere tid. Er det problemer med e-posten eller opplasting av filer? Bruk din erfaring til å hjelpe. Du burde også fungere som en buffer mellom webhost og kunde, selv om dette kan virke som noe som går utenfor din arbeidsoppgave som webutvikler.

    2. Lag komplett error-reporting

    I tillegg til god error-visning for applikasjonene du lager burde du ta forbehold for serverfeil. Dette gjør du som regel med .htaccess filen din. Lag feilmeldinger for error 404, 403 og andre tenkelige feilmeldinger. En god feilmeldingsside er mer kompakt enn en vanlig startside og inneholder link til fremsiden, sitemap og gjerne et søkeskjema. I tillegg er det lurt å ha en ydmyk tekst som ikke initierer at brukeren er en amatør som går inn på feil side. Kom med forslag til hvilken side de er ute etter og muligens legg til et alternativ for rapportering. Les mer om dette på ALAs artikkel Perfect 404.

    Bruk følgende i .htaccess for egne error-sider:

    # Error documents
    ErrorDocument 404 /php/error404.php
    ErrorDocument 403 /php/error403.php

    3. Legg sidene deres i søkemotorer om ønsket

    Sidene vil bli crawlet etterhvert, men desto tidligere desto bedre. Derfor burde du som utvikler legge sidene til kunden inn i de største søkemotorene som finnes der ute. Det skader heller ikke å linke fra bedriftssiden din til kundens side i en portefølje som gjør at kundens nye side vil øke i Googles PageRank. Å la siden du lager bli sett er en stor del av webutviklingen. Det holder ikke bare å lage en side så lenge den ikke blir brukt og oppdaget.

    4. Sperr mapper for direkte adgang

    Ikke la besøkende til kundens sider kunne snoke rundt omkring i stil- og bilde-mapper. Dette vil si at du slår av indeksering på mapper uten egen indeksfil. Dette gjøres med følgende:

    DirectoryIndex index.php
    Options -Indexes

    5. Installer favicon og bruk korrekt header-informasjon

    Installer et favicon som er passende til designet på siden. Dette er for å ha et kjennetegn i eventuelle bookmarks og for å unngå en konstant error 404 melding i loggen på hosten. Dette vil føre til tidstap, når den leter etter en fil som ikke finnes. Du burde også ha korrekt header-informasjon til siden. Dette vil si en god tittel, copyright-beskjed, forfatter, beskrivelse, nøkkelord, charset og annet elimentær informasjon. Dette er for å sende ut mest mulig informasjon til nettleser og robots/crawlere.

    6. Viderefør siden fra med www. til uten www.

    Dette er for å samle antall besøkende og PageRank til en side. Les mer om dette på no-www.org.

    7. Hold struktur i og kommenter kodene dine

    Denne er veldig viktig til tross for at den er nr. 7. Den er nr. 7 for den er såpass selvsigende at det ikke en gang burde ha vært nødvendig å nevnt. Likevell kommer det. Hold orden i kodene dine og kommentér på engelsk. Jeg har tidligere skrevet om viktigheten i dette. Det er ikke sikkert kunden kommer til å ha deg som sin utvikler hele tiden og det burde da være mulig for overtagere å forstå hva det er som har foregått inne i filene til kunden. Du kan lese om kodestruktur i PHP i artiklen min Kodestruktur, men dette gjelder også i HTML og CSS. Ha struktur og bruk indentering.

    8. Ha en høffelig tone ved kommunikasjon

    Er du som meg kan du til tider bli mildt sagt lei av kunden din. Mange kunder er vanskelig å ha med å gjøre på grunn av manglen av innsikt og kunnskap. Men det gjør de ikke til noe mindre verdige kunder. Du skal ikke forvente at kunden din har peiling på dét du gjør. Det er en grunn til at kunden har leid deg inn til å gjøre jobben. Derfor er det viktig at du holder en fin, høffelig profesjonell tone ovenfor kunden. Du har hørt ordsagnet “Kunden har alltid rett”. Det er noe du må huske på. Selv om du burde assistere med idéer som kan være alternative for å oppnå kundens mål. Selv om kunden har rett er du eksperten på emnet og burde bruke de kunnskapene og erfaringene du har gjort deg innenfor faget.

    9. Følg dagens webstandard og valider sidene dine

    Velg deg et språk og hold deg til det. Når du er ferdig med siden så passer du på at den følger standarden til den HTML du bruker. Du validerer hele siden ikke bare fremsiden. WsD hadde en god link som går igjennom alle filene i hiarkiet rekursivt. Den finner du under . Du trenger ikke å skrive “Valid CSS” og “Valid XHTML 1.0 Strict” på siden, da det skal være en selvfølge til kundens sider. (Paradoksalt at jeg har det på bloggen? Personlig valg).

    10. Lag robots.txt-fil til siden

    Siste punktet er ganske trivielt. Du burde lage en robots-fil til siden deres. Selv om den er tom så gjør det ingenting. Du unngår error 404-meldinger fra å samle seg opp i webloggen og sparer tid på det. Også kan det hende at du vil sperre enkelte roboter til å crawle siden.

    Til slutt vil jeg gjerne sitere noe som står på WcG:

    • Help them by getting it right from the start.
    • You’re the expert so you should know about and be doing this stuff.
    • Don’t wait until they ask for things that should already have been done correctly.

    Det var mine 10 tips. Kom gjerne med tilbakemelding på hva som kunne ha vært bedre.

    \\ emneord:

  2. Dec 04

    Anbefalt lesing: What are web standards and why should I use them?

    Generelt 0 kommentarer »

    Det har vært lite aktivitet fra meg de siste ukene. Jeg har vært utslitt og har hatt vondt i alle muskler. Russetiden går hardt utover helsen. Men nå er den tiden forbi, og er kun et minne til fremtiden. Nå har jeg bedre tid igjen, til å skrive mer på denne siden, og prøve å gjeneurobre lesere, som sikkert har synket så drastisk at jeg ikke en gang tør å tenke på det. Men det er vel slik som skjer, når russetiden kommer. Prioriteringslisten endrer seg.

    Som første post, etter pausen min, vil jeg anbefale noe lesestoff for de som er i tvil om hva webstandarder er, og hvorfor det er så sabla viktig. Denne lenken fører deg videre til Webstandards.org, som ofte kommer med gode poster til de som engasjerer seg for semantikk og webstandarder. Noen poster kan man kanskje styre unna, da de blir litt for tekniske for de fleste.

    Men dette er altså en artikkel jeg anbefaler alle som driver med nettutvikling å lese: What are web standards and why should I use them?

    \\ emneord: , , ,

  3. Dec 04

    4 nye semantiske tips

    Markup 0 kommentarer »

    Etter at jeg postet forrige post, tenkte jeg at jeg skal gjøre dette så ofte jeg kan, og lage en serie av artikler som jobber for å forbedre semantikken i dokumenter og sider over hele nettet. I alle fall til leserne av denne bloggen.

    1. Bruk ol til å markere kommentarfeltene dine. Det vil bli logisk oppbygd med tanke på at det er en kronologisk oppbygging av det. Først har du navn, så url/hjemmeside og e-post, deretter kommer det hovedsteget kommentaren. Rekkefølgen kan selvfølgelig være anderledes, men det var bare et eksempel. Du skal selvfølgelig i tillegg bruke fieldset/label og alle andre semantiske oppbygginger for form. Dette med å bruke en ordnet liste, er generelt for alle form, ikke bare for kommentar felt. Også registrering, søk, nyhetsscript osv.
    2. Snakker du om kode, kan du bruke var til å definere variabelnavn. Det gir brukeren informasjon om at det virkelig er et variabelnavn. Eksempel: <var>my_variable</var>. Også her kan du bruke lang-attributten, som snakket om forrige post.
    3. Bruk kbd til å definere tastatur-knapp/kombinasjon. Skriver du en guide til hvordan du kan gjøre en ting med hurtigtaster, kan du vise brukeren at dette er tastaturknapper du snakker om ved å bruke kbd-tagen. Eksempel på bruk er <kbd>SHIFT + ALT + V</kbd>.
    4. Bruk dfn til å definere en definisjon/uttrykk/et term. Om man kommer med ukjente uttrykk som ikke er en del av dagligdags tale, også gjerne kjent som faguttrykk kan man bruke dfn-elementet til å vise dette til brukeren. Eksempel på bruk er <dfn lang="en">object orientert programmering</dfn>

    Det var dagens semantiske tips, med noen kanskje ukjente elementer. Husk at du kan bruke standard attributter på disse.

    \\ emneord: , ,

  4. Dec 04

    4 semantiske tips

    Markup 0 kommentarer »

    Her kommer en kjapp liste over 4 semantiske tips som du kan fundere litt over og kanskje vurdere å bruke i dine sider, for å maksimere tilgjengeligheten. Dette er kanskje litt inspirert av Photoshop TVs “One for the Road”, der de gir tips på slutten av programmet som seerne burde sjekke ut.

    1. Definer sidespråk til eksterne lenker. Dette gjøres via attributten til a, som heter hreflang. Der definerer du språket til siden du lenker til ved å gjøre f.eks: <a href="http://site.no" title="Sidetittel" hreflang="no">Side</a>.
    2. Definer språk i paragrafene dine. Også slik at brukeren skal få informasjon om hvilket språk dette står på. Dette gjøres med attributten lang, og du kan blant annet bruke den på paragraf-elementet. Eksempel: lang="no".
    3. Bruk rel til å definere hva en link er. Om du lenker mellom sidene dine i en hel nettside kan du bruke rel til å si til nettleseren hva denne siden er for deg. Det er et nøkkelord, som kan gruppere forskjellige linker og si hva som hører sammen. Har du f.eks en “kontakt meg”-side kan du bruke rel="contact".
    4. Bruk rev til å definere hva lenkesiden er i forhold til nåværende side. Det vil si det motsatte av rel, og om du da er inne på “Kontakt meg” siden, og linker tilbake til fremsiden, kan du bruke rev="contact" for å vise at du er inne på kontaktsiden til hovedsiden din.

    Det var 4 kjappe (kanskje litt vell kjappe) tips, til hvordan du kan forbedre tilgjengeligheten/semantikken i dine sider!

    \\ emneord: , ,

  5. Dec 04

    Hvordan debugge et PHP-dokument

    PHP 0 kommentarer »

    Debugging kan være en plagsom ting. Frustrere deg godt og du kan tro all håp er ute. Du kan til slutt tro at det er ingenting feil med kodene dine, for du har gått igjennom alt. Her kommer en liten innføring i hvordan du kan debugge selv. Slik at mange unødvendige spørsmål kommer opp i PHP-forumet på NWF. Listen er satt opp etter hva du burde gjøre kronologisk. Start med punkt én, og jobb deg nedover listen.

    Det er store sjanser for at du løser problemet lenge før du i det hele tatt kommer nedover på listen. De fleste problemer blir løst på punkt 3 av listen.

    1. Les feilmeldingen nøye. Det er en grunn til at feilmeldingene kommer og de er faktisk ganske opplysende. Om det er noe du ikke skjønner i feilmeldingen, som hva T_VARIABLE er, burde du ta et kjapt på T_VARIABLE i google.
    2. Du får oppgitt linjenummer hvor det feiler i en feilmelding. Linjenummeret er veldig essensielt. Du går til linjen og sjekker hva som er galt. Noen ganger når det er PARSE-ERROR lønner det seg å se på linjen før det feilmeldingen sier. Dette kan være tegn som er glemt på linjen ovenfor, som å glemme å avslutte et if-statment, eller du har glemt å avslutte linjen med semikolon.
    3. Har du med MySQL og gjøre vil ikke MySQL feilene komme på lik linje som PHP-feil. Du vil bare ikke få noe resultat ut, og alt kan tyde på at det ikke er innhold i databasen/tabellen din. Er du sikker på at du har innhold med de kriteriene du er ute etter, må du printe ut mysql_error () for å finne ut hvilken feilmelding det er MySQL kommer med. Dette kan du gjøre på mange måter, men den mest brukte er som regel å legge til “or die (mysql_error());” etter siste ) i mysql_query eller tilsvarende som returnerer bool (returnere bool betyr enten sant eller ikke sant. (true|false)). Annen måte du kan gjøre det på er: 
      1
2
3
4
5

      $query = mysql_query ("SELECT id FROM table");
if(!$query) {
   echo "En feilmelding i spørringen:\n";
   echo mysql_error();
}

      Har du problemer med å løse det som står i feilmeldingen, bruker du manualen til MySQL for å sjekke hva enkelte ting støtter, og hvordan det skal gjøres. Eventuelt tar du å kopierer feilmeldingen inn i google og søker etter lignende saker. Da finner du garantert ut hva som kan løse saken.

    4. Inneholder arrayen/objektet/variabelen det du vil den skal inneholde? Får du helt feil resultat ut på siden din, bruker du var_dump/print_r på objekt/arrays, mens echo/die på variabler, for å sjekke om de inneholder det de skal. Om de ikke gjør det bruker du punkt 5 til å finne hvor det blir feil, og hva det er som virkelig skjer.
    5. Finn ut hvor det feiler! Om du ikke får ut noen feilmelding av noe slag, men du kommer bare ikke frem til dit du vil komme frem betyr det at en if-sjekk slår inn der du ikke vil den skal slå inn. En funksjon returnerer noe feil. Da må du finne ut hvor dette skjer. I hvilken brakke er det nettleseren kommer til? Slik finner du ut hvor det feiler, og dermed hva som er feil. Ta utgangspunkt i der du forventet at du skal komme og sett f.eks die (‘Kom inn hit’); i det ytterste leddet. Kommer den dit? Nei? Da går du inn et nivå, og sjekker om den kommer inn dit. Slik jobber du deg innover for å ekskludere plasser hvor det feiler. Til slutt vil du komme til der den kommer inn. Du finner f.eks ut at det er en funksjon som returnerer false i stedet for true som du ville den skulle gjøre. Er det en selvdeklarert funksjon går du inn på funksjonen for å bruke samme metode for å komme inn til der den faktisk returnerer false.
    6. Siste punkt, er det i alle fall ikke ofte jeg kommer frem til når jeg har brukt metodene ovenfor. Uansett er siste punkt veldig enkelt. Det er nesten garantert at dette punktet vil løse opp problemet ditt også: Just Fucking Google it!

    Eksempel på debug

    Jeg har et nyhetsscript. Når jeg prøver å legge inn informasjon fra form der, vil det aldri bli satt inn noen verdier i tabellen min i databasen. Ingenting kommer. Jeg får ingen feilmelding, men det kommer bare ingenting. Derfor hopper jeg over punkt 1 og punkt 2, siden det ikke er noen feilmelding i PHP. Da kommer jeg rett på punkt 3, som er å se på mysql_error. Jeg legger til som eksemplet ovenfor, og finner at det er for $_POST-verdiene mine ikke får noe som helst slags verdi. Merkelig tenkte jeg. Så jeg går videre til punkt 4, som sier at jeg skal sjekke hva er det $_POST-arrayen inneholder. Så jeg tar en die (print_r($_POST));. Der finner jeg følgende:

    Array (
    [title] => Hei du kåre,
    [message] => Min tekst nedover her
    )

    Da ser jeg va nøkkel-verdiene er på $_POST arrayen. Og finner ut hva jeg gjør feil. Jeg har heletiden brukt $_POST['tittel'] og $_POST['melding'] i stedet for $_POST['title'] og $_POST['message'].

    Slik kan du bruke listen. Og som sagt er det veldig sjeldent at du i det heletatt kommer ned til å måtte google feilen.

    \\ emneord: ,

« Tidligere poster Nyere poster »
Andre bloggere: