Upgrade your models from PHP to Java

I’ve recently had an opportunity to work with my team’s new developer, as part of the ongoing campaign to bring him over to core Java development from our soon-to-be end-of-lifed PHP tools. Since I was once in his position, only two years ago—in fact, he inherited the PHP tools from me when I was forcefully reassigned to the Java team—I feel a certain affinity toward him, and a desire to see him succeed.

Like me, he also has some limited Java experience, but nothing at the enterprise scale I now work with every day, and nothing especially recent. So, I gave him a copy of the same Java certification handbook I used to prepare for my OCA Java 7 exam, as well as any other resources I could track down that seemed to be potentially helpful. This sprint he’s physically, and semi-officially, joined our team, working on the replacement for the product he’s been maintaining since he was hired.

And just to make the learning curve a little bit steeper, this tool uses JavaServer Faces. If you’ve developed for JSF before, you’re familiar with how much of a thorough pain in the ass it can be. Apparently we’re trying to weed out the non-hackers, Gunnery Sergeant Hartman style.

So, as part of his team onboarding process, we picked up a task to begin migrating data from the old tool to the new. On investigating the requirements, and the destination data model, we discovered that one of the elements that this task expects has not yet been implemented. What a great opportunity! Not only is he essentially new to Java, he’s also new to test-driven development, so I gave him a quick walkthrough the test process while we tried to write a test for the new features we needed to implement.

As a quick sidebar, in trying to write the tests, we quickly discovered that we were planning on modifying (or at least starting with) the wrong layer. If we’d just started writing code, it probably would have taken half an hour or more to discover this. By trying to write the test first, we figured this out within ten minutes, because the integration points rapidly made no sense for what we were trying to do. Hurray!

Anyway, lunch time promptly rolled around while I was writing up the test. I’d suggested we play “TDD ping-pong”—I write a test, then he implements it, and the test was mostly set up. I said I’d finish up the test on the new service we needed, and stub out the data-access object and the backing entity so he’d at least have methods to work with. After I sent it his way, I checked in after about an hour, to see how he was doing, and he mentioned something that hadn’t occurred to me, because I had become so used to Java: he was completely unfamiliar with enterprise Java’s usual architecture of service, DAO and DTO.

And of course, why would he be? I’m not aware of any PHP frameworks that use this architecture, because it’s based on an availability of dependency injection, compiled code and persistent classes that is pretty much anathema to the entire request lifecycle of PHP. For every request, PHP loads, compiles, and executes each class anew. So pre-loading your business model with the CRUD utility methods, and operating on them as semi-proper Objects that can persist themselves to your stable storage, is practically a necessity. Fat model, skinny controller, indeed.

Java has a huge advantage here, because the service, DAO, and whole persistence layer, never leave memory between requests, just request-specific context. Classes don’t get reloaded until the servlet container gets restarted (unless you’re using JSF, in which case, they’re serialised onto disk and rehydrated when you restart, for… some reason). So you can write your code where your controller asks a service for records, and the service calls out to the DAO, which return an entity (or collection thereof), or a single field’s value for a given identifier.

This is actually a really good thing to do, from an engineering perspective.

For a long time, with Project Alchemy, I was trying to write a persistence architecture that would be as storage-agnostic as possible—objects could be persisted to database, to disk, or into shared memory, and the object itself didn’t need to care where it went. I only ever got as far as implementing it for database (and even then, specifically for MySQL), but it was a pretty valiant effort, and one that I’d still like to return to, when I get the opportunity, if for no other reason than to say I finished it. But the entity’s superclass still had the save() and find() methods that meant that persistence logic was, at some level in the class inheritance hierarchy, part of the entity. While effective for PHP, in terms of performance, this unfortunately doesn’t result in the cleanest of all possible code.

Using a service layer provides separation of concerns that the typical PHP model doesn’t allow for. The entity that moves data out of stable storage and into a bean also contains both business logic and an awareness of how it’s stored. It really doesn’t have to, and should. Talking to the database shouldn’t be your entity’s problem.

But it’s still, overall, part of the business model. The service and the entity, combined, provide the business model, and the DAO just packs it away and gets it back for you when you need it. This two classes should be viewed as part of a whole business model, within the context of a “Model-View-Controller” framework. The controller needs to be aware of both classes, certainly, but they should form two parts of a whole.

Besides, if you can pull all your persistence logic out of your entity, it should be almost trivial to change storage engines if and when the time comes. Say you needed to move from JPA and Hibernate to an XML- or JSON-based document storage system. You could probably just get away with re-annotating your entity, and writing a new DAO (which should always be pretty minimal), then adjusting how your DAO is wired into your service.

Try doing that in PHP if your entity knows how it’s stored!

One of these days, I’ll have to lay out a guide for how this architecture works best. I’d love to get involved in teaching undergrad students how large organisations try to conduct software engineering, so if I can explain it visually, then so much the better!

Women don't join this industry to fulfil your fantasies

It’s been another bad day week for men in the technology industry being complete and total shitheads to women.

Admit it, guys, we didn’t have very far to fall to hit that particular point. But last Friday uncovered a few particularly horrible examples of just how poorly some men can regard women, and how quickly others will come valiantly leaping to their defense.

My day opened up with being pointed to codebabes.com (no link, because fuck that). Describing itself as a portal to “learn coding and web development the fun way” CodeBabes pairs video tutorials with scantily-clad women, and the further you progress in a particular technology, the progressively less and less the instructors are wearing. As if software development wasn’t already enough of a boys’ club that has used busty women to get people to buy things (whether it’s the latest technology at an expo, or the latest video game), now somebody’s had the brilliant idea of having PHP and CSS taught by women in lingerie.

The project doesn’t even pretend to have any particularly noble purpose in mind. Above the fold on their site, the copy reads, “The internet: great for learning to code [and] checking out babes separately, until now.”

The mind boggles.

First of all—even if we were going to ignore everything about how socially backwards this idea is—is just isn’t an effective way to accomplish anything semi-productive. Did they not learn anything from trying to get off, playing video game strip blackjack? Or any other game where the further you progress, the more you see of a nude or semi-nude woman? Because this idea is clearly derived from those. The problem with those games is that in order to reveal the picture you want, you have to concentrate on the challenge you’re presented, but the more you concentrate on the challenge, the less aroused you are. The aims are in complete opposition to each other. If you’re trying to make learning a new technology a game, make sure that the technology is the aim, and the game is an extrinsic motivator. If you’re trying to look at naked girls… well, there are lots of opportunities to do that on the web.

But this problem is so much bigger than just being an unproductive way of trying to do two things at once.

What’s the catchphrase, again? “The internet: great for learning to code [and] checking out babes separately, until now.” These two things are implied to be mutually exclusive—that outside of the site, beautiful women and learning to write software have nothing to do with each other. That, were it not for these videos, beautiful women who look good in lingerie would have nothing to do with writing software.

So, if beautiful women who look good in lingerie would other have nothing to do with writing software, we can further assume that the creators are implying—and equally importantly, that their users will infer—that women know shit about computers (if I may coin a phrase).

Now, that being said, I’s quite sure that the women who are presenting these videos actually know what they’re talking about. There’s nothing more difficult than trying to convincingly explain something you don’t understand, unless you’re a particularly talented actor with a good script (see: every use of technobabble in the last thirty years of science fiction television). And I’m not trying to suggest that they should be accused of damaging the cause of feminism in technology. Why? Because there is nothing about this site that suggests to me that the idea was conceived of by women. The whole premise itself is simply so sophomoric that I can’t come to any conclusion other than that it was invented by men, particularly when the site’s official Twitter account follows The Playboy Blog, Playboy, three Playboy Playmates… and three men.

Software development, in most English-speaking countries, suffers from a huge gender gap, both in terms of staffing and salary. Sites like this will not do anything to close that gap, because all this says to a new generation of developers is that a woman’s role is to help a man on his way to success, and to be an object of sexual desire in the process—their “philosophy” flatly encourages viewers to masturbate to the videos.

What makes it that little bit worse (Yep, it actually does get worse) is that, on reading their “philosophy”, the creators also make it quite clear that they recognise that what they’re doing will offend people, and they don’t care. They say, “try not to take us too seriously”, and “if we’ve offended anyone, that's really not our goal, we hope there are bigger problems in the world for people to worry about.” Where have I seen these arguments before? Ahh, yes, from sexist men who are trying to shut down criticism of their sexist bullshit. The next thing I expect to see is them crying “censorship”. I’m not trying to prevent them from saying their repugnant shit. I would, however, like to try to educate them about why it’s hurtful, and why it’s something that they should know better than to think in the first place.

As for the rest of us, we need to make it clear that there’s no room for these attitudes in today’s software industry. That when somebody suggests visiting sites like this, they get called out for promoting sexist points of view. That when someone posits that a woman only got an interview, or even her job, because of her anatomy, that they get called out for thinking that she isn’t fully qualified to be there. If this industry has any hope at escaping the embarrassing reputation that it’s earned, we have to do better. We have to have to the guts to say, “that shit’s not cool,” to anyone who deserves it. Stand up for what you believe in.

How you speak reflects how you think

My good friend Audra pointed me to this list of “20 programming jargons” that is just full of awfulness. First of all—and this is the easy, facile complaint—I’ve never heard any of these terms (at least, with these definitions) used in the wild. Maybe it’s because I’ve generally worked for reasonably grown-up companies where we attempted to act like professionals, but who can say? I don’t quite know why these terms are so foreign to me, but some of them are just bad.

First, the good… or, at least, neutral:

Baklava/Lasagne Code

Okay, this one’s actually kind of good. Lasagne code evokes a particular variety of spaghetti code that got that way by adhering a little too closely to old “enterprise” techniques of organising class responsibilities, and by applying code patterns for the sake of applying code patterns. I’m hesitant to use baklava to describe this phenomenon because (a) baklava’s delicious, (b) there’s too good of a parallel to spaghetti code with lasagne, and (c) it feels like it’s making fun of Muslims, and I just don’t go in for that.

Banana Banana Banana

I’ve never heard of this, that I can recall. As an actor, I’m definitely familiar with rhubarb rhubarb rhubarb, the chorus equivalent of making it look like you’re having a conversation onstage without actually saying anything particularly coherent, that would pull focus.

Claustrocodeia

Can’t say I’m familiar with this term. Granted, I don’t like moving away from my nice 24” screen at the office, and working on my laptop screen, but it’s not like it’s anything more than a minor inconvenience. Get over it. Or buy yourself a big screen and expense it.

Stringly Typed

Again, this one’s pretty good. I’ve seen code like this, and it’s always much more of a headache than it could possibly be worth.

There’s Already A Word For This

Bugfoot

Over here, where the professionals work, we call this an “intermittent bug”. Could be environmental, could be infrastructure, could be code. But while we can’t replicate it, we don’t want to dismiss it out-of-hand, because this also means we can’t gauge its impact on the end user.

Jenga Code

Also known as “tightly coupled”. If you don’t already know this, or for some reason refuse to use this industry standard terminology, I frankly worry for the quality of your code.

Shrug Report

The bug report with insufficient detail. This is just a bad bug report, and should get sent back to the reporter for more details.

Unicorny

Otherwise known as “the business’s problem”. Unless you’re being called in to provide swag work estimates. I’ve also heard this as a “future project”.

Your Professionalism Is Showing

Counterbug

Code review isn’t supposed to be an adversarial process. When another programmer is reviewing your code, this is supposed to be about everyone’s professional development. Your reviewer may learn techniques they weren’t previously familiar with, and will gain exposure to more areas of the codebase, and that’s always a good thing. And by the same token, you’ll have the opportunity to learn techniques you weren’t previously familiar with, because your reviewed may be able to suggest a better (or even just different) way of solving the problem at hand. By saying, “yeah, well, you did this wrong”, you aren’t helping anyone (beyond exposing additional bugs to be fixed).

That said, getting used to code review as a collaborative process, and no longer hearing their comments as a personal attack, takes a conscious effort at first. But it’s effort that’s worth it. So when a reviewer points out an error, you should first bite your tongue, then think about what you can do better the next time around.

Duck

The business is not your enemy. Distracting their attention away from one particular area of the software is staggeringly unprofessional. It suggests that either you didn’t do your job properly there, or you think you know better what the business, or customer, wants. You might. You probably don’t; the business holds all the cards, and knows things they haven’t bothered to tell you, because they didn’t consider it germane to the feature request. If you have an issue with their ideas, the best thing to do is to take it up with them. In the event that they didn’t consider your alternative approach, then you might get them to reconsider their approach, and create an ultimately better product.

Refactoring

There’s a great maxim about how to write software: write code as though the next maintainer is an axe-wielding psychopath who knows where you live. Vivid, I know, and pretty violent, but I think it kind of gets the point across. Another, less aggressive version, describes the next maintainer as someone less capable than you with no context. If you’re writing code, or refactoring, and you don’t leave it in such a state that any developer could read it and know immediately what it does, you’re doing it wrong.

I know, I know; I’ve written before about self-documenting code being a lie. That doesn’t mean your code should be incomprehensible; it’s about not eschewing documenting your classes at a high level, simply because another developer need only read the code to understand it. Being a nice person to the next person is what self-documenting code is supposed to be about.

Smug Report

I’ll be the first to admit that I’m guilty of having this reaction to an external bug report that suggests that the reporter knows more about what’s going on than the developer. I’ll also cop to the reality that I’ve probably filed a few of these bug reports, as well. However, instead of going into adversarial mode, or trying to belittle the reporter, acknowledge something: you probably have a particularly technically competent reporter on your hands. If they’re outside your organisation, then you basically have someone who will do free testing for you! Make use of this reality, because you have someone on your level, who you probably wouldn’t have to work very hard to convince to do black-box testing. These reporters are gifts in human form.

Unfortunately, there are some that betray an awful interpersonal culture. Presented in no particular order, and certainly not the original order:

Being A Good Person: You’re Doing It Wrong

Jimmy

This, frankly, reads more like an in-joke at one particular organisation. Probably Jimmy was a wet-behind-the-ears recent graduate who managed to get past the interview, only to flail wildly until he was put out of the rest of the team’s misery. It happens sometimes. It’s unfortunate for Jimmy that no one on his team was willing to mentor him into a good programmer, but if the rest of the list was written at the same company, there probably weren’t many qualified candidates.

Not to say that professionals don’t turn colleagues’ names into in-jokes. Never mind that at the foosball table, I can think of at least four developers whose names are used to describe particular moves, one of our developers was, due to a fluke of seating assignments, regularly forgotten to be pulled into impromptu meetings. He’s now a verb, used when something (or, more typically, someone) is carelessly forgotten. However, this is done (a) in jest, and (b) is aimed squarely at the forgetter, not the forgettee. Poor guy just got it named after him after we did it so often that we started using his name as a shorthand for “we forgot him!’

So why is it unfair to call the clueless newbie a Jimmy? Because it pokes fun at the clueless newbie for being just that. Instead of mocking the new kid, they should be welcomed with open arms and guided into being a better developer.

Chug/Drug Report

Yes, suggest that the bug reporter was, at best, in an altered mental state when they wrote the report. This seems fair. Or, you could be working with a language barrier. Perhaps two, depending on when you, as the reader of the bug report, learned the language it’s written in. Assume that the reporter did their best to convey what they encountered, and give them the benefit of the doubt.

Mad Girlfriend Bug

First of all, this kind of bug is pretty much any bug that isn’t completely straightforward. Second of all, this is an idiotic gender stereotype. If you aren’t willing to try to communicate with your signficant other when you’re having an argument, your miserable relationship is your own problem. Finally, reinforcing idiotic gender stereotypes in the workplace is just one of the reasons that the gender balance both in the workforce and in school is so completely out to lunch. It’s one of the reasons that twice as many women as men exit programming as a profession. It creates a hostile work environment for your peers. Don’t do this.

Barack Obama

This one feels vaguely racist, and the fact that it’s the editors’s favourite, of everything on the list, gives a certain amount of credence to my worry in this regard. I want this to be a joke about Healthcare.gov, or about how a lot of liberal people had a lot of hope which has been repeatedly dashed, but the bit about “which would not otherwise get approval” bears a pretty strong suggestion that African Americans only voted for Obama because of the colour of his skin… and that just a reference of questionable future usefulness into a racist joke.

Ghetto Code

While I was simply wondering if the Obama project account was racist, this one pretty obviously is. Inelegant code is just that. Inelegant, perhaps sloppy. Tightly coupled. Not cohesive. Spaghetti code. With so many descriptors for code that isn’t elegant available… why on Earth would you go for the one that takes advantage of a marginalised group of people? Other than the obvious explanation that you almost certainly grew up in a life of privilege, with no idea of what it’s like to live in a ghetto. Bear in mind that the word ghetto was first used to refer to the quarters of the European cities where Jews were effectively obligated to live, because the Christians in power viewed the Jews as something less than themselves. Ghettos are areas of both crippling poverty and, at least once (if not still), systematic oppression. Your inelegant code is not described by this. Just stop using this word entirely.

As a profession, we get a lot of flak for how we treat people who don’t look like us… and I can’t say it isn’t well-earned. By adopting, using, and promoting language like this, all we’re doing is saying that we think it’s okay to do exactly that. It isn’t. So other than the two phrases up at the top… this stuff all has to go. The writers and editors at EFY Times who wrote and approved this list should give some serious consideration to what they’re really saying when they publish lists like this.

Abusing dependency injection for fun and profit!

Using Spring for dependency injection can do a lot more than just put together your singleton services how you need them, optionally tweaking them for different environments based on a configuration file.

Oh, the DI in Spring can do so much more fun than just that.

Let’s say, just as a “hypothetical” example, that you’re working with a controller and service interface in a prepackaged JAR that you either can’t modify, or would have to go through a far amount of headache to change. Specifically, you’re implementing the service interface, and you know it will be called from the controller.

You take on a new task that requires access to the HttpServletRequest. Okay, you think, I’ll just get it from the FacesContext, until you remember that this module isn’t using JSF (and you can’t make it—not your controller, remember?). You can read the controller source and see that the method that’s calling your service uses the HttpServletRequest, but it’s not a parameter on the service method.

Barring modifying the JAR, there’s a surprising, and easy, way to get at it: inject it. I kid you not, this works.

import javax.servlet.http.HttpServletRequest; import javax.inject.Inject; class MyService implements TheService { private final HttpServletRequest httpServletRequest; @Inject public MyService(HttpServletRequest request) { this.httpServletRequest = request; } @Override public void serviceMethod() { .... httpServletRequest.getRequestURI(); .... } }

That’s seriously all there is to it. You can inject anything higher on the call stack, though I suspect there needs to be only one instance of it. The HttpServletRequest gets updated with each request, even though MyService has been left in the default singleton scope. I wouldn’t recommend doing this simply because you can, though, for the sake of not having to pass the HttpServletRequest as a parameter. Injection breeds reflection, which is a crapton more logic, processing time, and memory usage, than simply passing a reference down the call stack. It also opens you up to debugging hell, particularly if you inject something that you then modify.

Use this with care, is what I’m saying, only when you have no other choice.

An unfit culture

Yesterday afternoon, Nitasha Tiku published a piece on Valleywag, entitled This Is Why There Aren’t Enough Women In Tech. It’s eye-opening reading, even for me (and I consider myself at least somewhat awake to the terrible ways in which women are treated in this industry). Go ahead, read it. I’ll be here. I’ve got a Scotch to keep me company. Read Shanley Kane’s February article and Ciara Byrne’s followup interview with Kane, while you’re there.

Read them? Good.

Assuming you’re a cis man… still feel good about yourself, and the developer culture in the office you work in? I hope not. Because if you’ve ever sat an interview, and were asked afterward about “cultural fit”, you’ve been on the edge of this problem. And the problem, as Kane puts it so eloquently over at Pretty Little State Machine, is that cultural fit is “a loosely coordinated social policy to ensure homogeneity in our workforce.” Cultural fit is a catch-all way of rejecting otherwise perfectly suitable job applicants, without having to flat out say that it’s because they don’t have a similar cultural background.

This also introduces design problems in your product. No, seriously. Hiring with a view to cultural fit ensures that your entire development team thinks similarly—and approaches problems similarly, allowing for slight differences in experience with the tools in use and with others. You could get an entire team of programmers who would write, structurally, almost the same code, just with different variable names. You might say, "great minds think alike," but I would suggest that fools seldom differ. Then. if you hire one person who is eminently qualified, and is largely unlike the rest of your staff (e.g. outspoken about what’s shit code and will just fix it, as opposed to the various forms of introversion you stereotypically see in programmers), you see not only significant structural differences in coding styles, but this also helps your entire team evolve as programmers. Instead of everyone already writing according to an unspoken code style, there’s discourse, improvement, and a gradual winnowing away of the chaff.

But enough about how cultural fit damages your codebase.

Cultural fit damages developer culture, and society as a whole. Reading through the anecdotes in Valleywag, I’ve seen hints of this attitude in virtually every office I’ve worked in, since I started working. My computer science program was, as in so many others, overwhelmingly dominated by men. The few women who started, and made it through the three years that I was there full-time, were either as naturally talented as some of the men, or struggled every day with it. And I can’t imagine it was made easy for any of them by the men, who alternately accused them of following their boyfriends into the program or buying answers, and incessantly hit on them.

I’ve said it before, and I’ll say it again, because it seems like every week I see another example of it: the tech industry, by and large, is an industry made up of little boys who were hurt over and over again, and never learned anything but how to hurt. They were rejected and hurt by their peers growing up, formed a tribe of comrade rejects, and grew to fear outside interest. When they were young, outsiders becoming interested in them led to pain, but now they have the means to reject and hurt those who rejected and hurt them. The bullied have become the bullies.

These hurting little boys grew up in a society of intense white male privilege. One where, even in 2003 when I began my degree, there were jokes that the women taking B.Comm. were really just being there for their “MRS”. One where the University of Waterloo was “jokingly” called the University of Waterwoo, on account of the high concentration of Asian students in the Math and Computer Science programs—almost as though they were displacing the rightful seats of (might I add, white) Ontario-raised students. A culture where, I hate to admit, I participated in jokes about final exams being either the perpetrators or victims of rape.

So these little boys, already distrustful of new people becoming interested in their interests, were raised to further distrust the motives of those others. And now that they’re creating tech companies, and doing the hiring, they’re applying that distrust to their staffing procedures, and keeping out everyone who doesn’t already think like them.

I’ve heard stories from colleagues—women who were interested in computers but hadn’t had the opportunity to try programming until they entered university—of being disregarded by the men in their program who had grown up in front of a keyboard and a CRT. That they were somehow inferior because, for whatever reason, they didn’t have the same opportunities growing up. The same men who, invariably, would describe developer culture as a welcoming meritocracy, where intelligence is fostered and output alone determines your worth. The same men who, on Slashdot (and later, Reddit) would, after receiving comments of “STFU, n00b” from their elders for asking naïve questions, would turn around and do the same to those who had naïve questions for them. A welcoming meritocracy, my ass.

Cultural fit is little more than code for “were you bullied as a kid for like computers and D&D,” when you get down it. It’s shorthand for decades of similar experiences of pain, and a similar unconscious desire to mete it out on the new kids. And it has to stop. We have to begin the difficult process of evolving past the pain and refusing to inflict it on others. Instead of demanding that people fit into our culture, we have to extend the olive branch to other cultures, and modes of thinking, and creating a brave new world where the meritocracy that we claim to exist is actually present. In private, we used to assure ourselves that, when we got older, the bullies would be working for us in the new knowledge economy. That knowledge economy seems to be here, but all the old rules of proving who’s got the bigger dick seem to still in force.

So to anyone and everyone reading who sits an interview, I call you to reject cultural fit, and reject old ways of thinking, and help create the meritocracy and the culture we all wanted our community to be.

The only limitation has been in your mind

A few days ago, Infinity Ward announced that the upcoming Call Of Duty: Ghosts would provide an option for players to inhabit the online mode of the game either male or female characters. Finally! About 14% of US Army personnel are women, and women are further underrepresented in Xbox and PlayStation users at 10%, and Infinite Ward has joined the ranks of enlightened game publishers, like BioWare, who recognise that they ought to reach out to all their customer demographics, not just the biggest one, because it's the right thing to do, even if they are a bit late to the party (2013, guys).

Right?

I want to believe that, really I do. The only problem is that producer Mark Rubin has gone on record explaining that the reason that CoD has never before offered women as playable characters was a technical limitation in the engine. Memory and processing requirements have, until now, been far too significant to provide players with the option of using multiple meshes in online play.

I might be able to believe that, if this were, I don't know... 1996. If I'd never played Quake 3 Arena on a sub-1-GHz system, which comes stock with a wide variety of meshes, and provdes players with the option of installing their own meshes, which would be seen by all players in the arena, all over the world. If I didn't own a copy of Halo 2, which allows players to appear on Xbox Live as either a Spartan or a Covenant Elite. If there wasn't a wealth of evidence supporting the fact that the technology has been out there to do exactly that for almost two decades.

Mark, if your engine can't handle showing characters with two different meshes in this day and age, on modern hardware, you are simply using the wrong engine, or you are abhorrently misusing it. But I find that hard to believe; if your engine was as shitty as it would have to be for your excuse to be realistic, then the Call of Duty franchise wouldn't be remotely as popular as it is.

Just admit it, Infinity Ward. You haven't offered women as playable characters because you didn't consider them a sufficient demographic to justify the expense of creating a second mesh (which, incidentally, would have been... What? 10K? 20? And what's your budget on these games?). You'll feel better, because you can also admit that you've been doing the wrong thing, and you want to make it up to the devoted women who play your games. That you want to encourage more women to play your games (because why wouldn't you? At 51% of the population, it's a huge market). That women deserve a hell of a lot better than the shit they receive from both the gaming industry and community, each and every day they play the games they love to play.

Anything other than the most bullshit copout to (dis)grace my screen in the last several months.

E3, or, Seventy-two hours of misogyny

After lunch most days, before returning to work, I typically take a few minutes’ break to catch up with Reddit and Twitter, to see if any of my friends have said anything funny or interesting today, or maybe there’s an programming-related article I can share with my colleagues. However, today, my Twitter feed had this waiting for me, courtesy of a retweet from @lindsaybieda:

Holy shit. Female 343 games producer walks on the Microsoft stage and a man *seriously* wolf whistled at her. Fuck you.

— brandon sheffield (@necrosofty) June 10, 2013

My immediate reaction was not unlike Gollum’s, when Sméagol tells him in the film of The Two Towers, “Master looks after us now. We don’t need you any more.”… what?

Now, I knew going into this that E3 is a ridiculous three-day-long display of sexism, objectification, and misogyny (oh, and something about video games, too). Last year, Scott R Kurtz had a character deliver a webcast from “either E3, or the world’s largest Hooters.” I have privately, among my friends, and probably publicly, too, lamented every marketing department’s decision to hire booth babes for a conference—to use women as little more than decoration and furniture— and I’ve written before about the technology industry’s rampant misogyny. It's not as though I didn’t at least somewhat expect the result of what I did next.

I ran a Twitter search for “#E3 Bonnie Ross”—just that—and was promptly given a feed full of complaints about the new Halo, pleas for 343 Industries not to mess it up… and a litany of tweets about Bonnie Ross: how good she looks, how inept she (apparently) was as a presenter, and multiple people explaining in sometimes graphic details that they want to have sex with her. In particular, @Boogie2988’s gem (since, it seems, deleted):

£429 do we get a complimentary blow job off Bonnie Ross with that?"

— Boogie2988 (@Boogie2988) June 10, 2013

I can’t believe that I have to ask this, but where the fuck do these guys get off, thinking that this shit is okay to suggest, let alone think?! Bonnie Ross is not the studio head of 343 Industries for you to cat-call, or to ask for sexual favours from. She is there to do a job, and judging by the Halo sales, she seems to be doing a pretty good one at that. If you think she’s a dull presenter, fine (during the BB10 launch, I described BlackBerry CEO Thorsten Hiens as having “all the personality of a wet dishrag”), but for God’s sake, can a woman, for once, show up at E3 and be treated with some basic human respect? Is that so hard, guys? Maybe, you know, not call her a MILF. Perhaps not suggest that “that bitch had to have skipped speech class.”

I went on a bit of a tear on Twitter, quote-tweeting and retweeting some of the more egregious offenders, because you know what? I am sick to death of the way that men in my industry talk about women, whether they’re presenting for their favourite console, or the speaker’s colleagues and peers. I would really like to think that, in this day and age, we were raised better than that, but, clearly, this isn’t the case:

@mgpcoe do you want to fight?

— goodsmell (@G__REX) June 10, 2013

@mgpcoe Oh sorry, didn’t realize I was being monitored. That FEMALE must have skipped speech class.

— sinrin. (@SannyRanny) June 10, 2013

@sannyranny @mgpcoe mgpcoe is the definition of a floppy wet turd. #E3 #goofball #letscaremorethanweshould

— Lawrence Fidelis (@HeyFiddy777) June 10, 2013

@mgpcoe It’s my opinion and I will freely state it anywhere I want. Your judgement means shit

— Vel (@God_Damn_Vel) June 10, 2013

I’m a little proud of eliciting “let’s care more than we should” as a hashtag; it really demonstrates the work that still needs to be done. And I have to say, I haven’t been challenged to a fight since Grade 9, so well done over there, too. However, one of the guys I quote-tweeted (the one who made the crack about speech class) got back to me and we had this conversation. It’s too long to embed without messing around with Storify, but I broke it down for this guy that, basically, what you say on Twitter is open for public critique (and I was just criticising his statement, not his character) but his closing statement, “I was in a casual context, speaking with kids just out of high school who couldn’t care less about semantics,” really reminded me, despite all the fucked-up things that have happened this year, that kids today still need to be taught this.

I’m sure he and his friends couldn’t care less about the semantics of what they’re saying, but the reality of the situation is that we need them to. Just as we, as adults and parents and nurturers and teachers, need to teach them to care. We need to carefully teach the younger generations about respect, and about the hidden messages they may not realise they’re delivering when they use certain words. We need to not only self-correct, and demonstrate the right behaviour; we need to call out the wrong behaviour in others. They may not realise what they’re doing, but that doesn’t mean they shouldn’t be taken to task for it. After all, not knowing that, in this particular jurisdiction, you can’t turn right on a red light doesn’t mean the traffic police are going to let you off the hook.

To make this abundantly clear, if you were one of the guys who decided to judge Bonnie Ross’ ability or competence based on her appearance or gender, or you made—or laughed at—jokes about her, using language specifically reserved for insulting women, you are part of the problem. You are holding back the human race from evolving beyond prejudice, beyond hatred, and beyond unwarranted fear. And I refuse to stand idly by and watch you do it.

On the definitions of terms

This morning, on my walk to work, saw a tweet in my feed mentioning a new service built on BitTorrent, called BitTorrent Sync. Fully encrypted, the blogger in question called it “Dropbox without the cloud”.

I just about tripped over my own feet.

The term “cloud” has very specific semantics in networking and computing, and it annoys me more every time I see it misused to sell something. There couldn’t possibly be a more cloud-like implementation of cloud storage than by using BitTorrent. By distributing the data all across the cloud, you really are just dropping your bits on the cloud, and picking them up later.

The Cloud, quite simply, any and all of the networks you connect to, but don’t control. Most often, network cut sheets use a cloud to represent the Internet as a whole. It’s an opaque region of the ether that may have your systems on the other side, or it might just be used to represent the source of incoming requests to your services. It may also be used to represent the networks between you and a network API with a specific, known endpoint (like, for example, Dropbox!).

Any x-As-A-Service service is fundamentally a cloud service, because it operates on on a network outside of your control. Dropbox is a cloud service. Netflix is, and you’d better believe BitTorrent is, too. Dropbox exists on a readily quantifiable set of servers, but this BitTorrent Sync product isn’t nearly so measurable—your data could literally be anywhere within the cloud.

For the sake of comparison and clarification, what would be a “Dropbox without the cloud”? A local server within your network that provides similar data mirroring. This would likely only ever be useful in an office environment full of thin clients (or tablets) where no one necessarily has the same desk from day to day. This, however, largely doesn’t exist in most office environments. I have a laptop computer at Kijiji that I bring with me when I need to work in a different room, or if I need to travel. And if, for any reason, I can’t bring the computer with me, I can access it through SSH, anywhere within the corporate network. “Dropbox without the cloud”, in our ecosystem of cheap, portable devices is fundamentally meaningless.

So please, if you&rsquo&re selling something, and want to refer to The Cloud, use the term correctly. This industry is one based on precision of language, and “cloud services” is vague enough already, without being used as its own antonym!

Abandoning commits in Subversion

Before we begin, I don’t normally keep my code in Subversion… any more. When I started at Kijiji, Subversion was our local VCS of choice until there was a organisational decision to switch to Git, and we local developers agreed that it made sense. In the roughly two years since then, I’ve become a total convert. However, I’ve continued to use Subversion for personal projects, simply because I’m the only person working on them, and in case I move from machine to machine, I want to have reasonably quick access to the code.

I have since lived to regret this decision. Despite the fact that Subversion externals work vastly better than Git submodules, there are still some things I can easily do in Git that simply aren't available in Subversion.

One of my favourite things about Git is that, as long as you haven’t shared your repository, you can really mess with history. Step back three commits in the history, branch, write a new commit, then even cherry-pick everything else back on… then reset your HEAD hard, fast-forward, and when you push, it’s like those commits never happened!

You don’t really get that option in Subversion. Since it’s a centralised repository, everything you commit goes off immediately, so good luck getting rid of it for good! So if you realise that your last two commits were completely wrong, what do you do?

Fortunately, you can still branch from your history in Subversion:

$ svn copy http://svn.example.com/project/trunk/@56 http://svn.example.com/project/branches/whoops

Your tree now looks something like this:

--55--56--57--58--59 (trunk)
       \
        \-------------60 (whoops)

Now, everything that was on trunk up to, and including, revision 56, is in the whoops branch. Update your project’s root directory (or check out the branch into a separate directory), and get back to work! Once you’re done, the challenge becomes how to squash everything on trunk since 56. This is disturbingly simple, and only incurs two commits. It sounds dangerous as all hell, but trust me on this.

You’re going to delete trunk.

Only for a second! Since you want to destroy the last few changes on trunk anyway, and replace them with what you’ve done on whoops, this is entirely safe. After deleting trunk and committing, you just move branches/whoops to trunk, commit, and you’re off to the races! The whole process looks like this:

$ cd ~/project/
$ svn copy http://svn.example.com/project/trunk/@56 http://svn.example.com/project/branches/whoops
$ svn update
$ cd branches/whoops/
... work ...
$ cd ~/project/
$ svn rm trunk
$ svn commit
$ svn mv branches/whoops/ trunk/
$ svn commit

And, at the end of the day, you get a tree that looks like this:

--55--56--57--58--59    /-- Branched here
       \               /
        \-------------60--61--62 (trunk)
                          /    \
   Deleted trunk here -- /      \-- Renamed whoops to trunk

If you need to get any of 57, 58, or 59 back, they’ll be visible from the project root. Not remotely gone forever!

And so we see that, even in Subversion, you can achieve a measure of Git-like control of your history. The only difficulty is coordinating with your collaborators, along with the obvious evidence in the history of what you’ve done!

To duck or not to duck

About a week ago, I gave a lunch-and-learn talk at my office on Robert C Martin’s Clean Code—it’s considered “highly suggested” reading in the office, so, as I do when that happens, I read the thing cover to cover. I’m inclined to believe that most, if not all, of the other developers on staff who had been hired by this point did as well, but one of the topics that Martin brings up in his chapter on error handling is whether or not developers should be using checked or unchecked exceptions. Martin comes down on the side of preferring unchecked; there’s no good reason, he says, to use checked exceptions that you have to keep declaring every layer up until you actually catch it—it violates the Open/Closed Principle, and it creates leaky encapsulation.

He’s got a really good point. Having to constantly redeclare your exceptions (or, God forbid, catch and rethrow) is a pain in the ass, unnecessarily exposes your code’s structure, and makes it really difficult to refactor changes to your exceptions (if, of course, you don’t use a magical IDE like IntelliJ IDEA). So there’s certainly some benefit to be gained from preferring unchecked exceptions, both in purely internal code and if you intend to publish an API.

Ultimately, though, I disagree. Unchecked exceptions, to me, should really only be used to handle completely avoidable situations; this is why the stock set of unchecked exceptions in Java includes things like NullPointerException, IllegalArgumentException, and ArrayIndexOutOfBoundsException. An unchecked exception is something that the programmer could, and should, have prevented through better care. As an aside, this is also why I feel ripped off that java.net.URLEncoder.encode() throws a checked exception—the likelihood that the encoding is being specified by anyone other than the programmer is practically zero, so making me catch an UnsupportedEncodingException that will never be thrown is ridiculous:

import static java.net.URLEncoder.encode; ... try { // "UTF-8" must be supported by the JVM, and what are you doing using any other encoding anyway? String encoded = encode("q=hey guys, what's up?", "UTF-8"); } catch (UnsupportedEncodingException e) { System.exit(); // CANTHAPPEN } ...

I also don’t believe that simply switching from extends Exception to extends RuntimeException does anything meaningful in terms of application structure when the catching method is four or five stack frames below the thrower, beyond preventing throws MyException from showing up in your method signatures. If we’re really adhering to the Law of Demeter, writing software on the assumption that a method should only know about the methods of its own variables, of its own class, and of its class’ fields, then most exceptions have no earthly business falling down the stack, particularly across class boundaries. If a method, m, throws an exception, e, then e should be an exceptional circumstance that arose while m was performing its task, not one that arose while m was waiting for a called method in another class to return. I’m willing to grant leniency to private methods, treating the class as a whole with respect to error handling, but simply put, classes should not duck exceptions.

Here’s a facile example:

package facileexamples; public class SomeController { @Inject SomeService service; public void doWork() { try { List<Entity> entities = service.getEntities(); doSomethingWith(entities); } catch (DatabaseConnectionException e) { dealWithTheMissingDatabase(); } } } package facileexamples; @Named public class SomeService { @Inject SomeDao dao; public List<Entity> getEntities() throws DatabaseConnectionException { try { return dao.getEntities(); } catch (NoResultException e) { return Collections.EMPTY_LIST; } } }

Clearly, the class designer is a jerk, who deals with NoResultException in the Service but not DatabaseConnectionException.

package facileexamples; import javax.persistence.*; @Named public class SomeDao { @Inject EntityManager entityManager; public List<Entity> getEntities() throws DatabaseConnectionException { TypedQuery<Entity> query = entityManager.createNamedQuery("entity.getEntities"); return query.getResultList(); } }

SomeService knows that there’s a possibility that the call to SomeDao might get rejected if the database connection has failed, because SomeDao declared that this might happen (this is why this is a facile example; any persistence layer worth its salt wouldn’t even throw that), but the getEntities() method is the wrong place to deal with that—it’s really just supposed to be focussed on handling Entitys, not errors. So it says one of two things:

1. I can’t deal with this; somebody above me will, or
2. this is crazy enough that the JVM should be able to unceremoniously terminate.

Neither of these options is particularly good. In the second case, application’s users don’t get meaningful error (unless they’re developers), and in the first case, a layer too-far-removed from the database has to deal with the database’s problems. SomeController shouldn’t know that there’s a database, or any kind of socket connection involved at all, when it asks SomeService to getEntities. All SomeController ought to know is that it can call a service that provides a List of Entity instances. That’s it; if something goes wrong in retrieving that List, it shouldn’t be up to the controller to handle that. Realistically, SomeDao should deal wih it, but, like I said earlier, the class designer was a jerk.

This architecture is bad in an extreme way, but it still shows that these classes are tightly coupled. The controller is not only tied to the data-access layer, but to that particular implementation of the data access layer… and all because the service layer ducked the exception, trusting that its caller would handle the problem.

There are certainly less insidious and less ridiculous examples that can be thought of, and probably a lot of counterexamples of occasions when it sort of makes sense to duck across a class boundary. However, I think that these can probably be programmed around with careful (re)architecture that ensures that each class and each method is concerned with doing exactly one thing.