Older blog entries for eMBee (starting at number 6)

presenting nReduce at the beijing open party

Today's Open Party had a low turnout due to strong rain. Nonetheless it still had 11 talks in 4 tracks. Topics were Firefox OS, Geek Park, backbone.js conference report among others.

My presentation about nReduce gathered about half a dozend people. Given 3 competing talks and not more than 20-30 visitors overall this is actually quite a high turnout. They were also quite engaged and asked many questions. Maybe we'll get some more beijing teams when nReduce opens a new batch. One person was also interested in the email-task-manager.

nReduce is an online incubator. That is, the key benefits of joining an incubator: meeting other teams and sharing your experience, as well as talking to mentors, are brought online. Every team makes weekly goals and reports with short (less than 1 minute) videos. Teams group with other teams to work with and then discuss each others weekly progress. Our experience with nReduce was great from the start. Every week we received valuable feedback. A few times our check-in had the most discussion activity from all the teams we grouped with. Our progress is slow because we work on this only part-time for now, but we managed to come up with suitable goals that invited discussion.

We have now reached the halfway point and also reached a significant milestone for the email-task-manager. Until last week we were not clear whether we should start with a webinterface or focus on mobile clients first. The opinions were divided with me siding for the web. But one short comment by Hugh Mason clarified what we should do:

the folk who started with mobile first were forced to focus on the ONE really important feature of their product because of the small screen and the demand for instant gratification that mobile users show. That was really valuable. I'd always generally going for mobile first now if you plan on it being mobile ever
After reading that the goal was as clear as day. We absolutely have to start with mobile. There is no doubt about it now. We need to focus on the features that we can fit onto a mobile screen first, before expanding onto larger devices where we can use the space to add more features. It is also interesting to note that while we found related and competing products, none of those seem to focus on mobile.

Syndicated 2012-07-21 09:46:33 from DevLog

open graphics hardware is not dead

Phoronix declares the death of the open-source graphics card, but i disagree. Now, i am not really following the projects mentioned in the article (though i pay attention when i come across the topic), but i believe that open-source graphics is far from dead and it will come back. I am certain. We just need some patience.

In the long term, since the first computers, more and more sophisticated devices are being created by hobbyists. It is all a matter of the cost of components and the availability of affordable tools. For example, just recently oshpark.com was launched. A site that will print custom circuit boards at an affordable price. This site may not be the first of its kind, but it certainly is not the last. And just like the 3d printers, circuitboard printing is becoming accessible to more people, and it will be followed eventually by the ability to create small batches of affordable ICs, opening up room for more development and creation of open hardware.

Incidently, just today i attended a meeting here in beijing of openbrd. A group of young enthusiastic developers intent on making a completely open version of a miniature form factor arm based computer. (Like the raspberry pi or the beagleboard, but all specs, drivers, etc completely open and designed to allow anyone to build the device for themselves). So they are not designing the chips themselves, but another group like them, in a few years, may. They are meeting weekly in a restaurant in the northwest of beijing. About half a dozen people sat around a table, watching an unscripted presentation and discussing the topic. Today's topic wasn't about open hardware but introduced wget and curl and then by a second speaker, emacs. This group formed less than a year ago, but it is not the first group about open hardware in beijing. Before it, the beijing linux user group was leading an effort to create an open hardware quadcopter. But like the open-source graphics projects, that project eventually ceased (because some key members left beijing). Worldwide, there are many more groups like it. And one day, one of these groups will produce that open source graphics card.

As i said, i am not closely following the open-source graphics card efforts, and it may be a long time before these efforts gains some traction again, as well as the focus may shift to other components in a digital device. But the failure of existing projects to produce a result is a setback, it's not the end. just wait!

This topic is also discussed on LXer. In particular, khamul makes some compelling counter arguments regarding the prospects of accessible IC production.


A short while after this posting the developer behind Project VGA has written a lengthy email explaining why the open-source graphics card is no more. It appears to be that part of the problem was lack of openness from a company supporting the project. And then, just a few days later a university group announces that they are developing an open source graphics accelerator as part of their master thesis.

Syndicated 2012-06-25 07:40:32 from DevLog

can remote teamwork be productive?

Because i usually find potential clients through the internet i am occasionally confronted with the question on dealing with remote work. In this post i will try to relay my experience and hopefully answer some questions.

I will write about four types of collaboration:
Effective local collaboration and effective remote collaboration as well as complete lack of local collaboration and ineffective remote collaboration.
I have experienced all four.

The key to each one is communication. if communication does not happen, it will fail. Let me detail all the types above and explain what i learned from them. Starting with the complete lack of local collaboration.

The situation here was that i was hired to work on a specific project by myself. There was no team, just a manager who was unfortunately very busy. I was seated in a different room and left alone to do my work. The result was a complete desaster. I didn't have enough guidance, there was no oversight, no progress checking, nothing. This was probably as much my fault as the managers. As i said he was busy, and i should have been more upfront to ask.

I believe that if i had done this project from home, it would have been more effective for that situation. When you are in an office it is easy to assume that you are disciplined and working, and making progress. When you work at home your manager will be more concerned to find out if you are really working, and at least check in once in a while. Also working from home makes it more obvious that actual working time needs to be documented as opposed to mentally ticking a clock when you enter and leave the office.

Later, when i started to work from home my first client asked for hourly time sheets. At first i thought that it would be a drag, but then i realized that it was quite liberating because i could take a break whenever i wanted without feeling guilty and simply subtracted that time from the time sheet. It helped with the discipline :-)

The next type is ineffective remote collaboration. The situation here was that i joined a team that was working on a Free Software project at a university. I was the only outsider in that team. I was welcomed with open arms. The personal relationship with the other developers was great. When i visited them we had parties together, and when i joined them in the office we were working together.

But that office became the problem in the long run. As everyone else was there, most communication happened accross the desk face to face, so not only was i not involved in the communication or decisions, i often didn't even find out about plans, goals, opportunities etc...

Not enough effort was made to keep me in the loop and as a result i didn't really see much opportunity to contribute. Opportunity sure was there, and if i had just done what i wanted i could have ignored the communication problem and just send in code. But i like to work with a team, and not despite it.

Now let us look at the types where collaboration worked.

There are actually two types of local collaboration. One is the usual with regular meetings, everyone does their thing, if you have a question you go and ask, you help each other, everything as you'd expect.

The second is more interesting. What was unusual here was that we were 50 people in the company working on a large project with a client on the other side of the planet. All communication was done through a project internal irc server that we shared with the client. Once a day we had a project wide irc meeting where everyone, yes, all 50 odd people, would report on what they were working on. Within 5 minutes there was a flodd of issue tracker numbers and short comments, so everyone got to see what everyone else was doing. The meeting was in two parts: first a plain status report, and then a problem report. A bot was there to track that everyone had made their status report before problem reports were allowed.

The rest of the day, work was done in small teams. Each team had their own daily 5 minute stand up meeting, which was done face-to-face and extra meetings if they needed it.

The office was a large open space, and because of that talking was usually not convenient and if you had a question you'd ping your colleague on irc even if she was sitting right behind you.

Using irc in this manner had another sideeffect. It was simply less disruptive. If you were diving deep into a coding problem you could simply ignore the irc window and you wouldn't be disturbed. On the other hand if i didn't get a response even though i can see my collegue if i turn around i would know that he was busy and so i'd either work on something else else or find another person for my question.

(Here are some articles on why interruptions are bad: http://37signals.com/svn/archives2/the_science_of_interruptions.php http://www.paulgraham.com/makersschedule.html http://www.futurepundit.com/archives/004149.html)

This setup had another sideeffect. It didn't actually matter if you were in the office. If the situation called for it, you could work from home without affecting productivity. Also occasionally some of the senior developers were sent to the clients location, but they'd continue to work with their team from remote.

Because all communication was written, it could be logged, and so you could for example review the irc meeting even if you missed it.

Which brings us to the last type: fully working from remote. Above all else, consider the vast amount of Free Software developed by volunteers all across the world. You can pretty much guess that most of them work from remote. And successfully so. Myself, i am involved in several international Free Software projects and i have worked with clients in new zealand, singapore, germany and austria all from remote.

the most recent project for example was managed using trac with work shared among half a dozend people in almost as many locations in two timezones (6h difference).

we used trac, email, irc, jabber and voip to communicate.

working from remote forces you to write down more, which in turn gives more opportunity to think before expressing something, or to correct it.

There is an interesting paper on this topic called: "Can Absence Make a Team Grow Stronger?" (A. Majchrzak, A. Malhotra, J. Stamps and J. Lipnack), Harvard Business Review, May 2004, pp. 137-144 ( (there are more papers on this topic at http://public.kenan-flagler.unc.edu/faculty/malhotra/))

So it all comes down to the willingness of team-members to use suitable communication tools and make sure that remote team members are kept in the loop. positive sideeffects include better documentation or more doccumentation of informal decisions, a quieter office and more flexibility for the team members without negatively affecting the teams productivity.

This article in itself demonstrates one of the advantages of remote work.

It was written as a direct response to one potential client. now, imagine someone asking me this question in a personal meeting. I'd give them an answer, but it would be much shorter and not contain as much details or even reference links.

So not only did i answer the clients question, but i produced a general document that will answer this question for everyone else.

I wrote documentation.

Syndicated 2012-05-14 18:00:27 from DevLog

better email

LXer today posted an article that compares email to MPI.

What i find interesting about this article is not the realization that MPI is like email, but the reverse, that human collaboration using messages is like MPI. The suggestion to use SMTP as a transport for things much more complex than emails is something worth looking at. It relates to my belief that the instant messaging difference does not come from the new protocols like XMPP for jabber, but from the new client interface that facilitates short messages in a conversational style. SMTP is equally (if not more) capable of transporting these messages. Sure, SMTP is not designed for "instant" messaging. but todays use of SMTP where my local SMTP server talks directly to your SMTP server, makes email is just as instant.

We don't need another protocol, at best we need improved SMTP servers that handle multicast messaging. But the sender/recipient envelope is as simple and timeless as it gets. Any additional data can be added in headers, and here is where there is plenty of room for change.

We can make email messages more sophisticated, with additional headers indicating for example whether a message requires an action, or a response or whether it is merely informational. A reply message could then contain headers to show if the message is a response, or a followup question, or just an acknowledgement of the original message.

All we need for this is to add these features into email clients to allow more sophisticated messages to be sent and received.

Syndicated 2012-03-28 10:29:38 from DevLog

RosettaCode vs Stack Overflow

Stack Overflow is a great site. Every time when a search on a problem takes me there i look forward to the helpful and insightful answers. In ways, posting a question on Stack Overflow is similar to creating a task on RosettaCode.

On Stack Overflow a problem gets posted in form of a question, and people attempt to solve the problem by answering it. Question and answers can be discussed and updated. Once the poster of the question is satisfied, an answer may be chosen as being accepted.

On RosettaCode a problem gets posted in form of a Draft Task and people attempt to solve the problem by creating an implementation in their favorite language. Task and implementations may be discussed and revised until a consensus is found. Once discussion stabilizes and people focus on implementing, the task may be promoted from Draft Task to Task status

The key difference is that the questions and answers on Stack Overflow can be of various qualities. There are lots of duplicates, and not always are the answers useful. On RosettaCode on the other hand the poster is motivated to solve the Task her or himself. Also the goal of all Tasks is to produce a usable implementation, and the discussion does not end when an answer is accepted by the poster but it continues until a consensus for an acceptable task definition is found. And then after that the Task stays active as long as new solutions in different languages get added. Also RosettaCode gets referenced frequently in Stack Overflow discussions

On RosettaCode people are not motivated to answer by getting points but because the answer helps shape the Task and thus ultimately the quality of the whole site. They take ownership of the task by providing their implementation. They don't want to help a fellow with a question but produce something of lasting benefit for all future visitors of the site.

As Stack Overflow grows, it will be harder and harder to sift through all the questions to find the right answer, whereas the growth of RosettaCode will lead to a library of problems and solutions where one can find practical code examples that have a clear relationship to the question (the Task) with several complete implementations that allow for analysis and comparison.

When i have a problem to solve i try to see if it is generic and interesting enough for RosettaCode. Then i formulate a Task, and make an attempt at solving it myself. The discussion often helps me to identify problems that i had not foreseen, edge cases, and different approaches. Every new task includes a lot of learning and goes beyond just solving the immediate problem.

I don't know if the creator of RosettaCode had this kind of use in mind, but i hope he can see the value of this approach. And it is not only new Tasks that get created this way, but also solutions to existing Tasks too. Just in the past week i found three Tasks that were directly applicable to problems i am currently solving. And one of the Tasks motivated me to produce a generic solution to a problem that i had solved in an adhoc manner before.

By using RosettaCode i am not just solving problems for myself, but i help generate solutions that are useful for other people too.

Syndicated 2012-01-09 17:58:55 from DevLog

a replacement for the cal commandline tool in pike

cal is a commandline tool to display a monthly or yearly calendar. It's convenient to use for lookup when there is no gui at hand.

It has a few limitations and irritations however. The most annoying one is that whenever i want to display a different month i have to enter a year as well. If you enter cal 2 it will display the year number 2, and not the month that i'd expect.

This pike version of cal fixes that. If you enter a number small enough to be a month then it will display the corresponding month of the current year.

The pike version has other features too. Thanks to pikes extensive calendar support, cal.pike can handle calendars other than the gregorian calendar. You can see a list of supported calendars in the pike module reference. To use a different calendar, just enter the name of the calendar as a first argument. The only calender from that list that doesn't work is Stardate because that doesn't have any months.

Further, motivated by this calendar task on rosettacode.org i have added support for varying terminal sizes. The program will check the calendar in an optimal with for the terminal. For a calendar with 12 months this means it will either fit as 2x6, 3x4, 4x3 or 6x2 rows and columns. The pike version for that task is btw only the year display. Support for showing a month and other stuff has been removed.

Other features: pikes calendar system supports events to mark holidays. Days that fall on an event are displayed in green. It is possible to choose events by region.

cal.pike is available under the GNU GPL v3. You can download it here

Syndicated 2012-01-05 16:35:06 from DevLog

use rosettacode.org to learn programming in pike

A few months ago i discovered rosettacode.org, a website where various programming tasks are implemented in many different languages.

rosettacode is not only useful to compare languages, but also to learn new ones. You can see how a problem solved in a language that you know, looks like in the language you are learning. Or you can try to implement it in that new language, using the existing implementations as a reference.

For me to learn a new language, i need to be able to do something useful with it. Simply taking a book and doing exercises that are thrown away is not very motivational.

But doing the same kind of exercises on rosettacode is quite different, because the result is useful to those who want to use the solution for comparisons.

Solving tasks on rosettacode of course only works with tasks that are not already solved in your target language. But that is not usually a problem because no single language on rosettacode has all tasks solved. And there are new tasks every week.

For pike there are still a few hundreds of tasks unsolved, ranging from trivial to very hard. So there is something for every level. And don't fear of making a mistake. Your solutions will be reviewed by others, and corrected or discussed if necessary.

If solving existing tasks does not satisfy you, you can also make up new tasks.

Writing tasks can be fun and challenging. But again, no fear. Others will add appropriate questions and point out where your task is unclear or could be improved. That alone is a great learning experience. Then providing your implementation and comparing it with the solutions others come up with is educational. Some people may come up with an approach that you have not thought of, giving you further insight into the problem, and may even cause you to adapt your own solution.

In summary, whether you are completely new to pike or an experienced developer, rosettacode is a place where you can improve your skills, contribute to others learning experience, and show off pikes unique features. I hope you will join me in increasing pikes presence on the site.

Syndicated 2011-12-25 15:02:33 from DevLog

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!