日本Kotlinユーザーグループ(JKUG)主催でLTイベントを行いました。Kotlin2017/07/10利き手のようにJava使うのやめたいなってってなんとなく思った。いろんな言語を学びたいとか言いつつ、お前が真っ先に書こうとするのはJavaだろう、と。「Javaが凄い出来ます!得意です!」とかなかなかそういうことを言う気にはならないんだけど、パッと何かをしようとしたときには一番楽な言語となっている。それかKotlinなんだけど。Javaに関して言えば、開発環境がすでに目の前にあるから咄嗟に使いやすいというのは大きい。利き手以外も使おうと例えば普段鉛筆を持たない左手で字を書いてみる。書いているうちに左手で字を書くことを覚える、みたいな作業は必ず必要である。「この忙しいのになに悠長なことしてんだ」ということになるので時間の捻出もある程度必要になりそう。家で趣味コードであればダラダラ書いても良いかもしれないが。ある程度家で素振りしてから実戦で個人で使ってみるという流れかな。それでよっぽどチームで使ってメリットがあるならチームで導入という流れになるだろう。向き不向きで手段が選べているかホントにそれってJavaでやる方が向いている作業?ってこともある。したらPythonの方が良いかもしれないし、JavaScriptの方が良いかもしれないし、RustとかGoの方が良いのかもしれないみたいなの。それでも案外Javaで出来てしまったりするからタチが悪いというか。Javaみたいなことになる。そもそもそんな難しいことを僕自身が書いていない。利き手のように使うためにやっぱり素振りだなぁ。考え2017/07/07このブログをhttps化した(少しだけ)一応世の中はそうなっていると聞いているのでそうした。以前にたまたま見かけたJxckさんのこれに感銘を受けた、というと大げさだけど。しないとなぁという思いから。http2とりあえずhttpのものはhttpsに置換。Bloggerの設定でhttpリダイレクトでhttpsになる仕組みがあったのでそれをオンにした。ブログの情報はhttpsで閲覧可能になった。https対応していないっぽいブログパーツは捨てた。各ブログエントリ内でhttpでaタグとか使っちゃっているところもあるだろうからそこは暇なときに直していくしかない。骨が折れるかもしれない。使っているAdsenseはhttpsか可能だったので、小遣い稼ぎがてら残しているけど収益なんか無いに等しいので飾り。悲しいのは、はてぶがhttpの方にリンクされていて全然表示されなくなったこと。今までのはてブの数でドヤってするのも微妙だしな。今後はhttpsではてブとかついていくだろうし大した問題では無い。件のコメント:Tweet2017/06/28個人的な勉強会に行くと良いこと最近、「勉強会に行く人が優秀うんぬん」とか流行ってたので、なんとなく書いています。ただのプログラマーが書いている文章です。考え2017/06/26Kotlinの演算子オーバーロードはnullableが絡むと少しめんどいつまりこういうめんどくささがあります。OK軽く解説nullableをレシーバーに取りにくいf1()という関数呼び出しは、実は演算子オーバーロードという機能によって実現しています。呼び出されるというものです。いうインターフェースです。Function0の実装はこうなっています。R}f1はFunction0自身であり、invokeが実行されます。これがf2のようにnullableとなった場合にKotlinの演算子オーバーロードはそれを許しません。f2?.invokeという風に厳密にかけとコンパイルエラーになります。nullableな変数の関数呼び出し(nullableな型をレシーバーとする関数呼び出し)をしにくいということです。演算子オーバーロードは?による特殊記法がない前述したコードのf2を、f2?()とかって実行出来れば良いのではという感じもしますが、Kotlinはそういった言語設計を行っていないようです。f2?()という呼び出しをサポートする代わりに明示的にf2?.invoke()と書きなさい、としています。普段は演算子オーバーロードによって隠蔽されているinvokeという謎関数が出てきた感じになるので、実装者としては混乱するかもしれません。推測ですが、f2?()とかという書き方をサポートしなかったのは単純に?を使った記法を利用できる箇所を限定的にしたかったのと、コンパイラの字句解析とかを簡単にしたい(めんどい)というのがあったのではないかと思います。nullableなものでも演算子オーバーロードを利用するnullableだと演算子オーバーロードが利用できないかというとそうではありません。拡張関数を利用すれば良いのです。次のように実装すればinvokeの呼び出しも演算子オーバーロードを介して利用可能です。コンパイル通るただし、Kotlinの標準ライブラリとしてわざわざこういった機能を提供せずf2?.invoke()と書かせているのは、関数を実行したつもりで関数を実行していないなどのバグの元になるのを防ぐといった意図がありそうですしあまりお勧め出来るソリューションではありません。nullableの場合の振る舞いは多分実装者が決めるものもう一つ、理由として考えるられるのはnullableなものを実行した時の対処というのは大体においてコーディングしている側に委ねられるものだと思います。BigDecimal?などは何を返すかはちょっと考える必要があります。あと、単純に標準ライブラリが膨らみますね。まとめ演算子オーバーロードはnullableをレシーバーにとる時の挙動はあんまりサポートしていないどうしてもやりたいなら実装者側で拡張関数で追加していく必要があるおまけ悪ふざけコードです。bookを僕も参加させてもらって、ちょっと書きました。皆さんありがとうございました。2017年5月29日ぜひ読んだ方はアンケートも書いてみて下さい。ありがたく拝見します。https://t.co/uaFHHfiLuhあくまで個人的な感想&意見という感じですが、裏話としてブログを書いてみます。Safety何も考えずタイトルつけたのに胡散臭い。趣味でKotlinの情報を集めてるだけの人です。KotlinはAndroidで公式採用されることが決まりまして特需が出てきています。こぞって企業がPRのために「Kotlin使ってますアピール」をしたり、Kotlinとはなんぞや、みたいな話を書いたりとかしてますので、この速さなら言える、ということで僕も便乗して久しぶりにKotlinの話を書こうと思います。前提プログラミング言語は簡単で、それを難しく語る人や難しく使う人がいるというだけな気がしています。何が言いたいかというとKotlinは簡単です。KoansとKotlinの公式サイトのリファレンスだけ見れば大体充分です。他の情報はまぁ、あんまり読んでも読まなくても一緒です。(というとアレですね。)あ、でもKotlinスタートブックという本は良いです。あと、僕のサイトも使ってみてね(宣伝)逆引きKotlinそれだけで良いと思うのでココから先は読まなくても問題ないです。2017)タイトルかぶりしそうなので変なタイトル。VMとDalvikとARTの話をしました。https://www.slideshare.net/yyyank/vm-dalvikartjava-vm発表した内容のイイワケ発表者の理解不足もかなりあって、資料見ていただくと簡潔でなかったり情報として微妙だったりする箇所も多いと思います。それでも勉強になったと言ってくれる人もいてありがたいです。(ホントはJVMS全部読んでARTとかOpenJDKの実装ももう少し読んだ上で発表したかった。Specification)ベスト尽くしてこんな感じです。それでも広いなとか思いました。JITとかAOTとかめちゃくちゃ簡単に説明しましたがプロファイリングした上でその情報に基づいてJITが走ったりするとか色々あるんですけど、あー、どこまで調べよう&説明しようかみたいな感じでした。質疑応答について今回はあまり質問なかったか、しにくかったのかもしれません。後から話しかけに来てくれる人もいたのでその人からは色々意見聞くことが出来ました。さくらばさんのJigsawセッションを拝聴してsli.doという匿名質問サービスが良さそうなのでまた機会があれば使ってみたいなと思いました(さくらばさんがツッコまれる世界を初めて見たw)。#ccc_g3データモデル、勉強になりました。咄嗟に出てくるようにしたいなとか思います。いっつもデータモデルのこういうものがあると思いつつも、どのタイミングでそれを使うべきかとか適切に判断できずじまいということが多いです。Javaエンジニアに知って欲しいRDBアンチパターン色々ためになる内容だったんですけど、アンチパターンはH2Oぐらいに思い出がいっぱいって感じなので素直に笑えなかったです。だいさんぐらい声が通る感じになりたい。Jigsawさくらばさんのセッションはいつも安定感がすごいです。スライドとか見ずに全部覚えてて話してるとかいう噂を何処かで聞いた気がします。Jigsawに関してはモジュールがうんたらーで最近もめてるやつってぐらいしか把握できてなかったので、勉強になりました。きしだが働いてるかどうか判定するきしださんぽいなぁと思いました。前半は難しいというか全然知らない分野で雰囲気で聞きました。コーディングのベストプラクティスの部分は納得出来る内容が多かったです。感想とかLINEさんの寿司ちょっと食べましたが美味しかったです。勉強できたし、色んな人と話せたし良かったです。CCC2017/04/10「イシューからはじめよ」はシステム開発、プレゼンで役立つ内容かもしれない「イシューからはじめよ」を読んだ。別にソフトウェア開発とかそっち系ではなく、もっと仕事をする人全般に当てはまる内容の本。自分として役立ちそうなのものとしてシステム開発トラブルシューティング勉強会とかの発表という場面が思い浮かんだ。勉強会で「プレゼンの資料が上手く作れない」とか悩んだりしてる人は読むといいのかもしれない。読書感想文2017/04/05経験積むほど守破離が出来なくなってきたプログラミングをするお仕事をして数年経つけど(5年ちょいぐらい)、段々と守破離が出来なくなってきた気がする。守破離とは剣道や茶道などで、修業における段階を示したもの。「守」は、師や流派の教え、型、技を忠実に守り、確実に身につける段階。「破」は、他の師や流派の教えについても考え、良いものを取り入れ、心技を発展させる段階。「離」は、一つの流派から離れ、独自の新しいものを生み出し確立させる段階。出来なくなるとは何かこの守破離という言葉は、近い職業で言うといわゆるITエンジニアの意識高い系の人たちが使っている気がするのだけど考えとしては大事と思っている。出来なくなってきてると思っているのは主に「守」の部分。知識のショートカットと愚直のトレードオフトレードオフ的な。新しい言語Aを学ぶとなったとする。すると、プログラミングを初めたばかりであれば入門書から全て基本文法を覚えたりとか始める。次に何かアプリとか作ってみようとする。一方で、それが今の僕であれば基本文法は入門書を細かく見なくても◯◯言語のアレと同じだからやんなくても大体分かるな、となる。一見して便利なんだけど、全然手とか動かさなくて済んでしまう。それで済まそうとする。記憶に残らないし身につかない。性分として、元々あたまでっかちな方なので結構質が悪い。言語の違いの部分だけ味見して分かった気になるとかそんな感じになってて中途半端だなぁ、、とかいうのが最近です。守のない守破離ということで、僕がやっているのは守のない守破離みたいな感じになっている。帽子のないマリオ、バクダンを持ってないボンバーマン、具のないカレー、みたいになんか足りない感じ。そもそも破も離も出来ないはずなので、完全にわかったフリということになる。初心にかえりたいここ最近思うのはもっと愚直にやりたいなということ。分かりきっていることをド初心者と同じように学ぶというのは効率が悪いのでやらないですが、もっと色んなことに真摯に向き合いたいなとか思う所存。いう自分の悩み?と自戒を書いた風のポエムでした。言ってないでコード書け的なやつだ。そもそも守破離と言うほど物事を突き詰めているのか、どうなんだ。考え2017/04/01僕の考えたさいきょーのJavaのプログラム初心者向け研修課題、の妄想ござ先輩さんのアレを読んだ。Javaで「はじめてのプログラミング」を教えるのはキツイと思った話Javaに造詣が深い方だった気がするし、色々考えた上でそういう決断するのは確かになぁーと思った。イマドキ、Servletさわんのかぁとか思いつつ、Servletそんなムズいんだっけと思いつつ。脱線して僕ならJavaの研修課題どんなものを作るかなとか考えた。class?)って前に聞かれたけど、スッと答えられなかったのでここに記します。スタッフでうまく成り立っているかなぁという風に思い色々感謝です。僕個人としては快く休ませてもらえた会社にも感謝です。あ、でも会社の宣伝全然出来てないや。(ていうか皆さん平日2daysで休み取れるなんて良い会社ですね?僕は自分の判断で1日参加でした)あと、チューターとして誘えてもらったたろうさんにも感謝。DroidKaigi2017/02/22オレオレ実装で良いと思う一人で書くときは。個人で書くときとチームで書くときは良いコードの意味が違う。参加してきましたオライリーが出版しているマイクロサービスアーキテクチャの読書会に参加してきました。前提この読書会は「本の内容をなぞって担当者が発表」→「ディスカッション」という形式をとっています。6章の危険な匂い6章のテーマは「マイクロサービスにおける」”デプロイ”に関してです。本の内容をなぞって説明をしてもらって、話を聞いている間に6章を初見で読んで、これは嫌な予感がするなーと思いました。その時の感想がこちら。他の章をきっちり読めてないっていうアレな状態なんですが、とにかくこの章はCI/CDというテーマに対して文書量が少ない。マイクロサービスアーキテクチャについてのCI/CDって意味での深掘りが無いです。したがって、これはCI/CDの話に内容がすり替わってしまってマイクロサービスの文脈からは離れてしまうのではないかという懸念がありました。グループディスカッション結果的にやはり「マイクロサービス」の文脈というよりはCI/CDのディスカッションという意味あいが強くなってしまったんじゃないかなぁと思います。6章を語る上でおそらく、CI/CDというのは「前提」であって「本論」ではないんですが、どうしても自動化とかそっちの方にディスカッションの話題が行ってしまいがちでした。本来ならマイクロサービスの文脈でCI/CDとはどうあるのが良いかというディスカッションになれば良かったんですが。やってませんみたいなレベルになってしまって少しもったい無かったかなと思います。自動化とか別に出来てても出来てなくても良いですけど。この本の主題は、マイクロサービスですから、マイクロサービスにおいて自動化はどうあるべきかに注力出来た方がホントは良いのです。グループディスカッションで面白かったところ結構座席的には面白い人が集まっている島だったんですが、マイクロサービスと組織論的な話が面白かったです。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の周辺のメリットデメリットなどの再確認にもなったので良かったのかなと思います。processingを読んだ。この記事をなぞって感想文を書きます。ドメイン駆動設計~もちこちゃんの大冒険~」というTechBoosterさんが出している本です。DDDだからページ数多いんだろうなというイメージだったんですが、60ページ。買ってハズレでもちょっと1日御飯を控えめにするだけでなんとかなる(大体控えめにすることはない)。思いPDF版を買いました。電車通勤の消耗を抑えるために、というのが一番大きいです。年々電車通勤する体力が減退している。徒歩通勤になるので電車とおさらばというのが嬉しいです。救急車消防車のサイレンの音などに悩まされていたため引っ越したいという気持ちがあったことなどもあります。引っ越しは勢いが大事です。会社から補助してもらえる部分もあって勢いがつきました。JapanJavaとGoでお仕事してるプログラマです。Java/Kotlin/Go/Vimとかが好き。【プロフィール】yyyank.github.io【問い合わせ先】yy.yank.dev.blog@gmail.com【twitter】@yy_yank【Github(クソコード)】https://github.com/yyYank詳細プロフィールを。