Considerations on home office

Ah… home office. The dream of any real programmer.

home_office

I was about to say ‘hacker’ but it seems that this substantive has become something that can’t be said in some circles in current ‘social sensitive’ society (but that is a topic of another post).

Can you imagine that: wake up at any time, no need to commute, have your very own office space decorated in any way you want?

desk

I have being working in a home office setup for the last 16 months and realized a couple things that may be interesting to share with my friends and the opensource community overall.

First lesson: it requires discipline. There is no one around to push you to do your job, so unless you are a disciplined lad, probably you may get in trouble. I’ve lead teams of developers in the past, and I can say that not everyone is cut to work in a more relaxed and self managing environment. What is interesting: the majority of people when offered the opportunity to work remotely will be scared of it and will find an excuse to avoid it.

Second lesson: timezone differences are your friend. Last year I was able for 2 months to wake up early in the morning, visit a beach from 6AM to 12PM and then start working. If you have the opportunity of working remotely for a sponsor located in a different timezone, it is beneficial for both sides to explore that. You will be available at the sponsor’s timezone and at same time, it gives you freedom to do things that won’t be possible in a common 9AM to 5PM workday. Tip: since I’m using KDE, I have in my workspace analog clocks displaying the timezones of all involved parties in a project.

Third lesson: have your office. To properly turn on your mind set, have an office (which may be a room in your house) that will be your work place. When you start working, close the door and make clear to everyone that you are busy and not available. And when you are done with your daily journey, simply leave the place and close the door behind you, to help you change the mindset and be able to relax.

Fourth lesson: communication rules. Be in touch with your pals, provide daily updates and try as much is possible to be aware to what is happening in your project. Being thousands of Kms (or should I say miles to the Imperial guys?) away makes your work pretty hard to be noticed by managers and at same time provides unique challenges to be able to feel how a project is going and what the sponsors priorities really are.

Fifth lesson: you will always loose something. The trash talk at the coffee place? Not documented good practices? Some cool pet project developed by a co-worker? You will loose all that working remotely and that is a sad fact that you need to accept. There are also limits to what you can contribute back to your company while working remotely, which leads to the next point.

Sixth lesson: you will achieve the ladder’s end pretty fast. We, humans, are related to primates. Hunters in the past used to depend on facial expressions to properly assess danger and happiness. Even with current’s advances on remote communication, there are limits imposed by our own nature that won’t be overcome by technology. You need to accept that you won’t be able to achieve the top of your company while working remotely.

Seventh lesson: it requires courage and confidence on your skills. Think about it: you probably signed a contract with a foreign company that probably cannot be enforced in your local country and which gives freedom to both parties to end the aforementioned contract at any time. I personally feel that this keeps things straight and honest between both parties (you need to be happy and the sponsor needs to be satisfied with the results), but there are people who may be afraid of such situation.

Well… this is it. If I remember other things I’ve learned on this subject, I will update this post. Do you have thoughts on the subject? Let me know.

April 24, 2013 at 5:27 am 5 comments

icecc setup how to

I wrote this article back last February just to document the way I did setup icecc in my home and decided to put it here for easy access. Just ignore the time of compilation for both Qt and webkit (since then, both have changed considerably and I also added another node into the cluster, an Intel i7). For reference, the trick of  combining ccache and icecc is not very well know and this is why I think it is still worthwhile to document it here.

Maybe those are techniques that you are already familiar with, so my advanced apologies. If you don’t have used icecc/ccache before or just want to known a little more about it, let’s proceed.

Ok, so this is the scenario: you are working with a big code base or maybe you need to recompile a specific version of Qt/WebKit. Or it can be another reason, maybe you just want to self compile your own kernel/desktop like real programmers do, right?

Even with today’s multicore/gigabyte based systems, it may take a little longer than you wish to compile it all: http://xkcd.com/303/

So, what to do in this cases? There are some projects that can help you out, let’s examine the case of ccache first.

Ccache (http://ccache.samba.org/) is a tool created by samba team, that project that offers CIFS/SMB protocol implementation over *nix kernels. It works with a simple principle of generating a cache of compiled files and reusing those object files if no changes in the source code were detected. Instalation is quite easy in Linux (sudo apt-get install ccache), and you only need to point your PATH environment variable to ccache.

An alternative is to have a file in your home (e.g. ~/.samba.bashrc) with the following function (and source it in .bashrc):
function sambacache {
export PATH=/usr/lib/ccache:$PATH
}

So that you can enable samba by doing:
adenilson@macmini:~$ which gcc
/usr/bin/gcc
adenilson@macmini:~$ sambacache
adenilson@macmini:~$ which gcc
/usr/lib/ccache/gcc

The first compilation will take the same time as you are used to, but the following ones (after the cache is populated i.e. check ~/.ccache directory) will give huge speed ups. So, as an example, a favorite of mine (http://cellardoor.googlecode.com) takes 4s to compile in a Intel i5@2.3Ghz the fist time but next it will take only 0.48s to recompile after a make clean. Pretty neat, hum?

Ccache adds almost no overhead in the compilation and is a perfect helper if you have just 1 computer to do your compilation jobs.

There is an issue with the way that ccache works. It is easy to see that if your project has many self-generated files by each new compilation, the cache will not be reused. So, if for recompiling just Qt there are not big benefits (it self generates lots of header files at beginning of compilation), for WebKit it brings the time compilation down to just 2 minutes.

The next project is icecc (http://en.opensuse.org/Icecream) and it allows to use several computers in the same network to distribute the compilation jobs. It is the ‘evolution’ of distcc, offers some extra features and has a great monitoring tool called ‘icemon’. Instalation is easy in Linux (sudo apt-get install icecc icecc-monitor), configuration not that easy and the documentation could be better.

The speed ups are almost linear, being the network speed the most probable bottleneck. I’ve used it in my previous job with up to 15 computers connected and it allowed me to do a cold recompile of Qt in less than 8 minutes (bear in mind that those 15 computers were also compiling other projects at same time…).

To make it easier to follow, I will explain my home setup. I have 2 machines:
a) macmini: Intel i5@2.3Ghz running Linux 32 bits (dual boot with OSX Lion).

b) blackbloat: Acer notebook (cheapest one I could find, so portability is not its strongest feature…) Intel i5@2.67Ghz running linux 64 bits (dual boot with Windows 7). IP is 192.168.1.135

What is neat about icecc is the fact that you can have varied nodes in your cluster and still perform compilation jobs distribution. It does that by allowing you to create a ‘rootstrap’ of libraries and compilers to be used, being those sent to the other nodes in your first compilation. To do it, you should run:

adenilson@blackbloat:~$ icecc –build-native
adding file /usr/bin/gcc
adding file /lib/x86_64-linux-gnu/libc.so.6
adding file /lib64/ld-linux-x86-64.so.2
adding file /usr/bin/g++
adding file /usr/bin/as
adding file /usr/lib/libopcodes-2.21.53-system.20110810.so
adding file /usr/lib/libbfd-2.21.53-system.20110810.so
adding file /lib/x86_64-linux-gnu/libz.so.1
adding file /lib/x86_64-linux-gnu/libdl.so.2
adding file /usr/bin/cc1=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/cc1
adding file /usr/lib/libmpc.so.2
adding file /usr/lib/libmpfr.so.4
adding file /usr/lib/libgmp.so.10
adding file /usr/bin/cc1plus=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/cc1plus
adding file /usr/lib/gcc/x86_64-linux-gnu/4.6.1/liblto_plugin.so
adding file /etc/ld.so.conf=/tmp/icecc_ld_so_confpM2h21
creating de07a31507267d47693646853b78125e.tar.gz

adenilson@macmini:~$ icecc –build-native
adding file /usr/bin/gcc
adding file /lib/i386-linux-gnu/libc.so.6
adding file /lib/ld-linux.so.2
adding file /usr/bin/g++
adding file /usr/bin/as
adding file /usr/lib/libopcodes-2.21.53-system.20110810.so
adding file /usr/lib/libbfd-2.21.53-system.20110810.so
adding file /lib/i386-linux-gnu/libz.so.1
adding file /lib/i386-linux-gnu/libdl.so.2
adding file /usr/bin/cc1=/usr/lib/gcc/i686-linux-gnu/4.6.1/cc1
adding file /usr/lib/libmpc.so.2
adding file /usr/lib/libmpfr.so.4
adding file /usr/lib/libgmp.so.10
adding file /usr/bin/cc1plus=/usr/lib/gcc/i686-linux-gnu/4.6.1/cc1plus
adding file /usr/lib/gcc/i686-linux-gnu/4.6.1/liblto_plugin.so
adding file /etc/ld.so.conf=/tmp/icecc_ld_so_confWHgW78
creating 73c127da41faa91bfdbae1faedbb2113.tar.gz

And later point the environment variable ICECC_VERSION to where is the rootstrap tarball. In my case, I added a file in my home (i.e. .icecc.bashrc) and renamed the tarball with the following:

function coolice {
export ICECC_VERSION=/home/adenilson/Desktop/ice_rootstrap.tar.gz
export PATH=/usr/lib/icecc/bin/:$PATH
}

Similar to ccache, icecc requires to add it in the PATH before the standard compiler.
adenilson@macmini:~$ which gcc
/usr/bin/gcc
adenilson@macmini:~$ coolice
adenilson@macmini:~$ which gcc
/usr/lib/icecc/bin//gcc

The final step is to choose which machine will run the scheduler, responsible for distributing the compiler jobs between the nodes. In my case, I picked blackbloat, for making the changes permanent, added in /etc/default/icecc
START_ICECC=”true”
START_ICECC_SCHEDULER=”true”

And all the nodes (including blackbloat, since I doubled it as both a scheduler and a compiler node) should know which network to connect to (I decided to call my network ‘tucks’) thus editing the file /etc/icecc/icecc.conf:

ICECC_NETNAME=”tucks”
ICECC_ALLOW_REMOTE=”yes”
ICECC_SCHEDULER_HOST=”192.168.1.135″

There are other parameters you can tweak. For example, by default icecc will assign a compiler job for each CPU/Core/virtual cpu in your system, so it would run at maximum 4 jobs in each node in the case of an intel i5 (2 cores + hyper thread). You can change that by assigning a value in ICECC_MAX_JOBS filed in icecc.conf. Another tweak is the nice level of each running job process, default is 5 (which is good for not disturbing the normal workflow in a computer, but you can get a slightly better performance by changing it to a lesser value).

To monitor the machines in the cluster, just use: icemon -n tucks (see attached image).

It is important to known if *really* the jobs are being distributed. You can check:
a) If in your machine there are several ‘g++’ named processes (using basically no CPU) and a few ‘cc1plus’ named processes using all the available cpu;
b) If the other node(s) has several ‘cc1plus’ processes;
c) If there is considerable I/O going through the network interface (in my case spikes of up to 2.8MB/s)
d) If icemon shows the jobs moving through the nodes.

I once thought that I’ve configured it all fine and then started ‘make -j30′ with all the jobs running in my machine… needless to say, the machine locked.
:-)

Alright, enough talk, let’s see some numbers… To compile Qt 4.8 from the git repository it takes 34 minutes in macmini, running with ‘make -j6′. By using icecc, and running ‘make -j12′ it compiles in 21 minutes (almost half the time). It is important to remember that there are steps that can not be made parallel (e.g. qmake creating the .pro files, moc running, linking and so on).

For webkit plus Qt5, the numbers are even better: 1h 10m X 19minutes (it is almost 400% faster!). Those 50 minutes *by compilation* can add a lot at end of day.

Finally, it is also possible to combine ccache *with* icecc. To do it, just define your path as: export PATH=/usr/lib/ccache:/usr/lib/icecc/bin/:$PATH. In my desktop, I added the following file in my home:

adenilson@macmini:~/apps/webkit/Webkit$ more ~/.bamf.bashrc
function bamf {
export ICECC_VERSION=/home/adenilson/Desktop/ice_rootstrap.tar.gz
export PATH=/usr/lib/ccache:/usr/lib/icecc/bin/:$PATH
}

Attached you can check how icemon looks like while recompiling Qt 4.8 with 2 different views (starview and gantt view).

November 23, 2012 at 2:58 pm 1 comment

CellarDoor in German plus Debian package

Dear friends

Some quick updates on CellarDoor are due. Since last week, it has debian packaging support in the buildsystem, contributed by Milton Soares.

Simply run ‘make deb’ and you are set: a nice debian package is generated at end.

Next, Adriano Cavalcanti contributed another translation to CellarDoor, German:

Thanks to the fact that German has some bigger than average words, it will require some adjustment in some parts of the UI, but so far so good! As soon I finish some missing features, I’m planning to make a ‘non-hackers’ release.

Currently CellarDoor is available in:

  • English
  • Brazilian Portuguese
  • Italian
  • German

Do you known French or Spanish?
:-)

August 17, 2011 at 1:23 am 13 comments

CellarDoor got its second translation: Italian!

Friends

Just 1 day after blogging about my pet project CellarDoor, I was contacted by Francesco Frassinelli asking about how to make translations.

The result in the next day can be checked below:

Of course there are some places in the UI that we will need to make minor adjustments, but it certainly is progressing really fast (except for minor UI code glitches, the Italian translation is done).

Do you speak German or French? Want to contribute to OSS/Freesoftware? Let me known.
:-)

August 8, 2011 at 2:16 pm 1 comment

Presenting CellarDoor

Last January I was talking with my friend Wilson Prata about applications. We have partnered a couple of years ago when creating amora (which by the way needs some care urgently, but this is another matter) and he presented to me a concept for a nice and cool new app: CellarDoor.

What is CellaDoor? Well, it is a wine app. Have you ever started a conversation with someone that also appreciate wines and then failed when trying to remember the name of a good wine you tasted a couple of months ago?

Or what about easily exchanging a wine recommendation? Trying to keep notes in a restaurant napkin is not really much effective.

Trying to address this and other user cases, I started to work in the mockups that he had at time. A great UX designer once taught me the value of close cooperation between programmers X designers to create something that looks good and performs well (and I honestly believe that the best way to create an app is to have at least one designer aboard since the very beginning). This is a different approach than the traditional hack-hack-hack then later ask a designer for some cute icons which is, with some exceptions, the rule in OSS/Freesoftware world.

Unfortunately, I lacked enough free time to progress quickly, but I believe that the app has progressed well enough for a public release. You can checkout the project’s webpage.

So, what are the current features? Here they are:

  • good looking UI with nice usability
  • create a wine card with basic information (year, name, vineyard, etc)
  • filter by wine type (e.g. red, white, other)
  • persistence of data in a sqlite database (which by the way you can edit in the desktop)
  • Supported platforms: Linux, OSX, Windows 7, Symbian 5th and 3 (e.g N8, N5800, etc)
  • snap a photo of the bottle/cork in supported platforms (Linux, Symbian). Persistence of this photo is my todo list (hey, I didn’t say that the app is completely done!).
How it looks like? Check it (running in OSX 10.6):


== What about the technology? ==

The magic to support such varying OSes (Linux, Window, OSX, Symbian), form factors (Mobile, Netbook, Desktop) and resolutions (from 360×640, ranging in 1024×800 and up) is that I used Qt/QML for the UI. At time that I started, Qt Components were not ready yet, so I got to implement my own (probably buggy) widgets like a combobox (based in joint work with my other friend Ricardo Sato) and a calendar widget (coded together with my friend Igor Trindade), this last widget deserves to be pictured bellow:


== What is next? ==

A long backlog indeed waits in the issue tracker of the project. Between those, I believe that next steps should be:

  • Packaging: for symbian I have it done (self signed), Window7 I played with WiX to create an installer but I need help for testing. OSX packaging (.dmg) and rpm/deb help would be greatly appreciated;
  • Translation: it currently supports English and Brazilian Portuguese. I believe it would be cool to support other languages (French, Italian, German);
  • Coding: there are several features that would be awesome to have, if you are interested, let me known.

So, since ATM there aren’t public packages yet, I guess this is a ‘hacker’s only release’. What you need to compile it is Qt 4.7.x and if in Linux, Qt Mobility 1.1.

Concerning the license, it is good and old GPL v2 code with CC non-commercial for the artwork.

August 6, 2011 at 2:01 pm 2 comments

Long time no see you

It is being almost one year without posting in my blog… What else to say, besides I have being busy? Since my last post, I have:

a) Trying to be a not so lousy father;

b) Led 2 teams in 2 different projects at same time at OpenBossa (both non-oss, targeting Symbian and Maemo respectively);

c) Visited Boston, Brussels, Miami, London,  Bristol, Jericoacoara;

d) Improving my old motorcycle with new accessories;

e) Bought a Brazilian off road “car” and travelled through the country side;

f) Moved to a new apartment, with space for a small office;

g) Since just motorcycling is not enough, tried some new things:

h) After learning QML, decided to write a new pet project (details in the next post!)

i) Reviewing and merging several patches in libgcal (news soon!)

And probably some other stuff that I plainly forgot. Now, I’m planning to post once in a while to not let my blog to collect dust… after all, like I said way back in September 2009: “… having a half-alive, half-dead, zoombie-like blog is worst than having no blog at all.”.

August 5, 2011 at 10:44 pm Leave a comment

Amora: 14001 downloads

Around 2 years ago, I did the release of Amora (A mobile remote assistant) for Nokia smartphones. This started as a pet project, mostly driven by my own requirements to have a good software for reliably controlling slides and movies using my cellphone through bluetooth. It has a server part, installed in the desktop (written in ANSI C) and a client part, installed in the cellphone (written in Python for S60).

Recently, I haven’t being really active developing it, mostly thanks to some factors:

  • At the time, I was waiting for PyS60 2.0 being released (and it took a long time to finally being made public);
  • This is my perception, but I feel that there is a shift from python to javascript as a scripting language in general;
  • I have being waiting for Qt in Symbian starting to support some features required (like bluetooth, for example). There is a QBluetooth project, but it requires some special capabilities to even install in a real device (and AFAICT, there is not an official build of it for third-party developers to use, say like Qt mobility);
  • Finally, I have being quite busy with other projects.

Last week, while checking the project’s webpage, I noticed this:

14001 downloadsNot too bad, hum? If you consider that from all the demographics, it targets only the Nokia, smartphone users (3rd and 2nd edition), non-touch, that runs linux as desktop (i.e. a subset of a subset of a subset of…). There is the added complication that the client is also available in other websites for download, so this number probably is not that accurate.

I guess that the fact that it followed the Unix philosophy (“do one thing, do it well”) and the great artwork (provided by my friend Wilson Prata and Alexis Younes) helped. And the fact that it is included in several Linux distros too! Special thanks to all the pacman (package mantainer) who packaged amora.

Amora background while connected

ps: initially, I thought about naming this post “Amora: 14k downloads”, but that would be incorrect, since 14k == 14336.

September 23, 2010 at 6:33 pm 5 comments

Older Posts


Categories

  • Blogroll

  • Feeds


    Follow

    Get every new post delivered to your Inbox.