半年ぐらい前に立ち上げた、カバレッジが低下するとライオンがコメントを書き残してくれる GitHub Webhook Service である twada-savannah ですが、本日 5/19 を持ちましてクローズさせていただきます。長年のご愛好ありがとうございました。
＿人人人人人人人＿ ＞ 使ってない ＜ ￣ＹＹＹＹＹＹＹ￣
使ってないし、Heroku の最近の価格のあれもあって残しててもしょうがないので削除しました。 なんかこう、いい感じのサービスの閉じ方みたいなのを調べてたんですが、気にせずまるっと消しました。お疲れ様でした。
みんな！ライオンが見てなくてもサバンナのこと考えてカバレッジ大事にしてこうな！！
今年でファイナルという YAPC::Asia Tokyo に初参加しようと思っており、せっかくなのでトークも応募してみました。
昔の「普通」から今の「普通」へ繋ぐ "安心の架け橋" - YAPC::Asia Tokyo 2015
トーク内容は ↑ にも書かれていますが、とりあえず Agile Japan 2015 サテライト＜沖縄＞ の発表内容 に、インフラ整備やチーム態勢についても加えた内容にしようと考えています。
仕事内容も一区切りついたころなので、自分たちがやってきたことをどこかでまとめておきたいというのがありました。 それならばイベント駆動でやってみよう、といったところです。
なので内容としてはただの「やってみました」系のふりかえりみたいなものなので、 聞く人によっては少し物足りないかもしれませんが、もし御興味があれば！
現在集まってるトーク、どれも面白そうなので採択されるかかなり怪しいですが、もし採択されてもされなくても、当日はビッグサイトでお会いしましょう！
Release Version 1.3.0 · jnicklas/turnip
リリースノートのとおり、1.2.4 との大きな差は、Ruby 1.9 以下のサポートを排除したことです。
現時点ですぐ Ruby 1.9.3 で動かないというわけではありませんが、 今後あらたにコードを追加していく時は Ruby 2.0.0 以上の機能を使うことに躊躇いがなくなる、ということです。
ちなみに、Ruby 1.9.2 は既に動かないと思います。
Agile Japan 2015 サテライト＜沖縄＞ - Java Küche | Doorkeeper
発表した話は後ろで書きます。
2日前に行なわれた 本会場 での基調講演の録画動画を見ました。
Janet さんの「アジャイル・テスティング」というタイトルからしてテスト技法みたいなイメージがあったけど、 どちらかというと「テストを通してチーム/メンバー間でのコミュニケーションをどうすべきか」みたいな話題でした。 特にテストのタイミングになると「質問」というフェーズから様々な情報の共有が行われるので そこでしっかりしていこう、みたいな話だったと思います。多分。なるほどなー。
横塚さんは、正直なところ発表を見る前は
「東京海上日動システムズ株式会社 顧問」
って肩書だし、すごい堅い上に「なんちゃってアジャイル」について語るのでは
みたいなイメージだったのですが、そんなことはなくて、ものすごい(いい意味で)Agile おじさんでした。 中期経営計画の話題になったときは、諸事情により面白かったです。
ここからは沖縄会場のセッション。まずは高江洲さん。
みたいな話題を、お馴染アジャイルマニフェストを交えて話してくれました。
途中には「残念なアジャイル(いわゆるあるある話)」の紹介もしてくれました。 ここで印象に残っているのは、懇親会でも同じ話題が聞こえてきたのですが
「残念なアジャイル」みたいなことが起きて ・やっぱりアジャイルは駄目だった ・おれたちにはできないものなんだ っていってそこで諦めてしまうのを良くみるが、そこでなんで諦めるのか。 「うまくいかなかった」「できなかった」ってタイミングで「気づき」を得られているだろ。 なんで駄目だったかということを『ふりかえり』して、それを次に生かしていけばいいのでは?
みたいな話をしていて、なるほど「気づき」という捉え方か、といろいろ考えさせられました。
永和の水谷さんによる、最近あった開発でのお話。
当初ウォーターフォールのつもりだったが、お客様からの 「要件を変更することを良しとする」という要件 を提示されて、いろいろあってアジャイル「っぽく」するようにした
みたいな話「うぉお」ってなりましたね。ある意味闇っぽい。 ほかにもいろいろ「あー」「あるあるだわー」みたいな生々しい話聞けておもしろかったです。
琉大の学生さんによるアジャイル開発してみました報告。
私が在学中にはこういう制度(イベント)が無かったので、結構羨しい。 プロダクトオーナーとのやりとりが、交通費の都合もあって週一で SKype(だっけ?) によるビデオチャットだけで そこが結構大変だった、というのはまあなるほどなーという。
その間はメールとかでやりとりしていたんだろうか。質問するの忘れてたな。
最後のセッション、「テクニカルセッション」という枠で発表してもらえないかーという話があったので、 ここ最近、ようやく安定してきた Docker を使った E2E テスト環境の話をしました。
今回みたいに真面目な話題で社外で発表するのっておそらく大学の時以来(学会とか修論発表)だったのでかなり緊張していました。 ちなみに真面目じゃない発表はこちらです → http://d.hatena.ne.jp/gongoZ/20110829/1314576794
30分という枠だったので、単に「Docker で動かしてました」だと時間が足りないだろうなということと、 あとなんでこういう構成にしたのかっていう背景が無いとどうしても突然感が拭えなかったので プロローグという形で、CI に取り組み始めた辺りから話すことにしました。 おかげで予想以上にスライド増えてしまい、高速に話してしまうし(そして噛み噛みだった)、質疑応答時間を取れないぐらいギリギリだったので そこが残念だったなーというところです。もし質問等ありましたらいつでも Twitter にメンションでもいいしメールでもいいので、よろしくお願い致します。
今回の沖縄サテライトのテーマが「現状確認会」ということで、現場の声みたいなものが聞けてとてもよかったです。
今回の私の発表、現チームメンバーが見たら「かなり端折ってるな」という印象があると思います。
内容としては、ここ数年で取り組んできたうちの 30% ぐらいなので、 できれば別の機会にちゃんとまとめて発表したいです。余談ですが YAPC Asia 2015 いきたいです。
View Logic と Markup の密結合、下の記事を読んで試してみたかった(React の記事だけど)
ところで、React.jsではComponentとして、マークアップとViewのロジックをcreateClassの中に書いていくのですが、他のフレームワークのようにマークアップはHTMLやmustacheで書いてViewのロジックをJSで書くみたいに分かれてなくて気持ち悪い！という人もいるのではないでしょうか？ それに対して、React.jsの開発者であるPete Huntはそれは「関心の分離(Separation of concerns)」ではなくて「技術の分離(Separation of technologies)」だとしていて、マークアップとViewのロジックは密であるべきとしています。 reactjs - React.jsのComponentについて - Qiita
そんなこんなで .vue ファイルを書くのは良いのですが、問題は私が Emacs ユーザだということ。
vueify 、エディタの mode が無いことだけが不満。作ればいいんだけど。ちなみに SublimeText にはある
— Wataru MIYAGUNI (@gongoZ) 2015, 4月 1vueify の特性上、いろんな言語が入り乱れることになるため、ここは昔懐しい mmm-mode を使ってみました。
.vue 内に書く <template> や <script>、<style> で、lang=xxx を使わない場合は、
mmm-mode を使うまでもなく web-mode で何の問題もありません。
<script> や <style> の中は勝手に js, css と判断してくれる<template> に関しては通常のHTMLタグ同様に扱うので問題無しcl-loop あたり使ったらもっと綺麗に書けるのかもしれないが、ひとまずこれでこいつを eval しておくと、こんな感じになります。
とりあえずこれで大分楽になった。
GitHub を見ると mmm-mode がまだ時々開発が行われているのと、最古のファイルが 15 years ago とか書いててすごい歴史っぽい。
てぃーだ大感謝祭2015 ～ ありがとう10年、これからもずっと ～
休日は いつも外食 して、すぐ家に帰って寝るという生活をしているので
たまには賑やかなイベントにでも参加しようと考えました。
場所は北谷にある うみんちゅワーフ というところ。
最初場所がわからずに、会場から 1.3km ほど離れたイオン北谷店に車止めたりしました。足痛い。
会場についた私は、早速イベントを楽しむことにしました。
まずは 梅しん の唐揚げ。塩こしょうor秘伝タレが選べたので、私はタレをチョイス。
美味しい。
続きましては カレー倶楽部ルウ のチキン南蛮。
お店の人が「他の店の唐揚げとはちょっと違うやわらかさを是非!!」と叫んでるだけあって、確かにおいしい。
唐揚げばっかりで胸焼けする人にはちょっとした味や食感の変化で休憩になりそう。
3店目は 舷喜屋(げんきや) の唐揚げ。普通。美味しい。
4店目はちょっと変化させて りょうたの手羽先 の手羽先。美味しい。
最後は 吉吾 のからあげ。しょうゆダレ。美味しい。
ついつい店の前にあった大量のかあらげを撮影。良い。
※ 他3店あったのですが、うち2店(からあげカリッジュ、ぶんごや)は沖縄にあるというのと、「瀬戸田レモンガラ塩唐揚」というのがお勧めという とり将 は、すでに売り切れていたので断念(普通の唐揚げはあったが)
そんなわけで満喫しました。てぃーだ大感謝祭。楽しかった！！
唐揚げどこが美味しかった、みたいなランク付けは苦手なので全部美味しかったってことにしてください。
[2015年03月10日 17時 追記]
以前は qb という名前でしたが、多数の方から「きゅーべーだと思った」という感想が得られたので Rename
一杯 tail していこうっていう精神を持った九尾的な意味です。 あと最近 NARUTO 読み返したのもあります。
こんな感じでインストールできるはず
$ go get github.com/gongo/9t/cmd/9t
そんでもって、更新され続けているファイルを幾つか指定して実行
$ 9t d.log tamura-yukari.log random.log
複数ファイルを tailf しつつ、それぞれのファイルを表す識別子か何か(ファイル名でもいいけど)を prefix にして足れながす、heroku log みたいなやつ出すいい感じのやりかたあるかな
— Wataru MIYAGUNI (@gongoZ) December 10, 2014tail -f で複数ファイル渡せはするんだけど、追記される度にセクション区切り入って、見えないことはないけどなーっていう感じ
— Wataru MIYAGUNI (@gongoZ) December 10, 2014BSD な tail だと -qf とかで似た感じになるんですが、今度はどのファイルから出力されたかわからない感じになるので断念。
こういうのも見つけて、しばらくはこれ使ってました。
複数ファイルを一気にTail - 自分の仕事を憎むには人生は余りにも短い
最長のファイル名に併せて揃えてるのですが、その指定の仕方をこんな感じ 9t.go#L26 でやってます。
fmt.Printf("%*s: %s\n", max, filename, text)
https://golang.org/pkg/fmt/ の中で * がどうのこうのって書かれてるのみて雰囲気で書いたらそれっぽくなった。便利。
(使い方間違ってるとかあれば連絡お願いします。)
THE LAST -NARUTO THE MOVIE- の予告の空耳で「NARUTO THE MOVIE」が「ナルトじゃムーリー」に聞こえました。
