RSS
 

An Argument For Dedicated Gaming Handhelds

15 Feb

This has nothing to do with programming, but it’s still something that’s been on my mind lately because I like to game. I like to play all sorts of games, from board games, card games, pen and paper role playing games, to video games. I’m going to focus on that last one here.

Prompted perhaps by the recently released PSP Vita, I’d like to talk a bit about dedicated handhelds and their place in the market. This mostly has to do with how the mobile game space has as of late been thought of as a replacement of dedicated handhelds. However, due to the price and lack of features of mobile games, I think dedicated handhelds still have a very important place in the market.

The PSP Vita launch in Japan didn’t fare so well. Many members of the media mention that a dedicated handheld has no place in current society where everyone has incredibly powerful phones able to play games. They also note that the prices of games on dedicated handhelds (often $30-$50 per game), is a losing prospect in consideration of mobile games typically costing $1-$5. Why would I buy a single game for $50 when I could buy 50 games for $1? There is some sort of consumer perception shift over the value of a game, and mobile games have traditionally been very inexpensive so the mantra is that portable games are worth the cost of a coffee or donut.

I think this is really unfortunate for several reasons. The main reason is that the value of a game being shifted to very low prices ($1), means that the development costs and production values of those games will need to stay in line with those budgets. Most games do not sell as many copies as Angry Birds (I’ll get to my problem with that game a bit later), but instead might sell a few thousand copies. Even a well executed game from a small independent developer might sell 10′s of thousands of copies. However, with each copy costing $1, and apple taking 30 cents of each of those dollars, even a game that sells 100k copies which should be considered a fairly large success, instead only covers the salary of $70k that a median developer might make in a single year. This is just one person with no additional work done in art, sound, etc. You can easily imagine the quality and depth of such a game, they pretty much take up the top 100 games apps on all of the mobile stores. Ad supported games just piss me off, so I won’t get into those.

Now of course many could point out that one of the interesting benefits of mobile gaming and the inexpensive prices of games is that it allows for more independent developers to shine where there was once only major corporations pushing games. In the current market, it is difficult for an independent developer to publish a game on the Xbox 360, PS3, or Wii. Granted with advances such as Microsoft’s XNA and indie marketplace that’s becoming less of an issue, but on the mobile front it’s still very prevalent. Getting a game to [legally] run on a PSP or DS is an expensive proposition. The development tools aren’t free and easily accessible, and the knowledge of how to develop in those environments isn’t as well known. However, on the mobile front such as with the iOS and android devices, the cost to develop is fairly low. So naturally they make the target platform for independent developers.

And this is a wonderful thing. We can be exposed to and discover new and interesting things by passionate people who are willing to take chances. However it also means that the market is full of cheap knock-offs and rushed, shallow games that are just striving for a quick buck. Finding the gems in the pool of slag is a depressing prospect. The quality to quantity ratio is skewed incredibly towards the later. The fact that prices are so low that a true creative endeavor will hardly ever be attempted because the chance of recuperating the production costs of such a product becomes quite low. In essence what we are left with is a marketplace that is full of very cheap, very shallow, low quality games that mostly are clones of one another. Gameplay is often incredibly simplistic (see Angry Birds), and often lacks any real challenge or sense of accomplishment. They’re fodder that are useful for minor diversions, but rarely a good rewarding experience that one can get from deep stories and deeper gameplay.

Other than the economic problems with mobile games, there exists another significant one relating to functionality. Mainly in that most mobile platforms being touch-screen only phones or tablets, the primary interface to interact with games on these platforms is through touch. Unfortunately for many genres of games, touch is a very poor interface. Often times games will use an on-screen controller; sectioning off portions of the screen with mostly transparent overlays that are visual representations of physical controls that you slide or tap as if they were an actual controller. These are often cumbersome and obviously trying to make up for something that is lacking: physical controls.

I noticed this acutely yesterday when I was on a shuttle heading towards the train. I took out my iPad and decided to try out Sonic The Hedgehog 4 Episode 1. The game is actually quite well done. Graphically it’s very pretty. The levels are well constructed. But the controls are terrible. One has to use a virtual controller that’s been mapped to the screen which makes playing a fast paced platformer like sonic very difficult and frustrating. A single analog stick (or even a D-pad) and one physical button would have made the game great. However, due to the poor controls, the experience was sub-par. Mostly just a ‘meh’ game that’s disappointing in its execution due to limited inputs.

Those two factors is why I am buying a PSP Vita and why I hope that dedicated handhelds are never truly overtaken by games on touch-screen only devices such as mobile phones and tablets. The depth of a game made on a higher budget that is supported by a higher price can vastly supersede a game made on a 70 cents per sale mobile game budget. Games such as Jeanne D’Arc for the original PSP, while technically could be created for a touch device, are not due to the convention of $1-$5 game prices. Experiences like ones found in a quality game such as Jeanne D’Arc are ones that I crave however, and that bring fun and excitement to events like my commute where a mobile game may only stave off bordom for a few minutes. Sometimes I want to just play something quick and mindless like Angry Birds, but sometimes I want something of quality. A GOOD game that I can immerse myself in to the point where I miss my train stop and end up in Gilroy. Something that I’m having so much fun with that it becomes dark when I’m playing on my couch and I don’t realize because I’m so involved. That has never happened for me on a mobile device, but it’s something that’s more probably on a dedicated handheld with the types of games those devices attract.

Having physical controls is another very important point to a dedicated handheld GAMING machine. Entire genres just don’t work well on touch-only devices. Fighting games, shooters, action games, platformers, and many types of hack and slashes, are all improved with the addition of physical buttons and analog sticks. If Sonic The Hedgehot 4 Episode 1 were on the Vita, it would double the fun of the game over the iPad version just because of the controls. This is a need that has been recognized by the 3rd party peripheral manufacturers who now make controllers and additional input devices for the iPad such as the iCade. OnLive has a universal controller that works on android and may someday work on iOS to play streamed games and use real controls.

In essence, dedicated gaming hardware has a niche that it serves outside of the general ‘mobile gaming’ space that has been very popular lately. Mobile games are big money right now because it’s capturing a huge casual game market that hasn’t been exposed before. However, there is still a ‘core gamer’ market that, while not as large, is usually willing to spend more money for a higher quality experience. Knowing that these two segments can exist independently is why, I think, products like the PSP Vita and 3DS are still very important and relevant in today’s society. Not all games need to be shallow and cheap.

 
No Comments

Posted in Gaming, Uncategorized

 

Ideal Development Process – Part 1: The Build

12 Jul

I’ve been kicking this idea around for a while now. I often make comment on ways that I would prefer to develop or practices I would like to use or even avoid. However, they’re often fairly disjointed things. “Write tests first” stands ok on its own, but where does it fit into the overall big picture of a full development work flow? So starting today I’m going to outline my ideal development process I would love to use. There’s a lot of aspects to such a process so it will be divided into multiple posts.

#FAIL

The state you want to avoid when writing software. This team... did not avoid that fate. Now their cubes lie empty and hollow, with a cold echo speaking of unimaginable loneliness and dispare. (actually they're still there just without the sign)

The Build

Today we’re going to start with the build process. Building an application is something that needs to happen quickly and with confidence. What this means is that creating a build for deployment should be a process that doesn’t waste hours, or even minutes of your time. Ideally it should be nearly instantaneous, like with Rails, PHP, or other interpreted scripting languages. However, there should still be a process to kick off and verify the syntactic correctness (via compilation) of code along with exercising tests.

While a plugin for an IDE to run a build and perform all of the tests would work, I don’t like being tied down to a particular editing tool. If you want to run your build process by sshing into your work machine from home, you shouldn’t need to bring up a graphical client to run the build. There should be an easy command to just launch it off. For this something like maven or ant can help accomplish the task. If it’s a non-compiled language then just a series of scripts for running the unit tests can be fine as those tests should be forcing the code to be interpreted (and internally compiled) and catch those sort of errors. Ideally, this whole process should take less than 20 seconds. Enough time to collect your thoughts after a change, but not too much to cause you to lose your focus, leave the zone, and feel like you’re watching a status bar.

The build should be able to produce a working deployable. This can be either a packaged distributable such as a Java .war file, an executable binary, or just a folder of flat php files that can be copied into an apache home directory. It doesn’t matter as long as the build system can produce something deployable that can be used for integration testing.

Building Should Be Easy On A New Dev Box

This deployable should not be dependent on a specific environment. If it’s a .war file for a web application that uses a database, the deployment should not have to assume that the database exists in order to be deployed. The build or deployment process itself should have the opportunity to create the database with the needed structures and perhaps some sample testing data. Something like Rail’s Active Record is a good candidate for this type of database versioning and creation. Liquibase is another tool for handling these sort of database changes and setups to a project.

Similar to the database, the system should not require a ton of applications or libraries to be installed (or environment variables to be set up) in order to build. Naturally you’ll need to get some of these tools, but time should be taken to write scripts to automate the process of setting up a new development environment from the checked out source code of your project. This could be using wget to download compilers, languages, libraries, and other tools along with automations to set up property files and environment variables. These scripts need to be kept up to date as well, and should be exercised as part of your continuous integration.

Speaking of which, Continuous integration should be taken into consideration with your build system. Whenever code is checked into whatever version control system you’re using (I prefer git, but use SOMETHING), those changes should be picked up by a continuous integration server that can run your build. The CI box should be cleaned after each run (ideally started from a blank VM) and those dev scripts that set up the environment for the test should be run. There shouldn’t be a manual process taking place for setting up the build server. The build server should run the build, including running all unit tests, deploy the distributable if it’s a web application, and run any integration tests on the deployed version. Emails should be sent for failures, and small red lights should turn on at the developers desk (I’m building one of those right now).

Large Applications

This sounds all great and dandy for your standard small team project. But what about large projects? What about something like Amazon.com or LinkedIn? These sites are composed of hundreds (possibly thousands) of services that all talk to each other via some sort of transport with coupling between modules. How do you build an entire site consisting of hundreds of thousands or millions of lines of code and keep your build under 20 seconds? The simple answer is: you don’t. You can’t really, but you shouldn’t have to build everything to work on your part of the application.

Breaking down large problems into smaller problems is the essence of what software development is. A huge site like LinkedIn is a large problem from a testing and deployment standpoint. However, the sections that you’re working on is most likely just a small service with a few dependencies on other services. For this, there are two solutions.

The first solution is for every service to have a mocked deployable. Something that acts as a stub so that when you deploy the service you’re using, you can rely on the stubbed service to provide an approximation of a correct answer to your call. It’s almost like a larger version of a mocked object that persists for interactive usage. These can be difficult to set up, but are worth the time invested because they can help stabilize your API and be reused for many components. This way when you deploy your real service, you just use stubs for testing your results. To make setting this up easier, you should standardize on a transport protocol and write a tool that automates the creation of a stub based on an interface.

The other solution is to have each service set up independently in different containers or boxes that can all talk to each other. The whole stack is up all of the time. When you make changes to a service, the continuous integration server builds and deploys that service. All other services can now talk to your new version and your service talks to real versions of all of the other services. The main problem with this approach is that if you break a service, other services that rely upon it can also break. It won’t be in the code for these other services (though they should probably handle errors coming from your service better), but it does make it harder to test them. However the results will be more accurate since they’re actual running services rather than stubs.

Personally I would prefer the stubbed service solution. Part of creating any new service should be to create a quick useful stub that can be deployed in placement of a real implementation. This would also have all of the unit and integration tests associated with it.

Conclusion

In essence, the build process should be fast, easy to automate, and run a full set of tests. The build should create a useful deployable that can act as the finished product. This should be something that you would release at the end of an iteration in the agile development process. The build should allow for a new developer machine to get started quickly, including scripts to acquire and install all required components for the build. It should be highly automated, to the point where you should be able to type in a short command and have everything run. It should be heavily tested and reliable so that the build runs the same way each time.

 
No Comments

Posted in Build Process, Coding, Continuous Integration, Programming

 

Inline Objects

07 Apr

I like to be able to test my code in an automated fashion as much as possible. A lot of code is connected to other code, so testing a specific section can be tricky because you end up testing the coupled code as well. This breaks the main idea of unit testing and is one of the reasons that code coupling can lead to harder to maintain code. We solve this problem by programming to interfaces, using dependency injection, and using mock frameworks for our tests. It can work wonderfully if you’re disciplined enough to avoid shortcuts.

 

This has nothing to do with inline objects or code coupling. It is instead a set of cosplay outfits from comic-con in ’10

Some developers like to use a particular construct while writing code that creates instances of interfaces using anonymous inner classes. The basic idea is to create a new instance of an interface with the definition inline in your code. I suppose it’s for readability on short code, since you can easily see what it will be doing without having to change to another class. Here’s an example:

public void someMethod() {
  ExecutorService service = new Executors.newSingleThreadExecutor();
  service.execute(
    new Runnable() { // This is an interface that we're making an inline object of
      public void run() {
        //Do thread stuff here
      }
    }
  );
}

This can be pretty useful at times. Something may be run in a thread but logically belong to a part of a method’s logic. Unfortunately there’s no easy way to run this method without also spawning a thread. The thread logic might be using libraries that need to be stubbed out, and that’s even more difficult if used as an anonymous inner class. Also, testing the functionality of the run() method itself is more difficult because it can only be accessed within the context of the containing method. Not the best scenario for testing.

There’s no real difference (not completely true) between a class implemented inline and a class defined in its own file or as an inner class to the one you’re working on. What’s more, you’ll have the ability to instiate the class directly if it’s not anonymous and test it’s functionality separate from the containing class. Decoupling this code can make it a lot easier to test and debug. Since the majority of the time spent on code is maintaining it, adding the additional effort to break it out into its own class can pay off in the long run.

Now I said that there’s no real difference and also noted that that’s not completely true. The main functionality that you lose when you turn an anonymous inner class into a hard class (even an inner class) is actions to the containing method’s final variables.

public void someMethod(final String usefulValue) {
   ExecutorService service = new Executors.newSingleThreadExecutor();
   service.execute(
     new Runnable() { // This is an interface that we're making an inline object of
       public void run() {
         String modifiedUsefulValue = usefulValue + " other stuff"
         //Do thread stuff here
      }
    }
  );
}

The variable usefulValue is accessible from within the the inline object. If the object was created from a non-anonymous inline class then it wouldn’t be directly accessible. However that just allows for some modification such as creating an instance variable inside of that class to hold references to those final variables. Not an insurmountable task.

My point is that there is a lot of code tricks that you can use in Java and any other language that will make it faster to write code. However, using those tricks has to be weighed against testability and the maintenance costs that additional coupling can provide. Being able to write a class in 10 minutes means nothing if you have to spend the next 3 months debugging it. Coding defensively might seem to take longer at the start, but you’ll have to fiddle with your already produced code less often.

And then you have more time to write new code!

 
1 Comment

Posted in Coding, Java

 

The ubiquity of iOS

11 Mar

If I asked you a decade ago what you thought the dominate OS on mobile devices would be, you probably would have thought Palm or maybe Windows. The idea that Apple would rise to domination of the mobile OSes (and devices) wouldn’t have really crossed your mind. I mean in 1997 Microsoft invested $150 million in Apple which helped the company avoid bankruptcy. Who knew that a decade later, Apple would surpass Microsoft’s valuation.

And while Google has made some attempts to push an open platform for mobile devices with Android, it still has the problems that many open source projects have early in life: lack of polish and ease of use. Android is made for power users, so there are many things that Android can do that Apple’s iOS can’t. However, those things that iOS does do, it does them better. Combining the ease of use, fast response time in applications, and a self-feeding cycle of popularity breeding developer effort breeding more popularity has made the iOS platform the ubiquitous OS of the mobile world. It’s the Windows of hand-held devices.

 

Apple just keeps pushing their mobile business forward, focusing on it more than their Mac business. It seems to be working for them.

About a year ago I switched from my iPhone 3GS to an HTC Evo. The real reason for this change wasn’t that I didn’t like the iPhone or that I really wanted the Evo and it’s 4G speeds. It was more that my fiancé and I wanted to combine our phone plans and AT&T had terrible phone selections for her, was too expensive, and was too difficult to set up the second line. I’ve had horrible experiences with Verizon and they’re the most expensive anyway, so Sprint seemed the natural fit. After having been using an Android device exclusively for a little over a half of a year, I’ve started to notice just how much Apple is dominating the area.

If you go to a mall, many stores will now advertise “Get our app in the App Store for additional deals”. Advertisements on web pages, billboards, posters, kiosks… they’re all for iPhone applications. I’ve had a meeting where we were discussing setting up a timer to finish the discussion so that we didn’t get side tracked. My manager actually said “Finding a timer isn’t a problem, we all have iPhones here.” And for the most part he was right; most of the members of my team does have iPhones. I have an android and another member uses a blackberry, but most everyone else has an iPhone 4. And it’s not that the assumption was that everyone has an iPhone. I think it was more the correlation that having a mobile smart phone just equates to an iPhone now for the most part. It’s starting to become assumed.

Microsoft has been trying to get into the tablet market for years. I remember reading articles about Bill Gates stating that it’s a huge market. He had grand visions of doctors using windows tablets to do bedside work of patients. This was in the late 90′s/early 00′s. But it wasn’t until Apple had a strong enough following for the iOS with the iPhone and iPod touch that the release of the iPad could truly take hold in the minds of the populous. After people got hooked to the iOS exclusive apps, and those apps became more and more useful and complicated, that the general population could understand how a tablet computer could really be useful. The polish and ease of use were there, along with a backlog of apps from the iPhone that ran natively. It made the jump very appealing because the ecosystem was already in place.

And that ecosystem is what really can make or break a platform. I’m pretty sure if the variety of software that’s available on Windows was available on Macs (and if Mac’s weren’t so expensive), that Windows probably wouldn’t dominate as it does now. But that backlog of titles makes most users choose Windows. Developers will develop apps that work on Windows because that’s where all of the users are. The cycle is self feeding, and it’s the same cycle that’s happening in the mobile marketplace; only this time for iOS instead of Windows.

With the iPad and iPad 2, Apple has added an additional blow that they’ve never really been able to manage in the past. Their devices might be well made, the OS a pleasure, but usually competing devices were cheaper. If your choice is between a $2000 Macbook Pro or a $1000 Windows Laptop, most people will choose the Windows machine. With the iPad though, Apple is actually cheaper than its competitors. It is also more polished and has a larger application selection. Having the price point going for them along with the ubiquity of iOS means that the tablet market is essentially theirs. There may be a few people getting Android tablets, but that will mostly be power users who want specific features and are already Android fans. Most people will just pick up an iPad and call it a day.

My main concern with all of this is similar to my concern with Windows dominating the PC market. Namely the lack of choice that happens when a vendor gets near complete control of a market. It’s probably even more worrisome with Apple due to their push on the App Store. Never before has a computing platform had a single point of censorship and a required retailer. For Windows applications, people could buy them from a store or from the developer directly. With iOS, Apple gets a 30% cut of all software. Also Apple has to approve all apps, which  means as a private entity they have the ability to censor developers works. A really closed system that may someday come back to bite users in the ass.

Still, at this point in time there’s no real appealing alternative. All of the good applications are for iOS devices and Android tablets are still expensive and incomplete. Apple is heading quickly towards monopolizing the largest growing technology industry (mobile) and even the powerhouses at Microsoft and Google can only manage to put up weak speed bumps. And yes, even knowing this I’m still going to drop by an Apple store to try to pick up an iPad 2 on Saturday.

As I already said, there’s no better options. And the app I need most is only on iOS.

 
No Comments

Posted in Ramblings

 

Steps towards GTD

01 Mar

As my fiancé can attest, I can be awfully forgetful. It isn’t that I’m not  paying attention or that I don’t care about my projects, it’s just that there is a lot to remember. I probably have a good 30-40 various projects that I’m either working on or would like to someday get done. Beside larger projects, there’s dozens of little things that I have to remember to do. The roof of my car needs to be cleaned (something horrible happened to it in Oakland… I’m still not sure), I need to pay the venue of my wedding, I have to fix my dev build, I have a voucher for rock climbing that I need to schedule, my cat needs cat food, and many other things. I struggle sometimes to remember all of this stuff, and more importantly remember it when it actually matters. I want to remember to buy cat food when I’m at the store, not when my starving cat is yelling at me at home.

 

When she gets hungry she starts shooting death lasers out of her eyes. Forgetting these things is bad for my health (and hers).

With the Pomodoro Technique, an activity log is created that has everything you want to do in it. Each day you’re supposed to pick the top items from that list and put it on a daily ToDo to get accomplished (no more than you can actually get done). Optionally the list can be given priorities, but for the most part it’s just a big old list that you add new items to the end of and is hard to maintain and track. I like portions of the Pomodoro Technique for focusing and removing distractions, but some of the task organization is too shallow.

Enter Getting Things Done or GTD. If you’ve never heard of GTD, it is a system of closing all of the “open loops” in your life. An open loop is basically some sort of unfinished task or project that you have to remember to do that sometimes enters your consciousness while you’re not working. You close these open loops by entering them into an organized trusted system. This is supposed to remove that nagging sensation in the back of your head that you have things to do that you’re not doing. It’s also about identifying the next action for any project you may want to complete so that you have a better idea of what you need to do to actually accomplish some goal.

The book is interesting if a little verbose and self-flattering. There are portions of the book, mainly the first several chapters, that sound a bit too much like an infomercial. “After you’ve implemented this technique, you’ll find yourself constantly in a state of relaxed control. No really, you’ll be controllingly relaxed. I go into clients and teach them the system and they’re like ‘wow, that’s awesome’. Let me tell you again how awesome this system is… it’s like, awesome.” That’s basically how the first chapter seems to read. Later chapters also have this problem, but they get a bit more explicit in the functionality and less preachy. I almost wish he used his own method more when writing the book, he may have asked himself “Why am I writing this part? What real purpose does it serve?” Oh well. Still, if you can get around that and find the distilled process, which would have taken half the size as the original book, there’s some value to be had.

The basic process goes like this: First, take a brain dump. Write down every little thing you need or want to do and write it down somewhere. The book recommends a single piece of paper per idea, which I think just wastes paper. I do mine on a computer using a GTD application. Whatever works for you though, just write each one down. Don’t think about how to organize it or anything yet, just get it out of your head. Keep doing this until you stop thinking of things you want to do. This stack of papers or digital list of items is your Inbox. He recommends using those paper trays like they used back in the olden days. You can’t even find those things at my office, but whatever works for you. Just have a list of stuff you want to accomplish.

Now for each one you have to look at it and decide what it is and if it’s something you can and want to physically do. If it isn’t, either throw it away, store it for later, or file it as reference. If it’s something you can and want to do, determine the next action to complete it. If it’s something that will take multiple steps you should probably figure out what the end goal is first, then determine the next step. Once you have the next step, if it can be accomplished in under 2 minutes, just do it and get it out of the way. If it’ll take longer than that then either delegate it to someone else who can do it, or defer it to some other time.

Any time you have a new thought of something you need or want to do, just write it down and throw it into the inbox and forget about it. At some point you’ll want to go through your inbox and clear it out by following the steps above. I do it around once or twice a day since I’m not a fan of seeing stuff in my inbox.

I haven’t finished the book yet, but from what I gather you’re supposed to assign each task a context. Basically what you need to accomplish a task. Contexts can be things like a Phone, being Online, or just in the Office. The idea for this is if you’re making a phone call, you may as well just make a lot of them and do all of your phone tasks all at once. Or if you’re doing stuff online, why not accomplish all of those things you need to accomplish online at the same time? Contexts for me seem more interesting when combined with some sort of location awareness. If I’m at the store I just want to see items related to being in the store (Oh yeah! I need cat food!). This way you can check what you need to do while you’re at a place that you can actually do it.

Then, whenever you’re in a particular context, just pick the next item on the list and do it. Check it off and move on to the next task. Do these until you run out of tasks to do, get tired, run out of time, or whatever your end condition is. The idea is that each item on your next list is something you can actually accomplish so the step of thinking about “What do I need to do to get this project moving forward” should already be done; you’re just executing a predefined task.

So I’ve started trying to implement this method. I acquired a copy of OmniFocus and put all of my tasks into it, created some projects, and then assigned contexts. At first I was attempting to just put work related things into OmniFocus, but I’ve since found that the method is pretty useless unless you put everything, including non-work related stuff, into it. There are things that I need to do at home and in other, non-work related areas of my life that just nag at me all day. Thinking about those things makes working more difficult, so trying to put them into a system where I can review it later and actually do those things at home means I (theoretically) won’t think about those things at work. I also should remember what those things are when I’m at home thinking “Man, I should be doing something. I know I have things to do, what are they?”

After I’ve finished the book and used the methods for at least a month I’ll create another post, much in the same vein as my Pomodoro Technique post, describing how the process works for me and if I really am in a state of relaxed control, or controlledly relaxation, or whatever.

 
4 Comments

Posted in Time Management

 

Succinct Code

10 Feb

This has been talked about in quite a few places and in a variety of ways. Most recently I was reading an article on PragPub about abstraction that caused me to pause and think about how I write methods. I’ve always had a set of best practices, but I think I can add another to it based on some information in that article.

Mischief is watching

Sometimes I imagine my cat is judging every line of code I add, every variable I name, and every parameter I have in a method. Not really, but you could imagine that based on this picture couldn't you?

Those practices have already included things like keeping my methods short. Some say that if your function or method needs to be scrolled to see the whole thing than it’s too long (and you have to have your screen set to 80 char cols and 25 lines long for it to count). I try to keep my methods under 10 lines if possible. The shorter your methods, the easier each is to understand.

Any non-trivial (ie, not a getter or setter) method has useful JavaDocs. I already went over commenting in the last post, I don’t think I need to reiterate.

Classes shouldn’t have hundreds of methods and be thousands of lines long. If this is the case, perhaps that class is really doing the job of several other classes. Classes and variables should also have succinct but fully understandable names. Any variable or class name that has some ambiguity on what it does should have a small comment near where it’s created to better explain. Also as a general rule, the smaller the scope, the shorter the name can be. Using ‘i’ in a local for loop is ok, using ‘i’ as the name of a property representing an overall index of a class is less ok. Using ‘i’ as the name of a parameter in an interface with no JavaDoc is just not helpful.

The most recent best practice from that article is to limit parameter list length by combining parameters into a containing object. If you have several methods that each take the same list of 6 arguments, why not combine those arguments into a single object and have each method just process that object? This also allows you to expand what parameters a method can accept without changing the method signature (and therefor breaking compatibility with other code that relies on it) by just adding new fields to that containing class.

This is especially important in methods where you find that the parameter list is constantly changing during development. If that method is used by many other classes, you have to perform a refactoring to make all of those method signatures valid. If instead you use a single containing class and just add new fields to that class, the function signature won’t change and, assuming those new fields are optional, code using that function don’t need to worry about your new parameters. You can always throw an exception if the required parts of that object are missing, and since you’re unit testing everything you’ll catch those right away.

 
No Comments

Posted in Coding, Programming

 

Why You Should Comment

07 Jan

I almost wonder why I would even have to make a post like this. It seems like common sense doesn’t it? When you write new code, you should write comments with your code to explain what the code is doing. Sometimes the comments should be inline for a tricky algorithm, but often it’s sufficient to place comments at the start of a method/function or class just to describe what it is so that the reader doesn’t need to step through your code to understand what it’s doing. When you make significant changes to a method/class, you update the comments. Seems simple and pretty obvious doesn’t it?

Then why don’t more people add useful comments to their code? Often I’ll see this:

Evil Default Comments

Ignore the fuzzed out bits, NDA and all. Note however that there's a default comment made by the IDE (IntelliJ in this case) and that the IDE itself even recognizes that the default comment should be changed by marking it yellow. Yet people still ignore this and just leave it be.

The fact that this BugzillaGrouper class was created on October 11th, 2011 at 5:01:37 PM in IntelliJ IDEA tells me… well not really anything about the class itself. The IDE even recognizes that this is just the default template comment and marks it as a warning (signified by the yellow bar on the right) as something that should be changed. Yet many developers will just ignore this and move on to writing code rather than ever changing the default comment. This brings up two points that I’d like to make.

Firstly, default comments are bad. They leave the developer with a false sense of documentation. I mean, the code has a comment on it, it’ll even generate documentation if you run it through JavaDoc or a similar tool. However, that documentation is worthless. The default comment is less than worthless because the developer sees that there is something up in the comment field and just ignores the fact that it’s a useless bit of fluff. If no default comment were in place, the developer might look at his/her code and thing “Gee, I don’t see any of those green comment boxes at all. This file seems really short. I should add a succinct, well thought-out, and useful comment so that other developers (or even myself) will later look at this file or the generated documentation and be able to easily understand the purpose and usage of this class. Perhaps I’ll provide an implementation example if I’m feeling randy.” Ok, no developer really thinks that, but they should. With a default comment in the code, the chance they’ll think about comments at all goes down significantly.

Second, when people do write comments, they often don’t write very good ones. Often it goes along the lins of “A BugzillaGrouper is a class that implements the Grouper interface.” Well that’s almost as bad as the default comment. Heck, I could figure that out from the class signature, and by reading less words even. What’s really the purpose of the class? It implements an interface, so that means it’s performing the function of the interface but in an implementation specific way. What is that? For example: “The BugzillaGrouper in this instance is a Grouper that groups incoming report data by the bugzillaId. It automatically splits apart bugzillaId’s that are comma separated into multiple ID’s. Unlike other Groupers that aggregate test result counts of similarly grouped items, the BugzillaGrouper only produces a set of distinct bugzillaId’s as it’s primary output. The output is a JSONArray in the following form:…”

I’m not going to list the actual form of the JSON output but I think you get the idea. The main part of the comment is only 4 sentences and took just a few minutes to write. However, the comment has some useful information about what it does specifically in relation to the interface it implements. It also describes how it is different from other implementations. An example of the output (which is different than what most groupers would produce) let the user’s of the class know exactly what to expect without having to step through the code itself for the output format.

Comment Driven Development

I’m already an avid fan of Test Driven Development. Another popular idea making the rounds is Comment Driven Development. I think these two can be used synergistically (one more for buzzword bingo!) to help with an agile development process. Also, it will leave a project with some (hopefully useful) documentation.

The main idea is to write the comment to a method/function/class before writing the code. If you’re unable to write an explanatory comment before coding, then you probably don’t know the problem domain of that piece of code enough to really be writing the implementation for it. Also, when you write the comment first, you’re actively thinking about what that piece of code should be doing. You can work out the design in your head, similar to how you can work out a design by writing a test before your code. Ideally, those two processes can intertwine and work off of each other.

For example, you would first start out by writing the comment to a function you want to implement. Having that basic written description of what the function does, you write a test for the implementation. Perhaps you find some sort of problem with how the actual implementation would work (maybe you need to split it into multiple functions or change some signatures around). This causes you to go back and modify your comment based on your new assumptions, which might reveal other problems. You can go back and forth between the two until you have some useful tests and a descriptive comment. Writing the code to meet those two goals should be pretty easy at that point.

This works even better if you follow the practice of limiting your function/method size. Ideally, your function should not be any longer than it needs to be. If you find yourself having to scroll down an editor to read an entire function, it’s probably doing too much and should be split into multiple smaller functions. Personally I try to keep my functions to 10 lines or less, though that’s not always possible. Still, keeping a goal for smaller function sizes makes them easier to understand and modify later, and makes writing both tests and comments easier by having a narrower scope.

Many developers will still shun comments in their code, wanting to produce something quickly and get it to compile and run. In the end though, the API’s will not be used very much because they’re not documented. Also, the code will be more difficult to maintain, not only by other developers, but by the original dev as well. Since most of your time coding will be in maintenance mode fixing bugs and adding features, it’s stupid not to add useful comments to your code. By forgoing it you will slow down not only other developers that have to work on your code later (and they’ll hate you for it), but also yourself when you realize you have no idea what you were thinking when you wrote that piece of obscure code.

Writing comments before you write your code is a way to not only help you make sure you actually write comments, but also a way to brainstorm design ideas. Comments can be helpful to the development process, and not just a necessary evil that slows down your coding.

Write comments. The world’s codebases suck enough as it is, raise the quality a bit!

 
No Comments

Posted in Coding, Design, Programming

 

Job Changes

04 Jan

There have been a whirlwind of changes for me personally lately. The main reason that I have been mia is that I was in a recruitment process that involved both phone screenings and on-site interviews. As this was a large focus of my professional attention for the past several weeks, it would have been the topic I blogged about. However, since there’s a chance colleagues of my current employeer would also read my articles, it seemed prudent to just be silent on the matter until everything was sorted out. I have since accepted a job offer with LinkedIn which ends my 2.5 year stint with Yahoo!. I do not regret my time at Yahoo. It has been a marvelous place for growth in my career that I’ve used to gain many skills and been able to make some worthwhile impacts. However, new challenges await and tempting new work draws me to continue on in enhancing my career.

The LinkedIn Logo

This is the logo I shall now be professionally associated with. Please note that even though I will be working there, this blog will have no relation to LinkedIn, just as now it has no relation to Yahoo!

It seems appropriate to tie in this change with the turning of the New Year. 2011 will be a year of significant change for myself and my fiancé. In 3 weeks I’ll be moving my life from Burbank to San Jose and I’ll be working in Mountain View; building my career in the heart of silicone valley. I’ll be working on a social network with some of the largest opportunities for both growth and real impact on peoples’ lives. I look forward to seeing the work that I do be used by millions of people to help them achieve whatever professional goals they have. Working on large systems has always been an interest of mine which I was partly able to accomodate at Yahoo but will be in a better position to ingrain myself in at LinkedIn. This year is also the year that I’ll be getting married, probably the most significant event in my life.

So that’s all for now. Big changes coming up. I’ll attempt to get back into a normal posting schedule. Be advised though that there may be a time in late January that I’ll be mia due to moving.

 
No Comments

Posted in Ramblings

 

Google CR48 and Chrome OS

21 Dec

Things that I can’t talk about are still going on, however I now have a new topic that I can comment on.

When I arrived home yesterday, I found a box waiting for me. That box looked like this:

It was quite surreal to find this box in the mail. I had only seen pictures of similar boxes before so I knew exactly what it was. Mischief was also intrigued.

I had signed up for the Google Chrome notebook (CR48) online and was apparently chosen to test it out. I wrote in my application that I would use it as my primary computer and blog about the experience. I don’t know if they read that part and if it had anything to do with being sent a CR48, but I figure that since they kept their part of the bargain, I should keep mine. In fact I’m writing this entry using the netbook.

The first thing that I noticed with the netbook is that it booted up very quickly. A login screen comes up that asks for a Google user name and password. Then the built-in web camera takes your picture and a chrome browser starts up with a lovely tutorial web page.

As far as the operating system goes, it’s basically just the chrome web browser. All of my settings such as bookmarks, themes, and extensions synced with my Google account and came right up. Also, since I log onto the machine with my Google account, Google apps such as Gmail, Google Docs, and Gtalk automatically log in when you go to them. There is a specialized version of the GTalk app that works across browser tabs.

One of the pieces of apprehension I had over an OS that is just a web browser is the lack of external files. Using something like Pandora to play music is not as nice as being able to play your own MP3s. Also, doing something like saving a photo so that you can upload it to another site wouldn’t be possible without some sort of file system. Luckily, Chrome comes with a file system. You can download files for viewing or uploading locally.

Another challenge that Google has overcome is that of printing. They have this great document site but if you can’t print, some of that functionality is lost. They solve this through a system they call Cloud Print. Basically you need to install a dev version of Chrome on a Windows PC. You can then enable that machine to share its printers over Cloud Print. On the CR48 you can then print to any printer attached to that Windows PC. Not the best solution (it requires a second computer that has to run Windows), but manageable. It does mean though that you can’t use CR48 and Chrome OS as your only computer if you plan on printing anything.

Hardware wise, it’s actually not that bad. The keyboard is probably my favorite part. While many publications have noted replacing the CapLock button with a “Search” button (All it does is open a new tab, not really search), what I find most refreshing about the keyboard has nothing to do with that button. Since it’s a piece of hardware designed to run a specific web-based OS, certain keys you would normally find make no sense and are therefor not found. For example, the “windows” key and the context (right click) key are missing. Instead the left ctrl and alt button are quite a bit larger than is standard, which makes them easier to press. Also gone is all of the function keys. Instead there are more relevant keys for a browser. There is a Back, Forward, Reload, Full Screen, Windows Switch, Brightness and Volume keys.

They keyboard uses a chicklet style keyboard that’s actually quite nice to type on. As mentioned previously, turning it on is very quick. Also turning it off is extremely fast, around a second. You can basically press the power button to log out, and if you hold it down it will turn off. Coming back from sleep mode is also very quick, though only slightly more so than OS X which I’ve found to be pretty quick already. Even though it comes back online from sleep fast, it still takes a few seconds for the wireless to turn back on to be useful again.

The trackpad is probably the flakiest part of the system. Clicking and dragging (such as on google maps) is not always the most smooth of experiences, but it works well enough. Also since it’s a fairly large trackpad you can accidentally click somewhere while you’re typing, but honestly I haven’t had too many problems with that. It’s definitely not the best trackpad, but if you get used to it I don’t think it’s a deal breaker either.

The system comes with both WiFi and 3G. Google added the ability to connect to Verizon 3G for up to 100mb a month for 2 years for free. You can also buy day passes or other data packages, but I haven’t even activated mine to look at it. In all honesty I’ll probably just use wireless tethering with my phone if I’m not connected to wifi.

Since it is a portable netbook, battery life should be a top concern. I haven’t tried running it down to see how long it will last, but the power icon right now is at 85% and it reports that it should last another 6 hours. Obviously doing something like watching flash videos will shorten the battery life, but considering the OS is only ever running a browser there is probably a lot of normal OS processes not present that can suck the battery out of a regular netbook.

The Chrome OS browser (or is it just the OS? The OS is the browser so I wonder if I should call it a browser or the OS?) is mostly the same as the regular Chrome browser on other platforms only with some additional settings such as user picture, usage of the search key, and the wireless options.

I’ve only been able to play with it for a few hours, but my first impressions are fairly positive. It’s obviously not for a power user and you’re drastically limited on what you can do with it to just those things found on the web. It makes the Chrome Web Store make more sense, even if those ‘apps’ really just turn out to be links to web pages. Still, one can do quite a bit of normal every day tasks using only a web browser. I’d say that as a second computer for a power user it can be pretty decent. It could also serve as the primary computer for a light user who mostly does email, web browsing, and documents with Google Docs. The speed of turning it on makes it a possible replacement for something like an iPad, though with less applications. I’ll continue to use the CR48 and make some future posts on any additional features I discover or problems I run into.

 
1 Comment

Posted in Living, Ramblings, Uncategorized

 

Absence

11 Nov

I know I haven’t updated in a while, and that may continue for a little bit longer.

There are some things going on and decisions being made that I can’t talk about right now. After they’re done… I still might not be able to talk about them, we’ll have to see.

I’m working on some stuff with apache Pig right now on a hadoop cluster that I may make some posts on in the future. For now I need to focus on work, some external things, and a D&D game.

~Colin

 
1 Comment

Posted in Ramblings

 
« Older Entries