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

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

2019-08-04

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

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

shiganai.connpass.com

なぜいこうと思ったか

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

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

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

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

ラジオ好き

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

行く前の準備

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

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

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

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

2019-07-01

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

ポエム

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

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

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

www.oreilly.co.jp

対象読者

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

諸注意

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

筆者について

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

想定されるラーメン

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

ja.wikipedia.org

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

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

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

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

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

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

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

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

うまいです。

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

kurashi-no.jp

ニンニクは少量入れる

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

野菜増し無料は頼む

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

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

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

スープは残す

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

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

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

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

まとめ

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

2019-06-10

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

ポエム Vue

史上最高のいいね。
どうだっか
いいねの理由を考える
自分の考えを書く
Qiitaを書くことについて

史上最高のいいね。

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

180いいねくらいです。

どうだっか

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

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

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

いいねの理由を考える

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

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

自分の考えを書く

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

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

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

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

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

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

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

Qiitaを書くことについて

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

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

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

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

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

qiita.com

2019-06-01

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

ポエム本の感想

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

読む理由
どうだったか
ソースも難しい
興味深いところ
単一責任の原則
オープン・クローズドの原則
本を読んでいる間に思っていたこと

読む理由

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

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

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

2019-05-24

Laravel Meetup Tokyo Vol.12に参加しました

イベントレポート

laravel-meetup-tokyo.connpass.com

Laravel Meetup Tokyo に参加してきました。前回の11に引き続き2回目になります。

前回
会場
ステッカー
Laravel JP Conference スタッフTシャツを着る
発表を聞く
ピザうまい
参加してどうだったか

前回

11回目のときは、Laravel界隈の勉強会に参加したことがなく知っている人が全くいませんでした。

今、参加したひとの面々を見ると知っている人が何人もいたので、そのときは、知らなかったけど同じ時間と場所を共有していたんだとエモい気持ちになりました。

このときは、コントローラーにロジックを全部書いてました。現場でもそうだったし、DIとかサービスクラスとか全く知りませんでした。

発表を聞いてなんて高レベルな話なんだと衝撃を受けました。

Laravel Meetup Tokyo Vol.11 - connpass

会場

会場は、アライドアーキテクツ様でした。とてもきれいでした。 www.aainc.co.jp

ステッカー

もらえてとてもうれしい。

#LaravelTokyo
着きました。

ステッカーもらえた😄
アライドアーキテクツさんのオフィス綺麗🐶
— よしにゃん🐱 (@yoshi_php) May 22, 2019

Laravel JP Conference スタッフTシャツを着る

Tシャツを着て行ったのですが、参加者の方で来ている人がみつからず、とてもアウェー感を味わいましたw

懇親会では何人かお見かけしました。

ららこんTシャツ着てきてしもうたが、他にいなくて、アウェー感ある😱#LaravelTokyo
— よしにゃん🐱 (@yoshi_php) May 22, 2019

発表を聞く

個人的に、吉田あひるさんの「 Eloquentに別れを告げるタイミングについて考えた」が設計周りの話が自分の中でトレンドだったので大変興味深かったです。

ことばの解説がありました。僕の中でよく聞くけど雰囲気しかわからないことばがあり、それがよく分かってよかったです。

laravel-meetup-tokyo.connpass.com

ピザうまい

ピザうまかったです。 3枚くらい食べました。

参加してどうだったか

学びがあり、とてもよかったです。ツイッターでよく知っているひとたちにも会えるのもうれしいです。

スタッフのみなさまお疲れ様でした。ありがとうございました。

2019-05-21

Laravel.shibuya #1に参加しました

イベントレポート

laravel-shibuya.connpass.com

「Laravel.shibuya」に参加させてもらってLTもさせていただきました。

申込時
Laravel相談会について
LT本番
ういろうさんのLT
KentarouTakedaさんのLT
まとめていただいたスライド
まとめ

申込時

初心者向けということで、気軽にLTにエントリーする。

Laravel.shibuya https://t.co/QPxmEVfWv1

駆け出しの方向けだと思い、LT枠に応募したが、参加の方にビックネームが何人もいて、震えている😱ブルブル。

ビビらず最低限ちゃんと話すことを目標にしました！🐱
— よしにゃん🐱 (@yoshi_php) 2019年4月12日

Laravel相談会について

事前にアンケートで募集されていた相談したい内容で、僕が送った「よい設計とは」みたいなものが採用されました。

なぜ、よい設計について相談したいのかを事前準備していない中でいろいろ説明しました。

「テスト書いてますか？」「何人くらいの規模ですか？」「どのくらいの期間使うシステムですか？」

などの質問をしていただいたのですが、中でも「テスト書いてますか」というのが印象的でした。

ytakeさんに、クラスをまず小さくするとよいよというようなアドバイスもいただきました。

LT本番

前の方のノリがよくて、とても助かりました。

自分の中でここは間をゆっくりとって、からスライドめくろうとかいろいろ考えてました。おおむねできたと思います。

ういろうさんのLT

とてもよく、勉強になりました。後日、__call()メソッドを調べ勉強になりました。

www.nyamucoro.com

また、LTでできたlaravel-ide-helperというのも入れてみました。一度チャレンジで入れようとしたことがあり、そのときは、うまく行かなかったのですが、懇親会のときういろうさんにやり方のアドバイスをもらってうまくできました。

qiita.com

KentarouTakedaさんのLT

内容が高度でした。僕もレベルアップして、実際にプロジェクトで得た知見を発表したいです。

まとめていただいたスライド

Sally_42さんにまとめていただいています。

qiita.com

まとめ

参加してとてもよかったです。こういう勉強会は参加して刺激になるし、これからの学習の指針になると思います。 LTもやってよかったです。

懇親会でよかったよとかフィードバックいただけてうれしかったです。