Finally rest for all that boilerplate in Java.  At each turn of lots of Java frameworks you are bombarded with layers.  I felt this long ago and see it in the developers eyes that work with Java.  Java can be easy, it can be RESTful and it will make you look sharp.

Lightweight REST framework for Java

Do you want to embrace the architecture of the Web and benefit from its simplicity and scalability? Leverage our innovative REST engine and start blending your Web Sites and Web Services into uniform Web Applications!

Java is making things more lightweight now with lots of emerging kits that compete with other web ready platforms like Python, Ruby, .NET, PHP etc. After this many years things get bloated and need to be simplified.  I think this will start winning people over in this direction.

If you have ever worked on a massively high trafficked website, you know that cache is very important to keeping the server count down and being a superhero to your database servers. Cache can be bad and overly optimized but when you hit a certain threshold, relational databases, databases that are dimension modelled for data warehouse, and even server resources get exhausted. At that point you have two options, buy more servers, or more likely, cache read data.

Each platform has their own way to do this, but there is a common baseplane way to do caching, yes even in .NET. That is with memcached. Memcached is a very common and useful tool that makes caching data and cache layers in an application something that can be the same on every platform. The benefit of using memcached is it is open, common and it has APIs for nearly every popular web development platform (and can be wired in easily to platforms that don’t have their own cache mechanism). Why write your caching layer specific to a certain platform when you can memcache?

If you write high performance web apps and don’t memcache, I feel bad for your server budget and your late nights when that ad buy hits or something popular on your site becomes all the rave.

Perl API

An object-oriented Perl module can be found on CPAN as Cache::Memcached or in Subversion (ChangeLog). (GPL/Artistic)

The Perl API takes advantage of the server’s opaque flag support and sets its “complex” flag whenever the object being stored or retrieved isn’t a plain scalar. In that case, the Storable module is used to freeze and thaw the value automatically going in and out of the memcached.

There is also Cache::Memcached::Fast—another Perl client written in C, largely compatible with the original Cache::Memcached. Available on CPAN at http://search.cpan.org/dist/Cache-Memcached-Fast/.

PHP API

There are tons of PHP libraries available, in different conditions. But it now seems there’s an official one:

• PHP PECL memcached client — official PHP client

Python API

The Python client we’d previously released was just a prototype, and we don’t have regular Python programmers on hand. The folks at Tummy.com have took over maintenance. See ftp://ftp.tummy.com/pub/python-memcached/ for the latest versions.

Ruby API

• http://www.deveiate.org/code/Ruby-MemCache.html
• gem install memcache-client
• http://blog.evanweaver.com/files/doc/fauna/memcached/. C backed client wrapping libmemcached.

Java API

A Java API is maintained by Greg Whalin from Meetup.com. You can find that library here:

• http://www.whalin.com/memcached/ — Java API for memcached

An improved Java API maintained by Dustin Sallings is also available. Aggressively optimised, ability to run async, supports binary protocol, etc. See site for details:

• http://bleu.west.spy.net/~dustin/projects/memcached/ — Improved Java API for memcached

C# API

There are multiple C# APIs:

• https://sourceforge.net/projects/memcacheddotnet/
• http://www.codeplex.com/EnyimMemcached/ - Client developed in .NET 2.0 keeping performance and extensibility in mind. (Supports consistent hashing.)
• http://code.google.com/p/beitmemcached/ - Client developed by BeIT with many new features.

C API

Multiple C libraries for memcached exist:

• apr_memcache by Paul Querna; Apache Software License version 2.0
• libmemcached by Brian Aker; BSD license. This is a new library, under heavy development.
• libmemcache by Sean Chittenden; BSD license. This is the original C library. It is no longer under active development. You should try libmemcached instead.

Postgres API

The pgmemcache project allows you to access memcache servers from Postgresql Stored Procedures and Triggers. More details and downloads are available at:

• http://pgfoundry.org/projects/pgmemcache/

Chicken Scheme

• http://chicken.wiki.br/memcached — Chicken Scheme library

Lua

• http://luamemcached.luaforge.net/ — Lua library

MySQL API

The memcache_engine allows memcache to work as a storage engine to MySQL. This means that you can SELECT/UPDATE/INSERTE/DELETE from it as though it is a table in MySQL.

• memcache_engine

A set of MySQL UDFs (user defined functions) to work with memcached using libmemcached.

• MySQL UDFs for memcached

Protocol

To write a new client, check out the protocol docs. Be aware that the most important part of the client is the hashing across multiple servers, based on the key, or an optional caller-provided hashing value. Feel free to join the mailing list (or mail me directly) for help, inclusion in Subversion, and/or a link to your client from this site.

The best part, they support all good platforms and even Lua, and wisely they left out VB.NET, no worries, VB.NET’ers will never know. Only kidding…

Finally, memcached is distributed, most cache layers included with platforms listed above are in process and per machine.  If you are running your code on a webfarm memcached is the only way to go.

MVC is all the rave these days with excellent toolkits for all languages that help to define good structure for long term projects and maintenance. From Django (Python), to Rails (Ruby), Spring (Java), Maverick or Microsoft MVC (.NET/C#/Mono) and last but not least PHP MVC Frameworks.

PHP gets alot of heat mainly because it is critical mass and when that happens mediocrity comes in but since PHP5, PHP has really grown to be a great web development toolkit with many frameworks to choose from. But which one do you choose for your development? Do you want an MVC, or do you want to piece together an MVC from a template library, model framework and custom controller?

Well if you want to pick an MVC there are some great ones.

There is a site that has a decent ranking that is similar to my own likings in PHP frameworks that lists them like this:

I have not used QPHP, Zoop, Prado or PHPDevShell but plan on doing reviews of all of them. I have a simple application that i will be building in the latest versions of each platform to help show highlights, pros, cons and the ins and outs of each.

Why? And why PHP? I have long been a developer of web sites and applications. Until around 2005 PHP was not accepted in enterprisey, but this is changing. Usually .NET, Java, Perl, Python and recently Ruby were the dictated choice of the clients or environments to code in. But with PHP5 now stable and PHP4 being retired, PHP is a insurgent platform that muscled its way into the web development world in a grassroots effort, from the bottom up. That takes work and the platform deserves a second look from people that have written it off.

PHP runs many large sites from Facebook, to Digg, to Yahoo and many other platforms even Microsoft is trying to buy. PHP might even be responsible for MySQLs meteoric rise to just recently being purchased by Sun. It is a platform that is being used to build platforms. It works on any platform, it is low-bar entry and high bar scalability and architecture if using a great framework or architecture (if custom or using an existing framework).

I am an engineer, developer, architect and interactive/game developer, I use the tools for the job no matter what is chosen. Any good developer can make a system work even with bad technology but today there isn’t alot of that going around. So many great platforms, languages and frameworks, why limit to a certain OS or platform. Open your horizons and stop specializing yourself out of special skills. Choose a tool that works on just about anything on the server side and doesn’t take over servers and take 3 times as long to develop. Try some PHP5 MVC frameworks today.

Well Mono has finally reached 2.0. This is great news!  .NET skills now can span *nix, OSX, and Windows platforms.  But is your app or assembly capable of running on Mono?  Find out with MoMa.

Of course this is just a heuristic check and only finds out if your application on the surface has issues with running on a mono platform such as calls to p/invoke to windows apis or unsafe code that uses native calls but it is a great place to start.

The Mono Migration Analyzer (MoMA) tool helps you identify issues you may have when porting your .Net application to Mono. It helps pinpoint platform specific calls (P/Invoke) and areas that are not yet supported by the Mono project.

While MoMA can help show potential issues, there are many complex factors that cannot be covered by a simple tool. MoMA may fail to point out areas that will cause problems, and may point out areas which will not actually be an issue.

Use the results provided as a guide to get you started on porting your application, but remember the true test is actually running your application on Mono.

For a description of the errors that MoMA detects and how to deal with them, see MoMA - Issue Descriptions.

I have recently been really interested in making platforms and applications that aren’t limited by the OS they are contained in.  Thus mono is a very interesting platform now that it supports 2.0 fully and all the generic goodness to limit boxing/unboxing, common code between .net 2.0 apps (which are pretty much mainstream now) and developing for more of a standard that ensures your apps are portable.

Granted .NET 3.0 and 3.5 (pretty much the same version really with the addition of new frameworks such as WCF, LINQ which is very cool and functional as well as Silverlight) but most places deployed code is still .NET 2.0 and the poor souls working on very constricting .NET 1.0 and 1.1.

Also, recently Moonlight the Mono version of Silverlight has been released for alpha.

Tenjin is a great templating library that gets not only cross platform but baseplane ability to make templating very similiar (and FAST) across many languages. pyTenjin and phpTenjin is currently what I am using but there are executions for Ruby, Perl and Javascript.

Here is a list of the Tenjin Templating engines:

• pyTenjin
• phpTenjin
• rbTenjin
• jsTenjin
• plTenjin

Changes

(Python) (Ruby) (PHP) (Perl) (JavaScript)

User’s Guide

(Python) (Ruby) (PHP) (Perl) (JavaScript)

FAQ

(Python) (Ruby) (PHP) (Perl) (JavaScript)

Examples

(Python) (Ruby) (PHP) (Perl) (JavaScript)

Presentation

2007 LL Spirit LightningTalk (full-version) (Japanese)

Here is what the template markup looks like:

This

<table>
<tbody>
<?py i = 0 ?>
<?py for item in [’<foo>’, ‘bar&bar’, ‘”baz”‘]: ?>
<?py     i += 1 ?>
<tr>
<td>#{item}</td>
<td>${item}</td>
</tr>
<?py #end ?>
<tbody>

</table>

Produces This

<table>
<tbody>
<tr>
<td><foo></td>
<td>&lt;foo&gt;</td>
</tr>
<tr>
<td>bar&bar</td>
<td>bar&amp;bar</td>
</tr>
<tr>
<td>“baz”</td>
<td>&quot;baz&quot;</td>
</tr>
<tbody>
</table>

Here are some speed results

PureMVC is quite a versatile MVC kit.  With implementations for AS3, .NET (c#), Python, PHP, Silverlight and other platforms it is quite a system and domain to spread that far and have consistency.  There are small changes but for the most post the MVC is the same structure across the platforms.  This can be very beneficial for a service firm or for a product base that needs to support many different platforms.

PureMVC is a lightweight framework  for creating applications based
upon the classic Model-View-Controller design meta-pattern.
This free, open-source framework is implemented in ActionScript 2 and
3, Java, C# and a number of other popular programming languages.
This allows development on a wide variety of platforms including:

• Mobile Environments: FlashLite, .NET Compact Framework, J2ME
• Server Environments: ColdFusion, J2EE, PHP, Python
• Browser Environments: Flash/Flex, JavaFX, Silverlight
• Desktop Environments: .NET, AIR, FLASH, J2SE

For Flex PureMVC happens to be my favorite MVC kit.  I only use one if absolutely necessary but PureMVC keeps it clean.  The great thing is that is works with or without Flex unlike Cairngorm and it is always up to date.  It is just an added bonus that is spans so many other platforms. There are a few things I don’t like about it in other platforms like the url naming but it is much better than kits out there now and Microsoft’s ASP.NET MVC most likely wont’ be cross platform *wink*.

Some info on the PureMVC framework (caution PDF):

• Goals & Benefits
• Conceptual Diagram
• Framework Overview
• Best Practices

PureMVC Manifold

• Documentation
• Project Owners
• Repositories
• Get Involved!

Ports

• ActionScript 2
• ActionScript 3
• C#
• ColdFusion
• Java
• Perl
• PHP
• Python
• Ruby
• Propose a Port

JSON-RPC is the answer to the argument that XML RPC is too verbose and bloated and convoluted.  JSON is just about as simple as you can get in data formats and it is becoming a great baseplane standard and is a tool that spans many platforms.

“Does distributed computing have to be any harder than this? I don’t think so.”

Can it be even simpler ?

JSON-RPC is lightweight remote procedure call protocol similar to XML-RPC. It’s designed to be simple!

• specification
• python package implementing JSON-RPC
• more implementations
• services
• about JSON-RPC

JavaScript

• There is a JSON-RPC implementations as part of JavaScript O Lait jsolait.
  You can also find some live examples
• The Open Source TelePort Library supports JSON-RPC as well as other RPC protocols.
  Live demos and documentation can be found here.
• JSON-RPC to Java bridge includes a JavaScript client.
• Dojo Toolkit 0.3 implements JSON RPC.
• JSON/XML-RPC Client Implementation which abstracts-away the differences between JSON-RPC and XML-RPC and permits cross-site requests.

C

• JSON-RPC C Bridge. There is also support for GoAhead WebServers.

C#

• .NET and ASP.NET

Erlang

• YAWS JSON-RPC module (HTTP client/server)

Java

• JSON-RPC to Java bridge
• JRP

Lisp

• Common Lisp

Lua

• Lua

Perl

• Catalyst using the JSONRPC plugin
• JSON module

Php

• JSON-PHP
• php-json
• PHP-O-Lait
• Phpxmlrpc (in the ‘extras’ package)
• SCA_SDO Pecl Package
• JSON_RPC_Server, a JSON-RPC implementation in PHP
• JSON/XML-RPC Server Implementation which abstracts-away the differences between JSON-RPC and XML-RPC.

Python

• A python package which implements the JSON-RPC specs. It includes an mod_python handler, a CGIHandler, a TCP server and (soon) a ServiceProxies implementation.
• CherryPy (python)
• Zope 2
• Zope 3
• Twisted JSON-RPC - Web, Web2, and TCP

Ruby

• Ruby

Frameworks

• Catalyst (Perl) using the JSONRPC plugin
• CherryPy (python)
• JRP
• .NET and ASP.NET
• Zope 2
• Zope 3

Mono is a great open source .NET implementation that has been looking to being a baseplane dream to .net development. They even have Moonlight which will eventually be caught up with Silverlight development.

However today mono gets a killer IDE in the MonoDevelop name.

[insertname]Develop projects are largely based on the SharpDevelop IDE that is one of my favorites with .net and is open source. If you are looking for a FAST IDE SharpDevelop is that. In the FAQ Miguel mentions that MonoDevelop is a port or branch of SharpDevelop which is great news for quality, speed and usability.

FlashDevelop is also another great kit based on this IDE framework. I am very pleased Mono is using the same standard for IDEs that mimic VS.NET only much more speedy and usable in SharpDevelop and FlashDevelop (both .net apps themselves and two of the only good winforms apps there ever were).

I highly recommend mono and MonoDevelop. These are tools that are baseplane languages and platforms that have all the benefits of .net development but for any platform and now for any platform as an IDE. One problem with FlashDevelop is that it is only for Windows machines but maybe MonoDevelop will influence and will allow it for other platforms as well and everyone will be able to use the best IDE there is for flash and flex development.

In the meantime if you are a .net developer and want to develop for multiple platforms not just Windows then Mono is your tool and MonoDevelop is your IDE.

The main features of MonoDevelop are:

• Customizable workbench, including custom key bindings, custom layouts, and external tools.
• Support for several languages, with C#, VB.NET and C/C++ support included, and Boo and Java (IKVM) support available as separate add-ins.
• Support for code completion and type information tooltips.
• Refactoring operations to simplify changes like renaming types and type members, encapsulating fields, overriding methods, or implementing interfaces.
• Code navigation operations such as jumping to variable definitions and finding derived classes.
• Easy to use GUI designer for GTK# applications, also supporting the creation and management of custom GTK# widget libraries.
• Integrated source code version control, with support for Subversion.
• Integrated unit testing based on NUnit.
• Support for ASP.NET projects, allowing web projects can be built and tested on XSP.
• Integrated database explorer and editor (beta).
• Integration with Monodoc, to provide documentation about classes.
• Support for makefiles, both generation and synchronization.
• Support for Microsoft Visual Studio project formats.
• Packaging system that allows generating tarballs, source code and binary packages.
• Command line tools for building and managing projects.
• Support for localization projects.
• Extensible add-in architecture.

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