Pixelastic

You can cut our wings but we will always remember what it was like to fly.

Posts tagged with "wednesday"

Working on Wednesday #11 : First steps with my Dreamplug

A while back, I ordered a Dreamplug. It's a micro computer more or less the size of a hard drive. It uses very little electricity, has ethernet, usb, sata and sd ports as well as bluetooth and wifi connectivity.

I wanted one to primarily work as a git and mercurial server to host my repos, as well as host a few websites I might be working on. As it's not the more powerful of device and will be using my home ADSL connection, it's also a good fit for testing web performance optimisations.

Actually, I have a lot of ideas for this plug (ssh tunnel, dropox-like server, etc).

First, let's establish a connection

To do any of that, you first have to log into your device. This first step might have been the one that caused me the much trouble.

I simply wanted to connect to the plug through SSH. I didn't want to plug it to my router because it would then have emit an open wifi network. Instead, I wanted to access it through a simple ethernet cable.

To do that I had to plug the Ethernet cable on the second slot (the one the closer to the lights) on the plug, then turn it on. I didn't manage to connect with the cable in the other plug nor if I plugged it after turning the device on.

What took me a while to figure is that the Dreamplug have its own ip address : 10.0.0.1. To enable transfer between your host and the plug, you have to set a fixed ip address to your ethernet (mine was eth0)

$ sudo ifconfig eth0 10.0.0.2 

I chose 10.0.0.2 because it's close to the Dreamplug address and I will remember it better, but you can actually choose anything you want, it absolutely does not matter.

Connect through ssh

Once the first step is done, you are now able to connect to the device through SSH.

$ ssh root@10.0.0.1

The default password is nosoup4u. I chose to keep it for now, as I'll have to type it a lot, but I'll change it once everything is installed.

First thing you should do is create a new user. Using root for the day to day activities is a bad habit.

$ adduser pixelastic 

You'll be prompted for password and other misc informations. Once done, we will give sudo power to this user.

On others Ubuntu machines, I usually do a adduser pixelastic admin or adduser pixelastic sudo, but this didn't work here. There wasn't even an admin group, and adding to sudo didn't seem to change anything.

Instead, I had to edit the /etc/sudoers file, using visudo.

If you've never used vi before, press i to enter edit mode, and vi will acts as a common editor. Press Esc when you've finished, then :x to save and exit

I added a new line just below the one starting with root and copied it, simply by changing the user name.

root    ALL=(ALL) ALL
pixelastic ALL=(ALL) ALL

Your new user should now have the sudo powers.

Unfortunatly, on my build one more thing was missing. It might not be the case on your plug, but we'd better check.

$ which sudo
/usr/bin/sudo
$ ls -l /usr/bin/sudo
-rwxr-xr-x 1 root root 114976 2011-02-14 08:08 /usr/bin/sudo

Check the permissions, if you have this output, then something is wrong. The sudo executable should have the s permissions, otherwise it won't work.

$ chmod u+s /usr/bin/sudo

Now, we can logout from the root session, and login back with our new user

$ ssh pixelastic@10.0.0.1
$ sudo pwd
/home/pixelastic

What next ?

Now, one last sensible thing to do is to change the root password for something stronger, and even disable login as root through ssh. To do that, simply edit the /etc/ssh/sshd_config file and set PermitRootLogin to no.

You could also add your keys to the plug to avoid typing your password, install your softs, and link the plug to your router to make it accessible from the outside.

I plan to replace Ubuntu for Debian on my Dreamplug, I'll post about that later.

Working on Wednesday #10 : Mercurial improved

Today I enjoyed the nice blue sky and moved to the park at the end of my street to finish reading the Mercurial guide.

I skipped the last chapters about patches and queues. I know this would be useful, but I'd rather get back to them when I'll need them instead of try them without any real world example.

Tweaking Mercurial

I updated my .hgrc to configure it as best as I could.

I set vimdiff to handle the conflicted merge. vim is quite hard to get (but it is coming easier the more you use it), but it seems so powerful that I'm willing to spend some time learning it.

I've also added a cm alias to commit -Am. This basically is the same as calling hg addremove; hg commit which I happen to do all the time before.

I've create two simple styles and matching templates for my new two aliases peek and hist that repectively display a peek at the last 4 commits, and display the latest 10 commits in history in a concise way. I still have to manage to find how I could add coloring to those.

I've also added a discardlocal alias to remove all local commit and get the repo back as it is on the remote repo. I never actually had to use it, but I found the code on Stack Overflow and thought I might need it later.

I finally wrote a custom resurect method. It will bring back a deleted file (obviously, the file needs to be tracked by hg). I simply find the changeset that deleted the file, and then revert the file to the parent changeset of that changeset. I might post the exact code later as I'm quite happy with the result.

A note on laptop screens

Also, I've spent the last few weeks working on my netbook when at home. This is very tiny thing, the screen is really small (compared to my two 21" at work for example). But (and I was the first surprised of it), you actually get accustomed to it after a while.

Now that I'm writing this post on my 13" other laptop, I feel like it's huge. The more I use the netbook, the more I like it. I didn't quite use it back when it was running Windows because it was way too slow. Now with Ubuntu on it, it's a whole new story !

Next week

I still have some zsh to learn. I still don't quite get the quote and double quote differences, and a few other quirks (arithmetic, arrays, etc).

I've kinda dropped the Rails tutorial. I liked it. Really, I liked it a lot. But I'm not sure I want to start again learning a framework for making websites. I've made a living doing websites for clients, I still do partly that today, and I'd like to change.

I have a lot of personnal project on my mind that I'd like to achieve. Almost all of them could be achieved using the traditional way of making websites that both cake and Rails would allow. But one of them might need another way to look at things. And for this one, I might better need node.

So.. maybe I'll start learning node next week. This is actually something I'd love to do, so this might happen. I'm currently refactoring the JS code of my work app in Backbone at the moment, so I guess there's no perfect time for some JS practice.

Working on Wednesday #9 : Mercurial

I'm feeling like I'm getting more and more behind schedule for what I intended to do at first. I still haven't tried Rails more than that and have gone on different learning side projects.

I've been reading the Mercurial : Definite Guide the past few days to get a correct grasp of the soft.

I've been using Mercurial for the pas two years, but through a GUI and without using any "advanced" features. I never branched a project, and always worked alone.

Commands

Now that I'm working on a Linux machine every day, I can use hg through the command line.

hg commit -Am "commit message" is the same as hg addremove; hg commit -m "commit message".

hg rollback will remove the last local commit. Useful if you forgot files in the commit, or if you inserted a typo in your commit message

hg revert can revert a file or set of files to the state they were at the last commit. This can also cancel a hg add or hg remove

hg backout can "forget" a commit in the history. It will not really forget the commit (ie. will not let you alter the history). Instead, it will create a new commit where the specified changeset is removed (through a merge). It can easily backout the tip, but may involve more merge work if we want to backout an old changeset.

Automation

Also, I've learned about two great tools of Mercurial.

hg bisect let you isolate a specified commit in your history where you introduced a specific bug. You write a piece of code that, given a changeset, returns true or false based on the bug presence, and hg bisect will cleverly scan the history to find the revision that introduced the bug.

hooks where also very interesting. One can script automatic command on specific hg command like commit, pull, push. Or even before those commande to refuse the command if something does not work as expected.

The classical examples where running a build process after a commit, refusing a commit if no bug id where specified, or if the tests didn't pass. Another use case would be to push changes to a remote server on commit.

Git

Why am I learning Mercurial while all the cool guys are using git ?

Well, I've read a lot of papers comparing hg to git. What I've read the more is that git is an awesome toolbox that lets you do whatever you want with your version control, through its 100+ tools.

On the other hand, Mercurial is far easier to learn and has built-in command for the day to day work. As I was already quite familiar with Mercurial, I stick with it, but know that I'll learn git also eventually.

 

Working on Wednesday #8 : Custom zsh scripts for housekeeping

I made a break of the Ruby/Rails learning this week. Instead I learned a bit more about the basic Linux command, and made a few scripts to help me in my day to day work (and fun) with my Linux environment.

I currently use two laptops. One is a tiny netbook while the other a Dell XPS. I mostly use the XPS for everything work related (like posting this), while the netbook is dedicated to casual use : browsing, playing, etc.

Last week, during my vacations, I only took the netbook with me, and while not strictly speaking working on it I still had to code a little bit. I installed ScummVM, CortixTH and managed to run Carmageddon 2 under wine. I also downloaded and tried a few old emulator games on my Dingoo.

As you may have guessed, I wrote a bunch of scripts during that week to help me in some of the more tedious aspects of this task.

Dingoo deployment

Downloading roms, copying them to the Dingoo, and then testing the games to make sure they are working was tedious. I wrote a little script that automatically mount the Dingoo when plugged to the computer, and copy my games to it, removing old version along the way while still keeping my saved games.

I had to parse dmesg (thanks to grep, tail and sed) as well as use rsync for the copy.

Sansa Clip cleaning

I also wrote a simple script to clean my Sansa Clip of all the useless files I had put on it. As I only have a text screen, I don't need the jpg covers, torrent txt files, auto-generated m3u files and other thumbs.db and .DS_Store useless files.

Here, find to the rescue with some zsh scripting, and here we go.

Shared config files

As I'm working on several computers (two laptops and the one at work at least), I found myself spending time reconfiguring stuff multiple times.

Here, thanks to Dropbox and some clever ln -s calls, I managed to replicate the same config on the 3 machines easily.

From my freelance time, I also have a pretty big /etc/hosts and ~/.ssh/config file. At work, I have another one for the work servers. But I sometimes had to connect to the work server from home.

So once again, thanks to Dropbox, some ln -s once more and cat I wrote two functions to regenerate those two files based on config files. That way, whenever I change one of those files, it is updated on the other machines too.

That was it. It took most of my day.

Being able to script those little repetitive tedious task is something I really appreciate on Linux. I am no longer dependent on the UI my OS gave me, and can now really understand how things work. It requires some time to learn, but this is not going to drastically change from one version to another like it does on each Windows new release.

Working on Wednesday #6-#7 : Correctly installing Ruby on Rails

This post spans two weeks because I couldn't manage to have a clean Ruby/Rails install on my first try. I read a lot, installed ruby using various methods, but finally managed to get it to work corretly.

Cleaning up

First of all, you have to remove any ruby version you might have already installed, just to be sure.

sudo apt-get remove ruby && sudo apt-get autoremove

Installing RVM

Then, you have to install RVM before installing Ruby. My biggest mistake in my various shots at installing Ruby was to install RVM last.

RVM is a very important part of the whole Ruby process. This is a little piece of genius that allow you to create Ruby sandboxes. You can install various Ruby versions side by side, even various gem versions and you simply tell RVM which sandbox you want to use.

If you are absolutly positive that you will never ever work on more than one Ruby project in your entire life, you can skip installing RVM and simply install Ruby globally on your system. But you know that this will never happen, so, avoid future troubles and install RVM first.

To install RVM, simply execute the following command

bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)

This will download and execute the install script. Once it's finished, edit your .bashrc or .zshrc to include the rvm config file whenever a shell is launched.

[[ -r $HOME/.rvm/scripts/rvm ]] && source $HOME/.rvm/scripts/rvm

Just to sure to have the latest version, I also ran

rvm get head
rvm reload 

Updating your system

RVM depends on some binaries to work, so be sure to install them all. They are listed when running rvm notes, but as the time of writing this was the list for me :

sudo apt-get install build-essential bison openssl libreadline6 libreadline6-dev curl git-core zlib1g zlib1g-dev libssl-dev libyaml-dev libsqlite3-0 libsqlite3-dev sqlite3 libxml2-dev libxslt-dev autoconf libc6-dev ncurses-dev

Installing Ruby

Once RVM is installed, installing the latest (1.9.2 as the time of writing) Ruby version is as easy as :

rvm install 1.9.2

This will take some time, downloading and compiling Ruby. Next, tell RVM that this is the version we are gonna use.

rvm use 1.9.2

You can always switch back to your system-wide ruby install by doing

rvm use system

Creating a gemset

Plugins in Ruby world are named gems. They can easily be installed/uninstalled to a project to provide advanced features. Rails itself is a gem.

The traditional way of using gem is to simpy using the RubyGem command gem.

When using RVM and its sandboxed mode however, the best way is to create a gemset, and install gems in that gemset. This will allow us in the future to switch between multiple gemset easily.

I suggest creating a gemset for each project you start. You can also install gems in the global gemset so they get available to each project. As I'm new to the Ruby world and still don't really know which gems ar "must-have", I'll skip this part for now.

Let's create a new gemset for our new project. I'll name mine pixelastic, but change the name to fit your project name

rvm gemset create pixelastic
rvm gemset use pixelastic 

You'll be now using the gemset pixelastic. You can list all available gems in your current gemset by doing

gem list

Or list all the available gemsets by doing :

rvm gemset list

The one you are currently using will be prefixed by "=>"

What is Rake ?

You might have noticed that your new gemset contains only one gem, named Rake. You do not need too spend to much time on that. You simply have to know that Rake is more or less the Ruby compiler. Your Ruby code will go through this gem to became a running app.

Installing Rails

As I said above, Rails is a gem like many other, so you can simply install it by doing :

gem install rails

Note that because we are using RVM, the gem will only be installed in this gemset and not globally. If you switch gemset, rails will no longer be available.

If we weren't using RVM, the gem would have been installed globally. RVM is actually wrapping itself around the gem command to sandbox it inside its own gemset.

Handling dependencies with Bundler

Installing Rails will install a bunch of other gems. One of them is Bundler.

Bundler is a Rails specific gem dependencies handler. Its features seems to overlap thoses of RVM. At the time of writing, I haven't yet used it, but its main use still seems to be its gemfile.

The goal of a gemfile (located in your project directory) is to list all the gems your project will need (along with respective versions if provided). Then, whenever you drop your project in a new environment, Bundler will be able to download and install your gems for you.

If said environment uses RVM, then the gems will be saved in the gemset, if not they will be installed globally. Bundler is absolutly not linked to RVM and can be used independently.

The syntax of a gem file will not be discussed here as I have no previous experience with them, but the command to read the gemfile and update the project accordingly is :

bundle install

Automatic switching gemset

One nice bit of RVM is that it is able to automatically detect the gemset to use on a per project basis. You simply have to create a .rvmrc file in a project, and RVM will execute it.

For example, to use my pixelastic gemset and Ruby 1.9.2, simply add the following to your .rvmrc

rvm use 1.9.2@pixelastic

References

I read a lot on the subject, to finally get it right. Here are the various sources :

Update : Sqlite3

If you got error complaining about Sqlite3 missing, just

sudo apt-get install libsqlite3-0 libsqlite3-dev

Working on Wednesday #5 : Rails documentation and Zombies

Today I continue on my Rails for Zombie learning. Actually, I wake up kind of late (11am), had to deal with noisy neighbors and make some shopping before being really able to start working. It's 2pm now, and I just open my browser.

Back to Zombies

I like the clean syntax Ruby provides. I like being able to pass custom parameters without having to care about the order. This could be achieved in cakePHP using array for options, but is much more clean the Ruby way, using truncate(zombie.graveyard, :length => 10, :omission => '')

Also the link_to and new_{Model}_path, edit_{Model}_path are clever and allow easy access to the link you always use. This force you to logically organise your app.

The way Rails controllers pass vars to the view (using @) is also cleaner than the cakePHP set method. I love those little things the language permits.

before_filter also seems more powerful than in cake world, being able to define several of them and restrict them to certain action. Could be extended (I guess) to an ApplicationController that could check on show, edit, etc that the specified id exists and display an error message if not.

I didn't quite get the various respond_as for JSON and XML. Why should I have to pass the @tweet while I don't have to for the html view ?

Also, the Rails routings system is more appealing to me than its cakePHP counterpart. I would have loved to have such a nice tutorial for cake when I learned it. Routing is very well explained in Rails for Zombies.

After completing the Zombie tutorial, I headed to the famous blog tutorial every web language should have. Once again, I started reading the doc and a few things caught my attention as very promising :

Command line interface

I like the way one can create a new app simply with one command line. Such feature is also provided by cakePHP but I never managed to make it work the way I wanted to. That might have been influenced by the fact that I was working on Windows at that time.

Directory structure

I also note that a Rail application seems greatly structured : there are spaces defined for documentation, tests, database migration, dependencies, logs, deployment scripts and so on.

Databases

This is great that Rails directly provides two distinct DB configurations : development and production. I will no longer have to do it myself.

Rails also uses SQLite3 as the default database for development. As I wasn't very familiar with this technology, I made some researchs. Turns out that SQLite is a very simple DB system, perfectlynsuited for the development period as it does not require a DB server.

Working on Wednesday #4 : Rails for Zombies

 

(I finally managed to update Ubuntu to the 10.10 version, configure Unity to make it more usable, and I'm not ready to start the RoR tutorial I wanted to start last week.)

I used vim this week (instead of nano) for very simple file editing. I will force myself to use only vim on wednesday to really learn it. I plan to completly drop Komodo Edit once I'll be familar enough with vim to gain more time than I lose.

Rails for Zombies

Anyway. I finally get to start the Rails for Zombies tutorial. And here is what I learned.

There are two distinct things I'm going to learn here : Ruby and Rails. I discovered that I was already familiar with a lot of basic concepts of Rails, thanks to cakePHP. Model and table convention, model relationships (belongs to, has many, etc) were exactly the same.

Ruby on the other hand was new. But also very interesting. No need to add () after a method to call it when no args are passed, possibility to chain method of the same object (much like jQuery) and the use of dynamic (yet strongly typed) vars.

The first part of the tutorial (basic CRUD) was easy. I didn't find how to make a complex SQL query like this (cake) one :

$Zombie->find('all', array(
'order' => array('Zombie.graveyard' => 'ASC', 'Zombie.name' => 'DESC'
));

I guess it's just a matter of time before I learn how to to do in Rails anyway. I saw that there was more "advanced" method (much like the cake find method) that would surely allow such finding.

Part 2 : Validation and Relationships

The second part of the tutorial was more about models. Validation rules were pretty much the same as those of cakePHP. But the Ruby syntax makes it more concise.

I couldn't find how to retrieve the validation errors when saving an object using the create method (no problem when manually calling save, though).

I enjoyed being able to create binded instances by simply adding the binded element to the model. Not very clear isn't it ? Here some code to explain it better. The last two lines have exactly the same effect :

class Zombie < ActiveRecord::Base
end
class Weapon < ActiveRecord::Base
belongs_to :zombie
end
Weapon.create(:name => "Rocket Launcher", :zombie_id => 2)
Weapon.create(:name => "Rocket Launcher", :zombie => Zombie.find(2))

Later on, I had to select all weapons binded to a specific Zombie. I was able to find the a specific zombie using any of the two following commands :

z = Zombie.where(:name => "Ash").first
z = Zombie.find(:first, :conditions => { :name => "Ash" })

Then, I wanted to find the weapons binded to this zombie. First I tried the following command :

Weapon.where(:zombie_id => z.id)

Obviously, this worked. But I wanted to test some more of the Rails magic. So I tried something along the lines of what I did in the previous chapter and tried to use my z var directly instead of z.id.

Weapon.where(:zombie => z)

This didn't worked. Well, I guess I'll also learn why later one. But one even more weird thing is that the following command did work even I'm not really sur why ?

Weapon.where(:zombie_id => z)

That's all I did today (well I also did some more Mercurial an Dingux testing, but I that wasn't really work)


Working on Wednesday #3 : The long path to get it done

This morning I started reading a lot of online blog post, framework description and other webdev material online I had in my bookmarks. After reading them, I saved them on my pinboard account to find them easily later.

Lot of good JS and CSS framework/libraries in there, I hope to be able to test them soon.

I also check my mailbox and respond to mails from my normal job. I shouldn't. I'm on a day off, I have to force myself to completly cut out those external calls.

Now, let's the work begin

Anyway, I finally finished the vimtutor. I still have a some difficulties to remember the mapping of the basic hjkl movement keys (I always want use k to move down instead of j). However, I feel confident enough in it to try writing my new code in it.

So, I headed to the Rails for Zombies tutorial. I thought it was free but the "win $5 worth of online teaching" / "next course costs $5" make me doubt it a little. Well, we'll see.

After registering to it, I wanted to save my login and password to KeePass as I always do.

Unfortunatly, KeePass on my Ubuntu machine works by using mono, and the keyboard interaction weren't that good (caret is slightly misplaced, inputs lags before getting displayed, text selection is weird). So I thought "Hey, let's see if there is a new version". Big mistake.

It appears that there was indeed a new version, a real one, with apt-get and stuff while mine was some hackish install I manually made a few month ago.

But wait, this means manually adding a ppa directory. No big deal, I trust the author. What ? Still doesn't work ? Hmm, I see. I need mono 2.6, and I only have 2.4.

What ? 2.4 is the latest available version on Ubuntu 10.10 ? You mean I must upgrade to 11.04 ? Hmm. Why not. I'll have to do it eventually, so let's go.

So I ran all my updates, to have the most up to date system. Unfortunatly, language-pack-gnome-fr doesn't want to upgrade so the OS upgrade isn't displayed.

Wait, what am I doing ?

And that's when I remember that my initial wish was to learn Ruby on Rails and that I was now on the road to upgrading my whole operating system. That is not exactly speaking procrastination, but it makes me do so much other things that my initial goal that I really looks like it.

I finally managed to purge my packets, upgrade to 10.10 and then to 11.04. But this took me 4 hours, and now it's 11PM and I guess I won't start this rails tutorial today, after all.

Working on Wednesday #2 : Why I want to quit PHP

Here it is : my first Wednesday off. Well, not completely off because I had a technical meeting this whole morning, and my cousin dropped by in the evening so... I finally didn't have as much time reading and learning as I wanted to.

Anyway, those past weeks I started thinking about what I intended to learn, and why. The main reason is that I want to be able to build website and apps faster, with less hassle and better overall quality. And the more I thought about that, the more it became obvious that PHP was the main bottleneck.

My journey accross PHP land

I've been writing PHP for the last 12 years. I started as a script kiddy, putting things together, hacking strings, saving stuff in databases, building my own toolbox and finally making websites out of it.

Then, as I started my first job in a web development company, I started to organize stuff to be able to use and reuse code accross projects.

Later, when I started as a freelancer, I learned cakePHP, and it let me much more time to focus on each project while still reusing the common code of previous projects easily.

PHP is just so easy

I can be considered a PHP coder. I have some years of experience to consolidate that. Nevertheless, I don't consider myself "good" at PHP. I just write PHP, and that's all.

I think there isn't any flavour in writing PHP : it is so easy anyone can do it. I don't feel like I know those special stuff that can make one an "expert". PHP just feels so easy, you just write code and it works.

The only area where I can think that my years of experience can be used is in tracking PHP bug or weird error messages (If you haven't read this website, go now).

It just does not feel right to be able to say "Yeah, you should work with me. Why ? Because my strength is that I'm very good at understanding PHP bugs".

There is no "PHP Philosophy", no good practices that were kept in mind by PHP lead developers when they wrote the language and they wanted us to follow. Instead, we just have a bunch of functions, and play with it as in a sandbox.

Adding some pattern in this mess

Over the years you learn (the hard way) how to organise your code. PHP5 gives a little hope by adding more OO features. No need to get back on the namespace delimiter choice, this is one more example of the PHP weirdness we'll have to work with.

The best thing that happened to me in PHP world over those years is cakePHP. It took me quite some time to get it, having to learn the whole MVC pattern (and deal with some of cake internal inconsistencies/limitations) but the result was worth it.

A clear separation of model structure, controller logic and view rendering gave me my sanity back. I does abstract a lot of things, and makes things cleaner on the outside, you can just concentrate on writing your app code.

But even with cakePHP, you still have to write PHP.

Summing up

So, to sum up, here are my feelings about PHP

  • No peculiar love for the PHP syntax and (non-)patterns
  • Growing list of bugs/inconsistencies you have to work with
  • Don't feel like I'm any better than any new PHP coder, no skill required
  • Best thing in PHP is cakePHP, an external framework

That's why PHP is the first language I'll drop in my new learning, and I'll replace it with Ruby.

Ruby seems to fit more in my vision of a language that tells its developers what are the good and bad way of writing code. And as cakePHP is largely based upon Rails, I think catching up won't be too difficult.

Also, Rails just realease it's version 3, so now the best time to learn it from scratch.

Next week

This first day off was much shorter than I expected it to be. I wanted to start coding some Rails code, following the Rails for Zombies tutorial. I also had plans for using vim a little more.

Next week I might write about vim, or maybe how to organize javascript code, depending on the time I had.

Working on Wednesday #1

Starting June 15th, I'll stop working at my day job for one day a week. Instead, I'll use this time to work on personal projects.

After more than 3 years of freelancing, I've been working full time for a very nice young company (making a great social game) for the past 6 months. Today, with the public release of the game, I find myself missing freelance.

I liked being able to sleep when too tired, working late at night when really productive, reading a log of blog posts on various subjects, learning new cool stuff other did. I kinda miss that on my new job.

Sure our project is damn cool and I really like working on it. I learn a lot, in fields that I was interested in but never had the chance to explore (server administration, CDN configuration, memcache, large number of users, etc).
But on the other hand, I'm almost only doing server-side work. I relatively interesting part of Javascript (nothing fancy) and a really small part of CSS.

And I miss all that front-end part of the job. I also get kind of tired of using cakePHP. I do like it a lot, but the more I write PHP and read posts about Ruby, the more I want to switch.

Working 4 days a week

I finally made a deal with my boss, for not working on Wednesday. I want to use that time to relax and learn all those things.

The last time I was working full time for a company, I finally quit because I thought I was waaaaaaay late behind all the current tech trends. It took me a couple of month to learn the cool stuff I'm armed with today : jQuery and cakePHP.

This time, I want to re-learn a whole new world, a better one. Using all I learnt those past years to make a fresh start.

What I want to learn

There's a lot of things I would love to learn, unordered :

  • vim : I want to be able to write code on any machine, easily, and fast
  • ruby / rails : I want to learn Ruby to be able to fully understand Rails. I have a pretty strong knowledge of cakePHP so I guess Rails won't be too hard for me.
  • git : I like Mercurial, but git seems to be the de-facto VCS for all the social geeks and rails coder, so why not ?
  • sass and haml : Those seems awesome, and were part of the things that make me want to try ruby. Writing CSS and HTML in a non-painful way. I already want to write modules (or are they called gems?) to enhance them, adding webperf optimisations on the fly (creating sprites/dataURI, optimizing selectors, etc).
  • CoffeeScript, Kafeeine or equivalent : Following the logic behind sass, I want to be able to write Javascript easily. I always encounter issues when my jQuery code became too big, everything gets tangled together. Backbone.js seems interesting too. I'll have to test all those solution.
  • nodejs : Because it looks kinda fun. I haven't really understand how it works yet, but it looks fun anyway :)
  • TDD : This is not a technology, but a way of writing code that I want to learn. I tried it in cakePHP, but I spent so much time writing tests (and making them work), to finally change the implementation and broke the tests that I finally gave up. I still have to understand HOW to do it properly. I thought I read somewhere that this principle was directly intergrated into Ruby (or was it Rails ?) development.

To summarize, I want to learn the good tools that will let me focus on the project(s) I want to make, not fighting to use tools to bend them to my needs. Writing "uncompiled" css, html or Javascript and having some automation tool to automatically transform it in the most usable version to use only.

Also, I have already written a pretty decent cakePHP CMS, with a full featured admin panel that I used when making website for clients. I wanted to put it open source for all to enjoy but never really knew how to do it. I don't yet know if I want to create a whole new CMS in Rails, or if I'll do custom dev for each project, or use (and enhancing) existing CMS.

That's all for now

I might have forgotten stuff (I'd want to try couchDB/mongoDB, getting better at using Linux everyday), but here is a dump of all the things I want to achieve in the next 6 month, one day per week. I'll try to post a summary of what I learned each Wednesday, hoping that it would help others (I know I'll surely enjoy looking back at it later).