Here’s a bit of information on all the video games I played in 2012.
Total games played: 22
Games played on 360: 21
Games played on PS3: 1
Games played (new IP): 12
Games played (existing IP): 10
Games played (in play order):
- Metro 2033 (360)
- Gotham City Impostors (360 - XBLA)
- Syndicate (360)
- Mass Effect 3 (360)
- I Am Alive (360 - XBLA)
- Journey (PS3 - PSN)
- Fez (360 - XBLA)
- Prototype 2 (360)
- Max Payne 3 (360)
- Lollipop Chainsaw (360)
- Spec Ops: The Line (360)
- Deadlight (360 - XBLA)
- Hybrid (360 - XBLA)
- Darksiders II (360)
- Mark of the Ninja (360 - XBLA)
- Borderlands 2 (360)
- Dishonored (360)
- Assassin’s Creed III (360)
- Halo 4 (360)
- Call of Duty: Black Ops 2 (360)
- Hitman: Absolution (360)
- Far Cry 3 (360)
I played 28 video games in 2010.
I played 27 video games in 2011.
I’m scaling back in 2012 and limiting myself to playing 10 video games. These are the video games I’ll be playing in 2012.
Syndicate (XBOX)
Mass Effect 3 (XBOX)
Prototype 2 (XBOX)
Borderlands 2 (XBOX)
Assassin’s Creed III (XBOX)
BioShock Infinite (XBOX)
Grand Theft Auto V (XBOX)
The Last Guardian (PS3)
The Last of Us (PS3)
South Park: The Game (XBOX)
If by chance any of the games here get pushed into 2013, I may substitute in a game that didn’t make this list. I may also purchase, but not play, certain games to support the developers and new video game IP.
I also considered limiting myself to playing 5 video games in 2012. However, I know I couldn’t hold myself to that limit.
My 2011 Game of the Year goes to Dead Space 2. It was a tough choice to come up with a single video game that stood out among the many video games I played this year*. However, Dead Space 2 was a thrill ride that never let up from beginning to end.
Whenever I talked with people about Dead Space 2, I was usually met with, “I still haven’t finished the first Dead Space. It was too scary.” For me, that was one of the highlights of both Dead Space games, its immersive environment, both art and audio. I played both Dead Space games on my family room surround sound system, after dark and with all the lights off. Certainly on more than one occasion I found myself jumping back in my chair as I got caught off-guard by a necromorph breaking through a vent, hell-bent on tearing me limb from limb.
I played through Dead Space 2 a total of 6 times, beating it on Casual, Normal, Survivalist, Zealot and Hard Core difficulties. Hard Core mode presents a true test of skill to even the most seasoned gamer as the enemies are at their most difficult, ammo and supplies are scarce, there are no checkpoints and you only get 3 saves in total (3.5 saves if you count the disc swap as a “save”). Before the final battle on Hard Core mode, I paused the game and psyched myself up for a good 20 minutes. After I finished Hard Core mode the first time and I got the Hand Cannon weapon, I went back and played the game again on Hard Core mode, completing a speed run in roughly 7.5 hours. One shot kills with the Hand Cannon are a lot of fun and who doesn’t love a weapon that goes “bang bang” and “pew pew”.
The Dead Space games aren’t for everyone. If you don’t like shooters or survival horror, they’re probably not for you. But if you do decide to give either game a chance, you’re guaranteed a good time, or at the very least a good scare!
* Here are all the video games I played in 2011:
- LittleBigPlanet 2
- Dead Space 2
- Bulletstorm
- Crysis 2
- Mortal Kombat
- Portal 2
- Brink
- L.A. Noire
- inFamous 2
- Duke Nukem Forever
- F.E.A.R. 3
- Bastion
- Insanely Twisted Shadow Planet
- Deus Ex: Human Revolution
- Dead Island
- Resistance 3
- Gears of War 3
- Ico & Shadow of the Colossus Collection
- Rage
- Batman: Arkham City
- Battlefield 3
- Dance Central 2
- Call of Duty: Modern Warfare 3
- The Elder Scrolls V: Skyrim
- Assassin’s Creed: Revelations
- Halo: Combat Evolved Anniversary
- Saints Row: The Third
rake stats is one of those less-oft used tasks when developing Rails applications, but it does provide a good breakdown of some code statistics. You’ll get total lines, lines of code, # of classes, # of methods, methods per class, lines of code per method and some ratios.
Here’s a breakdown of one project at work:
+———————————+———-+———-+————-+————-+——-+———-+
| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |
+———————————+———-+———-+————-+————-+——-+———-+
| Controllers | 2414 | 1837 | 31 | 182 | 5 | 8 |
| Helpers | 319 | 248 | 0 | 38 | 0 | 4 |
| Models | 1576 | 1149 | 36 | 142 | 3 | 6 |
| Libraries | 1275 | 832 | 5 | 109 | 21 | 5 |
| Integration tests | 284 | 181 | 2 | 8 | 4 | 20 |
| Functional tests | 4406 | 3364 | 27 | 268 | 9 | 10 |
| Unit tests | 2287 | 1817 | 35 | 214 | 6 | 6 |
+———————————+———-+———-+————-+————-+——-+———-+
| Total | 12561 | 9428 | 136 | 961 | 7 | 7 |
+———————————+———-+———-+————-+————-+——-+———-+
Code LOC: 4066 Test LOC: 5362 Code to Test Ratio: 1:1.3
It is also aware of specs and higher-level testing tools like Cucumber. Here is the breakdown of another project:
+———————————+———-+———-+————-+————-+——-+———-+
| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |
+———————————+———-+———-+————-+————-+——-+———-+
| Controllers | 329 | 267 | 13 | 39 | 3 | 4 |
| Helpers | 325 | 238 | 1 | 34 | 34 | 5 |
| Models | 1275 | 904 | 20 | 114 | 5 | 5 |
| Libraries | 85 | 68 | 3 | 8 | 2 | 6 |
| Model specs | 1037 | 839 | 2 | 4 | 2 | 207 |
| View specs | 406 | 337 | 0 | 1 | 0 | 335 |
| Controller specs | 674 | 537 | 0 | 1 | 0 | 535 |
| Helper specs | 103 | 84 | 0 | 0 | 0 | 0 |
| Mailer specs | 65 | 52 | 0 | 1 | 0 | 50 |
| Cucumber features | 338 | 192 | 0 | 3 | 0 | 62 |
+———————————+———-+———-+————-+————-+——-+———-+
| Total | 4637 | 3518 | 39 | 205 | 5 | 15 |
+———————————+———-+———-+————-+————-+——-+———-+
Code LOC: 1477 Test LOC: 2041 Code to Test Ratio: 1:1.4
A few times a year, I run rake stats for all our projects at work to get an idea of how our applications change over time at this level. I ran rake stats back in July and today I ran rake stats again. My summary was as follows: “Where we added code, we added tests, so our test coverage remained the same or improved. Good job.”
I’ve started doing code and coffee sessions around my area, the “Capital District” of NY (Albany, Troy, and Saratoga Springs). They’re informal gatherings where technology-minded folks can get together to share code or ideas. So, some initial thoughts after having done a number of sessions:
- Hold them once a week. It’s good to get a regular rhythm going. If you miss a week, no big whoop as not too much has gone by.
- Mornings are good and I think 8-10 AM is the sweet spot. It’s not too early and not too late. People can usually swing it since it’s easy to say, “I’ll be in an hour later today” for those with less flexible schedules. After normal work hours is tricky since you have to contend with dinner, kids, etc. My personal preference is Monday AM. I think it’s a nice jumping off point for the week.
- Regularly rotate your location to be more inclusive for people wanting to attend a session. In a larger geographic area, sometimes it’s not feasible for people to attend a session 30 minutes away, but it is feasible for them to attend a session 10 minutes away or possibly on their way to a meeting. Locations should have WiFi and a comfortable space to gather people based on the number of attendees.
- Try to be technology agnostic with your topics. Use the sessions as an excuse to learn or talk about something new.
- Send out a quick e-mail or Tweet after the code and coffee session with a recap of the discussion topic(s). It helps to keep the people who couldn’t attend your code and coffee session up-to-date and can serve as a useful reminder of things you might want to explore in more detail.
- Let’s say you hold 40 code and coffee sessions in a year and you’re holding 2 hour sessions. That’s 80 hours (2 weeks) of “working” with someone you might not normally work with.
Are you holding code and coffee sessions in your area? I’d love to hear more about what is working (or not) for other folks.
I did a quick assessment of our applications at work to look at the Ruby and Rails versions that we have running in production.
Number of applications running under Ruby … :
1.8.7: 1
1.9.2: 0
1.9.3: 13
All versions of Ruby are MRI.
Number of applications running under Rails … :
2.x: 1
3.0.x: 10
3.1.x: 3
Overall I think that’s pretty good. Our applications serve millions of gamers every day and so we need to stay current with our technology stack.
I recently started using Sinatra again for a few projects and found that my approach to developing these projects had changed significantly in such a short period of time (a couple of days). Looking at the difference between 2 significant projects, I wanted to enumerate what I found to be my “best practices”.
- Use a “self-documenting” application name. I see a lot of Sinatra projects that use app.rb. Your application is a unique and beautiful snowflake and you give it such a boring name like app.rb?
- Develop using Sinatra’s modular style. The changes are minimal and you don’t pollute the Object namespace.
- Organize your overall Sinatra application. I’ve gone with the approach of configure block(s), registration of extensions, followed by registration of helpers.
- In testing, take the approach of making the Rack::Test::Methods available in all test contexts.
- Sinatra::Contrib has many useful Sinatra extensions, especially Sinatra::Reloader. There are also useful extensions that can give you some of those handy Rails-isms like initializers (see sinatra-initializers).
I feel compelled now to go back and update past Sinatra projects to have internal consistency and that’s a good thing.
Do you have any Sinatra “best practices”?
What makes an API or a library “solid”?
- Logical?
- Documented?
- Tested?
- Performant?
- Maintained?
All of the above? Some of the above? None of the above?
It’s 2011.
Scenario:
- I need data from your web service.
- In order to retrieve said data, I have to call another web service from you that returns the most appropriately load-balanced URL from which to retrieve data.
- I now call the appropriately load-balanced URL at the time of my first request to get the data I need from your web service.
Problems:
- 2 HTTP requests > 1 HTTP request to request data from your web service.
- What happens if in-between those 2 HTTP requests, the URL that I am going to use to request data from your web service is not the most appropriately load-balanced URL?
Solutions:
- Seinfeld “Movie Phone” aka “Why don’t you just send me to the most appropriately load-balanced URL?”
It’s 2011. Stop being stupid about that fact.
If someone from thoughtbot asks if you’re willing to write a test (or tests) for a patch, that is a rhetorical question. Case and point, a pull request I opened on their airbrake project: https://github.com/thoughtbot/airbrake/pull/1 - Use the Capistrano logger for great justice.
It started off as an innocuous request to change the use of puts in a Capistrano task to use the Capistrano logger. I’m sure after the question “Was I willing to write tests for it?” was posed, I could’ve said “No thanks.” or “Does it really warrant a test?”
I chose the impossible. I chose … Rapture.
It’s not really impossible to test Capistrano tasks, but it’s also not as straightforward as I would have hoped. There are some projects like capistrano-spec that may have helped had airbrake been using RSpec, but no matter. In the end, the 2 line change resulted in a slight re-organization of the Capistrano task and a bunch of test code to assert that the Capistrano logger was doing its job.
Now that’s how you spend a few hours on a Saturday morning!
