Occasionally I moonlight as a python tutor for someone. Sometimes I show them the ins and outs of the language, and sometimes I talk to them about their current challenges in the workplace.

That's when I was reminded of a management phrase I absolutely loathe, "Don't bring me problems, bring me solutions".

If that saying was a person, I would encase their limbs in concrete1, and smash it open again with a lump hammer. Then I'd do other unspeakable things to the rest of it.

I hate that phrase.

To me, it's a management smell. When I hear that from a manager, I wonder if I'm in the right job.

I had a manager who said that. I was talking about problems I was having working with another member of the team, and lots of other people had them as well.

My manager told me he didn't care, and to sort it out. He then followed it up with the grand proclamation of "Don't bring me problems, bring me solutions".

To me, that's entirely the wrong approach to management; at least, it's the wrong approach to managing me.

When I got my first Forever Job2, I used to have a one-to-one with my manager every 2 weeks. That meeting was basically an opportunity for him to tell me what he needed from me, but at the end of it, he'd ask, "Is there anything I can do for you?". It was a ritual for him, he'd always end the meeting with that. Mostly, I'd just say, "No", and totter back to work, but it was a useful hook for when I did need something.

Once or twice, I did need a path cleared for me, in order to do my work, or to ask a favour, and that was the perfect opportunity to raise non-urgent issues.

And, with this manager, they got looked at.

When I was an intern, I had another good manager. If I had a problem, especially technical, he frequently restated, reframed, and decomposed my problem into chunks manageable enough for me to be getting on with. In other words, I went in with problems, and I came out with things to be getting on with. Now, in fairness, I was an intern, and I'm pretty sure that manager saw his role as being a mentor in that situation3.

These days, I work in an "agile" environment, and a Scrum Master is meant to be the person that clears the shit from a developer's way, and lets them get on with their work. That's pretty much what I think a line manager should be to their front-line staff. This is why I don't trust someone that will say, "Don't bring me problems, bring me solutions".

Maybe the phrase is meant to mean something else, but I take it to mean, "I don't give a shit about your problems, get me results".

That phrase betrays an attitude that the manager has no hand in the results. They're given a requirement that they relay to the team, and they expect results. They may have a hand in planning, or anything else, but that's as much as they're willing to enable their workers to get on with it.

Sometimes a problem is beyond the control of the developer.

Sometimes a problem is about resources, or politics, or a lack of information.

Personally, when I hear that phrase, all I think is, "Well, if I had a solution, I wouldn't have needed come to you".

In most industries, the rank-and-file workers are not unintelligent. Frequently, they know what's going on, and they know what is and isn't within their control.

Sure, it would be good for any employee to know what the ideal solution would look like. Actually, no. It would be good to know what the end-state would look like. Sometimes the end-state will be as simple as, "the impediment is not there any more", but they shouldn't have the solution immediately to hand. It's great if they do have the solution to hand and say, "I need access to this device, but I need written approval from you first", but they shouldn't have to have the solution if it's not readily available to them.

The manager may be able to instantly point to a known solution. But in most cases I expect there to be negotiation. I expect a conversation as we work out what needs to be done to remove my impediment. Sometimes the meeting itself is enough. That meeting will be curtailed if the initial response is, "Bring me solutions".

Sometimes that meeting involves figuring out what end-states are most achievable. "Will it work if we just can get this to happen?". Again, if The Phrase comes up, it just suggests a fundamental apathy, a complete and total lack of engagement.

Personally, when I heard my boss say that phrase, that's when I started looking for a new job.

Management is a tricky job, and I don't want to do it yet. But it involves making sure your team works smoothly. As a manager, you aren't directly delivering results, but you make sure your team has the best shot of doing so. That means doing the hard sums of figuring out what colleagues don't play well with others and giving individual work to them. It means making sure that you don't have a single point of failure in your team (aka increasing your bus factor). It means keeping morale to a level where all your employees don't want to quit all at the same time, which itself means resolving interpersonal conflicts, or at the very least keeping conflicting employees in opposite corners. It means sheltering your team from the shit flung from further up the ladder, and from people on the same rung of other ladders.

But, overall, it means keeping your team impediment-free, so they can do their fucking jobs.

Saying, "Don't bring me problems, bring me solutions" means you do not want to be part of that process.

If every employee gave you a solved problem, there'd be no justification for your job.

Obligatory footnotes )
Anyone who knows me will tell you I like puns; that's not entirely true. What a lot of my friends don't get is that I don't like to play on words, I like to take them out like toys and play with them. I use them like lego blocks in my head to see if I can create anything that's new to me, and I share the ones that amuse me. Sometimes I just brainfart, and waft the smell around. Either way, when I share them, I'm accused of punning; the lowest form of wit.

But I think it helps with my problem-solving when it comes to computers, but first, I think it's important to share the thought process as I played with words one time.

Last year, as I was walking home, I started trying to say "uncomfortable" in an old-school, Ronnie Drew style, Dublin accent. I don't know if you've ever heard it, but it has a slow beat and pace to it, and a tendency to add in hidden syllables. When you say Dublin in this accent, you say "Dub-a-lin". This made saying a word like "uncomfortable" very hard; where do you put in the hidden beats? I spent my time walking by the Grand Canal as I started trying to break it down. "Un" "com" "fort" "a" "ble". "Un" "comfort" "able". "Un" "comifort" "e" "a" "ble". "Uncomfort" "a" "ble". "Un" "comfortable".

The word broke down and the pieces swirled around my mind as I tried for all my life to put it back together in my head. I got un-comfortable. Unable to be comforted. It seemed so permanent of a state. I put it in sentences.

"I am un comfortable", says she, tears rolling down her face, "I'll never find a day's rest until I die".

"I am un comfortable with that word", said he, "There is nothing in this world, that'll make its blow softer".

It made conversations and the written word take on whole new meanings.

I shared it, and it was a "pun".1

But that's what I do to words. I also love doing it to concepts, and it's something mathematicians and others have been doing for ages. They pick ideas and concepts up, and stretch them, making them bigger or smaller, turning them upside down, trying to turn them inside-out, all so it fits better in their head.

It works really well when you program as well. If a solution can't be expressed simply one way, it might be that you're looking at the problem the wrong way.

My favourite example of this is the Monty Hall problem:

You are a contestant on a game show, and you're playing for the grand prize. You have the choice of 3 doors; one with the prize, and the other two with a tin of beans. When you make your choice, the presenter opens another door to reveal a tin of beans, and offers you the opportunity to choose the unopened door instead. Do you switch?

If you look it up on Wikipedia, you can find the answer, and detailed mathematical answers for each. But I have an explanation that fits better in my head.

The presenter will always reduce your choices to two options, one of which has the prize2.

So let's stretch this, and make a different game:

You are a contestant on a show. You are told to pick a card from a shuffled deck of 52 cards, but not to look at it. If you chose the Ace of Hearts, you win the grand prize. The presenter then looks at the remaining 51 cards, and throws 50 of them away. The presenter tells you that one of the remaining cards, yours or the presenter's, is the Ace of Hearts and that you may take their card instead of yours. The presenter is not lying. Do you make the switch?

It's essentially the same game. In both cases, the presenter asks you to choose between your initial choice and theirs, and that one card will win you the grand prize.

In the card game, you have one chance in 52 that your card was the winner. In probability terms, that's roughly a 1.9% chance of winning.

That means there's a 98% chance that the presenter has the winning card.

Do you make the switch?

I would.

Now, that we know this, let's make the game smaller again and go back to the original problem.

Instead, if we go with our initial choice, there's a 66% chance that we didn't pick the right door.

So, when the presenter reveals a wrong answer, and offers you a choice, there's still a 66% chance that your door was wrong, and that the prize lies behind the door that you are being offered now.

It was by doing this that I was able to believably explain the solution to myself3. I made the problem bigger, because thinking about it in that way made it easier to think about. Then I shrunk it down again.

When I do these things, it tickles the same bit of my brain that likes to play with words; the part that likes to capture the word in flight, pin it down by its wings and open it up to see how it ticks4.

But I hope I've done a little bit to show how I like to think about things. And how word play is punderrated

Obligatory footnotes )
So, this has been a mild rant in my head, and I feel like I need to articulate it somewhat.

Recently, I was out drinking with some developers, and I got talking about some pattern that some framework uses that another developer considered harmful1. To be honest, I didn't have a strong opinion on it, I just liked to use it on occasion when I was working with that framework a few years ago. However, the other developers argument against it is what I'll call an Appeal To Personality.

In this particular case, it went something like this, "I worked with the smartest programming guy ever, and he was really anal, and really obsessive, but he produced great quality code, and he said not to do X", with the implicit followup that I'm not going to claim I'm better than this guy I've not met, or otherwise challenge the authority of this Personality.

Similarly, when having a discussion about Agile, one of the developer said to another (who claimed Agile didn't work), "This was put together by some Very Smart People, and they found it worked. Who are you to argue with them?"

I have 3 words for this style of argument: Bull fucking shit.

My own personal take on this is simply that programming isn't a religion, there aren't the gods from on high, there aren't high priestess, priests or Great Rites that confer upon us the wisdom of the gods, and these great Personality Deities. Maybe it's just my own mental blocks, but I need a Reasontm to accept this. I need to understand why something is a bad idea.

Here's a list of things I know to be a bad idea:

  • Programming in really complicated Regular Expressions - I've done this before. I've had to debug some very complicated Regular Exression. As time went on, I spent less time fixing the broken big regex, and either reducing them to small ones in multiple phases, or just taking out the need for them altogether, because that was easier for me to debug

  • Similarly in python, I try not to use nested loop comprehensions. Yes, you can look smart and cool, but I don't do them. I can, but I won't because I've learned from regexes that just because you can do something is not a reason for doing it.

  • Operator overloading is cool, but unless the semantics fit what you're trying to do, you're just going to confuse yourself when you go back to it later

  • Don't write a one-liner just for the sake of writing a one-liner if you expect to rely on that code. If it fits more naturally in multiple lines, do that instead.2

It's not a whole load of stuff, really. They're just mistakes I made for myself, and that I've learned from. I learned a lot from mistakes I made. In fact, I'm pretty sure I've learned the most from mistakes I've made for myself.

Maybe it's a mental block that I can't accept wisdom from others without the memory of pain to back it up, or it's that I can't accept a good practice without a similarly good reason, but an appeal to personality is just not a good enough reason for me.

That said, there are Personalities that I will listen to. I have a few colleagues like that. One even gave a presentation on refactoring. He worked through an example from a book he was very fond of. So, you might be asking, how does this differ from the "Appeal to Personality" that I've just been wittering on about?

Well, in this guy's case, he didn't just rework an example application, following what was in the book, but he took the time to explain what he was doing. Moreover, he wasn't just explaining what was in the book, he was explaining his interpretation of what he'd learned in the book. He'd learned something, distilled it, and shared this knowledge with us. His personality lent a lot to the process, but he wasn't the reason. He didn't say, "I'm pulling out the code and putting it here Because I Say So", or saying, "Whenever you see this, this is a Code Smell and it must be moved", but took the time to explain why he was doing it. These reasons mean a lot.

I'd much rather hear someone who has lived through some pain share tales and stories of their pain, and reasons why they do what they do. I'd much rather have a good reason to do something, and because I'm told to by a Personality is not it. I don't care if Denis Ritchie said it, Linus Torvalds, or some super-smart guy in the back-ass of nowhere said it. I want good reasons, not the celebrity.

Herein lie the footnotes )
So, it's Thanksgiving again. It's that time of year where you can get games at super-discounted prices from the likes of Steam. However, you might also notice, if you regularly buy indie games from the Humble Bundle, that the Humble Store is open.

The two have very similar briefs - sell games cheap. The humble store say they give 10% of their earnings to charity.

This is not the reason to buy from them if at all possible.

The simple reason is, a number of years ago, Steam chose to sell to Europeans in Euro. However, they didn't bother with an exchange rate, they simply priced each game at its dollar price but in Euro. Given that the dollar is almost always weaker than the euro, that means that Steam get an extra bonus from any European customer. I can't see any good reason for that, it's the same game, but Europeans pay extra just because Valve can't be bothered to do the conversion.

I don't know where that extra money goes. Most likely into Valve's accounts.

In the case of the Humble Store, you only see a game's price in US Dollars. You pay in US Dollars - which are generally cheaper than Euro.

10% of the money you pay goes to charity (Child's Play is one of the 5 named charities - which I take issue with, because Penny Arcade and its general shittiness12, but I can ignore that in favour of a good deal) and it's cheaper. It may not be cheaper than the flash sales that Steam have on offer, but otherwise Humble is the way to go.

But overall, Humble Store is taking less of a cut, and you're still getting the same game, but for a cheaper price. Also, if there are multiplatform options, you get those (including Android). And if there's a steam key you get that, so rather than just pay for an individual Steam key at a higher price, you get more platform support AND the steam key for a lower price.

For instance, I've just bought Gone Home, Ironclad Tactics, Game Dev Tycoon, Kentucky Route Zero, Beat Hazard Ultra, Anodyne, The Bridge and Risk of Rain for a US Dollar price of $60. After currency conversion in Paypal (which isn't always the most favourable) it's just a few cent over €40.

The total on Steam, at time of writing is €56.70 - I just won with Humble (I realise that I could have saved a chunk by picking the cheaper options from Steam (for instance, Beat Hazard Ultra is cheaper on Steam right now) , but it still worked in my favour overall)

I hope more Europeans realise this, and make a move to Humble whenever possible.

1 (Trigger warning - Rape and general shittiness) Google "Dickwolves" - not for the faint of heart

2 (Trigger warning - Transphobia and general shittiness) Google "Tycho Brahe" and "transphobia" - also not for the faint of heard
So, I was at $conference. I think I walked out of there knowing and considering more than when I walked in, so that's a good thing.

There was an old joke told as an introduction to one of the talks: "There are 2 hard problems in programming: Cache invalidation, naming things and off-by-one errors."

Yup, names are hard. Names are harder for some than for others. Actually writing this post is hard.

It's hard because I want to speak about something.

But it's also hard because I don't want to lay blame.

This is not about anyone. It might be about me, a little... but not really.

It's not about $conference, or anything they can do.

I just want to talk about it. I know nobody (beyond those who know me) is going to read this, but I want to make it clear that this is not a thing that I expect to be fixed or for blame to lie anywhere. This is just something that Is.

This is the first time I didn't have to pay for a ticket. Basically my employer paid for the tickets for a bunch of us in exchange for spending some time on a desk pimping our jobs. Sure, it means I missed some talks I wanted to go to, because I was on the desk, but that's fine. That's also not what I want to talk about.

I'm really not sure if there are any answers here.

I'm trans, and in a weird situation.

Outside of work, I'm known as Aoife.

Inside of work, I'm known by a different name; it's the name that would be used if I had to appear in court.

In the Dublin $conference community, I'm known as Aoife.

Because my workplace paid for my ticket, I had my legal name on my name badge. So, the community got to see a name of mine that I really rather wish they didn't know.

I have a rule these days: I try not to give people a choice in my identity; I'm always disappointed when people choose the wrong one.

The letters on my name badge are big. I assume it's to provide safety behind knowing someone's "real" name.

It makes sense: big letters on a big badge make it hard to hide; it makes spaces safe; it doesn't let you hide.

People saw my legal name.

A name I don't want them to see.

They were given a choice in my identity, without me giving it.

A choice I did not want to let them have.

It caused confusion for others.

It caused embarassment for me.

There is no blame here.

Just an unfortunate situation.

I could get off the fence but, right now, there are reasons not to.

This was meant to be a temporary thing. For most, it is.

This embarassing little situation does not last long for most trans people I know.

But I'm stuck.

I know people who organised the event, this was nothing they did; no fault lies with them.

If I talked to them, I could have avoided this situation.

If I had done that, I would have had a different problem with work.

I have a rule: you don't come out in work, they look at you differently; it's never the same.

I have a rule: I can come out to colleagues, if I consider them friends.

I have a rule: you don't come out to management, they expect you to do something.

One choice or the other would have been uncomfortable.

Naming things is hard.
I'm a techie; currently I am living in the world of Linux1. I didn't always think I would be. In my teens, I was into computers. That meant that in the late 90s, I was chatting to folks on IRC over a dial-up modem. I didn't consider myself technical, just lucky to have an internet connection with enough wherewithal to understand how to use the applications2. I liked to learn how the things I used worked, but I couldn't do anything with that knowledge. I learned bits of IP and TCP until I realised I didn't have the programming chops to make what I wanted to make; sure, I did a bit of c++ when I was 13, but never got past for loops. Also, a friend of mine was seriously getting into programming at the time, and was zooming ahead with programming. That friend also made a lot of noise about himself and his skills. He believed his own press, and so did I.

Also, because I was trying to figure out my own gender issues around the same time, I spent more time with online trans communities than pursuing things like programming. Like I said, I was satisfied with a Win95 box, an mIRC client, my Netscape 3 suite with its mail/news utilities. Some of the people in that community also bigged up their skills and their involvement in the open source communities and whatnot. Their press machines were in full flow, and I believed them like I did with my friend. I didn't believe I could measure up in any meaningful way. Hell, I didn't know much about Linux. My friend had Linux (an early Redhat3 if I remember correctly) on his machine. So did my girlfriend, who was coding. So did the Open Source guru, and if she was to be believed, she wrote parts of it. I decided I wanted different dreams; I wanted to be a psychologist4.

Sure, I was good at Maths in school, and I was good at science... But there was a talk in my school from some software developers, and they tried to move people away from the image of a maths and science person. "We don't want NERDS", I remember one of them saying in a thick country accent. "We want team players; we want the type who do well in soccer." Given that I knew I was a bit of a nerd in school, I took that as a deterrent. I don't think the general encouragement managed to really sink into the ears/brains of those around. That said, the class-mates I took for shoo-ins in computer science never actually went for that course in college. Good thing I had already decided on psychology.

By the way, psychology didn't work out for me. There are a whole number of reasons, but the main one was that when we learned about the nervous system, and neurons, and the general hard biology of the brain, I realised I really liked those details, and while I like asking if the psychological experiments we did actually demonstrated what we were taught they should demonstrate, the rest didn't hold me. So I decided I wanted to be a Scientist; a Theoretical Physicist to be exact.

In my science course, I had to take an extra module, so I took one in Java programming. I did pretty well. I surfed by on some of the stuff I learned when I tried to teach myself c++, and was able to figure out the rest from some basic maths. "Functions? Man, they look an awful lot like the polynomial functions used in maths, and I think all the variable types are just hints to a compiler so it knows what sort of data goes in and out." I knew just enough to know when I knew something, but also knew enough to know when I didn't know something, and would have to work it out by myself. So I did a lot of internal monologuing, and told myself a lot of stories about how I thought things worked. Then I figured out if it worked the way I thought, and amended the story appropriately. I did extremely well in that module. Unfortunately, while I did extremely well in that module, I didn't do so well in my 2 physics modules5, to the point where my programming score was twice that of my two physics modules combined6.

Anyway, I didn't do well enough to continue to second year, so I dropped out, worked for a year in a clerical role, hopping from one short 1-3 month to the next contract, always on the lookout for a new job because I was never sure if my employer would renew the contract. Eventually, I got the chance to try one final time for a degree. I knew what I wanted to do now. I did computer science; and I worked hard at it7. While I wasn't top of my class, I did well, and I've been working in the tech industry for nearly 5 years now. I count myself extremely lucky in that story. There are so many place I could have failed before I got to where I am now.

In that time, I've looked back at some of the things that those technical people did. I realise now that a lot of it wasn't so big. They just were able to talk about it well. My friend in my teenage years, looking at his code from back then makes me wince. I hope it makes him wince as well, otherwise he's probably not learned much from it. Another talked about being able to make certain tools in a few evenings, and I realised a few years back how easy that job would have been.

What really stuck with me is that talk I got in school. I think I get what they mean now, although their delivery was, quite frankly, piss poor. I think they thought that they could get a more diverse bunch interested in the IT business if they appealed to the not-a-nerd crowd. I think they went about that in the wrong way, while potentially alienating the people who thought they wanted to be in that field.

For years, I've thought about how I'd deliver a similar recruitment speech to schools. I thought about how I'd deliver it to young men and women to see how I could get them in the door. I don't know about the rest of the world, but people keep concentrating on maths as a skill. I disagree. But before I go on, I'm going to digress for a second8.

I believe we need more women in the IT fields. Far more articulate people can detail why. Personally, as a trans woman (in a very odd position by way of transition), I want more diversity in general, and I think addressing the basic gender imbalance would make a pretty good start. That said, I'm not going to call myself an advocate, just an ally at best. I don't have the energy, nor do I think that my direct involvement based on my own issues are going to help much9. That said, I do take a keen interest in what others are doing, and can appreciate what is being done in that area. So when I saw she++, a video talking about women in tech, while also trying to encourage women to try technical roles, I was very interested.

Overall, I love what it's doing. I like that there's honesty, and I also like how it's nothing like the EU's ill-fated attempt to encourage women in science10. That said, some elements of it really reminded me of that recruitment talk in school.

What follows isn't a criticism of the video. I think it's excellent. However, it did raise various gut reactions in me. Thing is, I know this video isn't for me, so I would be mortified if any of these ramblings were used to try and justify demanding that the video be changed, especially if it's by a group this video isn't for.

So, tying back into how I'd want to present a recruitment drive in schools. I'd want to dispel the idea of maths being a necessary thing in computer science. Near the end of she++, there seemed to be a lot of emphasis on that. You know what? In the last 5 years (basically my entire working life in IT), maybe a little more, I haven't needed major maths, just some understanding of addition and multiplication. I think the last thing I needed it for was some pretty heavy and trippy stuff involving neural networks. And before that, when someone tried to teach me lambda calculus.

Let me just say: No. I mean, yeah, lambda calculus is a fairly core theorem in computer science, but it doesn't impact on my day to day life. In stuff like neural networks, it's domain knowledge. Similarly, if I was programming a simulation of particle collision, I'd need to know, and understand, some formulæ that model the world. But aside from domain specific knowledge, and understanding some of the seminal contributions to the theory of computing, I can't say it's absolutely crucial.

What I think is essential is language, and task subdivision. Can you break down a task into its most fundamental elements. Could you take those fundamental elements, and then sit down with a creativity-impaired 4 year old and communicate those fundamental steps to that kid? When you see the kid mess up, can you put yourself in their very literal shoes and figure out where you went wrong in your instructions? If you think you can, then congratulations, I think you could make it as a computer scientist.

A computer is a like a really dumb, but really fast, toddler. Don't believe me? If you have an hour to spare, listen to Richard Feynman on the topic11. Realistically, in this day and age, unless you're working on a really low level, you'll be treating a computer like a toddler giving it simple instructions. The difficulty of my job is not in the maths, it's the careful and unambiguous expression of what I want the computer to do.

That said, I'm biased. The way I learned programming, and general tech stuff in my adult life was by telling myself stories about I thought things worked, and refining and retelling those stories until I had a small working model of computers in my head. To me, programming is about words, stories and clear expression.

That's not to say that maths isn't a bonus; it really is a bonus. Chances are, if you're good at the maths side of things (or any science), you're probably good at the sort of logic needed for programming, and for breaking a problem down into its constituent parts. Also, if you happen to end up making a program to analyse statistics, you probably want to understand the maths behind the stats calculations.

So, what about the stuff like lambda calculus, should that get thrown by the wayside? No, I think that understanding that really helps you understand other things, but I've seen lambda calculus expressed in interesting non-mathematical ways.

Anyway, communication doesn't stop there. Communication and collaboration is needed in pretty much any technical job. More than likely you're not going to be the solo techie on a project. Even if you are, you'll either have a customer, or a boss, or someone else that you need to talk to. In general, if you're skinny-dipping in code, you're not going to able to speak to humans that well for a few minutes after surfacing. No really. Specific words take on very specific meanings in the field; one word is not always substitutable for another. It has the effect of limiting your active vocabulary for a while, so that when you're talking to non-techies you may sound like you're speaking a different language for a little bit. That said, if you're someone who's good with their words, you will have less of a problem getting back to a point where you can speak human. If you really know your stuff, and are articulate enough, you can be a good intermediary between non-techies and techies. I honestly believe that the tech sector lacks diplomats and translators (purely because of the mismatch of expectations on both sides) - this is somewhere I would love to end up, although right now I enjoy working in pure tech too much to consider an intermediary role.

Communication is necessary in all levels of my job. I need to be able to talk to, and collaborate with my colleagues. I need to be able to tell my various bosses what's going on in various levels of detail, while still giving them what they need to know. I need to be able to train in, and mentor, new joiners. I need to communicate what I'm doing to the customer. Each needs varying degrees of detail, and I need to deliver it in an effective way that conveys what they want/need to know, without too much embellishment. Last, but not least, I need to tell the dumbass computer what it's bloody well meant to do.

There were some other little things in the video that rankled my wrinkles, namely the implication that being good at tech meant you were better at everything. Yes, the skills of being able to break down a task into its constituent parts is a good thing, but the general hubris can be annoying. Almost every time I go on reddit, I want to smack that attitude out of some CS student who seems to think that because they can tell a computer what to do that they know how to do everything and that they have a solution to all the world's ails. Yes, you are trained in the use of a very powerful cognitive tool, but if all you have is a hammer, everything looks like a nail, and this world isn't made of nails. You also need to know when to turn off that bit of your brain. It's only a minor snag, but I reckon the less encouragement we can give folk to think that they can rule the world because they're a computer whisperer, the better.

That said, an excellent point was made that programming lets you look at your hobbies a different way, and your hobbies help you look at programming in a different way. Have a look at juggling some time. I see a beautiful marriage of a simple set of instructions, motion, and hand-eye coordination. I've recently taken up crochet, and find it really satisfying in the sense that there's an order that I could probably model in a machine. Who knows? Maybe those things will help me think of a solution to a programming problem I have some day.

Anyway, on the subject of how I'd sell my field to kids in school, I haven't thought further than trying to express the fact that it's down to communication. Sure, if you're good at maths, that's great, we want to hear from you. But if you're good at communication or are able to express yourself in different languages (which always felt like I was using the same bits of the brain for that as I do for programming), we also want to hear from you too. I just wish the guys who came to my school managed to put it that way, rather than alienating the self-identifying nerds.

As for the video, I really did love it, and want to see more like it. It just got folded into my general rambling rant because I happened to see a link to it when I was thinking about writing a blog post talking about the habit of misrepresenting CS as a maths-only kind of deal, which I think does an injustice to IT.

The final thing I want to say is for anyone starting in IT. The she++ video does a really good job at identifying and calling out the sort of stuff that leads to impostor syndrome. The really funny thing is, even though I looked like one of those speed-ahead folks in the labs, I was still trying to figure my way out. I also slowed right down in the "weeder" modules in the following year; it humbled me.

If I could offer one bit of advice to anyone looking the others speed ahead it's: Don't. I know it's hard, but don't look at those speeding ahead if you can at all. The last time I was in fresh meat, I was struggling along, and could only see the skaters who lapped me time and time again. It was incredibly hard not to feel like I was the runt of the litter. The funny thing was, when I stood off-track for a session, I noticed the really good skaters but how few of them there were, and how the rest were in the same position. I even remember telling another trainee skater, at the end of that session, how she honestly wasn't doing as bad as she thought she was; she was keeping pace with most of the rest, but could only see the really good ones overtaking her. I realised she was doing the same thing I was13, and I managed to feel a bit better about myself. Unfortunately, because of an injury I wasn't on track again to put that knowledge to the test.

Anyway, I know how hard it is to conquer the feeling that because one person is racing ahead, that everyone else must be doing the same as well, so the simplest advice (even though it's so much easier said than done) is to ignore it, and keep doing what you're doing.

If that doesn't work, comfort yourself with the fact that, like a lot of the people who made me feel like tech wasn't for me, probably a lot of them are churning out crap in the name of looking like they're racing ahead, or because they think they know it all already.

Herein lie the (gargantuan) footnotes )
Sorry for the delay in posting, there's been a post I've been trying to articulate for months, and every time I feel ready to finish it, another related event crops up, and changes (but reinforces) the point I want to make. So, I've stashed it for now to share something shiny I made.

You see, I've recently switched jobs, and I'm now working as a developer. I have to say, the benefits that switching jobs has had on my general well-being cannot be understated (sadly, I will be understating them in this post as that's possibly for another post).

However, professionally speaking my new role meant switching from my familiar use of mercurial to git. I was a bit wary at first, mostly because most blogs about git usage have a strange obsession about exposing the plumbing of the system, giving the impression that you need to understand the internals in order to simply use it, but I have to say I'm liking it now that I'm using it. That said, I've always been dabbling with git over a long period, but because I had done paid, productive work with mercurial, that got priority over my own git-dabbling. Now, part of my job is to learn how to use git productively, so I've taken some of my start-up time to go on a deep-dive into the system, and its supporting ecosystem, in order to customize my setup to a point beyond all recognition my needs.

If you google around about git and bash, you'll inevitably stumble on sites with completion recipes, prompt hacks, and other fun aliases to give you more information and insight into what you're doing and where. I have to admit, I felt a bit left out. I had to blog about something to do with git and bash.

Now, here's the thing. In my new workplace, we've got about 20 different git repos. There's apparently A Very Good Reason(tm) for this, but what it means is that when I'm flitting through the sources, I'm dealing with a forest of separate source trees, each with a roughly identical directory structure, and I'm prone to wanting to 'cd' up to the root, then switch to the next one. Now, it's quite possible that my Google-foo failed me, but I couldn't easily find something allowed me to realias 'cd' so that it that got me to the top-level directory of the repository when I just typed "cd" on its own; I'd just end up back in my home directory. So, after having a peek at the bash auto-completion code that's shipped with most git packages, I decided to make my own.

I shouldn't be as proud of this moment as I actually am. Seriously, I should not. It took some googling, and trawling StackOverflow for some of the interesting tricks I used, but overall, I had this done in about an hour or so.

After mentioning it on facebook, and how disgustingly proud I was of making this monstrosity, I was encouraged to join the trendy github hoardes and share it. So I did. I know, I'm now one of those trendy hipster GitHub folk, and I'm still disgustingly proud of this. It's like a kid running up to their parents holding a potty with a perfectly formed poo inside saying, "Look mommy, I didn't miss this time!".

With that adorable image aside, it was mentioned that if I'm blogging about this I might as well explain some of the tricks in there, so that's going under a cut. But first, a few notes:

  • You'll want to source this file after you source your bash-completion script for git, otherwise this won't work (this is kinda by design, more on that in the fine details).

  • While I've done my best to test this, there may be corner cases.

  • The idea is to get to the top-level directory of your git repo with a blank "cd" call. If you type it again, "cd" should behave normally.

Now for the finer details )

And that's my tour of the code12 done. I hope someone finds it (and the actual function) vaguely useful, and I really hope that the blog was at least fun to read, if not that informative. I welcome any comments, questions or issues on either the blog or on github (although if you mention an issue, please put the name of the function's filename in the title).

Herein lie the Footnotes )
Once upon a time, in my more evil days, I came up with an idea that I found entertaining.

The idea went a little like this: I ever ended up teaching in secondary school, I'd probably have to teach a transition year module; I'd call that module "Practical politics". I'd make a nice big web-application based on the Risk board game, but with various enhancements as were needed. I'd make a LOT of territories, and give a few to each student. I'd then give them non-destructive, but competing, goals like "secure territory X", wherein anyone with that goal would get 1 point towards their final score if they held that territory for a day.

I hadn't even heard of the Stanford Prison Experiment by that stage.

It got worse: my idea encompassed giving a survey at the start, to work out the various social networks and subnetworks in the class, and then basing the goals on that. In my thought experiment I reckoned it'd be fun to have friends vie for similar territories to see how they'd resolve the issues. I tried to predict the fun of a role-reversal as the unpopular kid found themselves in a position of power holding a resource that others would have to negotiate for in order to get their points. My mind positively spun with the idea of giving some people "reporter" roles, where they required the co-operation of a host army in order to operate, but earned their points based on the subscriptions of the other classmates.

Somehow, optimism prevented me from seeing this turn a little in the way of Lord of the Flies. I thought that it'd be an entertaining way to teach kids about the disconnect between what's seen on the map and what they are trying to achieve, and how a tiny bit of back-room chat could make or break a situation.

As much as I've grown as a person, and realise it's a fundamentally bad idea, I'm still ever-so-slightly in love with the idea. But a recent game of risk (the game that started this chain of thought) reminded me why this is a fundamentally Bad Idea (tm): back-stabbing is part of the game. You form tenuous alliances waiting for the point where they fall apart, knowing it will end in tears, and you still cry when they do (sometimes cries/tears/howls of laughter).

While this is a valuable lesson for everyone to learn, the above method is not the way to teach it. And this is why I should never be a teacher.

(P.s. I don't think anyone actually reads this, but if you do, I'd love to hear of any Horrifically Bad Ideas you've had)
There's an idea that's been playing in the back of my mind recently: given the diverse background of people involved in roller-derby, why aren't more of the resident techies making things to facilitate officiating the sport?

Actually, that's a bit of a loaded question. They already are. One of the most visible examples is the scoreboard you see projected on a board/wall at most bouts.

A bunch of people took time out to make stuff happen.

As a personal project, I want to write yet another penalty box timing app, one that suits my needs, given that I've done the job and know what irks me about my current system. (Also, I just want an excuse to code up a simple android app for a tablet I plan on purchasing)

After a random conversation at a practice session, it seems other people have other problems they want solved, and other than cost for a pre-packaged solution, I don't see why some of these things can't be done.

For instance, if you're tracking penalties, it's frequently hard to hear referees' calls. What would be interminably cool is some sort of headset system so the people on the inside could listen to the penalties on headphones and deal with them. The main issue is the transport signal (radio/bluetooth/whatever) and the ergonomics of it (and maybe the communication structure).

What I'd love to see is a timing device that could tie into the scoreboard so that the timekeeper could ensure correct time was displayed to the audience/skaters. The easiest solution in my head would be a smartphone app that utilised some method to communicate to the machine running the scoreboard software. Hell, then we could maybe have the penalty box software listen in to sync with the timekeeper so that the timing starts and ends with the jam.

Even if it was beyond the skillset of the league's members, I wonder if something like the Science Day Hackathon could work? Sometimes the hardest thing about figuring out about making something is what to make, or deciding what problem you want to solve.

I think improving some of the technology used could solve a lot of our problems, and it'd be really interesting to see if it works. It's mostly a matter of getting the right people together.
Conferences are fun. They're a great way to share skills with other people, chew the fat, and an excellent chance to just take off your blinkers and look at the technological world outside of your job. It's also good for getting drunk and telling war stories.

Sometimes you even get employers paying for employees to go to conferences to learn stuff. Unfortunately, working in QA there aren't a lot of technical conferences geared to my profession. QA have the best, and most damaging, war stories and they'd probably count as confidential information. So, companies don't pay for us to meet and trade tales of happenings that they'd really rather not let the public, or their competitors, know about. This means I tend to just go to some local OSS conferences and mill about playing the technological magpie, and also socialising.

One group that I like is the monthly Python Ireland group (although I've not gone to a meeting in far too long), and I also attended 2011's Pycon Ireland. It's great to see a number of talks and presentations that make me aware of new technologies, or novel uses for what I already use.

These days, in lots of meetings like this, there's a tendency to record the presentations and distribute the slides and source code. This is really cool, although frequently I find myself miffed that I get a choice of one or the other (recording or slides), but generally not the one I want at the time; that's just Murphy's law at work.

Recordings make interesting presentations like 'Daemon Slaying! Or, Unix Daemons in Python for fun and profit!' available to me, and I'm able to start thinking of how I might want to use them or if I should squirrel away that information for a rainy day. Having also been involved with Toastmasters, I immediately began to write up feedback for how that presentation went, so that I could have a list of tips for what I'd do if I had anything to present (this is from the speaker's point of view, not that of the organisers/camera folk):

What went well
  • He spoke clearly - he obviously had some sort of sound check as well

  • He knew the material he was going to present - it's actually amazing how many don't, and think they can wing it. That said he did surprise himself once with his code.

  • I didn't notice any verbal crutches or audible hangtime - that means he had no 'umm's or 'ahh's. Blank space was either left blank, or he repeated a point while giving himself time to think.

What could have gone better:

He forgot he was being filmed. Normally this is a good thing in that you don't get self-conscious or talk to the camera when you really should be addressing the people in the room. However, there were occasions where it worked to the detriment of the video audience (which is potentially bigger than the people who are in the room):
  • During one slide, he pointed to elements of his slide that he thought were and were not important - he didn't bother to say what those points were, he just pointed to them, leaving the camera operator to quickly orient and focus the camera not just on the speaker but on the points he was making.

  • Question time - he didn't repeat the questions he was being asked by the audience. In fact, I'm pretty sure there was a whole bunch of audio problems as the sound didn't cut back to him until he was half-way through his answer, but it's good practice to repeat the question back on the mic so that the video audience will know what's asked rather than trying to infer it from the user's answer.

It should be noted however, that I work for a multinational where I'm not always in the same room for a presentation. Sometimes all I have is a pdf and a phone, and I have to keep up with the rest. After enough of those, you start to consider the above to be a hanging offense, and you become conscious of it FOREVER MORE!

But overall, I really enjoyed that presentation and its content. He did nearly everything right, except for ignore the video audience, and it reminded me of some basic points which still apply to pretty much every talk:
  • Speak clearly

  • If you're being recorded, be aware of what the video audience can and cannot hear, and relay anything that may be of interest back to the video audience

  • Know your material and its flow

  • Avoid verbal crutches in the main material - it never comes across well on recordings (video or audio)

Hopefully I'll remember them if I ever have to do something like that.
So second freshmeat down. At the risk of turning this into my personal derby blog, I'd like to state this isn't my personal derby blog; it's about stuff that I like/want to do outside of work. It just so happens that I've found that derby's worked its way in there.

Anyway the rest are personal notes about fresh meat, that are probably of no interest to anyone:
No, really. Not interesting )
Last year, my attempt at Fresh Meat came to an abrupt halt due to a groin strain. I was fairly disheartened given my poor performance for that second session (I was falling over on basic knee falls, which wasn't exactly safe). Eventually I pulled myself from the session and realised a few days later that while most of my owies had disappeared (as expected), this one was a real injury.

As a result, I dropped out of the programme and, as a way to keep involved with a great bunch of people, I decided to help out as a Non-Skating Official (NSO).

As a quick side note, if anyone ever feels they want to get more involved with their local league, without learning to skate, I would suggest volunteering as an NSO. Leagues love good NSOs, and it's a great opportunity to get to know your local league, and all the people within it.

With 2012 rolling around, I decided my new year resolution was to get through a full Fresh Meat programme; I don't care about whether or not I pass assessments at this point in time, I think it's ambitious enough to work towards surviving the full 8 to 12 weeks.

What little prep I did )

How the Fresh Meat sessions went )

All in all, 'twas fun. And I'm still not sure how I'm not sore right now. (Warning, this post may be edited tomorrow so that I can articulate exactly what exquisite pain was waiting for me in the morning)
In case you haven't figured out from half of my posts, I'm one of the many people involved in the software industry. While most of my job is Quality Assurance, there's a relatively significant development portion as well; such as developing internal tools. Some of these tools are web-based, and some of them aren't.

Over time, I've developed a bunch of habits and tools that are probably so inutterably obvious to the professionals that they don't bear mentioning. That said, there's always a wealth of information for beginners and pros, but very little for those stuck somewhere between. Sometimes academia will teach you grand plan for how something works, but will ignore the basic techniques for writing anything more complicated than "Hello World". I'd like to make a humble effort to bridge that gap (although I think I'm still crossing that gap myself) by sharing techniques that I frequently fall back on in the course of my job.

I really don't know how I want to format this, so I'll go with a rambling list.

  1. Learn your method for isolating and identifying failures - As a QA engineer, I need to know this one to do my job. As a result, I've picked up too many techniques to enumerate, but basically it boils down to building a theory of what went wrong, testing that theory, and then taking steps to fix the problem. Many people will sell many techniques (either for money or for mindshare), but you should take none of them as gospel. As time goes, you'll build your own technique, and you'll pick up tips from others. But the basics remain the same: Identify the deviation in behaviour; formulate theories on what caused that deviation; test those theories (preferably in a safe environment); fix the problem.

    As a side-note: it also helps to document your progress through your diagnosis in case you encounter a similar problem again. Most professionals do that in a bug report or in some other tool they've employed for the job. Trust me, that saves a lot of heart-ache.

  2. Outlines in comments are a good thing - this is how I'm fleshing out my list, and how I did most of my essays in college (and my blogs; if you look carefully you can see the seams dividing something I wrote at different points of the day, or even entirely different days). Yet it came as a surprise to some co-workers, once upon a time.

    Figure out the basic steps you want to perform. Write them out in comments. Fill in the code to complete those steps between the comments. If you want, delete the comments later, although I always think that's a bit of a bad idea. But, reading a lot of code blogs, I'm pretty sure people wouldn't like how I comment. That said, these comments are just to remind you what the basic steps of your program are - this allows you to walk away from your program for a while, return to it, and figure out what the hell you were in the middle of doing.

  3. Investigate and learn how to use some tools of your trade - Depending on your development domain, there can be a lot of tools available to you, or not very many. No matter, you should take some time to get the lay of the land. One very useful tip, when you find yourself developing in a new domain is to browse around various forums and discussion groups to see what names crop up frequently; chances are you'll do well to become familiar with them before you're forced to do so.

    For instance, I had to maintain an internal webtool that relied very heavily on javascript. Mozilla's "view source" only showed the page that it had downloaded, not what it went on to render. For that, I found firebug to be indispensable; it would have taken me a lot more time to understand what was going wrong if I didn't have a tool like that at my disposal.

    I still don't use, or know how to use, a good 90% of its features. That doesn't matter, because the 10% I did use did the job I needed.

  4. Maintain a 'trinkets' directory - This is a little habit of mine, and I don't know if anyone else does this. I find this works better for scripts than it does for compiled languages, but both are perfectly acceptable; I just find compiled languages require a little more work (so I normally keep a template handy). Trinkets are exactly what they say on the tin. They are small playthings that you use to prove a concept to yourself in some way. In work, I currently have 3 trinkets directories for 3 different languages: c, ksh and perl. I've tidied up a handful of these and I'm putting them up for people to see - Hosted on BitBucket.

    Trinkets are useful because they allow you to test something outside of production code. They normally focus on exactly one topic, and just have a bit of other trivial code to show the output of what you're doing.

    At this point, I feel I must stress something: TRINKETS ARE NOT UNIT TESTS.

    A unit test is testing the functionality of your product, and should be automatable. A trinket is meant to solidify your working knowledge of something. Chances are you'll throw it away after you're done. A unit test should know whether it passed or failed. A trinket is meant to expose some functionality so you can eyeball how it works. A unit test tells you if you've broken something. A trinket tells you if you understand a concept or not. You're meant to play with it, and make it work. It's not any indicator of the quality of your project, it's simply a way for you to solidify something you weren't sure about. Trinkets are a learning tool, not production code.

These are practices that I use when coding. I'm pretty sure the programming community at large will sneer at some of them (namely comment outlines and trinkets), but I think these are really useful, especially for beginners.
One of my fascinations, although not enough to warrant giving myself any sort of title, is the history of computer folk in the days when unix and the internet were purely academic subjects. A lot of interesting culture and cultural terms emerged from that time, and seem to be relatively consistent. There again, the consistency probably stems from the fact that the authoritative tome for these terms is the FOLDOC (Free On-Line Dictionary Of Computing).

Some of its more famous articles are still common terms in industry today, such as Cargo Cult Programming. One of my favourites is the Magic Switch Story (although it's rather less famous, or at least not used commonly).

What really captures my imagination is that these terms are relics from what is the closest thing to an oral tradition as we're going to get. A lesson abbreviated into the title of a story or lesson. You hear terms like "Deep Magic" and you can guess at what they mean, even before you read the definition. Sometimes when I take a step back and look at what programmers are actually saying to each other, I can only think of "Darmok and Jalad at Tanagra". (By-the-by, the fact that I'm linkspamming with various pieces of hacker folklore, and the plot summary of a Star Trek episode is not lost on me)

Sometimes I'd get a little lost feeling about not having the same common depth of folklore nowadays, but hanging around the likes of reddit, I realise that there's as much of a common language now as there was before, but it's shifted. I can talk about doing a Bobby Tables and expect that folk understand it. If I say someone's a real BOFH, you might get an idea as to what to expect.

There are also traditions that are spreading as memes. For instance, the editing of production code, live on the server, now requires the perpetrator to wear a Pink Sombrero... and the thought of the pink sombrero brings me onto one of my own traditions.

Just over half-my-life ago, I was at the right age to appreciate the cartoon Earthworm Jim when it came out. I loved the graphical beauty of the game, even though I wasn't very good at it, and its attitude. To my mind, the cartoon managed to faithfully recreate and enhance aspects of game, and it was just enjoyable.

There's one scene from that cartoon that's stuck in my mind from then until now: Jim is, once again, captured by the bad guy of the episode, a particularly televangelist-sounding fish, who wants Jim's suit and, as a bonus, wants a nice worm-roast for dinner (what with Jim being a worm and all). The henchman tasked with making said wormroast decides to watch a cookery programme and learn how to make pot-roast. The henchman, not being the gifted in his class, says something to the effect of, "I know, when he says 'pot', I say worm."

The conversation follows something like this:
Chef: We're gonna make a pot-roast tonight.
Henchman: Worm Roast!
Chef: To make a pot-roast-
Henchman: Worm Roast!
Chef: you get a nice shiny metal pot and stick it in the oven.
Henchman: Get a shiny metal worm.
*casts eye around, and settles on a generic cartoon missile and shoves it in the oven*
*Hilarity ensues and our protagonist makes his escape*

So, how does this have anything to do with hacker culture, folklore, sayings and traditions?

Well, I sometimes have to heavily modify existing scripts. For better or for worse, I frequently find myself renaming and retasking one major component to make room for another. That's mostly fine but, from hard experience, I'm always conscious that I'm probably missing some of the subtleties that stop me from directly renaming one thing to another. Chances are I've got 90% of the problem in my head, it's just that last 10% is going to hurt me if I stumble blindly just swapping bits around.

It's just like saying 'worm' whenever they say 'pot' without understanding that the two are not completely substitutable.

Just to remind myself, when I do that sort of work, I chirp out in my dumbest little voice, "WORMROAST!"; it's fun trying to explain that one to co-workers who already think you're half-mad. Now that I've explained it to them, I'm more prone to chirping "WORMROAST" in the office.

I know that my call of "WORMROAST" isn't going to catch on any time soon, but it's a story that keeps me amused while I go and break things in the name of progress.

I know places like Stack Overflow like to enumerate all the new little terms that have turned up, but I'd love to hear any personal little terms you use, either in the comments here or by twitter.
There's a new obsession in my life. It's been building slowly. It's rollerderby.

For those that don't know what it is, this video explains it pretty well. What the video doesn't convey is the raw energy that hit me when I went to my first bout. Similarly with my second... and third. At the first bout, I really couldn't stop buzzing; it infected me. I suppose it doesn't help that I know one of the referees, and one of the girls who was involved in the Dublin league at the start. It wasn't the clothes, or the names, or the afterparty; it was the attitude. It was the fact that girls of different shapes, sizes and ages were involved and kicking ass... and it was our local sports team (seriously, I've never gotten that before).

Wherein I describe FreshMeat and unleash a clusterbomb of What The F*** thoughts )

On Derby Names )

And here's the real cincher: I'm pretty sure that none of what I've written sounds in any way rational. I haven't mentioned why I want to do it, beyond the energy of the events that struck me when I was watching as a fan. I haven't mentioned why I want to put myself through that much duress just to get to somewhere that I haven't even thought ahead to. Like I said, I don't know if I'll ever be good enough to play in a public bout, but all I know is that I don't want to stop, and that I want to give it a good shot, even if I don't meet the skills the first time around.

To be honest, I'm not going to over-analyse my motivations, I think it might ruin whatever it is that's driving me, and I haven't felt something like that for a long while. So, I'll just let it ride.

* Warning: probably not clinically neurotic
We're hiring in work. I happen to work in a Unix place so, when we hire, we tend to ask Unix questions (strangely enough).

Like most interview processes, we have a bunch of questions that we make sure we ask, and we might spit-ball a few follow-on questions just to test the range and depth of the candidate's knowledge in that area.

As an aside, I know everyone gets nervous in an interview, but in our interviews we want you to succeed; we're asking questions to see how much you know, not because we want to jump down your throat for not knowing it. The only rule I have as an interviewer is Don't Bullshit Me; if you don't know something, say so.

Anyway, there's one set question that is interesting. "What does the term fork/exec refer to in UNIX?" I didn't write the question, if I did, I'd leave it at fork(), because the answer we're looking for has nothing to do with exec(). What we're looking to segue into is a little chat about processes and subprocesses. Once they pick up on the fact that we're talking about processes, I'll start asking the questions that aren't set, like how you can find out what the parent process is. One of my favourite follow-ons is quickly becoming my head-desk question:

"What happens to the subprocess when the parent process dies?"

The inevitable reply is "Um, Zombie Process?". Normally, I'd let that slide; partially because I'm so nervous I forget the term "Orphan process" and don't mention that it's reclaimed by PID 1 (or at least, it typically tends to be init in most implementations).

An orphan is a subprocess that's still doing work after its parent died.
A Zombie process is a process, that has finished its work but is still in the process table because its parent hasn't reclaimed it with wait().

This is just one of those things that starts to bug me because a Zombie process is something to worry about, but orphans can be fine. I've used, and modified, shell scripts that spawn off children to finish their work while the parents go off and die in order to return control to the user. It's not great architecture, but it's ok, because the work done is big, and we don't want a user sending a SIGINT and leaving the work half-finished.

But, people say "Um, Zombie Process?" because it Sounds Cool.

Please, stop that. I don't want to sound like those bloggers that shout "YOU'RE WRONG" at the entire Internet, or one of those "Too cool" bloggers that likes to use a harsh tone because they're the uber-elite caste of computer professional. I just want people to know a little more so I don't have people trying to score cool-points when I ask a slightly obscure Unix question.
Over the past 2 months, I have occasionally found myself spending a lot of time working in the server labs in work. The job was re-racking machines; that is, taking machines from one rack and placing them on another. The reasons for this were daft enough as they were, so I won't go into it. However, I have learned a few lessons along the way. Some of these were hard learned, given that my job doesn't normally require me to spend much time in there.

I will dispense this advice nowNot in the form of Baz Luhrmann's Sunscreen Song )
Cross-posted to [community profile] command_liners

I'm a fan of twitter, and one of the features of the territory is shortened links. The twitter web interface generally does a half-decent job of expanding these posts, but I don't always get to see the expanded link.

Sometimes I want to see where the link leads without actually visiting the site in case it's hosting malicious scripts. After a little bit of digging I found that wget can do exactly what I want. I have a little throwaway directory (in my case, '/export/home/sketchy', which allows me to see where the link points to.

For example, let's say I see a link (it leads to a blog post of mine, so nothing very interesting) and want to know where it leads:

tara_hanoi@tara_babel:/export/home/sketchy$ wget --max-redirect=0 http://t.co/8xED8dz
--2011-07-25 16:01:10-- http://t.co/8xED8dz
Resolving t.co...
Connecting to t.co||:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://bit.ly/guxtdh [following]

0 redirections exceeded.

The bit in bold is where you should be paying attention. In this case, the t.co link points to another shortener, bit.ly - if I want to follow that on, I don't have to paste that back into wget, I can just increase the 'max-redirect' parameter:

tara_hanoi@tara_babel:/export/home/sketchy$ wget --max-redirect=1 http://t.co/8xED8dz
--2011-07-25 16:03:50-- http://t.co/8xED8dz
Resolving t.co...
Connecting to t.co||:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://bit.ly/guxtdh [following]
--2011-07-25 16:03:51-- http://bit.ly/guxtdh
Resolving bit.ly..., 2001:418:e801::12:1, 2001:418:e801::15:1, ...
Connecting to bit.ly||:80... connected.
HTTP request sent, awaiting response... 301 Moved
Location: http://tara-hanoi.dreamwidth.org/1508.html [following]

1 redirections exceeded.

Ok, so it leads to my own DW entry, so I'm pretty sure it's ok.

This might be useful for folks as a quick and dirty way to expand shortened URLs.
(My first attempt at actually writing anything in this blog that is in any way related to the reason I set up this thing in the first place - this is also my first ever attempt at a review of a resource, so some feedback on style would be appreciated)

Because it's been on my ToDo list for a while, I decided to try learning Ruby. Having learnt python from a fabulous publication called Dive Into Python, I realised that when learning a language, I want to learn the feel of the language and not just the bare syntax of it.

To me, learning the language's style is a must; there's a nice satisfying mental click when you get how things are phrased in the language. You suddenly see the strengths and weaknesses. Given as I prefer to use the language as it's intended from the outset, I like learning the language's idioms from the outset.

For the non-techies, it's the difference between human languages. For instance, how do you introduce yourself. In English, I'll go with one of a few options: "I'm [personal profile] tara_hanoi", or "My name is [personal profile] tara_hanoi". In French, you don't apply the concept in that way. Instead you say, "I name/call myself [personal profile] tara_hanoi". In Irish, you say, "[personal profile] tara_hanoi is the name for me". Sure, technically, you could mangle the English way of expressing what your name is and force the entire construct into the language and make yourself vaguely understood, but if you REALLY want to speak like a native, you need to use the shape of the language to your advantage.

I also realised I like introductions targeted at people who already understand programming. Things like if/then/else logic and loops are pretty standard fare for anyone who spends their time telling a computer what to do; you need to know how they work in any non-trivial language, and I don't need it all explained again. What I do need explained is the syntax and any associated caveats.

Beyond syntax, I also need to know what idioms are used and why. In python you have list comprehensions, which reduces trivial loops to one-liners in a readable fashion; if you try to write python the way you'd write some beautiful C code, and without grokking The Zen Of Python, you'll end up with a horrible half-formed mess as you try to marry 2 different cultures of elegance, breaking the rules of each in order to satisfy the other. If that style of program could speak, it would look up with doleful, rolling eyes and whisper, in a hoarse, scratch voice, "Kill me". The saddest thing is, unless you know the culture of the language you're learning, you won't even realise you've created such an ill-fated monster. Furthermore, despite not recognising the ugliness of your code, you'll probably fail to feel any serious attachment to the language and walk away.

I wanted to learn Ruby in a way that would put Ruby's features to good use, and I wouldn't try to use it like Java or C or even python. Sure, knowledge of how things are done in each of those languages help, but if you're always hacking a ruby program in the way you'd use C, why not just use C all the time?

By sheer chance, I happened upon Ruby Koans - a test-driven way of getting you into the Ruby Mindset. The idea of Koans appealed to me; I was fortunate enough in my upbringing that my dad told me early on what a Koan was. To me, a koan (although I've looked it up on wikipedia, and what it explains is different to what I understood) is a mental focus used for meditation. It helps jolt your mind with a paradox so that you slip into understanding the infinitesimal space between binary answers to an apparently either/or question. "If a tree falls in the forest, and there's no-one around to hear it, does it make a sound?", that sort of thing.

Following that idea, I liked the idea of some basic exercises that kickstarted you into the Ruby headspace. I also liked the idea that it was test-driven. I've been getting into test-driven development, or at least making sure I have a bunch of unit tests for my programs (they might not be written first). I'm also a Quality Engineer by trade, so I know how tests should work; tests should be clear, unambiguous and target one specific area as precisely as possible. (That's the theory anyway, there are always problems achieving that mystical goal)

I sat down and ran the tests. It is nice to have a directed, hands-on guide through the language, and it mostly delivered. You get a nice output with the failure, and the expected output. It's a nice little output, although, sometimes you really get the answer that you should be filling in from that. It's hard not to rely on those outputs in order to just fill in the answer that's expected without thinking about it. As a result, to improve my learning experience, I had to deliberately tune out those outputs telling me what I'd expect to see in order to make the test work.

It's stated on the page that the expected way you work through the tests is: See the test break, Fix the tests, Refactor/Meditate. Unfortunately, there wasn't a lot of refactoring/meditation to be done, and by the time you do get to the point that you have to start meditating on the experience, you're so out of practice with it, that you probably won't.

Overall, the Koans gave me a whirlwind tour of the language, but I'm not sure I know it well enough to program in it, despite having hands-on experience. For the most part the tests involved modifying implementing a one-line fix in a test. Sometimes there were projects where you'd write some code and, at the time, I felt competent doing so. But about 2 weeks on, I haven't heard some voice in my head saying, "I could express that Ruby-style".

It did do a solid job of expressing one ruby-ism, which was its peculiar in-line block style. For a small while, I got how it separated out concerns. However, I don't think I'd be able to write something in/for that style in any way competently.

Part of this whistle-stop tour of Ruby involved a deep-dive into some of Ruby's special innards. As a first-time learner, using the Koans as a tool, I was a little perturbed by this. Specifically, it played with the idea of send() and some method_missing function; that's great, but is this something where I'm expected to know what it is, just in case I see it, or is it something that's almost expected of the user to use? Were I to change the way Ruby Koans was organised, I'd probably introduce the concept of a scenario file. I'd have at least 2 scenarios, one for first-timers, and one for people who want the deep-dive.

At this point in the deep-dive, I started getting worried. There were comments like "This object can use send() and __send__() what do you think the difference is". Great, if I google that, the first hits are probably folks who are asking exactly the same thing because they were working through the Koans. It would be nice to have a little explanation, or some resource where they think it's actually well-explained.

Some other bits seemed woefully lacking. Sure, I knew how to use loops... sorta. But I realised I had major gaps in my knowledge when I tried to refactor a project I was working on. For all the shiny things the Koans taught me about loops and control flow, I found myself wondering that the basic syntax was for looping with an index ("run over the numbers from 1 to 6 and put it in a variable called i for me")? I looked back and found nothing on that subject (although from other aborted attempts to learn the language, I knew it existed). In the end, for the project I was working on, I just googled the Array class, and worked out a way to initialise a random array (if you do the Koans, you'll probably see what I'm talking about). I still don't know if I really did it the Ruby way or not, or if the way I was thinking of was a good way to do it.

So my final thoughts?

Would I give it to a day-0 programmer - Dear lord, no. But that wasn't what I was looking for.
Was it condescending? - Thankfully, no.
Would I recommend it as a ruby primer for folks that already know how to program? - Maybe. Depends on their mindset. I'm not sure I was of the correct mindset, but I think there were some gaps as well. It also mixes in some Deep Magic without any way to not dive into that stuff, and without pointers as to where to find out more.
Would I feel equipped enough to understand the framework code after working through the Koans? - Um, no. I've just looked again, and it's still Dark Magic.
Do I feel it's good for a ruby expert who wants to check if they know their stuff - Probably.

Basically, would I recommend it to others? Probably not.

However, the caveat is that I started with some clear idea of what I wanted, and hoped the Koans would live up to that. So that failure is with me. Maybe later on, when I finally grok the language, the Koans will be handy in solidifying my knowledge, but right now I feel I'm probably best off unlearning what I have learned (not hard) and try to find another resource geared towards programmers.



September 2015



RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 21st, 2017 06:42 am
Powered by Dreamwidth Studios