Planet MeeGo day #1 - The Dark side of N9, or : trust your instinct, n00b!

So!
I have been tricking around with N9 for a while now.
I must say.
This is a great Phone (if we consider it should have come out back in 2010/11)!
This could have been a great OS!

So I have developed so far two applications, LINKer, and BWizz (both are available in free and paid versions from OVI/Nokia store, btw).
In chronological order, they manifested as :

1. BWizz, a bookmark editor.
2. LINKer, an utility which gives you access to any file on your Phone, directly from your home screen (which originally only allows for Apps / Applets / URL bookmarks).

Whilst the first one is a "normal" QML-based application, the second one goes a step further, and dives a bit more into the wreck of MeeGo, specifically in the Share-ui capabilities of the OS (which I personally like as a concept, but is nothing new, as Android and now BB10 has as well).

Somehow, all this time I had been working with MeeGo, it felt as if I was working with a huge woolen ball;
twisted, complex, confused. The main reason for this feeling is most likely due to the fact that I could never get ahold of the "big picture". Already documentation is so fucking scattered around that your stamina will drop! There is harmattan-dev, when it is not offline, that is, and then there is the MeeGo Wiki (with it's own forum), the Maemo forums, the Qt documentation, some blog here and there (including this), the code base on gitorious - which btw is in the end the best resource for everything, really; the power of open source was strong in this OS indeed!

You would say with all these sources, the clearance (clearance, mind you, not coverage) about the OS is top-notch. Wrong! This whole scattering causes only frustration and loss of precious time spent jumping from one location to the other, trying to figure out which one is the one containing what you are looking for. For some kind of destiny joke, even Google seems to be obscure  So, if you were looking for information on architecture / QML / Qt, then most likely the Nokia pages in harmattan-dev are by far the better ones. For anything else, and I really mean anything else, everywhere else but harmattan-dev is a better place.
"Thank God there is everywhere else then", you would say. Wrong againg. harmattan-dev is the only place which actually has some structured information (albeit still messy and sometimes very, very vague).
So, whilst harmattan-dev is the normal starting point in your Journey To MeeGo,and is a good strating point,
since it covers every part required to publish a QML / Qt application to the Nokia store, everywhere else is nowhere else. It is a non-place! As you take a leap of faith and decide to step out of this "perfect Nokian Qt + QML" world, in which everything is perfect, but everything almost never works as it should, you will notice the even the normal laws of Googling do not apply anymore! Pages with the most hits for your search terms will not appear on Google's main page anymore! You will find yourself treasure-hunting together pieces of information for a certain topic from the most unexpected locations, and in the end you will still be back at square one because in the mean time the reason for the search will be erased from your mind. And this for every single problem you face. For example, Maemo forums is a great place to find even very obscure information tidbits of various topics. If you know what you are looking for. How do you know that? By trusting your instinct. Because that is the way it has to go.
After LINKer, I felt something was missing. In my decent experienced IT life, I have seen may OS'es, and somehow always managed to get a good glimpse of how they worked and what was going on "behind the scenes" in a fairly fast time. With MeeGo, this was not the case.
 I had made two applications. One on QML (BWizz), which in my opinion was already quite deep (based on Qt Plugins and so on), and the second one (LINKer) based on lower-level Platform services (Share-ui and libContentAction). So by then I had a pretty clear idea of the structure; and I started toying around with various concepts for my third application. For this application, I decided I wanted to make an overlay. An overlay like the notification banner, for instance. And this decision, like some crazy curse, or spell, opened up the dark hearth of MeeGo in front of me. There was no way to find how to make such beast in QML (QML requires a window, which I did not want). So, I had to start looking elsewhere.
After some initial lookaround, it became clear that at Nokia-(Platform) level I would have not found what I was looking for.
There must have been more to it!
So I decided to turn to the Gitorious codebase of MeeGo; as google kept on pushing up these results and as I am a n00b. And there, in all that which seemed to me like a pile of abandoned books, ruins of something that should have been but was not, I started searching through code and code. And guess what? The first thing I noticed, was that there was very little QML. NO QML! What the hell? I told to myself. N9 is supposed to be QML based? So wasnt I supposed to be able to make everything in QML? Where was the shiny and fancy, easy-to-use Nokia world of QML? Where were all the quick components? Why were they not used? Why was here libmeegotouch, meegotouch, contentlib, theming, a complete separate (MeeGo-) widget etimology based on Qt, buried and hidden away? Why did these MApplication, MButton, MLabel, and on keep on popping up? What was this...second personality of N9?
It turned up there was much more than QML. MUCH more than that.

BB10 screenshots from Alpha Device

It seems the easiest way to take a screenshot from the alpha device is to keep the volume up and down buttons simultaneously pressed! Wow!

LINKer goes BlackBerry!

Startin today LINKer is available on BB10!!!

http://appworld.blackberry.com/webstore/content/21197956/

Get it while it's hot! 

Android apps

LINKer is now available on Android!
Grab it!

Walk the line : The hard way of the negative feedback

Today I was confronted heavily on many aspects of some tools (which I will mention as "ToolX") I have implemented. I will put this as "feedback" as calling it "critics" is limiting (it was not all disruptive but also constructive).

Anyway; the sense of it is simple : getting feedback is easy; taking it is hard.
The first reaction to feedback is usually very well described by the following situation:
You sit at work, a co-worker comes up to you.

"Hey xx, I have a problem with tool xx. It does not do it's job."

I am pretty sure that this situation hits (or has hitted) alot of us.
Out of the frequency this event happens, you can give a score to the value of your work. This is why it is important to not just say the following :

"What? Impossible, my tool xx is awesome and works!"

 or

 "You must have used it wrong!"

 Which, translated into practical sense, equals to NOT listening.
 An answer like the following:

"What is the issue?"

or

"What's the matter?"

would probably be more appropriated.
So this seems easy so far - unless you have attitude problems (like myself); but then it's bad luck and failure until you learn your lesson (which might take some time, I tell you).

So, assuming your colleague did not run away chasen by you, the next thing you will have to figure out what is wrong with ToolX. Is it working? Yes/No? If no, what is the cause? Your colleagues wrong usage of the tool? a bug in it? environmental conditions (for example file shares offline...)?
In the end, alot of issues to go through. Assuming there was actually an issue - either in the user's usage or in the tool / environment required by the tool to run, the result might be :

"Ah, I did not know I had to do it like this"

or

"Ah, there is a bug!"

or

"F*ck, why is this server offline?"

Anyway, the outcome can be various.Usually if a bug is found, a discussion about the tool might emerge, and if the galaxy stars happen to be in the right configuration, you might be as well as lucky as being able to collect some feedback on ToolX. The form of this collection is purely passive; meaning the User will give a (usually oral) list of issues that he / she has encountered during his/her life making use of ToolX. See, here is the first challenge: Organizing feedback transfer. But let's not focus about that, there is plenty of documentation on the topic already.
What I want to focus on, is the magic moments of the conversation in which you will get negative feedback on ToolX. Why? It is easier to put it in a metaphor:
a feedback collection (from your point of view) is a race that your tool is being putted into, to evaluate it's performance. If the tool fails to achieve the race's goal (which it probably already did, for an example in the situation given above) or completes the race poorly (which means the User's list of bad feedback is LONG), your tool is most likely not up to the task
This reality might hit you; but also, you might not even hear it, because your self-protection mechanism will automatically switch the areas in charge of common sense of the brain off.
So the reaction can be two fold, either you listen and do not take action (because you did not really listen to the feedback), which I will herein call SCENARIO#1, or you take the reality: you have a shitty tool and do something about it, which is SCENARIO#2.

So far for the consequences. But how to be able to decide which of the two abovementioned outcomes to go? In the case of SCENARIO#1, you are obviously not in control of yourself anymore (at least not directly), because you will simply ignore the input from the User. Do not get me wrong, you will still hear it; but it will go through your ear (in through one and out from the other) like air.

The solution is being able to recognize when your brain shuts down.

Whenever you get feedback, ask yourself:

- how many questions about the feedback have I asked?
- how many valid feedback points (out of the ones mentioned by the User) have I collected?
- how much chance for feedback have I given to the User?

I think the most tricky being the third one:
Usually, on negative feedback we react with defensive walls or "counterattacks" like

"No you did it wrong" 

or

"No the server was down" 

or even

"You do not know what you are talking about" 

and on.

The more of these whe shout out, the less feedback we have collected, the more we are sliding in SCENARIO#1.

Any of these "counterattack" reduce the chances of feedback for the User, for various reasons.
It makes absolutely sense to let the User speak. Even if his thoughts are nonsense, let the User speak.
You can decide later on what to do with it (provided you remember it).

I think this could be a good reminder for myself. Feel free to use it for you too, if you think it might help :).

LinkStation ROCKS!

So it happens I am starting to have some code laying around.
On my laptop. From 2007. Commercial code.
So I figured it is time to get a decent safety solution.
At work, we used this LinkStation Duo (or something) from Buffalo.
I was quite impressed, because once you get into it, it is almost a fully-fledged linux system.
So yeah, armed with the good experience earned on the LinkStation Duo I decided to go for a similar box,
and was lucky enough to hear from a colleague that he was selling this LinkStation LS-WXL.
I did not miss the chance, picked it up, brought it home, installed it, and worked my way into it.
It took some time, but thanks to the good articles over @ Buffalo NAS-central it was more or less straightforward.
So, I have hot source, and need a place to store it. Did I say SVN?
Piece of cake!
By following this link now I have a fully-fledged NAS running SVN :). Worktime? 1 hour! :)

N9 Apps for everyone!

Let me showcase you my N9 apps here!

BWizz is a simple and efficient browser bookmark editing tool! Export, edit, delete bookmarks of Firefox, Opera and the N9 inbuilt browser!
LINKer transforms your home view in a full desktop! SHARE from any SHARE-enabled application documents, images, bookmarks (for example Spotify URI's) directly to your homeview and access them with one click!