I’ve talked about cports in the past, it’s basically a collection of makefiles which mostly automates the process of downloading, configuring, building and installing applications and libraries for High Performance Computing systems that use environment-modules.
One of the key-features that cports offers is the automated modulefile generation, and the fact that the makefiles acts as documentation to how software is configured, built and installed. It’s currently being used on the clusters at my work place, it has been a boost to the productivity of the systems admin team.
It’s all over the internet that RHEL6 and newer releases will have a life cycle of 10yrs. This is pretty good news for projects that are deploying systems that have a lifetime of 5yrs or more. Namely Digital Preservation projects, not having to worry about migration between point releases of an operating system platform reduces time and costs.
I’m now more likely to target the systems we develop in work towards a RHEL system (or a RHEL like clone).
Waterfall methods seem to work well for smallish projects that are well defined and well understood. At least from my own experiences of putting things together, but realistically to think of all possible scenarios and to write up all the possible solutions to the problem seems a little bit wacky. To also assume that the requirements process has captured requirements that won’t change close the end of the project is also a little unreasonable or unrealistic, this would be especially true on a project that is planned to run for a few years with fairly substantial goals in an ever changing research and development environment.
Apart from the obvious unit testing code which could be fun trying to convince a team to use. There are things known as ‘Continuous Integration’ processes and servers. The basic idea is to continually build and test your product automatically and report on successful and failed builds.
I’ve known about this methodology for long time now but I’ve never bothered to install a CI server since it was always for myself.
Everytime when I install, reinstall or setup a mac desktop or laptop I always tend to install the same set of software that I was using. As time goes on I change what I like to install and what to use. So I’ve been keeping notes and logs of that I usually install first.
For my new job I will mainly be writing documents, writing/modify JAVA code and other bits and pieces that an integrator/architect or release engineer might want to do.
Having worked in a number of cross institutional projects in the past has lead me to always be weary about how to interact with people. Often it’s the lack of co-ordination and communication that seems to be the killer. Parts of the team would seem to not know what other parts of the team are doing and thus either deviate from the master plan or duplicate work.
Gathering requirements for a project is always fun, translating the requirements for a developer to create the end product is even more fun, it often can lead to ‘chinese whispers’ where things just get miscommunicated and misunderstood.
I’ve recently started a new role as being a senior software engineer for an Irish National Project and I have had to refresh my OOP skills with JAVA.
Naturally I gravitated to free and opensource tools to refresh myself. This lead me to install Eclipse, which is the the EMACS of the modern world. I’ve never had much luck with IDE’s nor have I liked using IDE’s much in the past since I mainly dealt with codes written in C, Fortran and if I am lucky Perl or C++.