I forgot to make this project public when I created it for myself and started using it a couple of years ago.
I put together a filtered version of the Guardian’s RSS feed which is more to my tastes. It removes sports news, podcasts and other non news items that appear in the feed. It also inserts images seen at the top of stories on the website, which for some reason are removed from the official feed. It’s also in atom format but that’s more a side effect of atom being simpler to generate in rails.
It has been working fine with Google Reader for a number of years now, maybe someone else will find it useful too.
This works for me when booting into Windows 7.
- Navigate to your Far Cry 3 installation folder, usually c:\Program Files (x86)\Ubisoft\FarCry3 (or wherever Steam is installed).
- Go into the bin folder.
- Right click on farcry3_d3d11.
- Click Compatibiliy
- Check “Disable display scaling on high DPI settings”
- Play the game.
Fixes the flickering black screen problem when first loading and allows the game to run in fullscreen mode.
Recently, inspired by the work of Notch and Bret Victor, I have been doing a little more game programming in my spare time. The only game development I had done previously was in C/C++ and I found it just didn’t have the tight feedback loop that both Notch and Bret demonstrate so well when they code. As I didn’t feel like firing up Eclipse and going down the Java rabbit hole with Notch I decided to take Bret’s approach and work on an HTML5 Canvas game.
What I have been able to put together so far is called Gibdo - a top-down 2D game starting point featuring,
- A scrolling view window that tracks the player across the game world.
- View limit detection to allow the player to move off the centre of the screen as the edges of the game world are reached.
- Sprite collision detection.
- Keyboard input.
- Sprite animation and sprite swapping based on the player’s direction.
It’s obviously not a full game but I feel it’s a good starting point to build off. In the future I would like to add,
- Multiplayer support (maybe using pusher).
- Tile based world generation.
- Game mechanics such as combat, levels, etc.
- Sound effects.
- Massively Improved sprites (a pixel artist I am not).
In the last few years a trend in web development has been gathering pace. It used to be the case that we could write all of our views and templates on the server side to rendered by a web framework. Now if you want to build a modern web app you need to be comfortable putting the bulk of that logic on the client side.
But there was always a key problem with Backbone. I felt like I was writing lots and lots of code just to do very standard interfaces. This is mainly because Backbone gives a lot of freedom in how you choose to render templates and handle events. As I got more familiar with it I realised there was scope for a meta framework that could sit on top of Backbone and perform a lot of the heavy lifting for the developer. Of course this never happened, but Ember.js did appear!
Ember.js is a new framework that specifically addresses the problems I encountered with Backbone development. Instead of manually wiring everything together you can, for example, point a view at an array and it will automatically rerendered as the array is manipulated. This is because of Ember’s brilliant binding system and tight integration with the Handlebars.js templating language.
It was such a smart move for the Ember team to rebrand the framework (it used to be called SproutCore 2.0) as it grabbed my attention and I understood the angle they were coming from immediately.
The biggest problem facing Ember right now is documentation. I found it very difficult to discover the best practices and techniques so that I wasn’t fighting against the framework. I found the most success by reading through the Ember source, the unit tests and hanging out in the IRC channel. If more example applications were available to read through this problem could be solved.
I have also found other areas of the framework slightly lacking - specifically routing and persistence where I feel Backbone is more mature. The good news is that since I started using Ember last month a ton of work has gone in to both areas resulting in ember-states and Ember Data which are great steps towards addressing these holes.
Am I Sticking With Ember?
Yes, although it’s a little rough around the edges the core idea is solid and Ember is getting better on a daily basis. It’s probably not a good fit if you need to both learn client side MVC and release an app pretty soon but it’s just a matter of time before documentation and more example apps are released. If you are familiar with Backbone or another framework give it a try and see if it cuts down the amount of boilerplate you need.
This talk from Avdi Grimm is essential viewing for Rubyists or just OO programmers in general. He has some very clever techniques for avoiding nil at all costs which can be easily added to your own development arsenal.
Warning - if you watch this you will find it even more frustrating to read through poorly written libraries.
I was going to write a post on this topic but Rands summarised it so perfectly in this must read article. I’ve picked out some quotes that really hit home to me.
On the warning signs,
A decrease in productivity is a great early sign that something’s up, but what you are looking for is any change in their routine. Increased snark? Unexpected vacations? Later arrivals? Earlier departures? Anything that strikes you as out of the ordinary for someone whose day you are familiar with is worth considering.
On “urgent” tasks,
Get this urgent, unplanned task done or make progress on the unmeasurable? The only thing this decision teaches your team is how little you value the cultivation of your people.
On developer flow,
…it’s your job to remember that productivity costs surrounding these micro-tasks aren’t just the 30 minutes necessary to get them done, it’s the context-switching tax involved in stopping their work, preparing for the task, doing the task, and then rebuilding the context regarding the work that floats their boat … progress is not measured in interrupt-driven minutes, it’s blocks of delicious, uninterrupted hours.
Right on the money.
Splitstate.com is the gaming news service that I launched in 2009 and announced here a few weeks later. By using a combination of Ruby and CouchDB I was able to provide a stable and reliable service for over a year with very few tweaks needed. Just looking back at the git log and the server uptime I can see there was a period last year where no work was done on the site for 8 months while I and others were happily using the service everyday.
But all good things must come to an end - a few months ago requests started encountering long slow downs and the application would crash several time a day. It was due to a number of reasons but the main issue affecting performance was the database growing to 3GB and the app not being designed to handle such a large dataset. Partially my fault and partially a fault of the tools I was using I decided to rebuild splitstate once more - harder, better, faster, stronger!
I love CouchDB, I think it’s a fantastic database and it’s a great way to build web services and self contained data driven applications. What hasn’t been so great about using CouchDB is the driver and ODM support. The best way I found to work with it was to write map reduce functions right on the database - not the Rails way at all.
In my day to day work and on other projects I have been using MongoDB a lot more where the ODM support is just stellar. You really can’t go wrong with either MongoMapper or Mongoid as they both have active communities around them and continue to be updated to work with the latest versions of MongoDB and Rails. I went with Mongoid because I’m more familiar with it.
Last time I chose ruby daemons for processing all the feeds and links that need to be sifted through which has turned out to be a very primitive and non-scalable option. Luckily job queues and background processing options have come a long way since then! I chose DelayedJob because it integrates well with Mongoid and Heroku supports it with no configuration needed.
I took a much more modular approach when writing the code this time and was able to learn from the mistakes I made last time. Lots of small methods and anything that needed to hit a remote server I encapsulated as a delayed job. Switching to Mongo allowed me to keep more of the story selection logic in Ruby where it should be so I could throughly test it. I’m much happier with the code now - it’s cleaner, leaner and more maintainable than before.
I did rant about Heroku in my last post but it really is the easiest way to host a rails application. Splitstate 1.0 was running on Linode who are an excellent VPS provider but these days I need something a little more managed so I can just focus on the code. I don’t want to worry about installing packages on the server and heroku’s git based deployment makes it hard to use anything else.
This Is Not The End
The hard work is done, it’s running on production and finding loads of interesting news stories. Of course I would like to do more with splitstate and now it’s running nicely I can build on this a deliver new features and potentially even new sites!
Today Amazon’s US East Coast EC2 servers went down hard, taking with them many popular websites. Our internal application is hosted on Heroku, who provide a layer on top of EC2 for hosting Ruby rack applications, was one of the many effected. Heroku along with countless other hosting providers bill themselves as “cloud hosts” but that term is very lose and open to interpretation.
Amazon can degrade instances when they feel like and provide no easy way to move instances between data centres. Heroku provide excellent features and add a ton of value to the cloud but are really no better when it comes to reliability. They only run instances in the US East Cost data centre and are essentially at the whim of Amazon when it comes to availability.
A true cloud provider would spread instances across as many of Amazon’s regions as possible and even onto other provider’s clouds such as Rackspace.
The promises of the cloud were that it didn’t matter where your apps and data were located - they were just in the cloud! Turns out the current offerings are not even close.
We have been interviewing a fair number of junior/graduate/entry-level developers recently and it can be frustrating when someone with very poor fundamentals sneaks their way into a face to face interview. We came up with a stupidly simple question that we use to filter out these candidates.
Write a method that can add together (sum) all the elements in an array. Assume all the elements are integers. Use any programming language.
Seriously. I was shocked how many people just can’t do this.
If you haven’t checked it out yet I highly recommend watching David Chelimsky’s talk at RubyConf.
Using some great examples he shows exactly what DRY actually means and shows how sometimes refactoring can go too far. A lot of the topics are addressed in the Refactoring Ruby book and you can search your code for the issues mentioned using metric fu.