別にしんどくないブログ

技術のことや読書メモを書いています

W3K Web Developers Meetup #1 を開催しました。 #w3kansai

特定の言語やフレームワークなどに属さない話やWebに関する勉強会を開きたいという思いがあり、W3Kという勉強会を開催することにしました。

w3k.connpass.com

当日の様子です。

togetter.com

需要があるのかわからなかったので、最初は参加枠を15名にしていたのですが有難いことにすぐ埋まりました。そのため、参加枠を35名に増枠しての開催となりました。

キャンセルなどもありましたが、参加登録してくださっていた方の8割以上が当日来場されててドタキャンが少なく良かったと思いました。

セッション

Take rendering process to pieces for Web browser performance / @plum_shiga

レンダリングに関する話をしていただきました。
Paint処理がとにかく最強に重い!will-changeプロパティを使おうと強く主張されていて、力の入ったセッションでした。

WebUSB入門 / @aruneko99

WebUSBに関する話をしていただきました。
WebUSBはセキュリティが懸念でなかなか標準化が進んでいないイメージがあり、なかなか知見も出てきていなかったのでとても勉強になりました。

firebase を使い始めて / @koneko59

firebaseに関する話をしていただきました。

大規模データのパフォーマンス改善 / @ef_ryusx

パフォーマンス改善について話をしていただきました。
PostgreSQLのパフォーマンスを改善したことで最大約90%パフォーマンス改善したのはすごいのでぜひPostgreSQLをお使いの方はぜひ資料を御覧ください。

ビデオの字幕ってどうなってんの? / @Daikids2

web videoの字幕・キャプションを行うWebVTTについて話をしていただきました。
<track>タグやWebVTTといった馴染みのない技術を紹介されてて、見るもの聴くものが新しく勉強になりました。

Portalsを試してみた話 / @granciel_33

Portalsに関する話をしていただきました。
Google I/O '19やChrome Dev Summit '19などでも大きく紹介されていて注目度が高い技術で、まだ新しい技術なので事例や知見がまだ少なかったので大変勉強になりました。また、Portalsについてはもう少し使われ始めたら別途テーマとして勉強会を開きたいなと考えています。

最後に

初回ということで参加者が何を期待しているか、期待されていることとイベントの趣旨に大きな乖離がないか心配でしたが、概ね満足していただけたようで良かったです!これからも定期的に開催していきたいと思います。

最後までお読み頂きありがとうございました。今後ともW3Kを宜しくお願いします。

【資料公開】FRONTEND CONFERENCE 2019でXSSやセキュリティについて話します #frontkansai

2019-11-02 グランフロント大阪で行われるフロントエンドカンファレンス2019に『フロントエンドエンジニアのためのセキュリティ対策~XSS編~』というタイトルで発表します。
資料は公開しています。100ページ超えているので読むのが大変だと思います。(作るのも大変だったが・・・)
当日までに変更はあるかもしれませんが、大きくは変わらないと思います。マサカリ待ってます。

speakerdeck.com

スタッフとしても携わっているので当日はスタッフ兼登壇者ということであまり懇親会などには顔を出せないかも知れませんが、もし見かけたら気兼ねなく話しかけてください!質問やマサカリも待っています!!
発表をぜひ聞きに来てください!

2019.kfug.jp

そもそもこの話をするきっかけになったのは、Webは脆弱性と常に隣り合わせだなと日々感じることが多く、Webに関係するセキュリティ関係を調べていたところCSPやTrusted Typesなどブラウザのセキュリティ対策の機能に興味を持ち調べたためです。
CSP Lv.3はW3CのWorking Draftが出ていてTrusted TypesはChromeshipされようとしています

もし、お読み頂いている方でWebのセキュリティに興味がある方は仲良くなってください!色々教えてほしいです!

では当日お会いしましょう!お読みいただきありがとうございました。

関西Node学園 8時限目を開催しました。 #kng8

nodejs.connpass.com

サイボウズ(株)大阪オフィスにて開催しました。 Node.js v12がLTSになり、v13がリリースされたタイミングに合わせて開催しました。

当日の様子です。

togetter.com

登壇内容

Node.js v12のES Modules / @shimataro999

t.co

Node.js v12でES Modulesを使う方法や、CommonJSとES Modulesでの相互運用の話、importするファイルの拡張子の補完などについて話をしていただきました。

Node.jsではES Modulesを実験的にサポートしています。従来Node.jsはCommonJSというモジュールシステムを採用してきましたが、ここ数年Node.jsはWebの仕様に合わせていこうとしています。従来のCommonJSでのモジュール解決を破壊してしまうとnpmパッケージの多くが使えなくなる可能性があります。そのためNode.jsとしてもなかなかES ModulesをNode.jsでサポートするのに時間がかかっています。

資料中にも出てきましたが、以下の記事がNode.jsのES Modulesについて詳しく書かれています。

medium.com

Node.js v13の気になる変更点 / @shisama_

speakerdeck.com

10/22にリリースされたNode.js v13について話をしました。
内容は以下のブログに書いた内容と重複するので割愛します。

shisama.hatenablog.com

AmazonAPIGatewayのLambdaAuthorizerでJWTを検証するLambdaをServerlessFrameworkでデプロイする / @is_ryo

docs.google.com

API Gateway Authorizersで使えるLambda AuthorizerでのJWT(JSON Web Token)の検証を行う話をしていただきました。
JWKやjsonwebtokenを使ったJWTの検証、ServerlessFrameworkを使ったLambdaにAuthorizerをデプロイする方法について紹介してくれました。

serverless.com

私個人としてはこの辺はかなり弱いので、「そんなものがあるのか」と初めて知ることばかりでした。

今回紹介していただいた内容を踏まえたサンプルも用意していてもらっています。

github.com

Cloud Storage for Firebaseとセキュリティルール / @mochiya98

docs.google.com

FirebaseのCloud Storageにファイルを保存するときにメタデータに紐付かないファイルはアップロードを制限する方法について話をしていただきました。
Cloud Storageにはメタデータを付与してアップロードすることができます。しかし、クライアントが任意にメタデータを付与できてしまいます。任意ではなく、決まったメタデータ(例えば有効期限やパスワード)を必ず付与したい場合直接のファイルアップロードを禁止にします。ファイルのメタデータはFirestoreに保存しておき、アップロードはCloud FunctionsでAdminSDKから書き込みを行うことでファイルとメタデータの紐付けを担保するという方法を紹介していただきました。

Trying State Manegemant without Redux(updated) / @nkgrnkgr

speakerdeck.com

Reduxを使わずにReact HooksとContextで状態管理を行う話をしていただきました。
Reduxはコードが冗長になり、教育コストが高めということでReduxを使わずにReactだけでやってみようとしたとのことです。 ContextとuseStateを使うことでグローバルな状態管理を行うことができます。Contextを使いたいときはuseContextでContextを取り出すことができます。
また、useReducerを使うことでReduxと同じようにactionが発行するtypeによって処理を分岐させるreducer関数を書くことはできます。しかし、この場合はReduxの冗長さは解決できません。
また、Reduxはredux-thunkやredux-sagaなどのミドルウェアが便利なので使っているという方は多いのではないでしょうか。しかし、Reduxを使わないことでJSのファイルのサイズを抑えることができたり、冗長さを回避するように書くことができるメリットはあります。

asyncQuerySelector / @salamander_jp

docs.google.com

MutationObserverを使ったライブラリでターゲットのDOMが標示されるまで待つことができます。

デモページを用意してもらっています。

https://codepen.io/04/pen/ZEEKVyz?editors=1010

また、同様のことが可能なライブラリがあります。asyncQuerySelectorはこのライブラリを参考に作ったとのことです。

github.com

最後に

今回はNode.jsの発表もあり、LambdaやCloud Functions、フロントエンドの話など多彩な内容だったのが良かったと思います。
私も知らないことが多かったので勉強になりました。

今回、参加者(登壇者含む)が35名だったのに対してキャンセルが30名も発生してしまいました。プレミアムフライデーということもあってタイミングが良くなかったのかも知れません。
また、当日キャンセルせずに来られなかった方が6名ほどいました。

他の勉強会の主催者からも金曜日は避けた方がいいというアドバイスをいただいているのもあり、当日参加していただいた方々に何曜日が都合悪いかアンケートを取ってみました。 その結果、火曜と水曜がほぼ手が上がらなかったので、火曜と水曜に開催してみようかなと思いました。

関西Node学園では開場提供をしていただける方やJavaScriptやNode.jsに関わる発表をしていただける方を通年募集しています。
もし、興味がございましたらTwitterやshisama07@gmail.com宛にメールをしていただけると幸いです。

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

【資料公開】関西Node学園でNode.js v13について話します

nodejs.connpass.com

10/25に行う関西Node学園 8時限目でNode.js v13の変更点について話します。
昨日のブログで紹介した内容を発表します。

shisama.hatenablog.com

資料は公開済です。質問や不備がありましたらお手数おかけしますが、Twitterブコメ等で教えていただけると助かります。

speakerdeck.com

Node.js v13の主な変更点

Node.jsのv12がLTSになり、v13がcurrentとしてリリースされました。 ダウンロードは公式ページから行えます。

nodejs.org

今回はNode.js v13の主な変更点を紹介したいと思います。
以下リリースノートにあるNotable Changesからいくつかピックアップします。

nodejs.org

assert (PR: #28263)

assert.throws()またはassert.reject()でthrowされたエラーの検証にコンストラクターが使われた場合、throwされたエラーの代わりにAssertionErrorがスローされます。

コードで見た方がいいかもしれません。

gist.github.com

build (PR: #29887)

full-icuでビルドされるようになり、i18n系の機能ですべての言語をサポートしました。

Node.jsはこれまでビルド後のバイナリサイズの増加への懸念により、--with-intl=small-icuオプションを付けてビルドしていたバイナリを配布していました。
しかし、v13からは--with-intl=full-icuでビルドしたバイナリを配布するようになりました。
懸念されていたバイナリのサイズですが、macOSだと35MBから49MBになります。

オプションによる言語サポートの違いは以下の表のとおりです。こちらからも確認できます。

https://nodejs.org/api/intl.html#intl_options_for_building_node_js

挙動の違いに関するサンプルコードは以下のとおりです。

gist.github.com

v12以下(small-icuでビルドされたバージョン)はM01と出力しますが、v13以降(full-icuでビルドされたバージョン)はeneroと出力します。

console (PR: #29251)

console.timeEnd()console.timeLog()の結果がミリ秒ではなく時分秒の単位で出力するようになりました。

単位はh(時)、min(分)、s(秒)があります。

サンプルコードは以下の通りです。

gist.github.com

v12では3001.732msと出力されていましたが、v13からは3.001sと出力されます。

deps (PR: #29694)

JavaScriptエンジンのV8のバージョンが7.8になりました。

これによりObjectの分割代入のパフォーマンス、メモリ使用量、WASMの起動時間が改善されます。
詳しくはV8のブログを読んでください。

v8.dev

http (PR: #29589)

古いHTTPパーサーが削除されました。

v12からすでにデフォルトではllhttpが使われています。

github.com

しかし、--http-parser=legacyとオプションをつけてnodeを起動すると古いパーサーを使うことも可能でした。
v13からはEnd-of-Lifeとなりました。オプション自体が削除されました。

llhttpはTypeScriptで書かれたhttpパーサーです。

github.com

古いHTTPパーサーは保守が難しく、またアーキテクチャ上パフォーマンスに問題がありました。
llhttpは保守性向上のためにTypeScriptで書かれています。それをCのコードやビットコードに変換しています。
古いHTTPパーサーに比べてパフォーマンスはかなり向上しています。

Image from Gyazo

http, http2 (PR: #27558)

デフォルトのサーバータイムアウト時間が変わりました。

これまでサーバーのタイムアウトの時間はデフォルト2分でした
リクエストが完了するまでに2分以上かかる場合、ソケットは閉じられ空のレスポンスを返していました。
そのため、画像の変換やサイズが大きいファイルのアップロードなど処理に時間がかかる場合、処理の途中でリクエストが閉じられることがありました。
これまでも--http-server-default-timeout=millisecondsオプションを使うことでユーザー側でもこの時間を変更することは可能でした。0に設定することでサーバータイムアウトを無効にすることもできました。

v13からはデフォルトで0が設定されるようになりました。つまりサーバータイムアウトが無効になりました。

ES Modules (PR: #29866)

まだWIPでリリースされていませんが、ES Modulesもv13からフラグなしで使える予定になっています。

v13.2.0からフラグ無しで使えるようになりました 🎉 *1

nodejs.org

とはいえ、まだexperimentalなので自己責任でご使用ください。

Node.js v12にもマイナーバージョンの更新(12月か3月ごろ?)でバックポートする議論もされています。

New Release Plan · Issue #400 · nodejs/modules · GitHub

最後に

今回紹介したのは一部の機能になります。自分が気になった変更をまとめただけですので、他にもすごい変更点はあるかもしれません。

Node.js v13は2020年6月でEnd-of-Lifeになる予定です。
次のNode.js v14は例年通りだと2020年4月にリリースされ10月末にLTSになる予定です。今回紹介したv13の機能も含まれます。

https://raw.githubusercontent.com/nodejs/Release/master/schedule.svg?sanitize=true

最後までお読みいただきありがとうございました。質問や不備はTwitterブコメなどでお願いいたします。

*1:2019-12-10 追記

【資料公開】#v_kansai 11でVue.jsのパフォーマンスについて話します。

vuekansai.connpass.com

京都Devかふぇ#7〜Vue.jsLondon2019参加報告会(非公式)〜【v-kansai共催】 - connpass と共同開催みたいで、こちらの参加枠はまだ空いているのでお時間あればぜひ。

表題のとおり、v-kansaiでVue.jsに関するパフォーマンスTipsについて話をします。本当はWorkerDOMの話も盛り込みたかったが時間が足らなかったのでまたどこかで...。
言い訳がましい感じになりますが、転職してからVue.jsを触っていないので、もっと良い方法はあるかもしれません。マサカリ待っています。

speakerdeck.com

参考にした記事

今週末のVue Fesは参加しないですが、台風は来ないであげてほしい。参加数1400名の大規模カンファレンスということもあり、運営さんは気が気じゃない想いだと思います。

ウェブリオを退職しました。「いい話」から5年経ったいま

この記事は念の為元上司に査読していただきました。

2019年8月末でウェブリオ株式会社を退職します。
ウェブリオはオンライン辞書サービスを運営する会社です。

インターネット上にウェブリオの中の人の声や退職エントリは少なく、ウェブリオに入社しようと考えている人にとって情報が少ないと思いこの記事を書くことにしました。ウェブリオへの入社を検討されている方に参考になれば幸いです。

「いい話」

とても多くの人に読まれたウェブリオの退職エントリがあります。
以下の記事ははてなブックマーク数1000を超え、「ウェブリオ 退職」で検索すると検索上位に出てきます。
そのため、ウェブリオに入社を考えている人は一度は読んだことあるかと思います。
便宜上、本記事では「いい話」と呼ばせていただきます。

takeda25.hatenablog.jp

しかし、5年前の記事で情報が古くなっています。

その後W社の社風や開発者の扱いに変化があったかどうか等についてご自身で最新の情報を得ていただければと思います。

と「いい話」の冒頭にもありますように、本記事ではウェブリオの現在についてお伝えできればと考えています。
これから書くことはあくまで2019年時点の情報です。もし数年してこの記事を読んでいる人がいれば参考になさらずご自身で最新の情報を探していただければと思います。

「いい話」から5年経ったウェブリオのいま

この節では「いい話」を読まないとわからない内容が含まれています。

「いい話」が投稿されたのが2014年4月で、僕が退職したのが2019年8月なので5年が経過しています。
そのため、会社の中は変わっています。
もちろん「いい話」に対して批判を書くつもりはございません。 というのもこの方とは在籍期間が重なっておらず、全く面識がありません。また、在籍していたオフィスも違います。
そのため「いい話」に関しては真実かどうかも判断できません。 ちなみに僕は「いい話」の流動性には共感する部分があります。

実質上司について

まず、「いい話」に出てくる実質上司はすでに退職しています。
僕が入社した2016年8月時点ですでに退職されていました。
「いい話」に登場するエンジニアの方々はすでに全員退職されています。
現在在籍するエンジニアの中には「いい話」に出てくるような性格の方はいないかと思います。

OSSについて

MIT ライセンスの JavaScript 外部ライブラリを使おうとすると、「使っても問題ないか調査してください」と言われ、またできれば外部のものは使わずに実装してほしいと言われた。

OSSのライブラリについてはむしろ使っていきましょうという雰囲気です。
ウェブリオ自身もGitHubにMITライセンスでソースコードを公開しています。

github.com

役員との関わりについて

偉い人レベルでの、従業員は使い捨て可能・交換可能な部品であるという見方。

これについては私は結構大切にしていただいていた方だと感じています。
意見を尊重してくれましたし、最終出勤日に営業部の幹部の方から労いの電話をいただいきました。
人によっては合う合わないありますが、幹部の方と従業員の距離は非常に近いです。
また、意見をする人を尊重・評価する傾向があり会社に意見はしやすかったです。

良かったところ

ここから先は「いい話」とは関係なく、私がウェブリオに感じたことを書いていきたいと思います。
私自身の体験や感じたことに基づくので、違った意見や考えもあるかもしれませんがそれは他の社員の方が書いてくれることを期待しています。

働く環境について

働きやすさ・風通しの良さを求めている人にはウェブリオはおすすめです。 「いい話」にも出てきましたが、残業は本当に少ないです。有給休暇も1時間単位で取れました。申請こそありましたが、却下されることはありませんでした。これが個人的には一番最高でした。
10:00〜16:00コアタイムのフレックスだったので、僕はたまに朝1時間の有給をとって11:00に出社していました。朝起きて「11時に出勤します」とメールするだけなので、有給のとりやすさは抜群に良いかと思います。
非常に働きやすい環境かと思います。子育て、コミュニティ活動、OSS活動を並行して行えたのはこの働きやすさがあったからだと感じています。

学習支援について

技術書やビジネス書などの書籍は申請なしで購入することができました。各々がAmazonでポチるだけです。申請はいりませんでした。
備品も正当な理由があれば購入してもらえます。
勉強会やカンファレンス参加も業務として行くことができ、参加費用や旅費を出してくれる制度もあります。
地方に住んでいるエンジニアとしては東京で行われるカンファレンスに参加しやすかったです。
そういった学習支援を重視している人にとっても良い会社だと思います。

良くないと思うところ

評価について

マネジメントよりコードを書き続けたいタイプの人にはおすすめしません。コード書いてるよりマネジメントしてる方が評価される傾向があるように感じました。成果を出し続けている技術力ある人よりマネジメントしている人の方が評価されていました。私の推測ですが、幹部にエンジニア上がりの人やCTOのような技術のわかる人がいないのが原因なのかなと思いました。これは幹部の人も対応しようと考えていてリーダークラスのエンジニアの意見を評価の参考にするなど技術に対して評価できるように試行錯誤しているようにも見えました。

給料について

給料は低いです。私は給与テーブル上の平社員ではそこそこ上のほうにいたと思いますが、年収450万円弱でした。そのため、ほとんどの社員が400万円台なのではないかと推測できます。私自身転職ドラフトの指名額などを参考に市場価値に合った給料をいただけていないことを把握していました。
これはウェブリオに限った話ではないですが、市場価値に合わせた待遇にしなければ良い人は採用できませんし社員は辞めていくと思います。
ウェブリオもこれについては人事を中心に考えていると思います。一気に給料UPはなかなか難しいと思いますが、少しずつでも改善されると期待しています。

ちょっと話がそれますが、報酬の総定額を採用プロセスの早い段階で言ってしまった方がいいんじゃないかなと思います。内定出してから報酬を伝えることが多いですが、その時点で大きくズレが生じていて辞退することになることは珍しくありません。双方にとって面接などにかけた時間とかもったいないと思うんですよね。その点、最初から金額がわかっている転職ドラフトは良かったです。転職ドラフトに限らず、今回オファーいただいた企業は最初に参考値を提示してくれました。大変助かりました。

退職理由

転職前に昇進の話をいただいてて給料も上がるし評価もいただいてたので、上記の理由が直接的な退職のきっかけになったわけではありません。優秀な方々が徐々に辞めていったことが大きかったです。他の人の退職に関しては様々な理由があるのですが、ここでは控えさせていただきます。
優秀な人が退職していきだんだんと楽しさを失ってたときに、ある企業からお誘いいただいたのが直接的な退職のきっかけになりました。
もちろん給料も前述の通り市場価値に沿った金額をいただきたいと考えていました。

最後に

「いい話」が書かれてから5年経ってウェブリオ内部の変わったところや私が感じたことを書きました。
色々書きましたが私はウェブリオに入社して良かったと考えています。子をもつ身としては働きやすかったですし、自由に色々させていただき成長につながったと思います。
もし興味があれば、応募してみてください。

www.weblio-inc.jp

次はサイボウズ株式会社のフロントエンドエキスパートチームで働きます。こちらも興味があればご応募お待ちしております!

cybozu.co.jp

退職のタイミングでなくてもいいのですが、会社のことを社外に発信することで採用のミスマッチを防ぐことができるかもしれません。どんどん発信していくべきだと思います。
この記事がウェブリオに入社しようか考えている人にとって参考になることを願っております。

最後までお読みいただきありがとうございました。質問などはTwitter宛やコメントなどでお願いいたします。