Don't Quit Your Day Job

Erlang for Java developers presentation

noreply@blogger.com (Anonymous) — Fri, 23 Apr 2010 19:08:00 +0000

I gave this talk to the Chicago Erlang Users Group this past Wednesday, April 21st. It is meant to be an introduction to Erlang for someone coming from an imperative language like Java.

I am considering expanding it in to a tutorial screencast with the slides and some live coding. If that sounds interesting to anyone, let me know!

Erlang on a Mac (for the lazy)

noreply@blogger.com (Anonymous) — Tue, 13 Apr 2010 03:12:00 +0000

Getting Erlang installed on your Mac isn't really all that difficult. You can just download it from http://erlang.org/download.html and build from source. But if you want to plan for future lazyness, then Homebrew is the way to go. Homebrew is quickly becoming the package manager of choice for OSX, so it will not only get your Erlang installed quickly and easily, but many of your other *NIX-y tools of choice. Go here http://wiki.github.com/mxcl/homebrew/installation for download instructions. I strongly suggest reading the whole page before you start. Once you have it installed just go to the Terminal (yea you are already there if you installed Homebrew) and type 'brew install erlang'. After it completes downloading and making the source (yes Homebrew just automates the available .configure/make/make install process) you are ready for the next step.

Now that you have Erlang on your system you are going to want to get the Erlware tools. Erlware is conceptually like Homebrew, except for Erlang applications. It is a bit heavyweight and not always completely intuitive, but the benefits far outweigh the potential confusion. Once you start writing real Erlang applications, you are going to need to package and release them. While the core Erlang language is super simple, releases are arcane black magic. Having a tool that can automate the process is a real life saver. Erlware is essentially two tools, Faxien, which handles installing packages and dealing with remote repositiories, and Sinan, which will generate project structures and build your applications. You can find them at http://erlware.org, just follow the links for downloads and the Faxien universal launcher.

Once Faxien is downloaded go back in to Terminal and type python and the name of the file you downloaded. It is going to prompt you for several pieces of information, the most important is (if you used the Homebrew defaults) /usr/local/lib/erlang as the install directory. It will ask you if you want to keep your current Erlang install and install Faxien on top of it. Choose this option. Faxien will now install any application you retrieve or create with it in your Erlang distribution, making it available to any program. This will solve any dependency issues you may have otherwise run in to. Again, lazyness is key. Once Faxien is installed you can use it to install Sinan, just type 'faxien ir sinan'. ir is a shortcut for install release. All of the Faxien commands can be found with faxien help commands. ir is all you will need for now.

Once Sinan is installed it is time to do some damage. I generally use 'sinan gen' to create a project directory with all of the needed files for a valid OTP application. If the app is going to be relatively simple (99% of the time) then I generally move the contents of the project/lib/project/ directory up to the project directory. That probably didn't make much sense until you see it. For example if you did 'sinan gen' and entered 'bob' as the name of your project it is going to create a directory called bob with several subdirectories including _build and lib. Under lib you will find bob again, and inside that directory what appears to be a normal Erlang app. I just copy all of those files/directories up to the top. Sinan will handle this with grace and it feels a little less clunky. If you are planning on splitting your project in to several subprojects, don't bother doing this.

Now you can go in to the source directory, write some code, add those modules to the .app in /ebin and type 'sinan' to compile the code. After it compiles you can type 'sinan shell' which will open an erl repl with all of the proper code paths set. from here you can do an application:start(bob). And it will fire up your app and let you interact with it from the shell. Once you are happy with your code you can do a 'sinan dist' which will pack up your code in to an Erlang approved tarball format. Now Faxien comes back in to the picture. If you type 'faxien ir' it will install the tarball in to your /usr/local/lib/erlang directory.

Now, for the final piece of lazyness jackpot. When you sinan gen next, and create the project 'fred', you will be able to modify fred.app in the ebin of that project, and list bob in your modules and viola it just works as if you were using crypto or any other built in Erlang library.

Happy Erlanging!

Erlang for Java Programmers

noreply@blogger.com (Anonymous) — Wed, 09 Sep 2009 04:16:00 +0000

In a previous post I declared the end of my monogamous relationship with Java. I really played the field for a little while, but it did not take long for an infatuation with Erlang to take hold. Clojure was the runner up, and something I intend to explore more soon, but two languages at a time was a bit too much.

Erlang is a functional language, but as a Java developer it did not scare me off. While the syntax is a little out there, the concepts map pretty neatly:

Immutability
I have always erred on the naughty side with Java when it comes to the use of objects. I tend to have fairly struct like domain objects with getters and setters, and leave the business logic to manager type classes. I was never comfortable tying business logic to something I read out of the db and pass around and which may have different requirements in different apps. So the switch to a functional language was pretty easy, the main difference is instead of using setters, updating an object is a bit more like a clone/set combo. It feels a little like wasting memory, but you get over it.

Conditionals vs Pattern Matching
In Java my methods tend to end up littered with if/then/else tests on the state of various objects. In Erlang the case statement is occasionally used to make sure a function did not return an error, but not much else. Instead, Erlang takes the idea of an overloaded method to a whole new level. Pattern matching is pretty easy to understand, and impossibly powerful. Each function input can be used to direct flow in to this or another version of the function. This sounds like it might lead to a bunch of copy paste, but instead it results in a few succinct versions of a function that are far easier to reason about.

Objects are Processes
One of the main reasons I picked Erlang over a more traditional functional language like Haskell is the idea of processes. I didn't quite understand how anything could happen in a side effect free, stateless world, but Erlang keeps state all neatly wrapped up inside processes. Erlang processes are instantiated functions. You heard that right, unlike in Java, where an object is an instantiated class, in Erlang you run a function in a recursive loop forever. Weird right? Well the only real trick to this is now that the loop is going infinitely, passing its own state back in to itself, it needs a way to talk to the outside world. This is accomplished through messages. By putting a receive block inside the function, it will sleep until another process sends it a message. It will then wake, handle the message, loop and go back to sleep.

There are of course many more concepts to consider, and I did not touch on OTP, but these were the main hurdles I encountered when reading my first Erlang book. I think Joe Armstrong's book is fantastic, and the new O'Reilly book is solid as well.

There is a new online tutorial for beginners:
http://learnyousomeerlang.com/

For a solid 6 part intro to OTP check out Mitchell Hashimoto's blog:
http://spawnlink.com/articles/an-introduction-to-gen_server-erlybank/

A good searchable API site (though seemingly lacking the bifs):
http://erlapi.prepor.ru/docs/

If you are in Chicago, be sure to check out our user group:
http://groups.google.com/group/ceug?hl=en

And if you are interested, my first Erlang project:
http://github.com/chrisduesing/simmoa/tree/master

Learning a New Language

noreply@blogger.com (Anonymous) — Wed, 20 May 2009 23:05:00 +0000

At some point I realized I was on my way to becoming the COBOL programmer of tomorrow. 10 years in to my career and I hadn't touched another language outside of Java for 9 of them (not counting a myriad of technologies used in conjunction with Java for web, XML, etc.). It really hit home at Startup Weekend when I couldn't keep pace with the Ruby programmers. Not everything was a nail, and I had become way too comfortable with my hammer. I wouldn't mind learning Ruby, but my goals did not end up pointing me in that direction. I wanted something

completely different than Java
good for concurrent, distributed and/or real-time programming

I frequent Hacker News and it is difficult not to become intrigued by Lisp after spending much time there. I started reading articles and eventually bought Paul Graham's ANSI Common Lisp. It was a good book, and I don't feel intimidated by the syntax anymore, but I have a long way to go before I intuitively can tell the difference between a function + arguments, a list and a macro body while browsing code. I am intentionally not coding much beyond hello world, because I haven't decided on a language yet, and because I want to develop a feel for the right way to do things before I just start porting over Java habits.

Lisp was my first contact with a functional language, and the entire concept intrigued me. I began to do more research and started reading up on Haskell, Erlang and Clojure. I really liked all of them, but wanted to choose just one to really deep dive in to. I picked up the Manning MEAP on Erlang and started watching Clojure screencasts. My pro and con list is still taking shape, but here is a look so far:

pro: Erlang seems like a perfect fit for writing the kinds of systems I am interested in, and has an easily understanable syntax.
con: Erlang's OTP and system libraries are a complete mystery to me and the documentation/resources are a bit scarce.
pro: Clojure lets me take advantage of Java's libraries and leverage the time I spent studying Lisp
con: The Clojure syntax isn't clicking for me, and I feel like I am not branching out far enough from Java.

I may just end up pursuing both if I cannot make a decision. I am going to step it up in the meantime. Tonight I am going to attend the Chicago Clojure Meetup, and hopefully in June I can take the Hands on Erlang training. I will keep you posted!

Seam generated UI doesn't like references to multiple entities of the same type

noreply@blogger.com (Anonymous) — Tue, 10 Jun 2008 20:32:00 +0000

Given two classes (minus important details like @Id, getters, setters, etc).

@Entity
public class Bar {}

@Entity
public class Foo {

  private Bar bar1;
  private Bar bar2;
}

and then running seam generate-ui on the containing project will produce something like:

@Name("barHome")
public class BarHome {}

@Name("fooHome")
public class FooHome {

  @In(create = true)
  BarHome barHome;

  @In(create = true)
  BarHome barHome;

  public void wire() {

    Bar bar1 = barHome.getDefinedInstance();
    if (bar1 != null) {
      getInstance().setBar1(bar1);
    }
    Bar bar2 = barHome.getDefinedInstance();
    if (bar2 != null) {
      getInstance().setBar2(bar2);
    }
  }
}

which of course, does not compile. Even if it did, it would not work properly. The FooEdit.xhtml page would set both instances to the same thing. This is the problem I set out to solve, not really knowing if there are any other use cases where this might be a problem.

First I Googled seam generate-ui and found this JIRA post:
http://jira.jboss.org/jira/browse/JBSEAM-994

It wasn't all that helpful, especially when I saw that Gavin wrote, "...in fact I don't see any easy way to arrive at a correct solution - this is a super-difficult one to solve by code generation, it needs human-written code." In order to achieve just that I set out to write the simplest code possible, since I evidently won't be able to modify the generator, I am going to have to re-apply my fix each time I re-generate the ui.

First thing I did was tackle what seemed to be the most obvious 2 problems. 1) this doesn't compile. 2) The bars need to be stored in 2 separate home instances. The modified code...

@Name("barHome")
@Role(name="barHome2")
public class BarHome {}

@Name("fooHome")
public class FooHome {

  @In(create = true)
  BarHome barHome;

  @In(create = true)
  BarHome barHome2;

  public void wire() {

    Bar bar1 = barHome.getDefinedInstance();
    if (bar1 != null) {
      getInstance().setBar1(bar1);
    }
    Bar bar2 = barHome2.getDefinedInstance();
    if (bar2 != null) {
      getInstance().setBar2(bar2);
    }
}

The whole thing now compiles, but the resulting FooEdit.xhtml only sets the value of bar1, no matter which is selected.

What we ultimately want to be able to do is limit changes to the components that need to know about this complexity and hide it from the ones that don't. The requirement is to not change Bar or any of the components/pages associated with it. Luckily this ended up working by making small changes to FooHome, FooEdit.xhtml and FooEdit.page.xml.

First FooHome gets a variable to note which version of BarHome it should set an id for when coming back from the BarList.xhtml page. There need to be methods to get and set the proper barHome id for this as well.

@Name("fooHome")
public class FooHome {

  @In(create = true)
  BarHome barHome;

  @In(create = true)
  BarHome barHome2;

  int selectedBarHome;

  public void setBarId(Long id){
  
    switch (selectedBarHome){
   
      case 1:
        barHome.setBarId(id);
        break;
    
      case 2:
        barHome2.setBarId(id);
    }
  }
 
  public Long getBarId(){
  
    switch (selectedBarHome){
   
      case 1:
        return barHome.getBarId();

      case 2:
        return barHome2.getBarId();
    }
    return null;
  }

  public void wire() {

    Bar bar1 = barHome.getDefinedInstance();
    if (bar1 != null) {
      getInstance().setBar1(bar1);
    }
    Bar bar2 = barHome2.getDefinedInstance();
    if (bar2 != null) {
       getInstance().setBar2(bar2);
    }
  }
}

Next the FooEdit.page.xml parameter that sets the bar instance needs to reference the new fooHome bar id instead of the barHome id . So the line


<param name="barId" 
          value="#{fooHome.barHome.barId}">

becomes


<param name="barId" 
          value="#{fooHome.barId}">

Finally the FooEdit.xhtml is changed to tell FooHome which BarHome it is going to be making changes to. Look for the s:button in the tab panel for "Select bar1" and "Select bar2". Add an action to these buttons to accomplish this. Below is the generated xhtml page only showing the buttons with the new action added.


<s:button value="Select bar1"
    view="/BarList.xhtml"
    action="#{fooHome.setSelectedBarHome(1)}" >
 <f:param name="from" value="FooEdit" />
</s:button> 
...
<s:button value="Select bar2"
    view="/BarList.xhtml"
    action="#{fooHome.setSelectedBarHome(2)}" >
 <f:param name="from" value="FooEdit" />
</s:button>

And that is pretty much it. Now when you edit a Foo, the tabs at the bottom for bar1 and bar2 will properly select different instances of bar from the bar list.

Java Library Migration

noreply@blogger.com (Anonymous) — Wed, 09 Jan 2008 18:24:00 +0000

I don't generally get super technical on this blog (I also don't often write on this blog, so increasing the scope couldn't hurt the frequency), but I thought I would share some of the pain I experience from time to time in migrating an existing Java project from one set of library dependencies to another. In this case I am taking the first steps in migrating an app from MyFaces JSF on Tomcat to Sun's JSF on JBoss. The pain is compounded by the fact that I use Eclipse as a development environment. Eclipse is great right up until the point you try to change one of its basic project settings, at which time you need to have a detailed understanding of all of its configuration properties. This will be a step by step how I approached the problem rather than an after the fact recipe for doing the same thing. It should be more illustrative of what a developer actually goes through in troubleshooting an issue.

Background:
The project is set up as a standard Eclipse 'Web Project'. This means it will try to control all of the dependencies for Servlet/JSTL/JSF etc as well as Java version, building and server integration. The other way of doing this is to set up every project as a generic 'Java Project' and then use Ant scripts to build everything. It takes more time to set up initially, but down the road you will end up using Ant to build for test/production scripts anyway, so the pain it can help you avoid is well worth just using it off the bat.

Step 1 : Remove the MyFaces Libraries
I deleted the MyFaces api and impl libraries from the project. I also removed them from the Tomcat launch configuration. I then added the Sun RI version which can be downloaded directly from dev.java.net. Upon republishing and relaunching Tomcat I got the following error:


SEVERE: Exception sending context initialized event to listener instance of class com.sun.faces.config.ConfigureListener
java.lang.NoSuchMethodError: javax.servlet.ServletContext.getContextPath()Ljava/lang/String;
at com.sun.faces.config.ConfigureListener.getServletContextIdentifier(ConfigureListener.java:1804)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:558)

Several Google searches imply this problem falls in to one of a few areas:

I have previously upgraded Tomcat to version 6 and there might be a dependency somewhere on the old version of the servelt implementation that does not implement the latest spec.
A previous upgrade of Java to version 6 may be causing an issue with the way jsf/servlets loads classes that is incompatible.
The latest JSF libraries have different dependencies than MyFaces did and there is a clash.

Step 2: Troubleshooting based on shoddy information.
I initially try updating to the latest versions of the JSF libraries from dev.java.net to no avail. I then try pulling jstl from the latest Glassfish. I look around for newer versions of the servlet impl, but I have the latest version of Tomcat so that seems unlikely to help. To eliminate Tomcat from the equation I plop the war file in JBoss and get the same exception. Has to be the project itself or somehow still Java6. The Java version seems a strange solution as the app worked before pulling the MyFaces library. I set up a new Tomcat server in Eclipse with Java 5 runtime and the same error occurs. This has to be a library incompatibility issue of some sort, but Java doesn't help in this area so the experimentation continues.

Step 3: Getting the latest version of all dependencies.
I find a page that explains the steps for getting JSF running in Tomcat, its dated, but it sparks an idea... why not start over? So I merrily delete Tomcat and all of the jars my project is dependent on. I remove that Tomcat from the Eclipse servers list and then go in to the project. Uht oh, now I notice that my project compiler level was building to 5 and I was trying to deploy to a 6 runtime.. was that the source of the problem? May be hard to say even if this fixes the problem since I blew away so much. This is a great reminder of why the patient, one step at a time approach is always the right one, even when frustration sets in.

Step 4: Denouement
Once I get the latest versions of the libraries dropped in to the tomcat/common/lib folder and the project and server pointed to them I need to go through each entry in the project 'properties' menu and make sure everything is up to date and consistent. Once this is done the project builds and deploys nicely.

This is one of many instances where you come to realize that the more a tool works to make your life easier, as soon as something goes wrong you really need an intricate understanding of it. The more the complexity is hidden from you on a day to day basis the worse it is when you finally peek under the hood. It never hurts to have a general understanding of how the tools you use work, but it really is times like these that make it happen. Good thing they don't happen every day...