こんにちは！今年4月に入社した新卒7期エンジニアのえんどぅ(@endu)&しずちゃん(@shizuchan)&こーめい(@komei)&がっちゃん(@gatchan)です。 2017年8月3日(木)〜2017年8月5日(土)に開催されたbuilderscon tokyo 2017にエンジニア研修の一環として参加しました。
buildersconとは?
※公式サイトより転載
buildersconは「知らなかった、を聞く」をテーマとした技術を愛する全てのギーク達のお祭りです。buildersconではトークに関して技術的な制約はありません、特定のプログラミング言語や技術スタックによるくくりも設けません。 必要なのは技術者達に刺激を与えワクワクさせてくれるアイデアのみです。
弊社からはホスティング事業部のCTL(Chief Technical Lead)の@pyamaと執行役員CPO (Chief Productivity Officer)の@hsbtがスピーカとして登壇しました。 詳細は以下のページに記載されているのでこちらをご覧下さい。
この記事ではbuilderscon tokyo 2017に参加した新卒エンジニアの4人が、興味を持ったセッションに参加して感じた事、学んだ事をレポートします。
「RDBアンチパターン リファクタリング」で知らなかったを、聞く
こんにちは！最近エアコンを購入して自宅から一歩もでたくないえんどぅです！ 普段はPHPやRubyを書いている新卒エンジニアです。
builderscon tokyo 2017は前夜祭を含めて3日間参加したのですがその中でも@soudai1025さんの「RDBアンチパターン リファクタリング」が面白く、データベースのリファクタリングを経験してない自分にとって、buildersconのテーマである「知らなかった、を聞く」に相応しいセッションだったと感じたのでここで紹介しようと思います。
私はデータベース周りが凄く苦手で大学時代も苦戦したり、設計もそれほどちゃんと考えずに「SQL叩いてデータが取得できればいい」精神でした。 しかし「RDBアンチパターン リファクタリング」の発表を聞いて、知らなかった事尽くしで改めて「ちゃんと設計を考えよう。継続的にリファクタリングをしよう」という気持ちになりました。
研修中の経験から以下の3つが特に印象に残りました。
- データベースの設計を疎かにすると後々のサービスの成長に影響するし、コードの実装にも大きく影響する
- データベースのリファクタリングは手間がかかるため、それなりの覚悟が必要。 だからこそ継続してデータベース・リファクタリングをする必要がある
- データベースの寿命はアプリケーションよりも長い
ペパボでは新卒研修期間に新卒のエンジニアとデザイナーが手を組んで5日で1つのサービスをつくる 「お産ウィーク」という研修があります。 2チームにわかれて開発するのですが、私達のチームはまさにデータベースの設計を疎かにしてしまった事があり、途中からリファクタリングをしようにも難しく開発の後半で大きな遅れが出てしまった痛い経験をしました。
発表では「牛乳」の例でわかりやすく説明されていたのですが、最初は皆同じ牛乳(初期設計)で上手く年数を重ねていけばお金を生み出す価値のあるチーズ(よく設計されたデータベース)になります。問題は仕様の変更に弱く、年数が経てば立つほど負債がたまるデータベースです。不安定に設計されたデータベースをチーズと対比して腐った牛乳と紹介していたのですが、このようなデータベースを意図せず生み出した場合、リファクタリングする為にはどうすればよいのか?となってきます。
発表ではアンチパターンを見極め、次にアプリケーションの抽象化を行い、モニタリング、テストコードを書いて品質を保ち、最後に覚悟が必要であると述べられていました。覚悟というのは、データベースにリファクタリングを行うという事は稼働しているサービスの影響も考えなければならず、小さい変更を長いスパンをかけて行う必要があり手間も時間もかかります。なので、これだけの労力を払ってリファクタリングを行うだけの価値があるデータベースなのか?を検討し、それを決めた上で実行する覚悟が必要であるのだと、発表を聞いて強く感じました。
このセッションを聞いて、個人的にデータベース リファクタリングの話に限らず、それ以上にエンジニアとして問題に立ち向かう際の立ち振舞やサービスの品質をどう向上すべきかも一緒に学べた非常に熱いプレゼンだと思いました。「データベースの寿命はアプリケーションよりも長い」この言葉にあるように、一度作ったデータベースはそれで終わりではなく定期的にメンテナンスをし、リファクタリングをしなければサービスの品質にも影響が生じます。 ペパボは歴史の長いサービスが多くあり、サービスの品質を向上できるよう発表で述べていた事を配属後も忘れず実践して、継続的リファクタリングを心がけようと思います!
「polyglot」について知ったこと、感じたこと
こんにちは、新卒のしずちゃんです。モバイルアプリエンジニアを目指しているのですが、最近は画像加工に興味があり、勉強がてら特別役に立たない画像加工アプリを量産しています！
最も印象に残ったセッションは@janus_welさんの「polyglotになろう!!」です。 polyglotとは、「数カ国語に通じる人」という意味ですが、転じて「プログラミング言語を複数扱える人」という意味で使われるそうです。
私はiOSアプリ開発に興味があり、学生の頃からSwiftを勉強しています。 Swiftについての学習はとても楽しいのですが、最近は他の言語も使えるようになりたいと考え始めていました。 しかし、大学時代CやScheme、Gallinaなど複数言語の講義を受けるもどれも使えるまでには至らなかったという経験をしていました。 また、自分の時間に他の言語を少し触ってみるも、そもそもSwiftもまだ満足に書けないのだからそれができてからにしようと結局戻ってしまうということを繰り返していました。 そんな中でこのセッションを見つけ、複数言語を扱えるようになるメリットや他の言語を学習し始める足がかりを知りたいと思い参加しました。
セッションの中では、「polyglotとは？」、「polyglotのメリット」、「polyglotになるには」という3点についてお話されていました。
その中でも特に印象に残ったのは2つのメリットについてのお話でした。 1つ目は、「ある言語の概念を別言語に持ち込むことができる」という点です。これは、各言語にそれぞれ特徴的な設計や規則があり、それらを複数学ぶことにより様々な実装方法や設計思想を取り入れることができるという内容でした。 2つ目は、「特定のひとつの言語についてもより深い理解を得られる」という点です。これは、複数の言語を学ぶことで言語を別視点で眺めることができるため、それぞれの言語に対しての理解も進むという内容でした。 「複数の言語を使えるようになる」ということはつまり「複数のことができるようになる」ということだと思っていましたが、それ以外にもこんなにもメリットがあるのだということを学びました。 また、現在研修の一環として毎朝各個人が自分の興味がある本を読み、その場で内容を発表する読書会を行なっています。 その中で、自分が発表した内容に対して同期から「自分が知っている言語ではこのように考えるけれど、Swiftはこうなんだ」といったコメントを受け、それが新しい発見になるということがよくあります。 このような場面で自分自身も確かに違う視点から理解を深める経験をしており、自分で複数学習することでより多角的な視点を持つことができそうだと感じました。
また、もう一つ印象に残ったのが、polyglotになるには全く別の領域に手を出してみるのが良いというお話でした。 今まで新しい言語を始めようと思った際に主に学んでいる言語と似ているものからやってみようなどという発想をしていましたが、全く別の領域に手を出してみることで、上記のようなより大きいメリットを得ることができ、また、自分でできることの幅も広がるのではないかと感じました。
このセッションに参加したことで、複数言語を学ぶことのメリットをたくさん知ることができ、次にどのような言語を学ぶのが良いかということについても考えることができました。 今後は最も興味のあるSwiftの学習も続けつつ、異なる領域でかつ研修で少し触れたRubyを学習し使えるようになることでpolyglotを目指したいと思います！
（参考）polyglotになろう!!
「横山三国志の全文検索システム」を聞いて
はじめまして、こーめいと申します。ちなみに孔命が本名で諸葛亮孔明から名付けられています。 そんな私が聞くために用意されたかのような@heruheru3 さんの『横山三国志に「うむ」は何コマある？〜マンガ全文検索システムの構築』という発表を聞いてきました。 結論から言うと、横山三国志には「うむ」の台詞があるコマは456回登場するそうです！ 「そんなに多いのかぁ〜」という私の感想はさておき、発表者の方がどのように台詞の検索エンジンを構築したのかという技術的な話が大変面白かったため紹介いたします。
マンガ全文検索システムを簡単に説明します。
- OpenCVを利用して、マンガの画像からそれぞれのコマ毎に画像を分割します。これによりコマの画像を取得できます。
- Google Cloud Vision APIのOCR機能を使って、コマ画像に対してOCRを実行し、コマ画像に対応する吹き出しの文字データを取得します。
- Python製のWhooshを使って、文字データのインデックス（N-gram）を作り文字と画像ファイルを紐付け完成です。
このシステムによって、横山三国志の何巻の何ページに検索キーワードが含まれたコマがあるということがわかるようになると述べられていました。
この発表を聞く前、私はマンガの文字（画像）をテキストとしてデータ化する方法の見当がつきませんでした。 しかし、この発表を聞いて、マンガの画像からコマを切り出す方法やGoogle OCRを利用して画像の文字をテキスト化できること、Python Whooshを使って全文検索を実装できることなど様々な技術を学ぶことができました。 また、私はシステムの応用で紹介された自動翻訳する機能が大変印象に残りました。 Google OCRの技術とOpenCVを応用すると、吹き出し部分の文字を白で塗りつぶして文字を差し返えることができると述べられていました。 この使い方は、発表者が実際にシステムを構築していく中で得られた経験から思いつくことのできた発想だと感じられ、開発を行っていく中で自分の技術に対する理解が進み、それが結果的に新しい機能に繋がったと思いました。 このように、開発を行っていく中で技術的な成長があり、その成長が新しい機能を生み出すことに繋がるのは非常に重要なことだと感じました。
最後に、この発表を聞いて、学んだことをまとめます。 技術的な面では、以下のことを学びました
- 画像処理に関する技術
- Google OCRを用いて画像の文字をテキスト化できること
- Python Whooshを使って全文検索エンジンを作ることができること
思考的な面では、開発を通して技術的な成長をするだけではなく、得られた経験や技術から新しい発想に繋げることが重要だと考えるようになりました。 そのためには、開発を行っていく中で技術の応用先を考えることが重要であり、その結果、次に目指すべきものや新たな機能を生み出すことができたら良いと思いました。 また、新しい発想につなげるためには技術の理解を深める事と技術のトピックを多く知っている必要があると思うので、最新の情報に目を向け、その技術を使って実現できることや他との組み合わせで実現できる可能性を考えていきたいです。 今回の発表を聞いて得られたことを活かして、システム開発に取り組んでいきたいと思います！
（参考）横山三国志に「うむ」は何コマある？〜マンガ全文検索システムの構築
HTML+CSSのコンポーネント化について
おはこんばんちは！プログラミングのほかには建物を鑑賞したり、エレベータに乗ったりすることが大好きながっちゃんです。 buildersconのテーマにある「知らなかった、を聞く」を実践すべく、私の理解に自信がないHTMLとCSSのコンポーネント化について、@Takazudoさんの「真のコンポーネント粒度を求めて」を聴きました。 私もウェブサイトの構築を行った際に、自分の思いつくままにコーディングを行った結果、ページの増加につれてCSSも肥大化する事態に陥り、やがて1箇所の変更による影響範囲がわからなくなってしまい大変な思いをした経験がありました。 HTMLやCSSをコンポーネントとして適切に記述し管理すれば、このような問題を起こりにくくできることは想像できます。 具体的にどのように設計することで、たとえウェブサイトが巨大化しても安心してデザインを変更できるようになるのか、興味がありました。
発表でも、「CSSの記述は全てグローバルのために影響範囲が大きいので、設計論で制約を設けることが必要である」と述べられていました。 HTML+CSSの設計論としては、「OOCSS」「BEM」がよく知られているようです。
OOCSSは、一つ一つのパーツ毎にデザインを記述し、それらを組み合わせてページを構成する考え方です。 また、同じ見た目でも色が異なるパーツが必要な場合のように、バリエーションのあるパーツの定義には、「ベースとスキン」の考え方も提唱しています。 これは、基本となるパーツのCSSを定義し、一部のデザインを変更する際にはクラスセレクタを追加する、というものです。
BEMは、パーツをコンポーネント化する設計論を示したもので、Elementの集まりで構成されたBlockでページを組み立てます。 また、BlockやElementのデザインを少し変更したいときにはModifierを用います。 Block、Element、Modifierを構成するようにCSSクラスを命名し、HTMLを構成することでコンポーネント化しようという考え方のようです。
しかし、実際にこれらの設計論を採用しようとすると、コンポーネントをどこまで細分化するか、名称の抽象度はどの程度にするべきか、といった悩みを伴います。 それらを解決する糸口として、「Atomic Design」や「Enduring CSS」が紹介されていました。 「Atomic Design」は、ページを作成するという認識を改め、「デザインシステム」を構築していくという考え方と方法論が記されています。 CSS設計の手法にとどまらず、ワークフローなどにも言及しており、デザインシステムの重要性やシステム構築の方法が幅広く記述されているようです。 一方、「Enduring CSS」では、各機能ごとのまとまりで大きめにコンポーネントを定義することでCSSの影響範囲を限定的にするという、OOCSSとは対照的な考え方をもっています。 発表では、これらの考え方を参考に、状況に応じて検討することがよいのではないかと述べられていました。
私は特に「Enduring CSS」に興味を持ちました。 似たようなデザインのパーツでも、用いられる場所が異なれば全くの別物としてCSSを記述することになるため、似たようなソースコードが増えることにはなります。 しかし、コンポーネントが分離されていることでCSSの影響範囲が限定され、迷いなくデザインの変更や削除ができる利点があります。 私は今まで、コピー＆ペーストが散見されるコーディングは良くないという認識でしたが、利点と欠点のバランスを適切に見極めれば、必ずしもそうでもない場合があるということに気づくことができました。 自身の固定観念を壊してくれる良い機会になったと思います。
私が発表を聴いて感じたことは、世の中にある様々な設計論を知り、適切なものを選択できるようにしておくことが重要であることです。 当たり前のことかもしれませんが、これから本格的にチームでの開発を経験する私にとってはこの気づきは重要であり、様々な考え方から状況に応じた手法を引き出せることで、チームにおける開発でも説得力のある提案ができそうだと感じました。 状況に応じて最適な手法でシステムを構築することを実践し、迷いなくデザインを変更することのできるような、強いソースコードを生み出していきたいです。
（参考）真のコンポーネント粒度を求めて
まとめ
今回、新卒エンジニア4名で参加したbuilderscon tokyo 2017で、それぞれ最も印象に残ったセッションについて感想をまとめました。 各々が、今まで興味を持って取り組んできたこととはまた違った分野のセッションに参加し、イベントテーマとして掲げられている通り「知らなかった、を聞く」ことができたのではないかと思います。
そして、今回のイベントへの参加により興味の幅を広げ、今後業務で活かすことのできる知識や考え方を得ることができただけではなく、発表者の方々のように多くの人に刺激を与えるようなアウトプットをしていけるように頑張るぞ！という気持ちになりました。
以上、新卒エンジニアによるbuilderscon tokyo 2017参加レポートでした。