Monthly Archives: June 2011

Child (Theme), Please

For a project at work, I have to make a web portal. Originally, I tried out Joomla, but I didn’t like it at all. It felt clunky to play around with. After seeing ATDP Commons, I realized WordPress was a lot more powerful than I thought, so I switched over to that.

While playing with WordPress, I had to style some images, and being the hacker I am, I edited the style.css to do what I wanted to do. I’m very comfortable with CSS and didn’t think a thing of it. I since discovered that it’s better to create a Child Theme. This way, when the theme is updated, your custom modifications won’t need to be reapplied.

I found this really nice tutorial on Child Themes. I took out my code modification and stuck it in a new style.css for the child theme. Then, I decided I needed a smaller header than the default TwentyTen theme wanted, so I added a filter.

All of this has got me kind of itching to do a WordPress theme for my blog. Then again, I’m also tempted to create my own blogging application. I just want something that’s easy to use.

Being Good at Something

One thing that has worried me is how the number of fans doesn’t indicate the worth of a project. If I (not so hypothetically) make a comic that has 750 fans on facebook, how can I know that my comic is any good? I mean, way more people are going to watch The Zookeeper starring Kevin James. Lots of people listen to Rush Limbaugh and read Thomas Friedman even though they can be wrong by a lot of things. So, having fans doesn’t necessarily mean what I’m doing is worth anything.

I’ve recently made a distinction in my head between something being good at something and making something worthwhile. Pundits can be very good at what they do. They’re paid to spout interesting opinions while sounding confident. Maureen Dowd is annoying as hell, but she’s good at writing what she does. The pundit, however, isn’t paid to be right. Being wrong about the future, or the present, doesn’t affect their bottom line or their self-worth.* So, they can be good at being a pundit, but it doesn’t mean that a pundit does any good. Rush Limbaugh is a very good talk radio host. He has millions of listeners because he’s good**, not because he’s wise.

Likewise, it’s not actually that easy to make shitty music or a shitty movie. I have respect for even the shittiest TV show because I worked with my friend to put together an episode of Larry Whitman: Data Entry Maverick. There’s so much that goes into it: editing, music, writing, directing, storytelling, camera work, set-building, props, costumes, acting, and more. The same goes for movies. Even though The Zookeeper will be a giant turd, the acting won’t get in the way of the film, it will successfully tell a very basic hackneyed story (as opposed to failing to have any story at all), and it will probably have funny moments. I’m sure the digital animation of the animals will be decent too. It won’t tell a worthwhile story or be great art, but it will be good at what it wants to accomplish. With music, there may be a shitty repetitive song on the radio, but the sound people who do the editing are the best at what they do. Even though the music is inane, it won’t sound like someone recorded it in their garage. It’s professional.

I guess that means when it comes to art, I shouldn’t have as much anxiety about the number of fans I have. The number of fans can help me tell if I’m good at what I do, which is actually helpful. However, it can’t tell me if what I’m doing is worthwhile. I suppose this is where I end the essay with something cliched like, “This is only something I can decide myself,” but I haven’t said anything to support that conclusion. Instead, I’ll end here, still puzzled about what makes something worth doing.

*There are always exceptions, but sometimes we they must be set aside in order to make a worthwhile point.
**And lucky. We all have our debts towards Fortuna.***
***As an interesting aside, my thoughts about luck inform my proto-thoughts on redistributing wealth. The rich should pay more as a kind of luck tax. Capitalism can create a system where wealth is distributed according to a curve defined by a power law. Similar to how fame begets more fame, riches can beget more riches. The only way to be fair is to tax this.

Delicious Quickness and a Kata Curriculum

I need an easy way to share what I post on delicious. I’d like a way to share links on this blog without posting everything in my feed. (I often bookmark a ton of stuff in delicious when I’m researching a particular topic. Not all of these links are useful.) One possibility is to delve into the Delicious API and grab the bookmarks I tag with “myblog.” Then, I’ll format the links (a tags) and the descriptions (p tags). I could then cut and paste this into my blog. Another option is to just look at the source code in delicious, then copy and paste from that. (Just checked it. No good.)

I found some programming exercises: Here’s a 16-day curriculum: Go through the algorithmic exercises once in order. Write pseudocode and tests for these. Go through the algorithmic exercises a second time, in order, but this time implement the code. I don’t have any experience with TDD, so I need to learn that. A good book on that should be the next programming book I read.

An Actual HBA Installation

Humans are notoriously good at underestimation. When we think something should only take 5 minutes, it’ll more likely take 30. Not only are we bad at estimating the time, but we make our time estimates based on best-case scenarios. That’s why projects like Boston’s Big Dig end up taking forever and going over budget.

Let’s take an example from my day. I have to install an HBA. I tell myself, “This should only take five minutes. I’ll pop open the server, replace the HBA, and boom I’m done.” Oh how very wrong.

The actual HBA replacement process:

1) Attempt to log into the server to turn it off. (Let’s not haphazardly press power buttons.)

2) Realize you don’t have the login or password for this server. E-mail requester.

3) Wait 2 and half days for requester to respond to e-mail for “Ultra Extra Super Dee-Duper High Priority” ticket.

4) Go into server and check if anyone is logged in before powering it off. See that 2 people are logged in. E-mail requester to tell them that everyone needs to be logged off before it’s powered off.

5) Squeeze stress ball.

6) Requester e-mails back and informs you that everyone is logged off.

7) Log back into server and finally power it off.

8) Locate server in lab and label cables in the back. (It’s best not to pull out the server before removing the cables. And it’s best to label said cables so you can put them back in the right place. Otherwise, add 20 minutes to this ticket for trying to locate the correct NIC.)

9) Look for masking tape in the drawer where you left it. See that it’s gone. Again.

10) Walk all the way over to the other side of the lab to see if there’s any masking tape on the shelf. There is no masking tape.

11) Wander through all the racks trying to catch a glimpse of just one roll of masking tape. There is no masking tape.

12) Ask someone if they’ve seen any masking tape. They reply, “Oh yeah, I think there was some on the shelf.”

13) Reply, calmly, “No, I already checked there.” Person shrugs.

14) Go to your cubicle and grab some post-its because there isn’t any damn masking tape.

15) Go back to server to start labeling cables. There is a roll of masking tape on top of a server in the next rack.

16) Swear loudly.

17) Label cables.

18) Remove cables from back of server.

19) Walk all the way around the lab to get to the front of the server because the racks are too close together.

20) Pull out server.

21) Remove server cover.

22) Pull out old HBA.

23) Realize you left the new HBA on your desk.

24) Swear loudly.

25) Walk back to desk and grab HBA.

26) Install HBA.

27) Replace server cover.

28) Push server back in until it gets stuck.

29) Swear loudly.

30) Find someone stronger than you to push the server back in and show it who’s the boss*.

31) Replace cables.

32) Remove masking tape from cables and throw masking tape pieces in the trash.

33) Walk all the way around the lab to get to the front of the server because the racks are too close together.

34) Keep walking. You’re almost there.

35) Power server back on.

36) Walk back to desk.

37) Ping server to confirm that it’s on. No connection.

38) Wait 15 minutes because it’s an old server that takes that long to power on.

39) Ping server to confirm that it’s on. It’s on!

40) Update ticket to inform requester that the ticket is complete.

41) Go get a cup of coffee.

42) Return to desk. Find frantic e-mail from requester that HBA isn’t working.

43) Search online for an hour and find out that HBA isn’t compatible with the server.

44) Hit face with palm.

45) Repeat steps 1-41 with new HBA.

* Angela, not Tony.

Dry cleaning

There are several dry cleaning places within walking distance of my apartment. I don’t know if any of them are good.

My first inclination is to check Yelp for reviews. I suppose in older times, I would’ve chatted with my neighbors and asked them for advice. Did people ever really do that? Have we lost community in place and had to rebuild it on the internet?

Put a Rails Project on Github

It looks like I used Github before when I was going through a Rails tutorial. I subsequently abandoned that tutorial and forgot a lot about Rails because I wasn’t doing anything with it. I have since bought a book on Rails 3 (I believe the tutorial was before this), and worked on a new Rails project.

Today, I put the Rails project on Github. I pieced together stuff from a Rails tutorial and Github to get me going. I didn’t change the gitignore file from default. I also used https so I wouldn’t have to deal with proxy issues.

So, my crappy app is up there. Time to start playing with it some more. Also, it’s time to read that chapter in Pro Git on remote branching.

Lazy Branches

1) I really loved the comment from this article:

Am I the only one who thinks it’s ridiculous when people debate what stereotype applies to 46 million people?

2) This chapter from Pro Git on branching has helped me understand this topic better.