Embedding ActiveMQ

Recently working on embedding ActiveMQ in Tomcat for internal messaging (all within the JVM so using the vm protocol). Was really shocked with the amount of dependencies maven pulled down for ActiveMQ (jetty, pieces of Hadoop, etc). So far here is what I have for exclusions

<!-- ActiveMQ -->
        <dependency>
            <groupId>org.apache.activemq</groupId>
            <artifactId>activemq-core</artifactId>
            <version>${org.apache.activemq.version}</version>
            <exclusions>
                <exclusion>
                    <groupId>org.apache.activemq</groupId>
                    <artifactId>activeio-core</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.fusesource.fuse-extra</groupId>
                    <artifactId>fusemq-leveldb</artifactId>
                </exclusion>
                <exclusion>
                    <artifactId>mqtt-client</artifactId>
                    <groupId>org.fusesource.mqtt-client</groupId>
                </exclusion>
            </exclusions>
        </dependency>

The case for a rewrite

Ok here is something people just have to accept:

• All systems must eventually be rewritten or they will die

Now the question of course is how you go about it. The best plan is to have a plan. Realize that as you build a system, you add complexity which means eventually your feature curve levels off. You'll know this is happening because features end up taking longer and longer to implement. Even if you add staff you only have a short term increase in development velocity and then the inevitable context switching starves them for work and your curve levels off again. In other words, your graph looks like this

So you either limp along taking ever longer to add new features or you plan for the rewrite. When I say rewrite it can be either a total rewrite, module by module, or some other way of slicing your system up. The point is some time goes by and basically all the code is rewritten. You may of course not tell your customers this as they panic easily but believe me it happens in almost every system. Some call it a major release and under the covers a new architecture and new code goes in and the version number gets bumped but what really happened was a rewrite.

The important thing here is to realize that the goal of your rewrite is to enable your system to keep a steep feature versus time curve for as long as possible. In other words, you are able to add features over time for roughly the same developer cost. Programming methods, frameworks and architectures advance so they all help you to manage complexity. This enables you to continue to add features without so much technical burden and unintended side effects. Also important is to realize your rewrite will have 4 phases.

Phase 1 - This is the start of the rewrite and here everyone is happy. You take the best parts of the old system and port them over. There is no old code so things just fly.

Phase 2 - Ok here is where you need to have guts and stick to your guns. You remember all those nifty frameworks, new architecture, new build tools, etc. All those  help but they have their own learning curve. You'll bump into it here. Things slow down, management gets antsy. Hang in there.

Phase 3 - The curve picks back up again as everyone understands the new system and becomes more efficient. Productivity gains from the new architecture and tools really start to come through. If you have chosen wisely, your much better off than with the old system and hopefully you can maintain this development velocity for many years.

Phase 4 - The inevitable happens and you finally hit the wall on your system which by now is the (new) old system. Time to start thinking about the next rewrite. 

12 resolutions for programmers is a great thing to try

Came across this post on hacker news by Matt Might a CS prof at Univ of Utah.

http://matt.might.net/articles/programmers-resolutions/

I'd like to add a couple of resources

For (1) and (2) - Go analog & Stay healthy.
jogging is a great way to keep your sanity. Try the from couch to 5k program
couch to 5k

go vegetarian or vegan
http://features.peta.org/VegetarianStarterKit/

For (4) - Learn a new programming language.
python python python
http://python.org/

For (5) - Automate the real world
Normally I would recommend Arduino but after talking to a good friend of mine I think Raspberry Pi will change the world in the realm of low cost automation. For $25 you can stick a full PC anywhere to control anything.
http://www.raspberrypi.org/

All in all a great list and even if you only do a few it seems like a fun time.

JavaScript as a first language?

John Resig, noted JavaScript demigod, blogs about teaching JavaScript as a first language at the Kahn academy (http://www.khanacademy.org/).

I can see the advantages, I mean:

1. it is everywhere
2. no debug, compile cycle
3. fast path to visual results
4. job market is great

This still feels a little weird to me though. I mean JavaScript is such a franken-language. Or maybe it's me and too many years of Java as my bread and butter. I have been trained to think of OO and classical inheritance as the one true religion. But how in the world do you explain closures or the === versus the == operator or the bizarre behavior of with in JavaScript to a new person. Or do you just say "hey, this is a pretty cool language but some parts totally stink and all of this happened in the go go 90's when this whole internet thing was blowing up so just use this subset of the language and these libraries and you'll be fine"?

Open Source Physics Rocks!

This is so cool, great site with tons of physics resources. The coolest part for me is the simulations. They use Java of course but this team has put together a nice tool set for building and bundling simulations. So you can describe a pendulum experiment and then bundle the simulation into a double clickable jar that will play on any platform.

http://www.compadre.org/osp/index.cfm

Simulations here
http://www.compadre.org/osp/search/categories.cfm?t=Simulation

For example, Doppler effect
http://www.compadre.org/OSP/document/ServeFile.cfm?ID=7902&DocID=678

JavaFX now shipping as part of SDK but it's not truly cross platform???

This is good but what the heck, the system requirements are still windows? I mean something shouldn't go into the JDK until it is truly cross platform. I can't make up my mind about whether to be excited about JavaFX or not. There have been so many disappointments with Java GUI technology. And HTML5 is certainly sweeping the land. But if Java shops could crank out rich interfaces using nothing but their Java skills then it would be a big win even if it mainly is used in intra-company apps.

I saw this on Adam Bien's blog
http://www.adam-bien.com/roller/abien/entry/java_fx_2_8230_comes

The JDK release notes
http://www.oracle.com/technetwork/java/javase/7u2-relnotes-1394228.html

JavaFX system requirements
http://docs.oracle.com/javafx/2.0/system_requirements/jfxpub-system_requirements.htm

Spring context viewer

Spring is a great tool but in a large code base with component scanning and autowiring it can be really easy to lose a handle on exactly what your application context looks like. I had just such a problem at work the other day where I needed a structured view of my Spring app context. This was a context at the war level that had another context as a parent at the ear level. There were some classloader issues involved. Anyway, I was able to query the context to figure out what I needed, but after work I thought about writing a quick ascii tree view of the context. It wasn't too hard and you get something like this.

 === Spring ApplicationContext Info ===

+<ApplicationContext 'shared.context'>

     -startupDate: 12/12/2011 09:19:14.667

     -id: shared.context

     -identityHashCode: 567e768e

     -classloader: EarLibClassLoader : urlSet = [URLEntry : file:/C:/code/sctx/dist/gfde....