Written on Tuesday January 22, 2013 at 12:49 a.m.
It's been roughly a million months since my last update, despite my repeated announcements that I would in fact, keep things up to date.
The main culprit behind it has been my work. I'm not complaining mind you, I enjoy what I do, I just haven't had any time to myself really in months, and what little I have had, I've tried to spend away from any computers.
I think I'm finally ready to spend some of my downtime on my sites and projects again though, I've even taken a couple of contracts back up.
I'm going to pick up a copy of Pikmin 2 for the Wii today, and I'm excited to replay that on the Wii U. I can't tell if it's true or not that upscaling applies, but it certainly seemed that way when I went through the first Pikmin title, and this will get me caught up and ready to enjoy the third.
Written on Wednesday August 22, 2012 at 9:41 p.m.
I recently ran into this strange "jitter" with elements animated by jQuery, and searching for the culprit I found that a parent element set to inline-block in order to auto-adjust the width to the content was the source of my problem.
Normally, I don't really see an issue with people using inline-blocks for parent elements ( despite the title), though I'm not particular for it when a block is not really meant to be displayed inline but as a document-container.
In this situation it was causing some visually jarring problems in animation, but we still needed the block to expand to the size of the content dynamically.
correctContainerDisplay = ->
container = $('#content-container')
width = container.width()
This does a fantastic thing where, we find out what the size of the block turns out to be for its particular instance, and we just set it manually before switching it to a block. No flicker, or fuss, just a super easy solution. If only that were the case more often.
Written on Tuesday August 7, 2012 at 5:47 a.m.
I can't tell you how many countless times I've setup Ubuntu VMs for development, but I've only for the last couple of years done so on a linux host. This whole time I've been setting up /etc/hosts (frequently) because I couldn't find a great way to get hostnames working between the two. Well, the following snippet will get you everything you need to get the two talking over Bonjour:
sudo apt-get install avahi-daemon avahi-discover avahi-utils libnss-mdns mdns-scan
Simple enough right? You can test this out by typing trying:
Where guest is the hostname for your guest machine.
Written on Sunday July 22, 2012 at 7:04 a.m.
First off, setup your Container. I like to set this right after my app to make sure it's available:
@App = Ember.Application.create()
App.mainContainer = Ember.ContainerView.create()
This will attach the main ember container to your content, simple enough right?
Next we'll want to create a view for whatever object / array we have going for us. Personally I love using the Ember Array controllers, which we won't go into detail here, but are super useful for collections. Also, you'll want to make sure your view is already setup. I like using the ember-rails gem because it makes sprocket integration easy. So we setup our super simple view:
App.StuffView = Ember.view.extend
Now we've got our parent container, and our view, how do we make it appear? Well, I ended up handling this with my controller, so in my controller I have this tidbit:
App.stuffController.displayData = ->
stuff_view = App.StuffView.Create()
Now it's up to you to find out where and how you want to execute that, I'm doing it after loading my data successfully.
That's it! that should get your child view to load in parent container in Ember. I know there's bits and pieces left out ( especially data handling ), but I figure most people these days are probably handling data in Ember their own way, but if you want help on that, just let me know!
Written on Friday June 29, 2012 at 4:47 a.m.
As anyone who's interested in this topic already knows, Google has created a port of Chrome for iOS designed to work on the iPhone and on the iPad.
I did a little bit of testing today, hoping to see what the primary differences in rendering were and found that they were largely the same. Primarily because they are both using iOS's webkit rendering. This is actually a good thing, it helps to speed up the app and it keeps web pages consistent on the device.
I love the Chrome UI, and I'm a big fan of the synchronization, but the speed benefits on Safari might actually keep me from making the switch.