転職エントリ(1年後) - 世界線航跡蔵
Nianticに転職して1年あまりが過ぎた。 2018年の9月からNianticで働いているのだが、そういえば転職エントリーを書きそびれていた。 転職して以来、相変わらずサーバーサイドの開発をしていている。なお、開発しているのはIngressでもPokémon GOでもハリー・ポッター：魔法同盟でもない。 Nianticとの関わり Ingressは2014年12月から続けていて、Pokémon GOも日本での正式リリース日からぼちぼちやってきているものの、それにしてもNianticで働くようになるとは思ってもみなかった。 Pokémon GOがなんかえらく流行り始めたときも、自分とは関係ない話だと思いつつGoogle Maps時代の知り合いが何人か関わっているのを思い出して無責任に祝福していたぐらいである。知り合いへのご祝儀のつもりでポケコインを1万円分ぐらい買って、行動圏内にルアーモジュ
grpc-gateway機能ひとめぐり - 世界線航跡蔵
@vvakame さんが TechBooster の新刊"JavaScriptoon"の中でgRPCを解説していて、その中で grpc-gateway にも触れている。これはとてもよい記事だったので、みんなこの本の電子書籍版を買えば良いと思う。 ただし、grpc-gatewayは記事中で使われているだけで主題ではないので、すべてのトピックをカバーしてくれているわけではない。それは仕方が無いが、そろそろgrpc-gatewayの機能を見渡す日本語記事が欲しいと思ったので自分で書くことにする。 grpc-gatewayとは gRPC (HTTP/2 + ProtocolBuffers)をwrapして古典的なJSON API (HTTP 1.1 + JSON)を提供するリバースプロキシを生成するコード生成機だ。 別記事 にも書いた。 何ができるのか gRPCで使うサービス定義(IDLみたいなやつ
APIデザインケーススタディ —— Rubyライブラリを移植する前に読む本 - 世界線航跡蔵
『 APIデザインケーススタディ 』という本を頂戴したので読んでみた。 ライブラリ作者に向けて この本はRuby標準ライブラリを題材にして、分かりやすく、多様な機能をサポートして、互換性を保つAPIの設計をするにはどのように考えるべきかを教えてくれる。 ここでAPIと言っているのは、一般的なRubyのクラスとオブジェクトとメソッドから成るライブラリをどうデザインするか、という話である。 別にChef RecipeやRSpec DSLのようなちょっと変わったDSLを設計するとかそういう話ではない。確かにその種の言語内DSLのデザインには固有のセンスが必要とされるし、 Ruby DSL Handbook なんて本が書かれているように実装にあたってもある種のテクニックが必要なのも確かだ。でも、それ以外の「ふつう」のライブラリのデザインは果たして簡単だろうか。 適切な粒度のクラスを定義する。必要な
Dockerで何が変わるのか - 世界線航跡蔵
DockerCon 2014 に行ってきた。 この会期中には各社からいくつもの製品が紹介/発表された。そして、それによってクラウドという技術は次のステージに移行したと言っても過言ではないだろう。 より自由にユーザーがクラウドベンダーを選べる時代へ。どうやってクラウドにうまくデプロイするかではなく、アプリケーションそのものに注力できる時代へ。 Dockerとは Docker とはいわゆるコンテナ技術の1つで、Linuxホスト環境の中に隔離された別のLinux環境を作ってくれる技術だ。 軽量仮想マシンと呼ばれたりもする。 Solaris Container とも似ている。 新しくないDocker 1つ述べておくとDockerは技術的には新しくない。Dockerの価値は技術以外にある(とDockerのCEOもDockerConで言ってた)。 技術的にはSolarisにはSolaris 10の頃か
シンボルとは何か その1(後編) - 文字列のintern - 世界線航跡蔵
シリーズ・RubyのSymbol 。だいぶ空いてしまったけど、気が向いたので続きを書く。 前回 は文字列の同一性について復習したのであった。 意義 そう言うわけで、文字列においては同一性と同値性は異なる。特に、Rubyの場合は同じリテラルも評価する度に異なるオブジェクトを生成する。ところが、これは不便な場合があるわけだ。 まず、文字列の同値性比較はコストがかかる。長い文字列を比較にするには時間が掛かる。保持しておくにも長い文字列だったらメモリーを食う。更に、毎回リテラルからオブジェクトを生成するとしたら、無駄なケースが多々ある。Railsに良く出てくる疑似名前付き引数みたいなやつ。 some_method "a" => 1, "b" => 2, "c" => 3 おい、この箇所を通る度に一々文字列のメモリー確保してオブジェクト構築するのか? その背後ではパフォーマンス厨なら誰もが恐れる m
Rubyの呼び出し可能オブジェクトの比較(1) - 世界線航跡蔵
Rubyにはコード片を表すオブジェクトが複数ある。 Method , UnboundMethod , Proc である。 Continuation は少し違うけど、実行コンテキストを記憶しているオブジェクトという意味では近いものがあるか。『 Ruby Way 』にはこういういろいろがあることについて「驚くほどのことではありません」と書いてあるけれども私は驚いた。で、これらが微妙に違うのだ。困ったもんだ。いや、便利なのかもしれないが。 それで今回はこれらの概要を眺めてみたいと思う。 普通のメソッド defでメソッドを定義するのが一番普通だやな。 class C def greeting(arg) puts "C#greeting reveived #{arg}" end def iterator yield 'iterator 1st' yield 'iterator 2nd' yield
Mad web programmer宣言 - 世界線航跡蔵
この文章を、あまりにも早く去ってしまった才能、 伊藤計劃 に捧げる。 さて、私の名刺には"mad web programmer"と刷ってある。「何が"mad"なのか」というのはFAQである。今まで幾人かに答えてきたその答えをここに書きたいと思う。 webの安全性について ネットが危険であると言ったのは誰だろう。いや、ネットは安全である。WWWの隣人は包丁であなたを刺さない。WWWの中傷者はログから追跡可能だ。 オフラインとは、認証を経ていない誰かがあなたの存在を抹消できる世界。証拠を残さずにひそひそと他人を中傷できる世界。顔が見えているというだけの実質のところ匿名で、他人を追い詰めることので きる世界。 オフラインは危険である。webはより安全なのだ。webが理想郷であるというつもりはないが、ことさらに「web炎上」などと言うな。 そこにある暴力性は、少数者がオフラインでは日々脅かされてい
rubykaigi.orgの歴史 - 世界線航跡蔵
whoisしてみると分かるようにrubykaigi.orgドメインは現在私が所有している。 元々RubyKaigiは独自のドメインというのは持っていなかった。その頃、確か高橋さんか角谷さんにだったと思う、rubyconfみたいにドメイン取らないのかと聞いてみた。取るつもりはないというお答えであった。思うに、当時は今にも増してイベントの継続性は神のみぞ知るところだったわけで、ドメインを取ってそこで継続的にサイトをメンテナンスするのはそぐわないということだったのだろう。 それにしても、RubyKaigi 2007が行われようかという時点で既にruby-talkやruby-coreでも"RubyKaigi"という文字を目にするようになっていた。と、すればいずれここに目を付けるスパマーもいるだろう。みすみすこのブランドをスパマーにスクワットされるがままに放置しておくのは惜しいように思われた。そこで
Pulling Strings with Puppet - 世界線航跡蔵
Pulling Strings with Puppet: Configuration Management Made Easy (FirstPress) 作者: James Turnbull出版社/メーカー: Apress発売日: 2008/07/31メディア: ペーパーバック クリック: 4回この商品を含むブログ (1件) を見る 『Pulling Strings with Puppet』を読んだ。 Puppet の入門書である。 Puppetとは Puppetはシステム設定の維持管理を自動化するためのツールで、cfengineやらchefやらと同系統のものだ。クライアント/サーバー方式が基本となっていて、中央のサーバー(puppetmasterd)でシステムの設定情報を集中管理する。例えば「webサーバー機にはapache2が入っていること」とか「apache2にバーチャルホストfoo
Rubyのメタクラス階層について再び - 世界線航跡蔵
承前 。 3ヶ月ばかり時間が空いてしまったけれども、 sumimさんの記事 に答えたいと思います。 yugui さんの図は、たしかにクラスと特異クラス（メタクラス）が揃って並んでいて見た目にはきれいなのですが、これだとクラスが整然と並んでこそいるものの、肝心のメタ階層がどうなっているかという情報のほうは、正直なところ、いささか得にくいものになってしまっています。 いいえ、これで良いのです。なぜって? これが私の図(下記再掲)で一番言いたかったことで、ただ、一般のメタクラスと#<Class:Class>を並べているのはいただけないかな。これはsumimさんのSmalltalk版の図を意識しすぎて、まずかったかなと思います。 図1: うん、やっぱり メタ階層がどうなっているかという情報のほうは、正直なところ、いささか得にくいものになってしまっています。 これは当たってるかもしれません。 図の修
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
