The presentation was held at a company called Improove. I came in contact with the company through @andk. A friend of mine. Improove invites speakers on a montly basis to talk about web related topics.

The presentation hilights a selection of features I became very found of in Ruby. All in all the presentation went well and I hopefully inspired a few to start digging into the world of Ruby.

This year I decided to donate a total of $300 to two people I think have embraced and contributed to the world of open source in a outstanding way. It ain’t that much but hopefully something.

Ryan Bates

Ryan is the author of a fanatstic resource called Railscasts. Every week a new screencast if being released where Ryan covers something from the world of Ruby on Rails which he finds interesting. By now almost 250 episodes have been released. Therefor the chance of that gem or functionality you’re seeking isn’t yet covered by Ryan is close to nonexistent.

FUEL PHP5 Framework

The FUEL framework is definitely the most promising PHP framework out there. I’ve spent quite an amount of time working with CodeIgniter during this year. Don’t get me wrong I really like CodeIgniter but once I tried Ruby on Rails I’ve been looking for something equivalent written in PHP. FUEL might be the answer to my prayers.

Almost all my work I do for my clients are based upon open source tools. Contributing back is an important matter of keeping this ecosystem healthy and fair. I’m not asking you to donate cash. But giving somekind back is a nice gesture especially since it’s christmas.

I’ve borrowed Ryan Bates list filled with ideas on how to contribute back to open source. Slightly modified.

Start of by choosing one tool or solution you’ve been using alot during the last year. Contribute back by:

• Making a donation.
• Fixing a bug.
• Adding documentation.
• Or simply thanking them.

Go out there and start contributing back to open source!

The image in this post is borrowed from Jen.

As stated above the wrapper now uses the OAuth 2.0 protocol instead of 1.0. The new shiny updated protocol is in my opinion a huge step forward and the authentication flow isn’t that much of a hazzle anymore.

The wrapper has been written with PEAR in mind and can easily be distributed as a PEAR package. The PEAR coding standard is also adapted.

Also worth mentioning is that most of the code is now covered by unit tests which makes maintaning and contributing to the project a more gentle matter.

Check out the new demo application or go grab the updated wrapper over at GitHub.

Happy hacking!

Image borrowed from Anders Pollas.

I’ve been doing deployment using Git for a while by now. But I find Capistrano more flexible and reliable. Since Capistrano is intended to be used with Ruby on Rails it doesn’t work with other platforms “out-of-the-box“. But magic can still occur with a few lines of code.

Below you’ll a “step-by-step” tutorial on how the get started using Capistrano for easier deployment. The whole idea for this post came in mind during a Capistrano setup for a Codeigniter application I did recently. But I don’t see why this deployment process wouldn’t be applicable on any other platform or framework.

This tutorial assumes you already got your code hosted using either SVN or Git. You preferaly have setup public ssh keys between your computer and the server you’re deploying to. You’re using the same directory structure as below for your applications on your server (feel free to change the Capfile in order to match your existing structure).

/var/www/example.com
/var/www/example.com/www.example.com
/var/www/example.com/www.example.com/logs
/var/www/example.com/www.example.com/public

Start of by installing Capistrano on your computer. Capistrano is distributed as a Ruby gem.

$ sudo gem install capistrano

Next up clone my default Capfile (Capistrano config file) using cURL. Or use the Gist below.

$ curl "http://gist.github.com/raw/353124/ceda1eccacee7604d7180b23ff20cb618cb760af/capfile.rb" > Capfile

There are some variabels you need to change in order to make this Capfile work with your setup. Basically look through all lines that begins with “set” and change the corresponding value. Also make sure to change the server domain on line 10.

A typical Capistrano deployment is loaded with different kind of tasks. Since Capistrano is awesome it allows you to setup own tasks and even overwrite existing tasks.

As mentioned earlier Capistrano was invented with Ruby on Rails in mind, therefor we need to overwrite a few Rails specific tasks (migrate, restart, start). These default tasks are probably not compatible with your application. But feel free to rewrite them if needed.

As you might noticed by now the task “copy_config” inside Capfile isn’t a default task. My Codeigniter applications usually include some setup specific config files that shouldn’t be included in the repository by obvious reasons. For instance a config file including all necessary MySQL credentials. Therefor these files needs to be setup and edited manually in order to get the application running. But there’s one problem using this method with Capistrano.

Everytime you deploy using Capistrano a fresh copy of your latest application is being cloned/checkout from the repository and stored inside a new folder on the server. Since Capistrano doesn’t proceed from the previous deployed release all files that isn’t included in the repository will not be moved to the new deployed release folder. But no worries! Since Capistrano allows us to hook up our own tasks to specific events during deployment we can solve this problem with ease.

The task namned “copy_config” is being executed right after the “symlink” task. Right after the new release directory has been created and linked to the current directory. Since all my necessary config files are included in the “.gitignore” file we can use that as a reference and simply check if the file exists in the previous release folder. If so simply move the file to the newly created release folder. Capistrano provides some nifty variabels such as “previous_release” and “latest_release” to make this operation easier.

Any other needed operation to get your application up and running should probably be executed after the “symlink” task.

Once your Capfile is done it’s time to run a initial setup deploy. Start of by running the following command.

$ cap deploy:setup

You should end up with a similar directory structure on your server.

/var/www/example.com/www.example.com/public/releases
/var/www/example.com/www.example.com/public/shared
/var/www/example.com/www.example.com/public/shared/log
/var/www/example.com/www.example.com/public/shared/pids
/var/www/example.com/www.example.com/public/shared/system

It’s finally time to perform a first initial (cold) deploy of your application to your server.

$ cap deploy:cold

Congratulations! You just performed your first deploy using Capistrano. For future deploys the cold task isn’t necessary. Simply execute the command below.

$ cap deploy

Easy enough don’t you think?

This post should give you a brief idea of the Capistrano workflow. And show how you can hook up your own tasks in order to get your application up and running. I can’t guarantee that this method can be applicable on your application. As the title states “… almost anything“.

Interested in learning more about Capistrano? Here’s a few posts that I stumbled across and found interesting during research for this post.

Photo credit: heyskinny

Many older phones suffer from the lack of JavaScript support. Which in some cases makes it more complicated to track the user. But running the tracking service server-side will solve this problem easily.

As mentioned earlier Google does offer a server-side solution for Analytics. Sadly enough the documentation is almost non-existing and the only thing provided is some crappy PHP example code to get you started.

Therefor I wrote a simple class in PHP used for interacting with the server-side solution for Analytics. The logic and flow is provided by the existing example code. Below you’ll find a brief description of the “flow“.

A user comes to your site and the url function will generate an uri with all mandatory parameters included. This uri is will be included in the src attribute inside an img element. The browser will then request the uri believing that it’s an image. The uri will actually be pointing to a executable script. In this script the track function is called. A unique visitor id will be generated and stored inside a cookie. An HTTP-request will be sent to Analytics including all kind of parameters in order to track the user. When the request is done a 1×1 GIF image will be severed in order to satisfy the browser.

The method described above is a quite common way of solving lack of JavaScript related problems.

In order to start using this tracking method you’ll need to create a new Analytics profile for your website.

• Create a new profile.
• Select “tracking for a new domain” or new subdomain if applicable.
• Click on the “Advanced” tab and choose the mobile option.
• Copy your new Analytics ID from the textarea (MO-XXXXXX-XX).

The code is available on GitHub so feel free to fork away! There’s also a demo included in the repository. Should be just enough to get you started.

To all CodeIgniter fanboys out there. The class works perfectly as a library in CodeIgniter. You just need to make sure to include the uri generated from the url function inside your view. And then point it towards a function in your controller which executes the track function. See the demo inside the repository for further reference.

Happy accurate tracking!

Photo credit: Antonio Manfredonio.

Jag tog mig tiden att läsa igenom loggen med ändringar. Nedan följer en lista över mina fem favoriter.

1. Smidigare konstruktion av element
   Vid konstruktion av ett nytt element kan du nu skicka med ett objekt innehållandes egenskaper.

2. Enklare attribut manipulation
   Funktioner för att manipulera element så som .css(), .attr(), .val() och .html() kan nu ta en funktion som andra parameter. I funktionen kan du enkelt komma åt det befintliga attributets värde.

3. Unik easing metod per egenskap
   Det är nu möjligt att definiera en easing metod för enskilda egenskaper.

4. Äntligen en riktig delay funktion
   Nu är du inte längre tvungen att “fulhacka” för att skapa en delay effekt.

5. Ajax anrop tar hänsyn till Last-Modified headern
   Tidigare har alla ajax funktioner ignorerat Last-Modified headern. I syfte att ignorera eventuellt cache från webbläsaren. Genom att sätta ifModified till true tvingas jQuery att läsa från webbläsarens cache (förutsagt att något finns).

Om du är sugen på att grotta dig ännu djupare finns en bra redovisning av de nya funktionerna och förbättringarna på kampanjsajten 14 Days of jQuery.

I sedvanlig ordning tillhandahåller Google jQuery 1.4 (minifierad och gzippad) på deras supersnabba CDN.

Bilden tillhörande detta inlägg är lånad ifrån Eric Miraglia.

Därav hörde jag mig för om jag fick “forka” plugin:en och modifiera den utefter mina behov. Givetvis vart svaret ja.

Good Old Email Templates är alltså en plugin till WordPress för att skapa och administrera email-mallar. Mallarna kan innehålla ett flertal variabler som kan ersättas med egna värden. Detta är framför allt smidigt när man ska göra automatiska mailutskick till ett flertal användare.

Koden har fått sig en rejäl översyn och större delar har skrivit om av mig. Givetvis är plugin:en släppt helt i det fria. Var så god att ladda ner plugin:en från GitHub eller varför inte skapa en egen fork?

Beskrivningen på jQuerys officiella hemsida fångar det jag försöker beskriva.

jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. jQuery is designed to change the way that you write JavaScript.

Även jag har dragit mitt strå till stacken genom att dela med mig av några små plugins som jag har utvecklat på egenhand.

jContact

En plugin som kan används för att presentera kontaktinfo eller annan viktig information på ett snyggt sätt.

Exempel #1
Exempel #2
Ladda ner jContact

jFields

Låter dig ge textfält (inputs och textareas) standardvärden som beskriver vad fältet ska innehålla. Detta standardvärde försvinner så fort fältet markeras eller blir aktivt. Denna plugin är användbar om du inte vill använda dig av labels p.g.a. platsbrist eller av estetiska skäl.

Exempel #1
Ladda ner jFields

jCountUp

Tillåter dig att räkna upp ett elements värde på ett snyggt sätt. Kan vara användbart när man bygger en årtals-navigation eller liknande. Det finns även gott om inställningar så som t ex. hastighet, värde och en callback.

Exempel #1
Exempel #2
Ladda ner jCountUp

jPreloader

Ersätter submit-knappen med en valfri preloader när en AJAX request utförs. I dagsläget fungerar endast denna plugin med formulär och används tillfördel med jForm.

Exempel #1
Ladda ner jPreloader

SimpleBlock

Till ett kundjobb behövde jag blockera (göra dem “oklickbara“) några element under en bestämd tid. Det finns redan en del plugins som löser detta. Dock kändes de allt för tunga i detta fall. Därav skrev jag ihop SimpleBlock som låter dig blockera ett eller flera element under en given tid.

Exempel #1
Ladda ner SimpleBlock

Alla plugins finns tillgängliga på GitHub och är koden är helt och hållet fri. Vilket i praktiken innebär att du har tillåtelse att använda dem och modifiera dem bäst du vill. Har du hittat en bugg eller sitter på lite feedback? Lämna då gärna en kommentar.

Om du själv är sugen på att börja skriva riktiga plugins till jQuery rekommenderar jag denna guide från Nettuts och en från SitePoint.