language translation Posted: 8/26/2008 Created: 1/15/2006 Updated: 8/25/2008

I've been interested in on the fly language translation services.  There are many possible applications, but I was thinking that it could be useful in enabling communication between teachers and non english speaking parents.  I'm going to research this further in the future.

Reference: CodeProject - WebResourceProvider

gmax Posted: 8/21/2008 Created: 1/14/2006 Updated: 8/21/2008

gmax might be a good tool to create graphics models.

Reference: TurboSquid, gMax Tuorial

Contract First Service Development Posted: 8/20/2008 Created: 1/11/2006 Updated: 8/21/2008

In the bad old days of COM, IDL (interface definition language) defined the interface between the client and the component.  It looked like this:

The problem that it solved was the need to create a component and have that component be usable from Visual Basic and VB enabled applications, such as Word, Excel, etc.  To some extent, it was a problem of Microsoft's own making:  the decision to enable Office applications with a MS controlled language that they could and did change all the time.  From the point of view of standard-orientation and object-orientation, COM was a big step backwards.  Eventually, everyone recognized the reality that COM was ugly and stupid, but only after .NET was announced.  SOAP was the next mechanism to enable mixed environment remote procedure calls.  This replaced the IDL type library with an xml document called the WSDL (Web service description language).

However, some might say that it presented two ways of the doing things, the easy way and the hard way.  It's often true that the hard way in life is better, based on the idea that the hard way leads to something better later on.  It's also true that sometimes the easy way might lead to long term pain since you may not think about some things that the hard way might force you to think about. 

On the other hand, in many cases, the easy way has no long term pain. Sometimes, the hard way is just that, hard and stupid. In this case, the easy way refers to code first development and the hard way is contract first development.

Code First is loaded terminology that Aaron is using to refer to the practice of using an automated tool to generate the WSDL. This results in connecting client code to a web service in a way that is only slightly more inconvenient than normal software development.  His terminology is loaded and deceptive because it implies that it involves coding prior to designing, or coding without thinking.

Contract First is also also loaded terminology that refers to deciding on the interface prematurely, and then hand coding the WSDL.  The terminology is designed to appeal to computer science geeks who have been propagandized into believing that contract law is the most appropriate metaphor for software development.

Contract law is a completely inappropriate metaphor for software development.  Good software is created by an iterative process of refactoring with the goal of increasing cohesion, reducing coupling, increasing encapsulation and maintainability.  Anything that prevents or slows down refactoring is causing bad quality software.  Using contracts to hard code interfaces between components is doing just that.

In this Service Station Article, Aaron Skonnard argues that contract first development is always better.  He indicates that this is a lesson learned from the days of COM and Visual Basic.  I can't speak for COM and VB, since I was smart enough to stay away from that.  However, I disagree that hand coding WSDL is ever better, let alone always better.

Aaron says that "Experience has shown that services implemented using code-first techniques, like the default ASMX model, are less likely to interoperate cleanly in mixed-language environments."  However, I've been able to connect a native C++ client to a .NET web service without any problem.  Authoring WSDL by hand is difficult because the language is complex and confusing.  I can see no advantage even in the long term.

Reference: Contract First Development Example (from the next Aaron Skonnard article)
Reference: Thinktecture's free WsContractFirst tool

High Performance Game Server Posted: 7/25/2008 Created: 1/9/2006 Updated: 8/11/2008

I was on an idiotic project where we spent 2 million USD in development costs to avoid spending $150k on the right hardware. This mistake was related to hiring 15 very senior developers and then keeping them out of all architecture and design decisions.  However, it was a very stimulating environment to think about designing a high performance game server.

MMORPGs are a very popular game genre throughout the world. Worldwide revenues for MMORPGs exceeded half a billion dollars in 2005, and western revenues exceeded one billion USD in 2006.

Some interesting things from the Comparison of MMORPGs

• Star Wars Galaxies users went from 200k in 2005 to 100k in 2006.
• Eve Online went from 70k in 2005 to 200k in 2008.
• World of WarCraft is the biggest with 10 million active subscribers
• Eve and Everquest both have 200k users, but while EverQuest has 25 servers, Eve only has 1.

So, what's up with Eve Online?  They understand the performance triangle (PT).  The sides of the PT are CPU, Memory, and Input/Output.  The area inside the PT represents the overall performance.  When one increases only CPU and Memory resources, the triangle looks like this:

This is what most folks do, including EverQuest and the idiotic client referenced in the first paragraph.  They increase system performance by focusing only on CPU and Memory, ie by adding more servers.  Eve Online uses a solid state disk (SSD) to increase I/O performance, so the triangle looks like this:

Now, that's a lot more performance.  Some of the technology options are:

• Using AWE Memory in SQL Server 2000
• Using AWE Memory in SQL Server 2005 
• Holographic Drives
• Write Through Cache - A disk or memory cache that supports the caching of writing. Data written by the CPU to memory or to disk is also written into the cache. Write performance is not improved with this method. However, if a subsequent read operation needs that same data, read performance is improved, because the data are already in the high-speed cache
• Solid State Disks   With I/O performance around 250k RPS and response times around .73 milliseconds, this rocks.
• Real Time Database - I have another white paper from 2002 (so performance is better now) with a different SSD vendor combined with Times Ten that shows that they are able to update a database as fast as we need to read from a DB!  They got about 1800 Updates Per Second.  Given that RDMSs probably aren’t optimized for SSD, maybe the ideal would be to use a real time database like TimesTen.   With an SSD, there is NO penalty for random access, where as a traditional RDMS assumes it’s writing to disk.
• SQL Server 2005 on a 64 bit box with a whole lot of memory.  This article compares the state of high end RDMS products. http://www.computerweekly.com/Articles/2005/11/01/212652/HasSQLServer2005beenworththewait.htm http://www.eggheadcafe.com/articles/20050613.asp
• Flash Vs. RAM Solid State Disks
• Oracle Query performance is 176 times better with a SSD  (http://www.texmemsys.com/files/f000139.pdf)
  http://weblogs.asp.net/jezell/archive/2006/03/20/440649.aspx

Texas Memory Systems achieved the highest number of IOPS (291,208.58) and the lowest Price Performance ($0.67/IOPS) when they took part in the Storage Performance Council's SPC-1 IOPS test in January 2008.  Some other success stories:

900_success
http://www.superssd.com/success/

Now, let's move on to some architecture options.  The most ideal non-SSD architecture is 4 tier: 

1. client app tier - the client application is the video game running on the end user's machine.
2. web tier - the web tier is a web service or REST interface that is called on a regular basis by the client app.
3. application tier - the app tier is basically a cache of the database.
4. data tier - database of the game universe.

The ideal SSD architecture is 3 tier:

1. client app tier - video game running on the end user's machine.
2. web tier - web service or REST interface.
3. data tier - database of the game universe, with an SSD for data store.

The difference would seem to be minor, just an extra tier, but the devil is in the details.  The overall performance is dependent on the number of servers of course, but how many servers are needed for a certain load?  This brings in the concept of the architecture efficiency. 

If the web tier gets 1000 rps, and the app tier also gets 1000 rps, then it will take 2 machines for every 1000 rps of performance.  This means that a 4 tier architecture will cost twice as much to scale.  This is reduced if the web tier performance is greater.

This graph is based on achieving a 2-1 ratio of web tier to app tier.  Even if we can achieve a 4-1 ratio, the 3 tier version will still cost less.  In fact, we would have to achieve an 11-1 ratio for the 4 tier version to cost the same as the 3 tier version.

So, to make sense, the 4 tier architecture would have to be easier to develop, to reduce the up front engineering costs. However, the 4 tier architecture is not just more difficult to develop, it's several orders of magnitude more difficult to engineer.

It's quite an engineering challenge to create a robust scalable application that avoids database I/O by moving data from disk to cache. This difficulty is why the project mentioned in the first paragraph spent 2 million in development costs.  It's very expensive to develop, and when you're done, you don't have something better, you have something complicated that is also more expensive to scale.  This would all be simplified by just doing away with the disk.  When Eve Online switched to an SSD, they got a 40x boost in performance and handled 17000 concurrent users. 

Update: RamSan-440 is the world’s first non-volatile RAM-based solid state disk (SSD) to sustain up to 600,000 IOPS (input/outputs per second)

References:  SPC Benchmark 2004 with pricing info, RamSan-440

Password Vault Posted: 5/28/2008 Created: 1/7/2006 Updated: 5/27/2008

I was starting to have trouble remembering all the user names and passwords. I found that KeePass is a great little free program that solves this problem.  With KeePass, I only need to remember one long password, rather than about 100 user names and passwords.  It also keeps the URLs of many of the places where these are used, and one can simply copy and paste the user name and pw to the site.

Reference: CodeProject

Grasp OO Pattern Posted: 5/27/2008 Created: 1/6/2006 Updated: 8/21/2008

GRASP stands for General Responsibility Assignment Software Principles.  Wiki says the "P" could either be Patterns or Principles.  After reviewing the concepts, I would say that these are definitely principles.  I was recently asked about so called Patterns, and I drew a blank.  Had I been asked about object oriented principles, I would have hit the ball out of the park. 

It's amazing that a simple issue of terminology could result in someone getting the impression that I didn't know anything about OO, when I've been designing and implementing software with these OO principles for some 16 years.  I'm very good at Object Oriented development.  Oh well, their loss.  I note well that these are the folks that have tried reengineering their system 6 times and failed miserably each time.  They think it's the fault of the people working on it, but in reality, failure is in their DNA, as they resent any effort to change their world, and they sabotage it.

The disconnect reminds me of the time my friend Rick W asked me about skiing.  I have been skiing since I was 3 years old.  I'm pretty darn good at it.  My friend challenged me as to why I didn't teach them how to ski, asking me "how do you do what you do?".  I had no answer.  However, he wasn't stupid enough to think I couldn't ski, just because I couldn't explain it right then.  

Yet, these people are that stupid, especially since they used odd terminology in their question: "how does one perform low friction crystallized aquatic activities?".  Huh?  "HA, he doesn't know anything".  Ok, let's ski this 50 degree slope in deep powdery moguls, shall we?  Oh, you can't handle that?  I'm not surprised.  I'll be expecting Platform A to fail miserably, and when it does, a bitter smile will spread across my face.

Anyways, GRASP doesn't present any new information but only serves to better document and standardize old, tried-and-true programming principles in object oriented design.  There are nine GRASP Principles:

Information Expert - A general principal of object design is that there should be a class that has all the essential information.  duh.

Creator -  The Creator pattern solves the problem of who should be responsible for the creation of a new instance of a class. Given two classes, class B and Class A, class B should be responsible for the creation of A if class B contains or compositely aggregates, records, closely uses or contains the initializing information for class A. It could then be stated that B is natural object to be a creator of A objects.  duh.

Controller -  The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario.  duh.

Controller sits in the problem domain, but isn't a domain entity. It delegates to other objects the work that needs to be done; it coordinates or controls the activity. It does not do much work itself.  if you are building an application that manages your contacts, addresses, and phone numbers, you could call this object “AddressBook.” If you are building an e-commerce website, you could call this object “Store.” If you are building a chess game, you could call this object “ChessGame.“   wow, duh.

Low Coupling -  low dependency between classes; low impact in a class of changes in other classes; high reuse potential; Easier said than done.  Most say, I do.  To describe this as a pattern misses the point.  How did Bobby Jones achieve the Golfing grand slam?  Oh, he just used a "winning" pattern.

High Cohesion - keep objects appropriately focused, manageable and understandable.  Alternatively, low cohesion is a situation in which a given element has too many unrelated responsibilities. Elements with low cohesion often suffer from being hard to comprehend, hard to reuse, hard to maintain and adverse to change.  Gosh, you think?

Polymorphism -  Polymorphism lets you treat derived class members just like their parent class' members.  Allows programming by exception.  This is the most powerful of OO techniques, since it enables generic code.

Pure Fabrication - Just fancy terminology for a factory class.  big woop. 

Indirection -  Indirection pattern supports low coupling (and reuse potential) between two elements by assigning the responsibility of mediation between them to an intermediate object. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern.

Protected Variations -  protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability.  They can't bring themselves to use the word "encapsulation", because that would be admitting they are making a big deal of a concept identified in the 70s.


Reference: David Hayden

UML Posted: 5/23/2008 Created: 1/3/2006 Updated: 5/22/2008

The company with a really great name, Rational Software, realized that sales of their software modelling program was being held back by the industry having 3 major methodologies.  So, they acquired all 3 proponents by hiring them or buying their companies.  By doing so, they now had the 3 amigos, James Rumbaugh, Grady Booch, and Ivar Jacobson.  They set them on the task of creating a unified neutral modeling language.  The result was the Unified Modeling Language (UML).

Here is a nice clear description of UML.  For a UML Editor, see CodeProject.

Reference: WikiPedia UML