Build systems
Have a look at the following blog : http://karussell.wordpress.com/2009/09/29/evolution-of-build-systems/. Here he is talking about Gradle and Buildr as the next evolution in build tools – have to say I do agree with his picture. Personally I really like Gradle – I am waiting for good IDE integration though
Build system evolution
Grails web development
Have got me head buried deep in grails. I must say it has some really good concepts. The way it gets out of the way and lets you focus on “building up the layers of the onion” from the domain model upwards is really great. My only worry at the moment is that it seems to use quite a bit of memory.. But I cant believe how quickly I have created useful sites – pity that I am terrible at anything artistic (my eight year old daughter draws much better than me..) and they look like they need a facelift….
Tao of architecture
This is an interesting read on the Tao of the software architect. A bit fluffy but if you are in a philosophical mood….
Aspects to “good code”
Posted by Steve in Architecture, Design, Software on November 5, 2009
So, I often have to think about what makes good code. Is it code that is using the latest features of the language, the best patterns, the best layered design, uses the least amount of memory or performs the best? Obviously these are concerns when you design an application but should they be the first things you think of? Probably not!
So then what should you look at? After a bit of head scratching and navel contemplating I came to the following conclusions.So obviously the code / system needs to be scalable, correct (no bugs), complete (delivers what is needed), extendability (it can grow organically) and well documented, but ultimately it will probably live for a long time and will be worked on by many people so… drum roll please…It needs to be easy to maintain and of good quality (have unit tests etc).
What is good code then?
I feel good code is code that “everyone” feels they understand. It is easy to change, add to and re-factor. It should be as simple as possible (but no simpler) and should be as loosely coupled to other systems as possible.
Why should we write good code?
Well the simple fact is that usually many people work on the code over the lifecycle of a system. People leave, get hit by a bus, move on, go to jail etc and someone else needs to maintain what is left behind. The most maintenance programmers either want to completely rewrite all aspects they touch or they are too terrified to touch anything so they bolt bits on the side of programs because it is just too complex to maintain. Both of these scenario’s are bad for everyone involved. Ideally if we approached every project with the spirit of “Ubuntu” i.e. we code for the people that follow us (egoless), things would be a lot better in the long run. Also, if we built quality in right from the start (by using things like Test Driven Design – TDD) it would make the life of people making changes to the code much easier since they have a suite of tests to run that will make them more confidant about making changes (the tests should catch any foul ups or unconsidered side effects)
Lately we have been doing a lot of code audits for firms. This involves looking at the software process from a number of angles.This includes the following:
- Architecture and design
-
- We usually look for the following aspects
-
- Scalability
- Integration points and methods
- Flexibility
- Performance and monitoring
- Database layout and schema
- Code quality
-
- Follows coding style
- Commented and “JavaDoc”ed
- Simple as possible design
- Patterns implemented
- Documentation
-
- Architecture documentation (UML, Context diagram,etc.)
- Specification of some sort
- Technical specification
- Non-functional requirements (load, performance,etc..)
- Testing
-
- Unit tests
- Load tests
- Performance testing and monitoring
- Change control processes
-
- Source control implemented
- Processes around change management
- Continuous build environment
- Issue management process
SOA Manifesto (from http://soa-manifesto.org)
Service orientation is a paradigm that frames what you do.
Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation.
We have been applying service orientation to help organizations consistently deliver sustainable business value, with increased agility and cost effectiveness, in line with changing business needs.
Through our work we have come to prioritize:
- Business value over technical strategy
- Strategic goals over project-specific benefits
- Intrinsic interoperability over custom integration
- Shared services over specific-purpose implementations
- Flexibility over optimization
- Evolutionary refinement over pursuit of initial perfection
That is, while we value the items on the right, we value the items on the left more.
Guiding Principles
We follow these principles:
- Respect the social and power structure of the organization.
- Recognize that SOA ultimately demands change on many levels.
- The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries.
- Products and standards alone will neither give you SOA nor apply the service orientation paradigm for you.
- SOA can be realized through a variety of technologies and standards.
- Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards.
- Pursue uniformity on the outside while allowing diversity on the inside.
- Identify services through collaboration with business and technology stakeholders.
- Maximize service usage by considering the current and future scope of utilization.
- Verify that services satisfy business requirements and goals.
- Evolve services and their organization in response to real use.
- Separate the different aspects of a system that change at different rates.
- Reduce implicit dependencies and publish all external dependencies to increase robustness and reduce the impact of change.
- At every level of abstraction, organize each service around a cohesive and manageable unit of functionality.
Lost generation
Posted by Steve in Presentations on October 23, 2009
Interesting presentation – watch out for the catch ….
