タグ

ブックマーク / xuwei-k.hatenablog.com (5)

  • Scalaでバイナリ互換を維持しながらのプロジェクト運営 - xuwei-k's blog

    json4sでせらさんが頑張ってくれるらしいけど、どこにも(たぶん英語でも)まとまった知見ないはずなので、とりあえずscalazの知見をもとに、まとめておく 最新開発版のbranchをつくってそちらをメインにしておく それ以外のやり方もありえる(scala体)が、たぶん開発版(バイナリ互換維持しないほう)をメインにしておいたほうがよい。 具体的には、json4s 3.3ブランチがバイナリ互換維持するなら、3.4か4.0ブランチを作っておく scalazだったら、これ書いてる現在 series/7.2.x が開発用 series7.1.x がバイナリ互換維持しつつメンテする用 上記のbranch戦略をREADMEか何かに書いておき、pull reqは基的には開発branchのみで受け付ける(両方で無造作に受け付けるとややこしくなるので) 万が一、間違って互換維持するほうのbranchで、

    Scalaでバイナリ互換を維持しながらのプロジェクト運営 - xuwei-k's blog
    no8410
    no8410 2015/10/04
  • ScalaでOperational Monadを使って作ったAPI clientの内部実装の解説 - xuwei-k's blog

    気が向いたら書く、と言っていた解説を書きます。 Operational Monadを使用した最初のversion0.2.0を出してから、色々機能追加したり試行錯誤したりして、結構変わっています。その辺りの試行錯誤や経緯も少し含めて、内部の実装や設計の説明を書きます。 https://github.com/xuwei-k/ghscala まず最初に、自分が作ったgithub API clientの中で、Operational Monad以外に使われているScalazの機能一覧を挙げてみます。このあたり知らない人は、まずこれらを勉強したほうがいいかも*1 Monad始めScalazの基的なこと NaturalTransformation http://d.hatena.ne.jp/xuwei/20130912/1378984786 Scalaz独自のEither EitherT(Either

    ScalaでOperational Monadを使って作ったAPI clientの内部実装の解説 - xuwei-k's blog
  • 時代はリテラルレベルプログラミングだ! - xuwei-k's blog

    リテラルレベルプログラミングという用語が存在するのかは知りませんが、べつに厳密に定義せずなんとなく使います。まぁこれ https://github.com/okomok/lity の説明が "Exploring literal-level metaprogramming" なので、そこから拝借という感じですかね。 さて、scalaでは、StringやIntのリテラルでfinal valで定義すると、型自体が特別扱いされる(?)という、知られざる仕様があります。まずは以下のgist御覧ください finalを付けずに val a = "a" だと型は a: String = a なのに対して、final valにすると b: String("b") = b というよくわからない型になってますね。そして def foo(c: b.type) と定義すると、foo("bar")と渡すとコンパイルエ

    時代はリテラルレベルプログラミングだ! - xuwei-k's blog
    no8410
    no8410 2014/07/17
    こわい
  • 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); }

    Javaの10個のBad Partsのほとんどはscalaだと解決されちゃうんだぜ - xuwei-k's blog
    no8410
    no8410 2013/11/09
  • Scalaにおける細かい最適化のプラクティス - xuwei-k's blog

    列挙順自体はとくに意味ありません。あと「どの最適化がどのくらい速くなるのか?」を詳細に計ったことはないですし、「原理的にこうなってるから(ry」というのを説明するに過ぎません。中には「JITで無意味になるようなどうでもいい細かすぎること」も書いてありますし、最適化のトレードオフとして失うものもあるので、そのあたり自己責任でお願いします。当に最適化が必要とされる場合は、以下のものを無闇に実行するよりまず計測したほうがいいのは、言うまでもありません。*1 1. private[this]をつかえ scalaのvalやvarは、private[this]にしたときのみ、直接のフィールドアクセスになります(それ以外ではメソッド呼び出し)。シングルトンのobjectの場合も同様です。private[this]をつけられる場合はできるだけつけましょう 2. なんでもかんでもListをつかうな 最初の

    Scalaにおける細かい最適化のプラクティス - xuwei-k's blog
  • 1