You and Accounting

May 27, 2008

I’ve been working for almost a year now on my own Web 2.0 SaaS Accounting Software startup.  As I’m getting closer to a real market launch I’m learning a lot about the business and marketing side of things (yeah, it takes more than technology).  In that vein I’ve decided to try and gather some data about the market I’m thinking about that I can use to develop a revenue model and marketing strategy.

I hope that many of the readers passing through this blog will be willing to take a survey about their accounting needs and practices so I can figure out if I’m going in the right direction.

Here’s the link: You And Accounting Survey

I know you would do it out of kindness to help my fledgling startup, but there’s another perk – you’re also entered into a draw for a $200 gift certificate at Amazon!

Thanks in advance!


Are Dynamic Languages More Powerful? I don’t think so

March 2, 2008

Let’s say that power means “the amount of work done per unit of time.”

It could be said that development is made up of these types of work (and much more):

  • Design
  • Prototyping
  • Learning the Language
  • Writing New Code
  • Understanding Old Code
  • Refactoring
  • Debugging New Code
  • Debugging Old Code
  • Reading Other People’s Code
  • Debugging Other People’s Code
  • Making Use of Libraries
  • Making Libraries
  • Refactoring Libraries
  • Updating to Refactored Libraries

JavaScript, Python, and dynamic languages in general do well in some of these areas but not others

For example, “Writing New Code” seems to be the area of focus for advocates of dynamic languages, who see a big power gain there, and possibly in “Learning the Language”.

It seems to me, however, that Java is just as powerful as dynamic languages in the other categories, and much more powerful if you use an IDE with support for completion and refactoring.

That is to say, I can get a hell of a lot more refactoring done per unit of time in Java using Eclipse than I’ve seen in any other language.

This post was inspired this other blog post that compares using GWT to Javascript: http://blogs.pathf.com/agileajax/2007/05/angry_at_gwt.html


Using persistence.xml and ejb3unit

January 23, 2008

Lately the “Don’t Repeat Yourself”, or DRY, principle is quite popular. I like it quite a bit myself. However, when using ejb3unit, I found that I had to maintain two lists of persistence classes – one for ejb3unit, and one for the java persistence system. Today I finally decided to address this problem, and I haven’t regretted it!

I wrote a method which finds and parses my META-INF/persistence.xml and returns an array of classes from it. I can pass this to the constructor of the BaseSessionBeanFixture when I create the test case object.

Here it is:



 public static Class[] getDbClasses() {

        URL[] persistenceUnits;

 	try {

 		persistenceUnits = Classpath.search("META-INF/", "persistence.xml");

 	} catch (IOException e) {

 		throw new Error(e);

 	}

        Set> classes = new HashSet>();

        for (int i = 0; i < persistenceUnits.length; i++) {

            URL url = persistenceUnits[i];

    		try {

             nu.xom.Builder b = new nu.xom.Builder(false);

             Document d = b.build(url.openStream());

             Nodes unitNodes = d.getRootElement().query("//p:persistence-unit",  			new XPathContext("p", "http://java.sun.com/xml/ns/persistence"));

             for(int j=0; j < unitNodes.size(); j++) {

             	Node unitNode = unitNodes.get(j);

            	Element unitElt = ((Element)unitNode);

 		String unitName = unitElt.getAttributeValue("name");
		if(!unitName.equals("my-persistence-context"))
          		continue;

 	        Nodes classNodes = unitElt.query("//p:class",  			new XPathContext("p", "http://java.sun.com/xml/ns/persistence"));

 	        for(int k=0; k < classNodes.size(); k++) {

            		Node classNode = classNodes.get(k);

             		if(!(classNode instanceof Element))

             			continue;

         			Element classElt = (Element)classNode;

         			if(!(classElt.getLocalName().equals("class")))

         				continue;

 	            	String className = classNode.getValue();

 	                System.out.println("   class: "+className);

 	            	Class classInstance = Class.forName(className);

 	            	classes.add(classInstance);

 	            }

             }

    		} catch(Exception x) {

    			x.printStackTrace();

    			throw new Error(x);

    		}

        }

        return classes.toArray(new Class[classes.size()]);

 }

This is making use of the “Classpath” utility class from facelets, available here. Also note that you’ll have to replace “my-persistence-context” with your own persistence context name.

This also serves as an example of how to find things in the classpath and configure yourself; I’ve used for my own GWT templating system based on facelets. I used the facelets code to find my own tag libraries, just the way that facelets does. It’s quite a nice model for auto-discovery!


Eclipse J2EE Module Dependencies Page contains Illegal Values

January 22, 2008

I just ran into this problem that eclipse wouldn’t display the J2EE module dependencies for a couple of my projects.  The solution I found was to open the MANIFEST.MF files for those projects and delete the classpath entries.  I suspect I had some old classpath entries in there which were no longer valid, and the property page code was flipping out about it.

Hope this helps someone …


Can Java learn from python when it comes to library design?

January 16, 2008

When it comes to the language wars, I eventually came to realize that productivity in a language is driven first by the library that comes with the language (if any) and second by the IDE’s that are available for that language.

One thing that makes python great is that they integrate a lot of useful stuff right into the core library. Java, unfortunately, hasn’t done a great job of following this lead. For example, they don’t provide a way to encode a Base64 string by default. When I use my IDE to search for classes with the name Base64, I get a rather amusing list of re-re-implementations and copies of the same class, all because the Java library maintainers are unable or unwilling to put this common functionality into the library.

Anyway, when I saw this, I thought “Java could really learn a few things from python about having a feature rich standard library …”

All the completions of Base64 in my Java EE app


Glassfish: Setting the context-root of a WAR inside an EAR

January 15, 2008

I’ve been bashing my head against THIS one for weeks, on and off.  Each time I tried to figure out how to map my app to the name of my choice (‘/’) nothing I did seemed to work!

Finally today I learned about yet another XML file you have to edit in Java EE – application.xml.  Yep, the Java EE development life is filled with wonderful and magical XML files.

Application.xml is a lot like web.xml, but it applies to the EAR.  What isn’t obvious, and which nobody warned me about, is that the context-root for an app is set in application.xml, and it doesn’t matter what you put into sun-web.xml, web.xml, or anything else to try and rename the context-root of your war.  application.xml will override all of that.

So, I’m happy to have found it, but sad that it took so long.  Hopefully others having the same problem – “context-root in sun-web.xml ignored” or “glassfish ignores my context-root” for those searchers out there – can find this post and be enlightened by it!


Software testing with testuff.com

January 11, 2008

I just ran into this interesting tool at testuff.com.  It’s a combination bug reporter and screen capture tool designed to help clearly document and describe test results.  Easily adding some screenshots and a video of what you did seems like a great way to report bugs!  It integrates with trac, bugzilla, and others which lets the tester submit directly to your favorite bug tracker.  It looks very nice!

It’s free during beta and for single-user use, and they’re planning to charge $300/year for it after beta for 1-5 user setups.