Crossmap-mechanitis

Monday, February 14, 2011

For those who might want to make the leap from Developer to Architect

Posted by Unknown on 1:42 PM with No comments

The last two weeks, actual work has conspired to keep me away from the blog. How rude. I miss "the beach" already.

It seems only fair to summarise the lessons I have learnt whilst masquerading as an architect on a short consulting stint with Marc McNeill. Simon Brown at Coding the Architecture is much better at talking about this stuff than I am, but I need to update the blog with something!

1. Ask dumb questions
Someone's called you in because they want your help, and presumably if their problem was simple they would have fixed it already. You're not there to know everything out of the box, you're there to find out what's going on and summarise it. That means asking questions, even the dumb ones. That's something I learnt off my previous boss.

2. Draw lots of pretty pictures
As a developer, I like to think in code, I like to poke around it to find out what's going on. But if you want to get a feel for the bigger picture, not having access to the code, or even the documentation, could be better. It forces you to look beyond the detail. Sketch things out on the whiteboard to help get the picture of the domain and the systems in your head.

Of course, there's always the worry that your pictures aren't the reality. That's why you need to...

3. Check your theories/pictures/numbers with everyone
In the first week of the engagement I made some assumptions based on the information I had gathered so far. Once I'd run those past the architects and developers really working on the code, I found they were only half the story. The feedback from those guys helped evolve the picture of the current state of play, and shaped the future direction.

4. Take notes
Especially of acronyms used and people's names and roles.

This is probably more a "me" thing. My memory works as an index, so I need the detail somewhere - I can remember I wrote something about something, and where I wrote it, but I won't remember the details. I also find that simply writing things down helps to get it straight in my head. I probably didn't use 50% of my notes, but all that information was in my head.

5. Buy your own whiteboard pens!
I've worked in a lot of places, as a consultant and a permanent employee. And one thing you can almost guarantee is that the pens in your meeting room will not work. Or they'll be permanent.

I also bought a board rubber and spray cleaner, but that's probably my OCD....

At the end of an intense two weeks we had delivered:

A picture of the existing architecture
Pictures of three phases of future architecture
An approximate roadmap for delivery
Guide estimates for the stories discovered
...and pages and pages of supporting diagrams and information.

The air in Les Alpes must've helped get the brain moving! Of course, I took my camera on my little jaunt to France.

It was a great first role for me at ThoughtWorks. I worked my socks off and thoroughly enjoyed it.

Friday, January 28, 2011

CSS for Developers: Cross Browser Table Border Behaviour

Posted by Unknown on 2:53 AM with No comments

One of the aims of this series is to highlight some stupid gotchas in support for CSS in the different browsers.

Today's gotcha is table borders.

Yes, yes, I said don't use tables. What I means is, don't use tables for layout. But you can use tables for, you know, tabular data. Like, for examples, lists of instruments and their bid and ask prices.

But you should know that even when you use strict mode, Internet Explorer has slightly... eccentric... rendering behaviour for tables. Actually to be specific, it's IE7 only.

<html>
<head>
    <title>Table Borders</title>
    <style type="text/css">
        table, td {
            border: 1px solid black;
        }
        td {
            height: 20px;
            min-width: 5px;
        }
    </style>
</head>

<body>
<table cellpadding="0" cellspacing="0">
    <tr>
        <td>first cell</td>
        <td>second</td>
    </tr>
    <tr>
        <td>
            <div></div>
        </td>
        <td>
            <div></div>
        </td>
    </tr>
</table>
</body>
</html>

The HTML here is a simple table with a border round all the cells (using CSS border, not the deprecated border attribute on the table) - a fairly common situation.

This is how it renders in IE7:

Note the distinct lack of a border around the lower two cells. If a table cell is empty, or contains a div which is empty, IE doesn't render the cell at all.

The cheat to get around this is to add   into every empty cell - either inside the div, if there's a div in there, or inside the td if there's nothing else in there. Then IE wakes up and remembers to render the borders.

Thursday, January 27, 2011

My Experiences with Android Development

Posted by Unknown on 1:56 AM with No comments

Because I was missing coding, and because my friend and I had an awesome phone app idea at the weekend, I thought I'd try my hand at developing an Android application this week.

I want to give a quick overview of my preliminary thoughts on getting started on this endeavour.

Background: I've got more than 10 years Java experience, but any UI for the applications I've worked on was always a web UI. I am completely new to mobile app development.

Getting Started
I spent maybe a day and a half reading the excellent Android developer documentation and attempting to hack out a quick 'droid app.

I was surprised to find the Application Fundamentals section actually made sense to me. There appears to be a clear architecture with design guidelines laid out for developers to follow. This shouldn't really be a surprise I suppose, but years of hacking around with web UIs with poorly implemented MVC architectures must have left me thinking that all frameworks are less "frame" and more "work".

Setup
I remember the disaster of trying to get my first JDK working on my 486 - what a nightmare! And getting Tomcat 3 installed and running? Forget it. I also remember the last time I made a serious stab at a learning a new technology. I tried develop a Grails/Groovy application in Eclipse. The IS guys had to rescue my laptop from me during that enterprise before I could do it any serious damage.

Installing the SDK on my mac was surprisingly simple, especially bearing in mind I'm new both to OSX and to mobile development. I don't know if it's because Android development has been well thought out and well supported, or if it's a function of both the industry's maturity and my own experience.

The integration with IntelliJ was much slicker than I expected, especially since I'm using the freebie Community edition. I don't remember the exact steps to tell it I wanted to create an Android project, but it must have been ridiculously easy otherwise I would remember the trauma. I do remember a little confusion around installing the Android platform - I hadn't understood the difference between installing the SDK and then installing a specific API for it. But the documentation and the android application got me on the right track in the end. And then when I clicked the "run" button in IntelliJ, hey presto! The emulator appeared and there was my app!

I loved the emulator. I had some confused idea that I would have to plug my own phone into the laptop to see my application. Instead, the emulator looks enough like my actual phone to give me decent feedback on how the app is going to behave. The downside is I was trying to play with the camera, and I couldn't see how that would really work in the emulator, but I got a fair idea.

Did it work?

I managed to get a rudimentary application running, with a button and some descriptive text (it's not about to win any awards). The button was supposed to launch the camera viewer, but my first few attempts just resulted in the crash notification. It didn't take long to figure out how to use logcat to see the stack trace and see I hadn't set the permissions correctly to use the camera, so I rooted through the CameraPreview example in APIDemos to figure out how to set up the AndroidManifest.xml correctly, and rather amazingly it all worked!

Any downsides?

I was surprised (and slightly disappointed) at the amount of XML configuration. I've seen plenty of evil Spring and Ant XML in the enterprise and I thought frameworks were moving away from that. The manifest I can understand I suppose, but it felt a bit weird to be defining the UI in XML. It seemed like a bit of an afterthought tagged on after all the well-defined architecture behind the scenes.

But maybe this will make more sense to me as I develop my application further.

In Summary

I was pleasantly surprised to be able to get an Android application (albeit a very basic one) working in only a few hours.
Development in IntelliJ was much easier than I expected.
The documentation is actually very good.

We'll see how I feel about it when I start trying to do more than a very simple example application.

Tuesday, January 25, 2011

CSS for Developers: Column Layout Using CSS

Posted by Unknown on 1:08 AM with No comments

This is a continuation of my series of CSS hints / tips / cheats for developers (and other technical-but-not-UI people).

The screenshots are in Chrome on a Mac. The originals were on Firefox on Ubuntu so I can tell you the behaviour is identical.

Part Three: Column Layout Using CSS (or: still no excuse to use tables)

Today's example is a simple one, but worth knowing all the same. The aim is, once again, not to use HTML tables to provide any sort of layout. In most cases not only does using a div reduce the size of your DOM (and potentially help improve the performance of your page), it's actually a lot less complicated to organise your layout this way.

3.1 Display Elements or Text in Columns

<html>
<head>
    <title>Column layout</title>
    <style type="text/css">
        #col1 {
            background-color: yellow;
            /**have to know the width **/
            width: 30%;
            float: left;
        }
        #col2 {
            background-color: lightBlue;
            width: 30%;
            float: left;
        }
    </style>
</head>

<body>
<div id="col1">
    <div>1</div>
    <div>2</div>
</div>
<div id="col2">
    <div>3</div>
    <div>4</div>
</div>
</body>
</html>

Again you can see we're using float on the divs to get them to appear side-by side.

The code is much more intuitive organised this way - everything from a single column is grouped together in a single div. If this was done using tables, you'd have the content for a single column scattered in different cells on different rows of the table. Re-arranging the order of the columns in the case of tables is much more of a pain in the neck. With a div, it's a simple move.

Monday, January 24, 2011

On Changing The Image Of Programmers

Posted by Unknown on 1:54 AM with No comments

Gah!! This is exactly what I was talking about - it's pink, it mentions shoes, and it's about as patronising as you can get.

Would the chart be different if your possible outcomes were Bill Gates, Steve Jobs, Mark Zuckerberg, and Linus Torvalds? I bet for a start it wouldn't mention Jimmy Choos or choice of handbags. And it probably wouldn't be in baby blue either.

Which leads me nicely onto the next subject I have strong opinions on: Role models. Why do we need them? Do we need them?

If there is any good to be salvaged from that horrific infographic, it's that it gave me what I've been trying to research - some female role models in technology. Unfortunately it hit the other button I was ranting about earlier - they're all very presentable and polished. I don't doubt their value as role models, it's great to have people like that to try and emulate. But surely there must be IT women out there who look like real people? And how many of them started as programmers? I know there's a wider issue around women in technical professions, and women at the top of organisations in any business domain, but I'm trying to keep focused on the issues faced by girl programmers specifically.

Do we need role models?
I feel almost a responsibility to be a role model. I joined ThoughtWorks because I felt it would give me a better platform for greater visibility, so I could show that girls could do this job. I feel passionately that the industry desperately needs excellent role models to overcome the stereotypes kids are absorbing (in our western society) about what it means to be a programmer(/developer/techy).

My friend Mazz feels quite differently. She doesn't see why she should have a greater responsibility to be a role model simply because of her gender. It wouldn't be expected of her co-workers. She suggests that by making a career in programming an option for all, or worse, by targeting specific groups (e.g. women) we're devaluing the industry. Surely we're stronger if we only attract people who are interested in the first place?

During a week long trip to Vegas (it's a hard life), Mazz and I realised we actually agreed on fundamentals:

Mazz doesn't believe we need female role models to tempt women into programming
I believe we need more diverse role models than we currently have.

If Mazz doesn't want to be a role model because she's perfectly happy getting on with doing her job bloody brilliantly, then that's totally cool - after all, if minorities are expected to do stuff which distracts them from their day job, it's going to make them less appealing to employers.

My aim in being a role model was not specifically to get more girls into programming, but to show to the world that we're not all speccy asexual white boys. Some of us are speccy white girls. And this shows the ridiculousness of trying to encourage girls to be role models - you've only changed one dimension. And having a token bisexual black disabled older lady is only going to narrow the field you're appealing to.

So what do we need to change?

Back to the question that started this off - "what do we need to do to encourage the girls?". The answer, it would seem, is not to roll out the girls, dress them up and parade them around. After all, we got here with no female role models. And we may very well have been put off by role models like us - a teenage Mazz and a teenage Trish would probably not identify with the heel-wearing blonde I've become, despite my all-round awesomeness.

When I worked at Ford they used to tell us a story about marketing. They told us that Harley Davidson understood that to market something, you had to market it at the person your customers wanted to be. A Harley is a statement, a lifestyle choice. They focused on promoting that lifestyle, promoting the image of the Harley biker, all leather and macho attitude. They knew that the majority of their customers were CEOs, lawyers, doctors. Guys who'd made it in life and had the cash to spend. But if they'd marketed Harley Davidson directly to the stereotypes of these guys they would have lost their market. These men did not buy a Harley as part of their CEO persona. They bought them because they aspired to be the leather-wearing macho guy.

I don't know how true that story is, but I do know Harley Davidson revitalised their failing business by focusing on creating a community around their brand.

So back to the question: How do we get more girls into programming?

And the answer is: We're asking the wrong question.

The real question is: How do we attract more than just the "typical" geeks into programming?

And when you ask that question, you realise it's absurd to assume that attractive female role models and women-centered events are going to fix the problem, or even make any significant headway on it. You're narrowing your field of appeal instead of broadening it. You're being exclusive instead of inclusive.

Where can we find appropriate role models to represent us?

We have diversity amongst geeks. We've got diversity along the typical dimensions (age/race/sexuality/gender etc etc). But in addition we're all individuals and we're going to appeal to other individuals. I might appeal to someone who likes shoes. I might appeal to someone who likes photography. I might appeal to someone who thinks Java developers should give a toss about the user experience. I might appeal to someone who is massively OCD about the names of their variables.

We shouldn't care what little boxes those people tick on the dimensions that make absolutely no difference to their ability to program. In fact, if we focus less on this and more on our general awesomeness as geeks, we might find so-called minorities are happier to represent us.

Even with diverse role models we might have trouble getting the media to let go of their stereotype of the geek programming in their bedroom. But we might not - I did a search for "geek" on The Sun's website, and I found a lot more references to geek chic, and celebrities claiming to be geeks, than to stories of the lonely computer programmer who went crazy and killed everyone.

It is the time of the geek. Let's ride the wave and bring other people to the party.

So who should our role models be?

Everyone.

All of us.

You.

Friday, January 21, 2011

GWT: Why VerticalPanel is Evil

Posted by Unknown on 3:10 AM with No comments

At LMAX we adopted Google Web Toolkit pretty early on. One of the motivations for using it was so we only had to worry about recruiting Java guys, and then we could all work on every part of the application including the web UI. Sure, you can learn a bunch of different skills if you want to, but it reduced context-switching and kept the skill set we were hiring for to a nice short list.

The problem is that GWT does a very nice job of pretending to be Java whilst actually compiling down to HTML and JavaScript. If you don't have some understanding of the end result (the DOM the browser is going to be rendering) it's going to be hard to get the performance you need from a low-latency trading application.

My number one bug-bear with GWT is VerticalPanel. To the uninitiated developer, this seems like the sort of thing that will be useful everywhere. You often want stuff stacked on top of each other - think menus, lists, the layout of a dialog. What is not obvious is that it uses tables for layout under the covers, and I've mentioned in the past that Tables Should Not Be Used For Layout.

A much less obvious way of getting the same result with (usually) no extra effort is to use FlowPanel. This is rendered as a div, and most of the time the elements that get inserted into it will render in a vertical stack.

VerticalPanel Code

VerticalPanel panel = new VerticalPanel(); panel.add(/* your widget */); panel.add(/* your second widget */);

VerticalPanel Rendered As HTML

<table>
  <tbody>
    <tr>
      <td>
        <!-- your widget here -->
      </td>
     <tr>
    <tr>
      <td>
        <!-- your second widget here -->
      </td>
     <tr>
  </tbody>
<table>

FlowPanel Code

FlowPanel panel = new FlowPanel(); panel.add(/* your widget */); panel.add(/* your second widget */);

FlowPanel Rendered As HTML

<div>
  <!-- your widget here -->
  <!-- your second widget here -->
</div>

You can see that the DOM generated for a very similar-looking 3 lines of code is much much smaller for FlowPanel.

Who Cares?
Right, but we're only talking about a few more elements, and browsers are pretty smart about optimising these things. Right?

Maybe. But if you use VerticalPanel for all your containers, for every box which needs to be a slightly different colour, for every place you want to change the alignment slightly, things get very big very fast. This is an example of real code from an early prototype, where we had several nested panels (not unheard of if you've got a complex dialog box with lots of elements in it. Like, say, a deal ticket). And I've stripped out a lot of the table attributes that made this even more heinous:

<table>
  <tbody>
    <tr>
      <td align="left">
        <table id="panel1">
          <tbody>
            <tr>
              <td align="left" style="vertical-align: top;">
                <table class="orders-input">
                  <tbody>
                    <tr>
                      <td align="left">
                        <table class="row">
                          <tbody>
                            <tr>
                              <td align="left">
                                <table id="container">
                                  <tbody>
                                    <tr>
                                      <table id="panel2">
                                        <tbody>
                                          <tr>
                                            <td align="left">
                                              <table class="controls">
                                                <tbody>
                                                  <tr>
                                                    <td align="left">
                                                      <!-- widget -->

For every table element and associated elements (tbody, tr, td), you would get a single div element instead if you simply replace every instance of VerticalPanel in this stack with a FlowPanel.

<div>
  <div id="panel1">
    <div class="orders-input">
      <div class="row">
        <div id="container">
          <div id="panel2">
            <div class="controls">
              <!-- widget -->

See? Much nicer.

This is exactly what we did do, and we saw a noticeable speed improvement across all browsers - noticeable to a real user, not just some millisecond improvement on a performance test. Mind you, users' brains are amazing things and your system has to react in less than 0.1 seconds for a user to perceive it as instantaneous. So even in a browser, every millisecond counts.

In addition to improved performance, you get a nice bonus: now the layout is no longer controlled by tables, you can really easily shove stuff around and make things look pretty with the clever use of CSS. If you're really lucky, you can chuck that stuff over to your designers and not have to do another GWT compile when someone wants to move things 3 pixels to the left. Which they will.

Thursday, January 20, 2011

On How Not To Target Girl Geeks

Posted by Unknown on 1:30 AM with No comments

(First, let me say this post contains opinion, stereotyping and sweeping generalisations. But that's sort of the point. Also I don't pretend for one moment to speak for all girl programmers, I can only speak for myself)

When I first started this blog, I wanted to just post "proper" technical information. I wanted to prove that there are girls out there doing "real" programming.

I specifically didn't want to talk about my gender. I wanted to prove by silence that gender is incidental to what I do.

But, it doesn't really work that way, does it?

Firstly because one of the first things I get asked by guys when I meet them in this industry is "why aren't there more girl programmers?" (that's after they ask "do you work in HR?" followed by "are you a real programmer?" - I'm not joking, this happened this week).

And secondly because I'm pretty passionate about the gender issue. To be specific: I'm passionate about diversity. It's just that I'm more qualified to bang on about gender rather than something like race, sexuality, age etc.

What's started you off again this time?
The London Java Community got me thinking by asking "Is there anything we can do to attract more girls to the events?"

The thing is, the reason people (boys) keep asking this question is because they want more girls in the industry / at events. They want them to feel involved and included. I've said it before, but I mean it - I've never come across malicious sexism at work. Yes there is subconscious sexism. But the boys want the girls to come and play. Why wouldn't they? How many boys really want to work in a team which has 12 developers and only one is a girl?

But think about it: who is the worst person to ask why girls don't like being developers?

Yep. A girl developer.

Because we love it. We're here because we like programming, we like our jobs, we're good at it. We weren't stopped by sexism (assumed or real), by boys clubs, by not having female role models, by... well, any of the myriad of reasons posited as to why girls don't become programmers.

I have no idea why a girl wouldn't want to be a programmer. It's brilliant! It's problem-solving, logical and creative, you're usually surrounded by intelligent people who are striving toward the same goal as you, and you get to meet a lot of boys :-)

So, back to the question at hand: how do we appeal to girls, as a user group and ultimately as an industry?

There are lots and lots of ideas kicking around this area, and I'm going to start by ranting about the things I think we shouldn't be doing. This, of course, is totally my opinion so helpings of salt might be required.

No Pink
I get so angry about this!! As if the pinkification of our little girls wasn't bad enough, "people" (I have no idea who) think that they can inflict this upon grown-ups too!

Why, WHY, would a website that is aimed at professional technical women be branded in childish hues of the hated colour? I didn't even click on a single link, I'm not sure what service it's supposed to provide, because I was so disgusted by the colour palate I closed the browser.

In particular, if your target demographic is the somewhat unusual creature the girl-geek, or at least the lady technologist, what makes you think that ultra-feminine colour is going to appeal to us? Apparently "The November 2009 Times/Lady Geek Female Appeal Study showed that only 9% of women want technology to be feminine, let alone pink."

What do you think, that your average (female) maths graduate is going to decide Computing Is For Me Because It's Pink? Really?

I worry about this: are these sites (phones/consoles/cars) designed by men, and that's what they think women like? Or were they designed by women who really believe that's what ALL women like?

Please. Stop it. Now. It's embarrassing.

Be careful about your role models
Take the gadget show, for example. I don't actually watch it, I'll be honest, because I really don't need someone tempting me to spend money on things I don't require. But as an example of this point it's perfect - just the picture at the top of the page says it all to me: two reasonably attractive women (I know not everyone floats your boat but they're not ugly), token black guy and two white guys who certainly don't float my boat. If only one of them was gay, their diversity tick sheet would be perfect.

I am not for one second suggesting any of these guys don't know their stuff. That is not the point at all. I just wonder - if one of the women looked like someone's mum, would they have got the job? The subconscious message here is that yes, it's totally fine to be a girl and a geek. But you still have to look good too.

And there's another message there - if you're a guy and you're into technology, you don't have to be hot. In fact, the role models we see are definitely on the Not Hot end of the scale. Bill Gates anyone?

So girls get a double-whammy - I have to know what I'm talking about and look good (whilst also trying to prove that girls who look good have brains); and there are no hot guys in the industry.

Hmm, no thanks, I think I'll get a job in marketing.

Don't assume all women are the same
In fact don't assume anything about the girls you want to attract. Actually, assume they're people. Like you. And geeks. Like you.

For example. I actually do like shoes and clothes. But plenty of my fellow girl-geeks are about as bothered about that stuff as their male counter-parts. So trying to appeal to girls with iPhone apps that help you pick you next pair of Jimmy Choos might not be the approach you want to take. You'll attract a subset of women, sure, but they might not be the ones you want.

Imagine if you wanted to get more guys into programming, and you decided to do it by using football as the hook. Yes, you'd get certain guys interested. But I've met more guys who are utterly disinterested in football in IT than I've met girls who dislike it.

We're not all the same. We're interested in all sorts of different stuff.

Be very very careful about women-only events
My personal feelings are that there should be no need for all-girl conferences or all-girl line-ups. To me, it implies that girls want something different to boys, and that girls only listen to other females.

I think there are places for these sorts of things, especially if you're aiming it at girls who might be more uncomfortable with guys around (e.g. some sort of mentoring). So I'm not going to say flat-out they're wrong.

It's just I think it's not the right angle to attack the problem. And you're segregating based on one dimension only, but as I said we're all different and we all have different problems. The issues a non-white (am I allowed to say that?) lady might face could be different to those a middle class white girl like me has to deal with. And do you want all-black conferences, and all-gay conferences, and so on and so forth? Why are we special? Why are we allowed to exclude the boys? It's sexist.

Also, as a girl-geek, I get a bit freaked out when I'm surrounded by women, even if they're all geeks like me. I'm much more comfortable talking to a guy, they tend not to try to read between the lines of everything you say or wonder if you're bitching about them behing their back </gross generalisation>.

Diversity is about being inclusive, not exclusive.

In Conclusion
Lots of the girl-geek, women-in-IT movement often appears to me as if women are "special" and need different treatment. This is not helping our cause at all. It causes resentment amongst our male peers and it puts off women who don't define themselves by their gender - people like the girls who are already in our industry. We like technology, we love programming, and we're good at our jobs.

So. I don't know why there aren't more girls in programming. And I don't have the answers as to what will tempt them in.

But, just for me, next time you're creating an advert or a website or something aimed at geek-girls, can we have more hot guys please?