2020年代はモノリスの時代 ここ10年ほど流行っていたマイクロサービスについての理解が深まり、その限界が広く知られるようになってきた。ShopifyのModular Monolithについての記事などは代表例だろう。並行して必要性が叫ばれるようになってきたのがnamespaceだ。RubyKaigi 2023ではshioyamaさんがMultiverse Rubyと題して発表をしていたし、その後tagomorisさんも記事を書いている Rubyでは以前からnamespaceへの議論が行われてはいたのだが、Ruby 2.0の頃の議論では主にMonkey Patchingによる副作用を局所化するためのものだった。当時の議論とはライブラリ読み込みの局所化という課題が挙がっている点が異なっており、それに伴い技術的な困難も異なる。上述の記事でもそれらの多くは整理されているのだが、この記事ではまだ議

配列の全ての要素が等しいか否か mrkn 配列の全ての要素が等しいことはどう確認したら良いんだろう。 `ary.all? {|e| e == ary[0] }` これかな usa ary.uniq.size == 1 mrkn なるほど > uniq usa all?でブロック引数より速そうな予感 いやでもaryがでかくてかつ全然要素が等しくなかったらそうでもないか。 mrkn `ary.all? {|e| e.foo == ary[0].foo }` の場合はどうでしょう。map.uniq.size がいいかな usa all?は全て等しい時に遅いが、序盤で違うとわかったら速い mrkn 確かに > 序盤で違うとわかったら速い usa この辺は予想される集合の傾向で判断するしかないですかねえ。 map.uniq.sizeはmapの結果としての一時配列を作らないようにするには、えーと En

投資とは 最近、「投資を始めようかな」と考える人が増えたように思います。この記事を読んでいるあなたもきっとそうでしょう。 アベノミクス、株高、円安、ビットコイン、転職など理由はさまざまでしょうが、リーマンショックを乗り越えた世界の、日本の経済情勢の変化があなたの心にもついに波及したということでしょう。余力のある人にとって、多少のリスクを取って資産を増やそうというのはとてもよい行いです。 そもそも投資とはリソースの最適配分であり、リスクと正面から向き合うことであり、資本主義社会における投票権の行使でもあります。これまであなたは資産の全てを日本円の現預金で保有していたことでしょう。これがどのような意味を持つ行いだったのか改めて考えてみましょう。 2008年のリーマンショックから2012年のアベノミクス開始までは物価や株価は下がり、円高が進んでいましたから、日本円の現預金で資産を持つのは悪くない

序 最近、敵情視察を兼ねた仕事ととしてGoでアプリケーションを書いていた。このアプリケーションがどんなものかはそのうちid:tagomorisさんがどこかで話すと思うけれど、このコンポーネントがOSS化される予定はいまのところないので、そこで得た知見をここにまとめておくことにする。 GoroutineとChannel さて、GoといえばGoroutineとChannelですね。 Goroutineはようするにスレッドなんですが、文法と実装の支援でより気軽に使えるのが他の言語との違いでしょうか。なので、Goroutineをどれだけほいほい使うべきかというコスト感覚を身につけることがとても大事な気がします。Rubyなどとは気持ちを切り替えていく必要があるでしょう。ぼくはまだ切り替えきれていません。 もう一つがChannelですね。これは端的にはメッセージキューです。 Goは前述の通り同時に動く

RubyKaigi 2014の基調講演でまつもとさんが静的型の野望を明かしてから2年半が経った。 その間の進捗は芳しいものとは言えないけれど、それでもまじめな研究として例えば多相型、推論、Ruby が行われている。普通の人は私のこの記事を読むよりもこちらを読んだ方がよいと思う。 じゃあなぜこの記事を書いたかというと、それでも一部の人には得るところがあると思っているからである。この記事の読者の中にはRubyKaigi 2014中に書かれたakrさんの日記で「非常に簡単化した静的解析」の話を読んだ人もいるのではないかと思う。この話をそのまま発展させた場合にどういう迷路に迷い込むのかという点についていくつかの知見を得たものの、これまでそれを書いていなかったのでちゃんと書くことにしたのだ。 さて、nurse/static-check.rbである。 これは大きく分けて3つの部分からなっている。定義さ

iOS 10.3がリリースされましたが、APFSへの移行が含まれていて話題です。特に文字コード界隈ではHFS+で搭載されていた暗黙のUnicode Normalizationがなくなっている点が指摘されています1。 ではmacOSではどうなのでしょうか。SierraならばすでにAPFSを扱うことが出来るので試してみましょう。 % hdiutil create -fs APFS -size 1GB foo.sparseimage WARNING: You are using a pre-release version of the Apple File System called APFS which is meant for evaluation and development purposes only. Files stored on this volume may not be ac

先日の日記で最近のIntel CPUでは間接分岐の分岐予測がほとんどミスしなくなっているという話を紹介しましたが、Branch Prediction and the Performance of Interpreters - Don't Trust Folkloreという論文にまさに同じことが書かれているのを見つけました。ていうか、この論文わたし見た形跡がある……。 去年にこの論文を見かけたときは「Direct threaded codeとかオワコン」って話までしか見てなかったんですが、今改めて見ると分岐予測が世代ごとに進化していてすごいって話に加えて、ITTAGEという分岐予測手法を使うと同じくらい当たるって書いてありますね。 ITTAGEはTAGE (TAgged GEometric length predictor)の間接分岐版で、TAGEは原論文がA case for (parti

fluentdな人達と話していると定期的にRubyのオブジェクト生成が遅いとdisられます。 本質的にしょうがない部分もあるんですが、それにしても遅い部分も結構あるので、おもむろにperf statとperf recordを取ってみましょう。 % sudo perf stat -d ./miniruby -e'GC.disable;i=1000000;while (i-=1)>0;Hash.new;end' Performance counter stats for './miniruby -eGC.disable;i=1000000;while (i-=1)>0;Hash.new;end': 467.629812 task-clock (msec) # 0.993 CPUs utilized 19 context-switches # 0.041 K/sec 2 cpu-migratio

序 人は誰しも理想郷ユートピアを求めるものだし求めてしまうものだろう。「最強のUnix環境」、これもまたそうしたユートピアの一つである。 21世紀の正常な判断能力を持った人間A pragmatic programmerならば、ユートピアを探し求めることは諦めて、OS Xこそが現実的なデスクトップUNIX環境だと認め、林檎の木の下で日々を暮らし、1日17回だったり2週間に1度、現実的なサーバー用UnixであるLinuxサーバーにdeployして生活の糧を得るものだ。 しかし、やはり人はユートピアを求めてしまうものだし、正常な判断能力を失ってしまったプログラマプログラマにはよりにもよってWindows上にそれを求めてしまう頭の不自由な人interixやcygwinで懲りない人もいる。この記事はそうした人に向けた、2015年末での状況を述べたものです。 さて、アベノミクス以来の円安もあり、201

要約 therubyracerはやめてexecjsからnodeコマンド使え。 解説 Rails 3.1 で Asset Pipeline が導入されて以来、Gemfileにgem 'therubyracer'と書く人も増えたのではないでしょうか。しかし、それがどの程度のリスクを背負っているのか自覚のない人も多いように感じます。 平時はChrome由来のJavaScriptエンジンであるv8を手軽にインストールできてスーパー便利なtherubyracer.gem & libv8.gemですが、その潜在的なリスクには震えるものがあります。最初にこれが世を騒がせたのは3年前のクリスマス前のことだったでしょうか。 v8 この問題の背景には、本質的に「v8のビルドは難しい」という点があります。雑にバージョンを選ぶとビルドが通りません。そもそもがChromeのためのものだからなんでしょうか。リリースす

Ruby会議2015 1日目 朝 家で Ruby 2.3.0-preview2 のsvnタグを打ってから優雅に会場に到着し、オープニングでリリースを行う予定だったのだが、雨で時間ロスしつつ会場へのラストワンマイルで迷ったため、焦ってしまっていまいちいい感じにならなかったのが残念だった。 そもそもこの手の公開なんちゃらの類では出演者は観察されるアリになりきって何が起ころうともありのままをみせることが正義だという認識が足りなかったのがよくなかったので、今度はリリースに際して何をしているかへろへろと見せるのが正しいのだろうと思いました。 Matz 2020年までにRuby3というのがびっくり。まぁ、バージョニングはCRubyにいくつかあるMatzの専権事項の一つではある。しかし、個人的にRuby3は高速化だけじゃなく、型とMVMも入っていて欲しいなぁ。 haml 闘争本能に身を任せてコードを書く

今日から Treasure Data で働くことになりました。 前職が一段落して（退職エントリ）転職を考えた時に、ちょうどtagomorisさんが何社も回った末にTreasure Dataに決めていたので、TDにしました。 … もちろん物事を決めるときに理由はいくつもあるわけでして、 OSS開発者として暮らしやすそう Twitterを勤務時間中にできるとかそのほかもろもろ 知り合いの有無 何を目指しているかわかりやすい 目指しているところが不明瞭だと迷走しやすい気がする これからの成長の余地が大きそう Ruby開発に際してビッグユーザーであるTreasure Dataのユースケースを得たかった あと、AmazonやGoogle、Microsoftと戦って、その戦う武器がOSSってのがよいですね。OSS派の旗を降ろせる条件がめちゃくちゃ厳しいのがよいです。 ちなみに今心配なことは、みんなも気

というわけで、Ruby 2.1 に向けて DevelopersMeeting20130727Japan をしたのです。 開発者会議で何をするかというと、RubyKaigi での見世物の通り、みんなが集まって色んなトピックに対してああでもないこうでもないと言い合うわけです。するとあら不思議、チケットで議論していた時はなかなか進まなかった話が、あっという間に reject されます。 また、三人寄れば文殊の知恵とはよく言ったもので、集まって議論していると保留間違いなしな雰囲気漂うラディカルな提案が、ブレイクスルー的な発想によって合意を得られることがたまにあります。今回で言えば分数リテラルがそうで、1/2r という表記の発想と虚数リテラルへのコンボは会議のハイライトでした。 次回は DevelopersMeeting20130831Japan なので、また大きな進展があるといいなぁ。 まとめ: