2017/04/10 このエントリーをはてなブックマークに追加 はてなブックマーク - 「イシューからはじめよ」はシステム開発、プレゼンで役立つ内容かもしれない

「イシューからはじめよ」はシステム開発、プレゼンで役立つ内容かもしれない



「イシューからはじめよ」を読んだ。結構良かった。


別にソフトウェア開発とかそっち系ではなく、
もっと仕事をする人全般に当てはまる内容の本。

だけど、自分として役立ちそうなのものとして

  • システム開発
  • トラブルシューティング
  • 勉強会とかの発表

という場面が思い浮かんだ。
なのでシステム開発で「開発が終わらない」とか「バグの解析が苦手」とか、
勉強会で「プレゼンの資料が上手く作れない」とか悩んだりしてる人は読むといいのかもしれない。












2017/04/05 このエントリーをはてなブックマークに追加 はてなブックマーク - 経験積むほど守破離が出来なくなってきた

経験積むほど守破離が出来なくなってきた



プログラミングをするお仕事をして数年経つけど(5年ちょいぐらい)、段々と守破離が出来なくなってきた気がする。




剣道や茶道などで、修業における段階を示したもの。「守」は、師や流派の教え、型、技を忠実に守り、確実に身につける段階。「破」は、他の師や流派の教えについても考え、良いものを取り入れ、心技を発展させる段階。「離」は、一つの流派から離れ、独自の新しいものを生み出し確立させる段階。

https://kotobank.jp/word/%E5%AE%88%E7%A0%B4%E9%9B%A2-689006より引用




この守破離という言葉は、近い職業で言うといわゆるITエンジニアの意識高い系の人たちが使っている気がするのだけど考えとしては大事と思っている。

で、出来なくなってきてると思っているのは主に「守」の部分。



トレードオフ的な。

例えば、新しい言語Aを学ぶとなったとする。
そうすると、プログラミングを初めたばかりであれば入門書から全て基本文法を覚えたりとか始める。
次に何かアプリとか作ってみようとする。そして仕事で使うとかする。

一方で、それが今の僕であれば基本文法は入門書を細かく見なくても◯◯言語のアレと同じだからやんなくても大体分かるな、となる。
A言語とB言語があった時に、AのXXXX ≒ BのXXXX とか判断出来る。
一見して便利なんだけど、全然手とか動かさなくて済んでしまう。もしくはそれで済まそうとする。記憶に残らないし身につかない。
性分として、元々あたまでっかちな方なので結構質が悪い。
言語の違いの部分だけ味見して分かった気になるとかそんな感じになってて中途半端だなぁ、、とかいうのが最近です。


ということで、僕がやっているのは守のない守破離みたいな感じになっている。かもしれない。
帽子のないマリオ、バクダンを持ってないボンバーマン、具のないカレー、みたいになんか足りない感じ。


そもそも破も離も出来ないはずなので、完全にわかったフリということになる。厳しい。



ここ最近思うのはもっと愚直にやりたいなということ。
もちろん、分かりきっていることをド初心者と同じように学ぶというのは効率が悪いのでやらないですが、もっと色んなことに真摯に向き合いたいなとか思う所存。


という自分の悩み?と自戒を書いた風のポエムでした。


うだうだ言ってないでコード書け的なやつだ。



そもそも守破離と言うほど物事を突き詰めているのか、どうなんだ。



2017/04/01 このエントリーをはてなブックマークに追加 はてなブックマーク - 僕の考えたさいきょーのJavaのプログラム初心者向け研修課題、の妄想

僕の考えたさいきょーのJavaのプログラム初心者向け研修課題、の妄想


ござ先輩さんのアレを読んだ。


Javaで「はじめてのプログラミング」を教えるのはキツイと思った話


Javaに造詣が深い方だった気がするし、色々考えた上でそういう決断するのは確かになぁーと思った。

イマドキ、Servletさわんのかぁとか思いつつ、Servletそんなムズいんだっけと思いつつ。

で、脱線して僕ならJavaの研修課題どんなものを作るかなとか考えた。



2017/03/25 このエントリーをはてなブックマークに追加 はてなブックマーク - Kotlinにstaticが無いのなんで?(Why doesn't Kotlin have static members inside a class?)

Kotlinにstaticが無いのなんで?(Why doesn't Kotlin have static members inside a class?)



って前に聞かれたけど、スッと答えられなかったのでここに記します。


※このあたり(https://speakerdeck.com/ntaro/kotlinwoshi-meyouhanzuon-number-droidkaigi-number-droidkaigi6?slide=41



2017/03/11 このエントリーをはてなブックマークに追加 はてなブックマーク - Kotlinハンズオンのお手伝いしました&DroidKaigi2017の2日目に参加してきました #droidkaigi

Kotlinハンズオンのお手伝いしました&DroidKaigi2017の2日目に参加してきました #droidkaigi









DroidKaigi2017の2日目に参加してきました!
ハンズオンのお手伝いもしました!



DroidKaigi2017、運営面とても快適でした。
発表者、参加者、スタッフでうまく成り立っているかなぁという風に思い色々感謝です。

僕個人としては快く休ませてもらえた会社にも感謝です。
あ、でも会社の宣伝全然出来てないや。すんません。
(ていうか皆さん平日2daysで休み取れるなんて良い会社ですね?僕は自分の判断で1日参加でした)


あと、チューターとして誘えてもらったたろうさんにも感謝。


2017/02/22 このエントリーをはてなブックマークに追加 はてなブックマーク - オレオレ実装で良いと思う

オレオレ実装で良いと思う



一人で書くときは。


個人で書くときとチームで書くときは良いコードの意味が違う。



2017/02/19 このエントリーをはてなブックマークに追加 はてなブックマーク - 第5回 マイクロサービスアーキテクチャ読書会 #MSA読書会 に参加してきました

第5回 マイクロサービスアーキテクチャ読書会 #MSA読書会 に参加してきました




オライリーが出版しているマイクロサービスアーキテクチャの読書会に参加してきました。

第5回 マイクロサービスアーキテクチャ読書会 #MSA読書会

今回は6章です。


この読書会は「本の内容をなぞって担当者が発表」→「ディスカッション」という形式をとっています。


6章のテーマは「マイクロサービスにおける」”デプロイ”に関してです。
が、まぁ本の内容をなぞって説明をしてもらって、話を聞いている間に6章を初見で読んで、これは嫌な予感がするなーと思いました。

その時の感想がこちら。

他の章をきっちり読めてないっていうアレな状態なんですが、とにかくこの章はCI/CDというテーマに対して文書量が少ない。かつ、マイクロサービスアーキテクチャについてのCI/CDって意味での深掘りが無いです。

したがって、これはCI/CDの話に内容がすり替わってしまってマイクロサービスの文脈からは離れてしまうのではないかという懸念がありました。


結果的にやはり「マイクロサービス」の文脈というよりはCI/CDのディスカッションという意味あいが強くなってしまったんじゃないかなぁと思います。6章を語る上でおそらく、CI/CDというのは「前提」であって「本論」ではないんですが、どうしても自動化とかそっちの方にディスカッションの話題が行ってしまいがちでした。
本来ならマイクロサービスの文脈でCI/CDとはどうあるのが良いかというディスカッションになれば良かったんですが。

どっちかというと、CI/CDやってますよね? やってます or やってませんみたいなレベルになってしまって少しもったい無かったかなと思います。

だって、自動化とか別に出来てても出来てなくても良いですけど。この本の主題は、マイクロサービスですから、マイクロサービスにおいて自動化はどうあるべきかに注力出来た方がホントは良いのです。


結構座席的には面白い人が集まっている島だったんですが、マイクロサービスと組織論的な話が面白かったです。SIの文脈においてはマイクロサービスのサービス単位でチームが出来て縦割りになる。その際の政治的な問題とか。
はたまた「過剰なマイクロサービス」の話も面白かったです。CRUDでサービスが分かれるとか。Spring系のマイクロサービスの本とかであるんですって。まぁサンプルとしてはCRUDとかでサービス分けると分かりやすいんでしょうけど。実際やりすぎなんですよね。
でも技術書とかのサンプルがそうなっちゃってるから偉い人が「それが正しいんだ!こういう風にしよう!」みたいなことになったりするらしいです。


マイクロサービスで考えてた時、本にも書いてありますが、CIとCDはあって当たり前かつ、必要不可欠な存在です。かつ、筆者の主張に従うと、1サービス、1リポジトリ、1ビルド(CI)という比率であるべきと言っています。

加えてローカルでの再現が難しい。「バランスを考えてローカルでも環境を作るべき」、と。
また低速のテスト、高速のテスト、UAT、本番などで環境を変える場合はそれぞれの環境の違いを考慮する必要がある、など。

正直このあたりはもっと本の中で掘り下げて欲しいところで、もっと色々ケーススタディがあると思うんですよね。
でもきっと筆者的にはこの章はこのページ数で収めないと、、、とかあるわけです。(はしょりたくないけど)その大事なことをはしょっているんだろうなと言う感じを僕としては強く受けました。


Docker、Ansible、Vagrant、Vaultなど結果的にCI/CDツールの詳解で終わってしまったような章でした。
うーん、ちょっともう少し説明する必要あるだろうみたいな気持ちでしたが。で、そういうツール郡を熟知していればそっちにとらわれなくて済んだんでしょうけど。。。。
なかなか読書会の皆がそんなの当たり前に知っているというわけではないんですよね。


という感じで、なんだかモヤモヤしてしまう章ではあってのですが、学ぶこともたくさんありました。

  • 1サービスは1リポジトリであるべき
  • 1サービスは1ビルドであるべき
  • ブランチだけでなくマスターへのコントリビューションが常にあるべき
  • 1ホストに対して1サービスであるべき

みたいな話です。このあたりはマイクロサービス的に大事な内容なんじゃないかなと思います。

といっても、全てがこれに当てはまるわけではないですが、理想的にはこの体系にしていくのが良いのかなという感じです。

例えば、1リポジトリに複数のサービスがある場合は、サービスの境界を意識せず、複数のサービスに対してコミットしてしまいがちとか。つまりリポジトリが同じであるためコーディングをしていると無意識にモノリシックになりやすいということを言っています。(本の中だとあっさり書いてますけど)


ということで、(初参加で言うのもなんですが)ディスカッションとしては今回はもったい無かったのではないかと思います。CI/CDの話になっちゃったから。その話をするのであれば、CiICDの勉強会をやれば良いと思うわけです。
ただ、そうは言ってもマイクロサービスやCI/CDの周辺のメリットデメリットなどの再確認にもなったので良かったのかなと思います。





2017/02/13 このエントリーをはてなブックマークに追加 はてなブックマーク - Kotlinのkaptの話

Kotlinのkaptの話



Pushing the limits of Kotlin annotation processingを読んだ。
よくまとまっている。

ちょっとこの記事をなぞって感想文を書きます。


2017/01/28 このエントリーをはてなブックマークに追加 はてなブックマーク - DDD、やるかどうかは置いといて「わかる!ドメイン駆動設計 」は読むと面白い

DDD、やるかどうかは置いといて「わかる!ドメイン駆動設計 」は読むと面白い




良い本なので感想とか僕の考えてることを書こうと思います!


「わかる! ドメイン駆動設計~もちこちゃんの大冒険~」というTechBoosterさんが出している本です。
DDDだからページ数多いんだろうなというイメージだったんですが、60ページ。しかも1000円は安い。

買ってハズレでもちょっと1日御飯を控えめにするだけでなんとかなる(大体控えめにすることはない)。と思いPDF版を買いました。



こちらから買えますよ!まわしものじゃないけどw

https://techbooster.booth.pm/items/392260


2017/01/08 このエントリーをはてなブックマークに追加 はてなブックマーク - 世田谷公園の近くに引っ越しました

世田谷公園の近くに引っ越しました


引っ越しました!世田谷公園には行ったことがありません!


渋谷、三軒茶屋、中目黒などそのあたりで飲む際にはお誘い下さい!!!
それ以外の場所で飲む場合も誘って下さい!



電車通勤の消耗を抑えるために、というのが一番大きいです。
年々電車通勤する体力が減退している。。

徒歩通勤になるので電車とおさらばというのが嬉しいです。


あと、前の部屋は安くて広くていい部屋だったのですが、
川沿いの大通り沿いに面していて、走りたがりなバイクとか、スポーツカーなどのブォンブォン言う音、
救急車消防車のサイレンの音などに悩まされていたため引っ越したいという気持ちがあったことなどもあります。



引っ越しは勢いが大事です。会社から補助してもらえる部分もあって勢いがつきました。



渋谷、三軒茶屋、中目黒などそのあたりで飲む際にはお誘い下さい!!!
それ以外の場所で飲む場合も誘って下さい!