Pocket Freemind, Freemind on PocketPC

PocketFreemind is the first open source (and hopefully not the last :) ) project I've joined and the only one I took so far. I took a plunge since I do many critical stuff in Freemind and need them to be mobile. The state of PocketFreemind at that time is quite usable but it missing some feature that is quite substantial to the personal-semantic-convention that I use in the desktop version e.g: red and green font, icons.

I took some time to catch up and start adding the needed feature (thanks for Peter Carol that has started this project and already code some quite easy-to-work-with codebase). It was really fun and interesting (got exposed to windows mobile development). After I got the very-needed feature I needed, I took the time off due to, as usual, work and life.

I am still looking forward for some more spacious time to start coding it again. There are still some features I had floating in my mind that I really like to have it implemented and there's also the Freemind 0.9.0 support e.g : node with attributes that will be really interesting to explore.

It still uses what's is provide by .net regarding TreeView and Node, that's why you still see something funny like square block on node without icons (actually, without node it will be blank, but I add a blank square icon for node without icon to help with the visual since it will look really wacky without it). More exploration on doing custom drawing of node could, at least potentially, make things prettier.

So, if you got the need to sync your freemind file with your PocketPC, give it a try.

Budget Time with Time Block

How do we materialize our priority in our daily life? in the case of money people make budgets, in the case of time I think make routine time blocks would do it.

When we spend without budget and bookkeeping we usually end up wondering where the hell those money gone.Similarly, without allocating exclusive time to do something routinely I don't think we can feel sure we have already "walk our talk". When I say coding should occupy 80 percent of programmers time, then I would need to prepare an 80 percent of my working time to do just that with as minimum fragmentation as possible. For other responsibility I would then need to allocate another block to do them in batch thus minimize the overhead of context switching.

Here's an example of the time blocks :

• 9:00 - 12:00. Code : the most critical tasks
  
• 13:00 - 15:00 Code 2 : more explorative ones or continuing stuff from block 1
  
• 15:00 - 17:00 Mails and anything else
  

It's like creating a program for Television. If you're a News Channel, you probably have large blocks allocated for live news, certain amount for some documentary and a little bit for anything else. If you are a Software QA staff you should spend most of your working time crashing the system all the time and left almost none to anything else (definitely not even a second for befriending the poor developer :) ).

This requires that our tasks be pooled into certain system based on the block/context e.g: GTD, so when we are in certain block we pick a task only from that pool. Anything come our way when we are in certain block should be pooled into this system to be done later on it's block comes.

Of course, like diet, this would require someone to be committed to it if he want to see some difference. But unlike diet, people won't get fat if they cross the line, at least not directly (you know : missed deadline -> stressed -> eat a lot -> gain more weight). However, if you commit in doing it other people will start to pickup your rythm and will adapt to it and it will make things easier by time.

Allocate exclusive time block should be natural if someone is sure about what he think is important. It won't always means easy but the gain is worth it : steady progress in the area that is important can become something more common and not something that come by occasionally.

Vista ATI Display Driver Problem

Update (2008-06-08) : I updated to version 8.476.0.0 (28/03/2008) and the problem is no longer there. Case closed.

I have used Windows Vista several months now. Despite it's several shortcomings (and bad reviews around the net) it is quite usable in my case. However, one thing still really annoy me : the ATI display driver problem. Occasionally the screen would go blank and the message below showup :


I usually can get back to work fine after it happen. However, using recent drivers the problem is really bad, the driver reset would go on several time and ended up with the blue-screen-of-death (haven't seen this for quite a while before using Vista). I am currently stuck with driver version 8.390.0.0 which come from June 2007, otherwise the bluescreen would appear twice a day minimum.

I have tried any appearing driver updates, so far it's not solved yet. It's not that a major problem though, I can still work fine (old driver that works is enough for now), it's just that I think I can sympathize better with people having problem with this OS :).

Application Level Programming in C++

C++ is a language that you could twist to almost any form of programming (with a cost, of course). You could program with low-level-ness that is only one step away from assembly language and on the other extreme you could build the huge common-user-centered application with all it's bells and whistles. Here I would like to elaborate about the later.

Now that we have Java and C#, it's hard not to think application-level programming without getting them into the discussion. Doing the same thing as C# code would then mandate the C++ programmer to at least review factors that makes them widely-adopted (and even better to try them deep enough to really "get" it) and take some lesson.

That being said, I think to be able to compete in application-level programming using C++ i.e: use C++ to get the performance and flexible lower level API but still able to avoid getting stuck and wasting time in micro problems (pointer anyone?), is to "emulate" the virtual machine e.g: JVM, .Net.

Clearly, what I mean by emulating is not to make another VM or code a scripting a language (most language written in C/C++ anyway). What I mean is to prepare the environment, libraries, framework, tools, build system, etc.. so that you only concern with matters that most people using language like Java is concern too with other thing handled by your manually-crafted VM. Those things should be assimilated, glued and setup with rigidness to the point that we can take them for granted to be working and the use of them is made semi-automatic in our daily typing/coding.

With existing components available now, you could already emulate almost what the Virtual Machine offer albeit with a little more hard work on your part. If you think the gain is worth it then many things already available to you.

For example, using naked new and delete can be considered suicide if your aim is to make an application (hint : boost::shared_ptr). Iterating collection using Functor or using old-style for (incrementing index) would make you hard to match readability of C# code (hint : boost::lambda). Manually editing Makefile if you aim to make big application could cripple your speed when something messed up with the makefile along the way or it become an unmaintainable monster (hint : CMake, Rake, Ant). There are already libraries and tools to help you match those kind of things that many other offer in VM-based language.

Just because you have to use C++ does not mean you can not use conceptualization, abstraction, modularization that is used by higher level languages and put them to good use in your own case and situation.

Track Coding Session with Freemind and JEdit

Coding session is an activity that could fill your brain resources pretty quickly. You need to hold a lot of things in your head at one time. I find this tiring and stressful if not being helped by some tools to act as process scheduler and/or swap "device" so my RAM could have lots of space for the micro task.

I use mainly Freemind and JEdit for this (in conceptual level : a Mindmapping and Text Editor application) with pencil and paper ready for emergency. The use of Freemind is basically similar to what I wrote about tracking internet search only in this case it is used to track task, subtasks, subsubtasks, subsubsubtaks while coding. JEdit is handy as a "buffer" for codes, notes and other things that is less hierarchical in nature.

Some trick I find helpful so far :

• Don't branch out too deep. Try to make spawned task as a sibling instead of a child of current task, if possible.
  
• Try to do one task within one hour or two hour max. Keep subtask/subtask, if any, within 15-20 minutes. I use Activity Timer gadget to help with this.
• Use shortcuts, colors, icons to make the overhead of entering/typing small but still maintaining clarity.
  
• Attach the elapsed time of a task for evaluation. It's a good source for better estimating later and for better divide-and-conquer skill. Here's my own convention look like :
• Dump code snippets, notes, deleted code to JEdit, it could be useful later. I also find this better, more flexible and more dependable than to rely solely on undo/redo of IDE.
  

This setup of tools and tricks help me work in flow, tackling one small task after another without worrying too much about other things at the same time.

Combining Trac and XPlanner

I wrote sometime ago about how using issue/bug tracker (Trac) and progress tracker (XPlanner) is really helpful, at least in my case. It will be really good if those two really integrated, but unfortunately it's not the case right now. We need to "integrate" them manually.

Here's the main conceptual merging I have made between them to support the concepts I am using :

Tickets is Story, Story is Ticket

From here on it's like directing the flow of detail that is stuck in Ticket in Trac, connect it and let it trickle down in to more detail through Story "hole" in XPlanner. Every Story is a Ticket being done.

We could have best of both worlds with this connection. On the trac side we have more strategic view of the Ticket/Story (Milestone, Roadmap, Wikis) and on the XPlanner side we have Progrress/Development detail regarding it (Burndown chart, tasks drilldown, assignments, timesheet).

Some useful mechanism regarding this :

• Make a wiki shortcut in XPlanner to Trac so in xplanner you could type something like 'wiki:ticket/555' or 'wiki:changeset/555' XPlanner and it's wiki system will link it to the Trac's entry. We could do interesting with this like make notes in Task entry that link to certain subversion revision.
  
• Use 1 to n mapping from Trac's Milsestone to XPlanner's iteration. Pick story to be done in certain iteration from it's parent Milestone.
  
• Let all the detail concerning the Ticket (notes, references, updates, troubles) updated in Trac to avoid duplication or confusion. Position XPlanner more for scheduling, timesheet and log-like notes.
  

Trac and XPlanner has a very potential synergy which I think is worth exploring. It seems, by design, both are made to be complemented by the other or something else similar in nature.

Strip File Extension from Filename in .Net

Today I need to get a filename without the extension in .Net. It turn out that it's pretty easy. It's not so obvious from looking at MSDN (going through references for string and FileInfo give unsatisfying result). Being lazy to code this kind of stuff myself if I don't really have to, some googling get me more enlightening discussion.

Surprisingly, the line below return what I need :

Path.GetFileNameWithoutExtension(fileNameStr);

It's pretty straightforward and very convenient. It makes me wonder what people will make next, probably something like :

fileNameStr.AssumeThisStringIsFilenameAndGetItsNameWithoutTheExtension();

that would makes my work easier, although it probably would annoy someone else a little bit :).

Testing and Volatility of Code

When does automating test worth doing and when it does not? one of the consideration I think the is volatility of the code.

The more volatile the code the more it is probably not worth automating, at least not directly. If you just code something to be changed not long after or will be changed quite frequently keeping it automatically tested will be costly. It is not a burden if it is only several dynamic part that we tested, but if there is a lot of them the accumulation of little frequently-changing tests that need to be maintained will be burdensome.

I know, if you use TestDrivenDevelopment, you make test first before any code. However, I think of it in conceptual level. You have to have test before any code, not to have The Test e.g: xUnit-based test. Your test could be in your mind and the value could be the one that your command line program print in console and you do Assert with the value in your mind. It's TestDriven enough for me and for not yet stable problem sometime I feel it's more flexible that way.

My concern here is on the word "automating" not on the TestDriven-ness. Automation is investment and it should be managed so that it gives us benefit more than it cost. Volatile code makes the tests volatile too, so lots of volatile code to test, lost of cost in changing/maintaining those test accumulatively.

There are a lot of solution for this e.g: test it indirectly through more stable code, but the main point is that we could test in a more efficient manner by paying attention to volatility of the code.

Coding Tolerance

Regarding Coding Standard, Instead of following something resembling Coding Standard I see what I have been doing lately is more of from the other way direction : Coding Tolerance. With standard, you define what you want and then define how things should be to meet those. With coding tolerance you start with let things be the way they are and then review what you can tolerate and do refinement when necessary.

Coding Tolerance can be looked as a bottom-up, pragmatic approach to making guidelines in coding. With it, you do not spend time in advance to try to cover all possible things that would mess things up. Instead you allow codes to contribute as long as you can still tolerate it based on your knowledge, experience, situation and condition you try to maintain steady progress.

Tolerating does not mean you start with zero rules. You define only small, substantial guideline at the beginning and refine from there case by case, item by item and refactor/streamline the rules when necessary. You don't judge the code from your coworker or from certain libraries by rigid syntaxtual standard, instead you try to understand why they got the way they are and whether you can still accept it considering your goal. There are many learning experience you'll get from it.

The insights we get from tolerating certain coding style is not just we can go relatively faster in short term (since we focus on getting things working), but it is beneficial for the future too. We could get insights on better way of doing things that we will not get if we just forcing insisting that our way is the right way.

So, the next time you try to define coding standard, try to define it from the perspective of what you can tolerate instead of the usual structure, style, syntax oriented rule. It might give you lighter, easier rule to comply that is still effective.

Switch Between Analytical and Empirical Hat in Coding to Avoid Blocking

Programmers has two hat that he can switch around to avoid blocking when coding. Those two are the Analytical (thinking, elaborating and tracing logic) and Empirical hat (Debug, print and compare values). Without being aware of this, I find that I sometime spend too much time in one mode that if I just switch to another mode when things seems getting hopeless in the current mode it could be a lot faster. Being flexible in switching mode could speed up and ease up the problem solving process. It'll make things more fun too, almost like playing a game.

Being Analytical is when you review the structure and logic of program, class design, association, hierarchies, call sequence and finally find out what to do. Being Empirical is just give the program the input, trace, see the real numbers and values, and review the output.

Blocking in analytical mode is when you find reviewing the structure and logic seems to get you nowhere, the class seems ok, the function and logic looks alright but the output is wrong. Blocking in empirical is when the input and output does not reveal to you any pattern on insights on what's going on.

Our brain seems to need both concrete/empirical and conceptual input in problem solving. The empirical test could help us understand part of the logic that might not get into our attention when relying only on static analyzing. The analytical view could shed us some lights on the problems in it's substantial level that the output fail to give us any concrete things to work on.

In coding, when reviewing why something does not work, I usually start with analytical review and if it's not solving anything, I just start tracing, dumping values, debugging. Sometime in the middle of tracing and debugging I got another idea to review certain part analytically. I just need to remember not to push to solve the problem in one mode if it does not seen to bear fruit and start to see it with another perspective.

Of course, when both are fail, taking a break would probably the best thing to do. But that's another issue and would require another discussion. The point is to avoid being sucked by the problem and utilize different perspective to keep things in control and most importantly, to keep it fun.

Agile and Effectivity : Two Game at a Time

On the book "Agile Software Development", Alistair Cockburn wrote that there are two game running in parallel when people develop software. The two game can be summarized as :

1. Make code that work
2. Keep the code workable

If you ignore the item no.2 you'll get trouble sooner or later with the no.1. You could get away by ignoring item 2 in short time, but in the long run you will pay the much higher price .

I see the two item above parallel with, if not an instance of, the concept of Production/ProductionCapacity (P/PC) balance in Stephen Covey's book "Seven Habit of Highly Effective People". And if you look around for more, many problem following the same model : using tool vs. learning the new ones, adding more hours in one language with experimenting with the new ones.

Defining Effectivity as balancing between P/PC is like defining EffectiveCoding as balancing between Coding/Refactoring.

Track Internet Searching using Freemind

I've mentioned in the previous post that I used Mindmapping application to track my internet search in realtime. The reason is that the search can go out of hand if not tracked like this. We could end up spending hours looking at anything that caught our attention on the search result that is not too relevant to our current task.

Here's how, more or less, my "control center" looks like when I do a research-heavy task :





You've probably guessed the convention already : red for active item, green for done, small gray on notes.

I think the next step for after having a taste of how the searching in internet done and what it can gives us, is to use it with some kind of heuristic and a little discipline. This is just my current way of doing it and I find it quite useful to help focus on getting things done.

If You Want to Program in C, Use C++

There cases where C is chosen as a programming language. When this happen, I think it's better to use C++ with C style programming instead of using "classical" style one. This means use C++ as a Better C, an improved C for functional programming without it's Object Oriented and Generic Programming.

I have seen the code written in recent times that still use C strictly with it's old convention and. I think it's still makes sense if it's a maintenance/bug fixing work, but for new project I think we could improve readability, safety and more convenient coding time.

You could choose to use feature that only improve your typically-used structure like inline function to replace macro or use flexible declaration placement instead of having to declare all of them in the beginning. If you feel brave enough you could use more new stuff like references. You could even use STL's containers without harming your program's "functional-ness" (just use typedefs to hide those nasty template instantiation).

As a guideline, don't use what you don't understand or only have a vague sense of why behind certain construct. When you do, you'll most likely will get into trouble sooner or later.

You could program in functional-paradigm without having to revert to use plain old C these days, just need to get a little familiar with what C++ has to offer regarding it.

Separate Collecting and Action Phase in Searching

One useful idea in GTD is to separate collection and followup/action step. It helps us to not caught up in reactive mode and loose sense of direction. I find this idea really useful when I do searching on the internet. It is even more critical in this matter since there are tons of things that could get you off-balance and distracted while searching things on the net.

First thing to do is to have map and tracking tools of what you need to do. It can be just your mind, but it's better to have helper tools like Text Editor or Minmapping application. Be clear on what you want and put an entry on each query you requested and track what you get from each. Jotting down the query you pass and track the result of each can be a useful trick to incrementally refine your search. The next is to do it in two separate steps : collection and action.

In collection step I only skim each of the links or page and drag them to to bookmark and/or scrapbook (see my post on setup firefox for this purpose). Along the way, when I find any unrelated but seems interesting I just drag them to tmp folder to followup sometime later when there's more free time. Then, when I think I have enough interesting things and the search result seems exhausted I continue with action step i.e: follow them up one by one in a more relax and more concentration on each.

I don't always do it in a clear separation or perfectly like the above, there's occasional time I just follow along with the chain of links. However, having mentally separate the process helps to get more of the links i.e: prioritize which to followup and avoid to get distracted. If we just get along, we might already exhausted and our mind distracted when we unconsciously missed a worthy one or don't have energy to followup anymore links ahead which could have a good info.

Internet is such a big source of distraction if you are not careful. But it will be a dependable servant when you have clear focus on what you want and structure and discipline in handling what it gives back to you. Of course, it's fun to surf for leisure but it's better not to do it at the time you intended to have something done.

Books are Simplified Version of Reality

Reading books is reading filtered and structured knowledge. Compare to other sources like news, articles, forums, it has relatively the highest signal to noise ratio. That value comes with a cost, most notably generalization and omission of some details and context-related materials. Relative to other more "real-time" sources it is more "sterile".

This is why when we read books we feel we got so much information but sometime we are left hanging when trying to implement it in our situation. It's because the details in books are already smoothen out, some parts are simplified, so it is up to the reader to put them back on the reality ground. If I am going to write about some new techniques I would not have enough space to cover all possible cases but only take that I think would be enough to inspire and make a point to the reader.

There's nothing wrong with it, of course. It's just how the books are positioned and made. It's the forums, mailing lists, discussion group and our own experience role to fill in the blank. Besides, it's where the fun lies anyway.

Using Custom Deallocator in boost::shared_ptr

Using boost::shared_ptr in the typical situation is quite straightforward. If what you want is to to have your use of new and delete conforms with RAII idiom you will find it as close as coding things in language like Java. However when you need to use it beyond object that is acquired/instantiated the typical way e.g: COM object, it's when you find it's not that obvious.

It's quite simple actually but the standard documentation can be quite confusing if what you want to find is a practical way to do it. I find this discussion shed a light to this issue quite clearly.

It turn out that what you need to do is

• make a custom deallocator function that takes pointer to the class
  
• pass the function name as the second parameter to the shared_ptr's constructor

Here's a sample code snippet for it :

   1:
   2:void deallocatorFunc(ClassA *p)
   3:{
   4:  //deallocate p
   5:}
   6:
   7:boost::shared_ptr< ClassA > ptr(new ClassA(), deallocatorFunc);

Save Time by Being Clear

People debated over believes, religion, OS, text editor. Many times it's fun but a lot of them unnecessary. We could actually simplify things by being really clear on what we need and expect.

We could end up with debates and confusion when we are not really have one specific things in mind ourselves. We prolong problems by searching in in elegance side while we are really prioritizing functionality, picky about the price while our constraint is really about time, worry about perfection while anything good enough is more than enough to get us going. We stumble upon a fight over people regarding ideology in the process of searching very simple practical things.

We could simplify more by being really clear too about what the other people intention and perspective. We rarely have to be in defensive position when we realize clearly where the other people stand, if at all. People usually have a good point if we know what perspective they use and the background they have.

When we end up trying something we could also save time when we are clear what to use it for. For example, we don't bother checking out the internals of the lib if the part that we use it works perfectly well for our purpose. We only need those part functional and don't care about the rest.

So, be it religion, methodology, tools, libraries, framework. Being clear is a good filters and heuristic to get things that works for us. We'll also save more time that we could use to extract values on whatever we finally choose.

As a final note: sometime just trying things save hours of debating, it also sometimes give us valuable insights that won't come out just by debating, wondering or worrying.

"Toolbox"-based Tools and Concept

The greatest lesson of learning a lot of stuff, trying tools and concepts are not on how it actually solve our problem but, I guess, is on this : It teach us that people and problem are unique and there's no one single tool/solution that can cover all and it's better to have something that is modular, customizable and adaptive.

Even before we start to implement something new we'll probably already see how it has some edges and parts that does not really mirror with our situation. We then pick some part that is useful and left or modify the one that does not.

Learning from this picking and modification, I think a good tools and concept is the one that is more modular and flexible. People prefer to use something modular and flexible to something that requite "All or nothing" approach. It enable people to adapt it more to their situation.

However, for concept and methodology, this modular, toolbox-based approach is also necessary in learning and adapting new things. The tools and concept should enter into our toolbox and not hijack our mind. We should only let inside something that can be a good citizen in our mind i.e: helpful but not destroy our mind flexibility. Intrusive tools and concept should be avoided, or if it's not avoidable should be allowed with care.

This could explain why many people like the concept of plugins or interdependent little tools in UNIX-based system, it allows to play with it more and be creative instead of feeling being overwhelmed and somehow foruced by the tools. This also why some concept or methodologues can be fun to follow when they consist of several interdependent components where we can still see effect of each of them independently.

I prefer toolbox-based tools and concept then the "framework"-based one although it still useful in the cases where they are specifically made to solve.

Pencil and Paper as a Coding Helper

With all the tools available in the form of software, I still always have pencil and paper at my desk. Nothing can beat this tool yet and I don't think nothing will. The existence of softwares would only specialize it's positioning but I don't think it will threaten it's existence.

Here's the task that pencil and paper that I find still unbeatable :

• In coding, you deal with screen, taking occasional notes in physical form instead of fully in screen help to "refresh" perspective occasionally.
  
• Instant noodling, take scrap notes. I use freemind heavily for tracking what I am currenlty doing but when things got really hot, the speed of entering things to it cannot keep up with my head. The physical note-taking can keep up with flow of the mind really well.
  
• Braindump. Even in the not-too-hot situation, pencil and paper still shine in the brainstorming-style writing. For large-scope brainstorming, I sometime do mixing : Mindmap applications or outliner as a main media with papers for more chaotic, instant thoughts.
• Drawing your thoughts. Just try to draw your thoughts in Visio, good luck with that.
  

Even when you feel you are paper-free for good, just try to have notebook within your arms reach. Most prrobably, pretty soon you'll encounter situation where it feels really natural to grab and use it.

It's funny. People who do papers all day need software to help them. On the other hand, I think those who work on software should utilize paper more to help them finish it better/faster.

One Change at a Time, One Queue All the Time

New year, new resolution, changes.

No matter how much I want and inspired to change in certain time e.g: after reading inspiring books, either in specific field like improving coding technique or life in general I can't seem to do it like I want it i.e: one big and lots of changes ASAP.

It seems that when I find out something new and interesting my mind goes "this is so true and now that I know this, there's no way I could do the other way, the change will be natural, tomorrow I'll be a different person for certain". We all know where that story will go.

So far, I conclude that people can only change one tiny little bit at a time and no more. It is true we can have insightful moments or dramatic shock but the most it can do is to change our perspective and how we see things. After them, the next step is to embrace the current reality first and not to jump in picking and throwing some part of our life to be build something brand new on top of it.

I think little thing is big, and big things is little in this case. I look at tiny step, done with care and a lot of of awareness, as a tip of the iceberg where a lot of complex things going on underneath it. In personal level,a tiny change could include changing a lot of assumptions, mental block, facing discomfort. In organizational level, a tiny change is the tip of the iceberg of change in workflow, resource management, office layout. Big change in this case could mean thin effect since the unrealistic feel of it would make the rest of your self/system/organization could only interested only in skim it, get pass the checklist, get through it ASAP.

So, what do we do with all the interesting coming our way so we can follow it up in tiny steps? I think it is best to queue ideas to followup on dedicated list and only pick several item from it to followup at one evaluable time. In short : separate collection from followup. For programmer, it's easy to relate this with issue tracker/bug tracker application. Without them, it's hard to have real and satisfying progress since you will operate always in urgency mode and trashing would most likely occur.

We end up with two things here : do things only a handful we could handle with a lot of care and use queue to put things coming your way. The third would be : fight the temptation to deal with things as it comes, you are in no condition to make the best judgement for it's followup (it's kinda like when you deal with classic sales trick that put you in urgent condition with something like short-term discount or "the price will increase next month" ).