Goツールのクロスビルドとパッケージングのためのgoxzというツールを作った | おそらくはそれさえも平凡な日々
Goツールのクロスビルドと成果物生成には個人的に長らく、goxcを愛用していましたが、その乗り換えとして、goxzというのを作った。go + x(cross) + z(zip)でgoxz。便利です。 https://github.com/Songmu/goxz goxcは非常に高機能なのですが、僕がその機能の一部しか必要ないことや、goxcのメンテ自体も止まっている(とオフィシャルでも案内されている)ことが気になったので作りました。 具体的には「Goツールのクロスビルドと成果物のアーカイブ生成をパラレルにおこなう」ことしかしない。アーカイブ生成時に、リポジトリからLICENSEやREADMEを自動的にかき集めるのはやってくれます。 基本的には「設定より規約」という感じで、良い感じのデフォルトを決め打ちにして、あまり細かい設定項目などは作らない想定です。 インストール https://git
Mac上にGoの開発環境を構築する〜下準備編 | おそらくはそれさえも平凡な日々
同僚がGoを始める上で、案外まとまった資料が無さそうだったので書いてみることにしました。 Macでhomebrewが入っていることが前提です。事前に brew update をおこない formula を最新のものにしておくと躓くことが少ないでしょう。 Goのインストール % brew install go エントリ執筆時点では、1.6.2 が入ります。Goはメジャーバージョンが同じ場合は、後方互換が保たれているので、基本的に新しいやつを入れて問題ありません。 環境変数の設定 $GOPATH だけを決めればOKです。$GOPATH はどこでも良いのですが、ここでは $HOME/dev を $GOPATH に設定します。また、 $GOPATH/bin に $PATH も通しておきます。 export GOPATH=$HOME/dev export PATH=$GOPATH/bin:$PATH
POSIX sh準拠のシェルスクリプトを書くときに checkbashisms が便利。 | おそらくはそれさえも平凡な日々
http://sourceforge.net/projects/checkbaskisms/ 「#!/bin/sh なのにbashでしか動かないシェルスクリプトを書くな！」みたいなことはよく言われるわけですが、僕はゆとりなので正直どうでもええやろとか思ったりもしてました。実際、CentOSだと、/bin/sh は /bin/bash へのリンクだし、OSXでも /bin/sh の実態はbashだしね。 しかしそこで立ちふさがるのがUbuntu。Ubuntuだとデフォルトで /bin/sh は /bin/dash だったりするわけです。dashはPOSIX準拠のsh実装で、bash独自の記述があると見事に動かない。 とはいえ、それで困るのだったら、デフォルトシェルをbashにしたVMテンプレートを作ればいいんじゃないかって思うやろ。僕もそう思う。 しかしそこで立ちふさがるのがTravisで、
Macのメモリ利用状況をコマンドラインから取得する(2015年 Yosemite版) | おそらくはそれさえも平凡な日々
余り新しい情報がなかったようだったので調べてみた。正確じゃないところもあるかと思うので識者の指摘もお待ちしています。 Macにはアクティビティモニタっていうのがあって色々なリソースを見ることができる。メモリタブからメモリの状況も見ることができる。これは結構コロコロデザインや表示している値が変わっているようなのだが、手元のYosemite 10.10.3だとこんな具合である。 これらの値がどうやって算出されているかが知りたいし、コマンドラインから取得したい。つまりmackerel-agentで使いたい。 OSXではメモリに関する値はvm_statを使うと取得できる。だいたいこんな感じの出力が得られる。これらの数値に4096を乗じるとbyte数になる。 % vm_stat Mach Virtual Memory Statistics: (page size of 4096 bytes) Pag
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々
デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は本当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒
Linuxサーバーのアカウント管理について | おそらくはそれさえも平凡な日々
少人数でサービス開発をしていると、サーバーのアカウント管理を疎かにしてしまいがちです。良くないことだとわかっていながらも、共用ユーザーのログイン情報を数人で共有していたりだとか、rootばかり使っているなんてこともあるのではないでしょうか。 それだとオペレーターが増えたり、退職者がでたりした時に困ることになるので、最初からルールと仕組みを決めておいた方がトータルで楽になります。 前提 パスワードやログイン鍵の共用、ダメ！絶対！ rootを常用するの(・A・)ｲｸﾅｲ!! パスワードやログイン鍵を共用していると、人数が増えた時に誰が作業しているのか把握するのが大変になりますし、退職者が出た時に一斉変更をせざるを得なくなって混乱してしまいます。逆に一部のスタッフを別扱いして権限を制限したユーザーをアドホックに作ったりしてしまうのも管理が煩雑になります。じゃあどうすればよいかというと、個人ごとに
plenvを使ってプロジェクト用のPerlをビルドする方法とそのスクリプト | おそらくはそれさえも平凡な日々
ローカル開発の環境ではあんまcarton使う必要ないなーとか思っていて実際僕は使っていないんですが、みんなまじめにCarton入れて、いちいち% carton execとか打ったりとか独自エイリアス作ったりしてて大変そうだなーとか思っていたので以下の様なスクリプトを書いた。 プロジェクトリポジトリの直下なりに置いておいて叩いてもらうと、プロジェクト用のPerlがインストールされる。適当に-j 4してるけど結構早くて手元の環境だと10分位でビルドできた。 以下の2点がミソ。 plenvの--asオプションを使いプロジェクト固有の名前でPerlをビルドする .perl-versionファイルをプロジェクトディレクトリに配置して上の名前を指定する これで、プロジェクトディレクトリに入れば自動的にプロジェクト用のPerlを見てくれるようになります。.perl-versionはリポジトリにコミットし
DBI->connectの第4引数の内容は設定ファイルに書かないほうが良い | おそらくはそれさえも平凡な日々
Perlでデータベースに接続する場合は以下の様な感じになります。どんなORMなりラッパーなりもDBIを利用しているモジュールは内部的にはこういうことをしているわけです。 DBI->connect($dsn, $user, $password, { mysql_enable_utf8 => 1, RaiseError => 1, PrintError => 0, ShowErrorStatement => 1, AutoInactiveDestroy => 1, }); 第1〜第3引数は環境によって差異があるので設定ファイルに情報を持たせると思います。ただ、それにつられて第4引数も設定ファイルに書いてしまうのが散見されますが、これは良くない。 第4引数の値はプロジェクトでは固定に決まっているので、設定ファイルによって自由度を持たせる必要性が全く無いというかむしろ悪。この人の環境ではテストに通
CPANモジュールは依存モジュールのバージョンを固定しない方がいい | おそらくはそれさえも平凡な日々
Perl界隈ではCarton周りのtoolchainが整ってきて「これからはsemantic versioningやー」みたいな意識が高まりそうですが、そういうルールに則ってバージョニングをするのは大いに結構だとは思うのですが、バージョン違いのモジュールを同一プロセスで共有するとかそういうことはPerlではできないのでどちらにせよ注意が必要です。 まあ、バージョン違いのモジュールを共有できたところで、バージョン違いのオブジェクトが変なところに渡って死ぬみたいな話もあったりなかったりするらしいので夢を見過ぎるのも良くないですね。 それとタイトルのとおりですが、CPANに上げるモジュールの場合はバージョンは固定したり最大バージョンを決めない方が良いでしょう。 例えば、 Super::ORM が Mouse 2.0に固定依存 Hyper::WAF が Mouse 3.0に固定依存 だったりすると
おそらくはそれさえも平凡な日々: モダンなPerlを「読む」上で覚えておくとよい構文 第1回(?)
Perl学習者がある程度Perlに慣れてくると、他の人の書いたコードを読む機会も増えてきます。そこでつまづく人は多いのではないでしょうか。かく言う私自身がその一人です(笑) モダンなPerlはDSL(黒魔術?)的な書き方をしている部分も多く、雰囲気として処理内容をつかみやすいのですが、逆に文法的に構文を理解するのが難しいことも多いです。 「知っている人には当たり前、知らない人には黒魔術」 Perlにはそういうのが多いので、そういったところで悩んでいる人も多いのではないかと思い、このエントリーを書いてみることにしました。気が向けば続きも書きます。間違っている部分もあるかと思うので、ブクマコメ等でご指摘いただけると助かります。 本日の目標とサンプルコード 裸のワード(bareword)は怖くない encode cp932 => $str; sub PI(){3.1415926535} てことで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
