WTF: The Mythical Business Layer

Eric Hodel | Fri, 28 Sep 2007 07:11:43 GMT

Worse Than Failure made a post a few days ago about, among other things, built-in complexity, especially where its unnecessary and unsuited for getting things done.

Just look at the dreadful specs we’re given to work with:

When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.

I’m sure those of you who managed to make it through that spec did not have visions of IF-ELSE code blocks swirling through your head. I’ll bet some of you, without even seeing the rest of specs, excitedly envisioned a CancelationWorkflowProvider that inherited from the abstract RequestWorkflowProvider and implemented the IPermissionRequired, IPropogationStatusRequired, and IExpenseAllocationTypeRequired interfaces, and was powered by the all-encompassing WorkflowManager. Why? Because that’s so much more challenging than writing a simple IF-ELSE code block.

The Mythical Business Layer via Worse Than Failure

While the post focuses on the “business layer” of an application, it is applicable to any development. There’s no need to write that extra library! Start with the core of you want to do, and grow, then refactor, then grow again. Reuse what already exists unless it can’t be molded to your will. If your application code gets too big pull a library out. Don’t write the library up-front, you don’t need it and you won’t need it.

Posted in  | 2 comments

Finding Random Reading

Eric Hodel | Mon, 20 Aug 2007 03:13:43 GMT

I’m really missing what reddit used to give me, which was things I liked to read that I didn’t know I wanted to read on the front page. Now reddit is full of dups and political stuff I don’t care about. It also has a recomendation feature never worked for me, I couldn’t tell the difference between it and the home page.

Google News solves the dup problem but has too much stuff I don’t care about. Sometimes it makes me laugh, but it still doesn’t tell me what to read, or even what I probably will like.

The recommendation service I love is Netflix’s, I’ve rated over 350 movies now and it is spookily good at picking movies I like. For example 11:14 has a silly-sounding plot summary:

Five seemingly random story lines intersect at precisely 11:14 p.m. in this innovative drama-thriller written and directed by newbie filmmaker Greg Marcks. Even though they’re strangers, Buzzy, Mark, Cheri, Jac and Eddie will become a part of one another’s lives—even if it kills them.

I forgot why I added it to my queue. When it arrived I thought it would be silly, but I really enjoyed it, and that wasn’t the first movie I’ve experienced this with. Also, it tells me to watch things like Afro Samurai and Tinker, Tailor, Soldier, Spy that I would never hear about or know about otherwise.

What I really want is Netflix for for my random web reading. I don’t care about what’s popular, I care about what is well-written and interesting. Does this kind of thing exist yet?

Until then, I think I’m going to switch to clicking wikipedia’s Random article button when I get bored.

Posted in  | 5 comments

Vacation!

Eric Hodel | Wed, 01 Aug 2007 19:18:10 GMT

Yesterday was my last day working for Lime Spot, so now I’m on vacation for the month of August.

Most of my time is going to be spent working on various bits of software, like adding the automatic platform selection to RubyGems and getting it ready for inclusion in ruby 1.9, cleaning up some RDoc and ruby documentation tickets and going through the rest of my open tracker items on RubyForge.

But today, its time to watch the Simpsons movie, then Taxi Driver!

Posted in  | 3 comments

New Blog Design

Eric Hodel | Sun, 29 Jul 2007 04:02:43 GMT

I got this awesome new design from Jordan Isip, fellow Seattle Ruby Brigade member in exchange for some help on his DailyCaption project. Any lack of awesome is purely my incompetence at applying it.

Incidentally, Jordan is thinking about looking for some work. He’s primarily interested in front-end/UI work, but is a good RoR programmer as well, and a quick learner. Check out LunchFilter for an example of his work.

Posted in  | 5 comments

Later that month: healing

Eric Hodel | Sun, 31 Dec 2006 09:09:47 GMT

Why the Lucky Stiff posts a year in review for 2006:

April – Canada on Rails. DHH says the F-word. And flips the crowd off or something. It’s a pretty serious deal. Later that month: healing.

A Fine Time, Oh Yes! via RedHanded

Posted in ,  | no comments | no trackbacks

Takahashi Method

Eric Hodel | Tue, 04 Jul 2006 07:16:00 GMT

M. Edward (Ed) Borasky wrote:
> Pawel Szymczykowski wrote:
> > On 7/3/06, James Britt wrote:
> > > Thanks for pointing this out.  I recall when this was
> > > first suggested, and I'm glad it just faded away.
> > 
> > Pfft.. what are the kids all suposed to go out and get
> > tattoos of then?
> 
> Celtic symbols.

No, Japanese characters.  That way yo can use the Takahashi
method to give a presentation simply by removing your
clothing!
-- Daniel Berger, ruby-talk 200090

Posted in ,  | no comments

Keyboard Cleaning

Eric Hodel | Sat, 01 Jul 2006 05:31:25 GMT

I spilled a bit of Henry Weinhard's Orange Cream Gourmet Soda onto my Powerbook's keyboard and had sticky tab, shift and q keys. After sufficient annoyance I searched google for how to remove the key caps so I could keep them from sticking when I let go of the key. This guy who did a dvorak conversion of his G4 Powerbooks had the pictures I wanted, they demonstrated that the key caps should pop right off without breaking. Instead of his fancy key-puller tool I just used a 1/8 Craftsman flat-head screwdriver to pry up the edge of the key cap. I pried off the bottom, but it may be better to take the tops of first due to the construction of the riser. For the q and a keys were hard to reattach to once I took them off because the scissors riser came apart. I had to remove both pieces of the riser, snap the two pieces back together then re-attach it to the keyboard. I used the screwdriver to help guide riser parts back together. One part has posts that fit inside the other, so I used some careful pressure to guide them together. The key-cap should snap down easily after the riser is correctly installed.

Posted in  | no comments

RubyConf Lightning Talks?

Eric Hodel | Wed, 28 Jun 2006 19:45:58 GMT

My secret sources tell me that due to the overwhelming success of RailsConf's lightning talks there just might be lightning talks at RubyConf 2006. Well dblack...

Posted in  | no comments

Keyword Assistant

Eric Hodel | Mon, 29 May 2006 05:22:18 GMT

I use Keyword Assistant with iPhoto to tag all my photos before uploading them to flickr. Unfortunately it has the unfortunate habit of running back to a compatibility mode when run on a version of iPhoto which it doesn't know about. This means Keyword Assistant won't make new keywords until the author releases a new version. There is a not so simple way around this restriction, I just opened up the KeywordAssistant binary which lives in /Applications /iPhoto.app /Contents /NetServices /Bundles /KeywordAssistant.NetService /Contents /MacOS/ and change the stored version to the current version of iPhoto. In this case I bumped it from 6.0.2 to 6.0.3. Naturally this kind of hackery might cause Keyword Assistant to do bad things like make iPhoto crash, so save a backup of that binary (and maybe even a backup of your photo library data files) before changing things around.

Posted in ,  | no comments

Ruby Method Size

Eric Hodel | Wed, 10 May 2006 18:15:58 GMT

On ruby-talk Pistos started a thread on Method Size – Best Practices based on a previous post by me where he asks what a good method size is.

Ara responded with:

i think this is a bit silly really, i have several image processing programs that are 5000 lines of code. the longest method is around 100 lines and alreadys calls 20 other methods. breaking it down further would simply obfusicate the code. the size of methods it going to be related to the complexity of the task at hand. rather that thinking in arbitrarily limited terms like ‘10 lines’ or ‘20’ i think it’s best to always strive to write less code and the make is clear first and fast second

Which I agree with:

A good and acceptable method size should be almost entirely based on comfort. Trying to artificially constrain yourself is only going to lead to bad code (and stress).

My coding style (with TDD) leads to 10 to 25 line methods because those are most comfortable.

I want to enjoy what I do as much as possible, so my “proper coding practices” come from listening to my code. My code tells me when it is too complex, too long, poorly factored or just plain ugly. If my code is telling me these things I’m not having fun, so I listen and adjust so I don’t write code the wrong way in the future.

Posted in  | no comments

Older posts: 1 2 3