noisyheads Development Blog

I've decided to make the development of my pet project noisyheads public. I created a blog for that and while the main application is still not available, made the noisyheads.com domain point to it first. Expect to see a lot of Groovy/Grails related stuff there.

Creating an Independent Music Site

I've been formulating a music site for independent musicians for exposure and distribution. I know the space is crowded with the likes of Magnatune and Amie Street. I guess what would hopefully differentiate my idea is my so-called secret sauce I've been incubating.

Of course being a developer through and through, it would be a joy to create and explore this whole undertaking. As of the moment, current recipe looks like this:

Main Web Framework
- Grails (but of course)

UI
- leaning towards GWT

Streaming Music Format
- XSPF

Streaming Music Media
- either xmlmp3player or musicplayer

Authentication/Account Handling
- considering exclusive use of OpenID via OpenID4Java

Social Networking Feature
- would support OpenSocial probably via Shindig

Hosting
- Amazon Web Services

Payment Service
- PayPal perhaps, unless Google Checkout starts serving the Philippines

Hope I find the time to start working on it. :)

NullObjects with Groovy

I remember some while back when we have a heated discussion about Null Objects in the office. One argument was that there are times you would write more lines of code just to create a default object whose methods only throw an UnsupportedOperationException For example:

public class NullDAO implements SomeDAO
{
    public Something retrieveSomethingById(int id)
    {
         throw new UnsupportedOperationException 
      ("You did not specify a valid SomeDAO");
    }

    public void saveSomething(Something something)
    {
        throw new UnsupportedOperationException
             ("You did not specify a valid SomeDAO");
    }
}

Or probably implement something more meaningful but nonetheless does the same thing for all methods.

The argument won't be effective anymore though as far as Groovy is concerned. In Groovy, interfaces can be implemented via Closures and Maps. For the example above, the long class could instead be written as:

Closure nullSomethingDAO = { Object[] args ->
  throw new UnsupportedOperationException
  ("You did not specify a valid SomeDAO")
   }

Then could be used using the "as" keyword:

daoUser.setSomethingDAO( nullSomethingDAO as SomeDAO)

As you can see, the null object is now a one liner.

For cases you want your methods to vary, you could use Closures in combination with Maps:

Map nullSomethingDAO = [
     retrieveSomethingById : {int id -> doSomething},
     saveSomething : {Something something -> doSomethingElse}
   ]

And inject the same way mentioned above.

Groovy Accelerated Learning Technique

I always waste at least 2 hours of my life driving through traffic everyday. So I decided to attempt to be productive. I tried searching for worthwhile stuff to listen to while stuck in my car and chanced upon an old audio book by Brian Tracy and Colin Rose entitled Accelerated Learning Techniques. I gave it a shot, got myself a copy, loaded it to my iPod and listened away. Much of the stuff made a lot of sense. The bottom line is you have to have a system of learning that works for you. Although I've listened to it twice now since last year, I realized I never really applied what I've learned strictly.

Meanwhile, I've always incubated the idea of adding another programming language in my toolbox within the next few months. Being a Java programmer, the obvious choice is a programming language that works in the JVM. After a lot of struggle, I've finally chosen Groovy to be it, against runner up (J)Ruby.

So, finally, I could test the new learning system I've learned. The Goal: To learn Groovy in the shortest amount of time. The Way: Accelerated Learning Techniques as understood by me, while stuck in traffic. The audio book outlines 6 steps. I would write down these steps and how I could apply them in my quest for learning Groovy via this technique.

The Steps:

1. Be in the right state of mind - Before you can learn, you must be in the right state of mind. You must have the confidence and the motivation to learn before even attempting. Well, I learned Java, C, etc without much hassle. I don't see learning Groovy any different, except for the way I will be attempting to learn it now. Second, what's in it for me? A dynamic language in my arsenal, more programming paradigms to play with, promising frameworks around the language, bragging rights. Yup I'm pretty motivated :p
2. Get the facts - You must get the facts in a variety of ways that suits you. You could get information through any of your five senses. You must be comfortable with the materials you've chosen and are ready to break them into chunks while in the process. Now this one's tricky. The technique is to find a way to get the facts in different ways. Visually, I'm eyeing this book. I'll better stick with this first so I won't get distracted with more than one source. I don't need to read it cover to cover. Just directly to the facts I feel I need to learn, and motivated to read through. Auditory-wise, I really don't have anyone who already knows Groovy to discuss it with me. Kinesthetics - hmmm, I guess doing practice programs is considered as that. I just have to remember to break the topics in meaningful little pieces.
   
3. Explore the facts -You must look at the facts at various angles, different circumstances, other point of views. Also, relate the new facts to what you already know and see the connection. Finally, ask questions! Easily, I could compare Groovy with Java, syntax-wise. The other paradigms used in Groovy I could compare with OOP. I could explore the solutions I've made in the past and this time implement them using Groovy.
   
4. Memorize key ideas - You don't need to memorize everything. Stick to the key ideas. I definitely should memorize key APIs and syntax basics. Need to list them down while on step no. 2.
   
5. Show you know - Check how much you've learned by showing it to yourself and others. Teach someone. Discuss with another person with different ideas. Well, I could always blog about what I will eventually learn. I have friends who would want to learn the language as well. I could give some presentations in community gatherings or in the office.
6. Review and Reflect on the process - After every learning course, reflect on how effective it is and things to improve on. After this, we'll see how effective this stuff is ;)

Wish me luck!

Earning Money with Open Source Software

With all the news about the decision of Sun to acquire open source icon MySQL, this reminded me of that particular thread in Slashdot regarding earning money with OSS. Before anything else, US$1Billion is definitely earning money (though still far from 8.5B ). Kudos to the MySQL team, more validation for FOSS being legit.

Aside from the typical support subscription, dual licensing, and other conventional direct business models for FOSS, there are also a lot of ways to earn from it indirectly. Off the top of my head, here are a few I can think of:

1. Open source software usually happens because people just need to "scratch their own itch." For companies and organizations, these itches may be quite different from the current scratchers. Now, reinventing the wheel would be a lot effort (and of course money). In lieu of that, you could always fork an existing open source project to fit your own philosophy, just so long as the license of course would grant you to allow that component to co-exist harmoniously with your proprietary offering. Earning in this case by saving.
2. An organization may open source core but general components of their product without necessarily releasing their specialized offerings to the public. For example, you may have a set of Javascript libraries that is not too specific for your product but not too general that it does not fit into a niche. Being general would give you enough shield not to divulge much of your secret sauce, but specific enough to target a cohesive set of problems which would give it more sense. Think GWT and how little knowledge the public has of the implementation of GMail. So if your open source components gets enough mileage and community support, the stability of the component would definitely enhance your product and, indirectly, your earning power.
3. You may need special tools to address your needs that aren't available yet (or those available aren't sufficient). You could spearhead an open source effort for this. If successful, this tool would hopefully make you more productive, hence more earning potential.
4. Finally, open sourcing parts or your whole product showcases your brilliance as a developer/development organization. The sheer reputation itself could be a great money making tool. Just make sure you do show brilliant codes and design. Quoting Law 5 of The 48 Laws of Power by Robert Greene: "Through reputation alone you can intimidate and win." This guy would've never been taken seriously, trying to slay a giant, if not for his reputation.
   

Problem Driven Exploration

Who could resist the charm of shiny new toys? The least is a few seconds distraction. At best, we just couldn't get them off our minds, we just can't not reach out and touch them. I guess that inner kid in all of us just would never go away. Always the explorer of new things. And guess what, this could be a good thing.

20-something Java developers like me are easily intrigued by the newer and the not so new toys the past months brought like RoR, scripting languages on the VM, REST, etc. Of course with the intrigue and the curiosity, comes time and effort investment. The curious "kids" invest in the hype, well at least speaking for myself. But how productive are these exploration activities? Would a Java developer be better off concentrating instead and improving his handles on the "toys" already in his command?

Point is, exploration has the potential for innovation. But, blind exploration would more or less rest that amount of potential on luck. And unsuccessful effort is tiring and wasteful. What we want is to lessen our dependency on luck and drive this inner yearning to a direction that would make us successful.

This brings me to one possible solution to this: limit exploration to possible solutions of pre-determined problems. Problem driven exploration, as I would like to call it. Simply, look for answers, not questions for those answers. Tools solve problems. It's really not very helpful if you have a tool but have no problem. And problems differ from one person or organization to another. If you have no personal problems with your Java MVC framework, then why bother with RoR? But, if XML is becoming a hassle for your specific situation, then time to explore on stuff like YAML and DSL's perhaps.

In this light, I guess it's very important how an individual or organization keeps their list of problems specific to their situation (last four words very important). For organizations in particular, I guess they would be doing themselves a favor if they are pretty transparent with their pin-pointed difficulties to their developers. Who knows, some kid in a tiny department might have all the zest to explore a solution for them?

Never let the inner kid in you grow old and boring. But take advantage by strategic control of that phenomenal behavior.

Merry Christmas, World!

Using the unofficial Google translator API, here's a Merry Christmas greeting to everyone around the world! (or at least whose language are supported by the translator) :)

import java.lang.reflect.Field;

import com.google.api.translate.Language;
import com.google.api.translate.Translate;

public class MerryXmasWorld
{
public static void main( String[] args )
{
Field[] fields = Language.class.getFields();

for ( Field field : fields )
{
String lang = null;

try
{
lang = (String) field.get( null );

if ( lang.equals( Language.ENGLISH ) )
{
continue;
}

String translatedGreeting = Translate.translate( "Merry Christmas, World!", Language.ENGLISH, lang );

System.out.println( translatedGreeting );
}
catch ( Exception e )
{
System.err.println( "Cannot translate to " + lang );
}

}
}
}