Posted on

How to Start Getting Professional about Software Development

A great blog that simply states management philosophy and the flak that you may experience trying to apply, sometimes simple, dev practices.  It relates to keeping yourself grounded, and patient, and trying out new practices where you can.  The final point in the blog which I’m going to paste here is pure gold.

The grass is always greener on the other side. Switching jobs might be the right thing to do when you get a great offer, or if your current job resists all attempts to change it to the better. But consider this: When you have a real interesting software development position to fill. Whom would you consider? The guy complaining about the last job where he wasn’t allowed to work professionally and therefore hasn’t any real experience in writing tests, never worked with a CI system or a build tool. Or would you prefer someone who introduced testing into a project team, show initiative by setting up hudson on his own machine and is now looking for an employer who supports this kind of attitude. I know what kind of coworker I am looking for. So make sure you tried to make your job a better one, before you leave.

Schauderhaft » How to Start Getting Professional about Software Development.

Posted on

Now reading


JavaFX 1.2 Application Development Cookbook The JavaFX Application Dev Cookbook arrived for me to review today.

It promises to provide some worked examples of using JavaFX in the real world, which is always handy.  After all, why re-invent the wheel? I’m keen to see how it fares in the correctfulness and usefulness of its samples, as well as how they have weathered the newest JavaFX 1.3, and weather the authors site addresses any issues substantially.

Keep your eyes peeled for a review, real soon now.

Posted on

Tempus library for programmatic thread dumps

Turns out doing a CTRL+Break (or equivalent kill <signal> <pid> on *nix) programmatically is a bit harder than I thought.  This thread talks about ways to do it, but the easiest was to use the Tempus library which has a lot of threading tools, including a simple

ThreadDump.dumpThreads(yourPrintstream);

to get a stacktrace of running threads in a current environment.

Posted on

Mongo DB

Watched this presentation about how Sourceforge chose MongoDB for their customer facing webapp.  You know, the one you go to download Azuerus and all those open source apps from Winking smile

Sourceforge chose Mongo because it offered them high read performance although write was sucky but not needed for their app.  They learnt that even though you can put things in one document, you didnt need to retrieve everything all at once and how they easily used up all network bandwidth between the web and mongo server.  Additionally they found they didnt need memcache in between their persistence and the webservers as Mongo was fast enough to serve out the data as it was.

Posted on

Reading Other Peoples & your own old code

Old code is hard to read.  Even your own.  Its not uncommon 6 months down the track, to experience a bit of “what was I thinking when I wrote that?”.  Its one of the first things drummed into me by senior devs at my old work.  The best way to avoid this is to make your code as easy to understand as possible and I believe to do that you need to keep your code modules small (classes & methods) so that they are easy to test. 

But as I try to work with old code bases with long methods and classes with lots of dependencies that are sometimes difficult to test, and with shrinking deadlines to do anything about them, the messages about good practices fall by the wayside.  Its refreshing to see a blog like this, Beautiful Code: A Sense of Direction, talk about the core tennets of keeping things simple, small cohesive classes and refactorings to reduce LOC in addition to a nice example at the start that I read as even your own sh—, um, crap stinks.

BTW, the article made reference to a site that I had come across previously but hadn’t bookmarked which appears to be a great resource on Design Patterns (and Antipatterns) and UML called SourceMaking.com

Posted on

Embedding Tomcat 7 in your App

So what if you ship with a plain old Apache server just to run some aging PHP.  If you have an server app running all the time, according to this post, it looks like you can embed Tomcat, just like you can embed Jetty

Posted on

Strings and intern

Strings, yawn, boring.  They are kinda the bread and butter of our development but lets face it, we can take em for granted sometimes.

So some neat tips from this blog post about Strings in Java. The most useful one being that the compiler builds a string table of all strings that are in code.  The compiler is also smart enough to put strings together, a feature called compiler folding.  Eg “a” + “aa” in code becomes “aaa” in the string table and vars reference the same spot in the string table. All variables reference the premade strings in the string table which leads to faster equals() operations since String#equals() method checks reference equality first before doing a string size or character by character comparison. 

The problem is that if you want the faster equals, you have to have these strings at compile time.  If you have something like

String s1 = “a”; String s2 = “aa”; String s3 = s1 + s2;

then equals performed on s1 and s2 will be reference equals, really fast, but s3 won’t since it will be evaluated at runtime.

Thankfully a simple call to the String’s intern method will register a string in the string table

s3 = s3.intern();

The rest of the blog talks about common mistakes with String equality and understanding immutability. Scarily there was a potential memory leak problem with the substring() method which holds a reference to the original string’s internal value field when providing the sub string.

More importantly talks about different options to compare strings of different locales which have multiple unicode character combinations refer to the same printed character or different characters being considered equal in a locale but not as byte equals.  All things I was never aware of until reading this blog.

Posted on

Facebook as a business platform

I recently attended the Thoughtworks Quarterly Briefing which was about their Tech Radar – a whats hot in upcoming and existing software dev technologies.  One thing that came up as surprising was the idea of Facebook as a Business Platform. 

My first thought, Facebook for business?, am I doing it wrong?  Winking smile But its actually a pretty neat idea.  The concept is simple, if so many people are using FB as a platform for games (Farmville) and other apps then why not business apps on there?  It can be used as a powerful marketing tool or a business information platform.  It is not much different to the way businesses have caught onto SMS to send info around and so if the infrastructure is there, being maintained by facebook, then why not use it?

Its funny when you hear an idea and then see it replicated elsewhere – moments of synchronicity perhaps?.  In my email this morning there was an article about Delta airlines allowing users to purchase tickets on FB. 

Posted on

Legacy Java Systems

I’ve had my fair share of working with legacy code.  I don’t think legacy code is a bad thing because its existence means it has addressed the majority of the needs of the business successfully enough to stay around.  However, as time proceeds, the business needs to change in order not to become a historic entity and so legacy apps need to be updated.  This is usually where the frustration comes in.  You have to work with older development practices and styles you may not be used to.  You also may have to source old libraries or application containers in order to get things to build and deploy. 

However, I would like to think you can make a green field out of anywhere. A lot of other people may disagree, but the legacy system does have the advantage of addressing business need that your own ‘from scratch’ green fields app may not (provided the business need is still relevant).  There was a recent article on info q: Eight Quick Ways to Improve Java Legacy Systems that talked about the following areas

  • Tip #1: Use a Profiler
  • Tip #2: Monitor Database Usage
  • Tip #3: Automate Your Build and Deployment
  • Tip #4: Automate Your Operations and Use JMX
  • Tip #5: Wrap in a Warm Blanket of Unit Tests
  • Tip #6: Kill Dead Code
  • Tip #7: Adopt a ‘compliance to building codes’ Approach
  • Tip #8: Upgrade Your JRE

I’ve used a number of these techniques, but there were some I hadn’t heard of before such as the jdbcWrapper that simply wraps your jdbc driver with a logger so you can see what part of your code executes what SQL. (Tip 2)

Using JMX to trigger cache cleanups as described in Tip 4 is a great idea.  Another useful thing I’ve seen is using scripts and creating a Javascript or Groovy console within your app so that live maintenance can be performed on production environments.

Tip 5 touches on breaking dependencies, which is what you see a lot of in the code base I use. I’d like to get to know more about how to do this

Tip 6 advised that the Emma code coverage tool can also be used to find production code that isnt run (in addition to stuff thats untested)

Tip 7 really rang true to me.  Its easier to bring in all your toys under the sun, but without a common plan, everyone will bring in their own frameworks to solve the same problem and make the app even more confusing to work with.  I like ‘toys’ (frameworks, tools, etc) but I know I can get carried away Winking smile