Into the Aquaria Rabbit Hole

I have been intrigued by aquaria (plural of aquarium) for a while, and more specifically, really interested in the last year.

When I was an adolescent, my step-father had a freshwater fish tank with tetras, and I thought they were interesting enough, but only mildly so. Perhaps because of their tiny size of a couple of inches long and mediocre colors, I didn’t feel like they were captivating enough to warrant my time.

In a passing comment, I think I asked my parents, “Hey, why not get a saltwater tank! Those seem more interesting!” But my parents dismissed it rather quickly, and perhaps because I wasn’t interested enough in the tank we did have, I didn’t really press further. I instead focused on girls, which were way more fun at that time anyway.

Fast forward 20 years later. Last year, I discovered that a co-worker had some decent experience with saltwater aquaria and had educated himself on the topic rather well. In casual conversation, my curiosity resurrected and I started asking a lot of questions and learning quite a bit – enough to whet my appetite to start looking into the hobby more seriously this time around.

After only minimal research, I quickly realized that, given my age back then, there is simply no way I had the maturity or patience to be able to keep a saltwater tank alive. Saltwater tanks, if you don’t give them the time and attention they deserve, are difficult to maintain. Really difficult. And, as any experienced saltwater aquarist will tell you, they will inevitably become a money sink if you’re not cautious. Definitely not a hobby for a free-willed teenager with a part-time minimum wage job!

But I’ve learned recently that saltwater tanks can be an amazing hobby, and well worth the effort, especially if you enjoy any of the scientific or engineering disciplines. I don’t think I’ve found any hobby that more completely exposes the practitioner to science and engineering in a more fulfilling way. Saltwater aquarists learn more than a cursory amount of at least the following disciplines:

  • Physics: fluid dynamics, pressure, optics, gravity, electromagnetism, and more.
  • Engineering: pump mechanics, flow/pipe construction and building, overflow design, fault-tolerance, lighting design, environmental control systems and systems automation.
  • Construction: if you enjoy DIY, you can make your own tank, the stand it rests on, bracing and sub-systems used to keep the tank alive. If you’re a woodworker, you’ll have a big advantage here.
  • Chemistry: an applied knowledge of the Nitrogen Cycle, reverse osmosis and de-ionization, and knowing how to test for and control calcium, phosphate, magnesium, strontium, iodine, carbon, salinity control, and more.
  • Biology: this one is obvious, but it goes well beyond fish. Aquarists can gain deep understanding of corals, crustaceans, algae, bacteria and parasites, and more. Many aquarists can spout off Latin names and genus classifications like nothing.
  • Ecology: understanding environmental balance, both within a tank, and how it helps you understand the real world (and what we humans do to it) in a way that most people will never be able to understand (other than scientists actually employed to do so).
  • Design: a fun part of saltwater aquaria is aquascaping, where you can design beautiful in-tank landscapes with rock, corals and zoantharia (see? biology!) that can help relax and calm anyone.

Think about this for a second. If you like the Discovery Channel or National Geographic or the Science Channel, you might find saltwater aquaria far more enjoyable and rewarding than the shows on those channels. And let’s face it, Discovery Networks should just be ashamed at the completely false “scientific” crap they spew on some of their shows (Pawn Stars on the History Channel? Is that how low we have become as a nation? Anyway, I digress…). Have a saltwater aquarium, and you’ll be rewarded with first-hand knowledge with real scientific experience. You’ll probably now more than Discovery Networks’ producers anyway.

Anyway, I have been researching how to start my own saltwater aquarium for almost an entire year, without so much as buying a single piece of equipment. If you’re thinking of becoming an aquarist, don’t let this discourage you however; I’m just a little too OCD when it comes to trying anything complicated of which I have little initial knowledge. It is just my personality to want to become relatively knowledgeable in something before I invest real money into a potentially challenging venture. Plus, I just like the process of learning a lot, so the research is probably as fun to me as actually building something. I also like reading as much as I can to ensure that I don’t make silly mistakes, and I benefit a lot from reading from others’ mistakes so I can (hopefully) not repeat them.

That being said, most people start in the hobby with far less preparation, and most are just fine, especially with online help from the ReefCentral Forums (I’m kendoka there – say hi!).

So, as you can see, with so much to learn, saltwater aquaria can be a definite rabbit hole, but for me, and I assume many like me, this is actually part of the appeal of the hobby.

Learning and then applying knowledge to create something truly beautiful and personally rewarding sounds like something right up my alley. I jumped down the rabbit hole last year, and I’m enjoying the journey so far!

Eat to Live, Day 1

Today is my first day that I’m really, actually making a legitimate effort to eat healthier and exercise on a regular basis.

However, the anti-health gods were out to make my first day a living hell: I lost my keys when I arrived at work (that’s what happens when you have only 5 hours of sleep and your routine has been messed up due to traveling for 2 weeks).

So instead of spending my lunch hour making healthy food, I had to spend a full hour looking for the keys, contacting the police to see if someone turned them in to lost and found (there is a local small police station connected to the parking deck), and finally found them at a local locksmith near the garage, turned in by some wonderfully thoughtful person on their way to work in the morning (THANK YOU!).

After that was over, I finally went shopping for an hour and spent $205.00 on a ton of fruits and veggies and lean meats.  I didn’t get back to work until much later than I wanted, but hey – my health is pretty darn important, and I WILL NOT be defeated on my first day.

Anyway, tonight is Taco Salad night!

The recipe is an uber low carb version – basically my friend Allan’s recipe: taco-seasoned beef and turkey on top of a ton of shredded lettuce (and maybe I’ll shred a bit of cabbage too), with lots of an interpretation of pebre (a Chilean home-made concoction of lemon juice, olive oil, tomatoes, onions, cilantro, coriander and salt).  I bought some Fage 2% yogurt as a low cal substitute for sour cream.  I’ve done this before on Mexican food and it tastes great!  No cheese, but that’s ok – the Fage satisfies that craving for me.

I also bought some nice light olive oil and eggs: I’m going to try making homemade mayonnaise in my beloved Breville food processor :)

Day 1, could have been better, but I won’t be defeated!

Upgrading from Groovy 1.7.x to 1.8.x: MissingPropertyException: No such property: for class:

Just jotting this down for anyone that might encounter this problem.

Apparently Groovy 1.8 introduced a backwards-incompatible language syntax change. It cropped up for me while I was attempting to compile existing Groovy unit tests (written against Groovy 1.7.x) that use EasyMock. I’ll show an example next – just note that that what I experienced was due to a Groovy syntax issue and not specific to EasyMock.

In a test case, I had a bit of code that looked like this:

expect(mock.someMethod(...)).andAnswer new IAnswer<Whatever>() {
    //bunch of stuff left out for brevity
}

Notice how the method argument to the anAnswer method is an anonymous inner class that spans multiple lines. Also notice that I didn’t wrap the argument in parenthesis as they are usually optional in Groovy. That is, instead of doing this:

someMethod.doSomething( anArg )

I usually do this:

someMethod.doSomething anArg

I find it to be more readable and less to type.

This worked fine with an anonymous inner class that spanned multiple lines in Groovy 1.7. This will not work in Groovy 1.8.x. When upgrading to Groovy 1.8.0 that same exact code threw an exception:

groovy.lang.MissingPropertyException: No such property: andAnswer for class: org.easymock.internal.MocksControl

Not nice. The ‘no such property’ error was a little misleading, but helpful – it told me Groovy thought andAnswer was a property – not a method. So, I decided to throw some parenthesis in there to indicate that it was in fact a method. The code then became:

expect(mock.someMethod(...)).andAnswer( new IAnswer<Whatever>() {
    //bunch of stuff left out for brevity
})

Notice the new opening parenthesis after andAnswer and the closing one after the anonymous inner class’s final } bracket. A very subtle difference!

After doing this, all of my test code compiled again. I hope this helps anyone with a similar problem!

Google Chrome Funny Language Detection

I thought this was rather amusing. When viewing a web server directory listing (in this case, the Maven Central repository), Chrome thought it was Italian. Seems like their language detection stuff isn’t quite fully fleshed out yet:

To be fair, it’s just a directory listing, and I bet my request was served from M2 Central’s European mirror which probably resides partly in Italy. This is strange though, since I’m in Silicon Valley, California – you’d think that the mirror routing algorithm is smarter than that!

A Moral Dilemma

I’d like your thoughts on a moral dilemma I encountered last night in San Francisco. Here’s the story:

On my way in to an In-n-Out Burger to grab a quick bite, there was a homeless guy in his mid-twenties sitting in front of the door with his scrawny-but-cute dog. He asked, “Could you please spare some food when you come out?”.

Now, San Francisco is known for having one of the worst homeless problems in the nation. But the homeless’ public benefits here are good compared to the rest of the nation (health care, shelters, etc). Many argue that the homeless situation is so bad because most homeless receive benefits well enough such that they don’t have an incentive to try and remedy their situation. That is, it’s just easy enough to be homeless, that they don’t try to be otherwise.

So:

  1. Do you give the guy some food on the way out (or some money) because it is the holiday season after all, you’re a Christian, and you genuinely want to help people in times of need?
  2. Or do you ignore the request because if you succumb, you’re only ‘enabling’ that person, plus you make it uncomfortable for future restaurant guests because the homeless person might be encouraged to stay there and try again later.

What do you do? Why?

OSGi, Maven, Pax, and web applications

This post is written for developers that are trying to deploy a .war file inside of an OSGi runtime environment.  I experienced a lot of pain along the way to making my solution work, so hopefully this will alleviate any pain that you might have.

The Scenario

This post primarily reflects the environment in which I am writing and deploying my application.  Here are the key points that led me up to my course of action:

  • I use Maven to manage my project.
  • I already had an existing web application .war that had no ‘knowledge’ of OSGi.
  • I knew I would need to ‘OSGi-ify’ the .war and turn it into a bundle, since this is required by the OSGi 4.2 Enterprise specification
  • Once I had the new OSGi-compatible .war, I would need to quickly and easily start it up in an OSGi environment to test it.

The Setup

Based on my above environment/needs, I decided on the following:

  • Because I use maven and I have created plain (non-web) OSGi bundles with the Maven Bundle Plugin in the past, it would make sense for me to use it again to make my .war into a bundle.
  • Again, because I use maven, I want to launch my ‘OSGi-ified’ .war in an OSGi environment directly from maven.  I didn’t want to do anything painful like manually copy and install the .war into an OSGi container installed elsewhere.  That would be a pain that would frustrate me and infringe on my productivity.The Maven Pax Plugin looked like it could easily start an OSGi runtime (Felix, Equinox, etc)  as well as provide the additional web support that is required to launch .war files.  So, I decided to give that a go.

The Solution

Step 1: Make your .war OSGi-compatible

This was actually pretty easy, but there were two major problems I encountered along the way that caused me hours of suffering.  May my pain be your salvation! :)

Using the maven-bundle-plugin, you essentially tell it to create a MANIFEST.MF file with OSGi entries, and then you tell the maven-war-plugin to use that generated file.  All it takes is adding the following two plugins to your war project’s <plugins> section:

<plugin>
  <artifactId>maven-war-plugin</artifactId>
  <configuration>
    <archive>
      <manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
    </archive>
  </configuration>
</plugin>
<!--
    Enable support for non-bundle packaging types
    See: http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
-->
<plugin>
  <groupId>org.apache.felix</groupId>
  <artifactId>maven-bundle-plugin</artifactId>
  <extensions>true</extensions>
  <executions>
    <execution>
      <id>bundle-manifest</id>
      <phase>process-classes</phase>
      <goals>
        <goal>manifest</goal>
      </goals>
      <configuration>
        <instructions>
          <Bundle-SymbolicName>CHANGEME</Bundle-SymbolicName>
          <Export-Package/>
          <Import-Package>javax.servlet,javax.servlet.http,javax.servlet.*,javax.servlet.jsp.*,javax.servlet.jsp.jstl.*</Import-Package>
          <DynamicImport-Package>javax.*, org.xml.sax, org.xml.sax.*, org.w3c.*</DynamicImport-Package>
          <Bundle-ClassPath>.,WEB-INF/classes</Bundle-ClassPath>
          <Embed-Directory>WEB-INF/lib</Embed-Directory>
          <Embed-Dependency>*;scope=compile|runtime</Embed-Dependency>
          <Embed-Transitive>true</Embed-Transitive>
          <Web-ContextPath>CHANGEME</Web-ContextPath>
          <Webapp-Context>CHANGEME</Webapp-Context>
        </instructions>
      </configuration>
    </execution>
  </executions>
  <configuration>
    <supportedProjectTypes>
      <supportedProjectType>jar</supportedProjectType>
      <supportedProjectType>bundle</supportedProjectType>
      <supportedProjectType>war</supportedProjectType>
    </supportedProjectTypes>
    <instructions>
      <!-- ... etc ... -->
    </instructions>
  </configuration>
</plugin>

Just remember to set the values appropriate to your application, namely those for the <Bundle-SymbolicName> and <Web-ContextPath> and <Webapp-Context> entries (we’ll discuss the latter two shortly).

After you’ve added the plugins and changed the appropriate values, a normal maven build (e.g. mvn package or mvn install) will produce your OSGi-compatible .war!

But what you see is deceptively simple – there are two things that prevented me from deploying successfully for hours.  Make sure you avoid them:

Manifest Entries: <Web-ContextPath> or <Webapp-Context>?

Notice the two following lines in the maven-bundle-plugin‘s <instructions> element:

<Web-ContextPath>CHANGEME</Web-ContextPath>
<Webapp-Context>CHANGEME</Webapp-Context>

Doesn’t that look annoyingly repetitive to you?  Why do we need two?

Well, let’s cover what they are.  As you might have guessed by looking at either one individually, they specify the context path under which your web app will be accessible, for example http://localhost:8080/myContextPath.  If you don’t specify them, most OSGi web container implementations will default your context path to your .war’s Bundle-SymbolicName,  For example, servicing your webapp from http://localhost:8080/com.company.my.bundle.symbolicName.  That’s just plain ugly, so you really want to specify them to ensure your urls look sane.  But why are there two entries?

When I originally added the manifest entries, the only one I specified was the <Web-ContextPath> entry.  This is after all the correct Manifest entry as mandated by the OSGi 4.2 Web Applications Specification (Chapter 128 in the OSGi Compendium document).  I read the specification and added that entry accordingly.  All should work fine then, right?

Well, it would have if the Pax Web support used by the maven-pax-plugin used to launch the .war (covered below), was 100% OSGi 4.2 compliant.  It’s not.  I sat at my desk for hours, running various tests until 3:30 in the morning, swearing at myself that I couldn’t believe I was screwing things up, when all the documentation said it should be right!

Much to my early-morning chagrin, I discovered that the existing Pax Web support (0.7.2 at the time of this writing), does not yet understand the OSGi standard <Web-ContextPath> entry.  There is currently an outstanding Jira issue for them to fix this.  Until that is fixed, we’ll need to add both: the OSGi standard one to ensure it works in your standard OSGi deployment environment and the Pax Web-specific <Webapp-Context> one to make Pax happy while you’re testing with Maven.  When that Jira issue is fixed, you can remove it and keep the standard one.

But what if you don’t want to launch your .war using the maven-pax-plugin?  You can remove the non-standard entry, right?  

Well, not so fast – there are OSGi container distributions, such as Apache Karaf (which is the Felix OSGi runtime + a lot of nice enterprise features), that use the same exact Pax Web mechanism as their implementation to support .war deployments.  That means if you deploy your .war to Apache Karaf as your production environment, because Karaf uses the same Pax Web mechanisms, the non-standard <Webapp-Context> entry must still be specified.

Its safest to keep both entries and have them both reference a maven property that you can set once to avoid repeating yourself:

<properties>
    <web.contextPath>foo</web.contextPath>
    ...
</properties>

...
    <instructions>
        ...
        <Web-ContextPath>${web.contextPath}</Web-ContextPath> 
        <Webapp-Context>${web.contextPath}</Webapp-Context>
    </instructions>
...

web.xml: use a <welcome-file-list>

Now that we got the Manifest entries out of the way, there’s one final issue that caused me grief: welcome files.

My web app has an index.jsp file at the root of the war file.  It is incredibly simple – all it does is redirect the user to a nice ‘home’ landing page:

<%@ page session="false" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%-- Redirect to the home page --%>
<c:redirect url="/home/"/>

Trivial, right?

Well, my web.xml in my pre-OSGi .war did NOT have a <welcome-file-list> entry in it.  Tomcat and Jetty don’t care about this – they have a list of sensible defaults.  Because of that, I haven’t specified a welcome-file-list in years – I just didn’t think about it.

However, the  the OSGi war deployer mechanism I was using (Pax Web’s war extender) does require it.  It was not able to handle a request coming in to http://localhost:8080/myapp.  It didn’t know to automatically use the http://localhost:8080/myapp/index.jsp file.

This was equally as frustrating as the non-standard Manifest entry discussed above and further contributed to my hours-long “shoot me now, I hate OSGi” session – there were no error messages explaining why the request failed (terribly frustrating).  But I eventually figured it out by going through the arduous process of setting up an entirely separate ‘clean room’ .war project and trying different things from scratch.

I added the following XML snippet at the bottom of my web.xml file, and all was well again:

<web-app ...>
    ...
    <welcome-file-list>
        <welcome-file>index.jsp</welcome-file>
    </welcome-file-list>

</web-app>

Step 2: Launch your OSGi .war from Maven

Now that you have an OSGi-compatible .war, ideally you want to be able to launch it and test it immediately.  It would be a major pain to have to build your .war and manually copy it or install it into your OSGi deployment environment (e.g. Apache Karaf, Eclipse Virgo, Apache Geronimo, etc…).  We want instant gratification with no setup!!!

It’s the maven-pax-plugin to the rescue! (with the exception of the manifest entry and welcome-file-list complaints above)

Once you’ve completed both parts of step 1 above, the rest is smooth sailing.  Add the following plugin to your .war project’s <plugins> section:

<plugin>
    <groupId>org.ops4j</groupId>
    <artifactId>maven-pax-plugin</artifactId>
    <configuration>
        <provision>
            <param>--platform=felix</param>
            <param>--profiles=compendium,web,war</param>
        </provision>
    </configuration>
</plugin>

Notice that the first <param>, --platform=felix,  reflects my personal test environment.  You could specify --platform=equinox to use the Eclipse Equinox OSGi framework instead.  You could also specify other platforms as well.  See the maven-pax-plugin and Pax Runner documentation for more options.  You’ll naturally choose settings that will best reflect your production runtime environment.

The second <param> is what is important for testing .wars.  It specifies Pax Runner profiles that enable .wars to be deployed.  You can add other profiles as necessary, but those three are required for deploying .wars.

To run your web app, just execute the following:

mvn install pax:run

Super easy!

Success!

Once the two issues above were taken care of, and I could launch my new OSGi .war, it was accessible via http://localhost:8080/myapp and everything worked as expected.

But I hope this helps you, weary-eyed OSGi blog-searcher.  Good luck!

Born to Run

Because I finished reading Cryptonomicon a few days ago, I was looking for the next book I wanted to read on my Kindle. I downloaded some classics – Swiss Family Robinson, Treasure Island, Count of Monte Cristo – all of which cost me $0.00. But I wanted to read something current as well, so I browsed through the best-selling Kindle books and came across this one which had a very high user rating relative to many others:

So, I jumped on it – I was curious about the world of super-endurance and wondered if it would inspire me to one day check off “Run a Marathon” from my bucket list. I bought it and started reading.

I can’t put it down! I’m so fascinated by the Tarahumara tribe – a Mexican tribe, not African like I thought they might be at first glance. The author was a previous writer for Men’s Health and Running World magazine, and provides good backstory for the running-uninitiated like me. So far so great!

4.3 Hours of Streaming Flash Video on the Google Phone (Nexus One)

Here’s a great (but kinda long) video.

Short story – Apple (as we already knew) was full of shit when they said that Flash couldn’t be used on mobile devices, claiming that it would destroy battery life. But then again, if things were up to Apple, we’d all be stuck using QuickTime Video. *shudder*.

4.3 hours of streaming video over the web on only battery power is pretty damn good. The video was demonstrating the Flash 10.1 player, which is still in beta, but it looks like the performance improvements are a big success.

I still don’t think we’ll see flash on the iPhone in less than a year
- or maybe even 2 (if ever). Mr. Jobs, this is one area where you’re clearly wrong.

Java.net Maven Users Have Hope!

It is no stretch to say that Java.net’s Maven infrastructure (or lack thereof) is the worst I’ve encountered in a project hosting environment.

It looks like the boys from Sonatype are willing to help out on this front by offering Maven repository hosting on their own public Nexus instance for any Java.net project that wants it. That’s a big benefit to those projects – jump on it!

Read more about their rescue mission on March 5th, 2010.