最近以下のような記事や本を読み読書法を変えてみたところ、知識の吸収速度・引き出し速度が上がったと感じるので紹介。 kentarokuribayashi.com 知的戦闘力を高める 独学の技法 作者:山口周ダイヤモンド社Amazon やり方 以下のような流れで読書している。 学びたいと思った知識が書いてありそうな本を2~5冊選ぶ 1冊ずつざっくり読みながら、面白かった部分・気になった部分はKindleで黄色にハイライトしておく 全冊読み終わったら、ハイライトした部分だけ眺めて、やっぱり面白いと思ったところは赤のハイライトを付け直す 赤のハイライトを眺めて、読書ノートに転記する 特に面白い部分については、自分の知見まとめノートにカテゴリごとに整理する 学びたいと思った知識が書いてありそうな本を2~5冊選ぶ 自分の中で学びたいテーマがあって本を読むはずなので、そのテーマについて書いてありそうな本

最近、開発チームの生産性や健全性をどのように計測したら良いかについて興味を持っている。その中で「LeanとDevOpsの科学」の中に書いてあるようなデプロイの頻度・変更のリードタイム・MTTR・変更失敗率の4指標や、開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiitaに興味を持った。 一方、それらの指標を考えてみた時、以下のような点について悩んでいた。 マイクロサービスなどで複数レポジトリとなり、さらにデプロイ手法がそれぞれ違う状況の場合、変更のリードタイム = コミット〜本番稼働までの時間を計測するのがなかなか難しい コミットという単位だとかなり小さく、個々人のばらつきも大きすぎるように感じるので、もう少し良い単位はないのだろうか このような悩みから、PullRequestの単位で集計することで、生産性や健全性をもう少し測りやす

これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの

最近のWeb開発わからん...って思って勉強してる。Reactは公式のチュートリアルやドキュメントがわかりやすく、そちらを進めると入門しやすかった。 チュートリアルやったレポジトリ https://github.com/shibayu36/react-tutorial/tree/84f44577d4bc29efe41ca0ef147092ca6d04233b 今のところ、写経した + eslintの設定してみたくらい。 メモ React – ユーザインターフェース構築のための JavaScript ライブラリ 基本的にpropsで不変な情報を、stateで可変な情報を扱う。コンポーネントをネスとしていき、アプリを作っていくイメージ。jsxで定義されるコンポーネントのフックを利用することで、いい感じに他のツール(例えばmarkdown変換)と連携できる。 Getting Started –

https://github.com/shibayu36/notify-issues-to-slack というツールを作ったので紹介です。 背景 はてな社内では各チームでレビュータイムという時間を設けていることが多い。その時間にチーム内のissueやPull Requestを全部見るという心がけをしている。レビュータイムについては昔に以下のような記事を書いた。 blog.shibayu36.org 一方レビュータイムを導入したとしても、レビュー依頼中のissueやPull Request一覧がSlackに流れてこないと、レビューやっていくぞという気持ちが高まらないことがある。そのためレビュータイムになったらレビュー依頼中のissueをSlackに流すツールを各チームでそれぞれ作っていた。 最近自分もまた同じようなツールを作ろうとしてしまった。しかし、みんな同じツールを作っているのは良くない

仕事で何かしら課題を見つけた時に、それを効率よく解決する方法にはどういうものが知りたかった。そこで参考になりそうな「世界一やさしい問題解決の授業」を読んだ。 世界一やさしい問題解決の授業―自分で考え、行動する力が身につく 作者:渡辺 健介ダイヤモンド社Amazon この本は非常に良かった。100ページ強と非常に少ないページ数ながら、その中に問題解決のためのエッセンスが詰め込まれていて勉強になった。分解の木や課題分析シートなど問題解決のためのツールもコラムに書かれていて、これらも参考になる。とにかくおすすめ。 「課題を見つけて解決策をとりあえず試してみたけど何かうまくいかなかった」というような経験をしたことがある人は読んでみると良いと思う。薄い本ですぐに読めるので、とりあえず誰でも読んでみると良さそう。 この本の中で自分が印象に残った次の二点をまとめておく。 問題解決とは「現状を正確に理解し

Elasticsearchが裏でどのように動いているか理解できるようにするために、「検索エンジン自作入門」を読んだ。 検索エンジン自作入門 ~手を動かしながら見渡す検索の舞台裏 作者:山田 浩之,末永 匡技術評論社Amazon この本を読んで、検索エンジンがやっていることを簡易的に知ることが出来た。少し理解するのは難しいが、具体的な例をコードレベルで見ることができる資料はなかなか無いので、非常に良い本であった。 2章以降からはコードを使って説明がされていくのだけど、そこからは理解が難しいかもしれない。しかし、それ以降を理解できなかったとしても、1章が端的に検索エンジンの仕組みについて書いてあるので、1章を読むだけでも価値があると思う。 自分の中では以下のものが参考になった。 検索エンジンは4つのコンポーネントからなる インデックス管理器 インデックス検索器 インデックス構築器 文書管理器

アルゴリズムの設計手法として、力ずく法・分割統治法・動的計画法というような考え方があった。新しいアルゴリズムを学ぶ時、どの設計手法でやっているのだろうかと意識しておくと、頭に入りやすい気がした。そこで、自分の頭を整理するためにメモを書いておく。自分用メモなので、情報の正確さについては保証がない。 力づく法 全探索する方法 アルゴリズムの考え方としては単純なことが多いが、かなり遅いものになることが多い 例えば、Nクイーンなら、N個の置き方を全通り作って、それぞれが条件をみたすか確認し、条件を満たしたら返すようなもの。Nの二乗のなかから、N個の組み合わせを作って試すので、計算が膨大になる 例えば文字列マッチなら、1文字ずつずらしながら、マッチさせたいパターンとテキストの文字を比較していくようなもの 分割統治法 Wikipediaによると、そのままでは解決できない大きな問題を小さな問題に分割し、

はてなインターンの事前課題で非常に簡単なltsvパーサーを作るやつがあるのだけど、Javaの勉強のためにJavaで実装してみた。ltsvパーサーは結構いろんな言語で誰かが実装しているので、これどうするのがいいのかってなったら、その実装を見に行くとやり方を理解できて便利。 事前課題 https://github.com/hatena/Hatena-Intern-Exercise2015 やったやつ https://github.com/shibayu36/java-Intern-Exercise これでいいのか気になるところもあるので、詳しい人に添削されたい。 日付操作こんなのでいいのか https://github.com/shibayu36/java-Intern-Exercise/blob/master/src/main/java/org/shibayu36/intern/exerci

今日はGoogle Tag Managerの設定をすることで、自分が好きなエリアのリンククリック計測を簡単にする方法について書く。 課題 クリック計測は自作で作るのは大変 Google Tag Managerで計測することもできるが、計測対象を増やすためにタグを毎回一つ増やすというのも大変 他の開発メンバーに教えるのもだるい Google Tag Managerを一回設定しておけば、あとはちょっと本サイトのHTMLをいじると計測を追加できるようにしたい やりたいこと Google Tag Managerを一回設定しておけば、あとはHTMLにちょっとした属性をいれるだけで、その要素内のリンククリックを計測したい。つまり、Google Tag Managerを一度設定しておくだけで、 <section data-gtm-link-click-action-name="RecommendedBo

昨日、「AMPが導入された結果、現時点ではモバイルのブラウズ体験が大きく損なわれてるのですが、そう感じるのは僕だけでしょうか」とTwitterでつぶやいたら、いろいろ反応があり、いろんな観点を知ることが出来たのでメモしておく。なお、自分自身はまだAMPのコンテンツを実装したわけではなので、開発者の知識はなく、ただのコンテンツ消費者としての知識しかない。開発している人から見るとまた違った見え方があるかもしれない。 コンテンツ消費者側のメリット・デメリットという観点 AMPによるコンテンツ消費者側のメリットは速度面だが、モバイルを利用していた時に現時点では速度に困っていなかったので、自分はメリットを享受できていない 現時点では、いろんな理由によりユーザ体験が損なわれている部分がある ユーザ体験が損なわれている例としては、プラットフォームの問題とコンテンツ制作側の問題の両方がある プラットフォー

最近コーチングという分野に興味を持って、まずは簡単でさくっと読めそうな「ザ・コーチ」という本を読んだ。 ザ・コーチ 最高の自分に気づく本 (小学館文庫プレジデントセレクト) 作者:貴彦, 谷口小学館Amazon この本は、副題も含めると「ザ・コーチ - 最高の自分に出会える『目標の達人ノート』」という題名で、その名のとおり目標設定をなぜ行うのか、どうやって行うのかについて知ることが出来る本だった。1分間シリーズのように小説形式となっていて、すぐに読むことが出来る。 現在、自分が目標って何のためにあるのかもう一度知りたいと思っていた時期だったので、非常に面白かった。読書メモがかなりの量になった。マネージャーをやっている人や、その方向に行きたいと思っている人、他にも教育を担当している人は是非おすすめ。 以下のことが印象に残ったので、それについて書こうと思う。 目的・目標・ゴールの定義と、目標設

【2016/09/10追記】 勉強しなおして、Elasticsearchの知識についてさらにまとめた記事を書いたので、そちらを参照してもらうと良さそうです。 blog.shibayu36.org 最近Elasticsearchの勉強をした。ただ、入門のためどのような資料が適しているかを知るのが大変だった。そこでどのように勉強したかについてメモをしておく。少しまとめエントリー的なノリになりそう。 Elasticsearchの概念を知る 全文検索技術の基本を知る Elasticsearchのドキュメントのたどり方を知る の順に学習を進めていった。 Elasticsearchの概念を知る Elasticsearchの学習を始めようとした時に、まずは基本からということで以下の本を読んでいた。 高速スケーラブル検索エンジン　ElasticSearch Server (アスキー書籍) 作者:Ｒａｆａｌ

最近、簡単な漫画(フィクションではなくコミックエッセイ)のアシスタントをやった。僕自身は絵は全く描けないので、やったこととしては単に肌の色塗り、単調な服の色塗り・トーン貼り、髪の色塗りなどを手伝った。 これまで漫画には読み手という立場でしか関わったことはなく、書き手として初めて関わり、新鮮な体験を得られたので、感じたことを書いてみる。 手間がかかる まず一番最初に感じたのが、とにかく手間がかかっているということ。僕がやったところは、本当に単調で一番時間がかからないところだったけれど、それでも100ページくらい担当すると大体丸二日くらい時間がかかった。やった作業としてはおそらく全体の2~3%くらいしかなく、これとは別にネーム、ペン入れとか、トーンや色で絵の技術が必要なところとか全部やろうとすると、どれだけ時間がかかるのだろうかと思った。週刊連載で毎週16ページくらい書かれているのは本当に大変

JSDOM環境を使っていると、いくつか実装されていないAPIがある。もしそのAPIを使っている実装のテストを書きたい場合、そのAPIと近い動きをする仮のオブジェクトに置き換える、つまりfakeする必要がある。 localStorageもJSDOMでは現在動かないAPIなので、localStorageを使った機能をテストするにはfakeする必要がある。普通のJSの環境だと、https://github.com/tmpvar/jsdom/issues/1137#issuecomment-173039751 に書いてあるようなオブジェクトを代入すれば良いのだけど、TypeScriptだと型定義どおりに実装しないとうまくいかないので、今回はTypeScript環境でfakeするのをやってみた。 一番単純にfakeする 方法としては同じインターフェースを持った別のものをwindow.localSto

これまで自分のブログで、TypeScriptを使ったフロントエンド開発環境についてブログをいくつか書いてきた。ひとまずこの辺りで、TypeScriptでフロントエンドを開発するための最低限の環境を構築できるようになったので、総まとめとしてブログエントリを書いておく。 今回のサンプルコードは https://github.com/shibayu36/typescript-project-sample/tree/4653cd002eef3ee1946a2ca1da344e0076b2844f に置いたので参考に。 これまでの記事 EmacsでTypeScript環境を整える - $shibayu36->blog; JSをbrowserifyでビルドし、ライセンスコメントを適切に残す - $shibayu36->blog; gulp + browserify + tsifyを利用してTypeSc

コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは # TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ... みたいなやつです。 コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。 最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。 TODOコメントの問題点 問題点として次のものがあると考えました。 (1) 書く人によって形式がバラバラ TODO, XXX, FIXMEなどバラバラだったりする (2) TODOコメントの