二十四節気スプリントシステムのススメ | おそらくはそれさえも平凡な日々
tl;dr スプリントに名前がついていると便利 2週間スプリントの場合二十四節気をスプリント名につけると捗る ズレは適宜調整しましょう 二十四節気スプリントシステムとは 今年から、Nature社でもスクラムっぽくスプリントを回し始めたのですが、前職のチームでも採用していた二十四節気スプリントシステムを導入しました。 二十四節気スプリントシステムというと大げさですが、これは単に、各2週間スプリントの名前に二十四節気を割り当てるものです。二十四節気のWikipediaのリンクを以下に載せておきますが、最近はGoogle検索の結果にも出てくるので驚きです。 二十四節気 - Wikipedia ちなみに、これは、Mackerelチームでスクラムを採用し始めた頃に、当時のスクラムマスターであったid:motemenが発案したものです。 参考: はてなMackerelチームの開発フロー（スクラム、リモ
Nature Remo作ってる会社のCTOになったのでみんな買ってくれよな！ | おそらくはそれさえも平凡な日々
6月1日付けでNature Japan株式会社の取締役CTOに就任しました。最初の営業日の6/3(月)からいきなり台湾出張に行ってきました。良いスタートアップ感。ついでに本日6月5日に39歳になりました。新たなチャレンジにワクワクしています。 大塚(@maaash)さん、村瀬(@typester)さんに続く3代目のCTOとなります。2人はカヤック時代の同僚でもありますが、カヤックのラボチームのダブルエースだった彼らの後任としてCTOをやるのは恐れ多いのですが、僕は組織づくりなど含めて僕なりに組織に貢献していきます。 当社はおかげさまでスマートリモコンのNature Remoが好調で、現在はNature Remo Eというスマートエネルギーハブの開発を進めているところです。今後は電力なども見据えて事業を展開していく計画で面白いフェーズにあります。 まだ、社員全員でも10人に満たない小さな会社
JSONを使ってコマンドラインを動的に組み立てて実行するjfillを作った | おそらくはそれさえも平凡な日々
https://github.com/Songmu/jfill 標準入力からJSONを受け取り、その値を使ってコマンドラインを組み立てて実行するユーティリティです。以下のような具合です。 インストール % go get github.com/Songmu/jfill/cmd/jfill もしくはGitHub Releasesからご利用ください。 使い方 % echo '{"name":"jfill"}' | jfill echo Hello {{name}}! Hello jfill! {{name}} の部分がプレースホルダーです。それがJSONの入力を元に置換され実行されています。 プレースホルダー内には以下のようにデフォルト値を指定することも可能です。 % echo '{}' | jfill echo Hello {{name:jfill}}! Hello jfill! {{name
`ghg` で GitHub Releasesから適切な実行ファイルを統一的に取得する | おそらくはそれさえも平凡な日々
https://github.com/Songmu/ghg tl;dr % ghg get motemen/ghq とかやれば、GitHub Releasesに上がった最新の実行ファイルを取得できる。 % $(ghg bin)/ghq とかで実行可能。 $(ghg bin) を $PATH に追加してもよい。 % ghg get Songmu/ghch@v0.0.1 とかでバージョン指定も可能。 本文 Goで書いたツールを提供する場合、クロスビルドしたものを GitHub Releasesに上げるのが定番となっています。 なぜ、 go get ではないのかというと go get の場合以下のような問題があるからです。 go get するにはGoの環境が必要 安定版ではなく、開発中の最新をビルドしてしまう ビルド情報などをバイナリに埋め込めない ただし、GitHub Releasesに上げる
Makefileを自己文書化する `make2help` | おそらくはそれさえも平凡な日々
近年「タスクランナー」という言葉をよく耳にするようになりました。近年のWeb開発では、開発環境のセットアップ、依存ライブラリの管理、テストの実行、開発サーバーの起動、ビルド、デプロイ等等、とにかく気にしないといけないことが多いため、そういったタスクを一元管理してくれるタスクランナーは便利なやつです。 新しくプロジェクトに参加した際に、タスクランナーを見れば何をやれば良いのかだいたい分かるようになっているのが理想的だと思っています。 タスクランナーという言葉は主にJS界隈で使われており、そもそもタスクランナーなのかビルドツールなのかという話はありますが、ここでは便宜上それらをひっくるめてタスクランナーと呼ぶことにします。 gulp も本質的にはビルドツールですし。 Goの開発においては、タスクランナーとして、古き良きビルドツールであるところの make が主に使われます。 make も使って
コミュ力が無いのはいつだって自分 | おそらくはそれさえも平凡な日々
突然何を言い出すのかという話ですが、対話相手にコミュニケーション能力を求める醜さについて書きたくなったので書きます。 僕はオタクだったしスクールカーストで言うと下の方を彷徨ってきた。地元でもいろいろあって浮いていた。新卒時の就活も散々だった。なので、コミュ力がないことは自覚しているし、だからこそ「コミュニケーション能力」という言葉には警戒心があります。 比較的マイノリティであったことが多かった経験上分かったのは、相手とコミュニケーションが取りづらいな、と思うときは、そもそもプロトコルが異なる、ということです。 これは、話している自然言語が違うようなものだと考えるとわかりやすい。例えば、自分が日本語しか話せず、相手がロシア語しか話せないのであれば、まともなコミュニケーションが成り立たないのは明らかです。そして、その時に、日本語が話せない相手にコミュ力がないと思うような人はいないでしょう。 そ
horensoというcronやコマンドラッパー用のツールを書いた | おそらくはそれさえも平凡な日々
リリースしました https://github.com/Songmu/horenso cron等、バッチジョブを走らせた場合にその結果通知やエラーレポートをどうするかは悩ましい問題です。ラッパースクリプトを統一的に噛ますのが常套手段ですが、そのためのツールとして、horenso というものをGoで作りました。報・連・相。その名の通り、実行ジョブの報告をつかさどってくれる君です。以下のようにして使います。 % horenso -r reporter.pl -- /path/to/job args... -- 以降に指定したコマンドが実行され、その結果がJSONとして標準入力経由でreporterに渡されます。reporterは実行可能なファイル、もしくはコマンドライン文字列であり、記述言語は任意です。reporterに渡されるJSONは以下の様なものです。 { "command": "per
ISUCON5で優勝してきました | おそらくはそれさえも平凡な日々
毎回素晴らしいイベントを主催されているLINE株式会社様、毎回ホスピタリティあふれる運営に尽力されている@941さん、出題の@tagomorisさん@kamipoさん、その他協賛企業や運営スタッフの皆様に感謝申し上げます。 ということで、ISUCON5に出場し、優勝してきました。 ISUCON1の優勝チームの再結成で @fujwiara, @sugyanと僕というメンバー構成です。4年前のISUCON1の時にチーム名を「fujiwara組にしよう」と強く言ったのは実は僕で、そのまま僕が代表者として申し込んだのですが、まさかここまでfujiwara組ブランド(?)が定着するとは思いませんでした。今年もfujiwaraさんの力が大きい勝利ですが、僕も大分貢献できたと思います。 ということで当日を振り返ります。 お題 外部APIを叩くネタで驚いた。可能性は考えていましたが、まさか来るとは思ってい
kamipo TRADITIONALでは防げないINSERT IGNOREという名の化け物 | おそらくはそれさえも平凡な日々
インスパイア元→kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物 タイトルが全てです。ピンときた方は読み進む必要はありません。 データがなかったらINSERTして欲しいけど既に入っている場合には何もして欲しくないみたいな処理をするときに、 INSERT IGNORE を使ってしまうことがありますが、 INSERT IGNORE はユニークキー制約違反だけじゃなくて、あらゆるエラーをIGNOREしてしまいます。つまりkamipo TRADITIONALすらIGNOREしてしまうのです。なので使わないほうが安全です。 様子です。 mysql> SET SESSION sql_mode='TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY'; Query OK, 0
ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
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を回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
Perlで一枚岩のスクリプトをテスタブルにする | おそらくはそれさえも平凡な日々
Perlで単一ファイルのスクリプトを書くと、すぐに配置して動かせるので重宝しますが、テストを書きづらいのが難点です。 ちゃんとpmファイルに分割して云々とかやると単一ファイルで動かなくなるし、かと言ってfatpackするのもちょっとした用途だったらやり過ぎだしめんどくさい。 ということで以下のように書いてはどうか。 if ($0 eq __FILE__) { main(); } sub main { ... } $0に実行ファイル名が入っているので、それがスクリプトファイル名と一致していたらmainの処理を実行する。pythonのif __name__ == '__main__':みたいな感じ。 このスクリプトをテストしたいときは、普通にテストスクリプトを書いてrequire 'main.pl';とかやれば、plファイルの中で定義されている関数とかが個別に呼び出せるのでそれをテストしてやれ
「エンジニアならリモートワークは簡単だ」と思ってはいけない | おそらくはそれさえも平凡な日々
「強いチームはオフィスを捨てる」を読んだ。「小さなチーム、大きな仕事」でもそうだったが、 とにかくやって見ろ。やれば分かるさ やらない理由がない というふうにガンガン煽っていくスタイルが小気味良い。 とは言えしっかりリモートワークのリスクについても述べられていて、リモートワークは難しいなと思わせる内容でもあった。特に、メンタル面を含めた健康リスクに関しては相当気を使わないといけないように感じた。 リモートワークを実現する上で大事なポイント 個人的に大事だと思ったのが以下の2点。 信頼 自由と規律 相手をとにかく信頼して、自由と裁量を与える。 信頼された側は信頼に応えようとする。ただ、自由を与えられた場合に上手くいかないことがある。そこで、決まりをお仕着せてしまうのではなくて、本人が規律を決めるようにする、それまで待つのが大事なのだろう、と感じた。 例えば、始業時間は会社が決めるのではなく、
Perlベストプラクティスのベストプラクティスじゃないやつをまとめてみた | おそらくはそれさえも平凡な日々
Perlベストプラクティス Perlベストプラクティス(略してPBP)という良い本があります。僕自身もPerlを学ぶ過程で非常にお世話になった本なのですが、以下の様なことが度々指摘されています。 bestって書いてあるけど「著者の」bestプラクティスなので偏りがあることも 「決して」とか「必ず」とかが多いけどあんま真に受けてはいけない この本を書くために書かれたであろうCPANモジュールとかがあって、しかも公開されてないものまである 致し方ないけど現在の状況にマッチしない古い情報もある なので、PBPの何がベストじゃないのかについてまとめてみることにした。前からやりたかったんだけど、思い立ってやった。 まとめてみたら、思っていたほどには項目が上がってこなかったので、やっぱPBPは良い本だなと改めて思いました。なので、このエントリーがこれからPBPを読む人の助けになれば良いなと思います。
YAPC::Asia Tokyo 2014 に「Perl」のトークを応募しています | おそらくはそれさえも平凡な日々
http://yapcasia.org/2014/talk/show/e10a7e62-01ba-11e4-b7e8-e4a96aeab6a4 今年のYAPCはPerl以外の言語に関するトークが多く応募されています。それ自体は多様性の観点から悪いことではないし、Perlを触っている側からしても、Perlと比較しながら他言語について知ることができるのは有意義だと感じています。 ただ、これはPerlを共通言語として他言語を理解しようという流れだと思います。つまり、Perlというコンテキストが共有されていることが前提になっているのです。 翻って、今年のYAPC::Asiaの様相を見てみると、実はそんな「コンテキスト」なんて共有されてないのではないかと感じられます。 今年のYAPCはPerlを使っていない人もたくさん来場されそうだし、それに、YAPCに来る大半のPerl初級者・中級者にとって、日々
Yokohama.pm #11 でライブコーディングしてきました | おそらくはそれさえも平凡な日々
発表資料 リポジトリ CPAN 動画 一時間強の長きにわたってお付き合いいただいいた皆様有難うございました。 今回ライブコーディングを引き受けた上で考えたのは以下の点。 いつもの開発っぽい雰囲気ですすめたい ちゃんとテストは書きたい 普段どのように開発しているかの雰囲気と、どういうタイミングでテストを書いているのかとかを、普段テストを書き慣れていない人にもできれば勘所が分かるようにしたいなーとか思っていました。 実際は結構内容を詰め込んでしまって駆け足になってしまったりとか、コンソールでの作業が長かったのでちょっとイメージを掴みづらい人も多かったかもしれないなと反省しています。 最初1時間もらった時は長すぎだと思っていたのですが、実際は全然足りませんでした。あれ以上長くやっても、見ている方もダレると思うので、もっとうまくまとめてできるようになりたい。 またやりたくなった。YAPC::Asi
勝手に添削: Test::mysqldとTeng::Schema::Dumperを使ってTengのSchemaクラスを自動生成する 〜Daiku編〜 | おそらくはそれさえも平凡な日々
勝手に添削: Test::mysqldとTeng::Schema::Dumperを使ってTengのSchemaクラスを自動生成する 〜Daiku編〜 http://masteries.papix.net/entry/2014-05-19-teng-schema-dumper.html Daikuをご利用いただきありがとうございます。上記のエントリーに関して以下の様な点が気になりました。 Daikufileを太らせるのは良くない せっかくのDSLなのにコードがゲロっと書かれてしまうのは残念な感じがする あくまでコード例なので、対策はしているのかも知れませんが、僕だったらこうするというのを書きます。 概要は以下のとおりです。 task用のパッケージをつくる Daikufileからはそれを利用する パッケージは以下のようになります。 package MyApp::CLI::DumpSchema;
退職とFA宣言のお知らせ | おそらくはそれさえも平凡な日々
所属的には5月いっぱいですが、5月12日(月)が最終出社で有給消化中です。理由はいろいろありますが、結婚や離婚がそうであるように、結局のところはタイミングの問題です。 一番大きな理由は家庭の都合です。家庭の都合というとネガティブに聞こえてしまうかも知れませんが、実際にはポジティブな挑戦です。 ただ、そのために会社を辞める必要は必ずしもなく、会社も引き止めの時にその事情を鑑みてバックアップしてくれる事は伝えてくれました。CTOに 「会社は社員の夢を実現する場所だと思っていて、だからといって全員が別の方向を向いているわけにもいかないので、誰かの夢に乗っかる形で事業を作っている。なので『こいつの夢に乗っかりたい』とか思わせたり、逆にそう思えるようなイイヤツを採用している。ただ、松木くんくらい会社に貢献してくれた人間だったら、自分の個人的な夢や目的のために会社を利用してくれて構わないし、むしろそう
MarkdownによるHTMLスライド作成のためにText::Markdown::Slidyというのを書いていてそれをCPANizeした | おそらくはそれさえも平凡な日々
MarkdownによるHTMLスライド作成のためにText::Markdown::Slidyというのを書いていてそれをCPANizeした https://metacpan.org/release/Text-Markdown-Slidy Markdownでアウトラインを書いてそれをSlideにするっていうのはよく聞くわけで、まあなんか色々そういうツールがあるわけですが、とりあえずMarkdownをスライド単位で分割するやつがあればいいんじゃないかと思っていて、実際そういうのを書いて個人的に使っていたのをCPANizeした。 h1、h2の見出し単位でMarkdownを分割して、変換したものを<div class="slide">...</div>で括るようにしているという具合。Markdownはh1とh2の表現方法が2つあるので、----と====とかで区切った方で切るようにしてます。 use
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
