Code generation is not ORM (Object Relational Mapping). ORM is not code generation.

These are two separate ideas. ORM is part-of code generation but code generation is super to ORM.

I get in discussions with people that are strongly against ORM mostly due in part to Jeff Atwood’s post that ORM is vietnam. Yes it can be, and ORM is only for highly tailored teams and projects and creates bulk and uncontrollable code bases. BUT, code generation is valuable and here to stay.

Code generation can be a templating system that outputs code that exactly is the way you would write it and generate unit tests, db field mappings, basic skeletal architecture, maybe a data layer that accesses tables and views or any one of those things from a custom, open source, standard or commercial templating system.

Code generation can also be macros, db migration processes (SSPI or DTS or PL-SQL or n), adding a new file in yoru IDE (VS.NET/Eclipse/FD templates), configuration files, refactoring tools, and many other things. Code generation is a part of life for a programmer or engineer. In fact if you dont’ start getting a handle on the code generation systems that are evolving then you will be that much more without a solution when platforms advance.

Code generation can also be team building because many times people against code generation are hand coders. This is fine and this works great for one programmer. When you add programmer++ to any single team all of a sudden “styles” come into play. Code generation and basic framework or API code structures should be similar in a team environment so that others have a base layer of knowledge they can get up to speed on. Code generation brings the style battles and architecture to the forefront on how code should look in an organization. As you can imagine when you give 50 architects or developers the lead, you will get 50 different was of doing things, some good, some bad. Code generation ensures at least a basic structure of code and apis that can be used. Team integration is hard, code generation usually goes hand in hand with this if it is as small as new file templates in an IDE or a macro all the way to entire api framework generators.

It is important that code within the same project look and act the same. Same styles, same conventions, same architecture. One way of settling this is having code generation that everyone agree upon that can help at least structure projects the same, even if implementation and behind the API layer things are like the wild wild west.

Code Generation > ORM

Code Generation is usually guilty by association. We are hoping to change the perception, but again code generation is really only needed when you get beyond the single programmer mindset, or when you start to make a product family or open source.

Code Generation != ORM, Code Generation IS for the Code Generation

baseplane: In software development, a set of tools, systems, patterns and designs that allow a system to be easily transferred to many back ends, services or front ends using standards, patterns and ideally non platform specific tools. Typically the baseplane includes both open standards and market standards based on industry usage. A baseplane may also be a way to commonize output to allow better designer and developer production.

A baseplane is a word I termed to describe the current, most technologically advanced set of tools and patterns that are usable across all major programming platforms.

The idea is that a company or programmer is sometimes held hostage by a particular platform or developer mindshare. People loving a good competition boast about platforms over other platforms and how one is better than the other. It is all fun and games but it doesn’t really give you the ‘best’ patterns and solutions. By patterns I mean general patterns not design patterns specifically for OO programming.

The ideal situation is where software is built semantically and from user perspectives with simplified enterprise entities and collections that perform top notch in a data store, no matter the platform or the language used to create it.

That is where true solutions begin, when companies and individuals can use the best platform or framework no matter their legion. A baseplane is a way to create systems that work well in many systems.

For instance JSON is a great example, this allows a layer to make back ends any language and then the front end any presentation from apps, to web to flash to whatever.

There will be more on this but the tools on this site all have this in mind.

Markets of many things have a period of innovation and experimentation through normal human trial and error, record response, adjust feedback loops. Over time, certain market standards emerge.

For social networks these market standards are profiles, friends, messages, blogs, pictures, and other custom handlers. OpenSocial has emerged late 2007 and is a great example of where after a period of time, a standard baseplane platform emerges and makes it another stepping stone to a further period of innovation and experimentation through normal human trial and error, record response, adjust feedback loops by combining and allowing a protocol to expose and consume data for OpenSocial. This could help many smaller or quickly developed communities get setup quickly, and it will also create social network giants that own the data. OpenSocial from Google was released after Microsoft signed with Facebook. Google came back with OpenSocial that got lots of attention and respec, also a move for Google to own the information and data standard. Then Facebook got forced to open up the apis to provide almost the same functionality, but no OpenSocial. Sometimes you need toolkits that will help to talk to both systems or many more pluggable ROM generation kits that allow you to integrate into these services such as blogging has the metaweblog apis and do most communication in a RESTful or XMLRPC based standard communication. It has allowed many blogging tools to integrate and help proliferate the platform and the companies involved in constructing it such as Wordpress (Automattic), MoveableType (SixApart), etc. There is great value to having open standards and market standards that allow the platform to flourish.

The baseplane code generation BOM (baseplane object mapper) has a ROM (rapid object mapper) both in development that can map your objects or existing applications to share along the OpenSocial standards (roadmaps and tests coming soon). We have many more ROMs that allow layers to be added to your code generation and custom manipulation of that work that have been built after 12+ years of experience in enterprise development. The great thing is the ROMs are custom, meaning that they follow your coding style and how you want things. None of this dictator like ORM systems, this is the reverse to that. They can integrate with existing code and they are not THE platform, they help you shape one though. More on this as the BOM is dropped.

The good news is more platforms are emerging, the bad news is there is much to learn and become an expert on.

JSON is an amazing evolution to simplicity and one of the best new microformats of the 21st century. See in the early 90’s there were still many battles about formats, data and services really were non-existent. Sure there was some client/server based RPC and early remoting but it was more about protecting data and licensing fees to access data.

XML came along and many server platforms based on RFCs that made the web based on MIME and TCP/IP and many layers of the OSI. But XML really helped to simplify the output of data for many levels of developers and although bulky, it rooted out the data protectors and made it too easy to build systems that shared data. Formats like EDI and other tight textual formats survived the entire time but formats not destined to trade were also opened up with XML and spawned the service age.

The evolution to JSON a micro, object based and array based format is again so simple like XML and now so micro that it just is amazing to break it down to something that simple and have it spread (more…)

baseplane is a technology tentacle of drawk, a digital design and development company that produces web applications and games.

The goal of baseplane is to deliver tools that help developers, users and creating a level playing-field in a world of software where platform and company religiosity is breaking standards, simplified software entry points and going against the main rule of software, to minimize complexity.

With such great changes in software happening and so many platforms to consume, tools to simplify and make broad platforms to help manage bigger services it is key to take control of these services as the web generations advance.

baseplane has tools to help with social networks (Open social wrappers and other services), blogging aggregation (XMLRPC, metaweblog), code generation (data, to activity to apis to services to service modules like JSON services), consistent architecture spanning multiple platforms (.net, php, java, actionscript (as3) and ruby,python.

Stay tuned!