Changing Mac OS X Snow Lepoard’s Internet Sharing IP Range

Changing the default network when using Mac OS X 10.6 internet sharing.

Internet sharing is nice. Except when the network you are sharing uses OS X’s default 192.168.2.x range (which is a silly default choice by Apple, why not use something more obscure?)

Here’s how to change it. E.g. to set it to 192.168.24.x:

# set
sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.nat NAT -dict-add SharingNetworkNumberStart 192.168.24.0

# confirm
defaults read /Library/Preferences/SystemConfiguration/com.apple.nat

The most important thing is *don’t have the settings panel open when you do this*! As it loads that file in memory and won’t read it from disk.

So close the settings panel, fiddle with defaults, and restart internet sharing.

Reference: here.

NSAssert

NSAssert can be disabled if NS_BLOCK_ASSERTIONS is defined.

Had a nasty bug recently where some third-party code had critical statements in an NSAssert statement (a big mistake in any language), and NSAsserts had been disabled with a command line parameter unbeknownst to me in the project. Until then, I had never seen a case with NSAssert disabled.

Same code worked in another project in release, but not in this one. Fiendishly hard to track down.

I disagree entirely with the suggestions in this post, but it helped me track down the issue by pointing me to NS_BLOCK_ASSERTIONS.

Tales of PDF Generation in Rails

Last week’s “inflight project” (that is, some fun code I hack out while in the air) was to do some custom PDF generation in Rails. That is, a special view to render a PDF.

There appear to be two main approaches to this currently in rails:

• PDFKit (which uses the wkhtmltopdf binary, itself based on WebKit)
• Prawn (a native Ruby API)

The approaches are fundamentally different. PDFKit is designed to take HTML files and make them PDFs. Prawn is more like a “builder” in that you build your PDF (and it abstracts away a lot of the PDF nastyness).

PDFKit is great for when you need to make PDF’s of your existing HTML documents (railscast here). In fact in a few lines of Ruby in your config file, you can add the ability to make PDFs of every single URL on your site, making for a fancy “save as PDF” feature. With a bit of print-targeted CSS, you can make this pretty amazing.

However, I’m building a custom PDF that won’t be viewed as HTML. So that benefit is moot for this task. A few people did however mention that the nice thing about PDFKit is the learning curve is not very steep as you leverage your existing HTML skills.

So down that route I plunged.

Designing for a PDF with exact sizes, I laid out my HTML file using mm units. I created a “page” div class with the height and width set to my PDF page size. Perfect – now I can generate PDF’s that are page-accurate.

wkhtmltopdf is an amazing library. Don’t get me wrong. It is truly awesome how you can just give it an URL and get back a PDF. And if you set your CSS up nicely, your PDF can be exactly how you designed in in the browser (and that’s the other cool thing – you can preview in HTML…).

But I ran into a few near deal-breaking bugs. I have more-or-less worked around these issues for now, but they are sadly huge problems in this otherwise awesome API. I’m not all complaints here… I have contributed my own test cases and thoughts to these bugs, and in some cases offered some “coder motivation” in the form of a bounty. But a fact is a fact – some are very critical and have gone unsolved for years.

These bugs (as of 2011-04-18) are:

1. Totally borked kerning on characters in Linux. This is a severity one, deal-breaking bug. What looks awesome in Mac OS X, looks terrible in Linux. So be warned if (like me) you dev on OS X and deploy to Linux, as you’re in for a surprise. Workaround: try embedding the fonts and tweak the sizes a lot to hopefully achieve passable results. (nb. there is no real solution to this, only ways to mitigate the effect). Test on your deployment platform during development.
2. You cannot create a pdf that draws to the very edges of the document. There is a small white border at the bottom and right. Workaround: Suck it up.
3. @font-face relative links don’t seem to work. Workaround: use absolute ones

NB. if you’re using Centos5 and try to embed a font using @font-face, be aware of this missing dependancy issue in Centos5 which will crash wkhtmltopdf. Solution: upgrade your dependancies.

Aside: @font-face

Embedded fonts in HTML documents are surprisingly well supported now (even in IE4+, and no that’s not a typo), albiet not quite standardized. I highly recommend Font Squirrel’s @font-face generator for processing your embedded fonts and making them work across all browsers.

Concolusions

Given these pretty critical bugs, if I was starting over, I would probably consider Prawn for any custom PDF view generation, and use wkhtmltopdf more as Middleware for PDFing standard HTML views. wkhtmltopdf can be a little fickle to get the perfect output you want (see the bug list above), and sadly some of these bugs has gone unsolved for a long time. This could be due to the inherit complexities of WebKit and how Linux handles fonts, but it does’t change the end-result. Were these issues fixed – then I do quite like the elegance of re-using my HTML knowledge (hence why I chose that route to begin with).

I guess the biggest thing to realise is that Prawn is cross-platform, wkhtmltopdf is not. Sure, wkhtmltopdf will run on OS X, Linux and even Windows, but the output is not identical, and I doubt ever will be. wkhtmltopdf remains a totally kick-arse tool, one just needs to be aware of these inherit limitations.

Using CSS3 @font-face with wkhtmltopdf on Centos5

Centos5 has an outdated version of libfontconfig which will cause this error if you try and reference a font:

wkhtmltopdf: symbol lookup error: wkhtmltopdf: undefined symbol: FcFreeTypeQueryFace

The issue was reported here with some useful instructions (actually it’s just a dependancy issue).

To fix, first you’ll need freetype-devel:
sudo yum install freetype-devel

Then following this advice, I did something like this:

wget http://www.freedesktop.org/software/fontconfig/release/fontconfig-2.4.2.tar.gz
tar -zxvf fontconfig-2.4.2.tar.gz
cd fontconfig-2.4.2
./configure -prefix=/usr
make
# I moved the file file into /usr/lib manually (don't trust 'make install' on a production box)
sudo mv ./src/.libs/libfontconfig.so.1.2.0 /usr/lib/
# and setup the libfontconfig.so.1 symlink
cd /usr/lib
sudo ln -s libfontconfig.so.1.2.0 libfontconfig.so.1

Thanks to everyone for their awesome help…

Getting notified of Rails errors like the default message claims.

In production, rails3 by default says:

We’re sorry, but something went wrong.

We’ve been notified about this issue and we’ll take a look at it shortly.

Oddly by default it does nothing to “notify” you about the issue (and it certainly does nothing to “take a look at it shortly” ;-)), unless you count logging some data to a log file. This is actually pretty misleading, and I’ve had some customers tell me “I got a problem message that said you were aware of the problem” – I wasn’t aware of it, but could dig it up in the log file.

Enter exception_notifier.
Put:

gem 'exception_notification', :require => 'exception_notifier'

In your Gemfile, and:

config.middleware.use ExceptionNotifier,
  :email_prefix => "[Exception] ",
  :sender_address => %{"Exception Notifier" },
  :exception_recipients => %w{you@me.com}

In your production.rb’s config block. Customise the addresses, and you’re done! Now you will actually be notified of exceptions. Useful…

Here’s a neat way to use exceptions to create custom error pages: http://stackoverflow.com/questions/2238244/custom-error-pages-in-rails/2281215#2281215

I also recommend updating the 500 and 404 error pages with some text that more accurately describes what you plan to do about these errors. You can find these pages under public/