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.
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.
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).
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
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.
“NoSQL” databases are a “modern” approach to move away from the strict schema-based, normalized, relational databases. Traditional databases are best suited to interrogation with SQL queries and the modern cloudy databases better suited to map/reduce algorithms; hence the monikers “SQL” and “NoSQL”. Why, after decades of developing “SQL” databases is there a sudden interest in alternatives?
Cutting to the chase, if your application is stable (i.e. your tables aren’t changing and your queries are well understood) the data structure is simple; plus you anticipate having loads and loads of data then, SQL, hard schema, databases make some sense.However, if you are going to be modifying your data tables frequently then SQL databases are a “world of pain”.
In particular, NoSQL databases make the configuration and admin of scaling, or moving to a cloud architecture, a whole lot easier.
In regards to enterprise systems it can be summarised as follows: NoSQL databases become a possible solution at about the same size that denormalizing becomes useful for performance. Traditional SQL/normalised databases have the benefits of rigour and sophisticated schema modification. Novelty can be the enemy of business efficiency so if you do not suddenly need map/reduce there is no reason to move off a SQL database.
You occasionally hear people refer to “security through obscurity”. This refers to the belief that if you make your security scheme as complicated as possible it becomes secure. This is, however, built upon the assumption that “not provably insecure” is the same as “provably secure”.
It is frequently the case that those espousing “security through obscurity” are more motivated by “job security through obscurity”. Abstruse security schemes are fiddly and difficult to operate and also problematic to untangle. They are also difficult to get right. When it comes to ensuring that a computer system is not compromised complexity is the easiest way to make a costly mistake. They often suffer from issues of “weakest link in the chain” or multiple layers of weak security.
So Springsmith applies a very simple philosophy to security…use simple, standard and well used security schemes. The Spring framework is an ideal method for applying this to both new and extant Java projects.
From server database middle-ware to devices in your pocket – the Java language is now all but ubiquitous. Why should you choose Java to address a heterogeneous system?
There is often a temptation to “go native” and use software technologies unique to a particular platform. Using C, or assembler or .Net based on the theory that it will run faster. The development times and specialist knowledge involved with such a course of action almost always vastly exceed the benefit. It is likely better to buy a faster machine, or extend the server farm or move to a cloud based solution.
Although those options might sound complicated, in fact Java assists in implementing them. A common language across the code base also means that functionality can be migrated or devolved as necessary.
There is also nothing like having the same code handing the protocol on both sides of a link!
Springsmith picks up on a project philosophy of build from “something simple and useful”. Although the ultimate target may involve a database server farm, load balanced web-servers and distributed clients with native code; often a project should start by providing a usable chunk of functionality without using all those hardware targets.
Spring provides an opportunity to build up a system by migrating functionality between devices, integrating new functionality and introducing new functional concerns (e.g. network security) as the project evolves. Spring enable you to do this without messing about in already tested source files and often exploiting publicly available code.