|^|

Summary: At SXSWi 2013 Ed Hunsinger explained how he used Splunk's big data tools to turn his personal data into visualizations of his productivity, sleep habits and more.

• zdnet.com
• Violet Blue
• March 16th, 2013
• view original

Image by purpleslog via Flickr

We still live in an age where security is too much an afterthought, it doesn't *sparkle* enough – but lack thereof quickly removes any product sheen you ever had when exposed.

Inspiring to see young minds challenging the status-quo in Information Security, like this young girl at Defcon19.

PcWorld -10yr old outs security flaw

This is only a game break  - the scary thing is, you’ll never even hear of the majority of security breaches your Government and Banks experience on a daily basis.

Brilliant, Hilarious and very apt article on ‘Frameworks’ penned by Joel Spolsky “Joel on Software” almost 7 years ago.

It’s funny because it’s true.

http://discuss.joelonsoftware.com/default.asp?joel.3.219431

Image via Wikipedia

I like a good paradigm challenge, so when I stumbled upon this series post by Jeffrey Palermo on software architecture using an Onion layered analogy as opposed to the traditional Stacked layer analogy approach of separating concerns, I was hooked. He talks about something I’ve been battling to put my finger on for years.

The traditional, stacked, layered approach to software architecture was intended to create loose coupling has always had that noble goal – to separate concerns to a level of total layer autonomy. All the projects I’ve worked on follow this principle, yet every time it comes to an architecture overhaul it becomes clear just how tightly coupled these layers have become.

I’ve been doing a fair bit of MVC3 work lately and I like the way the .Net framework is heading, the little things like Convention over Configuration for dependency injection just make programming that much easier and step closer to purer loose coupling. This is where I stumbled onto this view of looking at dependent layers.

I believe focusing  on Domain Driven Design and development is the right approach to creating an agile project that can adapt the users needs readily. That's why I like the Onion Architecture, It focuses on the clear restraint – the Business domain’s needs, no solution can un-couple from it’s requirements – otherwise it becomes something it was never intended for.

The Onion approach builds dependencies outwards from this absolute constraint and approaches projects more realistically. Read the three part series below, Jeffrey does a great job of explaining the thought process.

Jeffrey Palermo on Onion Architecture:  http://jeffreypalermo.com/blog/the-onion-architecture-part-1/