転職活動、進捗30%です

ここ2ヶ月で、

スカウト20社

スカウトや自分から応募で話を聞きに行った12社

選考を受けた数 5社

技術試験・コードチェックで脱落3社

一次面接で脱落2社

大幅に戦術を変えなくてはいけないかもしれない。

具体的には、

  • 自社サービスに限らないでほかの業態も視野に入れる
  • なにか自分で小さいアプリを作る
  • Docker、CI/CDなどを自分でやってみる
  • テストを書く

SESで現場を選べないので自分で足りないところを自分で満たすしかない。

面接では、コードをかけるかよりも今の環境周りを聞かれる印象があった。

2社だけしか面接を受けていないのでなんとも言えないが、直感で足りない部分が分かった気がする。

また、自分がどんな会社・ポジションで行きたいかより言語化された気がする。 スカウトされてホイホイ、カジュアル面談に行くのも大切だが、ある程度、こちらのやりたいこととか、大事なことは前もって聞いておくことも必要だなと思った。

面接で言ってもらえたうれしかったこととして、次がある。

  • 学ぼうとする姿勢がよい
  • qiitaのアウトプット数が多い
  • 勉強会に行っている
  • 環境が変わったらレベルアップしそう

来月から、現場が変わり、新しい環境をキャッチアップしたり、稼働が多くなる可能性があるため、転職活動として多少おとなしくなってしまうのが悲しい。

今の現場で転職を決めたかったから、ほぼ時間切れな今の状況に少し絶望しているが、前向きにやっていきたい。

銀座Rails#12@DeNAに参加しました

初めてのRails界隈の勉強会

ginza-rails.connpass.com

Rails界隈の勉強会は初めてでした。 Ruby界隈も初めてです。

業務後行ったので、伊藤さんの発表前に到着しました。

なぜ参加したのか

ゲストスピーカー伊藤淳一さんがいらっしゃるということで1ファンとして参加しました。 本、youtubeやblogやtweetなどいつも拝見していて、とても参考になっています。

blog.jnito.com

ruby-book.jnito.com

ゲストスピーカー伊藤淳一さんの発表

発表は、プログラミングするときに何を考えてやっているのかを動画にして教えてくれるもので、とても参考になりました。

2倍速やショートカットがあったとはいえ、ものすごいスピードでプログラミングされており、僕から見たら神技に見えました。

激強エンジニアであることがわかりました。

勉強会行くと、他のひととの実力差は嫌でも感じますが、今回の衝撃は大きかったです。

speakerdeck.com

懇親会

絶対、知っている人はいないだろいうと思ったらややっぱり知り合いはいなくて、アウェー感を楽しみました。

印象として女性の参加者が多いなという印象でした。

あくまで個人の感想です。 PHPの平日の勉強会では、女性は少ないような印象があります。 Rails Girlsで女性に人気があるのでしょうか。

railsgirls.jp

懇親会では伊藤さんとお話できてとてもよかったです。

Railsでここ最近やったこと

きっかけ

本は一年くらい前から図書館で借りてRubyの基礎文法やRailsのさわりだけやっていました。

Rubyの言語仕様が好きだったり、Railsのシンプルに爆速で簡単なアプリが作れたりするのが好きです。

あと僕はとてもミーハーなところがあってまつもとゆきひろさんや、伊藤淳一さんのファンというか講演会やブログ記事などを拝見し「なるほど〜」思ったりとか参考にしてます。

Railsは外側は簡単そうなのですが、奥深く、easyではないなと思います。 Laravelも同じなんじゃないかと思います。

ここ最近でやったこと

ここ最近やったことは、

こちらのサイトで基礎文法を復習して、手を動かして、手に覚えさせることと、 www.tohoho-web.com

こちらのサイトでRailsの流れみたいなもを学び、手を動かして雰囲気を味わいました。動画での解説はとてもわかりやすく、楽しくできました。

https://dotinstall.com/lessons/basic_rails_v3

昨日、今日で夜な夜なRailsとVueをどうやって合わせていくかというのをやりました。

どうやって合わせて行くのかというのは、諸説あり、ベストな方法が分からず、こちらの記事を参考に一旦、結論を出しました。

わかりやすく手順が書かれてい大変参考になりました。 numb86-tech.hatenablog.com

ただVueのほかのライブラリ(ルーターとか)との組み合わせに関しては、奥が深く、難易度が高いと感じました。

Railsチュートリアル

Railsチュートリアルはやっていなくて、やったほうがいいというのはあるんですけど、時間がかかりそうで、全く手をつけてません。

cloud9やherokuなどが出てきて、環境周りもやる感じで億劫になっています。 VueComponentなどは出ずに、erbを使って行く感じだと思いました。

ボリュームがあり、どれを飛ばせばいいかもよく分かりません。

railstutorial.jp

やっている理由

仕事では、Laravelをやっていてそれはそれで面白いなとは思っているですが、Railsもさわりたいなというか違うのを触ると楽しいし、幅が広がるんじゃないかと思っています。

将来的に仕事で使えたらうれしいし、Laravelも触っていきたい。

laravelとの比較

現時点での話では、RailsもLaravelもどちらも好きです。 フレームワークは、手段であり、目的にしていくのはおかしいのかもしれないです。 僕は、技術・フレームワーク等は手段であり、入れ込みすぎるのはよくないなと思いながらも好きだから、プライベートでも触るし、知見を得たいと思うので、目的にしちゃっているという感じです。

ビジネス目線だとこの傾向はよくないと思います。 バランスが大事なのでうまくビジネス側に価値を提供しつつも好きなフレームワークを使っていきたいです。

#しがないラジオmeetup 3に行ってきた

日付がだいぶ経ってますが下書きで残っていたのでサクッと完成させて出します。

shiganai.connpass.com

なぜいこうと思ったか

ポッドキャストで聞いていて、たまたまミートアップイベントを知り、ノリで参加した。

今回の参加目的は楽しそうだったから。

技術系の勉強会に行くのが好きだったが、自分のリソースをそこまでさけないときに行ってもしょうがないというかきついなと思ってきて、参加するイベントは選んでいる。

僕は、今都内勤務ではないので勉強会はたくさん行くことをしていなくて、あくまで自分があとでLT資料の中でのトピックを復習できて、消化可能な範囲で参加したいというような感じになっている。

ラジオ好き

もともとラジオ好きで、小学校三年生から伊集院光さんのニッポン放送の「伊集院光Oh!デカナイト」から聞いていた。小中学校とニッポン放送を聞きながら勉強、高校生はTBSラジオずっと聞いて勉強していた。

行く前の準備

名札がないケースもあるため、PhperKaigiの名札を持参した。

声だけ聞いた声優さんに会ったような感動

歴代ゲストの方の近況報告(アップデート)があり、「このひとなんだー」みたいな感動があった。

声優さんで声だけよく聞いていてご本人を見たときの感動に似たものがあった。 たくさん会いたかったひとに会えました。

健康的なエンジニアを目指すラーメンの食べ方

エンジニアのみなさん、ラーメンはお好きですか? 僕は、大好きです。
20代のころは、週3で家系を食べてました。

30代半ばになり、最近、お腹まわりと健康が気になってきました。
そこで、考案?した僕のラーメンの食べ方のヒントを書きました。

技術を追うのは、もちろん大切です。 しかし、健康を損なうと技術を追うことができなくなります。 健康があればこそです。

www.oreilly.co.jp

対象読者

  • ラーメン好きエンジニア
  • 最近お腹まわりが気になるエンジニア
  • 健康が気になるエンジニア

諸注意

筆者はお医者さんではないため、医学的にはわかりません。 おそらく健康的だろうという知見です。

筆者について

ラーメン大好きエンジニアです。

想定されるラーメン

横浜家系ラーメンさんやラーメン二郎さんです。 ほかのラーメンでも、ヒントになるかもしれません。

ja.wikipedia.org

ja.wikipedia.org

麺固め、油少なめ、味薄めで、オーダー

麺は固めにしてください。 麺が伸びるのを気にせず、ゆっくり食べてください。 油は少なめのほうがいいです。 味はうすめのほうが健康的です。

大盛り無料、ご飯無料を勇気を持って断る

お店によっては、つけ麺、大盛り無料などがあるかもしれません。 できるだけ、断ってください。 大盛りにしないと損な気がしますが、健康を損なうほうがもっと損です。

同じ理由でご飯無料も断ってください。

無料トッピングで玉ねぎがあれば入れる

ラーメンの麺を食べ、スープ内にスペースができてきたら、玉ねぎを入れてください。 味のバランスが超えない範囲でいっぱい入れてください。

しばらく待って、玉ねぎが温かくなってきたら食べごろです。 スープごと食べます。

うまいです。

玉ねぎには血液をサラサラにする効果があるようです。

kurashi-no.jp

ニンニクは少量入れる

たくさん入れるとうまいですよね。 ですが、食べ過ぎは禁物です。 少し入れましょう。

野菜増し無料は頼む

店舗により野菜増しができます。 野菜をたくさん食べると健康的です。 できるだけいっぱい食べましょう。

週2日まで。中2日は空ける

ラーメンの食べ過ぎはよくありません。 最低、中2日あけて、ラーメンを楽しみましょう。

スープは残す

ラーメンのスープはとてもおいしいです。 ですが、塩分と油が比較的多い食べ物です。 できるだけ残しましょう。

全部飲むとスタンプがもらえるところもありますが、スタンプは諦めましょう。

ポイントカード類はもらわない

お店によって10回行くと1杯無料がありますが、スタンプのために行ってしまうことがあります。 もらわず、ラーメンを食べる頻度を下げましょう。

まとめ

ラーメンはうまいです。 うまいですが、たくさん食べると健康的によくないと思うので、ほどほどに楽しみましょう。

Qiitaでよしにゃん史上最高いいね数をいただいた理由を考える

史上最高のいいね。

先週、月曜日に投稿させていただいた記事がよしにゃん史上最高にいいねをいただきました。

180いいねくらいです。

どうだっか

ありがたいことに早々にトレンド入りし、それからいいねラッシュが始まりました。

今まで約70記事の合計で100いいねくらいだったのでこの勢いは初めて経験するものでした。

いいねしていただいた方々ありがとうございました。

いいねの理由を考える

完全に、主観なのですが、こういうことかと思いました。

  • 月曜日朝に投稿した
  • みんな興味があるJS。その中でも勢いがあるVue.jsの記事だった
  • ツイッターでいいね・リツイートいただきたくさんの方々の目にふれた
  • 実務をやりながら得た知見だったから
  • 自分の考えを入れたから

自分の考えを書く

この中で、少し詳しく書くと自分の考えを書いてみなさんに共感いただいたのではないかと思います。

僕はこのQiita記事の中で、まず、動くものを作るのが重要であり、そのためなら新しく複雑なものを使うのはやめておこうみたいなことを書いています。

Vue.jsはシンプルで便利なのですが、親子Componentぐらいならいいのですが、孫まで出てくると変数の受け渡しがバケツリレーになってつらくなります。

一般的に、Component単位で細かく分けていくのがいい設計だと思うのですが、Component数が多くなってくると変数の受け渡しで時間がかかってきます。

そのためのVuexなのですが、学習コストを考えると、もし、まわりに使い手がいない状況であれば、無理に使わず、Componentを分けるのを最小限にして孫までComponentを作らないように設計していくべきだと思います。

理想は、Componentを細かく分けVuexで変数の中身を一元管理していくのがいいと思いますが、スキルが必要なことだと思います。

僕は、現状そこまで分かってないのでプロジェクト内では使っていません。

Qiitaを書くことについて

Qiitaでいいねがたくさんつくと、うれしいです。

うれしいですが、いいねをたくさんもらうことだけが僕の目的ではありません。

僕がつまって困ったことや、あとで、見直したいみたいなことがあってそれをweb上に公開しておくことで自分も助かるし、もしかすると、同じように困っているひとの役にたつことがあるかもしれません。

それができたらうれしいです。

自分食べるつもりで作った野菜がいっぱい取れたからほしいひとにおすそわけする農家のひとみたいなことかもしれないです。

qiita.com

Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだ

クリーンアーキテクチャを読みました。

読む理由

設計界隈でよく耳にするこのクリーンアーキテクチャですが、一度は読んでおきたいと思い読みました。

他の姉妹本?のようなものも読んでいました。

yoshinyan99.hatenablog.com

yoshinyan99.hatenablog.com

どうだったか

難しい。 文章が抽象的で難しい。

ソースも難しい

javaのコードもたくさん載っていますが、量が多く、全部読むのは時間がかかります。

Javaの文法でよくわからないのがあります。

次のものは、この本を含め、設計の本を読んでいく中でJavaの文法でわからないものです。

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

String[] argsこの辺が??となっていたのですが、こちらのサイトの説明でわかりました。 引数を文字型で配列で指定しているんですね。

わかりやすく参考になりました。 www.task-notes.com

ArrayList<String>こういうのもなぞ。

次のサイトを参考に調べました。 単に、ArrayListクラスの型を表していてさらに文字列型であるということなんですね。

Javaは少し、本読んだだけで、雰囲気で読んでいるので知識の穴があります。

PHPの型よりも詳細に指定できるんですね。

qiita.com

www.javadrive.jp

興味深いところ

SRP:単一責任の原則

OCP:オープン・クローズドの原則

LSP:リスコフの置換原則

ISPインターフェイス分離の原則

DIP:依存関係逆転の原則

全部、ちゃんと理解できませんでした。

単一責任の原則

「そのクラスやメソッドにひとつのことをさせる」のではなく

「そのクラスやメソッドを変更する理由はたったひとつでなければならない」

ということだと理解しました。 よくひとつのことをさせると勘違いされているとこの本には書いてました。

変更する理由はひとつでなければならないは直感的でなくてソース書いてからもし、変更するなら理由はひとつだろうか?と考える必要があるのでしょうか。

ただ、これをちゃんとやるとごった煮クラスやごった煮メソッドを作らなくてよくなり、可読性、メンテナンス性があがると思います。

ごった煮コード読むのがつらく、時間がかかります。

なので、この原則はとても有効だと思います。

ある勉強会でもこの原則が一番大事とも聞いたおぼえがあります。

オープン・クローズドの原則

既存のソースを変更せず、ソースを追加して、拡張させるというようなことだ。

これは、自分の好みにあっています。 出来上がって動いてテストしても大丈夫なソースはできるだけ修正したくありません。

そのソースをそのまま利用して、他の機能を追加していければ理想です。

本を読んでいる間に思っていたこと

脱線します。

本を読みながら、これは、たくさんある理論・手段のうちのひとつだなと考えるようになりました。

バグがでない読みやすいコードを早く書くというのが、プログラマの目的なような気がします。

もっと上を見ると、儲かるコードを早く書くというのがあるのが本質かもしれませんが、プログラマは儲かるという不確定なことに関して、範囲外な気もします。

どっちも正解なような気がしますが、僕は、ある種職人的なアーティスト的にプログラマを捉えているので、前者のほうが好みであります。

tatsu-zine.com