Rasmus blogg

Tankar, funderingar och teknisk mumbojumbo

[b3rgstrom]

Morris.js charts in Bootstrap tabs

Morris.js is a javascript graph library based on the very competent raphael.js, I've come to include them in many projects lately because they are really dead simple to implement and they now, in the master branch, support the ability to natively resize with the page, in other words they are responsive, which is largely in demand right now.

Now can they be implemented in content that switches between display: block; and display: none; like bootstrap's tabs?

I've been working on a prototype for one of my clients who has the need to display data to their users in graphical form. It is easier to digest data in graphical form, easier to spot anomalies etc etc... 

One setback with using graphical elements is that they tend to take up a lot of space. Which makes other content less visible, and in data heavy user interfaces, screen real estate is worth a lot in many senses. Thus, developers struggle with the traditional issue of letting users have the cake and eat it at the same time. 

Solution -> Tabs. Great stuff, the space issue is resolved, but through implementing tabs we've spawned another problem:

Problem -> The tabbed content has the selector attribute display: none;

And why is this a problem? Graphs are generally drawn on document ready, which means the page loads, all elements are in place(except for our background tab) and the javascript starts drawing graphs on the elements it can see, hence our hidden tab will have nothing in it when its clicked. 

Example:

http://jsfiddle.net/b3rgstrom/cD6dd/2/

Now there is a solution to this, we can use the function redraw() that comes with morris, and we'll jack it up to the bootstrap event that determines the tab is active, shown.bs.tab. So when the bootstrap tab is shown, we draw some graphs. 

We will give each tab the HTML5 data-identifiers of the graphs that are present within them in the HTML. In the javascript we will determine on which tab we are, and take these identifiers and execute the redraw() function on them, this is so we don't try to redraw graphs that are not suppose to be shown at that time, economy economy... 

The complete working solution can be found here:

http://jsfiddle.net/b3rgstrom/cD6dd/12/

So there you have it, pretty pretty morris graphs in bootstrap tabs. I'll include all the code snippets at the end here if you'd rather read it here than on jsFiddle.

Enjoy.

The HAML:

.panel.panel-default.tab-box#monitor .panel-heading %h3.panel-title %i.fa.fa-signal Monitoring report %ul.nav.nav-tabs %li.active %a{"data-toggle" => "tab", href: "#fuel-tab", "data-identifier" => "line, donut"} Fuel data %li %a{"data-toggle" => "tab", href: "#co2-tab", "data-identifier" => "bar1"} Co2 data .panel-body .tab-content #fuel-tab.tab-pane.active .row .col-sm-12.col-md-7.chart .caption Fuel consumption last 12 months %span.label.label-default Liter/100km #fuel-consumption .legend %span.label#city City %span.label#highway Highway %span.label#idle Idle .col-sm-12.col-md-5.chart .caption Fuel projection this month #fuel-projection .legend %span.label#projection Projection %span.label#today Until today #co2-tab.tab-pane .row .col-xs-12.chart .caption Monthly average Co2 Emissions %span.label.label-default g/km #co2-emissions

The JavaScript:

$('ul.nav a').on('shown.bs.tab', function (e) { var types = $(this).attr("data-identifier"); var typesArray = types.split(","); $.each(typesArray, function (key, value) { eval(value + ".redraw()"); }) }); // Morris graphs ---------------------------------------------------------- // // on doc ready $(function () { // Fuel consumption // // Data set for fuel consumption var fuel_data = [{ "period": "2013-01", "city": 66, "highway": 34, "idle": 9 }, { "period": "2013-02", "city": 62, "highway": 33, "idle": 8 }, { "period": "2013-03", "city": 61, "highway": 32, "idle": 7 }, { "period": "2013-04", "city": 66, "highway": 32, "idle": 6 }, { "period": "2013-05", "city": 67, "highway": 31, "idle": 5 }, { "period": "2013-06", "city": 68, "highway": 43, "idle": 7 }, { "period": "2013-07", "city": 62, "highway": 32, "idle": 5 }, { "period": "2013-08", "city": 61, "highway": 32, "idle": 5 }, { "period": "2013-09", "city": 58, "highway": 32, "idle": 7 }, { "period": "2013-10", "city": 60, "highway": 32, "idle": 7 }, { "period": "2013-11", "city": 60, "highway": 32, "idle": 6 }, { "period": "2013-12", "city": 62, "highway": 32, "idle": 8 }]; // Line chart parameters for fuel consumption var fuel_consumption = { element: 'fuel-consumption', hideHover: 'auto', data: fuel_data, xkey: 'period', xLabels: 'month', ykeys: ['city', 'highway', 'idle'], postUnits: ' l/100km', labels: ['City', 'Highway', 'Idle'], resize: true, lineColors: ['#A52A2A', '#72A0C1', '#7BB661'] //yLabelFormat: function(y) { return y.toString() + ' l/100km'; } } // Make a line chart from the parameters line = Morris.Line(fuel_consumption) // / Fuel consumption // // Fuel projection // // Data set for fuel projection var projection_data = [{ label: 'Until today', value: 180 }, { label: 'Projected', value: 400 }, ] // Donut chart parameters for fuel projection var fuel_projection = { element: 'fuel-projection', hideHover: 'auto', resize: true, data: projection_data, colors: ['#7BB661', '#72A0C1'], formatter: function (y) { return y + " liters" } } // Make a donut chart from the parameters donut = Morris.Donut(fuel_projection) // / Fuel projection // // Fuel emissions // // Data set for fuel emissions var co2_data = [{ month: 'Jan', emissions: 35 }, { month: 'Feb', emissions: 37 }, { month: 'Mar', emissions: 40 }, { month: 'Apr', emissions: 38 }, { month: 'Maj', emissions: 39 }, { month: 'Jun', emissions: 42 }, { month: 'Jul', emissions: 37 }, { month: 'Aug', emissions: 65 }, { month: 'Sep', emissions: 38 }, { month: 'Okt', emissions: 45 }, { month: 'Nov', emissions: 41 }, { month: 'Dec', emissions: 41 }] //Bar chart parameters for CO2 emissions var co2_emissions = { element: 'co2-emissions', resize: true, data: co2_data, xkey: 'month', ykeys: ['emissions'], labels: ['Co2 emissions'], barRatio: 0.4, xLabelAngle: 35, hideHover: 'auto', postUnits: ' g/km', formatter: function (y) { return y + " g/km" } } // Make a bar chart from the parameters bar1 = Morris.Bar(co2_emissions) // / Fuel emisisons // }); // / Morris graphs -------------------------------------------------------- //

The CSS:

.tab-box .panel-heading > .nav-tabs { float: right; margin-top: -2px; display: inline-block; border-bottom: 0; } .tab-box .panel-heading > .nav-tabs > li > a { border: 0; padding: 6px 7px; } @media (min-width: 444px) { .tab-box .panel-heading > .nav-tabs > li > a { padding: 6px 15px; } } .tab-box .panel-heading > .nav-tabs > li.active > a { border-left: 1px solid #dddddd; border-right: 1px solid #dddddd; border-bottom: 0; border-top: 1px solid #7c1c1d; background: #fff; } .panel.panel-default > .panel-heading h3 { display: inline-block; } svg { width: 100% !important; }

Additional resources needed:

bootstrap 3 css & js

fontawesome

jquery

[b3rgstrom]

USA-utbudet på svenska Netflix

Har på senare tid forskat lite på det här med det amerikanska utbudet av Netflix, vissa saker finns där som ännu inte släppts för Sverige. Du kanske har märkt vid något tillfälle om du har sökt efter en film eller serie, hittat det i resultatlistan bara för att få meddelandet att "<insert name here> inte finns tillgänglig för streaming". Detta är med största sannolikhet något som hör till det amerikanska utbudet.

Går det att komma runt? Skiter björnen i skogen? Ja.

Det finns browserplugins som fungerar om du kollar via datorn, Media Hint är ett exempel, fungerar mycket bra, helt klart. Men om du vill kolla på din iPad, iPhone, Smart-TV etc? Det finns en lösning på det med, jag har testat, om än begränsat. Jag vill inte lämna några garantier, men för den som vill testa är det bara att mata in de här DNS-servrarna i enheten:

109.123.111.24

109.74.12.20

Jag har såhär långt endast testat lokalt i min MacBook Pro, vilket fungerade bra. Jag kommer återkomma till om det fungerar på Samsung Smart-TV. 

En serie som jag har hittat som finns i det amerikanska utbudet men saknas i Sverige är The IT Crowd.(länk till Netflix)

Värt att tänka på är att när man gör detta för att få amerikanskt innehåll så fungerar inte svenska undertexter, det är förstås lika enkelt att ändra tillbaka till vanliga DNS-inställningar om man vill ha svensk textning:

8.8.8.8

8.8.4.4

Om man vill ha en mer övergripande lösning, t. ex. att när man är på hemnätverket så vill man ha tillgång till det amerikanska utbudet, så är det inte svårare än att mata in DNS-informationen i routern.

Om du behöver hjälp med detta eller att konfigurera din enhet, kommentera.

[b3rgstrom]

Heroku demystifierat

Back story

Då och då när jag pratar med andra om webbutveckling har jag kommit in på ämnet Heroku, min föredragna deploymentplattform.

Varje gång jag gör det inser jag att hela konceptet är väldigt mystiskt och abstrakt. Det fanns även en tid när jag också satt och kliade mig i huvudet och funderade på hur allt hängde ihop. 

På det temat ska jag nu göra ett försök till att demystifiera Heroku och försöka avabstrahera det hela lite.

Heroku är UNIX 

Den mest förekommande termen när man pratar om Heroku är "dynos", vad är en dyno? En dyno är kort och gott en virtuell Ubuntu Server. Styrkan i plattformen ligger i att det är en virtuell miljö, ett oändligt antal dynos kan startas upp direkt on demand och ger en fantastisk möjlighet till skalbarhet för applikationsdrift. 

Varje dyno har följande specifikation:

4 CPU-kärnor Intel Xeon X5550 på 2,67GHz

512MB RAM, 1GB swap (Totalt 1,5GB RAM)

Isolerad exekvering, vad du än kör i din/dina dynos är helt isolerat från andra dynos.

Varje dyno har också "per-sekund-fakturering", varje dyno kostar 5US cent/timme, MEN man får en dyno gratis per app förutsatt att man använder den mindre än 750h/månad. Överskjutande sekunder faktureras enligt ovanstående.

Heroku handlar om program

Målet är inte att du ska köpa en virtuell VPS och konfigurera den själv, Heroku tar hand om det, du får fokusera på att bygga grymma apps. 

Så vad är ett program då? Ett program är mjukvara som;

använder HTTP för att kommunicera,  

har ett ändamål, den har en kodbas,

endast består av programkod, inte infrastrukturkonfigurationer

Det här innebär att Heroku tar ansvaret för att tillhandahålla infrastrukturdelen som hanterar;

Rollbackfunktioner

Lastbalansering

 ∞ Skalbarhet

Deploymenthanteringssystem

Redundans

Heroku tvingar tillämpning av "Best practice"

Som webbutvecklare har man ett ansvar att skriva bra programvara, om du, som jag, gör ditt bästa för att följa best practice, så kanske du har stött på något som heter "The twelve factor app" som är ett set av riktlinjer för utvecklare för att skriva effektiv programkod. Heroku's uppmuntrar inte bara 12-factor-design, de tvingar till den. 

Plattformen tolererar inte dåligt designade program, och välkomnar inte dåliga programmerare. Heroku är inte för idioter. Punkt. 

Om du jobbar med webbutveckling kan jag inte annat än att varmt rekommendera Heroku, ge det ett försök, du kommer inte ångra dig.

[b3rgstrom]

Allvarlig säkerhetslucka i Rails tilltäppt

Under gårdagen diskuterade i princip alla Ruby on Rails-kretsar om det allvarliga säkerhetshålet som upptäckts. Även om det är ett avancerat stunt att ta sig in i databasen på en Rails-app så gör man säkrast i att uppdatera sina aktiva installationer.

Det släpptes 4 säkra versioner:

3.2.11

3.1.10

3.0.19

2.3.15

Under länkarna för varje release hittar du detaljerade förändringar från tidigare versioner. 

För att underlätta uppgradering är säkerhetsfixarna de enda stora förändringarna i gem'sen. 

Har du några frågor eller behöver hjälp, kommentera.

[b3rgstrom]

Det här var intressant...

[b3rgstrom]

Hantera flera Heroku-konton.

Något som kan vara lite bökigt av och till för en utvecklare som använder Heroku för deployment är att hantera olika konton. Det kan vara privat/jobb eller kanske mer specifikt om du jobbar med många olika projekt/kunder.

Det finns en smidig plugin skriven av David Dollar på Github, som heter just heroku-accounts. Du hittar pluginet här: https://github.com/ddollar/heroku-accounts. 

För att förklara det hela kort

Installera heroku-pluginen:

$ heroku plugins:install git://github.com/ddollar/heroku-accounts.git

Lägg till konton:

$ heroku accounts:add personal Enter your Heroku credentials. Email: [email protected] Password: ****** Add the following to your ~/.ssh/config Host heroku.personal HostName heroku.com IdentityFile /PATH/TO/PRIVATE/KEY IdentitiesOnly yes

Eller använd den automatiserade varianten:

$ heroku accounts:add work --auto Enter your Heroku credentials. Email: [email protected] Password: ****** Generating new SSH key Generating public/private rsa key pair. Your identification has been saved in ~/.ssh/identity.heroku.work. Your public key has been saved in ~/.ssh/identity.heroku.work.pub. Adding entry to ~/.ssh/config Adding public key to Heroku account: [email protected]

Funktionell användning

För att byta konto på en herokuapp:

# in project root $ heroku accounts:set personal

För att se vilka konton som finns tillgängliga:

$ heroku accounts personal work

För att ta bort ett konto:

$ heroku accounts:remove personal Account removed: personal

Sätt ett defaultkonto för den dator du jobbar ifrån:

$ heroku accounts:default personal

När man ändrar konto uppdateras även .git/config med de korrekta adresserna. Om du har några egna erfarenheter om hur du jobbar med projekt/konton, kommentera.

[b3rgstrom]

Julbord med Doidea

[b3rgstrom]

Drinks with the Doidea crew

[b3rgstrom]

Hantera flera miljöer på Heroku från samma repo

Varje webapp som man kör på Heroku har som minst två miljöer, en utvecklingsmiljö som ofta är lokal, och en remote på Heroku, man kan säga där den är i produktion.

En bra metodik att använda när man håller på med webbutveckling är att lägga till en miljö för staging. Man använder sig av stagingmiljö för att säkerställa att kodförändringar man gör på utvecklingsservern, som ofta är lokal, fungerar som den ska på produktionsservern, utan risken för att dina användare får se fel som borde fångats upp tidigare. 

När man har en utvecklingsmiljö lokalt finns det alltid en risk att de ändringar man gör lokalt inte beter sig likadant på produktionsservern. Det är därför det är lite flott att ha en staging-miljö, det gör att man kan testa sina förändringar i en miljö som har exakt samma förutsättningar som produktionsmiljön. Aldrig mer: "det fungerade ju i utvecklingsmiljön...", glöm det. 

Den traditionella uppsättningen när man produktionssätter mot heroku använder sig inte av staging och produktionsmiljöer, men det är väldigt enkelt att åstadkomma. 

För att förklara det på enklaste sätt så innebär det här att man får två individuella applikationer som kör på Heroku, men med en gemensam kodbas. 

Såhär kommer du igång

För att sätta upp staging och produktionsmiljö på Heroku, kör följande från din projektroot:

 $ heroku create --remote staging

Det här skapar en herokuapp för din applikation med remote-flaggan staging. 

I vanliga fall skapar Heroku's CLI en git remote som heter heroku, men nu specificerar vi vad remoten ska heta helt enkelt. Det här gör också att förfarandet för att pusha till Heroku ändras lite. Vanligtvis kör man git push heroku master, nu får vi istället byta ut heroku mot namnet på vår remote. 

Byt namn på appen genom att köra:

$ heroku rename <staging-app-name> --remote staging

Återigen kör vi kommandot med flaggan --remote för att specificera vilken app det gäller, något som vi kommer fortsätta att göra för alla kommandon mot Heroku.

Sedan gör vi samma sak för att skapa en produktionsinstans:

$ heroku create --remote production

Byt namn på appen:

$ heroku rename <production-app-name> --remote production

Nu har vi alltså satt upp våra två remotes på Heroku, båda är tomma, så vi kanske ska pusha upp våran kod.

Vi börjar med stagingmiljön:

$ git push staging master

Och därefter produktionsmiljön:

$ git push production master

Nu har vi alltså två remoter på Heroku, en som heter staging och en som heter production, hädanefter kommer vi att använda oss av flaggan --remote för att specificera vilken remote app som kommandot gäller. Vi kanske vill migrera databasen på staging-miljön:

$ heroku run rake db:migrate --remote staging

eller vi kanske vill komma åt consolen för produktionsmilön:

$ heroku run console --remote production

Svårare än så är det faktiskt inte, nu har du en app som är versionshanterad med staging- och produktionsmiljö. Men vi ska göra en sak till innan vi är klara, om du kör en rails-app så kan det vara behändigt att lägga till en koniguration för Heroku som specificerar att din remote som heter staging är just en stagingmiljö. Heroku sätter per default konfigurationen för det som pushas upp till production. 

Det här kräver dock att du har filen config/environments/staging.rb för att det ska fungera.

$ heroku config:add RACK_ENV=staging RAILS_ENV=staging --remote staging

Du kan Kontrollera att miljökonfigurationen är korrekt genom att köra:

$ heroku config --remote staging

Vilket bör ge dig en sammanställning på konfigurationen med bland annat denna information:

RACK_ENV:                     staging RAILS_ENV:                    staging

Fördelen med att göra på det här viset är att du nu kan skriva miljöspecifik kod för olika remoter i samma dokument. Det låter kanske abstrakt, men för att ge ett exempel så kanske man vill ha sin staging-miljö nedlåst så att man kan testa själv utan att det är publikt tillgängligt, man skulle kunna göra följande i sin application controller:

if Rails.env.staging?     before_filter do       authenticate_or_request_with_http_basic do |username, password|         username == "username" && password == "pa$$w0rd"       end     end   end

Det här skulle alltså innebära att när man surfar till staging-appen så kommer man bli promptad för ett lösenord, medans produktionsmiljön kommer att vara öppen och tillgänglig för dina användare. Ganska smutt va?

Jag hoppas att det här kan vara till nytta för nån, jag tycker att det är en bra metodik för att produktionssäkra sina applikationer. 

Om du har några frågor, släng in en kommentar eller hör av dig på annat sätt så ska jag försöka hjälpa till så gott jag kan.

[b3rgstrom]

Haml i Rails istället för HTML

Haml(HTML Abstraction Language)är ett templating-språk för Rails, det är ett alternativ till ERB(Embedded Ruby) som kommer som default till Rails. 

ERB bäddar, som namnet antyder, in ruby i HTML-dokument (example-file.html.erb). ERB bevarar HTML-syntaxen och tillåter Rubykod att bädda in inom ett par av <% och %> avgränsare. Haml eliminerar <% och %> och använder sig av indrag för att markera början och slut på “markup”, följdaktligen behövs inte längre stängande taggar.

Supernajs. 

Jämförelse

ERB:

<section class=”container”> <h1><%= post.title %></h1> <h2><%= post.subtitle %></h2> <div class=”content”> <%= post.content %> </div> </section>

Haml:

%section.container %h1= post.title %h2= post.subtitle .content = post.content

Fördelar

Haml är avsedd för att ge en "elegant" markup genom att eliminera de repetetiva HTML-taggarna och genom att integrera villkorlig logik på ett kortfattat sätt. Det är mycket lättare att läsa, punkt. Jag hoppas att vi alla är rörande överens om detta.

Indrag är ett viktigt inslag i Haml, det ger också en trevlig sidoeffekt, att det blir ännu lättare att läsa koden förutsatt att man gör rätt. En drawback skulle väl vara att det blir känsligare för fel på grund av just indrag, lite irriterande ibland, men fortfarande lätt att åtgärda. Det finns IDE'er som håller koll på indrag åt dig om du nu prompt vill ha både hängslen och livrem. 

Vissa menar att om man är ny för Rails som koncept kan det vara bra att hålla sig till ERB för att det är så likt HTML. Jag tycker att valet är enkelt, och egentligen handlar det om att bestämma sig ifall man vill använda dig av ERB eller Haml under en överskådlig framtid. Man blir inte bra på Haml genom att inte använda det, så varför inte göra det direkt?

Kom igång med Haml

Om det är så att du har ett Railsprojekt redan så kommer du igång genom att lägga till följande i din Gemfile. 

gem 'haml-rails', '>= 0.3.4', :group => :development

Spara och kör:

$ bundle install

När du installerat gem'en för Haml så behöver du inte ändra något i din application.rb, varje gång du genererar en controller eller scaffold så kommer du få den formaterad med Haml-syntax. När du laddar om din Rails-app så kommer Haml laddas och initieras. 

OK men jag har en drös med ERB/HTML-content redan

Worry not child, det finns en finfin resurs för att översätta ERB/HTML till Haml. Du hittar den här: HTML2Haml. Happy?

Sammanfattning

Haml är grymt bra för att göra din kod mer överskådlig, det krävs en viss nivå av inlärning, men för att vara ärlig så kommer du ha igen den tiden på all tid du sparar på att inte skriva close-taggar till varenda eviga pryl. 

Varsågod, förenkla, njut och skratta åt alla apor som fortfarande skriver close-taggar.

Jag är som vanligt intresserad att höra ifall det är någon som är av en annan uppfattning än vad jag är, så kommentera vettja, eller rage'a lite på valfritt socialt nätverk ifall du föredrar det. 

[b3rgstrom]

Vem du bör "unfrienda" på Facebook

Funderar du ibland på vem du borde "unfrienda" på Facebook? Jag har svaret:

Klicka här

[b3rgstrom]

Github eller Bitbucket?

Alla som pysslar med utveckling och versionshanterar i Git har säkert någon gång kommit i kontakt med Github, ett repository management-verktyg. Jag tycker Github är kanonbra, inte minst för att hitta inspiration eller plugins och extensions för ett projekt. Github har en i det närmaste gigantisk användarbas, som leder till att det finns mycket content, bra bra. Men, Github har en stor setback i mina ögon.

Jag kan som standardanvändare inte ha några privata repositories. Något som gör att jag kategoriskt väljer att favorisera Bitbucket när jag behöver en remote repository. 

Jag förstår att Github behöver tjäna pengar på något, helt OK. Men jag förstår inte varför de inte kan visa lite kärlek till användare som inte ligger på corporate-nivå? Exempelvis så skulle man ju kunna sätta en gräns på hur många privata repon/utrymme man får ha som gratisanvändare, likt det de har idag för micro-medlemskapet. Av alternativen att antingen betala eller dela med sig till hela världen så väljer jag inget. Jag har mina repon på Bitbucket. 

Jag tycker att Bitbucket har en hälsosammare inställning, jag kan välja fritt om jag vill ha mina repon privata eller publika. Det finns en styrka i öppenhet, något som jag försvarar i 9/10 lägen. Det är ett utmärkt sätt att vidareutveckla funktionalitet utan att lyfta ett finger, men ibland vill man kanske bibehålla en viss mängd illusion utan att behöva pynta för det. Eller för att utrycka det såhär, om jag kan få i princip samma tjänst för antingen X kronor eller 0 kronor så väljer jag alternativet för 0 kronor, men det kanske bara är jag...

Github's prismodell: 

Bitbucket's prismodell:

Valet för mig är självklart, men jag skulle gärna vilja höra om någon resonerar annorlunda och varför. Kommentera vettja!

[b3rgstrom]

När kändislobbyismen fallerar

Det här är ju faktiskt jätteroligt, Oprah Winfrey, "Product maker/braker/influencer extraordinaire" tweetar om hur mycket hon älskar Microsoft's nya surfplatta, från en iPad. 

Vill dock tillägga att det inte finns någon officiell twitter-app till Surface än, vilket skulle kunna vara förklaringen, men ganska roligt ändå.... :) 

[b3rgstrom]

Apple touch ikon för din hemsida

Om du är som jag, mycket på språng, kanske det är så att du surfar en hel del mobilt... Du hittar en sjyst hemsida, kanske vill du bokmärka den.

Här är ett tips på hur du kan ge din hemsida en snygg ikon när den bokmärks på en iPhone/iPad.

På iPhone så kan man väldigt enkelt lägga till ett bokmärke på hemskärmen, jag har en egen mapp för alla mina bokmärken. En miss som jag ofta ser dock, är att många inte utnyttjar den fina funktionaliteten som gör att bokmärket får en tjusig ikon istället för en snapshot av hemsidan med lite reflexer över. Bilden trycks ihop till storleken av en vanlig iPhone-ikon, och det kanske inte behövs ett geni för att komma på att det här inte är särskilt tydligt.

Om det nu är så att du vill förbättra användarupplevelsen för dina användare så behöver du göra följande:

Knåpa ihop en liten ikon på 57x57 pixlar och en större på 114x114 pixlar (för iPhone/iPad) spara dem i .png-format och namnge dem: 

touch-icon-small.png

touch-icon-big.png

Ladda upp bilderna till root-katalogen för din hemsida

Dags att dyka in i koden

I filen som hanterar din header, i WordPress är det header.php, i Rails oftast application.html ska vi lägga till följande vid meta-taggarna:

<link rel="apple-touch-icon" href="/touch-icon-small.png" />

<link rel="apple-touch-icon" sizes="114x114" href="/touch-icon-big.png" />

By default lägger iPhone och iPad på ett glansigt lager och lite andra effekter över din ikon, rundar hörnen osv, om du skapat en ikon som gör sig bättre i sitt naturliga skick så lägger du till attributet precomposed:

<link rel="apple-touch-icon-precomposed" href="/touch-icon-small.png" />

<link rel="apple-touch-icon-precomposed" sizes="114x114" href="/touch-icon-big.png" />

Mer avancerat än så är det inte, det enklaste sättet är att testa att bokmärka din hemsida via en iPhone/iPad. 

Om du behöver hjälp så är det bara att höra av sig eller kommentera.