プログラマーの皆さんは日々（？）ライブラリを作成したり、あるいは使っていたりするのではないかと思います。しかし、ライブラリ開発やメンテナンスには様々な苦難が伴います。たとえば、継続してメンテナンスするための労力の捻出、バージョンアップの時の互換性の確保、ドキュメントの整備・更新など色々な苦労があるかと思います。ライブラリ開発には様々な苦悩が伴うにも関わらず、これまでそのようなライブラリのメンテナンスについての知見はあまり共有されていなかったように思います。というわけで、5月24（金）19:00-21:00に以下のような技術イベントを開催することにしました。 ライブラリ開発に苦悩する方々、あるいはライブラリを開発してみたいけど、どうやって開発すればいいのかわからない、など様々なソフトウェアエンジニアの方々の参加を歓迎したいと思います。ハイブリッド開催ですので東京在住でない方はリモート参加もで

こんばんは、みずしまです。最近は主に強化学習の勉強をしているのですが、読み進めていく過程で少し悩みの種がありました。それは、サンプルコードの扱いです。サンプルコードはPythonで書かれていて、実際に書き写すことが私にとって理解の助けになるのは確かなように思えましたが、一方で過去の経験から、そのまま写経すると「スルスルと動いてしまってフィードバックとして不十分そうだな」と感じたので、Scalaで書いてみることにしました。 別にScalaでなくて、JavaでもRubyでもあるいはJuliaでも良かったのですがそれはともかくとして、元のサンプルコードと違う言語で書くことで得られる利点も結構あるものだなというのが正直に感じた点です。たとえば、np.mean(...)というコードが書籍では出て来るわけですが、「そういえばScalaでmeanと同じことをするにはどうしたらいいんだっけ？」と考えること

このエントリをあえて書こうと思ったきっかけなんですが、先日の、とあるQiita記事です。この中で、 もちろん全員ではなくいい人もいるが、一部の人がKotlinやGoをディスっていて、かつその人が日本のScalaの第一人者的存在のため 誰も咎めることができず感じ悪い印象を与えることがあった。 と名指しで（訂正されて過去形になっていますが、読んだ時点では、現在形でした）中傷されたことがきっかけでした。というのは、この条件に当てはまる人は日本で私以外存在しないわけなので。 で、何が中傷かというと、日本のScalaの第一人者的存在のため誰も咎めることができずという辺りです。KotlinやGoをディスっていたのは事実なんでいいんですが、自分が偉い人だから誰も注意できなかった、みたいな物言いは端的に事実に反しますし、私を諭してくれた方々にも失礼なことです。 ただ、それは中傷ということで自分の中では決着

私は最近、昼間のお仕事ではObjective-Cをよく使っているが、この言語、さすがに元々の年代が古いというかあちこち微妙な部分があってイラっ☆とくることがよくある。とはいえ、Objective-Cに関してはまだまだ素人なので、熟練者からみればとんちんかんなことを言ってるかもしれないが、ツッコミを期待して書いてみる。 nil に対するメッセージ送信が例外にならない この仕様って、Objective-C以外でほとんど見かけたことがないのだけど、メリットに比べてデメリットが大き過ぎると思う。オブジェクトのメソッドチェインでこの仕様がたまに便利なことはあるけど、ほとんどの場合、バグが発現するタイミングが遅くなるだけに終わるというのが経験則。この辺、熟練のObjective-Cerはどう考えてるのか一度知りたいところ。 メモリ安全ではない ARCが入ってある程度マシになったものの、何故2012年の