Let's get rid of middle management.
No, not you, boss.
I'm talking about middle management in Java code. At one presentation in the New England Software Symposium in Boston last year, some Java-bashing guy (Stuart Halloway) described Java as the language that invented middle management. You have probably seen them: these classes often end with "Manager.java". I'm wondering whether we really need them.
This is a development-focused blog covering Java software development.
Monday, January 25, 2010
Saturday, January 16, 2010
What's new in KBLauncher 1.1.1
I recently released a new version of KBLauncher, my application quick launcher for the BlackBerry. This blog entry serves as my release notes for this app. The rest of you who are here for non-BlackBerry topics can safely move on.
Sunday, January 10, 2010
On the breadcrumb metaphor
I've heard the term used in UI work: people refer to "breadcrumbs" when they mean a navigation aid that shows UI path used to arrive at a point in the program. This supposedly prevents a user from feeling lost. It could be a trail of screens or dialogs like Options > Advanced Options > Applications. I don't have an objection to that. I do think, on the other hand, that "breadcrumbs" is a pretty bad term to describe this UI construct.
The most famous example of using bread crumbs to mark a trail resulted in those crumbs being eaten by wild animals and the adventurers nearly becoming dinner themselves. All versions of of the Hansel and Gretel tale that I've read had the children successfully return home when Hansel used pebbles or small stones to mark a trail. This trick failed when Hansel used bread crumbs. With the crumb trail eaten by animals, they end up lost in the woods. They eventually wander to that candy house where they are trapped by a witch who tries to eat them. You know the rest.
So if you say you want to use breadcrumbs, are you really saying that you want to leave the user lost in the woods to be eaten by a cannibalistic witch?
The most famous example of using bread crumbs to mark a trail resulted in those crumbs being eaten by wild animals and the adventurers nearly becoming dinner themselves. All versions of of the Hansel and Gretel tale that I've read had the children successfully return home when Hansel used pebbles or small stones to mark a trail. This trick failed when Hansel used bread crumbs. With the crumb trail eaten by animals, they end up lost in the woods. They eventually wander to that candy house where they are trapped by a witch who tries to eat them. You know the rest.
So if you say you want to use breadcrumbs, are you really saying that you want to leave the user lost in the woods to be eaten by a cannibalistic witch?
Oops, did you accidentally ship your BlackBerry source code?
If you develop BlackBerry software using RIM's BlackBerry Java plugin for Eclipse and use Subversion for version control, you could end up shipping your source code with your executable if you are not careful. I had hoped this would be solved with the new version (1.1) of the plugin -- still in beta -- but based on my experience with one of the betas this does not appear to be the case.
The problem comes from the plugin's naive handling of non-Java files. Subversion keeps a copy of every version-controlled file in your sandbox. For example, if you have a Foo.java you will also have a copy as .svn/text-base/Foo.java.svn-base. This allows you to do diffs with the base version or revert your changes without even contacting the SVN server. But when RIM's plugin builds your *.cod executable, it assumes those *.svn-base files are resource files to be bundled with your COD file. The result is that if you view your resulting COD file in a text viewer, you will see copies of your source files -- those svn-base files -- embedded in the binary. Good grief.
Until RIM fixes this, one way to work around this is to specifically tell Eclipse to omit those SVN support files from the build. In your project properties, go to Java Build Path, select the Source tab and edit the source folders' "Excluded" entries. You can use wildcards in your exclusion patterns. And of course, make a test build and view it to make sure your source code is really excluded.
The problem comes from the plugin's naive handling of non-Java files. Subversion keeps a copy of every version-controlled file in your sandbox. For example, if you have a Foo.java you will also have a copy as .svn/text-base/Foo.java.svn-base. This allows you to do diffs with the base version or revert your changes without even contacting the SVN server. But when RIM's plugin builds your *.cod executable, it assumes those *.svn-base files are resource files to be bundled with your COD file. The result is that if you view your resulting COD file in a text viewer, you will see copies of your source files -- those svn-base files -- embedded in the binary. Good grief.
Until RIM fixes this, one way to work around this is to specifically tell Eclipse to omit those SVN support files from the build. In your project properties, go to Java Build Path, select the Source tab and edit the source folders' "Excluded" entries. You can use wildcards in your exclusion patterns. And of course, make a test build and view it to make sure your source code is really excluded.
Subscribe to:
Posts (Atom)