Never be ashamed of where you came from!

I am frequently asked my opinion on how to encourage more people people to get into software development. My response frequently is:

“if people aren’t interested in software development, why force them to be?”

I enjoy hearing people’s various responses to my often unexpected follow-up question. All the while, I have my own answer to the question: I don’t think we want to force it, but we do want to make absolutely sure we’re not discouraging people either.

Lately, I have heard way too many people actually apologize for languages, platforms or technologies they once used. I’ve heard it in one-on-one conversations, in groups, even from a speaker addressing a local user group. Soon it struck me: YOU SHOULD NEVER HAVE TO BE ASHAMED OF WHERE YOU CAME FROM. It’s what makes you uniquely you, it gives you the unique perspective that only you have to bring to the table. I even hear people apologize for the languages, platforms or technologies they currently use. And I also feel YOU SHOULD NEVER HAVE TO BE ASHAMED OF WHO YOU ARE.

Please, let’s make sure we’re not making people feel ashamed of who they were, and of who they are.

I think a lot of people in IT tend to be very opinionated, er, I mean very passionate about their craft. Passion is a great thing when used for good and not for evil. But on more than one occasion I’ve heard people say that they stopped attending a local user group because whenever they went, they were made to feel bad about being “the [insert technology here] guy” (the .Net guy, the Java guy, the Python guy, the PHP guy, whatever) and sometimes to the point of feeling they have to defend who and what they are. That became very tiring after awhile, and they quit attending the group. Do we want to share the Ruby love or not? We all lose if we don’t. This person is no longer learns about Ruby and Rails at their local user group every month. And that Ruby community no longer has the unique point of view that only that person could have contributed if only people would listen.

Please, let’s welcome people who are different from us, and not try to change them but embrace them.

Dave Thomas spoke in his keynote at RubyConf 2010 that we, as a community, may be unaware of what we may do or say to discourage people into joining us. I hate to say it, but I think the Ruby community not seen as the most welcoming bunch. We have good intentions of welcoming. On the surface, we are. When it comes down to it, I get a feeling that we unknowingly making people who do not use Ruby, own Macs, and have iPhones feel very out of place. That is not a good feeling. It’s not a warm feeling. It’s not a welcoming feeling. I’m not saying this kind of thing isn’t prevalent elsewhere, but the Ruby community is what I know best right now, and it’s where I see it right now.

What can we do? I encourage and challenge everyone, the Ruby community especially, to be more welcoming.

  • Next time you are talking to a fellow technologist, and you hear someone says they are a .Net or Java or whatever developer, resist the temptation to say (or even think) “ohhh, I’m sorry!” You may be joking. And it may be appropriate to joke in that way with someone you know very well who knows without a doubt you are joking. But what you may not realize is who else is listening. There may be a person over in the corner who doesn’t know anyone at the user group yet, but is within ear shot of hearing you. That’s the impression they will get of how this Ruby community welcomes n00bs and people of other technological backgrounds.
  • Lead by example. Don’t criticize or look down on someone who uses a completely different language than you, or uses a different operating system, or chooses a different editor. Don’t strong-arm someone into seeing things your way. Never TELL someone that they should love something. Show them what YOU love about it, the rest will follow. Or it may not. But that’s all you can do.
  • Next time you’re at a user group meeting, make a point of talking to someone you don’t know. Maybe it’s someone who’s been coming for awhile but you have been too busy to notice. But maybe it’s someone who’s new and will appreciate that someone went out of their way to be nice. Find out what they do, but never judge. Find out how they got interested in Ruby and encourage that. Tell them what made you get into Ruby, but make sure they never feel they have to have the same reasons as you.

Go forth and ENcourage!


RubyConf 2010 Highlights

This year, I attended my first RubyConf on Nov. 11-13. It was a blast! I’ve attended lots of local and regional conferences in the last few years, but it’s been awhile since I’ve been to a larger conference.

I went to a lot of great sessions, & learned lots of things from lots of people. I won’t be able to cover everything I learned, as even now it’s all still soaking into my brain-sponge. Nor could I possibly name all the great people I met & talked to, & all the great places we went. So here’s a few highlights:

Top 5 favorite things of a non-technical nature

:hanging out with Marc Peabody => Marc is my peer, my cousin (b/c he married my cousin), & my friend.  I’m happy we got to know each other better as a result of heading out to Bourbon St. w/ the group, & staying out way too late & having good conversations that usually don’t happen among people at a conference until later in the week.

:beignets => a wonderful, delicious, donut-like pastry piled with tons of powdered sugar that we experienced at a place called Café Du Monde in New Orleans.  Funny thing is I spotted powdered sugar as I stepped onto the escaltor at the hotel on my way to my room that night! I found powdered sugar still clinging to my jeans on my way home, too! It’s everywhere!

:making new friends => including getting to meet Sarah Mei in person, who I’ve followed on Twitter for awhile now, & going out dancing the last night.

:getting up EARLY to run in the rubyconf 5k => mornings are hard enough for me, even more so after getting only 3 hours of sleep the night before.  But I did it!  And if that’s not positive enough, I finished the race in less than 50 minutes, including time to stop or slow down to take pictures! Bonus! I’m not a runner, so that’s a pretty good time for me.

:meeting david heinemeier hansson => and having a normal-person conversation about Rails, dynamic typing in Ruby, & Rails in mobile browsers.  Well, it was a normal-person conversation until I asked him to sign my conference t-shirt, haha.  He kindly obliged without making me feel ridiculous for it. And because of that, I decided to go get Matz to sign my shirt too!  How cool is that?


Top 5 things of a more technical nature

:Knocking Ruby’s Date & DateTime Performance Out of the Park with home_run – Jeremy Evans
=> This talk was about why the Date & DateTime classes in Ruby are slow, & about the ruby library “home_run” & how it works to speed that up. I’m really hoping to get time this week to try this out at work, run some benchmarks, and hopefully it will help some slower parts of our app.

:Writing games with Ruby – Mike Moore
=> This talk introduced us to the Gosu library for game programming in Ruby. Now I just have to figure out what kind of shenanigans I can get into with this new knowledge! 🙂

:RedCar – It’s time for a Ruby editor – Daniel Lucraft
=> This is an editor that installs as a gem. My understanding is that you can run Ruby commands, like you would in IRB, to extend the editor, make plugins or even edit your code if you want to. I like my RubyMine, but am curious how something like RedCar handles a very large rails project.

:Concurrency: Rubies, plural – Eleanor McHugh, Elise Huard
=> In talk the speakers discussed things like threads & fibers in Ruby that are used for concurrency. Unfortunately I was sitting way in the back & could not see the slides or code examples. However, I was able to follow along enough to get some ideas about some specific things I’d like to look into later.

:a cool introduction
=> At one point in the week, I was introduced by a former co-worker Jeff Lembeck to someone he knows as follows: “This is Gayle, she taught me Rails.” It was a really a good feeling to be regarded in that way.  Having trouble expressing in words how that makes me feel. Good. Worthwhile. Valued. Something like that.


:I’m not going to talk about this here => there’s been quite a bit of talk|debate|arguing on Twitter after RubyConf this year about the diversity of the various keynote talks. I’ve got a chaos of thoughts bouncing around in my head on that. If I can get my thoughts organized, maybe there will be another blog post coming soon.


One thing I’d like to take away from all the inspiration I’ve gotten…
:I really need to write in my blog more regularly!
=> I have a growing list of ideas & things I’ve learned that I’d like to share. I really don’t like to get up & speak in front of people. This – blog – is a much better way for me to do just that.

OSU Ruby on Rails

8 months after stepping so totally out of my comfort zone, speaking at Columbus Ruby Brigade, not remembering most of it because it was such a nervous blur, and swearing off public speaking again for a long time (if ever) – I surprised myself recently.

When the OSU Ruby on Rails group sent out an open invite to the Columbus Ruby Brigade (CRB) mailing list, inviting anyone who might like to speak, a little voice in me said maybe I should give it another try. A bit surprised the thought even crossed my mind, I talked myself into it.

For whatever variety of reasons, I don’t think I ever 100% convinced myself that I was qualified to speak at CRB. With some hard work I could probably get over the fear and insecurity. And yet, I’ve said before, public speaking has never been a passion of mine so I see little motivation to actually overcome it.

For whatever variety of other reasons, I didn’t have as much trouble convincing myself I am qualified to speak to a small group of college students. Small group being the biggest factor. I suppose knowing that I have more experience than people in my audience was something else to ease my mind too, not necessarily so at CRB.  And for this time anyway, they were OK with me re-using my previous talk on sorting in Ruby, so it helped that it was a talk I’d given before.

Three things to put me at ease. And put  me at ease it did. I didn’t incessantly rehearse/memorize what I was going to say this time. As a result I have a feeling my speech was more fluid and conversational. The guys were great and asked good questions, too.

So, I did it. I’m still not sure if/when I’ll do it again, but I’m not running for the hills either.  So we’ll see where it takes me.

CodeMash 2010

I’m happy to have

the priviledge of

attending CodeMash

yet again this year!

And I’m glad to have been able to help out and give back this year. I went and picked up the t-shirts this afternoon.  All 700 t-shirts, in 11 boxes.

It’s hard to believe that all of these fit in my car! All I can say is, I love my Honda Civic.  It may not be the biggest car, but it’s designed well I’d say, and makes efficient use of the space that it does have.

Check it out, this is awesome.  Big thanks to the guys at Ares Sportswear!

Model – View – Controller (MVC). Where do you put your business logic?

When I first started doing Rails development over a year ago, I often found other developers suggesting that I refactor my code to move the business logic out of the controller, and into the model.  After this happened several times, I wondered why this seemed so obvious to them, and why that wasn’t the way I was naturally doing things.  It wasn’t just me and another developer approaching problems in different ways.  It was multiple people approaching problems in a similar way — and then me.  I wondered why there was this general difference in thought processes and solutions?

I began to passively wonder if my background in Java was contributing in some way to my way of thinking here.  Since then, I have also heard other Rails developers who are working with former Java developers say things like

"these are good developers but they keep putting business logic in their controllers!"

That made me think more seriously about what a person’s Java background might have to do with this.


In earlier days of PHP, classic ASP, and early JSP, it was OK to put business logic in the view.  Back in the day, it was common to find <% %> tags in JSPs with all kinds of logic in the Java code.  I think we all now agree that business logic does not belong here. 

let the view deal only with DISPLAYING what it has.


It seems like I’ve spent a lot of time seeing a model as simply a data-holder class.  Something like a Struct in C.  Something like a Bean in Java, with private attributes, and with get/set methods for each attribute.  It’s just a data transfer object, nothing more.  But why?  Perhaps it comes from my EJB days.  That might explain why so many other former Java developers do the same thing.  To us,

the model carries data but is dumb. 


I always thought of the controller as being the one smacking around the model objects to get them to do what the controller wants – and

what the controller wants the model to do, is the business logic. 


Give the model more credit.

The model isn’t so dumb after all.  It doesn’t just hold state.  It contains the business logic behind the behavior of that model.  A model knows better than any other code how itself behaves, what it does or does not do, and how it interacts with the outside world.  I can try to predict how my brother will behave in a given situation; I can take a guess based on what I know about him.  But only he knows for sure, and the only way I can know for sure is to interact directly with him and find out.

Let the controller control the flow of information.

This leaves the controller with only the responsibility of collecting information and routing it to the right place.  It’s the electronic curator that finds and obtains art, and hands it off to the decorators to display.  He decides what pieces go in which rooms.  However, the decorators (analogous to the view) are the ones that decide how to arrange the art within that room for all to see.

I still need to be reminded sometimes to not put so much logic in my controller.  It is starting to come more naturally to me, but old habits die hard I suppose.  This way of thinking makes more sense to me now that I understand where my past way of thinking comes from.  I like this new way because it really makes sense now, and also because

I find that code re-use comes much easier when needed business logic is already available in the model.


Posted in code. Tags: , . 7 Comments »

Ruby Sorting [2] – Common Mistakes When Sorting With Blocks

This sorting technique is one I’ve had a chance to use at work more lately. But what keeps tripping me up is when you use the block to sorting primarily by one field, with a secondary sort on another field. Let’s say Fish has species and type, and we have these fish in our database:

species type
Platy Sunset
Platy Calico
Molly Dalmation
Platy Rainbow
Guppy Fancy Tail
Platy Mickey Mouse

When I sort first by species, then by type, I keep accidentally doing the following, which gives the wrong sorted results:

>> fishes = Fish.find(:all) 

>> fishes.sort do |a,b|
?>   a.species <=> b.species
>>   a.type <=> b.type
>> end

Doing that, I end up with a list like:

species type
Platy Calico
Molly Dalmation
Guppy Fancy Tail
Platy Mickey Mouse
Platy Rainbow
Platy Sunset

It ignores my first sort on species, and ends up sorting only by type!

Why? What’s wrong with that?  Well, the <=> comparator function (also known informally as the “spaceship operator”) returns either -1, 0 or 1, depending on whether the first value is less than, equal to, or greater than the other.  The block will return the last statement evaluated.  So what happens is we compare species, then we then compare type, and it is always the result of the type comparison, -1, 0 or 1, is returned from the block.  The problem is, if species is not equal, then we want to stop there and return -1 or 1 accordingly and not evaluate type at all.

A simple way to do this is to add “if result==0” to the end of the type comparison, and only evaluate type if species was equal.

>> fishes = Fish.find(:all) 

>> fishes.sort do |a,b|
?>   result = a.species <=> b.species
>>   result = a.type <=> b.type if result == 0 
>>   result
>> end

This way, it will perform the first search by species, then only continue to perform the secondary search if the result of the first search was zero, that is they were equal values. And so I end up with a list like:

species type
Guppy Fancy Tail
Molly Dalmation
Platy Calico
Platy Mickey Mouse
Platy Rainbow
Platy Sunset
Posted in code. Tags: , . 2 Comments »

Ruby Sorting [1] – When and Why to use sort_by()

When I read the rdoc on sort_by, I understood the general idea that sort_by is more efficient in some situations. The specifics on why were still over my head, so I wasn’t planning to get into specifics during my recent talk on sorting. Yet just a few hours before my talk Jim Weirich was still trying to cajole me into using big words like “Schwartzian Transformation” in my talk because, he teased, “using big words makes you sound important :)”

The good thing is that this gave me a chance to talk it out with him, and actually understand it for real. It was too late for me to add that into my talk a few hours before I was to give it, but I do want to talk about it here now that I understand.

sort_by() is good if the values you’re sorting on require some kind of complex calculation or operation to get their value.

Let’s say you have an aquarium, and you save the dates of when each fish is born in a database. Later, you want to sort the list of fish by age. But you must calculate the age based on the birth date. So the Fish class has an age method:

class Fish
  def age
    ( - birthday).to_i

So when you sort like this:

>> fishes = Fish.find(:all)

>> fishes.sort do |a, b|
>>   a.age <=> b.age
>> end

It will calculate age over and over as it sorts. And if you’ve studied sorting algorithms, you know that the items in the list are compared with other list items repeatedly until it can be determined where the items go in the ordered list. So using this way of sorting, the age will be calculated a lot!

When you use sort_by() instead:

>> fishes.sort_by do |a|
>>   a.age
>> end

It does 3 things:

1. It will first go through each item in fishes, calculate age, and put those values into a temporary array keyed by the value. Let’s say we have 3 fish, one 300 days old, one 365 days old, and one 225 days old. The temporary array looks like this

[[300, #<Fish:A>][365, #<Fish:B>][225, #<Fish:C>]

2. The complex calculation is now done, once for each fish. It sorts this temporary array by the first item in each sub array. Meaning, it sorts by the numbers 300, 365 and 225, without recalculating them.

[[225, #<Fish:C>],[300, #<Fish:A>][365, #<Fish:B>]]

3. Lastly, it goes back through the array, grabbing the 2nd array elements (the actual Fish objects) and putting them in order into a flattened 1-dimensional array

[#<Fish:C>, #<Fish:A>, #<Fish:B>]

So, that is how you end up with a sorted array without recalculating values more than you need to. And that is why sort_by() can be more efficient.

Posted in code. Tags: , . 1 Comment »