It all starts as a normal Monday. Last time you operated with your system, everything worked fine. And then you find it, a zombie lurking in your tasks.

$ top

top - 12:49:16 up 2:30, 6 users, load average: 0.18, 0.35, 0.42
Tasks: 195 total, 2 running, 190 sleeping, 2 stopped, 1 zombie

It is time to find the zombie process by running the following command in Terminal:

$ ps aux | grep Z

1001 6286      0.0     0.0       0       0 ?      Zs      12:10 0:00     [adb]

So. The Zombie is an adb command. It does not take any CPU or memory, but it blocks your adb from working at all. Killing it with $ kill -9 6286 does not help. $ killall -9 adb does not help either but still the Zombie adb blocks development. It is time to find adb’s parent process and go for it.
You can find the parent of the Zombie by running the following command in Terminal:

 $ pstree
pstree output

From the pstree you can see, that the parent of adb is java. So, time to prime your cannon and kill the parent process.

$ killall -9 java

After the parent process has been eliminated, the zombie process is also gone.

$ top

top - 13:04:18 up 2:45, 6 users, load average: 0.84, 0.79, 0.63
Tasks: 194 total, 1 running, 192 sleeping, 1 stopped, 0 zombie

And now, you can happily return to what ever development you were doing.

yay! Finally here, my first GUADEC!

A morning flight and arriving in time for lunch. Starting out with lunch was nice, seeing GOPW students and GSoC students all at once. Diego had come up with a game for the interns. So we were teamed up and for the next two days we will run around the venue and ask silly questions, so please, spare some of your time and share your wisdom, weather it is of your first GUADEC or about the Swedish Conspiracy.

OPW is nearly finished, but my work with the documentation on the other hand is not. After you have opened the door of documentation you can never really close it. There is always some room for improvements. Being introduced to a community thorough a program like this is brilliant. Initially, you have the brand of being a newbie and you are allowed to make all the mistakes and ask all the silly questions without feeling embarrassed.

My project, JavaScripter’s guide to GNOME has found it’s target, the developer docs. Talking about the developer story in Brno formed the idea that we need to have a staggered approach to the docs. Something for the beginners and something for more advanced users, so something for different skill levels. This way we can attract more people with different skill sets. If we can get to developers in an early stage, well have amazing developers later on with thorough knowledge of the platform from a longer time period.

For me the defining moment in this project was the Brno hackfest. That event sealed the feeling that I have found something I feel I belong to. GNOME, after the hackfest there is no way you are going to lose me, whether you like it or not!

The leap to become a developer has been a joyful one, with the necessary WTF moments. I have learned a lot and I still keep learning new things every day. I can’t emphasize enough of the meaning of the hackfest for me, it made all the difference, so all the future students should be brought to a hackfest as soon as possible. That is the way you get to keep us. For the future OPW and GSoC interns I have just one advice: enjoy.

My transition from a GNOME user to a developer has been in progress for two months now. I’m enjoying the challenges, but one constant annoyance has been bothering me along my journey:

The transition from user to developer seems to assume that in between I have had time to hack Linux for 10 years.

Well, I had a total of 0 days for that. I have grown up with the pleasure of not needing to know all the mysterious commands in terminal to get my Ubuntu running. Yes, I have memorized a couple of handy ones (killall -9 the programs!) but as a whole I’m a GUI-girl. I love to make small apps for myself to use, I like coding, but still without the OPW I would have given up already. For me the stumbling block is that the leap from user to developer is huge!

The thing that prompted this post was the setup for JHBuild. I felt uncertain and there were many things I wouldn’t have dared to do without the help of a friend. My dream would be to able to concentrate to the main thing itself with necessary information available without the presumption of being a hardcore Linux hacker.

There is need for both kinds of documentation: for those who are familiar with every nook and cranny of GNOME and Linux, and for those who have just had the great idea that they could have something to give to this community. I’m working towards my dream of having the latter, and I hope my documentation efforts will make this path easier for the enthusiastic hackers that come after me!

See you soon in Brno!

Working with small JavaScript apps for GNOME3 has led me to a wild exploration around internet, the quest for knowledge. The quest led me to trying to figure out two things – how to use different files from the same folder in your JavaScript app, and how to make asynchronous HTTP requests. I can tell the quest was a tricky one but now I can present you (queue dramatic music) my findings:

The first problem was brought up by wanting to separate asychronous calls to a different file. How can I reference the other file in my gjs code? The solution ended up being very simple. Just replace the normal gjs yourapp.js with this:
$ GJS_PATH=`pwd` gjs yourapp.js

in terminal in the folder your files are. Then the file can be included simply with:
const SomeClass = imports.myotherfile;

Where SomeClass is the variable that will hold any functions exported by the other file (by having those functions defined into the global namespace there), and myotherfile.js would be the name of the file.

You can see what keys are available through imports by running this JavaScript code through gjs:

for (i in imports) {

If you want to distribute your files in different folders the GJS_PATH environment variable must contain the correct path.

As we see, pretty easy but hard to come by amongst all the information of internet. Maybe one more post about it will ease the search for the next person trying to figure this out 🙂

Then we get onwards with our asynchronous calls. HTTP get, using async libsoup. Yet again a simple thing but hard to find.

first you need to import Soup to your code:

const Soup = imports.gi.Soup;

then prepare one asynchronous soup session

const _httpSession = new Soup.SessionAsync();
Soup.Session.prototype.add_feature.call(_httpSession, new Soup.ProxyResolverDefault());

then you decide what you want to get and where. Here I’m getting weather information for Helsinki Malmi airport (ICAO: EFHF) using the GeoNames web service:

function getWeather(callback) {
  var request = Soup.Message.new('GET',

Once you’ve prepared a request Soup message, you need to queue it, and provide a callback that will fire once the request has been handled.

It is good manners to handle both successful and failed requests. And when the information is in your hands, it is a good idea to parse it to proper JavaScript data structures:

    _httpSession.queue_message(request, function(_httpSession, message) {
      if (message.status_code !== 200) {
        callback(message.status_code, null);
      var weatherJSON = request.response_body.data;
      var weather = JSON.parse(weatherJSON);
      callback(null, weather);

A successful response looks like this:

    "weatherObservation": {
        "clouds": "few clouds",
        "weatherCondition": "light snow",
        "observation": "EFHF 101150Z 14002KT 9999 -SN FEW040 BKN050 BKN070 M05/M06 Q1016",
        "windDirection": 140,
        "ICAO": "EFHF",
        "elevation": 28,
        "countryCode": "FI",
        "lng": 25.05,
        "temperature": "-5",
        "dewPoint": "-6",
        "windSpeed": "02",
        "humidity": 92,
        "stationName": "Helsinki-Malmi",
        "datetime": "2012-01-10 11:50:00",
        "lat": 60.25,
        "hectoPascAltimeter": 1016

And then it is just the question of how to use the information.

This post has been updated according to Owen’s suggestions in the comments below.

My first reaction to the new GNOME 3.2 was that I hate it! Resistance to anything new lives strong in me, apparently. Then the realization kicked in: I can make it work exactly like I want. Modifying the JavaScript-powered GNOME Shell is as easy as hacking a web page.

And here came the extensions, and then the modified versions of existing extensions!

All of a sudden, after an hour of first whining and then hacking, GNOME 3.2 feels like home and I’m actually liking this ease of modifying my desktop to my preferences. This desktop is mine and I could have pink flying ponies in it if I wanted to. Brilliant!

To get all things going you just need a few easy steps.

  1. Load and install an extension from https://extensions.gnome.org
  2. Fork the extension project that you want to modify from git or wherever
  3. Make it your own
  4. Save your progress
  5. Run $ cp -r file_where_your_extension_is ~/.local/share/gnome-shell/extensions/ on terminal
  6. Reload your desktop with Alt-F2 and to the prompt r. If Alt-F2 doesn’t launch the prompt, fix it with this.
  7. After few iterations enjoy your own modifications to your desktop!

The looking glass debugger is a useful additional tool that can also be launched from command prompt. So, Alt-F2 yet again and then just type lg.

And there you have your tools to hack your browser-like desktop an inspector and a reloader. Happy hacking, everyone!

GNOME and JavaScript

The plans for the JavaScripter’s guide to GNOME 3.  (or the cookbook as I call my project now) are advancing.  The initial roadmap was layed this morning with Cosimo Cecci. Looks like I shall first dive into GNOME, explore the platform, read a lot of code and try to identify some patterns which are more common or important than others. Based on my views I will make a draft of what should be included in the cookbook.

On Tuesday I participated in Helsinki’s first JSmeetup. The thing that suprised me a lot was the fact that nearly no one knew of the possibility to write programs for GNOME with JavaScript. I promised to give a small presentation about the subject in February when my cookbook is looking a bit better.  Making all the different possibilities known to developers out there is an important task we have to deal with.

First week on work is finally happening and I’m happy to work with this project. Taking a plunge to GNOME with a wide smile on my face!

Shots towards GNOME 3.

New and exiting adventures ahead. I got GNOME Outreach Program for Women internship. I’ll be making a “JavaScripter’s Guide to GNOME” starting on December 12. The idea behind the guide is to enable web developers to utilize their skills in GNOME 3. development. I would explain how to structure an app, how to create windows, add content and functionality to them, and how to connect with various services of the platform, and build the necessary project templates to support it.

I believe that with the help of my mentors Cosimo Cecchi and Johannes Schmid I’ll be able to make a guide that will truly ease the way towards GNOME 3.  And as a bonus I’ll have a chance to get to know a new community and make some new friends.

Hello Android

And all of a sudden after Friday my Uni project with Java is much more meaningful: porting my last summer’s GSoC project The Tablet of Adventure to Android. Here is how it looks now:

What works:

  • Getting (and following) user’s location
  • Calculating the day’s geohash for the location
  • Displaying the geohash and user’s location on the map

What is still missing:

  • Social features

You can follow the progress on GitHub.

I have to say testing location based games is more fun in the summer time 🙂

Sleepless, browsing through the internet. Noticing that someone in  Singapore is on their way home. Joining the adventure just for the fun of it, not moving out from my bedroom 🙂 Wishing the adventurer nice journey to destination.