I have been experimenting with Python 2.3 and MySQL 4.0.13 recently and have been using a copy of my Movabletype 2.661 database as a sandbox. Before I started a spent a few minutes working out the structure of the database. This Entity Relationship Diagram is what I came up with. I expect version 3.0 of Movabletype is different, but just in case anyone else is digging around in Movabletype and could use a map here is a pdf version.
more >>
The International System of Units (SI) [72 page pdf Brochure] is maintained by the Bureau International des Poids et Measures at it's headquarters in Sevres near Paris, France. The Metric System as it is often known has a long history; supposedly invented in 1670 by Gabriel Mouton, a French clergyman, It was adopted by France in 1795 and by the United States in 1866. The system gained international status with the signing of The Convention of the Meter in Paris on 20th May 1875. The U.S. was one of the original seventeen signatory nations and is the only industrialized nation that still does not use the system.
more >>This is the first of an occasional series of reviews I intend to write to illustrate some important general traits of ontologies. In each review I will dissect an ontology and examine why it succeeded or failed. In this essay I mention concepts that are defined in my previous essay. Judging the likely success of an ontology. This first review covers an ontology called the Common Basic Specification (CBS) that was designed in the late 1980s to bring much needed standardization and rationalization to the fragmented information management processes of the British National Health Service (NHS). It persisted in various forms until the late 1990's when it was finally abandoned. This is my explanation of why it failed.
more >>The debate about the promised value of the Semantic Web seems to me to be missing a dispassionate examination of the success, or otherwise, of existing ontology based solutions. Clay Shirky is obviously right when he states that a single monolithic ontology will never work. His critics are equally right when they claim the Semantic web will only work if it is a melange of multiple interoperable Ontologies. What is missing from the debate is a more detailed explanation of what ontologies are good at, how they interoperate, and why systems based on ontologies succeed or fail. From my perspective as a systems designer this last point is the most significant. Debates about theory are nice, but examples of real solutions are more instructive. This essay will begin to examine this question by attempting to define the anatomy of an ontology. I will use this structure in later essays to examine the reasons for success and failure of individual ontologies.
more >>
The Evolution of Cooperation by Robert Axelrod is an outstanding book. First published in 1984 it has increased in significance with the evolution of the Internet. In the book Axelrod examines how cooperation can emerge and stabilize in multi-participant environments. The book is fascinating as an analysis of the evolution of cooperation, but is of particular interest to anyone seeking to establish effective; social software systems, peer-to-peer networks, or multi-player gaming environments. Axelrod builds his thesis on the analysis of a gaming tournament he organized. He invited multiple people from many different fields; economics, computer science, evolutionary biology, etc, to submit computer programs employing well defined strategies to play a series of games of Prisoner's Dilemma. Each program played several hundred games against every other program. The results were surprising and enlightening.
more >>In 1946 between 8th July and 31st August the Moore School of Electrical Engineering at the University of Pennsylvania held a special course entitled Theory and Techniques for Design of Electronic Digital Computers. The course was organized in response to interest generated by; the schools public announcement of the ENIAC, and the publication of The First Draft of a Report on the EDVAC. 1945 by Jon von Neumann. Attendance was by invitation only and the "Students" were selected from the leading experts at the major institutions working on the development of computing devices in the US and UK. At the time of this event there were only three published designs for a stored program computer and it was expected that all those present were familiar with these documents.
Within two years of these lectures the first stored program computer was operational, within 3 years there were 5 operational machines, and within 5 years stored program machines were commercially available. The Moore School Lectures, as they became known, were responsible for focusing all the leading developers of computing devices on a single problem:- How to design and build a stored program computer. It is interesting that despite being outnumbered and out-funded the British took, and held, the lead in this development effort between 1946 and 1953. In some areas such as business applications the British held the lead for much longer. How they were able to do this is not directly explained in any of the historical material available online, which tends to focus on individual development efforts and not on the larger picture.
more >>Finding an authoritative history of the Computer's invention is almost impossible. There are several reasons for this problem: People disagree on the meaning of the word "invent", they also disagree on the meaning of the word "computer". Finally significant parts of the history were either lost or deliberately concealed and only came to light again in the 1960's and 70's. The United States Army was the first organization to stake a claim to the invention of the computer with the 1946 public announcement of the ENIAC (Electronic Numerical Integrator and Computer). It has since become commonly accepted that ENIAC was the worlds first computer when in fact it was not a computer, in the modern sense, at all, and was not even the first of its class.
more >>
The concept of a balanced scorecard was developed by Dr. Robert S. Kaplan of the Harvard Business School, and Dr. David P. Norton, and is explain in their book Translating Strategy into Action. The Balanced Scorecard. The basic idea is that the, vision and strategy of an organization can be expressed as a set of goals and their associated objectives, measures, target values and initiatives. I covered defining goals and objectives for system design in a previous article. The Balanced Scorecard approach extends the scope of goals and objectives to the entire enterprise. Originally this approach was suggested as a business-measurement system but it has evolved into a business-management system. By continually measuring progress toward the objectives, the execution of a strategy can be monitored, corrections can be made, risks can be reduced, and the chances of success increased.
more >>Clearly expressed, goals and objectives are essential prerequisites for successful change management in complex environments. System design, implementation, and commissioning in the broadest sense are classic examples of this type of change. The only rational way of measuring the success of complex systems is to assess the degree to which goals have been achieved by measuring the attainment of objectives.
more >>L. Peter Deutsch first published the "8 Fallacies of Networking" internally while working at Sun Labs in 1991-92. This is a great list of the kind of wishful thinking that clouds so much system design.
Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences.
Most Software systems are developed by corporations to gain parity with, or advantage over, competitors. These systems are either intended for sale as products or to be used internally but in both cases they are supposed to produce positive business results for the corporation that uses them. As anyone who has ever been involved in the development of software systems will know they often fail to produce a return on investment and sometimes fail to produce any benefit at all. This failure to achieve business value stems partly from difficultly system designers have in tracking the changing relationships between Policy, Strategy, and the Architecture they are responsible for designing.
more >>Just because you can make a decision or solve a problem does not mean you should. There are times when it's better to delay until the last possible moment, others when its best to go half way and stop, and of course times when action must be taken immediately. Recognizing the best way to handle any given situation is fundamental when handling large numbers of problems. Recently I've been working with a client on defining a change management process for a large system and have been thinking about these issues.
more >>
