Setting up Dokku with DigitalOcean and Namecheap
..or how I made my own heroku in a few hours for $3.98.
find . \( \( -name "*.[chm]" -o -name "*.mm" \) -o -name "*.cpp" \) -print0 | xargs -0 egrep -n '^\w*\#' | egrep -v '(import|pragma|else|endif|HC_SHORTHAND|MOCKITO_SHORTHAND)' |
#compdef fab | |
_targets() { | |
_describe -t commands "fabric targets" target_list | |
} | |
output_levels=( | |
'status: Status messages, i.e. noting when Fabric is done running, if the user used a keyboard interrupt, or when servers are disconnected from. These messages are almost always relevant and rarely verbose.' | |
'aborts: Abort messages. Like status messages, these should really only be turned off when using Fabric as a library, and possibly not even then. Note that even if this output group is turned off, aborts will still occur – there just won’t be any output about why Fabric aborted!' | |
'warnings: Warning messages. These are often turned off when one expects a given operation to fail, such as when using grep to test existence of text in a file. If paired with setting env.warn_only to True, this can result in fully silent warnings when remote programs fail. As with aborts, this setting does not control actual warning behavior, only whether warning messages are printed or hidden.' |
// Just before switching jobs: | |
// Add one of these. | |
// Preferably into the same commit where you do a large merge. | |
// | |
// This started as a tweet with a joke of "C++ pro-tip: #define private public", | |
// and then it quickly escalated into more and more evil suggestions. | |
// I've tried to capture interesting suggestions here. | |
// | |
// Contributors: @r2d2rigo, @joeldevahl, @msinilo, @_Humus_, | |
// @YuriyODonnell, @rygorous, @cmuratori, @mike_acton, @grumpygiant, |
function bridge1Test() | |
{ | |
%obj = new SimObject(); | |
%start = getRealTime(); | |
%count = 0; | |
for (%i=0; %i<1000000; %i++) { | |
%obj.getId(); | |
} | |
%end = getRealTime(); | |
//echo("scriptTest3 result: " @ %count); |
typealias 😺 = String | |
let 😸😼:😺 = "🙀" |
// | |
// AppDelegate.swift | |
// TypedTableViewControllers | |
// | |
// Created by Chris Eidhof on 23/03/15. | |
// Copyright (c) 2015 Unsigned Integer. All rights reserved. | |
// | |
import UIKit |
When Swift was first announced, I was gratified to see that one of the (few) philosophies that it shared with Objective-C was that exceptions should not be used for control flow, only for highlighting fatal programming errors at development time.
So it came as a surprise to me when Swift 2 brought (What appeared to be) traditional exception handling to the language.
Similarly surprised were the functional Swift programmers, who had put their faith in the Haskell-style approach to error handling, where every function returns an enum (or monad, if you like) containing either a valid result or an error. This seemed like a natural fit for Swift, so why did Apple instead opt for a solution originally designed for clumsy imperative languages?
I'm going to cover three things in this post:
extension String { | |
func size(withAttributes attrs: [String:AnyObject], constrainedTo box: NSSize) -> NSRect { | |
let storage = NSTextStorage(string: self) | |
let container = NSTextContainer(containerSize: NSSize(width: box.width, height: box.height)) | |
let layout = NSLayoutManager() | |
layout.addTextContainer(container) | |
storage.addLayoutManager(layout) | |
storage.addAttributes(attrs, range: NSMakeRange(0, storage.length)) | |
container.lineFragmentPadding = 0.0 | |
let _ = layout.glyphRangeForTextContainer(container) |