Archive for the ‘Development’ Category

A vocabulary for product licensing

Published by Rob on April 14th, 2011 - in Development

Getting a shared vocabulary for conversations is always useful. Here’s a pattern/vocabulary that I’ve recently been introduced to for thinking about software product licensing.

  • Product Key
  • License
  • SKU

Product Key

A product key is the cryptographic software control used to control who/what can use the software

License

A license is the concept encapsulating that a customer is allowed to use the software. A customer is licensed to use software. This probably aligns with the legal contract that is used.

SKU

The SKU/stock keeping unit is how sales people can talk about the product. They sell a SKU to a customer.

The customer licenses the SKU (product), and then they are issued a product key which enables them to use the software.

The precise definitions for product keys, licenses and SKUs is valuable when communicating between product, sales and marketing teams. The list above seems to work pretty well. Let me know in the comments if you’ve got better ideas.

No Comments »

A Version Labelling Scheme for Software Product Development

Published by Rob on March 31st, 2011 - in Development

Computer software typically has a . separated version number. These numbers have value in helping to understand which version is being used. There is a shared understanding that things go from the most significant part of the version to the least. Having some precision around talking about a version labelling scheme is useful for setting up product lifecycles and communicating the details of a product.

I’ve heard numerous ways of thinking about the build numbers, normally involving terms like major and minor. I’ve never quite been able to keep the terms and distinctions clear in my head, so was pretty excited to recently hear a different approach, which I’ll share below.

Version.Release.Modification.Build

In numbers this will look something like:
3.4.5.1234

The idea is:

Version — a major product version. Customers care and know about versions. Versions are where potential breaking changes might happen.

Release — a major product release. Customers will care about releases. New functionality and bug fixes are introduced in releases.

Modification — a publicly available bugfix modification to the software. Users should be able to safely move between modifications of a product without breaking things. Modifications are focused around fixing problems in software.

Build — the internal build number for the software. A build is useful for the unique identifier of the software by development. The build number will be incremented automatically by the build system. Typically an officially released modification will only have one build number.

Another factor to consider in the system above is that the first two numbers are typically controlled by the Sales and marketing arms of a company, and the last two should be controlled by engineering. In fact if the last two numbers are being done correctly they should be automatically incremented, not being changed apart from automated systems and well defined rules.

For the first sets of numbers, engineering should be able to suggest that new functionality should be increasing at least the release, but it is a sales and marketing decision as to how much of an increase these might get.

2 Comments »

A Thought On Dynamic Languages

Published by Rob on January 7th, 2011 - in Development

Reading http://www.codecommit.com/blog/ruby/monads-are-not-metaphors got me thinking on a tangent not related to the article. The examples start in ruby then move to Scala. Daniel points out the difference between some of the scala and ruby code which led me to the following thoughts.

Duck type code encourages reading the source of methods to see the type requirements of params. This is  a good thing.

For this to work well methods need to be short and well written, another good thing. While this doesn’t negate the value of STRONG types, it does make the case for dynamic languages better.

No Comments »

4 Tips from the Unix Greybeards

Published by Rob on September 28th, 2010 - in Development

So I’ve been using Unix for a number of years, and think of myself as relatively competent in using Posix based operating systems. I’ve recently had the great pleasure of working with a few guys who’ve been using Unix for longer than I’ve been able to read, and I’ve been able to add a couple of more commands that are extremely useful. It’s always great to watch a master using their tools, and to learn while working with them.

The commands below are a mix of ones that I’ve just learnt. I probably should have known these already – but they are lovely, and you need to add them to your arsenal.

  1. !!
  2. locate
  3. look
  4. xargs

    1. !!

    re-execute the last command.

    !! also has friends like !COMM where it will execute the last command in your history that starts with COMM.
    e.g.

    1
    !find

    will re-execute your last find.

    2. locate

    With a locate database setup, locate is magic. Think spotlight for the commandline.

    3. look

    The man page for look talks about it searching a file, then mentions about the default location being /usr/share/dict/words. The default location is the key for the best usage. It’s a great little dictionary for looking up how to speel words.

    4. xargs

    The most masterful developers that I work with have advanced beyond xargs to the next level, but for people continuing on their pathway to true unix mastery, xargs is a great tool to add in.

    I commonly end up using variations of find and xargs together to search the contents of files, or to find out information about a project. If nothing else, the command:

    1
    find . -name "*.java" |xargs wc -l | sort

    is your friend.

    Tags: ,
    4 Comments »

    Eleven reasons to use the Play! Framework for Java Web Development

    Published by Rob on April 10th, 2010 - in Development, Java, Play! Framework

    The Play! Framework is a great tool for rapidly building Java web applications. Play! takes many of the ideas from the dynamic languages world (Rails and Django), and provides them to Java web development. Reasons to conside Play! for Java Development are:

    1. Rapid development via a local development server that automatically compiles your java code for you. It’s amazing how good it is to develop like this, and what a difference the rapid feedback loop makes.
    2. A good clean MVC famework.
    3. Nice testing support baked in.
    4. A useful routing table to make clean urls easy to work with.
    5. A focus around REST, but no slavish observence of it.
    6. built-in simple JSON support.
    7. A good module framework with useful modules including a “CRUD” module, and a Scala module currently under development
    8. An interesting mix of Java class enhancement that makes it easy to work with code, and then have the enhancer provide some of the hard work for ensuring that multiple threads are handled well.
    9. Deployment to a range of platforms, including JEE Servlets (Play! 1.0.2 has been tested on containers such as tomcat, jetty, JBoss and IBM WebSphere Portal 6.1), and the GAE.
    10. Enhancements to the JPA which make it really easy to work with.
    11. An active and supportive community. There is the right balance between having strong opinions about the “Play!” way of doing things, and helping people to get things done.

    Play! makes Java web development fun and productive. The feedback loop is really quick, and much of the boilerplate code is removed. It’s well worth considering for any application you want to write in Java.

    Take a look at the video, and work through the tutorial to get a feel for what development with Play! is like.

    Tags:
    8 Comments »

    Notes on Installing the Connections 2.5 Pilot

    Published by Rob on November 24th, 2009 - in Development

    The installation of the Lotus Connections 2.5 pilot looks easy. Unfortunately the out of the box experience was not at all pleasurable for me. Here are some of the issues that I encountered while doing the install. I’m not sure how many of these were specific to my environment, but they did all hurt.

    1) Don’t install from a directory with spaces.

    If you download the pilot to your desktop and try and install from here, things will crash and burn

    2) Don’t expect the VM to be easily moved around networks

    I started my second installation on my laptop at home, then brought it to work. This crashed and burned.

    3) Use fully qualified hostnames

    While the installer said that you could specify a short hostname or a fully qualified hostname, the short hostname did not work for me.

    4) Connections 2.5 is RAM hungry

    1.5 GBytes is not enough 2.5 GBytes is. Not sure of the exact threshold for it to work, but I can confirm that 2.5 GBytes is enough RAM.

    2 Comments »

    Making the Home and End Keys work in Eclipse 3.4 on Apple Mac OSX

    Published by Rob on June 12th, 2009 - in Development, Java, OS X Tools, Tips and Tricks

    Hidden in the comments of the article of Starry Hope – Mac Home and End Keys are some instructions for how to make the home and end keys work well as begin and end line in eclipse.  I've done all the other tricks to make this work on my Mac, so was getting really frustrated with Eclipse.  double home and double end are common key combinations for me in IntelliJ and Eclipse on Windows, so the current behaviour of going to the beginning or end of the file drives me crazy.  The details of doing this differ slightly in Eclipse 3.4.1, so I'll list the steps I followed below.

    1. open the eclipse preferences pane
    2. general->keys
    3. in the filter type line start and note that there will be existing bindings when editing text.
    4. select line start type home, and ensure that the "when" field stays with Editing Text
    5. apply
    6. follow this process for select line start, line end, and select line end.

    After doing this, expect your anger at eclipse on Mac to decrease to much more manageable levels.

     

    13 Comments »

    Port forwarding with iptables and debain

    Published by Rob on June 2nd, 2009 - in Development

     

    Subtitle: 

    Avoid Remembering that VMWare Server Listens on Port 8333 

    Alternate subtitle:

    Make Tomcat Listen on Port 80

    It's increasingly common for applications to have web front ends.  These all tend to run on their own port, which is nice in that it stops services from running into each other (and means that they can run as non-root), but is somewhat painful in that there are always a whole heap of different ports to remember.  Exposing a service over port 80 makes it much easier to use (especially on ie which is dumb, and doesn't know to make requests to non standard ports default to port 80, generating much rsi, and many hours logged into the IE Waste Recorder).  Making services listen on port 80 on Debian is pretty straight forward.  Follow the process below (which I pinched from someone somewhere in the blogosphere a while ago, put on a server as a part of some work with SSH Tunnelling, and only remembered recently when we were getting some VMWare servers setup). So here is the script. In your /etc/network/if-up.d add a script with the following:

    #!/bin/sh

    PATH=/sbin:/bin:/usr/sbin:/usr/bin

    # Flush any existing firewall rules we might have
     iptables -F
    iptables -t nat -F
    iptables -t mangle -F
    iptables -X

    # Perform the rewriting magic.
    iptables -t nat -A PREROUTING -p tcp

    1
    --

    dport 80 -j REDIRECT

    1
    --

    to 8222
    iptables -t nat -A OUTPUT -o lo -p tcp

    1
    --

    dport 80 -j REDIRECT

    1
    --

    to-port 8222

    This forwards requests from port 80 to port 8222, and will work for local and remote requests.  I keep this in a script called /etc/network/if-up.d/firewall, because iptables is firewallish, and I believe this is the standard place for this to live.  Remember to chmod +x the script. 8222 is the http port for vmware, and will redirect to 8333 using https. By putting the script in the /etc/network/if-up.d it will automatically be run when the networking layer of your debian installation is brought up.

    As per the NewInstance post, this will work for Tomcat as well (Luigi put the iptables rules in a different spot, but that was in 2005, and /etc/network/if-up.d is the right place for this).

    So with the above iptables rules, it will be easy to make any service available on port 80.

    Tags: ,
    No Comments »

    Updating RubyGems in OSX 10.5.7

    Published by Rob on May 27th, 2009 - in Development, Ruby

    .7When recently trying to install Sinatra via RubyGems, I got a message that RubyGems was out of date. I figured that gem would be smart enough to have an easy upgrade command, so there had to be a command to easily upgrade. Naturally there is:

    1
    <span style=" background-color: #ffffcc;">gem update --system</span>

    I only found this when looking through google, and I got a series of pages warning to be careful when using

    1
    <span style=" background-color: #ffffcc;">gem update --system</span>

    as it can kill existing gems (http://puctuatedproductivity.com/2007/11/01/unistalling-ruby-installed-by-source-on-os-x, http://thenoobonrails.blogspot.com/2008/06/doing-gem-update-system-might-lose-all.html) so I was a bit nervous.  Since I have a periodic use of ruby and I'm lazy enough to make Larry Wall proud, I figured I'd take a punt on just using

    1
    <span style=" background-color: #ffffcc;">gem update --system</span>

    .  Turns out it just works, and I've kept all my old gems.  Hooray.  Given that the posts talking about issues are old, I'm either assuming that they've done things differently to me, or things have been fixed since then… so… if you need to update gems due to a message:

    ERROR: Error installing sinatra:
    fastthread requires RubyGems version >= 1.2

    or similar, just use

    1
    <span style=" background-color: #ffffcc;">gem update --system</span>

    Tags: , , ,
    No Comments »

    A Review of 5 Java JSON Libraries

    Published by Rob on May 7th, 2009 - in Development, Java

     

    json.org lists 18 different Java libraries for working with JSON (Flexjson gets a double mention). These provide varying levels of functionality, from the simplest (the default org.json packages), to more comprehensive solutions like XStream and Jackson. Join me on a quick review of some of these, focusing on those which have friendly licenses, and meet my requirements.  If you are lazy, you can fast forward to my summary

    My Requirements

    1. Serialises and Deserialises JSON
    2. Lightweight and Simple
    3. runs on Java 1.4
    4. Friendly license

    The contendors

    1. org.json
    2. Jackson
    3. XStream
    4. JsonMarshaller
    5. JSON.simple

    Serialises and Deserialises JSON

    This might sound like an obvious requirement, but I’ve seen at least one library which was completely focused on spitting out JSON, without any support for reading JSON. I’m actually using this as a pre-requisite for inclusion in my comparison. If a library can’t read AND write JSON, I’m not going to consider it.

    Lightweight

    I’ll begin by stating that my actual usecase is to operate within a plugin for EditLive!. I don’t need a all singing all dancing JSON serialisation/deserialisation library. There are some very cool libraries out there that do awesome stuff, but all I need to do is read and write JSON data.

    Coupled with this is that I’ll want to be able to keep the memory footprint pretty low, so want to work with Java Streams without needing to necessarily pull in the whole serialised object if I don’t need it.

    Runs on Java 1.4

    Yep it’s still out there. Thankfully Java 1.4.2 has reached it’s EOL, but businesses can still request patches, and there are most definitely still Ephox clients running on this JRE, even though more recent JRE’s work so much better. (side note: If you have the option of upgrading your JRE to Java 6, please do it, the children in Africa will be much happier. Everytime someone runs up a 1.4 JRE a puppy dies). 1.4 is in it’s final death throws, but it is still kicking.

    Friendly License

    For Ephox to make money from the product/component that uses JSON (gotta think about the $$$ at the end of the day), I’ll need to make sure that the license is non-viral and Enterprise friendly. Apache license good. GPL bad. (sorry FSF)

    Assessment 

    So having run through the requirements, we can now consider the options. For each library, I’ll provide a simple table.

    The metrics I’m using to judge the libraries are included in the table. The most crude metric that I’ve got is the number of classes. I’m more than happy to admit that this is a very crude way to measure how lightweight the library is, but it does provide an ok rough heuristic, particularly given that there are order of magnitude differences.

    org.json

    The granddady of them all. This comes pretty close to being a reference implementation. It provides a nice simple API (7 classes), doesn’t try and do any magic, and just makes sense. I’ve used it before when working with small amounts of data. Unfortunately it doesn’t provide any streaming goodness.

    url http://www.JSON.org/java/index.html
    classes 7
    Streaming support No
    Friendly License Yes
    Java 1.4 Yes

    Jackson

    Jackson advertises itself as a fast powerful conformant JSON processor. It provides heaps of features, and looks to be a good tool for reading and writing JSON in a variety of ways (see the Jackson tutorial for more). The drawback of Jackson for my purposes is that it isn’t exactly svette at 250 classes.

    url http://jackson.codehaus.org/
    classes ~250
    Streaming support Yes
    Friendly License Yes
    Java 1.4 Yes

    XStream

    XStream gets a mention because it’s cool :) . I haven’t really considered it because it provides more of a direct object serialisation format, which wasn't quite what I'm looking for. Also, it’s heritage as an xml serialisation format shows, and it likes Java 5 much better. The ability to directly go between Javabeans and JSON java classes is cool, but I don't need this magic or the 200+ classes that come with it.

    url http://xstream.codehaus.org/
    classes >200
    Streaming support Yes
    Friendly License Yes
    Java 1.4 Yes

    Json Marshaller

    Json Marshaller sells itself (it almost sounds like a bolierplate project description by now) as “Fast, Lightweight, Easy to Use and Type Safe JSON marshalling library for Java”. It’s been under consistent active development for a number of years, and looks to be headed in the right direction. Unfortunately the current version has 3 deal stopping flaws for my environment at the moment.

    1. It requires Java 5
    2. It has a dependancy on ASM (the developers are looking to remove his dependancy)
    3. While it hasn’t quite piled on the bulk of XStream or Jackson, it still has a couple to many classes for me to consider

    These constraints make it not quite fit for my purposes, but like all decisions, it depends on your own situation.

    url http://code.google.com/p/jsonmarshaller/
    classes ~50
    Streaming support Yes
    Friendly License Yes
    Java 1.4 No

    JSON.simple

    JSON.simple advertises itself as “a simple Java toolkit for JSON”. It provides reading and writing to JSON streams. It’s lightweight and focused on generating JSON from Java code. The critical feature it provides is support for Java IO readers and writers.

    url http://code.google.com/p/json-simple/
    classes 12
    Streaming support Yes
    Friendly License Yes
    Java 1.4 Yes

    Summary 

    For the interested, here’s a table that summarises my findings.

      org.json Jackson XStream Json Marshaller JSON.Simple
    classes 7 ~250 >200 ~50 12
    Streaming support No Yes Yes Yes Yes
    Friendly License Yes Yes Yes Yes Yes
    Java 1.4 Yes Yes Yes No Yes

     

    Conclusion

    If you are looking for a simple lightweight Java library that reads and writes JSON, and supports Streams, JSON.simple is probably a good match. It does what it says on the box in 12 classes, and works on legacy (1.4) JREs.

    Tags: , , ,
    16 Comments »
    © Rob@Rojotek