マイクロサービスや自作ミドルウェアのAPIをメンテナブルにしたいよねっていう文脈で、OpenAPIやGraphQL、gRPCといった技術が採用されるのを最近よく目にする。 バックエンドを実装しているWebエンジニアとしては、こういう仕組みが整備されつつあるのはありがたい。APIをシステムの外に公開しようとすると、ドキュメンテーション/バリデーション/クライアントの実装など、意外と副次的な作業が必要なので、、汎用化されたツールに頼れるのは助かる。マイクロサービスを用いたアーキテクチャを考えるにあたっても、システム間のアダプタをイメージしやすくなる。 そういう背景で、最近家ではgRPCを調べている。このあとはgRPCについて調べたことのメモや感想のコーナーになっているので、興味があったらどうぞ。 主な情報源 だいたいこのへんを眺めておくと、gRPCの基本については抑えることができる。 grpc

KyashでAndroidアプリを開発している@konifarです。 4/2 (月) にリリースした最新版で、ユーザー名を登録できるようになりました。本名の登録は今までどおり必須ですが、他のユーザーに本名を知られることなく利用できます。自分を例にすると、 小西 裕介 ではなく こにふぁー としてKyashを使えるようになったということですね。 結果だけを見ると「ようやく表示用の名前を登録できるようになった」という話なんですが、実際にリリースするまでに社内でどんなやりとりがあったのかを記しておきます。「ユーザー名の対応だけで時間かかりすぎだよ」というご意見ももちろんあると思いますが、Kyashのプロダクト開発がどんな感じで進んでいるのかをお伝えできれば幸いです。 対応検討開始 Kyashは2017年4月にリリースした当初から本名のみで利用する仕様でした。 もともと仲の良い数人の仲間内で使うこ

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

株式会社サイバーエージェント（本社：東京都渋谷区、代表取締役社長：藤田晋、東証一部上場：証券コード4751）は、現在10 箇所に分散する東京・渋谷のオフィスを2019 年に2 箇所のビルへ集約し、より一層の業務の効率化を図るためオフィス移転を実施することをお知らせいたします。 移転先は、東京都渋谷区宇田川町に竣工予定の複合ビル「Abema Towers（読み：アベマタワーズ）」にメディア事業、ゲーム事業、本社機能が入居し、東京都渋谷区渋谷に竣工予定の「渋谷スクランブルスクエア」に広告事業が入居する予定となっております。

@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みたいなやつ

WEBサービスの保守や開発をやっていると、JavaScriptやスタイルシート、画像などの静的リソースを更新した際、しばしば「確認したけど、更新されてないよ」とか云われて、「ブラウザのキャッシュを消してからもう一度見てみてください」みたいなやり取りが発生することがある。これが、サービス内部のメンバー間のやり取りであれば（非効率ではあるものの）まだ許せるが、サービスを提供している顧客側に更新内容が反映されない事態が発生してしまうと、それは障害と同義だ。 そんなわけで、WEBページにおける静的リソースの読み込みには開発時に注意を払う必要がある。確実な対処方法としては、静的リソースの読み込み時にリソースパスに動的パラメータを付与して、ブラウザにキャッシュされないようにすることだ。 下記のように、フロントエンドだけで対応することもできる。

どうも。ひがし（Twitter：@m_higa4）です。 VUI（Voice User Interface）の未来に魅力を感じ、色々勉強中です。 さて、Google HomeやAmazon Echoが日本で発売されて以来、サードパーティ（GoogleやAmazon以外の会社）によるVUIアプリ（声を使って操作するアプリ）の開発がどんどん進んでいますね！ 今日は自分がリリースしたアプリが、1週間どのように使われたかを共有することで、みなさんのアプリ企画に対する考えの幅を広げるきっかけになればと思っています。 一瞬だけど、ちょっとバズりました Google Home用アプリ（正確には「アクション」）である"運命のコイントス"をリリースしました。 レストランとかで何にしようか迷っていると、大体二択までは絞れるんですけど、そこから結構迷いません？（笑） そんな時に、このアプリを使えば、コイントスで

技術部開発基盤グループのシム(@shia)です。 最近は cookpad のメインレポジトリを開発しやすい環境に改善するために様々な試みをしています。 この記事ではその試みの一つとして不要な gem を検出し、削除した方法を紹介したいと思います。 背景 cookpad は10年以上にわたって運用されている巨大なウェブアプリケーションです。 巨大かつ古いアプリケーションには昔は使っていたが、現在は使われてない依存性などが技術負債として溜まっています。 事業的観点から技術的負債を完全返却するのはコストとのバランスが悪いことも多いです。 これは20万行を超えるプロジェクトを幾つも抱えている cookpad のメインレポジトリも例外ではなく、その規模から使ってないと思われる依存性を探しだすのも大変な状況でした。 どうするか 人が頑張るより機械に頑張らせたほうが楽ができるし、何より確実です。 ですの

「異能」ともいえる際立った能力や実績を持ち、まわりから一目置かれるエンジニアを1カ月に一人ずつ取り上げ、インタビューを掲載する。今月取り上げるのは「Yugui」というハンドルネームで知られる園田裕貴（そのだゆうき）氏。書籍「初めてのRuby」の執筆者であり、過去にはRuby 1.9系のリリースマネジャーを務めた。スケールアウト（現Supership）の初期中心メンバーの一人でもある。今回は、プログラミングとの出会いからWeb業界で働くようになったきっかけを聞いた。 プログラミングを始めたきっかけは、小学校低学年のころ、自宅にPC-8800シリーズ（PC-88）というパソコンがあったことです。父親はIT関係の仕事ではありませんでしたが、趣味で多少プログラミングをしていました。デスクトップミュージック（DTM）のようなことをしたり、自作のプログラムで事務処理をしたりしていたようです。 私も家で

モバイル通信事業者が、ユーザのギガの残量やデータプランなどをGoogleと共有する、「Mobile Data Plan Sharing API」というものがあるらしい。 モバイル通信事業者に提供されているAPIであり、おそらく一般サービス運営者は利用することは出来ない。 GoogleではこのAPIを通してユーザのデータプランを共有し、様々な最適化を行っているようである。 ユーザのデータ通信残量を考慮して通信の最適化を行う 通信のオフピークに通信を行う この連携を行うために、モバイル通信事業者が、DPAと呼ばれるデータプランをGoogleのサーバと共有するサービスや、PlanGloupIDを生成するPGID Endpointと呼ばれる機能を実装する必要がある。 すでに、インドの3通信事業者とYoutubeで非ピーク時にデータ通信をさせる実験済みらしい(Web5Gの文章より)。（Youtube

みなさんにも、さまざまな過去の経緯からくる微妙挙動を満載した外部ユーザ向けのHTTPサーバをリプレイスしたりするとき、実際にガツンとやっちまう前にちょっとリクエストを分岐して挙動と性能を確認したい、と思うことがあると思います。考えるだけでつらい気分になってくるやつ。でもやったほうが100倍マシなやつ。 どうしよっかなとちょっと考えたところ、少し前にこんな話があったのを思い出すはずですね*1。 asnokaze.hatenablog.com とはいえヨッシャ使うぞといきなりぶちこむこともできないので、まずいくつか試してみることにする。 準備 前提としては以下のように、元のアプリケーションと同じにホストにリバースプロキシが立っており、そこのnginxで http_mirror_module を使う、という想定*2。ミラー先はどこか適当なアプリケーションサーバ(あるいはロードバランサ)で、元アプ