一休における開発組織の変遷（目的型組織への移行） - 一休.com Developers Blog
メリークリスマスイブ！ 皆様クリスマスイブはいかがお過ごしですか。 データサイエンス部所属のエンジニア 笹島 id:sisijumi です。 年末ということもあり、今日は一休という会社のエンジニア組織の変遷を振り返るとともに、現状に関してもお話させていただきます。 （現状はデータサイエンス部ですが、今年の10月までは宿泊事業部のエンジニアのマネージャーをやっておりました。） 一休における収益の変遷 宿泊事業に関してですが、過去発表した資料を元に説明させていただきます。 （近年非上場になった為、直近の収益に関しては資料はありません。） 創業期、成長期を経て、一時停滞したものの、きちんと再度成長していることがわかりますね。 事業のステージに合わせて変化してきました 創業期、成長期を支えてきた組織構造 各部署内に宿泊・レストランチームが存在しています 各部署が都度エンジニアのマネージャーとコミュ
Amazon EKSでgRPCサーバを運用する - 一休.com Developers Blog
以前の記事でも紹介した通り、一休では、gRPCを使ったサービスを導入し始めています。 user-first.ikyu.co.jp この記事では、このサービスをAmazon EKSで提供するための設計や気をつけたポイントについて紹介します。 背景 一休では、ウェブアプリケーションの実行環境としてAWS Elastic Beanstalkを採用しています。 そして、この4月からElastic BeanstalkをAmazon EKSへ移行するプロジェクトを進めています。 このgRPCサービスもElastic Beanstalkで運用をしていましたが、以下の問題を抱えていました。 適切にロードバランシングできない。 Elastic BeanstalkでgRPCサービスを運用しようとするとNetwork Load Balancer(NLB)を使うことになります。NLBはレイヤ4のロードバランサです
履歴テーブルについて - 一休.com Developers Blog
この記事は一休.com アドベントカレンダーの25日目の記事です。 レストラン事業部エンジニアのid:ninjinkunです。 一休.com及び一休.comレストランはユーザー向けのシステムだけではなく、店舗や一休内の管理者向けの業務システムという性格も持っています。 業務システム経験の無かった自分が一休に転職して最初に驚いたのが、DBに履歴を保持するための履歴テーブルが大量にあることでした。 そこから履歴テーブルの存在に興味と疑問を持ち、社内外のエンジニアと履歴テーブルについて議論してきました。このエントリではそれらの議論をまとめた結果について書いていきます。 履歴テーブルのパターン まず以下の図をご覧ください。 込み入った図かつ事例が一休特化で恐縮ですが、左上の起点から始まって、右のオレンジの部分が最終的な実装パターンです。 図にあるとおり、たいていのユースケースでは以下の3パターンの
Go + TypeScriptによるGraphQLスキーマ駆動開発 - 一休.com Developers Blog
こんにちは。宿泊事業本部の宇都宮です。この記事では、GraphQLをベースに、GoとTypeScriptでスキーマを共有しながら開発を進める方法について紹介します。 この記事は 一休.com Advent Calendar 2019 の16日目の記事です。 GraphQLとは ライブラリの選定 コードファースト vs スキーマファースト Goによるサーバ実装 TypeScriptによるクライアント実装 おわりに 参考文献 GraphQLとは GraphQLは、Facebookによって開発された、Web APIのための クエリ言語 です。その特徴もSQLに似ていて、データの取得や更新を宣言的な記述によって行うことが出来ます。 仕様は公開されており、リファレンス実装として graphql-js がありますが、それ以外にも様々な言語でGraphQLサーバを実装できます。 GraphQLでは以下の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
