January 16, 2007
Better GWT build with maven2

I've been using the maven-googletoolkit2-plugin from http://code.google.com/p/gwt-maven/ for a few weeks and I today I needed to add GWT to another maven2 project. Since I last looked maven-googletoolkit2-plugin has moved on. The build defect I noticed last time I used it has gone and the plugins can be directly downloaded from a repository so you don't have to build them yourself, but the whole thing has become more complex and now seems to depend on tomcat (from looking at the source). This wasn't going to work for me as I'm using jetty.

So, I went with calling the GWTCompiler from an ant build.xml file and then using the maven-antrun-plugin to call the correct target in the build.xml file. Here's the plugin entry from the pom file. I'm passing into the build.xml the properties it needs. Most interesting are gwt.devJar, which is set in the profiles section of the pom to gwt-dev-mac or gwt-dev-windows depending on the platform, and pluginClasspath, which gives access to the classpath used by the plugin, including the maven-artifact-ant classes, and which you'll see used in build.xml

       <property name="pluginClasspath" 
         refid="maven.plugin.classpath" />
       <property name="gwt.devJar" value="${gwt.devJar}"/>
       <property name="gwt.module" 
       <ant antfile="${basedir}/build.xml">
         <target name="CompileGWTSources" />
    <!-- can't add gwt-dev jars here because doing so breaks the ant
    task above, instead they are in build.xml -->

The relevant pieces of build.xml are shown below. I'm using the dependencies ant task provided by maven-artifact-ant and made available via the typedef using the pluginClasspath property to get access to the gwt-user and gwt-dev jars directly from the repository. Then using the java task it's very easy to call the compiler.

<typedef uri="urn:maven-artifact-ant" classpath="${pluginClasspath}"
<target name="CompileGWTSources">
  <artifact:dependencies filesetId="gwtDev.classpath">
    <dependency groupId="com.google.gwt" artifactId="${gwt.devJar}" 
    <dependency groupId="com.google.gwt" artifactId="gwt-user" 
  <java fork="true" classname="com.google.gwt.dev.GWTCompiler">
    <jvmarg value="-XstartOnFirstThread"/>
    <arg value="-out"/>
    <arg value="src/main/webapp/scr"/>
    <arg value="-gen"/>
    <arg value="target"/>
    <arg value="${gwt.module}"/>
      <pathelement location="src/main/gwt"/>
      <pathelement path="${pluginClasspath}"/>
      <fileset refid="gwtDev.classpath"/>

Overall a simpler solution that the maven-googletoolkit2-plugin one.

Posted by Alex. Permalink
December 20, 2006
GWT and maven2

Some notes on using the maven-googletoolkit2-plugin. Download the code for the plugin from the project's subversion repository. I used the command svn checkout http://gw-maven.googlecode.com/svn/trunk/ gwt-maven. You only need to build the maven-googlewebtoolkit2-support module. However, it won't build as is because it has a dependency that it doesn't need on maven-googlewebtoolkit-support and when you try and build the whole project there is a error. com.thoughtworks.qdox.parser.ParseException: syntax error @[47,64] in file:.../com/totsp/mavenplugin/gwt/support/beans/Bean.java Easy enouth to fix though, just delete the dependency from the pom and then mvn install will put the plugin in your local repository.

Next you have to configure the plugin in your pom. The plugin depends on the gwt-user and gwt-dev jars so you have to install these to your local repository using mvn install:install-file. For example

mvn install:install-file -Dfile=gwt-user.jar -DartifactId=gwt-user -DgeneratePom=true -DgroupId=com.google.gwt -Dpackaging=jar -Dversion=1.3

The plugin configuration itself should look something like.


The googleWebToolkitOutputDirectory is where the generated code is placed. This is changed from the default value to fit with a standard maven directory layout. googleWebToolkitCompileTarget is the module to compile and sourceDirectories specifies where to look for the source code.

Finally, to execute the gwt compiler you use mvn googlewebtoolkit2:compile

Posted by Alex. Permalink
December 19, 2006
IntelliJ IDEA and GWT Take a look at this demonstration of IDEA and GWT. It really shows them both off well, and certainly shows the great advantage in tooling that something Java based like GWT has over a ruby, for instance, solution. Java really has the best tooling of any language at the moment.
Posted by Alex. Permalink
June 01, 2006
Bi-Directional Programming

Surprisingly interesting. The presentation linked to from the post is good. The problems discussed are related to why Materialized Query Tables in DB2, Materialized Views in Oracle, and Indexed Views in MS SQL Server have the restrictions on the view operations that they do. The Weird World of Bi-Directional Programming | Lambda the Ultimate

Posted by Alex. Permalink
May 10, 2006
7 Reasons by web apps fail

A great list, linked to by many other people :) Bokardo 7 Reasons Why Web Apps Fail

Posted by Alex. Permalink
October 09, 2005
Maci Update

I've updated my version of maci so that it keeps track of your ten highest scores.

Posted by Alex. Permalink
October 03, 2005
My version of maci

In order to learn a little bit, and I mean a little bit, about programming using Java and Cocoa on Mac OS X, I've written a version of the MaciGame. It's available as a disk image, maci.dmg, is licensed under the GPL, and so includes source code. I still need to improve the application icon and add a way to keep track of high scores. Pretty good game though.

Posted by Alex. Permalink
September 08, 2005
JavaScript Debugging

I know I probably should have found this earlier but I'd like to recommend the venkman JavaScript debugging extension for mozilla/firefox. I downloaded version 0.9.85 from the venkman development pageand it worked just beautifully.

Posted by Alex. Permalink
May 07, 2005
What's fixed in this build?

This describes how we find part of the answer to this question at work. First you need to know that we use perforce for source control and bugzilla for defect tracking. Each time we make a build for QA the build process labels the source code using the p4 label and p4 labelsync commands. So what we need to do is to find what changed between two labels and translate that into what bugs were fixed.

Perforce and bugzilla are linked using p4dti so that each bug in bugzilla becomes a job in perforce and changes to the status of the job are propogated to changes to the status of the bug. Therefore, if we know what jobs were fixed between two builds we know which bugs were closed.

Based on information from this perforce technical note I devised the following procedure.

First find the highest numbered changelist in each label. This can be done using the command p4 changes -m 1 //path/to/release/...@label for each label.

Now find all the changes that apply to the release between the two release found in the first step. p4 changes //path/to/release/...@change1,@change2

Finally, find for each change which jobs it fixes and these jobs are the bugzilla changes that we're after. p4 fixes -c changeNumber

All of this can be incorporated into a little shell script that returns the result we're after. I've put the script on the next page because the lines don't wrap well. The last line does the following, finds all of the changes, uses cut to extract just the change numbers, uses xargs to call p4 fixes for each change, uses cut to extract the perforce job names returned, and finally uses sort to order the result and remove any duplicates.

get_change_number() {
    CHANGE=`p4 changes -m1 //path/to/releases/$release/...@$build | cut -f 2 -d ' '`

if [ $# -ne 3 ]
    echo "Usage: changes.sh   "
    exit 1

get_change_number $RELEASE $FROM_BUILD
get_change_number $RELEASE $TO_BUILD

p4 changes //path/to/releases/$RELEASE/...@$change1,@$change2 | cut -f 2 -d ' ' | xargs -n 1 p4 fixes -c | cut -f 1 -d ' ' | sort -u
Posted by Alex. Permalink
March 25, 2005
sed - sometimes a useful tool

Sometimes there is a better way, and sometimes you even have to resort to perl, but for some quick bulk editing jobs sed is just excellent. Today I was faced with a bunch of xml files defining screen layouts. They contained references to properties using elements such as <property name="Foo"... and <propertyMember name="Bar".... Unfortunately all of the names were with an initial uppercase letter while the correct Java convention is initial lowercase for property names and this was stopping the property change listener hooking up correctly. So, how to make the necessary change easily?

Using the gnu version of sed it can be done in one line to edit all the xml files in a directory, and keep backups, as shown below.

 sed --in-place=".bak" --expression='s/<property\(Member\)\?
 name="\([A-Z]\)/<property\1 name="\l\2/g' *.xml

Even though I had to download gnu sed and compile and install it on my box (Mac OS X) this was still much faster than any other solution. The actual script executes like lightning, you hit enter and it's already finished, amazing.

Posted by Alex. Permalink
Who wants to learn the sed invocation and regex details when perl has those flags? This is shorter to type: perl -pi.bak -e 's/<property\(Member\)\? name="\([A-Z]\)/<property$1 name="$l$2/g' *.xml Posted by: on May 5, 2005 08:34 PM
March 22, 2005
ant, xmlvalidate and foreach

As part of the build process I've been trying to validate some xml files against an xml schema using the xmlvalidate ant task. The problem is that the xmlvalidate task won't validate more than one file at a time, as bug 32791 shows. Unfortunately ant doesn't provide any built in looping constructs so I downloaded the ant-contrib project from sourceforge and was able to use the foreach task it provides with no problems.

<foreach target="validateOneFile" param="file_to_validate" 
        <fileset dir="${standard.xml.dir}/gui/forms/">
            <include name="*.xml"/>
Posted by Alex. Permalink
March 05, 2005
Scheme, Ruby, Python, Perl

Why is it that scheme isn't more popular? Why is it even necessary to invent languages like Ruby, Python or Perl? Or, why do people invent these languages instead of adding the features they want to an existing language? Is some of it just not invented here syndrome? Why did Python become popular when Perl already existed and why Ruby when there was both Python and Perl? Why is Java going to have a scripting language called Groovy when there are already other scripting languages, not least of which JavaScript and Jython, available? Sure, Groovy has closures but then so does JScheme.

No answers, just questions.

Posted by Alex. Permalink
Scheme isn't popular because syntax matters. If Lisp and Scheme have taught us anything, it's that if the syntax is really nasty, no one will ever get to know that the semantics underneath are beautiful. Python and Perl are so utterly dissimilar that I don't really see why you think that the existence of Perl should mean that Python shouldn't be needed. Ruby and Groovy, yeah, not invented here syndrome. Posted by: Simon Brunning on March 7, 2005 06:40 AM
Simon: You consider Python&Perl dissimilar, but Ruby similar to those!?! IMHO: Perl was invented to make a uniform framework to handle what was commonly done in 3 languages before (sh, awk, sed). Unfortunatelly it borrowed a lot of the ugly baggage from those languages and had a horribly inconsistant feel due to the multiple parents it borrowed from. Reading complex sh/awk/sed programs from before Perl existed shows the need for Perl quite clearly. Larry Wall's Rnmail and Pnews applications can still be downloaded and are good examples of the problems Perl was written to address. Python was a way of simplifying Perl's syntax so everyone (includng the original developer) could read it. [Disclaimer, I dislike Python's decision to use whitespace as a control structure. I think this was a mistake in the Makefile syntax, and continues to be a liability in Python.] Ruby was a ground-up design of a scripting language with a stronger theoretical basis and support for techniques like threading and OO and Blocks (theoretically more powerful than perl/python like Lambdas). Regarding the question about modifying the existing languages - you can't really do that because in each case a big motivator was to remove awkwardness from the existing languages, and not just to add features. Groovy, and well, Java itself - IMHO this is more of a social phenomenon, where Sun&IBM create an industry and demand in employers and programmers needing jobs gravitate to it to fill the vacuum. Groovy exists because all the Certified Java Programmers need a scripting platform that they can evangelize fits the Strategic Vision of a company that drank the IBM coolaid too deeply and wants to "standardize" on "java technologies". Posted by: RonM on May 25, 2005 01:16 PM
Bah, there's a good reason for scheme/lisp syntax. Can't do macros in such a powerful way without representing the parse trees directly in the syntax.... Perl may be a mess, but it's a glorious mess, if you've got a Larry Wall-ish personality. Check Higher Order Perl to see how to really make it shine (functional techniques not really available in Python).... Generally, there's a *lot* of innovation in programming languages these days. We have a lot of different ones because we're still trying to figure all this stuff out. Way too early to settle down. Check Lambda the Ultimate site... Posted by: on May 27, 2005 03:35 PM
Like anything - music, sports, clothes, food - different things appeal to different people. Perl to me is expressive and organic and gloriously messy while Python seems rigid and dull. But some people love Python and find Perl's syntax and its idioms ugly and non-intuitive. Now Ruby seems very appealing, and it's the one I'm looking to next Posted by: on June 18, 2005 12:30 AM
February 14, 2005
XSLTXT - Improved conversion to XSL

I've just posted the latest version of XSLTXT. This improves the conversion from xsltxt to xsl. I've been using it at work of some fairly complex and large (~1k lines) stylesheets with no problems. I've also added an xslTransfrom option to the command line so you can use xsltxt to just transform xml using regular xsl stylesheets if you want to.

Posted by Alex. Permalink
November 20, 2003
Too Much Code?

Kimbly has a post about Code Inertia talking about how the programmers in her shop write large amounts of code, with much copy and paste, to solve problems that could be solved more compactly. She's interested in trying to change this. To which I say:

What about the old reward and punishment routine? I'd say that it's very unlikely that the programmers will change their behavior on their own. The way they work now is fine by them, I'd go so far as to say that the way they work now is being rewarded. Producing a lot of code is probably regarded as a sign of being a code stud. Kimbly's comments imply that it might be. Are the people who write more lines looked up to, are stats maintained about how many lines each person wrote? If lines of code per programmer is tracked, even if no formal reward is associated with it, then I suggest stopping. Instead track something associated with the behavior you want to promote. One thing would be to track number of tests created and have some target for number of tests per lines of code, the more code written the more tests required. Unfortunately it's very difficult to directly measure the thing you want to promote, code reuse.

Another angle is to make it easier to do the right thing. If you use Java then IntelliJ IDEA or Eclipse with their refactoring support make it easier to reuse than to copy and paste. Instead of copying the code for a method from one subclass to another it's easier to automatically move the method to the superclass.

One suggestion, that of introducing XP, might work, but not if you continue to track lines of code per programmer. It's a way of adding a set of rewards and punishments that favour a particular style of development. I'd take a good look at the programming culture in your shop and see how it could be tweaked so that reuse becomes seen, and rewarded, as more important and valuable than lines of code.

Posted by Alex. Permalink
So what's the system where you work? How do you encourage code reuse? And isn't there a corollary? People who steal a bit of code because it's close to what they want, throw in a condition to switch between uses, and end up making it difficult to modify the original code because it affects so many things. When I worked problem reports and was debugging, I found this to often be the case. Don't get me wrong. I believe strongly in code reuse, but you have to understand what is really similar and what looks close but is actually different. Posted by: M Sinclair Stevens on November 21, 2003 11:30 AM
Copy and Paste programming is a cultural problem, and it is *serious*. The real tragedy is that the coders who behave like this don't see that they have a problem, and may resist attempts to change their coding practices. The mindset of Copy-n-Paste coders is usually, "We don't need any of that fancy theory stuff! I can turn out an app in three days by copying that other one!" If they're willing to change, great. If not, they have to go. Posted by: Chris on December 4, 2003 11:42 AM
Chris, I agree. I wonder if these are the same people who resist most changes? Sometimes it can be difficult to descern what's going to turn out to be a fad and should be ignored and what actually represents progress. That's no excuse for dismissing all possible advances though, it just makes it a bit more difficult. On the other hand people who jump from bandwagon to bandwagon can sometimes be just as much trouble as they constantly rewrite stuff to match the latest thing they read on the net. Posted by: Alex on December 11, 2003 10:27 PM
August 01, 2003
Testing software's like cooking popcorn

Testing software is like cooking popcorn is a microwave. With popcorn you set the timer for five minutes but it's time to stop when popping slows to 2-3 seconds between pops. With software you can estimate how long testing is going to take based on your past experience, and the amount of code to test, but the only way to know for sure when the software's done is watch for when the interval between finding bugs goes up beyond some limit you set.

Posted by Alex. Permalink
July 26, 2003
When to fix bugs?

Good article from Gamasutra explaining why you should fix your bugs as you go and start tracking them early in the development cycle. Gamasutra - Resource Guide - "Production Testing and Bug Tracking"

Posted by Alex. Permalink
July 21, 2003
Instant Netegrity Expert - Sort Of

Last week at work we had to demonstrate in a proof of concept single signon integration with Netegrity's product SiteMinder. As usual this involved us in installing, configuration and interfacing to software we'd never worked with before. When this happens we have to rely on the manuals.

The problem in this situation is that the manuals are not designed around the task we're trying to complete. Instead of a detailed and thorough explanation of all the possible options and the way to select the correct one in each situation, which is what a manual should provide for more normal uses, what we need is an explanation of how to get something up and running quickly in a simple situation. There's just not enough time, unfortunately, to understand everything in detail. We need a good conceptual model for the software and how-to style configuration information for the simplest possible working setup.

I imagine the actual readership for such a thing would be fairly limited for most software. For something like, for example, SiteMinder or a Portal product though, there must be a fair number of people who have to perform integration as third parties, not just install or setup for end users.

We did get it all working in the end though. Turned out to be pretty easy really, at least for the simple configuration I went with. Fortunately the design of our security system just required adding an addition SiteMinder specific module and modifying the configuration files. The whole thing could be shipped as a drop-in jar file.

Posted by Alex. Permalink
May 10, 2003
Generation Gap pattern for code generation

On the Joel on Software forum there was a thread called Code that writes code. In it I mentioned the technique I like of generating base classes and overriding them to add user written code. This means you don't have to manage files containing both generated and hand written stuff with all the problems when you want to regenerate. Turns out there's a name for this pattern, the Generation Gap.

Posted by Alex. Permalink
February 03, 2003
Paul Graham on language design and language research

Interesting little article. Design and Research. One remark though. I'm not convinced that an interactive toplevel is a huge win in software development. I'd prefer a decent refactoring editor/browser any day.

Posted by Alex. Permalink
January 29, 2003
Web Services Adoption

From TheInquirer a report of a report. Large firms hold off Web services because of security fears Pretty much matches what I've seen, lots of talk and RFQ check boxes but no real action.

Posted by Alex. Permalink
rysnc is my friend

I have linux on my machine at work and here at home. When I work from home I have a couple of options. Remote XWindows over ssh, which is pretty slow, or a local copy of the sources to work on. The best way I've found to get a local copy is to use rsync to replicate my source directory from work to home. The alternative is to use CVS to update a home copy of the code. Not only is rsync faster it also lets me work on stuff I haven't checked in yet. Because I'm syncing with my own copy of the sources I don't have to worry about overwriting other people's changes and I can either check in the code by logging in to work with ssh or just wait and do it the next day.

Posted by Alex. Permalink
December 18, 2002
Code Generation Patterns

On TheServerSide there's an article about Model Driven Architecture, TheServerSide.com - MDA from a Developer's Perspective. This includes 10 Myths about Code Generation. I spent several years working for a company whose product relied on code generation, and we use quite a bit of it at work now so I have some thoughts myself about this issue.

In particular I don't agree with myth 7. I'll just use XML/XSLT and be done with it. The explanation for why this is a myth makes the assumption that you will be modifying the generated code and have to merge these changes in with any later regeneration. In my opinion this is the result of using a flawed pattern for generated code.

I believe the correct pattern is to never modify the generated code. Clearly you'll never be able to generate code that provides 100% of the functionality you need. The question is where to add the extra functionality. Instead of adding it by editing the generated code, add it by subclassing the generated code and overriding and adding methods where needed. When you have control over the framework and it is designed with this approach in mind the end result are much better than can be achieved with don't touch the code colored blue techniques you see in NetBeans, VisualStudio.NET and similar tools.

We use this scheme very successfully at work with our own XSLT based code generation system. Using XSLT really is an advantage over proprietary tools with their own little languages, each of which will have its own little bugs, with their lack of full access to the template source, and with their vendor lock in. The biggest remaining problem with code generation really remains for the programmers writing the templates. This is the fact that you're dealing with two control flows, the one of the templates used to generate the code, and the one of the code being generated.

Posted by Alex. Permalink
I have to agree with you. XSLT is far from perfect, but it fits the "steam shovel vs. hydraulic excavator" criterion of a disruptive technology. It's worse at traditional text manipulations, but it's incredibly good at many tree-based transformations, and these are exactly the sort of transformations that will be needed for converting relatively flat data structures into classes and methods. The common language aspect is critical as well; XSLT and XPath are used all over for XML/HTML manipulations, so there's relatively little learning involved. Consider that a steam shovel might be great at digging holes, but a hydraulic-equipped front end loader can also move dirt, plow driveways, and in a pinch, pull a car out of a snow drift. Plus, it can be written in a streaming-friendly fashion, so very large files can be constructed. Steam shovels just sit in one place, and have to be moved and setup again when they reach the limits of the hole. To a great extent, you can bring a front-end loader to the work, so it's easy to dig large shallow holes as well as deep holes. There's an escape to Java for anything that XSLT does poorly, so it really is a great language for code generation. You can even generate XSLT stylesheets using XSLT, so some kinds of code generation could actually be written as code generator generation -- I never meta a template I didn't like.... If we can't have macros in Java, XSLT is a good substitute, and one with a shallower learning curve as well. Posted by: Ken Meltsner on December 26, 2002 12:42 PM
The "two control flows" has always been the problem. At ETI, it was always, "do we do this in the code or in the templates?" The Right Thing To Do, of course, was to do it in the templates, because then the code becomes extremely simple; so simple, in fact, that people can actually understand and use it. Unfortunately, most of ETI's latest code has a ton of run-time decisions that could have been taken during generation. Posted by: Glen Campbell on January 2, 2003 09:56 PM
Ken: Obviously I agree with using XSLT/XPath. The fact that it's standard gives many benefits; there are books available, there are multiple implementations so no lock-in and a better chance of there being fewer bugs. Glen: I think the biggest problem with the ETI generated code is in extending it. Some of that's down to the languages being generated not supporting overriding but looking back I think there's something that could have been done. Posted by: Alex on January 4, 2003 02:29 PM
December 16, 2002

As a sort of learning exercise I think I might have a go at porting XSLTXT to C#. This will have to be more than just a straight translation of code as the .NET apis for reading XML are different from the Java ones. In .NET Microsoft has implemented a pull type api. An application program makes calls to the parser to retrieve the next node they are interested in. Java uses SAX and application programs use listeners to handle events issued by the parser. The claim is that a pull api is easier for application programmers to handle. This may be true but I think it's going to be harder to write an XSLTXT parser to support a pull api as now I'll have to handle the state of the parse rather than letting the application do that.

Posted by Alex. Permalink
December 11, 2002
Microsoft and Software Patterns

Microsoft has only recently "gotten religion" where software patterns are concerned. Their patterns & practices site is recent, as is any formal interest in or promotion of patterns within the company. They were late to recognize the importance of software patterns, especially among corporate and Java developers, just as they were late to see the importance of the internet. However, as with the internet, though they are at the back of the field at the moment you can expect to see them running faster than anyone else and they'll soon catch up. I imagine they may well recruit some pattern heavy hitters to add credibility to their offerings. Eventually we'll probably even see people who think that Microsoft invented the whole concept!

In the meantime though, to have their most public .NET (and anti-Java) effort held up as an exmaple of how not to do things, as this article, PetShop.NET: An Anti-Pattern Architecture does, must be embarassing. It's an interesting look at the patterns used in Microsoft's PetShop.NET implementation. The issues have been raised before, in particular by Clinton Begin in discussing his JPetStore implementation, but it's good to see it as the main focus of an article. Though PetShop.NET performs better than the original EJB PetStore it may weaken Microsoft's overall argument in the end because of the poor design it demonstrates.

Posted by Alex. Permalink
November 25, 2002

Via Lambda The Ultimate comes this commentary Impressions of the International Lisp conference ILC2002 from Oleg Kiselyov. Excellent stuff, including such gems as I learned that Kent Pittman is an angry man --- and interesting observations on Google and programming in general.

Posted by Alex. Permalink
October 10, 2002
Fixing little things

For the past week and a half at work we've been putting together a point release of our software. This involves taking stuff that was going to be in the next release and stuffing it into the current one so that it can be delivered to a customer. Ok, not the best plan for how to go about things but that's the way it is.

The fun part has been fixing lots of little bugs and tweaking the UI. It's very satisfying to be able to knock off five or six or more issues in a day and see an improvement in the software. Having a close deadline and having to work under time pressure can be motivating. Everyone pitches in even more than normal and things really move forward. It's only when it drags on for weeks or months and becomes the company's normal way of operating that it's a problem. After a couple of weeks you need to slow down, step back and refactor, and make sure the code's still in a good state. I've certainly seen some stuff in the UI code that could benefit from some cleanup when we have the time.

Posted by Alex. Permalink
October 09, 2002
Messing with Python

In the past few days I've started to mess around with Python (2.2.1) a bit and I'm increasingly impressed. Perhaps it's not as elegant, I think, as scheme but it's a whole lot better than perl. Good library/module support for easily doing the sorts of things, like parsing xml and sending/serving HTTP, that are needed to build some classes of interesting apps these days. Very similar to Java but faster to write. My only quible so far would be with the GUI. I've used tk pretty extensively in the past, both from tcl and scheme, and I don't think it's as good as Swing. On the other hand it's certainly my choice for the P in LAMP.

Posted by Alex. Permalink
For Python GUIs check out http://www.wxpython.org/ Quite nice & robust. Posted by: Ken Rawlings on October 10, 2002 05:05 PM
That looks pretty nice. I'll have to try it out. Posted by: Alex on October 10, 2002 09:53 PM
Python makes a great P. Check out PyApache (@sourceforge) for a way to get mod_perl-style performance benefits whilst still writing standard CGIs that'll also work on the likes of IIS. (Annoyingly, requires a little bit of fiddling to compile on the latest versions of Python and Apache, but I use it happily for all my sites.) Also if you're doing lots of form-input stuff you may find the standard cgi module a bit cumbersome. I didm which is why there's an extensive replacement on my site, plug plug... Posted by: Andrew Clover on October 14, 2002 02:43 PM
I actually decided to go with mod_python for now. I've got (unfortunately) a bit of mod_perl experience and I like the way the handlers work. I'm still going to be faced with the separation of content and presentation problem. What's the best python solution for that? Posted by: Alex on October 15, 2002 09:06 PM
There are loads of sub-JSP style thingies for Python - . Webware's PSP is probably amongst the most mature, but Quixote is worth a look, and of course, YMMV. Posted by: Simon on October 23, 2002 05:34 AM
Gah, the URL that I entered got thrown away! Here is is again - http://www.python.org/cgi-bin/moinmoin/WebProgramming. This time, I'll preview. ;-) Posted by: Simon on October 23, 2002 05:53 AM
October 08, 2002
An overview of Analysts

From Gamasutra comes The Analyst Primer. Though directed specifically at the games industry I think it's a pretty good overview of the whole industry analyst scene and how it works.

Posted by Alex. Permalink
Gama's articles are often very interesting even for those outside the industry. Their postmortems in particular are usually far more helpful in working out whether you would like a game than the reviews in mainstream gaming mags! A pity, then, that they had to introduce a sign-up requirement (especially one with a questionnaire as intrusive as theirs). Instead, try the e-mail address guest@gamasutra.com, password guest. Posted by: Andrew Clover on October 14, 2002 02:52 PM
September 24, 2002
HP goes with BEA (J2EE) and MS (.NET)

On Friday it was announced that HP was going to bundle WebLogic with its UX11i server. BEA and Hewlett-Packard Team Up Against IBM. The article says this will be extended to all of HP's platforms in the future.

On Monday HP announces that it's going to join with Microsoft to promote .NET. Microsoft, HP Promote .NET Strategy. I suppose you're allowed to wager on both horses but I always thought only the bookies won in those cases. On the other hand, I suppose HP does have to hedge its bets so that they come out of the J2EE vs .NET "war" ok whoever "wins".

Posted by Alex. Permalink
September 18, 2002
New York Times - Pro Linux editorial

Wow. Editorial coverage for Linux in The New York Times. The New Challenge to Microsoft is a pro Linux piece touting the benefits to consumers and governments of wider Linux adoption.

Posted by Alex. Permalink
September 05, 2002
CMS for games

Gamasutra has another article worth reading, "Keeping Up with the Sims". It's about the problems of managing the production of the enormous amount of content when producing expansion packs for the Sims. Eletronic Arts outsources the production of sprite art for the Sims to New Pencil. It's interesting to read how they deal with the production of a vast number of images that all have to fit in with the style of the Sims game.

Posted by Alex. Permalink
August 25, 2002
Symbolics Lisp Machines

The Symbolics Lisp Machine Museum has, among other interesting things, this paper looking at why Symbolics Inc. failed. It uses heterogeneous engineering as a model to structure the analysis. Interesting. Crossing the Chasm also looks like a pretty good model for what went wrong, but perhaps one with less prescriptive benefits.

A quote: It turns out that technology is only useful if the environment is engineered to find it useful. I think Sun has been pretty successful here wrt Java. They've worked pretty hard to support the perception that Java is the solution to people's problems. Beyond a certain point this becomes a self fulfiling prophecy, people use the product to solve problems, hence it is a solution to problems.

Posted by Alex. Permalink
Hmm, I really had Sun in mind when I submitted that link to JoS, strangely enough. With Java you can really see how hard Sun is trying to do the Right Thing, with all that support for design patterns, clean code, and assumption that the user is a mediocre programmer. You can bet that Steele (of lisp, scheme; now at Sun) studied the failure of Symbolics and LMI. Posted by: Sammy on August 28, 2002 09:50 AM
Very interesting. You're right about Sun and their efforts to build a Java community. I think they are doing pretty well so far. It will be interesting to see if Microsoft tries to encourage a similar thing with .NET, or is it just not needed for them. I mean, did Java need to have a community to support its adoption while .NET will be popular just because it's Microsoft? Anyway, thanks for the link. Posted by: Alex Moffat on August 29, 2002 09:18 AM
August 14, 2002
Daily Builds

Today Joel Spolsky is talking about performing daily builds of software. He recommends a product called FinalBuilder for a special price of $199. Looking at the FinalBuilder website it seems to be a product like Ant with a nice GUI, but targeted towards building software for windows.

What does the existence of such a product say about Windows software development? Hard to say really but it does make me think about what sort of open source community Windows developers have access to.

When I write Java there are a lot of different projects I can borrow resources from, does a similar ecosystem exist if I'm writing MFC code? Building a supportive community around a language is important for its adoption and growth. For Java, open source projects like Jakarta and many others have helped a great deal. Will a community develop around .NET, or does the whole attitude of Microsoft mean it never will? I don't mean that MS will actively prevent it, but is the feeling that you have to pay to play on windows so ingrained that people just won't share?

Posted by Alex. Permalink
You can alternatively use Build Manager system at http://republika.pl/dailybuilds This distributed across machines system just help you with daily builds and co-work with VSS automatically for auto labelling and versioning solutions. Requirements: .NET Framework 2.0 beta 2 C++ Builder / Delphi (soon .NET compilers also) Visual SourceSafe (optionally when automatic labelling and code fetching) You can sign-up there and receive trial license to use daily builds now. Posted by: Build Manager on June 28, 2005 07:37 AM
August 12, 2002
Designing for experts

Interesting post on The Joel on Software Forum - CityDesk and swf. Talks about designing for expert users as well as for novices. How to integrate these two concerns is an interesting topic and I think it's discussed well in chapter 11 of Programming as if people mattered by Nathaniel S. Borenstein. The Amazon reviews are a bit unfair, some of the examples may appear dated but the underlying principles are timeless.

I especially like the advice to listen to your users but ignore what they say. It's suggested that you consider them like a class of three-year-olds. If they're all crying for a cookie you don't necessarily give them a cookie, but you might want to prepare them a nourishing lunch to address their real needs.

Posted by Alex. Permalink
August 04, 2002
Guiding Visitors Pattern

This paper introduces the Guide pattern. It's an extension to the more well known Visitor pattern which separates the action to be taken on the objects in a structure, for example the nodes in a tree, from the actual structure of the objects. The guide pattern goes further and also splits out the navigation. This lets you separate the three concerns, how the objects are related, how the objects should be navigated, and what should be done to each object, into independently reusable components.

Posted by Alex. Permalink
August 01, 2002
No Silver Bullet

A 1986 essay by Fred Books, of The Mythical Man Month fame called No Silver Bullet: talks about the impossibility of finding a Silver Bullet to solve the problems of producing software.

Quote: I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. If this is true, building software will always be hard. There is inherently no silver bullet.

Apparently this provoked many rebuttals when it was published but of course Brooks was right. Since 1986 no silver bullet has appeared. This IEEE Software: From the Editor column of 1999 claims that great progress has been made. Personally I'm not so confident.

I found this in a discussion on LtU. Towards the end of the thread this post is especially interesting. We should be paying more attention to how a language supports team development and how it encourages a community to form around it.

Posted by Alex. Permalink
July 18, 2002
Development War Stories

I've always found development war stories interesting. Sometimes they're also informative. I think you probably know the sort of things I mean. Tales of projects that went well, production disasters leading to phone calls in the middle of the night, companies where arms on chairs were status symbols, and so on and on. When told well they present useful lessons in an easily digested form.

One of the best sites I've found for this is Gamasutra. It's a game deveopers site that needs a free registration. The postmortem features can be just fascinating. Generally they use the format of "Introduction", "What went right" and "What went wrong", with right and wrong each being five points. It's interesting to see the same lessons popping up in different projects. Items such as under estimating work, managing content and programming workflow, and the importance of finding or building the right tools, . Lots of these apply to the more mundane sort of programming that I do for a living, and its fun to read about the rest. For example I've never worked on a project where choosing the right voice actor and building a character around their image was one of the things that made the development process successful.

Posted by Alex. Permalink
July 17, 2002
Design Patterns Are

From Lemonodor comes a link to "Design Patterns" Aren't by M-J. Dominus a Perl person.

The book he seems to base his argument around is Design Patterns: Elements of Reusable Object-Oriented Software otherwise known as GoF (Gang of Four). This was published October 1994 as the result of work over a number of years. Perl was first released in 1987 as version 1.0. Version 5.0, which introduced objects to the Perl world, came out in 1994 as well.

I think the place where M.J. Dominus goes wrong is in treating the the book is a series of C++ code samples to cut and paste into programs. Bashing design patterns because the Iterator pattern can be, to some extent, expressed using foreach statement in perl is ridiculous. Of course the simple things can be done that way, and picking the simplest pattern in the book makes it trivial to show how. What about the Observer, or Visitor patterns, what about Model-View-Controller? Does Perl have statements for these as well? Can you write mvc $foo $bar $baz->{'fruit'}; and have Perl "do the right thing"? Of course not.

As you start to look at higher level patterns like Acceptor-Connector it's clearer and clearer that they are shorthand ways to describe and name common situations so that programmers and designers can catalogue and pass on their knowledge. Just as carpenters call a particular joint a dovetail rather than describe it's detailed configuration every time, so programmers and designers use Observer as shorthand for a common configuration of components and assignment of responsibilities. Even if the language you're using provides facilities like scheme's excellent macro system you still should know that the Observer pattern is a useful way to organise responsibilites for some situations.

To end in the style in which the slides are written, what sort of person knows so little about Design Patterns as to put forward these arguments, yet feels themselves qualified to present on the topic? On the other hand seeing that on slide 6 Mr. Dominus expresses his opinion that the C++ macro system blows goat dick I think I can make a pretty guess about what sort of person he is.

The Perl community seems to attract this. Sometimes it looks like cleverness and trickiness in coding is valued over intelligence and clarity. Not just in coding though, look at the first Perl Artistic License. The GNU organization says "We cannot say that this is a free software license because it is too vague; some passages are too clever for their own good, and their meaning is not clear."

Posted by Alex. Permalink
I have to admit I've only skimmed the GoF book, but it did look like it was presented at a level that was only a little higher than 'C++ code fragments to be copied and pasted.' And I don't think that's necessarily a bad thing--a book at that level can be very helpful. One just shouldn't think they know too much about the general idea of patterns and their purpose after reading it. Or I just need to actually read the book. (OK, now you post a comment on my weblog, right? Oh no, nevermind. I have been lazy in upgrading to the newest Movable Type, and also I should probably read up on exactly what TrackBack is.) Posted by: jjwiseman on July 17, 2002 11:45 AM
You said: Can you write mvc $foo $bar $baz->{'fruit'}; and have Perl "do the right thing"? Of course not. But that might simply be a defect in Perl. Instead of deriding and dismissing this idea, perhaps you should consider it more seriously. Don't you agree that it would be an improvement if languages could abstract away the need for the MVC pattern? That would free up programmers' attention for more complex and powerful patterns. You might like to read Peter Lindberg's thoughts on this matter. I found his approach to this discussion more thoughtful and less reactive than yours. I hope you find this helpsful. Posted by: Mark Dominus on July 19, 2002 09:46 PM
I may have been a bit reactive. Design patterns provide a useful common vocab. for programmers to discuss program architecture, design and implementation. This is their main benefit. They should not be regarded as a cookbook of code samples to be copied without thinking. With the passage of time some patterns, perhaps Iterator is one, become so well known or appear so trivial that the benefit that came from describing them in the first place is forgotten. By analogy, the while loop is now trivial but was a great invention when first described. If perl is ever to have an MVC instruction or operation it can only come about because someone has first discovered, described and published the MVC pattern and it has become accepted as a useful way to structure the solution to certain design problems. The pattern comes before the implementation, even when the implementation is embedded in a particular language. Posted by: Alex on July 28, 2002 04:25 PM
Alex, you said that design patterns are not to be regarded as code samples to be copied without thinking. The problem is that the GoF book is mostly about these kinds of patterns, needed in C++ because of its inferior macro system. The inability for languages like it and perl and python and smalltalk and java to abstract at the syntactic level causes large amounts of repetitive code to be written when something clear, simple, and expressive could be used instead, had the syntax been amenable to automated processing. You should see how some of my Lisp code is written. I use some very strange macros to abstract various design patterns I use. See http://linux.rice.edu/~rahul/DefDoc/engine-framework.lisp and look at the with-breaking macro. It's not complete or nearly as general as I will make it later, but this is an example of the pattern coming at the same time as the implementation. Posted by: Rahul Jain on August 20, 2002 02:19 PM
Rahul, you're right of course. A lot of the problems are caused by the lack of macros, or higher order functions. I currently reduced to xslt and code generation to achieve compact notation for some stuff I'm working on. Some things look like they will only be tractable with aspect oriented programming though. Cross cutting concerns such as model view controller may best be expressed this way. btw, I like the lisp Posted by: Alex on August 20, 2002 09:13 PM
Camps within camps are fighting on this one. Many people feel Design Patterns are over blown. I think Arthur J. Riel's "Object Oriented Design Heuristics" was a much better book. Perhaps it lacked the prestiegous namesake, perhaps it wasn't as dumbed down. Within the camp that thinks Design Patterns are cool, there are those who think that Patterns are a cool hardcore object thing, then there are those who believe that the GoF butchered Christopher Alexander's concept of "A Pattern Language". I'm a member of the latter camp. Most Perl programmers don't use objects because large Perl programs aren't ever written. To write a large Perl program, you'd need two Perl programmers (or more), and no two Perl programmers can read each others code. Seriously, Perl isn't used for large projects. It has a deserved reputation for being unmaintainable - so, in one sense, it despretely needs patterns. In another sense, patterns won't do a thing for Perl. Being a hopeless idealist, and loving Perl, I want Perl to be used for more tasks and to work to counter its reputation. A liberal interpretation of the idea of patterns lets me document Perl idioms, object short cuts, hacks to deal with Perl's OO model shortcomings, mechanisms for retrofitting structure onto overgrown programs, integration of object and lambda programming styles - Perl is a diverse, introspective language. Depending on how you define patterns and how you define need, Perl needs patterns. This problem has been a real challenge for me - I've worked so hard on this project, but the interest is just lacking. The arrogance in the Perl community is stunning. I think Python is rising to power not because it is better than Perl - and it some ways it is, though it shares many of Perl's weaknesses. I think Python is gaining ground because of the attitude of the people who write it. In discussions of OO and Perl, I'll bring up short comings in Perl's OO implementation - the reaction is always the same - I must be some sort of an idiot to suggest that Perl implements method inheritance but not data inheritance - a subclass and superclass can't avoid namespace conflicts by using a keyword like "private". The fact that people refuse to see shortcomings is litteraly preventing people from taking interest in fixing them. Six months, thousands of hours, hundreds of pages, and the interest in the Wiki forum software far outweighs the interest in whats in the forum. Argh. Posted by: Scott Walters on March 5, 2003 08:06 AM
July 16, 2002
The Death Sprint - A new AntiPattern

Over on kuro5hin there's an interesting article on a new AntiPattern. The Death Sprint is the result of a missapplied and badly implemented XP development process. As opposed to the more well known Death March, where nothing is ever released, though development goes on endlessly, the Death Sprint has frequent releases of code. However, over time the quality of the releases, and the quality of the underlying code base, gets worse and worse. The team is going faster than they can support, tripping over their own feet. With no time to refactor existing code before adding new features, or to consider their design, quality goes downhill, and each new feature becomes harder and harder to implement and introduces more and more bugs.

The cure is threefold. First pause to implement unit tests for existing features and make sure they all pass. Secondly refactor the existing code to make it cleaner and easier to modify in the future, checking with the unit tests at each stage so that bugs aren't introduced. Thirdly, and finally, keep the unit test disipline and add some design so that quality remains high in the future.

Posted by Alex. Permalink
July 13, 2002
XML Shell

On sweetcode, which is a great place for finding the more offbeat and interesting software projects, I found XSH, the "XML Editing Shell". This is a perl module that uses the metaphor of a file system with directories to represent an XML document with elements. It provides a shell for traversing and manipulating the file system using commands analogous to the unix shell commands. For example, cd is used to change the current context to different elements with the argument being the xpath to the target element; ls is used to list the current context. Of course commands are also provided to add new elements and attributes, and even to apply style sheets. I suggest reading the article at xml.com first for an overview.

I've always been interested in systems that attempt to use an existing conceptual model from one domain in another domain. If done successfully it makes it easier for new users to understand and learn the system as they are able to apply knowledge from the domain they already know to the new tool. The danger is that any conceptual mismatch between the old known model and the model of the system being learnt can prove very jarring.

Just after I first posted this I realised how easy it would be to implement something like this is scheme or lisp. The read-eval-print loop is already built in. All that would be needed is to implement the cd, ls etc. commands as scheme/lisp functions and it would work. Using Oleg's scheme xml tools as a basis I could imagine even me knocking this together.

Posted by Alex. Permalink
June 05, 2002
Perl's had its day - It's become like COBOL

On Lambda the Ultimate this morning was a posting discussing Larry Wall's latest Perl language design statements, this time about regular expressions. As usual Ehud Lamm had interesting things to say not just about the proposal but also about the meta issue of language design.

Meanwhile, at the same time, over on the other side of town, on slashdot, the latest perl musings were also being discussed. When I got to this discussion it had about 4 posts rated at +3 or above, and they were all rated funny. Clearly no serious discussion was taking place yet. I would have liked to see some posts about people's experience with perl, the perl 6 efforts, alternatives to perl, in fact anything but more funny remarks. I thought maybe I could try and get a discussion started. A lofty and presumptuous goal. A provocative post title looked like a good way to attract attention and get people talking, so I posted Perl's had its day - It's become like COBOL.

I think this is a defensible argument. Certainly I would say that Perl has had its day. I don't think it will again be the defacto choice for scripting or cgi programming the way it once was. It used to dominate the space it is in, it's less dominant now with the rise of python and ruby for scripting and php for cgi work; I don't think it will get its dominance back. It will still be used but some of this use will be because of legacy perl code that must be maintained or extended instead of rewritten. The rest will be for quick scripts that must be written and the writer happens to knows perl, the situation I find myself in from time to time. In some ways this is similar to COBOL, legacy use and legacy users.

Actually some of the resulting discussion was interesting, though not perhaps as interesting as I had hoped. What was more interesting to me was the history of the moderation done to the post and the light it threw for me on the slashdot groupthink that occurs. The post started off at +2 climbed to +4 (interesting) where upon it must have attracted attention as it was hit with flamebait and troll to end up at +2 (troll). Then it started to go up again and it currently sits at +3 (interesting) having had 11 moderation points used on it. Result as of now:

Moderation Totals: Flamebait=2, Troll=1, Insightful=1, Interesting=4, Overrated=2, Underrated=1, Total=11.

A quick look at the moderation of other posts in the threads and it seems like they generally get a small number of points, maybe 1 to 3, all in the same direction. There is also a really strong tendency for moderators to use offtopic to force threads to stay rigidly on topic when a bit of drift would make for a much more interesting discussion. Ah well, it was fun.

Posted by Alex. Permalink
May 25, 2002
More Paul Graham

Paul Graham says in his most recent piece Succinctness is Power "It seems to me that succinctness is what programming languages are for." Actually, it seems to me that what programming languages are for is to enable us to explore and clearly express what we mean, realise that meaning as an executing program, and understand and change what we mean later without having to start from scratch. John Wiseman said in response to one of Mr. Grahams earlier pieces "I place a lot of value on Graham's thoughts on lisp because he's not a fanatic". I'm afraid his recent writings are starting to tend, in my opinion, in that direction. This isn't necessarily a bad thing though, after all, without RMS we wouldn't be where we are now.

Posted by Alex. Permalink
May 21, 2002
All Languages are not created equal

More interesting stuff from Paul Graham. In this article he advances the view that the Lisp family of languages are superior to other programming languages. I actually believe this, even though I write Java for a living. However, the meta-question is, why aren't Lisp style languages more popular now than they currently are? And the answer can't be, "the best solution doesn't always win" as that is no explanation at all. Paul talks about this towards the end of the article but no complete explanation emerges.

Quotes include and reading at runtime enables programs to communicate using s-expressions, an idea recently reinvented as XML.

and the very cynical Because, you know, when it comes down to it, the pointy-haired boss doesn't mind if his company gets their ass kicked, so long as no one can prove it's his fault. The safest plan for him personally is to stick close to the center of the herd.

Within large organizations, the phrase used to describe this approach is "industry best practice." Its purpose is to shield the pointy-haired boss from responsibility: if he chooses something that is "industry best practice," and the company loses, he can't be blamed. He didn't choose, the industry did.

Found courtesy of lemonodor

Posted by Alex. Permalink
May 14, 2002
Interesting Thread on UML

Over in the discussion area at Joel on Software, where the level of trolling has recently been rising, I read this very interesting thread on getting started with UML. Worth taking a look at.

Posted by Alex. Permalink
May 13, 2002
Enterprise Application Architecture - Martin Fowler

Martin Fowler has put on the web an early draft of what looks like an interesting book, Enterprise Application Architecture. Once I've had a chance to read it I'll post my impressions.

Posted by Alex. Permalink
May 09, 2002
Useful collection of Object Oriented tips

Ootips provides an interesting and useful collection of tips for object oriented architecture, design, and programming.

Not that I agree with all of the stuff. For example the section on static type checking doesn't address "modern" type systems and the type inference mechanisms in languages like Haskell, O'Caml, and ML. With these you get the benefits of static typing without the verbosity. You don't need to declare the types of all variables, and the language can and will infer undeclared types based on the types required by the variable's usage. The downside is that the type system is more complex and is currently harder to understand than the simpler models of, for example, Java and C#.

At this point in time I think that the static typing vs dynamic typing discussion is starting to heat up again after some years when less attention was paid to it in non academic circles. Personally I like languages with higher order functions and static type systems, but I also really like scheme, which is dynamically typed. This post and the thread it's part of seems to show I'm not the only one.

Posted by Alex. Permalink
April 25, 2002
Language Myths

Extracted from a discussion at Lambda the Utlimate here is a list of myths about programming languages. I've reordered them slightly. It's an interesting list really, many Slashdot threads about programming languages devolve into rants by people defending one or other of these myths.

  1. All programming languages are basically the same
  2. To be a professional programmer it is enough to know one language well
  3. EITHER Imperative programming is more intuitive (than functional programming) OR Functional programming is more intuitive (than imperative programming)
  4. OOP is best design methodology
  5. An OOPL must have a class construct
  6. Inheritance is the best way to get code reuse
  7. Java/C++/C is the best programming language ever designed
  8. C/C++/Java is the best language to base a first year / intro to programming course on, since "C/C++/Java is what they use in industry."
  9. Exceptions are bad
  10. Programmers who use LISP are more productive than those who use other languages
  11. Real Men don't need GC
  12. Static typing reduces programming speed
  13. C is faster than Scheme
  14. C is faster than C++
  15. Hand coded assembly is always the fastest

Posted by Alex. Permalink
Hello, I read your language myths page and I was wondering if I could get some programming advice. Im thinking of getting into programming and I would like to be involved in creating games. I would like some advice on starting a good base for my programming venture. Which language/direction should I go? Im a graphic/web designer and Im not sure if my knowledge in these industry softwares help me at all. Posted by: on October 23, 2002 01:00 PM
Hello, I read your language myths page and I was wondering if I could get some programming advice. Im thinking of getting into programming and I would like to be involved in creating games. I would like some advice on starting a good base for my programming venture. Which language/direction should I go? Im a graphic/web designer and Im not sure if my knowledge in these industry softwares help me at all. Posted by: don linville on October 23, 2002 01:00 PM
Hello Dear sir I am very glad to familiar with you . i m very interested in creating games such as Medal of honor , fifa 2003 and so on . If there is no trouble with you please help me Best regards M .nouri Posted by: mohammad nouri on April 12, 2003 08:50 AM
hello, i am interested in creating games, and i would like to enter in a gaming industry. Can u tell me some well known industries in india and an estimate of hw much can a professional game developer earn. Posted by: john on April 27, 2005 04:21 AM
hello sir, I am very new to the world of gaming.I want to create a game. I have great ideas.But I dont know how to Implement it.Being a IT student ,I can manage to program in languages like C,C++ & bit of java.Please suggest me about softwares to create 3d & 2d games...... Posted by: k.sowmya on July 1, 2005 02:32 AM
April 08, 2002
Unix System Programming with Standard ML

From the comp.lang.ml FAQ "ML (which stands for Meta-Language) is a family of advanced programming languages with [usually] functional control structures, strict semantics, a strict polymorphic type system, and parametrized modules." It's an interesting set of languages especially if you're used to Scheme with its dynamic type system or languages like Java with its OOP style. Using higher order functions (often abbreviated to hof in newsgroup postings) can take some getting used to.

I acutally started out by learning (at least partially) Haskell. Fascinating, even monads made sense after a while. However, I found it just too purely functional for the sorts of problems I like to try and solve, which are generally not along the line of how to encode and evaluate financial instruments using a domain specific language. I felt I needed something more like ML. From my little knowledge the two most popular "dialects" are Standard ML of New Jersey and OCaml and I settled on Standard ML, at least to start with. My efforts to learn it are currently being greatly helped by a recently published book book which helpfully uses largish chunks of code so you can see how to structure things for real. There is no real substitute for reading and writing code when you're learning a language.

Posted by Alex. Permalink
April 05, 2002
mod_gzip - compressing http traffic

Browsers that understand HTTP 1.1 can understand compressed data, this can reduce the bandwidth your site consumes by 75% . The HTTP 1.1 standard defines the Accept-Encoding header that lets a browser tell a server the various ways in which data transmitted to it can be encoded. One of the possibilities is gzip. I've sort of known this in the back of my mind for a while but today I actually got round to using it.

This article provides a overview of the whole subject and is written by the author of the mod_gzip module for Apache that I'm using on this site. I found it easy to instally mod_gzip both on Apache on this linux box and on Apache on a win2k box at work. It did take a little poking around but the needed information is in the FAQ.

For the main page of the site I'm getting around 60% compression and for the article pages around 75% compression. This is good for me as I'm quite prepared to trade a small increase CPU usage for a descrease in bandwidth consumption.

The impetus for this investigation was a performance problem encountered at work. Our current release version of our application has pages that are a bit larger than they should be. In the next release we've made quite a few changes to reduce their size. This is combined with a client that has a network connection that's a bit smaller that we would prefer to produce an overloaded connection. One of the things we can do is to serve compressed data and this is what we're doing. Fortunately we have a couple of choices, the mod_gzip and possibly mod_proxy approach for Apache customers and an IIS method for those who use Microsoft. Personally I think the Apache approach is easier to configure because you can do it by editing a configuration file instead of having to issue commands from the command prompt.

Posted by Alex. Permalink
Another comment Posted by: on April 5, 2002 10:36 PM
Sir, I read about a vulnerability on mod_gzip. I just want to know when the mod_gzip is triggered. I want to know how we can know that the mod_gzip is triggered. How you are able to capture the compression information Thanks. Posted by: Mallesh on October 19, 2002 01:04 AM
I am having problems when submitting a FORM (with POST method ) very big. When i click the submit button, the server send me back a timeout message. Is there a way of compressing POST data. I mean, from the client. This only happens in apache for win32. Apache for linux have no problems. Thanks in advance. Posted by: Danux on February 11, 2003 05:57 PM
Its true, slots is very fun to play. Posted by: online slots on December 29, 2004 09:27 AM
If anyone loves poker, PokerMagic is the best online poker site Posted by: poker on December 29, 2004 09:27 AM
I agree that the site is good, but cant people find better things to do. Posted by: casinos on December 29, 2004 09:28 AM
Very funny! I am L.M.A.O! Posted by: online poker on December 29, 2004 09:28 AM
Lose weight today Posted by: meridia on December 29, 2004 09:29 AM
Lose weight with phen Posted by: phentermine on December 29, 2004 09:29 AM
Nice site, great to be here Posted by: Diet pills on December 29, 2004 09:30 AM
Hello ・great work Posted by: adipex on December 29, 2004 09:30 AM
・ol Posted by: blackjack on December 29, 2004 09:30 AM
Increase your desire with supplements. Posted by: viagra on December 29, 2004 09:31 AM
Hey, slots casinos are great fun. Posted by: Slots on December 29, 2004 09:32 AM
March 20, 2002
Hurray, the time I spent learning Haskell and Standard ML wasn't wasted :)

You know how they say If the only tool you have is a hammer everything looks like a nail, well this is an example of how to use a hammer as a screwdriver. Of course it would all be much easier if you had a screwdriver in the first place but that didn't stop the writer of this code. Section one is entitled Functional composition, curried functions, partial applications and lambda expressions. and this is done in XSLT so watch out. Via LtU.

Posted by Alex. Permalink
March 10, 2002
Learning a language

What's the most important factor when learning a different computer language? I'd say it's whether or not you have an application for the language that you can use to motivate you. For languages like perl or python that's fairly easy as there is always some scripting to do that's not been done yet.

For languages that are not "scripting" languages it's sometimes harder to come up with something that's worth doing. This probably accounts for the million and one "frameworks" that you see on SoureForge. In some ways it's much easier to write a framework to write web applications than it is to think of a web application you want or need to write. To go off on a tangent I think that the best "frameworks" often emerge from a project that needed a framework to build something else that was their main focus. At least that way there is some discipline about what gets included and what doesn't.

At the moment I'm trying to learn Standard ML. The problem is coming up with something that I want to write in Standard ML. One of the reasons I write things like xsltxt in java in my "spare" time is that I write java at work so there is often some problem that would be fun to explore but which can't be done at work.

Ah well, back to the search for a problem domain.

Posted by Alex. Permalink
I agree. I have a terrible time learning languages when studying tutorials or reading books like "Java in 21 Days". But when I was trying to get a product out, I was able to learn Tcl, even though I'd never programmed before. During this first painful experience, I learned a lot of basic programming concepts which made it easier to pick up subsequent languages--but only when I was trying to get something to work. Coming to programming this roundabout way, I found the easiest way to learn was to debug someone else's errors. Trying to get something working is really the best motivator. Posted by: mss on March 21, 2002 09:02 AM
March 05, 2002
Maintainability as a language feature

In the development I do at work the most basic and common operation is looking through existing code to fix bugs or add enhancements. I suspect this is true for most commercial Java development whether you're looking through code you or someone in your team wrote or through xerces or xalan or jdom or some other package. Here's where there is the potential language feature conflict though. Brief to write and "more than one way" will help early adoption for a language but may conflict with easy to read and understand, which is what I want when faced with 250k lines to maintain. (of course the usual whipping boy here is perl, so I'll point my finger that way also)

Posted by Alex. Permalink
February 19, 2002

I decided that my emacs minor mode for assisting with java editing deserved wider circulation so I set it up as a project on savannah :) The project is called jxminor and the code is available via cvs or as a tar download.

I'm not anticipating a great demand for this code, after all how many people edit java with emacs these days, but I don't think that's the point really. jxminor is very useful to me and maybe someone else would like it as well.

It would be interesting to know how many people use emacs and how many other IDEs for java editing. I've not noticed any features in the IDEs that people use at work that are must haves and the extensibility of emacs is a big plus for me. Also, surprising as it is to people who remember the complaints about the size of emacs, it is a lean mean editing machine compared to the bloatware that is a "modern" IDE. Programs that are so large that you can either run the IDE or run the program you're developing seem a bit too big for me.

Posted by Alex. Permalink
February 05, 2002
"corporate development mixed-ability team projects"

Ah, now there's a phrase to conjure with (found in a slashdot post). I think there really is a set of language features that this environment requires, or at least that makes developing in this environment easier. Some languages target this environment and some, such as arc, deliberately don't.

Is there a way to make these environments more productive. I've heard of the studies that show great variation (10 times?) in programmer productivity, which seems to indicate you're better off with one star than five or six ordinary mortals. Fred Brooks, in "The Mythical Man-Month" proposed the surgical team model where one truly expert programmer is supported by others in different roles.

Is this how programming has to be done? Is it like playing a musical instrument where you can probably teach most people how to do it but few will be really great? Is an orchestra a good model? What do you do with all the people who play third chair violin? How do you deal with the "everyone needs to learn to program" ideas? Is it even true that everyone needs to learn to program? After all not everyone could repair a car but most people could drive one.

Do we need different languages for just these reasons? Some languages that are safe and fitted for the mixed-ability team and others that take the "With great power comes great responsibility" approach. Or, is it possible to build one language where you can choose to loosen the restrictions or tighten them depending on the situation? In which case how do different sections of code with different restrictions interact etc. etc.?

Obviously I have no answers, only questions.

Posted by Alex. Permalink
February 04, 2002

Paul Graham has just made available online his book On Lisp for download. Reading the first few chapters and other articles from his site again makes me think that much of XP is a way to try to bring the benefits of the lisp/scheme development process to java.

Obviously it's not as simple as a one to one correspondence between the two systems. The biggest difference I think comes from the XP focus on what might be called the corporate or enterprise sort of development project while On Lisp and Paul Graham's writings, though certainly commercial, relate to a different environment. (I'm trying to think of a couple of word characterization but I'm drawing a blank right now).

On the other hand the similarities between the design approaches are striking, and you could apply the enterprise techniques to the lisp approach quite easily, while there are things about the lisp approach that require lisp and don't translate well to a java based XP system.

The development technique On Lisp describes as Interactive Programming (Sec. 3.4) where functions are constructed bottom up towards an initial design with constant testing, refactoring and integration into the whole is very similar to XP. But I think the difference is that Java does not as easily support the most powerful part of the lisp style, the simultaneous construction of the application and the language extensions and abstractions that support it. In lisp you build the language in which you finally write the program so that when you get to the writing the program you have a syntax and semantics that match the problem domain.

In java you have no macros, can not extend the java syntax in the same way you can the syntax of lisp, and it's nowhere near as convenient to pass functions around and operate on them (and I'm not even considering the amazing stuff that Haskell makes easy). I find I end up with wordier and less "elegant" solutions than I would in lisp or scheme. Code that you could abstract out into a macro or closure in scheme ends up requiring a separate system to generate it from xml specifications using an xslt template system. (yes, I've done this)

Where java does shine is in it's excellent libraries that you can bolt together very easily to produce an application. It also has the mindshare advantage for enterprise development, especially with the J2EE APIs.

I need to think about these issues some more but the more java I write the more I miss the things that can be done in scheme.

First notice of On Lisp availability courtsey of lemonodor and Lambda the Ultimates, both well worth reading.

Posted by Alex. Permalink
"...generate it from xml specifications using an xslt template system. (yes, I've done this)" You are sick. SICK. Posted by: jjwiseman on February 5, 2002 03:13 PM
True :). In my defense I would refer to the "if your only tool is a hammer everything looks like a nail saying". We are unfortunately restricted to a toolbox mainly full of hammers at the moment even though we'd really like to use some of the nice power tools that are available. Posted by: Alex on February 5, 2002 03:47 PM
December 10, 2001
Ant as an example of the Innovator's Dilemma

Many, if not most, open source Java software projects use Ant instead of make as their build tool. When Ant was first introduced it offered only a subset of the features of make, and even now it is still behind in some areas. So, how come it took off so dramatically? Perhaps "The Innovator's Dilemma" by Clayton M. Christensen offers some useful insight.

Personal experience. I've actually constructed a complete build system for a commercial Java project using make and then turned round and redone the whole thing using Ant because it made some Java specific tasks so much easier on Windows platforms. I hope that this lets me comment on both systems from the basis of at least some experience.

The Dilemma. The Innovator's Dilemma identifies three key concepts that help to explain why and how an existing successful "product", such as make, can be rapidly replaced by a newcomer that initially has far fewer features. These are

  1. Disruptive technology.
  2. Existing product's available feature set outstrips actual needed feature set.
  3. Investing in disruptive technologies in not initially profitable for existing product's developers.

Disruptive technology. To quote from the book "Disruptive technologies bring to market a very different value proposition than had been available previously. Generally, disruptive technologies underperform established products in mainstream markets. But they have other features that a few fringe (and generally new) customers value."

This is clearly the case with Ant where I would point to the ease with which Java compilation can be done, the simplicity of building war and ear files and the lack of additional software needed to run on Windows platforms as some of the more disruptive values. Though Ant lacks features that make has, such as being able to dynamically generate rules by pattern matching, it is so simple to get Ant to do something when you are working on a Java project that you can get started much sooner than if you have to use make. Anyone can put together a simple Ant build.xml file to compile some code they have written because they already have most of the knowledge and software they need. Getting make set up to do the same thing may well include installing cygwin if you are working on Windows, and learing the syntax of make files.

Feature set.Because of the rapid rate of progess and the general ease with which features can be added any software product rapidy acquires far more features than customers need or are willing to pay for. In the context of make or Ant the currency of the payment is the time taken to understand either product and work out how to accomplish the task you have. Once a disruptive product reaches a certain level of "feature completeness" users will swap from the existing product to the new one at a dramatic rate as they trade some features they currently don't use for some ease of use or other benefit they want.

I would say that because make has so many more features, and to a great extent so much more capability, it is a more difficult product to get started with. For many projects Ant provides enough functionality even though it does not provide the same amount as make. Even if both continue to add features at the same rate the features that make adds will necessarily be of use to a smaller number of non make users, (those people who have a build problem but can't use make as it doesn't have some feature X) as most needs are already addressed by make. However, those features added to Ant will satisify a larger number of non Ant users as there are more of them.

Clearly existing projects are "locked in", at least to some extent, to their existing build system, but as new projects start they pick they can pick something new to use. If people don't already understand make, or are intimidated by it then they will start with something else if they can, and Ant picks up another user.

Investing. For open source products the investment being made is the time and effort people put into developing the product, including developing addons and surrounding infrastructure.

I think the hint here is that existing projects will seldom spawn their disruptive replacements. People working on an existing project have too much invested too easily throw it all overboard for a less functional alternative. You do see projects embarking on major rewrites, but almost always to provide a more functional, better architected solution, not to provide a simpler alternative that satisfies fewer of their "customers" than the current system.

Future. As Ant adds more features and becomes more complex will it be possible for it to remain easy to pick up and work with or will it start to approach make, leaving an opportunity for another replacement? A more "global" question, is it possible to design a system from the startbodybe a disruptive technology and so take over a market in that way.

Posted by Alex. Permalink
(Alex pointed me here in reply to a slashdot post--http://slashdot.org/comments.pl?sid=34220&cid=3702950--in which I decried several misfeatures of Ant.) What can I say, except that I suspect you're exactly right. Particularly, I had forgotten about the cross-platform part of Ant's appeal (I won't touch a Windows without Cygwin, but it's no doubt a hurdle for Windows natives), which I suspect is the biggest factor. Posted by: Andrew on June 17, 2002 04:45 PM
Hey, slots casinos are great fun. Posted by: Slots on December 29, 2004 09:11 AM
Its true, slots is very fun to play. Posted by: online slots on December 29, 2004 09:12 AM
If anyone loves poker, PokerMagic is the best online poker site Posted by: poker on December 29, 2004 09:12 AM
I agree that the site is good, but cant people find better things to do. Posted by: casinos on December 29, 2004 09:13 AM
Very funny! I am L.M.A.O! Posted by: online poker on December 29, 2004 09:14 AM
Lose weight today Posted by: meridia on December 29, 2004 09:14 AM
Lose weight with phen Posted by: phentermine on December 29, 2004 09:15 AM
Nice site, great to be here Posted by: Diet pills on December 29, 2004 09:15 AM
Hello ・great work Posted by: adipex on December 29, 2004 09:16 AM
...lol Posted by: blackjack on December 29, 2004 09:16 AM
Increase your desire with supplements. Posted by: viagra on December 29, 2004 09:17 AM
hehe, i like it very much. congratz. :P Posted by: teensforcash on August 16, 2005 09:18 PM
This is the first time i heard about this!!! :S Posted by: telecharger musique on August 19, 2005 06:24 PM
What do u mean? are you sure? Posted by: spam blocker on August 22, 2005 03:22 AM