nDiki : 実装

YAPC::Asia Tokyo 2014 1日目

昨日の前夜祭から一夜明けての YAPC::Asia Tokyo 2014 1日目。昨年に引き続き慶應義塾大学 日吉キャンパス開催なのでなんとなく勝手がわかってちょっと気楽。去年はなんか多目的教室に入りそびれたので、今回は早めに移動とかしてそちらも回ってみた。

電源の取れる藤原洋記念ホールがなんだかんだいって居心地が良かったりはするんだけれどね。

今日は Go 使ってみようかなと思ったのが収穫。会場でとりあえず golang Debian パッケージをインストールして hello.go ぐらいはしてみた。goroutine 以外は思っていたより普通の言語……なのかな?

お昼は @syamata 氏と @bornite 氏と日吉天神でラーメン。去年と同じ店だった。と思ったら去年は同じ場所で「らーめん 元山亭」という店だった。日吉天神は去年10月7日オープンらしい。 @syamata 氏が最近 Facebook で Yelp のフィード流しているのでモチベーションとか聞いてみたら「アーリーアダプターとして、まだデータにないお店やレビューを登録していくのが楽しい」とのこと。あーわかる。

「インフラエンジニア(狭義)は死んだ」 Satoshi Suzuki @studio3104 氏 (多目的教室2)

インフラエンジニアのメンタル的な面に視点を当てたトーク。

• 物理的なハードウェアにかかわる事は減ってきている。
• そのかわりコードを書ける必要が高まっている。ただしコードを書けばバグも発生するのでコードを書かない選択肢も常に考える。
• あとリーダブルコード的な話とか。

「Go For Perl Mongers」 Daisuke Maki @lestrrat 氏 (多目的教室2)

Go にいりては Go に従え。

• いわゆる例外処理無い。
• いわゆるオブジェクト指向的でもない。
• fmt は ふむと? / ふんと?。
• ハードタブ。

Go 使ってみたくなった。

「お待たせしました。Perl で BDD を簡単に実践する最高にクールなフレームワークができました」 Tokuhiro Matsuno @tokuhirom 氏 (多目的教室2)

Perl のテストフレームワーク回りの話し。

• 2 の開発中止あるある。

テストフレームワーク関連はできるだけ枯れて安定したものがいいなと思う(テストフレームワークの不具合とか仕様変更まで追いかけ続けなくていいように)。便利さとのトレードオフ。

「Perl::Lint - Yet Another Perl Source Code Linter」Taiki Kawakami @moznion 氏 (多目的教室2)

わりに泥臭い世界なのではと思ったら、やはり泥臭い感じだった(実装的に)。

C スタイル for だって goto だって適材適所なので使った方が良い場面だってあるので、そういうのはきちんと説明できるといいんじゃないかと思う(lint がそこまで判別できたら凄いけど)。

「One layer down below.」 Kang-min Liu @gugod 氏 (藤原洋記念ホール)

フルフルの汎用モジュール使わないで、軽くて速い機能を削った専用モジュールを作って使うのもいいよという話。

• Hijk:: ElasticSearch など用に特化した軽量 HTTP クライアント Perl モジュール。

「いろんな言語を適材適所で使おう」 Kentaro Kuribayashi @kentaro 氏 (藤原洋記念ホール)

経営的な視点まで入った技術選択の考え方の概論トーク。

• 継続性を見越した技術選択
• microservices

「WHERE 狙いのキー、ORDER BY 狙いのキー」 @yoku0825 氏 (藤原洋記念ホール)

MySQL のインデックスを Perl データ構造で擬似的に説明。

フォントかわいいけどコード部分とかちょっと見辛かった。

「Mojolicious を使った web アプリケーション開発 実践編」 Yoshimitsu Torii @torii704 氏 (藤原洋記念ホール)

ビギナー向け。

「Java For Perl Mongers」 Kazuhiro Osawa @Yappo 氏 (藤原洋記念ホール)

Java = Perl。

Lightning Talks Day 1 (藤原洋記念ホール) スタート!

ハッシュタグ #yapcramen

(画像は http://yapcasia.org/2014/ より)

今日のさえずり: 長呂儀探すのに苦戦した。最後の1パックだった。

2014年12月31日

• 11:34 大晦日の買い出しへゴー。暖かく穏やか。
• 12:37 長呂儀探すのに苦戦した。最後の1パックだった。
• 13:06 帰宅。買い出し完了!
• 14:34 買い忘れたしいたけ買った。
• 15:20 この間 iPad 2 にインストールしたアプリ「NHK紅白」を初めて起動してみた。トップ画面がただの @nhk_kouhaku Tweet 表示なのでガッカリした。けど、実装的には確かに楽でいいな。 #NHK紅白
• 15:38 iPad 2 + Google Chrome + TweetDeck した。 iPad で Twitter をマルチカラムかつストリーム表示できるアプリってあるのかな?
• 16:13 “『ダメな統計学』冊子PDFの公開｜Colorless Green Ideas” http://bit.ly/1D54UxV
• 16:13 平和。 / “年越しは「うどん」で 香川　NHKニュース” http://bit.ly/1D54WWL
• 20:32 妖怪紅白歌合戦の方を観たい。
• 20:47 紅に投票したった。
• 20:48 @yasa_gurek0 あっちの世界の方がいろいろ楽しそうですよねー。
• 20:58 「NHK紅白」アプリの紅白LIVE、しっかり選別された #NHK紅白 Tweet が流れている。
• 20:59 っていうか #NHK紅白 ハッシュタグの流速すごすぎてストリームだと何がなんだかわからなかった。
• 22:19 ポイまたやりたくなった。 #NHK紅白
• 23:19 眠気対策にウノやってた。
• 23:32 30分切ったので ssh -f -N -D したりしつつ裸待機。
• 23:37 紅投票。
• 23:50 揺れ。
• 24:04 Q4M よ、がんばれ。
• 24:53 あけましておめでとうございます(キューのピークが過ぎた)。
• 25:38 寝ます。

Android の Gmail アプリからドコモメールを送信する

最近 Nexus 6 とか欲しいなと思っている。もし今のNTTドコモの契約で使うとして、SIM カードを移してもキャリアメールはそれを必要とするネットサービス用に念のため使えるようにしておきたいなということで、ドコモメール(docomo mail)の設定まわりをしてみた。

キャリアメールはもう大して使っていないのでついこの間までspモードメール(sp-mode mail)のままだったのだけれど、去年12月の Xperia GX をリセットしたのを機にデバイス側はドコモメールに変わっている。

ドコモメールだと SMTP・IMAP で送受信できるとのことなので Android の Gmail アプリにアカウント追加をすることにした。

最初サーバ設定がうまくできなくてなんだろうと思ったら、事前に「ドコモメールのdocomo ID利用設定」が必要だったというオチだった。こちらをドコモメールアプリから設定しあらためて Gmail アプリでアカウント設定。

• ユーザー名: docomo ID
• パスワード: docomo ID のパスワード
• メールアドレス: ドコモメールアドレス (@docomo.ne.jp)
• IMAP サーバ: imap.spmode.ne.jp:993 (SSL/TLS)
• SMTP サーバ: smtp.spmode.ne.jp:465 (SSL/TLS、要ログイン)

これで送信できるようになった。ただ受信については Gmail アプリではメールが一覧に出ず閲覧することもできず。

Web で見た限り既知の状態みたい。K-9 Mail 等では読むこともできるらしいので、IMAP の実装の違いとかそういうあたりなのかな。急ぎではないのでしばらく様子見にしておくことにする。

---

[ Android アプリレビュー ]

今日のさえずり: チャックおろしたら「地震です!」とかやめて欲しい

2015年05月25日

• 13:07 Twitter の Facebook Connect を切った。
• 14:30 チャックおろしたら「地震です!」とかやめて欲しい。
• 19:16 Go での Prolog 実装ありそうだなと思ったらやっぱりあった。
• 20:08 セブン-イレブンにあった冷凍済みのドリンク、結局アクエリアスだった。
• 23:06 4カ月ほぼ全てアンフォロー状態にしていた Facebook を元に戻した。なにこのざわつき。
• 23:08 片っ端から Facebook でフォローし直すと「『購読するフィードは厳選しましょう』一度に多くのユーザーのフィードを購読すると、ニュースフィードに大量の情報が届くようになる可能性があります。フィード購読について詳しくはこちら。」というのが毎回出るようになることがわかった。
• 23:15 なんか充実したのがいっぱい流れてきた。これで良かったのだろうか。

メルカリ主催の Drink Meetup with Mercari #7 で CS 担当者交流をしてきた

株式会社メルカリ CS グループマネージャーの山田和弘氏の話がうかがえると聞いて「メルカリを支える“カスタマーサポート”について話をしましょう!」がテーマのメルカリ主催のミートアップイベントに行ってきた。六本木ヒルズ森タワー18Fにある株式会社メルカリが会場。

• http://mercari.connpass.com/event/15701/

コンタクトセンター/サポートセンター業界全体というと「比較的年齢層が高くスーツな人たち」という印象があるのだけれど、今回のミートアップはインターネットサービスの若くエネルギッシュな CS 関係者が集っていて良い交流ができたのでマジ参加して良かった。ちなみに一番エネルギッシュだったのはメルカリの HR の方。パワフル!

サポートスタッフの活躍と向上

山田氏は株式会社ミクシィでユーザーサポート・健全化推進についていろいろ教えていただいた先輩で、「よーし、やるぞー。」「やろう。」というのが口癖の前向きな姿勢と育成方針を尊敬している方である。

氏がカスタマーサポートスタッフが活躍し地位向上していくことに強い意識を持たれていた点について感銘を受けていたのだけれど、メルカリでもその心は変わらず、ユーザーに直接向き合うスタッフを大切にし業務を進めているという話を伺えてブレてなくて素晴らしいなとあらためて思った。

ユーザーの声(VOC)をサービスに活かしていくビジネスプロセス

カスタマーサポートはお問い合わせへの回答などを通じて直接的に問題解決を提供するとともに、ユーザーの声をサービスに活かしていくというのが大きな役目である。この VOC 活用については各参加者にとって大きな感心事で、活発に質疑・意見交換がされていた。

メルカリでは、サポートスタッフの日報による共有とそれに対する経営陣からのも含むレスポンスがあるとともに、それらを元にした CS 担当プロデューサーによる改善検討が行われているとのことであった。リジェクトされる事が多々あるとサポートスタッフの共有・提案意欲も下がってしまうのではという参加者の問いに、山田氏は「リジェクト理由を含めてきちんと伝えることが大切」と述べた。

ちなみに我々のところでは専属の企画メンバによる VOC からの改善検討と立案を行いプロダクト部門への提案を行うようにしている。実際のところプロダクト部門の優先度の兼ね合いで採用されない場合もあるが CS 開発という専属チームでかわって実装してしまうこともできるという体制を構築し推進している。

専属まではいかないけれども CS 関連開発を中心に担当しているというエンジニアの方ともお話させていただくことができたのも今回は嬉しかった。CS 関連開発をやっている人って多くないからねぇ。

メルカリオフィス

六本木ヒルズの現オフィスには3月に移転してきたばかりということで、真新しく木の匂いの残る素敵なオフィスだった。ミートアップの終盤に執務スペース見学までさせていただけるなど、このあたりのフランクさはすごい羨ましい社風だなと思っていた。オフィスの窓から見える東京タワーが大きく感じられた。

なおメルカリでは「お仲間」を募集しているとのことです。

なお私のところでも今日現在 CS 関連に興味がある企画者・エンジニアを探しています!

職務経歴書で「製造」と言っちゃうソフトウェア開発者

職務経歴書などで「プログラミング/コーディング/実装」あたりのことを「製造」と書かれているのをみると、悪いとは言わないけれど「あっ、違う」と感じる。

---

[ opinion ]

今日のさえずり: 「直接お話ししたことはありませんが、 Twitter では常々拝見しておりました。」

2016年08月31日

• 09:11 Google Keep はあとは undo (か編集履歴)が実装されれば完璧。
• 13:19 Twitter アカウントのアイコンをウニに変えたひと、一瞬「誰?」ってなった。ウニ。
• 13:24 月見バーガーです。 (@ マクドナルド 渋谷新南口店 in 渋谷区, 東京都) https://www.swarmapp.com/c/96otorxkhnw
• 13:35 見える範囲で女の人3人がマック内で Pokémon GO やってる。
• 15:33 「直接お話ししたことはありませんが、 Twitter では常々拝見しておりました。」
• 20:20 夏が終わる!
• 20:32 Blog を書くまでがインターンシップです。
• 20:55 Kindle のハイライト色を三色方式のどの色に割り当てるか迷っている。オレンジ → 緑かなー。
• 21:27 「お詫びと訂正」ページにコミカルな広告の画像がぷるぷる動いているの。
• 23:00 “戦場の移り変わりについていけない人は死ぬ　「切込隊長」から「山本一郎」へ【発信の原点】(Yahoo!ニュース個人 アプリ特別企画) - 個人 - Yahoo!ニュース” http://bit.ly/2bC3iGV

インターンシップがんばったぞい!

「がんばるぞい!」という意気込みで9月1日から配属されたインターンの方が就労型インターンシップの最終日を迎えました。1カ月間お疲れさまでした。

今までで一番幅広くトライ

私のいるチームでインターンに来ていただくようになって4年目ですが、今年は一番幅広く様々な業務に取り組んでもらうことになりました。「仕様決め」「デザイン担当と調整」「マークアップコードの依頼と受け取り」「実装」「コードレビューアとのやりとり」「QA 項目の作成と依頼」「ユーザーサポートへのリリース共有」「リリース」と、様々な担当の人とやりとりしながらリリースしていただいたのは今年が初めてです。体調不良をかかえつつ大変だったかと思いますがやり遂げられました。素晴らしいです。実際のサービス開発の1つのケースとして良い経験となったならチームとしても嬉しいです。

思い出

• 2日目に迷子。
• 6日目に救急。
• 5回一緒にランチだったけれど結局同席だったのは2回。

Blog を書くまでがインターンシップ

今回いろいろ経験したことについて、ぜひふりかえって1カ月間で感じたこと・思ったことをまとめていただければと思います。頭の中で考えるだけではなく手を動かして書き出すことで自分の中での理解を深められるでしょう。

Blog を書くまでがインターンシップです!

• チューターからのメッセージ
  • チューターの終え方 (要ログイン)

第8回 エッセンシャル スクラムを読む会

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会8回目。今日は第8章 技術的負債。

スクラムのコアコンセプトの部でわざわざ技術的負債について1章割くというのがふーんという印象でした。ベロシティに大きな影響を与えるので避けて通れないというところでしょうか。あるいはウォーターフォールと違って返済していくチャンスがあるからでしょうか。

技術的負債

技術的負債。当初は

意図的に手抜きをしてすばやく仕上げるという意味

技術的負債を抱えるということは、今後の作業のための時間を担保にした融資を受けるということだ。

からきていて、後々返済する必要が出てくる代わりに先に経済的効果を得ているものを指しています。単純にまずい設計や実装のことまで技術的負債と世間で呼ばれていることがありますが、個人的には違和感を感じています。本書ではナイーブな技術的負債と呼んでいますね。

技術的負債ですが

大切なのは、どんなプロダクトであっても技術的負債からは逃れられないということだ。私はここで、技術的負債をなくすよう努力しましょうなどと言うつもりはない。仮にそんなことができたとしても、負債をゼロにするためには大変なコストがかかるだろう。

ということで必ずしも罪悪感を感じる必要のあるものではないことがわかります。きちんと把握してコントロールしていくことが重要です。

ただ

技術的負債の経済的意味についての適切な認識

については、正直なところなかなか正確に見積もれることがない気がします。技術的負債を生むという選択をした時にそこまで見積もる余裕がない、あるいはあっても先のことなので詳細化しきれない、そういうケースが多いのではないかと。

技術者レベルでの技術的負債の可視化

• 方法1: 障害管理システムに記録する
• 方法2: 技術的負債を表すプロダクトバックログアイテムを作る
• 方法3: 技術的負債バックログを作る

サイズが大きいものは方法2の方が時間をとって返済しやすく、サイズが小さいものは方法3の方が「フィーチャーよりも優先度が低くていつまでも返済されないということがない」ので返済しやすいようです。

技術的負債の返済

• 作業中に偶発的な技術的負債が見つかれば対応できるところまで対応する。
• スプリントごとに既知の技術的負債のいくつかを返済対象として対応する。価値をもたらすフィーチャーの開発と関連するものを一緒に進めることで金利の高いものから勧められる。

あたりがポイント。

「技術的負債返済スプリント」だとか「リファクタリングスプリント」などといった言葉がチーム内で出てきたら、危険信号だ。

ということで、技術的返済のみに注力するのは価値を提供し続けるというのに反するで望ましくないとありました。

また実際のところ利息がほとんど発生しない技術的負債もあるので、きちんと見極める必要がありますね。

• エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

WikiName の特別扱いをついに停止

この日記の日記システム(DiKicker)は WikiEngine からの派生で作られた生い立ちをもっていて、現時点でも WikiName を特別扱いし自動的にそのキーワードへのリンクになるようになっていました。今日はコードを修正してその特別扱いをやめることにしました。

実装ですがまず WikiName を先に抽出し、そのあとに他のキーワードを AutomaticLink するようになっていました。このため例えば MacBook Pro という文字列はまず MacBook という WikiName として抽出されてしまうため MacBook Pro という文字列で自動的にリンクさせることができていませんでした(それだと困るので明示的に BracketName で書いていました)。

WikiName は WikiWiki というコンセプト的に良いものでしたが AutomaticLink を実装している日記システムではもう不要な表現です。

ようやく重い腰を上げて今回のコード修正となりました(いじったのは数行なのですけれども)。