What Am I Doing?

Frequently asked question:  What will you be doing in Saudi Arabia?

photo by Pete Manson, Saudi Aramco

Since most of my friends in Austin know me either as a software developer or a filmmaker, it's understandable. Few know about my work in refineries and chemical plants.

Short answer: Engineering Specialist for Saudi Aramco in their Process Automation Systems Unit.

And that's all I know, they haven't told me what exactly I'll be doing. But I'm okay with that.

Flashback: in 1990, my brother Timothy left Texaco's Central Engineering Department to start his own consulting company, Coherent Technologies, Inc. in Houston, now based in Palestine, Texas where Tim and I grew up.

Side note: There's a great song by T-Bone Burnett called Palestine. Here's a video I shot of Sam Baker and Carrie Elkin singing their version of it with Gurf Morlix on guitar and Ray Bonneville on harp. You can play it while you read the rest of this long post. ;)


Tim got so much work so quickly that he asked me to join him. Soon after, in '91, a young Electrical Engineering graduate from Texas A&M, named Fayez, joined us as employee #2. (Tim and I both went to A&M, '73 and '84 respective, so I guess he was partial to A&M grads.)

That was another life change for me. I had worked as an engineer in semiconductor manufacturing, consumer electronics consulting, and for a military contractor. Now I was a consultant to energy companies. It's mind bending how much money is at stake: if even part of a plant goes down unexpectedly, at best it can cost millions of dollars and at the worst, lives.

Explaining exactly what I do for them is difficult. The short answer is that I automate the plants, controlling the valves and motors based on temperature, pressure and time. I create custom software that run the plants efficiently and safely.

With automation, the plant operators can focus on the big picture of running the plant and not the small details of when to open and close valves, start a pump, or throttle a flow. That means the plant can run more efficiently.

My proudest accomplishment was working on Emergency Shutdown Systems for Texaco's gasification process. Gasification takes waste hydrocarbons, the hard-as-rock crap that's leftover after the refinery squeezes out everything it can, and combines it with 99% pure oxygen at a high temperature and high pressure to produce hydrogen that the plant can then feed to gas turbines for generating electrical power. It's classified as green, alternative energy. It's also an incredibly dangerous process that can explode. (The inside walls of a gasification reactor is lined with a refactory like the heat tiles on the Space Shuttle and if there is any defect in them, the wall of the reactor can melt and cause an explosion.)

My job was to program a special computer worthy of NASA to start the process and shut it down safely.

So even though I work for an oil company, my job is to make sure they are efficient and safe. If we have to rely on oil to live the lives we live, I want to help them not waste the resource and process it safely so people aren't hurt.

Fast forward: in early 2012, my friend Fayez (remember Fayez?) was talking with me on the phone about Saudi Aramco where he worked. It sounded great so I asked him if he could get me a job there. I didn't think it would ever happen so I didn't tell anyone. It took over a year, a botched interview (they didn't receive any of the copies of my resume that I had sent!), and a thorough background check before I finally got the word that I was officially hired, around June of this year.

Now I'm about to board a flight and I still don't know what I'll be doing exactly. But I got my dream of working overseas in a different culture with the chance to learn a new language. Of course, I was hoping it would be someplace not as hot as Texas and a language that shared the same alphabet as English, but at least now I won't be eating cat food when I'm 80.

And I am looking forward to the new adventure and exploring the world around Saudi Arabia. That is, the places that aren't hotbeds of extremism and instability. (I'm not a thrill-seeker.)

Leaving Austin where I've lived for 17 years is bitter sweet. I'm ready for a change but it's difficult leaving the life I've built here and the friends I've made. But with Blaze having taken me all over the world, I'm looking forward to seeing more of this world.

Thanks a lot, Blaze.

Giving Up or Moving On?

A dead guy I never met changed my life.

Blaze Foley was an iconic Texas blues man who's legendary persona captivated people and sometimes changed their lives. Even in death, he continues to change people's lives. He caused me to change from an engineer to a filmmaker and back into an engineer headed for Saudi Arabia.

When I began the Blaze Foley documentary, around 1998, I was an electrical engineer and computer game developer living in Austin, Texas. I was 45, single, and looking for a side project when Blaze came along. I'd never met him, but the incredible escapades told by his friends and the narrative-in-songs were compelling enough that I knew pairing his music and life story would make a powerful film.

To tackle this mammoth project, I needed training and equipment. Not just training on the equipment, but training on how to tell a story with moving pictures. And I needed the equipment to somehow pay off the credit card debt from buying all that equipment. So Mopac Media, a filmmaker equipment rental company, was born. Incidentally, Mike Nicholson was my first customer and became Director of Photography for the Blaze film.

Mopac Media grew from being in my house to being in a van to a south Austin building to the house next door to ultimately a home in east Austin. As it grew, I went from keeping track of all the rentals using a physical calendar to a web application (thanks to Kai Mantsch, who recorded sound for the Blaze film and performed many other roles for it) to a full-blown Ruby-on-Rails webapp running the business today.

Somehow, Blaze had managed to indirectly take me back to being a full fledged software developer. Things were good, with year-to-year growth averaging 20%. Then overnight, High Definition hit and cameras became more expensive to buy and there were more models in demand, meaning more debt. Then the Great Recession hit which sent growth through the floor and revenue back to 2006 levels.

Meanwhile, the Blaze Foley project had taken 9 years to complete and, since I insisted on paying people for their work, my credit card debt had reached over 90% of my available balances. Since I'd been an engineer before being a filmmaker, I had good credit with many cards and high balances on each card. Yikes.

We struggled on, June Burnum helping me run Mopac Media, shifting balances, taking out home equity loan, becoming smarter about the business and slowly digging out of debt. As I dug, the banks weren't helping with increased interest rates. I still don't understand why they wanted me to pay down my debt while increasing their finance charges. Banks are evil.
 
In 2009, Blaze was finally finished and set to premiere at the prestigious SXSW Film Festival -- when the projector bulb went out. With 400 people from all over the world waiting to see it. Bummer.

I took this as a sign of opportunity and spent the next two years re-editing the film -- turns out, it wasn't really ready to premiere. Maybe Blaze knew that and spilled beer on the projector. In 2011, we previewed the film in Austin to five sold out shows. Then Gurf Morlix and I took it on the road to every songwriter club we could find in the US, Canada, Netherlands, Germany, Sweden, and Norway. And it screened at festivals in the US, Spain, Brazil, and Finland. This past year, I showed it in Australia, New Zealand, and Japan.

Now I'm heading to Saudi Arabia. I've sold Mopac Media to June, sold my house (which paid off my credit card debt, thanks to insane Austin growth), my car (to Chris Ohlson, Production Coordinator for the Blaze film), and gave away most of the crap I've accumulated over the past 17 years of living in Austin. The movers came and packed up the last bits to put on a ship bound for Saudi.

I've gone full circle, back to being an electrical engineer hired by a company valued at up to $10 trillion USD. The Blaze project was great, I have absolutely no regrets but I wouldn't touch it if I had it to do over. It didn't pan out as a viable retirement plan, so not wanting to eat cat food when I'm 80, I've gone back to work until I can retire. Fortunately, it fulfills my new desire to live overseas and learn a second language. I was hoping for a location that wasn't as hot as Texas and a language that shared the same alphabet as English, but this seems a wonderful opportunity to live in a new culture and learn more about the ancient world.

 As Blaze liked to sing, "You gotta move."

Oh, and I'll definitely keep making films -- it's an addiction.

Cells are bad ass

I'm researching Nick Sutterer's cells for rails plugin and loving it so far. But, love can be fickle and this is just infatuation. But again, so far, so good.

To me, the V in Rails' MVC is severely lacking. And by lacking, I mean it stinks. I wanted to reuse partials from other controllers, pass arguments around, that kind of thing. The stuff that makes an RIA easier to build (I just learned that acronym yesterday). Partials are slick for simple apps like blogs, but they really look butt ugly when they're thrown around inside a complex form. And I've heard that using a bunch of partials can be slow, which may or may not be a factor (YMMV). Cells claims to be fast, but at this point I don't care.

Cleaning out the Clutter

Now ... lets try out cells. First, I branch my code so it can be scrapped if I need to bail.

Here's what one of my views looked like before:

...

%h2 Categories
= render :partial => 'category', :locals => { :f => package_form }

%h2 Available Contents
= render :partial => 'shared/search_field', :locals => {:name => 'search', :value => @search}
= render :partial => 'potential_packages', :object => @package.potential_children, :locals => {:f => package_form}

%h2 Current Contents
= render :partial => 'child_links', :locals => {:f => package_form}

...

And here's that view on cells:

...

%h2 Categories
= render_cell(:categories, :selections, :form => package_form)

%h2 Available Contents
= render_cell(:search, :search_for_package)
= render_cell(:packages, :selection_list, :packages => @package.potential_children)

%h2 Current Contents
= render_cell(:packages, :package_children, :form => package_form)

...

It's a subtle difference, but to me a huge difference: it's cleaner and easier to read what's going on. Partials, with their hashes, really obscure the intention, IMO.

Here's the rest of the code for one of the cells. Here's the cell, located in file app/cells/packages.rb:

class PackagesCell < Cell::Base
def selection_list
render
end

def package_children
render
end

def package_child
render
end
end

No work to do, just the three "states" each with a simple render. By Rails-style convention, it knows where to find the file to render: app/cells/packages/package_children.html.haml:

- form = @opts[:form]
- children = form.object.children
- if children.empty?
%h3 -:- No contents -:-
- else
%table
%thead
%tr
%th Vendor Model
%th Min
%th Max
%th Default
%th Min Items
%th Max Items
%th % Discount
%th Remove?
%tbody
- form.fields_for :child_links do |nest_form|
= render_cell(:packages, :package_child, :form => nest_form)

Look -- nested cells for nested attributes!

Reuseable Cells

The real treat comes when I want to use those same searches and package lists elsewhere: I don't have to handle different cases, don't have to reference any directories, don't have to pass a :locals hash, and as a bonus, I get a cells "controller" class that can do some work with both the model AND the session, with an explicit render. Multiple render constraints are gone, finally. This isn't a treat, it's a freakin' desert buffet!

In addition, I get to delete many partials so my view/model directories are cleaner, with fewer files, and it's still easy to find the cells when you need to: just look into the view that's referencing the cell and there it is, the hierarchy laid out for all to see, easy to find in the app/cells directory.

Just to test all this theory out, I plunked a cell into another controller's form, changed the object.attribute reference (from @packages.potential_children to @contract.potential_packages), and the cells showed up, working. Not only that but I added the same cell a second time and changed the attribute (from potential_packages to potential_inventory_items) and it worked! Man, that's what I call DRY.

Hierarchical

Cells introduces a new directory, apps/cells, but IMO the layout is intelligent and well organized. It didn't take long to learn the DSL and organization (I was afraid it was going to be a long road to learn Yet Another Framework). This blog post by Mike Pence helped out a lot. Mike also gave a talk (aptly called Components Are Not a Dirty Word) along with Cell's author, Nick Sutterer, at RubyConf 2008.

Plus, it's Rails 2.3 compatible.

Thanks, Nick, for a beautiful plugin -- you've made me believe that V can be complete. I can't wait to put cells on apotomo for some dynamic interaction.

UPDATE: Russell has convinced me to not use cells. render :partials can be wrapped to reduce their noise, accept variables and be shared. I looked at the apotomo code and it's an exciting concept but looks very complex. I'm going to take a "wait and see" attitude for now, to see how Russell implements the JavaScript for the app.

UPDATE: I still like cells, but will wait until the app calls for one. So far, Russell's partial wrapper is okay but the view directories are getting kinda messy. But, it does put everything in one directory and we aren't using a lot of shared partials yet. Here's a link to a post that talks about presenters and cells.

UPDATE: Nick Sutterer and I will be giving a presentation on cells/apotomo components at the 2010 Lone Star Ruby Conference! I'm really looking forward to working with Nick on this presentation and implementing cells in the app.