Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com

Epic codefest: 7 programming languages in 7 days

Learning a new programming language isn't hard if you understand the fundamentals

By Andrew C. Oliver, InfoWorld, 03/04/13

  • Print
  • Feedback
.

Page 4 of 5

But unless there is any reasonable valid reason for using JavaScript for the back end, I wouldn't recommend doing so. It worked pretty well for a small project like Granny's Addressbook, but add scalability, security, and larger project requirements, and I'm pretty sure more problems would creep up. For any small project that doesn't include these as requirements, using Node.js and Express would be my choice, if not for the ease of working with JSON, then for simplicity.

The other drawback is that there doesn't seem to be any extensive, easy support for databases. Yes, I was lucky enough to find a Postgres client, but that was an open source project written by someone who used the framework before. Let's say I wanted to switch to MongoDB, Neo4j, MySQL, Couchbase -- there's support for a few of these, but the switch wouldn't be easy. We basically would need to rewrite almost all the code.

 Day five: Go Granny
Developer: Brian Crucitti, "The New Guy"

Google Go was a rather frustrating language to work with, both in terms of documentation and in looking for solutions to problems. "Google" and "Go" are such common words in Internet articles that searching for, say, "Google Go as a server-side language" or "Google Go tutorials" is almost useless. And searching with the two words together in double quotes eliminates many of the articles that refer to the language simply as Go or Golang. Searches using "Golang" eliminated a lot of pertinent articles as well, including quite a bit of Stack Overflow, which refers to the language as "Go."

The home site for Go actually provides a brief tutorial on how to write your own wiki page, which I worked through with plans to refactor it into the back end of my Granny Addressbook application. Unfortunately, the tutorial ended after giving out some code snippets that were not fully explained, leaving me high and dry with no other option than to dive into the documentation to try to find out what exactly was happening in the bits of code I had received.

I think I was expecting something along the lines of the Android developer documentation; what I got was short descriptions and a lot of search-bar use. A search for http.request, an unexplained object that seemed to be very important in the tutorial, resulted in a brief description and some code. This code showed it was a structure made of primitives and other structures. If I actually wanted to know what it did and what I could do with it, I would have to spend time searching out all those underlying structures.

I can see the advantages of using Google Go for certain projects. It is C-like, but not quite as rigid, and the lack of .h files and makefiles is a definite plus. I imagine that anyone skilled in Go could definitely create some amazing programs. There are, however, easier (and more search-friendly) languages that can accomplish the same tasks.

If I had to do this application again with the choice of Go or Java, I would definitely choose Java.

 Day six: Scala Granny
Developer: Michael Brush, "like a hairbrush," Java/Spring guy

What makes Scala with the Play framework special is that it seems to be trying to make Java simpler.

Scala is similar to Groovy in that it is almost a scripting language on top of Java. Play is the equivalent of Grails as the Web framework that sits on top of Scala, and it seems to be the community's standard way of working with Scala. Scala/Play compiles all of its code into Java, and developers can use any Java class in the Scala language. Of course, Scala and Play themselves have a lot of classes that are intended to be used for the simplification and scalability of Java.

Scala/Play was easy to set up and use. I liked the way that you define the URLs for the application. There is a separate file that feels like a hosts file. This makes it easy to see all of your URLs in one location. It was also easy to understand what you were returning to the Web page. For instance, to return a 200 success, you just use the Ok() method with the contents of what you'd like to return.

I did my coding in Eclipse using a Scala plug-in that installed with no issues. There is not a plug-in for Play, so I also kept a console window open when I needed to do things specific to Play.

The build was done from the command window. Play has a console that you use. You browse to the root directory of your project and type play. This runs a few items, then you're in a command-prompt window specific to Play.

To build the project, I just ran run (and used clean if I needed to clean the project). This builds the project and starts it running on an internal Web server. After it is started, you can switch back over to Eclipse and develop; you don't have to touch it again. It compiles each time you go to the website that is set up.

I'd have to become more familiar with Scala/Play to know whether I would recommend it for a larger project. I don't know yet how models interact, but for something along the lines of Granny, I'd definitely use Scala/Play again.

One reason is simplicity. Sometimes I overcomplicate a problem, and I did just that with one of the issues I was having with this project. I was dead-set that if I didn't code the project a certain way, you could not have an address with blank fields. I finally decided to let that hang-up be, and it turned out what I was trying to do wasn't necessary and the framework took care of allowing the blank fields on its own.

James Iry at Typesafe was a big help with the project, especially with getting my big issues resolved.

I would recommend Scala on a project. For now, I'd start on small Web-based projects, but I can see that with some more knowledge, Scala could be useful for big projects as well. It's flexible and simple.

Documentation was the biggest issue with Play. It's a young framework (1.0 was released October 2009), and they are still improving and simplifying it. Specifically, I had problems marshaling and unmarshaling JSON. It appears that this has gone through a few iterations. I think this is a good and bad thing. The developers of Play appear to be listening to the community and are improving Play based on what the community wants, but this means a lot of changes between versions. As a result, it's harder to find information for the version you are currently working on. At some point as the framework gets more mature, this will slow down, and the documentation and answers on Google and the like will get more consistent.


For more enterprise computing news, visit InfoWorld. Story copyright InfoWorld Media Group, Inc.

  • Print
  • Feedback