For many years I have developed websites the old-fashioned way. I have used the MicroEMACS text editor and Unix/Linux command line tools to create HTML/Javascript and Perl/PHP CGI files entirely from scratch, and installed and configured MySQL databases and Apache webservers the same way.
Back in May I wrote about living on the open-source planet. This approach to web-based software development is often associated with the LAMP (I prefer the P to stand for Perl) ’stack’ of technologies.
In my job at the moment, I’m considering what it means to have responsibility for a website - what does this entail? A term that is often used in this respect is ‘webmaster’, but what does this mean? It’s a pretty vague term, but it’s used an awful lot - it’s often seen as text at the bottom of a website page, usually with some sort of contact email address hyperlink.
An enduring aspect of the various academic IT-related jobs I have had over the years has been the ongoing and seemingly endless debate about the merits of the Perl and Java programming languages, with strong adherents on both sides. Perl in many ways is seen by some people (not just software engineers) as a poor contender in this debate - Java is more ubiquitous and widely-used after all, certainly outside academia. But Perl has been around for longer than Java and refuses to go away.
One of the more indisputable advantages of the Internet as it exists today is the abundance of software on it that is ‘free‘. It is free in the sense that it is available to download and use without a financial fee. Some software, as well as being free, is also ‘open-source‘ meaning that the source code is freely available and can be changed for bespoke purposes - something that is obviously anathema to commercial software.
One of the issues a software engineer who develops HTTP interfaces (i.e. websites) as part of their code has to consider is ‘accessibility’. This catch-all term covers many things but essentially means that a website must be implemented in such a way that no-one is excluded from using it. It’s often thought of as purely a website graphical design consideration but it is absolutely something that a coder has to consider.
In the organisation where I am employed there is a dual, almost schizophrenic, nature to the work that I (and the other software engineers in my team) do there. Our funding comes from several sources, but a large portion comes from academic research councils. The nature of this funding is that it involves short-term projects that focus on research materials and on developing internet technologies to deliver those resources to the academic community in the UK in novel and groundbreaking ways. To do this work requires a specific type of software engineer, and one who is happy to take on new challenges where there is little supporting documentation (because very often no-one else in the whole world is doing quite the same thing), a very small but knowledgeable audience of users (typically research academics and information specialists like librarians and archivists), and where the limitations of the funding require that all the software development (and sometimes the project mangement too) are done by exactly one person, perhaps on a part-time basis.
I spend a lot of my time working with and developing Geographic Information software, especially graphical mapping applications. Recently I have been working a lot with the mapping data and JavaScript API provided by the Google Maps service, and I am very impressed with it. It’s very simple to use, and makes adding mapping capabilities to a website a breeze. I’ve used it extensively to display GPS data I’ve collected whilst hillwalking, an example of which can be seen here. A book I found very useful for helping with this was ‘Google Maps Hacks‘ from O’Reilly (my favourite publisher).
There is a well-known ratio in engineering; 80:20. This ratio crops up in software engineering too and refers to several rules-of-thumb that sound a bit flippant but in my experience are valuable real-world guides when managing software development projects. This is also called the ‘Pareto Principle‘.
At the organisation where I am a software engineer, discussions and debates about software development methodologies and tools (such as UML, Agile, XP etc) has gone on for a long time. There is a general feeling that these are a Good Idea, and that we should embrace them, but variety and complexity seem to be big barriers to actually implementing them for real and changing the way we do things.
You are currently browsing the archives for the Software engineering category.
Bad Behavior has blocked 72 access attempts in the last 7 days.