Like Jettro in his perspective on content management, I would like to draw your attention to another blog which was published on the Daily WTF and mentioned on The ServerSide. It’s hilarious and a good lesson as well: Java is Slow!
Enjoy!
|
||||||
 We now have a linked in group, join the group if you are a regular reader and want to see who else reads this blog.
 |
This year, 2009, we celebrate the 50th anniversary of a landmark moment for (Dutch) computing science: it is 50 years ago this year that Edsger Wybe Dijkstra, The Netherlands’ most famous computing scientist, published his Shortest Path Algorithm in Numerische Mathematik, the German journal of numerical mathematics. The shortest path algorithm is a solution to a problem from graph mathematics. A graph is a mathematical construct consisting of vertices (or nodes) connected by edges (or sides). Each path has a value (a length, a cost, etc.). The object of the problem is to find the shortes path through the graph from one point to a certain other point. And just in case that sounds like abstract mathematical nonsense that nobody will ever have use for: this problem and its solutions have been applied to network routing, traffic pattern regulation and worldwide distribution of goods. For those of you who drive cars: next time you get in you car, take a look at your satnav — then say “thank you Edsger”. Dijkstra’s algorithm is not the first solution to this problem. However, his solution differed from the solutions presented before in that it is simple and straightforward (most textbooks and professors covering the subject even remark that it is strange that nobody came up with this easy solution sooner). It is also one of the first solutions that was designed with implementation on a computer in mind, so it is optimal with respect to running time and storage need. This in turn undoubtedly explains its pervasiveness throughout computing even (or only?) 50 years after its invention. It’s also why Dijkstra is most famous internationlly for this algorithm; even to the point of being insulting, because it is really one of the least impressive results of his career, which literally lifted computing science from trial-and-error tinkering to a science. Dijkstra’s career focussed mostly on developing the science of computing science, by developing techniques for constructing provably correct solutions to problems by constructing the solutions hand in hand with the proof of correctness. Dijkstra was a great believer in computing science’s mathematical roots because exactly those roots yield the properties that computing science so desperately needs: correctness, accuracy and elegance. One of Dijkstra’s axioms in fact is that Beauty is our Business. So in that spirit (and, I hope, in Dijkstra’s spirit as well) I would like to present this birthday salute to Dijkstra’s algorithm – and to the man himself as well: a construction of Dijkstra’s Algorithm. This year, 2009, is the 200th anniversary of Charles Darwin‘s birth and the 150th anniversary of the first publication of On the Origin of Species. In this famous publication Darwin launched his notion of how species’ survival is dictated by their ability to make the most efficient use of the available resources in their environment, how they adapt to increase that efficiency and how the combination of increased procreation and targeted adaptation mean that the most adapted and adaptable species survive longest. Much like species of plants and animals, the software we build for our customers (and the software built by our predecessors) lives in an ever-changing environment. Business needs change and expand, fashions change, economic booms, lulls and the occasional crisis follow one another in an endless tide. Software systems face their own survival challenges, dealing with all these changes. And much like their biological counterparts it is their adaptability that rules their survival. Continue reading On the Origin of Technologies Following a trackback to your own blog entry can be interesting from time to time. Today, for instance, I was led to an interesting blog from quite some years ago on the sys-con site by Michael Yuan entitled “Is Ruby Replacing Java? – Not So Fast”. In his blog, Michael talks a bit about why he thinks Ruby and RoR will not push Java out of the web application development arena. Part of his argument is that each development system tends to etch out a niche for itself, to attain dominance there and to be almost impossible to force out due to the traction it gathers in that niche. His other argument, I think, is far more interesting and fundamental to the understanding of software engineering. To quote Micheal:
To put it another way (a way that I have tried to get many people to understand at different times):
Continue reading It’s not about the language, people…. The other day I noticed that a bulb had burned out in my room. Which meant that I had to get a new bulb and replace the one that had failed. The act of replacing the bulb, perhaps surprisingly, led to some aggravation. Let me tell you about it. The lamp in question does not take old-fashioned lightbulbs. No, this is a relatively modern lamp: it takes halogen spots. Halogen bulbs, as you might know, are not screwed into place. They use pin connectors which you stick into a recepticle which clamps onto the pins to prevent the bulb from falling out. In the case of smaller halogen bulbs a spring clamp suffices. Halogen spots are a little heavier, which means that their recepticles use two screws to clamp down on the pins. My lamp does not just use halogen spots: my lamp is a product of early industrial design, which means that it is something really special. My lamp, you see, is the modern version of track lighting. Track lighting was very popular in the 1970′s: it consisted of a track with electrical leads in it on the ceiling. The lamps themselves were movable modules which clamped onto the track and used either metal hooks to hook onto the electrical leads or metal plates pushed onto the exposed leads by a spring. Track lighting allowed you to create the lighting form of your desire (more or less). The modern track consists of two metal cables encased in plastic (thick enough not to slack, adjustable for length and isolated against contact by hands). In order to make electrical contact, the lamp modules use screw clamps and screws with a pointy tip. One clamp grabs onto one cable and if you tighten the screw the pointy tip just pierces the plastic isolation and makes contact. The clamps connect to a cradle that houses a recepticle for a halogen spot. And some ornamental metal bits cover the cradle up, making it difficult to electrocute yourself accidentally. There is a simple and straightforward procedure to replacing a lightbulb in this lamp:
Simple, easy. Any idiot can do it. And yet, after a few minutes fumbling with overhead screws and dropping screws and so on, I am left with one aggravated question:
Continue reading The parable of the lightbulb Within the JEE platform a rather common and well-understood system of configuration is based on the Chain of Responsibility and the Event Delivery patterns: the life cycle of enterprise components starts with achieving a general configuration goal. However, on top of this goal, the system defines a number of pre-goals that the system must achieve in combination with an event system that allows configurable actions to be undertaken when the system tries to achieve a pre-goal or the final goal. A typical example is the configuration and starting of a servlet. The servlet is configured in a configuration file and the servlet container reads this file, instantiates and initializes the servlet and puts it in the wait state, waiting for requests. But there is more involved: init parameters are set and the servlet context is initialized. Each step generates a runtime event that listeners can listen for and respond to. The standard configuration of the Spring context in JEE web applications uses this model to load context files through the The Java Instrumentation API on the other hand is not nearly as well-understood or even as well known. Yet it makes it possible to instrument each and every Java program with a similar Chain of Responsibility mechanism as the JEE standards provide out of the box. The mechanism is used by debuggers and frameworks like AspectJ that have to make just-in-time adjustments to classes as they are loaded. As a small introduction this article examines the creation of a Spring context loader mechanism for standalone Java Apps. This mechanism is, in truth, not very useful. But it’s a simple and effective exercise to learn the technique. IntroductionAuthor’s note: this is an article that I co-authored Many of the applications we write for our clients nowadays use the service paradigm: a dedicated and often reusable component within the application that is responsible for a particular task or process. Such components are often written and used in such a way that a component is instantiated once and reused often within the runtime of the application (such as a web service or a Spring managed bean). Using components in this way is a very resource-friendly way of constructing an application; resource-intensive objects are created only once and reused instead of having to be recreated and reinitialized for each request. However, they do make it necessary to pay special attention to issues that arise in reuse and concurrent use — specifically state management. A common technique to avoid such state problems is to build stateless components. Unfortunately, mistakes happen in software engineering. Sometimes team members introduce state to shared components without thinking about it. This article discusses using the Memento pattern as an easy way of transforming a stateful into a stateless service. Continue reading Using the Memento pattern to solve thread safety issues Over the course of a number of different posts on Gridshore, I have mentioned a number of different ideas (mine as well as others’) that I was planning to introduce into my project and of which I promised to report the results. However, I fear that it has become impossible for me to do [...] |
|||||
|
Copyright © 2012 Gridshore - All Rights Reserved |
||||||
