みなさまに、RBSに関する重要なニュースを発表できることを嬉しく思います。 私の目標の一つにはRBSを当たり前の世界にするというものがあります。 この目標に対して大きなインパクトを残せたことに大変興奮しています。*1 aws-sdk-ruby配下すべてのgemにRBSが含まれた状態でリリースされました こちらは公式blogからのアナウンスです。 aws.amazon.com aws-sdk-rubyはrubygemsでの累計ダウンロードランキング2位に乗るほどの人気gemです。(aws-sdk-core) aws-sdk-rubyは現状370以上のgemのあつまりです。 このすべてのgemにRBSが含まれた状態でリリースされました。 そうです。すべてです。 rbs v3.4.0以上でご利用いただけます。 steep + vscodeの例。etagがStringであることがわかる え、なにが

イントロダクション 「テストを走らせて型情報を収集すればいいんじゃない？」そのアイデア自体は話題に上がることが多かったかと思われますが、観測範囲では前例がないように見えます。そこで、実際に作ってこそ見える世界があると思い動くものを実装してみました。 Orthoses::Trace github.com orthosesはRBSを生成するための機能を作るフレームワークで、この機能の一つとしてOrthoses::Traceというミドルウェアを実装しました。 例 例題として、rack-testというgemのRBSを生成したいとします。 その場合の生成コードをOrthoses::Traceを使って以下のように準備します。 https://github.com/ksss/orthoses/blob/db80d506c5fb02dadaa0ae303e0761ba0a543f6f/examples/r

これは、これまでRailsの古き良きMVCな開発体制しか知らなかったバックエンド開発者が、環境が変わってフロントエンド開発を学ばざるをえなくなった者の記録です。 歴史的に正しい事実を書いたものではなく、私個人の理解を整理するための妄想日記です。 私はこれまではWebアプリの開発ばかりやってきて、RailsでHTMLテンプレートエンジン使ってviewを作るスタイルでしか開発してきませんでした。 しかし、ネイティブフロントとWebフロント両方があるアプリケーションが開発されているところを見て、ある事を思いつきました。 「Webフロントもネイティブフロントのように開発できれば、バックエンドエンジニアはバックエンドに、フロントエンドエンジニアはフロントエンドに分業できて、開発しやすくなるのでは？」 この気付きが超重要でした。このイメージを持てたおかげでフロント開発の意義がスルスル入ってきました。

次は決まってます。 はじめに 前回の自分の退職エントリーを読んでみたのですが、何が言いたいのかさっぱりでビックリしました。 最終出社日です - スペクトラム さて、そんな話は置いといて。 おもいで ちょうど4年間、Repro株式会社でお世話になりました。 4年間、本当にいろんなことがありました。 正直、自分でも「あれ？Repro辞めるの？待って、マジで？あんな良い所を？なんで？？？」という気持ちがよく現れて混乱しています。 引っ越しすると決めたのは自分なのに、いざ今くつろいでいる部屋とお別れとなると思うと急に寂しくなるアレです。 会社には本当にお世話になりました。入社時から週4のリモートワークも認めてもらっていてずっと続けていました。(コロナ禍で2020年2月中旬くらいからは一度も出社できていません) 報酬も高く、面白い仕事がどんどん舞い込んできて、大変優秀な方々と一緒にお仕事しながらエン

mruby v1.3 がリリースされましたね。 趣味mrubyウォッチャーとしてv1.2からv1.3で何が変わったのかを、個人的にまとめてみたいと思います。 注目すべきは、やはりmatzのcommit数。 もちろんmerge commitも含みますが、約半数のcommitがmatzのcommitになっています。 なぜmatzがここまでmrubyに力を入れるのか聞いてみたいところですね。 それではmruby v1.2 からv1.3への変更で何が変わったのか、ザックリ見ていこうと思います。 リリースノート http://mruby.org/releases/2017/07/04/mruby-1.3.0-released.html 1年以上あった割には、表向きにはそこまで変化はない感じ？ わりと最新のCRubyの文法やメソッドも入っていたりしますね。 Contributions https://

逃げるは恥だが役に立つ 皆さんは逃げ恥観ましたか。 私は5日間で11話全部観ました。TBSオンデマンドで登録すると最初の2週間無料とききつけて登録(したのは妻だけど)。普段からTVは観ない二人なので、始めの2話を観た日は刺激が強すぎるのか二人して寝付けませんでした。 最終話はティーバで無料で観れました。 マンガも8巻まで買って(買ったの妻だけど)読みました。 なんかこう状況が自分たちに被る部分が多かったので大いに感情移入しちゃって「わかるー！」を連発しつつ、二人でみていたわけです。 私は風見さんが好きです。 ああいう風になりたい。「僕は性格が悪いんです」とか言ってみたい。「すいません。」って笑顔で言うの、ズルい。正直で率直かつ相手の気持を気遣える。そこにシビれるあこがれる。 「イケメン」という偏見によって傷ついてきたキャラというのもいい。「イケメン」っていう言葉はもはや褒め言葉ではないした

長いと思うので結果だけ リポジトリはこちら。 github.com 使い方はgit cloneしてmakeするだけと大変お手軽。 make TESTS="core/nil"のように、ディレクトリ指定もファイル名指定もできる。 全国のmrubyistの皆様に於かれましては、是非お試し願いたいところです。 以下つらつらと モチベーション 数年前に始めてからというもの、mrubyという船に乗りかかったからには「mrubyには〜がない」とか「mrubyはバグが多い」とか言われたくない。と思うぐらいには愛着というか責任感を勝手に持っている。 「mrubyはCRubyと動作が違う」というのはよくある話なのだが、これを極力減らしたい。(完全には無理だけど) 仕様が同じならCRubyの知識がそのままmrubyに使えるし、ドキュメントもCRubyのものがそのまま使える。 「CRubyのライブラリをmruby

大体動くようになってきたので公開。 github.com きっかけは、まず最初にkiloがあった。 github.com kiloはredis作者が作った、C言語で書かれた超ミニマムなテキストエディタだ。*1 「このコードを読めば、ベーシックなテキストエディタの実装方法が分かるはず」 と思って実装を読み、大体わかったので試しにRubyで書いてみるかとはじめてみたのが始まりだった。 そのうち「mrubyでも動くようにしてみるか〜」と思って、 必要そうなmruby-io-consoleを書いた。 というわけで、riloはkiloを参考にして、rubyでもmrubyでも動く(ように今のところなっている)超ミニマムなテキストエディタ。という感じだ。 今後の展望は ワンバイナリで動くようにする riloはriloで書く 対応プラットフォームを増やす カラースキーマをプラグインで書けるようにする vi

regional.rubykaigi.org 東京Ruby会議11で「Rubyに型があると便利か」という発表をしてきました。 speakerdeck.com 何百人もの人に30分も時間をとってもらって話を聞いてもらうのは物凄く贅沢な時間だと思います。 トークを聞いていただいた皆様。声をかけていただいた皆様本当にありがとうございました。 発表内容についてはるびま記事としてまとめる予定ですのでお楽しみに。 みんなちがって、みんないい 今回の東京Ruby会議11は本当にそれぞれが非常に濃い内容だったと思う。 正直発表の7割ぐらいはよくわからなかった。 しかしそれでいいんだと思う。 東京Ruby会議11の目的にはこうある 技術的好奇心を改めて呼び起こし、プログラミングの難しさ、そして楽しさを再発見する場を目指します。 例えば火星がポンとあってもわけがわからない。 でも、「もっと知りたい」という好奇

https://github.com/ksss rebuild.fmの#120を聞いて、jQueryの作者が始めた「毎日コードを書く」というやつを40日間やってみた。 rebuild.fm John Resig - Write Code Every Day よかったこと アウトプットがふえた 毎日コードを書くというルールなので、 アウトプットは多くなった。 手持ちのリポジトリを大幅に整理したり、PRも10件ぐらい飛ばした。 毎日コードを書くと、コンテキストスイッチのオーバヘッドが小さくなるというのは本当で、 お風呂に入っている時にアイデアが思いつく事もあった。 無意識領域の脳リソースをうまく使うことができてるのかもなあと思った。 よくなかったこと インプットがへった アウトプットのために使う時間を必ず確保するので、アウトプットからインプットへコンテキストスイッチするオーバーヘッドは増加した

ISUCON5の予選に参加して、圧倒的な差で負けたので、 この悔しさをバネに復習して、自分の力にしたいと思う。 今回のファイトではアプリの修正が特に重要であったように思う。 そこでアプリの修正に焦点を当てて、「こうすればよかった」を追っていき、自分のものとして習得したい。 とはいえ、本番とまったく同じ状況を作ることはできないので、ローカル環境でベンチマークを走らせて、簡易に得点を見ていくことにする。 ISUCON5の予選で使われたアプリのコードとベンチマークのコード、gce用のイメージはすでに公開されているのでこちらを使う。 isucon.net なお、極力アプリの修正に集中するため、nginx.confやmy.cnfはいじらない。unicornのworker数すらいじらない。 インフラはせいぜいテーブルにインデックスを貼る程度とする。 これは、ISUCON予選本番で、やたらインフラに時間

Tempfileの実装を調べようとCRubyのコードを読んでいたら見知らぬコードを発見した。 それは僕がほしくてとっさに作ったものそのものだった(それ以上だった) http://docs.ruby-lang.org/ja/2.2.0/method/Tempfile/s/create.html Tempfile.createはTempfile.openと似ているようでちょっと違う。 Tempfile.openではブロックの終了時(close時)ではなくGCのタイミングでファイルを削除する。 Tempfileはプログラムが異常終了してもファイルが消えた状態になるので慣例的に即unlinkして使う事が多い。 そのためpathをとったりファイルの存在確認をしたりということはあんまりないんだけど、 外部コマンドを使いたい場合はやっぱりpathがあると便利。 かといってGCタイミングでファイルを削除と

#naruhounix を読んだ。 正直「プロセス？あれでしょ、なんか動くやつ。」というレベルだったので非常に勉強になった。 Rubyで書かれているのも、余計なこと(Cの文法とか例外処理とか)がついてこなくて理解しやすい。 書き方はいいからイメージが知りたいんや！というタイプの方におすすめ。 逆にRubyの余計なこと(このバージョンでは修正済みとか)がついてくるのでRubyist寄りであることはいなめない。 プロセスをforkしてもリソースは同じみたいなところはポインタ的な解釈。 あとfork後ちょっとでもメモリの内容が変わったら全コピーだと思ってたけど全然違ってオブジェクト単位？(このへんあやふや)というか本当に変わった部分だけコピーされるみたいだ。 例えばRailsアプリとかは立ち上がる際に大量のフレームワークのコードとアプリケーションのコードを読み込んでいるので数秒とかかかる。 しか

動的サムネイル生成 サムネイルは、ユーザアップロード画像を扱うアプリではほぼ間違いなく使われると思う。 サムネイルの生成には、先に作っとくか、後で作るかの2つの方式があるように思う。(気が向いた時とかナシとすると) 先に作っとく サムネイルを先に作る。 つまりは画像アップロードをキータイミングとして画像処理をかけ、 参照するときには静的な画像を見る方法。 メリットは参照に処理を挟まないので高速に動作することが期待できること。 しかしデメリットとして後から画像サイズを変更しようとすると、画像処理が全部やり直しになる。 また、近年ではCDNを使えば静的画像の参照が早かろうがあまり効果が無いことが多い。 後で作る そこで参照側からパラメーターを与えて、リクエストが来た時に画像処理をかける方法をみてみる。 一見参照するたびに画像生成するのは効率が悪すぎる印象があるけど、 その分ちょくちょくサムネイ

最近mrubyにコミットしているので自分の活動をまとめます。 mrubyを小さくした話 mrubyでは、文字列の扱いはシンプルにchar*を構造体でラップしていました。 struct RString { MRB_OBJECT_HEADER; mrb_int len; union { mrb_int capa; struct mrb_shared_string *shared; } aux; char *ptr; }; そのため1つの文字列毎に、構造体分と文字列分の2回のmalloc/freeが発生していました。 ここでCRubyのRStringを見てみます。 #define RSTRING_EMBED_LEN_MAX ((int)((sizeof(VALUE)*3)/sizeof(char)-1)) struct RString { struct RBasic basic; union {

概要 お仕事でRedisを触ってたので知見をまとめる。 Redisは高速はKVSだが、今回1000万件を超えるような大量のデータを扱った。 大量のデータをバッチで定期的に書き込んで、参照側では高速に返すシステムを考える。 バッチはユーザーの行動を『現在から1日以内にログインしたユーザー』のように時間区切りで条件検索している。そのため、検索する時間が変われば結果も変わるので、定期的に実行してデータを洗い替えている。 検索結果は1000万件あっても対応したい。 ユーザーがアクセスしてきたときにはこの検索結果の対象かどうか判断して結果を返したい。このユーザーからのアクセスは大量にあるため即座にレスポンスを返さなければならない。 洗い替えることによって使わなくなったデータは容量を空けるために削除したい。 クエリ結果はユーザーのidなので19475934や59103940のような法則性の薄い数字の列

2023年4月中ごろから6月の今日までの2ヶ月と少しかけた転職活動が終了したので、記録ついでに振り返りたいと思う。 あくまで個人的な記録である。 応募手法 応募方法は、さまざまな方向から行った。 Twitterでの公開募集 エージェント経由 YOUTRUST経由 直接応募 Twitterでの公開募集 正直なところ、一回やってみたかったという部分が大きい。今回の転職活動における大きなチャレンジだった。ありがたいことに20社以上から声をかけていただいた。知り合いのフリーランスの方から「うちが関わってるところどうですか？」という声がけも3名からあった。その節はありがとうございました。 数は多いものの、話を聞く聞かないを考えなくてはならなくなり対応に追われた。公開募集とは、受動的な方法なのだと痛感した。また「会社名も書いてないから怪しいな？」と思ってDMの送信主を調べたら国際指名手配者だったという