2018年振り返り(9月〜12月)
9月
- 屋久島にいった
退職した開放感によって大変気が大きくなっていた私は、単身屋久島に渡った。
正確には、
福岡で一泊、
鹿児島で一泊、
屋久島で二泊、
鹿児島で一泊、
実家に一泊
というかなりの長旅だった。
旅の目的は、九州で一番高い山に登ること。
屋久島ではなぜかオーストリア人のErichと仲良くなり、二日間ずっと一緒にいた。
国内旅行なのにずっと英語を喋っていた。
Erichの言っていることは半分くらいしかわからなかったけど、
山を登りながら侍になりきりちゃんばらごっこをしたのは良い思い出だった。
「NANIYATSU」
「HARAKIRI」
とか言っていた。
他の旅行客には通訳だと思われていた。
10月
- 新しい場所で働き始めた
新しい場所での勤務が始まった。
ここから先は楽しいことしかなかった。
というと嘘になる。業界も変わった。使う技術も変わった。
それ故に苦労もした。
でもそれが意味のある苦労だとわかっていれば頑張れるように、
人間はできているんだと思う。
それと、一緒に働きたいと思える人たちと働けるだけで
こんなに救われるなんて思わなかった。
前の職場にいた自分に早く教えたかったよね。
- 技術書店に出た。200冊売れた
デザインパターンなのに、エモい。
という技術書の亜種みたいな本を出した。
書くのはすごく大変だった(あとがきに産みの苦しみが書かれている)
多分こんなアホな本を出したのは自分くらいだと思うけど、
なんだかんだ読んでくれる人がいて、面白がってくれる人がいて嬉しかった。
- Wantedlyに投稿した記事がバズった
Wantedlyにしては珍しい、求人小説。
安易に画像に頼らず文章力のみで勝負した硬派な作品(だと思っている)
11月
- 引っ越した
都会の喧騒から逃れたくて、会社から遠くなるのに引っ越した。
友だちもいるし、とても平和な場所だしでかなり満足している。
引っ越し前日に東京に来てからずっとお世話になっているバーで呑み、
帰ろうと思ったら、
「まあ最後だしね」とか言いながら
常連とマスター合わせて計6人がドヤドヤ家に上がり込んできて、
酒盛りをしだした。
解体されていなかった僕のベッドは彼らの手により解体された。
酒盛りによって出たゴミは引越し先に送った。
12月
- 忘年会を家で開いた
僕が常駐しているmastdonであり、
QiitaのアカウントでログインできるQiitadonというmastdonがある。
そこにいる人達と忘年会をした。12人もいた。
家電が増えた。調理器具が増えた。
意味わからないくらい面白かった。
そして現在
正月を待つばかり。
いろいろな反省と目標は、新年のポストでかこうかな。
今年もいろいろな人におせわになりました。
ありがとう。
2018年振り返り(1月〜8月)
今年はいろいろな動きがあった年でした。
1月〜8月
9月〜12月
で大きな動きがあったので、分けて書いていこうと思います。
1月
- 記憶がない
2月
- 初めてQiitaの記事がバズった
個人ブログでは50pv/dayくらいしか読まれていなかったのに、
10,000pv/day という爆発を見せた。
深夜に思いつき、そのテンションで90minほどかけて書いた記事だったので驚いた。
拡散されていく記事。
どんどん跳ね上がるpv数。
制御不能、とはこのことをいうのかと思った。
全然知らない何処かの誰かが、僕の記事を読んでいる。
それは不思議な感覚だった。
- 会社に社員が一人増えた
僕よりも5つくらい上の上司だ。
ずっとSESで働いていた人らしい。
今後、この上司との人間関係がいい感じに悪化していくことになる。
3月
デート商法詐欺にあった。マンションを買わされそうになり、楽しかった
彼女と別れた
上司に素敵な言葉をいただいた
楽しかったら仕事じゃないよ。
自分のための仕事は仕事じゃないよ。すべてはお客さんのためだよ。
4月
またQiitaに記事をあげた。
つるのおんがえしとlinuxの親和性の良さがわかった。
5月
- 上司に素敵な言葉をいただいた
そんなんじゃ、技術者としてやっていけないよ
- エクセルで仕様書を書くようになった
スクリーンショットの撮り方が日に日に上手くなっていった。
- いろいろなことが禁止にされた
Angularの禁止
Webpackの使用禁止
新しい技術書購入の禁止
1つ禁止されるごとに、翼がもがれていくような思いがした。
- 副業を始めた
自分の市場価値に危機感を感じ始めた。
ちょうど東京きてからずっと付き合いのある飲み友達から誘われたので、
ベンチャー企業でVue.jsを書くようになり始めた。
- Vue.jsミートアップでLTをした(この時Vue歴3週間)
www.slideshare.net
会場はざわざわしていた。
6月
- Qiitaに記事をあげた
初めて1,000いいねをもらった。
以降、さらに良いものを書かなくては、というプレッシャーでスランプに陥る。
- 上司から素敵な言葉をいただいた
なんで書くまでに時間がかかるの?
設計?しなくていいでしょ
まず処理を書いてから、少しづつ関数化していくのがいいよ
だからまず書くことだよ。初めから設計する必要はないよ
JavaScriptってDOM操作しかできないんでしょ?
7月
- もう一人の上司に、8月末でやめたいと伝えた
次行くところの方が楽しそうだね。頑張ってこい
楽しくないところで働き続けるのは辛い。
8月
- 怒涛の引き継ぎ資料作成が始まる
スクリーンショットを取り、Wordに貼り続ける作業の毎日。
cd と入力
スクリーンショットぺたり。
enterキーを押下
スクリーンショットぺたり。
ディレクトリがxxなことを確認する
スクリーンショットぺたり。
上司はこういっていた。
猿でもわかる資料を作ることが大事だよ
猿と働きたい人なんているのだろうか。
それでも僕はスクリーンショットを取り続けた。
1枚貼るごとに、人間としての尊厳を少しづつ失っていく気がした。
生物学上、人間の進化は終わっているのだとどこかの本で読んだ。
それは本当かもしれない。
でも、人間はいくらでも退化できるらしい。
退職まで、あと少し。
〜つづく
ログ解析で用いられるElasticsearchとはなんなのか
いきさつ
Elasticsearchについて「大量のデータをスピーディーに解析する」
くらいしか理解できていなかったので、整理することにした。
ただし、今回は「ログ解析」という観点に絞って整理する。
ログ解析の一般的な構成
おもにログ収集、ログ集積、ログ解析の3つの要素から構成されることが多い。
具体的には以下の通り。
ログ収集
- Fluentd
- Logstash
- Apache Flume
ログ集積
ログ解析(可視化)
- Tableau
- Kibana
- Grafana
ElasticSearchはログ集積にあたる。
ElasticSearchを一言で
スケーラビリティに優れた全文検索エンジン。
用語をざっくり理解
Elasticsearch | リレーショナルデータベース |
---|---|
Index | データベース |
Type | テーブル |
Document | レコード |
実際に動かしてみる
インストール
$ wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.5.0.tar.gz $ tar -xzf elasticsearch-6.5.0.tar.gz # 日本語で全文検索をするためのプラグインを入れておく $ bin/elasticsearch-plugin install analysis-kuromoji
起動
$ bin/elasticsearch
にアクセスして、以下のようにjsonが表示されればOK。
{ "name" : "lzmX37g", "cluster_name" : "elasticsearch", "cluster_uuid" : "gs4RKJXHTj6XSHeQmn_irw", "version" : { "number" : "6.5.0", "build_flavor" : "default", "build_type" : "tar", "build_hash" : "816e6f6", "build_date" : "2018-11-09T18:58:36.352602Z", "build_snapshot" : false, "lucene_version" : "7.5.0", "minimum_wire_compatibility_version" : "5.6.0", "minimum_index_compatibility_version" : "5.0.0" }, "tagline" : "You Know, for Search" }
Indexを登録
基本的に操作はREST方式で行います。
Indexを登録
- リクエスト
PUT /library/books/1
{ "title": "Norwegian Wood", "name": { "first": "Haruki", "last": "Murakami" }, "publish_date": "1987-09-04T00:00:00+0900", "price": 19.95 }
- レスポンス
{ "_index": "library", "_type": "books", "_id": "1", "_version": 1, "result": "created", "_shards": { "total": 2, "successful": 1, "failed": 0 }, "created": true }
取得
- リクエスト
GET /library/books/1
- レスポンス
{ "_index": "library", "_type": "books", "_id": "1", "_version": 1, "found": true, "_source": { "title": "Norwegian Wood", "name": { "first": "Haruki", "last": "Murakami" }, "publish_date": "1987-09-04T00:00:00+0900", "price": 19.95 } }
検索
- リクエスト
GET /library/books/_search
{ "query": { "match": { "title": "fox" } } }
- レスポンス
長いので省略。
まとめ
わかったこと
Elasticsearchはログ集積に使用される
操作はRESTに則っている
kibanaと組み合わせて使うことができる(使ってみたけどまだ使いこなせていない)
まだわかっていないこと
ログ収集するときは、ログを持っている各インスタンスからElasticsearchのエンドポイントを叩く感じになるのだろうか
そのために必要なのがログ収集用のソフトなのかな
どうやってスケーラビリティを高くしていくのか、具体的にわかっていない
参考サイト
Qiitadon忘年会まとめ
日曜日なのにQiitadonが早い
今日はQiitadonの非公式忘年会だから
ホテルニュー淡路
はやすぎるひとたち(集合は16:00)
駅集合なのに早く着きすぎて、ファミレスで開かれる0次会
痛む、なのやつの古傷
足りないまな板
かろてん宅到着。直後のっとられたアカウント
LTL読み上げライブ開始
買い出し
カーテンがない
ボウルがない
いろいろない
でもオーブンレンジはある
さっき買ってもらった
でもカーテンがない
ウォーターサーバーはある
でもカーテンがない
突然始まる工事
なのやつのかつやく
かりてきたねこ
なべ(おいしい)
全ての話の落とし所に使われるカーテン
https://qiitadon.com/web/statuses/101284899848528333 qiitadon.com
ふかまるなのやつ氏
全部俺アプリ
おわらない忘年会
たのしかったようでなによりです
つづく
後遺症
babelで現在のnodeJsのバージョンに合わせてトランスパイルする
** あとで少し追記する
babelのinstall
yarn init -y yarn add @babel/cli --dev yarn add @babel/core --dev
コンパイルするソース
class Hoge { constructor() { } } const hoge = new Hoge();
コンパイル
何も入れず、そのままコンパイルしてみる
yarn run babel index.js
class Hoge { constructor() { } } const hoge = new Hoge();
そのままでてきた。
@babel/preset-envを入れてみる
今まではbabel-preset-es2015など、 トランスパイルするときに参照する仕様をパッケージに追加する必要があった。
しかし、@babel/preset-envを用いれば、 実行環境に合わせて勝手にパッケージを追加してくれる。
また、ブラウザを指定した変換ができたりする。
今回はnode上で動くようにトランスパイルするので、 .babelrcを以下のように指定。
yarn add @babel/preset-env --dev
{ "presets": [ [ "@babel/preset-env", { "useBuiltIns": "entry", "targets": { "node": "current" } } ] ] }
dockerのコンテナを削除する〜サブシェルについて〜
いきさつ
とまっているDockerコンテナを全部削除したい。
と思って方法を調べたら「サブシェル」という技術を知った。
方法
$ docker rm $(docker ps -aq)
解説
( )
( )でくくった処理はサブシェル内で実行する。
親シェルの環境変数を汚したくないときに使う。
$( )
$( )内の標準出力を値として得ることができる。
$ echo $(ls) Applications Desktop Documents Downloads Dropbox Library Movies Music Pictures Public
これを引数として渡すことができるのか。
releaseブランチを導入するメリットについて考える
背景
masterブランチとdevelopブランチ、
それとfeatureブランチで開発しているケースを考える。
developからfeatureブランチを生やして、featureの開発が終わったらdevelopにマージ。
developにマージしたものをリリースのタイミングでmasterにマージ。
それを本番環境にリリース。
問題
リリースに伴い、コードの細かい修正を行うことがある(リリース作業と呼ぶことにする)。
それらのリリース作業と開発作業が並行して行われるとき困る。
リリース作業内容も開発作業内容もdevelopにマージされるので、
それをmasterにマージしてリリースすると、開発途中のものまでmasterにマージされてしまう。
まだリリースしたくない機能があるのにリリースされてしまったりするよ。
解決策
開発用のブランチとリリース用のブランチを分ける。
リリース作業に入った時、developブランチからreleaseブランチを切って、
それに対してリリース作業のコミットをする。
リリース作業が終了すればmasterにマージする。
(さらにdevelopにもリリース作業の内容を反映させるため、マージする)
メリット
リリース作業中でも、developブランチにプルリク&マージができるので、
作業が滞らずに進む。
リリース作業中の開発内容が本番環境にリリースされることがなく、安全。