nDiki : 実装

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

「がんばるぞい!」という意気込みで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 を実装している日記システムではもう不要な表現です。

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

今日のさえずり: 冬至なのでキーマカレー with いとこ煮

2017年12月22日

• 08:39 REGZA につないでいる外付け HDD が認識しないなと思ったら HDD のランプが光っていない。電源抜き差ししたら復活した。録画した番組が残っていて良かった。昨日のアイカツスターズ!は録画失敗してたけど。
• 13:44 木村俊也 @kimuras 氏! / “メルカリ、社会実装を目的とした研究開発組織 「mercari R4D(アールフォーディー)」を設立” http://bit.ly/2kEjb3t
• 21:29 冬至なのでキーマカレー with いとこ煮。
• 21:50 Xperia Z5 が暴走して強制終了を初めてやることになった。挿入口カバーの中の黄色いボタンを3秒押し覚えた。
• 22:14 今度は Mac が落ちた。
• 24:13 iconv -f UTF-8-MAC -t UTF-8 覚えた。

キーボードを Gboard Android アプリにしてみる

iPhone では使っていた(それほどは使い込んでいない) Gboard、 Android アプリでも日本語入力ができるようになっていたので試してみました。

グライド入力を今回使いこなせるようになろうとちょっと奮闘。慣れるには少しだけかかりそうです。なぞっていく時に自分の指でキーが見えなくなると挙動不審になってしまいます。多少違っても補正してくれると思うので、多少は大胆にやってもいいのかな?　残念ながら日本語はグライド入力できるようになっていないので、今まで通りフリックで入力することにします。

単語辞書登録機能が無いのが気になるところ。これから実装予定なのか、それとも学習に任せなさいということなのでしょうか。

それから日本語 12キー日本語入力で空白を入力した場合、いわゆる全角スペースになるのを半角スペースに変更するオプションがないのもちょっと不便。都度他のキーボードに切り替える必要があります。

などなど触ってみて、もう少し経ってからでいいやと思ってアンインストールしたのですが、やっぱり気になってまたインストールしてみちゃいました。

Google 日本語入力も最後の更新からもうすぐ1年になりますし、そろそろ移行して慣れていくのがいいのかなと。

この記事は Gboard + JotterPad で書きました。

ようやく nDiki に Twitterカードを実装した

書いた日記を Twitter でシェアした際に Twitter 上でグレーの地味なリンクサムネイル付きSummaryカードが出るのちょっと嫌だなぁと思ったので、そのうちと思っていた Twitterカードを対応をようやくすることにしました。

記事中の最初の画像を自動的にTwitterカードの画像に指定する案も考えたのですが、過去記事にも自動的に画像がつけられるという利点はあるものの、小さい画像など適切でないものが設定されてしまうこともあるかなと思ってそれはやめにしました。

なので記事中に [[ogpimage:URL]]と書いてあればそれを

 <meta name="twitter:image" content="URL">

とするようにしました。あとは twitter:card と twitter:site と twitter:title もヘッダに合わせて埋め込むようにして完成。

ついでに設定した画像 URL は Open Graph protocol (OGP) の og:image にも指定して Facebook でも認識できるようにしました。

日曜日の朝食にカルディコーヒーファームで買ったパナビの冷凍クロワッサンを焼いたら熱々サクサクで最高だった。また買っておきたい。 https://t.co/VqhUM04lY1

— Naney (@Naney) 2018年2月19日

これで日記に写真を載せるモチベーションもアップしそうです。

長かった Day One Sync 障害

3月に Premium にした Day One の同期 (Day One Sync) が5月7日 26:37 (日本時間) 頃から障害が発生し、同期ができなくなっていました。ようやくほぼ復旧したのが5月10日 23:08 ぐらい。3日弱同期ができない状態が続いていたことになります。

• http://stats.pingdom.com/myq3fep9ig12/1103582/2018/05

各デバイスでオフラインで使えるとはいえ、さすがにこれだけ長く同期できないとかなり不便でした。

May 2018 Day One Outage Postmortem によると

• ハードウェア障害が発生した。
• バックアップから復元し同期を再開したが、新しいユーザーに既存ユーザーと同じアカウント ID を割り当てるという状況が発生したので再度同期を停止した。
• 問題を修正したあと、朝を待ってからアクティブ化を再開した。

バックアップからの復元でシーケンシャル ID の採番が巻き戻ったとのことです。

日記サービスとして、他人に閲覧を許してしまうという致命的なインシデントをやらかしてしまいました。同期を iCloud / Dropbox から独自実装に変えた時に、実装・運用経験が少なさそうだから信用しきれないと思っていたので、やはりというところです。

ビジネス的・技術的判断だと思うので、要望の多い iCloud / Dropbox 同期に戻すことはないでしょうね。これから頑張って欲しいところです。

end-to-end encryption しているジャーナルは他人から閲覧されることはないはず主張しているのですが、 Android 版がまだ対応できていないので有効にできないので優先して対応してくれるといいなと思っております。

トピックとリンクによる構造が特徴のサービス Trickle

丸山@h13i32maru 氏が開発された Trickle というサービスがとても面白そうなので、サインアップして触ってみた。

• 気兼ねなくアクティビティを書き留められるTrickleというサービスをリリースしました - maru source

より気兼ねなくアクティビティを投稿できるためのトピックという構造

Trickle は Twitter を使っていて

「自分が主体でありたい、自分への影響をコントロールしたい。でも一人は寂しい」

という自分も「そうそう!」と共感できるインサイトから、トピックというアイデア取り入れて作られた(ソーシャルメディア)サービスだそう。トピックという構造を1つ入れることで投稿する側は書き分けられるし、読む側は特定のトピックだけサブスクライブすることで読み分けられるというお互いにハッピーという仕組みだ。

投稿単位であるアクティビティはオプショナルな「ノート」「画像」「リンク」を持つ。「いいね」と名付けたトピックに他のアクティビティへのリンク付きアクティビティを投稿することで、ユーザーは「いいね」機能を「実装」できてしまうわけだ。非常に面白い!

また書き留めるサービスという観点から、アクティビティを再編集したり別のトピックに移して整理しなおせるというのも理に適った仕様だと思う。

一個人として自分はトピックを使い分けられるだろか?

19年 Web 日記を書き 11年 Tweet している身として「日常生活の中で使える時間は有限。メディアやアカウントをテーマ別に使い分けてどれも充実させていくというのは時間的にもネタ的にもかなり大変である。そもそも興味のあるテーマもどんどん変わっていく。なのでテーマ別に分けない方が良い」だと自分自身については思っている。

それからソーシャルメディアの投稿を読むという立場で考えてみてると「何のテーマの投稿か?」以上に「誰の投稿か?」を自分は重視しているなと。やはりトピックではなく人をフォローしたいのだ。うん。

1日使っただけで Trickle のサービスやモデルの良否は語れるものではないので、以上あくまでもファーストインプレッションということで。

知っている人がどんどん使い始めたら、もっと便利さが感じられるのかもしれない。……あ、やはり人をフォローしたいんだな。

今日のさえずり: α-7 のボディのゴムがベトベトになってた(α7 ではない)

2019年01月30日

• 06:45 沿線 #SEL1670Z https://t.co/5uUCY1udYl
• 07:00 RT @Naney: のぞきあな。 PowerShot G9 X Mark II https://t.co/2qRIYhjxiy
• 08:37 α-7 のボディのゴムがベトベトになってた(α7 ではない)。
• 09:51 @tanadel はい。フィルムカメラの方の α-7 です。 @tanadel さんも使われてたんですね!
• 09:53 2019年1月30日 #朝の渋谷 通勤にはちょっとだけ遠回りだけれど好きなコース。 PowerShot G9 X Mark II https://t.co/jk2DRaSkh3
• 12:49 SNS での投稿を機械学習で分類するシステム構成とその運用フロー、成果の紹介! / “「機械学習による不適切コンテンツ検出」の実装と成果” https://link.medium.com/jZg990n9ST
• 12:53 岩瀬さん!
• 19:19 Google ドライブ、拡張子 md のファイルをテキストとしてプレビューできるようになってる(Google Chrome や Android アプリで確認)。中身はまだ検索対象にならないけど。
• 23:45 寄り添い合う。 #SEL1670Z https://t.co/Bd7Wybcpux
• 23:56 ダーリン・イン・ザ・フランキス第6話。

HTML ページ中の Graphviz 定義を自動的にクライアント側で SVG 変換し表示させる

昨日 HTML ページ中の mermaid 定義を自動的にクライアント側で SVG 変換し表示させるようにしたらいい感じなので、勢いで Graphviz の DOT 言語で書かれたグラフ定義も Viz.js を使って SVG 変換できるようにしてみた。

• https://github.com/mdaines/viz.js

mermaid では HTML ページ中の mermaid クラスをもつ要素を SVG 要素に変換するコードが入っているのだけれど Viz.js にはそれは無さそう。なので mermaid の実装を参考に dot クラスの要素を変換するようにしてみた。

 <div class="dot">
 digraph {
   graph [rankdir = LR];
   a -> b;
   a -> c;
 }
 </div>

と書いたら以下のように変換される。

mermaid よりずっとメジャーな Graphviz (互換)が使えるとさらに捗って嬉しいぞ。

Viz.js は mermaid よりさらに大きいので、さすがに全ページで読み込ませるのはまずい。なので Viz.js と mermaid についてそれぞれの定義があった場合のみ動的ロードするようにしておいた。

で、まずます動くようになったのでちょっとしたノートを置いておくスペース nNote だけでなく nDiki でも動くように設定しちゃった。Viz.js や mermaid が使えなくなった時のことを考えて記事の寿命が長い nDiki の方では多用はしないつもりではある。