Fork me on GitHub

Recent Updates RSS Toggle Comment Threads | Keyboard Shortcuts

  • britg 8:31 am on November 4, 2013 Permalink | Log in to leave a Comment  

    How to Disable the Chrome Notifications Menu Bar 

    I love Chrome, but what’s this menu bar icon that it’s just added after the last update? If you’re like me, you keep your menu bar squeaky clean and slim. Also, I want all notifications to come through OSX’s Notification Center. I don’t know if disabling Chrome-specific notifications accomplishes this — let me know if you do.

    Here’s how to disable:

    1. Open chrome://flags
    2. Search the page for “rich”, which should land you on ‘Enable Rich Notifications’
    3. Disable

    • Mikel Kew 10:30 pm on January 31, 2014 Permalink

      Thank you – very helpful. Can’t believe they didn’t make it more intuitive to remove them!

    • ok heh 3:04 pm on March 12, 2014 Permalink

      This was driving me crazy trying to figure out how to get rid of it. Worst of all, you’d open the Notifications box and it’d say “nothing to see here, move along”. No fucker, you move along!

    • zomg 7:11 am on April 1, 2014 Permalink

      lmao, amen! :D

    • hana 6:12 pm on April 8, 2014 Permalink

      I try several time but I coudn’t see that enable rich notification option anywhere…please help!

    • Dave Nicolson 4:36 am on April 9, 2014 Permalink

      I couldn’t find it either, it looks like they renamed it to “Notification Center”. Set that to “Never show” and the menu item is gone.

    • Jercsy17 11:38 pm on May 2, 2014 Permalink

      If you can find “enable rich notification” you probably using the latest BETA version of Google Chrome but you can still fix it watch here

  • britg 1:50 pm on August 18, 2012 Permalink | Log in to leave a Comment  

    Device Domains 

    Up until recently I’ve tried to keep my 3 main computing devices (Macbook, iPhone, iPad) all capable of doing the same things. I installed twitter, feed reader, and even Kindle apps on the laptop, and attempted to use text editing, server monitoring, and IM apps on the mobile devices. It’s the future! All of my devices should do all of the things, right?!

    The unintended result was a mediocre experience on the domains that didn’t make sense for the device. This is a kind of poison to person who spends most of their time on one or the other. Overall productivity was down when it should have been up, and I found my reading and gaming going down.

    So, after upgrading my laptop just a couple weeks ago I decided to try and keep specific domains to my devices.

    • Macbook: Work, email, IM
    • iPhone: Gaming, Twitter, short-form reading
    • iPad: Gaming, long-form reading

    Here are a few changes in behavior I’ve noticed:

    • Whenever I’d get to a tough take-a-moment-and-think problem while coding, I’d context switch to Reeder or Twitter — no more!
    • I am finishing a lot more long-form reading
    • I am experiencing a lot more games (I’m not finishing them all, but that’s a whole other blog post)
    • I’ve rediscovered the beauty and utility in each of the devices

    The end result: I’ve noticed a huge difference in my productivity since adhering to these domains. The lack of context switching when I’m on a device increases focus tenfold. Also, when I use a device in a way that really makes the most of its form factor and capabilities, I feel like I’m in my stride. I’m not swimming upstream anymore, so to speak.

    So, I’m going to try my best to keep Twitter and Reeder off my laptop, and work off my mobile devices. You should too if you don’t already!

  • britg 9:05 am on July 13, 2012 Permalink | Log in to leave a Comment  


    I’ve recently returned from a trip to Alaska (highly recommended!) and there’s one thing that I keep returning to in my thoughts, and I think it’s something that’s going to stick with me.

    As you know if you visit any National or State Parks, a big part of their mission is to protect nature, and educate visitors about that protection. What they’re protecting is mostly the same between all the parks, just the setting is different. But, a few of the park rangers in Alaska listed a strange resource they were preserving: Solitude.

    Interesting, I had never thought of solitude as being something to protect, seek out or cherish. Perhaps it’s because the term is often mistakenly associated with loneliness. From Wikipedia:

    Solitude is a state of seclusion or isolation… A distinction has been made between solitude and loneliness. In this sense solitude is positive.

    In Alaska there is a pervading sense of enormity and scale. It can make you feel small and trivial, but not in a negative way. Even when around other people, there isn’t a subconscious press of humans — the space is just too big. The physical wonder of the place leads to a psychological state that I now recognize as solitude. It’s a pretty great place for the mind to be.

    In our normal lives it’s hard to attain solitude but very easy to feel the cold grip of loneliness. I think experiencing Alaska and realizing that solitude is something to seek out and preserve has helped me deal with feelings of loneliness that’s all too commonly found in modern society. For that, I am thankful and I feel compelled to carry the torch: solitude is something we should all protect.

  • britg 8:58 am on March 15, 2012 Permalink | Log in to leave a Comment
    Tags: , spdy,   

    SPDY and Its Relation to WebSockets 

    When SPDY was first announced I didn’t pay too much attention as history has shown it takes years before these things become widely adopted, if ever. Recently though, Twitter launched support for the protocol and I noticed (via this Chrome plugin) that quite a few of the sites I visit on a regular basis (mostly Google properties) are actually using SPDY in production.

    Interesting. I guess it’s time to pay attention.

    But, WebSockets!

    My first question, without knowing too much about SPDY, was what its relation was to WebSockets — are they two competing implementations solving the same problem? The short of it is: No, they are complimentary and will coexist. Here’s my best attempt to relate the two:

    SPDY is an augmentation to HTTP with the goal of making synchronous HTTP requests faster.

    WebSockets is an alternative to HTTP with the goal of facilitating real time communication.

    The big point here being that SPDY shouldn’t require too much application-level refactoring, whereas supporting WebSockets means building an application specifically for bi-directional communication.


    A word often bandied about is push and it has two different meanings with these technologies.

    SPDY Push is a technique where more than just the requested resource is sent down the pipe to a browser, but within the context of a single request. Example: on a given HTML page there’s a good assumption that the corresponding .js and .css and a few images will be requested. SPDY can send all of these in a single request, eliminating quite a bit of RTT (round trip time).

    WebSockets Push facilitates asynchronous communication between the server and browser. The server receives new data from another source and rather than waiting for the browser to request the new data, it is simply pushed through an already-open connection.


    The two protocols are actually complimentary. WebSockets makes its initial handshake with servers over HTTP to discover if the ws:// protocol is supported, and one of SPDY’s primary methods of optimization is compressing and caching HTTP request headers.

    From the SPDY Whitepaper

    Header compression resulted in an ~88% reduction in the size of request headers and an ~85% reduction in the size of response headers… We found a reduction of 45 – 1142 ms in page load time simply due to header compression.

    So, in an ideal future the RESTful request-based web is driven by SPDY, and all of the real-time communication and “app-ifying” is handled via WebSockets. Two peas in a pod!

    • Curt 7:40 pm on May 2, 2012 Permalink

      Hi, nice write up. You have helped me understand the difference between these 2 seemingly similar techs. I think that SPDY should find a new term besides Push as it adds confusion and does not describe the act of sending multiple resources simultaneously.

    • Bill 9:24 am on May 15, 2012 Permalink

      I concur, excellent write-up. Note that you meant “complementary”.

    • Brit 8:21 am on June 29, 2012 Permalink

      Ah, thanks for the correction, Bill

    • Brit 8:22 am on June 29, 2012 Permalink

      Thanks, I’m glad it clarified the distinction between the two for others as well.

    • Guest 2:46 am on July 11, 2012 Permalink

      Thank you for a very good overview of SPDY, websockets and their relations.
      (But you should really change “complimentary” to “complementary”  – with compliments Joe :-)

    • britg 8:20 am on July 11, 2012 Permalink

      Hah, I forgot when Bill had mentioned it — ok, I promise it’s changed now.

    • Murali Suriar 7:42 am on August 2, 2012 Permalink

      Great article; very helpful.

      Alas: you changed the section title, but not in text:”No, they are complimentary and will coexist.”"The two protocols are actually complimentary.”:)

  • britg 11:01 am on January 15, 2012 Permalink | Log in to leave a Comment
    Tags: css3, , ,   

    Forging Forgecraft: Integrating CSS3 Transitions with Javascript 

    Forgecraft is a game currently in development using Ruby on Rails, Backbone.js, and all sorts of HTML5 buzzwords. Read an introduction here, and play the demo here.

    With Forgecraft, and any game really, there are usually quite a few animations running concurrently. I found these moments to be choppy, unresponsive and frustrating when they were implemented in javascript (especially on lower CPU environments like the iPad) and needed another solution. CSS3 transitions were an obvious choice to check out, as they’ve been shown to be a great way to add a little pizzazz to a modern web app and can be executed natively (and even GPU accelerated).

    But, can they provide the technical underpinnings for an interactive gamely element? To be effective in this context, they’d have to be:

    • responsive, consistent and reliable
    • noticeably smoother than their javascript counterparts
    • simple to integrate with scripting

    Regarding the first 2 points, CSS3 transitions’ effectiveness will really depend on your particular use-case. With Forgecraft they were definitely response, reliable, and smoother than javascript and I decided early on to use them in lieu of javascript wherever I could. But, I won’t go into the benchmarks and A/B comparisons in this article… perhaps later. Let’s just skip straight to the useful part:

    Product Intergortion obscure 30 Rock reference →

    Integrating CSS3 transitions with the game’s scripting is pretty straight forward:

    • Define transitions in CSS on your master element
    • Define classes with resulting properties changed
    • Trigger a class change using javascript
    • Listen for the transition-end event with javascript

    Of course, there are a few pitfalls with each of these steps that I’ll go into here. Let’s take an example from Forgecraft: the Bonus Strike event. Randomly while forging the player will see a bar pop-up like this:

    The bar moves from left-to-right and the player’s goal is to click the icon when the moving bar is directly under the target (large white) bar. The moving bar is animated with CSS3 transitions.

    Defining the CSS:

    We have a bar that needs an initial negative offset (the start position) that transitions to its final position. Simple enough: we define the base CSS on the #bar element and give it two classes (.new and .activated) defining each of its states. We also define the transition between the two states:

    position: relative;

    background-color: rgba(153, 153, 153, 0.3);
    border-right: solid 5px white;

    -moz-transition-property: left;
    -webkit-transition-property: left;
    -o-transition-property: left;
    transition-property: left;
    -moz-transition-duration: 1.5s;
    -webkit-transition-duration: 1.5s;
    -o-transition-duration: 1.5s;
    transition-duration: 1.5s;

    } {
    left: 0px;

    #bar.activated {
    left: 600px;

    One pitfall you may run into: for the animations to work in Firefox, you have to explicitly define the initial state for whatever property you are transitioning. In this example we are transitioning the left property of the #bar element. You normally wouldn’t define left: 0; — that’s the default! But Firefox requires this to trigger the transition when that property changes.

    Triggering the Animation in Javascript

    Using jQuery, we simply apply the classes that we defined in the CSS when we want to trigger the transition.

    Listening for the transition-end event

    CSS3 Transitions would be useless if we couldn’t get their context from within our scripting. Luckily, a series of events are fired in javascript while the transitions are running, just like you’d expect in a javascript-based animation. The primary event we care about is when the transition ends as you’ll most likely want to trigger callbacks.

    Unfortunately, each browser vendor has decided to name these events differently… typical huh. Modernizr to the rescue! (If you’re not using Modernizr, you should be. But that’s another blog post altogether).

    There’s a hidden gem in the comments in the source code of Modernizr that explains how to use its .prefixed() API to make a simple wrapper around the browser-specific transition event names. Here’s how I implemented it for the transition-end event. Feel free to use this wherever you need it:

    var transEndEventNames = {
    ‘WebkitTransition’ : ‘webkitTransitionEnd’,
    ‘MozTransition’ : ‘transitionend’,
    ‘OTransition’ : ‘oTransitionEnd’,
    ‘msTransition’ : ‘msTransitionEnd’, // maybe?
    ‘transition’ : ‘transitionEnd’

    CSS3_TRANSITION_END = transEndEventNames[ Modernizr.prefixed('transition') ];

    Bam, now we can use one simple event binding to handle all browsers:

    Stopping a Transition Early

    When the player hits the hammer-and-anvil icon during the Bonus Strike event, I needed to stop the animation early. The easiest way I found to do this, was to just set the animating property to its current value. The transition delta becomes 0, so the animation stops:

    Transition: End

    You may find that integrating CSS3 Transitions into your game makes your interactions smoother and more responsive, and with a simple API for scripting against transition events, developing against them should look and feel a lot like working in pure javascript.

    More Forging Forgecraft:

  • britg 9:27 am on January 7, 2012 Permalink | Log in to leave a Comment
    Tags: , , , mongodb, postgres   

    Forging Forgecraft: A Hybrid SQL MongoDB Data Solution 

    Forgecraft is a game currently in development using Ruby on Rails, Backbone.js, and all sorts of HTML5 buzzwords. Read an introduction here, and play the demo here.

    One of my primary goals while building Forgecraft is to learn as many new technologies as possible. I’ve learned the hard way that it’s better to leave this kind of exploration in your hobby projects and out of your production “for real” stuff. And, seeing as how there are so many emergent technologies right now in web development there’s a lot to explore!

    Whole Hog is Too Much Hog

    MongoDB has quite a bit of steam behind it in the Rails/Ruby community (and plenty of other places too), and with projects like Mongoid and MongoMapper (I went with Mongoid) it’s an easy drop-in replacement for Active Record that maintains all those ORM conventions you know and love. I decided against the replacement approach for one primary reason: I wanted to use existing, robust, and actively developed libraries that rely on Active Record.

    Example: There’s no reason to roll your own authentication/user system when there are insanely popular and feature-full libraries already in place for them like Devise and authlogic (I went with Devise).

    Fortunately combining Active Record with Mongoid and getting the best of both worlds proved to be easy and painless.

    The Set Up

    The instructions for Mongoid include a step to remove the Active Record libraries from being loaded and delete your database.yml. Simply skip that step and both systems will run in conjunction.

    One small operational change you’ll have to make during development is explicitly defining when your rails generators should use Active Record. If you want to make an AR-driven model, your generators will look like:

    rails g active_record:model Player … produces a model the extends from ActiveRecord::Base.

    And by default, the data generators will use Mongoid:

    rails g model Skill … produces a model that includes Mongoid::Document.

    The Implementation

    Here’s how this combo system really shines in my opinion: get all the great features of gems built on AR with all the schema less features of Mongo. I’ll walk through an example:

    In Forgecraft, the authenticating object is the Player and players have many Skills which, right now, are Accuracy, Craftsmanship, and Perception. But, the skill list will likely grow and change over time as the game evolves. A typical AR/SQL based approach would be to create a skills table and a join table between players and skills resulting in a complex multi-table query to get a player’s complete skills.

    It’s clear here that the Player and Skills would fit well together as a single document in Mongo, queried all at once in one tidy object. But, since the Player is also our authentication model, using Mongo would prevent us from using Devise to handle all of that boring and complex auth stuff for us.

    Enter Hybridization. Forgecraft’s implementation uses the typical Devise set up around the Player object (again all on top of AR). All of a player’s skills go into a single document with a reference to the player, like so:

    class Skill
      include Mongoid::Document
      field :player_id, :type => Integer
      field :accuracy, :type => Integer, :default => 0
      field :craftsmanship, :type => Integer, :default => 0
      field :perception, :type => Integer, :default => 0
      index :player_id, :unique => true
      def player

    To set up the relationships like one would expect with Active Record is a simple method on your Player object:

    class Player < ActiveRecord::Base
      # ...
      def skills
        @skills ||= (Skill.where(:player_id => || \
                     Skill.create(:player_id =>

    Bam! Now we can retrieve our skills as a single document (fast), and add new skills with ease (easy). Since Mongo is schema less, you could even have a different set of skills per player. Again, all of this is achievable through SQL — it’s been done for decades — but it just makes more conceptual sense to treat these as a single document.

    Querying and working with these objects and their relationships looks and feels just like active record:

    player.skills.update_attributes(:accuracy => 5), 1)

    Benefits Outweight the Consequences

    I know, I know — any time you introduce an additional system, especially a datastore, you introduce a lot of complexity, failure modes, testing, etc. But, I honestly think the benefits are worth this extra complexity. Speed, ease of development, and the potential for less schema-driven growth make this an ideal environment for me. I highly recommend it, and will be using it in the future!

    More Forging Forgecraft:

    • Paweł Neubauer 12:47 pm on May 4, 2012 Permalink

      Thank you very much for this post :)

    • intelekshual 1:58 pm on May 23, 2012 Permalink

      FYI, Devise supports both ActiveRecord and Mongoid out-of-the-box. You could have chosen either, instead of both.

    • David Lowenfels 5:56 pm on January 9, 2013 Permalink

      I’m confused, so where/how does your application still use SQL?

    • james 10:33 am on November 23, 2013 Permalink

      great post. How did you handle N+1 queries between activerecord and mongoid. When you are
      loading the Player, how do you include the associated skills.

  • britg 6:50 pm on December 29, 2011 Permalink | Log in to leave a Comment
    Tags: coffeescript, , , , html5,   

    Forging Forgecraft Part 1: Introduction 

    For the past few months I’ve been hacking away at a game partly, well, to make a game, and partly to play with a bunch of web technologies I’ve been interested in. That game is Forgecraft! Check it out and tell me what you think.

    What is Forgecraft?

    If you’ve played bejeweled you’ve got an idea of the primary game mechanic: move gems into patterns. If you’ve played Minecraft you’ve got an idea of the gameplay twist: patterns. You’re not just matching 3, but moving ores into patterns that resemble weapons and armor. And finally, if you’ve played any loot-based game ever you’ve got an idea of reward structure: loot!

    The target player is the casual player, but the game may also appeal to people who just like loot. And the target platforms are any modern web browser. Right now things are working ok in Chrome, Firefox, and Safari. Oh, and the game plays well as an installable web app on the iPad. In fact, all of the design decisions were made with this play mode in mind. Go ahead and save-to-homescreen on your iPad!

    Warning: It’s rough around the edges. There’s no tutorial and there may be bugs/features just flat out missing. I consider the game’s state as ‘playable demo.’ But do let me know if you run into any bugs.

    The Tech

    Over the next few months I hope to put together a series of posts on the different technologies I played with while making Forgecraft. You know, go in-depth on each of them and all that jazz. For now, here’s just a run-down of the fun stuff I used:

    Back End

    Front End

    HTML5 Buzzwords

    • CSS3 Animations
    • Web Audio API
    • History API / Pushstate API
    • iOS web-app installable

    My plan is to continue developing Forgecraft, expanding the items, mines, etc. and digging further into these emergent HTML5 technologies. I also would like to continue improving performance across the board. Things can get pretty choppy on the iPad when there are a lot of animations running at the same time.

    Please, give Forgecraft a try and let me know how you like it and if you have any suggestions. The number one question I have is, is it fun? A game should be fun, I’m told.

    More Forging Forgecraft:

  • britg 7:18 pm on December 6, 2011 Permalink | Log in to leave a Comment
    Tags: , sysops   

    The Perfect Logrotate Config 

    One of the first things I do when setting up a new server somewhere is get all those damn log files rotating. Here’s the logrotate.conf block I use:

    in /etc/logrotate.conf

    /path/to/any/log/file/*.log {
    rotate 365

    This is a slight modification of this configuration. Check out his explanation for all of the params.

    The one I added that I think is essential is dateext, which appends dates instead of incrementing digits to the end of the log files, like so:

    -rw-r--r-- 1 britg britg 64M 2011-10-24 06:49 production.log-20111024.gz
    -rw-r--r-- 1 britg britg 62M 2011-10-25 06:52 production.log-20111025.gz
    -rw-r--r-- 1 britg britg 56M 2011-10-26 06:29 production.log-20111026.gz
    -rw-r--r-- 1 britg britg 56M 2011-10-27 06:51 production.log-20111027.gz
    -rw-r--r-- 1 britg britg 57M 2011-10-28 06:51 production.log-20111028.gz

    Which, in my opinion, is much more parseable by our puny human brains.

  • britg 8:07 am on November 30, 2011 Permalink | Log in to leave a Comment
    Tags: ,   

    ShapeEditor – Create and Export Shapes for MultistrokeGestureRecognizer 

    Nicolò Zereik and Luca Roverelli put together a neat tool for creating the JSON template files for the MultistrokeGestureRecognizer library:


    It’s a small JAVA app — check it out if you’re looking for a simple way to create basic JSON template files for the gesture recognizer.

    Thanks, Nicolò and Luca!

  • britg 9:39 am on October 29, 2011 Permalink | Log in to leave a Comment

    IGF Pirate Kart Pack 1 

    If you’re unfamiliar with the IGF Pirate kart, it’s a neat collection of over 300 indie video games:

    a FREE and LEGAL compilation of over 300 games by over 100 developers! It was put together at the last minute for entry into the 2012 Independent Games Festival Main Competition.

    I’ll be honest, it’s pretty dense and the fun-to-meh ratio is pretty low, haha. But, there are a few games I’ve stumbled upon in there that have neat concepts or neat execution. Here’s a package of 4 that I thought were playable at least. Grab the full torrent if you want to check them all out, otherwise grab this pack:

    IGF Pirate Kart Pack 1

    Perhaps my favorite of the bunch is “A Friendship in 4 Colours” by Damian Sommer. I may try to cull a few more gems out of the pack if I can find the time. Enjoy!

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help