massa142's blog

くり返す このポリリズム

2017年の振り返り

massa142.hatenablog.com

エンジニア

Python

PyCon JP 2017 システム開発

保守・運用がんばった。2018に向けた動きはあまりできなかった。もう少し人手がかからないようにしたい。

PyCon JP 2017 スポンサー

なんとDiamondスポンサーだった。自分がめっちゃ驚いた。社内とPyCon JPとの調整とか事前準備が大変だったけど、めったにない機会を楽しめたと思う。

SQUEEZEのCore Valueの1つである『With Our Community』の考えのもと、来年も引き続きスポンサーをやっていこう。

PyCon JP 2017 にスポンサー・スタッフとして参加してきた #pyconjp - massa142's blog

PyCon JP Reject Conference 2017 開催

去年のPyCon JPが終わったあとからRejectConやるぞって話してたので、なんとか実現できてよかった。また来年もできればいいな。

PyCon JP Reject Conference 2017を開催しました #pyconjp_rc - massa142's blog

Pythonもくもく会 毎月開催

PyCon APACに行ってきたり、PyCon JPの準備で忙しかった8月は開催できなかったけど、それ以外は毎月開催できた。

自分の作業時間確保も兼ねてるけど、来年も引き続き開催してコミュニティに貢献していきたい。

PyCon APAC 2017に参加する

Silverスポンサーとして参加してきた。SQUEEZEで英語に抵抗がなくなったからか、去年のAPACよりも英語でのコミュニケーションが苦じゃなかった。参加者と色々話せるようになってより楽しめた。

来年はCfPかLT応募がんばりたい。

PyCon APAC 2017 に行ってきた #pyconapac2017 - massa142's blog

JavaScript

Okachi.js

毎月継続参加した。毎回アウトプットの場を設けてくれるので、とても自分のためになっている。Okachi.jsから書籍執筆につながっているから、この勉強会(コミュニティ)に感謝しかない。来年も盛り上げていきたい。

Angular

github.com

翻訳手伝ったりした。来年はng-japanのコミュニティにもっと参加していきたい。

あとSQUEEZEのなかのAngularJSの部分をAngularに移行していく。

新しい言語

新しく勉強する言語をRustに決めたけど、今年は結局勉強できなかった。ちょっと余裕がなかった。

Rustは2018年の目標にするぞ。

アウトプット

はてなブログ

今年は44記事だった。毎月の振り返り・読書ログ・イベント参加レポを欠かさなくなったら、思ってたよりも書いてた。

習慣化できていてよい。

Qiita

例年同様Advent Calendar駆動のアウトプットになった。

WikiHub 日報

ゆるく1年間続けてる。日報に書くようことがないと、仕事や勉強でサボってることにすぐ気付けるのでよい。

スライド

今年は登壇機会を増やそうとしていった。Okachi.jsやSQUEEZE社内でLTをやっていってるのが活きている気がする。

執筆

codezine.jp

2017年前半にあった書籍出版の話は途中でなくなっちゃったけど、後半に書籍共著2つとWeb連載1つの執筆がありがたいことに始まった。

キャパオーバーで遅れ気味になってるけど、なんとか全て完成させるぞ。

SQUEEZE

今年取り組んできたことは主にこんなところ。

  • GoでのAPIプロキシサーバ開発
  • お問い合わせフォームのserverless化
  • マイクロサービス化
  • Python3移行
  • 静的ファイルのCDN配信
  • リファクタリング
  • 品質向上
  • パフォーマンス改善
  • スクラム導入
  • CircleCI2.0導入

会社としては

  • 新規プロダクトのリリース
  • 自社ブランドのホテルオープン
  • 旅館、ホテル、簡易宿泊所の運営サポート開始
  • @laugh_kが入社

などがあった。

詳しくは2017年の振り返り - checkpointの日記に書かれてる。

来年はもっとフロントエンドの改善に取り組んでいきたい。

読書

bookmeter.com

ここにある12冊の他にも、電子書籍Angular CLIがわかる本とかWeb連載時のGoならわかるシステムプログラミングを読んだ。

ドラマ

映画

Perfume

2017年参戦記録

2017年のPerfumeを振り返る #prfm - massa142's blog

ラクロス

  • リーグ戦第1戦 vs TLC 10-4
  • リーグ戦第2戦 vs DESAFIO 7-7
  • リーグ戦第3戦 vs RAGGAMUFFINS 10-6
  • リーグ戦第4戦 vs TLC 7-2
  • リーグ戦第5戦 vs DESAFIO 9-6
  • リーグ戦第6戦 vs RAGGAMUFFINS 13-5
  • 入れ替え戦 vs VIKINGS 10-7
  • プレーオフ第1戦 vs VALENTIA 8-7
  • プレーオフ第2戦 vs Stealers 6-26
  • 全日本クラブ選手権初戦 vs OPEC 16-8
  • 全日本クラブ選手権準決戦 vs FALCONS 7-16

二部からスタートだったけど、目標としていた「一部奪還」を達成してチームとしては16年ぶりの全日本クラブ選手権にも出場できた。来年は新主将のもと、また一部で思いっきり頑張ろう。

その他

肉を料理する

Saltbaeに憧れたけど、完全にいっときのマイブームだった。 目標設定はちゃんと考えようという反省。

DJの練習はじめる

ラクロスのオフシーズンにやろうと思ってたけど、執筆で忙しくなったため断念。引き続き来年の目標に。

今年振り返ってみて

良かったこと

  • アウトプットが多かった
  • セレッソファンになった
  • 西武がさしぶりにAクラス
  • 4時までやってるけやき坂スタバを知った
  • DjangoCon mini JPに向けて始動した

悪かったこと

  • 資産管理ができてない
  • 睡眠時間を削ったせいか体調を崩しやすかった
  • 筋トレしなかった

2017年12月の振り返り

仕事

  • チーム権限機能開発
  • Tech Culture MTG
  • 静的ファイルのS3配信化

アウトプット

スライド

ブログ

Qiita

dev.to

イベント

Yasutaka Nakata presents OTONOKO

音楽

映画・ドラマ・アニメ

N/A

目標と成果

  1. △ Web連載第2回執筆
    • 年明けに書くぞ 
  2. × 書籍のサンプルアプリケーション作成と第5章執筆
    • 共著メンバーが進捗出してくれた
  3. ○ JS本執筆
    • サンプルアプリは完成
    • あとは日本語書く
  4. ○ 出社チャレンジもっと頑張る
    • だいぶ改善できてよい
  5. ○ Advent Calendar完走
    • Qiitaとブログ合わせて16記事
  6. × 合同勉強会 in 大都会岡山 楽しんでくる
    • 体調を崩してしまい残念

1月に向けて

  • Web連載第2回執筆
  • Django本第5章執筆
  • JS本執筆完了
  • 筋トレ再開
  • ラクロス再開
  • pyhack雪山合宿 楽しんでくる

「EXTREME TEAMS」を読んだ

すごい会社はチームが違う! 現代の最先端企業7社、ピクサー、ネットフリックス、エアビーアンドビー、ザッポス、パタゴニア、ホールフーズ、アリババのマネジメントやプラクティスを横断的に紹介。変化の激しい時代にも成長し続ける企業の条件を知ることができる1冊。

読んだ動機

  • いまSQUEEZEで開発文化の明文化や新しくチームビルディングを行っているので、チームや組織に関する知見が欲しかった
  • 昔読んだHow Google WorksTeam Geek小さなチーム、大きな仕事を読み返しつつ、新しい本を探していた
  • 本屋で立ち読みして良さそうだったので購入

勉強になったこと

価値基準のあり方

たとえば多くの企業が「誠実さ」や「チームワーク」を大事にすると掲げているが、それを言うなら誠実さとチームワークを大事に思わない企業やリーダーなど存在するだろうか。そんなふうに形ばかりの価値基準にしないためには、会社の具体的なミッションに沿った、他社とは違う独自性のある言葉にしなければならない。


グループの価値観が高尚すぎると、どう行動に落とし込んでいくかわからない場合がある。「こうすべき」もしくは「こうしてはいけない」などと、期待されている行動がはっきりわかる形で定まっていなければならないのだ。


採用、昇進、報酬制度と結びついていなかったりすれば、価値観はただ空回りするだけで、誰も実現のために努力をしない。本書に登場する先鋭的企業はこの点に留意し、価値基準の遵守を報酬と結びつけ、違反した場合の措置も決めている。価値基準に照らして社員のパフォーマンスに褒美または罰を与えるので、結果と引き換えに価値観を損なっていないかどうか注目する。

開発文化の明文化に取り組んでいるので、この話はとても参考になった。気持ちが乗ってない綺麗な言葉を並べてるだけだったり、決めたことに満足してそれを遵守・運用されてないといったことはよく見聞きすると思う。本書ではそれらをバッサリ否定しているので、読んでいて気持ちよかった。

Netflixの「自由と責任」の文化

社員に絶大な自由裁量権を与え、かわりに高い水準のパフォーマンスを維持させることが、ネットフリックスにとって何より重要なことなのだ。働き方の自由を支えるためなら努力を惜しまない。社員の休暇に関する規定を設けず、本人が必要と思うだけ休んでかまわないほどだ。

これはレベルの高い人材しかいないことが前提となっている。「会社は家族ではない」と断言して、成果を出せない人材には去ってもらうシステムが整えられている。本書で取り上げられている7社のうちで最も厳しい会社だと感じた。

SQUEEZEでもコアタイム制で比較的自由度が高い働き方をしているので、責任という部分について改めて意識させられた。

またNetflixがこのような文化になった背景として取り上げられている出来事についても興味深かった。

一連の解雇が済んだあと、ネットフリックスのリーダー陣は、会社を成長させる取り組みはできなくなるのではないかと恐れた。残った80人で既存事業を回すことに集中しなければならないからだ。ところが驚いたことに、人数を減らしてからのほうが仕事の速度が上がり、質も高くなった。

この経験から玉石混合の集団ではなく、優秀な人材だけで構成される「人材濃度」が高い組織を目指している。

アリババの「オープンな話し合い」

アリババにいるのは文明人ではない。ルールに沿っておしとやかに試合をする選手たちではない。望むことを何が何でも追いかける。極端で過激な人たちだ。会議が終わって出て来るときは、誰もが叫びすぎて顔が真っ赤になっている。それがこの会社での会議のやり方だ。声を張り上げて強烈にやりあう。

声を張り上げることを良しとする文化は新鮮だった。議論の時はいつもHRTとの兼ね合いだったり、強く言うと人格否定に聞こえないだろうかと心配になるけど、こういった議論の仕方が推奨されているとやりやすいかも。

衝突に伴う気まずさは必要で生産的なものであり、パフォーマンスを悪くするものは衝突ではなく緊張感のない現状維持であると書かれている。

おわりに

さしぶりに技術本ではない本を読んだけど、組織論はチーム開発においても勉強になることがとても多かった。この本で取り上げられていることを参考にして、SQUEEZEをもっともっと尖ったチームにしていきたいぞという気持ちです。

合同勉強会・忘年会議に参加できなかった

この記事は、大都会岡山 Advent Calendar 2017 24日目の記事になります。

adventar.org

合同勉強会・忘年会議ってなに?

gbdaitokai.connpass.com

bonenkaigi.connpass.com

結果

体調を崩して風邪を引いてしまい、参加を泣く泣くキャンセルしました。本当に申し訳なかったです。

これに合わせて@rhoboroが住んでる尾道にも遊びに行こうと思ってたのに残念。

3年連続で年末のこの時期に体調を崩してるので、来年はなんとか対策を講じたい。

そして2018年こそ大都会岡山に遊びにいくぞい。

『Webフロントエンド ハイパフォーマンス チューニング』を読んだ

Webフロントエンド ハイパフォーマンス チューニング

Webフロントエンド ハイパフォーマンス チューニング

本書では高速化という課題に対し、きちんと対処できる知識と実力を身に付けます。基礎となるブラウザのレンダリングから、個別の問題に対する対応例、今後を見据えた設計の基礎などその場しのぎではない本質的な高速化を学びます。

この書籍のなかでも指摘されているけど、自分は巷で話題のベストプラクティスとかを調べて満足しちゃうタイプなので体系的に学べる本書はとても勉強になった。特にチューニングの話に入る前に、ネットワークとブラウザのレンダリングの仕組みについて解説されているのがめちゃくちゃ良い。

後半のところで書かれているテクニック(特にCSS関連のもの)は、否定していた『小さな最適化』のように感じられたが、全体として基礎をきちんと抑えることができる内容だったと思う。

また少し前に話題になったdev.toの速さの解説記事を合わせて読むことで、理解が深まって楽しめた。

フロントエンドのパフォーマンスについての興味が高まってるから、次にこの2つを読んでいきたい。

超速!  Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる (WEB+DB PRESS plus)

超速! Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる (WEB+DB PRESS plus)

パフォーマンス向上のためのデザイン設計

パフォーマンス向上のためのデザイン設計

読書メモ

第2章 ブラウザのレンダリングの仕組み

第3章 チューニングの基礎

第4章 リソース読み込みのチューニング

  • HTML/CSS/JavaSriptを最小化する
  • 適切な画像形式を選択する
    • dev.to は Cloudinaly を利用
    • Cloudinalyは、ブラウザごとに最適な拡張子(webp/jpeg)の選択をしてくれる
  • CSSのimportを避ける
  • JavaScriptの同期的な読み込みを避ける
    • script要素によるJSの読み込みは、ドキュメントのパースをブロック
    • defer属性
      • DOMツリーが構築されてから実行
      • 実行順序は宣言の順に従う
    • async属性
      • 実行タイミングと実行順を保証しない
      • ファイルが取得された時点で実行される
  • バイスピクセル比ごとに読み込む画像を切り替える
    • srcset属性
    • <picture>要素やsizes属性とも合わせて
  • CSSのメディアクエリを適切に指定する
    • FOUC(Flash of Unstyled Content)を回避するために、最初のレンダリングを行う前にCSSファイルの読み込みを待つ
    • link要素のmedia属性を適切に指定することで、CSSの読み込みがレンダリングをブロックしないようになる
<link href="style.css" rel="stylesheet" media="screen"> 
<link href="print.css" rel="stylesheet" media="print">
<link href="other.css" rel="stylesheet" media="(min-width: 920px)"> 
  • CSSスプライトを使って複数の画像をまとめる
    • HTTP/2以降では意味なし
  • リソースを事前読み込みしておく
    • DNSプリフェッチ <link rel="dns=prefetch" href="http://example.com">
    • リソースのプリフェッチ <link rel="prefetch" href="./image.gif">
    • プリレンダリング <link rel="prerender" href="//example.com/prerender.html">
    • 接続の投機的開始 <link rel="preconnect" href="http://example.com">
  • Gzip圧縮を有効にする
  • CDNを用いてリソースを配信する
  • ドメインシャーディング
    • HTTP/2以降では意味なし
  • リダイレクトしない
    • URLの最後のスラッシュを付けるようにしておく
  • ブラウザのキャッシュを活用する
    • 強いキャッシュ(期限が切れるかキャッシュファイルが削除されるまで有効)
      • Expiresヘッダー
        • Expires: Mon, 02 Nov 2015 13:19:30 GMT
        • サーバーとクライアントの時間設定がずれてるとだめ
      • Cache-Controlヘッダー
        • Cache-Control:max-age=600
        • ExpiresとCache-Control両方が設定されていれば、Cache-Controlを優先
        • モダンなブラウザではCache-Controlに対応してるから、Cache-Control設定のみでOK
    • 弱いキャッシュ(条件付きGETリクエスト<=>304 Not Modified)
      • Last-Modifiedヘッダー
        • Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
        • If-Modified-Since: Wed, 15 Nov 1995 04:58:08 GMT
      • ETagヘッダー
        • ETag: "7797921b867ce392cad8415b729ffa97"
        • If-None-Match: "7797921b867ce392cad8415b729ffa97"
        • Last-ModifiedよりETagを優先
        • ETagは複数の結果をキャッシュできるのでより柔軟
        • 配信サーバーが複数の場合はETag値が異ならないように注意が必要
  • Service Workerの利用
  • HTTP/2の利用
    • バイナリ化したプロトコル
      • HTTP/1.1まではテキストベース
    • HTTP/1.1のセマンティクスの再利用
    • リクエストとレスポンスの多重化
      • 1つのTCP接続で複数のリクエストとレスポンスが並列で扱える
      • ブラウザの同時接続数の制限がなくなる
    • HTTPヘッダーの圧縮(HPACK)
      • 以前送信したものからの差分だけ送信できるように
    • TLSが事実上必須
  • QUICプロトコル
    • Googleが開発したネットワークプロトコル
    • TCPではなくUDP上に構築
    • 以前接続したことのあるサーバーとの通信であればゼロラウンドトリップ可能
    • 最初の接続もTCP+TLS相当のコネクション確立がラウンドトリップ1回で可能
    • Source Address Tokenをやりとりする
    • Head-of-Line Blockingがない(パケットは同時並行で送信される)
    • UDP上でありながら、TCP持つがパケットロス検出や誤り検出が可能
    • TLCが提供している盗聴・改ざん防止の機能も
    • Google Chromeのみ対応

第5章 JavaScript実行のチューニング

  • メモリリークを防ぐ
    • メモリ使用量が増えるとメモリスワッピングを引き起こす
      • メモリをハードディスクなどに退避させてメモリを解放する
    • console.log()によるメモリリーク
      • いつでもコンソールに表示できるようにするために特殊な参照が付いてGCの対象から外れる
    • WeakMapとWeakSet
  • Web Workersの利用
    • Web WorkersのスレッドとUIスレッド間の通信には、非同期でデータを通信しあうメッセージパッシングで行う
      • データは共有されずに、コピーしたものを送信する
      • Transferableインターフェースを持つオブジェクトは、所有権を扱える
        • データコピーする必要がなくなって、そのオーバーヘッドを回避できる
    • モバイル端末でも4コアな機種が多い
    • DOM要素・document/window/parentオブジェクトはWeb Workersからは使えない
  • asm.jsによるJavaScript高速化
    • Mozillaが設計したJavaScriptのサブセット
      • 計算はすべて静的型付け
      • 計算で利用できる方はintとdoubleとfloatの3つのみ
      • asm.jsモジュール内部では仮想的にGCが利用不可
    • EmscriptenC/C++のコードをasm.jsにトランスパイル
    • WebAssemblyに置き換えられる流れ
      • asm.jsはあくまでJavaScriptのサブセット
      • WebAssemblyブラウザ上で実行可能なバイナリフォーマット
  • SIMD.jsの利用
    • 複数の値の計算を一度に行うことができるSIMD(Single Instrauction Multiple Data)を扱えるAPI
    • WebAssemblyに置き換えられていくのが予想され、正式な仕様にはならない見通し
  • 高頻度で発火するイベントの抑制
  • モバイル端末でのclickイベントの遅延をなくす
    • touchendイベント後300ms待ってからclickイベントが発火
      • ダブルタップかどうかを判断するため
    • meta要素によるviewportを適切に設定すればOK
      • <meta name="viewport" content="width=device-width, user-scalable=no">
  • Passive Event Listenerでスクロールのパフォーマンスを改善する
    • イベントリスナがスクロールをブロックするScroll Jank問題
    • {passive: true}オプション
      • イベントリスナないでevent.preventDefault()が無効になることを保証
  • 無駄なForced Synchronous Layoutを減らす
    • DOM操作した後にレイアウト情報を参照するとレンダリングエンジンが最新の正しいレイアウト情報を返すために引き起こされる
      • DOM操作する前にレイアウト情報を参照しておく
      • requestAnimationFrame()を使用する
      • requestAnimationFrame()に渡したコールバックが呼び出されるタイミングは、DOM操作が終わり再レンダリングが終わってから

第6章 レイアウトツリー構築のチューニング

  • レイアウトツリー構築の流れ
    • CSSセレクタは右から左に向けて処理される
    • セレクタの記述を増やせば増やすほどマッチング処理に時間がかかる
    • レンダリングの際は、すべてのDOM要素のスタイルが再計算されるのではなく、新たに計算し直さないといけないところのみ
  • 高速なCSSセレクタの記述
  • BEMを用いる
    • Block・Element・Modifier
    • 基本的に1つのクラスセレクタのみを用いるのでパフォーマンスに優れる
  • レイアウトを減らす非表示
    • visibility: hiddenはペイント処理は行われないが、レイアウトツリーには含まれたまま
    • display: noneはレイアウトの対象からも外すことができる
  • img要素のサイズを固定する

第7章 レンダリング結果の描画のチューニング

  • 再描画
    • Composite Layersのみ引き起こされる場合
      • opacityプロパティの値が更新
      • transformプロパティの値が更新
  • translateZハック
    • 描画結果そのものは変えずにGPUによるレイヤー合成を行う
    • GPUへの転送時間やGPUのVRAMの容量などもあるので、必要なときだけ用いる
.target {
    transform: translateZ(0);
}

第8章 高度なチューニング

.foobar {
    contain: content;
}                   

第9章 認知的チューニング

  • インジケータを用いる
    • 1秒を超えるようであれば適用するのが望ましい
  • インターフェースプレビューを用いる
  • 処理が終わったように振る舞う
    • 楽観的UI(Optimistic UI)と呼ばれる
  • 無限スクロールを用いる
  • 投機的なリソースの先読み
    • Ajaxでデータを取得してアプリケーションレベルのキャッシュに保持する
      • IndexDBやLocalStorageなどのストレージor単なるJavaScriptの変数で保持
    • Resource Hintsを用いる

2017年買ってよかったもの

この記事は、今年買ってよかったもの Advent Calendar 2017 18日目の記事になります。

adventar.org

AirPods

使ってたイヤホンが壊れたのをきっかけに、「試してみるかー」っていう軽い気持ちで購入。

使ってみた感想は

メリット

  • ワイヤレス最&高
    • AirPods使ってみて初めて、コードがかなりストレスだったということに気づいた
    • 長時間つけてても、耳と首が疲れない
  • 届きにくいところを掃除できる
  • イヤホンを外したら音楽が自動停止になるの便利
    • 片耳だけ外した場合は、付け直したら自動再開されるのめっちゃ便利
  • 全然耳から落ちない安定感

デメリット

  • まあ高いっちゃ高い
    • 他のワイヤレスイヤホンに安くていいのがあるかも
  • 見た目がうどんでしかない
  • 音質は普通らしい
    • 音質にこだわりないから個人的には気にならない

ってところです。

おわりに

あなたも Let's 耳からうどん生活

日報を使った情報共有

はじめに

この記事は、コミュニケーション Advent Calendar 2017 10日目の記事です。

qiita.com

日報のいいところ

個人ではWikiHubの日報を普段使ってる。会社でも最近GitHubTeam discussionsを使っての日報共有がはじまった。

日報によって

  • 自分の作業ログ・思考ログが残せる
  • 他人の作業ログ・思考ログが見える

このことが、自分にとって心地いいし情報共有として役立ってる。

アンチパターン

  • 毎日の投稿が義務として「やらされている」
  • 「今日の学び」みたいに意識高い系なことを求められる

やらされてるんじゃなくて、書きたいときに書きたいことを書くっていうやり方が好きだし、長続きすると思う。

まとめ

SNSっぽくゆるい感じで日報書いていきましょう。