[読書感想文] Measure What Matters

Measure What Matters

日本語版はこっち
Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR

Who should read this?

OKRを会社で導入した、あるいは導入しようとしているが、いまいちこれでいいのかわからなくてしっくりこない感覚を持っている人。

Impression

OKRの使い方はとてもシンプルなものである。わくわくするような目標としてのObjectiveと、それをどうやったら実現できるのか見える化するための指標としてのKey Resultを作成するだけである。ただ、シンプルが故にどのようにでも応用できてしまうので、それを効果的に会社組織に適用するのはなかなかハードルが高い。MBOなどのそれまでの方式と根本的に何が違うのか、という感想は多くの人が抱いたことがあると思う。

「覚えるのは1分 極めるのは一生」はオセロのルールとしてのシンプルさと、ルールを使用したときの奥深さを表す表現として有名だが、OKRにも同様のことが言えるだろう。

本書の前半(Part 1)は、GoogleやIntelなどを始めとする企業がどのようにOKRを導入し、どのような効果を実感しているかが紹介されている事例集となっている。過去の棋譜を読むような気持ちで、先行研究をするのに最適である。

後半(Part 2)は、OKRと並列して導入されるべきツールであるCFRについて触れられている。CFRはCommunication(対話)とFeedbackとRecognition(承認)を意味する。ObjectiveとKey ResultをOKRで設定したあと、CFRによって十分な関係をメンバと築くことが推奨されている。

下記は本書で紹介されていた図である。シンプルでわかりやすく、また個人的にとても印象的だったので、ここに紹介する。OKRを評価・昇給と直接連動しないように切り離したものにしつつ、CFRによって対話・フィードバック・承認を行うことを意味しており、ただ単にOKRだけを導入することの不十分さがひと目で分かる。

[読書感想文]Accelarate

Accelarate

日本語版はこっち。
LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する

Who should read this?

少々おすすめ先に悩む本である。

DevOpsのプラクティスの効果について理論付けがなされているので、DevOpsを自社に導入したい人にはいいかもしれないと思ったが、今の時代においてそもそもDevOpsを導入していないステージの会社にはいろいろと前提がかけているために読みやすさかける本になっているだろう。

普段実践していることについて、主観的・感覚的には正しさを信じているのだが、それだけでは飽き足らず、客観的な裏付けがほしい、みたいな人が読んで嬉しい本になるのかもしれない。

Impression

DevOpsやLeanの手法に知見のある人には、少々退屈な本に映るかもしれない。いわば業界の常識となったプラクティスがデータに基づいて結論として書かれている。後半はServeyを行う際の理論や手法について書かれており、このあたりもDevOpsとLeanに興味があって本を手にとった人には期待はずれに思えるかもしれない。

普段当たり前と信じていたことが、 科学的な理論に基づいたServeyによって得られたデータによって裏付けられたことがわかるのが本書の利点だろうか。

[読書感想文]バイリンガル教育の本

2冊ほど呼んだ。同じような内容であり、同じような感想を持ったのでまとめて書く

読んだ本

子どもの未来を広げる「おやこえいご」 ~バイリンガルを育てる幼児英語メソッド~
おうちでほぼバイリンガルの育て方

まとめ

日本人夫婦が日本で子育てを行い、子供をバイリンガルに育てる実践が書かれている。

インターナショナルスクールなどには通わせず、最低限の英語教室と母親による家庭教育が中心の様子。

子どもの未来を広げる「おやこえいご」 ~バイリンガルを育てる幼児英語メソッドの単著者を含む、計４人が自身の子供をバイリンガルに育てた経験を綴った本。実践内容の細かい違いはあるが、大抵は母親の献身的な本、DVD、Youtubeを使った大量の英語のシャワーを行っているようである。

感想

やはり、尋常でない母親の献身ぶりが目を引く。大量の英語の本やYoutubeを駆使して、英語をインプットさせ、母親が自然な雰囲気で英語で話しかけることにより、英語力を身に着けさせているようだ。

英語の本やYoutubeを見せるあたりは安価であるので、親のモチベーション次第で真似はできそうである。他のバイリンガル本と同じく、育った子供がどの程度、英語と日本語が身についているのか、客観的に伺い知れる情報がないことだけが残念か。

[読書感想文]バイリンガルを育てる

バイリンガルを育てる

まとめ

英語教育やバイリンガル教育が専門の湯川笑子博士が自分自身の二人の子供にバイリンガル教育をさせたときの記録集。体験や観察をもとに論文も書いているようであり、詳細な記録は参考になる。

教育内容として大きく目をひかれるのは下記のような事柄

• 子供には常に英語で話しかける。
• 幼少期に英語の本の読み聞かせを毎日30分から2時間程度
• ネイティブなEnglish Speakerと多くの交流があり、自宅にホームステイさせたり等、子供をInternationalな環境においていた。
• 子供は幼少期に海外で教育させた。
• 長男。4ヶ月-1歳半と5歳5ヶ月-5歳10ヶ月までハワイ、6歳-8歳ころにスウェーデンの幼稚園、学校に通う
• 長女は4歳-5歳ころにスウェーデンの保育園に通う

感想

おうちでバイリンガルやおやこえいごなどを読んだときも同じ感想を抱いたが、やはり親（特に母親）の尋常でない献身ぶりが目を引く。毎日2時間も英語の本を読み聞かせるだけでも、尋常でない気力が必要だし、ましてや海外に引っ越して現地の教育を受けさせるなどというのは並々ならぬ覚悟がいるだろう。著者の場合は、自分の研究テーマと同一していることもあり、仕事のキャリアと英語教育のメリットを同一化させられたのも大きな要因であろう。

参考にはなるが、一般的な日本人にとってすぐさま真似できそうな実践はなさそうである。また、結局この本で行ったバイリンガル教育の結果、成人した子どもたちがどのような英語力・日本語力が身についたのかが不明なのも実践の効果を伺い知れる情報がなく残念ではある。

Programming Kubernetes: Developing Cloud-Native Applications

Programming Kubernetes

by Stefan Schimanski, Michael Hausenblas
Released July 2019
Publisher(s): O'Reilly Media, Inc.
ISBN: 9781492047094
Explore a preview version of Programming Kubernetes right now.

O’Reilly members get unlimited access to live online training experiences, plus books, videos, and digital content from 200+ publishers.What the book is for?
The books describes about how to customize kubernetes engine itself. It doesn't describe about how to make an application on kubernetes. Thus it helps to understand how kubernetes controllers and components works.

Programming Kubernetes

Who should read the book?

Anyone who would like to understand controllers and components running under the hood.

Anyone who would like to the architecture of kubernetes.

Anyone who would like to make custom controllers. 

Anyone who aspires to be a kubernetes contributer.
Anyone who would like to know about client-go library. 

Impression

The book is for advanced level kubernetes developers. Before reading the book, it is recommended to have understanding on what kubernetes controllers, API servers and Operators are and how they behave. Some experience of kubernetes application development might be good to understand the book deeply.

Designing Distributed Systems

Designing Distributed Systems

Patterns and Paradigms for Scalable, Reliable Services
By Brendan Burns
Publisher: O'Reilly Media
Release Date: February 2018
Pages: 166

Without established design patterns to guide them, developers have had to build distributed systems from scratch, and most of these systems are very unique indeed. Today, the increasing use of containers has paved the way for core distributed system patterns and reusable containerized components. This practical guide presents a collection of repeatable, generic patterns to help make the development of reliable distributed systems far more approachable and efficient.What the book is for?
The book describes about example of architecture which is assumed to be built on kubernetes. Yaml files for kuberenetes are also included with explanation as well as the codes.

Designing Distributed Systems

Free book from Microsoft is also available.

Who should read the book?

Anyone who would like to know design and architecture patterns for kubernetes.

Impression

It's good as a recipe book. Some basic and easy to apply architecture patterns are described with use cases. It should be one to be recommended to every kubernetes application developers.

SCRUM BOOT CAMP THE BOOKを読んでみた

SCRUM BOOT CAMP THE BOOK

スクラムについて一通り学べる。基礎編と実践編の二部構成になっている。
基礎編で用語や概念が説明され、実践編ではそれをどのように適用していけばよいかが説明されている。

座学で得られる限りの情報はこの本で学べるのではなかろうか。

特に実践編ではスクラムを現場にどのように導入していく様子が漫画のストーリで描かれており、イメージが付きやすい。

スクラム導入のための本としては良本。

「エンジニアのためのマネジメントキャリアパス」を読んで管理職について考えてみた

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

を読んでみた。

入社されたばかりの被管理者であるSoftware Engineerから始まり、チームを束ねるTech Lead(TL)、管理職や管理職の管理職、そしてVP of Engineering(VPoE)やCTOなどの役職について、期待される役割や課題などを説明している。ざっくりと昨今のTech界隈の役職を俯瞰するのには最適の一冊であろう。

よくまとまってて読みやすい書籍ではある。ただ、ちょっと身も蓋もない言い方になるのだが、会社の役職なんて同じ名前でも役割が違うので、これを読んでどう活用するかは若干難しい。原著は米国の書籍であるので、当然のこととして、日米の文化的・法律的な差異もあるはずである。技術書のように、これを教科書として絶対視しても意味がないので、著者の界隈ではこういう共通認識で回ってるのだろう、といった参考程度に勉強するのが好ましいのであろう。


一点だけ大きく興味をそそられた箇所があった。
5.1節の「ITスキルの維持」の記述のところである。

管理職に転向した後の技術的知識のアップデートに関する主張であり、これ以上コードを書いても技術力が頭打ちになるラインまでは管理職になってもコードを書き続けよう、ということであった。技術力がしっかりと身につくまでは、管理職としても大成できない。そして上級の管理職になってからも何らかの技術的コミットメントを続けるべきだ、と。この意見はとても正しく思える。

私もソフトウェアエンジニアとしてのキャリアの中で、エンジニアから管理職に転向した方を多く知っている。ほとんどの方は、Mangerに転向したのを機にコーディングを行わなくなる。その結果、例えば20世紀にWindowsアプリの開発を行っていた人が、Windowsアプリのパラダイムのままネットの技術を語ったり、クラウド以前のInternet上でWebアプリを開発していた人が、その価値観のまま、クラウドの技術を捉える、といった状況に多く遭遇した。表面的な知識は間違ってないのだが、「それは根本的に考え方が違うんだよなあ」、と突っ込みたくなる状況である。

もちろん、管理職という立場で時間の許す限りキャッチアップは続けているのだろうが、Webの前後、あるいはクラウドの前後、そしてマイクロサービスの前後といったような大きなパラダイムの変換があるときには、業務を前提に深くコードを書いていない限り自分の中の技術的パラダイムはアップデートできない。プライベートな時間で自分しか見ないレベルのコードを書いたとしても、当然のこととして仕事で向き合うのと理解の度合いは違う。業務外でコミットしているオープンソースがあったり、副業としてエンジニアを続けているのでない限り、どの立場になってもコードを書き続けない限りいずれその人の技術的価値観は時代遅れのものになるのだろう。


ただ、言うのは簡単だが、マネージャ業務をしながら開発業務にもコミットし続けるのはとても厳しい。解決策としては、マネージャとエンジニアを数年おきに、すっぱりとJob Changeするくらいしかないかもしれない。米国ではよく(たまに？)あるとは聞くが、少なくとも日本ではあまり聞いたことがない。もしかしたら今後はこのようなJob Rotationが必要とされるかもしれない。

Golangのfake google searchフレームワークをjavaで書いてみた。その2

その1を投稿したあと、某友人から「CompletableFuture使ったらもっとスッキリできるよ」って情報もらった。なので、それ使って書き換えてみた。

import java.util.ArrayList;
import java.util.List;
import java.util.Random;
import java.util.concurrent.*;
import java.util.function.Supplier;

class FakeSearch implements Supplier<String>{
    String name = null;
    public FakeSearch(String name){
        this.name = name;
    }
    @Override    public String get() {
        try {
            Thread.sleep((new Random().nextInt(10) * 1000));
        }catch (Exception e){

        }
        return name;
    }
}

public class CmpGoChannel2 {
    public static void First(Supplier<String> supplier1,Supplier<String> supplier2) throws Exception{
        CompletableFuture<String> future1 =
                CompletableFuture.supplyAsync(supplier1);
        CompletableFuture<String> future2 =
                CompletableFuture.supplyAsync(supplier2);

        CompletableFuture<Object> future3 = CompletableFuture.anyOf(future1, future2);
        System.out.println(future3.get());
    }

    public static void main(String... args) throws Exception{
        FakeSearch web1 = new FakeSearch("Web1");
        FakeSearch web2 = new FakeSearch("Web2");
        FakeSearch image1 = new FakeSearch("Image1");
        FakeSearch image2 = new FakeSearch("Image2");
        FakeSearch video1 = new FakeSearch("Video1");
        FakeSearch video2 = new FakeSearch("Video2");


        CmpGoChannel2 c = new CmpGoChannel2();
        List<Future<String>> list = new ArrayList<>();

        First(web1,web2);
        First(image1,image2);
        First(video1,video2);

    }

}

while(true)と終了フラグで乗り切ってた汚い部分がだいぶきれいになった。

public static void First(Supplier<String> supplier1,Supplier<String> supplier2) throws Exception{
    CompletableFuture<String> future1 =
            CompletableFuture.supplyAsync(supplier1);
    CompletableFuture<String> future2 =
            CompletableFuture.supplyAsync(supplier2);
    CompletableFuture<Object> future3 = CompletableFuture.anyOf(future1, future2);
    System.out.println(future3.get());
}

行数もざっくり60行程度まで収まった。

Golangのfake google searchフレームワークをjavaで書いてみた。その1

Go concurrency patternsで触れられていたGoogle SearchのFake frameworkのコードが非常にすっきり記載されていて感動したので、これをJavaで書いたらどうなるんだろうと好奇心から書いてみた。

まず、Go言語の方のやつを、書き出してみる。

package main

import (
   "time"   "math/rand"   "fmt")

var (
   Web1 = fakeSearch("web1")
   Image1 = fakeSearch("image1")
   Video1 = fakeSearch("video1")

   Web2 = fakeSearch("web2")
   Image2 = fakeSearch("image2")
   Video2 = fakeSearch("video2")
)

type Result string

type Search func(query string) Result

func fakeSearch(kind string) Search {
   return func(query string) Result {
      time.Sleep(time.Duration(rand.Intn(100)) * time.Millisecond)
      return Result(fmt.Sprintf("%s result for %q\n", kind, query))
   }
}

func First(query string, replicas ...Search) Result {
   c := make(chan Result)
   searchReplica := func(i int) { c <- replicas[i](query) }
   for i := range replicas {
      go searchReplica(i)
   }
   return <-c
}

func Google(query string) (results []Result) {
   c := make(chan Result)
   go func() { c <- First(query, Web1, Web2) } ()
   go func() { c <- First(query, Image1, Image2) } ()
   go func() { c <- First(query, Video1, Video2) } ()
   timeout := time.After(80 * time.Millisecond)
   for i := 0; i < 3; i++ {
      select {
      case result := <-c:
         results = append(results, result)
      case <-timeout:
         fmt.Println("timed out")
         return      }
   }
   return}

func main() {
   rand.Seed(time.Now().UnixNano())
   start := time.Now()
   result := First("golang",
      fakeSearch("replica 1"),
      fakeSearch("replica 2"))
   elapsed := time.Since(start)
   fmt.Println(result)
   fmt.Println(elapsed)
}

コードの解説はスライドに譲るとして、First関数の中での、return <-c の使い方が素晴らしい。

で、これをJavaで書いてみた。

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.*;

class Web1 implements Callable<String>{

    public String call() {
        try {
            Thread.sleep(10*1000);
        }catch (Exception e){

        }

        return "Web1";
    }
}


class Web2 implements Callable<String>{

    public String call() {

        return "Web2";
    }
}

class Image1 implements Callable<String>{

    public String call() {
        try {
            Thread.sleep(10*1000);
        }catch (Exception e){

        }

        return "Image1";
    }
}


class Image2 implements Callable<String>{

    public String call() {

        return "Image2";
    }
}

class Video1 implements Callable<String>{

    public String call() {
        try {
            Thread.sleep(10*1000);
        }catch (Exception e){

        }

        return "Video1";
    }
}


class Video2 implements Callable<String>{

    public String call() {

        return "Video2";
    }
}

public class CmpGoChannel {

    public static void First(ExecutorService executor1,Callable<String> callable1, Callable<String> callable2) throws Exception{
        List<Future<String>> list = new ArrayList<>();

        list.add(executor1.submit(callable1));
        list.add(executor1.submit(callable2));

        boolean loopDone = false;
        while(true) {
            for (Future<String> f : list) {
                System.out.print(".");
                if (f.isDone()) {
                    System.out.println(f.get());
                    loopDone = true;
                    break;
                }
            }
            if(loopDone){
                break;
            }
        }
    }

    public static void main(String... args) throws Exception{
        ExecutorService executor1 = Executors.newFixedThreadPool(2);
        ExecutorService executor2 = Executors.newFixedThreadPool(2);
        ExecutorService executor3 = Executors.newFixedThreadPool(2);

        CmpGoChannel c = new CmpGoChannel();
        List<Future<String>> list = new ArrayList<>();

        Callable<String> web1 = new Web1();
        Callable<String> web2 = new Web2();

        First(executor1,web1,web2);

        Callable<String> image1 = new Image1();
        Callable<String> image2 = new Image2();

        First(executor2,image1,image2);

        Callable<String> video1 = new Video1();
        Callable<String> video2 = new Video2();

        First(executor3,video1,video2);


        executor1.shutdown();
        executor2.shutdown();
        executor3.shutdown();
    }
}

まず気づいたのが、Javaにchannelに相当する仕組みがなかったこと。JavaのConcurrencyはそんなに人気のあるものではなかったが、そうは言ってもそれなりに使われている実績はあるので、書こうとしてみて「そういや、なかったな」みたいな気付きがあった。

なので、ここは

while(true) {
    for (Future<String> f : list) {
        System.out.print(".");
        if (f.isDone()) {
            System.out.println(f.get());
            loopDone = true;
            break;
        }
    }
    if(loopDone){
        break;
    }
}

といった感じで while(true)と終了フラグで乗り切るというちょっと汚いコードで対応した。
このあたりですでに、簡素なコードを書けるというGoの魅了が十分に表れている。

GraphQLを触ってみた

The better Restとの触れ込みのあるGraphQLを触ってみた。

GraphQLとは何か?

ここ数年、Webではスタンダードとして使われていたRest APIに対する不満から生まれたバックエンドとフロントエンド間の通信規約である。具体的には主に下記のようなものを課題として捉えている。

課題1 endpointから返されるデータを全部使わない(Over-fetching)

たとえばユーザのプロフィール画面を作りたくて、/user/profiesのエンドポイントを叩いたとする。大体の場合は、これのレスポンスに含まれるすべてのデータは必要とせずに、一部のデータのみ使うであろう。使われないデータは無駄であり、結果として効率的でない通信のやり取りに繋がる。

課題2 endpointをいくつも叩かなければいけない(Under-fetching)

Over-fetchingと表裏一体ではあるのだが、一つの画面に必要となるデータをやり取りするにも、 user/<id>を叩き、次にuser/<id>/profiles、そして最後にuser/<id>/photosの３つのendpointを叩く必要になることがある。これは一つのendpointから返されるレスポインスでは足りないがために起き、そのため複数のendpointへの通信が過剰に走ることになる。パフォーマンスの観点からは基本的にフロントエンドとバックエンド間の通信は少なければ少ないほど好ましい。

課題3 endpoint作成のコストが高い

endpointを一個作るにはフロントエンド・バックエンド側双方の調整が必要となるため、作成のコストが高い。

実際に作ってみた

GraphQLを推進する会社にApollo社がある。Apollo社が提供するApollo Serverを使うと比較的かんたんにGraphQLを試すことができる。

Getting started

出だしに書いてあったとおり、本当に10分で雰囲気がつかめる。もしかしたら10分もいらないかも。

感想

npmで初期化するだけで、playgroundがついてくるのは便利。ただ、ドキュメントが不親切で断片的なコードしか書いてないため、ちょっとした改良をするにも試行錯誤が必要。急がばまわれ的に、まずはapollo serverを使わない素のgraphql.jsなどを触って基礎を先に身につけたほうが良さそう。

Go言語の学習に使った本・サイト

A Tour of Go
定番どころのサイト。一通りのSyntax等は学べるか、サラッと書かれてるので基本を知る以外には情報が足りない感じがある。ブラウザ上でGoの実行環境があるので、スキマ時間に理解を進めるのには役立ちそう

スターティングGo言語 (CodeZine BOOKS)   松尾 愛賀 
入門書として良書。C、Java、Pythonなどの経験がある人に向けたGoの入門書。文法を網羅的に説明しつつ、落とし穴となりそうなところをちゃんと解説している。注意点としては全くのプログラミング初心者を対象としてないところ。プログラミング未経験者がいきなり本書を読んでも理解ができる前提で書かれた本ではない。

Go言語によるWebアプリケーション開発
タイトルのまんまGo言語でWebアプリケーション開発をするために必要な知識についてまとめてある本。(読み終わったらまた書く)

Go in Action
Manning者のIn Actionシリーズ。個人的にIn Actionシリーズの大ファンなので、購入したが、これは若干いまいち。In Actionシリーズは、実際的なサンプルを作りながら、その技術セットに付いて学べるのが特徴であるが、本書に関してはGoの理解を進めるのにあまり向いている作りではなかった

メルカリの俺的活用方法

フリマアプリのメルカリ。いろんな使い方があると思うけど、俺が気に入ってる代表的な使い方を紹介してみる。


1. コミック全巻セットを買って、読んで、そしてまた売る。

コミックは場所的に嵩張るので、よっぽど気に入った本以外は家にキープしておく場所がない。解決策としてはTSUTAYAとかで宅配レンタルするとか、漫画喫茶で読むとかあるんだけど、それぞれ微妙な点がある。

• 宅配レンタル

TSUTAYAの場合、送料まで含めると一冊あたり150円くらいするので、結構コスパが悪い。またうっかり返却日をすぎると、容赦なく延滞料金が取られる

• 満喫

フリータイムとか利用すれば、かなりコスパは、個人的にはフリータイム3時間とか6時間とかで集中して漫画を読むのとか楽しめない。一冊読んだあと、ネット見て、またその後、次の巻を読んだり、あいた時間に一冊だけ読んだりと、ダラダラ読むのが好きなので、正直言って満喫に何時間も缶詰するとか若干苦行感ある。家でのんびりと読みたい。

ということで、メルカリとかで漫画全巻セットを買って、自分のペースで読み終わったあとに、またその漫画を売りに出すのが、おすすめとなる。大体の場合、買ったときとほぼ同じくらいの値段で売れるので、手数料+送料がランニングコストとなる。30冊くらいの漫画セットであれば、両方合わせてもせいぜい800-1200円程度である。

2. ゲームを買って、遊んで、また売る
コミックと一緒だけど、ゲームなんかも大体の場合は一度遊ぶと二度とやらないので、遊んだあとサクッと処分できると嬉しい。新作は値段の下落が早いけど、発売後数ヶ月から年単位で時間がたった古いゲームなんかは、コミック全巻セットと同様に大きく値段が下がらないので、だいたい買ったときの値段で売れることになる。ゲームは漫画に比べて小さく、当然送料も安く済むので、ランニングコスト的には更に安く上がる。手数料+送料で400-600円程度で済む。

というふうに、上げてみると、ほとんどシェアリングサービス的な使い方になった。もちろん、店で新品で買ったものをただ売ったり、逆に欲しいものをメルカリで中古で買ったりもしているが、とりわけ個人的には漫画とゲームの使い方が気に入ってる。

日経新聞をKindleで読むまでにしたこと

Kindleのフォーマット(mobi)への変換

日経新聞の電子版を長らくPCで読んでたのだが、目を酷使する時間を少しでも減らそうと思いKindleで読める方法がないか探ってみた。

調べたところ、Calibreというその筋では有名なソフトウェアが存在するようなので、試してみた。

何度か試したのだが、どうやら最近の日経新聞電子版ではエラーが発生するようで、Kindle化するまでに至らなかった。

幸い、Calibreは開発をオープンソースベースで行っているようでgithubにソースが管理されていた。その為、必要な修正をpushし、本家に取り込んでもらうことができた。

Ver 3.15以上であれば日経新聞を無事読み込むことができるので、エラーに悩まされていた人はぜひとも試してほしい

リファレンス
オープンソースの電子書籍管理ソフト「Calibre」を使いこなそう！

Amazon Web Serviceで自動配信

Calibre本体にタイマー機能がついているので、PCを起動しっぱなしにしておけば、毎日設定した時間に日経新聞を取得し、Kindleまで配信することが可能であるが、現在私はラップトップPCしか使っていないため、毎朝手動で朝刊を取得し、Kindleまでメールで送信する必要があった。毎日のこととなるとこの単純作業も地味に辛い。

はじめはフリー枠を恒久的に用意しているHerokuなどを使いたかったのだが、Calibreの場合は本体をインストールするという作業が必要になるため、Herokuでは技術的にこれを実現できなかった。

AWSならば基本的にはLinuxをそのまま利用できるのでこちらを利用することとした。

まずは一年間のトライアル枠で利用するので料金はかからない。厳密に料金の見積もりを取ってないが、Amazon CouldWatchというこれまたAmazonのサービスを使って朝刊と夕刊の時間を取得する時間だけインスタンスを立ち上げることができたので、トライアル期間を過ぎてもおそらくそれほど多大な料金はかからないだろう。

分かる人にしかわからないレベルの粒度で、AWSの自動配信のためにやったことを書いておく。

1. EC2インスタンスを用意する。Amazon Linux AMIを利用した

2. Amazon Lambdaを利用して、EC2インスタンスを起動するFunction、停止するFunctionを用意する

起動のためのFunction(python2.7)

import boto3
# Enter the region your instances are in. Include only the region without specifying Availability Zone; e.g.; 'us-east-1'
region = 'XX-XXXXX-X'
# Enter your instances here: ex. ['X-XXXXXXXX', 'X-XXXXXXXX']
instances = ['X-XXXXXXXX']

def lambda_handler(event, context):
    ec2 = boto3.client('ec2', region_name=region)
    ec2.start_instances(InstanceIds=instances)
    print 'started your instances: ' + str(instances)

停止のためのFunction

import boto3
# Enter the region your instances are in. Include only the region without specifying Availability Zone; e.g., 'us-east-1'
region = 'XX-XXXXX-X'
# Enter your instances here: ex. ['X-XXXXXXXX', 'X-XXXXXXXX']
instances = ['X-XXXXXXXX']

def lambda_handler(event, context):
    ec2 = boto3.client('ec2', region_name=region)
    ec2.stop_instances(InstanceIds=instances)
    print 'stopped your instances: ' + str(instances)

3. Amazon CloudWatchを利用して、2で作成したそれぞれのFunctionを実行するEventを作成する。

例えば朝刊は午前のJSTのAM2:30に配信されるので、起動をAM2:30、停止をAM3:20にした。

4. 1で用意したEC2にCalibreをインストールする

%>yum update 
%>sudo yum install libGL
%>sudo -v && wget -nv -O- https://download.calibre-ebook.com/linux-installer.py | sudo python -c "import sys; main=lambda:sys.stderr.write('Download failed\n'); exec(sys.stdin.read()); main()"

私の場合はcalibreのインストール前に、libGLを手動でインストールする必要があった。

5. 日経新聞をmobi化するためのコマンド、およびそれを自分のKindleに配信するためのコマンドをスクリプト化する。

%>/opt/calibre/ebook-convert '日本経済新聞（朝刊・夕刊）.recipe' /tmp/nikkei.mobi --username=<日経のIDとなるメールアドレス> --password=<そのパスワード>

%>/opt/calibre/calibre-smtp -r mail.gmx.com --username <送信用のメールアドレス> --password <パスワード> --port 587 -a /tmp/nikkei.mobi <送信用のメールアドレス> <Kindleのドキュメント受付用のメールアドレス> subject

6. 5のスクリプトをcronで実行するよう設定する

35 17 * * * /home/ec2-user/calibre.sh

リファレンス

How do I stop and start Amazon EC2 instances at regular intervals using AWS Lambda?

2016年に読んで・観て何かしら記憶に残っているものリスト（フィクション編）

観たフィクションで面白かったものまとめ。もっと色々観たはずだけどあまり覚えてないな。Amazon Primeで無料のやつとか履歴が残ってないので、何を観たのか思い出すのが大変。

The Game of Thrones

全米で大ヒットのドラマ。評判に違わず死ぬほど面白かった。現行の最新であるシーズン6まで一気に観てしまった。原作も読み始めた。ドラマの方も時間を作ってもう一度シーズン1からじっくりとみたい。

Silicon Valley

これも一部では大ヒットのドラマ。なかなかコミカルで楽しい。

Extant

ヒューマノイドロボットの話。本筋とは関係ないけど、アメリカンカルチャーに基づく夫婦の関係が描かれてて興味深かった。ああやってパワフルな女性を支える男性像が昨今の理想的な夫像なのだろうか。

Orphan Black

Amazon Primeで無料だったシーズン3まで観た。面白かったので4もフリーになったら見よう。

The Martian

邦題は「オデッセイ」。火星ミッションの話。月がありきたりになったのでそろそろ火星が映画のネタになる頃か。前半のMatt Damonが淡々と危機を切り盛りして行くところは楽しかったが、後半はすごいグダグダ。

ダンジョン飯 1巻<ダンジョン飯>

タイトル通りダンジョンで飯を食う話。まあなんか面白い。

PEACE MAKER 1

期間限定で5巻まで無料だったので読んでみた。非常に面白かったので、全部買っても良かったが、冊数が多いので結構金が掛かりそう。ここまで金かけるならKindleじゃなくて紙本で買いたい。

殺し屋１

これもKindleで一冊11円とかで売ってたので全部買ってみた。グロい描写が多い。読後感は良くない。でもなんか読むのをやめられなかった。

累

演劇のストーリのところが趣向が凝らされてる感じがしていい。いつか時間があったらこういう古典を読んでみても面白そう。漫画としても読み応えはある。

TED/TED2

シニカルな熊のTEDが観てて面白い。このくらい英語で口が回るようになりたい

Harry Potter and the Sorcerer's Stone

ハリポタシリーズ。実は観たことなかった。全部通してみたけど、思ってたより面白い。イギリス英語満載なので、英語の練習にもいいかも。原作も読んでみようと思ったけど、ストーリはやはり子供向けなので、途中で飽きそうだな。

2016年に読んで何かしら記憶に残ってる本リスト（技術書編）

2016年に読んでよかった技術書をリストしておく。
そもそも技術書はそんなにいっぱい読めないので、母集団は多くない。
積ん読もいっぱいあるので、なんとか消化しなくては。

Reinforcement Learning

教科学習の教祖Suttonによる教科学習の本。刊行が1998年と古いので、それだけが残念だが、例題がいっぱい載っているお陰で理解がし易い。説明もまあ、この手の本にしてはわかりやすい部類だろう。何よりも、章立ての構成が美しい。当然だが、頭が相当いい人なんだろう。この本一冊だけで基礎が手にはいる。第二版を執筆中とのことなので一日も早い出版が望まれる。

これからの強化学習

SuttonのReinforcement Learning本が古いので、そこと最新の間を補うための本。かの本とセットで読むのがいいと思う。

入門 機械学習による異常検知―Rによる実践ガイド

説明がやばいくらい分かりやすかった。すべての技術書はこのレベルのわかりやすさを心がけてほしい。

2016年に読んで何かしら記憶に残ってる本リスト（ノンフィクション編）

フィクション・ノンフィクション問わず今年はあまり本を読まなかった。本を読むという行為に少し食傷気味だったのかもしれない。米国に居を移したので意識的に日本語の情報量を減らした影響もあるかもしれない。（代わりに英語の量を増やしているが、残念ながら吸収率が違う）

その中から、少しでも何かしら心に残っている本をリストアップしておく。なお、読んだ直後のコメントではなく、年末まで自分の中で消化した後でコメントしているので、記憶違いや本書からの飛躍があるかもしれない。まあ気にしない。誰かへのおすすめではなくあくまでも自分メモである。

イギリス　繁栄のあとさき (講談社学術文庫) 

没落していく日本のロールモデルとしてのイギリスを書いた本。イギリスなんて100年以上も没落し続けてるのに、まだ大国なんだから日本も当分は大丈夫だよ、みたいなことを言ってた気がする。こういう観点の考え方もあるのかな、という意味で面白かった

ＶＲビジネスの衝撃　「仮想世界」が巨大マネーを生む (ＮＨＫ出版新書)

VRの情報が満載だった。Informativeでいい本。

2020年マンション大崩壊 (文春新書) 

マンション購入の一番のデメリットはそれが他の住民との運命共同体であることだ。共同体の一員と足るような意識の高い住民と住めればいいが、管理費すら払わないような人たちと同じマンションに住んでしまった場合、個人として打てる手はもう何もない。

読んで到達した結論。当分はマンション買わない。一軒家は予算的に変えないから、つまり当分は借家暮らし。どうせ日本の人口は減る一方なので、全体的には不動産価格は低迷していくだろう。人気駅の駅チカ物件とかは相変わらず高値をキープするだろうが、うまく選べばいい物件を広い放題な時代が来る（と予想している）

諦める力～勝てないのは努力が足りないからじゃない

アスリートの世界はNO1以外は価値がないので、そうなれないと判断したときに諦めるのが非常に重要である。サラリーマンならばNO2だろうが、NO100だろうが、給与水準が落ちるだけで、その道を諦めることの重要度は相対的に低いが、彼らはそうではない。

素人でも容易に想像ができるように、諦めるといってもそんなに簡単じゃない。事故などで客観的にも納得できるような不可能性を突きつけられれば別であるが、もう少し努力を増やせばまだまだ行けるかも、と思っている状態で諦めるのは、それができるだけで一流と呼べちゃうんじゃないかくらいの超人的なメンタリティを要する。

2017年を論じた本まとめ

2016年末ということで、2017年を論じてる本を何冊か読んでみた。

はじめの3つは経済・政治に着眼点をおいて書いた本で、最後のは技術トレンドだけに絞った本。

ちょっと毛色が違う最後の本だけ除いて、はじめの３つだけ横断的にコメントしてみると、IT技術としてはAI、IOT、VR・AR・MRが来て、世界情勢的には選挙を控えたヨーロッパでポピュリズムの波が来るぞ、という聞き飽きた話をカバーしながらそれぞれちょっとずつ独自色を出している様子。

２０１７年　日本はこうなる

話題は多岐に渡っているが一つ一つの掘り下げが甘い。
表面的な説明と根拠のない展望が記載されているだけという印象が拭えない。
例えば、ロボット開発の項目では、政府が「ロボット新戦略」を打ち出していること、それを受けて自治体が動き出していること、そして公と民が連携する必要があることしか記述されていなく、肩透かしを食らった印象がある。

VRの項目では、最後に「本稿では紹介しきれないほど、VRは進化を遂げている」と述べられているので、そもそもあまり深く伝えようとする意図が本書にはないのかもしれない。

日頃から新聞やネットニュースに目を通している方であれば、あえて本書を読んで得るものはないだろう。

おすすめ度★☆☆☆☆

経済がわかる　論点５０　２０１７

三菱UFJリサーチ＆コンサルティングの「２０１７年　日本はこうなる」はトレンドをカバーすることを意識しすぎて表面的になっていたのに対し、本書は「論点」に着眼したために、昨今の変化を見据えて本質的に考えなければいけないこと、これから情報をフォローしていかなければいけないことを得るのに最適であった。それぞれ、きちんと資料と出処が引用されていて、論理に信頼感がある。

2017年末にも、本書の翌年度版をぜひ読みたい

おすすめ度★★★★★

日本の論点2017～18 

大前研一が論点と考えることについて、更に彼独自の観点から見解が述べられていて非常に読み応えがあった。

類書と類似のテーマは多いが、イタリアから日本が学べることや、台湾と中国の関係、ミャンマーの政治事情などそもそも情報源としても他ではあまり聞いたことがない話が多く、彼の情報網の厚さに唸らされる。

類書では「経済がわかる　論点５０　２０１７」などもあるが、こちらでは執筆者一覧としてズラリ数十人の名前が記載されているが、それに匹敵する書籍を一人で書き上げられる実力は流石といったところだ。

日本の論点とあるが、後半ではドイツ・イタリア・中国・台湾・ミャンマーなど国外の論点についても論じられている。

実質「世界の論点」について語られているので、タイトルは無駄に小さくしてしまった印象。

Githubでフォーク元の修正を取り込む手順メモ

1. フォーク元を追加

git remote add upstream git://github.com/<username>/<reponame>.git

2. 修正をフォーク先に取り込む

git fetch upstream

git merge upstream/master

3. 修正をfortした自分のレポジトリに反映

git push

これ、githubのweb上でできてほしいんだけどな。
なんでremoteとかも自動で設定されてないのか（そういうもんなんだろうか）



参考文献
http://rcmdnk.github.io/blog/2014/06/09/compouter-git/

RestEasyを理解するためのサンプルコード集

RestEasyはJBossにバンドルされているJAX-RS実装。

日本語・英語問わず、あまり親切な情報がなかったのでサンプルとして纏めておく。

JBOSS系は公式ドキュメントがわかりづらい上に、Updateがきちんとされてなかったり、いつもながらとっつきにくい。Glassfish実装のJerseyの方がドキュメントが親切だし、mavenのarchetypeもある。選べるのならばJerseyの方がいいだろう。

RestEasySample1

まず単純なHelloworld。これが動けばとりあえず設定系は成功しているとみなして良いはず。

個人的にはweb.xmlに何も書かなくていいというのに嵌った。Jerseyでは確かここに定義を書かなければ行けなかったと記憶している。

RestEasySample2

GETとPOSTを使ったサンプルを少し。

RestEasySample3

JAXBと組み合わせた時のサンプルを少し。

メソッドの戻り値にJAXBのAnnotationをつけたクラスを指定すれば、勝手にxmlに変換してhttpの戻り値としてくれるのはちょっと感動した。

RestEasySample4

Basic認証を使ったサンプルを少し。

web.xmlでBasic認証を設定すると、JAX-RSがその先でEJBを呼び出したとしても、認証が通った状態になっている。JBOSS全体で認証をパスした扱いになっているのかも(未確認)