nDiki : 表記

今日のさえずり: 席で波平のイラスト眺めている時に声をかけられた

2014年11月12日

• 08:25 無印良品のシャツが早々と退色してきた。靴下もヨレヨレになるの早いし、インナーシャツも敗れるし、総じて耐久性がないな。
• 08:48 “VimConf2014 で発表してきました - 若き JavaScripter の悩み” http://bit.ly/10WSI4F
• 08:56 インフルエンザの予防接種日なので検温。 36.1℃。
• 13:35 席で波平のイラスト眺めている時に声をかけられた。
• 15:15 インフルエンザの予防接種した。なんか今年は入ってくる感じがみずみずしかった。
• 18:15 「ウエー」「ウエイ」「ウェー」「ウェイ」 / “外来語の発音・表記について ～［wei］のカタカナ表記と語末の長音～” http://bit.ly/1EswR1K
• 18:45 固定電話で Google 2 段階認証プロセス有効にしたった。
• 21:19 インフルエンザ予防接種のところ、去年よりは痛め。

LINE DEVELOPER DAY_2015 Tokyo #linedevday

「エンジニアチームの様々な経験を、未解決の課題も含めて共有する」というテーマで開催された LINE 株式会社のエンジニア向けイベント LINE DEVELOPER DAY_2015 Tokyo に行ってきた。

会場の装飾やクリエイティブなどお金をかけていてすごいなと。始まる前にプレス向けにきちんと立ち位置や照明まで案内していて、とても行き届いていて運営力もすごい。

細かいところだけれどイベントサイトや事前案内は「LINE DEVELOPER DAY_2015 Tokyo」で当日の会場が「LINE DEVELOPER_DAY 2015 TOKYO」と表記を変えていてどんな理由なのかなというのが気になった。まあどうでもいいことだけれど、物を書くのにちょっと困る。

スライドはシンプルで洗練されているんだけれど、完成されすぎていて素材ぽくも感じた。

全体的に microservices アーキテクチャというのが印象に残るイベントだった。

A-1 オープニング 代表取締役社長 CEO 出澤剛氏

LINE の成長とサービスなどの紹介。ウォーミングアップ的に聞いていた。

A-2 LINE Global Culture 上級執行役員 CTO 朴イビン氏

「LINE のグローバルな開発組織や文化について」

ちょっと綺麗にまとめられすぎていて感じがした。泥臭さが感じられない。より現場的な話をぜひ聞きたいなと思った。

ペンディング・先送りされた「cold-case プロジェクト」について、また取り組むきっかけを用意するというのは良いな。

A-3 LINE Messenger for the World 上級執行役員 サービス開発担当 池邉智洋 @ikebe 氏

「色々な国の通信各社、様々な環境に対応するために進めた実験や改善方法について」

LINE アプリのバイナリは1つとのこと。各国の事情について「LINE 遠征隊」として現地で実際に使って改善していくという取り組みがきちんとできているというのは素晴しいと感じた。グローバルなサービスではなく国内向けのサービスでも参考にできるな。

ストアのレビューについて、レビュー文章のキーワード分析や変化の把握もきちんとしているとのこと。(アプリではないけれど)化粧品業界などが良くやっているやつか。 この辺りは自分の部署でも取り組んでみたい。

A-4 LINE Platform Development Chronicle Tom.T @tsurutom 氏

「LINE Platformを支えるアーキテクチャ、組織、文化について」

鶴原翔夢氏による LINE のアーキテクチャの変遷について。

• polling / push / long polling
• Erlang で LINE Event Delivery Gateway
• SPDY

など。アーキテクチャは microservices に移行している。

Abusing も独立したバックエンドになっているとのことだった。abuse 対策のコンポーネント化は考えてはいるんだけれど、サービス毎に要件が結構異なるので本体とどの程度の結合にするかが迷いどころなんだよね。いつかはやりたいところ。

A-5 HBaseとRedisを使った100億超/日 メッセージを処理するLINEのストレージ Shunsuke.N @sunsuk7tp 氏

HBase と Redis の話し。桁違いだ。

A-8 Webサービスの国際化にあたり LINE Creators Market 開発がどのように行われたか Tokuhiro.M @tokuhirom 氏

最近 Java を書かれているようだけれども LINE Creators Market はやっぱり Perl で書かれているとのこと。ちなみにアプリケーションサーバでは Starlet を使っているそうだ。

実際に開発する上で問題になったことも混じえた @tokuhirom 氏らしい語り口のセッションだった。

B-5 ベイズ推定とDeep Learningを使用したレコメンドエンジン開発 Jun.N 氏

なみかわじゅん氏。

まずはスタンプ間の(レコメンド的な)距離を計算し、その上でユーザー-スタンプ間の距離を計算するというフローでレコメンドを生成しているとのこと。処理には Hive も使っているらしい。

コールドスタート問題については、Naver Labs と共同研究開発した画像の類似度計算を使って似た絵のものをレコメンドできるようにして対応しているとのことだった。

以上

午後は途中オフィスに戻ったりしながら面白げなセッションを聞いてきた。夕方に歯医者があるので 17:30 まで聞いて退散。

Xperia Z5 2日目、カメラをチェック

発売日である昨日に購入した Xperia Z5 SO-01H は昨晩と今日とでだいたい Xperia GX でやっていたこととほぼ同じ事ができるまで設定が済みました。

発売前から酷評されていた発熱問題も、普通に使っていれば気にならないので一安心。 使い勝手で気になるところはカメラの解像度と画角。

解像度

Xperia Z5 標準のカメラアプリだと選べる解像度はプレミアムおまかせオートだと以下で

• 23MP / 5520x4140(4:3)
• 20MP / 5984x3366(16:9)
• 8MP / 3264x2448(4:3)
• 8MP / 3840x2160(16:9)

で、マニュアルだと選べる解像度は以下になります。

• 23MP / 5520x4140(4:3)
• 20MP / 5984x3366(16:9)
• 8MP / 3264x2448(4:3)
• 8MP / 3840x2160(16:9)
• 3MP / 2048x1536(4:3)
• 2MP / 1920x1080(16:9)

しかし標準のではないカメラアプリから使える解像度はこれとは違ってきます。Camera FV-5 だと選択できるのが

• 3840x2160 (8.3 MP 16:9)
• 2048x1536 (3.1 MP 4:3)
• 1920x1080 (2.1 MP 16:9)
• 1280x720 (0.9 MP 16:9)
• 720x480 (0.3 MP 3:2)
• 640x480 (0.3 MP 4:3)
• 352x288 (0.1 MP)
• 320x240 (0.1 MP 4:3)
• 176x144 (0 MP)

となります(アプリの設定画面の通りの表記)。20MP 以上の撮影ができないのは個人的にはいいのですが、 8MP 前後の 4:3 で撮影できないのが厳しい。3.1 MP だとちょっと物足りないので悩ましいです。ちなみに Camera ICS+ だと以下。

• 3840x2160 (8.3 メガピクセル)
• 2048x1536 (3 メガピクセル)
• 1920x1080 (2 メガピクセル)
• 1280x720 (0.9 メガピクセル)
• 640x480 (VGA)
• 320x240 (QVGA)

やはり 8.3MP にしたければ 16:9、4:3 にしたければ 3.1 MP ということになります。

8MP から 6MP ぐらいで 4:3 あるいは 3:2 で撮影できると嬉しいなと思います。ちなみに Xperia GX だと Camera FV-5 では 2592x1944 (5MP 4:3)で、Camera ICS+ でも 2592x1944 (5 メガピクセル) で撮っていました。

画角

レンズは 35mm 判換算で 24mm 相当でかなり広角。なので普通に気軽に撮ると端に写っている人がすぐ歪んでしまうんですよね。

標準のカメラアプリを使うべき?

ということでこのあたりを考えると普段は Xperia Z5 標準のカメラアプリを使うのが無難なのかもしれません。 解像度で 8MP を選択し、画角については Clear Image Zoom 頼ると。 デジタルズームは使わない派だったのですがスマートフォンですし目くじらを立てずに使ってみようかと思います。8MP だと5倍まで、その上の解像度だと3倍までが Clear Image Zoom ということなので 8MP で使う分には余裕がありそうです。

記者ハンドブック 第11版から第13版に買い替え

今年の3月に記者ハンドブック 第13版が出ていました。5年半ぶりの改訂です。私が持っているのはさらにその前の第11版で9年前の版。今回は有名どころだと「メード」が「メイド」に変更されるなど今に即した改訂がされているので、買い替えることにしました。

表記の仕方について用字用語集の部分が役に立つのはもちろん、各種解説の部分もかなりためになります。

いつもそばに置いておきたい1冊です(電子版もずっと待ち望んでいるのですが出ないですね)。

• 記者ハンドブック 第13版

---

[ 読書ノート ] [ お薦めの本 ]

Android 版 Google 日本語入力アップデートで雰囲気が変わった

Android 版 Google 日本語入力がアップデートされて随分雰囲気が変わりました。ぱっと見は全体的に華奢な印象になりました。でもこれは印象だけかもしれません。

ケータイ配列レイアウトおよび QWERTY レイアウトから数字・記号入力画面に入った時の左下のボタンが「戻る」という表記になり画面の関係が分かりやすくなったのは良いなと思います。

しかしながらケータイ配列レイアウトでの「や」の左右フリックの括弧のデフォルトがいわゆる全角文字に変わったのはかなり不便。いわゆる半角の ( ) は変換候補の5〜6行目ぐらいの位置(私の端末の場合)になるのでちょとこれは厳しい感じです。

また私は特に影響は無いのですが、 まだ Android 4.2.2 である Xperia A を使っている妻的にはキャリア絵文字が Android の残念な絵文字に置き換わってしまったのがちょっとアレッという感じのようでした。

特に括弧の扱いについては今後のアップデートで選択できるようになることを期待したいところです。

• Android 版 Google 日本語入力をアップデートしました

今日のさえずり: 下の名前のよみでそれぞれの「さいとう」漢字表記を辞書登録した

2016年09月21日

• 12:00 mixi運営オフ#5喫茶去の開催レポートです。 / “mixi公式オフ会で「会ったことのないマイミク」と直接会っていただきました|よりミク” #mixi_off http://bit.ly/2d0sqHe https://t.co/AIWZMhdJEG
• 23:01 「さいとう」を漢字変換で出し分けるの困難なので、下の名前のよみでそれぞれの「さいとう」漢字表記を辞書登録した。
• 23:30 とうとうAmazonプライム無料体験申し込んだ。 http://amzn.to/2cfGvP3

FY 表記から年度表記に修正

社内資料で以前は「FY2016 = 2016年度」としていたのですが、最近になって「FY2017 = 2016年度」に改められました(後者の方が一般的)。

過去資料と通して扱う時に紛らわしいので、気がついた範囲で自分で作った資料については「年度」表記にいったん揃えることにしました。

仕事に追われない仕事術 マニャーナの法則 完全版

タスク管理の記事を読んでいると「マニャーナの法則」というキーワードがよく出てきます。今までスルーしていたのですがここ最近クローズドリストの考え方を取り入れてみているので、その辺りの話が書かれている「仕事に追われない仕事術 マニャーナの法則 完全版 (Do It Tomorrow and Other Secrets of Time Management)」を読んでみました。

• 仕事に追われない仕事術 マニャーナの法則 完全版

マニャーナの法則

まずマニャーナの法則ですが

• 原則1 新しい仕事は「明日やる」を基本にする
• 原則2 クローズドリストを使う

という2つの原則のこととあります。日本語ではマニャーナの法則と訳されていますが the mañana principle なので「(行動)原則」の方が適切に感じました。

「すぐやる」ことの弊害

すぐやると「忙しいだけの仕事」ばかりが進み「本当の仕事」が進まないと指摘しています。新しくきた仕事にすぐとりかかってしまうのではなく、既存の仕事より価値があるかをまず考える必要があると説いています。

「すぐやる」は自分の行動原則の一つなのでショッキングな指摘です。言われてみれば主体的な仕事よりも反応的な仕事に時間を使いがちです。

ただ「すぐやる」については

• 「後回しにしてチャンスを逃す」ことのないようにする。
• 先送りすることで増大するコストを最小化する。

というメリットがあるのも事実。このあたりは本書で言うところの「緊急レベルの判断」とバランスを取っていく感じなのでしょう。

全員がマニャーナの法則をやるとどうなるか?

個人個人がマニャーナの法則に従ってバッファリングすると組織全体のリードタイムが伸びるのではという懸念を持ちました。個人の稼働が最適化されるかわりに、作業の手待ち(idle work)が多く発生することになるからです。

このあたり要注意に思われます。

緊急レベルを判断する

入ってきた仕事はまず緊急レベルを判断するというのが本書の考え方です。

• 緊急レベル1「今すぐ」
• 緊急レベル2「今日中に」
• 緊急レベル3「明日やる」(ベスト)

本書では「明日やる」がベスト。

これはすでに2週間前からRemember The Milk の優先度設定に取り入れてみています。

will do リスト

本書では「WILL DOリスト」と表記。その日にやるとコミットしたタスクを入れておくクローズドリスト(本書ではクローズ・リストと表記)。自分は Remember The Milk でタスクの優先度を1にすることでリスト化しています。

処理する順番はファースト・タスクが最初で「明日のリスト作成」が最後です。それ以外はまったく自由。

1日の最後に何をおいても明日の will do リストは作成することが必須とあります。仕事については実践していますが、プライベートでは翌日の will do リストを夜に作るのがまだ習慣にしきれていません。

ちなみに本書ではタスクにかかる時間の見積もりについてはほとんど触れられていません。翌日時間が足りず will do リストを完了できそうもない場合もいつもどおりリストを作成し翌日は「できるとこまでやる」「完了できない日が続くなら対策をとる」という感じになっています。

やり残しをどうするか?

will do リストで完了できなかったものは、「やり残し」フォルダに放り込み、ファースト・タスクで処理しましょうとあります。

これは今週から Remember The Milk で backlog タグを付けるようにして実践中です。

ファースト・タスク

ファースト・タスクは「毎日の最初に行い、そこから1日をスタートさせるのが望ましい仕事」とのこと。毎朝最初にできる仕事は1つしかないので、常に1つ。

• 原則1 とにかく、する (Do)
• 原則2 一番始めに、する (First)
• 原則3 毎日、する (Every day)

ファースト・タスクに向いている仕事は

• 「やり残し」を片付ける
• 仕事のシステムを修正する
• プロジェクトを進める

です。今は「やり残し」を片付けるのに使っています。先送りし続けることが減りました。

実際のところ実際に一番最初にはやれてなくてまず「セットアップタスク」なるものをやってたりします。これらを前日に済ませるようにできれば本当のファースト・タスクにできるのかも。

ダッシュ法

ダッシュ法はポモドーロテクニックにつながるところを感じました。ちょっとマニアックでテクニカルなやり方だというのと、マルチタスク型な印象なのとで今回はスルー。

二分等法 すべての仕事を半分にする

プロジェクトをタスクに分解する方法。 GTD でプロジェクトに対して具体的な行動を設定するのと同様、本書でも具体的な行動に落とし込むよう指導しています。

その具体的なやり方として二等分法というのが紹介されていました。プロジェクトを二等分し、先にやる方をまた二等分にするというのを繰り返して「抵抗感が問題にならない状態」になるまで分割を続けるという方法です。

全てをブレークダウンすることはせず直近取り組む部分だけ具体的にするというやり方がスクラムにおけるプロダクトバックログリファインメントの考え方に似ていて気に入りました。

行動の合間に考える習慣をつける

最後の方の「考える」ということについての話で「行動の合間に考える習慣をつける」エクササイズが紹介されていました。

• 「毎日15分」など時間を決め確保する。
• 邪魔が入らない場所でノートと筆記用具を用意し、浮かんできたアイデアや考え方をノートに書き留める。
• 時間の終わりに近づいたら書いたものについて考える。良いアイデアや行動が必要なことに下線を引く。

というものです。時間(期限)を決めその時間の最後まで考え抜くというのがポイントだそう。ぜひ取り組んでみたいなと思います。

冒頭にキーワードが説明されているのが良かった

最後に本書の構成について。

本書では冒頭で「本書に登場する18のキーワード」として

• 「クローズ・リスト」「オープン・リスト」「チェック・リスト」
• 「コミットメント」「本当の仕事」「忙しいだけの仕事」
• 「バッファー・ゾーン」「マニャーナの法則」
• 「タスク」「プロジェクト」
• 「タスク・ダイアリー」
• 「デイリー・タスク」「ファースト・タスク」
• 「TODOリスト」「WILL DOリスト」
• 「ダッシュ法」「期限の効果」
• 「ラベリング」

が列挙されてそれぞれに簡単な説明がついています。簡潔でわかりやすく、本を読み進める助けになります。

本では「はじめに」で第1章では◯◯、第2章では△△とずらずらと書かれていたりしますが、前提知識が無いとわかりにくい書き方のものが多いです。それに対して、本書ではキーワードという見出しでサマリと流れをうまく説明していて素晴らしいなと感じました(ちなみに本書も「はじめに」では構成が手短に説明されています)。

• 仕事に追われない仕事術 マニャーナの法則 完全版

---

[ 読書ノート ] [ お薦めの本 ]

C92【日記】

タイムラインに C92 というキーワードが良く流れてきて C 言語の規格の表記に似ているなぁと思ったり。

話題が LSI C-86 試食版になって懐かしさを感じました。C MAGAZINE 付録に収録されていた LSI C-86 試食版で C に触れた世代。関数の引数をレジスタで渡すようにコンパイルするとか、当時わくわくものでした。

Perl バージョンと perl バージョンの表記

Perl はプログラミング言語を指し、 perl は Perl で書かれたプログラムを実行するプログラムというには良く知られています。

Perl 5.6.0 から v1.2.3.4 というリテラル形式が v-strings が出てきたので Perl v5.6.0 のように表記したりしていたのですが、調べてみると v-strings でバージョン番号を示しているのは perl に対しての場合が多く (perl -v でも v-strings で出力される)、Perl については v はつけない方がほとんどでした。

なので nDiki での Perl バージョンを表記する際は v をつけないように修正・統一してみました。