Writing

I should do it more

Recreating DuckDuckGo's "I'm Feeling Lucky" bang method on Google

DuckDuckGo has a slew of bang methods that let you do all sorts of things with your search terms. One of them is just the bang (!) that’ll automatically go to the topmost result. Like Google’s “I’m Feeling Lucky”.

How can we do that on Google aswell? Using dotjs! Long story short, dotjs let’s you write javascript files that run after sites load eg. ~/.js/google.com.js in this instance.

(function (window, document) {
  "use strict";

  console.log("dotjs");

  // Parse the search string to an object
  var params = window.location.search
    .replace(/^\?/, "")
    .split("&")
    .reduce(function (params, kv) {
      kv = kv.split("=");
      params[kv[0]] = kv[1];
      return params;
    }, {});

  // See if the ?q param contains a bang
  if (params.q.match(/\!/)) {
    // Click the topmost result
    document.querySelector("h3.r a").click();
  }
})(window, document);

El Capitan GM update notes

UPDATE 2015-10-11: Turns out, on a clean install /usr/local is still writable – even with SIP turned on.


I’ve been running the beta of OS X 10.11 El Capitan for some months and there’ve been very few hiccups. So full sail ahead on the update I say.

Upgrading to the GM broke my homebrew though. I think the days of using /usr/local might be over as El Capitan does some stuff to enforce even stricter permissions than a simple chown can get rid of.

So I’m moving out! Someone (forgot who or where – sorry!) mentioned in a Github issue thread how he’d been running his homebrew out of /Users/Shared/Developer for some months with no problems, so that’s what I did:

Installing Homebrew outside of /usr/local

$ git clone https://github.com/Homebrew/homebrew.git /Users/Shared/Developer

Now, that directory’s bin directory isn’t in your $PATH (like /usr/local/bin is automatically) so we need to add it. Open up ~/.bashrc or ~/.zshrc – whatever your preference – and add this:

export BREW_PATH=/Users/Shared/Developer
export PATH="$BREW_PATH/bin:$PATH"

Done. Run brew doctor to confirm.

Install taglib-ruby gem with Homebrew outside /usr/local

$ brew install taglib
$ gem install taglib-ruby -- --with-tag-dir=$BREW_PATH/Cellar/taglib/1.9.1/

Use webpack-dev-server and react-hot-loader with Phoenix

NB: Here’s an updated setup.

Phoenix has built-in livereload and it works right out of the box. But if you’ve ever had the joy of working with React and react-hot-loader you know you need to have that with you anywhere.

Phoenix uses Brunch to build it’s assets so we’ll have to pull that out and jam in a webpack-dev-server wherever it was. Luckily that’s quite easy.

The completed example is available on Github.

First, let’s create a new app:

$ mix phoenix.new my_app
$ cd my_app

We could’ve generated the app without Brunch but let’s keep it in, to see what we’re actually substituting. Let’s start by pulling out Brunch and it’s dependencies and then add our new ones:

$ npm uninstall --save babel-brunch brunch clean-css-brunch css-brunch javascript-brunch sass-brunch uglify-js-brunch
$ npm install --save babel-loader react react-hot-loader webpack webpack-dev-server

Now, webpack needs to be told what to build and how, so let’s make a config file. Here’s webpack.config.js:

var path = require("path");
var webpack = require("webpack");

var env = process.env.MIX_ENV || "dev";
var prod = env === "prod";

var entry = "./web/static/js/bundle.js";
var plugins = [new webpack.NoErrorsPlugin()];
var loaders = ["babel"];
var publicPath = "http://localhost:4001/";

if (prod) {
  plugins.push(new webpack.optimize.UglifyJsPlugin());
} else {
  plugins.push(new webpack.HotModuleReplacementPlugin());
  loaders.unshift("react-hot");
}

module.exports = {
  devtool: prod ? null : "eval-sourcemaps",
  entry: prod
    ? entry
    : [
        "webpack-dev-server/client?" + publicPath,
        "webpack/hot/only-dev-server",
        entry,
      ],
  output: {
    path: path.join(__dirname, "./priv/static/js"),
    filename: "bundle.js",
    publicPath: publicPath,
  },
  plugins: plugins,
  module: {
    loaders: [{ test: /\.jsx?/, loaders: loaders, exclude: /node_modules/ }],
  },
};

I will not go into too much detail but notice the address http://localhost:4001. That’s where webpack-dev-server will be running from when we’re developing.

Next, let’s set up the dev server in webpack.devserver.js:

#!/usr/bin/env node
var webpack = require("webpack");
var WebpackDevServer = require("webpack-dev-server");
var config = require("./webpack.config");

new WebpackDevServer(webpack(config), {
  contentBase: "http://localhost:4001",
  publicPath: config.output.publicPath,
  hot: true,
}).listen(4001, "0.0.0.0", function (err, result) {
  if (err) console.error(err);
  console.log("webpack-dev-server running on port 4001");
});

// Exit on end of STDIN
process.stdin.resume();
process.stdin.on("end", function () {
  process.exit(0);
});

That last last bit is there to make the process shut down properly when Phoenix shuts down. (A big thank you to josevalim for guiding me in figuring that out, for being such a seemingly nice guy and of course for making Elixir!)

Don’t forget to make it executable:

$ chmod +x webpack.devserver.js

We need to tell Phoenix to run this instead of Brunch, so open up config/dev.exs and the change watchers: line to include our dev server instead:

config :my_app, MyApp.Endpoint,
  http: [port: 4000],
  debug_errors: true,
  code_reloader: true,
  cache_static_lookup: false,
  watchers: [{Path.expand("webpack.devserver.js"), []}]

And let’s just cut Phoenix some slack and tell it not to watch the assets:

config :my_app, MyApp.Endpoint,
  live_reload: [
    patterns: [
      # ~r{priv/static/.*(js|css|png|jpeg|jpg|gif)$},
      ~r{web/views/.*(ex)$},
      ~r{web/templates/.*(eex)$}
    ]
  ]

OK, let’s make our entry file, web/static/js/bundle.js:

import React from "react";
import App from "./App";

React.render(<App />, document.getElementById("root"));

This renders our App (that we haven’t made yet) to an element with the id root (that we also haven’t made yet). Splitting your React components into separate files let’s react-hot-loader reload them independently from each other.

Here’s a simple web/static/js/App.js:

import React, { Component } from "react";

export default class App extends Component {
  render() {
    return (
      <div>
        <h1>This app is hot!</h1>
      </div>
    );
  }
}

So far, so good. Now we just need some html document to render it in.

Edit web/templates/layout/app.html.eex:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <meta name="description" content="">
    <meta name="author" content="">
    <title>Hello Phoenix!</title>
  </head>
  <body>
    <%= @inner %>
    <%= if Mix.env == :dev do %>
      <script src='http://localhost:4001/bundle.js'></script>
    <% else %>
      <script src="<%= static_path(@conn, "/js/bundle.js") %>"></script>
    <% end %>
  </body>
</html>

Remember that our dev server is running on :4001. We want to use it’s bundle.js in dev and a built one in production.

The only thing left is the element with id root. Let’s put it in web/templates/pages/index.html.eex:

<div id="root"></div>

And we’re done! Now go open http://localhost:4000, edit App.js and behold the magic of our hot reloading gods!

Addendum: Production

Phoenix compiles all it’s assets with the task phoenix.digest which you’re supposed to run before deploying. We can just remember to run webpack beforehand — or we can make our own digest task.

Here’s lib/mix/tasks/digest.ex:

defmodule Mix.Tasks.MyApp.Digest do
  use Mix.Task

  def run(args) do
    Mix.Shell.IO.cmd "./node_modules/webpack/bin/webpack.js"
    :ok = Mix.Tasks.Phoenix.Digest.run(args)
  end
end

Let’s be fancy and override the original task so new developers or deployment scripts don’t need to know about our special setup. Open mix.exs and alias the original to our new task:

defmodule MyApp.Mixfile do
  # ...
  def project do
    [ # ...
      aliases: ["phoenix.digest": "my_app.digest"]]
  end
  # ...
end

Try mix phoenix.digest and see that webpack runs first.

Force-update text shortcuts in OS X Yosemite

My text shortcuts never synced when I recently set up my new Macbook and so I was left inserting all my emojis using ctrl+space and using my mouse like you would if you weren’t communicating primarily by thumbs-up emoji like me 👍🏼

So, to force a refresh:

  1. Turn off iCloud Drive
  2. rm -rf ~Library/Mobile Documents/com~apple~TextInput
  3. Turn iCloud Drive back on

Open every link in Safari's Reading List in tabs

Use Safari’s Reading List as an inbox.

When you come across some link or page that you would like to look into at some point just not right now, hit cmd+shift+d on your mac or use the share sheet available almost everywhere on your iOS device and add it to Reading List.

Then when the time is right explode that thing into separate tabs and purge through them.

#!/usr/bin/env ruby
# $ gem install CFPropertyList
require 'cfpropertylist'

path = File.expand_path '~/Library/Safari/Bookmarks.plist'
plist = CFPropertyList::List.new file: path

list = plist.value.value["Children"].value.select do |item|
  if title = item.value["Title"]
    title.value == 'com.apple.ReadingList'
  end
end.first.value["Children"].value

bookmarks = list.map do |item|
  item.value["URLString"].value
end.reverse

puts "Opening #{bookmarks.count} tabs "

bookmarks.each do |url|
  `osascript -e 'tell application "Safari" to tell window 1 to make new tab with properties {URL:"#{url}"}'`
  print '.'
end

puts ''

Clear all items in Reading List and just re-add any linkif you’re still undecided about it.

The script also works perfectly inside Run Shell Script in Automator if you want a .app.

foundation-grid

For years I’ve been using ZURB’s Foundation as a starting point for new sites. It’s really great — but also kind of huge. And the internals are very advanced so picking out parts isn’t as easy as it probably could be. But here’s the grid for your blocky pleasure:

screenshot

Get it: foundation-grid

blank

Oh, where do I even start.

Now and then I like to sport a completely stripped down Safari, hiding the toolbar and everything else:

Stripfari

Look at that! Just the content. Just me and my one million tabs. Only problem: when I make a new tab, the address bar isn’t focused as it is, when the toolbar is visible. So you need to press cmd + l yourself like an animal.

So we make a start-page for new tabs. But there’s no api for focusing the browser chrome. But there is AppleScript (there’s always AppleScript).

We’ll just make a tiny server that serves a page with one button that it clicks itself. And then make that button call some Applescript. That’s definately not an insane solution to a very serious problem.

Sounds good? You should try it out.

Make Github responsive with 9 lines of CSS

My browser windows are seldomly as wide as Github’s layout. This works great for most of the websites that I visit - yay responsive - but Github’s layout is still too wiiiiiiide.

Taking matters into my own hands I opened up Web Inspector and found out that you can make it (naively) responsive with relatively few lines of css:

Please do fork it and improve it.

Getting your locales in line before going on your dokku adventure

Update 2015-05-12: Seems the correct file to edit is /etc/default/locale:

export LANGUAGE="en_US.UTF-8"
echo 'LANGUAGE="en_US.UTF-8"' >> /etc/default/locale
echo 'LC_ALL="en_US.UTF-8"' >> /etc/default/locale

Then reboot.


I’m really digging dokku-alt. Dokku is a simple way of setting up a deployment setup as easy as Heroku’s. Dokku-alt is that plus some bundled plugins.

I had some troubles though with the Postgresql databases being created with ASCII encodings. So before you install and setup dokku get your locales in order - make your /etc/locales look like:

LANG=en_US.utf-8
LANGUAGE=en_US.utf-8
LC_CTYPE="en_US.utf-8"
LC_NUMERIC="en_US.utf-8"
LC_TIME="en_US.utf-8"
LC_COLLATE="en_US.utf-8"
LC_MONETARY="en_US.utf-8"
LC_MESSAGES="en_US.utf-8"
LC_PAPER="en_US.utf-8"
LC_NAME="en_US.utf-8"
LC_ADDRESS="en_US.utf-8"
LC_TELEPHONE="en_US.utf-8"
LC_MEASUREMENT="en_US.utf-8"
LC_IDENTIFICATION="en_US.utf-8"
LC_ALL=en_US.utf-8

Source it (or reboot) and then set up dokku.

Install Qt on OS X Yosemite (Beta 3)

To install Qt on Yosemite (Beta 3 right now) using homebrew, just act as if you’re on Mavericks and it will work fine:

Edit /usr/local/Library/Homebrew/os/mac/version.rb:

def to_sym
  return :mavericks # <-- stupid hack.
  SYMBOLS.invert.fetch(@version) { :dunno }
end

Then when you’re done; clean up after yourself!

Pages

  • /uses — My current setup

COMPUTERS (Danish)RSS

Danish newsletter on life with computers

Past issues

PostsRSS

Musings on building software