John Gruber asked on Twitter how to force a unicode symbol to render as text insted of emoji. Jason Weather replied that appending U+FE0E forces the symbol to render as text.

I had recently researched a bit on the inner-working of the new emoji skin tone modifiers¹ in Unicode 7.0.² The basics: if a emoji skin tone modifier immediately follows certain characters they should be rendered as a single glyph.

See Unicode technical report #51 for more info.

Standardized variants

The character mentioned by Jason on Twitter is a variation selector under the standardized variants sequence in Unicode 7.0, U+FE0E is named VARIATION SELECTOR-15.

Variation selectors:

“Combining characters; in conjunction with the preceding character these indicate a predetermined choice of variant glyph”
— Unicode Consortium U+FE00 code chart

The basic functionality of variation selectors are comparable to the emoji skin tone modifiers in that they choose a certain variation of the preceding character.

Currently only VS-1, VS15 and VS16 have been defined and implemented, check out a list of VS-1 variant glyphs.

Unfortunately it’s a little hard to demonstrate these things since OS and browser support varies so much.

Character	Image	Emoji	Normal	Text
U+2764		❤️	❤	❤︎
U+21A9		↩️	↩	↩︎
U+25B6		▶️	▶	▶︎

Result on OS X 10.10.3: Chrome 42 and Safari 8.0.5 - the result on iOS with MobileSafari was identical to Safari. ³

I’ve used the Unicode converter on rishida.net quite a lot to convert to/from different Unicode representations. Taking another look at the solution by Jason and running it through the converter we see that the ↩ vs ↩︎ corresponds to: U+21A9 vs U+21A9U+FE0E - notice the U+FE0E at the end of the converted string.

If you’ve ever run gem install, you know how long it can take to complete. Trust me, you’re not alone: plenty of examples showcase similar frustrations in dealing with slow gem install.

Most larger Ruby projects comes with extensive documentation (awesome! 👍), unfortunately the process of turning RDoc into HTML and ri can be quite time-consuming - especially on larger projects or slower machines.

Fortunately, it’s possible to turn off ri and rdoc processing on gem install by executing the command with flags --no-ri and --no-rdoc:

$ gem install rails --no-rdoc --no-ri

Now keep in mind that RDoc and ri is actually pretty cool and if you use them often, instead of online documentation, then you might want to skip this.

If you want this as your default behavior add this to your ~/.gemrc file:

gem: --no-ri --no-rdoc

Another option is to create a Shell alias for gem install that in addition also prefixes with sudo to avoid those pesky “You don’t have write permissions …“:

# Alias
$ alias gemi=”sudo gem install –no-ri –no-rdoc”

# Usage
$ gemi rails

I’ve been getting into webpack a lot lately, partly because of the amazing experience of using React with a hot reloader like react-hot-loader.

If you haven’t used webpack in a project yet, go play around with it right now! For a quick React hot reloader boilerplate checkout react-hot-boilerplate or react-webpack-boilerplate.

In a recent project I wanted to use the new fetch API, if you are not familiar with the background story go read Jack Archibald’s “That’s so fetch!” post.

The overall browser support is starting to pick up, with Chrome 42(beta), Firefox 39 and Opera 29 all shipping with it by default. Internet Explorer is currently listing it as “under consideration” on their platform status page.

Luckily for us GitHub has been maintaining a great polyfill github/fetch since October 2014, which means we can already use this in production. Using the polyfill without a bundler like webpack would mean adding a <script> tag to your template.

I couldn’t figure out the “webpack way” of including the polyfill in my bundle, and after reading the webpack wiki page on shimming modules I still couldn’t quite figure out the syntax.

That was until I stumbled upon this gist by Luís Couto, showing exactly how to use the fetch polyfill with webpack.

The important part of the webpack config:

plugins: [
  new webpack.ProvidePlugin({
    'fetch': 'imports?this=>global!exports?global.fetch!whatwg-fetch'
  })
]

It uses the imports-loader and exports-loader for webpack, so make sure you have them installed:

$ npm i imports-loader exports-loader -D

For more information about shimming modules in webpack, checkout the documentation.

complete rewrite + new features: grunt-xcode

I started building the initial version of grunt-xcode around November last year. The primary reason for the project was that I was getting tired of manually having to do iOS builds for our clients - it needed to be a part of our Grunt build task.

I stumbled upon shenzhen which actually worked fairly well for me as a command-line tool, so I thought “hey let me just wrap this in JS”. That was probably not the wisest decision, but grunt-xcode v1 ended up sort of working for us (not so much for everybody else).

To be honest the code was quite ugly and I didn’t like the dependency on a RubyGem - it just didn’t feel right. I also started getting some bug reports on GitHub and email.

Rewrite

The primary goal of the rewrite was to remove the dependency on shenzhen and use the built-in xcodebuild tool instead.

Features:

• remove dependency on shenzhen
• added support for all parameters available in xcodebuild
• show progress indicators for archiving and export tasks
• show stdout if Grunt is run with the --verbose flag

Usage

I’m actively using grunt-xcode for a client project and it’s been working out great for me.

Installing grunt-xcode is just as simple as any other npm module:

$ npm install grunt-xcode --save-dev

require('load-grunt-tasks')(grunt);

grunt.initConfig({
    xcode: {
        options: {
          project: '/path/to/my/awesome/App/App.xcodeproj',
          scheme: 'Release'
        }
    }
});

grunt.registerTask('default', ['xcode']);

For a list of all options please refer to the README.

Hopefully the codebase is a lot more readable now, that was at least the goal.

Please do let me know if you run into any issues with grunt-xcode, I’m sure there are multiple cases I haven’t tested properly.