この4月にUbie入社4年目を迎えました。入社当初5, 6人しかいなかったメンバーも今では100人を超えました。プロダクトも成長し、顧客も増えました。入社から3年間で状況は様変わりしましたが、Ubie Discovery*1で働く本質的な楽しさは変わらないどころか、なんなら今が一番楽しいと思っています。本エントリでは、この「楽しい」に集中できる理由と、そうしておけば万事良しの理由について話します。チームでのプロダクト開発が最高に楽しい仕事には様々な楽しさがありますが、中でもチームでのプロダクト開発を楽しく感じています。チームで不確実性に飛び込み、学びを得て、目標へ全速力で走っていく、そのプロセスがとても刺激的です。今年の1月〜3月に僕がいたチームは、AI問診ユビーの医師が閲覧・操作するための画面における医師への情報提供に関する施策を行うチームでした。各分野のプロフェッショナルが集う少数精鋭のスクラムチームで、OKRを達成すべく仮説を立て、インタビューをして、アイデアを出して、議論して、実装して提供、そしてフィードバックを得て、次の改善サイクルを回す。先日公開された僕のインタビュー記事でも言及しているんですが、そういう営みを通じてHowよりもWhyやWhatに目が向くようになりました。Ubieに入社するまでは、どのプログラミング言語をどう使うか、フレームワークには何を採用して、いかにエレガントな設計にするか、という技術すなわちHowに対する興味関心が大きかったと自認しています。なぜ、技術を駆使するという部分以外にも興味を持ったのか、自分なりに分析してみました。一言で言えば自分の成長を実感できるから、だと思います。自己成長なんてありふれた表現ですが、ゲームが楽しいのと同じです。プログラミングもそうです。やってみて、でも上手くいかなくて、考える。考えた方法を試してみる、上手くいった！この達成感、充実感。プロダクト開発全体でこの感覚を味わえるということに気付けた、と言ったところです。とはいえ、僕はソフトウェア開発のプロとしての役割があるわけだし、それを抜きにしても個人的なWill, Canは「爆速開発によるPDCAサイクルの最速化」なので、当然ながらHowも重要です。爆速開発は社内でも定評があるんですが、酷いコードを書くことで近道しているというわけではもちろんありません。原則としてセオリーに沿ったコードを書いて、状況に応じて実装上・設計上の妥協をします。この妥協の方法や判断は明確に上達したと自分で思います。その甲斐があって、四半期末に行われるValue Award*2で、Launch & Launch賞（通称、ロンロン賞）をチームとして2度受賞しました！ロンロン賞は、慎重すぎる調査や議論よりも、行動を起こし、失敗による学びも含む成果を素早く得ることを重視した個人・チームに贈られる賞です。プロダクト開発に集中できる理由ロンロンなプロダクト開発に全力投球できる理由は、Ubieメンバーが極めて優秀であることと、組織の設計・運営が上手く機能しているからだと考えます。組織開発にまつわる施策を、ここでいくつか簡単に紹介したいと思います。ホラクラシー組織従来のヒエラルキー型組織のようなトップダウンの指令系統ではなく、上位（抽象）サークルから下位（具象）サークルへと権限を委譲することで、自律・分散した組織を目指すフレームワークです。目まぐるしく変化する状況に素早く対応するため、Ubie Discoveryには最適な体制です。1年前はPoCとして少数のチームのみで運営していましたが、今ではUbie Discovery全体で運営しています。透明化プロジェクトメンバーやチームが急増する中で自律・分散した組織を機能させるためには情報の透明性が重要です。Ubie Discoveryでは「透明化プロジェクト」が継続的に活動しており、情報の公開・整理・配信の最適な方法を模索し続けています。PMF工場Product Market Fit（PMF）を科学する。すなわち、再現性を持ってこれを実現可能なものにする。そのようなスキルを全メンバーに、というプロジェクトを面白がって「PMF工場」と社内で呼んで、実行しています。実際問題、全員がプロダクトオーナーとしてPMFを、というよりもそのエッセンスを修得して誰もが事業を大きく前進させるPBI（プロダクトバックログアイテム）を作れるくらいにはなろうというものです。Ubie Discoveryはプロダクトの0→1, 1→5, 5→10を担う組織であるため、必要となるスキルです。ある種の社内研修と言えましょう。評価なし・業績連動昇給Ubie Discoveryでは人事評価がなく、また当然これによる昇給はありません。評価をなくすことで、物理的にも精神的にも事業にフォーカスすることができます。また、個別最適を防ぎます。これは僕の意見なんですが、個別最適は社内政治につながり、社内政治は透明性や当事者意識、率直なコミュニケーションを阻み、疑心暗鬼に陥り、プロダクト開発に集中できない状況を生み出します。十分すぎるストックオプションと、業績連動による全員昇給という仕組み、そして人材要件Ubienessの下、採用に妥協しない姿勢が「評価なし」という制度を支えています。詳細は「人事評価は不毛？〜評価なしで100名の壁を超えたUbieの事例〜」をご覧ください。人材要件 Ubieness以前からあった人材要件を見直し、新たに打ち立てた6つの人材要件を「Ubieness（ユビネス）」と名付けて運用しています。Ubie DiscoveryにおけるDev人材なら職種問わず適用される要件です。ゼロベース思考今まで身につけた常識や慣習をUnlearnでき、常にゼロから最適解を組み立てられる思考の柔軟性があるラーニングアニマル常にLearnしつづける情熱を持ち課題解決への最善のアプローチのために活かすことができる突破力事業価値の高い目標に対して、実行可能な課題を設計し、方法論を問わず実行しきる力全社への当事者意識全社観点でやるべき重要なことを発見し、組織として最速で、最高の結果に到達する方法を考える論理性バイアスに飲まれず再現性のある論理的な思考とコミュニケーションをする率直かつ建設的なコミュニケーション力社内のあらゆる場面において、自分の考えを率直に伝え、物事を前に進めるキャリア戦略？そんなもの要らないプロダクト開発に集中できる理由がもう一つあります。それはキャリア戦略に悩まされることがないことです。今までは自分のキャリアをどう築くか不安になることが少なくなく、自分のキャリアにプラスになるようなムーブを意識したりして消耗していました。少し昔話をすると僕は大学では情報工学を学んで、新卒でSIerに入社しました。SIerは、いわゆるWeb系企業と比べると歴史があり、明確なキャリアパスがあります。システムエンジニアをやったらプロジェクトマネジャーをやって、そして課長、部長と。出世競争のようなものはあるのでしょうが、道が見えているのであとは走るだけというような安心感がありました。僕はそのSIerを1年半で辞めて、Web系企業に入りました。これは僕の中では大きな決断でした。25歳にして一度目の転職、そして歴史が浅く、明確なキャリアパスやロールモデルが存在しないWeb系企業。よく「この先生きのこるには」とか「生存戦略」とか言って、ON/OFF問わず勉強すべしとか、どの技術にベットすべしとか、そういうやつに振り回されないまでも、不安に感じることはありました。今ではそのような不安から解放されて、伸び伸びと仕事に集中できています。前述しましたが「十分すぎるストックオプション」の存在ゆえです。Ubieでは、全力で目の前の仕事を楽しんでさえいれば、成果は後からついてきて、おまけに経済的な自由を獲得できると信じています。   .alu-embed-iframe-hpkBpp7OqTHF7HswCMgs {     width: 424px !important;     height: 307px;   }   @media screen and (max-width: 480px) {     .alu-embed-iframe-hpkBpp7OqTHF7HswCMgs {       width: 318px !important;       height: 230.25px;     }   }             進撃の巨人 / alu.jp      alu.jp「生存戦略」のような死なないための、ある意味守りの姿勢は不要で、残りの人生は、ただやりたいことに挑戦するだけです。楽しくないことはやらない。賃金のための仕事はしない。こういうことを言うと「じゃあ、いつまでも今の会社にしがみつくのか？」というツッコミが入りそうですが、そういう考えは一切ありません。会社を辞めるというカードは常に手札の中に持っています。不安とは言いつつも、これまでの賭けにはほぼ全勝してきたし、自分の腕に自信がないわけでないので。その時がいつ来るのか全然想像がつきませんが、Ubieを辞めたら、何をするんでしょうね。良くも、そして悪くもUbienize*3されているので、これが役に立つ組織はたくさんあるのでしょうが、僕自身が心から楽しめる組織を見つけ出せるかというと、あまり自信がありません。そういう意味でも、Ubieを辞めたあとは無職を楽しむか*4、起業するか。いや、起業は向いてなさそうだから、知り合いが興したスタートアップにでも入るか…。いずれにせよ、生涯ワクワクすることだけをし続けたいし、それが実現可能だと本気で思っています。まとめUbie入社4年目ですが今が最高に楽しくて、特にソフトウェアエンジニアとしてプロダクト開発に参画し、チームのみんなで突き進んで行くのがエキサイティングです。これを可能にしているのは、メンバーが優秀であることに加え、組織のカルチャーや制度がイケてるから。そして、キャリア戦略について考えなくてよいくらいの経済的リターンが見込めるという安心感。もちろん、Ubieのプロダクトが世界を大きく変えるという自信、変えてやるという野心、世界中の人々の健康を守るという社会貢献の気持ちも、あります！ワークライフバランスとか働きやすさみたいな面もあります。けど、Ubieで働く一番の理由は「楽しい」から。これに尽きます。そして幸いなことに「楽しい」に夢中になっているだけで、すべてが上手く行く。そう信じています。*1:Ubieという会社は現時点でUbie DiscoveryとUbie Customer Scienceの2大組織で構成されており、僕やエンジニアなどが所属する組織がUbie Discoveryです。詳しくは「スタートアップで、カルチャーが全く違う2つの組織を作った話」をご覧ください。*2:Ubie Discoveryが掲げるValueを体現する個人・チームを称える会*3:僕が今勝手に作った言葉。Ubie Discovery人材の権化みたいな意味。*4:無職でもコードを書けるし、社会貢献だってできます。

Ubieだからこそプロダクト開発を全力で楽しめている

WYSIWYGエディタに憧れてContentEditableをいじってみると、けっこうな底無し沼だと。気づいたときにはどっぷり浸かってるやつ。ググればそれなりに知見が見つかるし、良い感じのライブラリもある。けど僕がやりたかったことは、自分でコードを書いて実現するのが早いんじゃないかなーと思って、沼にダイブした。やりたいことは、ワープロソフトみたいなやつというよりも、編集しているテキストのスタイルがリアルタイムに変化するMarkdownエディタっぽいやつ。つまりユーザがスタイルを当てるんじゃなくて、ユーザが入力したテキストに応じてスタイルを当てたい。より正確には、テキストの見た目をおしゃれにするだけではなくて、もっと高度な何か、Reactのコンポーネントとか、を埋め込むとかしたかった。Draft.jsやEditor.jsのような、ContentEditableを扱いやすくしてくれるライブラリも検討した。Reactのコンポーネントを埋め込むのも簡単そうだった。ただ、ContentEditableの内容を入力のたびに再構築するような方法を採ると、キャレット（エディタ内にあるテキストが挿入される箇所を示す | これ）が編集箇所とは無関係に先頭とかに飛んでしまう現象があった。パフォーマンス上の懸念はありつつも、ContentEditableの内容を再構築する方法は、ユーザの入力内容を解析してUIに反映する上で一番楽な方法だと思ったので、これを譲りたくなかった。かくしてやめときゃいいのに素のContentEditableをいじることとなった。結論としては「キャレットを制す者はContentEditableを制す」だ。出力したいUI次第だけどキャレットを良い感じに扱えれば、あとは些細な問題でちょっとしたテクニックでどうにでもなる。雑に列挙するとこんな感じ。ContentEditableにおけるキャレットの位置を知るためには document.getSelection() などでSelectionを得て、その focusNode, focusOffset などを使う。例えばContentEditableな要素が持つ最初の子要素から focusNode が見つかるまで「文字数」をカウントしていき、focusOffset を足したり引いたりして調整すれば、そこがキャレットの位置となる。「文字数」は「何を1文字とするか」を自分のロジックの中に記述していくことになるけど、これはどういうUI（DOM）にしたいか次第（これが相当しんどいのです）。ContentEditableでキャレットを指定の位置に移動させるには、同じようにSelectionを使う。selection.addRange(range) で、指定の位置に設定したRangeを渡せばOKRangeには「どの要素」の「何文字目」かを指定する必要があって、それを導出するために、先ほどのキャレットの位置＝カウントした文字数を利用する。ContentEditableな要素が持つ最初の子要素から順に走査して、指定文字数に達したときの要素が、Rangeに設定すべき要素となる（が、要件次第で全然変わる）以下、蛇足。単純なセットアップでは、期待どおりに挙動しない次のコードは、ContentEditableを実験するReactコンポーネントとしては完全なコード。その実行結果も下の枠の中で確認できるので、何かテキストを入力してもらいたい。セクション見出しにも書いてあるけど、期待どおりに挙動しない。連続してキーを叩いて単語を入力しようとしても、キャレットが先頭から動かず「hello」と入力したつもりがその逆順「olleh」になってしまう。onInputで入力イベントを受けて innerHTML をuseStateのhtmlとして保存する。次の描画時に保存された html がContentEditableな要素にセットされるという単純な寸法ではダメっぽい。入力時にキャレット位置を記憶し、画面反映後にキャレット位置を復元する雑に列挙したキャレットの扱い方のとおり、入力時にキャレット位置を記憶し、画面反映後にキャレット位置を復元すれば、連続してキーを叩いて目的の単語を入力することが可能になる。上記は完全なコードなので、例示するコードとしてはノイジーだけど細かいロジックは無視してかまわない。キャレット位置特定と、指定位置へのキャレット移動に関するヒントにはなりえるけど、散々言っているとおり要件次第でロジックも変わるので、まるっと参考にできるものではない。ここでは現在のキャレット位置を取得する関数をgetCaretPosition、指定の位置へキャレットを移動する関数をmoveCaretという名前にしている。それらの定義を省いてコンポーネントだけにしたのが、次のコード。export const Example2: FC = () => {  const editorRef = useRef<HTMLDivElement>(null);  const [html, setHtml] = useState("");  const [caretPosition, setCaretPosition] = useState(0);  useEffect(() => {    const editor = editorRef.current;    if (editor == null) return;    moveCaret(editor, caretPosition);  }, [html]);  const onInput = (e: FormEvent<HTMLDivElement>) => {    const currentHtml = e.currentTarget.innerHTML;    setHtml(currentHtml);    setCaretPosition(getCaretPosition(e.currentTarget));  };  return (    <div>      <div        ref={editorRef}        contentEditable        onInput={onInput}        dangerouslySetInnerHTML={{ __html: html }}      />    </div>  );};onInputで入力内容を保存するとともに、getCaretPositionを呼び出してその値を保存する。入力内容（html）に反応するuseEffectの中でmoveCaretを呼び出して、先ほど保存したキャレット位置とContentEditable要素（editor）を引数としている。「hello」と打てば「hello」と入力されるので一旦成功だけど、実は日本語の入力がおかしくなる。「こんにちは」と入力しようとすると「kおnnnいtいhあ」と入力されてしまう。日本語入力に対応するonInputにより入力したそばから、その内容が描画されるので、ローマ入力や漢字変換の暇を与えてくれないのが原因っぽい。ということで、入力が確定されるまで画面に反映しないようにしたのが、次のコード。英字でも日本語でもカウントされる文字数や要素に変化があるわけではないのでgetCaretPositionとmoveCaretはそのまま。変更点はinputHtmlとisInputtingという状態を追加したこと。inputHtmlは入力された内容をバッファーする。htmlに内容を書き込むまでは画面に反映されない。isInputtingは入力中、つまり入力が確定されていないときにtrueとなるフラグ。  useEffect(() => {    if (isInputting || intputHtml == null) return;    setHtml(intputHtml);    setInputHtml(undefined);  }, [isInputting, intputHtml]);  const onInput = (e: FormEvent<HTMLDivElement>) => {    const currentHtml = e.currentTarget.innerHTML;    setInputHtml(currentHtml);    setCaretPosition(getCaretPosition(e.currentTarget));  };このようにonInputで入力された内容を一旦inputHtmlに退避させて、入力中でないタイミングでinputHtmlの内容をhtmlに書き込む。その後、inputHtmlにはundefinedでも入れておいてバッファーをフラッシュする。入力状態については onCompositionStart と onCompositionEnd でイベントを拾う。ローマ字入力や漢字変換などが始まったタイミングで前者が、それが終わったタイミングで後者が呼び出される。      <div        ref={editorRef}        contentEditable        onInput={onInput}        dangerouslySetInnerHTML={{ __html: html }}        onCompositionStart={setInputting.bind(null, true)}        onCompositionEnd={setInputting.bind(null, false)}      />Reactコンポーネントを埋め込むここまでできたら、あとはContentEditableに何を含めるか、どうキャレットを計算するか、という話に尽きる。ちょっとガバガバだけど、入力内容に応じてReactコンポーネントをContentEditableに埋め込むやつが次のコード。[hoge] みたいに入力すると、ラベルっぽくなる。[hoge] なラベルは、テキストとしては6文字だけど、編集不可能（contenteditable="false"）にしてこれを1文字としてカウントしたい。なので getCaretPositionとmoveCaretのロジックを変更する必要がある。例えばキャレット位置を計算するときに要素を再帰的に走査するけど、contenteditable="false"のような特定の要素を見つけた時に1文字カウントして、その子要素はスキップするなどのロジックを追加する。Reactコンポーネントを埋め込むためには、まずプレースホルダーというか、その埋め込むべき場所を示す要素をぶちこむ。抜粋した下のコードは、入力された内容を描画用HTMLに変換する関数で<span contenteditable="false" class="label" data-text="${block.text}"></span>が、Reactコンポーネントを埋め込むための要素となる。コンポーネントにpropsとして渡すためのデータを要素の属性に載せておくなどの工夫をしている。const toHtml = (text: string): string => {  const blocks = parse(text);  return blocks    .map((block) => {      if (block.type === "normal") {        return `<span>${block.text}</span>`;      }      return `<span contenteditable="false" class="label" data-text="${block.text}"></span>`;    })    .join("");};描画用HTMLの変更を検知して、すなわちuseEffectの中で次のコードを実行することで、先ほどのプレースホルダーにReactコンポーネントが埋め込まれる。    document.querySelectorAll(".label").forEach((label) => {      const text = label.getAttribute("data-text");      render(<Label>{text}</Label>, label);    });まとめ

いまさらだけどContentEditableをいじって、キャレットの扱いがしんどいということがわかったよ

先月11月に爆誕した Compose for Desktop というPC向けGUIアプリケーション・フレームワークを味見、ということで簡単なメモ帳アプリをつくってみました。コーディングや調査した内容を順に紹介していくので、擬似的に開発を体験できて、読者の方も一緒に味見ができればと思います。Ubie Advent Calendar 2020の12/11分です。昨日は@hassy_ubによる「30歳。働き方を見直したら、医療xIT企業のUbieにたどり着きました。」でした。もくじCompose for Desktopとはつくり始めるテキスト編集エリアを設置するメニューを設置するファイルの読み書きダイアログを表示するまとめCompose for Desktopとはwww.jetbrains.com上記がCompose for Desktopの公式サイトですが、どういう機能が備わっているかをざっと見てみましょう。https://www.jetbrains.com/lp/compose/ より引用やはりKotlinはJVM言語ということで、AWTやSwingとの相互運用性が謳われてますね。その一方で、Pure Javaでは実現できない通知などのOSの機能が利用できるというのが面白いですね。そして、おそらくこのフレームワークの最大の売りである特徴が、Jetpack Composeとのコードの共有・再利用でしょう。あと、Skiaというクロスプラットフォームなグラフィックライブラリを使ってるみたいですね。つくり始めるIntelliJ IDEAがあれば簡単にCompose for Desktopを使った開発を始められます。プロジェクトの新規作成ウィザードに、いくつか必要事項を入力してプロジェクトを作成すると、プロジェクト雛形が生成されます。詳しい手順については公式チュートリアルをご覧ください。main.kt という生成されたソースファイルには、あらかじめコードが記述されており、これをそのまま実行すると上の画像のようにウィンドウとボタンを持ったアプリケーションが起動します。記述されているコードからわかるとおり「Hello, World!」ボタンをクリックすると、そのテキストが「Hello, Desktop!」に変化します。僕はJetpack Composeの経験はないですが、入れ子構造で宣言的にUIを構築していけるのは馴染みやすいと思いました。テキスト編集エリアを設置する今回は単純なメモ帳アプリをつくるということで、画面に必要なのはテキスト編集エリアですね。ということで元のコードを下記のように編集して TextField を設置します*1。fun main() = Window {    var text by remember { mutableStateOf("") }    MaterialTheme {        TextField(            value = text,            onValueChange = { text = it }        )    }}これを実行すると、下の画像のように TextField が設置され、テキストの入力・編集が可能になります。ただ TextField が左上に寄っているので、これをウィンドウいっぱいに広げたいと思います。fun main() = Window {    var text by remember { mutableStateOf("") }    MaterialTheme {        TextField(            value = text,            onValueChange = { text = it },            modifier = Modifier.fillMaxSize(),            label = { Text("") }        )    }}引数 modifier にはコンポーネントの様々な属性を設定できるようで、今回はサイズを最大にするよう指定しました。Modifier をインポートする際にはパッケージに注意してください。多くの Modifier がサジェストされますが、インポートすべきは androidx.compose.ui.Modifier です。ラベルに空のテキストを指定している label = { Text("") } というコードがありますが、これは何か意味があると思いますか？この指定がないと TextField の中身のテキストが上下中央に表示されてしまし、これを指定することでテキストが上寄りになりました。この指定方法が正しいのかは不明です…。メニューを設置するまずは単純なメニューから。「ファイル」→「新規作成」メニューを設置し、新しいメモを取れるようにする機能を作成します。fun main() {    val text = mutableStateOf("")    AppManager.setMenu(        MenuBar(            Menu(                name = "ファイル",                item = arrayOf(                    MenuItem(name = "新規作成", onClick = { text.value = "" }, shortcut = KeyStroke(Key.N))                )            )        )    )    Window {        MaterialTheme {            TextField(                value = text.value,                onValueChange = { text.value = it },                modifier = Modifier.fillMaxSize(),                label = { Text("") },                textStyle = TextStyle(fontSize = 24.sp)            )        }    }}メニューの設置のために追加されたコードの前に関数 Window の呼び出しや 変数 text まわりの変更に注目してください。メニューの設置には AppManager を使う方法と、関数 Window の引数に指定する方法があるようですが、今回は前者 AppManager を使う方法を選びました。関数 Window を呼び出す前に AppManager でメニューを設置する必要があるので、それに伴い関数 Window の呼び出しや 変数 text まわりに変更を行ったわけです。なお、キャプチャ上の視認性のため TextStyle で文字を大きくしています。ファイルの読み書き「名前を付けて保存」機能をメニューに追加します。いろいろ調査したんですが、現在のところファイル選択ダイアログはCompose for Desktopでは提供されていないようです、たぶん。せっかくSwingとの共存もできるということで、Swingのファイル選択ダイアログ JFileChooser を使って実現することにします。fun main() {    val text = mutableStateOf("")    val currentFile = mutableStateOf<File?>(null)    fun saveAs() {        val parentComponent = AppManager.focusedWindow?.window /* ① */        val fileChooser = JFileChooser()        val result = fileChooser.showSaveDialog(parentComponent)        if (result == JFileChooser.APPROVE_OPTION) {            val file = fileChooser.selectedFile            file.writeText(text.value)            currentFile.value = file /* ② */        }    }    AppManager.setMenu(        MenuBar(            Menu(                name = "ファイル",                item = arrayOf(                    MenuItem(name = "新規作成", onClick = { text.value = "" }, shortcut = KeyStroke(Key.N)),                    MenuItem(                        name = "名前を付けて保存",                        onClick = { saveAs() }                    )                )            )        )    )    Window(title = "メモ帳") {        MaterialTheme {            TextField(                value = text.value,                onValueChange = { text.value = it },                modifier = Modifier.fillMaxSize(),                label = { Text("") },                textStyle = TextStyle(fontSize = 24.sp)            )        }    }}「名前を付けて保存」という name を持つ MenuItem を追加しました。クリック時の処理として JFileChooser を使って保存先ファイルを取得しています。JFileChooserのメソッドshowSaveDialog の引数には親コンポーネントを指定するのですが、その型は java.awt.Component です。これは AppManager.focusedWindow?.window で取得可能です（①部分）。保存先ファイルを取得したら、Kotlin標準の便利拡張関数 writeText を使ってファイルにテキストを書き出します。そして②の箇所で保存先ファイルを currentFile に保存しておきます。これはあとで「上書き保存」や「開く」などで利用します。「上書き保存」は次のような MenuItem を追加するだけです。MenuItem(    name = "上書き保存",    shortcut = KeyStroke(Key.S),    onClick = {        val file = currentFile.value        if (file != null) {            file.writeText(text.value)        } else {            saveAs()        }    })「開く」は下記のとおり。MenuItem(    name = "開く",    shortcut = KeyStroke(Key.O),    onClick = {        val parentComponent = AppManager.focusedWindow?.window        val fileChooser = JFileChooser()        fileChooser.fileFilter = FileNameExtensionFilter("テキストファイル", "txt")        val result = fileChooser.showOpenDialog(parentComponent)        if (result == JFileChooser.APPROVE_OPTION) {            val file = fileChooser.selectedFile            text.value = file.readText(Charsets.UTF_8)            currentFile.value = file        }    })ダイアログを表示するダイアログは Dialog という関数で Compose for Desktopから提供されています。今回は未保存のデータが消える操作がなされたときに注意を促す、いわゆるフールプルーフを実装するので関数AlertDialog を利用します。AlertDialog の表示・非表示の切り分けは、フラグを用意して if文で実現しました（Composeのお作法をわかってないですがReact風なやり方でやりすごした）。「テキスト編集」→「開く」or「新規作成」→処理を中断して「保存しますか？」を表示→「はい」なら保存してから処理を続行、「いいえ」ならそのまま処理を続行、というところでコードの見かけ上で処理が飛び飛びになるのがけっこう面倒でした。最終的にコードとアプリの動きはこうなりました。fun main() {    val text = mutableStateOf("")    val currentFile = mutableStateOf<File?>(null)    val modified = mutableStateOf(false)    val suspendedFunction = mutableStateOf<(() -> Unit)?>(null)    fun new() {        if (modified.value) {            suspendedFunction.value = ::new            return        }        text.value = ""        modified.value = false    }    fun open() {        if (modified.value) {            suspendedFunction.value = ::open            return        }        val parentComponent = AppManager.focusedWindow?.window        val fileChooser = JFileChooser()        fileChooser.fileFilter = FileNameExtensionFilter("テキストファイル", "txt")        val result = fileChooser.showOpenDialog(parentComponent)        if (result == JFileChooser.APPROVE_OPTION) {            val file = fileChooser.selectedFile            text.value = file.readText(Charsets.UTF_8)            currentFile.value = file            modified.value = false        }    }    fun saveAs() {        val parentComponent = AppManager.focusedWindow?.window        val fileChooser = JFileChooser()        val result = fileChooser.showSaveDialog(parentComponent)        if (result == JFileChooser.APPROVE_OPTION) {            val file = fileChooser.selectedFile            file.writeText(text.value)            modified.value = false            currentFile.value = file        }    }    fun save() {        val file = currentFile.value        if (file != null) {            file.writeText(text.value)            modified.value = false        } else {            saveAs()        }    }    AppManager.setMenu(        MenuBar(            Menu(                name = "ファイル",                item = arrayOf(                    MenuItem(                        name = "新規作成",                        shortcut = KeyStroke(Key.N),                        onClick = { new() },                    ),                    MenuItem(                        name = "開く",                        shortcut = KeyStroke(Key.O),                        onClick = { open() }                    ),                    MenuItem(                        name = "名前を付けて保存",                        onClick = { saveAs() }                    ),                    MenuItem(                        name = "上書き保存",                        shortcut = KeyStroke(Key.S),                        onClick = { save() }                    )                )            )        )    )    Window(title = "メモ帳") {        MaterialTheme {            if (suspendedFunction.value != null) {                AlertDialog(                    onDismissRequest = {},                    confirmButton = {                        Button(onClick = {                            save()                            suspendedFunction.value?.invoke()                            suspendedFunction.value = null                        }) { Text("はい") }                    },                    dismissButton = {                        Button(onClick = {                            modified.value = false                            suspendedFunction.value?.invoke()                            suspendedFunction.value = null                        }) { Text("いいえ") }                    },                    text = { Text("保存しますか？") })            }            TextField(                value = text.value,                onValueChange = {                    text.value = it                    modified.value = true                },                modifier = Modifier.fillMaxSize(),                label = { Text("") },                textStyle = TextStyle(fontSize = 24.sp)            )        }    }}まとめまだアルファということで、いろいろ整備されてなさそうだなーという印象はあるもののReact風で個人的には手に馴染みそうです。Composeの名前が意味するとおり、このフレームワークの真骨頂はカスタムComposable関数をつくって、それらを組み合わせてコードの再利用性やら保守性やらを高めてくれることだと思います。ただ問題は、Androidアプリとデスクトップアプリを同時に開発したい場面があるのか、というところです。*1:import文は省略していますが、それ以外は完全なコードです。

KotlinのCompose for Desktopを味見してみたよ〜

自分用メモchome.debuggerremote debugging protocolchrome.debugger.attach でブラウザをデバッグモードにする（tabIdを指定するけどブラウザ全体がデバッグモードになってるっぽい）chrome.debugger.sendCommand({ tabId }, "Network.enable") すると onEvent で Network.receivedResponse のようなイベントをリッスンできるNetwork.webSocketFrameReceived イベントではWebSocketでやりとりしてる内容を取得できるレスポンスボディを取得するにはchrome.debugger.sendCommand(  source,  "Network.getResponseBody",  { requestId },  (body) => { /* 煮るなり焼くなり */ });requestIdをいい感じに投げないとリソース見つからないエラーになるっぽい（というか実際なる）-> Stack Overflow

Chrome拡張機能のdebuggerでレスポンスボディを覗くやつの自分用雑メモ

このコロナ禍において、ZoomやGoogle Meetを使ってオンラインミーティングを行う人が増えたのではないでしょうか。その際にPC画面を共有して、スライドなどの資料を参加者全員で眺めるということをしていると思います。ビデオ会議ツールのチャット機能は、わざわざ発言するまでもないようなちょっとしたリアクションなどを示すのに手軽に使えて便利ですが、ちょっと無機質な気もします。そこで、ニコニコ動画のようにコメントが画面上を流れていく、そういうツールがあったら盛り上がりそうですよね！実は、そういうツールは世の中にすでにあります。commentscreen.com投稿者は自らニックネームをつけてコメントを投稿できます。が、ニックネーム方式だとユーザ依存で、匿名を許容しています。投稿されたコメントや質問の詳細が知りたいときに、誰が発言したのか不明だと進行がグダるおそれがあります。また、コメントを後から追いたいとき、もちろんそれ以外のシーンでもコメントがSlackに存在していることが便利そのものです。例えば検索したり、ピン留めしたり、メッセージURLを共有したり保存したり、絵文字でリアクションしたり、スレッドで話題を深堀りしたり…。ということで、つくりました！Slackに投稿したメッセージが、画面上に流れるツール！正確にはChromeタブ上にコメントが流れるようにするChrome拡張機能です。その名もSlarrage（スラージ）！Slack + barrage（弾幕）から付けた造語です。chrome.google.com使い方はインストール後に、Chromeでお好きなSlackワークスペースのチャンネルを開きます。すると画面上部に「Slarrage is watching this channel」という帯が表示され、このチャンネルに投稿されたメッセージが、ニコ動風コメントのように画面の上を流れるという寸法です。実際にコメントを流すためにはもう一つ設定が必要で、コメントを流したい任意のChromタブを開き*1、Slarrageの拡張機能アイコンをクリックして飛び出る画面の「Show comments this tab」ボタンをクリックします。そうすることで、そのタブ上で監視対象のSlackチャンネルに投稿されたメッセージが流れます。さらに流れるテキストに添えるコマンドもいくつか実装しています。例えば監視対象のSlackチャンネルに こんにちは [red] と投稿すると、流れるテキスト「こんにちは」の色が赤くなるといった具合です。テキストを流さず画面下部中央に固定表示するためのコマンド bottom や、テキストを大きく表示するためのコマンド big などもあります。これらは組み合わせることが可能で こんにちは [red bottom big] と投稿すると、「こんにちは」と赤く大きなテキストが下部中央に固定表示されます。その他、振動するアニメーション shake など、いろいろ実装しているので試してみてください。そうそう、このSlarrageですがChrome拡張機能ということで、コメントが流れるのはそのChromeブラウザ上に限定されます。Chromeの外で動くパワーポイントのようなアプリケーションなどに、コメントを流すことはできないので悪しからず。技術的なメモGitHub Repoはこちらgithub.com没案最初にこのツールを作ったときの構成は、こんな感じです。矢印はデータの流れです。PCやスマホなどからSlackにメッセージを投稿すると message.channels というイベントが発生するので、それをEvent APIで受け取ります。Event APIは、指定したURLにイベントを通知してくれる仕組みで、今回はCloud Functionsのエンドポイントを指定しました。Cloud Functionsは投稿イベントを受け取り、その内容をFirestoreに書き込みます。SlarrageはFirestoreの書き込みイベントを監視しているので、つまり、SlarrageはSlackにメッセージが投稿されたことを感知できるというわけです。この構成は、最初はうまく機能しているように見えましたが、SlackのEvent APIからの通知がたまに詰まることがあり断念…。Chrome拡張機能のみで実現Slackの指定チャンネルへのメッセージ投稿をどうフックするかが問題でしたが、Chrome拡張機能であるSlarrageがSlackタブのDOMの変化を監視すれば実現できるのでは、と思い至りました。実際これはうまく行きました！もっとも、APIでも何でもない＝約束ではなく問答無用で破壊的な変更が起こりうるということなので、将来突然壊れる可能性はあります。MutationObserverChrome拡張機能のパーミッションとactiveTabChrome拡張機能をChromeウェブストアで配布しようと思い、今回が人生初の拡張機能公開だったので、5ドル払って開発者登録を行いました。そして、ソースファイル等をまとめたzipファイルをアップロードし、審査の申請を行おうとしたところ「この拡張機能は広範囲のホスト権限を要求している」と言った旨のアラートとともに「そういうわけで審査にかなり時間かかるよ」と言われてしまい、パーミッションまわりを見直すことにしました。Chrome拡張機能にはcontent scriptと呼ばれる、タブで開いているページ上で実行されるスクリプトを指定することができます。次のmanifest.jsonの一部のように「どのURLにマッチしたら、そのページ上で、どのスクリプトを実行する」というのを指定します。  "content_scripts": [    {      "matches": ["https://app.slack.com/*"],      "js": ["content/observer.js", "content/watchingAlert.js"]    },    {      "matches": ["<all_urls>"],      "js": ["content/presentation.js"]    }  ],問題となったのは <all_urls> という指定で、これが「広範囲のホスト権限の要求」に相当します。あらゆるページ（URL・ホスト）でスクリプトを実行可能にすることは、要求する権限として大きいようです。そこで、このcontent scriptを外して、activeTabという仕組みでターゲットとなるタブ、ページにスクリプトを流し込むように実装し直しました。つまり、content scriptは自動的にスクリプトが実行されるのが問題であって、ユーザが能動的なアクションを取ればスクリプトを実行してもいいでしょうという発想っぽくて、能動的なアクションとは例えば、拡張機能アイコンを押すことによるポップアップ表示、とか。content scriptsactiveTab流れるコメント画面を流れるコメントは、DOMを生成してposition: fixedでz-indexをでっかくしてtop, leftをいい感じにしているだけで、とても単純です。当初、少し頭を悩ませたのは、クリックやホバーなどのマウスイベントを無視したいということでした。流れるコメントがページを操作するユーザの邪魔になったら嫌なので。調べるとCSSにpointer-eventというプロパティがあって、これをnoneにするとマウスイベントが無視されるとのことでした。pointer-eventおわり*1:実際には利用できないタブがあります。chrome://のようなタブがその典型です。

Slack投稿をニコ動風に画面に流すChrome拡張機能をつくったよ〜

なんと早いもので！AI医療スタートアップのUbie（ユビー）株式会社に入社して、2年が経ちました。あっと言う間ですね〜。Ubieは来月に4期目を迎える、まだまだ若いスタートアップ企業ですので、そういう意味で2年という期間は長く、今と入社当時とでは状況がまるで違います。このエントリでは、僕にとってのUbieを「THE TEAM」の中で語られている組織のエンゲージメントの4Pという観点で、入社当時と現在を比較しながら考えていきたいと思います。もくじPhilosophy（理念）Profession（仕事の内容）People（人）Privilege（待遇）おわりにPhilosophy（理念）Ubieが掲げるビジョンは「Hello, healthy world」です。健康が当たり前に存在する世界を実現したいと考えています。そして、それを実現するため「テクノロジーで人々を適切な医療に案内する」をミッションとしています。患者はもとより医療従事者をも対象に、適切な医療にアクセスできるようにお手伝いします。入社当時創業当時からUbieの理念は一貫していますが、今のビジョンやミッションとはその表現が若干異なりました。2019年2月に開催された合宿に合わせてビジョンとミッションが決定されました。合宿では行動指針となるバリューを全員で決めたProfession（仕事の内容）Ubieには、いくつかのプロダクト開発チームが存在しており、主となるのは「AI問診Ubie」という医療機関向けのサービスを開発するチームです。タブレットで問診を行い、患者の回答を電子カルテへ転記しやすい形に翻訳・整形することで医療現場の業務効率化に寄与します。入社当時入社直後に僕に与えられたミッションは「AI問診Ubie」のうち、医師が使う画面への新規機能開発とそれに伴うUIデザインのリニューアルでした。TypeScriptやReactに不慣れではありましたが、ワンパンでした💪当時はまだ社外からお手伝いとして参画していた、医師画面の新UIの担当デザイナーはたけ氏は、僕の開発スピードに合わせるためにUbie入社を決めたと本人談。初めての引越しを終えた直後のオフィスで開発していた2019年4月〜12月もともと「なんちゃってスクラム」でプロジェクトを回しており、一応は機能しているように見えていたのですが、人数が増えるにつれ、生産性が落ちていることに気付きました。そこで、ちゃんとしたスクラムをやろうということになったのが2019年の4月頃だったと思います。「AI問診Ubie」は患者側チーム（タブレット問診）と医師側チーム（PC医師画面）に明確に分かれ、それぞれにプロダクトオーナーやスクラムマスターを配置しました。僕は医師側チームで、カルテ記載のための補助やそれに付随する機能を担当しました。このチームの構成は、医師兼プロダクトオーナー、デザイナー兼スクラムマスター、エンジニア4名です。POの医師やデザイナー、あるいはカスタマーサクセスが精力的に医療現場でのヒアリングを行い、ニーズを拾い上げ仕様案へと落とし込みます。それを毎日のプロダクトバックログ・リファインメントの時間にメンバーで議論を交わし洗練させ、週次のスプリント・プランニングで実装の計画を立てます。医師チーム（突発的に開催された社外ミーティング）からしか見ていませんでした。そして…  2020年1月〜3月「AI問診Ubie」という同じプロダクトを扱うチームが患者側と医師側で分かれることによって、施策の優先順位の見極め精度が曇るという課題が顕在化してきました。そこでLeSS（Large Scale Scrum）という手法の採用に踏み切りました。患者側と医師側をガッチャンコさせ「AI問診Ubie」でONE TEAMだと。プロダクトオーナーも、プロダクトバックログもひとつ。LeSSにより「AI問診Ubie」は全員同じ目線で動けるようになったと思います。プログラマーの美学とでも言うべき感覚にこだわりを持っていた僕ですが、必要ならば負債を積むことも厭わない、そういうバランス感覚が養われたと思います。  2020年4月（今）「AI問診Ubie」は比較的規模の大きい病院に受け入れられ、全国の病院で導入が進んでいます。この春から、街の診療所のような規模の小さい施設にもUbieを使っていただくため、僕は「AI問診Ubie」チームからクリニック特化チームへと移籍しました。大病院とクリニックとでは求められる機能が異なるため、また我々の解像度が低いため、別チームとして切り出し、仮説検証を高速に回していくことが狙いです。People（人）人が文化を創り、文化が人を育てる（名言風）個人的には4Pのうち一番重要なPだと思います。入社当時と今6人目のメンバーとして入社。月並みな表現ですが、みんな優秀で個性的で尊敬しかありませんでした。もっとシンプルに、好きと、そう言い切れるメンバーです。エンジニア採用LPのために撮った写真今、社員は40人程度で、そのうちエンジニア（ソフトウェアエンジニア、データサイエンティスト、SRE等）は20人くらい在籍しています。いろんな人がいます。やはりみんな優秀で、僕も負けないように日々研鑚しています。どのような人がいるか、ここに入社エントリやUbieでの働き方についてそれぞれが書いた記事がまとめられているので、見てみてください。組織運営Ubieという組織を表現するキーワードとして「オープン」「フラット」「透明」「率直」というものが挙げられます。共同代表の二人を除けば、その他のメンバー間に上下関係や階層構造は一切なく、それゆえに情報や知識の流れを阻害するものはありません。あらゆる情報にアクセス可能です。招待されていない会議にも興味さえあれば参加可能です。意見や提案も自由です。心理的安全性を支え、チャレンジ精神を育んでいるのかもしれません。  しかし、これがうまく機能しているのは人数の少なさゆえかもしれません。人が増え、情報が増えると、情報へアクセスするコストも増え、スピード感が損なわれるおそれがあります。そういう状況に危機感を覚えたメンバーが中心となり「透明性プロジェクト」が立ち上がりました。そもそもどういう状態が透明であるのかという定義から、透明である状態を貫くためのhowの検討までを担当しています。その一環としてホラクラシー組織の実装・運用も視野に入れています。OKRUbieでは目標管理の手法としてOKRを採用しています。今では珍しくないものですが、取り組みの度合いとしては本気です。全社員にMeasure What Mattersが配られ、これを読んでOKRに臨むぞと、去年の1月からスタートしました。それでも最初のうちは、なかなか運用が難しく、試行錯誤を繰り返して、徐々に慣れていきました。四半期に一度行われるOKRオフサイトミーティング業務外でも遊ぶよそりゃあ仲良くなれば一緒に遊ぶよね、人間だもの。キャンプ、HADO、釣りBBQ、スノボPrivilege（待遇）正直に、給料は悪くないです。というか納得している。でないと転職していません。加えて、ストックオプションをもらっています。求人票には年俸600万〜1200万円と提示されています。コアタイムなしのフルフレックスでリモートワークもOKです。出社するにしても自宅で仕事するにしても、満員電車を避けられるのは嬉しいです。もちろん、オフライン推奨ミーティングや出張のときなんかはこの限りではありませんが。オフィスのデスクに、パーテーションはありません。コミュニケーションを取りやすくするためでしょう。僕はでっかいディスプレイ2枚をもらって作業しています。一枚はターミナルを表示して、もう一枚はSlackとTwitterを表示しています。そしてノートPCにはIntelliJ IDEAを表示してます。椅子はエルゴヒューマンのこれだと思います。オフィスには無料のドリンクとフードが盛り沢山です。フードはお菓子だけではなく、OFFICE DE YASAIによるサラダや果物や豆腐のヘルシーそうなやつもあります。食糧には困らない卓球台もあります。単なる飾りで終わり、ではなく、ちゃんと使われています。卓球の取り組みについて取材を受けました。また、Gunosyさんと企業対抗団体戦をやったりもしました。ここ最近は、新型コロナウイルスの影響でリモートワークにシフトし、出社していないので卓球が恋しいです。ドライブを打つときの顔オフィス奥には芝生スペースがあるのですが、ここでミーティングをよく行います。大きいディスプレイにはNintendo Switchがつながってるのでゲームやカラオケを楽しむことができます。芝生側にある冷蔵庫にはビールが入っており、またその隣にはワインセラーがあります。ソファに座って、あるいはバーカウンターでお酒を楽しむことができます。みんなの憩いの場 芝生スペースよさそう  おわりに以上、Ubieにおける「組織のエンゲージメントの4P」でした。僕は「テクノロジーで人々を適切な医療に案内する」をミッションに、日々コードを書いています。「AI問診Ubie」の医師画面を担当していましたが、今月からクリニック向けプロジェクトが始まり、そちらに注力します。開業されている先生方にお話を伺い、仮説に肉付けをし、持ち前の爆速開発力でじゃんじゃんリリースし、価値を証明していきます。思い切り仕事ができるのも、周りの人々や組織文化、働きやすさのおかげだと思います。仕事も私生活もすごく充実しているし変化が起こりまくってる。今は将来懐かしいと思であろう日常で、伝説の始まりで、これから作っていく歴史の中を生きているって思ってる。— たろう (@ngsw_taro) 2018年8月10日  最後に、新型コロナウイルス感染症が世界中で猛威を振い、多方面に影響が広がっていることに関して一個人として心苦しく思っております。この状況にUbieだからこそ貢献できることもあると考え、社内でも色々と議論を進めております。一刻も早い事態の収束を望むばかりです。Ubieについてもっと詳しく知りたい方は👇をご覧ください。

入社して2年が経ったUbieについて理念・仕事内容・人・待遇の観点から語る

Ktorの面白い特徴のひとつとしては「Webアプリケーションに必要な機能を"install"していくスタイル」を採っていることだと思います。その典型的な例はルーティングです。よく見るルーティング設定のコードはrouting {    get("/") {        call.respondText("Hello, world!")    }}のように routing を使うものが多いと思いますが、これはinstall(Routing) {    get("/") {        call.respondText("Hello, world!")    }}と記述するのとだいたい同じです。その他にも標準で提供されているFeatureはたくさんあって、例えばContentNegotiationやCompressionのようなものがあります。install(ContentNegotiation) {    jackson()}install(Compression) {    gzip {        priority = 1.0    }}install(Routing) {    get("/") {        call.respondText("Hello, world!")    }}今回は、このFeatureを自作してみます。有用なものを作って配布したら、いろんな人にinstallして使ってもらえるかもしれませんね。参考https://ktor.io/advanced/features.htmlhttps://ktor.io/advanced/pipeline.htmlとは言っても役に立ちそうなアイデアがパッと浮かばないので、単純なロギングFeatureを実装したいと思います。ポイントは大元となるFeatureクラスを定義する（今回はMyLoggingクラス）そこに設定用クラスをネストする（名前は何でもいいけどConfigurationクラスとします）ApplicationFeatureインタフェースを実装したcompanion objectを定義するです。必ずしもこれに従うことはないとは思いますが、上記参考URLの公式ドキュメントではこうなっていました。ざっとこんな感じになります（importは割愛）。class MyLogging(configuration: Configuration) {    val decoration: String = configuration.decoration    class Configuration {        var decoration: String = "✨"    }    companion object : ApplicationFeature<ApplicationCallPipeline, Configuration, MyLogging> {        override val key: AttributeKey<MyLogging> = AttributeKey("MyLogging")        override fun install(pipeline: ApplicationCallPipeline, configure: Configuration.() -> Unit): MyLogging {            val configuration = Configuration().apply(configure)            val feature = MyLogging(configuration)            /* TODO */            return feature        }    }    // あとで使う    private fun log(message: String) {        println("$decoration $message $decoration".trim())    }}このコードで一旦はFeatureとしての体を成しています。が、現時点では何も仕事はしていません。メソッドinstallの引数configureが、独自定義の設定用クラスConfigurationの拡張関数になっていることに注目してください。このFeatureのユーザは、ラムダ式の中でConfigurationのプロパティにアクセスすることで設定を組み立てていきます。install(MyLogging) {    decoration = "🌟"}routing {    get("/") {        call.respondText("Hello, world!")    }}さて、まだ何の面白いこともしていないMyLoggingですが、リクエストの前後でログを出力したいと思います。2つ前のコードのメソッドinstallに再び注目してください。第1引数pipelineを扱います。PipelineもKtorの面白い特徴のひとつなんですが、ドキュメントコメントの言葉を借りればこれは「非同期の拡張可能な計算のための実行パイプラインを表す」ものです。Pipelineにはフェーズがあって、そのフェーズをインターセプトすることができます。override fun install(pipeline: ApplicationCallPipeline, configure: Configuration.() -> Unit): MyLogging {    val configuration = Configuration().apply(configure)    val feature = MyLogging(configuration)    pipeline.intercept(ApplicationCallPipeline.Features) {        feature.log("${call.request.path()}へのリクエストが始まるよ！")        proceed()        feature.log("${call.request.path()}へのリクエストが終わったよ！")    }    return feature}余談ですが、メインのApplicationCallPipelineには5つのフェーズがあって、今回は"Features"というフェーズをインターセプトしました。本来であれば"Monitoring"でやるべきだったのかなと思いつつCallLoggingという標準のロギングFeatureのコードを読んでみたら、新たに"Logging"というフェーズを作り、"Monitoring"の前に挿入していました。そういうプレイングもあるのか…。なお、今回つくってみたMyLoggingの使ってみた結果はこんな感じです。CallLoggingも併用しています。

KtorのカスタムFeatureをつくる

アドベントカレンダーの季節なので、KtorでWebアプリケーションを作るときのことを考えたメモを残します。いわゆるコントローラ、リクエストを受けてごにょごにょしてレスポンスを返すところを担うやつ。そしてルーティング、パスとコントローラを紐づけるやつ。Ktorでこの両者をどう扱うかを考えてみました。HelloWorldの延長線上でズラズラとコードを並べるとこんな感じになります（完全なコードではありません）。コントローラの役割とルーティングが同居する世界です。これを基本形として、いくつかの工夫を見ていきたいと思います。val userRepository = MyUserRepository()routing {    route("users") {        get {            val users = userRepository.findUsers()            call.respond(users)        }        post {            ...        }        route("{id}") {            get {                val id = call.parameters["id"]?.toLongOrNull()                val user = id?.let { userRepository.findUser(it) }                if (user == null) {                    call.response.status(HttpStatusCode.NotFound)                    return@get                }                call.respond(user)            }            delete {                ...            }        }    }}公式サンプルではどうやっているかKtorはサンプルプログラムを豊富に提供していて、その中にはそこそこ本格的なアプリケーションも含まれています。例えばTwitterみたいなKweetというサンプルです。このサンプルで、今回注目したいのはLocationsというfeatureと Route の拡張関数を使っているところです。Locationsはパスを表現するクラスをいい感じに扱えるようにしてくれます。詳細は公式ドキュメントに譲りますが、Locationsがどのように使われているのかざっくり説明します。単純のためKweetのコードを引用せず、上記のようなUser APIについて考えます*1。まず @Location にパスを指定して、クラスにくっつけます。@Location("users")class Users {    @Location("{id}")    class Member(val id: Long)}@Location がついたクラスを入れ子にすることで user/{id} のようなパスを表現することが可能です。ルーティングをこのように書き直すことができます。routing {    get<Users> {        val users = userRepository.findUsers()        call.respond(users)    }    post<Users> {        ...    }    get<Users.Member> {        val user = userRepository.findUser(it.id)        if (user == null) {            call.response.status(HttpStatusCode.NotFound)            return@get        }        call.respond(user)    }    delete<Users.Member> {        ...    }}users/{id} で指定したパスパラメータが Users.Member オブジェクトのプロパティ id にセットされるので、これを簡単にアクセスすることができます。Kweetではさらに、パスとHTTPメソッドの組みそれぞれに対して Route の拡張関数を別ファイルに定義しています。fun Route.showUser(userRepository: UserRepository) {    get<Users.Member> {        val user = userRepository.findUser(it.id)        if (user == null) {            call.response.status(HttpStatusCode.NotFound)            return@get        }        call.respond(user)    }}このような拡張関数を定義して、 routing のラムダ式の中身をこのように書き換えます。routing {    listUsers(userRepository)    createUser(userRepository)    showUser(userRepository)    deleteUser(userRepository)}ファイルを分割し、見通しはよくなった気がしますが、実質的にはコントローラの役割とルーティングが合わさっているように思えます。拡張関数 showUser は、パスパラメータ id をより抽象的な概念として捉えることができますが、自分のパスは Users.Member クラスと対応していることを知っています。コントローラクラスを導入する個人的にこれを改善しうるのって、いつものコントローラクラスだと思っています。リソース1種類につき、ひとつのコントローラクラス。素直にコーディングすると、今回の場合はこのような感じになりそうです。class UserController(private val userRepository: UserRepository) {    suspend fun index(call: ApplicationCall) {        val users = userRepository.findUsers()        call.respond(users)    }    suspend fun create(call: ApplicationCall) {        ...    }    suspend fun show(call: ApplicationCall, id: Long) {        val user = userRepository.findUser(id)        if (user == null) {            call.response.status(HttpStatusCode.NotFound)            return        }        call.respond(user)    }    suspend fun delete(call: ApplicationCall, id: Long) {        ...    }}そしてルーティング側はこうなります。もはやLocationsはなくていいかもしれませんね。val userRepository = DummyUserRepository()val userController = UserController(userRepository)routing {    get<Users> { userController.index(call) }    post<Users> { userController.create(call) }    get<Users.Member> { userController.show(call, it.id) }    delete<Users.Member> { userController.delete(call, it.id) }}という感じで、一旦の僕の中での結論としてはパスとHTTPメソッドを知らないコントローラを定義して、その各メソッドを routing の中でパスとHTTPメソッドに紐づける方式がよいのではなかろうかと。で、Locationsも要らない、ややこしくしているだけ説。UbieではKtorアプリケーションが爆誕しつつあるんですが、リリースされて本格的に運用が始まったらこの仮説は崩れるのだろうか。。ベスプラ知りたい。*1:KweetはSPAがREST APIを叩くというよりもページ遷移 + レンダリングなアプリケーションなので、今回の例とはそこらへんが異なりますが本質的な問題ではないでしょう。

Ktorのルーティングとコントローラについて考える

Kotlin技術カンファレンス、今年も開催！日本Kotlinユーザグループ（JKUG）主催のKotlin技術カンファレンス「Kotlin Fest 2019」を開催します。前回のKotlin Fest 2018のご好評を受け、今回は規模を大きくします！日程2019年8月24日 土曜日会場東京コンファレンスセンター品川主催日本Kotlinユーザグループコンテンツ3トラック 15セッション、企業展示ブース（予定）参加人数500名程度チケットは7月上旬に販売開始予定です。詳細は下記サイトをご覧ください。kotlin.connpass.comKotlin Fest は一貫して「Kotlinを愛でる」というテーマで企画・運営しています。ご来場のみなさまに、Kotlinに関する知見の共有と、ほかのKotlinファンとの交流を楽しんでいただければ幸いです。今回はご講演者さまを公募するという試みを行います。ぜひ、お持ちのKotlinの知識や経験を、Kotlin Festでのご登壇という形で共有いただければと思います！下記リンクのフォームから、2019年6月23日 23:59までにお申し込みください。日本語 : https://forms.gle/Sxb85wkUDVCL1aUJ9English : https://forms.gle/jv4cKekZC6G6jSPG6お問い合わせはJKUG窓口 japan-kotlin-user-group@googlegroups.com までお願いいたします。Have a nice Kotlin!

Kotlin Fest 2019 開催のお知らせ #kotlinfest #jkug

先日 結婚式を挙げました。教会でやるやつと、飲み食いしながらワイワイやる披露宴を都内某所にて。最高に楽しかったけど、初めて自分の結婚式を開催するということで、準備は相当しんどかったです。ということで、このエントリは結婚式とその準備の振り返りについて書こうと思います。結婚式のなんやかんや一般論ここらへん言いたいことたくさんあるけど、ちょこっと列挙するだけにとどめておきます。そもそも何度も利用するものではないのでユーザーが繰り返し学習するような構造ではないそのためかどうか、ユーザーと提供者（式場側）に情報の非対称性がある初回の見積もり時よりも最終的な請求額が高くなるのは、そうした理由が大きく占めるのではないか情報の非対称性、人生一度きりの希少性だけでなく、ご祝儀前提の強気な価格設定結婚式への個人的な思い妻と出会うずっと前から「結婚したら友達を呼んで結婚式をやりたい」と思っていました。友達や家族と飲みに行くのが大好きなので「自分の結婚式＝友達オールスター＋家族と飲める場所」と捉えていたのです。それから「ご祝儀や会費がない結婚式」も、以前からやってみたいと思っていました。言うほど大層なことではなりませんが、少なくとも自分はそのような結婚式を体験したことはありませんでした。なぜ完全無料の結婚式をやりたかったのかと言うと我々夫婦のために自分の時間を割いて出席してくれている人たちへの感謝の気持ちお金が絡むことで発生する双方の雑務・トラブルの回避新券や熨斗袋を用意する手間式当日の受付担当者によるご祝儀の管理祝儀が少ないだなんだのつまらないアレ引出物なし単純に変わったことをやりたかった自分の親、妻の親からの経済的な援助ももらってません。その代わりに、両親たちが要望を言うこともなかったし、自分たちがやりたい結婚式を好きにデザインできたと思います。変わったことをやりたかったという点で、もう一つ。招待状の機能も含めた結婚式アプリを開発して、出席者に使ってもらいました。招待状に回答すると各種コンテンツを閲覧できるReactで開発し、Firebase Hosting, Firestore, Cloud Storage, Authenticationを利用しました。プッシュ通知にはPushnateを利用しています。独自ドメインも取得しました。開発で苦労したのはアプリ組み込みのWebViewの対応でした。Firestore等は初めて使ったので調査しながらの開発になりましたがすごく便利で助かりました。また、ホーム画面にランチャーアイコン追加やプッシュ通知の実装なども勉強になりました。結婚式当日ウェルカムスペースでアルコールと軽食を提供したのはよかったこれは僕だけかもですが、やっぱすぐ飲みたいよね僕も少しだけ（時間にして10分ほど）ウェウカムスペースに登場して、ゲストと会話を楽しんだジャズの生演奏もおしゃれチャペルでの挙式、始めは少し緊張したが、入場すると知ってる人しかいないので緊張が和らいだ詳細には記載しないが、要所要所で笑いを取れてよかったチャペルからの退場時、バブルシャワーにしたけど当日の晴天も手伝って綺麗だった挙式前のウェルカムスペースでみんなとはしゃぐ様子ハッシュタグを設定したのはよかった。タイムラインが大盛り上がりだった。Togetterまとめかねてより僕はフリー素材であることを公言しているので、たくさん写真がアップされてたBGMは考え抜いた。披露宴、新郎新婦入場前の曲は東京ディズニーシーのエントランス曲で、入場曲は布袋さんのスリル「世界のトレンド」にもなった #たろかな婚 は3万8千人にリーチオープニングムービー、プロフィールムービーは撮影、編集ともに頑張ったよ乾杯のご挨拶をいただいたのは師匠である @yusukeさんスピーチはUbieの阿部（白衣着用）と久保（自作ラップで祝福）ラップ前で緊張する久保（左）と白衣着用の阿部（右）お色直しは和装。再入場曲はミュージックステーションのあれ。会場の手拍子が揃って嬉しかったうちの父のノリは大好評だった。最後の挨拶ではいい話もしてくれた記念品として母には花束を、父にはチロルチョコ一年分を贈った涙なし、笑いしかない、自由で疲れない結婚式を実現できたと思っているチロルチョコ一年分贈呈二次会二次会も開催しました。二次会から参加するゲストも多くいらっしゃいました。なお、二次会は会費をいただいています。二次会はたくさん会話したかったのでコンテンツを少なめにしました。友人からの乾杯の挨拶と、ゲームをひとつ、です。ゲームは独自に思いついた「インタビュー・ビンゴゲーム」というものです。3 x 3マスのビンゴカードには、各マスに新郎新婦にちなんだキーワードが書かれています。抽選で選ばれたゲストが、新郎あるいは新婦を指名し、インタビューします。そのインタビューへの回答が、キーワードと一致したとき、そのマスが開くというビンゴゲームです。ゲーム性を高めるため、各マスにはそのキーワードの出現数を併記しています。つまり、出現数が多いキーワードを開けためのインタビューをすると、他プレイヤーにも恩恵があるということです。見覚えあるスライドとともに何かが始まる！何か(BINGO) #たろかな婚 pic.twitter.com/PLaCyzysS5— よこな♨ (@ihcomega) 2019年4月13日余興のビンゴゲームで、勝つための戦略が解説されてるの新鮮#たろかな婚 pic.twitter.com/ZSYpfwK2f1— 森うどん@Ubie (@moriudon0626) 2019年4月13日二次会にはチューバッカとトルーパーも駆けつけてくれました後日いろんな人から写真や動画をいただいた様々なアングルなのイイ動画の場合、その席周辺のリアクションが入ってて面白いお祝いの品物をたくさんいただきました完全無料とか言いながらAmazonの欲しいものリストを公開していました。そしたら、たくさんの方々からお祝いをいただきました！新婚生活、新婚旅行に活用させていただきます！お礼とともに、お名前を紹介させていただきます（敬称略・順不同）。@mhidaka / @red_fat_daruma / @spetsnaz0173 / @yusuke / @syobochim / @bols_blue / @mstssk / @yukishigedo / @napplecomputer / @jooohn1234 / @maeharin / @nantani4 / @tomoya0x00 / @zinbe / @smochi_pub / @vvakame / @iwata_n / @RyotaMurohoshi / @mike_neck / @mochicon / @th_1983 / @shiraj_i / @takuyais / @toorusen / @ta9mar / @gfxそして、二次会は会費をいただいたのですが、特典がないにも関わらずやや高めの会費設定をした枠で申し込んでくださったみなさまにも感謝申し上げます（敬称略・順不同）。@ta9mar / @yusuke / @quvo_ubie / @red_fat_daruma / @95kugo / @sys1yagi / @takayamag /  @th_1983その他、高校や中学の友人からもお祝いをいただきましたが、Twitterアカウントを知らないため紹介は割愛させていただきます。まとめ結婚式はある意味 情報戦。ネットなどの口コミで調べまくる、式場の人に聞きまくるのがいいと思ったご祝儀がないと新郎新婦も親族もゲストもみんなハッピーになれるのでは説我々夫婦らしい、気取らず疲れず、とにかく笑いが絶えない、そんな結婚式ができた改めて、みんなに愛されていることを感じた今日は本当にありがとうございました！自分の好きな人しかいない空間を実現できて最高に楽しかったです！これからも仲良くしてください！！　#たろかな婚— たろう (@ngsw_taro) 2019年4月13日

結婚式をしたよ〜（ゲスト完全無料・自作招待状アプリ・世界のトレンド） #たろかな婚

8月25日に国内初となるKotlin技術カンファンレンス「Kotlin Fest 2018」を開催しました。1dayイベントで11のセッションがあり、来場チケット368枚はありがたいことに完売！ご協賛いただいた企業様は18社に上ります。午前中のオープニングセッションに始まり、夜の懇親会まで大いに盛り上がりました！大きなトラブルも、滞りもなく、笑顔と活気しかない、とても楽しいイベントでした。kotlin.connpass.com当日受付会場は東京コンファンレスセンター・品川様にお貸しいただきました。広くて清潔感のある会場受付では、PeatixのQRコードチケットを確認して、ネームプレートとKotlin Festのロゴ入りトートバッグをお配りしました。受付からオープニングセッションまでの時間には、ホワイエにてドリンクと朝食が振舞われました。オープニングセッションオープニングでは、私と@satorufujiwaraさんが登壇し、挨拶とKotlinトークを行いました。我々のKotlinへの愛を、これでもかと言うくらい伝えられたと思います！このイベントの空気をつくるのは、オープニングにかかっているという気持ちで臨んだ結果、大成功しました。オープニングセッションのスライドはこちら。個人的には、↓のスライドは非常によかったと思っています。セッションセッションはホールAとホールBの2トラック同時に行われました。内容を3つに分類するならば、Kotlinによるプログラミング一般、Androidアプリ、サーバサイドに分けられると思います。どのセッションも（個人的な体感として）拍手や笑い声、歓声にあふれていて、温かい雰囲気でした。ツイートやブログを拝見すると、同じように感じられている方が多く見受けられました。やはり、オープニングでの「盛り上げよう」のメッセージがよかったのかなと思います。各セッションの発表資料は、本イベント connpassのページにまとまっているので、ぜひご覧になってください。協賛企業ブースホワイエでは、ことりスポンサーのブースを出展していました。どのブースも、工夫を凝らしたコンテンツを提供されていて、面白かったです。ことりスポンサーのブースまた、ドリンクや軽食の提供があり、ホワイエ奥ではAsk the speakerとしてQ&A用スペースを設けていました。そのため、セッションの合間にはホワイエに多くの人が集まり大盛況でした。懇親会懇親会は会場を移動することなく、ホワイエで行いました。料理やドリンクが豪華で、Kotlin談義に花が咲きました。オープニングでのパックマンルール（輪になって話すときに人が入りやすいようにスペースを空けておくというもの）の紹介をしたことで、話しに入りやすかったという声をいくつかいただきました。私もいろんな人と話せました！ありがとう！オープニングでもクロージングでも何度も言ったけど、まだまだ言い足りないのが「ありがとう」です。ご協賛いただいた企業様、スピーカーの方々、会場のスタッフの方々、来場者の方々、みなさまに感謝です！そして、運営メンバーに感謝！みんなイベントの企画や運営の経験や知見やセンスがものすごいし、実際に動き回ってくれたしで、この運営メンバーなくしてKotlin Fest 2018は成り立ちませんでした。カンファレンス・レポートたくさんのレポートが公開されています。ありがとうございます！ここに列挙したいと思います（順不同）。Kotlin Fest 2018 - Kotlin Puzzlers by CyberAgent 解答・解説Kotlin Fest 2018に参加してきました - shiraji’s diaryKotlin Fest 2018でサーバサイドKotlinのテストについて発表してきた #kotlinfest - maeharinの日記Kotlin Fest2018に参加した - 道産子エンジニアKotlin Fest 2018でサーバサイドKotlinのテストについて発表してきた #kotlinfest - suusan2号の戯れKotlin Fest 2018 にさらりと参加してきた #Kotlinfest - 941::blogKotlin Quiz @ Kotlin Festの正解発表 – mixi developers – MediumKotlin Fest 2018 | 株式会社カサレアル ラーニングサービスKotlin Fest 2018で学んだこと・気づき・自分で調べてみたこと - Mi in progress#KotlinFest でLTしました！みんな「へ～」ありがとな！ - 僕はここだ！電気羊はandroidの夢を見る: Kotlin Fest 2018で「start from Convert to Kotlin」トークしましたKotlin Fest 2018 に参加しました - ikatechxの日記【多分最速？】Kotlin Fest 2018に参加しました【イベントリポート】 - BizReach Tech BlogKotlin Fest 2018でコルーチンの話をしてきた - visible trueKotlin festに行ってきました - Studyplus Engineering BlogKotlin Fest 2018 に行ってきました - みずねの備忘録Kotlin Fest 2018でエンジニアが登壇＆ことりスポンサーとして参加してきました - エムスリーテックブログKotlin Fest 2018 協賛＆主催レポート : LINE Engineering BlogKotlin Fest 2018に行ってきました！ - コネヒト開発者ブログKotlin Fest 2018 に参加してきた – ken kentan blogKotlin Fest 2018にメドレーが"ひよこスポンサー"として協賛しました - Medley Developer BlogKotlin Fest 2018 の運営を振り返る #kotlinfest - kikoのブログKotlinを愛するファンたちの壮大なオフ会 - Kotlin Fest 2018 レポート - ASKUL Engineering BLOGおわりにら、来年もやるぞーーーーーー！！！！！！？先日のKotlin Fest 2018のアルバムを公開しました！https://t.co/kRxG6If5Kpご利用の際は法律およびGoogleフォトの利用規約の遵守をお願いします。 #kotlinfest— Kotlin Fest 2018 (@kotlin_fest) 2018年8月28日

Kotlin Fest 2018 大盛況のうち幕を下ろしました！ #kotlinfest #jkug

問題WebTestClient.BodySpecのisEqualToメソッドを呼び出すと、ぬるぽる。webTestClient.get()    .exchange()    .expectBody(MyApiBody::class.java).isEqualTo<Nothing>(expectedBody)isEqualToを呼び出すためには、その型引数としてNothingを指定する必要がある（そうしないと、コンパイルが通らない）。これを実行するとNullPointerExceptionが発生する。解決方法拡張関数のexpectBodyを使用する。ただし、IDEはこの拡張関数をサジェストしてくれないので、自分でインポートする（サジェストさえしてくれていれば、あまり悩まずに済んだのに...）。// これをインポートimport org.springframework.test.web.reactive.server.expectBodywebTestClient.get()    .exchange()    .expectBody<MyApiBody>().isEqualTo(expectedBody)コードの見た目もKotlinらしくスッキリし、テストもちゃんと実行される。参考: [SPR-15692] Kotlin unable to inherit type for WebTestClient#BodySpec - Spring JIRAあーまたKotlinのジェネリクスまわりのバグ踏んだっぽい...— たろう (@ngsw_taro) August 20, 2018

【解決済み】KotlinでWebTestClientを使うと、ジェネリクスまわりでハマる

missionimpossible.jp現在上映中。本エントリはネタバレを含むので注意してほしい。待ちに待ったM:Iシリーズ6作目となるフォールアウト。今作はM:Iシリーズ総まとめのような内容であるとともに、過去作品のオマージュがふんだんに盛り込まれている。以前、1作目から5作目までの共通点や相違点をまとめたエントリを書いたので、そちらも併せて読んでもらいたい。デルブルック博士の病室交通事故で入院していたデルブルック博士は、眠りから覚め、主要な聖地が核攻撃を受けたというニュースを見る。声明文をニュースで放映する代わりに、彼のスマホにある情報にアクセスするためのコードを教えてもらうという取引をイーサンたちはする。声明文が読み上げられ、博士がコードを伝え、情報にアクセスできた瞬間に、この状況はすべてIMFによって作り上げられたものだというネタバラシがある。1作目の冒頭も似たような手法で、重要人物から情報を引き出していた。2作目でも、バイオサイト製薬会社社長のジョン・マクロイを病室のような施設で口を割らせた。ホワイト・ウィドウはマックスの娘ブローカーであるホワイト・ウィドウは、彼女の主催するパーティで演説を行っていた。その中で自分の母である「マックス」なる人物について言及するシーンがあった。これは、1作目に登場する、やはりブローカーであるマックスのことだ。立ちはだかるイルサに急ブレーキレーンを捕らえ、車で移動中のイーサンたちをイルサが襲撃する。車を猛スピードで走らせ逃走を図るが、途中、イルサが無防備に車の進路上に立ちはだかり、イーサンは車を急停止させる。5作目、デジタル金庫から盗み出すことに成功した情報をイルサが持って逃げ出してしまう。イーサンとのバイクチェイスの末、イルサはバイクから降りイーサンの目の前に立つが、イーサンは彼女を轢くまいと転倒しながらもバイクを止める。ウォーカーを走って追うイーサン捕らえたレーンを奪還され、逃走中のウォーカーをイーサンが追う。ベンジーにインカムで道案内を受け、長距離を全速力で走る。ときには段差や屋根を飛び越える。これは3作目、ジュリアを助けに急ぐシーンと同じ。そのときもベンジーから携帯電話越しにナビゲートされ、イーサンは上海の街を猛ダッシュした。離れたビルの屋上へジャンプ！が、飛距離が足りずしがみつくウォーカーを走って追っている途中、ビルからビルへジャンプするイーサン。最後のジャンプは距離が足りず、あわや転落。腕で建物にしがみつく。なんとかよじ登って、追跡を再開する。3作目、デイヴィアンを逮捕後、護送車が通る長い海上の橋でのシーンと同じ。ミサイルが打ち込まれ橋の一部が崩壊。イーサンは逃げるデイヴィアンを追って、橋に空いた穴の間をジャンプするが、距離が足りず、しがみついてよじ登った。ウォーカーを追う道中にある螺旋階段ウォーカーを追うシーンの中に、過去オマージュシーンはまだある。大きな螺旋階段を真上から写すシーンがあるが、これは1作目のイーサンやジムたちのアジトへ向かう螺旋階段と同じ見せ方だ。そして、これは微妙だが、その先にある鉄格子のようなエレベータ。1作目、プラハにあるアメリカ大使館でゴリツィンが使用したエレベータに似ている。レーンの体に埋め込んだ発信機の解説レーンは逃げてしまったが、発信機を埋め込んでいるので追えると説明するルーサー。発信機自体や、その説明内容、構図は、2作目でナイアの足首に同様の発信機を埋め込むときのシーンと同じだ。イーサンの操縦するヘリコプターの高度が下がるところイーサンは敵からヘリコプターを奪い、自身で操縦し、ウォーカーを追う。その際、ヘリコプターが高度を下げ、低高度警報が「Terrain, Terrain! Pull up, pull up!」と鳴り響く。2作目冒頭、アンブローズたちは飛行機をジャックし、最終的にその飛行機を墜落させるのだが、同じ警報が鳴り響いた。イーサンが乗っているヘリコプターが垂直に落下イーサンはヘリコプターでウォーカーに追いついたが、垂直な状態で岩場に挟まってしまう。しかしすぐに、イーサンを乗せたヘリコプターは落下。ウォーカーが乗っているヘリコプターとぶつかる。4作目、立体駐車場でのヘンドリクスとの戦い。下の階にヘンドリクスを追うため、イーサンは駐車してある車に乗り込み、車を前進させ、垂直に落下する。イーサンのロッククライミングウォーカーとの戦い終盤。尺は短めだが、2作目のアンブローズとの戦いを思わせる1対1の格闘。最後、断崖絶壁にしがみつき、得意のロッククライミングでよじ登るイーサンは、2作目でグランドキャニオンの岩山を登っていたのと同じだ。おわりに過去作品オマージュの答えあわせは、シリーズファンにはたまらない遊びだが、もちろん物語そのものもよかった。ウォーカーをハメるために、レーンのフルマスクを装着したベンジーを残すところや、それまでの話の持って行き方、M:Iらしくてよかった。潜入ミッションは簡単すぎて物足りないかな。バチカンとかクレムリンみたいなやつ、もう一度見たい。ジョン・ラークの替玉が拳法の達人すぎて引いた。他にも過去作品オマージュがあったら教えてください。

「ミッション：インポッシブル／フォールアウト」過去作品オマージュ答え合わせ

本日、30歳の誕生日を迎えました 🎉やはり、ひとつの区切り感はありますね。せっかくなので、僕のこれまでのプログラマー人生について話します。完全にチラ裏の自分語りです。ドラマチックな展開もなければ、知見も教訓もありません。ただ、昔のこと、プログラミングを始めた頃のことを思い出して整理してみたら、自分が初心に返るための便利アイテムになるじゃないかなと思い、記憶があるうちに書いておきます。簡単にまとめるとコンピュータとその面白さを知ったJavaは最高のおもちゃだった勉強会やコミュニティに参加するようになったマイナーなプログラミング言語と出会った毎日楽しくお仕事してるこれまでの人生を振り返って、一言で表すと「運がよかった」ですね。夢中になれるもの、仕事としてやっていきたいものが見つかったのは、とてもありがたいことですが、運とか偶然と言うほかありません。そして、これも運命の巡り合わせとして、いろんな人と出会いました。それが自分の人生にものすごくプラスになっていて、感謝しかありません。では本編を。以降、常体で。幼少期〜中学時代: プログラミングと出会う子供のころは、これと言って得意なものがあったわけじゃないけど、ものづくりに夢中だった。お絵かきとか工作が好きな子供だった。教育テレビのわくわくさんが大好きだった。小学生になると漫画を描いたり、RPGとかゲームの設定を考えてノートに書いたりして遊んでいた。我が家には、当時としては珍しくコンピュータがあった。しかし幼い僕はまったく興味を持っていなかった。コンピュータは、たまにお絵かきソフトで遊ぶ程度のものだった。コンピュータとか、パソコンとか、インターネットが便利なものだということが、小学生になると徐々にわかっていった。ポケモンの裏技とかを、父はインターネットで調べてくれた。中学校ではコンピュータの授業があった。とは言っても「技術・家庭」のひとつの小さな単元だ。これがまともにPCを触る初めての体験だった。教科書を見るとコンピュータの5台装置がどうのと書いてあって難解な印象があった。だいたい、この頃から自宅でのPC・インターネット利用が解禁された。親から許しが出たのだ。両手の人差し指を使ってキーボードを叩き、メールで友達と連絡をとったり、ちょっとした調べ物をしたり、ゲームなどを楽しんだ。授業とは関係なく、個人的な趣味でホームページをつくっているという同級生がいた。僕にとっては衝撃的だった。インターネットにつなげると見れる情報の詰まった画面、そういうものは専門知識を持った大人たちがつくるものだと思い込んでいたからだ。それを普通の中学生にも作れてしまうというのが衝撃的だった。中学生の僕もものづくりが好きだった。そして、当然このタイミングでホームページづくりに興味が湧いた。しかし、どう始めればいいのか見当もつかなかった。ある晩、父にホームページのつくり方を聞いた。父はPCを起動して「メモ帳」を開き、英字やら記号やらを書いていった。そして「.html」と拡張子をつけてファイルを保存し、ファイルをダブルクリックで開くとインターネットエクスプローラーが起動し、そこには「ホームページ」が表示されていた。メモ帳で書いた英字や記号のことを「HTML」というものだと教わった。その簡単なルールも教えてもらった。こうして、僕はホームページつくりに夢中になっていった。ネットサーフィンしていると、テキストや画像が動いたり、ちょっとした仕掛けがあるサイトをよく見かけた。ページ上に雪が降ったり、星がマウスポインタを追っかけてきたり、そういうやつだ。これを実現するにはJavaScriptというものを学ぶ必要があることを知った。僕はJavaScriptを修得すべく図書館に行って入門書を借りた。しかし、借りた入門書はJavaScriptではなくJavaだった。思えば、この勘違いは人生の分岐点だったかもしれない。わからないなりに入門書を読み進めた。最初の難関は環境構築だった。コンパイラをインストールしてパスを通すのに、結構苦労した。if-elseやfor, whileは楽しく学べた。条件によるループやジャンプが、楽譜の進行に似ていて面白いと思った。高校時代: クソゲー量産マシーンJavaを学んでしまったので、JavaScriptでホームページをリッチにするのは諦めた。代わりに、Javaでホームページを面白くしたいと思った。当時はまだ、いろんなところで使われていたJavaアプレットという、Webページに組み込んで動作できるJavaアプリケーションのひとつの形態があった。アルカノイドみたいなゲームや、オリジナルのしょうもないゲームをつくって、Javaアプレットとして公開していた。Javaアプレットをつくっても、それで遊べるのはPCだけだったので、学校で友達にプレイしてもらうにはハードルが高かった。なので、違う方法を模索したが、答えは近くにあった。携帯電話だ。当時、ガラケー最盛期で、誰もが持っており、授業中に着メロが鳴り出すと気まずくなったりしたものだった。僕の利用キャリアはVodafoneで、その機種はJavaのランタイムが搭載されていた。そうして、僕はVodafoneの携帯電話で動くJavaアプリケーションの開発を始めた。おそらくだが、PC上でアプリを開発して、USBか何かで携帯電話をつないでインストール＆デバッグなんてことは、できなかったと記憶している（もしくは、単に調査不足）。アプリを開発して、エミュレータではなく自分の携帯電話の上で動かすために、アプリストア（コンテンツアグリゲータと呼ばれていた）に開発者登録を行った。それからというもの、携帯電話ゲームをつくりまくって公開しまくった。アプリストアにある週間ランキングで1位を獲ったこともあった。アプリ雑誌で紹介されたり、作者インタビューとかも受けたりした。ゲームをつくって、みんなに遊んでもらうという、開発者としてはすごく幸せな体験をしていた一方、その実装はひどかった。オブジェクト指向以前の話で、データの構造化なんてしないし、メソッドさえも活用せず、巨大な神クラスが一つだけある、ひどい有様だった。public class MyGameCanvas extends Canvas {    // 敵の座標    int[] enemyXs = new int[100];  // ←java.util.Vectorが使えるの知らなかった    int[] enemyYs = new int[100];    // 敵のライフポイント    int[] enemyLifes = new int[100];  // ←こんな感じで敵に関する情報が散らばっていた    protected void paint(Graphics g) {        // ここが1000行以上とか    }}柔軟な設計とか可読性とか、全然気にしていなかった。コードをひたすら書いて、時には無知から来る車輪の再発明なんかもして、とにかく動くものをつくるのが楽しかった。そんな当時の僕の愛読書は、秀和システムの「最新Java逆引き大全 550の極意」だ。まるでゲームの攻略本のようだった。この本を読んで、Swingによるデスクトップアプリケーションの開発にも挑戦した。自分専用のPCが欲しくて、アルバイトで貯めた3万円で、中古のノートPCを買った。書籍の付録のLinuxのインストールCDを使って、Linuxを入れて遊んでいた。大学時代: Androidを始めて勉強会デビュー高校生のころ、唯一得意な科目が物理だった。興味もあったし、そういう学科に進学しようと思っていた時期もあったが、情報工学を学んだ将来の方が、高校生の僕にはイメージしやすかったので、情報系へ進んだ。とはいえ、具体的な将来の夢はなかった。なんとなくシステムエンジニアになるのかなーと思っていた。大学時代を振り返ると、もっと真剣に授業に臨めばよかったと思うけど、当時の僕にとって授業は退屈なものが多かった。だから授業の外で勉強を頑張った。大学2年の春に基本情報技術者試験に、同じ年の秋にソフトウェア開発技術者試験に合格した。資格なんて飾りみたいなものだけど、受験勉強で得た知識は、悪くないものだと思う。だいたい同じ頃、Head First デザインパターンという本を読み、オブジェクト指向プログラミングに開眼した。以来、拡張性・柔軟性、保守性・可読性に気を配ったコーディングが、僕のプログラマー人生のテーマのひとつとなっている。大学生になっても、細々とケータイアプリをつくり続けていた。ゲームのスコアをユーザ同士で競って遊べるように、ランキング機能をこのときに初めてつくった。サーバサイドはPHPで実装した。しかし、ケータイアプリでHTTP通信するには、キャリアに公式クリエータとして申請し、承認されなければならなかった。アプリ上でシームレスにランキング登録するUXを諦めて、代わりに、アプリが生成するURLをコピペして、ブラウザで開くことでランキングに登録することができる仕組みをつくった。大学3年生のとき、ゼミ的な科目を履修し、研究室を出入りするようになった。そのときの課題が卒論に続くテーマとなったのだが、それはフレームワークだった。教授からRuby on RailsとSpring frameworkを勧められて、Rubyは肌に合わない感じがして、Springを選んだ。そのとき初めてDependency Injectionというものを知った。また、同じ年（2009年、21歳）に国内初となるAndroid搭載のスマートフォン HT-03A が発売した。ガラケーでJavaアプリを開発していた僕にとって、Androidは最高のおもちゃだった。AndroidもJavaでアプリケーションを書くことができるし、（ちょっと違うけど）Java SEが載っているのがすごかった。そのときからAndroidファンであり、Android開発者だ。実際にAndroidマーケットの開発者として登録したのは、もう少し後だが、簡単なゲームをつくって公開もした。画面のタッチイベントを取れたり、各種センサーを使えるのが楽しすぎた。大学では、あまりプログラミングに熱心な友達はできず、学外でそういう仲間を見つけようと思った。日本Androidの会というコミュニティがあって、その支部である町田支部（僕の地元）の勉強会に参加したのが、初めての勉強会だ。他にも横浜支部とか、Androidデ部とか、Twitter API勉強会とかに参加した。ABCというAndroidのカンファレンスにも参加した。そこで出会った人たちとは、今も仲良くさせてもらっている。勉強会では、いろんな発表を聞いて新しい発見があるし、実際に開発を生業としているプロたちと話せるし、とても勉強になった。そして、ある欲がじわじわと湧いてきた。発表者として勉強会に参加したい、と。初めての発表は、ワイヤレスジャパンで日本Androidの会がブース出展してて、そこでのライトニングトークだったと思う。人前で話すのが本当に苦手で、ステージに立つと頭が真っ白。忘れる、セリフも時間も。これはいかん、数をこなして慣れるしかない、と思った。メインでやっていたアルバイトの他に、プログラマーとしてアルバイトを始めた。ベンチャーのゲーム会社で、少しだけ働いた。そこで身につけたAndroidでOpenGLする知識を、ABCで発表することになった（どういう経緯だったかは覚えていない）。いろいろあって留年して、大学5年生になり、卒論を終えて暇になったとき、運命の出会いがあった。Kotlinというプログラミング言語との出会いだ。2012年1月頃、ネットニュースでその存在を知り、面白さに魅了された。当時はまだコンパイラが提供されてなく、実行する環境がなかった。ドキュメントを頼りにKotlinについて調べ、ブログに書いたり、勉強会で発表したりした。そんなマイナーな言語を学んでも...という冷ややかな反応は少なからずあった。就職活動は、可もなく不可もなく、普通にスーツ来て会社を回った。SIerでのシステムエンジニアを志望していた。その中で、新卒で入った会社を選んだ理由は、僕の「技術に関心を持ち、熱心に取り組んでいる姿勢」を評価してもらったからだ。そういうこともあって、仕事が楽しみだった。新卒SIer時代まぁ普通の大企業。立派な内定式、入社式を経て3ヶ月間の新人研修。新人研修は楽しかった。同期も多く、まるで学校だった。今でも飲みに行くような友達ができた。ただ、覚悟はしていたが、やはり内容はJava入門みたいなやつが多かった。講師が間違えることもあった。新人研修のカリキュラムに、Androidアプリ開発の実習が2日間 組み込まれていたのを知り、担当講師に連絡を取り、僕に講師をやらせてください！と申し出た（今思うと若さってスゴイなぁと思いつつも、ほめてやりたくなるｗ）。結局、講師をやらせてもらえなかったが、代わりに10分くらい時間をもらって発表することができた。これは数少ない自慢話なのだが、研修の修了式で、最優秀受講生として表彰され、社内報に掲載された。研修が終わり、配属部署でOJTで働くことになったが、なんやかんやあって転職したくなった。やはり、人生初の転職は勇気が必要だった。あれこれ悩んだ。いろんな人に支えられ、転職活動は成功した。その間もKotlinエバンジェリストとしての活動は継続していて、初めて雑誌に寄稿したりもした。エムスリー時代実務でのプログラミング経験はほぼ皆無な状態でエムスリーに入社した。僕が入社してまもなく、Androidアプリの新規開発のプロジェクトが発足し、主担当として参加できた。つまり、僕にとっては初陣。初めて仕事でAndroidアプリを開発するのがすごくエキサイティングだった。以降、このアプリを軸に、エムスリーではいろんな仕事をした。詳細は退職エントリを参照してほしい。taro.hatenablog.jpエムスリーにいた4年半でいろんなことが起こった。Kotlinが正式リリースされ、しかもAndroidの公式言語となった。もちろん、その間 ずっとエバンジェリスト業は続けていた。相変わらず勉強会でKotlinの良さを発表を継続していた。もう本当に呆れるくらい。Kotlinなんか流行らないんじゃないかと思ったこともあった。しかし、大きな盛り上がりか何度かあった。その最初のきっかけは、@kiriminさんのブログかもしれない。kirimin.hatenablog.comそして、DroidKaigiの誕生。ありがたいことに、2015年の第1回の開催から今年まで、毎回 登壇者として参加させてもらっている。まさにKotlinをアピールする絶好の機会だった。SoftwareDesignで短期連載をやらせてもらったり、単著執筆の機会も与えられた。Kotlinが普及すると、夢のひとつだった「Kotlinを仕事で使う」が現実になった。そして、それまでとは変わり、Kotlinが一人歩きするようになる。つまり、僕の関わらないところで勉強会が開かれたり、ということ。Kotlinファンは、確実に増えていった。Ubieに入社して現在エムスリー元同僚の久保からの誘いで、彼が共同代表を務めるUbie（ユビー）という会社への転職を決めた。taro.hatenablog.jp毎日が充実していて、すごく楽しい。休日は休日でエンジョイするが、月曜を本当に楽しみにしているくらいだ。Kotlinエバンジェリストとしての活動も継続している。昨年のKotlinブームは落ち着いて、もはや定番な言語となった感はあるが、現在も執筆や講演の依頼はあるし、意欲的に取り組んでいる。今年の8/25にはKotlin Fest 2018なる1day カンファレンスを開催する。kotlin.connpass.com運営を手伝ってくれる仲間も増えて、これからもKotlinは盛り上がり続けるだろう。ということで、今日僕は30歳になった。ものづくりが好きで、偶然にもプログラミングと出会い、おっちょこちょいにもJavaの入門書を読み始めた少年だったが、ひたすらコードを書き、いろんな人と出会い、機会が与えられたおかげで今の僕がある。本当、すべてのものに感謝。次の10年はどうなることやら。そういえば、昨日 結婚しました。

30歳になりました！

本邦初！Kotlin 1day 技術カンファレンスKotlin Fest 2018 を開催します！！日程2018年8月25日 土曜日会場東京コンファレンスセンター品川 5F主催日本Kotlinユーザグループコンテンツ2トラック 10セッション、企業展示ブース（予定）Kotlin Fest 2018 は「Kotlinを愛でる」をビジョンに、Kotlinに関する知見の共有と、Kotlinファンの交流の場を提供する技術カンファレンスです。プログラミングをより楽しくしてくれるKotlinへの関心は日々高まっており、それが本イベントの開催へと繋がりました。Kotlinの技術にフォーカスしたコンテンツを取り揃えることで、参加者の皆様にKotlinをより深く学んでいただき、そして、よりKotlinを好きになっていただけるイベントにするべく、企画を進めております。2018年の初めに開催されたAndroid業界のトップエンジニア1000名以上が参加する技術カンファレンス「DroidKaigi 2018」のオープニングで、本イベントの開催をサプライズで告知しましたが、Kotlinの応用分野としてはAndroidだけではなく、サーバーサイドなど幅広い分野での活用が期待されており、本イベントも様々な分野の開発者の参加を想定しています。DroidKaigi 2018でのサプライズ予告今後のスケジュールとしては、近日中のイベントページの公開を目指しております。そして、参加申込の開始は7月中旬を予定しております。スピーカーは全員、企画・運営チームによって招待させていただいたエンジニアの方々となります。一部の時間を使って、ライトニングトーク大会のようなものを計画中で、こちらのスピーカーは公募を行う予定です。あわせて、当日のボランティアスタッフの募集も行います。詳細は追ってご案内いたします。また、本イベントに協賛いただける企業様の募集を行っております。名称壇上バックパネルに貴社ロゴブース出展 or ノベルティ等の配布イベントWebサイトに貴社ロゴ無料参加枠ことり○○○5名ひよこ××○1名ありがたいことに「ことり」スポンサーについては、すでにいくつかお申込みをいただいております。定数に達しましたら「ひよこ」スポンサーをご案内させていただくかもしれませんが、よろしくご検討いただけますと幸いです。ご好評につき「ことり」スポンサーは申込を締め切りました。「ひよこ」スポンサーは引き続き募集していますので、ご検討をよろしくお願いいたします。お問い合わせは japan-kotlin-user-group@googlegroups.com までお願いいたします。日本Kotlinユーザグループとしては、初めての大規模イベントですので、至らぬ点もあることと存じますが、みなさまのご理解とお力添えを賜りますよう、よろしくお願い申し上げます。Have a nice Kotlin!Kotlin技術カンファレンス「Kotlin Fest 2018」は8月25日(土)に開催します！会場は東京コンファレンスセンター品川で、参加者数350人を予定しています。イベントページは近日中に公開予定です！ pic.twitter.com/xaZ1mpdmCL— Kotlin Fest 2018 (@kotlin_fest) 2018年6月25日

Kotlin Fest 2018 開催のお知らせ #kotlinfest #jkug

JetBrainsのDeveloper AdvocacyであるHadi HaririさんがGoogle for Mobile I/O RECAP 2018のために来日するということで、Hadiさんはもとより、Googleさんにもご協力いただき日本Kotlinユーザグループによるイベントを6/27に開催しました。kotlin.connpass.com僕自身はあまり運営を手伝えなかったのですが、ライトニングトークをしてきました。下にあるのがそのスライドです。Spring Fuという、Springの新しいプロジェクトを使って、GraalVMの上で動かしたいという旨の発表でした。Now listening to the awesome @ngsw_taro on running Spring Fu on GraalVM. pic.twitter.com/cV1p8B1UYx— Hadi Hariri (@hhariri) 2018年6月27日Spring FuSpring Fuは、Kotlin向けのマイクロ・フレームワークで、Sparkや、Spring 5のFunctional Bean Registrationを思わせるAPIが提供されています。始めるのは簡単です。公式ドキュメントから、プロジェクトの雛形がダウンロードできます。入手したzipファイルを展開して、それをIntelliJ IDEAなどのエディタで開けば、開発を始められます。初期状態のまま./gradlew bootRunするとHelloWorld Webアプリケーションが起動するので、http://localhost:8080をブラウザで開くと「Hello world!」と表示されます。公式ドキュメントを参考に、DI機能を試してみます。package com.exampleimport org.springframework.fu.applicationimport org.springframework.fu.module.webflux.netty.nettyimport org.springframework.fu.module.webflux.webfluximport org.springframework.fu.refclass HelloService {    fun hello(): String = "Hello world!"}val app = application {    // bean登録    bean<HelloService>()    webflux {        server(netty(8080)) {            routes {                // beanのインジェクション                val helloService = ref<HelloService>()                GET("/") {                    val body = helloService.hello()                    ok().syncBody(body)                }            }        }    }}fun main(args: Array<String>) = app.run(await = true)これ、うまく行きそうなんですが、アプリケーションを起動しようとすると失敗します。そのときに吐かれる例外メッセージはこんな感じです。Exception in thread "main" org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'webHandler': Unexpected exception during bean creation; nested exception is kotlin.UninitializedPropertyAccessException: lateinit property context has not been initializedlateinit付きの遅延初期化されるプロパティcontextが、初期化されていないのにアクセスがあったようです。丁寧に調査してから、修正してプルリクエストを送りたいところですが、さしあたり、次のコードでこの問題を回避できます。package com.exampleimport org.springframework.fu.applicationimport org.springframework.fu.module.webflux.netty.nettyimport org.springframework.fu.module.webflux.webfluximport org.springframework.fu.refclass HelloService {    fun hello(): String = "Hello world!"}val app = application {    // bean登録    bean<HelloService>()    webflux {        server(netty(8080)) {            routes {                // ↓の1行を追加する                this.context = this@server.context                // beanのインジェクション                val helloService = ref<HelloService>()                GET("/") {                    val body = helloService.hello()                    ok().syncBody(body)                }            }        }    }}fun main(args: Array<String>) = app.run(await = true)GraalVMこれはオマケなんですが、Spring Fuで作ったWebアプリケーションをGraalVMで動かしてみたいと思いました。特にAOTコンパイラで、ネイティブの実行バイナリを作って、それを動かせたらすごいなぁと考えていました。GraalVMには、Community Edition（CE）とEnterprise Edition（EE）の2つのバージョンが提供されていて、今回はCEを使いました。CEは現在のところ、Linux上でしか動作せず、Macで直接動かすことはできないようです。そこで、rayyildiz/graalvmというDockerイメージを使いました。また、GraalVMのAOTコンパイルを行うコマンドnative-imageが依存するパッケージをインストールする必要があります。gccとzlib1g-devです。結論から言うと、Spring FuアプリケーションをAOTコンパイルすることはできませんでした。コンパイルに失敗します。試してから気づいたのですが、Spring Fuのissueとしてすでに登録がありました。github.comHadiさんと食事行ってきましたHadiさんと山本ユースケさんと食事に行ってきました！With @yusukey and @ngsw_taro who was using Kotlin before Kotlin, i.e. forever... pic.twitter.com/CstpTP4QGm— Hadi Hariri (@hhariri) 2018年6月29日Kotlin Fest 2018やります！！！詳細は近日発表予定です！！！！Kotlin技術カンファレンス「Kotlin Fest 2018」は8月25日(土)に開催します！会場は東京コンファレンスセンター品川で、参加者数350人を予定しています。イベントページは近日中に公開予定です！ pic.twitter.com/xaZ1mpdmCL— Kotlin Fest 2018 (@kotlin_fest) 2018年6月25日

Kotlin Developers Meetup #jkug でSpring Fuの紹介LTをしたよ〜

「ミッション：インポッシブル」シリーズ（以下M:I）の新作が8月3日に日本で公開される。今から楽しみにしているので、このワクワク感を共有したく、M:Iについて雑に語ってみる。M:Iの見所といえば、アクションシーンはもちろんのこと、どういう分厚いセキュリティが施されていて、それをどう破るか。どういう作戦を立てて、どう相手を出し抜くか。ここらへんがとても面白い！セキュリティは時代とともに進化しており、回を追うごとに「インポッシブル」感は増すが、主人公たちが使うガジェットもまた進化している。こういう大きい観点から、あまり注目されないような小さい観点まで、いろんな切り口で過去のシリーズを振り返ってみたい。当然ネタバレを含む。まだM:Iを見ていない人は注意されたい。あと、何かを主張したいわけではないし、多分に主観が含まれるかもしれない。同じようにM:Iが好きな人がニヤッとしてくれたら嬉しい。なお「スパイ大作戦」は観たことがなく言及していないので悪しからず。潜入ミッション物を盗み出したり、重要人物を誘拐したりするため、主人公 イーサン・ハント率いるチームは、堅牢なセキュリティに守られた施設に潜入する。これは、どの回にも必ず一度はある。1作目: CIA本部1作目は、CIA本部への潜入。イーサンたちはIMF（Impossible Mission Force）というCIAのスパイ組織のエージェントであるのだが、彼らは言わば自分たちの本拠地への潜入を企てる。消防隊になりすまし潜入し、NOCリストなる電子データの入手を狙う。イーサンがロープ一本で宙吊りになり、床すれすれに水平になるシーンは有名だろう。2作目: 製薬会社2作目は、製薬会社への潜入。敵が狙っているウィルスの培養施設があり、これを破壊することが目的だ。建物の屋上から潜入するため、ヘリから飛び降りるのだが、ここでもイーサンの宙吊りシーンが見れる。3作目: バチカン市国3作目は、バチカンとそこで開かれるパーティーへの潜入。ここらへんから潜入ミッションが大掛かりになってきたと思う。イーサンは忍者のようにバチカンを覆う塀を駆け上り、ロープをくくって、塀の内側へ垂直に飛び降りる。ここがまた、お約束の宙吊りシーンである。敷地に忍び込んだあとは司祭に扮して施設に潜入。チームメンバーと協力して裏社会のブローカーであるデイビアンを誘拐するため準備を整える。4作目: クレムリン4作目からナンバリングをやめて、副題を付けるようになった。同作の副題は「ゴースト・プロトコル」。ロシアの世界遺産であるクレムリンへ、軍の偉い人になりすまし潜入。そして、物語の後半ではムンバイの富豪の家に潜入し、チームメンバーの一人であるブラントがサーバルームへ向かうが、その途中にブラントは高所からジャンプし、宙吊りシーンを見せてくれる。5作目: デジタル金庫5作目「ローグ・ネイション」では、デジタル金庫に潜入する。かなり困難なミッションであるのだが、3作目や4作目の潜入と比べるとワクワク感は劣る。なお、5作目には宙吊りシーンがない。ミッションの受け取り方ミッションの受け取り方も、M:Iを観る上で注目したいポイントだ。ほぼすべてに当てはまる共通点は2つ。任務上でエージェント自身に起こる逮捕や殺害などの不利益について当局は一切関知しない旨の免責説明があるミッションを伝える媒体や装置が自動的に破壊される1作目: 機内サービスの映画1作目だけ、ミッションを受け取るのはイーサンではない。IMFスパイでイーサンの同僚であるジムが、飛行機内の座席でCAから映画を勧められる。その映画にミッション内容が記録されており、再生が終わると静かに爆発。立ち上る細い煙を、自分が吸う煙草の煙で隠すのだが、今の感覚では機内で煙草を吸えるのがすごい。2作目: サングラス休暇中のイーサンのもとに、おそらくIMFの人間がサングラスを届ける。それをかけると、映像と音声によりミッションが伝えられる。サングラスを外し、投げ捨てるとともに、わりと派手に爆発。かっこいい。あの音楽でオープニングが始まる。3作目: 使い捨てカメラ呼び出されコンビニに向かったイーサンは、上司であるマスグレイブに、捕らえられた仲間の奪還を依頼される。店内で販売されている使い捨てカメラのひとつを買うよう示唆し、マスグレイブは立ち去り、イーサンはそのカメラを購入して帰宅する。部屋で一人、使い捨てカメラのファインダーを覗き込むと、映像と音声とともにミッション内容が伝えられる。その後、静かにカメラは爆発する。4作目: 公衆電話車で移動中、古びた公衆電話に立ち寄る。イーサンが受話器を取り、番号をプッシュする。そして、虹彩認証をすると音声と、液晶画面に映る映像でミッション内容が伝えられる。いつもどおり「5秒で消滅する」と言われ、公衆電話から離れる5秒経っても爆発しない。イーサンは再び公衆電話に近づき、小突いて爆発させる。ミッションを伝える装置を手動で壊すのは、これが最初で最後だ。5作目: レコードイーサンはレコード店に立ち寄る。女性店員から営業終了だと言われるが、イーサンはレコードを探しており、それに関して会話が続く。一連のやりとりが鍵となり、女性店員からミッションが記録されたレコードをイーサンは受け取る。試聴室でレコードをプレイヤーにセットし、再生する。通常通りミッションが伝えられると思いきや、イーサンのターゲットであるテロ組織からのメッセージだった。このパターンも初めて。IMFの協力を得られない2作目を除いて、イーサンのチームはIMFの協力を得られない状況に立たされる。限定されたリソースで不可能なミッションに立ち向かう。ドラえもんの映画で、使える秘密道具に制限があるようなものか。1作目: 二重スパイの濡れ衣を着せられるジム率いるIMFチームのミッションに、イーサンも参加していた。そのミッションは、IMFの裏切り者をあぶり出すためのミッションだった。そして、ミッションが始まってみると次々とメンバーが殺害されていき、唯一の生き残りがイーサンだった。イーサンはミッションの失敗を報告し、CIAのキトリッジと落ち合ったが、彼に裏切り者として疑われる。イーサンは真の裏切り者を探すために、少人数のチームを結成する。3作目: IMF局長に指名手配にされるIMFのブラッセル局長は規律に厳格だ。IMF内部に裏切り者がいる予感がして、特に警戒していたのかもしれない。イーサンの仲間奪還の作戦が失敗し、それについてブラッセルは酷評した。とにかくブラッセルはイーサンに非協力的だった。4作目: ゴースト・プロトコルの発令クレムリンの爆破事件の犯人として、イーサンたちがロシア政府から疑われていた。アメリカ側の関与を否定するため、アメリカ大統領は「ゴースト・プロトコル」を発令し、IMFは組織機能を停止する。イーサンはテロリストとして指名手配される。5作目: CIAとの統合クレムリンの爆破事件や、核ミサイル発射事件についてCIAのハンリー長官は、イーサンやIMFのやり方に是正を求め、IMFがCIAへ取り込まれることになる。イーサンに責任を取らせるため、彼を指名手配に。敵が同業者イーサンの敵となる人物は、4作目を例外にすべて同業者、すなわち諜報員や工作員だ。1作目: 黒幕は同僚キトリッジが探していたIMFの裏切り者は、イーサンの同僚のジムだった。2作目: 元IMFのスパイもしかしたら、一番しょうもない敵キャラかもしれない。アンブローズは元IMFのスパイで、バイオサイト製薬会社の株を脅し取り、ここしか持っていない治療薬を売るためにウィルスを世界中にばら撒く計画を企てていた。3作目: 直接の上司デイビアンはわかりやすい敵で、ブラッセルが黒幕なのかと思わせといて、真の黒幕はマスグレイブ。最期はあっけなかった上、倒したのはイーサンではなく、その妻ジュリアだ。5作目: 英国の元スパイソロモン・レーンはテロ組織シンジケートの長で、元MI6のスパイだ。1作目から3作目のラスボスは死亡したし、4作目のラスボスもきっと死んだんじゃないかな。だが、レーンは存命のまま逮捕された。この終わり方はすごくかっこよかった。捕らえられたレーンに向かって、イーサンが「悔しいだろ」と言うシーン、痺れる。好きな脇役やはり主役のイーサンは好きだし、その仲間たちも好きだ。仲間で言うと、特にベンジー、ブラントが好き。4作目のブラントはただの分析官かと思われていたが、元諜報員で強い。イーサンが悟空ならブラントはピッコロ、くらいの安心感がある。5作目ではブラントは戦いには参加していないのが残念だった。役名登場作品解説・感想ジャック1イーサンのチームのハッカー。いいキャラしてる。序盤で死ぬけどもっと長く登場してほしかった。クリーガー1ジャン・レノが演じる敵サイドの人物。キトリッジ1役というよりも俳優が好き。ビリー2イーサンのチームメンバー。陽気なキャラ。この人ももっと出番増やしてほしかった。アンブローズ2悪の親玉としては器が小さいキャラ。役よりもこの俳優の顔とか声とか喋り方がよかった。ハナウェイ4回想シーンの中でしか登場しないキャラ。かっこいいイルサ5M:Iシリーズの中でトップクラスの美人かもしれない。1作目のクレアも美人。レーン5あの声が最高。吹き替え版はおすすめしないやつ。全体を通して一番好きなのは3作目かもしれない。3作目から登場人物が安定してくる。イーサンはもちろんだが、ルーサーは毎回登場している。が、これはある種のお約束的なやつ。ベンジーは3作目から毎回登場しているし、ブラントは4作目と5作目で登場している。馴れ親しんだキャラが登場するのは嬉しいし思い入れも強くなるが、あまりそれに傾くと新鮮さが失われるおそれがある。1作目も好きだが、他の作品と比べて派手さに劣る。2作目はあまり好きじゃない。2作目にして、なんと言うか、世界観が変わったかのような印象を受ける。もしかしたら短髪のトム・クルーズが好きなだけかもしれない（1作目はさわやか短髪、2作目はチャラロン毛）。フルマスク、チートアイテムのような気がしなくもないけど、やはり出てくると面白い。2作目なんかはフルマスクゲーだわ。そういえば、イーサンが公衆電話からIMFに連絡を入れるときのコードが「ブラボー・エコー・ワン・ワン」で、これは1作目と5作目に出てくるのだが、これを知っていて5作目を観た人はニヤッとしたかもしれない。ということで、だらだら書き綴ったが、M:Iの面白さを普段とは違う観点で感じることができただろうか？新作である6作目がこの夏に公開される。筆者は前情報は一切知りたくない人なので、キャストやらポスターやらが公開されているかもしれないが、まったく見ていない。次回作はどういう困難があって、どういう仲間がいて、どんなガジェットで、どんなミッションをするのか、今から非常に楽しみである。

新作が楽しみだから「ミッション：インポッシブル」についてチラ裏

5月1日付でUbie（ユビー）というAI医療のスタートアップに入社します！www.company.dr-ubie.comUbieってどんな会社？Ubieは、医療にコミットする会社です。その掲げるミッションは「医療と人々の医療情報格差をなくすために誰でも自分にあった医療にアクセスできる世界をITによって実現可能なものにする」です。医療に関する情報を持っている人とそうでない人、健康に対して意識の高い人とそうでない人がいて、その差をITの力で埋めたいと考えています。例えば、症状を自覚していても、きっと大丈夫だろうと放置してしまい、実は重大な病気だった、ということは珍しいケースではないでしょう。「きっと大丈夫だろう」という思いの裏にあるのはコスト意識で、医師にかかるためのお金であったり、時間がなかったり、単純に面倒に感じているかもしれません。この経済的、物理的、あるいは心理的なハードルを下げて、人々に自分の健康に向き合うお手伝いをしたいと思っています。適切な医療にアクセスすることも大切です。何かあったらすぐに病院に行くのは、安全側に倒しており、間違いがないように思えます。しかし必ずしもそうだとは言えないのではないかと思っています。例えば咳や発熱を感じ、病院に行って、数十分間を待合席で過ごし、風邪と診断されて薬をもらい、数千円を支払う。自分で風邪だとわかれば、ドラッグストアへ行き、同じ薬をより安く入手でき、時間も取られません。医師や病院側の視点に立つと、もっと他の優先度の高い患者や業務にリソースを割きたいところですし、国の視点では医療費の負担という点で、登場人物全員にとってメリットがなさそうです。とはいえ、専門家でない一般の人が自分の病名を判断したり、病院に行くべきか行かざるべきかを判断するのは実際問題、難しいです。このような課題をITで解決するのが、Ubieのミッションです。現在提供しているサービスは2つあって、1つは「Dr. Ubie」という、入力された症状から関連性の高い病名を提示するアプリです。体調に異変を感じたら「きっと大丈夫だろう」で終わらせずに、気軽にDr. Ubieを使って、どういう病気なのか、どういう薬を飲めばいいのか、安静にすれば十分なのか、病院に行くべきなのかといった提案を受け、次の行動につなげていただきたいと思っています。Dr. Ubieもう1つのサービスは「AI問診Ubie」という紙の問診票を置き換えるサービスです。医師は実は電子カルテの入力にリソースの大部分を取られているのですが、AI問診Ubieは問診情報を医師の言葉に翻訳し転記しやすい形で提供するので、電子カルテ入力の時間を大幅に減らし、病院の待ち時間が長く、診察時間は短いという問題の解消に寄与します。また、Dr. Ubieと同様に問診情報から関連性の高い病名を提示し、さらに病名に関するガイドラインなどの情報も閲覧でき診療のサポートとなります。AI問診Ubie将来的には、世界中から医療情報格差をなくして、何らかの理由で病院に行かない・行けない人たちの手助けをします。そして、医師などの専門家のリソース効率を最大化し、医療の発展に貢献します。それがUbie株式会社の使命です。Ubieに入社した理由きっかけは、Ubie共同代表取締役の一人である久保（通称「くーぼ」）に誘われたことです。症状から関連性の高い病名を提示するという、すごくシンプルだけど、誰も実用可能なレベルで実現できていないアイデア。これが、医療や世界中の人々へ貢献するポテンシャルは計り知れません。前職のエムスリーで医療に携わっていたこともあり、人々の健康を守る、命を守る、そういうことのためにプログラミングをし続けたかったし、くーぼやその仲間たちと一緒に未来を創っていきたいと思ったのが決め手です。左から阿部、長澤、久保もちろん夢が大きいだけでは、健康を守ることはできません。Ubieの、入力された症状から関連性の高い病名を提示する仕組みは、くーぼや阿部（もう一人の共同代表取締役）の血の滲むような努力の結晶と言えます。彼らは学生の頃から論文や書籍を地道に読み漁り、データを蓄積し、アルゴリズムを調整してきました。そして、優秀な社員と社外の協力してくれている人たち。彼ら彼女らのスキルやマインド、経歴、人柄が眩し過ぎて自分が恥ずかしいくらいです。このチームなら大きな夢の1つや2つは叶いそう！というくらい本気で取り組んでいます。なんか他力本願な表現っぽくなったからあえて言うけど「この俺が来たおかげだぜ！」と言えるように私も全身全霊を捧げて貢献します。ところで、私とくーぼの出会いは3年前くらい、2人ともエムスリー社員だった頃。くーぼは学生時にインターンシップとしてエムスリーでマーケティングの仕事をしており、新卒で同社にエンジニアとして入りました。バイタリティに溢れており、自ら声をかけて様々な人とランチへ行ったり、飲み会を企画したりして、そういうあれの中で私はくーぼと出会ったのだと思います。その個性的なキャラクターと、新卒の後輩というステータスがあいまって、なんていうか、かわいい存在（）でした。そんな彼が今は私の雇用主になるとは、予想だにしていませんでした。Ubieでやること一応、ポジションはバックエンドエンジニアとしての役割を期待されて入社することになったものの、Ubieはまだまだ小さい会社なので、自分の活躍の幅を狭めるようなことはせず、フルスタックで頑張りたいと思います。バックエンドエンジニアとして期待されている大きな仕事のひとつとして、入力された症状と関連性の高い病名を提示するAPIのリプレースがあります。現在Ruby on Railsで開発されているものを、Kotlinで置き換え、早い段階から静的型付け言語の恩恵を受けて、メンテナビリティを維持しながらも爆速開発をしていくことが狙いです*1。しかし当面は、Dr. Ubie すなわちAndroidアプリの改善にリソースを割くことになると思います。すでにKotlinで実装されているアプリで、この機能追加、UX改善、リファクタリングを持ち前のKotlin力とAndroid力で進めていきます。将来的には、技術者としてUbieをリードできるような存在になりたいです。まとめやっぱり医療って大事なのでUbieという会社に入って偉大なるジャーニー...未来へのジャーニー...One more thing...We're Hiring !　このジャーニーには仲間が必要だ！www.wantedly.com*1:実際には、まだどういう技術を使うかも決まっていません。検討するのも楽しみです。

Ubie株式会社に6人目の社員としてジョインします！

タイトルのとおり、今年の4月末をもって、4年半在籍したエムスリー株式会社を退職します。いわゆる退職エントリで、エムスリーへの感謝の気持ちを込めて、また自身の決意の表明として書きました。エムスリーが長澤太郎を育てた私は大学卒業後、メーカー系SIerにおいてSEとしてキャリアをスタートしました。いわゆる「SE」よりもプログラマーを志望していた私は、その1年半後である2013年10月にエムスリーへ転職しました。エムスリーとの出会いは、面白い偶然なのですが@yusukeさんに紹介されたことです。当時と比べると今は、エムスリーの知名度はエンジニア界隈に広まりつつあると思いますが、私はそのときに初めてエムスリーという会社を知りました。エムスリーは、医療への貢献を使命とする会社です。「インターネットを活用し、健康で楽しく長生きする人を一人でも増やし、不必要な医療コストを一円でも減らすこと」をスローガンとして掲げています。それまで「医療」について真剣に考えたことのない私にとっては、その事業の意義をあまり理解できてはいませんでしたが、それでも、世のため人のために自分の能力を活かせるかもしれないと思ったのがエムスリーに決めた大きな理由のひとつでした。そしてもうひとつの理由ですが、それは優秀なエンジニアが多数在籍しているということでした（もちろんエンジニア以外の職種の人たちも凄腕のプロ集団です）。「情熱プログラマー」に「チームの一番の下手くそでいよう」という教えがありますが、これを実践できる場だと思いました。つまり、エンジニアが皆優秀であり、全員を師匠にできる、そんな環境に身を置くことで成長できると思っていたのです。そして、入社から4年と6ヶ月。この狙いは功を奏しました。「エムスリーが長澤太郎を育てた」と言っても過言ではありません。エンジニアとしての実務経験がゼロに等しかった私を、ただ趣味でAndroidアプリを作って、Kotlinとか言うマイナーな言語（当時）が好きな変なやつを、採用してくれて、チャンスをくれて、育ててくれたエムスリーには、感謝してもしきれません。退職理由きっかけは、友人の会社に「誘われたから」です。次のステップを探していたわけでも、会社を去りたいと思っていたわけでもありません。誘われて、話を聞いてみたら、夢があったから。それが退職の理由です。次の会社のことは、またの機会にブログに書くと思います。エムスリーでやったこと「m3.com」というエムスリーの主力サービスのAndroidアプリの開発を行いました。2014年6月にリリースして以来、現在も機能追加やUX改善を続けています。「MR君」という医薬品情報提供サービスのAndroid版のリニューアルを行いました。フルKotlinで実装しました。アプリで重要なプッシュ通知システムの開発も行いました。Spring Bootを使って、マイクロサービス的に各サービスが協調して、iOSやAndroid、あるいはServiceWorkerを実装したWebブラウザに向けてプッシュ通知を送信します。医薬品開発で重要である「治験・臨床研究」を効率化するサービスの開発にも携わりました。治験に参加可能な患者を探すのは人手で行われているのですが、電子カルテから匿名化した情報を収集し、条件に合う患者を検索可能にするというサービスです*1。薬の開発期間の大幅な短縮や、薬の低価格化の実現に寄与します。私の担当範囲ではRuby on Railsを使用していました。また、治験をサポートする別のサービスの開発にも携わりました。これは治験に関するデータの確認作業の非効率な部分をITで解決するというもので、クライアントとしてAndroidを、サーバにはScalaでSkinny Frameworkを使用しました。公表できる主なプロジェクトは以上ですが、開発以外では、社内技術勉強会（M3 Tech Talk）のオーガナイザをやったり、エンジニア採用の手伝いをしたり、インターンや新卒入社のエンジニアのメンターをやったり、エムスリーの看板を背負って社外で講演をしたりしました。エムスリーのエンジニア採用は、現場のエンジニアが主体となり活動しています。人事やエンジニアリンググループのマネージャーのバックアップを受けながら、カジュアル面談やイベントで、候補者の方たちと直接コミュニケーションを取り、お互いの魅力を共有することで、マッチ度の高い採用を目指しています。私自身、エンジニア採用を通じて社内外でたくさんのつながりを作れたと思っています。また、自分の会社を相手に伝えるために、会社を見つめ直すことで、新しい気づきが得られるとともに、改めて自分の仕事の意義を確認することができました。会社や環境・制度についてエンジニアにとって働きやすい会社です。メンバーが自律しているからマネジメントがほぼ不要なレベルで、自由に動けます。机は広いし、椅子も快適。これは結構気に入ってる社風なんですが「正しい論理が通る」んです。誰が言ったかではなく、何を言ったかが重視されます。私が歴史ある日本的企業にいたからなのか、ちょっとした衝撃がありました。勢いだけで語るおじさんに、理路整然とした若者が勝つ。当たり前のことかもしれませんが。もうひとつ、社風というか社内文化としてROI（Return On Investment: 投資利益率）という言葉や考え方がキーワードのように連呼されていました。非常にコスト意識が高く、無駄な物は買わない、無駄な作業はしないということが徹底されていました。逆に投資額（コスト）が大きくても、それに見合った大きなリターンが見込めるのであればGOという感じでした。創業以来の連続増収増益の秘訣はこのROI重視の姿勢なのかもしれません。人事評価について。期初に3〜5つほど目標を立てて、期末に実績をまとめて報告し、さらにいわゆる360度評価*2と隠れパラメータ*3が加わって、その期の評価が決定します（たぶん）。私はこれまで8回、評価を受けてきましたが、不満に思ったことはありません（これは本当）。良い評価のときは素直に嬉しいし、まずまずの評価でも納得感のある内容でした。評価が良ければ報酬はちゃんと上がっていきます（私の入社時の期待が低く見積もられていた説もありますが）。イマドキ当たり前かもしれませんが、技術カンファレンスなどに出勤扱いで参加できます。参加費用の一部補助もあります。私が去年のKotlinConf（サンフランシスコ）へ行けたのも、この制度のおかげです。有給休暇は取りやすいです。ディズニーランドが好きな私としては非常にありがたいです。イベントの最終日（これが盛り上がるんだな）に、よく休みを取って遊びに行ってました。プロジェクトによるけど残業もそんなにないと思います。一応17:45が定時ですが、私はここのところ定時から、遅くとも18:30には退勤しています。朝が苦手な人や夜の方がパフォーマンス出る人は遅く残っていたりしますが、それでもオフィスは20:00になるとだいぶ静かになります。おわりにこの4年半、仕事でもプライベートでもたくさんのことがありました。成長を実感しているし、良い仲間とも出会えたし、何より楽しかった！エムスリーの皆様には本当にお世話になりました。改めて感謝を申し上げます。送別会でオリジナルクッションをいただきました（左）M3エントランスで記念撮影（右）最後にお約束の干し芋を晒して終わりにしたいと思います。@yusukeさんからは、すでにビールをお祝いにいただきました〜！ありがとうございます！（これは干し芋ではなく、gifteeという素敵なサービス経由です）お祝い ありがとうございます！転職のお祝いをいただきましたので、ご紹介させていただきます（順不同）。読みたかった本や、私のコーディングの燃料であるビール、猫用品、AmazonギフトカードやKyashでの投げ銭などをいただきました！みなさま、ありがとうございます！@yy_yankさん/ @vvakameさん/ @zaki50さん/ @ytRinoさん/ @RyotaMurohoshiさん/ @hyperkinokoさん/ @zinbeさん/ @raindrop_naoさん/ @MoyuruAizawaさん/ @konifarさん/ @eiryuさん/ @mame_pikaさん/ @zer0_uさん/ @suusan2goさん/ @seratch_jaさん/ @keianaiiさん/ @maeharinさん/ @ma2geさん/ @kikutaro_さん*1:日経新聞 2016年1月14日朝刊で紹介されています。*2:同僚からの、感情や主観を排除したファクトベースの実績や行動の報告を元に評価されるシステム。*3:怪しい表現ですが、要するに個人ごとに考慮すべき事情。

エムスリーを退職して新たなる挑戦へ！

droidkaigi.jpDroidKaigi 2018に参加してきました！KotlinがAndroid公式言語になってから初めてのDroidKaigi。そういうこともあって、多くの発表のデフォルト言語としてKotlinが使われており「Android界隈でKotlinはもはや普通なんだなぁ」と感じました。そんな中、私は「はじめてのKotlinハンズオン」というタイトルでハンズオン講師を務めました。去年の反省を生かし、大きくスコープを削って、Kotlinの本当に入門的な部分にフォーカスしました。簡単に振り返るとよかった点参加者に難しい印象を与えず、内容を理解していただけた開発環境としてWebブラウザで使用できるTry Kotlinを採用したため参加者の事前準備が不要で、負担を減らすことができた当日の環境トラブルがなかった課題の解答例を、すぐに実行できる形で共有できた発表前にスライドを公開したので、それを見ながら復習しつつ課題に取り組んでいただけた改善が必要な点セッション開始まで、プロジェクターへの接続状態を維持すべき接続＆投影テストで問題なかったため安心して切断して待機。開始直前に再接続したら正常に投影されるまでに時間がかかったスライド。ご活用くださいスライドを貼っておきます。入門者向けハンズオンをより頻繁に、多くの地域で開催したいのですが、私一人では物理的に厳しいので、よかったら、このスライドを使ってハンズオンを開催してみてください！Kotlinカンファレンス in Japan やるぞ！「やる！」と、宣言してきました！！オープニングで突然呼び出され、ババーンと！（珍しく緊張してました）しかし、何もかも未定。決まり次第、追ってアナウンスします。チェケラ！！！DroidKaigi 楽しかったです！ドロイド会議、最高と言わざるを得ない— たろう (@ngsw_taro) 2018年2月8日メルカリTシャツもらった！！ pic.twitter.com/8K1C4asCSh— たろう (@ngsw_taro) 2018年2月8日

#DroidKaigi 2018でKotlinハンズオンの講師を務めました！発表スライドは自由に使ってね！

国内発 仮想通貨のモナーコインが熱いです。その価格は、年初から600倍以上にもなったとか！私は乗り遅れまいと先月末あたりに買ってみました。値動きが激しく持っているだけで面白いです。なにより、日本の仮想通貨という誇りとモナーのかわいさが最高ですね。で、値動きが激しいのでチャートが気になってしかたないわけです。しかし（あることはあるんですが）よさげなチャートがないのが残念です。そこで、自分で作ってしまおう！というのが今回のモチベーションです。第一歩として取引情報を取得するところです。Zaifは、仮想通貨の数多くある取引所のひとつです。ここでは便利なAPIが提供されています。ドキュメントを眺めてみると、現物公開APIのストリーミングAPIが提供されているようなので、これを今回は使います。公開APIなのでAPIキーなどが不要で、すぐに使い始めることができます。WebScoketで下記URLに接続すれば、取引情報が流れてきます。wss://ws.zaif.jp/stream?currency_pair=mona_jpyすぐにこのAPIを試したいならwscatを使うとよいでしょう。jqを併用すれば加工したり整形したりすることもできます。$ wscat -c wss://ws.zaif.jp/stream?currency_pair=mona_jpy | jq '.trades[] | { price: .price, date: (.date | .+32400) | todate }'{  "price": 1900,  "date": "2017-12-08T19:23:20Z"}{  "price": 1899.6,  "date": "2017-12-08T19:23:17Z"}...さて、本記事タイトルのとおり、このAPIをKotlinプログラムから呼び出します。WebSocketクライアントとして、tyrusを使います。JSR 356のリファレンス実装のようです。github.com今回はこんな感じで依存性を追加しました。def tyrusVersion = '1.13.1'compile "org.glassfish.tyrus.bundles:tyrus-standalone-client-jdk:$tyrusVersion"compile "org.glassfish.tyrus:tyrus-container-grizzly-client:$tyrusVersion"最小限のコードはこんな感じになります（インポートは省略）。fun main(args: Array<String>) {    val config = ClientEndpointConfig.Builder.create().build()    val client = ClientManager.createClient()    val session = client.connectToServer(object : Endpoint() {        override fun onOpen(session: Session, config: EndpointConfig) {            session.addMessageHandler(MessageHandler.Whole<String> { message ->                println(message)            })        }    }, config, URI.create("wss://ws.zaif.jp/stream?currency_pair=mona_jpy"))    while (session.isOpen) {        Thread.sleep(1000)    }}自信ないけど最後のループは、じっと待つためです。サーバからのデータを非同期で受信するため、これがないと最初のデータを受け取る前にプログラムが終了してしまうからです。正しいやり方があれば、コメントで教えてくださいm( )mまぁ、これだけであとはJacksonとか使っていい感じにやればOKです。で終わりだと面白くないので、せっかくだからKotlinのコルーチン機能を使って書き直してみます。// v サスペンド関数                                                                      v チャネルを返すsuspend fun ClientManager.connectingChannel(config: ClientEndpointConfig, uri: URI): Channel<String> {    val channel = Channel<String>() // チャネルの生成    try {        connectToServer(object : Endpoint() {            override fun onOpen(session: Session, config: EndpointConfig) {                session.addMessageHandler(MessageHandler.Whole<String> { message ->                    // コールバックで受け取ったメッセージをチャネルに送信する                    channel.sendBlocking(message)                })            }        }, config, uri)    } catch (e: Throwable) {        channel.close(e)    }    return channel}この拡張関数connectingChannelが返すチャネルを使って、メッセージの到着を監視することができます。fun main(args: Array<String>) = runBlocking {    val config = ClientEndpointConfig.Builder.create().build()    val client = ClientManager.createClient()    val channel = client.connectingChannel(config, URI.create("wss://ws.zaif.jp/stream?currency_pair=mona_jpy"))    while (isActive) {        val message = channel.receive()        println(message)    }}いい感じに整えて動かすとこんな感じです。ちょっと地味すぎでしたね。。まぁこれでデータを取れるので、あとはかっこよく見せるだけです。おわり。

KotlinでWebSocketクライアントを作ってモナーコインの取引を見守る

今年も残すところ1ヶ月となりました。街には色とりどりのイルミネーションが輝いています。ピンクオンリーの電飾を最近見かけますが、なんだか桜を連想させて季節感がないなぁと思ってしまいます。私は王道の黄色？の電飾が好きで、表参道に見に行きたいです。クリスマスが楽しみですね！ということで恒例のKotlinアドベントカレンダーが本日スタートしました！初日はtak-ondaさんの「Kotlin サーバーサイド開発に採用した軽量 Web フレームワーク Jooby の紹介と採用理由」です。…実は、今年はアドベントカレンダーを作成したのはいいものの、参加のタイミングを伺っている間に全枠が埋まってしまいました。嬉しいですねぇ。そのため、この記事はアドベントカレンダーに紐付いたものではありませんが、今年のKotlinについて簡単に振り返ってみたいと思います。Kotlin 1.1 リリース（3月）blog.jetbrains.comKotlinのバージョン1.1がリリースされました。大きなところとしては、コルーチンの導入とJavaScript正式サポートです。また、文法や機能が改善されました。例えば型エイリアスが追加され、関数参照や分解、シールドクラスなどの使い勝手がよくなりました。Kotlin/Native 発表（4月）blog.jetbrains.comKotlinをネイティブコードへコンパイルするKotlin/Nativeが発表されました。LLVMを使用し、iOSなどのプラットフォームをサポートしています。Kotlinユーザグループのロゴ提供（5月）世界各地にあるKotlinコミュニティをサポートするプログラムの一環で、コミュニティロゴの提供が行われました。これは日本Kotlinユーザグループ（通称JKUG）のロゴです。Kotlinアイコンが輪になっているのがかわいいですね。JKUGは、世界126のKotlinユーザグループのリストに名を連ねています。Android開発言語に正式採用（5月）blog.jetbrains.com今年のGoogle I/Oのキーノート、Androidのパートのいわゆる"One more thing"にて、KotlinがAndroid開発言語として正式に仲間入りしたことが発表されました！その瞬間は下記の動画をご覧ください。会場の熱狂が伺えます。youtu.beKotlin本がいろいろ出た（10月）10月に3つのKotlin入門書・解説書が国内に登場しました。Kotlin Webアプリケーション 新しいサーバサイドプログラミング作者: 長澤太郎出版社/メーカー: リックテレコム発売日: 2017/10/06メディア: 単行本（ソフトカバー）この商品を含むブログを見るKotlinイン・アクション作者: Dmitry Jemerov,Svetlana Isakova,長澤太郎,藤原聖,山本純平,yy_yank出版社/メーカー: マイナビ出版発売日: 2017/10/31メディア: 単行本（ソフトカバー）この商品を含むブログを見るはじめてのKotlinプログラミング (I・OBOOKS)作者: 清水美樹出版社/メーカー: 工学社発売日: 2017/10/01メディア: 単行本この商品を含むブログを見るKotlinConf（11月）2daysのKotlinカンファレンス「KotlinConf」が開催されました。1200人もの参加者、44のセッションがあり大盛況でした。キーノートではKotlin 1.2 RCが発表され、その機能の紹介もありました。blog.jetbrains.comtaro.hatenablog.jpKotlin 1.2 リリース（11月）blog.jetbrains.comKotlin 1.2の目玉機能はマルチプラットフォームのサポートです。複数のプラットフォーム、現段階ではJVMとJavaScriptの2つのプラットフォームを対象に提供されていますが、これら両プラットフォームが同じKotlinコードを共有できる仕組みです。来年もHave a nice Kotlin!Androidの勉強会では、登場するサンプルコードがデフォルトでKotlin、のような話を聞きます。もはやAndroidでKotlinは普通というような時代になっていくのかもしれません。Kotlin/Nativeやマルチプラットフォーム対応、そしてSpring frameworkのKotlinサポートがあり、今後はAndroidにとどまらず、Webバックエンド、フロントエンド、iOS、デスクトップ、IoTなど活躍の幅を広げていくのでしょう。それでは、来年もよいKotlinを！

2017年のKotlinまとめ #ktac2017

JetBrainsによるKotlinのカンファレンス「KotlinConf 2017」に参加してきました！11月2日と3日の2日間開催で、場所はサンフランシスコです。このような大規模なKotilnカンファレンスは初めての開催となります。1,200枚のチケットは完売とのことです。本エントリは、KotlinConf参加を含む雑な旅行記です。技術的な話はCA.kt #4 (Kotlin Conf報告会)で発表します。私は「Spring and Kotlin」というタイトルで発表する予定です。ちょっと遡って、一週間前Kotlinの解説書で、世界で一番有名なものといえば「Kotlin in Action」でしょう。その邦訳書を3人の仲間たちと執筆しました。けっこう苦労したんですが、予定どおり10月31日に発売することができました！「これを持ってKotlinConfに臨めば、原著者のお二方からサインを貰えるかもしれない！」という夢に胸を踊らせていました。Kotlinイン・アクション作者: Dmitry Jemerov,Svetlana Isakova,長澤太郎,藤原聖,山本純平,yy_yank出版社/メーカー: マイナビ出版発売日: 2017/10/31メディア: 単行本（ソフトカバー）この商品を含むブログを見るサンフランシスコへ出発！しかし荷造りの際には、サインを貰うべく「Kotlinイン・アクション」とサインペンを持ったことを確認しました。飛行機の中での暇つぶしグッズも持ったし、安眠グッズも詰め込みました。よし、完璧です。空港のラウンジでビールでも飲んでのんびりしようと思い、余裕を持って家を出ました。今年はグアムと、オーストラリアはケアンズに行ったこともあり、慣れたものです。成田空港に着いてから、書類を取り出して乗り場を確認したら、なんと！出発地は羽田空港でした…。あのときの「ヤバイ！」感は、人生の中でせいぜい数回くらいしか体験できないものでしょう。今から羽田空港へ向かってもギリギリ間に合わないだろうと思い、旅行会社へ電話して助けを求めました。結果を言うと、航空会社が親切にも成田発の便に変更してくれました。今回の件については深く反省しています。@yusukeさんと一緒無事、サンフランシスコ国際空港に到着し、BARTという鉄道を利用して宿泊予定のホテルへ向かいました（BARTの券売機のユーザビリティの悪さよ…）。考えてみれば海外に一人で来るのは初めてで、アメリカも初めてでした。いろいろ不安がありましたが、私よりちょっと早く到着していた@yusukeさんとランチに行くことになり、そのあとも一緒に散策したりしました。夕食も@yusukeさん行きつけのお店に連れていってもらい、知らない街でも楽しく過ごせました。夕食〜 pic.twitter.com/AJrdBWqbJE— コイン猫bot (@ngsw_taro) 2017年11月2日KotlinConf！11月2日、KotlinConf初日！朝8:00から受付開始で、9:00からキーノートが始まります。キーノートが始まるまでの時間は、朝食をいただけます。キーノートでは、Kotlin 1.2で導入されるマルチプラットフォーム・プロジェクトのことや、Kotlin/Nativeの話がありました。詳細は、Kotlin blog、TechBoosterの記事を参照してください。休憩時間中に、Kotlin in Action著者のDmitryさんとSvetlanaさんから念願のサインをいただきました！（正確には、Svetlanaさんからは懇親会のときに）しかも、Dmitryさんとは写真も一緒に！Kotlin In Actionの原著者の方と。 pic.twitter.com/wFEHycFWOs— Satoru Fujiwara (@satorufujiwara) 2017年11月2日JetBrainsのエバンジェリストであるHadiさんとも写真を撮りました！Kotlin in Action - Japanese translation. With the authors #kotlinconf17 pic.twitter.com/y7OCaNn9an— Hadi Hariri (@hhariri) 2017年11月2日私が特に楽しめた、かつ勉強になったセッションはBOOTIFUL KOTLINです。Spring Framework 5.0がリリースされ、KotlinフレンドリなAPIが多く追加されましたが、それを活用した、Kotlin x Spring Bootでの迅速なWebアプリ開発をライブコーディング中心で解説されていました。スピーカーのJosh Longさんの高い発表スキルや陽気なキャラクターもとてもよかったです。会場2Fの休憩スペースはこんな感じ。蟹JavaOneの日本人参加者たちの恒例イベントである蟹パーティをやるお店に、ついに私も行って来ました！11月3日、KotlinConf 2日目の夜です。2日目は懇親会などがないため、最後のセッションが終わったあと、みんなでUberなりLyftなりで車に乗ってお店に向かいました。ゆーすけさんたちと🦀を食べに行ったよ！ pic.twitter.com/uIJNze8ag6— コイン猫bot (@ngsw_taro) 2017年11月4日シェアさせて頂きます 🦀 pic.twitter.com/09cY454eyB— 山本ユースケ (@yusuke) 2017年11月4日サンフランシスコ観光11月4日は@satorufujiwaraさんたちと、サンフランシスコを観光してきました。すべて@satorufujiwaraさんにアレンジしてもらったプランで、無駄なく楽しく回れました。コイトタワー、ゴールデンゲートブリッジ、アルカトラズ島、フィッシャーマンズワーフに行きました。おいしいものもたくさん食べることができました！

KotlinConf 2017に参加してきたよ〜！！

対象はSpring framework 4.3.10, Spring Boot 1.5.5, 1.5.6。こういう単純なREST APIがあります。@SpringBootApplication@RestControllerpublic class DemoApplication {    public static void main(String[] args) {        SpringApplication.run(DemoApplication.class, args);    }    @PatchMapping("")    public String patch(TestResource testResource) {        return "PATCH: " + testResource.getValue();    }}class TestResource {    private String value;    public String getValue() {        return value;    }    public void setValue(final String value) {        this.value = value;    }}ちゃんとPATCHメソッドでリクエストを投げれば問題ないのですが$ curl -X PATCH http://localhost:8080 -d 'value=HELLO'PATCH: HELLOPOSTメソッド + _method=patch指定で投げるとTestResourceクラスのvalueがnullになってしまいます。$ curl -X POST http://localhost:8080 -d '_method=patch' -d 'value=HELLO'PATCH: nullこれはどうやらSpring自体のバグっぽくて（https://jira.spring.io/browse/SPR-15828）、Spring 4.3.11で修正されているので、Spring 4.3.10の使用を避けます。スナップショットですがSpring Boot 1.5.7を使うか、Springのバージョンを4.3.11.BUILD-SNAPSHOTと直接指定してやればOKです。

Springで_methodがputやpatchのときにリソースオブジェクトに値がマッピングされない問題（解決済み）

昨日、オンライン動画学習サービスのSchooさんの生放送授業に出演しました。schoo.jpAndroid開発言語にKotlinが正式に仲間入りというニュースがきっかけで、初めてKotlinを知ったという開発者も多くいらっしゃると思います。そのような人たちのために、サクっとKotlin紹介みたいなノリで1時間お話しさせていただきました。小さい勉強会でのLTから大きなカンファレンスでの講演まで数多く経験してきて、人前でしゃべることには緊張こそすれ慣れているつもりでした。しかし「生放送」というものは初めての経験だったので、勝手がわからず緊張しているのかリラックスしているのか、よくわからないテンションで臨みました。普通の勉強会は、聴衆の反応を直接感じることができ、臨機応変に振る舞えるものだと思います。要は軌道修正やそのタイミングの察知が容易なのかなぁと。一方、生放送という形は、リアルアイムで視聴者のコメントが届き、ある程度の反応はわかるものの、「楽しんでもらえてるかな？」とか「難しすぎないかな？」という不安を話しながら感じていました。とはいえ、ネットを介すことでコメントや質問がしやすいようにも思えます。リアル勉強会では最後の質問コーナーで、挙手して皆の前で質問する人は決して多くないのではないかと思います（多くても質問の数は3個とか4個）。昨日の生放送では、20個くらいは質問をいただけたと思います。特に主張したいことはないのですが、初めての形態での情報発信をできたことを純粋に楽しめたし、私自身 非常に勉強になりました！いただいた質問を詳しく回答いただいた質問に対して丁寧に回答したつもりでしたが、プログラミング言語のことなので、やはり言葉だけでは伝わりづらい部分もあるのだと思います。なので、コードを添えて回答したいと思ったものを、この場で解説します。Q. データクラスのプロパティの妥当性検証はできるのか？できます。Kotlinのクラスには「イニシャライザ」というものがあり、ここでインスタンス生成に関する事前条件の検証等を行います。例えば人物を表すクラスPersonを考えます。次のような実装になるものとします。data class Person(val name: String, val age: Int)このような実装ですと、次のように年齢に負数をセットすることができてしまいます。val taro = Person("Taro", -1)このような不正な状態のインスタンスを生成したくありません。そこで「イニシャライザ」の登場です。クラスPersonを、次のように書き直します。data class Person(val name: String, val age: Int) {    init {        if (age < 0)            throw IllegalArgumentException("ダメ")    }}この新しいPersonのインスタンスを生成するときにPerson("Taro", -1)とコンストラクタを呼び出すと、例外がスローされます。不正な状態のインスタンスを生成することを防げた、というわけです。ちなみに、このような事前条件の検証を行うための便利な関数が標準ライブラリに含まれています。それを使って書き直すと、こうなります。data class Person(val name: String, val age: Int) {    init {        require(age >= 0, {"ダメ"})    }}Q. データ隠蔽はできるか？できます。Kotlinのプロパティへのアクセスは一見、内部データに直接アクセスしているように見えますが、違います。内部データは「バッキングフィールド」という形で保持しますが、外部からこれを直接触ることはできません。すなわち内部データと、それへのアクセスを提供する窓口は別に提供されます。デフォルトでデータ隠蔽できているのです。class Foo {  val foo = "Foo"}Foo().foo //=> Fooプロパティfooへのアクセスは、内部データを直接見ているような感じがします（Javaに慣れている人なら特に）。しかし、実はそうではないことを、次のコードで確認することができます。class Foo {    val foo: String = "Foo"    get() {        println("fooを返します")        return field    }}Foo().foo// fooを返します// Foofieldは暗黙の変数で、カスタムゲッターやカスタムセッターの中でのみアクセス可能です。このfieldが内部データの正体です。外の世界からこいつに接触することはできません。ひとこと「髪短くしたね！」って言われるのを期待しているのに「黒くなったね！」とよく言われます。

Schooに出演してKotlin語って来たよ〜！詳しい回答つき

blog.jetbrains.com苦節5年、Kotlinエバンジェリストを自称して啓蒙活動に励んできましたが、ついに！KotlinがAndroidアプリの開発用言語としてGoogleのお墨付きをもらいました！おめでとう！毎年毎年、Google I/Oのキーノートを見ながら友達と「今年はKotlin来てほしいなー」なんて話していましたが、まさか今年来るとはね。KotlinでAndroidを始める方は拙著がおすすめです！Kotlinスタートブック作者: 長澤太郎出版社/メーカー: リックテレコム発売日: 2017/03/21メディア: Kindle版この商品を含むブログを見るまた、日本Kotlinユーザグループでは勉強会や交流会を開催していますので、興味ある方はぜひ！kotlin.connpass.com

GoogleがKotlinをAndroid開発言語として公式サポートするってよ！

3/9(木)、3/10(金)にDroidKaigiに行ってきました。2日目にはKotlinハンズオンの講師を務めました。KotlinとAndroidを絡めたハンズオンをやるのは実は初めてで、結果的にはおおむね成功でしたが、課題がいくつか残りました。90分という枠にいろいろ詰めすぎたことを一番反省しています。RetrofitとDagger、async/awaitはスコープに含めるべきではありませんでした。これらを盛り込んだ理由は、RetrofitやDaggerなど  AndroidJavaで便利に使えるライブラリをKotlinからも難なく使えるんだよ  ってことを示したかったからです。async/awaitは、DroidKaigiより1〜2週間前にKotlin 1.1がリリースされたこともあり「せっかくだから紹介しよう」というノリで入れてしまいました。ご協力いただいたチューターの方々のブログもご覧ください。Kotlinハンズオンのお手伝いしました＆DroidKaigi2017の2日目に参加してきました #droidkaigiDroidKaigi 2017でKotlinハンズオンのチューターとしてお手伝いしてきた #DroidKaigiサンプルプロジェクトはGithubで公開しています（https://github.com/ntaro/github-client-for-droidkaigi）。スライドはこちら↓次回ハンズオンの宣伝日本Kotlinユーザグループ x teratail でお送りするKotlinハンズオンが4/15(土)に開催されます！3/22(水)から募集開始です。レベル感としては「Kolintは初めてだけど他の言語でプロダクト作ってるよ」って人を対象としています。ぜひお越しください！kotlin.connpass.com

#DroidKaigi でKotlinハンズオンの講師をしたよ〜！

blog.jetbrains.comKotiln 1.0.6がリリースされました！同時に面白いプラグインが2つリリースされました。all-open compiler pluginとno-arg compiler pluginです。all-open compiler pluginは、指定したアノテーションがついたクラスが自動でopen指定されるという機能を持ちます。no-arg compiler pluginは、指定したアノテーションがついたクラスに、自動でデフォルトコンストラクタ（引数を持たないコンストラクタ）を生成してくれます。導入方法は、冒頭に示したKotlin公式ブログを参照してください。今回はこれらのプラグインを用いることで、Realmが使いやすくなることを示したいと思います。プラグインなしまずは普通にKotlinだけを使って、Realmオブジェクトを定義してみます。open User(@PrimaryKey open var id: Long = 0,          open var name: String = ""): RealmObjectうひゃー、おまじないだらけですね。openが3回も登場していますが、RealmがこのUserクラスを継承して面白い機能を追加するために必要なのです。また、Realmはデフォルトコンストラクタを要求します。そのためUserクラスのプライマリコンストラクタでデフォルト引数を与えることで、引数なしのコンストラクタを提供しているというわけです。ともかく、本来であれば無視してもよいことに注意しなければならないのですね〜。all-open compiler pluginを使うall-open compiler pluginを使って、open修飾子を退治しましょう。プラグインの設定として、下記をbuild.gradleに記述します。allOpen {    annotation('io.realm.annotations.RealmClass')}この設定により、@RealmClassアノテーションが付いたクラスが、自動でopen指定となります。@RealmClassUser(@PrimaryKey var id: Long = 0,     var name: String = ""): RealmObjectno-arg compiler pluginを使う次にno-arg compiler pluginを使って、デフォルト引数を毎回記述する退屈な作業から解放されましょう。プラグインの設定として、下記をbuild.gradleに記述します。noArg {    annotation('io.realm.annotations.RealmClass')}all-openのときと同じように、@RealmClassが付いたクラスを対象に、デフォルトコンストラクタの自動生成を設定します。ついにやりました！謎のopenもデフォルト引数も、キレイに消えたコードが手に入りました！@RealmClassclass User(@PrimaryKey var id: Long,           var name: String) : RealmObject()おまけno-argで自動生成したデフォルトコンストラクタは、Kotlinのリフレクション機能を使ってもアクセスすることはできないようです。一方Javaのリフレクション機能を使うとアクセスできます。@MyAnnotation // このアノテーションに対してno-arg設定data class Hoge(val value: String)Hoge::class.constructors.forEach(::println)println("----------")Hoge::class.java.constructors.forEach(::println)println("----------")println(Hoge::class.java.newInstance())実行すると...fun <init>(kotlin.String): Hoge----------public Hoge()public Hoge(java.lang.String)----------Hoge(value=null)

Kotlin 便利なプラグインが2つ登場しRealmが捗るよ〜

一昨日くらいにAndroid 7.1.1のOTAが開始されましたね。私のNexus5Xにも届いたので、早速インストールしました。Android 7.1で目玉の機能となるのは、App Shortcutsなのではないでしょうか！ということで試してみました。公式のAPIガイドを見てやれば、すごく簡単に実装できます！App Shortcuts 概略App Shortcutsは、欲しい情報にすぐにアクセスするための機能です。ランチャーアイコンを長押しすることで、ショートカット一覧が表示されます。ショートカットを押せば、そのアプリの特定の画面にすぐにたどり着けるというものです。次の図のようなイメージです。地図アプリのランチャーアイコンを長押しすると「Work」「Home」のショートカットが表示されます。「Work」ショートカットを押すと単に地図アプリを起動するときとは異なり、現在地から職場までの道案内がすぐに始まります。動きの話をすると、各ショートカットはひとつのインテントを持っており、ショートカットが押されるとそのインテントが発行されるという仕組みです。App Shortcutsにおいて、ショートカットには2種類あります。静的ショートカットと動的ショートカットです。静的ショートカットは、XMLでショートカットを定義してやる方法です。一方、動的ショートカットは、プログラムコードで定義します。「動的」の言葉のとおり、アプリの実行中に状況に応じてショートカットを追加、更新、削除が可能です。静的ショートカットXMLでショートカットをあらかじめ準備してやる方法です。res/xmlの下にショートカット一覧を定義するXMLファイルを作成します。ここではshortcuts.xmlという名前のファイルを作成します。その内容は、下記が最小構成です。<?xml version="1.0" encoding="utf-8"?><shortcuts xmlns:android="http://schemas.android.com/apk/res/android">    <shortcut        android:shortcutId="launch"        android:shortcutShortLabel="@string/launcher_short">        <intent            android:action="android.intent.action.VIEW"            android:targetPackage="com.example.app"            android:targetClass="com.example.app.MainActivity" />    </shortcut></shortcuts>ルートにshortcuts要素があり、その直下にいくつかのshortcut要素を含みます。shortcut要素は、少なくともandroid:shortcutId, android:shortcutShortLabelの属性を持つ必要があるようです。そしてshortcut要素はintent要素を持ちます。ショートカットが押されたときに、このインテントが発行されます。この例では、指定したアクティビティを起動するだけです。次に、自分のアプリがショートカットを持っていることを知らせるためにAndroidManifest.xmlを編集します。ランチャーから起動されるアクティビティ内に、meta要素を追加します。<activity    android:name=".MainActivity"    android:label="@string/app_name">    <intent-filter>         <action android:name="android.intent.action.MAIN" />         <category android:name="android.intent.category.LAUNCHER" />    </intent-filter>    <meta-data        android:name="android.app.shortcuts"        android:resource="@xml/shortcuts" /></activity>これで静的ショートカットの準備は完了です。ビルドして実行するとか、次のようにショートカットを確認できるはずです。shortcut要素にandroid:shortcutLongLabel属性とandroid:icon属性を追加してみます。<?xml version="1.0" encoding="utf-8"?><shortcuts xmlns:android="http://schemas.android.com/apk/res/android">    <shortcut        android:shortcutId="launch"        android:shortcutShortLabel="@string/launcher_short"        android:shortcutLongLabel="@string/launcher_long"        android:icon="@mipmap/ic_launcher">        <intent            android:action="android.intent.action.VIEW"            android:targetPackage="com.example.app"            android:targetClass="com.example.comm.MainActivity" />    </shortcut></shortcuts>ビルドして実行すると、下記のように変わっています。ショートカット一覧に表示されるラベルがandroid:shortcutLongLabelに対応しているようです。android:shortcutShortLabelはどこで使われるかと言うと、ショートカット一覧でショートカットを長押しすると、ショートカットをホーム画面に設置できるのですが、そのときのラベルに使用されます。ちなみに、ショートカットのアイコンですが、デザイン・ガイドライン（PDF）が提供されているので、それに従うべきでしょう（この例はダメダメなデザイン）。今回、私が趣味で開発している「夢と魔法の待ち時間」では、次のように静的ショートカットを定義しています（一部、例示用に改変）。<?xml version="1.0" encoding="utf-8"?><shortcuts xmlns:android="http://schemas.android.com/apk/res/android">    <shortcut        android:shortcutId="land"        android:enabled="true"        android:icon="@drawable/ic_land"        android:shortcutShortLabel="@string/label_land_wait_time"        android:shortcutLongLabel="@string/label_land_wait_time">        <intent            android:action="android.intent.action.VIEW"            android:data="app://com.example.app/land_wait_time" />    </shortcut>    <shortcut        android:shortcutId="sea"        android:enabled="true"        android:icon="@drawable/ic_sea"        android:shortcutShortLabel="@string/label_sea_wait_time"        android:shortcutLongLabel="@string/label_sea_wait_time">        <intent            android:action="android.intent.action.VIEW"            android:data="app://com.example.app/sea_wait_time" />    </shortcut></shortcuts>ショートカットを押すと、URLへのアクセスが起こり、アプリがこれをフックするという具合です。動的ショートカット動的ショートカットのみを提供する場合はXMLは不要です。プログラムコードでショートカットを表現し、追加、更新、削除といった操作を行います。重要なAPIはShortcutInfoとShortcutManagerです。まずShortcutInfoでショートカットを表現します。val shortcutInfo: ShortcutInfo = ShortcutInfo.Builder(context, "lastVisitedScreen")    .setShortLabel(lastVisitedScreenShortName)    .setLongLabel(lastVisitedScreenLongName)    .setIcon(Icon.createWithResources(context, R.drawable.ic_history)    .setIntent(Intent(Intent.ACTION_VIEW, lastVisitedScreenUri))    .build()上記のように、ShortcutInfo.Builderというビルダーのインスタンスを取得し、メソッドチェーンを形成しショートカットの設定をセットしていきます。ちなみに、このコードはKotlinで記述しています。次に、このshortcutInfoをShortcutManagerを使って追加しましょう。下記がそのコードです。val shortcutManager: ShortcutManager = context.getSystemService(ShortcutManager::class.java)shortcutManager.setDynamicShortcuts(listOf(shortcutInfo))ショートカットの追加メソッドsetDynamicShortcutsと更新メソッドupdateShortcutsは、ShortcutInfoのリストを受け取るので、Kotlin標準関数listOfでリストにしています。削除メソッドremoveDynamicShortcutsは、文字列（ショートカットID）のリストを受け取ります。「夢と魔法の待ち時間」では、動的ショートカットを使って、最後に表示した画面へのショートカットを提供しています。これは静的ショートカットでは実現できない機能です。星のアイコンのショートカットが、最後に表示した画面へのショートカットです。まとめAndroid 7.1.1の配信が始まりましたApp Shortcutsはショートカットを提供する機能でAndroid 7.1で導入されましたショートカットには静的ショートカットと動的ショートカットがあります静的ショートカットは、XMLで事前に定義しておきます動的ショートカットは、プログラムで動的に定義しますAndroidでの体験がより便利になりそうですね！！！！さらにApp Shortcutsを学びたい人は公式のAPIガイドを参照してください。

App Shortcuts 実装方法と実際の応用例

今年もアドベントカレンダーの季節がやって参りました。ということでKotlin Advent Calendar 2016、1日目の記事です。2011年にKotlinプロジェクトが発表され、2012年に実装が公開されました。2013年は知る人ぞ知る言語という位置付けで、2014年、2015年は時折バズっては徐々にファンを増やしていった時期です。そして、2016年最大の出来事は何と言ってもver 1.0のリリースです。勉強会や開発事例、求人情報も増え、「実用の年」と言えるかもしれません。本記事では2016年のKotlinにまつわる出来事を振り返りたいと思います。Kotlinの成長2月に新しいロゴとともに、ver 1.0.0がリリースされました。さらに、同じタイミングでSpring BootのKotlinサポートがリリースされました。3月にはAndroidにおける、Jack and JillやJava8に対してのKotlinとJetBrainsの姿勢について言及がありました。5月にGradleのビルドスクリプトをKotlinで書けるようになるよという話もありました。で、いろいろあって（特に目立ったイベントはなく）、現在はver 1.0.5までリリースされており、いくつかのバグ修正、改善とツールまわりの対応がなされました。そして次のver 1.1のマイルストーンは、3番目がリリースされています。ver1.1での目玉は、コルーチンのサポートでしょうか。型エイリアス、Bound Callable Referenceも大きな改善です。型エイリアスは、その名の通り型に別名を与えます。Bound Callable Referenceは、例えばval f: (Int)->Char = "foo"::getのようにメソッドをレシーバと結びつけた上で関数化することができる機能です。その他にもデータクラスの継承サポート、シールドクラスのルール緩和、委譲プロパティの対象拡大、ラムダ式の引数での分解などが加わります。日本のコミュニティ今年は今までで一番コミュニティが盛り上がった年でもあります。connpassでKotlinを検索すると、現時点で47件もの勉強会がヒットします。去年が7件であることに対し7倍近く増えています。Sansanさん主催のKotlin勉強会は、非常に存在感が大きいです。第1回が1月に行われ、そのときは幸運なことに、JetBrains Kotlinチームの人にご登壇いただきました。第2回、第3回は勉強会スタート時からビール片手に発表を聞けるというスタイルで、なごやかな雰囲気で楽しかったです。そして、今月13日に第4回が開催予定です！今月、もう一つKotlin勉強会があります。Rettyさん主催の勉強会で、今回はKotlinのテーマらしいです。私は私用につき途中で退出しますが、登壇者枠、ブログ枠ともに空いているので、ぜひご参加ください！関西にKotlinコミュニティ Kansai.ktが誕生しました。やはり勉強会は東京に集中してしまいがちなので、活動を応援したいです！Kotlinエバンジェリストを自称しているだけあって、登壇オファーをたくさんいただきました。上記のSansan勉強会、Retty勉強会に加え、Kotlin/Goデベロッパーミーティング、Hacker Tackle、Lightweight Language of Things、たろうさんと学ぼうKotlin入門、ビズリーチ社内勉強会、関西Kotlin勉強会など、たくさんお声いただき、ありがとうございます。登壇、執筆依頼はいつでもお受けしますので、お気軽にお声掛けください！書籍手前味噌ですみませんが、今年の7月に「Kotlinスタートブック」なるKotlin入門書を出しました。Kotlinスタートブック -新しいAndroidプログラミング作者: 長澤太郎出版社/メーカー: リックテレコム発売日: 2016/07/13メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見るおわりに来年はさらに盛り上がるでしょう。ver 1.1のリリースが控えており、JDK9、Spring 5.0などのリリースもあります。前述の通り、connpassでKotlin勉強会を検索すると47件ヒットしますが、目指せ100件超え！ですね。Wantedlyで「シゴト」をKotlinで検索すると現時点で112件ヒットします。1年後には何件に増えているのか、楽しみです。明日の担当は@lVlA0805さんです。お楽しみに！