Springsmith

Springsmith Ltd was wound up in February 2014. This was following ceasing trading on 28th April 2013 and VAT deregistration.   With the company being registered in England, and no current contracts the sensible thing was to close the company. Thankfully I’m still here… the contact information will remain valid, and like all right thinking business people I’m always on the look out for an opportunity.  Thank you to our customers, associates and friends; particularly those who had to put up with hearing about the frustrations of administration, tax, agencies, accountants, etc etc.

Working in a fast paced but ultimately easily managed way, sometimes these seem contradictory. Working with Git and Subversion you can have your cake and eat it. Github, and similar, allow access you repository using either, but what about those working in environments where Subversion is mandated for projects, but want to use Git for a more agile, more frequent, more personal checkin pattern? 

The Promised Land

There does not seem to be much debate in the software community these days that Git is taking the version control world by storm. This is happening for many sound reasons. Which is great, unless you work in a company where Subversion/SVN is the order of the day.

Disagreement

Choice of version control tool is very much like choice of editor – everyone knows which one is best – except they do not agree with one another. Some people even try to impose personal tools, rather than adopt a policy of “use what makes you happy”. Those people are obviously bananas.

Subversion isn’t really suitable for “Personal Agile”.

Git and Personal Agile

“Personal Agile, what do you mean by that?” I hear you ask. Well…
1) Drive the code forward
2) If it turns out good check it in
3) If it turns out bad role back
4) If it is really not going to plan roll further back
4) Repeat until you get the code where you want to go

This is a pretty aggressive way of working, and in order for it to work partially working/half-baked/frankly embarrassing efforts get recorded along the way; it has to be quick; it has to avoid impacting upon other people and branch’n’merge has to be right in there. Git lets you do all that. SVN does not.

Subversion – it’s in with the Bricks

Many companies have a significant history using Subversion. SVN is perfectly fine for control and good for controlling projects.  People with an SCCS, DSEE, RCS, CVS, ClearCase, SourceSafe background find it is easy to follow.

Version control is however a team collaboration tool so there has to be agreement, respecting what each of these tools can offer and the momentum of history.

One day when the Subversion fans have all retired, the world will see the light and move to Git, but until then… let me tell you a secret…the choice between SVN and Git is a false one because they can co-exist.

Living sided by Side

One thing that many people don’t appreciate is that you can run Git and SVN on the same directory at the same time. This has been eased by the latest version of SVN client adopting the Git convention of a single .svn/.git directory at the top of the tree rather than throughout) which makes things a good deal tidier.

Provided that .git and .svn are listed in the .ignore files it works just peachy – so you can run your own private Git with local “commit/push to Git as often as you like”/rollback policy; and commit/update with SVN only at suitable landmarks e.g. each bugfix / feature introduction.

Tortoise Git and Tortoise SVN work fine in this configuration (with the exception of the icons, which is sugar anyway).

The usual rule of thumb of not leaving it out of SVN too long still applies.

# Ignored files
# Placed in the public domain by Springsmith Ltd in 2013
#
# Note: the first few lines are commented out as they concern
# deliverable executables and without a Maven repository you
# probably want to tie these in with the code that generated them.
#
# *.exe
# *.jar
# *.dll
# *.apk
*.suo
*.user
bin
obj
*.pdb
*.cache
*_svn
*.svn
*.suo
*.user
*.build-res
*.o
*.lo
*.la
*.al
.libs
*.so
*.so.[0-9]*
*.a
*.pyc
*.pyo
*.rej
*~
\#*\#
.\#*
.*.swp
.DS_Store
.git


There is always a debate among those in the software industry (and especially contractors) as to where technology is going to go and what skills are likely to be in demand. This post is an attempt to look at technologies in the whole software stack from  low level drivers to number crunching server software; from top to bottom; from by way of  mobile apps and web services; and surprisingly there is a commonality of themes between them all!

C to remain at the heart of low level drivers and native methods.

This is not really a prediction. It is just a fact  C is really little more than a macro assembler in terms of its abstraction capabilities – in fact it is really a macro assembler for a stack based machines. As such it is ideally suited to the very bottom software layer. Although C++ can add OO on top of that it is probably as well to jump to proper abstracting languages as rapidly as possible. There are exceptions to this for very time sensitive issues such as protocol stacks for communications but, in truth, those are few and far between.

The Java language to continue to make in-roads into the embedded space.

Android phones, e-readers such as Kindle, set-top boxes tablets and Smart-TVs are taking over the world. These platforms all run OSs based on Linux, and have Java based development environments. Increasingly, these are going to provide the standard for GUI interaction that consumers expect, on everything (as surely as colour LCDs took over from Starburst LEDs and Nixie tubes).

Anyone who has coded up a GUI by hand understands just what a tall order it would be to code up a system to compete (just ask Nokia and RIM). Thankfully all the fore-mentioned devices are supported by reference designs and backed by documentation and pool of talent (albeit an in demand pool).

Javascript, HTML5 and CSS to take over data-centric and enterprise applications.

Java applets on webpages are as dead as Flash. Where users interact with data the browser is already king; but the need for browser agnostic

There are fantastic tools for developing for Javascript, HTML5 and CSS; many of them drag and drop and customise.

All the facilities of modern devices can be accessed via such tools and using suitable frameworks, such as Spring, they can interface with the plethora of communications, SOA services and databases which make up the model and control aspects of modern systems.

Groovy and Spring  features (and then Java 8) to take the back-office by storm.

The productivity increases brought about by the use of Groovy and frameworks like Spring will make them an obvious choice for the back office. The devolution of responsibility to smaller SOA services will make the use of tools to generate and maintain such services a no brainer. Groovy’s integration with automated testing (via SoapUI) and its ability to hook straight into Java, will make it the RAD tool of choice.

The facilities provided by Groovy and Spring are both having an impact in the design and specification of Java 8; sometimes directly and sometime obliquely, but functional programming, easy data persistence and cross-cutting are definitely making their way into the Java roadmap. That change to Java will take some time but even once it is made Groovy and Spring based systems will interact more easily and port more readily; and further skills acquired with Spring and Groovy will be the closest thing to experience available in this fast evolving environment.