ZEALS TECH BLOG

チャットボットによる会話広告『fanp』を開発する株式会社ZEALSのテックブログです。技術やエンジニア文化について情報を発信します。

RDBの歴史をディグってみた

f:id:zeals-engineer:20190721141625p:plain

こんにちは!
4月に新卒で入社したエンジニアの荒木です。

業務ではデータの不整合を解消したり、データベースの構造を作り替えたりしています。

今回の記事のテーマは、【リレーショナルデータベース(RDB)の歴史】です。
RDBが生まれる以前のDBの歴史から、どのようにRDBが登場し、世に広まったのか、という流れを追います。

その背景としては僕が、歴史の勉強が大好きなことがあります。

単純に新たな知識・考え方が身につく、という理由もありますが、
それ以上に、物事のルーツを辿ることで、現在身の回りに当たり前のようにあるものが実は全く別の目的で生まれていたり、偶発性の産物だったりすることに好奇心が駆り立てられるからです。

僕たちが普段扱っている技術も全て、いつかの時代の何処かの国に住んでいた誰かの天才的な発見、発明の積み重ねによって確立されたものです。

遥か昔からの種々の学問的知見によって、今の技術が目の前にあると思うとワクワクしますよね!!

そこで今日は、RDBの歴史について調べてみたので、
それを極力分かりやすくシェアしたいと思います!

  • RDB以前のデータベースの歴史
  • RDBの登場
  • SQLの誕生
  • RDBの時代へ
  • まとめ
  • 参考文献

RDB以前のデータベースの歴史

データベースと言われると、エンジニアの方々はソフトウェアとしてのデータベースを想像するかもしれませんが、 広義に解釈されるデータベースは、もっと昔から存在します。

例えば、「鳴くよ(794年)ウグイス平安京」 と言いますが、
何年に起こったことなのかが判明しているということは、少なくともその時代から国の歴史のデータを蓄積するなんらかの機能があったということです。

我々は当たり前のように何年のどこで何が起きたのかを習ってきましたが、
それはソフトウェアとしてのデータベースがなかった時代から、脈々と受け継がれてきたものです。
すごいことですよね。

さて、初めてデータベースという単語が使われたのは、第二次世界大戦後、1950年代の米軍基地において
各基地に点在していたデータを、1箇所に集約した時であると言われています。

長らくデータを蓄積・保持してきた人類ですが、1960年代に入り、遂に ソフトウェアとしてのデータベース を発明します。

この時代では、IBMにより開発されたIMSと呼ばれる階層型モデルのデータベースと、
CODASYLの発表した関連ネットワークモデルのデータベースが人気のデータモデルでした。

f:id:zeals-engineer:20190720192253p:plain

階層型のデータベースはツリー型の構造で表され、現在で言う組織図のような構造になっていました。

1つのデータが1つ、もしくは複数のデータを子として持つことが許されていました。
そのため、「1対1」や「1対多」の関係を表現することができました。

しかし、このデータモデルはデータの冗長が発生しやすく、
例えば「多対1」を表現する時は、その子データは属する親データの数だけ存在する必要がありました。
また、エンジニアが階層型モデルでデータにアクセスするためには、その階層構造を理解している必要がありました。

その他に、階層型モデルを用いたプログラム開発は、プログラムが大きくデータ構造に依存してしまい、
保持・運用にかかるエンジニアの工数や必要とされる知識量が大きくなるという問題点を抱えていました。

一方、関連ネットワーク型のデータベースではデータは網の目の形で結ばれ、1つのデータが複数の親を持つことができるようになりました。
そのため、上記の冗長性の問題は解消されましたが、
階層型モデルの時の問題点であった、プログラムが大きくデータ構造に依存している問題は引き継がれ、
依然として保持・運用は難しい状況が続きました。

RDBの登場

そんな中、1970年にIBMのEdgar Frank "Ted" Codd(以下、コッド)が

"A Relational Model of Data for Large Shared Data Banks" https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
という論文を発表しました。

これが現在にリレーショナルデータベースとして広く知られるデータモデルの基礎的な考えでした。

リレーショナルデータモデル(以下、関係データモデル)では、全てのデータをテーブルという二次元表で表現しました。
さらにそのテーブルでは、行や列という位置情報にデータが縛られないという革新性を持っていました。

関係データモデルでは、階層型モデル等のようプログラマに複雑な実装や高い専門性を求めず、
データベースを欲する全ての人々にその利用を解放しました。

しかし、これらの革新性にも関わらず、当時のIBMはリレーショナルデータベースを実装することを拒みます。

当時IBMが開発・販売していた、階層モデルのIMSによる収益を守るためです。
いわゆる、イノベーションのジレンマでしょうか。

ja.wikipedia.org

SQLの誕生

その間に他の会社や研究チームはコッドの発表した関係データモデルに大きな可能性を感じ、開発に着手します。

最初に開発に着手したのは1973年、UC BerkeleyのMichael Stonebrakerによるもので、このDBは"Ingres"と名付けられました。
Ingresは後に、"Post"(後の)+ "Ingres"から、"Postgres"へ、そして"PostgreSQL"へと名前を変えます。

f:id:zeals-engineer:20190721222943p:plain

1974年にはIBMも関係データモデル型のDBの開発を始めますが、
コッドをプロジェクトマネージャーに指名することはしませんでした。

代わりに指名されたのは、コッドの関係データモデルの理論を快く思っていないチームで、
この開発チームがコッドと関わりを持たないようにすることが目的だったとされています。

コッドは関係データモデルの論文を発表した翌年の1971年に、
RDBを扱うための言語として"ALPHA"という言語を発表しましたが、
このアイディアが実装されることはなく、代わりにアサインされた開発チームにより、"SEQUEL"という言語が作られました。

とは言え、これは元のシステムよりも優れていました。
1975年、IBMは試験的なRDBである"System R"を発表します。

この"SEQUEL"が後に"SQL"と呼ばれるようになります。

RDBの時代へ

1977年、コッドの論文を読み、RDBに可能性を感じたLarry Ellisonが商用RDBを開発するべく、会社を設立します。
これが後のOracle社です。

1979年にこの会社は、世界初の商用RDBである"Oracle Database"をリリースします。
最初はミニコンピュータ専用のDBであったOracle Databaseも、1983年にはIBMのPC上でも利用可能になりました。

Oracleはどんどん成長し、同年1983年にIBMもついに商用RDBを開発・販売しますが、
既にOracleのDBはIBMの顧客にも導入されており、市場はOracleに支配されていました。

f:id:zeals-engineer:20190721223343p:plain

(↑Oracleの本社)

その後短期間でRDBは次々に開発され、1989年にはPostgreSQLが、1995年にはMySQLが最初のリリースを迎えます。

MySQLはMySQL ABというスウェーデンの企業により維持されていましたが、
2008年にMySQL ABはサン・マイクロシステムズに買収され、2010年にはサン・マイクロシステムズがOracleに買収されたことで 現在はOracleが商標権を有しています。

また、コッドは1981年にチューリング賞を受賞するなど、多くの賞を受賞しました。
その後、独立してコンサルティングの会社を設立しますが、2003年に心不全で亡くなりました。

まとめ

いかがだったでしょうか。

  • RDBも考案された当初はすぐに実装されることはなく、その可能性を信じた外部の人間によって今のような普及に至ったこと
  • RDBもSQLもIBMから生まれたものの、それらは異なる開発者から生まれたこと

この辺りを知れたのは、面白かったなあ、と思います。

僕自身もRDB以前のDBのモデルを調べることで、勉強になりました!

続きを読む

第1回 ZEALS Developer Meetupと称し、社内LT大会を実施してみた!

f:id:zeals-engineer:20190712114843p:plain

こんにちは!味わい深い担当のサーバサイドエンジニアKodyです!

先日 ZEALS DeveloperMeetup (社内LT大会) を開催したので、その模様をお届けしたいと思います!!!
同じく社内LT大会を企画しようとしている人に参考になれば幸いです!

  • Developer MeetUpを実施した背景
    • 目的
    • 内容
    • 発表人数
    • 発表時間
  • LTの内容を簡単にご紹介
    • 後藤 『GitHub Actions Hello World』
    • 阿部 『エンジニアでもできる Good UI & UX』
    • 中村 『React Componentの作り方』
  • さいごに

Developer MeetUpを実施した背景

目的

  • LTの練習場所を提供
    • LTしたいと思ってるけど、いきなりは怖い...というメンバーへ
    • プレゼンテーション能力の向上
  • 技術力の向上
    • アウトプットする機会を作ることで技術に対する理解度を深める
  • メンバー間の相互理解
    • メンバーが今どんなことに興味を持っていれるのか知ることができる

内容

  • 基本的になんでもOK(技術,組織, 作ってみたetc...)

発表人数

  • 3人前後
  • 飛び込みあり

発表時間

  • 5分 発表
  • 2 ~ 3分 質疑応答

LTの内容を簡単にご紹介

後藤 『GitHub Actions Hello World』

f:id:zeals-engineer:20190712114236p:plain

先日リリースされた Github Actions について、ごっちこと後藤が、自分の調査結果をダイジェストでLTしてくれました!
発表後に「これをこう使ったら便利かも?」と、Github Actionsの活用方法 がさっそく議論されていたのが印象的でした!

github.com

阿部 『エンジニアでもできる Good UI & UX』

f:id:zeals-engineer:20190712114538p:plain

あべじゃこと阿部ですが、最近プロジェクトで UI設計を担当した経験を活かしたLTをしてくれました!
彼女はサーバサイドエンジニアなのですが、UIにもこだわり、 少しの色の違いで改善されるユーザー体験 について話してくれました!

f:id:zeals-engineer:20190712115218p:plain

実際にスライドでUIを見比べて「おー、確かにこれは見やすい」「実装するときに意識します!」といった声が聞こえていました。

中村 『React Componentの作り方』

f:id:zeals-engineer:20190712114637p:plain

ごーやさんこと中村にはReactを用いたフロントエンド開発を設計から任せているのですが、その中で学んだコンポーネント設計についてのLTをしてくれました!

f:id:zeals-engineer:20190712115241p:plain

続きを読む

世界規模のハッカソン”AngelHack”の運営をしてきました!

皆さんこんにちは!
ZEALSでVPoE&サーバサイドエンジニアをやっている福本です!

6月29 ~ 30日に行われた『Angel Hack Tokyo 2019』に運営として参加してきましたので、当日の模様をお伝えさせて頂ければと思います。

www.routexinnovation.com

私Facebook公式Developerコミュニティである『Facbook Develper Circle』日本支部の運営を務めているのですが、今回のAngelHack TokyoにFacbook Develper Circleが協賛させていただいている関係で、運営として参加させてもらうことになりました。

tech.zeals.co.jp

それでは、ハッカソンの模様をお伝えするので、最後までお読み頂ければ幸いです。

  • AngelHack Tokyo 2019について
  • 会場の雰囲気
    • 場所
    • 雰囲気
  • ハッカソンの内容
    • ハック(開発)
    • ピッチ(発表)
  • さいごに

AngelHack Tokyo 2019について

「Angel Hack」は世界で同時期に開催されるハッカソンで、スタートアップ支援を目的としています。

優勝すれば世界的な投資家からの投資やメンタリングを受けることができ、今回開催されたのはその東京予選となります。

angelhack.com

また、Angel Hackの賞以外にも、AWSIBMメルカリなどの各スポンサーからの賞もあり、多くのエンジニアが集って賞を争いハックを行います。

ちなみに、今回はメルカリさんはじめ多くのスポンサー賞の条件にXR(VR/AR/MR)が関係していたため、作られたプロダクトにはXR関係のものが非常に多かったです!

会場の雰囲気

場所

場所はキラリトギンザの11階にありますビジネスハブ『BinaryStar』で行われました。

f:id:zeals-engineer:20190630162252j:plain

Facbook Develper Circle TokyoのオフィスがこのBinaryStarにあるため、こちらの会場を使用することになりました(※めちゃくちゃキレイな会場で、とてもリラックスして開発できそうな場所でした!)

雰囲気

当日の参加者なのですが、 なんと90人ものエンジニアの方に参加頂いたそうです(ありがとうございます)!!

f:id:zeals-engineer:20190630162527j:plain

普段XR周りのエンジニアの方とお話する機会は多くなかったのですが、この領域に賭けているだけあり、技術への思い入れが強く熱量の高い方が多いという印象を持ちました。

ハッカソンの内容

ハック(開発)

XRのデバイスをかぶった多くのエンジニアが黙々と開発を進める姿は、普段なかなか見られない光景でした。

デバイスは基本的には参加者の方々に持ち寄っていただく形となっていたのですが、発売されたばかりのOculus Questを持ち込む方がいらっしゃるなど、最新機器にふれる機会が非常に多かったです。

www.oculus.com

また、XRの性質上、ピッチの際はデモ動画を見せることが予測されるため、PCやスマートフォンとXRデバイスとの間でミラーリングを行い、その上で録画をする必要性がありました。

うまく録画できずに時間をロスされる方もいらっしゃったので、今後XRでハッカソンに参加される方は要注意です(会場でもさまざまなTipsが共有されました)。

note.mu

ピッチ(発表)

 2日目の午後からハッカソンの成果物をアピールするためのピッチが行われました(写真に問題があれば消します)!

f:id:zeals-engineer:20190630163112p:plain

ピッチは2分(!)とQ&Aで1分という非常にシビアな状況で、時間を超過した場合には、グローバルなハッカソンらしく容赦なく打ち切られるという条件でのピッチとなりました。

当日は27チームがピッチを行ったのですが、全体として「”コマース”と紐づけたプロダクト」「既存のスマートフォンやアプリの拡張を意識したプロダクト」が多かった、という印象を受けました。

こういったハッカソンへの参加は、技術力の向上はもちろん、技術のトレンドを掴むという意味でも非常に有意義な場であると改めて感じました。

f:id:zeals-engineer:20190701102847j:plain

さいごに

今回のハッカソンは運営がメインとなりましたが、当日の開発の様子や発表を観察するだけでも学びの多い経験をすることができました(自分も参加したい...)!

続きを読む

Gotanda.rbをZEALSオフィスにて開催 & 登壇しました #2

f:id:zeals-engineer:20190626201038j:plain

こんにちは!
ZEALSで Rails & Reactを書いている中村です!

今回もZEALSオフィスにてGotanda.rbが開催されたのでその様子をお伝えします!

前回のイベントレポートもありますので、Gotanda.rbに興味のある方はこちらもご覧ください。

tech.zeals.co.jp

テーマは"テスト"

今回も個性が溢れ出そうなテーマですね!

LTの内容は

  • factory_bot
  • Rspecの書き方
  • CircleCiとdocker
  • テスト設計
  • 飛び込みLT

こんな感じでした!

それでは早速登壇資料と共にGotanda.rbを振り返っていきましょう!

  • テーマは"テスト"
  • LT大会
    • ぼくらのかんがえたさいきょうのfactory_bot
    • Rspecあなたならどう書く?
    • 残して価値のあるテスト設計
    • CircleCIで docker-compose最強?
  • 番外編
  • 終わりに

LT大会

ぼくらのかんがえたさいきょうのfactory_bot

登壇資料 speakerdeck.com

最初のLTはZEALSエンジニアのtakkunです! 今回もRails Tシャツを着用し登壇していました。笑

f:id:zeals-engineer:20190626201038j:plain

takkunはfactory_botに関するLTでした!

default時代 → 一発作成時代 → 今

といったスライドの流れで

サービスの成長するに連れ、factory_botをどう改良していったかが、垣間見えるスライドになっています!
factory_botに興味がある方は是非ご覧ください!

Rspecあなたならどう書く?

drive.google.com

次はLinc'Wellの菅野さんです!

なんと一問一答形式のLTでした!
新しいですね!

ちなみにアンケートの内容は、普段テストを書くときのモヤモヤに関する事でした!

アンケートの結果も会場では意見が割れており、改めてテストに考えるきっかけとなりました!
集計の結果や、質問事項がスライドにあるので、是非皆さんも見てみてください!

残して価値のあるテスト設計

speakerdeck.com

次はスマートキャンプの今川さんです!
前職がQAエンジニアなんですね!!

LTの内容はテスト設計についてでした!
スライド後半にRspecでの応用の仕方が書いてあり、すごく勉強になりました!

また、「Rspecを仕様書であるかのように書きたい」というスライドが心に残っており、
それは正に残して価値のあるテストだと感じました!!

CircleCIで docker-compose最強?

speakerdeck.com

最後はマツリカの隅田さんです!
弊社の福本と共に、Gotamada.rbのOrganizerをしてもらっています!

テーマはCircleCidockerですね!

確か前回の登壇もdockerでしたね!

あれ。。。Rspecは?と思った方。。。大丈夫です!
最後にしっかりとRspecのお話をして頂きました!笑

スライドにcircleciのconfig.ymlのコードが掲載されているため、興味のある方は参考にしてみてください!

番外編

Gotanda.rbは飛び込みLTができます!
毎回飛び込みLTをしてくれる方がいるので、Gotanda.rbの名物になりそうです。笑

今回はSynamonのnontakさんです!!
飛び込みLTなのでスライドは用意できませんでしたがAWS Summit Tokyoについてのお話でした!

【参考URL】 aws.amazon.com

EC2とS3は個人PJで使った事があるのですが、他のサービスも触ってみたいですね!

終わりに

今回も登壇者の皆さまのお陰で、大変有意義な時間になりました!

続きを読む

ZEALSエンジニアに開発者アンケートを実施してみた

ãenqueteãã®ç»åæ¤ç´¢çµæ

皆さんこんにちは!
ZEALSでVPoE兼サーバサイドエンジニアをやっている福本です!

さて、本日はZEALS社内のエンジニアに使っている「エディタ」や「shell」などに関するアンケートを取ってみました!

普段ZEALSのエンジニアメンバーには、テックブログで記事を書いていただくことに協力してもらっています(ありがとう!)。

ただ、どんなエンジニアがZEALSで働いているのかを皆さんにお伝えする機会があまりなかったため、皆さんにチーム全体の雰囲気を知ってもらおうと、アンケートを取って公開しようと考えました。

宗教戦争的なものからそうでないものまで、いろんな意見を集めておりますので、よろしければ最後までご覧ください!

  • いつも使っているエディタは?
  • 使っているshellは?
  • 好きなプロダクトやサービスは何ですか?
  • 好きなor尊敬しているエンジニアは誰ですか?
  • 技術の情報収集の手段を教えてください!
  • ZEALS開発チームの好きなところは?
  • さいごに

いつも使っているエディタは?

The 宗教戦争なエディタ選定ですが、ZEALS内では圧倒的にVS Codeが多いですね!

それ以外にも、熱狂的なVimmerが所属したりしています。 

 

f:id:zeals-engineer:20190614104625p:plain

code.visualstudio.com

使っているshellは?

こちらは予想通りの三頭状態。
以前fishの記事をZEALSテックブログで書きましたが、以外とfishユーザー多いんですね...

 

f:id:zeals-engineer:20190614104644p:plain

好きなプロダクトやサービスは何ですか?

こちらは自由記述形式で、エンジニアメンバーが思い入れのあるプロダクトやサービスについて回答してもらいました!

結果は見事にバラバラで、普段使っているスマホアプリを挙げるメンバーもいれば、開発で使用しているツールを挙げるメンバーも居ましたね!

Medium
esa
Tabby CatというChromeの拡張機能…癒し(=^..^=)
Dreamscope。まだβ版ですがコンセプトが好きです
Airbnb
snapchat
学習サービスのExercismとRustコンパイラ最近めっちゃ好きです
spotify
RubyonRails, GitLab
キャンプファイヤー
pintrest
Codepen
Google map

好きなor尊敬しているエンジニアは誰ですか?

ロールモデルとなるエンジニアが居るかどうか?という質問です!
CTOの島田(hosmada)を挙げているメンバーが多く、CTOの愛され具合が現れてますね(気を遣っているわけではないと信じたい...笑)。

松本勇気さん(元グノシー/現DMM CTO)
hosmada
特にいない
Paul Graham、上杉 周作
Hosmada
hosmada
Typescript/Rust Language ServerのJonathan Turner, ClojureのRich Hickey
Salvatore Sanfilippo
kamipoさん, 松田明さん
伊藤淳一さん
mattn
Dan abramov
Dusty(ZEALS)

技術の情報収集の手段を教えてください!

エンジニアメンバーが、普段最もよく使う情報収集手段です!

結果は大半がTwitterでした。
やはり日本のエンジニア文化とTwitterは馴染みが良いんですね..

ちなみに、筆者はFeedlyでRSSをよく使っております!

f:id:zeals-engineer:20190614104656p:plain


 

feedly.com

ZEALS開発チームの好きなところは?

最後に、ZEALS開発チームの好きなところを挙げてもらいました。

色んなバックボーンを持っているメンバーが、同じ方向を向いて開発しているところ
仲が良く、向上心があって、一緒に働いて刺激になるし楽しいところ!
プロダクトにまっすぐで、良いものはどんどん吸収していこうというマインド!
チームが若く、裁量権があること
謙虚でひたむきな人が多いところ
互いにサポートしてくれるチームです
真面目でクレイジーでストイックなところ
みんなのびのび開発してるとこ
明るく前向きなところ
みんな技術が大好きなところ!!!
I love our team, and takakuda
Cool guys. Very open to everything and everyone. No negative energy. Love them all

 「楽しさ」「チームのまとまり」「向上心」といった内容が目に付きますね!
心理的安全性を担保して、メンバー全員が働きやすい環境を作るのはマネージャー陣の仕事なので、楽しく開発しているという声が聞けたのはすごく嬉しいですね。

rework.withgoogle.com

続きを読む

Gotanda.rbをZEALSオフィスにて開催 & ZEALSエンジニアが登壇しました!

f:id:zeals-engineer:20190604184832p:plain

はじめまして!
ZEALSで Rails & Reactを書いている中村です!

4月に復活したGotanda.rbのイベントがZEALSオフィスにて開催されたので、その様子をお伝えします! ZEALSエンジニアの福本がGotanda.rbのOrganizerであるため、今回ZEALSオフィスで開催する運びとなりました!

復活第一回目のイベントについての記事もありますので、Gotanda.rbの雰囲気を知りたい方はぜひこちらもご覧ください!

tech.zeals.co.jp

今回のテーマは"リファクタリング"

なかなかに渋いテーマですね!

  • そもそも、リファクタリングとは何か
  • リファクタリングをいつやるのか
  • リファクタリングを(チームで)どのように行うか

などなど、人によって内容に個性が出そうなテーマだと感じました!

それでは早速見ていきましょう!

LT大会

最初の登壇者はZEALSでRailsエンジニアをしているtakkunです!

f:id:zeals-engineer:20190606185137j:plain

写真ではわかりづらいですが、Railsのエラーメッセージが書かれたTシャツを着ています!
Railsへの愛を感じますね。笑

登壇資料

www.slideshare.net

スライドに紹介されているgem一覧

github.com

github.com

僕もZEALSにJoinするまで、これらのGemは知らなかったです!
2つのgemをうまく使えば、使われていないコードを綺麗に削除できますね!

またスライドの中の言葉で

「コードを追加するのは簡単だが、消すのは難しい」

って言葉が心に響きますね。

普段のコーディングから意識したい言葉です!

弊社takkunに続いて、3名+飛び込みで1名の計5名の方が登壇されました!
資料をアップロードして下さっている方もいらっしゃいますので、ぜひ見てみてください!

RubyMineでリファクタリング

エンジニアの皆さんの中には、お気に入りのエディタはカスタマイズして使っている方が多いと思います。
そんな中一度でも使ったら戻れなくなると噂のIDE RubyMineの機能を最大限に生かしたリファクタ方法を紹介されていました。

www.jetbrains.com

個人的にすごくインパクトがあったのは、一括リネーム(ファイル名・メソッド名・変数名)でした!
すごい…!!

RubyMineは有料のIDEですが、30日お試しで使用できるとのことです!

speakerdeck.com

クラウドワークスリファクタリングチーム「バグハンター」

クラウドワークスさんでリファクタ専門チーム作った時のお話です。
リファクタリングをモンスターハンターになぞらえて「分析した弱点部位に対してどのような武器を使って、どんな戦術で対処していったか」を発表されていました。

ZEALSでもtakkunがデザインパターンやオブジェクト指向の本を読みリファクタした、という話をしていました。
こちらの発表でも設計パターンを用いたお話があったので、その辺りももっと勉強しようと改めて思いました。

また、発表の中で「人を育てるコード」って言葉がすごい素敵で印象に残っています。

f:id:zeals-engineer:20190607105548j:plain

一覧画面のFatController/Modelになる理由と向き合ってみた

indexアクションが汚くなりがちな箇所に対しPORO(Plain Old Ruby Object)に切り出したり、生SQLを利用したり、ViewModelで定義してみたり...
問題点に対して様々な方法でリファクタしてみた、というお話でした。

原因に対していくつかの修正パターンを持っておく、というのはリファクタに限らず常日頃から意識したいと思いました!

speakerdeck.com

dockerで動いている プロジェクトのrubocop解析 vim編 + おまけ

最後はGotanda.rb Organizerであるマツリカの隅田さんの飛び込みLTでした!
前回もjoeさんが飛び込みLTをされていましたが、飛び込みが頻発するのは面白いですね。笑

「Docker+Vimでrubocopのリアルタイム警告を出すことができるようになったお話」と「OSS活動を続けてRubyMineのAll Products PackをGetした」というお話でした。
All Products Packを入手するには色々な条件とOSS活動を3ヶ月以上継続する必要があるそうですが、興味のある方は是非チャレンジしてみてはいかがでしょうか!

speakerdeck.com

交流会

f:id:zeals-engineer:20190607181910j:plain

LT大会後は、お酒を片手にお菓子をつまみながら参加者の方々と和やかに交流会の流れになりました。
こういう機会に社外の方といろんなお話ができるのはいい刺激になると思いました!

おわりに

今回は、各社向き合わなければならないリファクタリングというテーマについて掘り下げた会でした!

続きを読む

Kubernetesにおけるmanifestファイル, imageの管理について

f:id:zeals-engineer:20190603114959p:plain

こんにちは、CTOの島田です。

弊社サービスであるfanpでは、定期バッチ含む全サービスがGKE上で起動しています。

今回は Kubernetesのmanifestファイルやイメージを効率よく管理するための取り組みを紹介したいと思います。 Kubernetesを本番運用しているところだと基本的なことが中心の内容かと思いますが、お付き合いいただけますと幸いです。

  • Kubernetes化にあたって意識したこと
    • 環境の差異, manifestの再利用性
    • CD(Continuous Delivery)の効率化
  • ZEALSでの取り組み
    • container registry専用のprojectを作成した
    • manifest file専用のレポジトリを作成した
    • Cloud Buildで継続的デリバリ
  • さいごに

Kubernetes化にあたって意識したこと

環境の差異, manifestの再利用性

  • ステージング環境とプロダクション環境でそれぞれ異なる環境変数が定義されている
  • ステージング環境はプロダクション環境よりも少ないマシンリソースで運用したい

一方で、

  • 同じようなmanifest fileを大量に書きたくない
  • 別サービスの同環境で同じsecretを使いまわしたい

という思いがありました。

後者はcloud_sql_proxyのコンテナ起動に使用するJSONデータなどが該当するかと思います。
(複数サーバーで同一DBを参照する場合)

CD(Continuous Delivery)の効率化

数分で完了するデプロイ、大して複雑でないパイプラインを構築する上で、極力シンプルなCDツールを目指すことにしました。
CDツールを自分たちで構築/運用した場合, 定期的なバージョンアップも行わなければいけなかったりと手間がかかってしまいます。

また, 未だにKubernetesにおいてCDツールのデファクトは存在しないと考えています。
そのため、ツール依存の設定が増えてJenkinsおじさん的な事象が発生するのは避けかったという意図もありました。 

ZEALSでの取り組み

container registry専用のprojectを作成した

アプリケーションのコードを元にbuildしたimageを置くためだけのprojectです。
このcontainer registryでは環境依存のものは配置せず、再利用可能なイメージのみを設置します。

GCPは権限の設定がとても楽です。
Cloud Buildで別projectにあるContainer Registryからimageをpullするのも, Cloud Buildのサービスアカウントをcontainer registryのあるprojectに追加し, ストレージ オブジェクト閲覧者を付与したら動作します。

manifest file専用のレポジトリを作成した

全サービスのmanifest fileを1つのレポジトリに集約させました。
特徴は以下の通りです。

ディレクトリはざっくりこんな感じになりました。

.
├── bin/
│   └── gen_kustomize.sh
├── service1/
│   ├── base/
│   │   ├── deployment.yaml
│   │   ├── kustomization.yaml
│   │   └── service.yaml
│   └── overlays/
│       ├── fanp-prd/
│       │   ├── deployment.yaml
│       │   └── kustomization.yaml
│       └── fanp-stg/
│           ├── deployment.yaml
│           └── kustomization.yaml
├── service2/
│   ├── base/
│   │   ├── deployment.yaml
│   │   ├── kustomization.yaml
│   │   └── service.yaml
│   └── overlays/
│       ├── fanp-prd/
│       │   ├── deployment.yaml
│       │   └── kustomization.yaml
│       └── fanp-stg/
│           ├── deployment.yaml
│           └── kustomization.yaml
├── secrets/
│   ├── prd/
│   │   ├── kustomization.yaml
│   │   ├── secret-hogehoge.yaml
│   ├── stg/
│   │   ├── kustomization.yaml

Cloud Buildで継続的デリバリ

結果的にCloud Buildを使用しました。
Cloud Buildの使いところは、アプリケーションのimage build各環境へのデプロイ になります。 デプロイまでの流れは以下です。

  1. 各アプリケーションでgit tagを打ち、リモートリポジトリにtagをpush
  2. container registry専用のprojectにあるCloud Buildが発火, imageをbuild
  3. manifest専用レポジトリでimage tagを編集, deployブランチへプルリクを出す
  4. 3.のプルリクがマージされたら任意のprojectCloud Buildが発火しデプロイ

ZEALSではstgへのdeployブランチにマージされたらステージングのprojectのCloud Buildが発火、masterへマージされたらプロダクションのCloud Buildが発火し、デプロイが開始するようになっています。

さいごに

動きました!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

続きを読む

ZEALS第2回エンジニア開発合宿に行ってきました!!@三浦海岸

f:id:zeals-engineer:20190521171954j:plain

皆さんこんにちは!
サーバーサイドエンジニアの阿久津です!

5/11(土)〜5/12(日)の2日間、ZEALSで2回目となる「 エンジニア合宿 」に参加しました。
私は今回から初参加だったのですが、今回の合宿の様子を紹介させていただきます。

  • 概要
    • 開発合宿の目的
    • 合宿場所
    • 開発テーマ
  • タイムテーブル
    • 5月11日(土) 1日目
    • 5月12日(日) 2日目
  • 開発の様子
    • 1日目
    • 2日目
      • ダイエットアプリ
      • 顔認識
  • 良かったこと・反省
    • 良かったこと
    • 反省
  • 最後に

概要

開発合宿の目的

今回の開発の目的は以下3点です。

  • 普段の業務で触れることのできない技術に触れることで、組織全体の技術スタックの幅を増やす
  • 非日常でのコミュニケーションを取り、メンバーの結束を強くする
  • 今後、個人で勉強を進めていくきっかけを掴んでもらう

技術力の底上げはもちろんですが、普段できないような深いコミュニケーションも1つの大きな目的でした。

合宿場所

合宿の場所はモチベーションを左右する大切な要素ですよね!

社内の事前アンケートの結果、オフィスからのアクセス1時間以内の近場ということでマホロバ・マインズ三浦さんに決定しました!

開発は室内なのでどこでもよい派だったのですが、考え改めました。。
綺麗な海を間近で見ることができる環境最高!

f:id:zeals-engineer:20190521172338j:plain

開発テーマ

前回の開発合宿では、皆が持ち寄ったテーマをもとにチームに分かれて行うメンバーが多かったのですが、今回は以下のゴールのいずれかを満たせればテーマは自由でした。

  1. プロダクトに跳ね返る
  2. 外部に情報発信できる
  3. 技術の有用性を伝えられる

合宿に参加するにあたり、各自テーマを決めて合宿前に事前に共有してから開発をスタートさせます。

開発スタイルは個人でもくもくスタイルでも、チームでワイワイスタイルでも特に制限はありません。
各メンバーが一番開発しやすいスタイルで開発します。

今回のテーマは自由だったこともあり、バラエティーに富んでいましたが、大きく分けるとこんな感じでした。

  • 社内のアセット整理
  • これから学ぼうとしている言語を使ったアプリ開発
  • 社内のプロダクトに活きる新しい技術の深掘り
  • 開発の効率化ツールの導入

私自身は画像認識に前々から興味があったので、OpenCVを使った顔認識とモーションディテクションにチャレンジしてみました。

タイムテーブル

5月11日(土) 1日目

  • 12:00〜: 現地集合
  • 13:00〜:オープニング開発スタート
  • 19:30〜: 夕食
  • 21:00〜: 自由行動

5月12日(日) 2日目

  • 8:00〜: 朝食
  • 9:00〜: 開発スタート
  • 11:00〜: アウトプット発表
  • 13:00〜: 現地解散

開発の様子

1日目

開発場所はホテルの9階、眺めはバッチリです。 f:id:zeals-engineer:20190521172831j:plain

テーマは事前に決めていたため、簡単なオープニング後すぐに開発スタートです。 f:id:zeals-engineer:20190521172858j:plain

各々好きな場所で開発中。海を見ながらの開発は最高に気分がいいですね。 f:id:zeals-engineer:20190521172928j:plain

19:30に中間報告感を行い、待ちに待った夕食タイムです f:id:zeals-engineer:20190521172954j:plain

食後はフリータイムです。近場の海を散策したり、持ち寄ったゲームで楽しんたり、引き続き開発を楽しんだりしました。チームメンバーの距離感が一気に縮まる貴重な時間でした。僕自身普段あまり聞かない、エンジニアになるきっかけとなった話や仕事に対す熱い思いを聞くことができる、ある意味最も濃い時間でした。 f:id:zeals-engineer:20190522105150j:plain

2日目

朝食後いよいよラストの追い込みです。
みんな開発に集中しすぎて写真が一枚もない。。

11時から各自のアウトプットを全員に向けて発表です。

今回テーマを絞らなかったことで、アウトプットの形も様々で、聞くだけでワクワクしました。
そんな中から、いくつかアウトプットをご紹介します!

ダイエットアプリ

Reactの技術深掘りと本人のニーズがマッチしたプロダクトです。
開発期間短い中でもしっかり動くプロダクトをアウトプットとして出すところにプロ意識感じます!

f:id:zeals-engineer:20190522111609p:plain

顔認識

精度はまだまだですが、顔の認識ができるようになりました。
画像が荒くなってしまいましたが、PCのカメラからiPadで表示した弊社CEO、CTOをしっかり認識してくれています。

f:id:zeals-engineer:20190521174312p:plain

github.com

合宿を通して個人としては小さな成功体験を何度も感じることができました。
そして、新しい言語を学び始めたメンバーはこの合宿をきっかけに、学びが深まり業務にダイレクトに還元されています!

良かったこと・反省

合宿終了後、参加メンバーで振り返りを行いました。

良かったこと

  • 掲げていた目標はすべて達成できた
  • 開発環境が良かった
    • 海が見える開放的な場所でリフレッシュもできた
    • 片道1時間のため、移動で疲れることがなかった
  • コミュニケーションが取れた
    • 普段話せないメンバーと話したり、深い話をすることができた
  • テーマを事前に決めていたので、すぐに開発に取り掛かることができた
続きを読む