Monthly Archives: July 2014

JDeveloper 12c

29 Tuesday Jul 2014

Posted by in General, Oracle, Technology

≈ Leave a comment

Tags

, , , , , ,

So I have been using JDeveloper 11g for a while and have to admit that I wasn’t a big fan finding a bit flaky and prone to crashing. The biggest driver to using it has been the fact that it offers a lot of XMLSpy like features without the stupidly high XMLSpy license costs.

With JDeveloper 12c arriving I took the opportunity to give it a go. Wow, is it so much better – quicker particularly during the startup cycle and way more reliable. The features around XSD editing haven’t significantly changed but just feels subtly easier to use.

With all the features around working with SOA Suite 12c and Weblogic 12c for core Oracle development I can imagine it is a huge step forward.

With the easier deployment of 12c getting PoC work done should be a lot easier. It’s just a shame still needs that huge 8GB footprint to do anything meaningful and my company laptop being a notebook (great for travelling with) doesn’t pack that punch and Oracle isn’t yet offering low cost SOA Suite deployments in the cloud yet.

Evaluating SSL certificates for SaaS

29 Tuesday Jul 2014

Posted by in General, Technology

≈ Leave a comment

Tags

, , , , ,

So when looking at SaaS solutions one of the things we consider is the strength of the SSL certificate, and when using a small provider who the Certificate Authority as commercial authorities will provide insurance for a breach which can go to paying some of the cleanup costs (assuming the breach isn’t from negligence).

So how to evaluate SSL certificates in terms of robustness (i.e. cryptographic strength) after all some people will talk. About 128 bit certificates and others such as Google mention 2048 which on the surface don’t seem comparable.

So the bit length is to do with the cryptographic algorithm used of which there are several such as AES, 3DES and so on. No I’m no expert on this so I won’t presume to explain the pros and cons of the different algorithms, there are other resources on the web for that (such as this document).

The point I have been working towards is that NIST (National Institute of Standards and Technology)(aside from being a good resource on security) have tables  that recommends the size of the key used to help build the certificate (the document is here and tables 1 & 2 contain the key details, more here). The tables shown below takes into account the algorithm (therefore a comparator on key size) but also a recommended growth in key size.

 

NISTTable2 NISTTable

 

An alternative representation of the same information can be found here and the 1st table here.

So why grow a key size well one of the factors in driving key size is that as computing power increases the time and effort to brute force crack of a key shrinks. So every time the key size increases so does the effort to brute force the cracking of the key.

This leads to secondary consideration – that of the certificate life i.e. how long the certificate is valid for. This is in effect to potentially greatest period of exposure based on the fact that someone may brute force your certificate and then simply listen to the traffic so you never know of the compromise. Obviously you can revoke the certificate at any time.

Finally remember the need and level of security should be informed by assessing the data being transferred (in motion). Data security should also be considered for data at rest I.e being stored (data loss from a data store is likely to be far more damaging).

Review of Creating Flat Design Websites

18 Friday Jul 2014

Posted by in Books, General, Technology

≈ Leave a comment

Tags

, , , , , , , , ,

I always find when looking at book if I encounter early in the book comments such as “…eventually I found out that design is not about the answers, it’s about asking the right questions …” as Antonio Pratas does in the Acknowledgement of Creating Flat Design Websites that the book feels like I can trust the author as this sort of thing is both an honest observation and one that reflects some more considered thinking. The book beards this point out. For example rather than pitching the technology or approach as a tool for all things as many IT books have habit if doing, even in the first couple of chapters we are clearly informed that flat design isn’t necessarily correct approach in all cases and examples are given to illustrate the point.

The opening chapter explains the ideas of flat design vs skeuomorphic, and a brief history of the design approaches and “flat’s” ruse in popularity. Even providing an incredibly simple illustration that doesn’t demand that you be a graphic artist to achieve to show the differences and how you might move from skeuomorphic to flat.

The following chapters look at the consideration for usability, referencing Jakob Neilsen’s work (and if design piques your interest I’d highly recommend the work of Neilsen’s partner at NN/g – Don Norman with writing such as the Design of Everyday Things). The only criticism I might make here is with UI design, and specifically web there are legal (in the UK this cones presently as part if disability discrimination) and industry standards (particularly W3C’s WCAG standard/guidelines) aren’t really mentioned. But if you start digging into good usability material you will encounter these aspects.

From this point when are then guided through a design approach with plenty of recommendations on how to approach the design phase (from the basics of considering your target audience onwards).  It is only chapter 5 that really get stuck into web tech with HTML and the Designmodo framework built on Twitter’s Bootstrap and chapter 6 covers building your own flat UI framework. So this book maybe pitched at web app development, but actually the bulk of the books content holds true whether you’re working on web solutions, thick apps for the desktop or the mobile variety as it embodies the principles if good interface design.

Not only does it successfully talk about good design it bridges the gap between techies and graphic artists without the sense it is trying to address either skills base. No mean feat.

Rather than stealing the book’s wealth of useful resources, I’ll point you at links relevant the book and it’s author. From there you’ll find a cast array of helpful resources. The references :

CreatingFlatDesignWebsite

Pure REST is not always a good thing

05 Saturday Jul 2014

Posted by in General, Technology

≈ 2 Comments

Tags

, , , , ,

So following REST web service best practice is not always a good thing, but of a controversial statement. That said I came across a situation that beautifully illustrated it.

I was recently asked for my opinion on a web solution that had to interact with customer data. The developers concerned implemented the functionality using REST web services and followed the principles to the letter. Except one of the services needed to locate a unique customer object. To do this the service enough customer details are provided in the URL to obtain a unique record.

So regardless of the security Implemented using strong SSL and payload encryption in the solution implementation we have just exposed every element in the network that can log URIs to DPA levels of security (not to mention information commissioner requests). That is before you consider man in the middle and packet URL attacks.

What to do, such sensitive web services need to be delivered without personal data in the URL, we could go via WSDL (but our use case points to REST being a better approach) or we follow the object creation pattern for REST (and pay the price of not caching the results on the web tier although if we are concerned about security then this isn’t such a bad thing and we can still get performance on the DB tier. Using the payload is probably the right thing to do.