The project I’m currently working on uses a simplistic object store for persistence. The original authors, in their collective wisdom, decided that whenever something needed to be saved they would save it to a hashtable, and use Java serialization to save that to a file.
In a way I can see why they did. It’s a quick way of getting a simple to use object store. The project has been through several revisions since, but the data store stayed the same. It should have been replaced with something more robust a long time ago. I’ll explain more after the jump …
Anecdotally, I had always known that Software Engineers are terrible at estimation. I had never realised exactly how bad we are.
Some rules of thumb which seem to pop up now and again, is to take your engineers best estimates, and double them. Then you’re actually in the ball park.
BBC News reports that a recently published Microsoft study found that more than 97% of email sent is spam. Seeing this, I can’t help but feel that email is becoming a victim of it’s own success. With a signal to noise ratio like this, one as to wonder how long it can be before email becomes ignored as a mainstream communications channel?
In this paper we discuss approaches to Incident and Problem management within the context of IT Service Management, and its de facto standard the Information Technology Infrastructure Library (ITIL). We show how the Problem Management process attempts to diagnose problem root causes by applying various analysis techniques to historical incident data.
We propose a new categorisation mechanism. We break the data free from its hierarchical categorisation scheme through the use of a free form tagging system. By allowing all system users to categorise incidents using their own terms, we show that while individuals may differ, the aggregate meta data produced for each incident stabilises.
Further, by the application of PageRank analysis to the relationships between tags and incidents, we hope to show useful and interesting correlations. While these may or may not be indicative of a causal relationship, they are nonetheless, new facts about the system under scrutiny.
We conclude by showing the system shows some merit, assuming a certain set of minimum system requirements. If these requirements can be met, then this approach, can become another tool in the system administrators’ arsenal of system analysis approaches.
Introduction to Design Patterns
Within each engineering discipline, engineers have found that when analysing problems, similar types of sub-problems would tend to recur from time to time. Having had experience from previous project work, they knew that a similar solutions to those problems could be reused. This became the basis for design patterns.
Introduction to the Unified Process
The traditional view of system implementation is seen as a series of steps toward implementation, covering areas such as analysis, design, construction, documentation, handover, etc. Hay (1997) gives a good undertaking of the traditional approach stating:
Evolution of XML
Extensible Markup Languages (XML) history begins with the development of Standardised Generalised Markup Language (SGML) by Charles Goldfarb, along with Ed Mosher and Ray Lorie in the 1970s while working at IBM (Anderson, 2004). SGML despite the name is not a mark-up language in it’s own right, but is a language used to specify mark-up languages. The purpose of SGML was to create vocabularies which could be used to mark up documents with structural tags. It was imagined at the time, that certain machine readable documents should remain machine readable for perhaps decades.