自分が出したpull reqがconflictしていたら通知するGitHub Action君 - xuwei-k's blog
というのを作った。 仕事で自分が関わっている特定のリポジトリでは、以前からそういうの作ってbotがpull reqに直接コメントするようにしている。(自分のものだけではなく、そのリポジトリのpull req全てに対して) そうではなく、自分が出したOSS含めた任意のpull reqでconflictしていたら通知欲しいので、作った。 https://github.com/xuwei-k/cron/commit/17c9c731593ce5de9178fabdb26c088631d74e74 通知先はとりあえずslackにしたが、ここはメールでもなんでも、好きものでいいと思う。 自分のJavaScriptの能力はゴミなので、明らかにリファクタ出来そうだけれど、とりあえず動いたので一旦妥協した。 改変して使う際は q のauthor部分は、直接埋め込んであるけれど、自分のgithubのidに変
今までありがとうTravis CI、さよならTravis CI - xuwei-k's blog
しっかり調査してないですが、こういったCIサービスがほぼ存在しない時期にほぼほぼ最初に登場して、一時期明らかにデファクトスタンダードだったと思うので、昔からOSS活動している人ほど、とても多く利用してお世話になっていたと思うので、そういう人であればあるほど、この状況は、怒りではなく、悲しいというか残念というか、辛いと思うんですよね・・・。 今までありがとう・・・。 長年Travis CI使ってきたので、GitHub Actionsによって潰される(のかどうなるのかわからないけど)、の可愛そう、という気持ちが若干あるけど、とはいえ、こういうのよくある話な気はするな…— Kenji Yoshida (@xuwei_k) 2020年10月7日 買収されて方針変わったのかなと感じるところもありますし、OSSプロジェクトが無料で使っていても会社としては辛いのではという気もするので今までの感謝の気持ち
ドワンゴを退職しました - xuwei-k's blog
4年11ヶ月勤めたドワンゴを退職しました。2019年1月17日が最終出社日で、1月中は有給休暇消化期間で、2月から新しいところで働きます。 4年11ヶ月と書きましたが、半年間育児休暇をとっていたので、その期間を引くと実際働いたのは4年5ヶ月です。 4年制の大学(の文学部書道学科)を卒業して、新卒でとある会社に就職して、いろいろあってドワンゴは4社目でしたが、それ以外の会社で最長で2年程度しか勤めたことがなかったので、そう考えると5年近くも続いたのが感慨深いですね。 このblogを読んでいる人ならばある程度の人は知っているかもしれませんが、気づいたら個人的にScalaにとても詳しくなってコミッターにもなって、ドワンゴでの仕事も、ほぼずっとScala書いていました。 もちろん、デプロイツールやちょっとした管理ツール、細かい運用上のなにかで、多少Python, ansible, shell sc
Javaの10個のBad Partsのほとんどはscalaだと解決されちゃうんだぜ - xuwei-k's blog
ネタ元 業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策 結論から先に言うと、3と10以外は結構直接的にscalaで解決できるというか、javaに比べてscalaの方が便利だとおもいます。*1 あと、元ネタのblogの人はgroovy詳しいみたいですが・・・ groovyとscala比べるとgroovyの方が手軽で便利だったり、scalaのほうが型安全だったり*2いろいろあるかもしれませんが、groovyあまり詳しくないので、その辺の言及というか、比較はやめておきます。*3 1.標準APIのチェック例外が扱いにくい チェック例外ってなにそれおいしいの?(・ω・) java Field field; try { field = getClass().getField("testField"); Object value = field.get(this); }
HaskellのGADTsすごいなーと思ったのと、それをscalaz.Leibniz使って頑張る話 - xuwei-k's blog
まず、下記の10行程度のScalaコードをご覧ください sealed abstract class Foo[A, B] final case class X[A]() extends Foo[A, A] final case class Y[A, B](a: A, b: B) extends Foo[A, B] object Main { def hoge[F[_, _], A, B, C](foo: Foo[A, B], bar: F[A, C]): F[B, C] = foo match { case X() => bar case Y(a, b) => ??? // Yの場合のコードはどうでもいいので } } これは、コンパイルエラーになります(Scala2.11.1)。しかし、HaskellでGADTs使って同様のコード書くと、コンパイル通るらしいです。これの話をします。*1 Sc
関数型ガチ勢から見たScalaのアンチパターン - xuwei-k's blog
Scalazのコミッター、もしくはScalazを使いこなしているような関数型ガチ勢からみると、ある程度以下の様な共通認識*1がある気がする(けどあまり知られていない?)ので、ちょっとまとめてみました。 関数型ガチ勢ではない一般のScalaユーザーの間では、あまり疑問も持たずにそれなりに使われているものが多い気がします 個人的には、以下で紹介するものを「絶対使うな」とも思いません。*2が、しかしこれらのものに対して「アンチパターンとは言わないけど、デメリット多いし代替手段あるよね」という意見の人が少なすぎる気がするし、もうちょっとその辺りの議論がされるべきではないかなぁーと思い、あえて「アンチパターン」と言ってみました。 タイトルにScalaを入れましたが、厳密にはScalaに限らない話だと思います。ただし、「JVMで動く静的型付き関数型言語」という状況により、ある程度Scala特有の状況な
関数を扱えるだけでは、モナドを表現するには不十分過ぎる - xuwei-k's blog
つまりなぜかいきなり高階型の話です。 これ 関数を扱えることはどのようにプログラミング言語の能力をあげるか に対する便乗というかツッコミとして。 つい先日もある人がこんなこと https://twitter.com/koropicot/status/365014333413011457 を言っていて*1、「ですよねー」と勝手に納得していたりしましたが。 つまりScalazでよくみるような高階型 trait Monad[F[_]] extends Applicative[F] { implicit val listMonad = new Monad[List]{ がないと、モナドとして抽象化や共通化ができない、という話です。*2 高階型についてはたとえばこれ (もりそば)Scalaによる高階型変数 - Higher-kind Generics とか読んでください。 関数がオブジェクトとして扱
Scalaにおける細かい最適化のプラクティス - xuwei-k's blog
列挙順自体はとくに意味ありません。あと「どの最適化がどのくらい速くなるのか？」を詳細に計ったことはないですし、「原理的にこうなってるから(ry」というのを説明するに過ぎません。中には「JITで無意味になるようなどうでもいい細かすぎること」も書いてありますし、最適化のトレードオフとして失うものもあるので、そのあたり自己責任でお願いします。本当に最適化が必要とされる場合は、以下のものを無闇に実行するよりまず計測したほうがいいのは、言うまでもありません。*1 1. private[this]をつかえ scalaのvalやvarは、private[this]にしたときのみ、直接のフィールドアクセスになります(それ以外ではメソッド呼び出し)。シングルトンのobjectの場合も同様です。private[this]をつけられる場合はできるだけつけましょう 2. なんでもかんでもListをつかうな 最初の
Functional Programming in Scala の感想 - xuwei-k's blog
http://www.manning.com/bjarnason https://github.com/pchiusano/fpinscala 一年ちょっと前にblog書きましたが Scalaz の作者の人達が書いた "Functional Programming in Scala" という本がでるらしい 14章のぞいてほぼ完成したので、感想書きます。MEAP v9の時点です。ちょっと長いですよ。 まず、全体を通していえるのが、Scalaの本ではなくあくまで関数型プログラミングの本だということです。それは本文の最初の方にも書いてあります。 この本だけ読んでも、Scala自体にはあまり詳しくなりません。Scala自体については、必要最低限の文法だけを随時説明してます。 逆に、(英語が読めるなら)Scalaの知識がほぼゼロだとしても、大体読めるのではないかと思います。 また、Scalazの本で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
