サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
今年の「かわいい」
xuwei-k.hatenablog.com
よく「どうやって情報手に入れてるの?」みたいに聞かれますが、そんなの、ひたすら時間かけてgithubみたりメーリングリスト読んだり最近ではgitterの会話読んでるに決まってます。 どうやって(How)ではなく、なぜ(Why)、自分がそんなことをするようになったのかを、あらためて書いてみる気になったので書いてみたいと思います。 書こうと思ったのは、Howだけ書いても、Why書かないとあまり意味ないと思うことが多くなったからですかね。(この件に関しては) 無責任に大雑把にいうと、(どんな理由であれ)情熱みたいなものがあれば、Howは自然に身につきます、たぶん。 なお、少し長くなるし、自分語りっぽくなるし、いつも書いてるようなものとは少し方向性が違い、具体的なすぐ役に立つ技術的な内容*1は基本出てこないので、期待してるものが違うと思う人は、ここで読むのやめたほうがいいと思います。 どれほどコー
4年11ヶ月勤めたドワンゴを退職しました。2019年1月17日が最終出社日で、1月中は有給休暇消化期間で、2月から新しいところで働きます。 4年11ヶ月と書きましたが、半年間育児休暇をとっていたので、その期間を引くと実際働いたのは4年5ヶ月です。 4年制の大学(の文学部書道学科)を卒業して、新卒でとある会社に就職して、いろいろあってドワンゴは4社目でしたが、それ以外の会社で最長で2年程度しか勤めたことがなかったので、そう考えると5年近くも続いたのが感慨深いですね。 このblogを読んでいる人ならばある程度の人は知っているかもしれませんが、気づいたら個人的にScalaにとても詳しくなってコミッターにもなって、ドワンゴでの仕事も、ほぼずっとScala書いていました。 もちろん、デプロイツールやちょっとした管理ツール、細かい運用上のなにかで、多少Python, ansible, shell sc
しっかり調査してないですが、こういったCIサービスがほぼ存在しない時期にほぼほぼ最初に登場して、一時期明らかにデファクトスタンダードだったと思うので、昔からOSS活動している人ほど、とても多く利用してお世話になっていたと思うので、そういう人であればあるほど、この状況は、怒りではなく、悲しいというか残念というか、辛いと思うんですよね・・・。 今までありがとう・・・。 長年Travis CI使ってきたので、GitHub Actionsによって潰される(のかどうなるのかわからないけど)、の可愛そう、という気持ちが若干あるけど、とはいえ、こういうのよくある話な気はするな…— Kenji Yoshida (@xuwei_k) 2020年10月7日 買収されて方針変わったのかなと感じるところもありますし、OSSプロジェクトが無料で使っていても会社としては辛いのではという気もするので今までの感謝の気持ち
列挙順自体はとくに意味ありません。あと「どの最適化がどのくらい速くなるのか?」を詳細に計ったことはないですし、「原理的にこうなってるから(ry」というのを説明するに過ぎません。中には「JITで無意味になるようなどうでもいい細かすぎること」も書いてありますし、最適化のトレードオフとして失うものもあるので、そのあたり自己責任でお願いします。本当に最適化が必要とされる場合は、以下のものを無闇に実行するよりまず計測したほうがいいのは、言うまでもありません。*1 1. private[this]をつかえ scalaのvalやvarは、private[this]にしたときのみ、直接のフィールドアクセスになります(それ以外ではメソッド呼び出し)。シングルトンのobjectの場合も同様です。private[this]をつけられる場合はできるだけつけましょう 2. なんでもかんでもListをつかうな 最初の
コードレビューについて Oh, you `re no (fun _ → more) より引用 単に普段の開発で使っている VCS でそれを行なっていました。 つまり、コードの中にコメントの形でレビューを書き、それをコミットする。 そしてそこから派生する議論も全てコード上のコメントで行います。 (もちろん複雑な話になった場合は直接の議論を行い、合議の結果だけを記しておく、なども当然あるでしょう。) レビューをソースコードのコメントとして直接書き込むのは、GHC の開発でも時々見かけますね。例えば、新機能の開発 branch を作って、新しい機能を開発している時とか。 2012-08-14 18:44:19 via OpenTween まあ、主に入った変更に Simon Peyton Jones が(ソースコード上で直接)コメントしそれに従ってソースコードを修正する形なので、レビューと言えるほ
わざと両方のタイトルをblogのタイトルに入れてみました(ながい・・・) レビューに少しだけ関わりました。自分が翻訳したわけではありません。あくまでもレビューです 原著 Functional Programming in Scala Scala関数型デザイン&プログラミング ―Scalazコントリビューターによる関数型徹底ガイド (impress top gear) 作者: Paul Chiusano,Rúnar Bjarnason,株式会社クイープ出版社/メーカー: インプレス発売日: 2015/03/20メディア: 単行本(ソフトカバー)この商品を含むブログ (7件) を見る http://book.impress.co.jp/books/1114101091 作者達はおそらく訳されて今の時期にでることをあまり知らない?だろうから、知らせるのと感謝の意を伝えるtweet↓(そしてサンプ
ネタ元 業務系の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); }
以下の2つの続き ScalaでFutureとEitherを組み合わせたときに綺麗に書く方法 FutureとEitherの話の続き(ApplicativeとMonadの違い) 上記の2つ(特に最初の方)を読んだことを前提で書くので、読んでない人は先にそちらを読みましょう。 なんだか少し関連する話(?)で盛り上がっていて、書かないといけない気がしてきたので 非同期プログラミングの難しさとScalaのFuture そのtogetterの議論について色々書きたいこと*1もありますが、それは置いておき、表題の「モナドによる同期/非同期プログラミングの抽象化」について書きます。というか、(非同期プログラミングの話より)便乗してモナドとモナドトランスフォーマーの便利さを話したいだけかもしれません(?) 前回2つは「Future使って非同期にしても、だいたい関数の本体同じでいけるよ」ということを書きました
ScalaのWebフレームワーク事情 2015年版 - たけぞう瀕死ブログ Scala界隈のWebフレームワークやJsonライブラリは良くも悪くも混沌を極めている(?)わけですが、それにしても竹添さんが紹介してるやつだけでは個人的に不公平感というか、混沌としている感が全然伝わらないと思ったので、全部に詳しい訳ではいですが、自分なりに現状を書きたくなったので紹介しようと思います。 どうせ全部を本当に知り尽くしている人なんでいないので、これはこれで不公平というか偏った見方にもなってるかもしれませんが、そんなこと言ってたらこういう記事をいつまで経っても書けないので、思い切って書くことにしました。 いつもの注意書きですが、あくまでこれ書いてる2015年10月現在の状況であり、1年程度経過しただけで状況は劇的に変化する可能性あるので、ご了承ください。 そもそも、あまりこういうの書きたくないのは、わり
組み合わせるとはつまりアレのことを書くのですが、一応それほど前提知識無くても理解できるように書いてみます。さて、なぜいきなりEitherとFutureか?というと play2とか使ってると、Futureがよく出てくる Futureをそこら中でAwaitしたらFuture使う意味がないので、Future[A]をmapやflatMapなどでどんどん連鎖させて、メソッドの型にFutureが大量に出現! Futureは非同期に行われる処理であり、そこで例外発生したら、その中に例外を含むしかない(単純に例外投げるわけにはいかないというか不可能) Scala標準ライブラリのFutureは、Throwable型で例外を保持できるようになってる 逆にいうと、Throwableでしか保持できない 例外の種類が多くなってきて、プログラムが複雑になった場合、Throwableではなくもっと限定された独自のエラー
この度、1年10ヶ月ほど勤務した会社を退社*1することになりました。会社や一緒に働いた仲間達への謝辞の気持ちを表すとともに、今までのプログラマとしての人生を振り返って自分語りをしてみる、いつもと違った少し長めのエントリです。なお、ここに書かれていることは個人の見解であり、所属する(していた)組織の意見を代表するものではありません。 文学部書道学科卒という、ちょっと変わった学部をでてすぐに、新卒で、ある会社に就職しました。今年で社会人4年目の1986年生まれです。 もともと、学生時代にプログラミングはほとんど経験がなく、高校から大学はずっと書道に明け暮れる日々でした。*2 初めてプログラミングを勉強したのは大学3年の就職活動が始まる少し前です。文学部書道学科という経歴では、高校や中学の教師になるくらいしか学部時代の経験を直接活かすことができる道がなく、教師になる気がなかった自分は、なんとなく
Scalaのマクロというより、一般的にマクロに共通する基本であり重要な部分です。それをScala使って説明するだけです。 Scalaのマクロは、未だexperimentalという位置づけで、他の機能に比べれば仕様やAPIが変わりやすい状態です。そして、機能が搭載されてからあまり時間が経っていないこともあって*1あまり一般的に使われているとはいえない状態でしょう。しかし、Cなどのマクロとは違い、Scalaのものはある程度は本格的にコンパイル時に抽象構文木を自由にいじれるものであり、使いこなせるようになってくるとなかなかおもしろいです。 マクロというと、ある程度の人はLispを思い浮かべると思いますが(?)、先ほど書いた「本格的に抽象構文木いじれる」という点はまさにLispと共通する部分もあります(もちろん異なる部分も多くあります)。 つまり、これから説明することは、On Lisp*2 On
ということをここ2、3ヶ月やっててわりと続いてるのでおすすめです。論文じゃなくて普通の英語の本でもいいけど。 論文自体を読もうと思ったきっかけや、具体的にどうやって論文探して、どういう論文読むのか?みたいな話はべつの機会に書くとして、なにはともあれ論文読むのは英語の勉強の為でもあるわけです。 そもそも英語の勉強するには、単に読むより、リスニングとかその他色んな方法でやってみたほうがいいですね?たぶん。 CDくっついてる教材みたいなのを何冊か買って勉強してみたこともあるんですが、内容が興味あるものでないせいか、なんとなく微妙な感じになるので、色々試行錯誤した結果「だったら論文読んだほうがいいだろ」となりました。 あと、(比較するの若干おかしい?が) そういうやつは、そもそもCDの音声をPC経由でiPhoneやiPod的なものに入れる事自体面倒なので、論文ダウンロードして読み上げてもらうほうが
Scalazのコミッター、もしくはScalazを使いこなしているような関数型ガチ勢からみると、ある程度以下の様な共通認識*1がある気がする(けどあまり知られていない?)ので、ちょっとまとめてみました。 関数型ガチ勢ではない一般のScalaユーザーの間では、あまり疑問も持たずにそれなりに使われているものが多い気がします 個人的には、以下で紹介するものを「絶対使うな」とも思いません。*2が、しかしこれらのものに対して「アンチパターンとは言わないけど、デメリット多いし代替手段あるよね」という意見の人が少なすぎる気がするし、もうちょっとその辺りの議論がされるべきではないかなぁーと思い、あえて「アンチパターン」と言ってみました。 タイトルにScalaを入れましたが、厳密にはScalaに限らない話だと思います。ただし、「JVMで動く静的型付き関数型言語」という状況により、ある程度Scala特有の状況な
最近いくつかlombokが話題になってた lombokで快適Java生活 サイバーエージェント公式エンジニアブログ JavaでIDEのアクセッサ生成よりlombokを使ったほうがいい理由 Java特有の冗長なコードを簡潔に記述する「Lombok」 codezine ので、twitterなどでは何度かつぶやいた私見を、改めてblogにも書いておこうかと思います。Scalaもlombokも好きなので、ある意味「Scala使えばいいじゃん」という単純な意見に対する反論でもあります。 lombok自体のそれぞれの細かい機能の紹介は、先ほど上げたリンク先で既に語られてるのでしません。 lombokがScalaに比べて優れている点 IDEの恩恵 (自分はeclipseである程度やっていましたが)ほぼ素のJavaを書いているときと同じくらいの快適さです。対して、Scalaでは、IDEAだろうがeclip
sbtというと、独特なSettingのシステム*1や、Scalaで記述する内部DSL*2ばかりが注目されがちです。それらは、初心者にわかりづらかったりして批判されることが多かったり、逆にsbtを使い慣れた人にとってはとても強力で面白い仕組みです。 Settingのシステムに注目すると、汎用的に色々な言語のビルドにも使えそうに思えます。事実、sbtでC++のpluginを作っている人もいます。 しかし、sbtはあくまで「Scala(とJava)のためのビルドツール」です。 これは「単にScalaをデフォルトでサポートしてる」という意味にとどまらず、おそらく皆さんが思っているよりもずっと深い意味で「Scalaに特化したビルドの仕組み」が内部に備わっています。 今回は、そんな「sbtの内部アーキテクチャ」の紹介をします。 以下、かなり長いです。読み物としては面白いかもしれませんが、単にsbtを使
飛び入りで、芸者東京さんの勉強会で、初心者にScalaを教えるという勉強会をしてきた時の話です http://partake.in/events/5c793335-6b54-43f5-ac6f-6234b0847308 事例1 sbt0.12.xのlauncherがインストールされていた ↓ それで、Play2.2やろうとすると、エラーでる(0.13のlauncherが必要) ↓ 初心者だとそのエラーの意味が、すぐにはわからない ↓ 「sbtどうやって入れた?いつ頃入れた?」 ↓ 「homebrewでいれました」 ↓ brew updateする ↓ sbt以外のものも大量にupdateされて、とても時間を消費する 事例2 sbtでOutOfMemoryエラーでる ↓ インストール方法によるが、少なくともhomebrewは、デフォルトではJVMのオプション設定されないらしい*1 ↓ 結論とし
ScalaとJavaってまぁまぁ見た目は似てて、同じ予約語も多いので、Javaの予約語を、Scalaの視点からみた場合に分類して簡単に解説してみました。分類の方法は独自だし、けっこう雑です。 Scala始めようと思ってるけど、Javaのあの予約語は、Scalaだと同じやつあるの?もしないなら、Scalaの予約語の、どれを使えばいいの? っていうJavaプログラマ向けです。Javaプログラマにこそ、Scalaが普及して欲しいので。 完全に説明するのもめんどくさかったので、説明もなんか雑ですが・・・ 同時に、以前scalaの予約語について書いたものがあるので、こっちも見るとよいかも。*1 だいだいJavaと同じ機能のモノ 特に説明の必要がないほど、ほぼJavaと同じ使い方するものはなにも書いてません。 catch class もちろんclassの定義に使うのは同じです。 が、Javaの場合 C
わりと以前から書いてみたかったことなので、書いてみます。 たとえば最近ではここ Web✕Java - HTML5で進化したWeb標準を、Java技術でどう扱うのか?でStruts使ってる人へJSFの説明をしてきた #jjug #html5biz でとりあげられていたりします。*1 昔からずっと言われてる話です。ですが、「互換性がない」とある程度多くの人が口をそろえて言う一方、「ではどのくらいの互換性があればいいのか(どういうポリシー?どのくらいの期間を保証?)」という具体的な議論がほとんどされていない気がします。 なので、もうちょっと具体的に考えてみたいと思います。 先日こんなtweetをしました @seratch 順調にいけば今年中にScala2.11はRC出るくらいになりそうだし、3世代クロスビルド(2.9、2.10、2.11)はかなり厳しいので、もし2.11サポートと同時に2.9切り
The Scala 2.8 Collections API 英語 日本語1 *1 日本語2 *2 The Architecture of Scala Collections 英語 日本語 The Scala 2.8 Actors API 英語 日本語 すべて、scalaの公式サイトに掲載されているもので、しかも、scalaの開発者の人達が自ら書いたものなので、かなりわかりやすくまとまっていて、なおかつ正確です。 しかも、それぞれ日本語に訳してくれた方がいます! *3 とくにThe Scala 2.8 Collections APIについては、一番最初に読むべき かつ 一番重要だと思います。 The Architecture of Scala Collectionsについては、The Scala 2.8 Collections APIのほうを読んでからでいいと思います。こちらは内部構造がどう
最近以下のようなJava8の記事 Java 8を関数型っぽく使うためのおまじない をちょくちょく見かけるようになったので、自分もなにか書こうと思い、前からちょっとだけ気になっていた、highjというライブラリ https://code.google.com/p/highj/ https://github.com/svn2github/highj/tree/master/branches/java8/src/main/java/org/highj を読んでみて、概要を書いてみます。 Javaで関数型プログラミングというと、functional java https://github.com/functionaljava/functionaljava という、一年くらい前にちょっとblogにも書いたものがあります。 http://d.hatena.ne.jp/xuwei/20120427/13
例のごとく、最初に注意書き まだfinalがでていないので、細かい部分変わるかもしれません*1 個人的に、「大きい変更点だなと思ったもの」「ライブラリ側のユーザーが直接使うクラス関連*2」「なんとなく興味があるもの」を中心にとりあげただけで、すべてを網羅してるわけではありません finalがでるまではできるだけ随時更新する予定です Scala2.11.0は、今のところ順調にいけば2014年の2月には最初のRCがでて*3、3月にはfinalがでるらしいです。*4 https://issues.scala-lang.org/browse/SI しばらくこの記事がblogの一番上にくるように、少し未来の日付にしておきます。 2.9から2.10のときの変更点に比べると、だいぶ少ないですね。(2.9から2.10の変更点が多すぎただけですが)細かく追えていませんが、その分コンパイラ側の細かいパフォーマ
つまりなぜかいきなり高階型の話です。 これ 関数を扱えることはどのようにプログラミング言語の能力をあげるか に対する便乗というかツッコミとして。 つい先日もある人がこんなこと 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 とか読んでください。 関数がオブジェクトとして扱
リテラルレベルプログラミングという用語が存在するのかは知りませんが、べつに厳密に定義せずなんとなく使います。まぁこれ 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")と渡すとコンパイルエ
http://www.manning.com/bjarnason https://github.com/pchiusano/fpinscala 一年ちょっと前にblog書きましたが Scalaz の作者の人達が書いた "Functional Programming in Scala" という本がでるらしい 14章のぞいてほぼ完成したので、感想書きます。MEAP v9の時点です。ちょっと長いですよ。 まず、全体を通していえるのが、Scalaの本ではなくあくまで関数型プログラミングの本だということです。それは本文の最初の方にも書いてあります。 この本だけ読んでも、Scala自体にはあまり詳しくなりません。Scala自体については、必要最低限の文法だけを随時説明してます。 逆に、(英語が読めるなら)Scalaの知識がほぼゼロだとしても、大体読めるのではないかと思います。 また、Scalazの本で
togetter 正規表現が構文として必要かどうかという話から プログラミング言語における正規表現リテラルの必要性について こういう収集がつかなそうな話題にあまり首突っ込むの好きじゃないんですが、blogに書いておけば、まぁそれはそれでScalaをあまり知らない人にとっては役に立つだろうから、丁寧に説明しておきましょう。 togetter(と、その他関連するtweet)はあまり読んでません。 とりあえずkazuhoさんがわかりやすくblogに要点まとめているので、まずそれに対応するかたちで説明しましょう。 また、大前提としてScalaに構文としての正規表現リテラルはありません。なので、以下の説明を読んで 「いや、それは単に苦しい言い訳だし、やはり正規表現リテラルは存在したほうがいいでしょ」 と思う人もいれば 「なるほど、このくらいの機能があれば、たしかにそれほど正規表現リテラル必要ないな」
tototoshiさんの、これ Play 2.3 がリリースされたので変更点と試し方を説明します の便乗(?)的な感じで、なぜか自分もチュートリアルを書いてみます。普通に書いたら意味ないので、少しだけ変わった方法を書いてみます。 変わった方法とは、あえてtypesafe activatorを使わない方法を書きます。また、play2.3がどうやって成り立ってるのかを説明するのも兼ねて、activatorを使わないだけでなく、なんらかのテンプレート使ったりとか自動生成とかもせずに、一つずつ手作業でやって、最低限の構成のところまでだけを説明します。 なので、実用的なのかどうかはわかりません。慣れたら、それぞれみんなtypesafe activator使うなり、独自にテンプレート的なプロジェクトを用意しておくなり、giter8使うなりした方がいいかもしれません。 あと、先に完成後の最小限のplay
twitterで、海外のScalaistを大量にfollowしていないとわからない、マニアックなScala界隈の事情の話。 海外で、Scala使っている企業というと、twitterやfoursquareなどが有名ですが、個人的に観察していて PrecogIO という会社が最近とにかくすごいので、こんな変わったblog書いてみます。 Precog engineers: @nuttycom, @dchenbecker, @AlissaPajer, @d6, @puffnfresh, @fponticelli, @tixxit, @milessabin, Tom Bowles. Best. Team. Ever. 2012-08-24 05:10:05 via Twitter for Mac 最近も増えてる 代表的なすごい人をいくつか自分が知ってる限りで説明 @djspiewak github
以下の、Appleが最近発表したSwiftという言語の、面白い(?)仕様が話題になってますが、 This playground should illustrate why the immutability behavior of #Swift is *terrible*: URL 2014-06-10 19:31:56 via Twitter for Mac 大事なことは全部MLが教えてくれた 〜 Apple の Swift の mutability 周りの件を理解する これ見て、なんとなくScalaの "とある構文" を思い出したので書いてみる。 自分の理解では、要するに 「b.append(5)というのが、単なるメソッド呼び出しとかではなく、コピーして、追加して、かつ元の変数b自身の参照を書き換える(再代入する)」 という挙動をするあたりが、(他の言語でこんな動きするのがないので)、み
次のページ
このページを最初にブックマークしてみませんか?
『xuwei-k's blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く