Why I love ABQ...

Albuquerque is just too cool... balloon-wise... This was taken at my daughter's day-before-balloon fiesta kick-off at her grade school next to the Rio Grande.

Gravity explained as a leak from another dimension

Gravity according to Lisa Randall -- Somebody's Leaking...

Lisa explains gravity with an angle on why the heck is gravity able to keep us inhabiting the planet, yet we can out-wrestle the Earth's pull in a tug of war using a magnet on a pin.

If you are familiar with the latest theory of everything using string theory as the context, then you may know that there are 11 theorized dimensions (10 physical, 1 time).

Where Lisa stirs the pot starts here: Imagine that maybe our four dimensional universe actually lacks gravity as a force. To be more specific, she has theorized that the force of gravity is actually just as strong as the other forces (weak, strong, electrical, nuclear) within the 11th dimension... and this 11th dimensional gravitational force is actually leaking into our 4th dimensional universe to the degree that it (as described by Einstein) supports our galaxies and solar systems. Somehow this explains how it can be so weak and have such a fundamental impact on who we are and why planets keep us tucked in our beds at night.

Wow.

-- Got this from watching "Parallel Universe" on the Science Channel, Sunday evening, 29 June 2009

Riding across the Rio Grande

Existence comes to me.

Read at your own risk: I wrote the following from an experience I had riding across the Rio Grande Bridge on Montano in Albuquerque.

The "Material" throws me. Throws everybody.

Time throws me. How can you take a concept like eternity seriously?

Existence comes together with that singularity of creation called the Big Bang. ...when something wasn't, and then it is.

It has nothing to do with reality because reality, like time, is our perception. It's more like the seed of a nightly dream. The lifetime of that dream is the lifetime of the universe as a collection of physics that is only defined as told in the dream.

Too dreamy?

Well, look on the other "side" of that singularity. There are no physics. Or no One physics. There is only dream potential where walls are not defined. Limits are not defined. No carbon. No gold. No nothing. Only, maybe, the one thing we can speculate that exists is Energy?

There, there is no time. There is only eternity. Eternity, the word that ironically requires the concept of time in order to have relevance. If there is no time, then there is no need for the concept of eternity for there is no yang to its yin.

Now you can picture the other side of the sunrise called the singularity. Infinite possibilities. No need for questions about how old is anything. Or when will time end? It's relevant only to our existence called the Universe. It's like asking how long are we staying at Aunt Dorothy's house? Then it's irrelevant once we leave.

So if you ever felt like you're living a dream... you are. And you'll probably be around again to live it again because infinite possibility does imply you get more than one shot.

Playdough Programming

Revelations about new Web development technologies are getting to be a regular thing. The natural energies and consequences of open source projects and the rapid fire innovations they spawn (prototypejs.org) or legitimize (Ajax and the back-channel feature of modern browsers), life for software development bears little resemblance to disk drive-grinding Pascal compilers of the not-so-distant past.

The newest revelation for me is what I'm characterizing as "playdough programming." For someone who, as a boy, couldn't wait to paint my car models before the glue had dried, a language like Groovy has changed the way I tackle new programming tasks. 1. Get it going (i.e., start some tactical coding), 2. validate concepts and strategies early, and 3. then begin refining your project into something that gets early feedback. And because it's still basically a Java app, (modestly) refactor it into compilable code (if you think it's a necessity) and leave the rest to the Groovy components as library elements that can natively interact with Java code.

A quick example. In my job I wanted to know about patterns in collections of files in various directories. So I quickly wrote the following:

def grabDataFromFiles(directory) {
   def listOfFiles = []
   new File(directory).eachFile { f ->
        listOfFiles.add(f)
   }
   return listOfFiles
}

Pretty terse, eh?

listOfFiles

is an ordered list of file names. And

def

not only declares the function, it also returns the type "linked list" because Groovy uses duck typing, which you can choose to leverage or you could just go with the more formal Java declaration

List grabDataFromFiles(directory) { ...

Keeping this to one page, let me list some of the things I enjoy and value about Groovy.

1. Greatly lowers barrier to generating basic functionality
2. Code is testable from the start.
3. Easier to get there with constructs like : ${'A'..'Z'}.each {}
4. 100% compat with Java (Java to Groovy, but not other way around)
5. Great for newbies

My most pleasant surprise, besides the pure joy of using and exploring Groovy, is the amount of code re-use I'm practicing. You just feel much more like _not_ rewriting existing functionality -- probably because it's so easy to locate and modestly rework where differences demand.

So far I haven't mentioned closures. In a future blog entry, I'll explain the other 90% of why I'm smitten with Groovy. And yes, insert "Ruby" here if you like. Same value. Same new world.

The (Applied) Downside of Hibernate

Don't get me wrong. I love Hibernate. I use it for Java as well as Grails development (using the supporting GORM library).

But there is one thing I've observed -- it tends to insulate developers from the actual data and what's really going on under the covers.

Perhaps this is not a problem for traditional Web applications, such as community sites and such. But for a data-driven application with lots of proprietary content it's often necessary to explore new angles on data mining. Often, you need to walk your way through the data before you know the angle you want to take. That means writing ad hoc SQL queries and mixing and matching to see what you can produce for a new business perspective.

The problem is that developers get so used to the Hibernate representation of data and data relationships, they have no idea where to go to diagnose data problems in the underlying SQL schema. Unless you've super generalized your view of data through Hibernate, it's kind of tough getting past the Matrix (the Movie) effect... where it's rather shocking to look at the underlying schema if all you've done is view content through the Hibernate model.

On Being a Web Application Developer - Get outside of that IDE!

You're looking for a job. You're considering a company that has a web-hosted service or application. Basically, they have servers running Linux or Unix and the application you'd be (using Ruby, Java, PHP...) to work on is hosted on those servers. You know how to build a Web application. At least the presentation and business layers. And, now that you've got a family(!), you want to knock your potential employer's socks off once you get there. Here's my advice. Use your Eclipse knowledge, but please, move outside of Eclipse and research and spend significant time learning what it takes to actually deploy and run that Web application!

Why? Because while your colleagues sit there, staring at their Eclipse window, spinning on a nasty bug that's steadily becoming the show-stopper it's likely to become, and mutter, "Geez, I've looked at everything I can," you can show them how you sadly dependent they are on desktop tools and do the following. Use ssh to log into your server and ...

• Use your knowledge of the vi editor (because we're talking Linux) to view key resources and search for possible issues. Other tools you've learned to take advantage of including df (to make sure there's sufficient file system space and that an NFS mount hasn't been lost) and find to locate files created in the past couple of days that that are larger or smaller than usual).
• Read the logger.xml file in your application's configuration directory to locate the application log files that are likely to have a stacktrace and source code file and line# that you can then use back in Eclipse, or, just as likely,
• Use the log file's stacktrace to locate the resource that that has been corrupted and is no longer readable.

It's not that it's really something you couldn't do with Eclipse. You could have. But maybe because you're used to using the find command and because you're used to it, you've learned many of its amazing attributes and, more importantly, you've learned more about how your application is layed out on the server and the run-time environment (scripts, file systems, cron tasks, etc.) that are required to deploy, test and support it.

So why is this an advantage to you and why would it wow anybody, espeically your boss? While your colleagues sit there and spin on issues they're dealing with in Eclipse, you...

• know how to find resources that are tripping up the application, such as an unreadable XML file on the file system, and you
• know how to use find to find files (out of hundreds of thousands) that are newer than 3 days old (when the problem start) and you know how to limit the search to two directories of depth, not the 5 levels of directories that would take your query forever to search. But most importantly,
• you are comfortable with the operating environment of the bread-winning application of your company and when stuff happens, you are a go-to person because people know you can magically, calmly weed your way through the areas of the server and find the source of trouble (e.g., badly formatted XML document, mysteriously restrictive file permission, missing file, improperly updated configuration and, gee, a missing NFS file mount (because you simply knew to type "df -f").

I was going to call this entry "On Being a Web Application Developer - No Microsoft Certifications please," but I didn't want visitors to think this entry is a political statement. It's really a suggestion that you need to consider making yourself more impervious to getting your job off-shored. Step 1 is "get out of your IDE and learn about what it takes to actually deploy, run and maintain your application (even if you only own a small part of it), because

1. Increase your breadth of knowledge of the application you're responsible for. If you're the GUI guy, find ways to learn about the data layer, the integration layer, where business rules are kept.
2. Get comfortable with the server environment. Learn how to navigate around so you're no longer paranoid about moving around the server. When you no longer regard the server folks as "priests", you've accomplished this task.
3. Most importantly, especially as it relates to doing what you can to keep your position from getting off-shored, understand the business you're in. The more you internalize your company's domain knowledge and how the web application supports that domain, the more indispensable you become. Start with having lunch with a sales person, the product manager and ask them about who the customer is, why do they buy the service,

How do you know if this applies to you? Ask yourself, "do I really feel comfortable looking for things in a Linux terminal window?" If the answer is yes, then you can skip to #3 above. If not, start learning.

With all of this said, the best outcome of all is that you're in a much better position to have more fun, and when the time comes, have many more choices when it comes to future employment options, including self-employment.