Teach yourself to code (or teach your kids to code).

From time to time I share interesting infographics that I spot on social media. I spotted this one earlier and though it was quite good. I’d certainly endorse the idea of learning Python, Javascript, Ruby and Java. I’d also recommend trying Scratch if you are brand new to development. It’s aimed at kids in primary school but I’ve used in to train staff in the basics of algorithms and software development in the workplace.  You might also want to look at Swift on the Apple devices and .Net C# on Windows, both have free development environments to get you started.

teach yourself coding info-graphic

 

If you are interested in how to get started in software development or have any suggestions do get in touch or leave a comment below. I’ll write some follow-up blogs if there is any demand for articles on this subject.


How to get access to the raw XML when processing XML in Java

I’ve always felt that XML processing in Java is overly complex. Surely something that so many business applications need to do on a regular basis should be simpler and easier by now.

Recently I needed to get access to the raw XML being retrieved in this case from an Amazon Web Service for two reasons. Our application needed to store the raw XML into a database for caching and audit purposes. The other reason was so that we could look at the raw XML to research some corner case issues when the data we received wasn’t quite what we were expecting.

Have done a:

Document doc = db.parse(requestUrl);

You would have thought that Document would have a method along the lines of

RawXML = doc.getRawMessage();

It’s at that point that you really start to question why something so obvious and so simple is missing from standard Java libraries. I did some Googling around and found lots of people asking similar questions. The solution isn’t difficult it’s just unbelievably clumsy.

Basically what I do now is to read my XML source into a string. Once it’s in a String I can do whatever I need with it. For some reason DocumentBuilder.parse doesn’t have a version that accepts a String. You therefore have to use your String to create an InputStream that you can then pass to Parse.

My Solution:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();

// Fetch the XML into a string
 URL myURL = new URL(requestUrl);
 InputStream myInputStream = myURL.openStream();
 Scanner myScanner = new Scanner(myInputStream, "UTF-8");
 myScanner.useDelimiter("\\A");

String myRawXMLRequest = myScanner.next();
 myInputStream.close();
 myScanner.close();

// Output the Raw XML Request to prove we have access to it
 System.out.println(myRawXMLRequest);

// Now instead of passing the RequestURL directly to the parser we
// wrap the Raw XML String in a new Input Stream and pass that into the Parser. 
 
 // Old code was:
 // Document doc = db.parse(requestUrl);
 
 // New code:
 Document doc = db.parse(new InputSource(new StringReader(myRawXMLRequest)));

How to improve MySQL 5.7 Performance

MySQL 5.7 How to fix performance issuesWe upgraded to MySQL 5.7 and have had numerous problems with performance. We upgraded because we needed the new support for fractional timestamps but we’ve since learnt that this functionality has been ported back to MySQL v5.6.35.  So in some situations the best way to fix MySQL 5.7 performance issues is to downgrade to V5.6.35 which actually came out after 5.7.

We also struggled with some indexes which MySQL 5.7 ignored despite everything we tried. The queries kept coming back up in the slow running query log. These indexes then just started working after we had rebooted the whole server for another reason. So if you are finding MySQL 5.7 slow, it’s worth trying a reboot.

The other problem we had was that 5.7 can take a very long time to startup. We still haven’t found a solution for this other than to downgrade back to 5.6.35. It in part seems to be caused by having very large record sizes on some tables but then we also saw it affecting some very short tables. It seems to be that after a restart MySQL 5.7 rebuilds the query optimisation statistics cache and buffer pools each time. In previous versions these can be preserved when the Database is closed down. We haven’t managed to make this work in 5.7.

In my view as of January 2017 5.7 is not production ready and the only real solution to addressing the performance issues is to downgrade back to v5.6.35.  For the record I’ve found MySQL V5.6.35 reliable and performant so far.