Archive for the ‘Programming’ Category

An Intro to Ext JS

I recently hosted an hour long brown bag at Headspring to tell my colleagues a little bit about Ext JS. Here are the slides:

Stats are More Fun When Made Up

I bought a domain a long time ago with the hopes of creating an application to host some fun and made up stats. For too long I’ve been using this site as a playground to learn new things. The problem with that is that I’m never actually done. I decided to do something super simple using AppHarbor and now is now finally live and showing some garbage fun statistics. I decided to not over-engineer this site and just get it live. Feel free to leave me a comment for features I should add. If you have a stat you want added, for now, just let me know via Twitter or Facebook and I’ll add your bogus stat.

Why is your Site Not Getting Faster?

Your site’s performance should always be improving. Period. Hardware and internet connections are continually getting better and faster, so why are some web sites not getting faster?

I think it’s because people aren’t too concerned with their site’s speed, but they should be! Maybe they’re writing bad code on top of existing code and slowly ruining their project… I’ve seen it happen before.

Am I just crazy or do people not measure and/or care about performance?

Adding a GOTO

The other day on LosTechies, I posted about how I fix defects. Today, while looking back at some old xkcd comics, I found something that made me think of that post and laugh really loud.

Neal Stephenson thinks it's cute to name his labels 'dengo'

Explaining New Code

I just finished up writing an article about How Spark’s Once Attribute Works. This was a lot better of an exercise than I had hoped. I’ve heard of two good practices that this successfully accomplished:

  1. Reading code to help you be a better developer
  2. Teaching somebody to help yourself learn it better

It wasn’t exactly easy trying to explain some code that I, myself, didn’t know very well. I had to read through and re-read to fully understand how the code works. It was a great exercise, I’ll do this more often and highly recommend it to others as well!

Code Coverage Metrics

I know code coverage of 100% doesn’t mean that the application is without bugs. I also know that code with zero unit tests can work just fine. I do, however, firmly believe that having automated tests is a must when writing complex software.

You can increase your code coverage several ways:

  1. Writing unit tests to cover code that isn’t being tested.
  2. Delete un-used classes and functions.
  3. Reducing the number of uncovered lines of code in tested methods by means of refactoring.

There are others I’m sure, but that’s all I can think of off the top of my head (and while I’m typing this up). Of the many ways you can reduce your coverage (writing new, untested code being the most obvious), another way just came to me that may be common sense to others, but it just popped in my head.

I could have a class with 100 sequence points, all covered. I could also have an application with 2570 of 3212 sequence points covered. This would give me just over 80% code coverage. Not bad, but what happens when I refactor that class of 100 sequence points into one that is still covered 100%, but now contains only 30 sequence points?

My coverage drops to under 80% code coverage:

2570 / 3212 = 80.0125%
2500 / 3142 = 79.567%

Sure, it’s less than one half percent, but it’s still a drop. My application is likely better and easier to maintain (less code), but my coverage numbers have gone down. This quick realization blip in my head just reminded of yet another reason code coverage isn’t a good measure of a project.

You may ask: How would you even notice something like this happening?
Well, you can fail a build in a continuous integration environment if coverage drops below a configured threshold.

Practices of an Agile Developer

Before I was even finished reading “Practices of an Agile Developer” by Venkat Subramaniam and Andy Hunt, I realized that it was going to exceed my expectations. I consider a lot of the practices in which I’m engaged in daily to be good agile practices. It wasn’t until I read Venkat and Andy’s descriptions of them that I truly appreciated the practices I regularly partake and learned about many others that I’m not participating.

The authors describe 45 practices in the book. They go over things like “What it feels like” and “Keeping your balance”. The signs you’ll notice and feelings you’ll feel when you’re doing it right, and pointers on not getting in over your head.

I can’t cover them all, but I’d like to touch on a few that stuck out in my head.

The Bad

There were a few practices of which I would say I’m not doing a good job. I wouldn’t have read it if I didn’t think I’d learn something right? Here are few I noted that I couldn’t relate to when reading “what it feels like” when you’re doing correctly.

Be a Mentor

Aside from helping others out at work or going over code after user groups and code camps, which I wouldn’t consider mentorship, I’m definitely not a mentor to anybody. The next closest thing would be blogging and presenting at code camps and user groups. I have done this so I’d say I’ve participated in some type of mentorship, but there’s still much room for improvement.

Keep a Solutions Log

With the combination or mix of unit testing, test driven design or just test first, I usually think I do a decent job of eliminating defects early in the development process. There will be bugs that show up from time to time though. One thing I’m not as good at doing is keeping a solutions log. At work, we use Trac for our defect tracking tool and I’ll find myself getting lazy and adding something like: “Fixed with revision 6230” or something to that effect. I may not always noticed, but the details of the defect sometimes aren’t written down very well. We might have the result of the bug and how to replicate it, but when closing it with some boring message like I stated above. Another developer viewing it later on might not understand the full implications of the problem. Within our team, questions have risen about previous fixes and I wasn’t able to articulate them as well as I wished I could have. The authors suggest that it should feel like an extension of your brain… I’m not recording enough to be at that point yet. I’m good about recording the “what” and “when”, but working on improving the “where” and most importantly, “why”.

The Good

There are recommended practices that I think my group and I follow quite well. I selected a few to talk about that I think are very important and I’m proud we’re doing so well at keeping up with these.

Criticize Ideas, not People

I work on a team that is very open and honest. Sometimes I’ll forget I’m not at work and be very critical of something that somebody is doing. People don’t always take kindly to criticism, so I’ll get dirty looks. Within our team this type of criticism is not taken personally; we’re all part of the same team trying to do the best job we can for our company. I’m also lucky to work with a group of individuals that focus on quality and aren’t just there to collect a paycheck so they can spend it on the weekends. Because we’re often criticizing ideas, questioning the “way things are” and continually improving our process, we’re creating a better work-place for ourselves.

This practice talks about how you can interact with your colleagues to create an environment of respect, trust, pride and cooperation. Venkat recalls and talks about a real-life scenario where he learned a valuable lesson from a senior administrator. This senior admin could have pointed the finger, but decided to remain calm and help him with the fix. By working together they were able to fix what they needed and made everybody happy. This reminded me of the Collective Ownership practice the authors mention in Chapter 8.

Keep it Releasable

Small iterations and a short feedback loop make keeping it releasable easy. If you’re always making sure that you keep the code base in better condition than when you left it, you shouldn’t have a problem with this. The single best way to do this that I can think of is running unit tests in a continuous integration environment. The best part of this practice is that you can do it for free. Andy and Venkat describe this feeling as though you can always show your latest code without hesitation or fear. The project is always in a ready-to-run, stable state.

Final Thoughts

Many of the books I have on my shelf are more of a reference book than books about ideas and practices. This one will continue to be an excellent resource for bettering myself as a developer and a team member. I’ll probably end up reading this book a few times a year just to make sure that I stay balanced!