Here you don't know what's there

Quite some shift having worked mainly at companies that were open source-centric before, now at one that endorses proprietary enterprise platforms.

I have found that latter such companies don't recognize open source efforts and startup solutions.  It is a mystery (to them, at least) how Twitter has managed so far with obscure languages like Ruby and Scala.  It must be a joke to claim Google used commodity hardware for their servers.  When you have a USD 30K DBMS you have no reason to consider NoSQL toys.

Whereas at my previous workplaces we would probably be rolling our eyes, thinking why we would ever need it, when offered, say, a USD 30K DBMS when we ran everything on PostgreSQL just fine.  Yahoo! did it with PostgreSQL, why couldn't we, right?  We could implement Hadoop and Cassandra for specific tasks if they fit better than they would on PostgreSQL.  If everything were still slow, it would be the development team's fault, of course.  Couldn't have it any other way because, otherwise, why hire us at all.

But of course, experience will vary depending on how one makes use of either technology.  Many proprietary products do excel at what they do.  And it is only natural that people spend money on these works.   I'd think the distinction is that at one (extreme) end you see lots of money and at the other (extreme) end you feel a great deal of passion (and both are perhaps equally reliable catalysts of creativity).  This isn't a rant on merits of either practice--not that I have authority on that topic to begin with!

What this is about is how easily we turn a blind eye to the other side when we've been delving in just one side of the equation for long.

Around the Web

Sometime ago I checked out different approaches to web application development (in my free time.)  With Python I explored the Pyramid framework as well as Django.  With Scala I did Lift.  And lastly I explored JSF using Groovy as a replacement for Java.

Actually I was quite overwhelmed with Python.  It's not difficult to write anything in Python. 
However, to write good code in Python it should take considerably more effort and more thorough understanding of the language.  I stumbled across a lot of metaprogramming then.  I think it grossly difficult to feel secure because, with metaprogramming alongside dynamic typing, most of your application's survival depends on the condition of your gestalt.

Scala lifts much of that mental burden off me I should think.  I like Lift.  I could do more in Lift in the future.  :)

Groovy is, as I probably wrote in my previous post, somewhat in the middle when it comes to typing--a degree of static as well as dynamic typing.  It saves a lot of time and code lines.  In a way it intuitively guides me to write better code.  There can be a lot of metaprogramming too in Groovy, but it's not a show stopper.  You don't necessarily have to understand it to write good code.  Though it's pretty easy (I think compared to that in Python).  It would be much better if Java EE and relevant stuff were tailored to fit Groovy more.  And better IDE support.  And a way to filter exception stack traces (Seam Catch maybe?).

Huh, OpenJPA?

Purpose of this post is primarily to help add hype around OpenJPA (there is lack of hype, from community and Apache/OpenJPA all the same).

Contrary to the plain vanilla JPA implementation vibe the project site gives off, OpenJPA might actually have its own distinctive virtue.   A popular phrase among Haskellers perhaps, "do one thing, and do it well."

Configuration might be a little daunting at first because it takes a rather different approach from such that Hibernate and EclipseLink share.  But that aside it has worked well for me (after about two-weeks use for development purposes) and perhaps most importantly for me is that its documentation is awesome.  The content feels well-thought out.  It comes in the usual online help and PDF formats.  Haven't you ever stumbled across duplicate or outdated content somewhere in EclipseLink's wiki-style 'Documentation Center'?

On that note, actually Hibernate comes with similar documentation formats as well.  The difference is that with Hibernate documentation feels more like a long tutorial (a JBoss thing perhaps?) while with OpenJPA (an Apache thing perhaps?), documentation is more formal.

Anyway one nice feature I've recently found is a native UUID generator assignable via the usual GeneratedValue annotation.  Excerpt from the documentation:

OpenJPA also offers additional generator strategies for non-numeric fields, which you can access by setting strategy to AUTO (the default), and setting the generator string to:

• uuid-string: OpenJPA will generate a 128-bit type 1 UUID unique within the network, represented as a 16-character string. For more information on UUIDs, see the IETF UUID draft specification at: http://www.ics.uci.edu/~ejw/authoring/uuid-guid/
• uuid-hex: Same as uuid-string, but represents the type 1 UUID as a 32-character hexadecimal string.
• uuid-type4-string: OpenJPA will generate a 128-bit type 4 pseudo-random UUID, represented as a 16-character string. For more information on UUIDs, see the IETF UUID draft specification at: http://www.ics.uci.edu/~ejw/authoring/uuid-guid/
• uuid-type4-hex: Same as uuid-type4-string , but represents the type 4 UUID as a 32-character hexadecimal string.

These string constants are defined in org.apache.openjpa.persistence.Generator.

So there goes my preliminary hype around OpenJPA.

What's a programmer to do in Indonesia?

One question that often comes up during an interview, "What do you expect from working with X company?"  Considering that the question is often asked somewhere along the end of the interview I would think it's only casual chat.  But I'd know better.  So, what do you expect from working with X company?

Sometimes I would blurt out (especially after a rough interview) and say something like, "All of it--good salary, nice environment, awesome colleagues, successful products or services."  Or would you rather hear someone say, "I love programming so I would like to have a lot of challenges coming my way.  I get a kick out of torturing my soul day in and day out."

Basically what I'm trying to say is that, no, economic situations in Indonesia won't allow a regular programmer to ever become successful enough to live well.  I'm talking about the small salary, yes.  I'm also talking about high property rates, poorly distributed IT companies across Indonesia (they all flock in central Jakarta), and bad traffic.  So the rhetoric is why would anyone want to pursue this kind of career in Indonesia at all.

Here's some loose calculation.  With perhaps up to 10 years of experience, one might land a decent position in the management--one out of, what, 50 people?  Suppose one is a highly accomplished senior programmer then.  The standard salary, I think, for a senior programmer here is currently at maximum 15 million rupiahs with a standard threshold of 30% and few lucky ones reaching over 25 million rupiahs.  The question is how long will it take from the moment one starts receiving salary decent enough to save up (10 million say, at age 27) until he owns himself a decent house.  Consider one is lucky and steady, with 30% of salary to save, standard 10% annual increase (loosely considering inflation and GDP trend), for a house worth 600 million rupiahs it will take about 11 years until you can finally own it--which is doubtful because once you reach age 30 you become much less marketable in the programming field (in Jakarta).

It's the fault of frameworks I'd say.  There are so many frameworks to build your application upon that enable companies to only hire average fresh graduates and have it up and running.  Hardly any companies need you to be a guru at it.  Hardly any companies nowadays (in Indonesia) will require you to be adept with lexical analysis, Z notation, serialization mechanisms, or even kernel scheduling. Chances are along the way in the future more and more experts will find it very hard to land a job befitting their expertise.

So I would instead say, "I expect to leave--have someone to remind me to leave even, to leave the company the moment I save up enough to start my own business."

Resources Publishing for WTP Maven Projects

I never realised this before but apparently these Eclipse Builders work really well to avoid collision between each other.
It was nightmare having to 'clean package jboss-as:deploy' the entire EAR again and again even when change was only on the xhtml--no recompiling!
The EAR project retains its skeleton structure even without the Maven EAR plugin (which is to be expected really, duh).  Which means you can deploy, undeploy, and redeploy part or all of the EAR into your web container via the usual Add or Remove menu.  What a pleasure!

Lift as Eclipse WTP Project

Some of us--we've never used Maven, let alone SBT.  We're used to Eclipse's default build, test, deploy, and reload features. Why limit the choices to starting up a Lift web project by requiring knowledge of either.  So here goes it:

1. Make sure you have Eclipse with WTP (comes with the default Java EE package), Scala IDE, and IvyDE installed.  You can opt not to use IvyDE for library management by adding jars manually.  For that you can go to MvnRepository to see the required dependencies.  A basic Lift project usually relies on either lift-mapper or lift-jpa as a single parent dependency.
   One thing to note here is this issue where Scala compiler generates version-specific byte-code.  This generally means that if you use Scala 2.9.1, you have to compile your project against a version of Lift that's compiled against Scala 2.9.1 and all the Lift dependencies must also be compiled against that version of Scala.  Lift packages come with their version as their name's suffix, thus if you use Scala 2.9.1 you would pick lift-mapper_2.9.1 as the basis of your dependency resolution.
2. In the IDE create a new Dynamic Web Project.
   Because Lift works with any servlet container that implements the Servlet 2.5 specs, chances are your favourite container will work just fine too.  Personally I would recommend using the latest release of JBoss AS.  It's quite as blazing fast as advertised and perhaps you might want to use some bleeding edge Java EE specs like JPA, CMT, and EJB to help with your software architecture.
3. To add Scala nature, open file .project and do the following changes:
1. Add a buildCommand with name org.scala-ide.sdt.core.scalabuilder.
   
2. Add a nature with value org.scala-ide.sdt.core.scalanature.
   
4. In project→Properties→Java Build Path, add Scala libraries.  Also add it to project→Properties→Deployment Assembly.
5. Add Lift packages and their dependencies, although...
6. If you have IvyDE installed:
1. You can skip this if the default ibiblio Maven repository works ok for you.  It's most of the time really slow for me so I tend to use Antelink's instead.  To do this, create a file named ivysettings.xml (could be anywhere in your project) containing:
   <ivysettings>
      <settings defaultResolver='antelink'/>
      <resolvers>      <ibiblio name="antelink" root="http://maven.antelink.com/content/repositories/central/" m2compatible="true"/>
      </resolvers>
   </ivysettings>
2. Create an Ivy file using the wizard and add this:
   <dependencies>
      <dependency org="net.liftweb" name="lift-jpa_2.9.1" rev="2.4">
         <exclude org="org.scala-lang" matcher="glob" name="scala*" />
      </dependency>
   </dependencies>
3. In project→properties→Java Build Path→Libraries click Add Library and select IvyDE Managed Dependencies.  Set the Ivy File, check Enable project specific settings, and set the Ivy settings path.  Also add this Ivy dependency to project→Properties→Deployment Assembly.  When you're done, Ivy will probably take a while to resolve your dependencies.  You can see its progress by displaying the Ivy Console.
   
   
7. A Lift web project generally has this kind of folder structure:
   src
   |_main
     |_resources
     |_scala
     |_webapp
       |_images
       |_static
       |_templates-hidden
       |_WEB-INF|_test
     |_scala
   To do this, you will need to remove the default WebContent directory and move everything inside it into src/main/webapp.  You will also need to, in project→Properties→Java Build Path→Source, edit accordingly to point to src/main/resources as well as src/main/scala.
8. Inside src/main/webapp/WEB-INF you need a web.xml.  This is usually generated automatically upon project creation.  Add a filter with name LiftFilter and class net.liftweb.http.LiftFilter and a filter-mapping with name LiftFilter and url-pattern /*.  You can change the name and url-pattern according to your needs.
9. The LiftFilter by default looks for a class named Boot inside the package bootstrap.liftweb (src/main/scala/bootstrap/liftweb/Boot.scala) and executes the boot method (def boot() {...}).
   But you can also have this class anywhere else in your classpath.  To do that your Boot class needs to extend net.liftweb.http.Bootable and add the following entry in your web.xml's LiftFilter:
   <init-param>
     <param-name>bootloader</param-name>
     <param-value>path.to.your.Boot</param-value>
   </init-param>
10. Setting up logging.
1. I have only ever used Logback so this is the logging backend that we'll use here.  I would advise against using IvyDE to manage your Logback dependency because by default Logback depends on a lot of other libraries that you might not even use in your Lift web project (such as Groovy).  You can instead manually download Logback and add logback-access, logback-core, and logback-classic to your build path.
2. Now you want to setup your Lift's default logging back end.  First add a logback.xml in src/main/resources.  Logback configuration doesn't have a schema so don't bother looking.  Do open this link for an example of the most basic Logback configuration.  Next open your Boot class and add the following inside the boot method:
   LiftRules.getResource("/logback.xml") match {
     case Full(url) => Logger.setup = Full(Logback.withFile(url)); case _ => println("Logback configuration not found.")
   }
11. Next you can continue by setting up class resolution and site map and creating your first page by utilising templates and binding.  A Lift tutorial book I would totally recommend is Lift in Action by Timothy Perrett.
12. Lastly you can build, test, and deploy your web application the way you normally do it in Eclipse.  Managing and configuring your web server and deployment are probably much easier using their default Eclipse adapter plugin compared to using Maven.