While I didn’t officially “pledge” for this (bah), I thought I’d throw something out there for Ada Lovelace Day 2009 – March 24, and write about a woman in technology whom I admire.

When I first thought about participating in this, I had some severe writers block.  I just couldn’t think what or who I wanted to write about.  And as I reflected on why this was so tough, it occurred to me that most of that came from a thought that goes something like:

“dangit, people, why aren’t we writing about about inspiring people in technology.  What about people who inspired my career?  Why does it matter if it’s a woman?  I guess I just don’t get it.“

I, for one, want to be defined by – I want to be remembered as – many things, but not necessary because I am a woman.  Rather because I am a good developer.  Because I am intelligent.  Because I am a nice person.  Because I am a person who can figure things out.  Because I am a person who helps others figure things out.  Because I have good ideas.  But not because I am woman.

Then, a person came to mind: the first woman programmer I ever worked alongside: Clar-René Sliper.  I was a little, junior co-op, still in college.  She was one of the senior members of our group.  Aside from me, she was the only female programmer there.  (There were other women around, just not programmers.)

I remember wondering how she got into IT.  After all, there were so few women in my college classes.  I can imagine that finding women in the field was even more rare when she got into IT.  Yet whenever she was around, it just never seemed like – nobody acted like – she was any different than anyone else on the team.  She was smart, I never saw her ideas ignored, she never got walked all over or had to put up with crap from anyone.  And she never had to put forth any attitude to get that respect.  The only difference was her name was Clar instead of Jim or Liem or André or Dean or Matt or Dave.

It’s not unusual for people’s first experiences with things to shape them going forward.  Maybe those early experiences paved the whole way for me thinking: “People – this is not a big deal. Quit making it one.  Singling people out only makes it worse.”  You should admire anyone around you who deserves it.  Man, woman, white, black, Asian, disabled, etc.  Appreciate anyone around you who deserves it.  And treat everyone around you with at least a basic level of respect, no matter what.

I appreciate Clar for unwittingly showing me that it is not that hard, or weird, to be as competent and capable as everyone else around me.

I spent a little bit of time yesterday trying to figure out how to use Selenium to check for the presence or absense of a specific image used as the background of an HTML table.  It wasn’t that hard to do in the end, but I got a little tripped up trying to check for the wrong thing.  Pretty cool once I got it done, so I figured I’d share here.

What I tried to do:

At first I tried to grab the HTML text inside the TD and verify the presence of the filename of the image as text.

What I should have done all along:

What ended up working was that I knew the table row and cell in which I was expecting the image, and I had to do a “verifyElementPresent” instead. (Thanks to Dean for helping me figure that out)

The only thing I don’t like about that approach (vs. checking for text) is that I can’t do a wildcard search for the text.  I have to exactly check for the full path to the file.  So, if we decide to re-organize the directory structure and move some images to a “saltwater” and some to a “freshwater” subdirectory, the selenium test is then fragile and breaks.  But chances are the images are going to remain pretty static, so I am happy enough with this approach.

As I’ve mentioned before, I’ve enjoyed going beyond my local network of technical folks and attending regional events in Ohio and Michigan such as CodeMash, Cleveland Day of .Net (even though I’ve never been a .Net developer) and Agile Summer Camp. 

It’s high time I expand my Ruby-specific regional network, especially now that I’m getting paid to write Ruby code!

This weekend, I’m looking forward to attending the

Over the past year or two - through attending local user groups, regional conferences, and starting to use Twitter - I have enjoyed increasing my social network and expanding the IT community in my world.  I’ve met some amasingly smart and fun people that I’m glad to know.  And Twitter helps me keep in touch with these folks in ways never possible before.

It’s time to give a little bit back to the community.  Inspired by Jeff Blankenburg’s blog post: Celebrate Contribupendence Day! encouraging people to write recommendations for 5 people.  So that’s what I’ve done.  I’ve been pretty busy with the new job, summer & life in general, so I’m getting this out there a couple months later than anticipated.  But better late than never! 

Here’s the collection of my 5 Linked-In recommendations:

Mike Busch

Even though Mike was a fairly recent college graduate when I worked with him, he far exceeds the technical competence I would expect from other developers at his level of experience.  He not only does well at his work, he also takes the time to help out others with, and learn things within his areas of expertise.  Mike does a good job understanding and following the methodologies used by the team, and stepped up when asked to lead the team through a weekly code-review walkthrough on at least one occasion.  I enjoyed my time working with Mike.

Brian Disbrow

As a project architect, Brian does an excellent job of balancing his focus between technology, business, and the needs of his team members.  He is able to switch gears between talking about the details of the project, and talking about the big picture more effiently than most people I know.

Brian does a lot to help a team be successful.  He is willing to make decisions he feels are best for keeping the team moving forward, and stand by them even if the decision is not a popular one.  Brian has an acute understanding of the struggles and concerns of his team and works to improve upon these issues whenever possible, even in the face of opposition or, worse yet, indifference.

Brian is also an exemplary teacher, exhibiting patience and enjoyment in the process of helping people learn, regardless of their skill level.  He has the ability to easily recognize the level of assistance that an individual requires for a particular task, and is able to adjust the level of help he provides accordingly.  He is able to recognize team members’ strengths and weaknesses and to help people use their strengths while improving upon their weaknesses. He goes beyond just being approachable by making a point to ask people periodically “Is there anything I can help with?”

Kevin Munc

I worked on a project with Kevin where he was the tech lead on the project.  He is very intelligent, learns new things very quickly, and frequently shares his extensive knowledge with others around him.  This coupled with his ability to retain detailed knowledge about his past experiences make him an invaluable and highly competent tech lead.  His ability to think outside the realm of the way things have always been done in order to try a new approach is a major asset to the team.  He is easily approached and always willing to take the time to help people accomplish tasks and work with them to weigh options and figure out the best solutions to problems.  Kevin does a wonderful job making decisions on core best-practices that the team should follow to provide a high quality product. 

Dean Stautberg

Dean is the type of software developer who is able to both focus on the details of what he’s working on, as well as step back and see the big picture of the problem when necessary.  He is constantly keeping his eyes open for new technologies, ideas and tools that will help do things better or more efficiently than before.  He takes time to try out lots of different things in this quest, and is happy to share what he’s learned with others. 

Dean is very approachable when co-workers or other peers have questions, and he is patient and clear when helping others learn.  He is good at brainstorming and thinking of new things to do, or different ways to approach a problem if something isn’t working.  I would not hesitate to work with Dean again on future endeavors.

Ed Vaflor

Ed Vaflor is one of the best managers I have worked with so far in my career.  He is able to relate well to the people he manages.  He is able to see beyond politics into the reality of a situation, and come up with action plans and help others forumulate plans to move forward based on that reality. 

Ed communicates openly and freely about what he observes, thus promoting trust and openness from those around him.  It is my feeling that those around him want to work hard for him because of the rapport he creates.

eRubyCon 2007 was a great time in Columbus Ohio last year, and I will be attending eRubyCon again this year!

If you’ve always worked with version control systems that use file locking (where only one person can have a file checked out at at time, such as Visual Source Safe, PVCS or Clear Case), then getting used to a non-file-locking system (such as CVS or Subversion) is quite an adjustment.

It’s a change in the way you think, that starts with a change in terminology. Here’s a list of some terminology differences and best practices for use with non-file-locking systems.

TERMINOLOGY

• Add – Used to add new directories and files to the repository. Must be followed by a “commit” to finalize the change. Also note that a “commit” without an “add” will not include the new file or directory to the repository.
• Checkout – A one-time only action to retrieve all the code in the repository, and put it in a local working directory.
• Commit – Similar to “update” in other version control systems, this command is used to copy changes from the local directory to the repository. If adding new files, you must do “Add” before commit.
• Repository – the remote copy of your code base controlled by the CVS or Subversion server.
• Update – Similar to the term “check out” in other version control systems, this command is used to get the most recent changes from the repository, and put changes in your local working directory. This does not lock any files, nor prevent anyone from making changes to any files. If two people have made changes to a file, CVS/Subversion will attempt to merge the two files locally, and notify you if there is a conflict. This way, you have the most recent changes, and they will still be there when you commit your changes.

DAILY USE

• Always do an “update” before beginning your work, to make sure that your local working directory has the most recent code.
• Make your code changes.
• IMPORTANT: Before “committing” your changes, do an “update” once more to make sure you get any changes since your last update,
  
  • If someone else has been making changes to this file, and they committed their changes first, you will have to merge their changes in with yours before committing.
  • If you “commit” your changes without updating first, and someone else made a change to a file you changed, you will overwrite their changes! This is not a good way to make friends on the team
    
• After retrieving the latest code from the repository, it is a good idea to re-run any unit tests to make sure that your new code still works along with the new code just retrieved.
  
• If you have created any NEW files, you must first “add” them to the repository, or they will not be included when you “commit” your code.
• Finally, “commit” your code changes, both new files and modified files.
  

BEST PRACTICES

• Update Often! Most people check email several times a day. It is not a bad idea to get the latest code changes from everyone else several times a day. This will help more quickly identify things like API changes that would result in compiler errors, etc. The bigger the team, the more important it is to keep updating to the latest version of the code.
• Commit Often! No need to wait until you’re completely done with something before checking in.  There are several advantages to committing often.
  • More often you commit your code, the sooner everyone else on the team will have your changes.  If 2 people work on the same file, and you commit your changes first, it is the 2nd person’s responsibility to merge them together
  • Committing frequently also means you will be committing smaller chunks of code, rather than giant blocks of code changes that touch many files.  This reduces merge conflicts later, and reduces the chance that someone else will have to ask you about your changes if they are merging their code with yours.  Smaller chunks of committed code are much easier to merge!
  • In addition, it can be a good backup for yourself.  If you reach a good stopping point where things work to a certain degree, commit that code. If you do this often, and something gets screwed up, it makes it very easy to revert to what you know was a working version of code and start over, without losing a lot of changes.
• Do not commit broken code!  Your can commit your code even if what you are working on is still a work in progress. However, you should still follow a few rules of thumb.
  • Do not commit code that does not compile!
  • Do not commit code that causes unit tests to break.
  • Even if your code may not fully work yet, do not commit code that causes something else that was working before to break.

I’m pleased to announce that effective 6/9/2008 I have accepted a Ruby/Rails job with MedWiz Technologies. I’m taking the leap from Java, which I’ve done for over 9 years now, into Ruby, which I’ve been interested in for over a year. I’m very excited, somewhat nervous, but very much looking forward to this new opportunity and step in my career!

I just realized something I did not know about the JSTL <c:if … > tag recently.

I had assumed that the item in the conditional test had to be either a Boolean object, or some other expression that would evaluate to a boolean primitive type. But JSTL is also smart enough to handle the String value “true” as a boolean as well (I didn’t know that before!)

As a Boolean object, this results in putting fish in the water:

In the Java:
request.setAttribute(”aquariumHasWater”, Boolean.valueOf(someMethodThatReturnsBooleanPrimitive()));

In the JSP:
<c:if test=”${aquariumHasWater}”> <aquarium:putFishInWater /> </c:if>

As a String, JSTL is smart enough to know the String value “true” and deal with it as a boolean

In the Java:
request.setAttribute(”aquariumHasWater”, Boolean.toString(someMethodThatReturnsBooleanPrimitive()));

In the JSP:
<c:if test=”${aquariumHasWater}”> <aquarium:putFishInWater /> </c:if>

Many times we have methods that return primitive boolean values.

Since primitives are not objects, we can’t put them in the Session/Request/etc. We have to convert it to some Object. A Boolean. Or A String. So I got to wondering, which way is better? Does it matter?

So I dug into the way it works (thanks to the JAD decompiler) and figured out that ultimately, the String value is “coerced” (org.apache.taglibs.standard.lang.jstl.Coercions) into being a Boolean object, by calling Boolean.valueOf() on the String. So, it would be slightly more efficient to just call Boolean.valueOf() on the primitive to begin with, rather than calling Boolean.toString() on the primitive, only for the taglib to turn around and just call valueOf() itself.

For anyone curious enough to see this coercion code, here’s a portion of the coerceToBoolean() method taken from the org.apache.taglibs.standard.lang.jstl.Coercions class:

public static Boolean coerceToBoolean(Object obj, Logger logger) throws ELException {
  String s;
  if(obj == null || "".equals(obj))
    return Boolean.FALSE;
  if(obj instanceof Boolean)
    return (Boolean)obj;
  if(!(obj instanceof String))
    break MISSING_BLOCK_LABEL_70;
  s = (String)obj;
  return Boolean.valueOf(s);

  ... // more

}

This, like a lot of topics here I suppose, is not specific to anything technical. But being in an IT field, I’ve heard the term “man-crush” a lot and find it interesting and fun to talk about

Mostly, I think it’s funny. What changed it from “funny” to “interesting” in my mind, happened at CodeMash this past year (like many interesting conversations that happen outside of the scheduled sessions) when I had to define the term to someone who had never heard it before! Take a minute… think about it… what can you come up with?

.

.

.

.

My definition of the term was something like: when you admire someone so much it’s like you have a non-sexual crush on them. You want to talk to them, be around them, and learn as much as you can from them. A “technical crush,” if you will.

Brian Prince at CodeMash had a definition I liked even better: when you admire someone so much you just want to hug his brain!

The top-rated definition on urbandictionary.com defines the term as “When a straight man has a ‘crush’ on another man, not sexual but kind of idolizing him.”

And since then I’ve seen shows (new and re-runs) that have also used the term:

From “Seinfeld”:

“George has a ‘non-sexual crush’ on him, he’s like a school girl around him”

From “Men in Trees”

“You have a man crush!”

“I don’t have a crush on him. I just want to be him.”

If I recall correctly, the reason I brought this up in conversation at CodeMash, was to pose a question for the group to ponder and respond:

Can a person have a non-sexual, “technical crush” on someone of the opposite gender?

I think it’s definitely possible. I believe I have. The group had differing opinions. I recall one guy mentioning a female business partner that, in his opinion, fit that category. Yet another guy had the opinion that with some guys it’s never non-sexual.

Who knows?

I’m curious if anyone else has opinions on the matter. Or if anyone else has any other, better terminology.

• Can a woman have a “man-crush” on a man or would you call it something different?
• “Man-crush” seems to have a nice ring to it, but if a woman admires another woman technically in that way, you can’t really say it’s a “man-crush” right?
• I tried it out, but “woman-crush” doesn’t have the same ring.
• My term “technical-crush” is closer, but I’m not quite sure it captures the meaning.

I would love to come up with a better term that fits multiple admiration scenarios, and captures the full meaning. I’m still thinking.