What a computer engineer looks like March 6, 2010 1:47 AM

This month, an unusual new Barbie was born—Computer Engineer Barbie, chosen by popular vote on barbie.com. For the first time ever, you can get a Barbie with her own little laptop.

When I first saw a photo of the doll, I was aghast at her outfit, which seemed garish and drastically outdated for a doll so famous for being fashionable. The press release said she was supposed to represent “geek chic.” I decided to indulge in a little redesign.

First, I swapped the unflattering pink-rimmed glasses for some black ones. I replaced the unlikely Bluetooth headset with some noise-cancelling headphones. The crazy binary-print top complete with flying keyboard keys spelling out “Barbie” was exchanged for a standard tee with just enough binary for the letter B, along with a nice pink hoodie. Finally, the wrist-watch (which actually has a funky circuit board pattern, but seems redundant when you’re always staring at your laptop or cell phone) was swapped for a coffee mug, and I put some command line windows up on the laptop screen.


Anyway! Aside from all this nitpicking (and ignoring the bigger question of Barbie’s overall effect on young girls), I’m really excited about this new variant of Barbie. Every career Barbie has been a cartoonish, glittery representation of the career, and that’s okay; it’s targeting girls who would be attracted to Barbie in the first place, after all. It’s awesome that Barbie now has a computer. I’m happy that millions of girls will see this doll on the shelf and feel that it’s acceptable or even cool for a girl to work on computers. I hope this influences girls to ask for a computer at an earlier age—maybe before their male siblings do, even. It’s really quite impressive that Mattel produces career Barbies at all. I’m sure they don’t sell half as well as the Barbies that come with a unicorn and a glittery princess gown.

Discussions on geek Barbie have brought up some important points about stereotypes. Some people seem to believe that because this new Barbie is so pink and feminine, she couldn’t be an actual computer engineer. In reality, we female engineers range anywhere from highly fashionable to totally tomboyish. I recommend reading through the presentation “I’m a Barbie Girl in a CS World” to see how much of a hurdle the nerdy/boyish stereotype can be for some of us.

I’ve usually worn a t-shirt and jeans to conferences so that I’d look like an average developer rather than a passerby or somebody’s girlfriend who was dragged along. (Yes, I have been asked whether or not I’m a developer. It’s irritating.) However, I also love wearing feminine outfits and I’m interested in both mainstream and alternative fashion, the latter of which has had a lot of influence on my personal style.

I’m starting to loosen up now and wear whatever I want to tech events. One of the nice things about not working for any company besides my own is that I don’t have to represent anyone but myself. By representing myself rather than a stereotype, stereotypes that involve me can become more accurate. One of these days, I hope the US developer community becomes so diverse that these stereotypes weaken and don’t hinder people from joining the field anymore.

(It’s not impossible. There are actually places in the world where these stereotypes don’t exist, and there are also countries with equal numbers of males and females working in technological fields. Egypt is one example.)

Over at the excellent Devchix mailing list, we discussed these topics at length. One person suggested that we blog photos of ourselves coming into work in order to help people see the diversity in the appearance and dress of female programmers. I’ve never posted a photo of myself here—something about pointing to my appearance feels risky—but I realized that if all women worried about this, and thus shrouded their inherent femaleness, it would only exaggerate the gender imbalance in the industry, and stereotypes would continue to go unchallenged.

One of the last tech conferences I attended was about 1% female—and I talked to people who literally knew no female developers back home. it’s hard to blame people for making inaccurate assumptions about female developers if they’ve seen so few of them.

So here’s a photo of me. There might even be more in the future. :)



At the Stables Market in Camden Town, UK.


4 Comments

My worst iPad fears February 1, 2010 7:17 PM

Wow, the iPad. Cocoa developers are going crazy about this because it reeks of iPod-level success with the possibility of changing the face of computing forever. It’s a gorgeous new all-purpose device that anyone can learn to use, nearly as powerful as a normal computer but so much easier to understand; it’s an inspiring machine that calls for a totally new breed of elegant software. And, it might make some of us lots of money. Considering that many more people need a simplified computer than a fancy phone, I think Steve Jobs is probably right when he says the iPad will be a second gold rush for developers.

It wasn’t until dinner at NSConference this evening that I really thought thoroughly about the iPad. Wolf and I had a soulful discussion about different cultures with our new friends from Argentina, Belgium, Denmark, Germany, and Switzerland. We lamented the flaws of human nature and worried together about losses of liberty all over the world. It seems that as governments gain more and more control, corruption is inevitable—unless, perhaps, an intense dedication to freedom is baked into the system.

The conversation turned to technical topics, and disturbingly, the observations we made about governments could be applied to companies like Apple, Google, and Oracle. We started to discuss the closed nature of the iPad.

Oh god, what if nobody actually does make a fantastic, open competitor to the iPad? After all, it can be argued that nobody’s made a solid competitor for the iPhone yet. What if the iPad really does become completely embraced by the 80% of normal people who don’t need a real computer?

At this time, I suspect the closed nature of the App Store is not as worrying as it should be because it only concerns our smart phones. We can still develop anything we want for Macs, the “real” machines. However, what if the iPad starts to replace the Mac to such a degree that it no longer becomes profitable to write apps for the Mac? It seems that to be a Cocoa developer will eventually mean to have one’s business chained to the App Store. To be chained to the App Store means Apple makes the final decision on whether your apps can be sold the way you like them, or at all. Perhaps that’s not as worrying right now due to the relatively low number of App Store rejections, but who knows what the future will hold if Apple actually gains a majority control over the computer market. There are many things I love and respect about Apple, but their current approach to the App Store makes me feel like we’re all doomed.

Maybe no BigCo will make a better iPad and all of this is inevitable. But I consider the massive creativity of the Cocoa developers and designers around me, and I can’t help but think that if some of us formed a company driven to compete with the iPad, we could do it. With our skills for creating beautiful, simple, and intuitive software, and a commitment to developer and user freedom, why wouldn’t we have a chance at making a better computer for the masses?

5 Comments

Decruftifying Movable Type 5 January 31, 2010 2:50 PM

My old install of Movable Type 3 was getting overrun with comment spam, so I decided to start anew with Movable Type 5 in hopes that the spam problem would be fixed out of the box. Unfortunately, it’s not much better than before. I suppose it will, at least, be easier to maintain and upgrade my system from here, and I do get some new goodies like autosave and revision history. I plan to install an extra anti-spam plugin like Comment Challenge if it ever gets updated for MT5. For now, closing comments on all the old entries will help.

Getting Movable Type where I wanted it turned out to be much more of a project than I expected. I’ve documented the following in hopes that it’ll help someone out there.

Putting your blog at the root of your website

Movable Type 5 requires that you create websites that can contain multiple blogs. You can’t have a blog without creating a website first. Your blog URL ends up being something like http://example.com/site/blog/. As I’d think would be a common case, I have only one blog, I want my domain name to point at it directly, and I don’t need the extra idea of a website. The solution I found thanks to this post is to create a website in Movable Type with its root path set to whichever directory your domain name points to, and its URL set to your domain name. Then, create a blog inside it, with its root and URL set to the same respective values as your website’s root and URL. As long as you never publish the website (which would overwrite the blog), it works.

Adding pagination with pretty URLs

When I read a blog, I always want to see the next n entries, not the entries of a specific month (which is how Movable Type’s archive links are displayed by default). Especially if someone blogs only once a month or so, it’s not useful to have monthly archive links.

Movable Type has supported pagination since version 4.3; however, the front-end for it isn’t built into the default themes. A template sample can be found here. By default your page URLs are crufty, and in order to make them clean (e.g. /page/2), you’ll have to modify the pagination code as well as MT’s source.

Replace the 5 lines within the search_link tags in the pagination code with page/. (Save everything that was originally in the search_link tags for the next step.)

In your .htaccess file, you’ll need to rewrite the original search_link value with the new clean URL. The rule would look something like this:

RewriteRule ^page/(.*)$ /mt5/mt-search.cgi?IncludeBlogs=1&template_id=1&limit=7&archive_type=Index&page=$1 [P,L]

Then, find /lib/MT/Template/Tags/Pager.pm in Movable Type’s source. A quick fix (thanks Wolf for the help) is to replace return $link; at line 156 with return "/page/$page";.

Cleaning up entry URLs

This post helped in removing more cruft from my URLs. Basically, you leave the extension fields empty and add some rewrites. I found this Stack Overflow entry useful for redirecting my old blog post URLs to the new style of URL (with hyphens instead of underscores). (I hadn’t actually wanted to convert all my old URLs to use hyphens, but after exporting my old blog and importing it into this new installation, MT had done it for me, and there doesn’t seem to be a way to get around it.)

Better template modules

I don’t like the way Movable Type does templating in its default theme—you still end up repeating a lot of HTML across the various templates. For my site, I created three new templates modules that I used as includes: upperhead, upperbody, and lowerbody. Upperhead has all the HTML of the head down to the title tag. Upperbody contains all the HTML between the body tag and the content. Lowerbody contains everything below the content. With these modules in place, I no longer had to update all 6 index/archive templates every time I made a change to the HTML.

Comments without registration

By default, Movable Type blogs require people to register before they can comment. I’m not a fan of this, so I disabled the registration options. I completely missed the check box labeled “Allow anonymous commenters” as I didn’t expect it on the Registration page, and this plagued me for quite a few hours before I figured it out. So, just FYI :). I’ll also mention that if you require email for comment, you’ll need to add “required” labels to the email (and name) fields in the comment form template yourself, or there’ll be no indication that those fields are required.

That’s it for now! Currently I’m in London for NSConference UK, which together will my Paris visit will likely result in another post or two.

5 Comments

Reboot January 14, 2010 5:55 PM

In an affront to good taste, I’ve been Twittering semi-regularly but my blog has been silent for over two years. My main problem was that I had become too much of a perfectionist. Each entry would involve several hours of writing, several days of revisions, and then many more days of editing after finally being published. I also had this insane rule of illustrating every post. Blogging became a burdensome task.

I feel it’s important to record my life’s lessons and I enjoy sharing them here, so I’m going to start blogging again as best I can. This time, I’ll try to be more spontaneous with it so I don’t fall into the same rut.

A new blog layout was also overdue. Early last year I started working on a design inspired by the movie V for Vendetta. However, by December I realized I was no longer in a V for Vendetta mood, so I switched to a much lighter look. I also upgraded to Movable Type 5, an experience I’ll have to write up in a later entry.

Please do let me know if anything seems broken.

3 Comments

Beautiful Code & Beautiful Software October 29, 2007 12:35 AM

Programming was fun because I could make cool stuff, but what actually got me obsessed about it was suddenly seeing something interesting in the semantics and syntactics of the very lines of code. Being sensitive to the difference between good and bad code was intensely motivating, and discovering ways to write efficient, self-documenting, and thoughtfully-organized code was something I knew could captivate me forever. This is what I loved (and still love) about my field—the art of programming, the wonderfully complex craft that could take a lifetime to master.

As I added to my Ruby knowledge Java and then Objective-C, I began appreciating software development at a lower level. I grew up in an environment (the Rails community) where there was a lot of hate for those big verbose languages, but upon actually experiencing them for the first time myself, I discovered that I enjoyed them. They were different, but still interesting in differing ways. And hey, there was something satisfying and clarifying about writing dumb code after being born in high-level land—my first for-loop in Java, for example, helped me better appreciate the cleaner, object-oriented practices I knew, but I also saw something appealing in the for-loop itself. It wasn't just elegant language that intrigued me, it was also the basic logic behind the syntax, and the fact of differing syntax. Computer language, and differences in computer languages, were fascinating in and of themselves.

I had the same satisfying feeling when I first learned Assembly in college this term. Assembly was tedious and sometimes quite painful, but the way it made me think about basic programatic functions in such new ways was completely worth the pain. Of course, I also got a geeky pleasure just from being aware of the low-levelness of the code I was writing.

It gets worse! I had a great moment of self-discovery when I read Wolf's Programmers Don't Like to Code early this year. I indeed love the problem solving, elegance-creating, coding-to-learn part of coding, but I realized that I actually like coding for coding's sake, too. At least, that's how I describe my enjoyment of CSS and XHTML. I have an extensive enough grasp of front-end programming that I don't often solve a new problem these days (in fact, problems that take me a while or bugs I haven't seen before can be downright thrilling). Yet, I still enjoy working with the stuff. There's something relaxing about dumping out good-looking code that I understand very well, sort of like how I enjoy doodling the same cartoon cat over and over in my class notes, or how I enjoy playing the same three tunes when I sit at a piano. Even just looking at good CSS—well ok, my CSS, with everything ordered, indented, and cascading correctly—feels good in the same way that I felt bad, almost physically ill, as I waded around in the stylesheets of a certain forum software and found inconsistent indentation, extra line breaks, commented-out junk styles, and styles disabled by deliberately misspelling the property name.

This is what happens when you're so easily inspired, interesting shadows on the walls motivate you to continue living. You have to come back in once in a while and reorganize your levels of sensitivity so that your appreciation for light and sound is appropriately proportional to your appreciation for Off-Off-Broadway.

That is to say, these days I've been thinking a lot about the software part of software development. Specifically, the design of user interfaces in software. At BARcamp this year, I liked how Aza Raskin asked all developers to raise their hands, then all designers, later saying that the hands that went up the first time should have stayed up. All developers should be designers. At least, that's true for all developers lucky enough to work jobs where they have a say in the design of their software.

I'm getting increasingly excited about the importance of design within development, especially as I come to terms with my different passions and reflect over some of my past gigs. In the web app contracting world, design and development are usually separate jobs. In some cases, the design job is minimized in comparison to the rest of the project because clients generally pay for features, not for beautifully thoughtful design. On a project where I played both design and development roles, I recall feeling uncomfortable because I was assigned only two days to complete the visual design. It needed a lot more than two days. It was a complicated application that deserved weeks of rigorous iteration and conversations with the client. Unfortunately, that's not what the client was paying us for. The client was perfectly fine with the version-one mockup that took me a couple hours, and well, we had an app to launch.

I had another wake up call while I was at C4 this year. It appears that many Mac developers, perhaps most of them, are solo indies producing their own products. As such, they really do have to be both designers and developers. Actually, design is often the most significant part, and there seems to be a lot more enthusiasm over user experience and just producing a great product than there is over the code itself. One night during C4, someone inadvertently helped me see this when he described to me the nature of his work: "Coding the basic functionality is the easy part. That just take a couple weeks. What's really hard and time consuming is figuring out the specifics of the UI."

Wow, I thought. Why does that seem so right? Why is that so cool to me?! Oh, right, I'm a designer to begin with. There are dramatic rifts between my enjoyment of development, design, and art because I appreciate each of them in very different ways. I constantly try to integrate development and art, but I really ought to figure out how to mix all three.

After all, my goodness! Do we want beautiful code, or beautiful software? Here's another peek into my life: A side effect of being extremely open minded and absorbent is that I find myself believing all kinds of contradictory ideas, sometimes even opposite ones. It doesn't bother me right now because I'm in exploratory mode, not know-what-I-believe mode, but to retain sanity it is, of course, a must to occasionally sort things through until they make some kind of sense.

Thus, for further consideration I've listed just a fraction of the many things people like about software development, loosely ordered from the most intrinsic rewards to the most extrinsic rewards. I've left out a lot of really wonderful stuff like community, open source values, and challenges because those are harder to fit into this order, but I think you'll get the point. This is an extremely interesting sort order to me because of how psychologists say that intrinsic motivations are stronger and more likely to keep you going. For example, the person who takes karate classes because she feels energized and excited by the sensation of punching and kicking will more likely end up with a black belt than the person who takes the same classes for the health benefits.

Is it the same for programming?

  • The sensation of writing code
  • The knowledge that one is writing code
  • Enjoying computer logic
  • Enjoying computer language
  • Elegant syntax
  • Elegant semantics
  • Learning about code
  • Problem solving
  • Learning about problems
  • Achieving usability
  • Finishing a product
  • Elegant software
  • Solving human problems
  • Solving business problems
  • Satisfying market needs
  • Making money
  • Having a stable career

Which is the most persistently motivating kind of reward? Most importantly, which kind of motivation produces the best software? I'd love to do some formal research on this topic sometime, but I'm already pretty sure that the answer is "a healthy balance of most of the items on this list," as we certainly want our software to be both usable and maintainable, and sellable, and everything else. I'm also pretty sure that the balance is different for every situation and person. At the moment, however, I envision a wide bell-shaped curve sitting upon a rectangle, and everything turned on its side—the motivations that result in the best software are the ones nearer to the middle of the curve; but really, I think all of the motivations are beneficial in some way, and insofar as the programmer has her priorities straight, the more the better.

The tragedy of our field is that most programmers don't ever get to appreciate the majority of these rewards, particularly the more profound ones. Then again, it works out great because the majority of programming jobs couldn't possibly satisfy someone who cared about all these things. Still, I wonder what the industry would be like if we were all intrinsically, thoroughly passionate about our craft, and nobody was signing up for Computer Science classes just for the "stable career." I wonder what it would do to the world.

I think I should revisit this train of thought every year or so as I become a better software developer. I get the feeling, though, that my fate is already somewhat set in the fact that the more I grow, the more I desire a working situation where I have enough freedom to create beautiful things. It's probably worth noting that both freedom and beauty are vague, subjective ideas, so that could mean anything. All I know is that the compromises to both beauty in code and beauty in software design as necessitated in most programming jobs give me an unwavering feeling of discontent. I wouldn't be surprised if I ended up settling down as a freewheeling solo developer using, you know, web design contracting to support my freewheeling solo lifestyle.

Eventually I'll retire my computers and spend the rest of my days plein air painting on some beautiful farm out in the country. That, or a sensuous city life of alternating between street art missions and serving time. It's fun to imagine where I'll go once I feel done with technology. Hopefully that never happens, because I want to be the cool guru grandma who's still around when her children are giving mandatory programming lessons to their children.

15 Comments

PSIG 107 | Xmo'd + mogenerator October 13, 2007 11:55 PM

(What is PSIG? | PSIG 107 announcement)

Show and Tell


Xmo'd + mogenerator: Seamless Core Data code generation

Mogenerator refresher (from PSIG 98):

Object relational mappers integrate object-oriented software with relational databases. They allow you to work with objects instead of raw SQL statements. Classes map to tables, and rows map to instances. There are a few different ways to implement this:

  • Class first (e.g. Java Beans + XDoclet): Embed relational table and column names into the source to write SQL for you. Wolf believes this is the worst philosophy -- you can reference the data source, but there's not enough information to derive the schema from embedded metadata.
  • Schema first (e.g. Active Record, code gen): Link classes from the schema. Unfortunately, DDL (Data Definition Language) is a harsh and primitive landscape incapable of supporting sane metadata and you end up needing hacks. With Active Record, "you must name things the way god intended them to be named -- who is of course DHH." With code gen it means manually hacking mapping files.
  • Model first (e.g. EOF, Core Data): Wolf likes this philosophy best -- you start with a declarative base, but you have infinite room for sane metadata and you're not tied to any specific data source. Because it's just data, there's no need to write a parser or interpreter. You can generate both DDL and code from a single source. In dynamic languages, custom classes are optional.

Core Data can generate wrappers for all of your attributes as NSManagedObject classes or as custom subclasses of NSManagedObject. Custom subclasses are great for holding your business logic and helping with type safety. The problem is that it's kind of a tedious task to get Xcode to generate your subclasses and it usually involves a lot of painful merging due to the fact that each file contains both generated and custom code.

You can use the lovely Generation Gap pattern to help with the merging problem: put machine-generated and custom code in separate files and make your custom code subclass the generated code.

This is where mogenerator comes in -- it's a command-line tool that automates everything and makes use of this pattern. mogenerator owns the machine's files which are subclassed off of NSManagedObject, and subclassed files off of that are owned by you and untouched by the machine. When you modify your data model and invoke mogenerator, all your generated code will be updated but your custom code won't change.

Xmo'd

Xmo'd makes your life even easier by integrating mogenerator into Xcode. Wolf achieved this with the use of undocumented, reverse-engineered plugin API. Xmo'd overrides the data model document method to automatically run mogenerator for you. When you save a data model document in Xcode, the Xmo'd override fires off an AppleScript which calls mogenerator. This keeps your generated code continuously synced up with your data model. Xmo'd also adds the menu item "Autocustomize Entity Classes." Currently it works on Xcode 2; Xcode 3 support is coming soon.

2 Comments

PSIG 106 | NSToolbar August 6, 2007 1:39 AM

(What is PSIG? | PSIG 106 announcement)

Items of Interest
NSToolbar

Great presentation by Dave and El Wolfo involving a cowboy hat, a gaucho hat, methods named "spanishize" that define anything starting with "El " as Spanish, and oh -- we got to see some live debugging ;). Summary:

Currently, Interface Builder doesn't help you create toolbars, so you either have to do it in code or use Belkadan's GenericToolbar palette.

Doing it in code: After allocating your toolbar, initialize it with a unique identifier (initWithIdentifier) so that Cocoa can automatically remember user customizations to the toolbar. You'll also have to set setAutosavesConfiguration: and setAllowsUserCustomization: to YES. Once you've created and set the delegate, tell your window to setToolbar:toolbar.

There are four basic methods you need to manage your toolbar:

  • -toolbarDefaultItemIdentifiers: Specify default toolbar items. Remember to avoid name collision with Apple's standard items
  • -toolbarAllowedItemIdentifiers: Choose which of Apple's standard items to allow. By default none of them are allowed
  • -toolbar:itemForItemIdentifier:willBeInsertedIntoToolbar: Returns toolbar items as specified by the identifier
  • -validateToolbarItem: Called on every toolbar item. The target and action must be set and responsive for this to work

GenericToolbar is the non-code alternative: It has a nice drag/drop interface for adding and removing items as well as hooking up items to your controllers. It doesn't work very well with bindings, so it's better to do those in code.



Thanks to Gruber for the great wwdc photo upon which this is based


C4[1] this weekend!

Ok, I think this is the most excited I've ever been about a tech event. I can't wait for the sessions and I'm hugely looking forward to meeting everybody. I'm actually going to be manning the registration booth so I'll at least get to greet everyone :)

Hay -- anybody out there have an idea for Iron Coder that could use my help? I'm pretty psyched about the announced "API" because it would seem I could easily make use of my art/design/webcode-fu, but I'm not coming up with any ideas...

5 Comments