Vår fina Prius är till salu

Letar du efter en tystlåten, bränslesnål och rymlig liten familjebil så är våran till salu.

Det är en Toyota Prius Business, 2006 års modell. Den har gått drygt 7 000 mil. Skatten är endast 360 kronor per år och försäkrings-premien är även den riktigt billig.

För en camping-semestrande och villaägande familj är det dock en stor nackdel att den inte har något drag och att vi blir lite trångpackade när vi släpar med oss vårt gigantiska tält på somrarna.

I övrigt är det alltså en i alla avseenden kanonbra bil. Dessutom nyservad och nyreparerad. För all information, besök vår annons som ligger uppe på blocket.se.

 

Vår Prius, fotograferad snett bakifrån

Vår Prius, fotograferad snett framifrån

Vår Prius, fotograferad lågt snett framifrån

Vår Prius, förar- och passagerarsäte

Vår Prius, instrumentpanel

 

 

Så tänker stora ledare

TED.com är sannerligen en källa till inspiration. Jag är grymt fascinerad över alla duktiga talare som får utrymme där för att prata om en stor variation av företeelser.

Ikväll såg jag ett mycket bra klipp med Simon Sinek där han förklarade vad som skiljer världens stora ledare från oss andra. Det finns ledare och det finns ledare. De som är naturliga och leder genom att förklara sin idé, sin vision, sin dröm. Sen finns det som som utsetts till ledare, av sig själv eller andra. De pratar gärna om resultat. Vem hade du blivit mest inspirerad av, och varför?

Simon har en enkel, bra och underhållande förklaring i sitt föredrag:

 

 

Nu finns kollektivtrafiken på Google Maps

Idag har Google släppt en mycket smart och användbar liten tjänst som de kallar Google Transit. Med Google Transit görs Sveriges kollektivtrafik tillgänglig direkt i Google Maps.

När du söker en väg från punkt A till punkt B i Google Maps kan du växla till en kollektivtrafik-vy och där få se vilka kollektiva resmöjligheter som finns tillgängliga. Enkelt och smart.

Google menar såklart att detta är ett sätt att hjälpa sina medmänniskor och underlätta för vår miljö, och även om de har en poäng så är det nog vinstintresset i att driva (webb-)trafik och i långa loppet annonsörer till Google Maps som är den stora moroten för Google.

Som användare tackar jag och bockar hur som helst. Detta är kanon!

Kollektivtrafik i Google Maps

 

Del 1: GIT på Bravomedia – vår utvecklingsmiljö

Vi på Bravomedia har valt att använda oss av GIT för vår källkodshantering i alla de webbprojekt vi jobbar med. GIT är ett distribuerat versionskontroll – system. Det innebär att det skiljer sig åt en aning från Subversion, Visual Sourcesafe och liknande system som är uppbyggda runt ett centralt s.k. repository som alla jobbar mot.

Fördelarna för oss som arbetar är framförallt möjligheten att samarbeta i projekt utan att riskera att skriva över varandras arbete. Dessutom innebär det ett tryggt och säkert sätt att undersöka och testa ny funktionalitet och lansera färdig funktioner och lösningar på ett sätt som garanterar att det som lanseras är kvalitetssäkrat. Att lanseringarna kan göras med automatik på ett tryggt sätt, utan några större förkunskaper medför att inget kan missas och att inga ändringar behöver göras i kundernas produktionsmiljö eftersom det är ”mest effektivt”.

 

Så använder vi på Bravomedia GIT

Så här använder vi på Bravomedia oss av GIT i vår webbutveckling. Vi har lånat mycket av våra idéer från den utmärkta blogg-posten av Joe Maller: A web-focused Git workflow

Våra förutsättningar på Bravomedia är att vi består att ett gäng utvecklare och designers. Vi är totalt fem stycken. Vi utvecklar egen webbaserad programvara och webbplatser / onlinetjänster för kunder.

Förutom det uppenbara med att kunna jobba tillsammans i projekt utan att behöva fråga varandra om det är ok att öppna och ändra en fil just nu, så är en av de stora fördelarna för oss att kunna skapa branches för att testa olika nyheter och sidospår i vår ptoduktutveckling utan att det påverkar andras utveckling under tiden. Att vi dessutom i förlängningen kommer att kunna ge våra kunder och partners möjlighet att delta i utvecklingen är en framtida möjliggörare.

 

Fungerande utvecklingsversion

Viktigt för oss är att det alltid finns en fungerande utvecklingsversion tillgänglig av våra produkter och webbplatser – där kunden kan följa utvecklingen. I denna ”utvecklingsversion” ska alltså ingen utveckling ske – den ska bara innehålla den fräschaste fungerande versionen.

Lösningen är ett centralt bare repository med ett tillhörande konventionellt repository. Ett bare repository innehåller inte någon fungerande kod utan används endast för ren källkodskontroll. Det konventionella repositoryt innehåller den fungerande versionen av webbplatsen / produkten. Med hjälp av så kallade hooks håller vi det konventionella repositoryt i synk med det bare repository som alla projektdeltagare kommer att jobba mot.

Alla deltagande utvecklare kan skapa egna kloner av repositoryt och utveckla sidan vidare på sin egen maskin eller på ett eget område på samma server. Eftersom vi använder oss av diverse server-komponenter för minnescache, logganalys etc så har vi valt att våra egna utvecklare jobbar i sina egna hemkataloger på servern. Via dynamiska virtuella host-inställningar i Apache kan vi enkelt skapa fungerande subdomäner under dev.bravomedia.se för att komma åt respektive utvecklares version av sidorna och för att komma åt den utvecklingsversion som man vill visa upp för slutkunden.

Vi vill även att man ska ha möjligheten att göra mindre ändringar på den utvecklingssidan som slutkunden ser utan att det finns risk att förstöra något. Designers eller projektledare som lägger till enstaka bilder eller liknande ska kunna göra detta utan att behöva klona en hel webbplats och sätta sig in i en rad Git – kommandon.

 

Strukturen

Vi har valt att hålla alla repositories i två separata kataloger och varje utvecklare får en egen www-katalog i sin hemkatalog dit aktuella projekt klonas

/var/www/git/hub       <-- för bare repositories
/var/www/git/prime     <-- för konventionella repositories
/home/developer1/www   <-- för klonade repositories under utveckling

 

Att påbörja ett projekt

För att starta ett nytt projekt eller göra ett existerande projekt tillgängligt via Git ska ett konventionellt repository kopieras eller skapas en mapp och filer till prime-katalogen på servern. Därefter loggar man in via terminal / ssh och initierar Git för projektet.

$ cd /var/www/git/prime/projekt1/
$ git init
Initialized empty Git repository in /var/www/git/prime/projekt1/.git/
$ touch index.php
$ git add .
$ git commit -m"import av existerande kataloger och filer"
[master (root-commit) 42137e1] import av existerande kataloger och filer
1 files changed, 7 insertions(+), 0 deletions(-)
create mode 100644 index.php

Nu har vi en fungerande webbplats (aka prime) i Git. Dags att skapa ett bare repository som håller koll på alla förändringar. Detta repository kallar vi för projektets hub.

$ cd /var/www/git/hub/
$ mkdir projekt1.git
$ cd projekt1.git
$ git --bare init
Initialized empty Git repository in /var/www/git/hub/projekt1.git/

I det här läget finns det dock ingen koppling mellan våran prime och vår hub. Detta åstadkommer vi genom att gå in i prime-katalogen och lägga till hub som en s.k. remote. Vi skickar därefter dit vår master branch som innehåller projektets huvud-applikation.

$ cd /var/www/git/prime/projekt1/
$ git remote add hub ../../hub/projekt1.git
$ git remote show hub
* remote hub
Fetch URL: ../../hub/projekt1.git
Push  URL: ../../hub/projekt1.git
HEAD branch: (unknown)
$ git push hub master
Counting objects: 3, done. Writing objects: 100% (3/3), 272 bytes, done. Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To ../../hub/projekt1.git * [new branch]      master -> master

 

Hooks

Git har stöd för s.k. hooks – kod som exekveras i samband med Git-relaterade operationer.

Eftersom alla utvecklare kommer att jobba mot vår hub – ett bare repository så behöver vi använda oss av hooks för att vår prime som kunden kommer att kolla på ska uppdateras automatiskt efterhand som ändringar committas av våra utvecklare och designers.

Två hooks behövs. En som ser till att vår prime automatiskt uppdateras när vår hub uppdaterats från en av våra utvecklare. Dessutom behövs en hook som uppdaterar vår hub om någon skulle ha ändrat / lagt till något direkt i vår prime. Detta ska normalt inte ske, men bör vara tillåtet för att man ska kunna göra små bidrag till projektet utan att behöva gå igenom stegen som krävs för att klona projektet, ändra och synka tillbaka.

  • post-update – i Hub
    Denna hook kallas det automatiskt på när vår hub tar emot en uppdatering. Scriptet innebär att vi byter katalog till vår primeoch därifrån hämtar den senaste versionen.

    $ vim /var/www/git/hub/projekt1.git/hooks/post-update
    #!/bin/sh
    echo
    echo "**** Pulling changes into Prime [Hub's post-update hook]"
    echo
    
    cd ../../prime/projekt1/ || exit
    unset GIT_DIR
    git pull hub master
    
    exec git-update-server-info

    $ chmod 755 /var/www/git/hub/projekt1.git/hooks/post-update

  • post-commit – i Prime
    Denna hook anropas i prime efter att något committats. Det innebär alltså att man kan göra ändringar där (även om vi vill undvika att göra ändringar direkt i den miljön) och få dessa tillgängliga för andra utvecklare utan att riskera att förstöra något.

    $ vim /var/www/git/prime/projekt1/.git/hooks/post-commit
    #!/bin/sh
    
    echo
    echo "**** pushing changes to Hub [Prime's post-commit hook]"
    echo
    
    git push hub
    $ chmod 755 /var/www/git/prime/projekt1/.git/hooks/post-commit


För utvecklaren som vill vara med och bidra

Utvecklaren som vill vara med och bidra ska checka ut sin egen version av webbplatsen och arbeta vidare med den på sitt eget utvecklingsområde. När allt är testat och fungerar tillfredsställande där ska detta återföras till vår hub.

Utvecklaren måste logga in via ssh med sitt eget inlogg till servern. Så här enkelt är det sedan att via terminal skapa en kopia av det projekt vi nyss skapade:

$ cd ~/www
$ git clone /var/www/git/hub/projekt1.git
Initialized empty Git repository in /home/developer1/www/projekt1/.git/

Där jobbar man sedan vidare med webbplatsen med sin favorit-editor. Om man skulle använda sig av Eclipse, Zend Studio eller någon annan editor med Git-stöd kan man utföra sina Git-kommandon direkt i editorn.

 

Apache-konfiguration

Vi vill enkelt kunna jobba med nya projekt utan att behöva krångla runt alltför mycket med Apache-konfiguration för varje ny webbplats vi jobbar med. Vi vill därför använda våra standardiserade sökvägar i kombination med dynamiska virtuella hosts för att skapa en uppsättning url-er som alltid kan användas.

Vi tänker oss följande för projektet ovan:
http://projekt1.dev.bravomedia.se <– blir adressen för den version av sidan som kunden kommer att se
http://projekt1.developer1.dev.bravomedia.se <– blir adressen för utvecklingsversionen av sidan som developer1 arbetar med

Den delen av domänen som föregår dev.bravomedia.se och developer1.dev.bravomedia.se kommer alltså dynamiskt att mappas mot den katalog som motsvarar domänens inledande del.

Vi vill dessutom att mappen .git inte blir tillgänglig för åtkomst via webbläsaren.

Det gör vi genom att aktivera virtuella alias och skapa en config-fil för apache:

# a2enmod vhost_alias
Enabling module vhost_alias.
Run '/etc/init.d/apache2 restart' to activate new configuration!
# /etc/init.d/apache2 restart
# vim /etc/apache2/sites-available/git
<VirtualHost *:80>
#Developer websites
ServerAdmin daniel@bravomedia.se
ServerName code.dev.bravomedia.se
ServerAlias *.code.dev.bravomedia.se
VirtualDocumentRoot /home/%-5/www/%-6+

# deny access to the top-level git repository:
RewriteEngine On
RewriteRule \.git - [F,L]

LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
CustomLog /var/log/apache2/access_log vcommon
ErrorLog /var/log/apache2/error_log
</VirtualHost>

<VirtualHost *:80>
#Staging websites for Git Development
ServerAdmin daniel@bravomedia.se
ServerName bravoadmin.dev.bravomedia.se
ServerAlias *.dev.bravomedia.se
VirtualDocumentRoot /var/www/git/prime/%-4+

# deny access to the top-level git repository:
RewriteEngine On
RewriteRule \.git - [F,L]

LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
ErrorLog /var/log/apache2/error_log
CustomLog /var/log/apache2/access_log vcommon
</VirtualHost>
# a2ensite git
# /etc/init.d/apache2 reload

 

Gitweb

Vi vill dessutom gärna ha möjlighet att granska våra repositories via webbläsaren. Det gör vi med hjälp av Gitweb.

Gitweb finns färdigt att installera för de flesta Linux-distributioner. Därefter behöver vi i stort sett bara ändra sökvägen i gitwebs konfiguration och peka ut platsen där vi lagrat våra repositories.

# aptitude install gitweb
# vim /etc/gitweb.conf
$projectroot = "/var/www/git/hub"

Du kommer därefter åt Gitweb via aliases /gitweb på din server.

Med detta så avslutar jag första delen av denna två-posts beskrivning av hur vi använder Git. Läs gärna den andra delen här.

 

Del 2: GIT på Bravomedia – det dagliga arbetet

Detta är en uppföljning på min tidigare post angående hur vi konfigurerat och tillämpar Git för våra behov på Bravomedia.

 

Vårt dagliga värv

För att underlätta i vårt arbete så har vi skapat egna shell-script som initierar ett nytt projekt korrekt, såväl vårt gemensamma repository som varje utvecklares eget område.

Scripten har placerats i /usr/local/bin/ för att samtliga användare ska kunna köra dom.

 

  • bravoinit www.example.com – skapar repositories under /var/www/git/hub och /var/www/git/prime. Om det finns en existerande webbplats under vårt tidigare utvecklingsområde ( /var/www/html ) så flyttas den in till vårt nya utvecklingsområde. Filrättigheter sätts så att alla användare i gruppen webdev på vår server kan jobba och ändra våra repositories.
  • bravodevelop www.example.com – klonar ett existerande projekt i Git till utvecklarens eget område och kopplar ihop dessa.

 

Därefter jobbar vi helt enkelt som vanligt och använder oss i stort sett endast i vårt dagliga arbete av synkroniserings-funktionerna för Git samt de branching-möjligheter som användning av Git.

Branching är en viktig funktion i vår produktutveckling som möjliggör att vi kan testa vidareutveckling i vissa riktningar, med möjlighet att enkelt förkasta dessa om vi märker att de inte fyller sitt behov. Vill vi t.ex. bygga in stöd för minnescache genom hela vår plattform kan vi börja testa detta i en egen branch med vetskapen att vi helt kan förkasta denna funktionalitet om vi inte ser resultaten vi önskar.

Några av de funktioner i Git vi utnyttjar regelbundet:

$ git pull
#hämtar senaste versionen av koden från det centrala repositoryt till utvecklarens eget område
$ git commit
#sparar utvecklarens förändringar till repositoryt
#görs typiskt när en funktion är färdigutvecklad och testad på utvecklarens eget område.
$ git push
#skickar tillbaka alla uppdaterade filer från utvecklarens område till det centrala repositoryt

Flöde för att skapa branches:

När det gäller hur vi arbetar med branches så har vi lånat idéer från våra idoler på Thinkvitamin.

 

$ git push origin master:refs/heads/ny_feature_branch
#skapar en ny branch med namnet ny_feature_branch för test / utveckling av ny funktion
$ git fetch origin
#ser till att allt uppdateras från det centrala repositoryt
$ git branch --track ny_feature_branch origin/ny_feature_branch
#skapar en lokal version av den aktuella branchen
$ git checkout ny_feature_branch
#checkar ut den nya branchen så att alla förändringar vi fortsättningsvis gör sparas dit

därefter jobbar man på som vanligt, om man vill vara säker på att den nya funktionaliteten man utvecklar fortfarande är kompatibel med master – branchen bör man regelbundet slå ihop dessa på sitt utvecklingsområde.

$ git merge master

När man är nöjd med det man utvecklat och vill slå ihop detta med sin master, slår man först ihop sin branch med master-branchen enligt ovan och testar att allt fungerar tillfredsställande. Därefter gör man enligt följande:

$ git checkout master $ git merge ny_feature_branch

Om man är övertygad om att arbetet med den aktuella branchen faktiskt är klart så kan man i samband med detta även ta bort den helt.

# ta bort branchen från det centrala repositoryt
$ git push origin :refs/heads/ny_feature_branch

# ta bort den lokala branchen
$ git branch -d ny_feature_branch

 

Driftsättning av projekt

I enlighet med de metoder för branching vi just gått igenom så kan man skapa en branch som används för lansering av projekt. Genom att skapa en branch med namnet ”deploy” så kan vi regelbundet lägga undan testade och fungerande versioner av vår master – och använda denna för lansering.

Denna branch används alltså inte egentligen för någon direkt utveckling, utan endast för att sätta färdiga versioner.

 

# utcheckning av deploy-branchen, kan göras av valfri utvecklare
$ git checkout deploy

# se till att få senaste versionen
$ git pull origin deploy

# slå ihop master-branchen med deploy-branchen
$ git merge master

# tagga releasen som vi är på väg att genomföra
$ git tag -a -m "Våra kommentarer angående releasen" [tag_name]

# tryck tillbaka alla förändringar till deploy-branchen
$ git push --tags origin deploy

# återgå till master branchen, eftersom vi aldrig gör några ändringar i deploy-branchen
$ git checkout master

Därefter har vi en branch med namnet deploy som vi kan använda för att lansera våtr projekt. Vem som helst kan under tiden fortsätta arbeta med projektet och genast bygga vidare på nästa version, medans vi i lugn och ro lanserar projektet.

 

Lansering med DeployHq

Eftersom vi vill kunna lansera våra projekt till en eller flera servrar, utan att låta någon egentligen fysiskt logga in på våra produktionsservrar så använder vi oss av tjänsten DeployHq.

Där definierar vi snabbt och enkelt upp våra projekt och kopplar ihop dessa med våra fördefinierade produktions-servrar. Vi väljer att vi vill lansera projektet från dess deploy-branch och kan live följa hur projektet publiceras på en eller flera av våra servrar medans vi tar en välförtjänt kopp kaffe.

 

 

Summering

Vi är som sagt relativt nya med Git. Efter att tidigare använt oss sporadiskt av Subversion så känner vi att detta ger oss mycket större flexibilitet. Även om vi i dagsläget jobbar mot samma server så medför detta i förlängningen att vi kan göra utvecklingen lokalt om vi önskar. Det är dock framförallt i själva lanseringsfasen vi ser de stora fördelarna.

Att inte behöva göra någon utveckling lokalt, utan på ett tryggt och säkert sätt genomföra ändringarna på vår testserver och trycka ut dessa utan några märkvärdiga förkunskaper, och utan oro över att missa att överföra enstaka ändringar är ovärderligt för oss.

 

Eftersom vi fortfarande är ganska färska tar jag gärna emot era kommentarer, kan vi jobba ännu effektivare och bättre med Git skulle ingen bli lyckligare än jag 🙂

 

 

 

 

 

 

 

 

Lonely Island – Vilka sköningar

Hot Rod, en klart underskattad film som inte fått så mycket publicitet som den förtjänar var min första kontakt med sköningarna Lonely Island.

Jag vet inte vad man ska säga att de håller på med, men allt de gör blir hysteriskt roligt den saken är klar.

På senare tid så är det väl främst deras ”musik” som kan ha gjort att ni skulle kunna ha träffat på dom, men om ni inte gjort det så ta en titt på deras alster – och missa för allt i världen inte Hot Rod – en av senare års roligaste filmer, dessutom med Europe som i stort sett står för filmens hela soundtrack.

För er som vill få lite feeling har jag plockat ut lite av det bästa de gjort:

Nyast – Jack Sparrow, musikvideo med Michael Bolton

Sjukast: ”Motherlover”

Första musikvideon jag såg med dom: ”Jizz in my pants”

I’m on a boat – lite sommartema med bl.a. Justin Timberlake och T-Pain

Lite highlights från filmen Hot Rod

Twitter är genialt

Ni som inte fattat att Twitter är grymt, fatta det nu. Ni missar en värld av insiktsfulla, humoristiska och smarta budskap sammanfattade på mindre än 140 tecken.

Dessutom ger Twitter en fantastisk snabb och lättanvänd kommunikationskanal till många av de personer ni beundrar mest – och de flesta av dom är fantastiskt duktiga på att snabbt svara på de frågor eller tillrop som man skickar till dom.

För er som inte redan gjort det, ge det chansen nu. Twitter är allt som Facebook inte är. Kärnfullt, humoristiskt och underhållande. Tror inte jag läst ett enda ”dags att sticka och träna” på Twitter överhuvudtaget faktiskt. Bara en sån sak 🙂

Genialt på fotbollstema – av @Leifby
Genialt av Leifby - på fotbollstema

Snabb dialog med @Magnusbetner om vårt gemensamma intresse för poker:

@leifpagrotsky svarar helt underbart på @carlbildt och ger oss Twittrare en helt ny bild av sig själv. Kan karln verkligen skoja till det så här?!

Ett par sköna axplock som kanske kan fungera som en spark i rätt riktning för er som ännu inte börjat använda Twitter. Gör det nu, och hitta några intressanta personer attt följa. Det är en alrig sinande källa till glädje och kunskap.