Insanity in a box

Still Alive

Sun, 29 Mar 2009 10:30:10 GMT

Yes, this blog is still alive, although a little... quiet.

While I'm figuring out a good topic to write (and while I flesh out a workable blogging schedule), here are a few pics from the various trips I've taken recently. I've been getting more and more into photography, having bought a DSLR, a Nikon D80.

Palawan:

Laoag, Ilocos Norte

Cebu

Quick Updates

Sun, 16 Nov 2008 16:10:49 GMT

Two things:

Work on tool that will be released as open source. I'm currently finishing up a component that we'll be releasing as open source in the coming week or so, once I get the bits cleaned up and checked in. It's a case of an "itch to scratch", and I'll be using it for a possible work project.
Another haircut. I got rid of my long hair today. That is all.

Discuss.

My git-svn workflow

Sun, 07 Sep 2008 15:03:56 GMT

I recently gave a lightning talk on git-svn at Barcamp Manila, and I thought some people might be interested in my day-to-day workflow when I work on projects.

When I get started on a project here at work, I usually first do a clone of the upstream tree, whatever that might be. I run:

git-svn clone --stdlayout https://svn.orangeandbronze.com/project

which checks out a copy of the SVN repository of project; this might take a while, so I usually go out for coffee or move on to other tasks while it completes. Sometimes, however, I don't want the whole history, so I do a partial clone:

git-svn clone --stdlayout -r HEAD https://svn.orangeandbronze.com/project

This then does only a checkout of HEAD, without history.

When I begin work for the day, I cd to the project's directory in a terminal, and do a status check to see what I've been up to recently, just to refresh my memory:

git status
git diff HEAD | less
git log | less

This gives me a) the status of my current work tree and the branch I'm working on, b) the changes since the last git commit I made, and c) notes from the log history. Sometimes, I'll be lazy and just pull up gitk for the tree, since it gives me pretty much everything above:

gitk --all

The gitk(1) command above allows me to visualize the commit history of the project, which is a boon when trying to nail down when something changed.

Once I know where I am on the tree, so to speak, I do a checkout of master, and I pull any changes from upstream SVN:

git checkout master
git-svn rebase

I usually checkout a branch when working on a particular feature or item. If I'm starting work on that feature, I do:

git checkout -b feature-name

However, usually I have already started on something, and I want to go back to that branch:

git checkout feature-name

This allows me to sandbox different work (bugfixes vs. features). I avoid touching the master branch, and instead work in other branches. Note that these branches are not visible on the SVN side; they're local to my git tree.

If master has changed (i.e. I've pulled in new changes from upstream SVN), I usually want to rebase my work on top of that:

git rebase master

I then bang on the code, making frequent commits for every small atomic unit of work completed. Once done, I review the code (in gitk(1) or by checking the git logs), and see what needs to be pushed. I also take this time to edit the commit history (which I'll explain in another post). When I'm ready to push upstream, I do another pull from upstream SVN (just so I'm sure my code is built on top of HEAD), and rebase. I also run unit tests to make sure I didn't break anything. When I now know everything's peachy and ready to be published, I do a push to upstream SVN via dcommit:

run tests...
git-svn dcommit
git checkout master
git rebase remotes/trunk

The last two lines simply fast-forward master to whatever the current SVN HEAD is. At this point in time, I'm ready to work on another task/feature/bugfix.

Source Available: My hacks to fsp-h

Thu, 28 Aug 2008 05:19:12 GMT

For those interested in my hacks on top of other hacks to fspanel (i.e. my hacks on top of fsp-h), see here. Source code available via git here, git URL: git://github.com/jmibanez/fsp-h-jmi.git.

Xlib, XWMHints, XGetWindowProperty and 64-bit

Mon, 25 Aug 2008 12:08:31 GMT

I've been hacking on a small panel for my current desktop environment— I've switched to using a really minimal no-frills environment consisting of openbox-3 and a small dock/notification area, since I was getting antsy about the GNOME 2 panel. I only wanted a simple list of open windows on a particular desktop and a clock, and I didn't need too much chrome on that. I couldn't quite set up the GNOME 2 panel to not use buttons or alternatively maximize the space for window title text, so I decided to simply ditch the panel altogether.

So, enter fsp-h. The hacked version of F'ng Small Panel is what I needed. Plus, to get the minimal window footprint needed, I added in a Openbox theme designed for people who don't need the titlebar text.

As you can see, I've been trying to get as close to my old Ion3 environment as possible, and I think I've gotten close enough. I hacked in support for quick window switching, ala ion3, where hitting 'W-1' will switch to the first window on the desktop, hitting 'W-2' will switch to the second, etc. I also got some 64-bit issues cleared up (the original code was built on 32-bit, and icons were broken on 64-bit).

All in all, I think I'm getting to like this. Plus, I'm using GNOME Do for quick opens etc., as well as for doing Ion3's quick SSH (which I use to open a terminal to SSH to hosts).

Emacs as a Java IDE

Mon, 21 Jul 2008 14:28:36 GMT

(Note: Geek post ahead. You have been warned.)

Admittedly, I'm an Emacs power user (and no, I am not as hardcore as some people). Emacs has been my primary text editor for the longest time— the first time I picked up Emacs was way back in 2004, a little over four years ago, when I decided to just sit down and learn the little bugger. Now, I do a lot in the editor: my mail is handled and served by Gnus, I handle my TODO lists and outlines through Org Mode, and I do the majority of my text editing and coding in it.

The last item bears a little explanation. My work entails a lot of heavy text editing in the form of code. I am a programmer by profession, and that means that I spend a majority of time looking at code if not writing it. We do a lot of Java where I work, and most of the company uses Eclipse as the IDE of choice. I use Emacs.

Now, Emacs has some decent support for editing Java files in the form of java-mode, which features basic syntax coloring. That's a good bit, but it isn't exactly what I need— if syntax coloring was all I needed, I could just edit files in gedit. And, admittedly, there are a lot of goodies that a full blown IDE such as Eclipse can bring to the table— code completion comes to mind, especially since Java can get somewhat verbose.

So, my Emacs config also includes JDEE, the Java Development Environment for Emacs. Unfortunately, JDEE development has been relatively stagnant of late, what with it only supporting ant and not Maven— and the latter is a big deal in our shop, as we use AppFuse 2 in a lot of our projects.

Fortunately, someone wrote a decent parser for Maven 2 POMs (which isn't really a parser as it simply asks Maven for the classpath, but what the hey, it works). Unfortunately, it doesn't work for multi-module projects, for one reason or another (and I'm bad at debugging elisp. So, I decided to write a custom macro to handle it. I simple place the following in a JDEE prj.el file (in the root directory of my project):

(jmi/load-multi-module-pom
 "/path/to/project/root/here"
 '("pom.xml" "core/pom.xml" "web/pom.xml") ;; Path to module POMs
 ('(jde-project-name "My JDEE Maven Project") ;; Other JDEE variables set here
  '(jde-expand-classpath-p t)
  '(jde-lib-directory-names '("^lib" "^jar" "^java" "^plugins"))
  '(jde-expand-classpath-p t)
  '(jde-ant-enable-find t)
  '(jde-gen-k&r t)
  '(tab-width 4)
  '(jde-compile-option-command-line-args
    (quote ("-Xlint:all" "-Xlint:-serial")))))

Et, voila. I get multi-module support. The macro is pretty simple, but it's the first I've ever written (and I'm thinking I could have written it as a function, if not for the expansion of the JDEE variable list at the end):

;; Project file helper for multi-module Maven projects
(defmacro jmi/load-multi-module-pom (base-path pom-path-list other-variable-setters)
  "Macro to load multi-module projects into JDEE. BASE-PATH is
the path to the root of the multi-module project, POM-PATH-LIST
is a list of paths to the submodule pom.xml (relative to
BASE-PATH). Pass in a list of JDEE variables to set in OTHER-VARIABLE-SETTERS."
  (let ((my-classpath (make-symbol "my-full-classpath"))
        (my-sourcepath (make-symbol "my-sourcepath")))
    `(progn
       (require 'pom-parser)
       (setq ,my-classpath  '("/usr/share/java"))
       (setq ,my-sourcepath  '())
       (mapcar
        (lambda (pom-name)
          (progn
            (message "Reading %s" pom-name)
            (with-pom (concat ,base-path pom-name)
              (pom-set-jde-variables *pom-node*))
            (setq ,my-classpath (append ,my-classpath jde-global-classpath))
            (if (stringp jde-sourcepath)
                (setq ,my-sourcepath (append ,my-sourcepath (list jde-sourcepath)))
              (setq ,my-sourcepath (append ,my-sourcepath jde-sourcepath)))))
        ,pom-path-list)
       (jde-set-variables
        ,@other-variable-setters
        '(jde-global-classpath ,my-classpath)
        '(jde-sourcepath ,my-sourcepath)))))

I'll probably elaborate on more of my Java development environment under Emacs in future posts...

Goodbye, pogi man. We'll miss you.

Wed, 06 Feb 2008 10:23:37 GMT

Brother Felix Mason, FSC
1919 - 2008

On social relationships and metaphors

Tue, 15 Jan 2008 10:01:51 GMT

I've been trying to find a copy online (or at least a summary of) Gilingang Bato by Edgardo Reyes. The short story was published in the 1960s. It depicts a poor family who own a small millstone for griding rice; they sell rice cakes and other sweets to subsist.

What prompted my sudden urge to find the story? I'm kind of hazy on the plot of Gilingang Bato and I wanted to clear up some bits of what I remember from it. It came to mind, in particular, during a conversation with Clair about social relationships, particularly with families and what-not. Food can sometimes be used as a metaphor for these relationships— take a look at the difference between kalamay (ground glutinous rice cooked with sugar, coconut, peanut butter, etc.) and biko (a rice cake with caramel, etc.): the grains in kalamay are tightly bound together, while in biko you can distinguish these grains. Some relationships are tightly knit, some families are tightly bound in the same way as kalamay; while others are more loosely bound together, where each member has more individuality.

Just send a note my way if you find a copy.

I am not the man(1) system

Wed, 09 Jan 2008 12:58:03 GMT

Actual occurrence, just five minutes ago:

Butch: JM, what's the purpose of -a in git-commit?
Me: Uh, it's like this. (Then I begin to explain in terms of svn commit and the git index)

Pause.

Me: You did not just use me as a man page.

Desktop Environments, continued; and a bit of House

Thu, 22 Nov 2007 18:10:26 GMT

Since I'm a bastard to please, I've again switched away from ion3. I'm now back to using Openbox 3 as my work environment, though I believe it to be suboptimal for my workflow. Call me fickle. Details under the cut.

One of the reasons why I find most of the present-day environments suboptimal is probably because I have been so spoiled by ion3 (and have used ion3 for so long) that I have formed some opinions and assumptions about my work environment. Here's a rundown of my habits:

I agree with Tuomo Valkonnen: the window manager should manage windows, not me. I don't like having to move through a stack of windows just to pull up a single window; I don't want to have to move my hand to the mouse to resize a window; I dislike the clutter of overlapping (floating) windows.

When working on something, I usually have two Emacs frames up and running, one with my mail and the other with a buffer with a file I'm currently working on, whether source or other. I also have several browser windows open, and hidden in another desktop, as well as several terminals. With this setup, I don't want to be bothered with the terminal windows while editing source code, and I don't want to have to move the Emacs window when it obscures a terminal window, for example. However, I want to be able to quickly switch to the terminal window with a keystroke.
Although I like having my windows maximized by my window manager automatically, I also need to see at a glance what windows are open in a particular desktop. Before using ion3, I was a ratpoison user— I switched to ion3 primarily so that I could have a listing of windows on a desktop without having to hit a keystroke. Under ratpoison, I had to hit C-t w to get a list of windows. With ion3, I know at a glance which windows are on a desktop, and...
...have one keystroke access to all my windows in a particular desktop. Currently, with Openbox and other window managers with an overlapping window policy, I have to circulate through the list of open windows just to get to a single window.

With the above example, I know which Emacs frame I want to go to from the terminal. I don't want to have to move my hand to the mouse just to point to the Emacs frame. Under ion3 and my custom setup, I could hit Mod4-1 to select it (if it's the first window in the frame), and hit Mod4-Backspace to go back to my previous window. In fact, I could hit Mod4-Backspace to alternate between the two windows, across desktops in fact. I have yet to find an equivalent in Openbox or other environments
I need a system tray/notification tray. Although ion3 does not have a EWMH-compliant system tray (it follows a simpler protocol), I use mod_dock and an app called docker (as well as window hints to move the docker window to the dock). Why do I need this? I have several apps running — GNOME's NetworkManager applet, power manager, and bluetooth applets in particular. Without the dock, I would have to go through a barage of steps just to switch WiFi networks, for instance; this is one case where I don't mind using the mouse.

The reason for the switch back to Openbox is so I can wean myself slowly away from ion3. The mod_xinerama module that I mentioned in my last post is sort of broken, and I don't have the time to figure out how to get it running. Openbox Just Works when I resize my desktop across monitors, and although I find the whole setup still suboptimal, I might as well live with it.

Tune in; I might suddenly decide to move back to ion3.

Fickle.

Just watched the latest episode of House, and wow. The killer scene, I have to admit is between House and Cuddy. House has just ordered the candidates to steal Cuddy's thong, and someone has purportedly done it. House wants to check:

(House intentionally drops his bottle of Vicodin, Cuddy bends over to pick it up)
House: (wide-eyed) OH. MY. GOD! You're not wearing underwear!
Cuddy: Of course I am, I—
House: Skirt that tight, you got no secrets. Skirt that tight, I can tell if you've got an IUD. Seen Dr. Cole?
Cuddy: No...
House: You're blushing.
Cuddy: I am not.
House: Look at me.
(Cuddy turns to House)
House:OH. MY. GOD.

Of course, it's way funnier when you watch it.

That and the ending, which I'm not spoiling.

Desktop Environments, Or How To Piss Off Your Users

Tue, 06 Nov 2007 03:23:46 GMT

If you've ever seen me work, you probably know that I am quite comfortable with the command line. In fact, I prefer opening a terminal or writing a shell script rather than booting up a file manager; I can do a lot more on the command line, without taking my hands off the keyboard.

So, my desktop environment of choice is Ion3, a keyboard-driven tiling window manager for X11. Recently, however, Ion3's author has made it non-free and has removed Xinerama support; this does not bode well for my particular use-case. I often have my work laptop plugged into another monitor (a "head", in X11 parlance), and with XRandR 1.2 I can do this without having to restart the X server. With the two monitors, I have a lot more screen estate to work with, and I usually have one monitor with my code while the other shows documentation, or a terminal, or gitk(1) visualizing the project I'm working on.

Apparently, Tuomo Valkonen has this bull-headed idea that Xinerama is simply unecological penis enlargement, and that he seems to think that all current-day GUIs (WIMPs: Windows, Icons, Menu, Pointing device) and their proponents are complete idiots, and I doubt his ideas of the free software community and its behavior are all that accurate— he draws comparisons between the wiki communities and the FLOSS groups in one breath; those two communities may share the same ethos, but have vastly different mindsets and operational mechanics. Anyway. With the loss of Xinerama support, I had to drop Ion3 from my toolset and switch to another window manager/desktop environment.

My first option was WMII, another keyboard-driven tiling window manager. Although I like its management policy, I felt that it was still lacking as it too did not have Xinerama support (yet). I needed an environment with Xinerama support, so I shopped around some more. I opted to use Openbox 3, which I've used before.

Openbox 3 has the advantage of Xinerama support, a lightweight core, and keyboard shortcuts (which makes it 2 for 3 on my scale). I could have learned to live with it, and I could have been quite productive. However, the whole stacking and overlapping window policy was slowly getting to my nerves, and it was starting to annoy me that I had to move my hands off the keyboard to manage my windows. I have been too used to Ion3's management policy, that I felt that overlapping windows was just not my bit.

So, after just a week on Openbox, I switched back to Ion3. I found that someone had hacked up a Xinerama support module, which was what I needed.

I'll be sticking around with Ion3 for now, until WMII grows Xinerama support. Tuomo has been bull-headed from day one, and although I admire his hubris (I have to agree on the broad swath of his thesis on window management and user interfaces; it's on certain details I don't agree with), I dislike that he seems to think that his policy is the best, and that WIMP interfaces are wrong (although I don't use a WIMP interface, I have to agree that the research behind them is pretty solid, and that they are usable; in other words, I disagree with Tuomo on that point). I disagree that the FLOSS community is completely wrong; in fact, I think that Tuomo Valkonen is an idiot for abandoning his users in this way.

I would have stuck with Ion3 for a long time, had it not been for this particular detail. Too bad. I happen to like Ion3, and I have been using it for more than three years now, a long time compared to the other environments I've used. With Tuomo Valkonen abandoning Ion3's users in this manner, by pissing them off with intolerance and implying that they are ignorant, I am forced to move on to something better.

I doubt that Tuomo realizes this: the silent users are more than the more vocal ones, and that he is probably slowly losing that silent majority.

Hiatus.

Thu, 04 Oct 2007 21:35:55 GMT

On Indefinite Hiatus. Will probably post some twitts.

Murphy's Law, and How Not To Call a Web Service

Thu, 09 Aug 2007 17:21:17 GMT

Recently, we've been assigned to assist another company in a development/maintenance role. They had an existing web application, written in Java and used by a large number of users— the web application was up and running and they needed to modify the application to interface with an external system, but they did not have the people who knew Java well enough onboard and the previous developers were no longer available to help them in this. That's where we came in: we provided the needed skills to add the feature in.

To interface with them, the external system provided a web service interface (written on the .NET platform) which we had to call in a remote method fashion. That is, certain transactions on the web site had to call a web service method and await its reply before saving the transaction data into the database. We couldn't perform these web service requests asynchronously, a point I'll come back to later.

To add to the pressure, we had four days to complete the code to interface with the web service (as well as an additional, but minor, feature), and two weeks of "transition time", where the new web application would go live straight into production, with live data, but users would not be charged for transactions they've made during the time.

There was three of us on the team: me, Butch, and Miguel. We decided right off the bat to use Spring's remoting services for calling the external web service. We got everything up and running quickly on our development server, and we were waiting for the client's team to ready the production system for the turnover. However, Murphy decided to pay us a visit: there was a planned database switchover where the live production site would be made to point to a standby database instance while the live database would be upgraded, but things went south quite quickly.

Anyway, we eventually got the whole shebang up and running the next day, with Murphy still breathing down our necks. This time, we found the application dying: within an hour or two of use by users, access to the application would slowly grind to a halt until nobody could access the application at all, and the application server (OC4J in this instance) had to be restarted.

We set out to figure out this particulary nasty bit of news, and why it was happening. After about halfway into the transition time (and about two to three app server restarts a day, disastrous) we found out why things were happening, as it was.

It turns out that Axis 1.x, which we were using under the hood of the Spring JAX-RPC proxy bean creator as the JAX-RPC provider, uses a fire-and-forget HTTP transport. This means that under high concurrent load, the default axis HTTP transport would eventually exhaust all connections, as a lot of the finished HTTP transactions will be idling in the CLOSE_WAIT or TIME_WAIT, and the time for these to transition to fully closed isn't short enough for sockets to be reused.

To give an idea of the connection loads we were seeing, the web application was handling about 20,000 to 30,000 transactions a day, from 9am to 6pm, with traffic peaking from 10am to 12pm; almost little to no traffic occurs outside of these times. Although this isn't spectacular (web sites that have been Slashdotted could get traffic a magnitude or two greater), the situation was exacerbated by latency: it took from one to two seconds for the external web service to finish, per method, and for each web transaction we were performing two web service method calls.

(Aside: Since me and Butch were more conversant with monitoring and adminstering Linux servers than the Windows server that the web application was installed on, and since the only interaction we had with the server was a VNC connection to the machine (where it was coloc'd), we had a tough time trying to piece together enough data to actually get to that conclusion. Really. And now my favorite tool on Windows is PERFMON— even if I don't run Windows, at all. But I digress.)

Apparently, Axis 1.x also supports another HTTP transport that uses the Commons HTTPClient library, which in turn does HTTP connection pooling. Telling Axis to use the Commons HTTPClient instead is well documented here, so I won't go into it. However, for reasons beyond me at the moment, the remote web service (being served by IIS, and possibly behind an ISA server) refused the Commons HTTPClient connections because of chunked encoding (i.e. the Commons HTTPClient wanted to send HTTP transactions in chunks and told the server by issuing "Transfer-encoding: chunked" in the initial headers). As I found out from here, there is a workaround, which I had to implement via subclassing of Spring's JaxRpcPortProxyFactoryBean, where I overrode postProcessJaxRpcCall:

    public void postProcessJaxRpcCall(Call call, MethodInvocation method) {
        super.postProcessJaxRpcCall(call, method);
        Hashtable ht = new Hashtable();
        ht.put("chunked", "false");
        call.setProperty("HTTP-Request-Headers", ht);
    }

I also used the subclass to fix a particular concurrency bug in the JAX-RPC proxy bean that Spring has which we were hitting.

So that basically saved the day. We did some stress testing before we put it into production, we observed the number of TCP connections established. Without the use of the Commons HTTPClient sender, the graph of network activity was rising linearly, with occasional dips as the load testing machine's activity dropped off (where the load tester's own threads were hogging each other for CPU time). With the Commons HTTPClient in place, the graph was quite flat, reaching a natural peak level without moving above that (of course, our concurrent load was constant, hence the ceiling).

The moral of the story? When you're about to put a site live, Murphy will be knocking.

Ping

Thu, 02 Aug 2007 06:21:18 GMT

This is a test of the emergency broadcast system

Expertise is more than meets the eye: One String IT Pieces

Mon, 25 Jun 2007 15:31:35 GMT

In a post, Sacha Chua asked: what are the "one-string pieces" of the IT world?

The "one-string piece" of IT (systems administration maybe) could be the various command line or Perl one-liners and what-not that does the job and astounds our bosses; where, as deadlines loom or we're in the middle of downtime costing the company, we pull out a one-liner that saves the day. Or it might even be the little things: the libraries or tools you've researched or played with in your spare time, and apply in a Eureka moment. You get that rush, knowing you've gotten the most bang for the buck, and your colleagues or bosses have no idea how you've accomplished so much with so little. Little do they know that you've been doing this kind of stuff for so long it comes naturally to you.

It can be the knowledge of various sed/awk/perl combinations that you've played with, then applied with awe-inspiring precision to the problem at hand. It can be the knowledge of the esoteric bits of the Java Language Specification or the Java memory model or even the class library, allowing you to figure out what exactly is going on underneath the hood, causing that heisenbug that your coworker has been debugging for days -- which you've solved in five minutes with a one line fix.

It could be that.

It's the stuff that others think they'd never really need, but you know will come in handy. It's the stuff that allows you to spend more time at the higher levels of abstraction, but with the knowledge that you're going to be comfortable going down to the bits and bytes if and when (most likely when) the time comes.

It's knowing that although GUI tools and wizards and nifty IDEs and autocompletion will probably cut down the time it'd take you to shape your code, you have to know how those tools work so that when it breaks you can fix it.

It's experience.

VisualDNA.

Wed, 20 Jun 2007 20:38:02 GMT

Read my VisualDNA™ Get your own VisualDNA™

On Programming and The Programmer's Toolbox

Tue, 19 Jun 2007 16:35:03 GMT

I am quite interested in a wide swath of technologies, some esoteric, some popular. Particularly, I follow the news on various libraries and tools. I like to keep my toolbox full.

Although I'm usually quite busy and I currently work in Java, I keep my finger on the pulse of other systems. I play around with Ruby, with PLT Scheme, with Perl. I look around for Emacs hacks. I read various planets and aggregators. I check out what people are working on. Mostly, I look at what I can put in my toolbox.

I try to learn what other people are using, what libraries they're using, what tools and IDEs they're working with. I don't do this out of envy— I know my tools are still inadequate, and my toolbox is still bare.

Take, for instance, Microsoft's LINQ. LINQ is essentially a language-level query system in the .NET universe, particularly in the Orcas release of Visual Studio.NET and the .NET runtime. It allows you to write queries as part of your source code, complete with syntax checking and with the support of your language's data structures, etc. Of course, I'm glossing over some of it's really nifty bits, but you get the point.

Someone asked the PinoyJUG mailing list about LINQ and Silverlight and what Java has to offer. It got me thinking about the tools of my trade, and the tools in my toolbox.

Are my tools sufficient for the job at hand? Are the stuff we have in the Java space sufficient for what I do?

I disagree.

The tools are never "sufficient"; they're usable for the job at hand, they do the job, but they have their quirks and issues. For example, if Spring or any dependency-injection framework wasn't in your repertoire, you'd think that the Factory and Service Locator patterns were sufficient, were enough, to do the job -- and you'd be blinded by the problems of those patterns, that those patterns are not the end-all-be-all. However, Spring isn't a silver bullet— dependency-injection has it's own quirks, it's own series of questions. How do you refer to "soft" dependencies? Why do I have to write tons of XML? Setter or Constructor injection? What about bean lifecycles? Cyclic dependencies? Hooking it up to legacy systems?

If you ask me, it's not about looking for the tool when you need it, but rather what tools you already know will help you deal with the problem, or will help make the problem amenable to your other tools. So goes the aphorism "If the only thing you have is a hammer, everything looks like nails": by expanding our knowledge of what tools are available, creating new tools, and fixing existing ones we get to write better code.

Tools transcend code and libraries. When I refer to tools I also refer to how to think of the problem. One can borrow the paradigms of functional programming to write Java inner classes and nested classes to parameterize or box behavior, for example. One can grok C++ templates and their patterns of use, and use it to metaprogram in Java.

My point here is that as someone in the business of writing software systems, I do not sit still and just passively look up resources as I need them. I become a better coder by reaching out and enriching my toolset, and by that I can write better software.

But in the end, only one truth can be said about tools:

There is no silver bullet.

Work, Browsers, and Context-Switching

Thu, 14 Jun 2007 07:26:04 GMT

Someone on the PLUG mailing list said to an email I sent out:

Now, why on earth does someone have multiple tabs? Too many tabs mean you ain't working! That was mentioned by one of my friends.

In my case, I really work with a lot of tabs and windows open. (It helps if you're using something like ion3, or if you're perfectly comfortable using a desktop environment and can rapidly switch between windows and apps). Primarily, I usually have the following in a browser session:

One window for mail (gmail)
One window for blogs and feeds
One or two windows for app development
Several windows for reference lookups

Under my windows for reference lookups, I usually have several tabs open, usually with a Google search being the first tab. I'd open each potentially useful link open in a tab. Plus, I group tabs with windows, with each window dealing with research on a particular scope (API docs, libraries, administration references, etc.)

This allows me to move to cross-check references from each source. Say, I have a tab open for the Javadocs to the Spring API for Hibernate integration. I'd want another tab showing the page from the online Spring reference showing how a particular task is done in Spring+Hibernate, with another tab showing possible code samples, with yet another tab showing source code for related classes in Google Code search (because I might be working on something that might need me understanding how the implementation works, possibly because I might need a hack or two to get what I need working).

I might also be reading news posts and blog posts related to that feature, so I'd have another window open. Or I might go off to a tangent and check whether or not there's an existing solution or library out there for what I need (which means I don't write code, yay!).

Multiply that by the fact that I don't necessarily close my windows or tabs -- what I keep open represents my "persistent state" (of mind), and when I context-switch to another aspect of what I'm doing -- say I take a breather, because I'm stuck -- I can get back to what I'm doing, and just glance at the open pages and what tabs are open and what-not and see from there how to proceed.

That's also the reason why I have several buffers open in Emacs -- I use Emacs as my primary work mail interface too (outside of GMail that is), and I also use it for planning. I also use it as my IDE; flymake + the Eclipse compiler + BeanShell means I get syntax highlighting *and* I get background compilation inside of my Emacs session. But if I simply closed off all my files, I couldn't easily switch easily between those buffers, see files side-by-side, etc.

Then again, I work this way because I can easily juggle state between those related tasks, and I don't necessarily have to pay a penalty for context-switching between them. It works for me, but I don't mean that it'll work for you.

Sure, if you have multiple browser windows and tabs open you might not be focusing on what you're doing (hence, you're not working). But for me, having those windows and tabs open means I don't have to really remember a lot of information -- I use my computer to maintain that state for me, allowing me to easily switch between tasks.

YMMV. :)

Shanghai, May 2007

Mon, 21 May 2007 18:44:52 GMT

Some Popular Myths About JM Ibanez

Mon, 16 Apr 2007 11:56:00 GMT

JM Ibanez is Sanjaya Malakar in disguise.
JM Ibanez does not sleep. He just goes into suspend mode.
JM is a programming god.
JM doesn't troubleshoot computer problems or software bugs; computers are just scared of him.
JM Ibanez is actually a bunch of Linux daemons that have become sentient, written and maintained at a secret laboratory somewhere in southern Metro Manila.

You know you've had too much caffeine...

Mon, 12 Feb 2007 22:05:58 GMT

... when you're suddenly tempted to do an impression of a dog humping a pole. Or an impression of a monkey in a cage. Or you suddenly have these other crazy impressions fill your head.

Crap.

My Sister Is Really My Sister

Mon, 12 Feb 2007 15:31:37 GMT

On our way to dinner last Sunday, my mom inquired as to what restaurant nearby accepted credit cards.

Me: I'm pretty sure that Yellow Cab will
Steph: I'm not sure, but I am pretty.

My Journey Into Computing (Part 3)

Wed, 31 Jan 2007 16:50:02 GMT

I decided to actually write about my experiences and my introduction to computing. I wanted it down for some semblance of posterity. This is part 3; you can read part 1 here, and part 2 here. I don't intend there to be a part 4, but feedback is much appreciated. Yes, yes— this part is long-delayed.

Oh, and for those in the crowd: this is my space. You might find the hubris a tad bit too much though.

Growing up

So, in all honesty, I was a BASIC coder for the longest time, even longer than my current-day affair with Java. (Don't get me started on that topic though). BASIC had annoyed me, what with things I felt I couldn't do in it. Looking back with some hindsight, some things were indeed possible, although klunky— one could simulate linked lists, for example, using arrays, and one could do graphics blitting via PEEKs and POKEs. But then, I didn't have much knowledge in such matters, and I couldn't really do the more ambitious things I had in mind. I wanted a more powerful language. At first, Pascal sounded nice, but I decided to go to C since I knew it had a reputation for being quite powerful. (Which, mind, is quite an understatement)

But in order for me to play around with C, I needed a compiler. Initially, Turbo C fit the bill. The computer lab did have a copy, and I did use it for some time, but I felt that it was too old, too small. I wanted a 32-bit compiler. The exact reasons for wanting a 32-bit compiler, of course, is lost on me right now, but I did find one.

By my second and third years in high school, I was interested in writing a computer game from scratch, and I demanded from myself that I do it in C. If there's anything I learned from all my years coding in BASIC, it's all the bad mental habits. Unstructured code. Huge functions. Global variables. Variables appearing out of thin air. All very, very painful to wrench away from, especially when you start coding in C. And, considering that I wanted to do a game from scratch in C, very painful indeed. (I never did get to finish that game too— I don't know if that's a commentary on my abilities though. You be the judge)

Mostly though, I dived into learning about AI and graphics— 3D graphics was all the rage then, so I also dived into that. And I began to plunge into the Internet, but not really at home (we didn't have a modem yet). I began surfing at net cafes and shops, and at the library. The vastness of what was available online was stunning. This was still at the beginning of the explosion of the Internet in the popular consciousness of the world. I can say I was a witness to the explosion, albeit a bit late though.

In any case, I picked up a lot of stuff from the Net. I was already aware of the existence of Usenet, of IRC, of the myriad forums that dotted the virtual landscape. However, there was one thing I wasn't yet aware of: free software and the open source movement.

In the middle of the 90s, the free software movement led by the Free Software Foundation and the GNU project was just nascent. The free software movement's battle cry was about, well, free software— free, as in freedom, not necessarily free as in beer. Open source wasn't yet what it is today. Linux was still in its early days. But it was there: the GPL was already out, there was a substantial amount of code already written for the GNU project. One particular component became critical however: the GNU C Compiler, now known as the GNU Compiler Collection, or GCC.

There already existed several ports of GCC to various platforms. In fact, it was slowly becoming the de facto C compiler for a lot Unixen and Unix-like systems. Two ports were what caught my eye at the time: a port to the Win32 API and platform by Cygnus Solutions as part of their Cygwin system, and a DOS port by DJ Delorie named DJGPP.

Now, I did look into Cygwin. After all, I was running a Win9x box at the time, and Cygwin was (and still is) a complete set of Unix tools for Windows. What turned me off was the size of it all. I couldn't download it and save it to a floppy— CD burning was at its infancy, and USB and USB flash drives weren't even in existence. DJGPP, on the other hand, was tiny. The components I needed I could save onto floppy. And that I did.

It took several trips to a Net cafe near our house as well as several false starts, but it was worth the time. I finally had a 32-bit compiler (albeit for DOS).

Of course, while I downloaded the ZIP files I needed, I explored DJ Delorie's site. On one particular corner was a collection of essays, one of which would slowly sink into my consciousness. It was a text file, and the author of the essay was Richard M. Stallman.

Linux: Enter, Stage Left (well, almost)

Like I mentioned earlier, Linux was still in its early days— but this is not to say that it wasn't quickly growing in the technical community. In my freshman year in high school, I decided to join the school orchestra (due, in part, to some prodding by my friend Leandro). Among the people I met in the orchestra was a junior by the name of Denny Antonino. Denny, who played the flute, introduced me to several other people, among them Carlo Sogono and Paolo Dolina.

Paolo helped set up the #zobel IRC channel back in its heyday, and I would often visit #zobel while I surfed at Net cafes everywhere. Carlo, on the other hand, was a true geek— he knew and ran Linux, and in fact helped set up the school's mail system. One of the memories I have of Carlo Sogono was when I was in sophomore year. I had joined the high school paper that year, after vowing not to the previous year— I was part of the grade school paper in my seventh grade, and that wasn't an experience I relished. In any case, we all hung out at the PPRO, the Publications and Public Relations Office. Our adiviser, Mr. Arianwen Dagmar Androu Tapang Lopez (who will kill me once he sees this entry) was friends with us all, including Carlo. One lunch hour, while helping with some articles, Carlo walked in rapidly to Sir Arwee's PC and fired up the telnet client of Windows 98. Now, I was well aware of the venerable telnet, but what I wasn't aware of was Linux. Anyway, he connected to a server (which one, I don't know until now), logged in, then fired off several commands. I was, obviously, looking over his shoulder. He was talking about an exploit named Teardrop, and how he had downloaded it and how it was affecting the server.

I freely admit that at the time what he was talking about flew past me. I was a PC geek, and Windows-oriented at that. TCP/IP and networking was as foreign to me as Latin and Greek. So what I saw really flew past me, and I was utterly amazed. I wanted to know what the heck he was doing. And I wanted to check out Linux. But, unfortunately, I had a few hardware issues.

First, we only had one PC which the whole family shared (or rather me, my sister, and my dad shared). The PC was running Windows 98 at the time, and it only had around 100MB of disk space left on the hard disk— a hundred megs that I was constantly juggling with, removing and adding applications as necessary. Paolo (who also was a Linux geek then) was telling me that I could install it there, but I was a little wary considering the space I had left.

If there was any moment in my journey which I regret, it was then. I could have started on Linux and joined the community early on, but because of disk space I couldn't. As they say though: better late than never.

Free and Open Source Software

My almost foray into Linux did, however, get me interested in the workings of the Internet. It got me started on networking and other topics. And, quite fortuitously, it got me interested in open source.

Remember that essay I was talking about earlier, the one by a guy named Richard M. Stallman? Richard M. Stallman (or RMS as he is better known) is the founder of the Free Software Foundation and leader of the free software movement and the GNU project. The essay was essentially about the philosophy behind Free Software (free as in freedom, not necessarily as in beer). At the time, I found it heady and hard to absorb. However, bits and pieces of it began to filter into my consciousness— in particular, the need to have source code.

DJGPP was my first taste of free software. With DJGPP came a license named the GNU General Public License, or GPL. I read through it and what it told me I could do kind of blew me away. You mean you're giving the source code away? At the time, I was of the opinion that source was equivalent to the crown jewels of software: something that you jealously guarded from your competitors. I was of the proprietary, closed-source mindset. I had always believed that the money was in the source: you had to protect the source code to get paid. To sell software, I believed you had to protect the source code to it, to prevent anyone from gaining on you. The free software movement, on the other hand, seemed antithetical to business, to money making.

However, I soon was able to digest what was not just possible, but what had already been done. The more I read about Linux, the more I read about the early success stories of the free software and open source movements, the more I got to understand: hey, this whole shebang about free software works. And when I hit college, I was already quite well-versed with the whole deal, and was amazed by the news that Netscape was opening the source to their browser. Woah, I told myself.

I soon found myself using more and more of the FOSS stack. First, it was just the browsers. I opted to run Mozilla instead of Internet Explorer. Then, since I was already DJGPP, and since I wanted to write Windows apps, I switched to using MinGW, another GCC port, this time to Windows, just like Cygwin but more minimalist. MinGW was a perfect fit for me, as I only needed to compile apps. During this time, I also discovered Allegro, a game programming library. Although technically not distributed under any one of the various licenses accepted as open source (it was and still is "giftware"), it was and still is developed under much the same ethos as other open source projects. (I remember one weekend hacking on a toy app that I wrote for a class; it was small tic-tac-toe app to help demonstrate the concept of AI). I started reading up on MySQL, and before long I actually started using Linux.

My then-college professor, Mr. Joel Pira, was an avid Linux enthusiast, and we had a lab class on Java servlets. He decided to set up one of our labs as a dual-boot environment, where we would work in Linux for the lab class (Windows was left in for the other classes using the lab). That's where I first got a real taste of a Linux environment. I already read up on some Unix shell commands, having bought a beginner's introduction on Unix, and I was quite comfortable with a command line, having used one even on our family Windows machine. So I dove in. I knew how to request the manual pages for commands, I knew how to change directories, I knew how to list files. Before long, I started simply messing around, ssh-ing from one lab PC to another. Mr. Pira had entrusted me with the root password to all the machines there, and so I started really messing around— I once wall'd a message to a friend's PC, and played around with his GNOME session by killing processes and restarting them while he was logged in. (Yes, I'm evil.)

Mr. Pira also lent me a copy of what would be the first distro I would ever have: Mandrake 8.1. As soon as I got the money saved up, I bought a el-cheapo 8-GiB hard disk from a PC shop in Makati, plugged it into our home PC, and installed Mandrake 8.1, keeping up the whole night as the machine copied and installed files. I was excited; I was thrilled; I was pumped up. Finally, I told myself, I'll be able to play around with Linux.

I have not looked back ever since. I have run Linux as my desktop system from then, from basic stuff at first, to full-bore Internet browsing when I got my winmodem working through a, well, clever hack. I run Emacs as my text editor of choice, and Gnus as my mail client of choice.

And that, my dear friends, is my journey into computing. What's yours like?

More Git

Tue, 30 Jan 2007 02:53:23 GMT

So, because I'm such a geek, I'll post more about my Git experience.

Juggling multiple states. I've been handling several aspects of the project at my current assignment. Particularly, I'm more or less in charge of the Ant build files, a JMS consumer for asynchronous task execution, and various other code-fu. Recently, Butch put the task of writing and wiring code to inject domain objects with a crypto service class— an instance of which is only available in the HTTP session. Which means that, ordinarily, one couldn't do it via Spring: we're talking about domain objects (which aren't ordinarily managed by Spring) and session scope (which isn't available until the HttpSession is created).

Enter Spring 2.0. We moved to Spring 2.0 recently, primarily for better JMS support. As a side-effect, we get shiny new stuff in the form of Spring 2.0's new bean scopes and better AOP support, which are godsends.

So, I set up my Git working tree to handle experimental work (which won't hit the central SVN repo until I'm actually sure that I've gotten my tests to run green) by creating a branch for it. With the branch set up, I can switch between my main (master) branch, where I work with the stuff that should hit everyone, and more experimental tree-breaking stuff. Switching between the two is as simple as doing git checkout master and git checkout my-experimental-tree. And, I have a third tree where my tree-specific config changes are applied and versioned, where I actually run tests and build test WARs and what-not.
Maintaining tree config files for testing. The codebase for the project I'm working on uses several configuration files in the form of Java .properties files. To separate test configurations, I have separate trees. The advantage of this setup is I can use my work branches for real work, and switch over to the test configuration branches to test various configurations. Also, I keep debugging code in these branches— I usually write some tracing logic in the form of simple System.out.println statements, which I don't want to check in.
Experimenting safely, while offline. Since Git affords me offline commits, I can create a branch with git checkout -b experimental-codebase, experiment, and later on apply certain patches from that tree into my mainline branch with git cherry-pick <commit-id>. This preserves my commit log message, and applies the necessary patch. I haven't yet tried out patch managers (such as quilt), but I would be willing to bet that they'd be of much help

Is The Long Hiatus Over Yet?

Mon, 22 Jan 2007 10:43:02 GMT

(...or, JM updates. Finally.)

So, I've been terribly busy with Real Life that I haven't had the time to update this little corner of the web. (For the insatiably curious, I've had countless opportunities to update— just not the time to sit down and do so.) For those who don't interact with me in any form or manner (i.e. those who probably wouldn't give a damn anyway), here's a list of what I've been up to lately, in the usual bulletpoints:

I'm busy working for this wonderful company— this blog is in fact aggregated in the company Planet, along with my wonderful cow-orkers;
... Which also means that I've stopped school for the meantime— juggling the two is insane (I've tried it before, and it is not very conducive to either work or studies, at least in my case);
I'm definitely a year older, and will be another year older still this coming June;
We bought a new desktop PC for the house, my specs, my choices— a 2.6 GHz Pentium D, 512MB RAM, nVidia GeForce 4400, 160GiB SATA, and a 19" widescreen LCD monitor. With Linux installed, of course;
On a related note, we moved houses. I no longer live in Las Piñas. I now live on the border of Las Piñas and Paranaque. Hah. Seriously, we moved houses, but we didn't move very far;
I have a pet, a mongrel pup I've deigned to name Ronin. (My sister wanted to name him Bernie, and there was one cousin who wanted him named Pringles, for what it's worth);
For the uninitiated, I have a girlfriend, and we've been together for more than a year and a half! :);
I've been to Baguio for the Christmas break, just like (almost) every year;
I've discovered the utility of sleeping under cubicle desks;
...Primarily because I've been assigned to a project where that utility is one of the few things keeping me sane. That, and playing with Butch's, Glenn's and Clair's balls— stress balls, that is. (Shame on you for having a dirty mind.);
On a more geeky note (elaborated below), I heart Git and now use it over Subversion for my personal projects and what-not.

So, I was saying something about Git. Details under the LJ cut, for those inclined.

Basically, Git is one of those things that just makes sense for me. Why didn't I use this before?, I kept asking myself. I never quite grokked distributed SCM before, but after actually trying Git out, I was blown away. I first tried it out on a personal project (which I may speak of in the future, if I can get an actual running prototype done), and was simply blown away primarily by the size of working tree— it was way smaller than an equivalent Subversion working copy or repository and it had the whole history of the project right there with the working tree. The whole history. Damn.

What got me started on the road to Git was a blog entry by X.org hacker Keith Packard on repository formats/layouts. He basically made a case for Git vis-a-vis SVN, and what he asserted made sense; I disagree with some points of his, but the gist I agree with.

Git provides better conflict resolution and merge tools. Definitely. Merging branches under SVN is a pain, and merge point tracking is still a TODO feature in SVN.
User interfaces are fixable; repository formats are not. Fixing the UI is easy— but starting from a "broken" repository format means that the breakage of that format cascades downwards, and one cannot move away from the format easily.
SVN's repository format is essentially broken. Having each revision diff as a file (under the FSFS backend) means that damage is propagated downwards across files. It also means that corruption is not easily detected. Git mitigates this by using SHA-1 hashes as object identity, meaning that corrupted objects are easily detected when read.
Git wins in terms of size. When Keith Packard compared an import of the Mozilla CVS repository into SVN and Git, Git outshined SVN in terms of repository size. The base CVS repository was 2.7GB; the SVN tree bloomed to 8.2GB, while Git tree shrank it down to just 450MB. To quote Keith Packard: "Given that a Mozilla checkout is around 350MB, it's fairly nice to have the whole project history (from 1998) in only slightly more space."

What got me really hooked was a recent release of Git, which contained git-svn(1), allowing bi-directional operation between a Git working tree and an SVN repository. Which meant that I could turn myself into the company guinea pig and test Git out, while still being able to work on our projects (where we use SVN as our SCM of choice). I've tried it out on my current assignment, and I was simply amazed by the fact that:

I could now (almost) work while at home— the project's SVN server is located at the client's premises, walled-off from the Internet at large, which means that we had to be at the client site to check in code. With Git and git-svn(1), I could work on some code, check it into my Git tree (preserving history), and sync with the SVN server once I get to the client site. Almost, because I can't run tests or even run the app— the webapp has a dependency on a large Oracle database we have installed at the client's premises;
I can make commits of finer grain. With SVN, I'm forced to make commits that are coarser-grained. For example, I'd want to check in a test even though I know that it'll break the build or will run red (because I haven't written the class or classes the test depends on, or haven't added in wiring in the Spring context files), primarily to preserve history— I can go back to the log and see when I wrote the test, and so I know I can back out just that change when I need to, say when I find out that I don't need the test for some reason, even after writing the class the test was supposed to run against;
I can work on multiple lines of development (i.e. multiple branches) without worry. With SVN, one would normally create a branch in the conventional branches directory in the repository. Merging under SVN, however, is a bit of a pain— SVN doesn't yet keep track of merge points or branch points, so when doing an 'svn merge A B' one has to specify the revision range manually. So, keeping track of trunk in your SVN branch is also a (relative) pain. Also, I'd often want to work on several things at a given time: I'd probably be refactoring the build files at the same time as working on a bug fix, and I don't like to check in the build file refactorings until I've tested them properly, so a branch would make sense here. Git makes it simple for me to do that.
Related to branching, Git comes with gitk(1), a graphical browser for browsing the history of a Git tree. With gitk(1), I can see where a tree has broken off the trunk, so to speak, and where branches merge

I had been previously of the "distributed is not for us" mindset, but am starting to think in terms of more hybrid, middle-ground solutions. Git + git-svn(1) is one of those solutions, and I believe that even if your team uses an SVN repository, team members will benefit from using Git for their own trees.