Cirrus Android Widget for Weather Display Live

One of my recent projects was to develop an Android widget to display the values found in online WD Live clientraw.txt files. It accesses the same data as my other weather related code projects this year: a JSON Web Service for Weather Display Live and a PiFaceCAD Weather Display Console.

I’ve name the Widget “Cirrus” after the cloud genus. The widget supports 18 different weather data points (and displays the current trend for many of these) and 16 different measurement units. It also has colour coding for easy recognition of different temperature ranges (using the BBC Weather temperature colours) and UV index (using the US EPA UV Index colours).

Click to Enlarge

I use the widget to display the current conditions for both my own weather station and others when I travel. So far I have installed and run it successfully on a Samsung Note II (Android 4.4.2), Samsung Galaxy Express (Android 4.1.2) and a 2013 Nexus 7 (Android 5.0.1).

At this time I do not have any plans to publish the widget on the Google Play Store. I have, however, open sourced the code using the MIT License and made it available via GitHub here:

https://github.com/waynedgrant/android-appwidget-cirrus

See the read me for installation and use instructions.

 

A History of KeyStore Explorer – Part Three

KeyStore Explorer (KSE) has existed, in one form or another, since 2002. These days it is a freeware offering but it has not always been that way. KSE started as an open source project before morphing into a commercial project. It is only relatively recently that it was re-licensed to be free for all to use once again. As the utility is now almost ten years old I feel it is a good time to write a potted history of KSE.

This post continues from Part Two and concludes the history.

KSE Freeware

This history continues in late 2009. At the time version 3.4 of the commercial KeyStore Explorer (KSE) was under development but I was growing bored with it. Managing a business was losing its appeal and I was running out of ideas for new features.

First of all I resolved to close Lazgo Software as an enterprise so that I could reclaim the time it was taking to run it. However, before I could do that I would have to cease selling KSE. I was reluctant to go back to an open source model so decided to try something different again by making KSE freeware. This would allow me to keep the utility available to those who had paid for it and make it available to a larger audience without giving away my IP. After putting so much effort into the code I was reluctant to give it away again.

To differentiate the freeware version from the commercial versions I gave it a new major version number of 4.0. Despite the version jump the only difference between 4.0 and 3.3 was the inclusion of the minor features I had already developed for 3.4 and an absence of any licensing code. KSE 4.0 was released in April 2010. I started the process of killing Lazgo Software Ltd immediately after that.

With version 4.0 released I started development of 4.1. I wanted to see if I retained any interest in KSE now that I was free of the shackles of the business. The focus of 4.1 was to expand the selection of signature algorithms to include the various extended length SHA variations. This would be tricky as it would require an upgrade of the Bouncy Castle libraries and therefore the provision of a mechanism for users to upgrade their JRE’s crypto strength. I got some way through the implementation but it took many months to get there. Finally I simply ran out of steam. It was time to park KSE and come back to a decision on its future at a later date.

I took a break and dabbled in a few other pet projects instead. The most enjoyable was my time spent writing a turn-based zombie strategy game, inspired by the classic game Laser Squad, using Microsoft C# and XNA. That was great fun although I have never finished it. I did a lot of studying and dabbled in mathematics and meteorology. It was also during this time that I started blogging on topics including my experiences with scrum, agile and amateur meteorology. It was great having so much free time again. Nine months passed pleasantly without my touching KSE or deciding what to do with it.

Blogtastic

In September 2011 I picked KSE development back up again. I can’t remember why but I just had an urge one morning to start hacking away at it again. It was tough getting back into it after so long away. Nonetheless I quickly found I was enjoying it again. My enthusiasm for KSE was back and I resolved to get 4.1 out the door as soon as possible.

In the 18 months since 4.0 had been released I had noticed a marked increase in the number of downloads KSE was enjoying. It was a no-brainer working out why that was happening. An application will be more popular if it is free as opposed to paid-for. I reckoned that I may be able to leverage the application’s growing user base by combining it with my new-found interest in blogging.

The idea was to start telling users exactly what I had planned for KSE and to publicly invite suggestions for enhancements. Even if I ran out of ideas to progress KSE’s feature set a motivated user-base never would. In addition I could offer a beta test programme for 4.0 and get extra testing from real users. This would be a massive help to me if it worked out.

Using this blog I posted the development updates, invited users to submit enhancements and got a beta test program up and running. The reaction from users was pretty awesome. Many people gave up their time to test and submit bug reports and many more provided their own ideas to improve KSE. I have no doubt that the first beta test programme for 4.1 led to a better finished product. In addition the backlog of user submitted enhancements I am even now working through will continue this process of improvement.

Buoyed by the feedback I hammered through the remaining features of 4.1 making a final release available in March 2012. The expanded signature algorithm support was the main feature but many smaller enhancements were also included.

It is now May 2012 so that pretty much brings the history up to date. Work on 4.2 has started and is progressing well. Of the enhancements that will feature in 4.2 every single one is based on a user suggestion. I’m now confident that running out of ideas is no longer going to be an issue so I’ll be continuing development of KSE for the foreseeable future.

A History of KeyStore Explorer – Part Two

KeyStore Explorer (KSE) has existed, in one form or another, since 2002. These days it is a freeware offering but it has not always been that way. KSE started as an open source project before morphing into a commercial project. It is only relatively recently that it was re-licensed to be free for all to use once again. As the utility is now almost ten years old I feel it is a good time to write a potted history of KSE.

This post continues from Part One.

Money Talks

This history continues in early 2004. At the time version 1.8 of the open source KeyTool GUI (KTG) was under development. Out of the blue I received an email from an IT Security company who had a proposition for me. The company was interested in integrating KTG into one of their products. However, KTG was licensed under the GPL which was not suitable for their purposes. Would I consider, for a fee, re-licensing the source code to them under their own license?

My answer was a maybe and negotiations commenced. This got me thinking. If a proper, grown-up company was prepared to pay good money for a source code license then perhaps end-users would pay for a commercial version of KTG. I decided that they might and started planning a new venture to test this out.

KTG would have to be forked, closed and re-licensed. I also decided to rename it. Firstly because “KeyTool GUI” was a bit of a naff name and secondly to reduce confusion when the tool became a paid-for offering. The plan was to stop working on the open source KTG and start working on the new commercial offering. I settled on the name “KeyStore Explorer” and got to work on finalising the features that had originally been earmarked for KTG 1.8 (notably unencrypted  PKCS #8 private key support). I also had to quickly implement runtime license support and a time-bombed evaluation mode. Source code obfuscation was also added and the code was re-licensed commercially.

(At the time I received some criticism for my decision to re-license the GPL’d KTG source code. Some people suggested that I couldn’t do this. Rather than engage in a debate I left them to their delusions. I own the copyright to the code whether it is licensed under the GPL or not. As such I can re-license it under another license should I choose. In addition my permission is required before any of my GPL code can be re-licensed under any other license. I plan to expand on this and the many other open source misconceptions I have encountered over the years in a future post).

I was determined to run the new venture legitimately and therefore formed a company: Lazgo Software Ltd. I had never run a business before but was looking forward to familiarising myself with the inner workings of a real company. I would have to get to grips with taxes, payroll, dividends, company accounts, marketing and everything else. It may sound perverse but all of this interested me purely because it was all so unfamiliar.

Next came web hosting, the company website and a simple integration with PayPal to enable purchasing. I had to get the hang of PHP and MySQL very quickly to accomplish all of this. Early 2004 proved to be a very busy time for me as I continued with my full-time employment.

Over this time a deal was agreed for a source code license with the IT Security company, contracts were exchanged and a tidy sum materialized in the Lazgo company bank account. I had an initial injection of cash and was ready to release KSE a few weeks later. Selling a single source code license was one thing. Would users pay for runtime licenses? I really had no idea at the time whether or not anyone would be interested in buying a license for KSE.

KeyStore Explorer

Click to enlarge

KSE 2.0 went on sale in May 2004. I offered single, five and ten user licenses as well as site licenses. Over the next few months I was pleasantly surprised to see the sales projections in my business plan smashed. It looked like there was a market for KSE after all and I duly got working on new features.  August and December 2004 saw the release of versions 2.1 and 2.2 respectively. In these versions many UI improvements made an appearance, the Help feature was greatly improved with the introduction of Java Help and functionality relating to CSR, JAR and MIDlet signing were all added.

Providing new features so quickly proved to be a good move when KTG was again forked, but not by me. While I worked on KSE I had abandoned my open source work on KTG. However, there was nothing to stop others from continuing my work. That is, after all, one of the main advantages of open source. I suddenly had competition in the form of Portecle. This was essentially KTG under a another name and again licensed under the GPL. I could also expect the maintainer of Portecle to to start adding new features in future releases. I reckoned that I would have to work very hard to compete with a free offering. To be competing with my own work was odd to say the least.

With sales going well I turned to streamlining the e-commerce side of the business. Initially I had manually fulfilled sales upon notification of purchases from PayPal. This quickly became unsustainable. I moved away from PayPal and signed up with a professional web payments service with a better integration offering. I carried out work to fully automate all aspects of purchasing with license keys and invoices being automatically emailed out on purchase. With most of the drudgery of sales eliminated I had more time to focus on the product.

Click to enlarge

Three more releases followed between March 2005 and February 2006 taking KSE to version 2.5. I focussed on support for new key formats including encrypted PKCS #8, and Microsoft’s hideous PVK private key format. I also invested time and money in making the product look more professional. First impressions are everything and I had to make KSE look as slick as possible if I was going to persuade users to part with their hard-earned cash. It is my belief that the best application in the world will struggle more than it should if it does not look professional.

To describe KTG’s icons as amateurish is being generous and they were still present in KSE up until 2.2. I tackled this by purchasing a license for the excellent Icon Experience icon set and integrated those into version 2.3. I also reworked the splash screen and was quite pleased with the results.

Besides enjoying the development and creative sides of KSE I really thrived on progressing my business skills. During the time KSE was available commercially I experimented with different price-points, promotions and carried out marketing via Adwords. Everything was a new experience to me and that in itself made it all enjoyable.

KSE: TNG

With the release of KSE 2.5 I decided it was time for some major changes in the product. I had basically been piling features onto the same old creaky UI that had been created for KTG. There were many areas ripe for improvement. At the time the tool sported a single document interface which was unacceptable for a modern application. Users could not utilise copy/paste or drag and drop in the application either nor was there any undo/redo support. Installation options were also lacking with only Windows or manual installations available. The application was written in Java and worked perfectly well on Mac OS X and Linux so why not cater directly to those users? As a commercial application, users would expect all of these features and more.

Click to enlarge

KSE versions 3.0 – 3.3 were written and released between March 2006 and November 2009. I included many new features including a tabbed multiple document interface, cut/copy/paste support, drag and drop export, undo/redo, a Mac OS X disk image, a Linux/Unix self-extracting install, a new Quick Start welcome UI, Tip of the Day, support for many new key and certificate formats (PKI Path and SPC certs, Netscape SPKAC CSRs, OpenSSL keys), support to edit X.509 extensions and many more improvements too numerous to mention here. I also continued to improve the look and feel of the application with custom icons commissioned from Iconaholic (see the modern KSE application and KeyStore icons for examples of their awesome work) and continued by obsession with tweaking the splash screen.

Click to enlarge

For the first time KSE felt to me like a grown-up desktop application. In addition I was miles ahead of any of the competition in terms of features (many open source keytool UIs had sprung up in the intervening years). I had invested heavily in terms of my time and reinvested some of the profits wisely in terms of icons, third party libraries and the many books I had studied over the years on general security, PKI, UI design and business. However, it was all worth it. Sales were still good and I could now say that I knew how to run a profitable business.

Unfortunately by late 2009 a lot of the fun and excitement had evaporated. I had greatly enjoyed the experience up until then but was growing a little bored with running Lazgo Software. I had streamlined all I could but increasingly dreaded my quarterly weekend session with the accounts, dealing with the tax man and the plethora of other really dull things that are involved in running a business. Running the business was not a challenge any more, just a bit boring. Worse still I had no idea what direction I could take KSE in. It supported every relevant crypto format and was feature rich. It just seemed done to me.

So the business definitely had to go. When something isn’t fun any more it isn’t worth it no matter the money it brings in (when I told people this at the time they looked at me like I was nuts, maybe I am). I still had to decide what to do with KSE, however. I will detail what happened next when I conclude this history in part three.

A History of KeyStore Explorer – Part One

KeyStore Explorer (KSE) has existed, in one form or another, since 2002. These days it is a freeware offering but it has not always been that way. KSE started as an open source project before morphing into a commercial project. It is only relatively recently that it was re-licensed to be free for all to use once again. As the utility is now almost ten years old I feel it is a good time to write a potted history of KSE.

Inception

Back in mid-2001 I was a relatively green programmer with only four years of industry experience, mostly in C/C++ and RDBMS. I had just joined an ISV in Glasgow to cross-train as a Java developer. Many things interested me about the language notably its simplicity when compared to C++, the principle of Write Once Run Anywhere (WORA) and the cross-platform GUI toolkit: Swing.

(WORA and Swing are much maligned but not by me. If you put in the effort into each you can reap the benefits. I may dip into these topics in later postings).

All was well in my world. My employer looked to be going places, the fallout from the Dot Com bubble hadn’t yet bitten and I was working with interesting technology. However, to get the full benefit of working with Java and Swing what I really needed was a side-project, something outside of work where I would be free to develop as a chose, free from interference. As a bonus it would be great if the side-project was something new. The last thing I wanted to do was write yet another text editor or world clock, something that had been done a hundred times before.

It was then, in the course of my day job,  that I came across keytool. What keytool did intrigued me as I had no previous exposure to Cryptography. How it presented itself, on the other hand, with its ugly command-line interface provided me with an opportunity. I decided I would use Swing to recreate keytool in the form of a friendly GUI. I did some research and discovered that nobody had yet written a decent GUI alternative for keytool. I had found my side-project.

Thanks to the Way Back Machine I have been able to retrieve my exact thoughts at the time. Back then I wrote on the original tool’s website under the heading of “Why Bother”:

“As mentioned above Sun already supply keytool with the Java SDK and the KeyTool GUI is just a GUI implementation of (approximately) the same functionality. So why bother?

I found keytool to be a bugger to use with it’s many and various options. Command-line tools are, after all, invariably harder to use than equivalent GUIs. Secondly keytool forces its users to type in keystore and protected entry passwords in the clear on the command-line. This, of course, defeats the whole purpose of protecting keys in a keystore in the first place! Thirdly I needed a wee project to get me up and running using Swing.

So in an attempt to create an alternative to the command-line keytool utility (and get some practise with Swing) I’ve put together the KeyTool GUI.”

KeyTool GUI

Click to enlarge

So KeyTool GUI (KTG) was born with the aim for the application being that it not be “a bugger to use”. At first progress was slow as everything was new to me. My Java experience was limited, as was my exposure to GUI programming and UI design and I knew next to nothing about cryptography or PKI. However, it was great fun developing all these new skills. My core Java skills improved far more rapidly than they would have done through my day job alone. I also greatly improved as a UI designer by learning as much as I could from existing applications and various publications. However, what turned out to most challenging was the world of cryptography and PKI. Fortunately with the aid of many books and the Java Cryptography Extensions (JCE) and the Bouncy castle JCE provider I was able to progress in this area rapidly.

Early on I decided to open source my efforts so that others could benefit from my work. I settled on the GPL without too much thought. The idea of open source was new to me too and it struck me as being the most popular license at the time.

I worked for a year to produce version 1.0 releasing alpha and beta candidates during this time. When released in April 2002 version 1.0 was fairly feature rich allowing users to utilise a UI to create, modify and save JKS KeyStores. They could also generate RSA and DSA key pairs, import trusted certificates, create CSRs, import CA Replies and delete and rename KeyStore entries. In other words, the core functionality of keytool.

Over the next 20 months six more versions were released culminating in version 1.7 in January 2004. Many additions were made during this time including extending KeyStore support to include the JCEKS, PKCS #12, BKS and UBER types, the ability to examine Certificates and CRLs, CA Certificates support, PKCS #12 key pair import, a Windows installer as well as many usability improvements.

By version 1.7 KTG could be described as a complete replacement for keytool. However, there was still plenty of room for improvement so I planned to release more versions. After all there was no reason to be limited to simply imitating what keytool could do. Some of the improvements planned included converting the single document interface to support multiple files, to extend support to include more crypto algorithms and file formats and to create installers for other platforms like Mac OSX and Linux.

Click to enlarge

Also, despite effort being lavished on making the UI easy to use, it was still a bit ugly, especially in the icon department. The icons were  those provided by Sun’s look and feel guide for Swing and some I had cobbled together myself. I had no idea how I could source high quality icons but I was determined to improve what was in KTG at the time. However, I still like the splash screen that I put together for KTG which featured my own set of key ring. In fact I still use the swiss army knife featured on the splash screen above.

Regardless of its limitations the tool was proving popular with over 2,000 downloads a month and I received overwhelmingly positive feedback from users. This helped spur me to carry on development.

In early 2004 I was working on KTG 1.8. Despite this version 1.7 proved to be the last version of KTG released as 1.8 never saw the light of day. I will detail why KTG was abandoned when I continue this history in part two.

Code Visualisation with Relief

A colleague recently pointed me in the direction of an interesting code visualisation application called Relief. The purpose of the tool is to analyse a Java project and present the objects therein as a 3D model with various characteristics to show size, client/provider dependencies and frequency of use. I had some spare time this week so decided to use Relief to visualize the KeyStore Explorer (KSE) project code.

The set up process for Relief is relatively straightforward. You’ll need JRE 1.5+ and Java3d 1.5+. I plumped for Java 1.6 and Java3d 1.5.2. I had to use the Windows installer for Java3d  as, try as I might, I couldn’t get Relief to find a manual install. Another tip is to make sure that you run Relief with the JRE that Java3d installs itself into.

Once installed Relief requires an xml configuration file which points it in the direction of the project source to analyse and any dependant libraries. Here is the config file I created for KSE:

<parser name="JavaParser">
  <driver>org.workingfrog.relief.plugins.java.JavaConfigHandler</driver>
  <projects default="kse">
    <project name="kse">
      <jrePath jreVersion="1.6">C:\Program Files\Java\jdk1.6.0_23\jre</jrePath>
      <basedir>C:\projects\kse</basedir>
      <!--blackbox /-->
      <build>bin</build>
      <src>
        <path>src</path>
      </src>
      <lib show="false">
        <fullpath>C:\projects\kse\lib\AppleJavaExtensions.jar</fullpath>
        <fullpath>C:\projects\kse\lib\bcmail.jar</fullpath>
        <fullpath>C:\projects\kse\lib\bcprov.jar</fullpath>
        <fullpath>C:\projects\kse\lib\binor.jar</fullpath>
        <fullpath>C:\projects\kse\lib\jh.jar</fullpath>
        <fullpath>C:\projects\kse\lib\junit.jar</fullpath>
        <fullpath>C:\projects\kse\lib\looks.jar</fullpath>
      </lib>
    </project>
  </projects>
</parser>

Fortunately KeyStore Explorer has very few dependencies. Note the commented out ‘blackbox’ element. Relief will analyse dependencies based on either interfaces alone (blackbox) or implementation. Running Relief against the config file involves running a simple command line:

java -jar relief.jar kse.xml kse

If a dependency is missed a ClassNotFoundException will be displayed in the console and Relief will freeze on its splash screen. To fix this simply kill it, add the missing dependency indicated by the exception and re-run. Once all dependencies have been included the Relief should start with no errors.

I ran the tool with black-box switched off as I wanted to see the true dependency picture in all its ugliness. The project code is analysed on start up and the analysis  is very fast. The time to start Relief for the KSE project was 15 seconds on my Macbook Air running Windows 7. That is impressive given that the KSE code base is made up of 286 classes over 33 packages and encompasses ~37,000 lines of code.

After analysis completes Relief displays an impressive 3d model:

Click to enlarge

The screenshot above shows each KSE package as a cube and dependencies between packages as gradiated lines coloured from green to blue (green for the provider, blue the client). Some other key features visualised are:

• The bigger the package’s cube the more classes and interfaces the package contains.
• The closer to the centre of a diagram a package is the more it is utilised (see grey concentric circles for reference).
• The lower down a package is the more dependencies it has on other packages.

Using a mouse it is a simple matter to rotate, pan, zoom and move the 3D model to focus in on a particular area. In addition double-clicking on any package will bring up a diagram featuring the same visualisations for the package’s contents. Relief contains a few other options I haven’t played with yet including set operators and the ability to show dependencies to third party library entities and to the Java Standard API itself.

The author of Relief touts it as a ‘design tool’. I would not go as far as that as I don’t see myself using it as part of my development process. It is, however, a cool tool that appeals to my inner geek. If I was to take a picture of KSE’s code to put on my wall (which I would never do, I’m a geek not a complete saddo) then I would use Relief as the camera.