はじめに こんにちは。 年末に http://www.java-users.jp/ccc2018fall/#/ に参加してきましたので、少し期間が空いてしまいましたが、聴講したセッションについて投稿します。 当日のタイムテーブル、資料は下記をご覧ください。 https://docs.google.com/spreadsheets/d/1cyNPjk8doq26FgjhLVwA0Pw2grGFwxqo4yVXqJgQCTE/edit#gid=413114967 qiita.com はじめに 参加セッション セッション感想 IBM CloudとKubernetesでSpring Bootのマイクロサービスを簡単に！ エムスリーでのKotlinへの取り組み Java を活用したマイクロサービスのための Kubernetes 活用 終わりに 参加セッション https://jjug-cfp.cfapps.io/submissions/017fc549-8d12-49dc-bb20-08ed3c9ccbb2 https://jjug-cfp.cfapps.io/submissions/331c1102-be76-4e17-bf7c-43f55dbc73da https://jjug-cfp.cfapps.io/submissions/cf4aefdb-b146-449e-9350-66f581900a84 セッション感想 IBM Cloudと Kubernetes でSpring Bootのマイクロサービスを簡単に！ IBM クラウド 上に Kubernetes の クラスタ を作成して、DBの構築、事前にDockerイメージとして作っておいたSpring Bootの Java アプリケーションをデプロイしてサービスを構築していくセッションとなっていました。 先日からDocker周りに興味が湧いているところなので、次は Kubernetes に手を出すいいきっかけになりそう。 エムスリーでのKotlinへの取り組み 運用中の Java アプリケーションをKotlinに移行する話。 移行の方法としては３通りほど考えられていましたが、今回は「全部まとめて書き換える」方法を取られていました。 コンバート中は完全に機能開発を止めて、移行をすることに集中、余計なことはしない、短期間に完了する。 移行作業のノウハウを学ぶことができ、システムをAからBに移行するぞとなった時の参考になりそうです。 Java を活用したマイクロサービスのための Kubernetes 活用 かなり内容の濃いセッションになっていて、 k8s にまだ触れていない私は少々パンク気味でしたが、今後自身で K8s を触る時の参考になるTips紹介が多かったです。 Docker関連 Dockerイメージの取得時、いつのバージョンかわからなくなるのでlatestは使わないこと! 小さなサイズのイメージをつくるように! DockerHubのイメージは安全か? 信頼されてないイメージは 脆弱性 が含まれている可能性はある。 本番利用するならセキュリティチェック・検証はしましょう。 k8s 関連 利用用途によって、向き不向きあるので何でもかんでも k8s でというのはやめましょう。 k8s は色々できるけど、全ての機能を使う必要はない！ 後々のメンテナンスのことも考えてシンプルな構成にしておくのがおすすめ。 k8s のバージョンアップには要注意！ 今まで動いていた yaml では動かなくなる可能性がある。 新しく クラスタ を作成して、動くことがわかってからルーティングを変えて対処しましょう Docker、 k8s に関してはまだまだ初学者であるため、触り程度でしかわかっていない部分がありますが、今後触っていく際の有益な情報になりました。 何でもかんでも k8s でというのはやめましょう。 私もよく言われていて耳が痛いですが、手段ベースでものを選んではいけないの典型ですね。 終わりに JJUG には昨年度から参加していますが、昨年よりも内容がわかるようになっている自分を感じることができました。 同じテーマで複数の発表があれば今のトレンドの技術はこれなのかな？といった業界の流れのようなものも少し感じられた点も昨年から参加していた成果かと思います。 若手にとって、はじめての勉強会やカンファレンスへの参加は足が重い人が多いかもしれませんが、大きめのカンファレンスは参加のハードルも低いので、１ヶ月後に入社する新メンバーにもオススメしてあげたいです。

こんにちは。新卒1年目エンジニアのbadaikiです。 はじめに 今回は、先日大阪オフィスで開催された3月ビアバッシュをご紹介いたします。 前回のビアバッシュの記事はこちらです。↓ tech-blog.rakus.co.jp はじめに テーマ枠発表 自由枠発表 サービスの環境構築 1年間で得た新たなCSSの知識 おわりに テーマ枠発表 今回のテーマは、「トラブル事例特集」。今年度に発生したトラブルを発表していただきました。 「今年度のトラブルは今年度のうちに」ということで、何が原因でどのように対処したのか、各チームに当時の心情も込めてお話していただきました。 共有したいところなのですが、ほとんどの内容が社外秘の内容のため以下は発表全体の総括になっております。 全部で5つのサービスで起きたトラブルを発表していただきました。 なかには「リリース日と震災が重なったことで出社できた社員が2名という状況下で発生したバグ対応」というものもあり、そういうこともあり得るのだと知りました。 トラブルを起こさないことが一番ではありますが、トラブルが起きてしまったときに如何に冷静かつ迅速に対応できるかが重要になると感じました。すぐには難しいですが、いずれは私もトラブルの対応ができる技術を身につけていきたいです。 これまで配属されてからほとんどのビアバッシュに参加してきましたが、いつものビアバッシュと比べて緊迫感があったような気がしました。 自由枠発表 テーマ枠のほかに自由枠発表もありました。 テーマ枠とは異なり、今自分が気になっていること、伝えたいことを題材に2名の発表者が登壇してくださいました。今回は2名とも新卒1年目の若手が発表していただき、最近つまったことや今年度を振り返った内容となっていました。 サービスの環境構築 チームに新しく参入するメンバーの環境構築や開発の準備を行った際に、苦戦した点を発表していただきました。 あと3か月ほどすれば新卒の後輩が私のチームにも配属されるため、私も他人事ではないなと考えながら聞いておりました。 手順書に記載されている通りに行うのではなく、なぜこの スクリプト を叩く必要があるのか、なぜこの作業が必要なのか、を考えながら作業をしていくべきだと感じました。 1年間で得た新たな CSS の知識 新卒1年目のメンバーが配属してからの期間で得た CSS の知識について発表していただきました。 この方は学生のときから CSS に興味があり使っていたそうなのですが、業務レベルにはまだ達していなかったことを痛感したそうです。 私も学生のときに得た知識だけでは足りないと思う節がこの一年間だけで多くありました。今の知識だけで十分だと慢心せずに積極的に技術を吸収することの重要さを再認識いたしました。 最後には彼の今後の成長意欲を感じました。 おわりに 普段はあまり聞くことができない各サービスのトラブルについて聞くことができました。直で聞くことにより、当時の緊迫感なども伝わり普段のビアバッシュとは一風変わったビアバッシュだったのではと感じました。 私自身はまだ大きなトラブルに見舞われたことはありませんが、発生時には慎重に対応していきます。 ラク スでは同じような問題を二度起こさないよう、開発全体で起きた問題やその対処法を共有しております。 過去の知見を活かし、障害を乗り越え、 ラク スのサービスは進化していきます。

はじめに はじめまして、新卒1年目のエンジニアのmrym_618です。 今回は、Schooで JavaScript について学習してみましたので、その感想を書いていきます。 目次 はじめに 目次 Schooとは 実際に学習してみた Schooとドットインストールの比較 まとめ Schooとは Schoo(スクー)とは、大人たちがずっと学び続ける生放送コミュニティであり、参加型の生放送授業と、4,600授業以上の動画教材で 「仕事に活きる」知識・スキル・考え方を学べるサービスです。 schoo.jp 特徴 プログラミングやWebデザインなどのIT分野以外にも英語やビジネススキル、企画・ マーケティング など幅広い分野の授業がある 生放送ならではの講師や生徒同士でのリアルタイムなコミュニケーションをとることができる PCだけでなく、 スマートフォン 、アプリからも利用することができる 実際に学習してみた 今回は、業務でも使うことが多い JavaScript について改めて学習したいと思い、 JavaScript 入門を受講してみました。 また、ドットインストールでも JavaScript についての学習を行い、Schooとの比較をしてみました。 schoo.jp Schooとドットインストールの比較 Schoo 講義ベースなので、基礎からわかりやすく学習できる 講師の方が実際のエンジニアの方なので、現場ではどのように使われるかを話してくれる ドットインストール 一つ一つの項目を短時間で学習することができる 知りたい項目をピンポイントに学習できる 新しいことなど基礎 からし っかり学習したい場合は、Schooで学習した方が分かりやすいと感じました。逆に、ある程度知識があり、短時間でピンポイントに学習したい場合は、ドットインストールで学習する方がいいと感じました。なので、どのように学習したいかによって使い分けることが大切だと思いました。 まとめ 今回は、Schooで JavaScript について学習しました。Schooは、新しいことを基礎 からし っかり学習するには分かりやすいと感じましたので、今後も様々な分野を学習するときに活用していきたいと思います。

はじめに こんにちは、新卒で入社して3年目のnorth_mkyです。 最近業務で SQL チューニングをする機会があったので、実行計画を読み解く記事を書こう！...と思いたったのですが、記事を書くにあたってサービスのデータベースを使うわけにはもちろんいかないので 適度なサンプルデータベースを作成し、 大量のデータを投入する という準備作業を行う必要がでてきました。 今まで大量のデータを入れるという作業はあまりしたことがなかったため、備忘も込めて当初予定していた記事を書く前に大量データの投入について述べたいと思います。 はじめに PostgreSQLに大量データを投入する方法は大きくは2つ generate_series()関数を使用する方法をおすすめする3つの理由 1. 大量データ投入処理までの準備はなし 2. 学習コストがほとんどない 3. 実行時間がCOPYコマンドと変わらない generate_series()関数を使用した大量データ投入方法とは 検証 : COPYコマンド VS generate_series()関数 環境 サンプルデータベース 結果 おわりに PostgreSQL に大量データを投入する方法は大きくは2つ 色々探していると、大きくは下記2つが投入方法として出てきました。 CSV ファイルをインポートする方法 generate_series()関数を使用する方法 1. は postgresql が用意しているCOPYコマンドを使用する方法です。公式のお墨付きです。 14.4. データベースへのデータ投入 データベースにデータを初期投入するために、大量のテーブル挿入操作を行う必要がままあります。 本節では、この作業を効率良く行うためのちょっとした提言を示します。 (中略) 単一コマンドですべての行をロードするために一連のINSERTコマンドではなく、COPYを使用してください。 COPYコマンドは行を大量にロードすることに最適化されています。 https://www.postgresql.jp/document/10/html/populate.html ですが、公式の言葉を押し切って今回私は 2. generate_series()関数を使用する方法 をおすすめします。 generate_series()関数を使用する方法をおすすめする3つの理由 1. 大量データ投入処理までの準備はなし 両者の作業手順は以下になります。 投入方法1では大量データを生成する→生成したデータをインポートする、というデータ投入前にデータを用意する準備作業が発生しますが、投入方法2では データ生成→データインポートの両方の処理をSQL1文で行ってくれる ため、投入するまでにかかる準備はありません。generate_series()関数は標準で入っているので拡張モジュールの読み込み等も不要です。 CSV ファイルをインポートする方法 CSV ファイルを生成する スクリプト を作る 作成した スクリプト を実行する COPYコマンドに適切な引数を与えて実行する generate_series()関数を使用する方法 大量データを生成する SQL を作る(generate_series()関数を使用) SQL を実行する 2. 学習コストがほとんどない 投入方法1の CSV ファイル生成 スクリプト は自分の好きなやり方で組めばいいのでそこまで時間はかかりませんが、鬼門はCOPYコマンドだと思います。COPYコマンドはおそらく大量データの投入か、既存テーブルの別テーブルへの複製に使うと思いますが、いざ使おうとすると色々お作法に馴染みがなく手間取ってしまいます。 COPY table_name [ ( column_name [, ...] ) ] FROM { 'filename' | PROGRAM 'command' | STDIN } [ [ WITH ] ( option [, ...] ) ] ここでoptionは以下のいずれかです。 FORMAT format_name OIDS [ boolean ] FREEZE [ boolean ] DELIMITER 'delimiter_character' NULL 'null_string' HEADER [ boolean ] QUOTE 'quote_character' ESCAPE 'escape_character' FORCE_QUOTE { ( column_name [, ...] ) | * } FORCE_NOT_NULL ( column_name [, ...] ) FORCE_NULL ( column_name [, ...] ) ENCODING 'encoding_name' https://www.postgresql.jp/document/10/html/sql-copy.html ファイルパスの指定1つにしても windows と linux で異なるのはもちろんのこと、投入するカラム値に空白が入っている場合の扱いを指定したりなど、馴染みのない人間にとっては トライアンドエラー で時間がかかります(私は5-10分かかりました)。 一方投入方法2はいつもどおり SQL を作成するだけなので学習コストは ほぼなし です。 3. 実行時間がCOPYコマンドと変わらない これは実測して驚いたのですが、両者とも 投入時間はほぼ変わらない という結果になりました。 公式のお墨付きのCOPYコマンドと同等の処理性能で、準備に時間がかからないというので私はこのgenerate_series()関数を使用する方法をおすすめします。 generate_series()関数を使用した大量データ投入方法とは 「顧客テーブルに1000万行のデータを入れる。名前は" ラク ス太郎n"にする(n=1...10,000,000)」 上記を満たす大量データ生成 SQL は以下になります。 1000万行が入った1GB超のファイルを用意する必要はありません。SQL1文で作成できます。 INSERT INTO customer (id,name) SELECT i, format('ラクス太郎%s', i) FROM generate_series(1,10000000) as i ; SELECT 部分だけを打つと下記が返ってきます。 ?column? | ?column? ----------------+------------------------ 1 | ラクス太郎1 2 | ラクス太郎2 ... 10000000 | ラクス太郎10000000 連番を生成し、集合として返すgenerate_series()関数を応用すると、このようにその場でテーブルを作るようなことができ、大量データを投入することができます。他にも上述のformat()関数のようにrandom()関数などと組み合わせるといい感じの大量データを手軽に作成することができます。 検証 : COPYコマンド VS generate_series()関数 あるテーブルに1000万行を投入する処理の経過時間を計測しました。 環境 Mac OS10.14, メモリ8GB postgresql 11 postgresql .conf shared_buffer=128MB wal_level = minimal # アーカイブ をoffにする サンプルデータベース PostgreSQLTutorial.com のサンプルデータベースを使用しました。 チューニングの記事を書く目的だったため、ある程度外部キー制約があったりカラム数があったりするデータベースはないかな、と探していたらすぐにこのデータベースが見つかりました。 http://www.postgresqltutorial.com/postgresql-sample-database/ 結果 両者ともほぼ同じ結果になりました。 COPYコマンド dvdrental=# COPY customer (store_id,first_name,last_name,email,address_id,activebool,create_date,last_update,active) FROM '/Users/north_mky/customer.csv' ( delimiter ',', format csv, header true ); COPY 10000000 Time: 556051.126 ms (09:16.051) generate_series()関数 dvdrental=# INSERT INTO customer (store_id,first_name,last_name,email,address_id,activebool,create_date,last_update,active) dvdrental-# SELECT dvdrental-# 2, dvdrental-# 'Austin', dvdrental-# format('Cintron%s', i), dvdrental-# format('austin.cintron%s@sakilacustomer.org', i), dvdrental-# 605, dvdrental-# 't', dvdrental-# '2006-02-14', dvdrental-# '2013-05-26 14:49:45.738', dvdrental-# 1 dvdrental-# FROM dvdrental-# generate_series(1,10000000) as i dvdrental-# ; INSERT 0 10000000 Time: 558479.994 ms (09:18.480) おわりに generate_series()関数は大量データの投入に対して、楽に導入できて楽に使える関数です。 テスト時に大量データが必要になった際の手助けになれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

RAKUS Meetup のロゴ @moomooya こと 勉強会最速オジサン を目指している鈴木です。 先日弊社にて RAKUS Meetup Tokyo #2 フロントエンドNight と称したイベントを開催しましたので、そちらのイベントレポートを投稿します。 いつもはイベント閉幕後3秒以内にレポートを公開しているのですが、今回は1,688,400秒ほど経過してしまいましたorz 当日の様子 発表の紹介 Vue.js の新規プロダクトで楽して UI を提供しようと思ったらそこまで楽じゃなかった話 話の経緯と発端 選択の成否 鈴木の感想 既存 Web アプリケーションへの React.js 適用 話の経緯と発端 React 導入にあたってやったこと 既存実装との共存と、その後の課題 鈴木の感想 Vue.js を初めてプロダクトに導入して直面した課題と得られた幸せ プロダクトに Vue.js を導入してぶつかった課題 Vue.js を採用して幸せだったこと 懇親会 次回開催について 当日の様子 RAKUS Meetup Tokyo #2 会場の様子 今回は30人の募集枠を予定していたのですが、予想外の好評につき会場をグループ企業である ラクスパートナーズ のオフィスに変更しての開催となりました。 当日は雨も降る 悪天候 の中ご参加いただきありがとうございました。 発表の紹介 Vue.js の新規プロダクトで楽して UI を提供しようと思ったらそこまで楽じゃなかった話 好きな言葉は YAGNI と "Done is better than perfect." *1 という弊社デザイナー竹川の発表です。 新規サービスで利用する UI フレームワーク を選定した時の話です。 話の経緯と発端 新規サービス開発プロジェクトに スクラム 開発のプロダクトオーナーとして参画。プロジェクトの方針が 「提供してから考えよう」 というものだったため、UIについてはどんどん変わるものとして自前での作り込みを避ける方向に意思決定したとのこと。 選択肢として Bootstrap か Material Design か検討したところ、仕様として技術レイヤから独立している Material Design を採用することに。 さらに主だった3種類の UI フレームワーク のなかから Vuetify を採用。 Material Design な UI フレームワーク の特徴比較 選択の成否 ただし、現状ではどの選択肢も完璧ではない様子。一時は選定をミスしたと思い再度検証したものの、 Material Design の仕様に対する充足度はどれも一長一短である ことがわかった。採用した Vuetify の作者は Twitter 上でこのように発言している。 One thing I've learned over the years working with @materialdesign is that there are so many inconsistencies between the spec and their web components. It's frustrating, but in the end works out for the user because we are going to make sure both are supported. — John Leider (@zeroskillz) 2019年1月6日 「仕様と公式実装の差異も多いが、 UI フレームワーク 側で吸収していくしかなさそう」（意訳） 鈴木の感想 「Bootstrap は Twitter Geek 向け」 というなかなかパンクな発言が面白かったです。 既存 Web アプリケーションへの React.js 適用 dev ドメイン 購入予定の ポケモンGO オジサンで、弊社楽楽明細リードエンジニアの三田の発表です。 2017年後半に 楽楽明細 の新機能を開発する際に React.js を導入した話です。 話の経緯と発端 既存のフロントエンドの実装は jQuery を用いたものだったが、このとき開発する機能はフロントエンドの要件が複雑なものだった。 DOM を基軸に操作を行う jQuery では状態の管理が難しく 、フロントエンド フレームワーク の導入を検討。 選定当時は特に日本国内で React.js が突出して流行っていた。JSX の見た目の インパク トとは裏腹に覚えることが少なく、 マークアップ をシンプルに保てそうだったことが魅力に感じた。加えて、流行っていたため情報量が多いこともプラス評価になった。 React 導入にあたってやったこと 導入にあたってはチーム内で小さなツールを開発してみた。実際に開発してみると state と props の管理が大変だったため、最初から Redux を採用することに。 小さく試してみることは大事 だった。 さらに ES2015 勉強会をチーム内で開催。資料として WEB+DB vol.87 は神号 なのでオススメ。 既存実装との共存と、その後の課題 jQuery との共存はできていて、適材適所に使い分けている。本番移行後に React に起因したバグはまだ起きていない 。 当時まだ v15 系だったので現在 v16 系への以降を頑張っているが、破壊的な変更もあり少しつらい。 他画面への適用は簡単な画面でも適用するべきかどうかなど悩んでいるが、古いシステムを少しずつ React に置き換えていくことは可能そう。 鈴木の感想 「人類にDOMを扱うのは難しすぎる」 という発言がすごくわかりみが深かったです。DOM ベースで複雑な状態管理はすごく難しいです。 ちなみにスライド5枚目の 出番のないSさん は私のことです（当時楽楽明細開発チームにいました）。 余談ですが、 楽楽明細もついに CM を作ってもらえました 。 Vue.js を初めてプロダクトに導入して直面した課題と得られた幸せ Qiitaで勉強会最速オジサンを目指している 弊社エンジニア鈴木（私のことです）の発表です。 竹川の発表にも出てくる 新規サービス の開発に Vue.js を導入した話です。 弊社のサービスでは一部 Vue.js を採用しているサービスはあるものの、プロダクションレベルで全面的にフロントエンド フレームワーク として Vue.js を導入したのは今回のプロジェクトが初でした。 ちょうど私がこのプロジェクトに参画する際に Vue 熱が高まっていたこともあり、 半ばゴリ押しで 採用にこぎつけました。 とはいえ本格的に利用するにあたって以下のような課題にぶつかりました。 プロダクトに Vue.js を導入してぶつかった課題 アロー 演算子 使えない 初期化時に存在しないプロパティをオブジェクトに追加するときは注意が必要 ライブラリ間で要素名が衝突してしまうと動作しなくなる セオリーがわからない けどスタイルガイドが充実しているので熟読すると答えが書いてあることが多い Vue.js スタイルガイド Vue.js コンポーネントスタイルガイド Vuex使いすぎ？問題 コンポーネント に閉じるような非同期なデータ取得処理 *2 も Vuex に実装していた React （というか Redux ）だとそれが正解らしい *3 ですが、Vue だと コンポーネント に実装したほうが扱いやすかった mixins 使いすぎた props やローカルステートを mixins で定義してしまい、 mixins が解決されるまでの一瞬の間 undefined になって困った Vue.js を採用して幸せだったこと 単一ファイル コンポーネント は本当に幸せ ドキュメントが充実しているのも本当に幸せ 最近、 弊社の大平 も ローカライズのコントリビューターになっています React + Redux やってた人なら考え方が近いので Vue + Vuex もスムーズに入れて助かった 懇親会 お約束の Sushi と Pizza と Beer を用意しました 次回開催について 次回の東京での開催は5月に 「BtoBサービスが自社DCに Amazon S3 互換ストレージを導入したときの苦悩」 をテーマに開催予定です。 今月3月の後半には募集を開始できると思います。 Connpassのグループ に入っていただけると通知が飛びますのでそちらもよろしくおねがいします。 *1 : Facebook 本社の壁に貼られているという標語。日本では「完璧を目指すよりまず終わらせろ」と訳されている。 *2 : API 叩いてデータ取得するような処理 *3 : 懇親会で教えていただきました

はじめに こんにちは。エンジニア1年目のy_kwmtです。先日、業務でpuppeteerを用いてE2Eテストのテストコードを実装しました。E2Eテストとは、End to Endテストの略で、開始から終了までアプリが期待通り動くか確認するテストです。今回はpuppeteerの学習をするためにpuppeteerを用いて自動で ラク スのエンジニアブログサイトにアクセスしたことについて書きたいと思います。 目次 はじめに 目次 puppeteerとは 導入方法 コーディング、実行 最後に puppeteerとは puppeteerは、Node.jsでHeadless Chrome を自動で操作できるようにするライブラリです。puppeteerを用いることでクリック、テキスト入力、画面遷移などが自動で行えます。 公式サイトはこちらです。 github.com 導入方法 今回はこちらの記事を参考にインストールを行いました。 tech-blog.rakus.co.jp まずはNode.jsとnpmをインストールしてください。 Node.jsは こちら からダウンロードを行い、 インストーラ を実行し、画面の指示に従ってインストールしてください。npmのインストールは以下を実行してください。puppeteer は操作結果を Promise で返すので、async/await が使えるv7.6.0 以降のバージョンを用意したほうがよいです。 npm init Node.jsとnpmのインストールが完了したら、puppeteerのインストールを実行します。 npm i puppeteer コーディング、実行 puppeteerのインストールが完了したら、コードを書いていきます。コードはこちらのページを参考にさせていただきました。 webbibouroku.com 以下のファイルを実行して ラク スのエンジニアブログにアクセスします。今回は実行できているか確認するためにブラウザを表示するだけでなく、 スクリーンショット も撮影しました。そのコードがこちらです。 ファイル名：sample.js const puppeteer = require( 'puppeteer' ); (async () => { //ブラウザを定義(headless:false ブラウザを表示する, true 表示しない) const browser = await puppeteer.launch( { headless: false } ); //タブを定義 const page = await browser.newPage(); //ブラウザのサイズを定義 await page.setViewport( { width: 1240, height:1080 } ); //待機 async function sleep(delay) { return new Promise(resolve => setTimeout(resolve, delay)); } // Googleにアクセス await page. goto ( 'https://www.google.co.jp/' ); // 検索窓に「ラクス　エンジニアブログ」と入力 await page.type( '.gLFyf' , 'ラクス　エンジニアブログ' ); //スクリーンショット撮影 await page.screenshot( { path: 'google.png' } ); // 検索ボタンクリック //待機時間を設けないと止まってしまうことがあるので記述 await sleep(5000); await page.focus( 'input[name="btnK"]' ); await page.click( 'input[name="btnK"]' ); //待機時間を設けないと止まってしまうことがあるので記述 await sleep(5000); //スクリーンショット撮影 await page.screenshot( { path: 'search_result.png' } ); // 検索結果の先頭リンクをクリック await page.click( '.rc > .r > a' ); //スクリーンショット撮影 await page.screenshot( { path: 'blog.png' } ); //ブラウザを閉じる await browser.close(); } )(); コードを書いたら、コマンドでファイルを実行します。 node sample.js 実行中に撮影した スクリーンショット がこちらです。 google . png search_result. png blog. png 最後に 今回はサイトにアクセスするという簡単な動作でしたが、puppeteerを0から始めてファイルを実行することができました。今後、また業務でpuppeteerを使うとなった時のために、これからも勉強を続けて複雑な動作を自動化できるよう頑張ります。

id:radiocat です。2/26に大阪オフィスで実施したMeetupでは楽楽精算開発2課のメンバー全員で半年かけて準備をして発表しました。今回はMeetupの内容と合わせて、全員で役割を持って取り組んだ勉強会発表プロジェクトの内容をご紹介します。 rakus.connpass.com プロジェクトの経緯 私たち楽楽精算開発2課は成長サービスを支える開発組織として、常に新しい領域の開発に取り組んできました。一方で、開発部門としてMeetupというイベントを継続的に開催していくことになり、私たちのチームがどう関わっていくべきかを考えた時に、チームでイベントのコンテンツを作り上げるという新しいチャレンジを行ってその知見を残すことが私たちのチームらしい取り組みではないかと考えました。そして2月のMeetup発表者としてチームで名乗りを上げてプロジェクトをスタートさせました。 2018年10月にプロジェクトスタート 前回のMeetup の開催翌月にキックオフを行いました。 まず、どういうイベントにしたいかを全員で話し合って、発表テーマの候補を出しました。その中からいくつかのテーマに絞り込んでそれぞれのメンバーがいったん持ち帰り、次回までに発表テーマを検討することにしました。 11月 前月にそれぞれが持ち帰って検討した発表テーマと発表のイメージを共有して、イベントの全体像をすり合わせしました。 この時にそれぞれのメンバーが担当する発表内容の大枠が決定しました。若手メンバーは3人1組で発表資料を作って代表者が発表することになりました。 12月 前月に決まった発表テーマと内容の大枠をスライドに落とし込んでアウトラインレベルで中間発表を実施しました。そしてお互いの発表を聞いてフィードバックし合いました。このとき、主力エンジニア、中途社員エンジニア、若手エンジニア、 スクラム マスターというそれぞれの視点で発表するという流れがだいたい確定しました。 1月 ドラフト版レベルのスライドで発表練習して、全員でレビューしました。ここまでは スクラム マスターが最初に発表する流れにしていましたが、「いきなり スクラム マスターが場を引っ張って発表するのはなんか違うよね」となって、 スクラム マスターは最後に発表する流れに変更しました。 2月 本番さながらの練習会を実施し、資料と発表内容の精度を上げていきました。チームで整合性を合わせる部分があるため前日までスライドのチェックや修正を行って当日を迎えました。 発表したスライド 当日のスライドと合わせて発表に関わったメンバーのコメントをご紹介します。 大阪開発チームが取り組んだ スクラム 1年目の開発現場 まずはチームを取り巻く状況と、 スクラム に取り組んできた経緯を簡単にご紹介しました。 1. 開発チームク エス ト 楽楽精算開発チームの岡本です。 Meetupでは「開発チームク エス ト」というタイトルで、開発チームが歩んだ１年間の振り返りを発表しました。 タイトルは直訳すると「開発する仲間たちで探求する」になります。 探求とは「さぐり求めること。さがし回ること。※1」らしいですが、この1年はまさに仲間たちで課題の解決方法を探し回った1年でした。 中でも一番深刻だった課題がチームの分断問題です。若手とベテラン、新規メンバーと既存メンバーで知識量に差があり、フォローによる稼働圧迫が慢性的に発生していました。我々のチームでは、モブプロ／モブワークの手法を採用して、この課題を克服しようとしました。 当初は知識のあるメンバーがモブを主導することが多かったのですが、回数を重ねるうちにチームの平均知識が上がっていき、今は知識のあるメンバーが一方的に発言するというシーンは少なくなっています。また、モブで開発を進めた結果、必然的にメンバー個々へのフォローも少なくなりました。 ところで、モブプロとは全員でひとつの課題に取り組む開発手法ですが、これを言い換えると「開発する仲間たちで(ひとつの課題を)探求する」と言えるんじゃないかと思います。つまり、色々書いていましたが、今回の発表の結論としては「モブプロやってみると意外と良かった」に尽きると思います。 ※1 出典:精選版 日本国語大辞典 2. 中途社員がチームに参加しました 中途入社の福岡です。昨年5月に入社してからの1年間について発表しました。 当初は、入社してからの苦労話を発表しようとしたのですが、全く思い出せず、最初は何を話せるだろう、どういった価値を参加者へ提供できるだろうと悩みました。そこで発想を変え、どうして苦労話がでてこないのか？から、 スクラム チームが実施しているイベントを振り返り、これがなかったら苦労しただろうなという事例をピックアップしました。 またイベントだけでなく、HRTという考えから得るもの、これまでの自分を反省することが多々ありました。このブログを見た方は「HRT」についてだけでも、 Google先生 に聞いてみてください(笑) 今後チームに新たにメンバーを迎えられる方、またチームへ参加される方に何か響くものがあればと思います。 3. 学習 スクラム をやってみた件 入社3年目の中野です。私は「若手エンジニア」パートの発表を担当させていただきました。 チームの教育課題に スクラム を適用するという内容で登壇させていただきましたが、今回のMeetupに参加された方の多くは、プロダクトの開発に スクラム を適用することはあっても、新人の教育課題にまで スクラム を適用した例はあまり無いのではないかと思います。 実際、弊社のチームでも教育課題に スクラム を適用したのは今回が初めてでした。「教える側」は スクラム の経験が約1年と浅く、「学ぶ側」は スクラム の経験が皆無という状況で、お互い様々な苦労がありました。登壇の際にも触れましたが、最初の頃はタスクの残量がバーンダウンせず、どうすれば計画通りタスクを消化できるかを考える日々が続きました。スプリント内で確実にタスクを完了させるために1つのタスクの粒度を小さくしてみたり、前提知識を補うための事前学習的なタスクを作ってみたり、試行錯誤を繰り返しました。思い返せば スクラム において最初の難関はこの「バーンダウンしない問題」なのかもしれません。 今回は上記のような問題が発生するたびに「教える側」と「学ぶ側」が一緒になって解決策を考えたので、お互いにとって学びや成長があったと思っています。まだまだ スクラム 初学者の私が言うのも恐縮ではありますが、もし貴社で新人教育に スクラム を取り入れようと考えておられるならば、今回の発表が少しでも参考になれば幸いです。 入社二年目の桑原です。 私は学習 スクラム に教える側として参加し、Meetupでは資料作成に協力しました。ここでは発表であまり触れることのできなかった、学習 スクラム の中で、教える側がプロダクトオーナー(以後PO)や スクラム マスター(以後SM)のロールを体験して感じたことについて記載したいと思います。 私は1年ほど スクラム の開発に参加してきました。もちろん、POやSMの立場の人とも関わることがありました。そのため、学習 スクラム 実施前は、それなりにロールを担うことができるだろうと考えていました。しかし、実際に学習 スクラム が始まると全然ダメでした。例えばPOを担当した際のプロダクト バックログ 1つに着目しても、 バックログ の順番やどこまで作りこむか、エラー時の動作等、考慮が足りないことは多くありました。結果、最初のスプリントは計画段階で躓き、開発時間を圧迫、進捗も悪くなり、次のスプリントの準備も不十分になるという悪循環に陥っていました。最終的に、イベントの実施日は決めたものの、そのイベントのゴールは何か、そのゴールのために誰が何をどこまで準備するのかを整理できていなかったことに気づき、各イベントで最低限やることをリスト化、イベントまでに誰が何をするのか整理することで改善しました。 今思い返してみると、POやSMの役割、チームが動きやすいように舵をとることに関して、表面上は知っていた（見ていた）ものの、その役割を果たすためにどのような準備をしているのかが分かっていなかったのだと思います。１年間 スクラム に触れ、少しは分かったつもりになっていましたが、まだまだ学ぶべきことは多いのだと感じさせられました。学習 スクラム という取り組みは、新規メンバーが スクラム に慣れていくという面だけでなく、教える側の若手にとっても、チームがよりよく動くために自分達が何をすべきかを改めて考えさせられる良い取り組みであったと思います。 入社一年目の庄禮です。 「学習 スクラム をやってみた件」で実際に教えていただく立場にあり、中野（登壇者）の資料作成に協力しました。 学習課題を スクラム で回すという初めての取り組みで、「こんなの上手くいくわけがない！」と始める前や始めた当初は思っていました、しかし、 スクラム を回していく中で徐々に改善していき、イベントの役割などを身をもって体感することができたので、結果的に取り組んでよかったと思っています。 この度Meetupの題材にあがって資料作成をおこなうまで教育者側の苦労などは意識できていなかったのですが、資料づくりの中で今後のチームや教育の改善の観点から学習 スクラム を見ることができたので、今回のMeetupでアウトプットすることができて良かったと思っています。 来年、チームに入ってくる新人がいれば私も教育に関わることになるので、今回の反省点や課題点も踏まえて取り組んでいきます。もし機会がありましたら、学習 スクラム の取り組みの進捗・変化をみなさんにお伝えしたいと思います。 4. アジャイル であり続けるためのチームリーディング スクラム マスター担当の大塚です。 9月末に大阪オフィスで1回目のMeetupを開催した時に、次回は私たちのチーム全員で取り組んでみたら面白いのではないかと考え、チームに提案してみたのがきっかけで準備がスタートしました。半年もあれば準備万端で当日を迎えられるかというと、実際はそんなに単純ではありませんでした。業務の合間を縫って少しずつ準備を進める必要がありました。また、半年前から内容が決まっていたわけではなく全員が「これからやること」をイメージして2月に「こういう発表ができそう」というテーマを決めて、仕事でそのイメージに向かって進んでいくことで発表内容も同時に組み立てられていきました。つまり、Meetupに向けて発表の準備をすること自体が、ひとりひとりがチームの未来をイメージしてそれに向かって進んでいく作業にもなっていました。 主力メンバーが別のチームに移った時、今こそチームで アジャイル になるべきだと私は考えました。「誰か」ではなく「私が」でもなく「チームで」が大事な理由は同じことを繰り返さないためです。誰かがチームを引っ張るのではなく、チームで未来をイメージしてみんなで取り組んで作り上げる過程こそ アジャイル ではないでしょうか。そうやってMeetupに向けて進みながら少しずつイメージを具体化していく過程を スクラム マスターとして支援してきました。 「やってみたら面白そう」と思えるようなア イデア を見つける それを実践するきっかけを作る 実現イメージの具体化をファシリテートする 実行するうえでの課題や懸念の解消を手伝う このようなちょっとした支援で少しずつチームが前進していくのを手助けすることこそが サーバントリーダー の醍醐味だと思います。 ふりかえり アジャイル Night らしく、ふりかえりは 「Fun Done Learn」をやりました。 Fun Done Learnって何？というかたはこちらをご確認ください。 qiita.com Fun Done Learnをやってチームで議論した内容を以下にまとめます。 良かったこと・学び スクラム の取り組みについて参加者との交流や外部のエンジニアとの情報交換ができた 自分たちがやってきた事へのフィードバックが得られて今後のモチベーションに繋げられた 自社開催でチームでの取り組みなのでアウトプットへのハードルが低く、 心理的 障壁が少ない中で前向きに取り組めた 半年間の活動でしっかり時間を確保して学んだことや取り組みの総括ができた 改善点や今後に向けたTry 資料作りが基本であり一番大事、これを極めればもっと良い内容にできそう スケジュールを立ててチェックポイントを設けて計画的に取り組むことが大事 当日の発表を想定した練習が大事（もっとやっておくべきだった） ふりかえった内容は社内で共有して、他のチームの新たなチャレンジに役立ててもらいたいと思っています。また、社内だけでなくこの記事を読んで頂いた皆さんの何かの取り組みに役立てば幸いです。 おわりに 次回のMeetupは6月を予定しています。内容は決まり次第、connpassで告知します。 rakus.connpass.com また、大阪オフィスでは毎月1回エンジニアもくもく勉強会を開催しています。今回の発表内容に関しても興味を持たれましたら情報交換できればと思っていますので、是非ご参加ください。 rakus.connpass.com

楽楽精算開発２課 岡本です。 今年から月１回のペースで開催している「もくもく勉強会」ですが、３月もまた実施しますので、告知も兼ねて２月実施回の模様をお伝えしようと思います。 ちなみに、１月の模様はこちらの記事で紹介されています。 tech-blog.rakus.co.jp ２月実施の模様 前回(１月実施回)の振り返りで主に以下のような意見が出たので、２月はこれらの改善を実施しました。 参加者同士が離れて座りがち 食べ物があったほうがいい BGMの音が大きい ■参加者同士が離れて座りがち 前回は、机を離して設置していたため、それぞれの机に別れて参加者が座ってしまい、もくもく中にコミュニケーションが取りづらい状況でした。 前回の様子。空席が多くてどことなく寂しい感じ そこで、今回は参加者同士が近くに座れるように、机の配置を見直しました。 今回の様子。写真の時点では全員揃っていないので空席ありますが、最終的には各机に一人づつで全ての席が埋まりました。 ■食べ物があったほうがいい 食べ物があったほうがコミュニケーションを取りやすいのではという意見が出たので、今回はお菓子を用意してみました。 ちょうど実施日が２月１４日だったのでチョコレートをメインに用意。 ただ、あまり消費量は芳しくなかったようです。 まだまだ残っています。 次回以降も、お菓子は用意しようと思うので、お越しの際はガンガン消費していってください。 ■BGMの音が大きい もくもく勉強会の会場では普段からRaspberryPiからラジオが流されるようになっています。 こんな感じ、ちなみにこのRaspberryPiでエントランスのディスプレイに流れている映像も制御しています。 前回はここから流れてくる音が大きすぎるという意見が出ていたので、今回は予め音を絞ってBGMを流していました。 ただ、RaspberryPiの処理の関係で時々BGMが途切れ途切れになってしまっていたようなので、次回は別の方法でBGMを流そうと検討中です。 次回告知 次回は３月１４日に開催予定です。既にconnpassに公開中ですので。興味を持たれた方は是非お越しください。 rakus.connpass.com

はじめに こんにちは、 id:FM_Harmony です。 今回は先週開催された東京オフィスのビアバッシュに関する紹介記事を書きました。なお、東京オフィスでのビアバッシュについては、下記の記事にて詳しく紹介されています。 tech-blog.rakus.co.jp はじめに 発表内容 デブサミ2019で印象に残ったセッション デブサミ2019で興味があったもの PostgreSQL11のパーティショニングを試してみる おわりに 発表内容 前回 同様、東京のビアバッシュでは自由なテーマでの発表のみ行われました。 デブサミ 2019で印象に残ったセッション LTのタイトル① 前回に続き、今回も私が発表する場をいただけました。 2/14(木)、2/15(金)に開催された Developers Summit 2019（以下 デブサミ 2019）について参加しましたので、今年のテーマである「SHARE YOUR FUN！」にちなんだ以下のセッションの内容、感想を発表させていただきました。 event.shoeisha.jp event.shoeisha.jp セッションの感想ですが、楽しんで仕事をすることで利用者が幸せになるようなものを作りたいと思いました。また、東京のビアバッシュでも何度か話題になった技術書典についても、「面白い」と感じるポイントがあったので、次回開催分にはぜひ参加しようと思いました。 デブサミ 2019で興味があったもの LTのタイトル② 同じく デブサミ 2019に関する発表でした。興味がわいたセッションとして、下記のセッションについて発表されていました。 event.shoeisha.jp Node-REDを用いたコードレスなアプリケーション開発に興味がわいたとのことです。 PostgreSQL11のパーティショニングを試してみる 以前、 ラク スAdvent Calendar 2018に記事を投稿された方が、記事の内容について発表されていました。 qiita.com PostgreSQL 10から追加された宣言的パーティショニングについて、下記の二点が追加された PostgreSQL 11からは実用可能なレベルになったのでは？ということでした。 親テーブルにプライマリキーが設定できるようになった ただし、プライマリキーにはパーティショニングキー（分割の際に参照する項目）を含める必要がある パーティショニングキーを更新した場合、自動であるべきテーブルにデータが移動されるようになった 発表の最後には参加された方の間で、パーティショニング機能の商材利用についてディスカッションのように質疑応答が繰り広げられていました。 おわりに 東京オフィスの2月ビアバッシュについてお送りしましたが、いかがでしたでしょうか。 3月は拡大版ビアバッシュともいえる全社MeetUpの開催が予定されていますので、そちらで発表された内容もお伝えできればと思います。

はじめに こんにちは。若手エンジニアのchoreiiです。 最近、業務でswiftに触れる機会がありました。 Xcode での アプリ開発 が楽しく、swift勉強したい欲が高まり勉強会にも参加しています。初心者ながら、ある程度アプリの作り方も理解してきたので一度アウトプットをしようと思います。 swift勉強中の方の刺激・参考となれば幸いです。 目次 はじめに 目次 題材 完成形 地図の埋め込み 検索とピン配置 最後に 題材 取り上げるのは、 MapKit になります。 簡単に言うと、アプリの画面に地図を埋め込んだりできる フレームワーク です。 今回はMapKitを使って、近場の駅を表示するアプリを作ってみました。 完成形 最初に完成形をお見せします。 起動後 ラク スの会社住所で検索 駅にピンがたつ（検索地が ラク スです） ゴールイメージが掴めたところで実際の手順を説明します。 地図の埋め込み xibまたはstoryboardで MKMapView を貼り付けるだけです。 xcode で部品をペタペタ貼り付けるのは直感的にできるのですごく楽しいです。（しっかりとしたレイアウトを考えだすと面倒ですが） MKMapViewの配置 今回はテキストボックスに住所を入力して検索するので textField も貼り付けています。 検索とピン配置 検索はMKLocalSearchを使用しています。精度はあまりよくないようですが、ローカルで API のように簡単に検索機能が使えるので使用しています。 検索用の関数を作成している先人の方がいらっしゃったので、検索自体は そちら をお借りしています。 Map.search(query : "駅" , region : region ) { (result) in switch result { case .success( let mapItems ) : for map in mapItems { let annotation = MKPointAnnotation() annotation.coordinate = map.placemark.coordinate annotation.title = map.name ?? "名前がありません" mapView?.addAnnotation(annotation) } case .failure( let error ) : print ( "error \( error.localizedDescription ) " ) } } query: 検索したい建物　region: 検索範囲のイメージです。 帰ってきた検索結果それぞれに MKPointAnnotation() を addAnnotation することでピンを立てています。今回は駅固定にしていますが、ここも入力フォームやユーザデフォルトに保存しておいた値などを使うと、いろんな建物が検索できて使い勝手はよくなると思います。 最後に xibファイル上でのオブジェクトの配置と、コード上でのオブジェクトの操作の両方を体験できるので、 iPhoneアプリ の開発練習にはぴったりだと思います。私自身イベントの制御などまだまだ把握できていないところばかりなのでこれからも勉強は続けていきます。今回のアプリのソースは GitHub に置いておきます。練習用のコードで汚く読みづらいコードとなっていますが、基本的な操作は一通り試しているのでご自由にお使いください。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめまして、新卒のtaku_76です。 qiita.com 上記URLからチャット bot を作成したいと思ったのですが、これにNode.jsの知識が必要だと書いてあったので学習してみました。 その結果 フレームワーク であるExpressを使用すると簡単に Webサーバーが構築できることが分かったので試しに使ってみました。 Node.jsとは Node.jsのインストール Expressで新規プロジェクトを作成 おわりに 参考 Node.jsについての記事 Node.jsとは JavaScript を使ってサーバーサイドのコードを書くことが出来るプラットフォームです。 特徴 V8エンジン GoogleChrome で使われている JavaScript エンジンでブラウザとほぼ同じ JavaScript が書くことができます。 JavaScript を即座にコンピュータが理解できる 機械語 に変換して処理を行うため非常に高速です。 ノン ブロッキング I/Oモデル I/Oが終わったか何度もチェックし、終わっていなければ次の処理に進んで、次の処理が終わったらまたチェックする、この動作を繰り返します。 シングルスレッドの大量のアクセス制御が難しいというデメリットを回避します。 Node.jsのインストール https://github.com/nullivex/nodist/releases こちらのURLからnodistをインストールします。 nodistとは Windows 環境で動作する Node.js のバージョン管理ツールです。これを使うことで、複数の Node.js のバージョンを切り替えて使い分けることができるようになります。また、同時にnpmもインストールされます。 npmとは Node.jsのパッケージを管理するツールです。Node.jsのパッケージとは、予め用意された便利な機能をまとめたものです。 Expressで新規プロジェクトを作成 Expressとは Node.jsで利用できるWebアプリケーション フレームワーク です。 イベントループで非同期のため同時リク エス トに強く、多くのユーザーの同時アクセス・大量リク エス トを捌くことができます。 テンプレートエンジン(サーバーサイドで動的にオブジェクトを渡して、それをHTMLとして返す)を選べます。 今回はhtmlに近い形でかけるテンプレートエンジンのejsを使います。 Expressのインストール 以下のコマンドでインストールを行うことが出来ます。 C:\Users\takumi\Desktop\test\Nodist>npm install -g express-generator 公開までの手順 C:\Users\takumi\Desktop\test\Nodist>express -e newproject オプション-e でejsが設定された状態でプロジェクトが作成されます。 C:\Users\takumi\Desktop\test\Nodist>cd newproject && npm install 作成されたnewprojectのnode_module ディレクト リの中に必要なモジュールがインストールされます。 packege. json に何をインストールするのか設定してあり、これを参照してインストールを行います。 C:\Users\takumi\Desktop\test\Nodist\newproject>npm start サーバーを起動し、ローカルにWebページを公開します。 http://localhost:3000 と入力するとexpressにデフォルトで入っているhtmlが以下のように表示されます。 express おわりに 今回は、Node.jsのExpressを使ってローカルにWebサーバーの構築をしてみました。 次は、自分でWebアプリを開発してherokuを用いて公開するところまでやってみたいと思います。 参考 https://www.sejuku.net/blog/45745 https://techacademy.jp/magazine/16105 https://techacademy.jp/magazine/16119 Node.jsについての記事 こちらにも詳しい記事があります。 Node.jsの勉強会でお手軽にWebアプリを作った話

id:radiocat です。2/22〜23に開催されたScrum Fest Osaka 2019 へ私たちのチームから3人が参加してきましたのでレポートします。 Scrum Fest Osaka 2019とは？ www.scrumosaka.org 公式サイトには以下のように書かれています。 Scrum Fest Osakaは スクラム の初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。 アジャイル 開発のプロセスのひとつである スクラム のイベントで、関西では初の大型イベントです。約200人が集まって2日間開催されました。 ちなみに、弊社も大阪に拠点があり スクラム に取り組むIT企業のひとつとしてスポンサーをさせて頂きました。 なお、会場となった「 関西大学 梅田キャンパスKANDAI Me RISE」は大阪オフィスの隣のビルでした。その点でも何か不思議なご縁を感じて参加してきました。 登壇レポート 今回は登壇の機会も頂くことができました。せっかく頂いた機会ですので、私たちのチームが取り組んできた スクラム についてたくさん詰め込んで紹介しました。 スクラム はシンプルなルールの 開発プロセス ですが、その実践にはチームに応じた様々な工夫が必要です。私たちのチームもこれまでたくさんの試行錯誤を繰り返してきました。その中で支えとなったのは、既に スクラム に取り組んでいる先人やコーチなどの 有識者 の方々の取り組み事例でした。これまでも同様のイベントが開催されたり、同じ課題を持つ人が集まるコミュニティなどからたくさんの事例が世の中に発信されており、それらの情報を参考にして自分たちのチームに取り入れて スクラム を続けてきました。つまり、私たちの スクラム はこれまで取り組んできた人たちの試行錯誤に支えられているのです。 ですので、今度は私たちの取り組みを、同様に試行錯誤している人やこれから スクラム に取り組む人たちの支えにして頂けるように、たくさん詰め込んでお伝えしたつもりです。幸いなことに発表後の懇親会などで、たくさんの方々から共感のコメントや自分たちも同じ課題を持っていて勇気が湧いたという温かいお言葉を頂き、私たち自身もまたこれから スクラム を続けていくモチベーションを得ることができました。 参加レポート 一緒に参加したメンバーが印象に残ったセッションをまとめてくれているのでご紹介します。 楽楽精算開発チームの岡本です。印象に残ったセッションをまとめました。 プ ラク ティス厨から始める アジャイル 開発 クラスメソッドの 藤村さんのセッションです。 スライドは、こちらで公開されています。 プラクティス厨から始めるアジャイル開発 from Arata Fujimura www.slideshare.net スクラム の本に書いているようなプ ラク ティスについて、まずは、そのまま実行してみて、形骸化してきたと感じたら立ち止まり、 スクラム ガイド等の原典と現状の差分を確認してみればいい、といった内容のセッションでした。 スライド中には「プ ラク ティス厨が許されるのは、形骸化するまで」という言葉が出てきていましたが、うちのチームにも形骸化していそうなプ ラク ティスがちらほら出てきているので、原典との差分の確認時期なのかもしれないです。 スクラム フレームワーク を使用する具体的な方法。僕の場合。 楽天 の 椎葉さんのセッションです。 スライドは公開されていませんが、ブログで内容が公開されています bufferings.hatenablog.com 楽天 の大阪開発チームで実践している スクラム の方法についてのセッションでした。 色々と参考になるセッションで、特に、仕様の決め方や開発の進め方については、うちのチームでも取り入れてみたいと思いました。 仕様の決め方 何を作るのか？だけではなく、なぜ作るのか？をより重視して書く それによって、開発チームはより目的に沿った形で実装することができる。 開発の進め方 実装／テストで役割を分けて、それぞれ並行して進める 実装／テストそれぞれの観点で開発を進めるので見落としやバグを防ぎやすい。 オーディエンスとして参加して来ました、庄禮です。 私自身、現在の スクラム チームに参加してまだ半年ほどで、こういった スクラム のイベントにも参加したことはありませんでしたが、運良く参加枠をいただくことができましたので参加してきました。 以下、拝聴したセッションの中から一部ご紹介します。 お堅い企業で スクラム チームを一から作った話 3年前からチームに スクラム を導入した 三菱電機 株式会社さんのお話。 アナログなカンバンの導入に始まり、少しづつ自分たちの課題点を解消していく軌跡をお話しされていて、チーム体制の変更したり、デジタルなツールを導入して効率化をはかるなど、工夫しながら自分たちの スクラム を形作っており感銘を受けました。 ピンポンゲームで スクラム 体験ワークショップ 「Ball Point Game」というワークショップをおこないました。ワークの詳細は軽く調べるとでてきますので、気になる方は調べてみてください。 限られた時間、初対面の人と協力して目標にむかって行動するのはやりごたえがありました。やってみてダメな点は全員で振り返って、次にプランニングに活かす、といった スクラム の基本を体験学習できる良いワークでした。（ワークということもあり、実際の現場ではおこなわないようなチャレンジも行いました） 所感 交流会やコーヒーブレイクの時間に様々な スクラム 関係者と交流できたことも、参加してよかったと感じているポイントです。まだまだ自分自身の知識も浅く、お話を聞いて参考にさせていただく機会ばかりですが、いつか自分の経験をみなさんにアウトプットできるように精進していきます。 まとめ 2日間 スクラム のテーマにどっぷりと浸かり、参加者それぞれが交流と学びを深めて持ち帰ることができる場所でした。Scrum Festは、その名前のとおりカンファレンスや勉強会とは違った独特のフェス感のある素晴らしいイベントです。次回もぜひ参加したいと思います。 今回のイベントにも関連しますが、関西の アジャイル コミュニティの関係者の皆様には普段から大変お世話になってきました。今後もイベントへの参加だけではなく会場のご提供などでも関係を深めてコミュニティに貢献していきたいと思います。 devlove-kansai.doorkeeper.jp scrumdo-kansai.connpass.com スクラム 道関西さんには既に一度、弊社にお招きしてオープン・ジャムを開催して頂きました。また、3/18にはDevLove関西のイベントを弊社にお招きして開催予定です。 devlove-kansai.doorkeeper.jp また、弊社でも毎月１回エンジニアもくもく勉強会を開催してエンジニアの交流の場をつくっていこうとしています。よろしければぜひご参加ください。 rakus.connpass.com

こんにちは。堀内（ id:yhoriuchi ）です。 弊社が日頃からお世話になっている 株式会社アトラクタ 様が開催された 認定スクラムマスター研修 を受講してきました。講師は Gabrielle Benefield さんで、ジェフ・サザーランド博士が率いるScrum Foundationの共同設立者でもある方です。 Gabrielle Benefieldさん 研修内容が非常に素晴らしかったため、少しでもご紹介できればとの思いで研修の簡単な紹介、学んだこと、現場でやってみたことをお伝えしたいと思います。 研修概要 スクラム マスター研修は2日間のコースです。Gabrielleさんがメイン講師で、株式会社アト ラク タの 原田さん が研修をサポートする体制で行われました。 基本的に研修は英語ですが、プロの通訳の方が同時通訳を行いながら進行します。要所要所で原田さんがご自身の経験や考え方を交えた補足を行なって（日本語）くれましたので、 スクラム を学ぶ上でこれ以上ない講師陣だったと思います。 研修の始まり 研修が始まるとGabrielleさんから「全員と握手」するように言われます。40人ほどの参加者が部屋を歩き回って全員と握手するというワークショップ（？）です。初めて顔を合わせる人たちばかりでしたが、最初に握手をするだけで後の研修が非常にやりやすくなったと感じています。 スクラム マスター研修は多くのワークショップが取り入れられた内容になっているので、こうした 心理的 な障壁を最初に取り除く行動は研修そのものの効果を上げることにつながりました。 次のワークショップ：ピンポン玉回し 研修生が20人ずつくらいの2チームに分かれ、ピンポン玉を特定の時間内に落とさず手渡しで何個回せるか、という簡単なゲームをしました。2チーム同時に始めて優劣を競うのですが、チームごとにやり方が違うため、当然のように差が出ます。その後、一方がもう一方のチームのやり方を観察して自チームのやり方を見直し、改善するということを行いました。この時一番驚いたのが、相手チームを観察して良かったやり方をそのまま真似るのではなく、私が想像していた以上の改善が行われ、無駄がそぎ落とされた方法に一瞬で進化したことでした。観察して振り返り改善することの重要性に気付かされたその時の衝撃は今でも忘れることができません。 やり方は違えど、以前 吉羽さんに社内で実施して頂いたスクラムトレーニング で伝えようとしていたことが改めて理解できた気がします。 色々端折りますが その後は スクラム の全体の流れを説明頂いたり、チームに分かれてワークショップを行ったりして スクラム の理解を深めました。 疑問があれば随時質問を行うこともでき、貴重な意見やアド バイス を受けることができます。知識としての スクラム だけでなく、多くの現場を見て改善されてきた知見を持つ講師からのアド バイス は心に突き刺さるものがあります。私が質問をした回答の最後に、Gabrielleさんが "Good luck"と言ってくれたのは今でも心の支えとなっています。 学びを実践で試すと更に学べたこと 研修に参加すると、不思議と勇気と自信が湧いてきます。そのまま自社に学びを持ち帰り、一番試してみたかったことを早速試してみました。それが「他チームを観察する」です。タイミング的に他チームを観察することが難しかったため少し工夫して、他チームの スクラム マスターをやっている id:radiocat に自チームの振り返りの ファシリテーター をお願いしました。 「人は鏡」といった言葉があるように、人は人との対話を通じて自身の内面に気付かされることが多くあります。 スクラム の振り返りでの開発チームと ファシリテーター という関係性から考えて、チーム外の人が ファシリテーター を行うことにより、自分たちのチームが外からどのように見えているのか気付かされ、新たな改善や行動につながることに期待していました。 結果は思っていた以上のものでした。 開発チームメンバー個別に振り返りの感想を聞いてみたのですが、全員が口を揃えて同じことを言っていたのです。それが 「1週間で課題（problem）が多いのは正常なのか？」 という質問があったということでした。振り返りに KPT を利用しているのですが、“P”に上がる項目が多いように外からは見えるというチームへの見事な問いかけだったんだなと思いました。 感じ方は人それぞれあるようですが、この質問がチームにとって大きな意味があり、各自が深く考えるきっかけを与えてくれました。 更には、他チームの振り返りをファシリテートすることで ファシリテーター 自身も多くの気づきがあったようです。 下記がその一部。 チームの関心事によって出てくるものが全く違う。 振り返りのファシリテートはすごく重要で、すごく難しい。 チームが課題と感じているところを察知して石を投げ込まないと意味がない。 振り返りはプロセスの改善の場であると他チームの課題感を通して改めて認識することができた。 これらを聞いて私自身も学べることが多く、この一連の行動から学びで学びを繰り返すのだと気づかされました。今後はチームとしての学びを最大化するためにも スクラム マスターとしての学びは尽きることがないと気を引き締めた次第です。 そしてその先へ 認定 スクラム マスター研修を受けると、認定 スクラム マスター（CSM）になるための受験資格がもらえます。オンラインで受験できるのですが、私も無事合格することができました。CSMは資格取得して終わりではなく、むしろ果てしなく続ける旅路の始まりだと思っています。このような研修の機会を作ってくれた株式会社アト ラク タ様や自社にも感謝しつつ、これからも スクラム チームを支援していきたいと思います。 ジャーニーは始まったばかりです。

こんにちは、fuj_takです。 エレベーターがなかなか来なくてもやもやすることありませんか？ かく言う私もエレベーター待ちになると、いつ来るんだろうと悩まされます。 自分にエレベーターの制御をやらせれば、もっといい感じにできる 皆さんも一度は考えた事があるのではないでしょうか！ そんなあなたにこちらをご紹介します。 Elevator Saga Elevator Saga - the elevator programming game GitHub にも公開されています。 GitHub - magwo/elevatorsaga: The elevator programming game! ※私の環境だと IE でうまく画面表示できなかったので、 Chrome などのブラウザでお試しください プログラミング内容 ブラウザ上で JavaScript のコードを記述し、エレベーターの操作を行います。 エレベーターに乗った乗客の行先ボタンに応じた制御、 各階での上下ボタンが押された場合のエレベータの制御、 などを行い、時間内に多数の乗客を輸送できるかどうかにチャレンジするという内容。 ブラウザさえあれば誰でもお手軽に試せるので、チーム内ワークショップとかでも使えると思います。 2015年頃に公開されているようなので、一度は触ってみたことがある方もいそうですね。 API も公開されています。 Elevator Saga - help and API documentation やってみた エレベーターの数や各階の数が異なる設定で全18ステージあります。 https://play.elevatorsaga.com/#challenge=1 https://play.elevatorsaga.com/#challenge=2 　～ https://play.elevatorsaga.com/#challenge=18 頑張ってみたのですが、5ステージを超える事ができませんでした。。。。 色々と無駄な動きが多いですね。 エレベーターの制御プログラムを作っている方々、えらそうなことを言ってすみませんでした m(_ _)m 我こそはという方は是非チャレンジしてみてください！！ 参考に API を頼りに作ったコードです。 いけてない点があるのは承知していますが、笑って許してください。 { init: function(elevators, floors) { var waitFloor = []; var queuePush = function(floorNum){ if (waitFloor.indexOf(floorNum) < 0) { waitFloor.push(floorNum); waitFloor.sort(function(a,b){ if( a < b ) return -1; if( a > b ) return 1; return 0; }); } } // 動作対象のエレベーター取得 var getTargetElevetor = function(updown, floorNum){ var target = null; elevators.forEach(function(e) { // エレベータ内の混在率を考慮 if(e.loadFactor() < 1) { if (updown == "up") { if (e.destinationDirection == "up") { if (e.currentFloor < floorNum) { target = e; } } else { target = e; } } else if (updown == "down") { if (e.destinationDirection == "down") { if (e.currentFloor > floorNum) { target = e; } } else { target = e; } } } }); return target; }; // エレベーターの上昇／下降に合わせて停止階を決める var setStopFloor = function(e, floorNum){ // 上昇中は上階のみ止まる if (e.destinationDirection == "up") { if (e.currentFloor < floorNum) { e.goToFloor(floorNum); } // 下降中は上階のみ止まる } else if (e.destinationDirection == "down") { if (e.currentFloor > floorNum) { e.goToFloor(floorNum); } // 停止中は指定階に向かう } else { e.goToFloor(floorNum); } }; elevators.forEach(function(e) { // 待機中 e.on("idle", function() { // 1階で待機 e.goToFloor(0); }); // 行先ボタンプッシュ e.on("floor_button_pressed", function(floorNum) { // 上昇中 if(e.goingUpIndicator()) { if(e.currentFloor() < floorNum) { e.goToFloor(floorNum); } // 下降中 } else if(e.goingDownIndicator()) { if(e.currentFloor() > floorNum) { e.goToFloor(floorNum); } } else { e.goToFloor(floorNum); } // 行先を制御 setStopFloor(e, floorNum); }) // 移動中 e.on("passing_floor", function(floorNum) { }); // 到着 e.on("stopped_at_floor", function(floorNum) { // エレベーター待ちをクリアする waitFloor = waitFloor.slice(waitFloor.indexOf(floorNum), 1); }); }); // 各階で上下ボタンがプッシュされた floors.forEach(function(f) { f.on("up_button_pressed", function() { queuePush(f.floorNum()); var e = getTargetElevetor("up", f.floorNum()); if(e != null) { // 行先を制御 e.goToFloor(f.floorNum()); } }); f.on("down_button_pressed", function() { queuePush(f.floorNum()); var e = getTargetElevetor("down", f.floorNum()); if(e != null) { // 行先を制御 e.goToFloor(f.floorNum()); } }); }); }, update: function(dt, elevators, floors) { // We normally don't need to do anything here } } エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは。実は ラク ス大阪ビアバッシュ実行委員の、Y-Kanohです。 先日、毎月恒例のビアバッシュ@大阪を行いました。 今回のテーマは、「 他部署のお仕事紹介 」。 いつもは技術系の発表ばかりのビアバッシュに、他部署の方をお招きし、それぞれのお仕事内容を発表していただく、毎年恒例の人気企画です。 今回も内容をダイジェストでご紹介いたします。 営業のお仕事 まず、配配メールの営業担当に発表頂きました！ ネット申し込みなどが普及し、システムを売るために、人手が必ずしも必要でない中における、営業の存在意義を教えていただきました。 お客様の困っていることを解決するためにも、 人それぞれに違うシステムに対する価値観を、いかに高めて紹介するかが腕の見せ所だそうです。 また、営業担当としてプレゼン時に心がけているテクニックも教えていただきました。 ネットワーク純情派 つぎに、365日インフラを守っているインフラ部隊、「ネットワークチーム」からの発表です。 ログ調査から障害対応まで、幅広い業務内容についての話から、 日々取り組んでいる、サービス品質向上のために行っているプロジェクト活動についての話などを伺いました。 （表紙のデザインがシブいですね。） 情シスの業務紹介 多数の業務内容を抱えている情報システム部からも発表頂きました。 業務内容は多岐にわたり、比較的馴染みのあるPC管理や、問い合わせ対応から、 あまり表に見えない、社内システムの基盤整理、セキュリティ対策、新しいITサービスの導入などについてお話しいただきました。 また、実際に最近社内へ導入された、業務効率化のための Bot システムの紹介もしていただきました。 これからも、 ラク スグループで働く人（： ラク ト）のために、より良いIT環境をサポートして下さるそうです。 サポートお仕事紹介 楽楽精算の顧客サポートを行っている、大阪サポート課からの発表です。 顧客サポートの中でも、導入支援を専門に行っているチームです。 せっかく導入したシステムを最大限利用してもらうため、2か月間の専属サポートを行い、 できるだけ長く使っていただけるよう工夫しているそうです。 技術発表 いつも通りの技術系発表も行いました。 OSS の開発にJOINした話 OSS の開発にJOINした経験から、仕事や開発における積極的な行動の意義を教えていただきました。 フェリー ハッカソン 参加報告 先日、 こちらの記事 で紹介された、フェリー ハッカソン のレポートです。 記事には載らなかった内容まで、写真を交えて発表していただきました。 また、最後にはLTでの発表も行いました。 いつもはエンジニアばかりのビアバッシュですが、今回はエンジニア以外の方も巻き込んで、いつもとは違うビアバッシュを行うことができました。 毎年行っている企画ですが、毎回新しい発見や知らなかった情報が出てくるため、ぜひ今後も続けたいです。 以上、大阪開発ビアバッシュレポートでした。

いろ いろ なところでネタになっている開発エンジニアの坂田です。 以前の投稿 で周知されました通り、先日開催されたLaravel JP Conference 2019に登壇してまいりました。これも以前の投稿で触れていましたが、株式会社 ラク スは BRONZE スポンサーとしてイベントに協賛しました。 イベント概要 日時 : 2019 年 2 月 16 日 (土) 会場 : グランパークカンファレンス 公式 HP : https://conference2019.laravel.jp/ ハッシュタグ ： #laraveljpcon conference2019.laravel.jp 登壇 チャットディーラーの高速開発を支える Laravel（30分セッション） speakerdeck.com 昨年の PHP カンファレンス関西 2018 で発表 した内容から資料を修正して再演しました。 感想 個人的にはあまり満足のいく発表が出来なかったなというのが正直な感想です。 マイクを持ってしゃべればよかった 発表中、聞いてくれている人たちをあまり見れていなかった（話に興味を持ってくれているか不安になった） 時間を余らせてしまった 登壇力が足りない ただ良かったこともありました。 「Mustache Injectionという言葉を流行らせたいので覚えて帰ってください」がちょっとうけてた Mustache Injectionについてつぶやいてくれている人がいた mustache injectionという言葉を覚えて帰ってください。 #laraveljpcon #laraveljpcon3F — なずな🌱 (@akaa07_pg) 2019年2月16日 mustache injection 簡単に起こせますな！！怖い。。。 #laraveljpcon #laraveljpcon3F — KamiyaKizuku (@kizu19911020) 2019年2月16日 mustache injection こわい #laraveljpcon #laraveljpcon3F — 青ごへいもち (@blue_goheimochi) 2019年2月16日 これからLaravel＋Vueで開発する予定だったから XSS 対策の話聞けてよかった。知らなかったらやっちゃう、mustache injection。 #laraveljpcon3f — よだか (@engineerYodaka) 2019年2月16日 やはり 脆弱性 に関する話題は関心をひきやすいのだなという印象です。 Mustache Injectionに関して参考 Mustache Injectionに興味を持ってくださった方向けに参考情報を載せておきます。 https://laravel-news.com/laravel-5-6-9 https://medium.com/@taylorotwell/js-frameworks-server-side-rendering-and-xss-722805009892 https://github.com/dotboris/vuejs-serverside-template-xss

Y-Kanohです。 先日、弊社がスポンサーとなっている、Laravel JP Conference 2019 のライトニング トーク に登壇してきました。 イベント概要 こちらの記事で紹介いただいたイベントです。 tech-blog.rakus.co.jp 日時 : 2019 年 2 月 16 日 (土) 会場 : グランパークカンファレンス 公式 HP : https://conference2019.laravel.jp/ Laravel JP Conference は、今回が初めての開催です。 （このような登壇イベントでの発表は初めてでしたが、まさかのトリの発表でした...） 発表資料 発表時の資料はこちらです。 speakerdeck.com 資料作成前は、基本機能の紹介等をクイズ形式で面白おかしくできたらと思いましたが、 実際はもろもろの事情により GitHub のコードから非常にコアな問題を出題することにしました。 感想 思ったより受け入れられて、とても楽しかったです。少しネタ寄りの発表でしたが、 コードを読まないとわからない内容だったため、聞き手の方もクイズを楽しんでいただけたようで、 発表後の懇親会では「Laravel クイズの発表者です」というと、「1問しか正解できませんでした」とか、「Laravel の内部って面白いですね」など、様々な反響をいただけました。 ちょうど、他のセッションで「何らかの形で少しでもアウトプットを行うことが成長への近道」といった話がありました。 私も、今回の登壇を機に、ブログや登壇といったアウトプットの機会を増やせればと思います。

初めまして、新卒エンジニアのEngawaです。 今回は iphoneアプリ 作成で使っている Monaca についてかなり簡単に紹介させていただきます。 Monacaとは 統合開発環境(IDE) デバッガー おわりに Monaca とは アシアル株式会社様が提供しているハイブリッドアプリ作成の開発プラットフォームです。 統合開発環境 ( IDE )とデバッガーなどの機能を提供しています。 統合開発環境 ( IDE ) Monaca では クラウドIDE という IDE が用意されています。 名前の通り クラウド 上のあるためローカルで面倒な環境設定を行わなくても、会員登録さえすればどの端末でもブラウザ経由ですぐに開発ができます。 実際の編集画面はこんな感じです。 普段から eclipse を使っており、 Monaca の開発画面の見た目はほとんど同じだったので大まかな扱い方はすぐに理解できました。 実行結果も上図の右側の部分にあるのですぐに確認できます。 また、 Monaca が提供しているデバッガーを使用すれば スマートフォン でも実行結果を確認することもできます。 デバッガー 上にも記載したのですが、動作確認する時は Monacaデバッガー という デバッグ 用のツールを使えば スマートフォン で動作の確認をすることができます。 アプリ自体は普通に App Store 、 Google play で無料でインストールできます。 アプリのインストールが完了したら、アプリを立ち上げてログインし、作成したプロジェクトを選択するだけで簡単に確認することができます。 デバッガーの画面はこんな感じです。(作成したプロジェクト一覧(左)と実行結果(右)をくっつけてます) おわりに 今回は、 Monaca についてかなり簡単に紹介させていただきました。 面倒な環境設定をしなくて済む上、様々なテンプレートが用意されているので手軽に アプリ開発 を行いたい方にはオススメします。 Monaca に関しての詳しい記事は こちら にもあります。 参考サイト： https://www.asial.co.jp/business/mobile/ https://ja.monaca.io/features/

メールディーラー開発エンジニアの@neroblubrosです。「フェリー ハッカソン に行ってくる」というブログを前回書きましたが、実際に行ってきたことを書きます。 前回書いたブログの記事 tech-blog.rakus.co.jp 若手社員と一緒に参加しました 前回のフェリー ハッカソン には私ひとりで参加しましたが、今回はなんと若手社員のふたりも参加することになり、 ラク スからは合計3名でフェリーに乗り込みました！ 若手社員が書いた参加レポートはこちら MasaKu tech-blog.rakus.co.jp Y-Kanoh tech-blog.rakus.co.jp フェリー ハッカソン に限らず、私はいままでいくつかの ハッカソン に参加してきましたが、今回のフェリー ハッカソン はプレイヤーではなく、スタッフとして参加しました。 スタッフの中でもプレイヤーのみなさんをサポートする「メンター」です。 どこまでサポートするか？で迷いました メンターのお仕事は前述のとおりプレーヤーのサポートです。具体的には下記のとおりです。 各チームのア イデア をどうやって実現すればいいか？の提案 API の使い方などのサポート 時間が足りない！ときの助っ人 実際のところ、1と2はあまりありませんでしたが、2日目に進捗が遅れているチームが発生したので、そのチームに助っ人に入ってサポートをしました。 チームの助っ人を始めると「どこまで手伝うか？口出しをするか」ということに苦慮しました。 チームそれぞれの思いや考えがあるため、コンセプトといった成果の根幹に関わる部分に口出しはできません。そういう意味でメンターは受け身です。 その反面、チームメンバーは猫の手も借りたい状態なので「もっと手伝ってほしい」「いろいろ意見を言ってほしい」とメンターに求める気持ちも理解できます。 また、私自身「こうしたらいいのに」「こっちのほうが絶対いい！」という意見もあり、それをチームに伝えるか伝えないかで迷いましたし、「メンターが言うのだから」とある意味チームメンバーの方が気を使うことも恐れました。 この点がメンターをするにあたり難しいと感じたことです。 他のメンターと相談しながらサポートし、結果的にお願いされたこと以上のことはしない、聞かれたこと以外のことは答えないことにしました。 ですので、恐らくサポートしたチームメンバーの方々は物足りなく感じたと思います。 ハッカソン は自分ができることと足りないことを教えてくれる 最後に、私が ハッカソン に参加する目的について書いてこの記事を終わりにします。 私が ハッカソン に参加するのは「自分ができることと足りないこと」がわかるからです。 技術的な知識やスキルももちろん大切なのですが、 ハッカソン はごくわずかな時間の中で成果を出す必要があるので チームのタスクを効率よく処理するにはどうすればいいか 突発的に発生した問題にどう対処すればいいか 成果を審査員に理解してもらうにはどういう発表をすればいいか と言ったモノの考え方やチームの進め方がより大事だと私は考えています。 そして「自分のやり方は正しかったか？」「考え方は間違っていなかったか？」ということを ハッカソン 終了後に自問自答することで、自分が通用したところ、しなかったところ再確認できる。 だから私は ハッカソン に参加しています。 こういったことは一方通行の セミ ナーでは体験することができません( セミ ナーがダメだと言っているのではありません)。 今回は迷うところがありましたが、フェリー ハッカソン にメンターとして参加したことはとても勉強になりました。 みなさんも ハッカソン に参加しませんか？ ＃そうだ ハッカソン に行こう！

はじめまして、新卒1年目のエンジニアの id:aa_crying です。 今回はブログ運営でも使っている Google アナリティクスと、 UTMパラメータについて調べてみましたので、紹介させていただきます。 Googleアナリティクスとは UTMパラメータとは 実際にパラメータ付きURLを作成する アクセスして、結果を確認する まとめ Google アナリティクスとは Google アナリティクスとは、 Google アカウントの作成後、「 Google アナリティクスに申し込み」を行うだけで利用できるフリーの アクセス解析 ツールです。 申し込みをすると「新しいアカウント」作成画面に遷移するので、必要項目の入力後、ト ラッキング IDを取得できます。 このト ラッキング IDをサイトに埋め込むことで、 Google アナリティクスでサイトのアクセス計測が可能になります。 UTMパラメータとは UTMパラメータとは、プロモーション広告やバナー広告、メルマガなどの効果を計測するために設定するパラメータのことです。 Google アナリティクスでは カスタムキャンペーン と呼ばれています。 UTMパラメータには、以下のような種類があります。 パラメータ 説明 utm_source プロパティに トラフィック を誘導した広告主、サイト、出版物、その他を識別します utm_medium 広告メディアや マーケティング メディアを識別します utm_campaign 商品のキャンペーン名、テーマ、プロモーションコードなどを指定します utm_term 有料検索向けキーワードを特定します utm_content 似通ったコンテンツや同じ広告内のリンクを区別するために使用します *1 よく使われるのは utm_source , utm_medium です。 utm_source の部分を サイト名 にすることで、どこのサイトから 流入 したかを簡単に区別することができます。 実際にパラメータ付きURLを作成する パラメータ付きURLは以下のサイトで簡単に作成ができます。 https://ga-dev-tools.appspot.com/campaign-url-builder/ 今回は、 utm_source=mattermost , utm_medium=social でURLを作成します。 計測対象のURLと、それらの情報を入力すると、下の Share the generated campaign URL の欄にURLが作成されます。 UTMパラメータの作成 アクセスして、結果を確認する 実際に作成したURLからアクセスしてみます。 https://aa-crying.hatenablog.com/entry/20190206/tameshi1?utm_source=mattermost&utm_medium=social その結果を Google アナリティクスから確認します。 結果は、 リアルタイム > トラフィック から確認することができます。 Google アナリティクスでの確認結果 先ほど設定した utm_source の内容が ソース に、 utm_medium の内容が メディア に表示されていれば正しく計測が出来ています。 まとめ 今回は、 Google アナリティクスの初歩である、UTMパラメータ(カスタムキャンペーン)の扱いについてご紹介しました。 今回お見せした部分は Google アナリティクスの機能のほんの一部であり、他にも様々な機能があります。 誰でも気軽に、簡単にアクセス計測が出来ますので、興味のある方はぜひ活用してみてください。 参考サイト https://support.google.com/analytics/answer/1033863#parameters https://seolaboratory.jp/59695/#p01c エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com *1 : たとえば、メールのメッセージに行動を促すフレーズのリンクが 2 つある場合は、utm_content を使用して別々の値を設定し、どちらが効果的か判断できます。