Brook’s Studio

ISUCON 11 予選にチーム「四年ぶり二度目」で参加した

2021-08-22T23:45:54+09:00

ISUCON 11 の予選にチーム「四年ぶり二度目」でまよ子くんとしょラーさんと参加した。チーム名の由来はこのメンバーで参加するのが四年ぶり二度目だから。

自分個人としては通算で5回目ぐらいの参加。今回初めて一般枠で最終22位で予選通過できた。

やったこととか感想とかをメモしておく。

準備

とりあえず言語を何にするかという段階で候補に Ruby, Python, Go, Rust が候補に上がった。これまでは Ruby か Python で参加していたが、違う言語で参加したい気持ちがあった。

Rust は特に読みにくい言語でもないし参考実装も提供予定、他の2人も行けそうということでせっかくなので Rust で参加することにした。本番までに10予選の環境を作ってみたりコード読んだりして軽く練習した。

本番

やった対応は大体しょラーさんの記事にある通り。自分は主にインフラ周りをみながら、二人がやっている実装のデバッグを手伝ったり、進捗をみたりしていた。競技時間中はずっと Discord で通話をしながら、困ったことがあったら画面共有して確認していた。 Zoom or Skype 使おうみたいな話もしていたが結局 Discord で事足りた。

反省

しょラーさんも書いている通り、最終的に12万点近く点数は出たが、あえて /api/trend にバグを残すことでユーザーを増やさず、その分他で点数を伸ばす、というハックをしてしまった。これがなかったら半分以下のスコアだったはず。若干すっきりしないが結果オーライだとは思う。ユーザーが増えたときにスコアが落ちてしまった原因については本戦までにベンチ環境作って検証しておく。
初動で用意した Ansible script で MariaDB を飛ばし、 CloudFormation から再構築するという失敗をした。
Conditional GET について知らず、image を取り出す実装をした。スコアにはつながったが、結構時間かかってしまったのでもったいなかった気もする。
/api/condition の重要性(初期状態で9割のレスポンスを落としていること)に気づくのが遅く、対応ができなかった。バルクインサートにしたり、キューイングしたりやりようは思いついたが気づいた時点での残り時間が少なく断念。

所感

Rust で実際どのくらい行けるのかわからなかったが、使ってみて正解だった気がする。

また毎度のことながら課題として用意された問題のうち、5/10ぐらいを解いたところで時間が来てしまう。そして毎年知らない技術要素に出会う。

問題や形式も楽しく、お祭り感もありいいコンテストだなと思います。開催ありがとうございます。

本戦もがんばります。

PC環境 2021

2021-03-13T15:17:43+09:00

2017年にPCパーツを購入して自作PCを組み立てた(自作PCのパーツ購入)。

あれから数年経ち、いくつかのパーツを買い換えた。あれなんのパーツ使ってるんだっけとか思って記事を見返すことが多かったので、現在の環境についてもメモがてら整理しつつ記事にしておく。

変わっていないもの

PCケース
- 大きいやつを買ったのでそのまま使えている
電源
- CPU、GPUを買い替えた時に変えようか迷ったが現役続行
メモリ
- 16GB なのでもう少し増やしたい&買い替えたい気持ちはある
ノートPC
- Macbook Pro 2015 を使っている。さすがにそろそろ買い替えたい

CPU & マザーボード

Ryzen 5 5600X & TUF GAMING B550-PLUS

おそらく最大の変更。以前作ったときはこだわりがなければIntel一択という状況だったが、この数年でRyzenいいよという風潮が広がり、今回買い替えのタイミングでせっかくなので乗り換えた。

クロック数もコア数も増えたので非常に快適になった。 5950Xにも心惹かれたが、電源容量や予算的な都合から見送り。

マザーボードもCPUが変わるのでそれに合わせて買い替え。 CPUと抱き合わせだったので特にこだわりはないが、インタフェースが色々新しくなっている。

GPU

GeForce RTX 3080 GameRock OC 10GB

GTX1070 から買い替え。Cyberpunk 2077 を快適にプレイした買ったので更新した。 2020年末に買ったおかげで、2021年になってからのマイニング需要によるGPU不足を避けられて良かった。

NVMe M.2 SSD

SSD & ヒートシンク

ディスク容量が足りなくなってきており、せっかくなのでNVMeでM.2のものを購入。速い。

周辺機器

Dell U3219Q 31.5インチ4Kモニター

4K / HDR / USB-Type C で探していて、ちょうど良かったので購入。個人的に4Kディスプレイは32インチぐらいがちょうどいいのではないかと思っている。

USB切替器

在宅勤務で普段使っているキーボード・マウスと仕事用のPCを接続するために購入。ボタン一つで切り替えられるので便利。

Realforceキーボード

在宅でキーボードにこだわりたくなり、自作キーボードに一瞬入門していた。道具を揃えて Ergodox を作ってしばらく使っていたが、あれ、これ普通のキーボードの方が使いやすいなと思ってしまった。というわけでRealforceを買った。

押しごこちが非常に良い。

ロジクールMX Master 3

特にマウスにこだわりはなかったが、せっかくなのでいいものを購入してみた。若干重いが使いやすい。アプリごとのショートカット割り当てや、複数PC間での移動がスムーズで良い。

BenQ ScreenBar

在宅勤務で机の上の暗さが気になったので購入。 USB給電でディスプレイの上に引っ掛けることができて良い。

所感

自作PCを組み立てるときに、「アップデートするときに結局全取っ替えすることになるよ」みたいなコメントをよく見たが、結構その通りになっている。

2020年に読んだ本まとめ

2021-01-03T15:15:48+09:00

2020年に読んだ本まとめ

はじめに

2020年に読んだ本をまとめる。 2020年は15冊だった。年々減少傾向にある。数を増やしたいわけではないけど、ゲームとかYoutubeとかでダラダラ過ごしている時間が長いのでもうちょっと読書に時間当てたい。総じて無駄に過ごしている時間が長い一年だった。

積本が結構あるのでまずはこれを消化していきたい。

小説

2020年は小説はあまり読まなかった。その代わり漫画をいっぱい読んだ気がする。読んだ小説はどちらも虚構推理で言及されていたもの。

スリーピング・マーダー

回想の中の殺人。事件自体はすでに起きていて、何があったのか、犯人は誰なのかを残された手がかりや人々の証言から探っていく。手探りで真相に近づいていく感じと終盤の緊迫感が良かった。

ロウフィールド館の惨劇

最初の1ページ目で犯人とその動機が説明されているミステリー。最初に結論があって、それをひたすら補足していくスタイルで面白かった。

雑学など

これまでに読んだ本から派生したり、面白そうなレビューを見たりして買ってる。

サーチ・インサイド・ユアセルフ――仕事と人生を飛躍させるグーグルのマインドフルネス実践法

マインドフルネスについての本。マインドフルネスのやり方とか、その効果とかを説明している。結構面白かったのと、思考を整理する時間が欲しいなという時期もあったので一時期瞑想をしていた。最近は飽きてやっていない。。。

数学で犯罪を解決する

NUMB3RSというアメリカのドラマで使われていた数学の手法について解説した本。ニューラルネットとか主成分分析とか、確率と統計の話が多かった。さくっと読めて面白かった。

岩田さん岩田聡はこんなことを話していた。

任天堂の元社長である岩田さんの言っていたことなどをまとめたエッセイ本。友人に勧められて読んだ。

コーヒーの科学「おいしさ」はどこで生まれるのか

コーヒーについて、科学的にいろいろな面から解説や紹介などをしてくれる本。豆の木の話から、最後の抽出して飲むところまで、幅広く扱われていて参考になった。

すし手帳

Kindleで安かったのでなんかの機会に買った。食べ物とか飲み物、お酒とか、ただ食べて美味しいだけじゃなく、ちょっとした知識があるだけで楽しみ方が変わってくるので少しづつ学んでいきたい。

技術書・ソフトウェアエンジニア向けの本

いわゆるコードの書いていない技術書については、書いてあること結構似ているし、新しい知識を得るという意味ではあんまり読んでも意味ないんじゃないかみたいなことを少し感じた。一方で特定の言語・フレームワークに依存する知識ばっかりつけててもしょうがないし、その辺はバランス取る必要がありそう。

実践Firestore

趣味の開発で使ってみようと思って買った。簡単な導入や解説があってとっかかりには良さげだった。

リファクタリング(第2版): 既存のコードを安全に改善する

ソフトウェアエンジニアへのおすすめ本によくある本。リファクタリングの技法について、やり方と解説が書いてある。自分的にはよくやる作業に名前をつけてもらったような感じで、めちゃくちゃ新しい知識が得られるようなものではなかったが役に立つと思う。

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

どういう開発をしているとプロダクトがレガシーになってしまうのかみたいなことが書いてある。この手の本、基本的に「テストを書こう」「レビューをしよう」「CI/CDちゃんとやろう」みたいなことが書いてあることが多い。それだけ大事ということなんだろうけど、自分は割と最初からそのへんちゃんとやってる環境に加わることが多いので、またこういう話かーみたいに感じることが多い。

テスト駆動開発

’

ユニットテストの手法について、簡単なアプリケーションを題材に説明してくれる本。実際どういう風にやればテストドリブンで開発を進めていけるのか意識できるので結構良かった。

個人開発をはじめよう！クリエイター25人の実践エピソード

個人開発している人たちのエピソードを集めた本。個人で趣味で何か作りたいみたいな気持ちはずっと持ってて、その参考やモチベーションアップ用に読んだ。結局何も作れていないので2021年は何か作ることを目標にしたい。

エンジニアとして世界の最前線で働く選択肢 ~渡米・面接・転職・キャリアアップ・レイオフ対策までの実践ガイド

アメリカでIT企業で働くための手順とか諸々が、筆者の実体験を元に書いてある。この手の話は最近はブログとかで読めたりもするけどある程度参考にはなった。いつか海外で働いてみたいみたいな気持ちもあるが、このご時世なので数年は無理そうだし、なんならリモートが前提になっちゃいそう。

新装版達人プログラマー職人から名匠への道

最近第2版が出てた本。テストを書こうとかCI/CD環境整備しようとかペアプロやってみようとか書いてあった。あとはドキュメントちゃんと書こうとか、プロジェクトに参加する時の話とか。

情熱プログラマーソフトウェア開発者の幸せな生き方

この手の本では今のところ一番面白かった。研鑽を怠らないとか、プログラマーでもビジネスに興味を持つとか、日々の仕事に全力で取り組むとか書いてあった。

ソフトウェアエンジニアとしての人生ゲームでスキルの3軸、自分の中の3人をどう育てるか

2020-08-31T19:29:38+09:00

はじめに

個人レベルでのスキルの割り振りについて、思考をまとめるためのメモがてら記しておく。いくつか他の記事でも似たような考え方は見た記憶があるので、見つけたらリンクを貼っておく。また、自分はソフトウェアエンジニアでしかもペーペーなので、時が経ったり、他の立場の人から見たりしたら全く異なる意見になるかもしれない。

3軸

自分のキャリアを考えていく上で、どういうスキルを身につけるか、あるいはどういう人になりたいかということを考えながら周りの人や環境を見たときに以下の3軸があると思っている。

ギーク：新しい技術を身につける・使う人
ビジネスマン：お金を稼ぐ・仕事を回す人
アーティスト：新しいものを作る人

もちろんこれ以外にも、マネジメントスキルとか、語学スキルとか、言語スキルとか基礎となってくるスキルも色々ある。だがおおまかに分けるとこの3タイプになるのではと思う。

個人としての成長戦略を考えたときに、このスキル割り振りをどうするか、自分のメンターやロールモデル、あるいはチーム、組織はどういうスキル割り振りか？とか気にしてみると結構面白い。特にソフトウェアエンジニアの面白いところは、この3軸すべて伸ばそうと思えば伸ばせるところだと思う。

スキルの大きさと割合

大きさ

各軸について、HumanKindのグラフみたいな段階があると思っている。

今週登場したクリエイターの格付け「THE AK LINE」は広告業界に実在するアイデアの指標「ヒューマンカインド」を元ネタにしてます。

こちらは8超えをエイトボールと評し、確実に世界的な賞を受賞できるレベルとされています。

確か「iPhone」が9だった記憶…。 pic.twitter.com/QH20DTG8GX
— かっぴー/左ききのエレン👉13巻発売中 (@nora_ito) August 15, 2020

どの軸についても、飛び抜けている人はそれ単体で生きていけるし、できる人は早い段階でかなりの高レベルになるのではないかと思っている。だが大体の人は各スキルが1ないしは0、得意分野は2ぐらいで社会人になり、ベテランと言われるようになるまでに日々の仕事や趣味、自習によって各軸少しづつ伸ばしていくことになるのだろう。

やはり社会人の場合仕事によって伸びる割合が一番多いのではないかと思う。また、どの軸についても学習をやめると成長が止まり、年が立つとだんだんと衰退していくのだろう。

割合

バランス型

器用貧乏とも言われるタイプ。こういうタイプの人は、ユーティリティ・プレイヤーとして色んな所でやっていける一方、すべての知識を高レベルで維持するのは相当難しいと思う。実際3つがハイレベルにきちんとバランスしている人はほとんどいないと思う。少なからずバックグラウンドの分野や今取り組んでいることにバイアスがかかっているはず。

ギーク＋ビジネスマン型

ビジネス知識を持ちつつ、技術スキルもあるタイプ。SIerに多そう。新しいものを作るよりは、スケジュールを立ててしっかりとものを作るタイプでProject Managerとかになるのかもしれない。技術スキルもビジネススキルも潮流が早そうで、しっかりついていくのは難しそう。

ギーク＋アーティスト型

技術スキルがあり、新しいものを作っていくタイプ。OSSや企画開発などで世の中にないものを作って提供していくイメージ。ハイレベルであってもお金を稼ぐのが難しそうだが、評価されるところに行けば相応の評価をもらえる人たち。世の中でいわゆる天才と言われる人たちはここになる一方で、ワナビーがもっとも多そうでもある。

ビジネスマン＋アーティスト型

新しいアイデアがあり、それを具体化してお金にするタイプ。ベンチャーを作ったり、経営戦略などを行なうタイプ。これにさらに技術スキルがあると一人でなんでもできる人になる。あるいは自分のために技術を提供してくれる部隊が必要になる。どれくらい具体的なビジョンがあるか、人を集められるかで成否が決まっていきそう。

組織構成

個人、チーム、部門、会社単位で見たときに、大きくなればなるほどバランスが取れていくはず。チームを作ることになった場合、そのチームの目的や目標によってどういうスキル軸の人がほしいか決まってくると思う。

ただし、個人という視点で見ると自分に影響を与えるのはせいぜい部門単位で、直近のスキル成長という面ではチーム単位での影響が一番大きいのではないかと思う。会社の場合、各部署で求められていることやその時点でのチームバランスによって外発的に中の人のスキルバランスが成長していく。

個人のスキルとキャリアパス

自分のやりたいこと、伸ばしたいスキルを考えたときに、今の仕事とギャップを感じてしまうこともあると思う。そうなるとそこを抜け出したくなるはず。そうなったときに、自分の伸ばしたいスキル構成になれるようなところに所属するためには、今の仕事では伸びないスキルを自分で伸ばさなければいけないという状態になりそう（大企業の新卒配属などそれまでのスキル構成を無視した配属でない限り）。そうなると自習が必要になる。

このときの自習は、すぐに成長に結びつくものでもないし、ましてや報われる保証なんてないわけで、個人で努力するにはある程度胆力がいりそう。だが一人で楽しめない部分を伸ばそうとしてそれはそれで本当に幸せなのかという考えもあり、時間などの都合を見て自由にやっていくのが良さそう。

また、自分で考えている得意分野、なりたい人と、他人に認められる・必要とされる分野が違うこともあると思う。他人に褒められるところが自分の得意分野という意見もあるが、どこまで自分を曲げずに過ごしていくか、どこまで受け入れるのかも悩ましい。

スキル割り振りについては、自分から成長するよりも外部環境によって成長する割合の方が大きいらしい（となんかで読んだ）し、意外と個人でドリブンできる範囲は小さいのかもしれない。なので方向をある程度考えながら流れに身を任せていた方が楽な部分もありそう。あと、あまり枠にはめて考えすぎるのも柔軟性を失うのかなと思ったりもする。

さいごに

こういうこと考えるの面白いけど、うだうだ表面で考えているだけで何も行動を起こさないのが一番良くないのかなと思う。まぁ悩みすぎても疲れるだけだし、ゲームだと思って楽しみながら人生をやっていきたい。

Gradle のタスクを除外する方法

2020-03-12T22:39:23+09:00

Introduction

Gradle でタスクを実行する時に、プラグインにより　SourceSets に対して自動的に追加されるタスクなどを実行せずに除外したい場合がある。タスクの除外の仕方について調べたことをメモ。

$ java -version
openjdk version "11.0.6" 2020-01-14 LTS
OpenJDK Runtime Environment Corretto-11.0.6.10.1 (build 11.0.6+10-LTS)
OpenJDK 64-Bit Server VM Corretto-11.0.6.10.1 (build 11.0.6+10-LTS, mixed mode)

$ ./gradlew --version

------------------------------------------------------------
Gradle 6.2.2
------------------------------------------------------------

Build time:   2020-03-04 08:49:31 UTC
Revision:     7d0bf6dcb46c143bcc3b7a0fa40a8e5ca28e5856

Kotlin:       1.3.61
Groovy:       2.5.8
Ant:          Apache Ant(TM) version 1.10.7 compiled on September 1 2019
JVM:          11.0.6 (Amazon.com Inc. 11.0.6+10-LTS)
OS:           Mac OS X 10.14.6 x86_64

コード例

適当な　Gradle プロジェクトを用意し、 build.gradle に以下のようにタスクを定義する。

task checkMain {
    doLast {
        println "Main"
    }
}

def taskNames = ["First", "Second", "Third"];
taskNames.eachWithIndex { name, i ->
    task "check$name" {
        doLast {
            println "$name"
        }
    }
    if (i > 0) {
        tasks.getByName("check$name").dependsOn("check${taskNames[i-1]}")
    }
    if (i == 2) {
        checkMain.dependsOn("check$name")
    }
}

task checkStart {
    dependsOn "checkMain"
    doLast {
        println "Start"
    }
}

checkStart を実行すると以下のようにジョブが実行される。

$ ./gradlew checkStart

> Task :checkFirst
First

> Task :checkSecond
Second

> Task :checkThird
Third

> Task :checkMain
Main

> Task :checkStart
Start

BUILD SUCCESSFUL in 2s
5 actionable tasks: 5 executed

このコードを例に除外する設定をおこなう。

依存も含めてそのタスクを全て除外する場合

以下の3つは全て同じ動作となり、実行するとそのタスクの依存を含めて全て除外して実行する。 settings.gradle, build.gradle に記載した場合プロジェクトから完全に除外される。

$ ./gradlew checkStart -x checkSecond

> Task :checkThird
Third

> Task :checkMain
Main

> Task :checkStart
Start

BUILD SUCCESSFUL in 1s
3 actionable tasks: 3 executed

コマンドラインオプションを指定する

$ ./gradlew checkStart -x checkSecond

settings.gradleに設定を書く

startParameter.excludedTaskNames= ["checkSecond”]

build.gradle に設定を書く

project.gradle.startParameter.excludedTaskNames.add("checkSecond")

一部の依存タスクのみ除外したい場合

除外ではなく正確には無効化だが、以下の2種類によって実現できる。実行すると次のようになる。除外した checkSecond のみがスキップされ、 checkSecond の依存タスクである checkFirst は実行されている。

$ ./gradlew checkStart

> Task :checkFirst
First

> Task :checkThird
Second

> Task :checkMain
Main

> Task :checkStart
Start

BUILD SUCCESSFUL in 1s
4 actionable tasks: 4 executed

タスク生成時に無効化する

tasks.whenTaskAdded { task ->
    if (task.name.startsWith("checkSecond")) {
        task.enabled = false
    }
}

TaskExecutionGraph 作成時に無効化する

gradle.taskGraph.whenReady { graph ->
    if (graph.hasTask(checkMain)) {
        tasks.findByName("checkSecond").enabled(false)
    }
}

参考

Gradle Official Document: Build Script Basics

Gradle Official Document: Build Lifecycle

StackOverFlow: How can I disable a task in build.gradle

How to exclude a task in Gradle

2020-03-12T22:39:23+09:00

Introduction

In this article, I explain about how to exclude a task when you run some task by using Gradle. You might need these configurations in a case that you want to exclude tasks generated by a plugin for each SourceSets.

$ java -version
openjdk version "11.0.6" 2020-01-14 LTS
OpenJDK Runtime Environment Corretto-11.0.6.10.1 (build 11.0.6+10-LTS)
OpenJDK 64-Bit Server VM Corretto-11.0.6.10.1 (build 11.0.6+10-LTS, mixed mode)

$ ./gradlew --version

------------------------------------------------------------
Gradle 6.2.2
------------------------------------------------------------

Build time:   2020-03-04 08:49:31 UTC
Revision:     7d0bf6dcb46c143bcc3b7a0fa40a8e5ca28e5856

Kotlin:       1.3.61
Groovy:       2.5.8
Ant:          Apache Ant(TM) version 1.10.7 compiled on September 1 2019
JVM:          11.0.6 (Amazon.com Inc. 11.0.6+10-LTS)
OS:           Mac OS X 10.14.6 x86_64

Sample code

I create a Gradle project as a sample, and define tasks in build.gradle as below.

task checkMain {
    doLast {
        println "Main"
    }
}

def taskNames = ["First", "Second", "Third"];
taskNames.eachWithIndex { name, i ->
    task "check$name" {
        doLast {
            println "$name"
        }
    }
    if (i > 0) {
        tasks.getByName("check$name").dependsOn("check${taskNames[i-1]}")
    }
    if (i == 2) {
        checkMain.dependsOn("check$name")
    }
}

task checkStart {
    dependsOn "checkMain"
    doLast {
        println "Start"
    }
}

when I run checkStart, the tasks executed like this.

$ ./gradlew checkStart

> Task :checkFirst
First

> Task :checkSecond
Second

> Task :checkThird
Third

> Task :checkMain
Main

> Task :checkStart
Start

BUILD SUCCESSFUL in 2s
5 actionable tasks: 5 executed

Based on this sample, I configure to exclude the checkSecond task.

Exclude the task, including its dependency tasks

These 3 configurations exclude the task including its dependency tasks. When the checkStart task executed, checkSecond and checkFirst, which the dependency task of checkSecond, are excluded.

Note that when you write in settings.gradle or build.gradle, the configuration are enabled on all tasks in the project.

$ ./gradlew checkStart -x checkSecond

> Task :checkThird
Third

> Task :checkMain
Main

> Task :checkStart
Start

BUILD SUCCESSFUL in 1s
3 actionable tasks: 3 executed

Set command line option

$ ./gradlew checkStart -x checkSecond

Write the configuration in the settings.gradle

startParameter.excludedTaskNames= ["checkSecond”]

Write the configuration in the build.gradle

project.gradle.startParameter.excludedTaskNames.add("checkSecond")

Exclude the task, without excluding its dependency task

These 2 configurations exclude only the specified task, so the dependency tasks of the excluded task are executed. These configurations are not exclude but disable to be exact.

In this example, the checkSecond task is skipped and the checkFirst task is executed.

$ ./gradlew checkStart

> Task :checkFirst
First

> Task :checkThird
Second

> Task :checkMain
Main

> Task :checkStart
Start

BUILD SUCCESSFUL in 1s
4 actionable tasks: 4 executed

Disable when task added

tasks.whenTaskAdded { task ->
    if (task.name.startsWith("checkSecond")) {
        task.enabled = false
    }
}

Disable when task execution graph is ready

gradle.taskGraph.whenReady { graph ->
    if (graph.hasTask(checkMain)) {
        tasks.findByName("checkSecond").enabled(false)
    }
}

That’s all.

References

Gradle Official Document: Build Script Basics

Gradle Official Document: Build Lifecycle

StackOverFlow: How can I disable a task in build.gradle

VPSを移動した

2020-02-02T18:43:56+09:00

はじめに

長らくServersmanのVPSを使っていて特に不満はなかったんだけど、CentOS 6 で立てておりサポート終了が迫ってきているのでぼちぼちアップデートが必要になっていた。というわけでせっかくだし他のVPSに移動するかーと思い作業をした。

移行先はAWS Lightsail, Vultr, Conoha, さくらあたりが候補。いろいろ評判はあるけど、このサイトとメールサーバーぐらいにしか使ってないし、GMOインターネットの株を持っていれば優待で割引になるというのを知ってConohaにしてみた。

あと CentOS じゃなくて Ubuntu にした。

以下自分用に作業ログ。

Conoha で VPS を立てる

GUIをぽちぽちしながらインスタンスを立てる。そのあとログインして最低限の設定をする。

ユーザー追加
SSHの設定

PermitRootLogin no
PasswordAuthentication no
# 適当にポートを変える

UFW の設定

sudo ufw logging on
sudo ufw allow いろいろ
sudo ufw status
sudo ufw enable

fail2ban の設定

sudo apt install fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
#いい感じに編集
sudo systemctl start fail2ban
sudo systemctl enable fail2ban

その他使うソフトウェアのインストール&設定

logwatch, rbenv, tmux あたり。

postfix, dovecot の設定

https://www.server-world.info/query?os=Ubuntu_18.04&p=mail&f=2を参考に設定をしてメールアカウントを作る。とりあえずSSL/TLSを使わずに送受信ができることを確認。そのあと証明書を取得して送受信ができることを確認。

Let’s encrypt を入れる

ググって入れる。 cron で renew の設定も忘れずにする。

nginx

インストールして設定する。サイトの設定は別ファイルでよしなに。

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
	worker_connections 768;
}

http {
	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;
	keepalive_timeout 65;
	types_hash_max_size 2048;
	include /etc/nginx/mime.types;
	default_type application/octet-stream;
	ssl_protocols TLSv1.2;
	# SSLセッションキャッシュをすべてのワーカープロセスで共有
	ssl_session_cache shared:SSL:30m;
	ssl_session_timeout 30m;
	# 2048bit以上で作ったDH交換鍵を指定
	ssl_dhparam /etc/ssl/private/dhparam.pem;
	# OCSP Stapling を有効にする
	ssl_stapling on;
	ssl_stapling_verify on;
	# ルートCA証明書と中間証明書結合した証明書を指定
	ssl_trusted_certificate /etc/letsencrypt/live/brookbach.com/fullchain.pem;
	# サーバが示した暗号スイートの優先
	ssl_prefer_server_ciphers on;
	ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

	access_log /var/log/nginx/access.log;
	error_log /var/log/nginx/error.log;

	gzip on;
	include /etc/nginx/conf.d/*.conf;
	include /etc/nginx/sites-enabled/*;
}

ブログ移動

こんな感じでPushしたらデプロイされるスクリプトをおいているのでこれをそのまま新しいサーバーに移動する。

!/bin/bash -l

GIT_REPO=$HOME/brookbach.git
TMP_GIT_CLONE=$HOME/tmp/brookbach
PUBLIC_WWW=/var/www/brookbach

git clone $GIT_REPO $TMP_GIT_CLONE
cd $TMP_GIT_CLONE
bundle install
JEKYLL_ENV=production bundle exec jekyll build -s $TMP_GIT_CLONE -d $PUBLIC_WWW
rm -Rf $TMP_GIT_CLONE
exit

確認

メールサーバーの判定https://mxtoolbox.com/diagnostic.aspx
- 降ってきたIPがBARRACUDAのブラックリストに登録されていたので許してと懇願
SSLの判定https://www.ssllabs.com/ssltest/analyze.html
Webページの表示スピードなどhttps://developers.google.com/speed/pagespeed/insights/?hl=JA

おわりに

週末で終わってよかった。メールとか最近はサービス登録するときにしか使わないし、それすらソーシャルアカウントで代用できたりする。届くメールも9割メルマガだし、要らないのでは？という気持ちもある。自分のサイトとかも別にはてなブログとか Qiita でいいじゃんと言われたらそれはそう。とはいえなんとなく Software engineer として働いているという矜持もあり、まだ持っていたい気持ちの方が大きい。

自分でサーバー持ってて何が怖いってセキュリティで、一応今の所経験はないけど、DDosとかはともかくサーバーが諸々の踏み台にされたりすると辛い。次に辛いのはメールがなぜかわからないけど届かないとか。自分なりに調べながらやってるので勉強にはなる。

2019年に読んだ本まとめ

2020-01-05T16:39:20+09:00

2019年に読んだ本まとめ

はじめに

2019年に読んだ本をまとめる。 2019年は合計21冊だった。少ない。多分ゲームのやりすぎだと思う。（確認したら去年も全く同じことを書いていた）

前半は社会人になったばっかりということで意識高く過ごせていたが、後半になるとモチベーションも下がりダラダラしている時間が長くなっていた。

以下、本の簡単な要約と感想。雑にジャンル分けしてみた。感想については、前に読んだものほど簡素になっている。画像はアマゾンリンク。

小説

まとめて本を5冊ぐらい買うときにアラカルト的に1冊ぐらいは小説を読みたくなるので読んでいる。

ためになるような本ばっかりじゃなくて物語を読むのも好きなんだけど、物語を楽しむなら映画とか漫画とかの方が娯楽としては楽しいのでそっちに流れがち。

タタール人の砂漠

辺境の砂漠に着任した兵士が、いつ来るともわからない敵に備えながら一生を終える話。いざ敵が来たときには自分は老いており、若者に邪魔だと言われ何もできず後方へ送られる。

何か起こるのでは、何か起こって欲しいと願いながらひたすら単調な人生を過ごすのが大多数の人間の人生なのではと思った。自分から動かないと、何も変わらず、変えたいなら動かないとなとぼんやり思った。

熊と踊れ

兄弟が銀行強盗をしていく話。元となる事件があるらしく、リアルな計画をドラマチックに仕立てている。また話が進むにつれて泥沼になっていくのも面白い。ちょっといびつな形の家族の絆が描かれており、そういう視点からも面白かった。

砂の女 (新潮文庫)

ミステリーとかSFを読むことが多いので、あまりこういう文学的な本を読むことはないのだがオススメされたので読んでみた。表現がとても官能的で、直接的な表現をせずここまですごい文が書けるのかと感動した。内容についても色々な見方ができると思うが、自分は本人が満足しているならそれでいいのではないかと思った。

老人と海 (新潮文庫)

海に出た老人がカジキマグロを釣りにいく話。前半と後半に分かれており、前半でカジキマグロと死闘の末に釣り上げ、後半はそれを持って帰る道中で釣った獲物を狙ってくるサメなどと戦っている。

話の流れとしてはこんな感じで、うまいこと感想を書こうと思ったんだけど難しい。もうちょっと人生経験積んでから読み直すとまた違ってくるのかもしれない。

ためになる本

「ためになる本」ってなんだって感じだが、うまいこと名前がつけられない。読んだら新しい知識が得られそうな本とか、単純に読みたいと思った本とか、オススメされた本とか。

虫眼とアニ眼 (新潮文庫)

医者である養老孟司さんと宮崎駿さんの対談をまとめた本。対談を通して、二人が世の中をどういう風にみているのかが感じられて面白かった。また宮崎駿さんの自身の仕事に対する思いとか考え方がとても面白く、この人はすごい人なんだなーと思った。

ぼくは、子どもの本質は悲劇性にあると思っています。つまらない大人になるために、あんなに誰もが持っていた素晴らしい可能性を失っていかざるを得ない存在なんです。それでも、子どもたちがつらさや苦しみと面と向かって生きているなら、自分たちの根も葉も無い仕事も存在する理由を見出せると思うんです。(p. 159)

ピクサー流創造するちから――小さな可能性から、大きな価値を生み出す方法

ピクサーという組織についてはいくつか本があって、これはその中でも一番有名な気がする。苦境に立たされていたピクサーが、どのように作品作りをしてきて、どう生き延び、成功してきたがが創設者の視点から書いてある。とてもおもしろい。実際に面白いものを作ってきた人、組織の人が、どうすれば面白いものが作れるか？ということについて書いている。いつかピクサーで働いてみたいと思った。

アイデアをきちんとかたちにするには、第一にいいチームを用意する必要がある。優秀な人材が必要だというのは簡単だし、実際に必要なのだが、本当に重要なのはそうした人同士の相互作用だ。 (p. 112)

睡眠の話

自分がロングスリーパーで、かつ寝起きがとても悪いので睡眠についてハックしたいと思っている。この本は、睡眠の仕組みとか、健康との関連とかについてわかりやすく書いてあって面白かった。

動的平衡

生命とは、絶え間ない流れの中にある動的なものである。生命とは何か、何を持って命とするかという話について、生命学的な話を中心にまとめている。命や心というものは紛れもなく化学反応の連鎖によってできており、その「流れ」自体を指して命と呼んでいるのだなと感じた。化学や生物学の話を織り交ぜながら、食事や時間、病気などについて幅広くおもしろい話が書いてある良い本。

生命とは何か？この永遠の問いに対して、過去さまざまな回答が試みられてきた。DNAの世紀だった二十世紀的な見方を採用すれば「生命とは自己複製可能なシステムである」との答えが得られる。確かに、これはとてもシンプルで機能的な定義であった。しかし、この定義には、生命が持つもう一つの極めて重要な特性がうまく反映されていない。それは、生命が「可変的でありながらサスティナブル（永続的）なシステムである」という古くて新しい視点である。(p. 229)

自分の仕事をつくる (ちくま文庫)

様々な場所で様々な働き方をしている人にインタビュー形式で話したことをまとめた本。「いい仕事」とは何か、「いい仕事」をしている現場はどんなものなのかについて書いている。結構面白くて、かついい言葉も多く自分もいい仕事をしたいなと思った。

以前、あるピアノ奏者に「音楽家にとって、最も重要な能力とは何か？」という質問をしたところ、迷わず「聴く能力です」という答えが返ってきた。自分が出している音を聴き取る力がない限り、その先への進歩はない。イメージと現実とのギャップが感じられるからこそ悩めるし、成長することも出来るが、もし「自分は十分にいい音が出せている」と感じたら、そこがその人の音楽の上限となる。(p. 29)

優れた技術者は、技術そのものではなく、その先にかならず人間あるいは世界の有り様を見据えている。技術の話をしているときにも、かならず単なる技術に終わらない視点が顔をのぞかせる。音楽家でも、医者でも、プログラマーでも、経営者でも同じだ。(p. 74)

「そもそも模型なんて生活必需品ではない。僕らのような仕事がなくなったところで、誰も困りはしないでしょう。だからこそ、つくる側が楽しんでいなかったら嘘ですよね。最初から遊びの世界なんだから、馬鹿みたいに思いっきりこだわった仕事をしたほうがいいと思うんです。(p. 225)

人生には、それ自体に価値のあるものが、とてもたくさんあります。経験というものは、何か他のことに役立つから重要なのでなくて、たんに存在しているというだけで重要なんです。（中略）木を植えるのは、リンゴが欲しいからというだけではない。ただ美しいからという理由だけで植えることもある」(p. 229)

知的生活の設計―――「10年後の自分」を支える83の戦略

どうやって勉強していくか、みたいなのを思って読んだ。本の読み方とか日々の生活についてTipsがいっぱい書いてある。全てを実行することはできないが少しづつ参考にしていく。

伽藍とバザール

いわゆるギーク的な古典。オープンソースのメリット、どういうプロダクトならオープンにするとメリットが生まれるか、どういう風にやるとうまくいくかみたいなことを口語調の論文で書いてある。サクッと読めて結構面白かった。

まともな行動をとっていれば、おもしろい問題の方からこっちを見つけだしてくれる。(p. 12)

人間は仕事をするとき、それが最適な挑戦ゾーンになっていると、一番うれしい。簡単すぎて退屈でもいけないし、達成不可能なほどむずかしくてもダメだ。シヤワセなプログラマは、使いこなされていないこともなく、どうしようもない目標や、ストレスだらけのプロセスの磨耗でげんなりしていない。楽しみが能率をあげる。(p. 46)

FACTFULNESS(ファクトフルネス)　10の思い込みを乗り越え、データを基に世界を正しく見る習慣

ちょっと前にすごい話題になってて人にオススメされたので読んでみた。日常で遭遇するニュースやデータ、噂話について、人間がどういう風に誤解しやすいか、なぜそういう風に考えてしまうか説明してくれる。いわゆるバイアスみたいなのは自分で気づくのが非常に難しいが、この本の内容と合わせてデータをもとに検証することで誤解なく読み取ることが出来るようになりそう。

趣味

旅行・料理・雑学など。

地球の歩き方 B23 ペルーボリビアエクアドルコロンビア 2018-2019

旅の指さし会話帳６２ペルー（ペルー〈スペイン〉語)

2019年の3月に南米旅行に行っておりそのときにKindleで買った本。夜などの暇な時間にiPhoneで読んでいた。付け焼き刃なのでとっさに口に出すのは無理だが、挨拶などのフレーズだけでも覚えておくと現地でのコミュニケーションがスムーズになるし楽しめる。今後も海外旅行行くときにはこれ系の本を買っていこうと思う。

アメリカ海軍SEALのサバイバル・マニュアル: 極限を生き抜く精鋭たちが学んでいること (単行本)

ちょっと前にTwitterかなんかで話題になっていて軽い気持ちで買った本。実際この本の知識が役に立つ場面は来ないでほしい。ちなみに一般人にとって一番大事なことは、戦おうとせずに必死に逃げることだそうだ。

料理の科学〈1〉〈2〉素朴な疑問に答えます

料理って手続きでもあり、化学でもあり、また自分の欲望を自分で満たせる手段の一つでもあり、とてもおもしろいと思う。この本は、エッセイとして巷で流布している噂や素朴な疑問について回答しており面白かった。

パリ在住の料理人が教えるフライパンでできる本格フレンチレシピ

ニコニコとかYoutubeで前から見ていた料理人の人のレシピ本。買って実際にいくつか作ってみた。美味しかった。料理については引き出しをどんどん広げていきたいところ。

技術書

本当はもっと読んだ方がいいと思われる。今までは読みながらしっかり写経をしていたが、それだと時間がいくらあっても足りず、今年に入ってから思い切って写経をやめた。内容の理解度という意味ではやった方が良いのだろうがいかんせん読みたい本に対して時間が足りないし技術力も足りない。ここに書いている以外でも読み途中のものが何冊かあるのでそれらも少しづつ読んでいきたい。

ふつうのLinuxプログラミング第2版

買ったのは一昨年ぐらいだが2019年にやっと読み終わった。簡単なLinuxの仕組みから、headやlsといったコマンドの実装をしながらLinuxプログラミングについての入門ができる本。断片的に知っている知識はあったが、基礎としてまとまっており良い本だった。

エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)

エンジニアとしての勉強の仕方、本の読み方、考え方、アイデアの出し方・まとめ方などの「知的生産」の方法を解説してくれる本。ちょっと感想からは外れるけどこういう風に自分をメタ的に見ることができて1冊の本にできるのすごいなと思った。内容については、例によって少しづつ意識して実践していきたい。

エンジニアのための時間管理術

いわゆる運用系のエンジニアが横割りタスクなどがある中でどうやって日々の仕事をこなしていくかについて解説している本。冒頭にプログラマ向けではないと書いてある通り、自分に対してはちょっとスコープ外だった感じがした。それでもいくつか役に立つことはあったのでこちらも例によって以下略。

［改訂新版］Emacs実践入門──思考を直感的にコード化し、開発を加速する WEB+DB PRESS plus

Spacemacsを使ってメモをとったりしているが、自分でいろいろカスタマイズしたくなるので買って読んでみた。結局メモ書きにしか使っていない。。。

オブジェクト指向でなぜ作るのか　第2版

オブジェクト指向がバズった頃になんでオブジェクト指向で作るのか、何がいいのかということについて説明している本。もはやその時代を知らない自分にとってはちょっと古いかもと思った。そして内容はソフトウェア工学の授業でやったような話となっており、それはこの本に書いてあることが教科書になるようなレベルという話ではあるのだが、今更読む本でもなかったかもしれない。世代的にオブジェクト指向がそんなに夢のあるものには見えておらず、今だと機械学習がこんな感じの扱いになるのかなとか思った。

おわりに

2020年は社会人2年目ということで日々に余裕も出てくるだろうし、このままだとあかんなという思いもあるので技術の勉強含めもっと取り組んでいきたい。

2019年に読んだ本の中では、以下の3冊が面白かった。オススメです。

ピクサー流創造するちから
自分の仕事をつくる
動的平衡

肥大する欲しい本リスト → http://amzn.asia/itMXcYK

明日から仕事だし大学生活を振り返る

2019-03-31T10:32:36+09:00

はじめに

長かった学生生活（学部5年＋修士2年）を終えて明日からとうとう仕事が始まるので、大学生活を振り返ってみる。自分が色々迷っていたときに先輩達が書いているブログとかを読んで参考になったり、助けられたりしたので、この記事もそんな感じで大学生の自分が読んで参考になればいいかなと。あと、たぶん10年後ぐらいに読み返したらまた面白いんじゃないかなとか。

なので、この記事はたぶん

情報系に進んでいる（進もうとしている）大学生・高校生
留年して進路に悩んでいる人
大学院に進もうか迷っている人
昔の自分

あたりが読んだら1byteぐらいには参考になるんじゃないかと思っている。完全に自分語りだけど自分のブログだしまぁいいかという気持ち。読んでてなんか言いたいこととかあったらメールでもTwitterのDMでも良いので来たら反応します。

というわけで振り返っていく。

大学入学以前

高校は大体の人がどこかしらの大学に行く普通科のまぁまぁな進学校だった。それなりに勉強して、なんとか現役で早稲田に合格できたので進学した。正直この時点では進路とか将来の計画とかまったくなかったし、進振りがあるから入った後に考えられそうとかいう適当な理由で基幹理工学部を受験した。

学部1,2年

なんとなく入った大学で、なんとなく勉強をしていた。サークルに入っていなかったので友達は授業で会う人ぐらいしかおらず少なかった。学部生活の一番の反省点がそれで、情報系に進む予定ならコンピュータ系のサークルとか、ロボコンのサークルとかに入っておけば良かった。転生したらその辺に入る。

バイトは小さめの飲食店でキッチンをやっていた。バイトをしていたおかげで基本的な調理スキルを身につけたり、自分より年上でなんとかやっている人達を大勢見られたのでこれは非常に良かった。

大学生になって暇な時間がとにかく増えたので株とかポーカーやったり、映画を見たり、あとはプログラミング（競プロとか）をちょっっっとだけ勉強したりしていた。

もともと授業形式で真面目に勉強するのが苦手で、1年後期ぐらいからすでに授業をサボりまくっており、2年が終わった時点で単位が留年ギリギリだった。ただその時点では、まぁ3年で必死にやればなんとかなるだろぐらいの気持ちでいた。

大学3年（1回目）

だらだら大学に行って、だらだら生活するのを続けていたら自分の中の糸が完全に切れてしまって、なんのために大学行ってんのかわからんしもういいやみたいな気持ちになっていた。家庭がちょっとごたごたしたりで1人暮らしする計画も挫折したりとかで、1回目の3年生の前半は精神が死んでいたしなんなら本当に死のうと思っていた。このころの日記を読み返すとよく自分生き残れたなと思う。

前半が終わって、留年が確定したぐらいで、なんか吹っ切れて逆にこれからどうするかとかどうなりたいかとかを真面目に考えるようになった。大学辞めてバイト先に就職するかとか、どっか働けるところ探して働くかとか、このままもうちょっと大学で頑張るかとか。

無限に時間があったのでゆっくり考えた結果、せっかく情報系に進んだんだし、技術を身につけたいという気持ちと、働くにしても今の自分はこの分野（CS系、いわゆる情報系）のことを知らなさすぎてどうしようもないという考えからどっかで一回開発系のバイトをしたいという考えになった。とりあえずRuby on Railsの勉強をして、Web系の開発ができるアルバイトを探していくつか申し込んだ。そしたら、そのうちの一つで幸運にも雇ってもらえたので働き始めた。

留年したせいで1年余裕ができてしまったのでこの計画を実行できたところもあり、もし留年せずにギリギリで進級、卒業できていたら全く違った人生になっていたと思う。

余談だが、Ruby on Railsからプログラミング始めるのはオススメできないみたいな言及をたまに見かけるが、自分はなんとかなっているし、Railsはなんもわからなくてもとりあえず動く物を作れるようになるというメリットもあり、悪くないかなと思っている。もちろんフレームワークなので裏側で色々やっていてそれが隠されているが、しばらくやってれば段々理解できるようになる。重要なのは何でも良いので始めて、続けることだと思う。あとは情報系の学部・学科だとコンピュータサイエンスの基礎の部分はなんだかんだ教えてくれるので、それと合わせて実戦的なWeb系の技術を身につけることで、深いところと広いところ両方学べると思う。

このころからときどき1人で旅行に行くようになった。これは1人で部屋で閉じこもって寝ていると精神を持ってかれるので、だったら貧乏旅行で良いのでどっかに出ていた方がいいということに気づいたからっていうのもある。

大学3年（2回目）

相変わらず精神はそんなに回復していなかったが、だるいなりになんとか動くことができるようになっていた。

開発のバイトをやっていることで、逆に大学の授業に興味が出てきたり、もっとこの分野勉強したいなと思えるようになっていた。もくもく会に行ったり、勉強会を覗いたり、インターンに行ったり、プロコンの大会に参加していたりする中で、ソフトウェアエンジニアの人とか、他の大学の人とかと会えて色んな話を聞けたのも大きかった。

単位がなんとかなりそうで、今度は進級できそうとなったときに、大学院に進むか就職するか迷った。情報系で大学院に進むか悩むときに真っ先に思うのは、「あれ、これ別に大学じゃなくても良くない？」だと思う。この分野は研究でやっていることと仕事でやっていることが非常に近く、なんなら最先端が現場だったりする。（もちろん違うところもある）そうすると、わざわざ高い学費を払って大学院に進むより、働きながら技術を身につけた方が良いのでは、と思ったりする。

自分はそう思っていて、一時期はかなり就職の方に傾いていたんだけど、最終的に大学院に進学することにした。理由はいくつかあって、まず一つはこのまま社会に出るには何もできなさすぎて厳しそうと思ったから。適当に大学生活前半を過ごしたおかげで何も身についてないし、インターンとかで会った人達はすごい人ばっかりで、今の自分がこのまま進むにはちょっと怖すぎた。もう一つの理由は、前述したとおりバイトやインターン、あとは大学の授業をやるなかで、もうちょっとこの分野を勉強したい、詳しくなりたいと思っていたから。もちろんそれは個人でも、働きながらでもできると思うけど、大学という場所と、大学院生という立場を活かしてでしかできないこともあると思った。そして、それは今やらなきゃ今後やることはないだろうなと思った。そういうわけで2回目の大学3年の10月ぐらいから大学院に行くことを決意した。

このときの手帳を読み返すと、大学院に行きたい理由として以下の３つを書いていた。

まだ働きたくない
研究興味ある
院に行って損はしないという人が多い

あと、このころから本を読むようになった。

大学4年

4年で研究室に配属されて、研究室生活がスタートした。4年生の前半は大学院入試の勉強が主だった。このころには精神は回復していて、勉強する目的が決まっていたので勉強もやりやすかったし、色々やっていたおかげで理解もしやすくなっていた。院試の勉強がてら基本情報と応用情報を取った。

外部の大学院をうけようかどうか迷ったが、結局そのまま同じ研究室で進むことにした。終わってみるとなんだかんだ良く過ごせたと思うが、違うところに行っていてもそれはそれで面白かったと思う。

研究は、それまでの勉強と違って自分でやりたいこと見つけて、調べて、やっていくという形なので自分にとってはやりやすかった。もっと早くからこの形式で大学生活を過ごしたかったと思う。大学での研究について、研究室選びの時によその研究室の助教から聞いた「研究は小学生の夏休みの自由研究を今から大学でやると考えれば良い」という言葉が心に残っている。これは的を射ていると思う。

大学院修士の2年間

修士課程に入ってからは、研究、自宅、ときどきバイトという生活を過ごしていた。研究は、2年間で国際会議2本採択されたし（ワークショップとWiPではあるが）それなりの成果を残せたと思う。もちろんサボっていた日も多かったし、もっと頑張っていれば、と思わなくもないが、そのときなりに頑張ってはいたと思う。

研究については、たぶん1人で頑張るより教授とか助教とかと協力してやる方が辛くないし成果も出ると思う。あと、せっかく高い学費と長い時間をかけて大学院に行っているので、バイトとかインターンを必死にやるより研究していた方がいいと思う。それなりの研究室なら研究補助でバイト代よりもお金が出たりするので。

修士1年の夏ぐらいからインターン含めた就活が始まっていた。自分の考えでは、1dayインターンという名の会社説明会や職場見学に行くのはよっぽどその会社に入りたいか雰囲気を知りたいかでないと無駄だと思う。また、1週間ぐらいでよくわからないグループワークをやるのもマジでメリットがないと思う。行くなら、ちゃんと職場で責任もって働けて給料が出る、ある程度長期のインターンに行った方が良いと思う。

そういう考えだったので主に外資ITのインターンに絞っていくつか応募していたが、あえなく全部落ちたので修士1年の夏休みは研究に専念していた。結果的にそのおかげで国際会議出せたので良かったが、Googleとか、Microsoftとかでインターンしてみたかったなーという気持ちは今でも持っている。

年が明けて春になると就活が本格的に始まっていた。自分は、

自社できちんとソフトウェアを開発している
できればハードからソフトまでやっていると良い
仕事が楽しそう、技術力が身につきそう

という感じの点を意識して会社に応募していた。ちゃんと応募したのは5社ぐらいで、そのうちの一つから幸運にも内定をいただけた。

修士生活を通して、やっぱり行って損はなかったなと思う。大学での研究や学会がどんなもんか知ることもできたし、自由な時間を活かして色々できたと思う。また、1人で海外旅行を計画して行けるぐらいには英語力も付き、なんとか生きて行けそうな感じがしてきている。

その他適当なアドバイス

情報系でなんかやりたいけどなんもやることないなーという人にはとりあえずAtCoderをオススメする。
- 今だとAtCoder Jobsもあるし、そこ経由で最初の開発バイトを始められそうなのは非常にうらやましい。
- もちろんAtCoderで身につくことは分野の一部分なので、興味があれば合わせて色々勉強していけばいいと思う。
- あとはIT系の就活だと足切りに使われたりもするので、ソフトウェアエンジニアとして働きたいならやっておいて損はないと思う
技術力とか、強い人達がいっぱいるけどその人達を見て自分なんか・・・と思う必要はあんまりなさそう。自分なりのペースでちょっとづつやっていければ。
ブログとか、なんでも良いのでアウトプットをしておくとたまーに役に立つし少なくとも備忘録にはなる
悩んだら1人で悩まずに昼に外に出て誰かに会うと良いと思う。1人で夜悩んでても死にたくなるだけなので。
- とはいえ最終的に決めるのは自分なので、1人でじっくり考えるのも大事
意外と適当でも生きていけます

一人でフランスとイタリアに2週間ぐらい行ったときのメモ

2019-01-30T14:09:28+09:00

1人でフランスとイタリアに行ってきたのでそのときの諸々をメモ

2018年9月にフランス、ヨーロッパに個人手配で2週間ほど旅行に行ったので、そのときのことを備忘録としてメモ。

メモなので文字が多いです。

事前準備

日程決め・予算決め

まず、どこに行くか、何をするかを決める。

自分の場合は、モン・サン・ミシェルが見たいというのが第一希望だったので、それを中心にフランス、イタリアあたりを2週間ぐらいで見に行こうと決定した。また、ツアーを使わずに個人手配で行くことも決めた。

日程は、

3泊4日パリ観光（日本からの移動日含む）
1泊2日ベネチア観光
3泊4日フィレンツェ観光
3泊4日ローマ観光
1泊2日モン・サン・ミシェル観光

という感じで、11泊13日だった。

航空券を取る

決めた日程の航空券を取る。航空券はGoogle Flightsかスカイスキャナーなどを使って調べる。乗り換えの回数とか、時間とか、航空会社とかを意識しながら乗る飛行機を決める。

自分の場合は、羽田 - 北京 - シャルル・ド・ゴールという経路で往復76920円だった。航空会社は中国国際航空（Air China）だった。

宿泊先を決める

次は宿泊先を決める。

自分は宿泊先探しにBooking.comとAirbnbを使った。

両者の比較

Airbnb
- 民泊なので、ホストファミリーがいる。よって相性がある。ホストに気を遣ったりとか、ちょっと話したりとかはする。
- 民泊なので、ホテルと比べてアメニティや清掃などのサービスなどはないことが多い
- 宿泊先を探す場合に値段別でソートできない
  - 値段ではなく、体験で選ばせようとする思想なので良いところがあれば使う
Booking.com
- UIが良く使いやすい
  - 地図で検索、値段で検索、部屋の確認とか
- セールがあったりとかして安くなることが多い
- ホテル・ドミトリーを探すならこれで間違いない

宿のタイプ比較

ホテル
- 日本のホテルと同じ感じ
- 個室、アメニティ、サービス
- 日本ほどしっかりした清潔感やサービスを期待してはいけない
- 他のタイプと比べて高い
ドミトリー
- 共用部屋に二段ベッドがいくつかおいてあり、そのうちの1つを使う形式
- タオルなどは用意してくれるところもある、がないことも多い
- トイレ、シャワーも共用
- 安い
- 同じ部屋にどんな人がくるかわからない。
- 安いので、若い人が多い。夜中に帰ってきたりする人もいる
- ホテルに比べて狭いし汚いことが多い
- 一人旅の人も多いので、話したりできる
民泊
- ホストファミリーのおうちにおじゃまして、滞在中一部屋or一軒家まるごと借りる
- 実際に会うまでお互いに相手がどんな人間かわからない
- ので、ホストファミリーとのコミュニケーションはとる（相手もそれを望んで民泊をやっていると思う）
- どれくらい話すかとか、どれくらいの距離感かとかは使ってみるまでわからない
- 現地で普段住んでいる人の感じに近い感じで滞在できる

自分の場合は、滞在した5箇所のうち、ドミトリー2箇所、ホテル2箇所、民泊1箇所に泊まった。

それぞれの感想をあげる。

ドミトリーA
- 同居人が若いグループの女性陣で、片身も狭いし場所も狭いしでわりと辛かった。
- シャワールームが狭かった
ドミトリーB
- 同居人が男性陣一人旅の人だけで、部屋も広く快適だった。
- キッチンやシャワールームも良かった。
ホテルA、B
- それぞれ日本のホテルと感覚的には同じ
民泊
- ホストファミリーのお母さんがとても優しく快適だった。
- 朝晩観光の前後に今日何する予定かとか、どこ行く予定かとか、感想とかをコーヒー飲みながら話した、割と楽しかった

荷物を用意する

旅行に持って行く荷物を用意する。一人旅なので、なるべく少なく、軽くすることを目標にする。

持って行って役立った荷物を列挙する。

スーツケース
- ハードタイプのスーツケースより、ソフトタイプの軽いやつの方がおすすめ
- バンダナなどの目印をつける
服
- 男の一人旅なので適当に
- 洗剤を多少持って行き現地で洗うことにすると量が減って良い、コインランドリーの利用も考える
現金・クレジットカード
- 紛失・盗難対策に現金は5万円分ぐらいを小分けにして分散して持っておく
- クレジットはVISA・マスターカード両方あると安心
- 限度額に注意
スマホ
- 必須、これがないと死を覚悟する
- 移動時間など暇な時用に映画をダウンロードしておく
- SIMフリーのものだとSIMを現地調達して挿すだけでネットに繋がるので楽
アプリ
- Google Map: 神。乗り換えとか、店の営業時間、評価の確認とかに使う。
  - 住所入力だとたまに実際の場所と違う場所が表示されることがある。
  - あらかじめ行く範囲のオフラインマップをダウンロードしておくと良い
- Google 翻訳: カメラ入力が便利、店のメニューを撮影して翻訳したりできる。こちらもあらかじめ現地の言語をダウンロードしておく
SIMカード
- 2週間で４GBのものをあらかじめAmazonで購入、むこうについたときに機内で入れ替え
- 地図検索とかで普段より使うので注意。自分は4GBでギリギリだった
- ホテルのWi-Fiなどが使えるときは使う
モバイルバッテリー
- スマホを酷使するので必須
- ある程度大容量の方が良いかも
電源プラグ変換器
- USB端子とかついてるタイプがあると便利
- このタイプを買った
  - 予備ヒューズとかもついてて安心感ある
ばんそうこう
- 歩き回るので靴擦れしがち
- 毎日使った
南京錠
- バッグのファスナーにつけて防犯に
- ロッカーの鍵としても使う（ドミトリーなどでは元から鍵がついておらず自前の鍵を使うことが多い）
衣類圧縮袋
- スーツケースに衣類を詰め込む用
- ちょっとした袋代わりにもなる
クリアファイル
- チケットやパンフレットとかを入れるのに一つあると便利
爪切り
- 2週間ぐらいだと気になってくるので
石けん、ハブラシ、スポンジ
- 現地で買っても良いかも、少量でもあると安心
薬
- 現地でも買えるが、正露丸やバファリンなどは少量でも持って行った方が安心

行く

準備が整ったら出発する。空港には2時間前までについていると安心

治安

少なくとも自分が行ったフランス、イタリアでは主要な観光地には警察官とか小銃もった軍人がパトロールしているので不安はない。とはいえあらかじめ行く前にどこら辺が危ないかとかのチェックはしておく

巻き込まれるのに気をつけるとしたら軽犯罪とかその辺。基本的に、日本で見かけても無視する類の人は海外でも無視すること

また、路地裏とかを通る時や人混みなどではスリ、ひったくりにも気をつける。この辺は日本でも同じだと思う

人

観光客: 同じものを見にきているので、譲り合いとか助け合いはある程度やった方がお互い幸せ
店員: 普通の店なら適当英語で伝えようとすれば相手も察してくれる、困った時とかは聞く
押し売り
- 無理やりハグしてきたり、ミサンガとかのアクセサリを無理やり付けさせたあとにお金を請求する人たちがいるので注意
- 基本的な対策としては、相手をせずに無視か、ノーといって移動する
- 乞食も同じ
- 大道芸人とかも、ちゃんと見たり相手をするとお金を要求されるので注意
  - ただし自分も楽しんだ場合は少しで良いので払った方がお互い幸せになれる
キャッチ
- 日本で声をかけられて無視するタイプのキャッチは無視する
- 下手な日本語で呼びかけてきても無視

ご飯

サンドイッチとかはその辺で売ってるので適当に買える。
店員さんは簡単な英語なら話せることが多い
- あとは欲しいものを指差したり、数を指で示したりすれば適当英語で買える。
露天とかで値切るつもりがなければ値段はあらかじめ確認しておく、値段が書いてある店に行く。屋台だとカードが使えないことがあるので注意
お腹が弱い人は生もの、水に注意（水は硬水が多いのでペットボトルの種類を調べておく）

観光地の回り方

主要な観光地だとその辺一帯の美術館に優先入場できたり、バス、地下鉄が使い放題になるパスがあるので2,3日滞在してしっかり見るつもりなら買うと良い

言葉

自分のスキル: 海外経験ほぼなし、数年前に受けたTOEIC900弱。読みはそこそこ読める、リスニングはなんとなく聞けるぐらいで決して得意ではない。こんなんでもほとんどの場面で中学、高校レベルの英語で通じる（日本の教育すごいと思った）

ホテルのチェックインとか店での買い物とかのときはあらかじめ会話をシミュレーションしておく
わからなかったらわからなさそうな顔をする、聞き直す
知らない単語が出てきたりもするので、そういうときはGoogle翻訳を使う
こっちが聞き取れなかった時の相手の会話フロー
- 普通に相手が話してくる
- ゆっくり話してくる
- 単語で話してくる（receipt? とか Ketchup？とか）
- ものを指差してくる

覚えた方が良い言葉・よく使うフレーズ

現地語のこんにちは、ありがとう、さよなら、please
can I …? （〜してもいいですか？）
can you …? （〜していただけますか）
how can I …? （〜をするにはどうすれば良い？）
Google翻訳の訳語を見せてあとはdo you know this ?とかでつなげる

一応旅行用の指差し会話帳みたいなのを買って読んでたんだけど、現地語で話そうとしてもとっさに出てこなかった。でも挨拶とか簡単な言葉でも現地の言葉が話せた方が受け入れてもらえるし喜んでもらえることが多いので読んでおいてよかった

その他

スーツケースを持ち歩いているときは少し警戒する
- ホテルに置いておく、預かってもらう
疲れたら休む
- 気疲れ、歩き疲れなど、普段より体力を使うので定期的に休む
- ベンチで座ったり、その辺で一休みするときは荷物から手を離さない、周りに人がいるところで休む
定期的に絶対になくしたくないもの（パスポート、財布とか）の位置を確認する
- なくした時にいつまでは絶対にあったかを確認するため
日本食が恋しくなる
- 味噌汁、ご飯、寿司、ラーメン、そば、うどん、牛丼、ファミチキ、カップ麺、魚、肉、焼き鳥、納豆、豆腐、ハンバーグ、天ぷら、カレー、豚汁
- 甘くないお茶、緑茶、烏龍茶、ジャスミン茶、紅茶、ほうじ茶、スポドリ、コーヒー

Brook’s Studio

ISUCON 11 予選にチーム「四年ぶり二度目」で参加した

準備

本番

反省

所感

PC環境 2021

変わっていないもの

CPU & マザーボード

GPU

NVMe M.2 SSD

周辺機器

Dell U3219Q 31.5インチ4Kモニター

USB切替器

Realforceキーボード

ロジクールMX Master 3

BenQ ScreenBar

所感

2020年に読んだ本まとめ

2020年に読んだ本まとめ

はじめに

小説

スリーピング・マーダー

ロウフィールド館の惨劇

雑学など

サーチ・インサイド・ユアセルフ――仕事と人生を飛躍させるグーグルのマインドフルネス実践法

数学で犯罪を解決する

岩田さん 岩田聡はこんなことを話していた。

コーヒーの科学 「おいしさ」はどこで生まれるのか

すし手帳

技術書・ソフトウェアエンジニア向けの本

実践Firestore

リファクタリング(第2版): 既存のコードを安全に改善する

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

テスト駆動開発

個人開発をはじめよう！クリエイター25人の実践エピソード

エンジニアとして世界の最前線で働く選択肢 ~渡米・面接・転職・キャリアアップ・レイオフ対策までの実践ガイド

新装版 達人プログラマー 職人から名匠への道

情熱プログラマー ソフトウェア開発者の幸せな生き方

ソフトウェアエンジニアとしての人生ゲームでスキルの3軸、自分の中の3人をどう育てるか

はじめに

3軸

スキルの大きさと割合

大きさ

割合

バランス型

ギーク＋ビジネスマン型

ギーク＋アーティスト型

ビジネスマン＋アーティスト型

組織構成

個人のスキルとキャリアパス

さいごに

Gradle のタスクを除外する方法

Introduction

コード例

依存も含めてそのタスクを全て除外する場合

コマンドラインオプションを指定する

settings.gradleに設定を書く

build.gradle に設定を書く

一部の依存タスクのみ除外したい場合

タスク生成時に無効化する

TaskExecutionGraph 作成時に無効化する

参考

How to exclude a task in Gradle

Introduction

Sample code

Exclude the task, including its dependency tasks

Set command line option

Write the configuration in the settings.gradle

Write the configuration in the build.gradle

Exclude the task, without excluding its dependency task

Disable when task added

Disable when task execution graph is ready

References

VPSを移動した

はじめに

Conoha で VPS を立てる

UFW の設定

fail2ban の設定

その他使うソフトウェアのインストール&設定

岩田さん岩田聡はこんなことを話していた。

コーヒーの科学「おいしさ」はどこで生まれるのか

新装版達人プログラマー職人から名匠への道

情熱プログラマーソフトウェア開発者の幸せな生き方

ピクサー流創造するちから――小さな可能性から、大きな価値を生み出す方法

FACTFULNESS(ファクトフルネス)　10の思い込みを乗り越え、データを基に世界を正しく見る習慣

地球の歩き方 B23 ペルーボリビアエクアドルコロンビア 2018-2019

パリ在住の料理人が教えるフライパンでできる本格フレンチレシピ

ふつうのLinuxプログラミング第2版

オブジェクト指向でなぜ作るのか　第2版