はてなブックマーク

以下の記事はbanjun氏との共同執筆です。 banjun氏の深い知識と経験に尊敬と感謝の意を表します。 要約 UITableViewControllerを使わずに、自分で実装しろ。 ちょっと長い要約 UITableViewControllerのコンストラクタにはバグがある Swift 1.1には、簡単な回避方法があった Swift 1.2で使えなくなったので、別の回避方法が必要 前提知識 Swiftのdesignated initializer と convenience initializerに関する知識を前提する。 [Swift] クラスのイニシャライザ３： Designated Initializer と Convenience Initializer - Qiita UITableViewControllerに関する問題 複数回呼ばれる designated initialize

SHELL=/bin/bash MALITO=alert@example.com 0 0 * * * /path/to/command そして、以下のようなポリシーでログを取りたい。 標準出力も標準エラー出力も、全部ログに記録する。 標準エラー出力があった場合は、メールを送信する。 /path/to/command >> /var/log/some ですと標準エラー出力がログに記録されませんし、 /path/to/command >> /var/log/some 2>&1 だと標準エラー出力に出力されずメールが送信されません。 解決策 SHELL=/bin/bash MALITO=alert@example.com 0 0 * * * (/path/to/command 2>&1 >> /var/log/some) | tee -a /var/log/some 解説 まず前半の /path

ssh接続 ビルド結果画面にある「&enable SSH」をクリックすると別インスタンスが起動し、ssh接続可能になる。 「ローカルでは動くか、CI上では動かない」などのトラブル調査の際に便利。 circle.ymlで設定可能な項目(抜粋) Configuring CircleCIからの抜粋。 /etc/hostsへの登録 名前解決できないテスト用サーバ等を設定するとよい。

SML#で書かれたプロジェクトをWerkecrでCIできるようにする方法を書きます。 前提 対象のプロジェクトがGithub/Bitbucketにあること(プライベートレポジトリ可)。 make check等で単体テストが走るようになっていること。単体テストを書く際はSMLUnitがオオススメです。(というか他に選択肢がない) 設定方法 Werckerの設定 Werckerのアカウント取得やプロジェクトの作成等が必要ですが、そのあたりについてはGithubのプライベートリポジトリでも無料で使えるCI、Werckerを使ってrails newからHerokuのデプロイまでやってみるの「Werckerを設定する」が分かりやすいです。 wercker.ymlの作成 SML#インストール済のOS(werckerではboxと呼ばれる)はすでにmzp/smlsharp-boxとして用意してありあす。

Section HilbertSaxiom. Variables A B C : Prop. Lemma HilbertS : (A -> B -> C) -> (A -> B) -> A -> C. Proof. move=> hAiBiC hAiB hA. move : hAiBiC. apply. by []. by apply : hAiB. Qed. コマンド Section HilbertSaxiom は、あとで閉じられるCoqのセクションを始めます。 コマンド Variable A B C : Prop は命題変数A,B,C(型はProp)を仮定します。 これらの変数は今のセクション HilbertSaxiomの中で使えます。 上の補題は HilbertS と呼ばれます。 (A -> B -> C) -> (A -> B) -> A -> CにおけるA -> B -> CはA

前提 heroku toolbelt がインストール済であること Heroku のアカウントを持っていること 準備 まずはheroku用にGemfileの整理などを行なう。

Mirageを使うと、OCamlでXenやEC2の上で動くOSを作ることができる。 スタブライブラリも用意されているので、Linux、 MacOS Xのような普通のOSで開発して、その後、Xen/EC2上で動くカーネルにコンパイルできる。 http://openmirage.org によると、通常のソフトウェアよりも、より安価に、セキュアに、より詳細な制御が利点です。 前提 Debian squeeze (x64) Xen Server 6.1 x64は必須らしい。 OCaml 4.00.1 の インストール 3.12.1以降がapt-getで入るなら、そちらでもOK。 まずは、依存ライブラリをインストールする。

dstatの結果をfluentd経由でGrowthForecastに投げる方法は、ぐぐると何件かブログ記事がでてきます。 ただ、どれもdstatを改造したり、プラグインを改造したりしてて、あまり使い勝手がよくありません。 というわけで、gemでいれれるプラグインだけを使って、可視化できる設定を探してみました。 準備 必要なgemをインストールする。 <source> type dstat tag dstat option -cm delay 3 </source> # GrowthForecast用にメッセージを加工する <match dstat> type copy # CPU関連の結果だけを取り出す <store> type map tag "perf.cpu" time time record record['dstat']['total cpu usage'] </store> #

RubyはともかくCで書かれた拡張ライブラリになるとかなりOS固有の部分がでてきます。 例えばfoo_ext.bundleとbar_ext.bundleが同名の関数fを定義していると、シンボルの束縛がうまくいかず、意図したfが呼ばれないことがあります。 確認方法 DYLD_PRINT_BINDINGS環境変数をYESにして実行すると、各シンボルがどのように解決されているかを確認できます。 $ DYLD_PRINT_BINDINGS=YES ruby app.rb 2>&1 | grep _f dyld: lazy bind: foo_ext.bundle:0x105C55010 = foo_ext.bundle:_f, *0x105C55010 = 0x105C54E90 dyld: lazy bind: bar_ext.bundle:0x105C88010 = foo_ext.bundl

$ bundle exec ruby some_test.rb Run options: # Running tests: ... Finished tests in 1.017405s, 2.9487 tests/s, 1.9658 assertions/s. 普通はこれでも十分なんですが、セグメンテーションフォールトとかの低レベルなバグを追っているときだとちょっとつらい。 そういうときは-vオプションを使ってやればいい。 $ bundle exec ruby some_test.rb -v Run options: -v # Running tests: SomeTest#test_a = 0.00 s = . SomeTest#test_b = 1.01 s = . SomeTest#test_c = 0.01 s = . Finished tests in 1.017389s, 2