しっかり調査してないですが、こういったCIサービスがほぼ存在しない時期にほぼほぼ最初に登場して、一時期明らかにデファクトスタンダードだったと思うので、昔からOSS活動している人ほど、とても多く利用してお世話になっていたと思うので、そういう人であればあるほど、この状況は、怒りではなく、悲しいというか残念というか、辛いと思うんですよね・・・。 今までありがとう・・・。 長年Travis CI使ってきたので、GitHub Actionsによって潰される(のかどうなるのかわからないけど)、の可愛そう、という気持ちが若干あるけど、とはいえ、こういうのよくある話な気はするな…— Kenji Yoshida (@xuwei_k) 2020年10月7日 買収されて方針変わったのかなと感じるところもありますし、OSSプロジェクトが無料で使っていても会社としては辛いのではという気もするので今までの感謝の気持ち

最初に結論 Scala 2.13.3 と 3.0.0-M2-bin-20201031-1ab76c1-NIGHTLY をscalaz最新版でベンチマークしたところ、 Scala 2.13.3は平均約57秒、Scala 3の最新版は平均約31秒で 約45%短縮！！！ めでたいなぁ。 他の条件で計測した場合にどうなるのかわからないが、このままの速度を維持して欲しい。 以下詳細な条件や結果記載。 条件 scalazの最新版masterで、JVM側のmain側のみ(つまりtest除く。除いたのは、test含めると、よりコード量に差が出てしまうなどの理由) (数時間前に7.4.0-M4リリースしたので、実質それ) ベンチマークのために.travis.ymlだけ改変 https://github.com/xuwei-k/scalaz/commit/5956af9d2b280ef05b42eac9241

Phil Bagwell Awardって何？という人は、まず以下を読んでください。 www.scala-lang.org 簡単にまとめると Scalaコミュニティに対して貢献した人に送られる賞 2013年から (いまのところ？)毎年1人だけ "Phil Bagwell" というのは人の名前で、その人にちなんでつけられた あくまで賞の名前がちなんでつけられただけで、賞の内容は上記に書いたような "Scalaコミュニティに対して貢献" らしい？ 今までの受賞者は以下 2017: Josh Suereth 2016: Erik Osheim 2015: Bill Venners 2014: Lalit Pant 2013: Dick Wall "Phil Bagwell" さんについてですが 2012年に亡くなった https://www.lightbend.com/blog/rip-phil-

4年11ヶ月勤めたドワンゴを退職しました。2019年1月17日が最終出社日で、1月中は有給休暇消化期間で、2月から新しいところで働きます。 4年11ヶ月と書きましたが、半年間育児休暇をとっていたので、その期間を引くと実際働いたのは4年5ヶ月です。 4年制の大学(の文学部書道学科)を卒業して、新卒でとある会社に就職して、いろいろあってドワンゴは4社目でしたが、それ以外の会社で最長で2年程度しか勤めたことがなかったので、そう考えると5年近くも続いたのが感慨深いですね。 このblogを読んでいる人ならばある程度の人は知っているかもしれませんが、気づいたら個人的にScalaにとても詳しくなってコミッターにもなって、ドワンゴでの仕事も、ほぼずっとScala書いていました。 もちろん、デプロイツールやちょっとした管理ツール、細かい運用上のなにかで、多少Python, ansible, shell sc

ここでいうScalaとは https://github.com/scala/scala のScala programming language本体のことです。 以前、以下のようなblogを書きましたが xuwei-k.hatenablog.com その後も同じようなpull reqをずっとして、2018年8月10日の時点で、96 commits で 23 位です。 https://github.com/scala/scala/graphs/contributors?from=2003-02-21&to=2018-08-10&type=c 日本人だと1位のはずです。*1 あと、最近だとおそらくこういうのもあります (無駄に?)ここ数ヶ月細かいpull req大量にしたので、2.13.0-M4以降で2.13.xにmergeされたpull req数だと、もしかすると今のところ自分1位なのでは (

github.com mergeされてました。それの簡単な説明や、以前から自分がやりたかったやつを試したらうまくいったので、実例の紹介をします そもそもSIPまであり SIP-NN - Byname implicit arguments | Scala Documentation pull requestにも、言語仕様への記述追加含め結構詳しく書かれているので、それ読めば特に書くことはないわけですが、一応説明します。 (これまたpull reqにも書かれていますが)一言で言うとshapelessのLazy相当のものをScala標準で出来るようになった、ということでしょうか。pull reqの例そのまま引用しますが、以下のようにimplicit parameter部分はbynameにできなかったわけですが、それが出来るようになります。 implicit部分がbynameにできないと何が不便か

以前にも増して、普段ずっとgithubしかやっていないわけで、githubでの活動のことに関してはいくらでも書くことがあるというか、逆に全部をblogに書いていたらとても書ききれないわけで、よってあまり特別なことがない限りblog書かないわけですが、なんとなくScala本体にまとまってpull requestするのは自分にとっては多少は珍しいし、特定のプログラミング言語本体にpull requestするのが、どの程度敷居高いのか、どういうpull requestが受け入れられるのか？を少しでも誰かの参考になればと思い、書いてみます。 以下全部、最近1、2ヶ月でpull reqしてmergeされたものです。このblog書いてる時点で38個でしょうか。 (ここ1、2ヶ月という制約をかけなければ、もっと多く送ったことはあります) 一つずつ簡単に解説書きます。 長いので先に結論というか、感想書いて

nettyのコミッターの人、appleに勤めてる有名人だから、swiftにあまり関係ないけど特別ゲスト的な感じでswiftのカンファレンスで登壇するのかと思いきや、こんなことやってた(コミット数1位)のか、なるほどーhttps://t.co/ZkRg8kn5A0 pic.twitter.com/yrZiuPiQcB— Kenji Yoshida (@xuwei_k) 2018年3月1日 おそらく日本初のSwift NIO記事ではないでしょうか？(どうでもいい) "雑に比較" とは、同じようなclass存在してるのを列挙してみる、などをするだけです。 作者同じなのだから、似ているの当たり前だし、そもそもswift NIOのNOTICEに以下のように書いてあります。 https://github.com/apple/swift-nio/blob/b81ae9a4b0087235880927cd

togetter.com 面白い挙動だけど、さすがに自分が本当に最初に見つけた、というのもなにか違う気もするので、あのScalaパズルの本や、どこかのブログにこれ載っていたりしないんですか？

sbtというと、独特なSettingのシステム*1や、Scalaで記述する内部DSL*2ばかりが注目されがちです。それらは、初心者にわかりづらかったりして批判されることが多かったり、逆にsbtを使い慣れた人にとってはとても強力で面白い仕組みです。 Settingのシステムに注目すると、汎用的に色々な言語のビルドにも使えそうに思えます。事実、sbtでC++のpluginを作っている人もいます。 しかし、sbtはあくまで「Scala(とJava)のためのビルドツール」です。 これは「単にScalaをデフォルトでサポートしてる」という意味にとどまらず、おそらく皆さんが思っているよりもずっと深い意味で「Scalaに特化したビルドの仕組み」が内部に備わっています。 今回は、そんな「sbtの内部アーキテクチャ」の紹介をします。 以下、かなり長いです。読み物としては面白いかもしれませんが、単にsbtを使

以下経緯 togetter.com github.com それで、tweetしていた件 「compiler の bridge に互換なくなった場合でも最低限コンパイル可能なような、インクリメンタルコンパイルを一切行わない、scalacのmainに直接引数渡してコンパイルするだけのモード」 が70行ちょっとのコードで出来たので、貼り付けておきます。 ログの処理とか成功失敗の判断などがとても雑というか、何もしてないですが、全てのオプションをちゃんと渡して、依存ライブラリのpathも渡して(わりと勝手に渡ってくる)、classファイル生成先ディレクトリくらいは正しく設定したので、最低限使えると思ってます。 キャッシュを一切考慮しないので、全くソースファイルに変更がなくても、毎回classファイルをディレクトリ丸ごと削除して全コンパイルします。 ただし、これはあくまで「やってみたらできたので貼り付

以前同じようなものを書いたけど、それがもう2年くらい経過してるので、また書きました xuwei-k.hatenablog.com xuwei-k.hatenablog.com まず、このblog書いてる時点でのGitHubでのstar数での順位 1 https://github.com/playframework/playframework 9900 2 https://github.com/twitter/finagle 6088 3 https://github.com/spray/spray 2533 4 https://github.com/scalatra/scalatra 2230 5 https://github.com/twitter/finatra 1645 6 https://github.com/finagle/finch 1115 6 https://github.

finally (๑•̀ㅂ•́)و✧https://t.co/Y52DVWOBQT pic.twitter.com/b6tYt6Aish— Kenji Yoshida (@xuwei_k) 2017年11月12日 むしろ今までなぜ1位ではなかったのか？というくらいには貢献していたわけですが(4年連続コミット数1位なので)。 昨日(2017/11/11)までは、retronymさんという、scalaz 7の仕組みをほぼ１人で作った人が１位にでした。retronymさんはここ数年はずっとlightbendのScalaコンパイラのチームで中心となってコンパイラ頑張ってる人です。 自分の1位がどう、とかいうより、4年もかからないと超えられないほどに色々頑張ってくれてたretronymさんすごいな、みたいな感想です。 さて、scalaz 7.0.0がリリースされたのが2013年4月なので、7系はもう

Scalazのコミッター、もしくはScalazを使いこなしているような関数型ガチ勢からみると、ある程度以下の様な共通認識*1がある気がする(けどあまり知られていない?)ので、ちょっとまとめてみました。 関数型ガチ勢ではない一般のScalaユーザーの間では、あまり疑問も持たずにそれなりに使われているものが多い気がします 個人的には、以下で紹介するものを「絶対使うな」とも思いません。*2が、しかしこれらのものに対して「アンチパターンとは言わないけど、デメリット多いし代替手段あるよね」という意見の人が少なすぎる気がするし、もうちょっとその辺りの議論がされるべきではないかなぁーと思い、あえて「アンチパターン」と言ってみました。 タイトルにScalaを入れましたが、厳密にはScalaに限らない話だと思います。ただし、「JVMで動く静的型付き関数型言語」という状況により、ある程度Scala特有の状況な

gistに書いたものを、ほとんど書き写すだけの簡単なお仕事(｀・ω・´) 以下が最新版をゴニョゴニョしてみた結果。(このblog書いている時点の最新の安定版である) 2.9.1で同じことやろうとすると def withFoo(foo: Foo): foo.Bar = foo.f という部分がコンパイル通らないはず。fooという 引数 の抽象型であるBarに依存した型だからっていう感じ? 追記: 例としての自分の書いたコードが適切なのかどうかあやしい気がしてきたがががが(´・ω・｀) StackOverflowの解説がかなり詳しいのでちゃんと知りたい人はそっち読んで！(ぉぃ 以下参考URL StackOverflowの解説がなぜかやたら詳しい このコミットらしい gist上でのちょっとした議論 そして、こんなこと言ってたら #Scala で新しく入る予定の depend type がなんとな

これ ドワンゴScala勉強会で学んだ、ハイブリッド言語「Scala」の魅力 twitterでつぶやいたけど コメント書くとこない？オリジナルのPhantomTypeと微妙に違う気がするんだががががが。これもありといえばありかもしれんが、どうなんだろう？ #Scala URL ドワンゴScala勉強会で学んだ、ハイブリッド言語「Scala」の魅力 2011-12-06 21:40:11 via web さっきのあれによりPhantomTypeについて考えなおしているが、やっぱりなんかモヤモヤするなぁ。フィールド全部変えるならべつにPhantomTypeじゃなくて違うClassのインスタンスでいいし、implicit使わないんだったらScala以外でもできるしだいぶ違うものな気が 2011-12-06 22:46:15 via web そして、例が謎ぃので Java で書いてみたら書けちゃっ

前回に引き続き第3回もいってきました。そのときにでた話題についてちょっと書こうかとおもいます。 using文 C#にusing文*1という制御構造がありますが、scalaでは、同じようなものを簡単に作れます。C#のほうのusing文については詳しく触れませんが、これからかくようなusing文について、個人的に思う利点としては、 本体と例外時の処理を分けて書けるので、コードが読みやすくなる リソースの開放のし忘れが起きにくい どこからどこまでリソースを使用しているのかが、読む側としてわかりやすくなる 解放後のリソースに間違ってアクセスする心配がない。(スコープがそもそも限定されるため) などでしょうか？この、scalaでのusing文の制御構造の作り方なんて結構よく例としてあげられるものですが、あえて詳しく書いてみようと思いますww で、その第3回勉強会でのソースを引用させて頂きます（・∀・

色んなScalaプロジェクトにpull request送りつけ過ぎた結果です。( 去年502個 ) https://twitter.com/rossabaker/status/799727645634297856 https://github.com/finagle/finch/pull/726 OH doesn't even have a commit from @xuwei_k yet, so not a serious Scala project 2016-11-19 06:35:03 via Twitter for Android circe is finally a real Scala project! URL /cc @rossabaker 2016-11-28 23:39:39 via Twitter Web Client to @rossabaker @travisbro

ついにバレてしまったか・・・(ぇ 猫のgitterで @xuwei-k are you an awesome functional programming robot sent to us from the future? or are you a human? という、謎な褒められ方(?)をしていました。 https://gitter.im/non/cats?at=55fd1c310ed44a00046effbf これからは「未来から送られて来た関数型プログラミングロボット」という設定で生きていこうと思います、よろしくお願いします(?)