続・転職に向けて

このご時世、自分の身に危機を感じております。
出社の危険性が高いので再び転職を考え始めました。

一人暮らしならいいんですけど、実家暮らしなので家族に何かあったら嫌なので。

以前コーディングテストを受けたとき
それはもうひどい点数を取ったので（もちろん落ちた）勉強しようと思いました。

最近LeetCodeを始めてみました。
https://leetcode.com/problemset/algorithms/leetcode.com

時間を縫ってちまちま進めていきたい。

本もいくつか積んでるので読んでいきたい。

これの電子版を買いまして peaks.cc

あとこれも買った techbooster.booth.pm

今だとこれを待ってます peaks.cc

最近睡眠の質が浅いのか
すごく疲れてるのでよくない。寝よう

おやすみ。

「完全SIer脱出マニュアル」読了

あけおめ～～～

新年早々なんやかんやありまして、また転職活動を続けることになりました。

転職活動ということで、前々から気になっていた本を１冊読みました。
今年から読んだ本はブログに書き残そうと思って筆を執った次第です。

読んだ本はこちら

books.rakuten.co.jp

本の名前をtwitterで見たことがあったのと
本屋で見たときの名前のインパクトが強くて頭に残ってたんですよね
（このご時世なのでしばらく本屋に行ってませんが・・・）

さてさて本のご紹介。新書程度の量なのでサクッと読めました。
書いてあったことは軽くまとめるとこんな感じですね

各項目の内容と、軽い感想を込みで書いていきます。

SIerが転職する背景の話

悪い意味でのSIerで心をすり減らしながら働くのってどうなん？って話。

こんな地獄もあるんだなとちょっとぎょっとしました。
僕は今の会社だと２年働いて１年半はAndroid開発できたので、だいぶ恵まれてましたね。

働く環境の話

自分にとってどういう環境が働きやすいのか。
もし今の会社に所属しながら環境を変えられるならそれでもいいんじゃない？って話。

これ大事ですよね。わりと上に持ち掛けたらどうにかなったりするんですよねこれ。
直談判して解決する可能性が少しでもあるのならば
勇気だして当たって砕けろくらいの気持ちで動くといいです（体験談）
失敗してもなんだアイツってなるだけなので

あとはIT業界ってどういった働き方があるの？って話がちょいちょい。
自分のキャリアだと働いているとこって２つ（うち１つは非IT）なので参考になりました。

自分がどういった環境下だとパフォーマンスが出るのかなって見直せました。

転職するための下準備・面接の話とか

心壊すくらいなら今すぐ辞めた方がいい！って話が冒頭に出てくるのですが
これはマジです。みんな気を付けましょう。僕もそうだったし、知り合いが何人かやられてます。

あとは内容としては

• インプット・アウトプットするために
• 転職サービスやエージェントの利用について
• 履歴書と職務経歴書
• 面接や企業とのマッチのノウハウ

ざっと読んで、転職するための下準備を見直す感じですかね。
僕自身は「まぁそんなもんだよな」くらいの感覚で読みました。

ただ、「技術のインプット」の話にちょっと問題があるかなと・・・。
これは後で書きます。

キャリアの話

IT業界で働く際にはこんな企業・業種があるよーって話ですね。
本当に触りだけ書いてあるのでそんなに参考にならなかったかな。

楽しく働くために

自分のキャリア含めてどうしたら良い方向に進めるかなって話。
長い目で見た時、何ができるようになればいいかなという指針というかそんな感じ。

< 総評 >

「マニュアル」というよりは「アドバイス」って感じの本ですね。
本当に基本的なことは書いてあります。
この本だけでは解決はしないので、これをベースに必要な情報を仕入れる必要があります。
何もわからないよ！って人には最初の一歩の指針になると思いました。

良い意味で全体的に広く浅くって感じでした。
肝心なとこがもうちょっと深掘りされていればなぁって本でした。

ただ、前述した通り「技術のインプット」に関しての記述には賛否両論だなと感じました。

何も分からん人がどうやってまずは何でインプットしたらいいの？という答えに

1. 技術系のポッドキャストを聞いてみる
2. Railsチュートリアルをやってみる

Railsについては正直なところあんまり同意できませんでした。

ひとまずRailsチュートリアルみたいなの良くないと思うんですよね・・・。
（Railsを否定しているわけではないですよ！）
この辺はいろんな人が記事を書いていると思うので詳しくは語らなくていいや。

分かってる人が読めば「まぁそういう選択肢もあるよね」って感じだとは思うんですけど。
安易にこれってお勧めするのって結構危険だと自分は考えてます。

人によって異なるから難しいんですけど
技術への興味の持ち方のノウハウとかとかを書いていればなー、と思いました。

そういえばつい最近この記事を読んだんですよね。

qiita.com

Railsチュートリアルやって、スクール通って
この記事のようなコンボが完成する可能性があって怖いなって思いました。

僕個人としては、面白そうだなって思ったのを自分でいくつか試してみて
そこから「一番興味がわいた〇〇をもうちょっとやってみよう」みたいな感じの方がいい気がします。

だいたいチュートリアルなんてどこにでもあるし（英語だけど）
本とか買うと１冊きちんとやろうってなるのでいいと思います。

明日からアルゴリズムのお勉強します。

Kotlinをちまちまやり直してる

ちまちまやり直す

基礎的なやつ

// デフォルト引数つきで簡単に関数書く
fun add(i: Int = 0): Int = i + 1

// 再起呼び出し
fun sum(numbers :List<Int>): Int = 
    if (numbers.isEmpty()) 0
    else numbers.first() + sum(numbers.drop(1))

fun main() {
    // "1 add 0 = 1"（関数だけ呼び出すとデフォルト引数が参照される）
    println("1 add 0 = " + add())
    // "1 add 1 = 2"（ふつう）
    println("1 add 1 = " + add(1))
    
    // "sum = 6"
    println("sum = " + sum(listOf(1, 2, 3)))

    // 関数をオブジェクトとして扱う
    val functionAddDefault = ::add
    // "functionAddDefault = 1"
    println("functionAddDefault = " + functionAddDefault(0))
}

ラムダ式と無名関数

fun main() {
    // ラムダ式の例
    val squareA: (Int) -> Int = { i: Int -> i * i }
    // "squareA(1) = 1"
    println("squareA(1) = " + squareA(1))

    // ↑ を省略
    val squareB = { i: Int -> i * i }
    println("squareB(1) = " + squareB(1))
    
    // 引数が１つならitで呼べる
    val squareC: (Int) -> Int = { it * it }
    // "squareC(1) = 1"
    println("squareC(1) = " + squareC(1))

    // 無名関数を利用 returnが使える
    val squareD: (Int) -> Int = fun (i: Int): Int {
        return i * i
    }
    // "squareD(1) = 1"
    println("squareD(1) = " + squareD(1))

    // ↑ を省略 returnが使えない
    val squareF: (Int) -> Int = fun (i: Int) = i * i
    println("squareF(1) = " + squareF(1))
}

忘れるという話

今週は天候ぐちゃぐちゃで全然きちんと寝れなかった
だるーん、つかれたーん

最近仕事でAndroid開発してないので
空いた時間で今までやってきたことの復習をしてるんだけど

結構色んなこと忘れてる
やばい、あと結構ショック受けてる

１回実装したっきりのやつとか完全に忘却してる
仕事でAndroid担当外れて２ヶ月くらいでこれか

ちょっと前に久々にKotlin書いたら
エルビス演算子の書き方忘れてたんだよね

やべーよやべーよ
面接でコーディングあったら確実に即死する

今週は身体だるいしやること色々積もって死んでたけど
連休で挽回しないとまずい

今までと、これからのこと

おかげさまで転職ドラフトで自身の過去最多指名を頂きましたーん

そのうち職務経歴書を書かないといけないので
今まであったこと&思ったこととか整理したいので書き残す

あとは個人的には、転職ドラフトの指名体験記書いてる人って
「学生時代はベンチャーでインターンしてて～」とか「OSSコミッターでした～」とか
指名されるの当たり前じゃねーか！みたいな人ばっかだったので
こういった話に需要がないかなーって感じでのんびり書いてきます

おちこぼれの這い上がり経験談です
前半はプログラミング関係ないです

学生時代

高校は全科目ほぼドベ。でも数学はマジで死ぬほど大好きだった
プログラミングの勉強ができたらいいなってなんとか情報系の大学へ進学した

大学でも勉強はからっきしで、とにかく人から教わるのが苦手
今そこにあるものの理論の根っこが気になって仕方がないのですぐに物事を覚えられない
（でもこの考え方がプログラミング的には有用かも）

自分に見合ったやり方じゃないと
勉強ができないということにようやく気が付いたのはつい最近

プログラミングの実力に関しては、情報系大学出身とは言えないレベルだった
研究もお粗末だった。よく卒業させてもらえたな・・・

社会人１年目

めちゃくちゃでっかいメーカー企業
エンジニアで入ったはずがなぜか品質保証部になった

過去にブログで書いたように色々ありすぎた
この経験があったから、身体を壊すような働き方をしないと一生誓った

身体を壊して１年たたずに退職

無職１年目

数ヶ月療養してからはしばらく遊んでた
幸いにもお金を全く使ってなかった上に実家住まいだし貯金はあった

興味があったWebとか（今ではもう役に立たない知識ばかりだけど）触った
あとはラズパイとかで無意味な鯖立てたりした

無職２年目

どうせならやりたかったことをしようとゲーム会社を目指してみる
結論から言うとこの就活には失敗した

Unityで半年ちょっとでゲームを作った
ついったーのもーめんと
"作ったゲームのzipリンク（クリックでダウンロードが始まります）"

このとき一人で開発してた経験がめちゃくちゃ役にたってる
一人でものを１つ完成させることの大事さを知った。完成は正義

コーディングのアンチパターンを踏みまくって開発したので
何をしたらダメなのかを身をもって実感した

溢れかえるグローバル変数
１つのメソッドに大量の処理が書き込まれ
１つのクラスに様々な機能が盛り込まれ
めちゃくちゃな命名規則に始まり
複雑な条件分岐が構成され
〇〇フラグが大量に散在し
次の日には見たくないようなコードが生成された

マジで全部踏みつくした

再就職の活動には失敗し、貯金も底をつき
病院や年金が財布を襲い、どこでもいいから就職しないとって感じで
ひとまず働けるとこをって就活し始めた

再就職

なんか勉強意欲あるし、Javaちょっとやったことあるんでしょ？
って感じでAndroid開発にまわされた

給料は一般の新卒くらい
前職よりちょっとあがったけど賞与ないし見込み残業だったからトントン

入りたての頃

開幕Android担当が３人⇒２人になった
もちろんマニュアルなんてあるわけもなく、仕様も分からず
コードを片っ端から泣きながら読んでった。Javaを復習した

Kotlinに触れ始める

Kotlinがイケてるらしいからに脱Javaしようぜって空気が社内に流れ始めた

ここがエンジニアとしてのターニングポイントな気がする
もちろんKotlinなんて初めて触った
ひとまず本を買って必死に勉強した

プロジェクトが大きくなった

新人がぶわっと入ってきた
何人か抱えることになって、教えなきゃと思ってgitの復習とかした
間違ったことを教えないようにと思って基礎を固めた

コーディングの基礎とか、丁寧に書けるように意識し始めた
この辺で人へ教える技術のノウハウを入手する

技術書をあさり始めた

とにかく新しいことを覚えることが楽しくなり
家で勉強する機会が増えて、この辺でぐーんと実力が伸びた

CoroutineとかJetpackとかその辺をそこそこ使えるようになった
ようやくエンジニアとして働いてますって言えるかなって思い始めた

役職が上がった

給料が変わるわけじゃないけどサブリーダーにランクアップした
上の人がいないときに代替で色々やるようになった
チームビルディングとかの本を読んだ

GitHubの使用許可が下りなかったので
コードレビューをほぼペアプロ状態でやってた

転職を考え始めた

今いる会社ではやれることに限界があるなぁと感じ始めた
自分よりもっと強い人に囲まれて開発がしたい

プロジェクト強制異動

色々あって異動になった。原因は資金まわり
納得がいかなかったので近々の転職を決意する

現在

無理くりしてリモートワークを勝ち取って、ある程度平和に働いてるけど
まだAndroidに未練たらたらなので転職がしたい

あとAndroidが見せてくれる世界をまだまだ楽しみたい
Android11Betaきたし、Kotlinの1.4の正式リリースもそろそろかなぁ

今年で27歳なので、なるべく早めに動きたいなって思ってる
そんなに時間は残されてないのかな・・・

現在使えるもの

基礎的なコーディング技術
Androidライフサイクルへの理解
Kotlinの基礎的な理解
Coroutine
DataBinding
Espresso
UIAutomator
GooglePlayConsole
Git

ぼんやり使えるもの

Androidアプリケーションに必要な機能実装（いつも調べながらやる）
xmlによるレイアウト記述（割と適当に書いてるのでよくない）
LiveData
Room
Retrofit2
MVVMアーキテクチャ
Androidにおけるマテリアルデザイン
スクラム開発

勉強したもの（未実践）

RxJava
CleanArchitecture

今後勉強したいもの

Android Architecture Components(AAC)
CI / CD
Unitテスト
ドメイン駆動開発
テスト駆動開発

つまづいたこととか感じたこととか

自主学習する人は一握りである

「この本とか参考になるから」とか「これ覚えとくといいよ」とか
自分の中では親切にアドバイスをしたつもりなんだけど、特に意味をなさなかった

彼らにとって「プログラミング ＝ 仕事」であり
プライベートで仕事はしたくないと
別にこの思想自体が悪いとは全く思わない（個人の自由だし）

僕もそりゃあプライベートの時間を削って仕事はしたくない
でも新しいものを知ることが好きだからときどき勉強する
もちろん勉強よりゲームやってる方が好き

Androidの環境変化のスピード

とにかく色々なツールが使えなくちゃならない
新しいライブラリやGoogle I/Oで発表されることとか
AndroidのOS Verは１年ごとに上がっていくし

僕はそれが楽しかったんだけど
チームで使えるツールなどはある程度制御していかないと
やたらと便利にしても使えない人が出てきてしまう

あとリファレンス読まないで
個人ブログの古い記事参照にして書いちゃう人とかで事故る

一部機能は担当の人しかメンテできないみたいなことが起きた

設計

スタートとゴールだけ考えてなんとなく作っていくのは明らかに難しい
ソフトウェア設計で使う図とか色々あるけど、なんとなくしか読めない
（そもそも使える人いなかったから書いても意味なかったんだけど）

世間では何がどのくらい使われているんだろう

今は何をどう実装したらいいかなーって紙に書いてから手を動かしてる
流石にこの辺は今後やっておいた方がいいな・・・

アーキテクチャの理解はまだまだ足りないなぁ、実践経験が少ない

世の中で使ってるツールが使えない / 実践できない

わりと重めな悩みのタネ
１人だと実践できなかったりで、解決もできない

GitHubのプルリクとか

日本語を母国語としない人とのコミュニケーション

日本語は難しい。文章もそうだけど、はなし言葉も難しい

単語だけで分節を区切って、日本語だと不自然だけど
短い文章で簡潔にすると伝わりやすかった

敬語も「です、ます」くらいに抑えて
やたらと礼儀正しい文章は使わない方がお互いに楽だった・・・
できればこんどこそ日本人の方が多いところで働きたい（切実）

今後

ひとまず転職したい

転職するする詐欺みたいになってたのは
自分の実力がまだ足りないなぁって思ってたのと
どうせならアプリ１個くらい作りたいなぁって考えてたのがあって
なかなか足が動かずにいた

世の中のAndroidエンジニアは誰しもが個人開発して
アプリのリリースを１回くらいはしてるよなぁ
って思ってたけど、実際に企業の人と話してみたら
「家庭がある人はそもそも時間取れないし、そうでもないよ」って言われた

ちょっと安心した
でもそのうち何かリリースしたいなぁ。ネタはあるので

転職ドラフトでちょこちょこ指名されたりしてるので
今のスキルでも必要としてくれる人はいると信じて

やってみてダメならまた考える

CleanArchitectureの話

記事を書くのに間が空き過ぎてしまった・・・
最近天則に復帰したりVLORANTが楽しかったりで忙しいです
転職したいならその時間を勉強にあてろ

CleanArchitectureの勉強はぶっちゃけ手間取りました
DDDもかじりながらボブおじのブログを読んだので・・・
あと原文をそのまま理解しようとするのは難易度が高い
そもそもCleanArchitecture自体がちょっと難しい・・・（個人差があります）

正直なところ記事にするけど内容の正確性に自信がない
まさかり募集

blog.cleancoder.com

CleanArchitectureを一言でまとめると
「抽象度でレイヤー分けして、依存性を排除したアーキテクチャ」

具体的なモノ（抽象度が低いもの = UI, DB, etc...）は変更されやすいので
そこは一番いじりやすくしようぜ！みたいなニュアンスだと思ってます

ここからは和訳もかねて書いてく

みんな大好きなあの図。ボブおじのブログから引用

様々なアーキテクチャがあるが基本的に目的は同じであり
「ソフトウェアを機能ごとにレイヤー分けすることで関心の分離を行う」ことにある

1. フレームワークに依存しない
   制限された状態でシステムに機能を落とし込む必要性が無くなる

2. テスト可能
   外部に依存しないのでテストができる

3. UIに依存しない

4. DBに依存しない

5. 外部から独立している。ビジネスルールは外部の状態を知らなくても良い

依存関係のルール

外側から内側に向けて依存する
内側はが外側の状態を知らなくても良い

エンティティ

不変なビジネスルールを記述
サービスの基幹部分（単一のアプリケーションであれば、アプリの仕様になる）
要はこれがなきゃサービスにならないレベルのもの（＝ドメインオブジェクト ）

ex.) twitterであれば「ユーザー」や「ツイート機能」などに当たる

外部の変更があった場合でも、変更される可能性が最も低い

ユースケース

エンティティに記述しないようなビジネスルールはこっちに記述する
ソフトウェアの仕様変更の影響を受ける

このレイヤーはエンティティへ影響を与えることは想定していない（無関心）
エンティティとのデータフローを調整
ユースケースの目的を達成できるようにエンティティへ指示する

インターフェースアダプター

エンティティやユースケースのデータを、DBなどで使える形に変換する
エンティティとユースケースはDBについては知らなくて良い

ようはぶっちゃけViewMode強化版みたいなとこ

フレームワークとドライバ

DB・UI・Webのフレームワーク
変更の多いところはここ

図について

あくまで例として４つのレイヤーにしただけで、増えることもある
仮に増えても依存性は外側から内側へなのは変わらない
内側へ向かうとソフトウェアはより抽象的になる

レイヤーの境界を超える

右下の図について説明

ユースケースと通信するコントローラーとプレゼンター
コントローラで始まりユースケースを内でデータを操作、プレゼンターで実行

普通は「依存性逆転の法則」を利用するんだとかなんだとか

直にやりとりすると依存性が高いので×

境界を超えるデータ

境界を越えてデータを渡す場合
常に内側の円に最も便利な形式で渡す
内側の円は外側の状態を意識しなくて良い！

個人的な感想

実装の仕方やモノによって、様々なデータの流れがあって複雑になりそう

抽象度が高い部分で、ロジックをどこに書くかというのが曖昧になりそう
別途ルールを作らないと、人によって書き方がバラバラになりそうかなー・・・？

ちょっとまだ理解がふわふわしてる

UIが一番上で、DBが一番下なアーキテクチャに馴染みがあるので理解するのに時間がかかった

リアクティブプログラミング10日目

結構間が空きました。元気になったので再開
無理はよくない、転職してぇ、そのためのRxJava

最近アプリ開発から強制立ち退きカウントダウンを食らって気分が沈んでます
自分が関わっているサービスが今後ボロボロになっていくと思うと辛い

別に僕が何かやらかしたとかそういうのが理由ではないのが本当に悔しい

Base class vs base type

性能比較でもすんの？
ざっと和訳

RxJavaの設計はReactive Streamsの仕様の影響を強く受けたため
ライブラリには各々にインターフェースが用意されている

「基本クラスが静的メソッドとインスタンスメソッドが多いので重い」
という記述があるが何の意味かわからん・・・

「considered heavy」って「重いと考えられる」だよな
重いって何？何が重いん・・・？

リファレンスに載っている表
「各々にインターフェースが用意してあるよ」ってことで記述されてるんだけど・・・

Type	Class	Interface	Consumer
0..N backpressured	Flowable	Publisher	Subscriber
0..N unbounded	Observable	ObservableSource	Observer
1 element or error	Single	SingleSource	SingleObserver
0..1 element or error	Maybe	MaybeSource	MaybeObserver
0 element or error	Completable	CompletableSource	CompletableObserver

Consumer is 何

表のTypeとclassで説明されていることはこれで説明した表の詳細

denden-kata.hatenablog.com

この表ですね

名前	説明
Observable	値が複数
Single	値が１つ
Maybe	値が１つ or なし
Completable	値なし

FlowableとObservableはバックプレッシャーがあるないだけ

んで、後ろの部分は何なんだ
Reactive Streamsの仕様を見てみる

（抜粋）
SPECIFICATION
1.Publisher

public interface Publisher<T> {
    public void subscribe(Subscriber<? super T> s);
}

あっこれかぁ

つまるとこインターフェースで呼ぶときはこうしろってことなんですかね
ちょっと良く分かんないです
というかこれ何の意味があるんですか（殴られそう）

RxJavaではなくてリアクティブプログラミングを根本から勉強しろと言われてる気がする

RxJavaトップページの翻訳はこれでおしまいです
あとは下の方に別のドキュメントとかwikiがあるのでそれを見ろという感じで・・・

総括

RxJavaの基本はコレクションをストリームで管理するという非常にシンプルなもの
多分これでいいと思います

ぶっちゃけ基本を学ぶだけでも覚えることめっちゃ多いのかと思っていたけど
いざ取り掛かってみるとそこまででもなかった

概念は結構シンプルで分かりやすい
まぁ実際に現場で使ってみたりすると沼にハマったりするんだろうけど・・・

Android開発で利用する場合はライフサイクルとかUIスレッドとか
色々と考えながら実装しないと思った通りに動いてくれないみたいな事故があるんですよね
変な実装しなければ割ときちんと動くはずなんですけど・・・

結構適当に読み解いているのでそろそろ警察に後ろから刺されそう

せっかくのGWなので
次はなんかいいサンプルコードがあれば復習がてら読み解いていくか
Clean Architectureの勉強をしていこうと思いまーす

おしまい