xuwei[B!]新着記事・評価 - はてなブックマーク (original) (raw)

3 users
xuwei-k.hatenablog.com
昨日の続き xuwei-k.hatenablog.com 昨日のcheckするだけのものは数秒で終わるのですが、これは手元で compileに2分くらい かかります。 速度に関して改善の余地があるのかどうか？はわかりません。 改善したら、問題が簡単なら数秒で終わるようになりました。 いくつかtweetしましたが、compilerの限界なのでは？と思ったけれど、頑張った結果、いくつかは自分のミスでした。例えば 割り算するべき箇所で余りを取っていた scala.compiletime.ops.any.== は、singleton同士ではないと比較不可能。例えば (1, 2) と (3, 4) といったTupleのまま比較不可能なので、自前でsingletonになるまで必要に応じて再帰的に分解しつつdeepなequalsを実装する必要がある(つらい) 複雑になり過ぎると、上記のようなミスをした場

25 users
xuwei-k.hatenablog.com
なんかtweet流れてきたので TypeScriptの型がどれほど強力かというと、コードエディタ上で直接数独ができるほどの複雑な型を作成した方がいるほどです。このSudoku型を使用すると、TypeScriptの型チェッカーが間違いを正確に指摘してくれます。 pic.twitter.com/mCXXjGqK9D— Jeffry Alvarado (@jalva_dev) September 7, 2024 github.com Scala 3のmatch type自体の詳細な説明は省略しますが、compile時計算的なことができて、チューリング完全です https://tarao.hatenablog.com/entry/lambda-scala3 あくまで答えがvalidか？のcheckerだけで、プレースホルダー部分実装してない それも実装しました。下記に貼った 少なくともIntell

3 users
xuwei-k.hatenablog.com
個人的に、すごい細かい使い捨て含めるとおそらくもう1000個くらいはrule書いたことあるので、おそらく現状では日本一scalafix rule書いていると思うのですが、 慣れるとそのくらい気軽に書けてすぐ役に立って便利なので、既存の他人が書いたruleを使うだけではなく、独自に書くことを強くすすめていきたいです。 しかし、それにあたって、sbtのproject構成が思ったより面倒なので、それの解説をします。 タイトルの通りあくまで「同じsbt project内部に置く」場合の話をします。 gitやsbtのprojectそのものを完全に分けてしまえば、もちろん考えることが減って楽になる点もありますが、分けることによるデメリットもあるので、個人的には(scalafixに限らないですが)わりとmonorepoというか、同じprojectで頑張ることを推奨したいです。 (OSSにはしないような社

15 users
xuwei-k.hatenablog.com
継続的にメンテナンスするのではなくて、雑な使い捨てでいいならshellscriptとjq職人芸でいけるので頑張ってしまったけれど、継続的にやるならもっと違うもので書いた方がメンテナンスしやすいと思います。 細かい部分はいくらでも改善の余地があるとは思いますが、とりあえず動いたのでヨシ・・・!? 以前も多少似たような何か作ったけど、こういうの誰か既にもっと綺麗に作ってないんですかね。 xuwei-k.hatenablog.com GitHub Actionsのログはデフォルトでは90日保存されてるはずなので、その程度の期間をなんとなく集計したいだけならば、こうやって後から集計するだけで十分ですね。 もちろん、yamlの内部の構造がすごく変わっていると集計が難しいか実質不可能になるリスクはありますが。 もっとしっかり計測したいならば、buildした時点で専用の場所に綺麗に記録して、他のもっとリ

14 users
xuwei-k.hatenablog.com
すごく重要な予定が色々と決まりつつあるので、独断で勝手に？雑に？選んで紹介しておきます。 単なる翻訳というよりは、自分の感想や主観みたいなものが入ってます。 詳細な原文を知りたい人は、以下のあたりを読んでください https://github.com/playframework/playframework/blob/80da98b0352e1d3e7e1ba034ec9c5e4c15e1cb3e/documentation/manual/General.md https://github.com/playframework/playframework/blob/80da98b0352e1d3e7e1ba034ec9c5e4c15e1cb3e/documentation/manual/releases/release29/migration29/Migration29.md https://

31 users
xuwei-k.hatenablog.com
switch式の結果javapしたらhttps://t.co/xMc0YEYsrg java.lang.runtime.SwitchBootstraps と tableswitch が使われることに気がついたが、これ巨大なswitch式をJDK 21以降で書いた場合、同等の巨大なmatch式をScalaで書くよりも速度が速い可能性があるのでは？？？ これScalaで活用できるか？というと— Kenji Yoshida (@xuwei_k) September 25, 2023 switch式の結果javapしたら https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/runtime/SwitchBootstraps.html java.lang.runtime.SwitchBootstraps と ta

14 users
xuwei-k.hatenablog.com
ScalaでもJavaでも、overrideする際に、sub typeでoverrideすることが可能です。 (すごく古い1.4以前のJavaでは不可能だったはずだが) Javaの仕様書で英語だと covariant return type というはず？の機能です。 https://docs.oracle.com/javase/specs/jls/se11/html/jls-8.html#d5e14373 $ jshell | Welcome to JShell -- Version 17.0.6 | For an introduction type: /help intro jshell> interface A { Object a(); } | created interface A jshell> class B implements A { @Override public St

9 users
xuwei-k.hatenablog.com
Scala 3のmatch typeで何かのparserでも書くか?と思ったけど、コンパイル時にリテラルのStringを、型情報というか分解した場合の値情報？を、保ったままの分解が単純には出来そうにはないというか… あるいは一旦CharのHListにしたいんだけど、何か方法あるのかな— Kenji Yoshida (@xuwei_k) February 28, 2021 https://t.co/sNupBRy3rV type Substringが増えてるからいける…？— Kenji Yoshida (@xuwei_k) 2022年2月28日 できました。 parserなどに慣れてないので、とりあえず以下のクソ雑仕様？だけど、tokenにするのとparseとevalをなんとなくちゃんと分けたぞ！ みんなScala 3のmatch typeで、任意の言語などのparserや評価機を書こう！！

3 users
xuwei-k.hatenablog.com
というのを作った。 仕事で自分が関わっている特定のリポジトリでは、以前からそういうの作ってbotがpull reqに直接コメントするようにしている。(自分のものだけではなく、そのリポジトリのpull req全てに対して) そうではなく、自分が出したOSS含めた任意のpull reqでconflictしていたら通知欲しいので、作った。 https://github.com/xuwei-k/cron/commit/17c9c731593ce5de9178fabdb26c088631d74e74 通知先はとりあえずslackにしたが、ここはメールでもなんでも、好きものでいいと思う。 自分のJavaScriptの能力はゴミなので、明らかにリファクタ出来そうだけれど、とりあえず動いたので一旦妥協した。 改変して使う際は q のauthor部分は、直接埋め込んであるけれど、自分のgithubのidに変

3 users
xuwei-k.hatenablog.com
ここでいう最新技術とは以下です。 JDK8や11よりも、17の方が速い？ M1 Macが速い？(2021年最新のM1 Maxではなく、2020のMacbook Pro 13インチのM1です・・・。M1 Max欲しい！！！ => 最後に追記したぞ) Scala 2より3の方が速い？ 自分の最近の経験上、それらが速いはず？なので。 上記は、全部場合による(projectによる)かもしれないし、あまり変わらないパターンも含まれているかもしれませんが、とりあえず一部(Scala 2自体のcompile)を除いて、上記の条件でコンパイル速度を計測してみたら、 数年前の感覚と比較して結構速い感じがあったので、それの計測結果の共有です。 個々の条件をもっと細かく変えるのは、組合せ爆発して辛いので、誰か気になった人はやってみてください。 何年も前と比べるとsbtでの依存解決もだいぶはやくなったし、ビルド速

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

11 users
xuwei-k.hatenablog.com
最初に結論 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

19 users
xuwei-k.hatenablog.com
3割というのは、もちろんprojectの構成だったり、計測方法やその他色々によるわけですが、とにかく自分が計測した場合には3割短縮されました。114秒が80秒になりました。 pipeline機能自体の説明は最後に書きます。先に、測定方法や具体的な結果。 測定方法 travis-ci上で、他の条件を同じにして clean update test:compile を(50分制約でtimeoutするまで)ひたすら繰り返して test:compile にかかった時間(sbtが [success] 表示する)を計測、集計する JVMの暖まりを考慮して 上記のサイクルを繰り返すにあたって、sbtは起動させたまま 最初は遅くなるので、ある程度遅かった最初の8つは除いて、それ以外で平均や中央値を計算 測定に使ったのは、このblog書いてる時点でのscalazの最新master branch(7.4.x用)

6 users
xuwei-k.hatenablog.com
見た目通りで、あまり難しくないので、特に説明することがない。 macroさえ使わずに書けますね。 shapelessにあったような色々な機能が標準で装備されています。 みなさん、Match Type使ってもっと複雑な色々な計算書いてみましょう。 ちなみに、この単純な実装だと、大きい数渡すと(コンパイル時に)大変なことになるのでご注意ください。 plugins.sbt addSbtPlugin("ch.epfl.lamp" % "sbt-dotty" % "0.4.1") build.sbt scalaVersion := "0.26.0-RC1" Main.scala package example import scala.compiletime.ops.int.{-, +} import scala.compiletime.testing.{typeChecks, typeCheckE

5 users
xuwei-k.hatenablog.com
Graalについて全然詳しくないので、Graal自体の説明はしません、というかできませんが、JDK10以降で -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler というオプションを付与すると有効にできるらしいですね。 というわけで、以下のような条件で計測した結果、結果からいうと13%くらい速く(コンパイル時間が短く)なりました。 scalazの現状の最新masterで計測 https://github.com/scalaz/scalaz/tree/9369d23137d29c1490ccb72a83c8f76dc873285a 他の条件を基本的に同じにして、travis-ci上で適当に10回くらいclean update compileをsbtを起動したまま繰り返し実行して、sbtが表示したcompileの部分の時間計測 他の条件が

5 users
xuwei-k.hatenablog.com
CircleCIにおけるキャッシュの仕組みというか仕様は、他のCIサービスと比べると、少し変わった特徴がある気がします。 といっても、自分は他にはTravisCIくらいしか詳しくないので、実はCircleCIのように色々工夫している方がむしろ最近は主流な可能性もありますが、そこは本題ではないし、詳しくもなく話せないので話しません。 まずは、公式ドキュメントがしっかり書かれているので、それをざっくりと読んでみてください。 circleci.com 完全に理解する必要はないですが、ある程度読んでいる前提でこの先の話は進めます。 *1 また、以前書いた件は依存ライブラリのみならずjob(?)をまたいだときにclassファイルやインクリメンタルコンパイルの情報を丸ごとキャッシュする話でしたが、 xuwei-k.hatenablog.com 今回はあくまで依存ライブラリのキャッシュだけについて話すの

12 users
xuwei-k.hatenablog.com
いきなり本題というか、一番言いたいことを書くと、まず テストの fork の設定によってぜんぜん違う。 という点があまり知られていない気がします。 *1 というか、自分も今回調べるまで、微妙に古い知識のままで完璧に知らなかったので、今一度理解した現時点での詳細を今書いています。 sbtにおいて、テストがどう並列化されるか？に関して、関係するというか、今回話すのは、以下の点です Test / parallelExecutionというkey Test / fork が true か falseか concurrentRestrictionsというkey testForkedParallelというkey また、今から話すのはsbt 1.3.8時点の情報です。 さらに前提として、マシンのCPUのコア数によって挙動が異なる可能性がありますが、ひとまずそれなりに十分にコア数がある、として話を進めます。

3 users
xuwei-k.hatenablog.com
以下のような質問を某所で受けたので 書きました gist.github.com 既にあるとか、もっといい感じに書ける、みたいなのがあればお知らせください。 ちなみに、デフォルトでは単体のprojectしかcleanしないのは、完全にsbt的には意図した挙動のはずです。 デフォルトが今回自分が書いたような挙動では、逆に特定の単体のprojectだけをcleanしようとすると手段がなくて困るので。とはいえ、その手段が提供されていればデフォルトのcleanの挙動がそっちでも困らない？といえるかもしれませんが。 > もっといい感じに書ける、みたいなのがあればお知らせください。 自力でloopしなくても、classpathTransitiveRefsを使えば同じことできそうです。 val ref = thisProjectRef.value (ref +: buildDependencies.val

26 users
xuwei-k.hatenablog.com
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-

26 users
xuwei-k.hatenablog.com
前回↓ "2月になったくらいのタイミングでまた別途書きます" と言っていたやつです。 xuwei-k.hatenablog.com 今日、2019年2月1日が初出社でした。 Scalaをやってる企業としての知名度だと、おそらく前職に比べたらそこまで有名ではないかもしれませんが、それなりにやってるらしいです。 もちろん(?)、全部の部署がScalaではなく、自分が関わることになる部署を中心に一部で、会社全体でいうとおそらく今のところはScalaは少数派だとは思います。 一応、会社的な色々を説明しておくと リクルートは数年前まで大きい一企業だったけど、いくつかに分社化された。そのうちの一つが リクルートマーケティングパートナーズ 。*1 Quipperという企業を数年前？に買収して、教育関連のサービスはそことも関わるので、自分もそことも関わるのだが、ここでこれ以上詳細を説明してもしょうがないの

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

35 users
xuwei-k.hatenablog.com
以下、普段と違いプログラミングの話題があまり出てこない、あくまで個人が育児休暇取った話を書くだけなのでご注意(?)ください。 最後の方に少しだけプログラミングの話出てきます。 まず時系列での大まかな流れ 2月後半に生まれる ↓ 妻の入院中は数日休んで、病院通ったり役所行くなどする ↓ 3月いっぱいまでは働く(妻はそのあいだ妻の実家) ↓ 4月から半年間育児休暇 ↓ 9月いっぱいまで休みで、10月から復帰予定 (ｲﾏｺｺ という感じです。 そもそも育児休暇とは？とか、そのあいだのお金のこととか、ググればいくらでも正確なわかりやすいサイト出てくるはずなので、詳細に説明はしませんが、簡単に書くと 国が決めてる制度なので、原理的には会社によらず、一定の条件(一定期間勤務してるなど)を満たしていれば、男女関係なく1年くらい取れる(細かいことはもっと色々ありますが) その間の給料は"会社からは"出ない

24 users
xuwei-k.hatenablog.com
ここでいう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位なのでは (

3 users
xuwei-k.hatenablog.com
4年以上前に買ったものを買い替えました。計測条件は後で書くとして、雑な結論を先に書いておくと 30%くらい速くなった 相変わらずCPUの1コアあたりのクロック数がボトルネック？(本当にそういう理由なのか、あまり自信ない) CPUのコアを使い切っている感じではなさそうだった。つまり現状ではコア数に比例してスケールはしなそう。 軽く見た限り、JVMのwarm up時にCPU多めに使っている感じで、本当の計測時はそこまで多く使っていなく(?)、CPUのグラフがギザギザだった。 メモリを増やしたからといって、それに比例してはやくなったりはしなそう(それほどちゃんと計測してない)。ただ、2GBから12GBくらいに増やしたら、1〜2割速くなった気もする。GCの回数が減った分？ (そもそも、メモリ量に 比例して速くなる プログラムの方が圧倒的に少なそう) 少なくとも今回の計測では、SSDの性能も特に影響

4 users
xuwei-k.hatenablog.com
最初sbtにissueたてるか、などとtwitterで言っていたけれど、そんなに困っている人多くなさそうだし、blogにだけまとめておけばいいか、という気持ちになったので、ひとまずまとめておく。 まず、TLS 1.1以前のサポート打ち切りました、という記事は以下。 jfrog.com blog.sonatype.com 主にビルド時のことに焦点をおいて書きますが、別に実行時にmaven centralやその他TLS 1.1以下をサポートしなくなったサイトにhttpsでアクセスするプログラムは、同様の問題が起きるはずです。 また、自分は普段ほぼsbtしか使っていませんが、gradleやmavenやantなど全部のJava製のビルドツールで同じはず？ Java6 TLS 1.2をサポートしていないらしいので、基本的にJava 6上でビルドツールを動かして、httpsでライブラリをダウンロードす

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

11 users
xuwei-k.hatenablog.com
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

19 users
xuwei-k.hatenablog.com
Java 9が広まってきて、しかし多少古いScalaやsbtのままやろうとしてハマっている人を見かけることが多くなってきたので、簡単にまとめておきます。 (追記) Java 9となっているところは、Java 10やJava11と置き換えても大体当てはまります。つまりJava8からJava9のclasspath関連の変更が一番重大で、逆にJava9で動けばJava10や11でも動く場合が多いので。 Java 9 で動くScala(のコンパイラやREPL) 2.9系以前は不可能 2.10系はScala 2.10.7以降なら可 2.11系はScala 2.11.12以降なら可 2.12系はScala 2.12.1以降なら可 *1 2.13系はマイルストーン含めて全部可 Java 9 で動くsbt sbt 0.12系以前は不可能(0.12系はScala 2.9系なため) sbt 0.13系はsbt

35 users
xuwei-k.hatenablog.com
以前同じようなものを書いたけど、それがもう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.

次のページ