別にしんどくないブログ

正直しんどいので更新はゆるくやります

blink-devのススメ。Webの情報収集方法の紹介

最近、情報収集の一環で新しく始めたことがあるので紹介したいと思います。

blink-dev

知っている人も多いかもしれないですが、blink-devというchromiumレンダリングエンジンBlinkに関するグループが存在します。

https://groups.google.com/a/chromium.org/forum/#!forum/blink-dev

ここではBlinkの機能や仕様について活発に議論がされています。 このグループは誰でも参加可能で、誰でも投稿することができます。

このグループのフォーラムを眺めているとchromiumの最新の情報を得ることができます。 すべての情報をキャッチアップするのは大変ですが、ここでは僕がなるべくやるようにしていることを紹介したいと思います。

Intents

上記のblink-devのページを開いてもらうとわかると思いますが、各投稿はIntent to 〜というタイトルになっています。Intentは意思とか意図とかって意味だそうです。 そのIntentsにも種類があります。 * intent to ship: stableに入る * intent to implement: 実装が始まったもの * intent to remove: 削除される機能 * intent to experiment: 試験運用がされる などがあります。

そもそも多すぎてタイトルだけでも確認するのが大変なので、intent to shipまたはintent to implement and shipだけ見ることもあります。

メールで確認する

興味のある内容は抑えておく

このグループのメンバーになると投稿があるとメールで通知が来ます。毎日結構な数が来るので、すべて見ているわけではないですが興味のあるタイトルは概要だけでも読むようにします。
内容をちゃんと読みたい場合はページを開いて議論の内容も見ます。

知らないけど気になる内容も見てみる

タイトルを見て知らないけど気になったメールも見るようにしています。
メールを見てまったく興味がわかない場合もありますが、その場合はアーカイブして終わりです。
知らない単語が出てくることも多いですが、その都度調べることで新しいことを学ぶことができます。

無知で恥ずかしいですが、最近知ったのはCross-Origin-Resource-Policyです。

他のグループ

blink-dev以外にもchromiumに関するグループはあります。 例えばdevtools-devやChromium-devがあります。全く投稿が無いグループもありますが、グループ名から興味のあるグループを覗いてみるといいと思います。

https://groups.google.com/a/chromium.org

他のブラウザ

自分はChromium派生ブラウザを使うことが多いのと(良し悪しありますが)ブラウザの進歩をリードしているのはChromiiumだと考えているので、他のブラウザについては全く見ていません。
しかし、他のブラウザでも最新情報を追う方法はあります。
Jxckさんが配信しているmozaic.fmでは毎月Webの最新動向を配信するMonthly Webがあるのですが、それを聞くと毎月の最新情報はキャッチアップできます。
Jxckさん自身がどうやってキャッチアップしているかというのは以下のエントリにまとめてくださっています。僕もこのエントリを読んでblink-devを知りました。

blog.jxck.io

このエントリに書かれているように他のブラウザでも最新の情報を能動的に得る方法はあります。

また、ChromeにCanaryがあるようにFirefoxにはNightlyがあり、SafariにはTechnical Preview版があります。それらを使ってみたり、CHANGELOGを追うのもいいかもしれません。

今回は最新のChromiumの情報を得るために行っていることを紹介しました。
最後までお読みいただきありがとうございました。質問や不備などがありましたらTwitterまたははてブとかでコメントしてもらえるとキャッチアップできると思います。

Kyoto.js 15で"off-the-main-thread with WorkerDOM"というタイトルで登壇しました

kyotojs.connpass.com

表題のとおり、Kyoto.js 15で登壇してきました。

speakerdeck.com

off-the-main-threadについては昨年のNode学園30時限目で@kosamariさんが発表していたあたりから関心はありました。

speakerdeck.com

Kyoto.jsの翌日に開催された次世代Webカンファレンスでもoff-the-main-threadに関しては何回か言及されていましたし、注目されていると思います。フロントエンドのセッションでは「2、3年後には当たり前になっているかもしれない」とも話されていました。


Frontend - 次世代Webカンファレンス #nwc_front

WorkerDOMに関しては、社内のインターン生から「AMPページでスクロールしたらでこういうバナーを差し込みたいのですが・・・」って質問されて「amp-position-observerでできないですかね」って話すと、要件が色々あるみたいでどうやら試したけどできなさそうでした。

www.ampproject.org

JavaScript使えるならここのdivのdisplay書き換えるだけでいいんですけどね」って話をしていたのですが、「そういえばAMPでJavaScript使ってDOM操作できるライブラリをどこかで見たぞ」と思い出して調べると、amp-scriptがそれっぽくて中でWorkerDOMが使われていました。

github.com

WorkerDOMはReactなどのライブラリとも互換性があると書かれていたので、試してみたところ成功しました。

developers-jp.googleblog.com

せっかくなのでJSの勉強会で話そうと思っていた時にKyoto.js開催が決まったので今回話したという経緯になります。

発表ではcreate-react-appで作った雛形をビルドしたJSファイルをWorkerで動かすということもできることを話したのですが、実際はcreate-react-appで雛形作ってnpm run buildでできたJSファイルをWorkerで読み込めばいいのですが、そのためには多少初期設定から変更が必要でした。

index.htmlを書き換えたり、webpack.config.prod.jsを書き換える必要がありました。それらに関しては時間の都合や話の本質ではない(webpackの話をしたいわけではない)ので発表時には話しませんでした。

diffを貼っておくので興味があればみてください。「いや、こうやればいいでしょ」などツッコミどころがあればどんどん教えていただけると嬉しいです。

github.com

最後までお読みいただきありがとうございました。質問などはTwitter(@shisama_)までお願いいたします。

『エンジニアのためのマネジメントキャリアパス』から学ぶ、キャリアアップを楽しむためには

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

O'Reilly Japan - エンジニアのためのマネジメントキャリアパス

内容はいちメンバーからマネージャー、CTOや経営幹部までのキャリアパスや各職務についてわかりやすく明確に書かれています。
上のO'Reillyのリンク先に内容の説明書きと目次が載っているので惹かれるものがあればそこから読んでみても学びや気づきはあるかと思います。

この本を知るきっかけになったのは及川さんのこのブログ記事でした。

takoratta.hatenablog.com

この記事の中でも以下にとても共感できたので読むことにしました。

どのように地位が高くなろうと、自ら手を動かし技術に触る機会を持つべきであると一環して言われているように、高い技術力と組織作りの両方が要求されるからであるが、技術をやり続けられるならばと魅力を感じる人も多いであろう。

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド - Nothing ventured, nothing gained.

この記事では、自分の経験を照らし合わせながら本の中で特に心に残った箇所を書き残しておきたいと思います。

相手の言葉をよく聴き、相手の言葉で話す

これは新入社員の研修メンターを担当したときに感じたのですが、自分の言葉で話しても伝わらないものです。
自分では当たり前と思っていたり、ある程度経験年数のあるエンジニアであれば"言わずもがな"な内容であったとしても、新入社員や経験の少ないエンジニアには相手が理解できる内容で伝えないと理解してもらえません。
当たり前すぎることですが、つい自分の言葉で話してしまい後から反省することはよくあります。
多くの自己啓発本やビジネス書の類の本にもよく傾聴力の大切さが書かれています。
指導方法も「こうしなさい」と最初から言うのではなく、相手の話を聞いて改善点はどこにあるのかを見極める必要があると思います。例えば、わからないことがあった時に調べ方が悪いのか、コードを読む力が足りていないのか等、改善点が異なっていることがあると思います。答えがわかっていて言いたい気持ちがあってもグッと堪えて相手の話を聞くことで相手の短所や傾向がわかってくるのかなと思います。
また、この本の中では相手の言葉を理解できているか確認するための「相手の発言を復唱する」「相手の発言を自分なりの表現で言い換え、返してみる」練習をする実地で行うことを勧めています。これは意識して取り組んでいきたいと思いました。

細かすぎる上司と、任せ上手な上司

人に任せることが難しく感じることはよくあります。例えば、部下に任せた仕事の進捗が良くないと細かく指示をしたり管理したくなってくることがあります。しかし、信頼して任せること、責任を負わせないことを貫くことが大切だと思っています。
そうすることで部下との信頼関係を築くことができます。
これも意識しておかないといけないと感じています。というのも、どうしても自分でやった方が早いからやっちゃう癖があるからです・・・毎回後から反省するので改善しなければいけないと思っています。

「チームの結束を乱す人」への対処

ブリリアントジャーク*1」「秘密主義者」「無礼者」をどう対処するかということが書かれているのですが、そもそもこの3パターンに自問自答してみた方が良さそうです。
自分が得意な分野で議論になったときにマウンティングしていないか不安になりました。故意でないとしても周りの空気を悪くしたり、攻撃的になっているときはあるかもしれません。気をつけなければいけないと心に釘を打っておきました。

ITスキルの維持

小規模な技術的成果物の作成(バグ修正や機能追加の開発)には携わるべきと著者がエンジニアリングリードになったときの職務記述書(JobDescription)に記載されています。管理者もコードの作成に積極的に関わっていれば問題が起きたときにもすぐに対処できるためです。
「確かな技術力の持ち主」という評価が無ければ技術者からの評価は得られないと思います。
開発が活発であればコードはどんどん変わっていきますし、技術トレンドもどんどん変わっていきます。管理者になっても技術に積極的に関心を持ち続けることが大切です。それを楽しめるように自分自身を管理する必要もあると感じています。勉強しなければいけないからやるのではなく、やりたくて堪らないから頑張って時間を作るぐらいの心構えが良さそうです。

好奇心をもって当たれ

著者が人間関係に悩みコーチに相談したときにアドバイスされる言葉だそうです。相手が何を考えているか考えること、さらには技術や戦略や事業にも好奇心をもつこと、自分の認識や考えが間違いであったことを論破されても喜んで受け入れるようにして好奇心を絶やさずに進んでいくことを読者にアドバイスしてこの本は終わります。

全体感想

心に特に残ったことは「好奇心を絶やさないこと」「相手の話を聞くこと(傾聴)」「コーディングや技術的なスキルの向上のための時間を作る努力を惜しまないこと」です。これらを身につけていると、役職や役割など立場の変化、技術トレンドの変化、チームや環境の変化にも対応し楽しめるのではないかなと感じました。
変化に対して好奇心を絶やさず楽しみながらキャリアアップしていけるのではないかなと考えています。

コーディングや技術から離れていくのが嫌でマネジメント職を避けていた方もネガティブなイメージを捨てて、あなたがなりたいあなただけのマネージャーを目指してみてもいいのではないでしょうか。
何が何でもマネジメント職になりたくない人にとってもチームで働くために必要なことが多く書かれているので是非読んでほしいと思います。
もちろん既にマネジメントに携わっている方にもオススメです。

長くなりましたが、最後までお読みいただきありがとうございました。

*1:優秀だけど嫌なヤツのこと

Denoの標準テストモジュールについて。READMEをコミットした

あけましておめでとうございます。今年もよろしくお願いいたします。

2018年末からDenoのコードを読んだり、Denoについて調べたりしています。
DenoのテストモジュールのREADMEを書いてマージされました。今年最初のマージされたPRになります。

github.com

せっかくなので、Denoの標準テストモジュールについて簡単に紹介したいと思います。

Denoとは

Node.jsを最初に作ったRyan Dahl氏が開発しているTypeScriptをV8で動かすラインタイム実行環境です。

deno_stdとは

Denoにはいくつか標準モジュールが用意されています。

github.com

使うためにはhttps://deno.land/x/から始まるURLを指定してモジュールをimportする必要があります。
例えば今回紹介するテストモジュールの場合は

import { test, assert, equal, assertEqual } from 'https://deno.land/x/testing/mod.ts';

のように書きます。
実行のたびにHTTPリクエストするわけではなく、一回ダウンロードするとローカルにキャッシュされます。
ダウンロード先は $HOME/.deno/deps/ です。'https://deno.land/x/testing/mod.ts' は、 $HOME/.deno/deps/https/deno.land/x/testing/mod.ts にあります。

テストモジュールについて

今回コミットしたREADMEに書いたサンプルコードとAPIについて紹介します。

deno_std/README.md at master · denoland/deno_std · GitHub

import { test, assert, equal, assertEqual } from 'https://deno.land/x/testing/mod.ts';

test({
  name: 'testing example',
  fn() {
    assert(equal("world", "world"));
    assert(!equal("hello", "world"));
    assert(equal({ hello: "world" }, { hello: "world" }));
    assert(!equal({ world: "hello" }, { hello: "world" }));
    assertEqual("world", "world");
    assertEqual({hello: "world"}, {hello: "world"});
  },
});

Short syntax (named function instead of object):

test(function example() {
  assert(equal("world", "world"));
  assert(!equal("hello", "world"));
  assert(equal({ hello: "world" }, { hello: "world" }));
  assert(!equal({ world: "hello" }, { hello: "world" }));
  assertEqual("world", "world");
  assertEqual({hello: "world"}, {hello: "world"});
});

test

testという関数を使ってテストを実行します。
testには2パターンの使い方があります。

  • namefnを持ったオブジェクトを渡す
  • named functionを渡す

型は以下の通りです。

export type TestFunction = () => void | Promise<void>;

export interface TestDefinition {
  fn: TestFunction;
  name: string;
}

export function test(t: TestDefinition | TestFunction): void 

assert

これはbooleanを引数に取るアサーション関数です。
基本的に後述するequalと一緒に使います。

assert(expr: boolean, msg = "") 

となっていて第一引数は比較結果をbooleanで渡し、第二引数は失敗時のエラーメッセージを渡します。

equal

これは期待値と結果の値を比較してbooleanを返す関数です。
成功ならtrueを失敗ならfalseを返します。
上記のサンプルコードにもありますが、Objectも比較してくれます。また、Objectの中のObjectも判定してくれます。

equal(
  { hello: "world", hi: { there: "everyone" } },
  { hello: "world", hi: { there: "everyone else" } }
)

型は以下の通りでunknownを取るので何でも渡せます。

equal(actual: unknown, expected: unknown): boolean

assertEqual

これは前述のassertとequalを組み合わせたみたいな関数です。
実際、内部の判定は前述のequalを使っています。 型は以下の通りです。

assertEqual(actual: unknown, expected: unknown, msg?: string)

最後のmsgは失敗時に表示するエラーメッセージです。メッセージを渡さない場合はデフォルトのError: actual: ${actual} expected: ${expected}が表示されます。

デフォルトのエラーメッセージは変数をそのままテンプレートリテラルで埋め込むためObjectの比較で失敗したときのメッセージが不親切です。

f:id:Shisama:20190105141654p:plain
標準のassertEqualの失敗時のエラーメッセージ

しかし失敗したObjectの内容を表示してくれるpretty_assertという便利なライブラリを使うと以下のように表示されます。

f:id:Shisama:20190105142310p:plain
pretty_assertを使った失敗時のエラーメッセージ

github.com

あとがき

Denoの標準モジュールはNode.jsのようにCoreに内包しているのではなく、必要なときだけ外部からダウンロードして使うという方式をとっていて面白いです。
標準モジュールは他にもnetloggingなどあります。
netを使った簡易Webサーバを起動する記事をQiitaに書いたので興味あれば読んでみてください。

qiita.com

最後までお読みいただきありがとうございました。質問や不備があればTwitter(@shisama_)までお願いします。

2018年の活動

2018年は様々なことを経験させていただきました。
今回は2018年の技術的な活動を振り返っていきたいと思います。
前半がプライベートな活動で後半が仕事でやったことです。

アウトプット

勉強会・カンファレンスでの登壇は大小含めて9回
Presentations by Masashi Hirano - Speaker Deck

JavaScriptに関する内容を中心にQiitaに20本
shisama - Qiita

dev.toに1本
Masashi Hirano - DEV Community 👩‍💻👨‍💻

このブログ10本(この記事含む)

登壇も記事も昨年より増えましたが、もうちょっと書けたんじゃないかなと思っています。
1つアウトプットするのに時間かかりすぎているのをなんとかしたいと考えていたり、
ネタを溜めても消化不良のまま鮮度が落ちて捌けなかったものもありもっとシュッと出せるようにしたいと思っています。

Node.js Core Collaboratorになった

思うところが色々あって春から半年ほどかけてNode.jsにコミットし続けた結果、11月にNode.jsのCollaboratorになりました。

shisama.hatenablog.com

関西Node学園を主催

同僚と一緒に関西Node学園という勉強会を運営することになりました。
運営を手伝ってくれている方々、会場を貸していただいている企業様、スポンサーをしていただいた企業様、登壇してくださっているスピーカーの方々、参加してくださっている方々には感謝の気持ちでいっぱいです。
僕たちはまだまだ未熟ですが、これからも皆様と一緒にコミュニティを活発にできればと感じています。

東京Node学園祭のスタッフ

東京Node学園祭2018にスタッフとして参加しました
当日は動画撮影とCode And Learnのメンターを行いました。
Code And LearnはNode.jsにPRを作ってみようというハンズオンです。
結果として10名以上の方がPRを作りmasterにマージされました。

shisama.hatenablog.com

Node.jsのWebアプリケーションの本格運用

仕事ではNode.jsで開発したWebアプリケーションの本格運用が始まりました。
Node.jsにすることで他の言語では発生しないようなエラーにハマったりして知見をためることができたと感じています。
例えば、こういうのとか(同僚の登壇資料ですが・・・)

speakerdeck.com

あと、Babel→TypeScriptに移行したり、設計を見直してRepositoryパターンやフレームワークをアプリケーションから分離していったりしていきました。
設計もっと強くなりたいと毎日感じています。

PMを務めた

表示速度の改善のためにWeblio英和和英辞書( https://ejje.weblio.jp )など主要な辞書サービスをAMPページに対応させました。
小さなチームでしたがプロジェクトマネージャーをさせていただきました。
AMPの実装自体は簡単なのですが、広告収入やユーザー数などビジネスサイドへの影響を考えながらGoogle Analyticsで計測しながら開発を進めたり他の部署のメンバーの進捗管理を行ったことは良い経験になりました。

ちなみにその一部をHTML5 Conference 2018で話しました。
ポジティブなFBも多くいただき嬉しかったです。

speakerdeck.com

技術的負債と戦う

15年もののレガシーシステムと絶賛戦っています。
JSPサーブレットで書かれていて環境構築も困難極まりないので、とりあえずDockerにしてイメージをPrivateレジストリに置くまでしました。

ちなみにDockerやPrivateレジストリについても登壇したので、興味あれば御覧ください

来年はコードやアーキテクチャリファクタリングしていきたい。
ちなみにこのリファクタリングプロジェクトのスローガンは「面白くないものを面白くする」なので、自分も楽しみながらやっていきたいと思います。

あとがき

振り返ってみると今年はNode.jsやJavaScriptばかりやっていました。
来年はもう少し幅を広げていきたいと考えています。
Web以外のこともやりたいとぼんやり思っているのですが、なかなかできずにいます・・・
来年は今年よりコード書きたいです。

あとNode学園祭のときに海外から来たスピーカーやNode.jsのTSCメンバーと会話がうまくできなかったので、英語にも力を入れていきたい。

では、来年も@shisama_をよろしくお願いいたします。
🎍良いお年を🐗

2018年買ってよかったもの

今年の買い物の履歴を残しておこうと思います。
買って良かったものを紹介していきます。

掲載順は購入して順番です。

完全ワイヤレスイヤホン

AppleAirPodsが出たときに「これはすごい!欲しい!!」となったのですが、AirPodsカナル型ではないのでなかなか購入に踏み切れずにいました。
そんな中rebuild.fmで宮川さんがAnkerのZoloが良いって言っていたのを聞いて調べたところ8000円ほどだったので即購入しました。
初期不良で左耳から音が出なかったのですが、18ヶ月保証があるのですぐ交換してもらえました。Anker Japanのサポートも迅速かつ丁寧で好印象でした。

音質も結構良いと思います。あと全然耳から落ちませんし、つけ心地も良いです。
一番驚いたことは防水性です。誤ってポケットに入れたまま洗濯してしまったのですが、今の所全く問題なく使えています。

初めての完全ワイヤレスイヤホンにオススメです。
今だと同じAnkerから出ているSoundcore Liberty Liteも良さそうです。

浄水器

浄水器を買うまでは飲料水を買ったり、スーパーのRO水(濾過水)を利用していました。
しかし、数リットルの水をスーパーから自宅まで運ぶのはかなりの労力が必要です。
年間5000円でこの労力を消費しなくても済むようになったので、もっと早く買っていれば良かったと感じました。
また、この商品はカートリッジ交換が1年に1回なので面倒くさくないのが決め手でした。

スマートスピーカー

Amazon Echo DotとGoogle Home Miniを買いました。

生活をスタイルを変えたモノです。
Amazon Echo Dotはリビング用、Google Home Miniは自室用に使い分けています。
毎朝、天気やニュースを聞くだけでなく、家で音楽を聞くためにも使っています。
元々Amazonプライム会員でしたが、Amazon Music Unlimitedもサブスクリプションするようになりました。
後述の商品でも紹介しますが、家電もアレクサに指示して操作しています。

あと、Alexaスキルも開発しました。Linuxのコマンドをランダムで紹介してくれるアプリです。  かなりニッチですが、興味があれば使ってフィードバックもらえると嬉しいです。

Linuxコマンド

プレステ4

アメリカ国籍の同僚がアメリカに帰国することになり、持って帰ることができないので格安で売りますよって言ってくれたので15,000円で買い取りました。
元々ゲームはしない方なのですが、格ゲーだけは好きでMARVEL vs CAPCOMの最新作はやりたいなと思っていました。

あとAmazonプライムビデオやYouTubeなどのメディアプレーヤーとしても使っています。 最近はもっぱらプライムビデオの観賞用として使っています。
15,000円で買えたのはかなり良いお買い物でした。

食洗機

我が家は共働きのため、なるべく家事は自動化したいと考えています。
食器洗いはそんなに時間がかかるものでもないですし、食洗機を置くためのスペースが必要ですし、頑固な汚れが洗えるのか疑問に感じていたので、なかなか購入に踏み切れませんでした。
しかし次期モデルが出るということで価格が急落し購入に至りました。

懸念していた置く場所についてはキッチンの横にラックを置くことでスペースを拡張しました。
汚れに関しては頑固な汚れもしっかり落ちています。

もっと早く買っていれば良かったと後悔した商品No.1は食洗機です。

2人以上で生活しているのであれば、50Lの食洗機を強くオススメします。

スマートフォン

store.google.com

5年間使ってきたiPhone5sからついに乗り換えました。
決め手となったのは大きさとカメラです。
最近のスマホは6インチを超えるものが多く片手操作が困難な機種が多かったのですが、
このPixel3は片手でも操作できます。
写真の画質は評判通り良かったです。また子供と一緒にインカメラで写真撮ったりするのですが、シャッターを押したときに子供が笑顔になっていなかったりカメラ目線ではないことが多かったのですがトップショット機能によりシャッターの前後で最も良い写真をAIが判定してレコメンドしてくれます。
この機能により全員がカメラ目線の笑顔の写真が残せるようになりました。

jp.techcrunch.com

iOSからAndroidに変えてよかったこと悪かったことはありますが、Androidもかなり進化していて使い勝手は全然問題無いレベルになった印象です。
ただUIはやっぱりiOSがわかりやすい感じがします。(慣れの問題?)
あとWebエンジニアとしては普通のChromeが動いたり、デフォルトブラウザを選択できたりするのは良いです。

こたつ

もうこの冬は家にいるときはずっとこたつに定着しています。
もはや多くを語る必要はないでしょう。
この記事もこたつに入りながら書いています。
この山善のこたつは2〜3人までの人数ならちょうど良い大きさで手頃な価格です。また天面は黒と白のリバーシブルになっているので好みによって変えることができます。

スマート家電コントローラー

PayPayで買いました。全額返金されませんでしたが・・・

これはスマホスマートスピーカーで家電を操作するリモコンです。
家電の赤外線リモコンを学習してスマホスマートスピーカーからWifi経由で赤外線操作を行います。
前述したスマートスピーカーと組み合わせて、家電を声で操作しています。
例えば「アレクサ、電気をつけて」というと電気をつけてくれます。
便利なのはいくつかの家電の操作を一つの命令で同時に実行してくれる機能です。
我が家では「アレクサ、おやすみ」というと電気・エアコン・こたつを同時に電源OFFにしてくれるようにしています。
また、外出先からでも操作できるので帰宅前にエアコンの電源をONにするといったこともできます。

あとがき

他にもビデオカメラやポータブルBluetoothスピーカーなど買ってよかったものは色々あるのですが、特に良かったものを紹介しました。
こう振り返ってみると結構散財したかもなーと感じています。

来年は自宅のMacbook Pro 2013を買い替えたいと考えているのですが、AirクアッドコアもしくはTouchBarなしProのクアッドコアを待っています。
iPad mini5がでるかもしれないと噂されているので、iPad mini2から買い換えたいなとも考えています。
スマートウォッチも欲しくてFitbitにしようかAmazfitにしようかとか考えています。
スマブラもやりたいな・・・

来年も散財の予感・・・

東京Node学園2018でスタッフをした

もう12月も終わりかけで今更な感じは否めませんが、途中まで書きかけて下書きのままになっていたので2018年中に出しとこうと思った記事です。

11月23日、11月24日に開催された東京Node学園祭にスタッフとして参加しました。

https://nodefest.jp/2018/

当日は動画撮影とCode And Learnメンターを担当しました。
動画については後日公開します。これから多少の編集を行い随時YouTubeにアップロードしていきます。
先に言い訳しておくと、素人が撮影しているので動画の品質についてはお見苦しい部分があるかと思います。ご了承ください。
無料で公開するわけだし、お許しいただきたい。
難しかったこともありましたが、良い経験になりました。

Code And Learnについては、hiroppyさん、ronkorvingさん、Lekoさん、Annaさん、Joyeeさんと一緒にメンターをしました。
Node.js CoreにPRを出す体験をしてもらうワークショップです。
PRを出すことをゴールとしているので、できるだけ簡単な修正のネタを探しました。
以下が準備したネタです。 * functionをarrow functionに変更 * assert.strictEqualの引数順番 * strictEqual(expected, actual)をstrictEqual(actual, expected)に修正 * APIドキュメント内のサンプルコード内のfunctionをarrow functionに変更 * ドキュメント内のtypo * V8の新APIであるArray Functionへの変更

単純な修正が多いですが、せっかくなので一つずつ説明していきます。

functionをarrow functionに変更

これはそのままです。Nodeの中のJavaScriptの中のfunctionをarrow functionに変えていく作業です。
しかし、制限をかけさせていただきました。

  • function内でthisを使っていないこと thisの扱いを間違うとバグになるためです。

  • 無名関数であること 例えばprocess.on('exit', function onExit() {...})process.on('exit', () => {...})と変更しちゃうとheap debugしたときに名前が表示されなくなります。これはユーザーにとって不便になるかもしれません。 このissueでそのことが書かれています。 https://github.com/nodejs/node/issues/8913

  • prototype.fooなどに代入していないこと これもthisに関連しています。prototypeに代入しているthisは外側のthisとは違うため単純にarrow functionに書き換えることでthisの参照先が変わってしまいバグが発生するかもしれないからです。

assert.strictEqualの引数順番

これは簡単でNodeのテスト内で使われているassert.strictEqualの引数の順番を修正するものです。APIの仕様を見ていただくとわかるのですが、第一引数がactual、第二引数がexpectedです。
しかしNodeのテスト内には第一引数にexpected、第二引数にactualを設定しているコードが多数存在します。
なので、その引数の順番を修正するのが目的です。

APIドキュメント内のサンプルコード内のfunctionをarrow functionに変更

これはAPIのドキュメント内に記載されているサンプルコードの中のfunctionをarrow functionに置き換えていく作業です。
制限については前述した内容と同じです。

ドキュメント内のtypo

http2のAPIのドキュメント内にfor this this HttpStreamと余分なthisがあったので、それの修正です。

V8の新APIへの修正

Node.jsが使っているJavaScriptエンジンであるV8のAPIを使った配列の追加方法を新APIに書き換える作業です。 これはJoyeeが説明を書いてくれています。

github.com

これも修正のサンプルDiffを用意して、そのとおりに置き換えていく作業だったため作業としては単純でした。