Hvem glor - din bror http://dinbror.dk/blog Den ikke-så-personlige blog af Bjørn Klinggaard Tue, 31 Aug 2010 17:42:04 +0000 http://wordpress.org/?v=2.8.6 en hourly 1 bPopup http://dinbror.dk/blog/bpopup/ http://dinbror.dk/blog/bpopup/#comments Wed, 14 Jul 2010 11:00:08 +0000 dinbror http://dinbror.dk/blog/?p=390 bPopup is a learning and exploring jQuery project. It’s a lightweight cross browser jQuery popup plugin. It’s not creating your popup but doing all the logic as opening, closing, centering on resize & scroll, creating a modal overlay etc. It can open any container you create with all kinds of content.
bPopup has been tested in IE6-8, FF2-3.6, Opera 9-10, Safari 4-5 and Chrome 4-5.

DEMODownload

Contents

  1. Usage
  2. Options (API)
  3. Changelist
  4. What can you do?
  5. Downloads

Usage

This is a really simplified example. For using bPopup I recommend that you’re familiar with HTML and CSS.

Scripts to include:

<script type="text/javascript" src="
   http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<script type="text/javascript" src="jquery.bpopup-0.3.6.min.js"></script>

HTML:

<html>
  <head> HeadContent ... </head>
  <body>
    BodyContent
    ...
    <a id="click" href="some url">Click here</a>
    <div id="div_to_popup">Content of Popup</div>
  </body>
</html>

CSS:

#div_to_popup {display:none;}

The magic:

$(document).ready(function(){
   $("a#click").bind('click', function(){
      $("#div_to_popup").openPopup();
      return false
   }); 
});

Or with custom settings

$(document).ready(function(){
   $("a#click").bind('click', function(){
      $("#div_to_popup").openPopup({appendTo:'form', zIndex: 2});
   });
});

Enjoy

Options

API – name [type] (default value)
amsl [int] (150) Above Mean Sea Level. Vertical distance from the middle of the window, + = above, – = under.
appendTo [string] (’body’) Element to append popup (and modal overlay) to. For asp.net sites append to ‘form’.
closeClass [string] (’bClose’) Class to bind the close event to. Version 0.3.3
duration [int/string] (’normal’) Animation speed. Removed in version 0.3.6
escClose [boolean] (true) Should popup close when press on escape?
fadeSpeed [int/string] (250) Animation speed on fadeIn/out. Version 0.3.6
follow [boolean] (true) Should the popup follow the screen on scroll/resize? Version 0.3.6
followSpeed [int/string] (500) Animation speed for the popup on scroll/resize. Version 0.3.6
loadUrl [string] (null) External page or selection to load in popup.  Version 0.3.4
minTop [int] (20) Minimum distance from top to popup. Removed in version 0.3.6
modal [boolean] (true) Should there be a modal overlay behind the popup?
modalColor [string] (’#000′) Which color should the overlay be? Version 0.3.5
opacity [float] (0.5) Transparency, from 0.1 to 1.0 (filled). Version 0.3.3
scrollBar [boolean] (true) Should scrollbar be visible?
vStart [int] (null) Vertical start position for popup. Version 0.3.6
xLink [boolean] (false) Is the popup a xlink popup? Version 0.3.4
zIndex [int] (9999) Popup z-index, modal overlay = popup z-index – 1.

Changelist

0.3.6 changelist:

  • New options: fadeSpeed, follow, followSpeed, vStart
  • Deleted: duration, minTop
  • Included position:absolute styling on popup in plugin

0.3.5 changelist:

  • New option: modalColor
  • bPopup can now take callback functions

0.3.4 changelist:

  • New option: loadUrl
  • The popup can now open an url inside the popup
  • Implemented x-link feature
  • Refactored code, created private help functions
  • Changed default value for scrollBar to true

0.3.3 changelist:

  • New options: opacity, closeClass
  • Changed modal overlay to position fixed in supported browsers. Non position fixed supported browsers still uses position absolute.
  • Added default close event
  • Fixed issue with overlay in IE6+7 and body positioned relative with a width

0.3.2 changelist:

  • Modal overlay width miscalculation on resize.
  • Auto textfield focus
  • Resetting textfields before showing popup

0.3.1 changelist:

  • New options: escClose, zIndex and minTop.
  • Fixed bug with modal overlay when body has position: relative and a width. Now calculates the distance from the left to the body.

0.3.0 changelist:

  • Unbind events on close.
  • Centering popup on resize.
  • Centering popup on horizontal scroll.
  • Refactor code.

What can you do?

  • Report bugs
  • Help optimizing code
  • Give suggestions

Downloads

v 0.3.6 developer
v 0.3.6 minified
v 0.3.6 custom
v 0.3.5 developer
v 0.3.5 minified
v 0.3.5 custom

]]> http://dinbror.dk/blog/bpopup/feed/ 39 ASP.NET Ajax asynkront postback jQuery problem http://dinbror.dk/blog/asp-net-ajax-asynkront-postback-jquery-problem/ http://dinbror.dk/blog/asp-net-ajax-asynkront-postback-jquery-problem/#comments Mon, 19 Apr 2010 19:04:08 +0000 dinbror http://dinbror.dk/blog/?p=379 Problem: $(document).ready() bliver normalt kaldt, når DOM er klar til at blive manipuleret, men det sker ikke efter, at et UpdatePanel renderer efter et asynkront postback. Det resulterer i, at man mister funktionaliteten, som der skulle være afviklet i $(document).ready().

Løsning: Der findes adskillige work-a-rounds, men fra og med jQuery 1.3 tager jQuery selv hånd om sagen og stiller eventen live() til rådighed. Live() sørger for at dine events altid er klar.

Så i stedet for at bruge den “normale” click()

$(document).ready(function(){
  $("a#klikMig").click(function(event){
     alert("Klik");
   });
 });

Skal du bruge live(), og sikre dermed at dine events også virker efter et asynkront postback

$(document).ready(function(){
   $('a#klikMig').live('click', function() {
      alert("Klik");
   });
});
]]> http://dinbror.dk/blog/asp-net-ajax-asynkront-postback-jquery-problem/feed/ 1 Sådan laver du hurtigere websider http://dinbror.dk/blog/sadan-laver-du-hurtigere-websider/ http://dinbror.dk/blog/sadan-laver-du-hurtigere-websider/#comments Tue, 13 Apr 2010 20:30:17 +0000 dinbror http://dinbror.dk/blog/?p=310 Efter påpegelse af Niels Gamborg og i forlængelse af mit forrige indlæg Sådan laver du perfekt CSS kommer her en tilføjelse, som omhandler performance aspektet. Selvfølgelig skal man ikke være ligeglad med performance, hvorfor man skal huske at optimere sine websider. Hvis det ikke er for din egen skyld og/eller pengepung, så for at brugerne får en bedre (og hurtigere) oplevelse. Ligeledes tyder det desuden på, at Google vil (og til dels allerede gør) vægte hurtigere hjemmesider højere.
Jeg har opstillet nogle simple punkter, som gerne skulle hjælpe med at opnå hurtigere indlæsningstider på dine websider.

0: Minimer HTTP-requests

Jo færre requests jo bedre. Den største og nok nemmest måde at reducere dine indlæsningstider på dine websider ligger i antallet af HTTP-requests, hvorfor du skal eliminere unødvendige requests.

Hvorfor
Browsere bruger i dag cirka 80% af deres tid på at hente eksterne filer såsom stylesheets, scripts, billeder etc. Hver fil er lig med et request, dog henter browsere disse requests parallelt (på nær script-filerne), og alt afhængig af browser, kan de have x antal forbindelser kørende på samme host på samme tid.  Herunder er opstillet nogle eksempler på, hvor mange forbindelser per host samt max forbindelser de mest benyttede browsere kan håndtere:

    Browser           |   Connection per hostname   |   Max connections
Internet Explorer 8                   6                        57
Chrome 4                              6                        55
Chrome 5                              6                        40
Firefox 3.5+3.6                       6                        30
Safari 4                              5                        60
Opera 10                              4                        20
Internet Explorer 7                   2                        60
Internet Explorer 6                   2                        56

Andre browsere og flere detaljer omkring de enkelte browsere kan findes på browserscope, som er et open source projekt startet af Steve Souders og Lindsey Simon.

Hvordan
Ja nu ved vi, hvorfor det er en god ide at minimere HTTP-requests, men hvordan gør vi det egentlig i praksis?
Der findes flere måder at gøre det på. Jeg vil her præsentere 2 måder, som jeg selv finder nyttige, brugbare og bruger til dagligt.

a) Kombinerede filer: Så snart det er muligt, skal man kombinere sine scripts og stylesheets således, at alle ens stylesheets bliver samlet i en fil og ligeledes med sine scripts. På denne måde kan man spare requests.
Det kan dog være svært, hvis scripts og stylesheets varierer meget fra side til side. Her må man gå ind og vurdere den enkelte situation, og kigge på hvad der mest gavner indlæsninghastigheden. Man skal være opmærksom på, at fx billeder i stylesheets også generer requests, så hvis tendensen på din side ikke er, at brugeren besøger mange sider, og du har meget forskelligt styling fra side til side, kan man spare requests ved at benytte sig af en side-modulær CSS opbygning. Men som tommelfingerregel skal man samle sine stylesheets samt scripts i en fil.

b) CSS Sprites: CSS Sprites reducerer antallet af billede requests. Kort fortalt går det ud på, at man samler flere af sine billeder i et billede, og vha. background-position styre hvilken sekvens af billedet, man vil vise. Hvis du ikke kender til sprites, kan du læse mere omkring emnet her:

-  CSS Sprites: Image Slicing’s Kiss of Death af David Shea

-  The Mystery Of CSS Sprites af Sven Lennartz

-  CSS Sprite: What they are … af Chris Coyier

Eller kigge nærmere på hvordan jeg har lavet min top menu.

1: Placerer stylesheets i toppen

Der er to grunde til at placerer stylesheets i toppen.

  1. W3 dikterer, at stylesheets skal være i toppen (head), medmindre det er inline-styling.
  2. Ved at placere stylesheets i toppen opnår man, at ens side loader progressivt, hvilket er vigtigt, hvis din side har meget indhold, eller brugeren sidder bag en langsom forbindelse. Siden viser indholdet så snart, det er klart, og brugeren har en indikation af, at siden er ved at loade. Denne indikation er meget vigtig for brugervenligheden. Hvis man derimod indsatte stylesheets nær bunden, ville man i mange browsere (eksempelvis Internet Explorer) miste den progressiv hentning og stå tilbage med en hvid blank side, da browsere blokerer renderingen for at forhindre at skulle gentegne elementer, der måtte ændre sig.

2: Placerer scripts i bunden

Grunden til at scripts skal være i bunden er, at scripts blokerer for den parallelle hentning, hvorfor resten af dit indhold må vente til scriptet er færdighentet. Derfor placerer altid dine scripts i bunden, når det er muligt. Der findes selvfølgelig situationer, hvor du ikke kan, fx hvis du indsætter markup via document.write, hvilket jeg dog ikke er den store fan af eller initialisere ting i dit script i den øvre del af dit HTML dokument.

3: Stylesheets og scripts skal være eksterne

Nu kommer jeg til at modsige mig selv, men der er en mening med galskaben. I første punkt fik du at vide, at du skulle spare på HTTP-requests, og undgå dem så snart det var muligt, men nu fortæller jeg dig, at du skal gemme dine stylesheets samt scripts eksternt frem for at gemme dem inline, og dermed generer et ekstra request per fil. Igen kommer det an på situationen, men oftest er der mest at hente ved at gemme dem eksternt. Ved at gemme dem eksternt bruger du som sagt et ekstra request per fil, men da browsere cacher filerne, kan det være en fordel, hvis du eksempelvis bruger de samme filer på flere sider. Ved at gemme dem inline spare du det ekstra request, men HTML dokumentet bliver tungere, og filerne bliver indlæst ved hver page load. Når dine filer derimod er cachet generer de ikke et ekstra request og HTML dokumentet er ligeledes lettere.

4: Minify

Ved at minify sine stylesheets og scripts fjerner man unødvendige tegn og luft, og gør dem derved lettere at hente. Der findes forskellige værktøjer til at minify med:

  1. YUI Compressor: YUI er et af de mest kendte og mest effektive minify værktøjer. Det er skrevet i Java, og man skal afvikle det på sin computer. Det gode ved YUI er selvfølgelig den effektive algoritme som minifyer, men også at den kan minify scripts såvel som stylesheets.
  2. CSS Compressor: Online værktøj, som kan minify dit CSS ud fra forskellige indstillinger.
  3. Closure compiler: Googles svar på et script minify værktøj, som eftersigende skulle være bedre end YUI. Compileren kan både downloades eller benyttes online samt indstilles efter behov og temperament.

5: Fjern duplikater

Punktet burde egentligt ikke have været med på listen, da det giver sig selv. Men jeg har set steder, hvor de stadig forekommer, duplikater af scripts. Ved at have duplikater forøges indlæsningstiden. Internet Explorer laver et ekstra unødvendigt request, hvorimod Firefox godt kan se, at det er det samme script. Dog spilder begge browsere tid på at evaluere scriptet to gange, så undgå at have duplikerende scripts.

6: Reducer DOM-elementer

En tommelfingerregel er, at jo flere elementer du har på en side, jo tungere er den at renderer. Sørg derfor altid for at have så ren og meningsfuld markup som muligt. Mange elementer på en side gør det ligeledes sværere for JavaScript at tilgå dem. En måde du kan undersøge, hvor mange elementer en side har, er ved hjælp af Firebug. Skriv blot følgende i konsol vinduet:

document.getElementsByTagName('*').length

7: Brug dine subdomæner

HTTP 1.1 specifikationen anbefaler, at browsere ikke downloader mere end 2 komponenter parallelt per host. Ved at gemme dine billeder på flere forskellige hosts, kan du opnå mere end 2 parallelle downloads ad gangen, og dermed gøre din side hurtigere. Steve Souders har lavet et lille eksempel, hvor han illustrerer forskellen på at gemme sine billeder på et host kontra to.

8: Undgå @import

Brug <link /> frem for @import. Internet Explorer opfatter filer indsat ved hjælp af @import som link-tags, der er indsat i bunden af siden.

9: Undgå filters

Hvis du vil have transparente png billeder i Internet Explorer 6, kan du bruge Microsofts eget filter, AlphaImageLoader. Dette er dog ikke anbefalingsmækværdi! Problemet ligger i at filteret blokerer rendering af siden og fryser browservinduet, mens billedet bliver hentet. Filteret forøger ligeledes brugen af computerens hukommelse. Undgå derfor at bruge dem, og brug i stedet gif eller png8 billeder eller nogle af de andre alternativer der findes, hvis du vil understøtte semi-transparente billeder i IE6.

10: Undgå tomme billede referencer

Tomme billede referencer resulterer i ekstra og nytteløse serverkald:

<img src="" alt="Tomt billede reference" />

Nicholas C. Zakas har skrevet en udmærket artikel, der beskriver problemet rigtig godt.

11: Komprimerer dine billeder

Hvis du som jeg ikke altid selv klipper dit grafik og dermed gemmer det, kan der opnås store besparelser ved selv at genkomprimerer billederne. Uden at slå alle designer over en kam, så tænker de ikke på størrelsen.

12: Komprimerer dine komponenter

GNU zip eller også kaldet gzip er en komprimeringsmetode, som kan spare dig adskillige kilo bytes og dermed minimere svar tiderne. Vel og mærket hvis server samt klient understøtter det. Fra og med HTTP/1.1 er web-klienter begyndt at understøtte komprimering med Accept-Encoding i headeren af HTTP-request’et, fx:

Accept-Encoding: gzip, deflate
]]> http://dinbror.dk/blog/sadan-laver-du-hurtigere-websider/feed/ 3 CSS: Sådan laver du perfekt CSS http://dinbror.dk/blog/css-sadan-laver-du-perfekt-css/ http://dinbror.dk/blog/css-sadan-laver-du-perfekt-css/#comments Fri, 26 Feb 2010 23:33:27 +0000 dinbror http://dinbror.dk/blog/?p=133 Igennem mit arbejde og efter kraftig inspiration af Andy Clarke har jeg fundet den “perfekte” måde at lave CSS og markup på. I denne artikel vil jeg forsøge kun at koncentrerer mig omkring CSS delen og give dig opskriften, som tager udgangspunkt i solskinsdage. Til den dovne læser har jeg lavet et kort resume til sidst under hvert punkt.

0: Markup

Lav altid dit markup før du begynder at style. Sørg for at den er valid, og at den er semantisk opbygget. En god tommelfingerregel er, at ens markup skal give mening uden brug af CSS.

Resume: Markup før CSS!

1: Validering

Ligesom med dit markup skal dit CSS være valid. Hvis du er i tvivl, kan du validere dine stylesheets via W3’s CSS validator. Mange undervurderer vigtigheden af valid kode, så længe det bare ser ud, som det skal. Men ved ikke at have valid kode, kan man ikke være sikker på, at ens websider vil blive vist rigtigt i fremtiden, og at mindre og alternative fremvisere kan vise dit indhold. Hvis ingen fulgte en vis standard ville khaos regerer.

Resume: Lav valid kode!

2: Normalisering

Normaliserer altid dit stylesheet inden du går i gang. Forskellige browsere har forskellige default værdier til de forskellige elementer, hvorfor det til tider kan være umuligt at lave en side, der opfører sig ens cross-browser uden brug af reset. Hvor meget eller hvor lidt der skal resettes er en temperamentssag. Herunder er listet nogle eksempler:

  1. CSS Reset Reloaded by Eric Meyer
  2. Yahoo! UI Library: Reset CSS
  3. CSS Global Styles Reset by Kyle Neath

Være opmærksom på at det korte og brugte reset: * { margin: 0; padding: 0; } er et misforstået reset. Det er tungere at renderer (især med store websider), da det definerer regler for hvert enkelt element i ens dokument og nulstiller alt, hvorfor det ikke er anbefalingsværdigt.

Resume: Reset dit stylesheet før start!

3: Navngivning

Navngivning er utrolig vigtig og desværre også utrolig undervurderet. Uanset hvad du vælger så vær konsekvent. Hold dig evt. til engelsk, brug camelCaseMedLilleBegyndelsebogstav og giv strukturelle navne frem for præsentationsmæssige.
Et strukturalt navn beskriver, hvad det er for et element, du vil henvise til frem for et præsentationsmæssigt navn, som beskriver, hvor elementet befinder sig på siden eller hvordan det ser ud.

Præsentationsmæssige navne:

topNav, leftTopLogo, footer, leftContent, redBoldLink

Strukturelle navne:

primaryNav, branding, siteInfo, mainContent, externalLink

De præsentationsmæssige navne låser elementet fast, hvorfor de skal undgås. Hvad nu hvis din top menu (#topNav) pludselig skal ligge til venstre for dit indhold?

Resume: Vær konsekvent og brug camelCaseMedLilleBegyndelsebogstav samt strukturelle navne i din navngivning.

4: Struktur

Ens struktur kan virke utrolig ligegyldig og spild af tid hos mange, men er faktisk et af de vigtigste punkter i perfekt CSS. For din egen skyld, for kundens skyld og for fremtidige udvikleres skyld sørg for at have struktur i dit CSS. Som med navngivningen er det vigtigt at være konsekvent.

a) Inddel dit stylesheet i afsnit, fx via sektioner eller selectors.

/****** STRUCTURE  ******/
#branding, #primaryNav, #mainContent...
/****** HEADERS  ******/
h1, h2, h3 ...
/****** ANCHORS  ******/
a, a:hover ...
etc

b) Et element pr. linje.

#element 1 { egenskab 1, egenskab 2 ... egenskab n }
#element 2 { egenskab 1, egenskab 2 ... egenskab n }

Mange vil måske være uenige, og hælder til den mere fyldige og måske mere overskuelige-ved-første-blik-måde; en egenskab pr. linje:

#element 1 {
    egenskab 1;
    egenskab 2;
    ...
    egenskab n
}

Men her må jeg insister. Min erfaring er, at ved større projekter bliver stylesheets hurtigt store og uoverskuelige ved en egenskab pr. linje, også selvom man deler det op og har et stylesheet pr. side.

c) Undlad hierarkier i niveauer

Jeg har set folk anbefale, at man inddeler sit stylesheet i et niveau-hierarki, som afspejler sit markup:

div#element { egenskab 1, egenskab 2 ... egenskab n }
  ul { egenskab 1, egenskab 2 ... egenskab n }
    li { egenskab 1, egenskab 2 ... egenskab n }
      a { egenskab 1, egenskab 2 ... egenskab n }

Ideen er rigtig god, men forvirrer mere end den gavner. Desuden kræver det mere vedligeholdelse. Hver gang du ændre det mindste i dit markup, skal du ind og opdatere dit CSS, så de afspejler hinanden.

d) Opstil dine egenskaber i alfabetisk rækkefølge for at få et hurtigere overblik:

#element { float: left; height: 250px; width: 250px; }

e) Vis type på dit element (unikke), igen for overblikkets skyld:

div#element 1 { egenskab 1, egenskab 2 ... egenskab n }
ul#element 2 { egenskab 1, egenskab 2 ... egenskab n }

f) Kombinere elementer med samme regler. For at undgå redundans skal man samle elementer med samme egenskaber:

div#element 1, p#element 2 { egenskab 1, egenskab 2 ... egenskab n }

Resume: Vær struktureret og konsekvent. Inddel i afsnit, et element pr. linje, sortere egenskaber alfabetisk, illustrer type på dit element og kombinere elementer med samme egenskaber.

5: Shortcase

Brug shortcase. Du kan formindske din kode betydeligt og derved få et bedre overblik. Et eksempel illustrer guleroden meget bedre:

div#element 1 { margin-bottom: 15px; margin-left: 5px; ...
                ... margin-right: 20px; margin-top: 10px; }

bliver til

div#element 1 { margin: 10px 20px 15px 5px; }

Du kan bruge shortcase hos følgende egenskaber; background, border, font, list, margin, outline og padding. Dustin Diaz har skrevet en fremragende guide til emnet.

Resume: Brug shortcase!

6: Spring mellemledet over

Som i den virkelige verden er det oftest bedst for forbrugeren, at mellemledet bliver fjernet, og det er det også hos CSS. Mellemledet er ofte ubrugeligt og fylder kun ekstra i dit stylesheet, hvorfor det skal fjernes. Der findes dog situationer, hvor du kan blive tvungen til at inkluderer det men som udgangspunkt; fjern det:

div#element ul li a span.class

bliver til

.class eller div#element .class hvis man har behov for at specificere det lidt

Resume: Undgå unødvendige elementer hos en regel!

7: Flere stylesheets

Det kan være en god ide at have flere mindre stylesheets end kun et samlet, specielt når man udvikler. Udover at det giver et bedre overblik, kan man også undgå at skulle indlæse alle regler på sider, de ikke vedkommer, og have muligheden for at overskrive en regel, som ellers ville forstyrre ens underside eller kræve ekstra og unødvendig markup.
Nogle deler desuden deres stylesheets op i selectors, hvorfor de har et til headers, et til links, et til billeder etc. men det er en smule overkill og gavner ikke just overskueligheden. Desuden resulterer det i en masse ekstra http-requests og dermed længere load time, medmindre man samler og eventuelt minify‘er sit stylesheet, inden man skubber det live. Igen skal opdelingen kun ske, når det giver mening og eventuelt kun i udviklingsøjeblikket.
Ved større projekter har jeg et generelt stylesheet, hvor der defineres de generelle regler inklusiv reset, og så et pr. underside med de specifikke regler. Selvfølgelig alle i et strutureret stylesheet.

Resume: Adskil i flere stylesheets, men kun når det giver mening!

8: !Hacks

Hold dig fra at bruge hacks! Hvad enten det er * hack, _ hack eller lignende. Brug i stedet Conditional Comments til fx at indsætte et Internet Explorer 6 specifikt stylesheet.

<!--[if IE 6]>
<link type="text/css" href="ie6styling.css" rel="stylesheet">
<![endif]-->

Resume: Undgå hacks, brug conditional comments i stedet.

9: Adskillelse

Markup og CSS er som Batman og Robin. De er fantastiske sammen, dog kan Batman fint klare sig alene, hvorimod Robin er ubrugelig uden Batman.
Man må aldrig begynde at sammensmelte markup og CSS og lave noget så uhyggeligt som inline styling. For at sikre fleksibilitet og overblik er det vigtigt at alt styling adskilles fra markup og kun styres fra sit stylesheet. Der er dog situationer, hvor inline-styling kan være eneste løsning, men brug det kun som sidste udvej, og ikke fordi du er doven.

Resume: Markup og CSS skal adskilles!

10: Divitus, classitis og idikus

Undgå at få divitus, classitis eller idikus. Generelt for alle 3 sygdomme er, at man overforbruger. Man kan sammenligne det med et sønderjysk kaffebord, hvor der minimum er 14 forskellige kager, 7 bløde og 7 hårde, hvilket er helt unødvendigt. Derimod ville 1-2 kager fra hver kategori have været rigeligt.
Divitus er når man bruger for mange div‘er. Mange nybegynder har en tendens til at smide en div rundt om alt:

<div id="mainHeader"><h1>Min overskift</h1></div>

Div‘en er ikke nødvendig, og man kan i stedet skrive

<h1>Min overskrift</h1>

og så style på h1 i stedet for #mainHeader.
Classitis og idikus minder meget om divitus:

<ul id="unsortedList">
  <li class="listItem">Item 1</li>
  <li class="listItem">Item 2</li>
  <li class="listItem">Item 3</li>
</ul>

Det er ikke nødvendigt at overklistre alle selectors med klasser og id’er:

<ul>
  <li>Item 1</li>
  <li>Item 2</li>
  <li>Item 3</li>
</ul>

Resume: Minimer dit markup!

11: Centrer med margin

Centrer med margin: 0 auto; i stedet for fx at hardkode en fast padding i venstre side. For at centrer med margin skal du definerer en bredde:

div#element { margin: 0 auto; width: 800px; }

Resume: Brug margin: 0 auto; til at centrer

12: Position og floats

Brug position og float rigtigt! Lær dem at kende, og brug dem når det passer ind. Lad være med at låse dig fast, hvor du kun bruger float eller position.

Resume: Brug position og float når det giver mening.

13: Vær doven

Sidste punkt som i øvrigt gælder programmering generelt er, at man skal være doven. Hvorfor opfinde den dybe tallerken igen og igen, når den nu er opfundet? Genbrug dine komponenter medmindre du ønsker eller mangler træning i at forstå eller lave dem.
Man støder på mange ens og lignende problemstillinger i CSS, hvorfor det vil være uhensigtsmæssigt, at skulle gennemtænke samt lave samme løsning gang på gang, og da man selvfølgelig har en strukturel navngivning, er det ikke noget problem at genbruge sin kode.

Resume: Genbrug dit veludviklet kode!

< SLUT / >

Det var mit bud på, hvordan man, ved hjælp af nogle simple principper, opnår bedre og mere overskueligt CSS. Vigtigst af alt er, at man er konsekvent hele vejen igennem og tro mod kode standarderne. Sammen kan vi gøre verden til et bedre sted. Kom gerne med en kommentar, hvad enten det er ris eller ros.

]]> http://dinbror.dk/blog/css-sadan-laver-du-perfekt-css/feed/ 9 CSS: min-height i IE6 http://dinbror.dk/blog/css-min-height-i-ie6/ http://dinbror.dk/blog/css-min-height-i-ie6/#comments Mon, 04 Jan 2010 10:00:04 +0000 dinbror http://dinbror.dk/blog/?p=155 Igennem mit arbejde er jeg begyndt at rode rigtig meget med CSS igen, på godt og ondt. Det er så meningen, at jeg vil dele nogle af de erfaringer, jeg gør, og ligeledes for at jeg selv hurtigt kan finde de forskellige tips og tricks, at jeg har oprettet en kategori, CSS, på min blog,  som efterhånden også har stået stille hen i lang tid.

Første tip er et “trick”, som de fleste webudvikler nok allerede kender, men som er utrolig nyttigt, og som skal være i enhver webudviklers værktøjskasse indtil IE6 dør.
Jeg har tit stået i en situation, hvor mine forskellige undersiders højde har varieret, og hvor kunden har ønsket, at hver side som minimum skulle have en bestemt højde, men på samme tid være dynamiske, så undersiderne kan ekspanderer.
Dette kan nemt løses ved at definere attributten min-height til den ønskede minimum højde, men IE6 understøtter desværre ikke min-height. Dog understøtter den height, og netop height attributten opføre sig faktisk som min-height i IE6. Ved at sætte en fast højde på fx 1000px, får man overraskende nok en højde på 1000px i IE6.  Dog er højden ikke låst fast, hvorfor man ligeledes får et dynamisk design, som kan udvide sig, men ved at definere en fast højde låses højden fast til de 1000px i nyere browsere, og så er man lige vidt.
Løsningen er tagget !important. !important bliver normalt brugt til at beskrive præcedens, hvor det i CSS altid er den sidst specificerende regel. Med tagget !important kan man dog gøre en regel tidligere i sit stylesheet præcedens, og da IE6 ignorer tagget kan man cross-browser sikre min-height effekten på følgende måde:

#Elementet-som-skal-have-min-height {
min-height: 1000px; //Understøttes ikke af IE6
height: auto !important; //Understøttes ikke af IE6, men gør denne regel/højde præcedens i alle nyere browsere
height: 1000px; //Hos IE6 er denne højde præcedens, men i nyere browsere overskrives attributten
}

]]> http://dinbror.dk/blog/css-min-height-i-ie6/feed/ 0 Validering af e-mail adresser http://dinbror.dk/blog/validering-af-e-mail-adresser/ http://dinbror.dk/blog/validering-af-e-mail-adresser/#comments Sat, 16 May 2009 20:08:41 +0000 dinbror http://dinbror.dk/blog/?p=106 Når jeg udvikler software eller websider, arbejder jeg ofte med formular, hvorfor der forekommer input felter, som en bruger skal udfylde. For at sikre sin data, så det er mest brugbart og korrekt, er det altid en god skik at lave validering. Uden validering kan man risikerer at dataene bliver ubrugelig og dermed værdiløse. Ofte er valideringen simpel i form af tjek om et givet felt er udfyldt eller om det er den korrekte datatype. Men når vi snakker e-mail adresser, er det lidt mere kompliceret. En korrekt e-mail adresse består af en række regler:

Starter med minimum et tegn efterfulgt af et snabel a, hvor der så igen er minimum et tegn efterfulgt af en prik. Sidste men ikke mindst defineres domænetypen, som er på minimum 2 bogstaver fx dk, de etc.

En nem måde at håndtere en række regler for en tekststreng er ved at bruge Regular Expression. Et regulært udtryk er en tekststreng, som beskriver en mængde af tekststrenge og som overholder syntaksen for opstilling af det regulære udtryk. Så for at kunne validere en e-mail adresse vil jeg lave et regulært udtryk:

(/^.*?@\w[\w.-]*\.[a-z]{2,4}$/i)

Overstående giver måske ikke så meget mening, hvis man ikke kender til regulære udtryk, så jeg vil anbefale, at man læser om det på nettet [1][2][3]. Men jeg vil selvfølgelig ikke snyde jer for en forklaring af overstående udtryk.

^ : Starten af strengen.
.* : 0 eller flere tegn.
? : Non greedy (dvs. match mindst mulige tegn i stedet for flest mulige, 0 eller 1 gange).
@ : Et ”@”
\w : Et tegn a-z, A-Z eller 0-9 og ”_”
[\w.-]* : 0 eller flere tegn, som er a-z, A-Z eller 0-9, foruden ”.” eller ”-”
\. : Et ”.”
[a-z]{2,4} : 2-4 tegn af typen a-z. For eventuelt at fremtidsikre sine e-mail adresser kan man sætte max antal tegn op.
$ : Slutningen på strengen.
i : ”ignore case”, ingen forskel på store og små bogstaver.

]]> http://dinbror.dk/blog/validering-af-e-mail-adresser/feed/ 1 Test din side i forskellige browsere http://dinbror.dk/blog/test-din-side-i-forskellige-browsere/ http://dinbror.dk/blog/test-din-side-i-forskellige-browsere/#comments Thu, 14 May 2009 15:36:53 +0000 dinbror http://dinbror.dk/blog/?p=89 Et almindeligt problem når man designer hjemmesider er, at få dem til at se ud som man ønsker i alle browsere ens målgruppe måtte benytte. En af de vigtigste ting i kampen for ensartet design uafhængigt af browser og god kode er, at følge w3c’s standarder [link til w3c validator]. Desværre er det ikke altid nok. Nogle browsere følger ikke standarderne 100%, og der er stadig brugere af Internettet, der kan finde på at bruge en forældet browser som Internet Explorer 6, IE6.

Heldigvis findes der en række gratis værktøjer, der gør det muligt at teste sit design i de forskellige browsere. Nogle er online, hvor andre skal installeres på computeren:

Browsershots.org
En hjemmeside der gør det muligt at teste sine sider i alverdens kombinationer mellem browsere, operativsystemer og ekstra indstillinger. De ekstra indstillinger består af skærm størrelse, farve dybde og om javascript, java eller flash skal være aktiveret eller deaktiveret.
Værktøjet kan ikke bruges lokalt, men kun online. Man indtaster en url og vælger de browsere samt operativsystemer, der skal testes i. Herefter loader programmet din url i de forskellige browsere og tager et screenprint af siden. Værktøjet kræver en smule tålmodighed, da der kan forkomme ventetid på resultatet.

IE NetRenderer
Ligesom browsershots.org er dette et online værktøj til at se sine sider i forskellige browsere. Dog kan der kun vælges mellem forskellige versioner af IE ned til version 5.5. Testen renderer med det samme, og er derfor et godt alternativ til browsershots, hvis man kun skal teste IE.

Multiple versions of IE
Et program udviklet af TredoSoft, som hjælper dig med at installere flere versioner af IE på en gang. Her kan du teste dine sider online såvel som lokalt.

IETester
Et program udviklet af My DebugBar, som kan vise dine sider i IE ned til version 5.5. Programmet gør det mulig nemt og hurtigt at skifte mellem de forskellige browsere både lokalt samt online. GUI mæssigt er programmet nok det flottest og det fungere ok, dog skal man stadig tænke på, at det er et alpha release, hvorfor fejl kan opstå. Ligeledes har det stadig nogle begrænsninger, fx kan der forekomme problemer med visning af flashelementernår man tester i IE 6.

MS Expression Web SuperPreview
Microsofts eget værktøj til at teste sine designs i forskellige IE versioner. Værktøjet viser dit design i IE 6 og IE 7 eller IE 8, afhængigt af hvilken version du har installeret på computeren. Du kan se siderne ved siden af hinanden eller ovenpå hinanden, og programmet giver dig nogle værktøjer, der kan identificere forskelle helt ned til pixelniveau.

]]> http://dinbror.dk/blog/test-din-side-i-forskellige-browsere/feed/ 1 Test-Driven Development – hvad, hvordan og hvorfor? http://dinbror.dk/blog/test-driven-development-hvad-hvordan-og-hvorfor/ http://dinbror.dk/blog/test-driven-development-hvad-hvordan-og-hvorfor/#comments Mon, 27 Apr 2009 22:01:43 +0000 dinbror http://dinbror.dk/blog/?p=11 Motivation

Efter at have afleveret hovedopgave på datamatikeruddannelsen, som blev lavet sammen med to medstuderende, skulle jeg forberede et 10 minutters oplæg.  Her lå mit interesseområde indenfor optimering. Hvordan kunne vi have gjort vores proces og produkt bedre?
Igennem undervisning var vi blevet introduceret til udviklingsmetoden eXtreme Programming [1]. Vi brugte en del af metodens arbejdspraksisser dog ikke Test-first programmering, selvom det havde været ideen fra starten af. Den manglende erfaring samt manglende viden omkring emnet havde skræmt os, og da vi havde anvendt en del ny teknologi i form af Adobe Flex, Hibernate, BlazeDS mm. var den blevet nedprioteret, hvorfor en fordybelse i emnet forekom naturligt.

Hvad er Test-Driven Development?

Test-driven development, herefter forkortet TDD, har været anvendt i årtier. Den er blevet en del af eXtreme Programmings arbejdspraksisser i form af test-first programmering. Det er her jeg er blevet gjort bekendt med teknikken. Det er en softwareudviklingsteknik, og ikke blot en test metode, som mange måske tror! Det er en teknik til at programmere med og fastligge krav til sit software. I eXtreme Programming er den med til at understøtte udvikleren med øjeblikkelig feedback på sit arbejde.

Hvordan bruges Test-Driven Development?

Nedestående figur illustrerer TDDs anvendelse. Jeg har delt det op i 6 trin:

Hvordan bruges test-driven development?

Hvordan bruges Test-Driven Development?

  1. Tilføj en test: Man starter med at lave sin test. Testkoden laves før selve programkoden, hvorfor udvikleren tvinges til at tænke over kravene inden der udvikles. Dette er den største forskel kontra almindelige unit test.
  2. Kør alle tests: Herefter køres testen. Vi forventer at den fejler, da programkoden ikke er udviklet endnu, men skulle den mod forventning bestå, går man tilbage til trin 1, da testen tydeligvis ikke virker.
  3. Skriv noget kode: Nu udvikles programkoden. Her er det vigtigt, at man ikke begynder at forudse problemer, men kun fokuserer på at testen skal lykkes.
    Kent Beck, skaberen af eXtreme Programming, skriver om flere strategier for, hvordan man hurtigst muligt få sine tests til at bestå. Bl.a. kommer han med udtalelsen: “Fake it (till you make it)”, som går på at man starter med at returner en konstant, og først senere laver den om til en variabel i den endelige kode.
  4. Kør alle tests: Herefter køres testen igen. Igen er der to mulige output. Fejler testen går man tilbage til trin 3 og kigger sin programkode igennem. Består testen går man videre til trin 5.
  5. Refactor: Test- og program-koden gennemses og eventuelt optimeres. Hvis der er duplikater i form af fx temp værdier og strings fjernes disse. Det er vigtigt at dubleret kode fjernes, da det medvirker til et dårligere design, inkonsistens og mindre tillid til koden, især når udvikleren glemmer, hvor det dublerede kode er.
  6. Kør alle tests: Testen køres igen. Fejler den vender man tilbage til trin 5, ellers fortsætter man med næste krav og trin 1. Det er vigtigt at man hele tiden får kørt sine test, så en eventuel fejl ikke når at blive stor og ressourcekrævende.

Hvorfor bruge Test-Driven Development?

Ja, hvorfor skal man bruge Test-Driven Development? Herunder har jeg opridset nogle klare fordele ved TDD og unit testing generelt.

FORDELE

  • Testkode før programkode: I og med at testkoden bliver lavet før programkoden, tvinges udvikleren til at tænke over kravene, inden de begynder at udvikle.
  • Mere produktivt: Forskning foretaget i 2005 viser at programmør, der skriver flere test er mere produktive [2]. Ved at man tager små bider ad gangen (tester et krav/unit ad gangen) er det nemmere at overskue, og dermed fejlrette. Det er nemmere at skulle rette i en metode på tre linjer kode end en program fil på flere tusind linjer kode.
  • Mere tillid: Alle metoder/funktionaliteter er gennemtestet, og det giver en større grad af tillid til koden.
  • Hurtigere: TDD giver mere kode i form af testkode – dog har undersøgelser foretaget af IBM vist, at det tager kortere tid eller lige så lang tid med TDD som uden [3]. Desuden viste undersøgelserne at udviklingen med TDD havde resulteret i færre fejl. Mange fejl blev opdaget tidligere, og nåede derfor ikke at blive store og ressourcekrævende (tidskrævende).
  • Lavere kobling:  Funktionaliteterne deles op i små bider og testes. De skal kunne testes individuelt, og det resulterer i lavere kobling samt mere fokuserede klasser.
  • Øget programforståelse: Undersøgelser foretaget af bl.a. Ried Kaufmann har vist at TDD at med til at give en øget programforståelse og dermed mere selvtillid. Udvikleren tør rette i koden, da man hurtigt kan se, hvis og hvor det fejler.
  • Eksempelkode: Testkoden er et eksempel på, hvordan udvikleren har tænkt sig at programkoden skal anvendes.

Træerne vokser desværre ikke helt ind i himlen, så TDD har også nogle ulemper.

ULEMPER

  • Blind spot: Ofte samme udvikler som laver testkode og programkode. Det giver den fordel, at man ikke skal sende sine krav ned til test-afdelingen og vente på at de udfærdiger ens tests, men også den ulempe, at du kan stirre dig blind på koden samt overse visse elementer og ligefrem have misforstået opgaven. Den “blinde vinkel” kan minimeres ved at bruge en af eXtreme Programmings andre arbejdspraksisser, parprogrammering. På denne måde får man et sæt ekstra øjne på koden.
  • En for alle, alle for een: TDD virker kun optimalt, hvis hele udviklingsteamet er indstillet på at bruge det. Hvis man har én der modarbejder det, har man tre muligheder:
    1. Man kan forsøge at overbevise personen til at arbejde efter TDDs principper.
    2. Man kan smide personen ud af sit udviklingsteam.
    3. Man kan droppe at bruge TDD.
  • Falsk sikkerhed: TDD kan give en falsk følelse af sikkerhed. I og med at man tester og ser sine test bestå, kan det give en følelse af at ens programkode spiller. Der kan dog stadig være masser af fejl, og det er derfor vigtigt ikke at glemme sine andre tests; accepttest, integrationstest etc.
  • Lang indlæringsproces: Egne erfaringer har vist, at hele TDD-tankegangen kan være svær at vende sig til og indføre i et udviklingsteam, og at det tager tid før man ser skoven for bare træer.

Afrunding

TDD ville bestemt have gavnet vores produkt og proces. Når man benytter sig af TDD får man ryddet op i sin kode løbende, og står ikke tilbage med rodet og dubleret kode. Samtidig er det nemt for andre at overtage koden og lave tilføjelser, idet testkoden vil verificere om en rettelse medfører fejl og hvorhenne fejlen opstår. Med TDD får man mere indsigt i koden, da man altid ved hvilken metode, der fejler, når der fejles. Man undgår derved at bruge en masse tid på at debugge sin kode igennem. Samtidig er TDD med til at sikre at din kode kan testes og styrer færdighedsgraden af dit program. Når alle tests/krav gennemføres er man færdig.
Det kan dog være svært at teste på større systemer med database og GUI-elementer. Her kan man laver Mock Objekter [4] for at simulerer en væremåde. Dog har det den ulempe, at fx vil den faktiske database aldrig være blevet testet af selve TDD processen, hvorfor mange udvikler mener, at man skal adskille disse test fra sine TDD unit tests, og henviser til dem som integrationstests [5]. Når man laver sine tests, er det vigtigt at have styr på sine krav. Uden krav kan man ikke lave sin testkode.

Teksten er forfattet på baggrund af at lære mere om TDD, og lagt online for at andre muligvis kunne få glæde af den viden jeg tilegnede mig. Teksten giver ingen dybdegående viden om TDD og dens brug, men kradser lidt i overfalden, og giver forhåbelig læseren en ide om, hvad TDD er.  Jeg har ganske vist lige overstået min afsluttende eksamen, men modtager derfor alligevel gerne ris/ros på det skrevne.

]]> http://dinbror.dk/blog/test-driven-development-hvad-hvordan-og-hvorfor/feed/ 12 Unified Process, UP http://dinbror.dk/blog/unified-process-up/ http://dinbror.dk/blog/unified-process-up/#comments Sun, 28 Dec 2008 09:33:17 +0000 admin http://dinbror.dk/blog/?p=3 Kort gennemgang af udviklingsmetoden Unified process faser. UP bruger UML som notationsprog, hvilket jeg ikke går yderligere i dybden med. Jeg nævner blot de forskellige diagrammer som et softwareudviklingsprojekt kan inddrage her: use case diagram, use case specifikationer, domænediagram, designdiagram, systemsekvensdiagram, designsekvensdiagram og tilstandsdiagram. UP er en iterativ udviklingsmetode, som oprindeligt blev udviklet af Ivar Jacobsen, Grady Booch og James Rumbaugh sidst i 90´erne. De tre samlede hovederne for at definere en ensartet objektorienteret softwareudviklingsmetode, hvilket udmundede i beskrivelsessproget UML samt fire faser:
1) Inception
2) Elaboration
3) Construction
4) Transition
Hver fase består af en række iterationer. Antallet af iterationer afhænger af udviklingsprojektets kompleksitet.

Fase 1: Inception (Forberedelsesfasen)

Forberedelsesfasen er ikke lig med kravspecifikation, som det kendes fra vandfladsmodellen. Man analysere i stedet kritiske krav og fastslår de grundlæggende ideer om systemet. Der foretages en risikoanalyse og der vurderes om projektet kan realiseres. Denne fase består som regel af 1-2 iterationer.

Fase 2: Elaboration (Etableringsfasen)

Fortsættelse på første fase, hvor man fordyber sig i sine krav, man udspecificere dem, beskriver dem og gør dem målbare. De største risici elimineres, og man får sin grundlæggende arkitektur på plads samt programmering og test påbegyndes. Der er en del iterationer i denne fase.

Fase 3: Construction (Konstruktionsfasen)

Produktet konstrueres. Man udvikler og tester systemets funktioner samt laver brugerorienteret dokumentation og manualer. Construction er fasen, som består af flest iterationer.

Fase 4: Transition (Overdragelsesfasen)

Systemet udrulles. Man laver de afsluttende tests samt installerer og oplærer brugerne. Herefter kan man evaluere på forløbet og projektet afsluttes. Dette varer normalt 1-2 iterationer.

Fordele ved Unified Process:

- UP egner sig til store og tidskrævende projekter med mange udviklere.
- Løbende reviews.
- Meget dokumentation. UP er arkitekturcentreret og systemet beskrives grundigt, som gerne skulle resultere i, at andre udviklere hurtigt kan få et overblik og overtage systemet.

Ulemper ved Unified Process:

- Meget dokumentation, i form af use case specifikationer, sekvensdiagrammer mm. Den grundige dokumentation er tidskrævende og resulterer i, at ændringer løbende koster meget tid.
- Ufleksibelt, UP er låst fast i sine faser, og det er derfor ikke nemt at lave store ændringer, når man er sidst i en fase eller har afsluttet en fase.
]]> http://dinbror.dk/blog/unified-process-up/feed/ 0