Drawing a Blank

But... why ruby?

2009-11-11T13:09:00.000-08:00

"One Language A Year" - or at least that's what the Programmatic Programmer reckons one should do. I've spent the majority of this year doing non development work. For any coding work I have done, I've gone back to my workhorses of bash, java, and python. This effectively means that in the three years I've worked as a software engineer (or similar) I've remained a three-trick pony. Although with that said, if I decided to actually go learn C++, I would know the gamut of the predominant languages used within Google, so I'm not fairing too badly.

Still, learning a language teaches one new idioms, new ways of solving problems, and increasing the toolset available with which to solve problems. For those reasons I'm going to allow myself to pick up another language. However since there is only two months left in this year and I'm super busy with non development work, I'm not going to learn a full language and become somewhat familiar with its accompanying sets of frameworks, libraries, and APIs in two months. Instead, I'm going to take a minimalist approach and take a one day at a time shot at learning ruby. I'll be spending a single solitary hour on hacking ruby code each working day. Doing that from now until the end of the year should possibly teach me enough of the language to claim I know it on the surface and will let me know whether or not I want to continue with it in 2010.

But... why ruby?

Everyone who I know that has picked up ruby has only good things to say about the language and API. I'm not counting rails here... just ruby the language.
It looks more flexible than my current dynamic language of choice, python. For example, one sees tons of material about writing DSLs in ruby. For all of python's goodness, it doesn't feel like a good language to facilitate writing DSL's. I welcome any objections to that assertion, of course.
The ruby developer community where I live is strong. Hashrocket, a pretty well known ruby (on rails) shop is a 7 minute bike ride away. There's nothing better than sharing with and learning from a kick ass group of tightly knit developers.
I want something that isn't tied to JVM. I could have cheated with my selection and chosen something like Groovy or Scala, but I want something completely different. Scala is interesting and there are some neat functional idioms and concurrency support features intrinsic to the language that would be useful, but I'll save it until next year. For now I want to see what world is like outside of java land.

Of course, one needs a non-trivial project in order to pickup a language and its platform. I learned java pretty much by attempting to hack on the Netflix Prize as part of my Master's thesis. It's a fun problem and will probably allow me to flex a majority of ruby features in attempting to solve it again.

Day one was yesterday. I spent the first 25 minutes going through the Ruby in 20 Minutes tutorial (yeah... I'm slow) and the next 35 minutes starting to write a module/class to read in comma delimited files from the Netflix Prize dataset that identify a user id, rating, and timestamp for all ratings on a given movie.

In doing so, I managed to explore the following basics in Ruby

File I/O (or at least reading files)
The CSV module
Iteration
Attributes

My initial first thoughts?

irb is a pretty neat interpreter. I'm a huge fan of the interactive python interpreter (and even bigger fan of bpython). The only thing missing here is the ability to see rdoc from irb - probably due to the fact that rdoc isn't stored as a member of any modules or classes the way that docstrings are in python (and accessible via .__doc__)
Attributes are awesome way to remove boilerplate property code. It just reduces the noise of having tons of getX() and setX(Object x) implementations and calls to access the internal members of objects in Java.
Reading in a file in ruby was just as easy and straightforward in ruby as in python. That's always a joy.
The shorthand iteration of an enumeration threw me at first, but perhaps it's just a rubyism that will grow on me as I find out how to use it effectively.
```
file.each { |line| extract_rating_from_line } 
```
just didn't seem quickly intuitive the way that an equivalent list comprehension in python would
```
[extract_rating_from_line(line) for line in file.readlines()]
```
or perhaps I'm just too used to python at this point.

Hopefully after this evening I'll have at least a working module and some classes for parsing ratings from those text files and get to explore some things like exception handling.

iDon't Have Market Penetration

2009-11-08T17:33:00.000-08:00

iDon't have a real keyboard.
iDon't run simultaneous apps.
iDon't take 5-megapixel pictures.
iDon't customize.
iDon't run widgets.
iDon't allow open development.
iDon't take pictures in the ark.
iDon't have interchangeable batteries.

Too bad Verizon forgot to mention this other truth about the iPhone:

iDo have massive market penetration.

Last week Verizon released the Motorola Droid as its latest smartphone offering. Quite honestly, it is the first smart phone Verizon has supported that is mildly appealing. As a former Verizon customer, the lack of decent phones was my biggest complaint and ultimately led to my departure as a Verizon customer.

I really like Android though, from what I've seen of it at least. Had Verizon announced plans to support an Android phone around the beginning of this year, I would have stuck around. I love Verizon's network and service. But I needed a smart phone worth a darn to support me in my budding freelance career.

What did I switch to? Why of course, I switched to an iPhone.

Already being a Mac OSX user, I figured I put away any reservations I had about the iPhone and AT&T and just get an iPhone. I have not regretted it. I love everything about the phone basically. And mind you I'm not even running a jailbroken phone - I like the base user experience and apps in the app store as they are. AT&T has had great coverage here in Northeast Florida so I can't even complain about them yet either.

But that's now. In my honest estimation, I expect Android to really be an awesome platform now and later. I admittedly also have a soft spot for Verizon's service - they have had great coverage every where I've ever lived or visited in the continental United States. But I'm not switching now... Verizon was too late.

What would it take for me to switch? I'm guessing it would probably take what every other iPhone owner on AT&T's network would require to take the risk of jumping to another phone platform and carrier - it would take Verizon offering some type of credit to iPhone customers canceling their AT&T contract early to cover the switching costs. For all of the things that Droid can apparently do better, the one thing it doesn't have right now is the user base and appeal that the iPhone has. It won't get those two things either unless it does something to woo those iPhone users away. It's going to be those users raving about how Droid is better than the iPhone (assuming it truly is), not Verizon's ads, that draw the masses to Droid.

There Is No Cloud

2009-10-20T15:37:00.000-07:00

I wake up at 5:30 AM to lift weights and run. That's my own personal sanctuary from what is now my work day. My work day consists presently of helping a company manage applications and data "on the cloud". I do not think about "the cloud" while I'm working out... typically.

Late last week while doing cardio, I start listening to one of my subscribed podcasts as I always do when engaging in such a miserable activity for the benefit of my heart. The podcast of choice on that morning was TWiT. This particular episode came directly on the heels of the big Sidekick data loss fiasco - which just happened to be the loss of a ton of customer data such as address books, text messages, and other fun bits of personal data that was stored... guess where? That's right - "on the cloud". The TWiT crowd on that particular episode had a fun time with that term for the opening ten minutes this story was talked about. Thankfully neither Dvorak or Laporte were actually there, or else it may have just been intolerable. Regardless, they had a fun time talking about how "the cloud" failed.

Actually, no - that data was stored somewhere in the bowels of Danger's and/or Microsoft's infrastructure. Their infrastructure, and their policies/procedures around it are what failed. "The cloud" didn't fail anyone here.

Why? Because there is no cloud.

The "cloud" is just an abstract term that we used to use when drawing diagrams of networking infrastructure or system architecture. The "cloud" is drawn to represent parts of the diagram we either don't control at all, or don't care enough about how they work to include them in our documentation, or both. Normally this refers to things outside of our network, or just the internet in general.

This is what drives me nuts about the usage of the term "cloud" in the media. In their view, anything that lives outside of a user or company's machines or on-site storage is "on the cloud", implying that the user or company has no control of it or doesn't care how it works - which is bogus. Everyone I know who is doing something with a so called "cloud provider", be it AmazonAWS or Google AppEngine (notice there is no "cloud" in those titles) knows how those services operate, how their data is being managed on it, incorporates the internal workings of the service in to their architectures, and have plans in place to make sure they aren't totally wed to storing that data and applications on those services with some semblance of disaster recover in place were something to go horribly wrong.

Viewing those services as "a cloud" is just dead wrong. When dealing with my clients with work on Amazon EC2, I'm very careful not to refer to anything as "the cloud" to them. It's either "servers/elasticIPs,volumes on ec2" or "storage on s3". I want my clients to understand specifically that the services we are dealing with are services that we should own the process for using and understand how it works. The services are not an abstraction. They are real. In fact, I'd argue that this whole "cloud" movement changes nothing other than

The interfaces for how we deal with storage and application hosting are now remotely programatically accessible - this is a good thing. Essentially traditional system administrators are being replaced with APIs, which is great revenge given their previous collective views of everyone else in the world.
The previously mentioned storage and hosting is now distributed. By now we should all know that making things distributed is better for us all.

What I'd like to see happen is for anyone who talks about the "cloud" actually refer to those platforms by what they really are. Call "the cloud" for your Apple stuff MobileMe and describe it in the terms used for MobileMe. Describe your applications living on ec2 and your messages living in Amazon SQS. Stop using the blanket term "cloud". There is no cloud.

Staying Focused on a Mac

2009-10-17T10:56:00.001-07:00

I admit it... I have mild ADD. Luckily there are a couple of apps on the Mac that help me focus on a single application at a time, despite the fact I might need to keep several applications alive at any given time.

Isolator - This one was suggested to me by my friends over at Mystic Coders. This nifty application works in the same way that predecessors like Doodim do. It basically leaves the application in focus at the current screen brightness but dims or completely darkens the rest of the screen. This is ultra useful if you want to keep any eye on windows (e.g. irc) but you don't want them to dominate your attention while you toil away in another app.
Witch - Witch basically provides alt+tab behavior that works kind of like it does on Windows. For what it's worth its worth, I find the cmd+tab behavior between Apps only to be less of a cluster than sifting through all open windows I might have on a Windows machine at any one point. However, Apple's default cmd+tab behavior is lacking if you need to do something like very quickly giving focus to a minimized window. This action typically require you to pick up the mouse or perform multiple keystrokes. Witch reduces this burden by allowing you to use alt+tab like behavior to give focus to or un-minimize any individual window. This helps me stay focused by allowing me to minimize windows of applications that I don't need active and getting them back quickly without needing to touch my mouse.

Firefox DNS Cache Expiration

2009-10-02T13:55:00.000-07:00

Every need to increase the frequency in which Firefox invalidates DNS cache? At my current shop, we use separate DNS servers to draw the lines between parallel environment (e.g. QA and Pre-Production). Switching back and forth between the environments is as easy as modifying my /etc/resolve.conf file. However, Firefox actually caches those hostname mappings retrieved from DNS rather infrequently by default and I'd find myself quickly killing and restarting the Firefox process just to have my browser keep up at the frantic pace I was switching between environments. To expedite this, Firefox has a setting, available at about:config that allows you to modify how often Firefox invalidates its DNS cache.

The preference is Network.dnsCacheExpiration and its value is an Integer that represents the number of seconds to wait before invalidating cache.

I personally set this to 10 seconds to make Firefox somewhat instantly retrieve new IP mappings for the hostnames I was resolving. Conversely, if you wanted to speed up your browsing, you could simply set this value to something like 3600 (one hour in seconds) so you are only ever hitting DNS once an hour.

Using Python to quickly share files over HTTP

2009-09-10T06:45:00.000-07:00

Have you ever needed to share something quickly with someone on the same network and tussled with your OS's built in sharing mechanism more than you needed? If so, then just use python next time:

[whaley@closer ~/tmp]
> python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

The above will start an http server that allows directory browsing for only the current working directory you started python in (in this case, ~/tmp). Just have your colleague go to http://your.ip.add.ress:8000/ and you have instant and easy read-only file sharing from your machine.

Certify This - Export IIS Certificate and Private Key and Import to Java Keystore

2009-09-03T05:32:00.000-07:00

Here's the scenario. Our shop has a certain application out in the wild that expects to be able to hit some pre-existing https:// url's hosted presently on a windows machine running a .NET web application. Accessing those url's with http over ssl is mandatory, as the application will not attempt to fall back to http on port 80. We are also in the middle of porting those .NET web applications to a Java based web infrastructure. In order to serve those same urls with https from java from our application server, a Java keystore must be used to handle SSL/TLS requests from http clients.

I end up asking both a lead developer and a system administrator for the certificates used. The lead developer obliges with .pfx file, which is a pkcs12 file. The system admin pops over a .cer file in the form of a pkcs7 file.

To make a long story short, the pkcs12 is the one that you will want. You can retrieve a pkcs12 (extension of .pfx in Windows land) by following the documentation here at MSDN - there is a section devoted to exporting.

Using openssl, you can view the full contents of the pkcs12 file with the following:

`openssl pkcs12 -in thefile.pfx`  #The full contents
`openssl pkcs12 -in thefile.pfx -nokeys` #Show only the certificates in the chain
`openssl pkcs12 -in thefile.pfx -nocerts` #Show only the private key.

In order to actually use these commands, you'll be challenged for an "Import Passphrase" that was set on whatever tool generated this file. In in our case, this is IIS).

This is fine and all, but this file can't really be placed in to a pre-existing java keystore, or a new one for that matter, by using the keytool utility - the common and suggested way to manipulate java keystores. The keytool utility basically assumes it is going to either 1) have certificates placed in it to know what to trust as an ssl client or 2) be created with a public/private key pair that will be used to generate a csr and accept certificates from that csr that match the key pair. It does not allow you, intrinsically, to import a pre-existing private key or keypair that match already pre-existing certificates so that your application or application server can act as a server for ssl/tls communication with those pre-existing certificates.

The solution - there's a little library called Not Yet Common SSL that let's you do just that. It was being actively developed on until June of this year. I grabbed the 0.3.9 version (0.3.10 didn't work for me... I'll spare the details) and issued the following commands using the pkcs12 file as input.

`java -cp not-yet-commons-ssl-0.3.9.jar org.apache.commons.ssl.KeyStoreBuilder $challenge_password yourfile.pfx`
Successfuly wrote: [www.yourdomain.com.jks]

The result is a keystore file named www.yourdomain.com.jks where www.yourdomain.com is whatever the CN is the bottom-most certificate in your chain. The lone entry in the keystore will be an alias of the same name. You can now use this particular keystore in your application server for ssl and it will present your full chain of certificates to clients.

Code First Conundrum

2009-08-25T05:56:00.000-07:00

... or another more apt title is "Why on earth is ASP.NET still producing .wsdl files with soap encoding".

Here's the scenario - out in the world of a fledgling SOA architecture that is currently .NET based, there is a SOAP web service published for consumption. This particular SOAP service was created using Microsoft ASMX in ASP.NET 2.0 - which implies that the web service features a .wsdl that is code-first generated from a .NET interface. Our application is Java based and is using Apache CXF to perform compile time binding against the web service. Immediately upon trying to consume the wsdl as published from CXF for compile time code generation and binding using wsdl2java, we get this error message:

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Thrown by JAXB : undefined simple or complex type 'soapenc:Array'

Here's the lovely piece of generated SOAP goodness that's responsible for said parsing problem:

<s:schema targetNamespace="http://tempuri.org/AbstractTypes">
      <s:import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
      <s:complexType name="StringArray">
        <s:complexContent mixed="false">
          <s:restriction base="soapenc:Array">
            <s:sequence>
              <s:element minOccurs="0" maxOccurs="unbounded" name="String" type="s:string" />
            </s:sequence>
          </s:restriction>
        </s:complexContent>
      </s:complexType>
    </s:schema>

A colleague and I both start researching why on earth this is. He discovers the quick fix, which is manually replacing the soap encoding Array type with the more familiar sequence element in the wsdl as follows

<s:schema targetNamespace="http://tempuri.org/AbstractTypes">
      <s:import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
      <s:complexType name="StringArray">
            <s:sequence>
              <s:element minOccurs="0" maxOccurs="unbounded" name="String" type="s:string" />
            </s:sequence>
      </s:complexType>
    </s:schema>

I went off trying to discover why on earth .NET 2.0 ASMX is producing this in the first place and why wsdl2java was barfing when it encountered it. As it turns out, JAX-WS (which CXF is an implementation of) doesn't support soap encoding or soap rpc any longer. This is apparently for good reason. Do you want proof? Well, here's an explanation as to why soap encoding is bad and should be moved away from entirely written in the year 2000 by the company whose flagship web framework still produces it by default in a version that was released in 2005. Unfortunately, I never did discover the answer as to why .NET produces this or how to disable it, if at all. The documentation on ASMX on MSDN was pretty sparse and no annotations in the .asmx in file seemed obvious candidates for tweaking to make this go away.

If anyone has any ideas, let me know. In the meantime, we'll maintain our own copy of the .wsdl without the soap encoding cruft so work can actually get done.

Windows Foolishness

2009-07-21T18:43:00.000-07:00

If you want an example of pure Windows foolishness, check this out.

In order to change the hostname of a linux machine, you'd do something like this

echo -n newHostname > /etc/hostname

To do the same thing in Windows from the CLI you first have install netdom.exe from the installation CD (it doesn't install by default), and then issue the following command

netdom renamecomputer machine  /newname:new_computername  /userd:domainname\administrator_id  /passwordd:* /usero:local_admin
/passwordo:* /reboot:seconds before automatic reboot

Which OS was supposed to be easier to use and administrate again?

Now, the enterprising Windows users who might be reading this may counter and say "you can do this very easily under Computer Management". They would be correct, you can point and click your way in to changing the hostname and restarting in about 20 clicks. But try doing that over 50 or some servers and let me know how your RSI is treating you if you continuously use that as your mechanism for administrating your systems.

Pet Peeves

2009-07-17T16:14:00.000-07:00

The following is a list of my top five pet peeves that I encounter in the software engineering field. It is meant to be a completely childish exercise in vetting frustrations with things I encounter on a weekly, if not daily basis. Without further ado:

#1) Learned helplessness - or "I'm too lazy and/or selfish to take five minutes to try and find the answer myself or learn to do it myself.

This takes the cake, in my opinion, as the single largest time suck any software engineer faces when working collaboratively with a team that is guilty of this foul. It is also probably my biggest pet peeve not only in software engineering but in any facet of life - I despise it when perfectly capable people resign themselves to asking for someone's help or advice without first having tried to do something or figure something out themselves. In our field, it generally takes 5-10 minutes tops to write a test case to answer a question or even less time to determine if there is documentation to answer it through this wonderful invention called google. If one can't find the answer in that amount of time by themselves, then it's time to ask someone. People learn more by finding the answer themselves than they ever will by having fed by others - and in doing so they don't risk interrupting the precious flow of their co-workers with questions they haven't bothered finding the answer for. Doing so is a selfish act and completely disrespectful of others who have strived to teach themselves so much.

#2) Anything involving a Microsoft product.
Yes, I'm quite biased - but for a good reason. Having to deal with anything Microsoft related when working as either a developer of applications or working with applications in a server deployment is just an absolute pain. For starters, a software engineer worth his or her salt will spend a sizable amount of time in a console while doing their work. Unfortunately for folks stuck administrating and or using windows machines, you have to install a combination of cygwin + Console just to have a halfway decent console experience... and even that experience is half-baked.

Furthermore, most applications and tools from Microsoft assume you are a complete buffoon and offer you only wizards and menus to configure your applications. These might be great when initially setting up an application but they often come with absolutely no way to configure them outside of said wizards and menus - thus meaning it is near impossible to script and automate changes to them.

Altogether, the user experience is just awful, full of interruptions, and a pain to do anything quickly in. The only way I could justify owning a dedicated Windows machine again is if I were to get back in to full time gaming... and even that is changing now with things like crossover.

#3) Calling directories a "folder"
This one annoys me to no end, but it's hard to explain why. If you are a non-technical end user, this is perfectly excusable. The whole folder/desktop terminology and graphical presentation was created as an analogy to make computers easier to use for the masses. However, if you are an engineer, you obviously don't fit that bill. So call the thing by its real name - they are directories, not folders.

I equate this to my mother-in-law, who can't name a single position on a football outside of quarterback, calling a 4-3 defense in football "a bunch of guys trying to tackle the ball". That's excusable because she has never played and doesn't know the lingo. However, if you were my teammate on the offensive line and you called a 1 technique simply a "Nose Tackle" when trying to identify alignment, then you ought to be smacked upside the head.

For those of you who don't know, what typically gets referred to as a Nose Tackle can be aligned in about 5 different positions in a down position (2, 2i, 1, shade, 0 - all of which make a world of difference), so simply calling that person a Nose Tackle is horribly uninformative, misleading, and just wrong. And for that matter, so is calling a directory a folder.

#4) Meetings that include brainstorming but with no actionable items or plan associated

See here for a recent diatribe against this.

#5) Using Email to Debug and Collaborate on Work

Email might be the single worst communication method possible to debug and resolve problems - outside of using a conference call with no textual methods to aid. Yet, pretty much every shop I've ever worked in (aside from my present shop) uses it as the primary means in which to collaborate. Email is intrusive, asynchronous, not fit for working on code, forced upon unwilling audiences, and encourages grandstanding and long drawn out replies. Really, what most folks need is a synchronous pub/sub communication mechanism, like irc.

See here also for a previous post on my adoration of irc for teams.

What ChromeOS Will Really Do

2009-07-11T07:01:00.000-07:00

Hint: It won't be revolutionary.

Since the general press announcement regarding Chrome, Google's new cloud based OS, hit the presses, I've seen all kinds of articles from the media and bloggers discussing how huge of an impact Chrome will have on the computing landscape.

Yeah yeah... we've heard it all before.

Don't get me wrong, moving disk storage and applications and nearly all computing resources to the cloud is a desirable thing. But, this isn't exactly new stuff. Businesses are already doing this with things like Amazon EC2/S3 for storage and machinery, using distributed processing with MapReduce based architectures, and both offering and consuming Software as a Service (SaaS) applications.

They certainly aren't the first OS vendor who's made this vision their modus operandi for what their consumers should experience either. Sun Microsystems for the longest time has been spouting off "The Network is the Computer" as their mantra. Even Apple has been offering MobileMe (formerly .mac) for cloud based storage and synching between desktops.

Here's what Chrome OS will really do - it'll really just drive the existing OS stalwarts to adopt using the cloud faster... much like the Chrome browser did. When Chrome was released, it upped the ante for how performant a browser a should be in regards to speed and responsiveness. Not too long after the release of Chrome, the public is given Safari 4, Firefox 3.5, and IE 8... which are competitive in speed with Chrome and are arguably much more functional (especially in the case of Firefox). So while Chrome introduced new competition, it didn't exactly establish, let alone maintain, a competitive and differentiating advantage over the existing products.

And so it will be with ChromeOS. It will not be the savior of "desktop" computing. It won't come even remotely close to bringing Microsoft down (something not even Google's search has been able to do to MSN/Bing). It will just push the existing OS's to move more intrinsic capabilities to the cloud, which is something Apple has already been doing and something Microsoft definitely has the capacity to support, while achieving and stagnating at a very small and limited share of the overall OS market.

Brainstorming Done Wrong

2009-07-06T06:47:00.000-07:00

Brainstorming - a group problem-solving technique in which members spontaneously share ideas and solutions.

Notice that the definition doesn't use the word critique anywhere in it. That's because brainstorming is meant to be an activity in which all participants, even if it is just one person, are meant to throw out as many ideas as possible without shooting any down under existing premises and allow the organization and planning of those ideas be placed on the back burner.

Sounds like a wonderful way to come up with new ideas and possibilities, eh? It is the day dreaming portion of being a knowledge worker - where you get to think without reality. But that's the part where brainstorming can go awry if you let it.

Brainstorming must be done in the overall context of a plan or a project. If one is just brainstorming willy-nilly and simply for the sake of brainstorming alone, it's a rather pointless activity that is orthogonal to anything that we as knowledge workers should be focusing on. In fact, if brainstorming is conducted without the results of sessions being used to impact an already existing project or goal then it is, in the best-case of a single person, a huge waste of time and mental energy used to flutter out ideas that won't be used. In the worst case, it can demoralize a whole team if they are coerced in to a highly collaborative activity that sucks up double-digit man hours, all to produce nothing if no actionable steps or follow through is executed on the residual items left over from a session. One can guarantee this does not happen if brainstorming is put in to the context of an overall plan or project and is usedas the basis of forming next steps in a project.

A case point that I've experienced at the professional level involves a brainstorming session we had close to the initial launch of a high visible web development/services project I was a part of. Toward the end of that project, when frustrations were high and deadlines were starting to slip, management thought it would be a good idea to have all of the key participants gather in a room and have a brainstorming session on identifying problems in the project and how to correct them. As an exercise in how to conduct a brainstorming session, it was very well done. Someone in management had been doing his/her reading well on how to conduct a successful brainstorming session. Lots of ideas and thoughts were tossed out there, displayed wonderfully as sticky notes on a whiteboard (there were literally hundreds of them). Unfortunately, what management in this case did not do was use this brainstorming session in the context of the full project. There were no actionable items were created as a result of the session and no follow up meetings were held - contrary to the lip service given by those organized the affair. It was as if hundreds of good ideas and thoughts suddenly cried out in terror and were suddenly silenced. The voices of all who participated were just simply ignored.

This particular session ultimately did more harm than good. To this day, that brainstorming session still gets mentioned in the office in very negative connotations as a useless waste of time and no one today wants to engage in any formal brainstorming sessions out of distrust from the original. This is due to the fact there was no follow-through - the brainstorming was not done in the larger context of a plan. Had the ideas used in that brainstorming been used for actionable items immediately as part of our project plan, two things might have occurred: 1) the rest of project may have gone much more smoothly (it didn't, no problems were addressed) 2) the folks doing the work would have had confidence in the brainstorming activity and would have engaged in more.

Things - Part 2 of How I Get Things Done

2009-06-29T05:50:00.000-07:00

This entry expands on my previous post on managing communication to Get Things Done (GTD). In that post I stated

I set the timer for 48 minutes and kick it off and focus solely on items in my GTD list - nothing else exists in the world if I can help it. I ignore all non-urgent electronic communication (anything mentioned above and email) and I only communicate with others on purpose if its relevant for the task at hand that I'm working on. What is considered urgent or not is often for me to decide on the fly.

That sounds fine and dandy - but just how does my GTD list get populated? I basically try to follow David Allen's instructions (at least those outlined in the first three chapters or so) to a tee. This includes having a system that I can trust that I put every actionable item I need to take in it. The system that I trust is a piece of software called Things created by Cultured Code.

It is essentially setup the same way that Allen instructs well. Any actional item that I encounter that I can't get done in a *very* short amount of time (2-5 minutes) typically gets placed in my Inbox so that I can decide what to do with it later. For the entire time that I'm working, I am focused solely on those tasks that I have given myself in the Today section, giving higher priority to those makred as Due on that day. Every single item is assigned to an Area of work (e.g. work for my Employer, Personal Projects, Housework, Developer Communities, etc. etc.) and within those Areas can be projects - which are items that require two or more actionable steps to complete.

I have found that using this system has had two effects on me:

I'm much better organized and prioritized in my daily work. Organizing all of my actionable items in such a way allows me to focus on one thing at a time knowing that the sequential order based on priority has already been taken care of for me, thus negating my ADD.
My mental burdens are very low - I no longer obsess about work or what I haven't done when I'm not working because I have my things to-do ready for me when it's work time again.

The book and the software itself comes out to around $70 total, but given the boost in productivity and quality of work/life if its had on me, $70 is one hell of a deal.

Mysql Backup Script

2009-06-24T04:13:00.000-07:00

[Note: This script was not written originally by me. I am just pasting it for others to consume.]

Here is a quick and nice mysql backup script that one can add to their crontab to produce nightly mysql backups. It is not completely turnkey as you need to edit some of the variables (or write some code and pass some arguments such that they can be specified on the command line) and also have a dblist.txt file ready with the names of the databases you wish to backup.

#!/bin/bash

# Backup mysql databases

# Set a value that we can use for a datestamp
DATE=date +%Y-%m-%d

# Our Base backup directory
BASEBACKUP="/folder/to/store/mysql/backups"

for DATABASE in cat dblist.txt
do
       # This is where we throw our backups.
       FILEDIR="$BASEBACKUP/$DATABASE"

       # Test to see if our backup directory exists.
       # If not, create it.
       if [ ! -d $FILEDIR ]
       then
               mkdir -p $FILEDIR
       fi

       echo -n "Exporting database:  $DATABASE"
       mysqldump --host=localhost --user='YourMySQLUser' --password='YourMySQLPW' --opt $DATABASE | gzip -c -9 > $FILEDIR/$DATABASE-$DATE.sql.gz
       echo "      ......[ Done ] "
done

# AutoPrune our backups.  This will find all files
# that are "MaxFileAge" days old and delete them.
MaxFileAge=30
find $BASEBACKUP -name '*.gz' -type f -mtime +$MaxFileAge -exec rm -f {} \;

OSX Java Update Surprise

2009-06-22T09:45:00.000-07:00

On Friday of last week I installed Apple's latest Java update to Leopard, Update 4, which gives us 1.6.0_13 of Java. This patches a pretty critical vulnerability in Java that Apple was lagging behind on addressing in their repackaging of Java.

After installing the update, I notice that my version of Java, as reported by `java -version` was a 1.5 version, not 1.6. However, the Java version I set per Java Prefrences.app was indeed 1.6. I did not muck with any of the symlinks found within /System/Library/Frameworks/JavaVM.framework and there certainly wasn't a java bin directory on my path.

Turns out that Java on OSX now honors your JAVA_HOME environmental variable, which I did have set in my .bash_profile file. I originally had this set to Java 1.5 for a project I work on that requires a 1.5 JRE (the bundled version of JAXB in 1.6 conflicts with a version of CXF we depend on).

This is kind of neat actually. I no longer have to open a gui app to change the version of Java I am using... I can use my ~/.bash_profile file as I always have on any other system. Here are the relevant contents of my ~/.bash_profile file:

#export JAVA_HOME=$(/usr/libexec/java_home)
export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home
#export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home

I basically leave the version of Java I want to use uncommented and then `source ~/.bash_profile` to make that take effect. If I wanted to actually use the Java version that takes priority via what's set on the Java Preferences.app utility, I would uncomment the first line - /usr/libexec/java_home simply returns the directory of the currently active Java version set by Java Preferences.app. I personally chose to forgo that route since it requires multiple steps and opening that utility instead of just allowing me to simply edit my ~/.bash_profile and re-source it.

Managing Communication - Part 1 of How I Get Things Done

2009-06-19T05:26:00.000-07:00

This post was prompted by another blog post by my friends over at Mystic Coders. In short, it discusses the topic of communication overload. This post is simply a re-edit of a comment I made there. I will base a series of posts off of the general subject of how I Get Things Done (GTD) of which this post will be the first.

I have been keeping this thought inside for quite sometime, only ever preaching to choir when a certain style of communication annoys me. Here is that thought for the rest of the world to consume...

EMAIL IS NOT INSTANT AND SYNCHRONOUS! STOP USING IT AS SUCH!!

We live in a world where friends, family, and coworkers are all constantly sending each other emails and somehow the protocol was established that replies and threads must be replied to and read in an almost instantaneous fashion. The coworker bunch is the worst offender of this. My favorite example of this is from a former operations director who would send a (non-critical) email to you and within five minutes later he would be at your desk to make sure you read it. That, my friends, is a double-whammy to The Flow. Unfortunately, everyone seems to have forgotten that the final 80% of characters in the word "email" spells "mail" - a communication mechanism that we all find acceptable to check once a day and let pile up when we are out of town.

Of course, given the world of constant interaction that we find ourselves in now, it would be pretty implausible to just trivialize email the way I just did by comparing it to snail mail. It wouldn't work practically in some organizations. Given the fact that I work remotely, I really would have a hard time eschewing it.

Of course, email isn't the only distraction that we face. I personally engage and benefit from using 4 other electronic communication mechanisms:

IRC
IM
Skype
Twitter

If one is not careful in their usage of any electronic communication protocol, it can become a timesuck just like, if not bigger than, the barrage of email piling up in your inbox. Of course there's always those interactions you must and will have with people on the phone and in person as well.

So... here's what I do to circumvent this. For the part of my days that I've partitioned to Get Things Done (aka work), I put myself on a timing system. I'm on a Macintosh and I use the simple but functional Apimac Timer application. I set the timer for 48 minutes and kick it off and focus solely on items in my GTD list - nothing else exists in the world if I can help it. I ignore all non-urgent electronic communication (anything mentioned above and email) and I only communicate with others on purpose if its relevant for the task at hand that I'm working on. What is considered urgent or not is often for me to decide on the fly. Roughly, if it's direct coworker who is pinging me via a synchronous communication protocol (IM/IRC/Skype) or in person or on the phone about something important to my tasks or their tasks and I'm not in The Flow, I'll pause to answer them; otherwise... they must wait. I do not even look at my email window at all unless a high priority email came. After the timer finishes and the 48 minutes is up, I reset it to 12 minutes, and allow myself to check email, irc, hit the bathroom, read a random article from my rss feed, and so on. After the 12 minutes is up, I'm back to focus mode again for 48 more minutes... Rinse, and repeat.

This 4:1 ratio allocation of one hour blocks of time has the triple effect of allowing me to:

synchronously communicate and email enough when it is warranted
concentrate in almost 50 minute blocks of time - long enough to establish and keep a flow on short tasks
take enough mental breaks from tasks during the day so as not to be drained by 2PM

I only ever void this schedule if the work I'm doing is either super critical, if I'm really in the zone and it doesn't seem like a need to take a short mental breather, or if I've scheduled an event previously (a meeting, or phone appointment, for instance).

To help me stick to this schedule the I do the following things with my email and email client which delivers the communication that is often the nosiest and responsible for the biggest chunks of time that could potentially be wasted

Turn off pop-up windows and noises that occur when ANY new messages arrive
Create a filter rule that automatically gives a low priority status to any message where my name, or one of my distribution lists/groups are not in the TO: line. Low priority emails are read at the beginning of the day on the next day.
Keep my own email messages under 3 sentences, unless the piece of communication really deserves more. Unless an email message will contain a moderate amount of technical detail, it must be typed in 3 sentences and under 5 minutes. Otherwise, it probably ought to be communicated through some other means.
Bounce the dock icon on my Mac if there is a high priority email - I allow myself to at least skim those at any time to determine if there is an action item I need to perform right away. This form of notification is subtle enough to not distract my eyes until I've come to an intermediate stopping point in whatever it is I'm doing (e.g. finishing writing a statement in a piece of code).
Strive to keep the Inbox at 0 unread messages... I never want to have the feeling that I'm behind or missing anything.

What I've found in applying these techniques to email is that the signal/noise ratio of the email I check constantly is very acceptable. I probably only read about 10 during the normal workflow of each day, as I only permit myself to read/write them once per hour. Ignoring emails you are CC'ed on until the next day also has the side effect of making you resist the urge to peanut gallery on threads you were merely CC'ed on - thus preventing (or at least keeping in check) the negative feedback loop of everyone trying to shove their opinion and thoughts in to a gigantic email thread.

With the other communication protocols, I just play it by ear. I don't want to eliminate folks from being able to find me, at will, on synchronous communication protocols unless I really need the focus. I do nothing fancy with them outside of turning off growl and setting my skype to DND status (which prevents me from seeing when others call).

The end result of all of this is that I now probably spend about 1 hour a day on communication during my work time instead of the 3 hours or so I estimated I did before - and that's an extra 2 hours a day one can devote to doing the real work that one needs to do to stay productive and valuable.

What are some things that you do to help facilitate getting in The Flow and keeping your communication avenues available but without getting in your way?

Ivar Jacobson's Smart Practices

2009-04-07T07:38:00.000-07:00

Here's a neat little article that provides several quotes from Ivar Jacobson regarding current Agile practices and software methodologies in genera l.

The really cool part is the juxtaposition of what Jacobson considers to be smart and un-smart practices - and I tend to agree with him. Here are the top three I can pick from that list (in the order they came in at that list).

Unsmart with Projects – Trying to follow a waterfall approach
Smart with Projects – Build a “skinny system” to demonstrate that you have eliminated all the critical risks, then add more capabilities on top of that skinny system as needed.

“Think big, build in many steps”

I work at a shop that essentially uses a waterfall approach. Nothing is really done iteratively with very little to no prototyping - outside of a rare alpha delivery here and there. What unfortunately ended up happening was lots of debate and wasted time with up front planning, no one group owned the full architecture (as there wasn't buy-in up front), implementers of a project shoved everything out in one go using the same technologies that were selected up front without knowing, through the use of a prototype, whether they were the right tools for the job. Time then gets wasted during the "death march" period fighting problems that could have been identified up front with a prototype.

That basically results in two instances of wasted time and contention - once up front because everyone tried to get the implementation correct on the whiteboard in their own way instead of in code, and a second time because everyone ends up dealing with a design problem during the construction process because the design wasn't correct. This has been written about at last as far back as Steve McConnel's first edition of Code Complete in 1993 - and probably even further back than that. It seems we haven't learned much as an industry since that point if well known names in the software industry are still having to give talks decrying the waterfall methodology as a common pitfall in today's practices.

Unsmart with Testing – having two classes of people – developers and testers. Unsmart projects testers are “the cleaners in the software world” – picking up the mess left by the developers
Smart with Testing – the whole team is jointly responsible for quality and testers are first-class citizens

“Whatever you do, you are not done until you have verified that you did what you wanted to do”

In a shop I've worked at, I have seen the "Unsmart with Testing" scenario crop up as well. I've heard straight from the mouths of developers that "our job is to write code, we don't need to test our code at all, that is QA's job", to the point that 10 minutes would not be spared for a member of that time to run a quick smoke test on a build before it was delivered to QA. Additionally, no form of automated unit testing was being performed by this team, essentially leaving all formal testing up to QA folks. This is the epitome of not owning your own work. It also did not help that at this shop many QA folks were not especially savvy at describing and reporting bugs or helping developers find issues. It was the stereotypical example of a place where bugs were just tossed back and forth over a very thick brick wall with no communication.

The point here is that developers should own the testing of their code and QA folks should be proactive in helping resolve bugs. To provide concreteness to that assertion - developers need to 1) write automated tests for their code up front 2) write automated tests that reproduce bugs deliver by QA 3) take at least some time to work with QA members on the resolutions of bugs. QA folks also need to 1) make the developers lives as easy as possible by not only owning the reporting of bugs, but by helping see them to resolution b) provide concrete steps and extremely detailed pieces of information in every peice of communication given to developers - "It doesn't work" is always the wrong piece of communication in this case.

Unsmart with Documentation – slavishly filling in a document template because some process rule says it has to be there
Smart with Documentation – recognize the “law of nature: people don’t read documents”. Document only what is absolutely needed

“Focus on the essentials – the placeholders for conversations – people figure out the rest for themselves”

I'm wary of this, as I think documentation of any form is better than no documentation than all (which is debatable). However, I feverishly oppose enforcing documentation by template any chance I get - if the documentation writing is manual. The only documentation that ought to be placed in a template needs to be something automatically generated - such as bug resolution reports from an issue tracker, or something like javadoc or maven site generation.

Beyond that, documentation should be treated like like creating the software itself - make it an iterative process. Document only what is necessary and when the gaps need to be filled in, they get filled in. This is why wiki's as documentation are a powerful thing. Developers need to spend time in their tools and in conversation with other co-workers, not time in Microsoft Word or whatever the editor of choice is.

What are your thoughts and takes on Ivar's list?

Continuous Deployment - Neat Idea, but not generally applicable

2009-03-31T13:40:00.000-07:00

Continuous Deployment, as I interpret it from this particular article, is basically automating your production pushes to come straight from your Continuous Integration environment with NO human intervention in between. I will leave it to you, the reader, to check out the full article before continuing reading my post.

To paraphrase the author, this method of development involves building and testing all commits in your Continuous Integration environment followed immediately by an automated deployment in to your production environment automatically, and that such a methodology actually encourages very strict and rigorous automated testing and discipline from developers. I believe him. It is a lofty goal and is an extremely neat concept. There are cases where I'd probably see myself recommending and implementing such an approach - think of a smaller start up with limited resources whose production systems don't necessitate 24x7 availability or correctness according to a specification (perhaps Twitter in the early days?).

However, in the general case, I don't know if Continuous Deployment is such a wise goal - at least to a production system. I for one don't even encourage it in my own shop to our development environment since I want to maintain some semblance of stability in that environment where deployments are timed and roughly scheduled simply due to the number of disparate groups who rely on them for testing and working on their own components and systems (this is a side affect of an SOA architecture). Continuous Integration encourages constant integration somewhere, which means deployment ought to be happening somewhere for automated integration testing - to me that environment shouldn't be to your production environment. I for one think that automated deployment followed by automated integration testing should be segregated from live environments consumed primarily by humans, be they developers, testers, business users, or external users/customers. Most organizations have environments containing specific versions/combinations of their systems, each with different roles according to their development process. Updating one automatically at the point in which any developer makes a commit is too loose for an organization of larger size with many systems and many teams where there is usage and testing (manual or not) of a given environment going on seemingly at all times.

That's not to say that deployment shouldn't be automated... it should. But the ability to deploy, in the general case, should be held in escrow by a human to at least enact a deployment on a push button basis. Otherwise, I believe too much burden (that being almost all) falls on the developers for owning deployments to an environment - a task they should be mostly decoupled from.

There is something else that rubs me wrong about Continuous Deployment. There aren't multiple validation factors being applied to the sanity of a given build. Automated testing, be it unit/integration testing at build time or monitoring via an alert system (e.g. Nagios) is indeed quite awesome, but it shouldn't be the only check. Automated testing, much like manual testing, is fallible because it too is ultimately orchestrated by humans (someone has to write those tests!). One method of testing by itself can't be trusted - I have seen it all too often where an automated test picked up what QA guys did not catch (or picked it up much more quickly) and when QA guys spotted failures that the automated tests did not account for. Going full hog on Continuous Deployment gives you a single point of failure on testing, and in my honest opinion, is no more reliable than manual human testing by itself where correctness is concerned.

Again to summarize I think Continuous Deployment to production is a neat idea and applicable in certain cases - but I wouldn't suggest getting all hot about it unless you are willing to accept the risks it might bring with it to your organization.

IRC - The Online War Room

2009-03-23T03:59:00.000-07:00

My last post, Bootstrapping a Development Team, drew at least one comment from my friend waz. He suggested that a team also needs a synchronous communication mechanism such as IM or IRC - a virtual water cooler.

I made the mistake in my last post of taking internal communication for granted and did not make mention of the means a team may take to synchronously communicate to one another online. I have long been a member of the converted, spending lots of my online time on irc in development related channels (mostly public channels on freenode) and have even used irc as a major communication mechanism for the last year long project I was involved. I thought it was a wonderful tool for the job - especially given the amount of remote development we were conducting.

However, when explaining my usage of irc for professional and development purposes to non irc denizens, I could never find the appropriate analogy for it. I can thank Neal Ford for giving me one now. During Ford's leading keynote at TheServerSide Java Symposium '09, he talked about developer productivity and how cube farms are detrimental to developer productivity. I couldn't agree more. Of course, every developer would love to have their own office space, but this is not possible given limited office size. So instead he explained the concept of a "war room", or an open room full of nothing but developers where the only conversation revolves around the project - it is pretty popular over in the Agile world, it seems.

So what piece of technology can encompass that same concept for communication? It is not IM and email, which are so riddled with non-development noise that it is hard or impossible to filter and can easily lead to distraction for the concentrating developer who is short on time and has precious mental cycles to spare. The best solution would be irc. It is synchronous, channel based, filterable, and most clients support nick highlighting so that only messages directed to you are highlighted - easily allowing a conversation to take place within a conversation. I'd take it one step further than the virtual water cooler analogy that was given. I dare say that irc is the quintessential online war room for developers. I would also ammend my previous list of things needed to bootstrap a development team and place irc as a must have.

Bootstrapping a Development Team

2009-03-16T15:47:00.000-07:00

I have been trying to have brainstorming sessions lately. Basically, I give myself about five minutes everyday to brain dump tons of ideas on how to solve a particular problem or how to come up with a creative use of a particular tool or platform. One day, I started pondering all of the technologies I would need, outside of personal machines, languages, and developer tools that I would need if I were to bootstrap a development team.

Here's the list I came up with:

Essentials:
- Issue Tracker - You need to have a bug base of some kind when developing software. This can double up as a task management/monitoring system also.
- Version Control System - I'm of the opinion that no development on any project should be done without some form of version control.
- Wiki - Use this to encourage documentation of everything.
- Continuous Integration - Gives your team a one-stop shop and authoritative source for producing and unit testing your builds.
- Backup solutions and Disaster Recovery plan - Make sure everything that is critical to your project development and release to the outside world can be recovered in less than a couple of hours maximum (and even less depending on what it is that you are doing).
Essentials for Web / Server-side projects (since there will be N number of servers to work with):
- Server Management Tool - Use tools like Puppet or Capistrano to automate as much as you can regarding server setup.
- Server Monitoring - Central system to handle the monitoring and alerts for when your systems reach an undesirable state (for example, Nagios)
Sorely needed, but not deal breakers:
- Test coverage tool - in this day and age, anyone writing code ought to be aggressively writing unit tests. It is very useful to have metrics to see how effective your unit tests are.
- Code review tool - code reviews are extremely useful, but also time consuming when done formally. Having them conducted asynchronously in some kind of server side tool would help streamline the process.

I tried on purpose to not mention any specific technologies in this post, with the exception of server management since most folks may not be familiar with what I was talking about. I may do a little "best of breed" or "most bang for your buck" case study later at some point to discuss the various implementations of the aforementioned technologies.

What are your thoughts? What would you include or exclude from this list?

Adding Environmental Variables to Netbeans

2009-03-06T06:45:00.001-08:00

Short story - I loaded a fairly large multi-module maven project into my Netbeans 6.5 IDE and hit an OutOfMemoryException when running `mvn clean install` on the parent pom. Simply put, running all of the goals on this project requires more than that default 256m of max heap size that automatically gets allocated for maven. It is an easy fix when running mvn from your shell - just use:


`export MAVEN_OPTS=-Xmx512m`.

Unfortunately, the maven configuration in Netbeans doesn't allow you, through menus at least, to set this. In order to set environmental variables such as this, you'll need to add them to ~/.netbeans/6.5/etc/netbeans.conf. E.g.:


jwhaley@thirdeye:jwhaley$ cat ~/.netbeans/6.5/etc/netbeans.conf 
export MAVEN_OPTS=-Xmx512m

Growl Maven Integration

2009-02-25T06:06:00.000-08:00

Well, not really. I am copying and pasting something directly from Lars Trieloff that shows a bash script that wraps the mvn executable, pipes its output to awk, and sends selective notices to growl. You will need to have the growlnotify exectuable installed to use this.


#! /bin/sh
/usr/share/maven/bin/mvn $* | awk '
{
print;
if($0 ~ ".*ERROR.*") system("/usr/local/bin/growlnotify -n mavenError -t Maven Error -m\""$0 "\"")
if($0 ~ ".*BUILD SUCCESSFUL.*") system("/usr/local/bin/growlnotify -n mavenComplete -t Maven FTW! -m\""$0 "\"")
} 
END {
}'

Pretty neat.

Paying Attention Outside of your Discipline

2009-02-19T05:42:00.001-08:00

I have a problem of staying too focused on what happens inside my own discipline and industry. For example, my list of RSS feeds that I try to read daily is composed of about 95% technology and software news - with the remaining 5% devoted to feeds from Slate and xkcd. Basically, I am up to speed on software news, a couple of national and world editorial pieces, and a funny geek-centric comic. In other words, I think I fit the stereotypical reading pattern for a developer who doesn't leave his editor/IDE... ever.

Well that might be detrimental and keep me (or you, if you have the same reading pattern) from reaching our full potential for creating awesome stuff. Here is why - read this article on Wired about a ophthalmologist named Edward Chaum. The gist of the article is that Dr. Chaum visited a semiconductor research laboratory, saw how automatic image analysis helps find defects in hardware that humans otherwise would have a hard time finding based on, what I am assuming to be, some case-based reasoning machine learning. Dr. Chaum then applies the same technology and techniques to retinal scans. His retina scanning devices are now being placed in communities in rural areas (the Mississippi Delta, for instance) where ophthalmologists are not exactly accessible and diabetes rates are high. Given that diabetes if left untreated can cause blindness, there is an urgent need to be able to supply such detection to those who otherwise would not find a reasonable way to see an eye doctor.

Pretty cool huh?

So how does this apply to us software geeks? Well, Dr. Chaum's idea most likely would have not come into fruition had he not visited a semiconductor research lab. Practically speaking, an ophthalmologist under normal circumstances has no reason to be visiting a semiconductor lab - what has that got to do with being an eye doctor, one might ask? "Probably very little", would have been my answer five minutes before reading the article.

However, Dr. Chaum's case is one of someone crossing over to a different discipline or industry, seeing what is happening over there, and finding a way to apply those developments in a beneficial way to his own field. Perhaps we as software writers should do more of the same? I get the impression that many of us write software or facilitate software development for the love of the technology and the mental stimulation it brings us, but not for what the technology enables. I hypothesize that this is because we have not tried or just simply do not draw inspiration from other fields, typically. I most certainly do not at the moment, I'm afraid to say. If we learned and explored a variety of disciplines, even at the basic level, our creativity might be spurred to go out ourselves and enable something like Dr. Chaum has and apply our own expertise to using existing technology to real problems faced outside of own little bubble of thinking of only frameworks, languages, tools, etc. etc.

What do you think?

deployment is hard!

2009-02-09T18:20:00.000-08:00

Except that Barbie is not kidding. Here is a link to an excellent post by Mr. Dan Diephouse (you know, the fellow who is responsible for XFire and is presently employed over at Mulesource).

For one, it is very refreshing to see a developer publicly acknowledge that deployment is a hard problem. I often get the impression that deployment gets taken for granted, or it is at least not publicly talked about or given much attention. It should though - what good is software if you can not get it installed and running on the target environment.

One of my primary functions at the day job is owning all technical aspects related the deployment of several web applications and web services with a fair number of interdependencies. While the post Dan made highlights the usage of some tools to help automate things, I have to admit that even getting to a point where you can automate can be pretty tough - especially in an environment where you have many dependencies to worry about (and to coordinate across multiple groups, such as DBAs since I have been instructed to not touch the data tier directly). At this point my automation is crude - a set of scripts that can pull down a build from a local maven repository and install it in a given container. It is ok, but because of certain things needing to happen in a certain (variable) order, most of the process remains manual.

What I would be curious to know is what other folks in the build and deployment business do to automate deployment to the environments in a full-proof (if possible) manner when there is variable sequential order involved? Any takers?

LINQ Revisited

2009-01-16T04:42:00.000-08:00

One of the very first posts I made decried the usage of LINQ as just more inline SQL coding that leads to ugly, coupled code. Looks as though my prediction, based on at least this blog entry, was not far off.