Leo Langeveldt's Blog

technology, software architecture, development and whatever else pops into my head

NAS FTW — June 25, 2012


i finally replaced my “so-many-external-drives-that-i-need-my-own-power-station” setup with a NAS solution and i’m glad i did. the Synology 1512+ brought with it a simple, robust way to ensure all my media, various projects etc. is in a simple to access single location that ensures that i never have to worry about a drive crashing ever again (high reliability FTW). certain data is still stored in the cloud, of course, but for less critical data that i need at a moment’s notice, nothing beats a RAID 5 config running over gigabit ethernet. add to that 15W of lower power consumption goodness and it’s a definite winner.

near field communication — April 11, 2011

near field communication

i’ve been doing some fairly lightweight home automation of late. ordered a wireless ip cam from http://www.chinavision.com (delivery within 7 days, great stuff), settin up motion detection and notification via mms, ftp to a central site for later reference and remote viewing via my Android based phone. fitted stereo speakers in the ceiling to get “zone based” sound going. remote control of media via ipad device etc.

but this is still very basic stuff, nothing that hasnt been done a million times before.

the next phase is the stuff that really has me excited … nfc! near field communication allows me to access control virtually anything via an nfc enabled device (ie. my cellphone). and besides access control, there are other applications such as switching on lights when i walk into the house (requires some more hardware but that’s further down the pipeline), switching my phone to bluetooth mode when i get into my car etc.

like i said, exciting stuff.

ill be posting more on this as it progresses. for now, i’m waiting on a batch of tags from http://www.tagage.net/

The five factors powering the Android revolution … from TechRepublic — October 11, 2010

The five factors powering the Android revolution … from TechRepublic

Interesting read …

Google Android is looking more and more like a runaway freight train destined to lead the mobile computing space. Here are the top five factors that are propelling its progress.

The five factors powering the Android revolution

The one I find the most interesting …

Developer momentum

In a recent survey of developers, 72% said Android is “best positioned to power a large number and variety of connected devices in the future.” Just 25% said the same thing about Apple’s iOS. A lot of those developers are making a nice chunk of their current income from iPhone and iPad apps, while still betting on Android in the long term.

good tech = happy techs — August 3, 2010

good tech = happy techs

as i sit here pining away for my macbook pro i5 with super crisp led display while working on a less than stellar lenovo t500 with a display so hazy i’m afraid i’ll go blind before the end of the year, i realise how important it is for companies to empower employees with the not just adequate tools to do the job, but also the right tools to make them happy.

especially where developers are concerned as they are a fickle lot, not always satisfied with what might be the latest and greatest to their boss, but so “last season” as far as they are concerned (hint: intel centrino out, i-anything in). sure, new tech costs money, but weigh that up against the cost of an unsatisfied employ and it’s peanuts in comparisson. once he/she leaves think of re-training costs, ramp up time, etc. for a new employ and that R2k for a monitor is insignificant. you’d be suprised how many geeks cherish having that new 22″ LCD on their desks above any other benifits you might provide. listen in on water cooler talk amongst the nerd herd and you’ll hear boasts of overclocked GPUs and wireless whot-not rather than the new coffee machine and a good medical plan.

Application Architecture vs Technology Architecture — July 27, 2010

Application Architecture vs Technology Architecture

Application Architecture vs Technology Architecture

They’re the same thing, right? No, they’re not. Where application architecture deals with a “map” of applications used in a business and how they interact with each other, technology architecture maps these applications into a set of technology components (both the software AND the hardware it relates to) e.g. having an email solution relates to the application roadmap whereas using exchange on a windows server with specific hardware requirements and outlook on the client side is the technology architecture.

This “soft association” ties into how you plan the migration and implementation of solutions. And that’s where a few architects get confused once they roll the two disciplines into one. Treating it as a single entity results in incorrect timing estimates (and thus costing) for one and incorrect assumptions. Saying “we need an exchange server running on a dell blade” isn’t where you’re planning should start. “Do we need an email solution that is locally hosted?” is the correct question that FIRST addresses the app architecture and might not have the pre-determined result. “Let’s put it in the cloud” might actually be a resultant answer that sees a totally different tech architecture emerge with different implications (like cost etc. as mentioned).

architectural patterns — July 21, 2010

architectural patterns

one of the key areas any architect needs to understand is that of architectural patterns. well described and available to be consumed, a pattern describes the best practice for solving an architectural problem in a specific problem arena. SOA is in fact a pattern (and one of many) that can be applied to a problem area. sometimes patterns can be combined (e.g. SOA & Domain Driven Design (DDD)) to provide an optimal solution. for more on architectural patterns, check out Microsoft’s Application Architecture Guide’s description of the architectural patterns.

business architecture — July 8, 2010

business architecture

business architecture is the essential component that is missing from architecture domains in most organisations. there, i said it. do with it what you will.

in most large enterprises that concept is by far the most neglected. companies neglect the fact that even though they are doing business as usual the rest of the business, especially IT, don’t have a clue as to what’s going on in the organisation as a whole.

the business architecture of any enterprise should outlay the blueprint of the organisation and how it does what it does. be it acquiring new clients to calculating how income is distributed amongst its investors or even just the vision the CEO has for the future, these esssential bits of information should be easily available and understood.

recently i’ve been brushing up on togaf and it’s business architecture model and the following key views are identified that are helpful :

1.) business strategy view : captures the strategic goals that drive an organisation forward.

2.) business capabilities view : describes the primary business functionality or business services of an enterprise and the sections of the organisation that perform those functions.

3.) business knowledge view : establishes the shared semantics (e.g., customer, order, and supplier) within an organisation and relationships between those semantics (e.g., customer name, order date, supplier name).

4.) organisational view : captures the relationships among roles, capabilities and business units, the decomposition of those business units into subunits, and the internal or external management of those units.

through unfortunate trial and error i have made the mistake of NOT taking this into account when designing systems and it’s not a mistake I would make again and I dont recommend you take it for granted either.

the right developer for the job — April 30, 2010

the right developer for the job

interviewing developers is always a tricky thing. they need the right amount of experience, technical knowhow and drive but there are two important
factors that most development managers neglect to focus on – team dynamics and communication.

team dynamics are as important as skill level. a bad fit often results in conflict and as a result an unhappy team and lower productivity. the last thing you want is one of your devs seeking greener pastures because the new hire is, in a word, a jackass. gauging if a prospective hire will fit is not easy. my approach is to usually ask questions regarding interests and hobbies outside the technical sphere in relation to the existing team’s interests. sometimes the super geek that spends his life playing quake may not be the appropriate hire (unless you have a team of gaming enthusiasts). again, not easy to gauge but an important component none the less.

communication isn’t something that most associate with coding. geeks sitting in a dark room doing nothing but writing code and not talking to anyone might be ideal for a garage startup but in a corporate environment, it could spell the end of an otherwise well planned project. between business, business analyst, systems analyst, architect and developer, there needs to be a constant stream of communication (whether written or verbal) to ensure that the final product meets (and in an ideal world, exceeds) a client’s expectations. a break in that cycle will result in system that is flawed (technically, relating to biz requirements etc.). in my experience, the interview itself will reveal heaps about how well the dev in question can communicate. one or two word answers are a first level indication that he or she won’t be the best candidate and a reluctance to speak even more so.

continuous integration — March 9, 2010

continuous integration

The typical scenario : You’re building software. You’re quality assurance process takes place AFTER all software has been built, a sort of big bang approach. Here’s what has been developed, now go and break it. The problem with this scenario is that you now have a complex system with multiple points of failure and testing each one is both time consuming and chances are there are issues that will be overlooked. An issue that that was introduced four sprints ago now suddenly rears its ugly class shaped head and at least twelve other functional points of interest fall to their knees as a result.

Continuos Integration (CI) is a process to help ensure (but not always guarentee) better quality software and (hopefully) reduce the delivery time of this quality software. A simple statement for a process that’s not as simple to implement. So how does it do that : Isolated changes are immediately tested and reported on when they are added to a larger code base thereby providing rapid feedback so that if a defect is introduced it is almost immediately identified and corrected as soon as possible. The process helps to relieve the problem of QA after software has been developed by implementing good practices that test frequently once any changes have been implemented (or on a hourly/daily etc.). It facilitates constant feedback on the status of your product development so that at any point you are able to see who broke what (your basic name-and-shame principle – old school but effective). Because CI detects deficiencies early on in development, defects are typically smaller, less complex and easier to resolve.

There are multiple tools (more on this in another post some other time) such as Cruise Control and Hudson that can be used to automate this continuous testing and build a document trail (in conjunction with other tools such as Sandcastle for .Net) but they are not the begin all of the process. Getting business buy in is more important by illustrating the long term time (and thus cost) saving in speeding up your development life cycle.

embracing the legacy — February 17, 2010

embracing the legacy

i’m currently involved in a project that incorporates legacy technology (COBOL, IBM DB2) and leading edge (.Net, AJAX, SOA etc. etc.) all in one blob (and not in the binary large object kind of way, but I digress).

When faced with such a task most shy away from the challenge, opting to rip out the legacy and replace it with the latest and greatest. until you start looking at costs, timing, affected processes etc. and realise “well that’s not going to happen”. the beauty of a truly service related system is that it’s ok!

your legacy tech can become part of your new eco system using any of the modern design tools (such as domain driven design and it’s many patterns such as the anti-corruption layer offering, as I am using in my project) and you can still have the latest and greatest integrating into it. with enough abstraction the old safely does what needs to and has been doing while the new affords all the benefits attached to it.

next challenge : getting continuos integration to play nicely now that everything is in place …