転職エントリ(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の開発に学ぶ、ソフトウェアの設計手法〜Yuguiが定めた、2つの基本設計方針 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
grpc-gatewayの開発に学ぶ、ソフトウェアの設計手法～Yuguiが定めた、2つの基本設計方針 良いソフトウェアとはどのような方針のもとに設計されているのでしょうか。広く使われているOSSであるgrpc-gatewayの開発過程を作者のYuguiさんが振り返り、その設計手法を解説してもらいました。 こんにちは。 Yuguiと言います。 本記事では読者がより良いソフトウェア設計を行うための参考として、筆者が経験してきた設計上の決定をご紹介します。 筆者はこれまでRuby 1.9のリリースマネジメントを担当したり、Google Mapsの日本向け地理データ処理やgrpc-gatewayの開発などをしてきました。そしてこれらを通じて、広く長く使われて拡張されていくソフトウェアを設計するための方針決定に携わったり、方針に関わる良い議論を目にしたりする機会に恵まれてきました。中でも本記事では、
Rubyコミッター・Yuguiに学ぶ、コードに書くべき「適切なコメント」と「適切な場所」 - エンジニアHub｜Webエンジニアのキャリアを考える！
Rubyコミッター・Yuguiに学ぶ、コードに書くべき「適切なコメント」と「適切な場所」 Rubyコミッター・園田裕貴（Yugui）さんが、長年の経験で体得したソースコードに書くべき「コメントの技法」を教えてくれました。 プログラミングにおいて、どんな初心者でも書けるけれど、適切に書くのは上級者でないと難しいもの。それがコメント（=ソースコードに書かれている注釈やメモ）です。 不適切なコメントをつけても、プログラムの動作には影響しません。しかし、書き方の巧拙によって、コードの可読性や理解のしやすさには雲泥の差が出ます。良質なコメントが良質なコードをつくるのです。 今回はRubyコミッターでありgrpc-gatewayの開発者でもあるSupership株式会社の園田裕貴（Yugui）さんに、優れたエンジニアがどんな観点を持ち、どんなコメントを書いているのかを聞きました。 園田 裕貴（そのだ・
Rubyのリリースマネジャーを趣味でやるのは無理
「異能」ともいえる際立った能力や実績を持ち、まわりから一目置かれるエンジニアを1カ月に一人ずつ取り上げ、インタビューを掲載する。今月取り上げるのは「Yugui」というハンドルネームで知られる園田裕貴（そのだゆうき）氏。書籍「初めてのRuby」の執筆者であり、過去にはRuby 1.9系のリリースマネジャーを務めた。スケールアウト（現Supership）の初期中心メンバーの一人でもある。今回は、Rubyとの関わりやスケールアウトに参加したきっかけを聞いた。 （前回から続く） Rubyは2000年半ば、大学1年生の頃に趣味で触り始めました。バージョンが1.4の頃でした。高校時代からちょっとしたCGIを書くためにPerlを触っていました。そうした情報をいろいろ調べているうちに、Rubyといういい言語があるらしいという話を聞いたのです。 Rubyは割とすぐ手になじんだので、ちょっとしたスクリプトを書
性同一性障害の私に居場所を与えてくれたWeb業界
「異能」ともいえる際立った能力や実績を持ち、まわりから一目置かれるエンジニアを1カ月に一人ずつ取り上げ、インタビューを掲載する。今月取り上げるのは「Yugui」というハンドルネームで知られる園田裕貴（そのだゆうき）氏。書籍「初めてのRuby」の執筆者であり、過去にはRuby 1.9系のリリースマネジャーを務めた。スケールアウト（現Supership）の初期中心メンバーの一人でもある。今回は、プログラミングとの出会いからWeb業界で働くようになったきっかけを聞いた。 プログラミングを始めたきっかけは、小学校低学年のころ、自宅にPC-8800シリーズ（PC-88）というパソコンがあったことです。父親はIT関係の仕事ではありませんでしたが、趣味で多少プログラミングをしていました。デスクトップミュージック（DTM）のようなことをしたり、自作のプログラムで事務処理をしたりしていたようです。 私も家で
protocプラグインとカスタムオプション - Qiita
以前の記事ではprotocプラグインの書き方を紹介したが、実は1つ問題があった。 実用的なプラグインを書こうとした場合に、しばしば生成時に必要な、ドメイン固有の情報が足りないのである。本稿ではそれを補うカスタムオプションの話をする。 ここでもう一度確認しよう。protocのプラグインはProtocol Buffersのスキーマを読んで任意の処理を行える仕組みだ。それはCodeGeneratorRequest内のFileDescriptorProto messageを読み取って任意のバイト列を出力し、出力を受け取ったprotocが指定通りにファイルにバイト列を書き込んでくれる。 ただ、FileDescriptorProtoはprotobufのスキーマ言語の文法をprotobufメッセージとして表現したものに過ぎないから、極めて一般的なデータ構造とサービス定義を表現する能力しか持たない。プログ
gRPCのシリアライゼーション形式をJSONにする - Qiita
gRPCで送受信されるメッセージは、標準ではProtocol Buffersでシリアライゼーションされることになっている。一方、gRPCのwire protocolはそこは柔軟になっていて、実際、多くの実装ではシリアライゼーション形式をカスタマイズ可能だ。 たとえば、ある種のニーズのためにFlatBuffersが必要だとか、HTTP/2をサポートする標準的なツールでの解析のためにJSONのほうが可読性が良いとか、社内のバイナリ表現の一貫性のためMsgPackが必要だとか、宗教的な理由でProtobufを使えないとか、そういうときはスキーマだけprotobufで書いておいて、シリアライズは好きなようにやれば良い。 で、具体的にはそれはどうやったらできるのだろう。これが本稿の話題である。いくつかの言語で実際にJSONでシリアライズするクライアントとサーバーを書いてみたので、その結果を紹介する。
今さらProtocol Buffersと、手に馴染む道具の話 - Qiita
Protocol Buffersは別に新しい技術ではない。同時にそれは、未だ知られざる、未だに可能性を秘めた先端のソフトウェア技術基盤である。 新しくないのは事実で、GoogleがProtocol Buffersをオープンソース化したのは2008年のことだし、オープンソース化前に社内で使われ出したのは更に昔に遡るだろう。たぶん。 デザイン的にもJSON対応は後付けで、将来JSONが隆盛を極めることなんか全然想定していなかったのが透けて見えて古くさい。 しかし、同時にどうも情報に聡い人であってもなかなかその真価を実感し得ておらず、ある意味で未知の技術であるらしい。ならば、Protobuf (Protocol Buffersの略)を解説した文書は幾多あれども、それに1を加えるのもやぶさかではない。 Protocol Buffersとは Protobufはスキーマ言語だ! 一般的にはProtob
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の頃か
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
るびま
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
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"という文字を目にするようになっていた。と、すればいずれここに目を付けるスパマーもいるだろう。みすみすこのブランドをスパマーにスクワットされるがままに放置しておくのは惜しいように思われた。そこで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
