WebKit CSS Variables⚓

CSS variables were just added to WebKit. This probably won't make it into a browser for awhile, but still really exciting.

The sad thing is the syntax is just horrendous.

<style>
  body {
    -webkit-var-foreground: green;
    -webkit-var-background: rgb(255, 255, 255);
    color: -webkit-var(foreground);
    background-color: red;
    background-color: -webkit-var(background);
  }
</style>

This text should be green on a white background. There should be no red visible.

Awhile back there was some discussion on the mailing list about copying how SCSS does it. It's a shame that didn't happen.

Why the Facebook IPO Matters

Facebook's IPO was today. Unless you're living in a cave, you already knew this. Facebook's IPO is a big deal.

A bunch of people not too far from here just became millionaires (or will be very shortly). All of these now super rich Facebook employees are going to spend this money. Housing near the Facebook office has been going up and up in price. Buying a ridiculous house is where I'd start, but that's only a few million.

What would I do after I buying a sweet house and a Tesla? Invest in some smart kids making something cool in San Francisco. The bubble is just getting started.

Ruby in the Browser⚓

Ruby just got support for Native Client.

Google Native Client (NaCl) is a sandboxing technology for running a subset of Intel x86 or ARM native code using software-based fault isolation. It is proposed for safely running native code from a web browser, allowing web-based applications to run at near-native speeds…

This is pretty exciting. This means you can start running Ruby code in the browser.

In the next couple of years the lines between “web technologies” and other development tools are going to get more and more blurry. Really exciting possibilities.

Google Knowledge Graph⚓

Looks like Google got tired of us using Wikipedia. It does look like a cool idea and the video is pretty neat.

Overall, it will be a good improvement to search results. Google should do more of this. Focus on what they're good at, search.

(via Steve Derico)

Introducing SSPullToRefresh

There are tons of pull to refresh views for iOS on GitHub. Every time I need to add pull to refresh to a project, I end up hacking one of them to pieces. This is silly. I wrote a better one: SSPullToRefresh.

Customizable

SSPullToRefresh is highly customizable. There is a contentView property that allows you to set the view that shows when the user pulls. This is really great because you can simply make a view conforms to the SSPullToRefreshContentView protocol you're good to go. You don't have to hack up the pulling logic.

By default, a basic content view is set if you don't provide one. See the readme for the full details on customizing).

Clean API

You don't have to implement all of the UIScrollViewDelegate methods and forward them. This is silly. SSPullToRefresh uses KVO to track the scrolling. This is all you have to do to add it your scroll view:

[[SSPullToRefreshView alloc] initWithScrollView:self.tableView delegate:self];

That's it. It will automatically add all of the necessary KVO, set its frame, and add itself as a subview at the right spot.

Flexible

You can easily change the height of the view when it's fully expanded by setting the expandedHeight property. Easy as that.

Every pull to refresh view I've ever used doesn't take into account that you may want to change the content inset on your own as well. When you initialize SSPullToRefreshView with a scroll view, it will detect any content inset and make all changes relative to that. If you need to update it later, just set defaultContentInset on your pull to refresh view. Assuming you set it as a property in your view controller, here's what that looks like:

self.pullToRefreshView.defaultContentInset = newContentInset;

Enjoy

I'm using this in Cheddar and several other apps. Not having to hack the internals of a poorly implemented pull to refresh view is really refreshing.

The full source code is on GitHub. Enjoy.

SASS vs LESS⚓

Chris Coyier from CSS Tricks compares LESS to SASS in the most fair post I've seen. His conclusion:

SASS is better on a whole bunch of different fronts, but if you are already happy in LESS, that's cool, at least you are doing yourself a favor by preprocessing.

Most arguments I've read are just “I like SASS better.” His is very technical comparison of the two. It's a really interesting read.

(via David Kaneda)

The Balance

The balance between shipping and perfecting the details is what makes things great. Last night I spent 3 hours on an animation for Cheddar. It was probably overkill to make a custom animation curve with CAKeyframeAnimation, but I really wanted it to look like what I had in my head.

Looking back at it today, I'm proud of it and glad that I learned more than I cared to know about animation curves. It might have been a better use of time to just use a default curve and finish the feature instead of spending the whole time on a single animation.

I'm still not sure if learning something new and perfecting it was better than finishing in this case. Usually whenever I spend hours on a particular detail (like fading in a slight shadow at exactly the right speed) I'm never sure which side of the spectrum it falls on. I think this feeling means you're doing it right.

Strapless iPod Nano Watch⚓

Who needs a wristband for an iPod nano when you can just implant magnets? I'm sure he'll have fun at airports now.

(via Kevin Smith)

Zendesk Careers Video⚓

Zendesk has a really amazing careers video. Best line:

These people are not a-holes. Zendesk does not hire a-holes.

If I was looking for a job, I would consider Zendesk after seeing this amazing.

(via Luke Beard)

Cheddar Lessons So Far

I've been working on Cheddar full time for a month and a half now. This is the first time I've exclusively worked on my own products. The things I've learned in this short time are far from what I expected. Here's a few.

Tech Doesn't Matter

As a software engineer, the tech behind a product or feature used to be the interesting part to me. It doesn't matter though. Users don't care about any of those details. They just want it to work well. Solving interesting engineering problems, while fun, doesn't matter. Trying to release a product all by my self makes that so much more clear than it used to be. (I'll post more on the tech stuff later.)

This brings me to my next lesson.

Ship It

I went back and forth a lot on if I should release Cheddar before the iOS application was ready. A bunch of friends were on both sides with really good arguments. I ended up opening sign ups for the web app for a few minutes yesterday and the response was amazing. (Follow @cheddar for updates on when sign ups open again.)

The feedback was super valuable. Lots of people reported little bugs that I had missed. The cycle became clear. Release, fix all the bugs, repeat. All of this feedback and watching the number of users double each time is super motivating.

Charge Money

I'm a big fan of 37signals mindset. To paraphrase:

If you're running a business, charge for something.

From day one of Cheddar being out, there was something the user could pay for. A few did. I think over the long term, the freemium model will be the way to go. I could've taken the lazy route, but this is important.

Charging sets the expectation between you and your users. They expect excellence if it costs money. This holds you accountable to not ship crap. I like it.

Design Takes Time

I've designed all of Cheddar (except the logo and iOS icon). At first it was hard. I was frustrated because I can program something way faster than I can design it. After awhile, the process became more enjoyable and the time it took seemed less relevant. Enjoy the process.

Final Thoughts

Cheddar has only been out (in limited release) for 2 days, so I'm sure there's much more to learn. This has been the must fulfilling project I have ever worked on. I can't wait to see where it takes me.

Progress in iOS

In this year's RailsConf keynote, DHH talked about progress. In short, things are always changing—usually for the better. Progress is good. Embrace it.

I know a lot of people (especially in the Objective-C world) that fear progress. We have all of these great tools like Automatic Reference Counting, Core Data, and UIKit to make writing iOS applications easy. Apple has spent some considerable engineering time solving problems that we all have to solve. Quit wasting your time and embrace it.

People give lots of excuses for not using these fantastic technologies. Most of them boil down to resisting learning how to use them. Progress means learning. Learning is good. For these three in particular, the learning required to leverage all of the solutions to problems you're spending time solving is absolutely worth it. Spend your time building something useful instead of reinventing a solution to a solved problem.

I've heard of people rewriting simple things like UIImage because they didn't understand how it works, writing complex wrappers around SQLite to make an object graph, or starting new projects and not using ARC. This is ridiculous. On the other side, I know people who have used Core Data in their first app and happily upgraded their projects to ARC.

Spend an hour, watch a WWDC video, and start embracing progress.

By the way, I highly recommend watching his keynote even if you don't care about Rails. It's worth your time. If nothing else, it's good motivation.

RubyMotion Review

RubyMotion was released today. RubyMotion lets you write iPhone and iPad apps in Ruby.

RubyMotion is a revolutionary toolchain for iOS. It lets you quickly develop and test native iOS applications for iPhone or iPad, all using the awesome Ruby language you know and love.

Background

It's a very exciting new product from Laurent Sansonetti, the creator of MacRuby. He was at Apple working on MacRuby full-time, but decided to leave and do his own thing. This is what he made.

Initial Reaction

After paying the $149.99 for RubyMotion, I was excited to try it out. The installation process was super easy. There was a small issue with it not finding my version of Xcode right away, but I have a pre-release version, so that's understandable.

I got my first app up and running in less than a minute (once I got my Xcode issues sorted out). Already way impressed.

Ruby Instead of Objective-C

Writing Ruby code like this is amazing.

@window = UIWindow.alloc.initWithFrame(UIScreen.mainScreen.bounds)
@window.makeKeyAndVisible

Here's the same code in Objective-C

self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
[self.window makeKeyAndVisible];

Here's another example. Ruby code:

navigationBar = UINavigationBar.appearance
navigationBar.setBackgroundImage(UIImage.imageNamed('nav-background.png'), forBarMetrics: UIBarMetricsDefault)
navigationBar.setTitleTextAttributes({
  UITextAttributeFont: UIFont.cheddarFontWithSize(24.0),
  UITextAttributeTextShadowColor: UIColor.colorWithWhite(0.0, alpha:0.4),
  UITextAttributeTextColor: UIColor.whiteColor
})

Objective-C:

id navigationBar = [UINavigationBar appearance];
[navigationBar setBackgroundImage:[UIImage imageNamed:@"nav-background.png"] forBarMetrics:UIBarMetricsDefault];
[navigationBar setTitleTextAttributes:[[NSDictionary alloc] initWithObjectsAndKeys:
  [UIFont cheddarFontWithSize:24.0f], UITextAttributeFont,
  [UIColor colorWithWhite:0.0f alpha:0.4f], UITextAttributeTextShadowColor,
  [UIColor whiteColor], UITextAttributeTextColor,
  nil]];

I'm totally in love with the Ruby syntax over Objective-C. Also, I'm really looking forward to using mixins. Categories are also awesome. Want to add a method to a class? Just open the class and add it:

class UIColor
  def self.cheddarTextColor
    self.colorWithWhite(0.267, alpha:1.0)
  end
end

Build Settings

The way the build system works in RubyMotion might be my favorite thing. It's just a rake task, and it's amazing.

I have custom fonts in the application I was working on. I figured this would be annoying to figure out how it wants me to tell it that I'm using a custom font. After reading the RubyMotion docs, I ran rake config to see the current configuration. It already had the correct configuration! RubyMotion detected that I added a font file to my resources folder and added the appropriate configuration for me. Amazing.

Here's an excerpt of my Rakefile:

Motion::Project::App.setup do |app|
  app.name = 'Cheddar'
  app.interface_orientations = [:portrait]
  app.prerendered_icon = true
  app.icons = %w{Icon-29.png Icon-50.png Icon-57.png Icon-58.png Icon-72.png Icon-100.png Icon-114.png Icon-144.png}
end

I totally love this. This is a million times better than fighting with Xcode's clunky UI for configuring all of these options. I also really like that RubyMotion gives you access to edit whatever Info.plist or build settings you want.

You can just run rake config to see the entire configuration of your application. For anything you want to change, you just add the option in the Rakefile. Such a great way to do it.

Console

The REPL (read-eval-print loop) is hands down the most amazing part of RubyMotion. It's even more advanced than Apple's tools here. Watch the demo to understand how awesome it is.

You can command-click a view on the screen and then it becomes self in the console. Say you command-click a UILabel in the simulator. You can type the following command:

>> self.text = 'Awesome'

and see label's text updates immediately.

I was trying to see if some fonts were being loaded in my RubyMotion application. Normally, I would add some logs to the beginning of my application delegate to see what's going on. I realized I had a console, so just typed what I was going to log in the console. There was the output immediately. Amazing.

Testing

I'm also really looking forward to testing with Ruby tools. The Objective-C community rarely tests stuff. The Ruby community is all about it. My theory is that's due to the compiled nature of Objective-C. Anyway, I'm really excited to use MiniTest to test my apps. The RubyMotion documentation is a bit lacking here at the moment.

Final Thoughts

I am quite confident that if Laurent had stayed at Apple, we wouldn't have anything close to this today for two reasons. Apple is heavily invested in Objective-C. Objective-C is fantastic. Apple has been using it for years and years. It's not “broken” per se. Secondly, I think the main reason is this is a lot of new stuff. Apple is a giant company. Stuff like this would take a ton of effort navigating internal politics to pull off. I'm glad he left and made it a reality.

I really like the build system, configuration, and writing Ruby.

I plan on converting Cheddar to RubyMotion in my free time. I doubt I'll ship a RubyMotion version anytime soon, but I'm not opposed to the idea. Overall, RubyMotion is great. It means more people on the iOS platform, which is a good thing.

Announcing Cheddar⚓

Cheddar is an app I started working on November of last year. From the start, it was a really exciting project, but I never had much time to devote to it. Now that I don't have a job, I've been focusing on it full time.

Cheddar will be the first Nothing Magical product that I launch. I'm massively excited to release it so you can see what I've been up to. It should come out in a couple of weeks. I have a lot of other ideas that I can't wait to work on, but more on that later.

Check out Cheddar (there are some screenshots on Dribbble too). I made a little video to tell you about Cheddar. Head on over and watch it.

Image Optimization on iOS

Recently in IncrediBooth, I greatly decreased the size of the IPA we send to Apple. We were around 70MB before everything and ended up at 31MB. It was honestly really easy to shave that much off the app.

IncrediBooth is a universal iPad/iPhone app. With the last update, we added support for the new iPad's retina display. This made our bundle huge. IncrediBooth has a ton of full screen textures to help illustrate the physical metaphor. These images as 2048 x 1536 PNGs are just massive. Converting some of these to JPEGs saved a ton of space. It's unfortunate they don't load as quickly, but some PNGs that were 10MB+ were ~200Kb. This was a good first step.

Even after converting as much of the big textures as I could to JPEGs, I was still over the 50MB limit. My goal was to be under 20MB so older devices could download it without WiFi. I turned to my Twitter friends and found ImageOptim.

Next, I converted as many images to PNG8 as possible. In Photoshop, you can Save For Web as PNG8 instead of PNG24 for images that would work well as GIFs. Even though it doesn't support variable alpha, it's great for simple images.

ImageOptim is fantastic. Just give it all of your images and it will crank away on them. It runs your images through a series of tools to compress them as much as possible without reducing the quality. Even though I had saved-for-web all of the images, ImageOptim was able to compress most of them over 50%. Some got as high as 90% savings. Amazing!

I ran all of the images through ImageOptim twice. The second time was able to compress some images even more. Remember this is all lossless compression. Everything still looked great, but was way smaller. Really great stuff.

The last thing I tried to make things even smaller was ImageAlpha (by the creators of ImageOptim). It's a tool that lets you create PNG8 images with variable alpha! This will save tons of space. It's a way more manual process than ImageOptim, but works well for larger images with alpha that don't have a lot of colors.

Note: Be sure to disable Xcode's image optimization or it will undo all of your hard work when it creates your bundle.

Conclusion

I've heard mixed thoughts on these tools. Some Twitter friends said it caused issues for them. Personally, I haven't had any issues with these tools. Everything works amazingly well. If you're trying to shrink your bundle size, I highly recommend these tools.

If you want even crazier compression, checkout Scribd's fork of AdvanceCOMP by John Englehart (the creator of JSONKit). It's a little too hardcore for my taste, but you may want to give it a try.

Here We Go Again

If you've kept up with me at all the last couple of years, you already know what this post is about. April 5th will be my last day at Synthetic. It has been absolutely fantastic working here. I have had an amazing time with everyone. I got to be a part of some really great stuff in my time at Synthetic. Everyone I got the privilege of working with will definitely be missed.

What's Next

I'll be dedicating all of my time now to some products I can't wait to show you. My goal is to stay on my own for as long as possible. Hopefully some of the products I'll be releasing will make enough money to pay my bills so I can continue to keep doing this.

When I run out of money, I'll figure something out. Contract work will probably be a temporary means of building back up my cash buffer (or cash cache if you will) so I can get back to my own stuff. (That said, I'm not looking for work.)

I'm really excited and nervous about the coming months. It's a dream come true to be able to do this. Thank you to everyone for your encouragement and support.

By the way, I have something small launching soon. Exciting times!