アルゴリズム図鑑 を読んだ

アルゴリズム図鑑 絵で見てわかる26のアルゴリズム

アルゴリズム図鑑 絵で見てわかる26のアルゴリズム

Amazonで評判が良かったので買ったけどさすがに簡単過ぎた。とはいえ非エンジニアや中高生なんかが読む本としてはなかなかいいんじゃなかろうか。

試して理解 Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識 を読んだ

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

発売されたときに買って積んでしまっていたのを今更読んだ。

感想

「試して理解」とタイトルに入っているように、実際にCでプログラムを書いたり、ターミナルからコマンドをうってLinuxの挙動を実験しながら、Linuxがどう動いているかを理解していく進めかたになっている。さすがにエンジニアになって何年もたつので「全くしらないことばかりだった」みたいなことはないけど、プロセススケジューラ・仮想記憶など知識として知っているレベルだったことも、実際にプログラムを書いて挙動を確認すると理解が深まってよかった。WEBエンジニアとしてこのレイヤーのことを意識することはそんなに多くないと思っていたものの、ちゃんと手を動かして挙動を確かめてみると自分が気づいていなかっただけでこのレイヤーのことをもっと深く知っていれば仕事でヒントになる場面は結構あったのではという気がした。

Linux環境は仮想環境などは使わずにマシン上にLinuxを立ててくれ〜とあったけど、マシンを用意するのが面倒だったのでParallel上にUbuntu立ててやりました。デバイス絡むところはさすがに難しいけど、それ以外の部分は概ね問題なくできたと思う。

自分は出てすぐ買ったので初版なんだけど、結構誤植があるようなのでこれから読む人はサポートページを確認しましょう。

gihyo.jp

次はGoならわかるシステムプログラミングを読もうと思っている。前職で輪読回やってた気がするので出ればよかったな〜

Goならわかるシステムプログラミング

Goならわかるシステムプログラミング

  • 作者:渋川 よしき
  • 出版社/メーカー: ラムダノート
  • 発売日: 2017/10/23
  • メディア: 単行本(ソフトカバー)

自分が出来ること出来ないこと2020

いまゆるゆると就職活動してるんだけど、そうすると自分のアピールポイントばっかり書いたり言ったりすることになるので、いま自分がそんなに自信がないこともちゃんと言語化しておきたいと思った。最初はできないことだけ書こうと思ったんだけど、逆に「自分はなんにも出来ない人間だ・・・・」となりそうになったので、ちゃんと自信を持ってできることも書いておく。

自信を持って出来ること

  • Ruby (Rails) / Python / Kotlin / Go / React / VueでサーバーサイドからフロントエンドまでWEBアプリケーションを1から作る / 機能追加する
    • いくつか新規事業の立ち上げもやったし、この辺の言語なら普通のWEBアプリケーションを作ることは大体できると思う
  • レガシーなコードを読み解いてリファクタリングする、モダンな技術でリプレースする
  • 決済など難易度の高い機能の設計・実装を行う
    • レガシーな決済コードをリファクタリングしつつ、新規決済方法追加とかもやったしまあいけると思う。

それなりにできること

  • GCP / AWSで普通のWEBアプリケーションが動く構成を構築する
  • Terraformで構成を管理する
    • 新規の立ち上げのときに既存の構成を参考にしつつイチからTerraformでインフラを用意したり、既存のTerraformにプルリク送ったりしたので、出来る。が、日常的に触っていたわけではないので、得意とは言い難い。仕事でやったのはECS、GAE。本番で動かしてないけどGKEも環境を作るくらいはやった。
  • クラウドコンポーネントを組み合わせてピタゴラスイッチを作る
  • Kubernetes
    • Kubernetesができるって意味不明なんだけど、仕事でPOC作ったり、フリーランスになってからGKE環境をプロダクションで動かしてるところをいくつかお手伝いしたので、Kubernetesの基本的なところ(PODとかDeployment)については分かっているつもり
  • OSS
    • OSSがそれなりにできるってのも意味不明だけど、自分のOSSを公開したり、OSSのコード読んでIssue / PRを投げるということは普通にやっている。
  • スクラム開発
    • 自信を持って…の方にいれるか迷った。スクラムで開発していったり、スクラムやってない会社でスクラム始めたりもしたので、できる…と思う。ただ凄いスクラムチームが作れたみたいな経験はないので、こちらに入れておく。

やったことない・あまり自信ないこと

  • いわゆるEM業
    • 組織のために動くみたいなことはそれなりしてきたつもりだけど、職務としてマネジメントしたことはない。
  • ハイパフォーマンスが求められるアプリケーション
    • toCで爆裂なアクセスがあるようなサービスに関わってこなかったので、経験がない。もしかしたら問題なく出来るのかもしれないけど、正直分からない。
  • 機械学習
    • 機械学習チームというところにいたけど、自分はアプリケーションやってたので出来ない。正直中身の理論的なところから全く分かってなかったので、CourseraのStanfordのやつで勉強中。
  • ミドルウェアに関する深い知識
    • アプリケーションエンジニアとして扱うもの(RDBMSとか)の表面的なAPIくらいは理解しているものの、具体的にいうとこの資料のようなレベルでその中身を理解してるとは言い難い RDBMS in Action - Speaker Deck
  • AWS / GCPに関する深い知識
    • 何をもって深い知識というか難しいけど、今まで一緒に働いたことのある専門でSREをやっていた人たちほど詳しくないのはたしか。
  • アルゴリズム等CSの知識
    • いまLeetCodeなどをやりつつ、おすすめされた本をちまちま読んでいる…
  • ネイティブアプリの開発
    • Flutter / React Nativeまでは触れたんだけど、Swiftのコードになるともはやさっぱり分からない。基本やったことない領域でもチャレンジして頑張ったけど、一度だけiOSアプリへの機能追加はギブアップしてごめんなさいした。
  • マークアップ
    • デザイナーさんのカンプをもとにそれに忠実にコーディングしてくみたいなこと。やれば出来るとは思うしやったこともあるけど得意ではない。。

こうやってまとめると、やはり器用貧乏感がある。精進します。

フリーランスとして(約)1年働いた感想

suusan2go Advent Calendar 2019 - Adventar の25日目の記事です。

TL;DR

  • フリーランスとして(約)1年くらい働いた
  • 基本的にリモートの仕事ばかりしていたので、家庭的にはとても助かった
  • そろそろどこかにフルコミットしたいと思っていて求職中です

フリーランスとしての活動

基本的に、過去に同じ会社にいた人 or その人に紹介された人、など知っている人経由でお仕事を頂いていました。折角フリーランスになったのだからいろんな現場を見てみたいなーという思いがあったものの、知り合いのいる会社の安心感には勝てずそうなってました。エージェントなども試しに使ってみようかなーと思っていたものの、幸い仕事に困ることはなかったので結局一度も使わないままです。

仕事としては以下のようなことをやりました。

  • 開発チームに入っての機能開発 (Go、React、Vue.js、 PythonRails、Flutterなど)
  • スクラムの導入と支援
  • フロントエンド環境のモダン化(Vue1.0 => 2.0アップグレード、テスト / lint 導入、Webpack移行など…)
  • PHPアプリケーションのSPA移行(CakePHP、Nuxt.js)
  • Kotlinのコード・アーキテクチャレビュー・技術調査など

アウトプットしてはこんな感じ。

suzan2go.hatenablog.com suzan2go.hatenablog.com suzan2go.hatenablog.com suzan2go.hatenablog.com suzan2go.hatenablog.com engineer.crowdworks.jp

来る仕事を拒まずに「まあ週XX時間くらいなら動けるかもですが…」みたいなことしてたら、最終的に5並列くらいになってしまい8-10月くらいは結構辛かったです。稼働時間でいうとそこまで無理していたわけではないんですが、特にレビューの仕事など稼働日決まってない依頼ベースの仕事は稼働時間自体は大したことなくても発生したタイミングで結構マインドシェアを持っていかれるので辛い。。。

めちゃくちゃ幅広く仕事させてもらってそれはそれで楽しかったのだけど、T字の-部分をめちゃくちゃに広げてる感じもあって、もうちょっと腰を据えて仕事していかないと今後の成長はないなという焦燥感がだいぶ強くなってしまいました。一応補足しておくと、これはフリーランスがだめとかそういう話ではなく、自分の仕事のとり方とか目指す方向に依存する話です。

家庭

以下の記事にも書いたのだけど、子供二人の育児と家事は本当に大変で、フリーランスとして働いてないとなかなかキツかっただろうなという感じがします。

suzan2go.hatenablog.com

週一くらいでMTGやオフィスに出社して仕事してましたが、それ以外は基本的にリモートで仕事させてもらっていました。特に今年は3ヶ月に一回くらいのペースで、上の子が風邪 => 下の子が風邪 => 妻が風邪 => 自分が風邪 のようになることが多くて、普通にフルタイムの仕事してたら有休が足りなくなっただろうなと思います。

あと最初は家で仕事してたんですが、3歳にもなると上の子は自分の仕事部屋にもガンガン突撃してくるし、妻からは「上の子の突撃を止めるのが大変なので、家で仕事しないでほしい」と言われてしまって、9月からはみなとみらいのWeWorkにデスクを借りて仕事しています。できるだけすぐに家に帰れる、ドア2ドアで30分以内(自宅が駅から徒歩15分程度)の場所を探して、設備とかサービスを鑑みてWeWorkにしました。WeWorkは拠点によってだいぶ価格に差があり、東京は特に高いのですがみなとみらいの拠点は相場からはちょっと高いくらいの値段で借りられます。

入居とあのCEOが辞めたりしたゴタゴタのタイミングが重なって情弱認定されそうだたったので、なかなか大っぴらに言えなかったw

今後 & 求職情報

上にも書きましたが、そろそろ腰を据えて仕事していかないと、今後の成長はないなという焦燥感がだいぶ強くなっています。思えば前の会社に転職して入ったときには「WEBエンジニアとしてどこでもやっていける力」みたいなものを欲していて、いまはまたちょっと軸が違うんだろうなと。分かりやすくいうとEM / SRE /PdM みたいに今までとちょっと仕事を変えてやっていく、、、とかWEBサービスのレイヤーでないソフトウェアを書く、、、など。あと少し前はスタートアップしか考えてなかったんですけど、今は大企業の内製IT部門とかDXの専門子会社とかでも面白そうだなーとか。。。ただ何れにせよ次は長期間フルコミットする前提で選びたい気持ち。

という感じでまだあまり方向性定まってないんですが、もし私に興味があるよという方いればお気軽にご連絡ください。

IntelliJ Plugin 「kotlin-fill-class」の現在

この記事は suusan2go Advent Calendar 2019 - Adventar の12日目の記事です。

kotlin-fill-classとは

自分が趣味で作っていたIntelliJ IDEAのPluginで、Kotlinのコンストラクタを(実は今は関数の引数も)シュッと補完してくれます。

suzan2go.hatenablog.com

実際に見ていただくとどんなものか分かるかと思います

https://user-images.githubusercontent.com/8841470/59397528-e61a4380-8dc7-11e9-9684-d82d225316fe.gif

Kotlin Festのなかでも発表させていただきました。

公開されたあとも地味に色々と機能が追加されているので、このブログではその紹介をします。

kotlin-fill-classの現在

独自クラスでも再帰的にコンストラクタを埋められるようになりました

これまではInt, Stringなど組み込みの型については自動で埋められていたものの、 例えば以下のようなValue Objectを用いたユーザー定義クラスの型は値を埋めることができませんでした。

data class UserName(val value: String)

data class UserId(val value: Int)

data class User(
        val id: UserId,
        val name: UserName
)

user = User(id: , name: ) // fill constructorしても値は空欄になってしまっていた。

それが、現在は以下のように再帰的に独自クラスのコンストラクタも呼んで値を埋められるようになりました。

non empty

以下のプルリクで対応されました。

github.com

関数の引数も値を埋められるようになりました

kotlin-fill-class という名前の通り、もともとはコンストラクタをターゲットにしていましたが、なんと現在は関数にも対応しています。

function

以下のプルリクで対応しています。

github.com

もはや kotlin-fill-class という名前でいいのかという感じになってきましたが、なんかいい名前ください。

import分も自動で追加されるようになりました

これはコンストラクタにユーザー定義のクラスを含んでいた場合に、自動でimportされるようになりました。 github.com

テストが追加されました

ユーザーからすると関係ありませんが、テストが追加されました。以下のプルリクでCircleCI回していますが、テスト書いてくれたのは @t-kameyama さんです。

github.com

その他

補完されても嬉しくない箇所で補完されていた箇所など、ちょっと使いにくかったところが改善されています。

github.com

github.com

謝辞

プルリク見ていただくと分かりますがこの辺の大きな機能追加や細かな改善は自分ではなく、@t-kameyama さんという方がやってくれています。もはや自分のコードは殆ど残ってなくて、自分がやってるのはIdeaのバージョンがあがったときに動作確認してプラグインの依存を上げるのと、チェンジログを書いてJetBrainsに公開するくらいです。@t-kameyama さん、PR頂いたときにお礼を言うくらいしか出来てませんが本当にありがとうございます!!!!!

@t-kameyama さん以外にも、 IntelliJがアップデートされたタイミングで「サポートしてくれーーー」ってIssueを上げてくれる人や、プルリクを上げてくれる人がいて嬉しい限りです。顔も名前も知らない、なんなら国も違う人が自分の作ったものをガンガン改良していってくれてるの、凄い。普段利用者としては正直あまり意識していないけど、OSSってすげーなとPRやIssueもらうたびに思います。

残念ながら最近は仕事でKotlin書いていないので機能面での改良はなかなか思いつきませんが、今後もほそぼそとメンテナンスしていきます。今後ともkotlin-fill-classをよろしくお願いいたします。

ソフトウェアファーストを読んだ

この記事は suusan2go Advent Calendar 2019 - Adventar の11日目の記事です。

古巣のインタビューが乗ってることもあり、ソフトウェアファーストを読んだ。

ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略

ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略

感想

一般的なWEB企業で働いた経験のあるものからすると、そこまで真新しいものは無いかもしれない。自分がSIerにいたときにこんな本が読めたらもっとがんばれたかもなーと思った。この本の主題とはちょっと外れることかもしれないけど、自分はエンジニアの組織やキャリアに関する話で結構考えさせらた。

ソフトウェアエンジニアのキャリア

ぽつぽつとTwitterにも呟いたのだけれど、主にこのあたりの話

本から引用するとこの辺りとか

同期の2人が同じ時期にスタートを切って、Aさんはエンジニア(スペシャリスト)の道を選び、Bさんは途中からマネジャーに転向したとしましょう。マネジャーは担当する組織の大きさに比例して貢献度を図れるので、Bさんは組織規模が大きくなるのに合わせて収入も増えていきます。一方、エンジニアのAさんはどうなったでしょう?自分もマネジャーのBさんと同じくらい評価されたいですし、年収もほしいと思っています。100人の部下がいるマネジャーのBさんと同じくらい評価されるにはどうすればいいでしょう 及川 卓也. ソフトウェア・ファースト (Japanese Edition) (Kindle の位置No.4013-4018). Kindle 版.

この辺りとか

エンジニアの純粋な(狭義の)技術力が右肩上がりで成長し続けることはまれで、どこかのタイミングで鈍化するのが普通です。ここで言う純粋な技術力とは、コーディングスピードであったり、コードの品質であったりします。もちろん技術の幅を広げるという方向性もありますが、いずれもどこかで一次関数的な成長は難しくなり、技術的な成長が高止まりしたままだと評価も停滞を余儀なくされます。 及川 卓也. ソフトウェア・ファースト (Japanese Edition) (Kindle の位置No.4018-4021). Kindle 版.

これは、「だからこそスペシャリストとなる人間が何をもってエンジニアリングマネージャーやプロダクトマネージャーと同等とみなせるのか定義しておく必要がある」という文脈での話ではあるんだけど、「自分はいまT字型の- の部分をめっちゃ広げている感じになってしまっている」と自覚しているので、余計に来るものがあった。

何かを深く掘っていくか、はたまたエンジニアリングマネージャーやプロダクトマネージャーといったところに行くのか、まだ何も決めていないけどこの本を読んでから次の方向性を探しにいっている。

VSCodeからWebStormに乗り換えた

この記事は suusan2go Advent Calendar 2019 - Adventar の10日目の記事です。

最近のサーバーサイドの開発ではほぼJetBrainsのIDE (RubyならRubyMine、GoならGoLand、PythonならPyCharm、サーバーサイドじゃないけどFlutterならAndroid Studio)を使うようになったものの、フロントエンドだけは別でVueやTypeScriptのサポートの厚さからVSCodeを使い続けていました。しかし、一つだけショートカットの違うエディタを使うと結構生産性が落ちるのと、リファクタリングの機能はJetBrains製IDEの方にかなり軍配があがるので、関わっているプロジェクトのコードのリファクタリングを考えるタイミングで乗り換えることにした話です。

WebStormに乗り換えるにあたっての設定

自分はフロントエンドだけかけばいいときはWebStormを立ち上げてますが、PHPStormでもRubyMineでもJS書く環境は同じようにサポートされています。このセクションのタイトルも便宜上WebStormになってますが、以下の設定などはWebStormじゃなくてもほぼ同じです。

ESLint設定

ESLintはIDEに組み込みで入っています。プロジェクトにESLintが設定されていれば特になにもしなくてもいい感じに設定されるはずです。 f:id:suzan2go:20191211121218p:plain

Prettier設定

Prettierはプラグインとして提供されています(WebStormならデフォルトで組み込み)。ただこのプラグイン単体では、 Format on Save は提供されていないのでFileWatchersと組み合わせることになります。 f:id:suzan2go:20191211121814p:plain

FileWatchersもプラグインとして提供されており(WebStormならデフォルトで組み込み)、これとPrettierのプラグインを組み合わせることで Format on Save が実現できます。こうかくと結構面倒そうに感じるんですけど、実際にはFileWatchersの追加からprettierを選んで対象のテンプレートを選択するだけなので楽ちんです。

f:id:suzan2go:20191211122701p:plain

f:id:suzan2go:20191211122612p:plain

注意としてデフォルトではScopeが Project Fiels になっていますが、Recently Changed FilesCurrent File にしておくと良いでしょう(ビルドしたJSとかを全部フォーマットにしにいって重くなることがある)。

Vueサポート

これが一番心配だったんですけどちゃんとVueプラグインが提供されています。最初にpublishされたの Feb 03, 2017 だから結構前からあったのか知らなかった……

plugins.jetbrains.com

VSCode向けのプラグインであるVeturがかなり高機能だったので心配してましたが、ほとんどストレスなく開発ができています。 github.com

乗り換えてみての感想

直近Vueを書くときにつかっていたので、Vueでの感想が中心です。

補完とジャンプが強い

VSCodeでもコード補完とジャンプは出来てましたが、WebStormの場合のほうがやはり強力で型で引けない場合にも候補を出してくれるのはかなり強いです。VSCodeと比べても、Vueのシングルファイルコンポーネント <template> 内の補完が快適で驚きました。

VSCodeの場合、data() 内の最初のキーまでしか補完してくれなかったんですけど(自分の環境だけ?)、オブジェクトの中身についてもちゃんと補完を出してくれています。

f:id:suzan2go:20191211125212p:plain

またコンポーネントのpropsについてもちゃんと補完が効いています(これはVSCodeも同じ)。

f:id:suzan2go:20191211125703p:plain

リファクタリングがやりやすい

リファクタリングがめちゃめちゃやりやすくなりました。Vueのコンポーネントファイルの中にベタで書いていた関数を外部ファイルに移す、1ファイルにまとめて書きすぎた関数を別ファイル分割するみたいなことが簡単に実現できるので、ファイルの整理が捗るようになりました。もちろんちゃんとそれらを呼び出していたファイルでもimportパスの変更などは自動で追随してくれます。

f:id:suzan2go:20191211130205p:plain

computed の関数名をリファクタリング機能で変更するとテンプレート内にもちゃんと反映されますし*1VSCodeで触っていたときよりもリファクタリングの面倒さが格段に少なくなりました。

複数のショートカットキーを覚えなくてよくなった

これはめちゃくちゃ個人にしか当てはまらない感想ですが、VSCodeとJetBrains系IDEを行き来していたときによく脳内でショートカットキーがコンフリクト起こしていたのがなくなったのは地味に大きかったです。特に直近はVSCodeを触る機会がフロントエンド触るときだけに限定されたこともあって、久しぶりにVSCode側を触るときに基本的なショートカットキーが思い出せなくてググったりしていたので……

良くなかった点

いいところばっかりだとステマっぽいので微妙なところも書いておくと、やはり立ち上がりがVSCodeに比べると遅いです。ちょっと何かを編集するみたいな用途に立ち上げるのは向いてないです。自分は今までもそういうちょっとした変更ではVimを使っていたので特に困ってないですが。 あとは最新のAPIに対応していない場合もあるようで、Vue内の v-slot:hogehogeシンタックスハイライトがうまくいっていませんでした。また自分は試してませんが、レビュー を見ると、Vue Composition APIにまだ対応してないようです。 https://plugins.jetbrains.com/plugin/9442-vue-js/reviews#review=35618

まとめ

これでアプリケーションコードを書くものは全てJetBrains製品となりました。フロントエンド書くならVSCodeでしょ!と特に試しもせずに思っていましたが、有償のIDEだけあってJetBrains製品もなかなか良いです。

*1:残念ながら完璧ではないですが……