Monday, August 15, 2011
Friday, June 17, 2011
…there is still little consensus on the precise definition of software engineering, and even the legitimacy of using software engineer as a professional title is still being debated….
One of the key differences between engineering and craftsmanship is that the success of engineering projects can be assured beforehand through scientific analysis of their designs, whereas the success of craftsmanship projects is attained through trial and error during current and prior construction….
Monday, June 6, 2011
Pricing is not an exact science, but it is not magic either – it is influenced by perception of your software, market conditions and its value. So what is the process of finding that sweet pricing spot?
Monday, May 23, 2011
Thursday, May 12, 2011
Just installed the Blogger application from the android market. I don't know how it took me so long to discover this app but it really is a must have.
The application does what you would accept - write and post new applications, post pictures from your phone memory card or directly from the camera and tag ur posts. I still need to fugure out how it fairs on formating text etc. The basics are good enough for me.
I discovered there are several other applications for doing the same job but I settled for the official one by Google Inc.
Saturday, April 30, 2011
Monday, April 18, 2011
Read more at the Oracle Technology Network in "Contexts and Dependency Injection in Java EE."
Friday, April 15, 2011
Wednesday, April 13, 2011
The build system should be looked at as a module or component of the software application or platform being developed, so the philosophy taken towards code ownership apply.
If a single person owns the build system, everyone else becomes dependent on them to fix issues with it, and to extend it to meet new needs. There is also a risk, especially for projects which are big enough that maintaining the build system becomes a full time job, that a bit of a siloed mentality can develop.
If developers have a poor understanding of how their software is built and deployed, their software is likely to be difficult and costly to deploy. On the flip side, if build and test tools are implemented and maintained entirely by people who don't develop or test the software, it isn't likely to make the life of those who do as easy as it could be.
In the past few months I've taken on a role which is largely focused on this area, and have been helping a development team get their build and delivery system in place. Pairing with developers to implement aspects of the system has worked well, as has letting them take on the setup of particular areas of the build and test tooling. This follows what Martin Fowler calls "Weak Code Ownership", allowing everyone to take part in working on the build and test system.
Special attention is needed for stages of the path to production as they get further from the developer's workstation. Developers are keen to optimize their local build and deployment, but can often be fuzzy on what happens when things are deployed in server environments. This is exacerbated when the platforms are different (e.g. developers working on Windows, code deployed on Linux).
Even without platform differences, developers understandably focus on the needs of their own local build over those of production system deployment. This is natural when server deployment is not a part of their daily world. So the best way to compensate for this is to keep developers involved in implementing and maintaining server deployment.
Driving the implementation of the build and deployment system according to the needs of business stories has also been useful. So rather than setting up tooling to test parts of the system that haven't been developed yet, wait until the design of the code to be tested starts to be understood, and the code itself has actually started being developed. This helps ensure the tooling closely fits the testing and deployment needs, and avoids waste and re-work.
Blog post originally from Kief Morris' Grok and Roll
Wednesday, April 6, 2011
- #lsof -Pan -i tcp -i udp
It works for AIX, Apple Darwin, FreeBSD, Linux, NetBSD, NEXTSTEP, SCO OpenServer and Solaris 9 and 10.
- -P don't bother converting port numbers to port names - speeds up lsof.
- -n don't bother converting ip addresses to host names
- -i internet address must match the address specified (-i4 and -i6 are used to IPv4 and IPv6 respectively).
- -a used to AND list options i.e show only files that satisfy all list options. The default behaviour is to show files that satisfy any of the list options.