Remote Pair-Programming

AgileApprenticeshipDesign processSoftwareTestingThoughts

Seems like Pair Programming is “all the rage” lately in my circles. I haven’t exactly done it before but after hearing about the success and rapid knowledge growth amongst those that pair program…I was almost dying to try it! Especially after i saw David Chelimsky and Corey Haines at WindyCityRails in Sept 2009. I saw them pair and do BDD with Rspec/Cucumber and it was so fascinating, It was like I was watching a ballet as they hopped from RSpec to Cucumber and back and forth. I was like, wow…I wish I was that good! I would have paid good money for a recording of that so I could watch it again and again! I see Corey Haines traveling around pairing with people too. Some people get together and play cards, but Corey gets together to code!

So ok, I like code, I like people, I want to try it! I live a little south of Chicago so its a long commute and it seemed everyone was so busy to pair in person when I asked. I asked on Devchix mailing list for suggestions on how to do pairing online. I had found a few, and the group had some good suggestions. I even had a volunteer to try it with me! This week aimee and I set a few hours aside to try it and see if we could do it!

This article was also sort of “paired” as it was written from my perspective with input and suggestions from aimee!

We asked on Devchix mailing list for suggestions on how to do pairing online. I had found a few, and the group had some good suggestions. I even had a volunteer to try it with me! This week aimee and I set a few hours aside to try it and see if we could do it!

After introductions on Skype we set about getting a shared environment in which to code together. Ideally, we wanted some kind of desktop sharing so we could run tests, console and editor.

We had heard of a few tools and got suggestions from the devchix list:

IChat desktop sharing – we couldn’t get this to work, we did different things and it would appear to connect but then it failed. I tried to mess with settings for Sharing on mac, but nothing doing.

Rio seems to be a library to make collaborative apps, not to use in a pair programming environment.

BeSpin was hard to use.. we couldn’t figure out exactly how to use it. It almost seemed to offer to import the git repository we were working on, but then it said it only supports Subversion and Mercurial, not git.

SubEthaEdit worked but we would have to open each file individually and share each file… unless I was missing something. This would be fine for collaborating on a single file but then we could not share the test runs, terminal commands or view the browser together.

Etherpad – we didn’t end up trying this but I have used it before to debug some code or try out ideas with a friend. They recently got bought by Google, so it would be interesting to see what they do with it. This would suffer the same limitations as SubEthaEdit in that it’s just a text editor.

GoToMeeting (which is $40-50/month) its a little steep for the open source work I want to do. But people say it works really well.

VNC and Unix Screenaimee had used this successfully before but since we weren’t on the same network, just our laptops at home, we weren’t sure it how we could make it work easily.

Then we came to TeamViewer which worked brilliantly! We shared desktop and I could type in aimee’s console window, see the tests running and type in textmate. Even with aimee on her Dvorak keyboard and I on Qwerty! I could type fine but couldn’t copy/paste with keyboard shortcuts so I used the mouse to copy/paste and it worked fine.

All in all, it was an awesome experience and I picked up on a few tidbits of knowledge from aimee on git, and rake! I had some bits of code from another project i was able to quickly copy/paste and get us rolling. We had a few discussions about coding style as we went.

Since aimee was more familiar with the codebase, she mainly wrote the behavioral specs and I wrote the code to satisfy them. We plan to switch around next time, when we pair on a different project that I’ve been developing for a while.

Book Review: "Refactoring in Ruby"

BookDesign processEventsIntroductionsRubyTestingTips and Tricks

“Refactoring in Ruby” written by William C. Wake and Kevin Rutherford.
Published by Addison-Wesley

This is more like a “workbook” then a “how to write awesome code” book. You can download the code from github and you will find tests/specs for the exercises.

The book is arranged in three parts, The Art of Refactoring, Code Smells, and Programs to Refactor.

There are explanations of “code smells” which are one characteristic of code that could be improved. Some of them are long parameter lists, unnecessarily complex, global variable, feature envy sections, etc. One thing I find interesting is the “How did it get this way?” section. It gives some insight into the thought process and reasoning behind the smell. I think this is good, as programmers our ego may be rather miffed to hear “This code stinks” but with some reasoning, it makes the pain less and I think firms up in our minds when this happens again, to do it this other way. I always want to know why when someone says I could do such and such thing better.

In addition to the code smell examples there are three programs to refactor in the end of the book. In a conversational tone, it walks through and gives some hints on what needs refactoring. Its almost as if you had a pair programming buddy working with you and identifying in small chunks what can be improved. This is definitely something I want to work through more carefully.

What I find odd, is that not all the code smells have code examples. The inspiration for the book I think is the Martin Fowler book “Refactoring Improving the design of Existing Code” which has examples for every code smell. Maybe Ruby smells less than Java? Or those fixes are really trivial? I don’t know. Overall, this is a great book and is certainly worth the price and investment and you will be a better programmer because of it!

Don't go splurging at the widget store

Design processIntroductionsThoughts

It is easy for clients, I have noticed, to mistakenly conflate adding widgets, effects and acronyms — Sliders, Sorters, Expanding-Menus, Oh My! — with implementing an idea. The client talks excitedly, rattling off a Rube Goldberg chain of widget-to-widget interactions, their voices rising, the importance of each and every widget in the chain perceived critical to the achievement of the Internet Holy Grail: Angel Investment. Or at least, a really slick site.

Don’t get me wrong. I think everyone is in favor of a well-placed widget.

They can be so smooth and beautiful that you gasp. They can glow yellow for just the correct duration before fading to white (“where has that beautiful apparition gone?”, you wonder, before drunkenly clicking again. And again. And again.). They can add an item to a list almost magically: never was it so fun to have so many things To Do. They can save you clicks, keep you in one place, slide items into carts with almost illicit ease.

In short, they can make things so simple that a tear comes to your eye, and you rush off, hat in hand, in the quest of The Holy Spinner to deliver your payload.

The Holy Spinner

But stop.

What are you looking for? Forget the elevator pitch, as it can be intoxicating: the sound of your voice, people nodding enthusiastically, the doors shut blocking their escape (especially if you are stuck between floors). Instead, do the quiet room test. You alone. Your idea. Naked. A convergence of souls.

“What do you need, Idea”, you ask, “in order to fully manifest your glorious Idea-ness?”

If your idea is quiet, do not rush to speak for it. If your idea speaks but is simple, do not scoff. Do not dress your idea up in Widget Drag, so it looks like a teenager searching for their identity at the Web 2.0 Store. If your idea does not need a Yellow Fade or slider, that is OK. If you remove the slider and yellow fade and find there is no idea underneath, that’s OK, too. Go for a walk. Another idea will come.

Think about building a UI like listening to the ones that you love. You observe them. You listen to their likes and dislikes so your gifts will please them, not reflect your tastes. It’s not about the shiny present: it’s about the connection, the need anticipated and met, a little bit of the edge taken off. Brush cleared, the path made simpler.

If you’re tempted to drive up to your date in the red corvette of ideas — or wow your user with the accordian navigation ’cause it like, opens and closes! — remember that you might be saying more about yourself than anything else.

And then ask yourself: Do you need that rainbow-colored slider on your site?

The journey towards achieving the devchix theme.

Design processThoughts

Emergence of the blog —
Nola hooked us up a few months back and devChix members are now entitled to post and share ideas with the world via this blog using the Word Press blogging engine. This was our very first intro post from Liz, one of our Perl girls, and then everything came rolling in. Yay! The initial theme was screaming pink (Leone by Andiz) and served its purpose well. But surely, back in everyone’s mind was the wish to have a look and feel that we can call our own.

The beginnings –
Back in September of 2006 immediately after the launch of the devChix blog, one of our lovable members, Victoria proposed some logo ideas for devChix. We all picked the girl with the beaming radio glow. Four days later, I helped enhance Victoria’s great idea with this devChix logo set using funny lip spoofs. We were all excited, threw in all our ideas and concerns like too much red lipstick, or not enough girlishness or too much of it. Of course this was a back and forth dialog with women! smiley face Then majority wanted a code/programming element within the logo so here came another set. In this last set, we have four variations: the matrix-adapted 1s and 0s feel, the radio beaming glow effect, the simple #hash element and the vertical numerics. Suffice it to say, Neo’s camp won.

After the holidays –
We’re all awol due to the holidays. That’s fully understandable. We nudged and chugged with a few post for events and things some of our talented folks have been getting into. It’s different now. About a week ago, everyone is pitching in and volunteering to post on allotted scheduled times. Thanks to this rekindled enthusiasm, I was engaged and prompted to contribute. I have the devChix logo, which I’ll use to influence the design of the theme.

Theme in early stages —
Using the logo, I tried to get a simple look. This was the beginning of my first comp/mock-up. It didn’t feel right. It had the look of “a cotton-candy-sky-world met screaming blue”. Oh no! from screaming pink to screaming blue! I stopped cause this is not the path I want. I took a break and leveled my hunter. Wow is a good distraction for me at least. While I was riding the gryph, it hit me that I was seeing a lot of different colors. Colors! I came back to the drawing board. The first comp was missing contrast. I could use bold colors with a subtle presentation. Err! Yah! Now I have the colors dealt with. Then came rounded or edged? (That’s such a 2003 question). The quick addition to outdated things of sorts was swirls and warping and an illustration feel. From simple to funky, spicy and hot – my second comp.

Get friends/or not friends to critique your work –
I am by no means a full time designer (nor great) but I know my way around Photoshop and I am very handy with CSS. I do coding most of the time too with Coldfusion and PHP. I love doing both design and code! But I learned that in order to make pretty things useful, you need to have someone ruthlessly nitpick the design. Feedback, good or bad, is your best friend. Listen to the points raised and evaluate it by trade if they’re valid. The feedback I got was that my colors are now too dark and readability is an issue. With a simple color swap – this is my third comp. A total of 26.9 KB for 15 image files, a 2kb css file and this skeleton mark-up, that last comp is now converted to fit a new Word Press template to get the same look.

I hope I also achieved an easy way finding route for our navigation versus our old category set up that looked so clunky. I look forward to the days when we’re able to work on code and design our own apps here at devChix. Cross-fingers!

Work on validations –
It occurs to me that the site can’t validate when content is mashed into the template. That’ll be the tweaking part I hope to smooth in the following days.


Thanks to devChix for the opportunity to play. I had fun putting the theme together and thank you for stopping by! /rockon

2/20 8:25 am
Fixed known OmniWeb, Safari and Camino Search Box render issues. Thanks to J. Rentzsch for the screen shots!

About Carmelyne Thompson

With 14 years experience in web development consistently learning new technologies; Loves: user interface design, programming & being an entrepreneur

More Posts by Carmelyne Thompson - Author Website

Waterfall? Spiral? Who cares?

Design processThoughts

When I graduated with a CS degree, lo these many years ago, I had no idea how software was actually built, despite several quarters of “software engineering” courses. These classes covered the classic “waterfall” model, in which a list of requirements leads to an architecture leads to coding leads to testing leads to release (and woe be to the project that does these out of order or interspersed) and also the slightly newer “spiral” model, in which a little bit of requirements analysis leads to a little bit of architecture leads to a little bit of coding leads to a little bit of testing leads to more requirements analysis and so on until you’re dizzy.

So I went out in to industry, and discovered that how software is actually built has nothing to do with a waterfall or a spiral. It is, in fact, much messier.

The spiral model is, however, the basis of Scrum and XP and other agile methodologies, in which you do a little bit of work, make sure everything’s OK with your customer, change direction if necessary, repeat until you’re done. What agile methodologies add to the spiral is the explicit acknowledgment that creating software is a social act. Communication at the right time with the right people often makes the difference between building the right product and building the wrong product.

The waterfall and the spiral and other formal models such as the “surgeon” don’t model real-world software development very well because they ignore the impact of communication skills. The agile methods do not. XP, for example, sets up a formal channel of communication between the customer and the programmers. It also sets channels within the programming team via pair programming, nightly check-ins, and automated builds.

I recently started reading current academic papers on software engineering again, and discovered that many researchers still use the process model of “requirements -> architecture -> coding (repeat as necessary).” They think it is how software is built. They look for ways to improve a particular phase of that process.

In general, they completely miss the social aspect of software production, which is really what determines whether a project succeeds or fails. Creating software is inherently a chaotic event that depends on forces we can’t (currently) model formally. Perhaps they’re uncomfortable with something they can’t reduce to a diagram, but if they continue to ignore it, the gulf between what academia thinks we’re doing and what we’re actually doing will continue to grow.