• Javascript and jQuery Tips

    I came across Paul Irish’s 10 Things I Learned From the jQuery Source screencast today and found it quite interesting. He delves into some of the inner workings of jQuery as well as a few nice tips for plain old Javascript. Rather than telling you myself, I’ll just let him do it. I’ve embedded the screencast below. In addition, I’ve embedded Irish’s presentation slides from his presentation “jQuery Anti-Patterns for Performance & Compression”. It also has a few good tips and some new jQuery functionality that I’m going to try out. If you have some time, take a look at both as they have some good info.

  • Effective Communication of Software Requirements

    What is the most effective way to get a customer to clearly explain the requirements for software? Time and again I fail to fully get the full set of requirements from my customers or get an incorrect interpretation. It isn’t that I don’t ask questions or that the customers don’t give me details, but rather it seems that the different perspectives on the requirements lead to many misunderstandings from both parties.

    I’m not trying to nail down every requirement up front - just attempting to get an accurate representation of the requirements I do ask for from the customer. It often seems that a each party understands a particular requirement differently which leads to confusion, frustration, and stalled projects.

    Perhaps using more detailed scenarios where the customer can give a step by step description of how they expect the software to work. Maybe having them give a more visual representation of the software using pictures and flow charts. Perhaps better questions. Maybe a combination of all the above. I wonder if certain methods work better with certain customers?

    Either way, there must be a better way to collect requirements.

  • Scala Named and Default Arguments: A Sticky Situation

    I love named and default arguments. I’ve been using them for years in ColdFusion and find them quite useful. It is a wonder more languages don’t support them. Scala 2.8 has both as new features. Here is an example of the usage.

    class Person(
      var firstName: String = "Dustin",
      var lastName: String = "Martin"
    )
    
    // Use named arguments
    val person = new Person(
      firstName = "John",
      lastName = "Doe"
    )
    
    // Or use the default arguments
    val person = new Person
    
    // Or mix and match the two - lastName uses the default of "Martin"
    val person = new Person(
      firstName = "John"
    )

    As you can see this is a very simple class with two properties. I’m very fond of these new features and both can serve to simplify your code.

    But not all is well when using named arguments. Lets say you have a class and start off using names arguments for the constructor.

    // Use named arguments
    val person = new Person(
      firstName = "John",
      lastName = "Doe"
    )

    No problems yet. But lets say you need to add a custom method for firstName to return “foo” instead of the actual firstName

    class Person(
      var firstName: String = "Dustin",
      var lastName: String = "Martin" ){
    
      def firstName = "foo"
    }
    
    val person = new Person(
      firstName ="John",
      lastName = "Doe"
    )

    As soon as you run this you find the compiler throwing an error. The problem is that variables and methods share the same namespace. In other words, methods and variables can’t share the same name. Consequently, if a custom method is needed, the variable – in this case firstName – must be renamed. This poses a problem if you have already started using named arguments.

    // The above would need to be...
    class Person(
      var _firstName: String = "Dustin",
      var lastName: String = "Martin"){
    
      def firstName = "foo"
    
    }
    
    val person = new Person(
      firstName = "John",
      lastName = "Doe"
    )

    But this still will not work either. The problem is that when the person object is instantiated, the argument firstName is referenced. It no longer exists though. Only _firstName exists. So to fix this we are stuck renaming firstName to _firstName every time a new person object is created. But that seems like a poor solution. We don’t want to have to change all of our code every time we need to update a class.

    So what is the solution to the problem? I’m not sure. Always prefixing variables with underscores or some other character? Not using named arguments? Something else? Right now I’m inclined to simply not use named arguments – at least not for constructor arguments. That way I can change firstName to _firstName and create my custom method without having to update my code. But it would certainly be nice if named arguments could be used in constructors without having to worry about this. Perhaps there is another solution that I’m not aware of. Seeing as how Scala is still a fairly new language, and version 2.8 hasn’t even been officially released, a lot of best practices have yet to be established. It will be interesting to see how the Scala community decides to handle this sticky situation.

  • Thoughts on Event Driven Programming

    What is Event Driven Programming? In the context of ColdFusion, the way I see it is as a way to loosely couple different components from each other by announcing when important moments happen (events) in an application and letting other components register interest and then receive notification via some kind of even manager. This way, components do not really know about each other, only about events that may happen in the system and only have the even manager as it’s dependency rather than any number of related components.

    Does that make sense?

    Just recently I began thinking about event driven programming in the context of ColdFusion. The idea is very appealing to me. Being able to have many of my components be loosely coupled and not having to worry about injecting as many dependencies seems quite nice. Not to mention being able to very easily add new features to an application without having to inject some new component into a bunch of existing components or having to mess with AOP seems lovely.

    The trick though is how to go about creating an event driven architecture (EDA) and then how far to take it in an application. Do you try to use EDA to completely decouple every component or just use it for auditing and similar cross cutting concerns. For instance, is it possible to decouple a DAO from a service so that a service merely announces an event and the DAO registered to listen for that event takes action, saving or querying? It seems that saving is one matter since it doesn’t typically involve any return value. But what about querying? Obviously the DAO would need to return results but how would that be accomplished?

    This leads to another question. What happens if an event fails? Or succeeds for that matter? Is it possible to notify the original component and should I? I have no idea. It seems that might be pretty tricky. Asynchronous events seem much easier to handle.

    The place I really see event driven architectures succeeding though is with things like sending emails, logging, auditing, etc. Crosscutting concerns that need access to many facets of an application. This poses the question though: what about AOP in matters like this? There seems to be some overlap in the two areas. But, as is always the case, it seems some times using an event driven method would be better and likewise, sometimes using an AOP method would be better. I’m curious to know what other uses there are that would be a good fit.

    As with any new thing, it is possible to go completely overboard and overuse it, but I’m leaning to a more subdued approach for the time being. Using events to drive things like auditing seems like good approach for now until I understand it more. I am however, excited to seem what new uses I can come up with.

    I’ve been taking a look at Sean Corfield’s Edmund framework and it is pretty interesting. I’m definitely going to investigate it further, work up some tests, and see how it goes.

  • A Domain Specific Language to Describe a Web Application Model

    The web applications I typically write often have a lot of similarities in them. They usually have a similar architecture, follow the same conventions, use the same libraries, etc. Perhaps another way of putting it would be to say that they follow a similar set of patterns. I have a particular way of programming and my web apps reflect this.

    This however has made me wonder: just how much of an application could be abstracted out and defined within a domain specific language? I have no doubt that much of my apps could be done this way. But how do I go about this? In my reading and tinkering I’ve created small frameworks (or would interpreter be a better word?) that take a DSLs and help to build part of an app for me. What I’m thinking though is on a bit bigger scale: like generating my entire model from a DSL and eventually some views and other portions of my application. But starting from scratch to create a language and framework to build most of my app for me is probably a bit overkill. So, I will just start with my model.

    My model, as is probably the case with others, is fairly formulaic. Of course there is some customization involved but getting the initial SQL, service objects, business objects, etc. created is fairly trivial – just monotonous and time consuming. Which is one reason why you find people using tools like Transfer ORM and Hibernate. Sure, it wouldn’t be that difficult to actually write all the classes that and write all the SQL an ORM creates for you but it definitely would consume a lot of time – time that could be better spent making the application better or getting it done faster (or both). Doing all that manual work also creates a bigger chance that errors will be introduced since you’d be writing so much more code by hand.

    This is why I’ve started getting excited about the possibility of domain specific languages generating my applications or portions of them. The idea of creating a simplified language to allow me to rapidly define my app (or part of it) and cutting out much of the repetitive aspects of development is an exciting idea.

    The type of DSL I’m talking about is called a horizontal DSL if I understand correctly. Horizontal DSLs deal with the technical aspects of app. There are also vertical DSLs that align more with business processes and ideas rather than the technical side of things.

    To start off I’ve worked up a DSL that I hope to start using for the model in my apps. There is still a lot of work to do like creating the framework to transform the DSL into actual code but first I must come up with a usable DSL to define my model in. So far, this is what I have come up with (it is a bit simplified for this blog).

    Note: Much of this DSL I did not originate on my own but from other sources such as Peter Bell’s blog and presentations. His articles and presentations have given me a lot of inspiration in this and much of his examples I have used in this DSL.

    <model>
        <serviceobjects>
            <serviceobject>
                <name>PersonService</name>
                <class>path.to.concrete.service.object.class</class>
                <dataaccessobjects>
                    <include name="PersonDAO" />
                    <include name="OtherDAO" />
                    <include name="AnotherDAO" />
                </dataaccessobjects>
            </serviceobject>
        </serviceobjects>
    
        <dataaccessobjects>
            <dataaccessobject>
                <name>PersonDAO</name>
                <businessobject>person</businessobject>
                <class>path.to.concrete.dao.class</class>
            </dataaccessobject>
        </dataaccessobjects>
    
        <businessobjects>
            <businessobject>
                <name>person</name>
                <pluralname>persons</pluralname>
    
                <pluraltitle>Human Beings</pluraltitle>
                <table>persons_tbl<tbody></tbody></table>
                <idproperty>personID</idproperty>
                <class>path.to.concrete.business.object.class</class>
    
                <properties>
                    <property title="Identification Number" name="personID" datatype="number" columnname="person_id"></property>
                    <property title="Name" name="personName" datatype="string" columnname="person_name">
                        <validationrule name="required" value="true" />
                        <validationrule name="maxLength" value="50" />
                    </property>
                </properties>
            </businessobject>
        </businessobjects>
    </model>

    Right now I’d say I’m fairly happy with this DSL. That said, I have very little experience in working with them so only time will tell. I’d love to hear what people’s thoughts on it are though.