初めてのフロントエンド

初めまして、開発本部のT.Aです。 突然ですが弥生では今年の3月、フロントエンジニア強化施策という取り組みが発足しました。

この3月の取り組み(第一回目)を見ていたメンバーが、自分もやりたい!と参加者を集め、先月から第二回目を開催しています。 私は業務上フロントに関わりないチームなのですが、「やりたい」と周囲に話していた所、参加させていただけることになりました。

というわけで本記事では、第二回フロントエンジニア強化施策の取り組みをババーンとお伝えします!

メンバー紹介

今回は運営メンバー3名、参加メンバー4名で施策を実施しています。

簡単な自己紹介も添えているので、お時間ある方は各メンバーの欄を展開して、ご覧ください。

運営メンバー

田中さん

  • フロントシステム開発/UX検討チームのプロジェクトリーダー
  • 声が大きい(物理)

K.Kさん

  • マイポータルWebの開発をテクニカル面でリードしている
  • Markdown記法の存在を私に教えてくれた人
  • 質問すると丁寧に教えてもらえる

S.Uさん

  • SMARTを開発している
  • 第一回目の参加者→今回の運営へ(前回記事)
  • 弱音を吐くと励ましてもらえる。。。

参加メンバー

D.Kさん

  • 入社四年目の先輩
  • オンライン製品を開発している
  • 基本雑だけど本気で困ってると助けてくれる

R.Oさん

  • 入社一年目(中途)の先輩
  • マイポータルWebを開発している
  • すごくものづくりに対する拘りがある(気がする)

R.Tさん

  • 入社三年目の先輩
  • 自動テスト作るチームのリーダー
  • 入社から今に至るまでお世話になってます。。。

T.A(私)

自分の話

導入がてら自己紹介を。先に内容が気になる方は施策の内容

現在の業務

新卒で入社し、現在二年目です。 R.Tさんと同じチームでデスクトップ製品の自動テストを作成・実施しています。 後は新卒の教育チームで後輩の研修や、ふりかえりを実施しています。

スキル

普段業務で使っているのはC#です。 学生時代フリー配布のテンプレートを編集してサイトを作っていました。 ただ、フロントスキルは「タグとセレクタって何?」「CSSって色変える以外に何ができるの?」というレベルでした。

施策を通じての目標

自分の作りたいもの(Webアプリ)を作るとっかかりを作る

大学時代、演劇をしていて見るのもやるのも好きでした。 しかし社会人になってから忙しくなり、公演を見に行くことがめっきり減り…。 好きな芝居は観たいけど、調べるために色んなサイト回るのは面倒くさい。 そんな人(自分)のための小劇場・学生演劇に特化した検索アプリを作りたい!

…と思い立ったはいいのですが、Web系の技術は種類が豊富すぎるし、Gitも開発環境も良くわからない。 ①調べる → ②どの技術から勉強するか決められない → ③一先ず業務でも使うC#の勉強する そのループを今年の3月くらいから繰り返していました。

そんな時に知ったのが、このフロントエンジニア強化施策です。 まずフロントエンドの技術をこの強化施策で勉強しよう! そこをきっかけにして、他(サーバーサイドとか、フレームワークとか)勉強しよう!

長くなりましたが要するに、この施策をきっかけに自主学習を進めることを目標にしています。

かっこいいサイトを作れるようになる

私が思うかっこいいサイト例:弥生30周年記念サイト 自分の中で「一から自分でデザインを考えて、調べながらサイトを作れる」ことができたら、フロントエンド少しはできると言っていいんじゃないかなと思っています。 ただ今まで、ネット上で配布されているテンプレートをいじってサイトを作ってきたため、一からサイトを作ったことがありません。 例えば、例に出した弥生のサイトで、メニューのメインの部分はどうやって分けているのか? 何も見ずに作るのは無理でも、これを使えば実現できそう!と考えられるレベルにはなりたいです。

他チームの方とたくさん話す

普段はデスクトップ製品の自動テストを作成しているため、オンラインやウェブ製品の開発をしている方と関わりがほとんどありません。それらのチームの方と話して、どんな技術を使って開発しているのか知りたいです。

施策の内容

使っているツール

やり方

  • 基本定時後に行う
  • ペアプロで実施する
    • 1人がコーディング、もう1人がそれを見てこうした方がいいんじゃないか、とかを話しながら画面を作る
  • 成果物の作成が完了したら、レビューを行う

最初の1週間でやったこと総まとめ

第一週目は、HTMLとCSSの基礎を学べるような施策を実施しました。 作ったものは全部で3つ。 以下のGitに全てコミットしています。 成果物置き場

  1. レスポンシブ対応画面作成 flexboxを利用して、レスポンシブ対応した画面を作成する
    作成画面 f:id:tomoe_aizawa:20170817085447p:plain ペアプロの担当:オペレーター⇒私、ドライバー⇒D.Kさん
    一番印象に残っている施策です。 画面自体はすぐに作成できました。 意気揚々レビューに出したら、田中さんから一言「flexboxを何もわかってない!笑」 この時は、アイテム(1)(2)(3)を一つのdivで囲い、 display:flexを当てていました。 また、 PC用の画面はflexboxのアイテム(1)を、width:100%(横幅いっぱい)にしてアイテム(2)(3)を(1)の下に回り込ませていました。 しかしそれではflexboxの良さを全く生かせていないとのこと…。 頂いた指摘を元にコードを修正。 f:id:tomoe_aizawa:20170817085626p:plain 元々上図の①(アイテム(1)(2)(3))しかdivで囲っていなかったのですが、②(アイテム(2)(3))もdivで囲み、それにもdisplay:flexを当てました。 さらに、flex-directionプロパティの値を変えることで、widthを指定せず横並びから縦並びに簡単に変えることができました!

  2. セレクタのトレーニング HTMLが指定されたデザインになるように、色んなセレクタを使ってスタイルを当てる
    作成画面 f:id:tomoe_aizawa:20170817085607p:plain ペアプロの担当:オペレーターD.Kさん⇒、ドライバー⇒私
    ペアの先輩(D.Kさん)のすごさを実感した施策でした。 この回は先輩がコーディングをしたのですが、指定されたスタイルをサクサク当てていくので、見ていて楽しかったです。 ここで「詳細度」というものを教えてもらったのですが、なるほどと、わかった気になってしまい、次の施策で慌てることに…。

  3. mock作成 弥生で実際に使われているボタンなどのUIの共通部品を利用して、画面を作成する
    作成画面 f:id:tomoe_aizawa:20170817085642p:plain ペアプロの担当:オペレーター⇒私、ドライバー⇒D.Kさん
    コピーペーストで部品を配置していく簡単(?)なトレーニング。 なのですが、なかなかお手本のデザインにならず四苦八苦しました。 上手くいかなかった原因は、 ① スタイルを当てても、より詳細度の深いものに打ち消されてしまう ② 要素の間に、開発者ツールで見ないとわからないmarginがある セレクタのトレーニングでなんとなくしかセレクタや詳細度を理解しなかったことが仇となりましたが、開発者ツールを駆使し、なんとか完成しました!

まとめ

施策を通じて学んだこと

HTMLとCSSについて

  • flexboxを使った画面構成のやり方、レスポンシブ対応した画面の作り方を知った
    • 画面を見たときにどう作ればいいのか、というイメージがつくようになった
  • CSSのセレクタの種類と詳細度について知った
    • セレクタ:種類とそれぞれのセレクタの使い方は分かった
    • 詳細度:概念は分かった。詳細度を意識してセレクタを使い分けできているわけではない
  • 弥生の共通部品を使ってみた
    • ※弥生標準として使われている「HTML、CSSのテンプレート」らしいです
    • 弥生のフロント開発ではこういうものを使っていると知った

他チームの方と話せた

  • オンライン製品のソースコードを少しだけ見せてもらえた
    • 使っているライブラリを知った
  • プログラミングする時に便利なショートカットキーや、小技を教えてもらった

サイトのデザインを見て、どう作るのかイメージできるようになれたのは嬉しかったです! ただ、flexboxの理解はまだまだ…。 実際にWebサイトを作って、理解を深めていこうと思います。 また、とっかかりができたと自分では思っているので、繁忙期が終わったらフレームワークの勉強に手を出したいな~と思ってます!

次の施策は……

f:id:tomoe_aizawa:20170817085701j:plain 上の弥生カレンダーをHTMLとCSSで作成中。 flexboxの新たな発見も有ったりしました。 試行錯誤の詳細は次回のR.Oさんの記事で! 乞うご期待!

【勉強会】弥生内での新人育成 vol.1 を開催します

セキトウ(@relaxteatime)です。

新人育成って難しいですよね。

  • 何をすればいいのだろうか?
  • どうやって教えればいいのだろうか?
  • 育成の評価ってどうすればいいんだろうか?
  • ・・・・etc

各社、いろいろと工夫をしていると思いますが、
弥生では、開発の新入社員は「自動化チーム」に配属となります。

自動化チームとは?

弥生では、デスクトップからオンラインまで幅広いラインナップがあります。
この幅広いラインナップの製品のテスト自動化を目的に作成されたチームです。

メンバーは、入社3年目ぐらいまで若手中心で結成されており、
製品のテストを通して、製品の仕様を覚えたり、
自動化プログラムを作ることにより、C#などのスキル向上を行っています。

弥生の自動化チームはここが違う

最近はDevOpsなどで、テスト自動化といったことをよく耳にしますが、
弥生は、Webだけでなく、デスクトップ製品もあります。

また、Webも帳票というやっかいなものが。。。。

ただ、一定の品質を担保する為には、 大変だとしてもテスト自動化はとても重要。
そこを解決していくのがテスト自動化チーム。

公開

上記のように、いろいろ大変なテスト自動化。
今回、弥生で行っている”自動化テストエンジン”の一部について、
お話させていただきます。

また、今回はゲストスピーカーとして、
理想科学工業株式会社の増田様に登壇していただきます。

理想科学工業株式会社では、組込みシステム技術協会のETロボコンへの参加を、新卒教育として実施されているそうです。

申し込み

2017/07/27(木) 19:30~21:00に、 新人育成やテスト自動化について、弥生本社にて勉強会を開催いたします。

興味を少しでも持たれた皆様、ぜひconnpassからお申込みください。

mokuteku.connpass.com

AWS Certificate Managerの自動更新に失敗??

弥生でAWS関連のインフラをやりつつ、
たまにJavaのコーディングもしているセキトウ(@relaxteatime)です。

弥生では、API通信部分や開発環境のAWS利用部分については、
AWS Certificate Manager(簡単に SSL/TLS 証明書を作成、管理、配置) | AWSを利用させていただいています。

証明書の自動更新の注意点にある、「失敗した場合」を体験したので 実際に行ったことを記載してみました。

aws.typepad.com

何故自動更新に失敗したのか?

弥生はACMを利用する際、1つ1つ証明書を発行するのは大変なので、*.yayoi-kk.co.jpというワイルドカード証明書を利用しています。
適用先は、ELB/CloudFrontです。
ELB配下には、EC2が存在しておりIPアドレス制限をしてます。

ワイルドカード証明書であり、IPアドレス制限を利用している。
たぶん両方が原因なんだと思っています。

更新前の状態

下記の通り、更新ステータスが検証保留中になってます。

ただ、ここで問題が。
公式マニュアルをみると、メールが飛んでくるはずだったのですが、メールが飛んでこない。 AWS CLIなどでも試したのですが、ダメ。

f:id:relaxteatime:20170623145200p:plain

やばい。どうしよう。

困った時は、サポートを有効活用しましょう。

  • 順次メールなどを送信する
  • AWS CLIなどで状態は確認できない。サポートで調べることができる

という内容でした。

まずは、一安心ですが、まだ証明書が更新されたわけではないので、ドキドキな毎日。

なお、弥生は AWSビジネスサポートにちゃんと入ってます。
aws.amazon.com

無事メールが到着

AWSアカウントのメールアドレスに"Action Required - Your cetificate renewal"というタイトルのメールが飛んできました。
中身的には、証明書更新の為のメールをwebmasterやadministratorのドメインメールに送ったから確認してね。
という内容。

webmasterやadministrator向けには、"Cetificate renewal for ドメイン名 requires approval"というタイトルでメールが飛んできてます。
後は、本文のリンクを踏むだけ。

いざ更新

下記図の通り、無事更新された。 よかったよかった。

f:id:relaxteatime:20170623145242p:plain

なお、実際にメールのリンクを踏んで更新されるまで、1時間ぐらいかかりました。

今までなら、定期的にcurlなどを使って確認していたかもしれません。
ただ、現在弊社では、Mackerelを導入しています。

MackerelのURL監視では、なんと証明書の有効期限までチェックしてくれるすごい機能があります。

mackerel.io

その為、後はいつ更新されるかな?とコーヒーを飲みつつノンビリです。
結果、1時間後に以下の通りOKが帰ってきました。

f:id:relaxteatime:20170623150110p:plain

結論

ACMはやっぱり便利です。
ただ、自動で有効期限が更新されないこともあるので気を付けましょう。

気をつけろって言われても・・・
と思われる人は、MackerelのURL監視をぜひ導入してみてはいかがでしょうか?