はじめに こんにちは、 @rs_tukki です。新卒2年目です。 前回の記事は以下をご覧ください。 tech-blog.rakus.co.jp また、以前に書いた記事がじわじわアクセス数伸びてきているみたいです。ありがとうございます！ tech-blog.rakus.co.jp さて、本題に入りましょう。 社会人として2年目に入り、テストの結果を資料にまとめたり、バグ修正の対応方針を伝えたりと、自分のやったことを先輩や上司に報告、発表する必要性が増してきたように思います。 自分は今まであまり説明やら発表やらが好きではなかったのですが、今では得意というほどではないにしろ、徐々に苦手意識はなくなってきました。 今回は、エンジニアとして必須スキルである説明や発表の苦手意識を取り払うための1つの手段、 LT についてのお話です。 はじめに Lightning Talks(LT)とは？ 何故LTが有効なのか 「説明する」という行為の練習になる 色んな技術の知見が得られる 人と繋がる機会になる まとめ 参考 Lightning Talks(LT)とは？ ではまず、 LT とは何でしょうか？ 困ったときの Wikipedia 先生。 ライトニング トーク （英: Lightning Talks）とはカンファレンスやフォーラムなどで行われる短いプレゼンテーションのこと。様々な形式があるが、持ち時間が5分という制約が広く共有されている。 形としてのライトニング トーク は1997年の Python カンファレンスで初めて行われたとされている。[1]その時点では単に「ショート トーク 」と呼ばれていた。「ライトニング（Lightning：稲妻、電光石火）」という言葉が用いられるようになったのは、2000年6月に行われた YAPC 19100 Conferenceからとされている。[2]その後技術的なカンファレンスに於いて、この言葉が浸透するようになっていった。 LTというのは簡単に言えば短いプレゼンのことです。 プレゼンテーションというと、会社内では新しい企画の説明会、会社外では新商品の発表会…などなど、どちらにしても1時間以上は時間をかけてじっくりと話すイメージがあるかと思います。 ですが、LTは「稲妻 トーク 」という意味からも分かる通り、持ち時間はだいたい5分、長いものでも10分とごくわずかです。 LTの内容自体はある程度のテーマこそ指定されるものの、技術的な トーク に限定されないことも多く、皆さん限られた時間の中で自分の好きな話を自由に発表しています。(そして勉強会などでない限りは大体お酒がついてきます) connpass 等の募集サイトでも頻繁にLT会が開催されていたりします。 reedex.connpass.com connpass.com engineers.connpass.com 何故LTが有効なのか 最初に、LTとは 説明や発表の苦手意識を取り払うための1つの手段 と説明しました。 LT…というより発表自体に苦手意識のある人にはハードルが高いかと思いますが、それでも私としては、社内、社外問わず新卒のうちからぜひLTに登壇してみてほしいと思っています。 「説明する」という行為の練習になる LTの特徴は、何と言ってもその短さです。 「長い時間話すのに耐えられない」「目を合わせられない」という人でも、大体5～10分経ってしまえば強制的に終了ですから、割と失敗しても恥ずかしくないです。 社外のLTでヤジが飛ぶのが怖い…という人もいますが、大抵社外のLTは Twitter で実況されるので見ている人もヤジを飛ばしている余裕はないと思います(笑)。 togetter.com そんな環境の中で、自分が学んだことや気になっていることを短い時間で発表することで、資料の作成に慣れ、分かりやすい伝え方に慣れ、いずれは社内で人に説明することにも慣れていけるのではないかと思っています。 色んな技術の知見が得られる 新卒として会社に入社した皆さんは業務で使う技術を学んでいるかと思いますが、部署が異動になればまた別の技術が必要になるでしょうし、転職ともなれば今持っている技術では太刀打ちできないこともあるでしょう。 そんなときに、 新たな技術を(名前だけでも)知っている、というのは大きな武器になり得ます。 話をする側だけでなく、聴く側としても様々な人の様々な内容のLTを聴く中で、エンジニアとしての知識がどんどん身についていけると思います！ 人と繋がる機会になる こと社外のLTで言いますと、これも結構なメリットです。 先ほどLTの内容は Twitter で実況されると書きましたが、発表が終わり、懇親会になった後で気になった発表者にお話を聴いてみるのもいいと思います。そこから SNS 等で繋がることもありますし、話が盛り上がる中で別の勉強会に誘っていただけることもあります。 新卒の間はどうしても社外の人と繋がる機会が少ないかと思いますが、こういったLTの機会から輪を広げていってみてはどうでしょうか？ まとめ 今回の記事で言いたかったことは一つです。 「説明力」の向上のために、LTに積極的に登壇しましょう！ そして、 皆さんの面白い話をぜひ聞かせてください！ 以上です。ご視聴ありがとうございました。(LT風に) 参考 ライトニングトーク - Wikipedia IT業界でよく聞く「LT」ってなんなの？3つのメリットを知って、きみもLTしてみよう！ | トビラシステムズ株式会社

はじめに FM_Harmonyです、8月2回目の投稿になります。 ↓前回の記事はコチラです tech-blog.rakus.co.jp 今回はgitコマンドのfetchについて、学んだ内容をまとめてみました。 今回の記事を書こうと思ったきっかけは pullとfetchの違い について尋ねられた時、細かいところまで答えられなかったことです。 （大雑把に fetchはデータを持ってくるだけ、pullはmergeまで行う ということまでは答えられたのですが...） そこで、この機会にfetchについて学びなおしてみました。 Gitを学び始めたばかりの方や、復習したいと考えている方の参考になれば幸いです。 はじめに fetchの説明...の前にリモート追跡ブランチの説明 本題、fetchの説明 merge, pullの説明 おわりに 参考 fetchの説明...の前にリモート追跡ブランチの説明 fetchを説明するうえで リモート追跡ブランチ の説明は欠かせません。 では、リモート追跡ブランチとは何でしょうか？ リモート追跡ブランチ（Remote-tracking branch）とは、ローカル リポジトリ にあって リモー トリポジ トリの状態を保持する参照 です。 簡単に言うと、リモートにある同名のブランチと同一のコミットを指すブランチの事です。 このブランチの特徴として、リモート追跡ブランチのブランチ名は( リポジトリ 名)/(リモートのブランチ名)で固定される、ユーザが変更をコミットするなどしてブランチが指すコミットを直接操作することはできない、といったことが挙げられます。 そのため、ローカル リポジトリ からもリモート追跡ブランチを通じて、リモー トリポジ トリの変更を確認する、ローカルの作業ブランチにリモートの変更を取り込むといったことができるようになっています。 しかし、ローカル リポジトリ は24時間365日ネットワークに接続はしていません。 そのため、ローカル リポジトリ にあるリモート追跡ブランチは常にリモートのブランチと同じものを指すわけではありません。 誰かがリモートのブランチに変更をpushしてしまうと、リモート追跡ブランチとリモートにある同名のブランチが指すコミットが異なるということが発生します。 この状況を解消するために使うコマンドが fetch なのです！ 本題、fetchの説明 fetchコマンドを利用することで、リモー トリポジ トリの変更をローカル リポジトリ に取り込み、リモート追跡ブランチを同期することができます。 例えば、下記のコマンドを利用すると、リモー トリポジ トリ origin の master ブランチについて、変更をローカル リポジトリ に取り込み、リモート追跡ブランチ origin/master をリモートブランチ master と同期させます。 $ git fetch origin master この時点では、ローカルの作業ブランチに変更は反映されません。 そのため、例えばローカルのブランチ master に対してコミットを行っていた場合、リモート追跡ブランチとローカルのブランチとが分岐することになります。 merge, pullの説明 さて、こうして取り込んだリモートブランチの変更をローカルブランチに反映するにはどうすればよいでしょうか？ その方法の一つとして、 ローカルブランチにリモート追跡ブランチをmergeする という方法があります。 例えば、 origin/master とローカルブランチ master が分岐する場合、下記のコマンドを実行することで図のようなブランチ構造になります。 $ git checkout master $ git merge origin/master また、同じコマンドを実行した場合でも、 origin/master がローカルブランチの先のコミットを指しているだけで分岐していない場合、 master の指すコミットを変更するだけのいわゆる Fast-forward マージを行います。 別の方法として、 pull コマンドを利用するというものがあります。 これは、 fetch + merge と同じ動作を行います。 すなわち、 $ git checkout master $ git pull origin master というコマンドは、下記のコマンドと同義です 。 *1 $ git checkout master $ git fetch origin master $ git merge origin/master おわりに fetchについて簡単にまとめてみたのですが、いかがでしたでしょうか。 個人的にはリモート追跡ブランチの存在を知らなかったため、この機会に知ることができて良かったと思います。 今回の記事作成を通して、Gitについてまだまだ知識が足りないことが分かったので、また別の機会に他の操作(addやpush, etc...)について、機会を作って調べてみようと思います。 参考 Git - リモートブランチ Gitの公式によるリモート追跡ブランチとfetchの説明です エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 *1 : 厳密には同義ではなく、masterにmergeされるのはFETCH_HEADというfetchした際に作成されるブランチです。

id:radiocat です。既に記事で紹介されていますが、大阪オフィスの開発部内で毎月開催しているビアバッシュで『タスク管理のやりかたとツールの使いかた』というタイトルで発表をしました。 tech-blog.rakus.co.jp 今回はこの発表で紹介した スクラム 方式のタスクマネジメント手法を改めて記事にまとめます。 個人のタスクマネジメントとは？ そもそも個人のタスクマネジメントというのはいつ、何を、どう管理するのでしょうか？ 家族と生活している人は家族に頼まれた買い物を会社帰りに買って帰るために買い物というタスクを管理したいかもしれません。反対にプライベートは自由気ままに過ごしたいので細かい事まで管理したくない人もいるかもしれません。 ツールの選びかた 何をどこまで管理したいのかは人それぞれなので、ツールの選びかたもその人の生活スタイルや環境によって変わってきます。 世の中には様々なタスクマネジメントツールがあります。ネット上ではTrello、Todoist、asanaといったサービスを使った事例をよく目にします。私の所属するチームではTrelloを使っています。 trello.com ja.todoist.com asana.com 私の場合は家族と生活をしていて自分の時間は限られているのでスキマ時間は大切です。また、 スマホ は Android で、カレンダーやメールは Google のサービスを使うため、これらと連携した使い方もポイントになります。 また、性格的にプライベートをあまりキッチリ管理するのは息苦しく感じるため、スキマ時間を使うにしても手軽さやカジュアルさも重要です。 Google Keepの使い方 以上を踏まえて私が選んだツールが Google Keepです。 Google Keepはタスク管理ツールというよりはメモツールですが、それが逆にシンプルで個人でタスクを管理するならこのレベルで十分と感じています。 スケジュールとの連携など Google の他のサービスとも連携できます。 スマホ のホーム画面に表示される ウィジェット や、駅などの特定の場所に到着したら通知してくれるリマインド機能も便利です。 外出中であれば音声で登録したり、 スクリーンショット を撮って残りは自宅でという、その場の状況に応じた使い方も可能です。 スクラム 方式のタスクマネジメント実践方法 そして、 Google Keepを使い、 スクラム のやり方にヒントを得たタスク管理の手法が今回紹介する スクラム 方式のタスクマネジメントです。 スクラム 同様にシンプルで軽量なマネジメント手法です。 バックログ のように重要なものから1列に並べる Google Keepはメモツールとして登録したメモが縦一列に並ぶようになっています。そのため重要なものから順番に並べるだけで バックログ のように扱うことができます。 バックログ のように「完了した／していない」だけを管理 スクラム ではスプリントの期限までに完了していないタスクはたとえ途中まで完成していたとしても未完了として扱います。個人のタスクマネジメントも同様です。買い物をしたり、ブログに記事を書くというタスクが途中まで終わっていてもあまり意味がありません。そのため、完了したかどうかだけを観測するようにします。また、完了したタスクは「 アーカイブ 」することで一覧からは除外されますが、メニューから アーカイブ 一覧を表示することができるためいつでも完了したタスクを確認することができます。 タイムボックスを決めて繰り返す 私は毎週日曜日に1週間を振り返って、翌週のプランニングをしています。プランニングでは1週間でできそうな範囲の上位のタスクだけを重要な順に並び替えて、リマインドを設定したり、タスクの内容を整理します。 スクラム でもユーザーストーリーを具体化したり完了の定義を明確化したりして バックログ をReadyにしますが、個人のタスクも同じようにブログのアウトラインをメモしておいたり、 Google Keepのリスト機能を使ってやることの詳細をチェックリスト化してReadyにします。 スクラム 開発とは違うところ スクラム 開発とは違って個人のタスクマネジメントではやらないこともあります。 全体の見通しを立てない 何かを開発したりリリースするわけではないので、個人のタスク管理には終わりがありません。そのため全体の見積もりやバーンダウンチャートを作って見通しを立てるようなことはしません。 個々のタスクを見積もらない 全体の見通しを立てる必要がないので個々のタスクも見積もりません。ただし、個々のタスクがどれくらい時間がかかるかなどを細かく管理したい人は見積もりをしてもいいかもしれません。 これらはあくまで私の場合はやる必要がないと感じていることですが、必要に感じる場合はやりかたをアレンジしてみても良いかもしれません。その場合は Google Keepではできないこともあるので、上記で紹介したTrelloなどの本格的なタスク管理ツールを使うほうが良いかもしれません。 おわりに この手法はやりかたはシンプルですが、プロセスがきちんと回るようにするためには、日々の状況チェックや1週間単位の完了確認、ふりかえりをどこまでやるかなどを、自分でルールを決めてブラッシュアップする必要があります。理解は容易ですが、習得が困難な点も スクラム と同じです。 今回は私が愛用している Google Keepを使ってのやりかたを紹介しましたが、同様のやりかたは他のツールでもできるかもしれません。自分の使いやすいツールで実践してみると良いでしょう。ただ、 Google Keepは軽量で扱いやすいツールなので、今回紹介した手法に向いているツールだと思っています。私と同じように普段使うツールは Google のサービスが中心で手軽にタスクマネジメントしたいという人は Google Keepを使って スクラム 方式の個人のタスクマネジメントを実践してみてはいかがでしょうか。 当日発表したスライドは公開していますので良ければご覧ください。 speakerdeck.com 告知：Meetupで スクラム 開発について発表します 当ブログでも既に告知済みですが、9/13に開催される弊社主催のMeetupで楽楽精算の開発チームが実践している スクラム 開発の取り組みについて発表します。今回の発表は過去の 社内イベント の資料がベースですが、資料をアップデートして当時はリリース前で話せなかった内容や、プロジェクトのその後の状況についても話をする予定ですのでぜひご参加ください。 rakus.connpass.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

kuwa_38です。 ラク スでは月１回のペースで開発メンバーの交流会としてビアバッシュを開催しています。 ビアバッシュとはビールなどと軽食を片手にフランクに技術内容について発表したり語り合う交流会です。 （7月分のビアバッシュについては下記の記事をご覧ください） tech-blog.rakus.co.jp 大阪開発部のビアバッシュでは、決められたテーマに沿った発表を行う「テーマ枠発表」と自由なテーマで発表を行う「LT（Light Talk ）枠」が存在します。 今月のテーマは「 ツール特集 」です。各々が使用している便利なツールや業務効率化のために使っているツールについて発表して頂きました。 本記事ではテーマ枠、LT枠（自由発表）それぞれの発表についてご紹介します。 テーマ枠（ツール特集） ツール紹介 Node.jsとnpmの関連ツール My Powerful Scripts タスク管理のやりかたとツールの使いかた 個人的に使っている便利ツール 業務効率UP iOSアプリ LT枠（自由発表） インフラエンジニアの怖い話 トウダン・ジャーニー おわりに テーマ枠（ツール特集） テーマ枠で行われた6件の発表についてご紹介します。各発表の紹介を少し記載した後、発表内で述べられていたツールを列挙します。 ツール紹介 Snipping Tool や Tampermonkey の スクリプト など業務で使用している便利なツールや スクリプト を紹介して頂きました。業務でどのような時に使っているのかというお話もあったため、使う場面が想像し易すく、他のチームの方がどのような業務や進め方をしているのかといった点でも参考になる発表でした。また、 Snipping Toolが廃止される ことは知らなかったため驚きでした。 Snipping Tool phpStormのDiff Node.jsとnpmの関連ツール Windows でのNode.jsやnpmのバージョン管理ツールであるNodistやnpmのバージョン5.2.0で導入されたnpx、自作したパスワードを生成するツールについて紹介して頂きました。npmを使用する従来の方法と、npxを使う方法を前で実践して下さったため、npxを使うことでワンラインで簡潔に実行できることがわかる発表になっていました。 Nodist npm npx パスワードを⾃動⽣成するツール My Powerful Scripts Tampermonkeyで自作した便利な スクリプト についてランキング形式で発表して頂きました。GitLabでのレビューを簡単にするために優先度を付加するボタンを表示する スクリプト やMattermostで未読のみを表示する スクリプト などを紹介して頂きました。「Mattermostで未読のみを表示する スクリプト 」はチャットがスッキリして見易くなるので私も普段から使わせてもらっています。 Tab キー押下時に、タブ（Hard Tab）の代わりに、スペース x 4（Soft Tab）を入力するスクリプト GitLab の Merge Request の Code Review コメントに対応優先度を付加する スクリプト Mattermost で未読チャンネルだけを表示する スクリプト タスク管理のやりかたとツールの使いかた 色々なタスク管理ツールを紹介した後、現在使っているタスク管理ツール（ Google Keep）とその使い方、何が良いのかについて発表して頂きました。業務向きというよりはプライベートでのタスク管理にフォーカスしたお話でした。 Google Keepでは Googleカレンダー などの他の Google アプリと連携ができること、どこでも見れることが便利とのことです。また、メモのように手軽に書き込み週末に優先順位を変更し、次の1週間のタスクを決めているそうです。 Google Keep （発表者おすすめ） Trello （今の主流） Todoist asana Toodledo Google Tasks Microsoft To-Do 個人的に使っている便利ツール コピー履歴を保存してくれるツール（Clipy）や Markdown 記法を用いて綺麗に書くことのできるエディタ（Typora）、 Mac 上のアプリ・ファイルなどを検索できるツール（Spotlight検索）など業務の中で個人的に使っている便利なツールの紹介を行いました。業務で Markdown 記法を用いることが多いため、TyporaやMarpは愛用しています。 Clipy Typora Spotlight検索 Marp 業務効率UP iOS アプリ 業務効率化のために使用している iOS アプリについて紹介して頂きました。現在、発表者の方が行っている業務の関係上、Office LensやSkitchなどの画像加工アプリがメインでした。おまけとして、文字に濁点を付けていく、Dakutenといった面白いアプリの紹介もあったため、 堅苦しい ものでなく聞き手から笑いの起こる発表でした。私も情報共有のために スクリーンショット をとり、説明を付加することは良く行うためいつくか試してみようと思います。 Office Lens Skitch Key 楽楽精算 モザイク ぼかし&モザイク加工アプリ Dakuten LT枠（自由発表） LT枠で行われた2件の発表についてご紹介します。 インフラエンジニアの怖い話 夏といえば怖い話。この発表ではインフラエンジニアが実際に起こした、または、起こすと肝が冷えるミスについてご紹介頂きました。発表中は笑いが起こっていましたが、 rm -rf / やshutdownコマンドなど、誤って実行してしまうと笑いごとでは済まないミスについてご紹介頂きました。rmコマンドやshutdownコマンドを業務で使ったことはありませんが、機会があるときは本当に気を付けないといけないなと考えさせられる発表でした。 トウダン・ジャーニー php conference 2018 Kansai に登壇したことについて、登壇が決まるまで、業務として登壇するにあたり準備したこと、資料作成などについてご説明頂きました。公開リハーサルや当日の発表に至るまでの発表者間でのタスク管理や情報共有など、登壇までの過程や裏側について知ることができる発表となっていました。 （登壇された様子については下記の記事を御覧ください） tech-blog.rakus.co.jp おわりに 今月も様々なタイプの発表が聞くことができて、大変充実したビアバッシュになりました。 次回のテーマは「 他人のスライド発表会 」です。他の人が作ったスライド、面白かった記事やスライドを用いて発表して頂きます。今までにない発表形式なので、どのような発表がされるのか楽しみです。

ラク スは「 IT技術 で中小企業を強くします！」をミッションに掲げ、 メール共有・管理システムのメールディーラーから始まり、経費精算システムの楽楽精算に至るまで、 延べ40,000社を超えるお客様に自社開発した クラウド サービスを提供してきました。 今回（9/13(木)）は、 ラク スで主力 クラウド サービスの開発を牽引するエンジニアによる トーク セッションと交流会を開催します。 クラウド サービス開発のエンジニアとして活躍している方はもちろん、 クラウド サービス開発にご興味をお持ちのエンジニアの方も気軽にご参加頂ければと思います。 自社開発ならではの技術・運用ノウハウや、新しい取り組みの成果や失敗談など ご参考にして頂ける情報を積極発信していきたいと考えております。 このイベントが新しい気づきや成長につながる機会を提供する場になるとともに、 ラク ス社員と参加者の皆さま、また参加者の皆さま同士で新たなつながりが生まれるきっかけになれば幸いです！ 開催概要 【日時】2018/9/13(木) 19:30～21:30(開場は19:00) 【会場】 ラク ス 東京本社 （〒151-0051 東京都渋谷区 千駄ヶ谷 5-27-11　アグリスクエア新宿2F [アクセス] ） 【定員】30名 【申込み】 connpass 【参加費】無料 【主催】 ラクス 今回の トーク テーマ 終わらない スクラム 　～楽楽精算のサービス拡大を支える スクラム 開発の取り組み 大塚正道（おおつかまさみち） ラク スでは、まだ多くの開発チームが ウォーターフォール 型の 開発プロセス を採用していますが、 一部のチームで スクラム による アジャイル 開発に取り組んでいます。 今回は楽楽精算チームでの取り組みを紹介します。 実際にやってみると様々な問題が発生しました。問題解決に向けたアクションや取り組みを通じて得た知見、今後の課題等を事例を交えてお話しします。 テッ クリード （自称）としてのやっていき！　～ iOS アプリ開発 チームを率いて 川並裕（かわなみゆう） 若手エースエンジニアが初めての iOS アプリ開発 でテッ クリード として奮闘したお話しです。 iOS アプリ開発 は、自身も初、メンバーも初、しかも短納期（3ヵ月．．．）。 この デスマーチ を予感させる不利な条件下で、テッ クリード としてどのようにチームをリーディングしたのか。 様々な事例を交えてご紹介します。 流行の開発手法ChatOpsとは　～楽楽明細チーム/ChatOpsでルーティン作業をまるごと自動化～ 三田英一（みたえいいち） Jenkinsの導入で自動化が進んだけど、「Jenkinsを毎回開くのは面倒」、「アカウントの作成も面倒」、「非エンジニアに使ってもらうにはちょっとハードルが高い」。 そこで導入したのがChatOps! Slack互換のチャットツール「Mattermost」でルーティン作業を丸ごと自動化しました。 利用した bot ツール、システム構成、Hubot スクリプト の実例など、ノウハウを余すことなくご紹介します。 タイムテーブル 19:00 開場・受付開始 19:30 イベントスタート 21:30 終了予定 トーク が終わり次第、交流会に移ります。 交流会では、フィンガーフード、ドリンクをご用意致します。 お気軽にご参加ください。 エントリー方法 [connpass] よりエントリーをお願いします。 ※当日はお名刺2枚ご持参ください ※提供可能な設備： Wi-Fi 、電源 会場 ラク ス　東京オフィス2F セミ ナールーム 東京都渋谷区 千駄ヶ谷 5-27-11　アグリスクエア新宿2F [アクセス]

こんにちは。エンジニアのmickey-STRANGEです。 今まではめんどくさがりをテーマに、「簡単に○○する方法」を紹介してきました。 tech-blog.rakus.co.jp 今回の記事では、3年目になった私が、これまでのエンジニア生活の中でやっててよかったと感じる「 JavaScript で遊ぶ」ことについてお話したいと思います。 エンジニアになると周りから「勉強しといた方がいいよ」「いろんな技術触っといた方がいいよ」と声をかけられることが多いと思います。 しかし、何から手を付けていいか分からない、どんな技術を、どんな言語を触ってみればいいか分からない、と最初は思うかもしれません。 そういった新人エンジニアの方が勉強と気負い過ぎず、軽い気持ちで「 JavaScript で遊ぶ」ことから始めるメリットについてお話していきます。 実行環境の準備が要らない JavaScript の実行環境はブラウザです。勉強を始めるための環境構築というフェーズが必要ありません。 テスト用のHTMLファイルさえ用意してしまえばブラウザで開くだけで実行してくれます。 ただ、最初はHTMLの記述と JavaScript の記述を同時に考えるのが難しいと思います。そんな時は普段見るサイトのHTML構成をそのまま引っ張ってくることをお勧めします。 実際に公開されているHTML構成なので作り込みがされていて、簡単にしっかりとしたテスト用HTMLを用意することができます。 こうすることで、自分でベースのHTMLを用意しなくても JavaScript の練習が出来るようになります。 環境構築が必要ないのは、とっつきやすさという面でかなりの強さになりますね。 実際に使える業務知識が得られる JavaScript は業務でもよく使う言語です。Web系エンジニアなら当然、画面上の動きは JavaScript で記述することになります。 とはいえ、非同期処理があったり、画面上のユーザ操作との兼ね合いがあったりで、実行順が分かりにくくなる傾向があり、私の周りでも JavaScript に対して苦手意識を持つメンバがちらほらいます。 私も最初はそうでしたが、 JavaScript でちょくちょく遊んでいた結果、大規模な画面改修タスクを担当することになっても怯まなくなり、今では苦手意識は自分ではほぼないと感じています。 また、 JavaScript はもはやブラウザ上だけの言語だけではなく、 JavaScript ベースの言語でネイティブアプリの画面を構成できたり、サーバサイドの処理を記述したりすることもできます。 以前投稿されたGASも、 JavaScript ベースの言語だったりします。 tech-blog.rakus.co.jp JavaScript は他の言語と比べて、得た知識がどこかで業務に繋がる可能性の高い言語であるといえるでしょう。 小さな改善がすぐにできるようになる 普段見るサイトやブラウザアクセスするシステムの画面に対して、使いにくいなーめんどくさいなー、と思ったことはありませんか？ そんな時は chrome の 拡張機能 のTampermonkeyがおすすめです。 chrome.google.com Tampermonkeyは、指定したURLのページが開いたときに自動で JavaScript を実行してくれる 拡張機能 です。 これを利用することで、普段使うシステムの画面をちょっと使いやすくする、といったことが気軽に行えます。 また、作成した スクリプト は他のメンバのTampermonkeyの画面に貼り付けしてもらうだけで共有が出来るので、小さな改善をすぐチームに共有することが出来ます。 私も社内の基幹システムの膨大な数のメニューをいい感じに検索出来る スクリプト を作成して、チーム内に共有していたのですが、いつの間にか広まっていき、他のチームの方から感想をいただくこともありました。 用事がない限り他チームの方に話しかける機会はあまりないので、こういった面でもとてもよかったと思います。 さいごに 私が感じた「 JavaScript で遊ぶ」ことで得られたよかった点をまとめてみました。いかがでしたでしょうか。 とっつきやすく 、 業務に繋がりやすく 、 改善にもつながる 、というのはかなりのメリットだと思います。 また、 JavaScript は ajax を用いることで他システムの API を叩くことも可能ですので、1つの スクリプト 内で出来ることの幅がかなり広いです。 「勉強しよう」と思うと難しいかもしれませんが、このページのここをこうしたいな、を原動力に「 JavaScript で遊ぶ」感覚で手を付け始めると楽しさが分かっていただけるかと思います。 楽しいという感覚になってしまえば勝手に持続するので、遊び感覚で スキルアップ してみましょう！

はじめに エンジニアのFM_Harmonyです。 Rakus Developers Blogには、何度か記事を投稿させていただきました。 tech-blog.rakus.co.jp ↑前回の投稿記事はこちらです さて、今年も早いもので7月初旬に開発部へ新卒社員が配属されました。 また、同時期にオフショア先の ベトナム 子会社から出張者の受け入れを行いました。 そこで先日、新卒社員＆ ベトナム メンバーの歓迎会を開催いたしました！ 歓迎会の内容をまとめましたので、みなさまに ラク ス社内の雰囲気が伝われば幸いです。 交流の様子 まずは自己紹介から行いました、名前と顔を覚えていただくのは重要です。 今回は、普段のビアバッシュで用意しているものよりも、豪華な食事をご用意させていただきました！ 参加された方に伺ったところ、みなさんご満足いただけたようで何よりです。 普段はなかなか話す機会のない、先輩や管理職の方ともこうして話す機会を設けることができるのが、歓迎会のよいところです。 新卒の方も積極的に話しかけています。 ベトナム のメンバーの方はすっかり日本のメンバーとも打ち解けられようで、こうして記念撮影も行っておられました。 アイスブレイク：ペーパータワー 会の終わりごろには、アイスブレイク（Ice break）として ペーパータワー というゲームを行いました！ 簡単に説明しますと、A4用紙20枚を使って最も高いタワーを作ったチームが勝利するというゲームです。 では、ゲームの様子を写真とともにご覧ください。 ルール紹介 今回は以下のようなルールでゲームを実施いたしました。 1チーム4～5名で行う 2回ゲームを行い、それぞれで勝利チームを決定する 作戦を検討する時間は5分、実際にタワーを組み立てる時間も5分とする 利用して良いのは、A4用紙20枚および紙テープ1m分のみとする ↓ルールはこちらのサイトを参考にさせていただきました heart-quake.com ↓ルール紹介の様子、彼の厳正な審査により各チームの勝敗が決まります 作戦タイム ↓あるチームの作戦会議の様子、このプランニングにより作業がスムーズに行えるか決まります ↓別のチームの様子、紙を片手に作戦会議中です ↓ ベトナム メンバーの方々は1チームとして集まっていただきました 続いて実際の組み立ての様子といきたかったのですが、残念なことに撮影担当者もゲームに参加していたため、組み立て時の写真はありませんでした… そのため、結果発表の様子に移りたいと思います。 結果発表 ↓計測の様子、タワーが倒れないようみなさん必死です ↓中には予想外の組み立て方をされたチームも！ 肝心の結果はどうなったかというと、なんと 2回とも ベトナム メンバーチームの勝利 でした！！ ↓成果物と一緒に記念撮影、みなさんおめでとうございます！ おわりに というところで、今回はここまでとさせていただきます。 この記事を通して、みなさまに ラク スという会社の雰囲気を伝えることができたのであれば幸いです。 今回は私もイベント開催を担当したのですが、本当に楽しい歓迎会を開催することができて良かったです。 また、新人や ベトナム の方だけでなく、私たちも普段あまり話す機会のない方とお話しできたことも良かったと思いました。 最後になりますが、新卒の方にはこれからの活躍を、 ベトナム の方には日本で貴重な経験が得られるよう、心から祈っております。

こんにちは。開発エンジニアのamdaba_sk（ ペンネ ーム未定）です。 前回の冒頭で、ちょろっと以下のように書きました。 「OWASP ZAPについて調べてみた」という記事を書きました。 単体テスト 中にこっそり使ってみようかと思っていたのですが、手元の環境ではポート待ち受けでエラーが出てしまって放置しています……。 この件について、実はポート番号を選べばローカルプロキシとして使えそうだということがわかったのでそのことで続報を、と思ったのですが。 いいタイミングでまたもあの人が目立ってくれましたね！ 2018.kphpug.jp tech-blog.rakus.co.jp 先日開催された PHP カンファレンス関西 2018 に ラク スのエンジニアが登壇しました。我らが坂田くんがそのうちの一人として参加しています。 当日は私も見に行きました。開始前のえらく緊張してそわそわしている姿と、発表中の堂々と話す姿のギャップが激しかったのがすごく印象的でした。 というわけで、このブログへの次の投稿もこれをネタにするしかあるまいと思った次第です。例によって雑談に見せかけてまた坂田くんにインタビューしてみましたので、その時の話を今回は書こうと思います。 （※本人了承済み。ただし写真は気恥ずかしいのでやっぱりNGだそうです。ほんともう今さらな感じもしますが） なおイベントそのものと、弊社がこのイベントに公式に参加することになった経緯などについてはリンク先をご覧ください。 カフェスペースにて PHPカンファレンス 関西の開催された翌週、私はいい感じに話を聞けるタイミングを見計らっていました。坂田くんは何やら忙しそうで、なかなか昼食もいっしょに行けない様子。無理に時間を作ってもらうのも悪いのでどうしたものかと思っていたところ、ちょっとした休憩でも取るつもりなのかコップを持って執務室を出ていく坂田くんの姿が。私はチャンスとばかりに後を追いました。 ペンネ ーム未定 （以後 ペン未 ）「というわけでお話をしましょう」 坂田くん （以後 坂田 ）「何が『というわけ』なんだ……。ていうかそのメモ紙とペンは何？ またブログのネタにされるやつ？」 ペン未 「ちっ、君のような勘のいいガキは……」 坂田 「嫌いだというなら無理にお話しなくてもいいのだけど」 ペン未 「いやいや好きだから。もうめっちゃ好き。察しがよくて助かるわ～」 スピーカーディナーのこと ペン未 「前日にも業務後に何か行ってたよね？」 坂田 「スピーカーディナーっていうのに参加してた。当日はお互い発表があって話す時間が取れないからだと」 ペン未 「飲み会自体あんまり好きじゃないって言ってたのによく行く気になったね」 坂田 「せっかくの機会だからと思って。社外の人と交流する機会もあんまりないし」 ペン未 「どんな感じだった？」 坂田 「ネットの知り合いとのオフ会って感じだった。みんな私服だし、『もしかして、○○さんですか？』みたいな声のかけ方とかも。全員集まるまで適当にだべってる感じもまさしく」 ペン未 「へー。その場にいた人はみんなお互い初対面だった感じ？」 坂田 「いや、けっこう知り合いって感じの人も多かったかな。毎回登壇してるような人とか、現運営、元運営みたいな人達はお互いに知り合いで、むしろ私みたいな新参者の方が珍しかったような印象。それもあってちょっと話に加わりづらい感じがした」 坂田 「でも実行委員長の人は席も近かったしけっこう話せた。そういえば今回はスポンサーの応募も例年よりすごく多かったみたいで、しかも初めてスポンサーするってところも多かったらしい。それで問合せがいっぱい来て対応が大変だったとか」 ペン未 「そうなんだ。それはちょっと申し訳なかった感じがあるね……」 当日のこと ペン未 「発表直前はめっちゃそわそわしてたよね。坂田くんでも緊張するんだって思った」 坂田 「私だって緊張ぐらいします。ビアバッシュの発表のときだって緊張してるんですが」 ペン未 「全然そうは見えない」 坂田 「それ他の人にも言われたんだけど。なんでそう見られているのか……」 ペン未 「それは君がそういう振る舞いをしているからとしか言いようがないけど。でもあの時はことさら緊張してたってことでしょう？」 坂田 「まあね。発表が始まってからは多少落ち着くんだけど、発表前の5分間は結構つらかった」 ペン未 「発表前にパソ コントラ ブルもあったしね」 坂田 「そうそれ。私の持ってる唯一のノートパソコンが元XPで現 Linux 搭載の古いやつで、もともと使えるかどうかわからないねって話はしてたのだけど。 VGA のケーブルがあったから自分のパソコン繋げられると思っのに、いざ繋げてからパソコン起動させてみるとなぜかログインできなくなっているという。わけが分からなかったし時間も無かったから急遽パソコンを貸してもらった」 ペン未 「あせってパスワードミスってただけでは」 坂田 「間違ってはいなかったと思うのだけどなあ。後で VGA を外してから同じようにログイン試行してみたら普通に入れたし」 ペン未 「まあでも発表始まったら急にスイッチ入った感じだったよね。なんか練習よりも一段と分かりやすくなってたような気がするし。何か準備してた？」 坂田 「別に直前に特別なことはしてない。スライド見返すとかその程度で」 ペン未 「それで話せるとかすごいな。時間もほぼぴったりだったよね」 坂田 「時間は、実はちょっと遅いかもって思ってた。一回時計を見たのだけどいつ始まっていつ終わらないといけないのかわからくなって、もういいやって」 ペン未 「まじで。それめっちゃ不安じゃない？」 坂田 「今思うと不安なんだけど、発表中はなぜか時間のこと忘れてられたんだよね。不思議なことに」 坂田 「でも発表中に出ていっちゃた人がいたのは残念だったなあ」 ペン未 「あー、そういえばいたね。でもそれって仕方ないんじゃない？」 坂田 「そうかもしれないけど。でも今思い返してみると、確かに『Laravelの良かったところ』のセクションは確かに聞いててつまらないかもとも思うんだよね。Laravelの宣伝してるだけみたいな感じになってて。といってもどう変えればいいのかよくわからないのだけど」 ペン未 「まあそれは今後の課題ということで。また同じような発表をする機会があればその時考え直してみるといいですね」 坂田 「そうですね。そう頻繁に同じような発表をすることになっても困るけど」 そして仕事はつづく まだまだ話は引き出せそうでしたが、息抜きには十分なほどに話をしていました。 私たちは話をするうちに飲み干してしまったお茶を入れなおし、自席に戻りました。 これからは会社としても PHPカンファレンス のようなイベント、勉強会への参加を推進していくとのことなので、坂田くんに活躍してもらう機会が今後もたびたびあるのでしょう。 私は心の中でエールを送りつつ、先ほど聞いた話をブログにまとめるべくキーボードをたたくのでした。

@kawanamiyuu です。以前の 投稿 でお知らせしましたとおり、先日開催された PHP カンファレンス関西 2018 に ラク スのエンジニアが登壇しました。 また、 ラク スはシルバースポンサーとしてイベントに協賛いたしました。 イベント概要 日時 : 2018 年 7 月 14 日 (土) 会場 : グランフロント大阪 公式 HP : https://2018.kphpug.jp/ 2018.kphpug.jp 登壇 チャットディーラーの高速開発を支える Laravel（30分セッション） speakerdeck.com （本人コメント） PHP カンファレンスに限らず技術系のイベント初参加でした。最終的に私が登壇することになりましたが、会社としての参加が決まってからネタ出し、アウトライン作成、資料作成、発表練習等、最後までチームで準備を進めました。当日もちろん緊張はしましたが、不安を感じずに発表ができたのはチームのみんなのおかげです。 また発表以外の時間では聞く側としても楽しめましたし、勉強にもなりました。これからはもっと積極的にこういった社外のイベントや勉強会に参加してみようかなと思い始めています。 mixed 型なんてけしからんと社内チャットでつぶやいたら炎上した（ライトニング トーク ） 私、 @kawanamiyuu も実はライトニング トーク が採択されましたので話してきました。 speakerdeck.com （本人コメント） 今回がカンファレンスでの初 LT 体験でした。ネタはけっこう前から温めていて、社内のビアバッシュとかで話そうかと思っていましたが、今回弊社のエンジニアが 30 分セッションにも登壇するし、LT もやったれ！と思って応募したら採択されて、ドキドキしたけどとても楽しめました。 イベント 2 日前にオフィスで行った公開発表練習では 1 分半も時間が余ってしまい焦りましたが、自主練の結果、本番では時間ちょうどくらいで終われて安心しました。ほんとうはドラを鳴らされてみたかったです (^m^) 所感 今回、 ラク スにとって初めての技術イベントへの協賛および登壇でした *1 。いろいろ勝手が分からず、ちゃんとイベント当日まで漕ぎ着けることができるか不安でしたが、担当サービスを横断した登壇推進チームで協力して資料作成や発表練習を行い、当日、自分の会社のエンジニアが目の前で発表している姿を見てとても嬉しくなりました。 今後も継続して技術イベントに登壇していけるよう、また、コミュニティに貢献していけるよう、開発組織のレベルアップやエンジニアリング文化の 醸造 に取り組んでいきたいと思います。 *1 : これまでも弊社のエンジニアがプライベートで技術イベントで登壇することはありましたが、開発部の公式な取り組みとして登壇や協賛を行ったのは初めてでした。

Google API とは、 Google が提供するのサービスやプラットフォームを扱える API です。 これらの API を使いこなすことで、 Google のサービスを自身のアプリケーションへ組み込み、様々なことを実現できます。 ここでは、 Gmail を扱う API と、GoogleDriveを扱う API を PHP アプリケーションから利用する例に紹介します。 （内容は2018年7月現在の情報です。） この記事の内容 今回は、 Google API のガイドに記載されているQuickstartを用いて、 OAuth認証 を行い API を実行します。 *1 概要は以下の図のような感じです。 この記事では、「その1：プロジェクトの用意」で、 Google Cloud プラットフォームにプロジェクトを用意し、 「その2：認証情報の作成」にて、OAuthに必要な認証情報ファイルの作成、 「その3： API を叩く」でサンプルプログラムを用いて上記図の①～④に示す認証処理と API の実行を行います。 少し内容が長くなってしまったので、目次を見て必要な情報のところをご覧ください。 この記事の内容 その0：Googleアカウントの用意 その1：プロジェクトの用意 プロジェクトを作成する プロジェクトで使用するAPIを指定する その2：認証情報の作成 OAuth 2.0 クライアント ID を作成する OAuth 2.0 同意画面を設定する その3：APIを叩く Google Client Libraryのインストール 認証情報をダウンロード サンプルプログラムの作成 APIクライアントオブジェクトの取得 利用するAPIのサービスオブジェクト作成 サンプルプログラムの実行 （余談ですが、恥ずかしながら、この記事を書くまで、私は「OAuth」を、他のシステムで認証するから「Other Auth」の略だと思っていました。正しくは「Open Auth」ですね。。。） その0： Google アカウントの用意 言わずもがな、 API を利用して操作する Google アカウントが必要です。 詳しい方法は割愛。作成したら、ログインしてください。 その1：プロジェクトの用意 API を利用するため、 Google アカウントに紐づいたプロジェクトを作成する必要があります。 プロジェクトを作成する 使用する Google アカウントにログインしたら、 Google Cloud プラットフォーム にアクセスしましょう。 左上の ハンバーガ ーメニューから、「IAMと管理 > リソースの管理」を選択します。 リソースの管理画面に、「プロジェクトを作成」リンクがあるので、クリックします。 その後の画面でプロジェクト名を入力し、「作成」します。 これでプロジェクトが作成できました。 （少し画面表示に時間がかかることがあります。） プロジェクトで使用する API を指定する 次に、作成したプロジェクトで使用する API を指定します。 Google Cloudプラットフォームの画面上部から、先ほど作成したプロジェクトを選択した状態で、「 API とサービス > ライブラリ」を選択します。 ここでは、使用することができるGoogleAPIライブラリを選ぶことがあります。 どの API も面白そうですが、とりあえず今回は「 Gmail 」と「GoogleDrive」を利用するので、まず、「 Gmail API 」を探し、「有効にする」を選択します。 これで、このプロジェクトで Gmail API を有効にすることができます。 なお、この画面からは Gmail API のガイドやリファレンスなどのドキュメントを閲覧することができます。 同様に、「 Google Drive API 」を、 API ライブラリから探し、有効にします。 これで、使いたい API を有効にしたプロジェクトが作成できます。 その2：認証情報の作成 さて、プロジェクトは準備できましたが、 API を叩くにあたり、認証が必要です。 次は認証情報を作成し、自分が作成するアプリケーションからのリク エス トのみを受け付けるようにしましょう。 Google Cloudプラットフォームの画面上部から、先ほど作成したプロジェクトを選択した状態で、「 API とサービス > 認証情報」を選択します。 その後、「認証情報を作成」から「OAuth クライアント ID の作成」をクリックします。 OAuth 2.0 クライアント ID を作成する OAuthの設定をするにあたり、まずは API を叩くアプリケーションの種類を指定します。 今回は、「その他」を選んでください。 API ガイドに載っている「Quickstart」を使うためには、「その他」を選ぶ必要があります。 選択したら、クライアントの識別名を入力し、作成します。 OAuth 2.0 同意画面を設定する 次に、 OAuth 2.0 同意画面の設定を行うため、 「認証情報を作成」から「OAuth 2.0 同意画面」を選択します。 OAuth 2.0 同意画面とは、設定している API によってユーザのデータへアクセスするときに、表示される画面で、データへのアクセス前に認証を行う画面のことです。 この画面で認証を行うため、メールアドレスと、表示する任意のアプリ名を指定します。 ここで指定したアプリ名は、以下のように認証画面にて表示されます。 設定出来たら「次へ」ボタンを押下します。 これで認証情報の作成が完了しました。 ハンバーガ ーメニューから、「 API とサービス > 認証情報」を選択すると、認証情報が作成できていることが確認できます。 その3： API を叩く 次に、アプリケーションから Google API の認証を行い実際に API を実行します。 ここからは Gmail API の公式ドキュメントを参考にしながら進めましょう。 「 API とサービス > ライブラリ」から「 Gmail API 」を探し出し、「 チュートリアル とドキュメント」の「Learn more」をクリックし、公式ドキュメントを表示します。 表示したら、「ガイド」タブの「Quickstarts」から、使用する言語を選択します。 今回は PHP で説明します。他の言語で API を扱いたい場合は、対象の言語を選択して、頑張ってください。（←丸投げ） PHP のQuickstartでは、Step1～Step4の手順が紹介されていますが、Step1の API を有効化する手順はもう完了しているので、Step2から行います。 Google Client Libraryのインストール QuickstartのStep2です。 Google の API を使用するために、 Google Client Libraryをインストールする必要があります。 PHP の場合、composerを用いることで簡単にインストールできます。 composer require google/apiclient:^2.0 認証情報をダウンロード 先ほど作成したOAuth2.0クライアントの認証情報が記載された JSON ファイルをダウンロードします。 Google Cloud プラットフォームのメニューから、「 API とサービス > 認証情報」を選択し、先ほど作成したOAuth2.0クライアントのダウンロードアイコンをクリックすることで、ダウンロードできます。 ダウンロードしたクライアントの認証情報ファイルは、次のサンプルプログラム実行で使います。 サンプルプログラムの作成 QuickstartのStep3です。 quickstart.php という名前で以下のコードを保存します。 <?php require __DIR__ . '/vendor/autoload.php' ; if ( php_sapi_name () != 'cli' ) { throw new Exception ( 'This application must be run on the command line.' ) ; } /** * 指定した権限が付与されたAPIクライアントを返す * @return 権限が付与されたGoogle_Clientオブジェクト */ function getClient () { $ client = new Google_Client () ; $ client -> setApplicationName ( 'Gmail API PHP Quickstart' ) ; $ client -> setScopes ( Google_Service_Gmail :: GMAIL_READONLY ) ; // ※1：スコープの設定 $ client -> setAuthConfig ( 'credentials.json' ) ; // 取得したJSONファイルのパス $ client -> setAccessType ( 'offline' ) ; // クライアント証明書ファイルが存在しない場合（初回実行時）は // 認証情報JSONファイルを用いて取得する。 // 存在する場合（2回目以降の実行時）は、クライアント証明書を読み込む。 $ credentialsPath = 'token.json' ; // クライアント証明書ファイルのパス if ( file_exists ( $ credentialsPath )) { $ accessToken = json_decode ( file_get_contents ( $ credentialsPath ) , true ) ; } else { // ユーザからの認証を行う $ authUrl = $ client -> createAuthUrl () ; printf ( "Open the following link in your browser: \n %s \n " , $ authUrl ) ; print 'Enter verification code: ' ; $ authCode = trim ( fgets ( STDIN )) ; // 認証コードをアクセストークンに変換する $ accessToken = $ client -> fetchAccessTokenWithAuthCode ( $ authCode ) ; // クライアント証明書をファイルに保存する if ( ! file_exists ( dirname ( $ credentialsPath ))) { mkdir ( dirname ( $ credentialsPath ) , 0700 , true ) ; } file_put_contents ( $ credentialsPath , json_encode ( $ accessToken )) ; printf ( "Credentials saved to %s \n " , $ credentialsPath ) ; } $ client -> setAccessToken ( $ accessToken ) ; // クライアント証明書が有効期限切れの場合は更新し、ファイルへ保存しなおす if ( $ client -> isAccessTokenExpired ()) { $ client -> fetchAccessTokenWithRefreshToken ( $ client -> getRefreshToken ()) ; file_put_contents ( $ credentialsPath , json_encode ( $ client -> getAccessToken ())) ; } return $ client ; } /** * メイン処理 */ // APIクライアントを作成し、サービスオブジェクトを作成する $ client = getClient () ; $ service = new Google_Service_Gmail ( $ client ) ; // 使用するAPIごとのサービスオブジェクトを作成 // Print the labels in the user's account. $ user = 'me' ; $ results = $ service -> users_labels -> listUsersLabels ( $ user ) ; if ( count ( $ results -> getLabels ()) == 0 ) { print "No labels found. \n " ; } else { print "Labels: \n " ; foreach ( $ results -> getLabels () as $ label ) { printf ( "- %s \n " , $ label -> getName ()) ; } } 上記コードでは、大きく分けて、以下の処理を行っており、一部 API の実行目的によって変更する必要があります。 API クライアントオブジェクトの取得 クライアント証明書の取得と更新 API クライアントオブジェクトの作成 利用する API のサービスオブジェクト作成 API クライアントオブジェクトの取得 API を実行するクライアントのオブジェクトを作成します。 作成時には、先ほどダウンロードした、クライアントの認証情報を利用して、クライアント証明書を取得し、ファイルに保存します。 クライアント証明書には、特別な設定をしない限り利用期限があり、利用期限が過ぎていた場合は更新されます。 また、クライアントオブジェクトを作成する際に、「スコープ」を指定します。 「スコープ」は、そのクライアントが、 API を用いて「どこまでの操作が実行できるか」を指定するものです。（コード内コメント※1） スコープは API を使って何を実行したいのかによるため、場合によって書き換える必要があります。 スコープは各サービスオブジェクトの定数を指定するか、 API ガイドにある URI を指定することで、設定できます。 Gmailのサービスオブジェクト定数一覧 URI一覧 たとえば、 Gmail でメールを送信したい場合は以下の通りに書き換えます。 $client = new Google_Client(); $client- > setScopes(Google_Service_Gmail::GMAIL_SEND); Google Drive でファイルをアップロードしたい場合はこんな感じ。 $client = new Google_Client(); $client- > setScopes(Google_Service_Drive::DRIVE); 複数のスコープを指定する場合は、定数を配列に格納することで可能です。 $client = new Google_Client(); $scopeList = array(Google_Service_Gmail::GMAIL_SEND, Google_Service_Drive::DRIVE); $client- > setScopes($scopeList); 利用する API のサービスオブジェクト作成 取得したクライアントオブジェクトを利用して、各サービスの API を扱うためのサービスオブジェクトを作成します。 ここは各サービスごとに異なるため、ドキュメントをご覧ください。 作成したサービスオブジェクトを使うことで、そのサービスの API リク エス トが可能になります。 サンプルプログラムの実行 作成したサンプルプログラムを コマンドライン から実行します。 $ php quickstart.php 実行すると、URLが表示され、入力待ちになりますので、表示されたURLへブラウザからアクセスしてください。 アクセスすると、認証情報の作成時に設定したOAuth 2.0の同意画面が表示されますので、画面に従って実行を許可してください。アクセス トーク ンが表示されるので、 コマンドライン にコピペすることで、クライアント証明書を取得することができます。 次回実行時からは、この作業で取得したクライアント証明書をもとに認証を行うため、同意画面での実行許可は不要になります。 また、サンプルプログラムは Gmail の API ガイドから取得しましたが、この認証で今回作ったプロジェクトへの認証ができるので、他 API も利用可能になります。 これで API を実行する準備はできました。 あとは各サービスオブジェクトのメソッドを使って Gmail を送ったり、 Google Drive を操作したりできます。 例として、 Gmail でメールを送るときのコードを記載します。 *2 /** * Gmailを送信する */ public function sendGmail($client) { $data = ""; $data .= "To:xxxx @xxx .xxx.xx\n"; $data .= "Subject: メールたいとる\n"; $data .= "\n"; // ヘッダーと本文を区切る空行 $data .= "本文"; $data = base64_encode($data); //base64エンコード $service = new Google_Service_Gmail($client); $msg = new Google_Service_Gmail_Message(); $msg- > setRaw($data); $result = $service- > users_messages- > send('me', $msg); return $result; } エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 *1 : https://developers.google.com/gmail/api/quickstart/php?hl=ja *2 : https://sepg.biz/2018/03/23/post-564/

はじめに ラク スエンジニアのstrongWhiteです。今回はSwiftのextensionとprotocolについて書きます。 私がSwiftを勉強し始めたころは、この2つの概念がよくわかっていませんでした。 2つとも似ているようで全く違うので、両者について簡単にまとめてみます。 extensionとは extension（拡張）とは、特定のクラスや構造体、データ型など、名前はそのままにプロパティやメソッドを追加する機能です。 Java でいうと「継承」と似ています。 Java の「継承」はクラスのプロパティやメソッドを引き継いだ別名のクラスを作るのに対し、Swiftの「拡張」は名前はそのままになるのが特徴です。 extensionの使い方 それではextensionを使った簡単なプログラムを書いてみましょう。今回は データ型 の拡張を行ってみます。 extensionを使って、Swiftに標準で備わっているデータ型（例．Int、String）を拡張してみます。 extension String { func isLongString () -> Bool { if self .count <= 20 { return false } return true } } let text = "RAKUS Developers Blog" print(text.isLongString()) // 実行結果：true サンプルプログラムでは、String型を拡張し、文字数が20文字以上かどうかを判別する簡単な関数を定義しています。 このように、extensionを使えば、変数の値の比較や加工処理を、既存のデータ型にメソッドを追加することで実現できます。 私は今まで「データ型の定義を拡張できる」ような言語に出会ったことがなかったので、この辺りはとても新鮮な感覚でした。 protocolとは お次はprotocolです。protocolとは、クラスの挙動や振る舞いを決めたものです。クラスでは、プロパティや挙動を細かく記述していきますが、protocolでは、インタフェースのみを定義します。実際の挙動はprotocolを採用するクラス側で記述します。 protocolの使い方 ではprotocolを使った簡単なプログラムを書いてみます。今回は 列挙型 にprotocolを適用してみます。 protocol BaseProtocol { var type : String { get } } enum Blood : BaseProtocol { case AB case A case B case O var type : String { switch self { case .AB : return "AB型" case .A : return "A型" case .B : return "B型" case .O : return "O型" } } } print( "あなたの血液型は" + Blood.AB.type + "です" ) // 実行結果：あなたの血液型はAB型です サンプルプログラムでは、血液型を列挙型で定義してみました。また、ベースとなるprotocolとして、 BaseProtocol （そのままですが）を採用しています。 また、列挙型のほうで、 BaseProtocol に定義してある type 変数を宣言しないと コンパイル エラーになります。 最後に Swiftのextensionとprotocolについて、違いがよくわかっていなかったので勉強してみました。 それぞれ身近な Java を例に挙げて、extension→継承、protocol→インタフェースであると解説しましたが、Swiftを知らない人でも少しはイメージができたのではないでしょうか。 皆さんもこの辺りを勉強してみるとよりSwiftが面白いと感じるかと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

id:radiocat です。中学のとき美術の先生に美術科への進学を勧められたことがありますが、それ以降は描いた絵を褒められたことがありません（後述）。 アジャイル な開発チーム以外でも近年は「ふりかえり」を行っているチームは多いのではないでしょうか？ 従来型の 開発プロセス では「反省会」とも呼ばれますが、これまでやってきた事を振り返って未来に向けた改善アクションを見つけるという点ではどちらも同じです。そして、そのような改善に向けて振り返る会議の前にまず行うのが「チェックイン」です。 チェックインとは？ ふりかえりの「場を設定する」アクティビティの1つで、『 アジャイル レトロスペクティブズ』という書籍で紹介されています。 アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き 作者: Esther Derby , Diana Larsen オーム社 Amazon 目的 この書籍の中で、チェックインの目的は以下のように説明されています。 余計なことを考えずに、レトロスペクティブに集中してもらう。レトロスペクティブから何を得たいのかを明確にしてもらう。 ふりかえりの場に意識を集中してもらい、チームでどういう議論がしたいのかを発信して参加者の目線を合わせるための作業なのです。 やりかた 簡単な質問を1つする メンバーは順番に質問に答える たったこれだけです。例えば、ふりかえりの ファシリテーター が「今の気持ちを一言で答えてください」という質問をして、メンバーが「嬉しい」とか「悲しい」などと順番に答えます。 「場を設定する」ということ チェックインのように「場を設定する」ことについて『 アジャイル レトロスペクティブズ』の中で次のように説明されています。 部屋にいる全員に口を開いてもらう。最初に喋らなかったら、ずっと何も喋らなくてもいいという暗黙の了解を得たと思ってしまう。レトロスペクティブの肝はグループで考え、一緒に学んでいくことなので、全員参加が不可欠である。 たった一言ですが、質問に答えてもらうだけで全員に参加意識を持ってもらえます。また、答えた内容によってその人がどういう気持ちで会議に臨んでいるのかを知ることができます。例えば「嬉しいと感じているのは自分だけかもしれない」と思うと発言がしにくいかもしれませんが、全員の気持ちを知っていればそのような不安が減って発言のハードルが下がります。 つまり全員が一言ずつ喋ることで、その人自身の発言のハードルを下げるとともに、周りのメンバーの発言のハードルを下げることにも繋がるのです。 場を設定するアクティビティ このような場を設定するアクティビティには様々なやりかたがあります。我々のチームでもいくつか実践してみたので、それらの一部を紹介します。 One Word 今の気持ちを一言で表現してもらいます。実際にやってみた結果は次のような回答でした。 一言では言い表わせれなかったメンバーもいますが、そういう気持ちなんだなと受け止めます。逆に一言だと意図がわからないものもあります。例えば「早い」は開発スピードのことなのか、作った機能のことなのかわかりません。ふりかえりの目線を合わせるためにも、必要に応じてどういう意味なのか聞いてみても良いでしょう。ただし、まだ場を設定するタイミングなので議論に発展するようならいったん止めてあとで議論するようにします。 漢字1文字 今の気持ちを漢字1文字で表現してもらいます。このケースでは順番に回答していくうちに、他のメンバーと被らないようにと、色々考えて回答するようになって後半のメンバーが苦戦するというせめぎ合いも起こりました。 自分の気持ちに適した漢字を選ぼうとすると意外と難しく、色々考えることでふりかえりに向けて集中できる効果もあります。One Wordと同じで意図がわからない漢字の場合はなぜその漢字なのか聞いてみても良いでしょう。 Happiness Rader 今の気持ちを顔文字で表現してもらいます。この時はどんな顔かを聞いて ファシリテーター がホワイトボードに書きました。 参加者に自分で書いてもらっても良いですが、「どんな顔ですか？」と聞くことでどんな気持ちなのかがわかります。ただ、言葉で表現された気持ちを絵で表さなければならないので、 ファシリテーター の絵心も場の設定に影響しそうです… 絵の得意なメンバーが見かねて代わりに書いてくれました。絵心がある人が描くほうが、参加者も今の気持ちを言葉で表現しやすいかもしれません… 3 dots 今の気持ちを3段階のドットで表現してもらいます。短時間かつシンプルに表現できるのが最大のメリットです。 顔文字と違って最速で表現できますが、なんとなく物足りなさはあります。3種類しかないので複雑な気持ちを表すことはできません。チームが複雑な課題をたくさん抱えているような場合は、みんな1ドットという回答でそれぞれが抱えている気持ちの違いはわからないという結果になる可能性があります。 Good & News 良かったことと新しい気づきを共有してもらいます。 前向きな意見を集めるような場の設定に有効です。ふりかえりで課題がたくさん出ることが予想される場合にあえて最初に前向きな意見を求めてみるという使い方もあります。気付きの共有はやや時間が長くなりがちなので時間が少ない場合には向いていないかもしれません。 希望と懸念 ふりかえりに対する希望と懸念事項を共有してもらいます。 参加者それぞれがふりかえりをどういう場にしたいかが比較的わかりやすく表現されます。ただ、これも少し時間がかかるアクティビティです。 以降は我々のチームではまだ試したことはありませんが、書籍等で紹介されているものです。 DPA （Design the Partnership Alliance） 決め事を作ります（どんな雰囲気で話すかなど）。 事前にその場の雰囲気をどうするかを参加者で話し合って決めるので、スムーズに議論に入れそうです。 Keep+Wakattakoto 良かったことと分かったことを共有してもらいます。 Good & Newsと似ていますが、 KPT のKをより意識した場の設定ができるかもしれません。 連想ゲーム 起きたことを一言づつ隣の人に連想ゲームします。 漢字1文字と同じで、考えることで意識を集中することができそうです。また、ゲーム感覚で場を和ませる効果もありそうです。 おわりに 我々のチームでは、これらのアクティビティの中から1つを参加したメンバーに選択してもらっています。参加者が主体的に考えたり選択してもらうことで、ふりかえりの場が設定されます。 このような場を設定するアクティビティはふりかえりだけのための手法ではありません。議論に集中するために参加者同士で意識合わせをすることが目的なので、ふりかえり以外の会議でも活用できる場面はあります。 会議の場で次のような課題を感じたことはないでしょうか？ 発言する人が少ない 自由な意見が出てこない いつも同じ人の意見でチームの方針が決まる もし、このような課題を感じたら「場を設定する」ことからはじめてみると良いかもしれません。 参考 ふりかえりワークショップ～実践＆実践～ - Speaker Deck エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに こんにちは、新卒で入って入社3年目のnorthmkyです。 いままでの投稿では yumコマンド についてや 文字コード など実業務でも役立つ基礎知識をまとめたものを書いていましたが、今回はプライベートで Google Apps Script、略称GASに触れたのでご紹介したいと思います。 題名を「5分で理解する」などと自身でいうのもなんですが巷でよくあるキャッチーで怪しい、ほんまかいな...というようなものになっておりますが、嘘ではないと思います。 ただ前提として JSの経験がある 必要あります。逆に言えば WEB界隈でJSを触ったことがある方は学習コストがほぼ0になります。本記事を読めばやりたいことはすぐ書けます。 理由としては JSと パラダイム がほぼ一緒 JSと文法がほぼ一緒 標準でついているメソッド名が直感的でわかりやすい の3点です。 ほぼ同じ思想なので、あとは特有の押さえておくべき用語と スクリプト と操作するアプリ画面の対応関係がわかれば書けるようになります。 それでは前置きはこのくらいにして紹介に入りたいと思います。 Google Apps Script(GAS)とは 「 Google の各種アプリ( Google スプレッドシート / Google ドキュメントなど)をアプリ内ではなく外から操作できるJSライクな プログラミング言語 」です。 エクセルに対する VBA の関係と一緒です 1 。 実現できることの例としては、指定時間になったら特定のセルの値を読み出して外部アプリに渡す bot であったり、 スプレッドシート だけでなく googleカレンダー にまとめてスケジュール登録したり、などなどができます。 2 色々できるのですが、本記事では読者のみなさんに馴染みがあると思われる スプレッドシート を題材にします。 早速GASを理解する GASでは操作対象のアプリをオブジェクトとして扱います。 スプレッドシート の場合、覚えるべきオブジェクトは下記3点のみです。 Spreadsheetオブジェクト Sheetオブジェクト Rangeオブジェクト アプリと スクリプト 内のオブジェクトは下図のような関係性になっています。 ウィンドウ左はおなじみの スプレッドシート 、右はGASです。 図の スクリプト は「特定のセル範囲に値を入れる」処理をします。 実行すると下記のようになります。 好き、という文字列が指定したセル範囲(= range )に格納されました。 どうでしょうか、説明はこれだけです。 値を入れるというだけの処理の紹介ですが、これだけでもう スプレッドシート を自分の好きなように操れる気がしないでしょうか。 特別な文法を覚えたりする必要もありません。 ここでは記載していませんが、分岐/繰り返しなど基本構文はもちろんありますし、標準メソッドもあるので安心です。 「いやメソッドいちいち調べる感じじゃ...?」と思われた方、安心してください。 こちらの標準エディタは補完機能付きなので、適当にメソッド名を打っても実現したいことができるメソッドを見つけられる確率が高いです。メソッド名がわかりやすい...素晴らしい... おわりに GASの超入門として、 スプレッドシート に対して処理を行うことを通して、GASをどのように書けるかをお伝えしました。 今回はお話しませんでしたが、webAPIを叩く機能も標準でありますし、 google 本家、またそうでない人によるたくさんのGAS用ライブラリも github で公開されています。 ですので twitter /slackBotも 開発環境構築なしで Google アカウントがあれば誰でも作成できる という敷居の低さも魅力的なGAS、皆さんも試してみませんか？ 題名を裏切らない内容になっていれば幸いです。 付録: スクリプト 作成〜実行の簡単な流れ スクリプト 作成方法 ツール をクリック スクリプトエディタ をクリック これで スクリプト が立ち上がります。 実行方法 Ctrl + S ... スクリプト 保存 Ctrl + R ... スクリプト 実行 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com やや過大表現です。厳密にはGASは、エクセルに対する VBA のような、どこかのbookに紐付いて動く「Container Bound Script」と紐付かず単独で動く「Standalone Script」の2種類があるので厳密な表現ではないです。本記事では「Container Bound Script」のみを扱いますのでこのように表記しました。 ↩ ここで私は基礎を学びました。他にもいろいろな実例を平易に書いてありとてもわかりやすいです。 https://tonari-it.com/google-apps-script-manual/#toc2 ↩

こんにちは。west-cです。 早いもので 1エントリ目の記事 から1年が経とうとしており、自チームにも今年の新卒メンバーが配属されました。 そこで今回も、今年入社の新米エンジニアの方を対象に、個人的に業務でよく使うツールを紹介したいと思います。 私自身もまだ4年目で新米に属する部類ではありますが、少しでも業務効率化に寄与できれば幸いです。 WinMerge WinMerge 日本語版 テキストファイルの差分比較・マージを行える有名なソフトウェアです。 修正前後の差分チェックを行い、意図通りの修正となっているかを確認するために利用しています。 目diff *1 ・目 grep は特殊な訓練を受けた上で実施しないと思わぬ事故に繋がります。正確な結果を得るためにツールを活用しましょう。 Sublime Text Sublime Text - A sophisticated text editor for code, markup and prose ソースコード エディタです。 コーディングは IDE を利用しますが、ちょっとした スクリプト を見たり 正規表現 を用いた検索・置換をサクッと行いたい場合に利用しています。 Visual Studio Code や Atom などのエディタでも同様のことは行えますが、動作が一番軽快なため私はこのエディタの利用頻度が一番多いです。 指定フォルダ下の全ファイル文字列検索（ grep のようなもの）も行えます。 Awesome Screenshot Awesome screenshot ブラウザの画面キャプチャが行えます。 撮影範囲の指定や文字挿入などある程度の画像編集も行えるため、そのまま Mattermost *2 や Redmine に貼り付けて利用しています。 ScreenToGif （↑実際に動画撮影をした様子） ScreenToGif - Record your screen, edit and save as a Gif or video 画面を動画撮影し、GIF形式で保存できます。 自チームでは発見したバグを Redmine のチケットで管理しています。 バグ報告時に再現手順を文章で説明するのが難しい場合には、その手順を撮影したGIF画像もチケットに添付しています。 動画だと操作手順が分かりやすく認識齟齬も起きにくいため、チーム内でもよく利用されています。 Boostnote Boostnote | Boost Happiness, Productivity, and Creativity. Markdown 形式でメモを取ることができます。 日々のタスクやちょっとしたtipsなど、基本的にここで一元化するようにしています（手帳に取ったメモもこちらに清書しています）。 タグ付けやフォルダ分け・検索も行えるため過去のメモも追いやすく、「メモした記憶はあるけれど、どこに書いたか忘れた」という事態がほぼ無くなりました。 Postman Postman | API Development Environment WebAPIに対して GUI で直感的にリク エス トを送信できます。 少し API のテストを行いたい場合に curl コマンドを打つことなくサクッと実施できるので重宝しています。 自分で作成したリク エス ト情報をインポートすれば、プログラムに詳しくない方でも簡単に API のテストやお試しができる点も魅力です。 おわりに これは個人的意見ですが、 面倒なこと・正確さが求められることはコンピュータに任せる という意識はエンジニアとして重要だと思っています。 （「 プログラマ の三大美徳」という有名な言葉にも繋がると思います） ぜひ非効率だと思う部分があればツールの導入等で効率化を試みてください。 そして、場合によっては自分で作成してみるとさらに良いと思いす。 自分が欲しかったものを自分の手で作ることができるのは、エンジニアならではの醍醐味だと思いますよ！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com *1 : Linux コマンドの diff 相応の差分比較を目視で行う特殊技能のこと。目 grep も同様。 *2 : チャットツールとして有名な Slack に似たツール。自チームではチャットツールに Mattermost を導入しています。

はじめに 新卒2年目エンジニアのkasuke18と申します。 今回はLINEでメッセージを送信することで Twitter 検索を行うLINE Bot を作成してみましたので、作成の流れや実際のコードを記載します。使用言語は PHP です。 もくじ はじめに 構成 必要なもの 実装例 メッセージの取得 Twitterで検索 検索結果のパース LINEに送信 おわりに 参考文献 構成 今回はLINEの API と Twitter の API を利用します。また、LINEで送信されたテキストに対して処理を行うWebhook スクリプト を設置する SSL 対応のサーバが必要なため、HEROKUを使用しています。 イメージとしては以下のようになります。 必要なもの LINE Messaging API Twitter REST API HEROKU Twitter 連携パッケージ mpyw/cowitter API を利用するまでの流れについては、LINE Messaging API は 公式サイト に詳しい説明が記載されています。 また、 Twitter REST API は公式サイト上のどこに記載されているか発見できませんでしたが、検索すればそのあたりのことが書かれている導入記事が数多くあるので省略します。 HEROKUの使用方法については当ブログに記事がありますので、ぜひそちらをご参照ください。 実装例 メッセージの取得 まずはLINEから送信されたメッセージテキストを受け取る部分です。 LINE Platformから送信されるのは JSON で、以下のような形式となっています。 { " events ": [ { " type ": " message ", " replyToken ": " ********** ", " source ": { " groupId ": " ********** ", " userId ": " ********** ", " type ": " group " } , " timestamp ": 1529822351422 , " message ": { " type ": " text ", " id ": " ********** ", " text ": " 送信メッセージ " } } ] } 上記の JSON をもとにパースして送信されたテキスト情報を取得するコードが以下となります。送信される形式が JSON なので、 $_POST ではデータが取得できないことに注意が必要です。 <?php $ json = json_decode ( file_get_contents ( 'php://input' ) , true ) ; $ message = $ json [ 'events' ][ 0 ][ 'message' ] ; $ messageText = $ message [ 'text' ] ; Twitter で検索 次に受信したテキストをキーワードとして、 Twitter で検索します。 Twitter の連携については自前でやってしまうのもありですが、 面倒なので Twitter 連携パッケージ mpyw/cowitter を使用しています。 <?php $ client = new Client ([ $ consumerKey , $ consumerSecret , $ twitterAccessToken , $ twitterAccessTokenSecret ]) ; $ tweetsParams = [ 'q' => $ q . ' -rt' , 'count' => '10' , 'result_type' => 'recent' , "include_entities" => true ] ; $ tweets = $ client -> get ( 'search/tweets' , $ tweetsParams ) -> statuses; $tweetsParams で検索条件を指定します。 q は検索キーワードで、検索 演算子 も利用できます。今回は リツイート を排除したいので、検索 演算子 -rt を使用しています。 count はそのまま検索結果の取得件数で今回は10件、 result_type は取得するツイートの種類で recent とすることで最新のツイートを取得します。 最後の include_entities は少し特殊で、取得したツイートオブジェクトにentitiesプロパティを含めるかどうかを指定します。entitiesプロパティとはツイート本文を拡張するエンティティで、画像や動画などの本文に付け足すための情報が格納されています。今回はツイートに付随する画像のURLを取得するために使用しています。 他にも設定可能なプロパティがありますが、今回は不要なので省略します。必要に応じて こちら をご参照ください。 検索結果のパース 検索結果から必要な情報を抜き出すときにも、 mpyw/cowitter が当然ながら活躍してくれます。 今回必要とする情報は ツイート本文 ・ ユーザ名 ・ ツイートURL ・ 画像URL です。それぞれの情報は以下のようにして取得します。 <?php foreach ( $ tweets as $ tweet ){ $ text = $ tweet -> text; $ name = $ tweet -> user -> name ; $ url = 'https://mobile.twitter.com/' . $ tweet -> user -> screen_name . '/statuses/' . $ tweet -> id_str; $ img = $ tweet -> extended_entities -> media [ 0 ] -> media_url_https; } ここで注意する点が2つあります。 まず１つ目はツイートURLです。これはツイートオブジェクトの中に直接記載されていないので、その他の情報を結合して作成する必要があります。 ２つ目は画像URLです。画像のURLは２種類あり、 media_url と media_url_https があります。見ての通りHTTPか HTTPS かが違うだけなのですが、LINEの API が HTTPS でないとダメなので、 media_url_https のURLを取得する必要があります。 LINEに送信 最後にLINEに送信します。単に動かすだけならプレーンテキストでもよいのですが、今回は少し見た目にこだわって Flex Message という形式にしてみます。 Flex Message では複雑なレイアウトを自由に作成可能です。今回は以下のような見た目にしました。ほかにどのようなレイアウトにできるのかは、サンプルなどもありますので 公式ページ をご参照ください。 以下が今回の見た目を作成するのに必要な情報を設定した配列です。この配列を json_encode して送信します。 function toggleFold(){ if(document.getElementById('fold').style.display=='none'){ document.getElementById('fold').style.display='block'; document.getElementById('link').text='◀クリックで閉じる'; } else { document.getElementById('fold').style.display='none'; document.getElementById('link').text='▶クリックで開く'; } } ▶クリックで開く <?php $ messageData = [ "to" => $ groupId , "messages" => [ [ "type" => "flex" , "altText" => $ altText , "contents" => [ "type" => "bubble" , "hero" => [ "type" => "image" , "url" => $ img , "size" => "full" , "aspectRatio" => "20:13" , "aspectMode" => "cover" , "action" => [ "type" => "uri" , "uri" => $ img ] ] , "body" => [ "type" => "box" , "layout" => "vertical" , "contents" => [ [ "type" => "text" , "text" => $ name , "weight" => "bold" , "size" => "xl" ] , [ "type" => "box" , "layout" => "vertical" , "margin" => "lg" , "spacing" => "sm" , "contents" => [ [ "type" => "box" , "layout" => "baseline" , "spacing" => "sm" , "contents" => [ [ "type" => "text" , "text" => $ text , "wrap" => true , "color" => "#666666" , "size" => "sm" ] ] ] ] ] ] ] , "footer" => [ "type" => "box" , "layout" => "vertical" , "spacing" => "sm" , "contents" => [ [ "type" => "button" , "style" => "link" , "height" => "sm" , "action" => [ "type" => "uri" , "label" => "See Tweet" , "uri" => $ url ] ] ] , "flex" => 0 ] ] ] ] ] ; そして実際に作成したメッセージを送信する部分のコードが以下となります。 改めて説明するまでもなく、 curl をたたいて終わりです。 <?php $ ch = curl_init ( "https://api.line.me/v2/bot/message/push" ) ; curl_setopt ( $ ch , CURLOPT_POST, true ) ; curl_setopt ( $ ch , CURLOPT_CUSTOMREQUEST, 'POST' ) ; curl_setopt ( $ ch , CURLOPT_RETURNTRANSFER, true ) ; curl_setopt ( $ ch , CURLOPT_POSTFIELDS, json_encode ( $ postData )) ; curl_setopt ( $ ch , CURLOPT_HTTPHEADER, array ( 'Content-Type: application/json; charser=UTF-8' , 'Authorization: Bearer ' . $ accessToken )) ; $ result = curl_exec ( $ ch ) ; curl_close ( $ ch ) ; おわりに 特に需要はないでしょうが、今回はLINEから Twitter 検索をしてみました。単に API をたたくだけで多くのことができます。今回はテキストメッセージを検索するということしかしていませんが、もっと面白いものがあれば機能拡張という形で取り込んで行きたいです。 最後までご覧いただきありがとうございます。 参考文献 LINE developers: Messaging API を利用するには https://developers.line.me/ja/docs/messaging-api/getting-started/ Docs — Twitter Developers https://developer.twitter.com/en/docs.html Heroku Dev Center https://devcenter.heroku.com/ GitHub - mpyw/cowitter: Asynchronous Twitter client compatible with mpyw/co Generator-based flows. https://github.com/mpyw/cowitter GET search/tweets - ツイートを検索する https://syncer.jp/Web/API/Twitter/REST_API/GET/search/tweets/ LINE developers: Flex Messageの要素 https://developers.line.me/ja/docs/messaging-api/flex-message-elements/

MasaKuです。 ラク スでは月１回のペースで開発メンバーの交流会としてビアバッシュを開催しています。 ビアバッシュとは ビールなどのアルコールを片手に(+軽食)フランクに技術内容について発表したり語り合う交流会 です。 ラク スで行っているビアバッシュについては以下の記事が参考になるかと思いますので、よろしければご確認下さい。 tech-blog.rakus.co.jp tech-blog.rakus.co.jp 大阪開発部では毎月何らかのテーマを決めてビアバッシュを行っています。 今月、大阪の開発部で開催されたビアバッシュのテーマは「 技術ネタ 」です。 技術ネタといっても、硬い雰囲気は全くなく、業務に直接関係しないような内容について発表されている人がほとんどでした。 また、テーマに縛られないLT枠も毎回開催されており、こちらも毎回数名の方が発表しています。 簡単ではありますが、今月のビアバッシュの雰囲気をお伝えできればと思い、発表内容についてまとめさせていただきました。 テーマ枠（技術ネタ） PHPのマジックメソッドについて これまでのPWAとこれからのPWAについて Haskellの参照透過性について LT枠（自由発表） 使い続けているツールについて Googleのデータセンターについて Android Studio で作ったアプリについて おわりに 参考サイト ビアバッシュの様子。ちなみに、今回のケータリングは「サンドイッチ」でした。 テーマ枠（技術ネタ） PHP のマジックメソッドについて マジックメソッド とは、クラスに設定しておけば、明示的にメソッドを呼び出さなくても特定条件で自動的に発動するメソッドのことです。 __construct() は業務の中でもよく目にしますが、それ以外のマジックメソッドについては、 PHP の学習初期に利用していた参考書に紹介されていたものを少し読んだくらいで、ほとんど知りませんでした。 マジックメソッドは フレームワーク やライブラリの中で利用されていることが多いようで __call() や __get() は CakePHP でも利用されているようです。 発表は __callStatic() を中心とした内容でしたが、機能の説明だけでなく、どのように実装するかということを、書籍管理を例にして説明していただきました。 発表の時間内でライブコーディングするというテクニックも披露していただき、大変見ごたえのある発表でした。 これまでのPWAとこれからのPWAについて Progressive Web Apps については、Webアプリでありながら、ネイティブアプリのように振る舞うことができるもの、くらいの認識でした。 また、どこでもネットに繋がる現代において、オフライン環境でも利用できることのメリットはそこまで大きくないのではないかと考えていました。 しかし、データを端末にキャッシュすることで、アプリのレスポンスが早くなるという点もPWAの特徴であるということについてご指摘いただき、オンラインで通信する必要のある箇所を切り分けるという観点を見落としていました。 様々な フレームワーク でPWAのテンプレートが利用できるようになってきている（React.js / Vue.js / Angular.js）ことから、PWAの開発が加速化することが期待されます。 Microsoft が今年中にPWAをWebアプリストアに追加することを発表したこともあり、今後のPWAのニュースにも注目しておかなければなりません。 www.itmedia.co.jp Haskell の参照透過性について Haskell の参照透過性のメリットについての発表内容でした。 なお、本発表は発表者とは異なる方が作成された資料を参照しながらの発表でした。（下記の slideshare ） 関数を実装する際に気をつけなければならないこととして、その関数がどのような値を受け取ってどのような値を返すのか、ということを明確に意識しておくことが挙げられます。 Haskell は静的型付き言語の中でも、制約が強い プログラミング言語 に分類されるようです。 そのため、実装した関数が正しい型で設定されていない場合は、 コンパイル 時に失敗するが、裏を返せば、 コンパイル で落ちなければ、関数の型が正しく設定できていることが保証されるということでもあります。 発表者の方は、 Haskell のような強い静的型付き言語でプログラミングを行うことによって、 PHP などの制約の優しい プログラミング言語 でプログラミングをする際にも型を意識する癖がついたとおっしゃっていました。 実装する際の心構えだけでなく、体に癖をつけておくことは大切だなと思いました。 Haskell Day2012 - 参照透過性とは何だったのか LT枠（自由発表） 使い続けているツールについて 業務で使っているツールを２つ紹介してくださいました。 Wireshark ネットワークに流れるパケット情報をリアルタイムで調査できるツールです。 Linux のコマンドも利用できることに利便性を感じて、今でも利用されているようです。 knowledge.sakura.ad.jp Vimium ブラウザ操作をキーボードで行うためのツールです。 マウスを操作しなくても ブラウジング ができることから、キーボードから手を離したくないような場合に便利で、体感的にはすごく楽とおっしゃっていました。 なお、以前のビアバッシュでこちらのツールと同様の cVim という Google Chrome の 拡張機能 の発表をしている方もいらっしゃいました。 マウス無しで ブラウジング することの需要は一定存在するようですね。 Google のデータセンターについて Google のサーバは、サーバを構成するビス1つから Google が自社で作成しているようです。 なんでも、利用している製品に 脆弱性 が発覚した際に攻撃されるリスクを回避するためなんだとか。 また、本発表で面白いと思ったのが、サーバの維持管理で一番コストがかかる箇所が、空調管理のための電力だそうです。 PUE(Power Usage Effectiveness)という、データセンターのエネルギー効率を表す一つの指標がありますが、 Google ではこのPUEが1.12～1.19程度らしいです。（ 業界標準 は1.5程度） 以前耳にした話ですが、 さくらインターネット では北海道の冷涼な外気を サーバル ーム内に取り込むことで、一般的な都市型データセンターと比較して約4割の消費電力を削減しているそうです。 サーバの維持管理のコストをいかに抑えるか、という話を聞くことで、 Google 検索を行う度に Google の電気が一部利用されているということをちゃんと意識できるようになりました。 提供されているサービスとはいえ、無駄なクエリ発行はできる限り抑えなければなりませんね。 www.sakura.ad.jp Android Studio で作ったアプリについて 業務で行った内容の復習として取り組まれた、 cURL で外部サーバにアクセスして情報を取得する Android アプリの開発について発表していただきました。 アプリの内容は Wather Hacks という Webサービス の API を用いて、その日の天気情報を取得するといったものでした。 本アプリを開発する上での苦労話として、 Android はOSのバージョンアップによって仕様が変わることから、参考にしている記事がどのバージョンの Android を対象とした記事なのかをしっかりと確認しなければ、うまく動作しなかった、ということを話されていました。 これは、自分が情報を収集する際のポイントとして、気をつけなければならないことでもあります。 しかし、新たに情報を発信する際も、環境依存となる情報は明確に提示しておくことで、記事の価値を高めることに繋がることを認識することができました。 tech-blog.rakus.co.jp おわりに いかがでしたでしょうか。 今月も様々なタイプの発表が聞くことができて、大変充実したビアバッシュになりました。 次回のテーマは「 使用しているツール特集 」ということで、次回も魅力あふれる発表が聞けるのではないかと今から楽しみです。 参考サイト 便利だけど使いどころが難しいPHPの代表的なマジックメソッドと無名関数の使い方：PHPオブジェクト指向プログラミング入門（4）（1/3 ページ） - ＠IT PHP: マジックメソッド - Manual モバイルウェブアプリケーションの新しい形「プログレッシブウェブアプリ」 | DATA INSIGHT | NTTデータ Haskell Day2012 - 参照透過性とは何だったのか Wireshark · Go Deep. Vimium - Chrome ウェブストア Wiresharkを使った通信監視（後編）――コマンドラインベースでのパケットキャプチャ | さくらのナレッジ さくらインターネット、新しい空調コンセプトで石狩データセンター3号棟を建設 | さくらインターネット livedoor

id:radiocat です。 スクラム マスターの修行中です。 今回はチーム力を高めるために私たちが取り組んでいる手法を紹介します。 アジャイル のプ ラク ティスとして紹介されている手法ですが、 アジャイル ではない開発の現場でも活用できるのでぜひ参考にしてみてください。 学びにフォーカスしてチームで試験問題を作る この手法は「 スクラム 現場ガイド」という書籍の第20章で、新しいメンバーを受け入れる手法として紹介されています。 スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本- 作者: Mitch Lacey マイナビ出版 Amazon この書籍を翻訳されている安井さんが同様のテーマのスライドも公開されています。 "Test" New Members / チームメンバーを"テスト"する from Yasui Tsutomu www.slideshare.net 目的 チームが大事にしている文化や技術について繰り返しテストをすることで新しいメンバーにそれらを理解してもらいます。また、テストをすることで新メンバーの理解が足りていないことを既存メンバーも含めてお互いに認識することができます。 やりかた チームが問題を作る 新しいメンバーは毎週必ずテストを受ける 問題の例 システムの アーキテクチャ を説明してください ペアプログラミング とTDDの意義を教えてください コードの所有者は誰ですか？ チームに取り入れよう 私たちのチームも新しいメンバーを迎えることになったので、早速この手法を取り入れようと考えました。しかし、ここでいくつか疑問が浮かびました。 テストするのは新しいメンバーだけ？ テストは新しいメンバーだけに必要なものでしょうか？我々エンジニアは新しく作った機能を必ずテストしますが、そのテストを日々回帰的に利用する手法を取り入れています。同様に スクラム チームも定期的にテストすればよりチーム力を高められるのではないかと考えました。 テストという言葉のハードルが高い 新しく入ってきたメンバーに対して「これからテストしますよ」と言うのは少し仰々しく、これから一緒にやっていこうというのに逆に 心理的 な壁ができてしまいそうな気がしました。そもそもこのテストは「チームが大事にしている文化や技術について理解する」ことが目的であり「テストする」のは手段でしかありません。無理にテストという言葉を使う必要もないので余計な 心理的 障壁を作らないように「クイズ」という呼び方にしてはどうかと考えました。その名も「Scrum Quiz」です。 Scrum Quizとは 私たちはScrum Quizを以下のように定義しました。 スクラム チームを前進させるための質問集です 以下のような内容について質問に回答することで相互理解を図ります 文化 価値観 必須スキル・理論 クイズはみんなのものなのでチームの誰でも追加・更新できます クイズの内容を考える あとは問題を作るだけです。 インセプション デッキにまとめた内容やチームで決めている品質の基準などを質問するようにします。また、ふりかえりで決めたルールなども質問に加えました。ふりかえりの時にチームで決めたルールがいつの間にか形骸化してしまうことが時々あります。クイズの問題にしておけばチームでそのルールを意識することができて、定着につなげることができます。 また、理解や定着が目的なので一言で答えられるようなクローズドな質問ではなく、あえてやや曖昧でオープンな質問にしてみました。 Scrum Quizの完成 そして私たちのチームのScrum Quizが完成しました。 チームの朝会（デイリー スクラム ）後に数分ほど時間をとってメンバーの誰か1人がクイズを引いて答えてもらうようにしました。正しく答えられることも大事ですが、チームで「ああ、そういうルールだったよね」という理解が共有されることも大事です。「補足すると、ふりかえりでこういう意見がでたのでこういうルールにしました」というような話が出ればさらに理解が深まって良いと思います。また、もしクイズに答えられなかったら、次の日のまでに答えをみつけて朝会で共有してもらいます。 チームを継続的にインテグレートする Scrum Quizはチーム力を高めるためのテストです。これを日々実行することで継続的にチームの大事にしている文化をより強化することができます。エンジニア的な言葉で言い換えるとチーム力を高めるためのCIツールなのです。 アジャイル な現場に限らずどんなチームでも大事にしている文化やルールはあると思います。チームでテストを作っておけば、それらを確認し合ってチーム力を高めることができます。

はじめに こんにちは。 @rs_tukki です。 先日、このエンジニアブログでY-KanohさんがDockerでの開発環境構築について説明されていましたね。 tech-blog.rakus.co.jp また、mickey-STRANGEさんはHerokuを使った開発環境の構築を行っていました。 tech-blog.rakus.co.jp 恥ずかしながら、一エンジニアとしてもう1年以上が経過している私ですが、業務以外でガッツリ開発することがあまりありません... 環境の構築についても色々手法があるなー程度で見ていたのですが、 先日 Vagrant というツールを使って、「どの」、「誰の」、「どんな」環境でも手軽に開発環境を構築できる手順を学びましたので、今回はそちらについて簡単に記事にしたいと思います。 はじめに Vagrant？Docker？ VagrantとDockerで誰でも使える開発環境を構築してみる 必要なツールのインストール Vagrantfileの作成、VMの起動 Dockerイメージの取得 実行 おわりに 参考 Vagrant ？Docker？ まず初めに Vagrant とDockerで開発環境を構築するにあたっては、当然ですが Vagrant とDockerがどのようなツールなのか、ということを理解しなければなりません。 正直自分も違いがよくわからないまま触っていたのですが...調べていると 面白い例え を見つけました。 Vagrant : 家の内装、全体的な設計 - どんな室内構造か、部屋は何があるのか～その他 Docker : 部屋or（キッチンも可） - 様々な種類がある、場合によってば独特な空間を持ち合わせている Vagrant は、設計図を基に自分のPCに仮想環境という「家」を作成するためのツールです。 普通に環境を作ろうとした場合は、どういう階層構造にするか、どんなOSを使うのか…等々、都度細かく設定しなければなりませんが、それらの設定を Vagrantfile としてテキスト形式で保存しておけば、それを元に どんなPCからでも同じような仮想環境を作成できる のです。 Dockerに関してはこのブログでも何度か説明されていますが、今回の場合では、 Vagrant から作成された「家」の中に作られた部屋 *1 というイメージで説明します。 それぞれ作られたコンテナの中にはそれぞれ単独で機能する仕組みがあり、例えばそれがWebサーバならWebにアクセスできる仕組みがありますし、DBであればデータを保存する仕組みがあります。また、それぞれのコンテナの間にネットワークという通路を作っておけば、複数のサーバを用いるようなWebアプリケーションも簡単に作成できるというわけです。 そして最も便利なのは、このコンテナ自体も Vagrant と同じく Dockerfile を作成しておくことによって、 細かい設定なしにいきなりコンテナを配置する ことが出来るという点です。 Vagrant とDockerで誰でも使える開発環境を構築してみる では、VargrantとDockerを用いて、実際に開発環境を作成してみましょう。 必要なツールのインストール まずは必要なソフトとして Vagrant と、仮想環境を作成する際に必要となる VirtualBox をインストールします。 Dockerは？　となるかもしれませんが、Dockerをインストールするのはあくまで Vagrant で作った仮想環境 に対してなので、現時点でのインストールは不要です。 Vagrant by HashiCorp Oracle VM VirtualBox 特にこだわりがなければ、最新版でOKです。 画面の指示に従ってインストールしてください。 Vagrantfileの作成、 VM の起動 インストールが完了したら、早速仮想環境の元となるVagrantfileを作ってみましょう。 ちなみに今回の手順は、 windows での操作を前提にしています。予めご了承くださいm(__)m。 まずは コマンドプロンプト を開き、 適当な作業用フォルダを作成します。 mkdir vm\test cd vm\test 作成したこのフォルダの中にVagratfileを作成していきます。 本来であれば vagrant initコマンドでテンプレートをダウンロードするのですが、今回は手軽に環境構築をお試しするためのVagrantfileをサクッと作っておきました。 Vagrant.configure("2") do |config| config.vm.box = "CentOS/7" config.vm.network :private_network, ip: "192.168.33.10" config.vm.provision "docker" end Vagrant.configure("2") do |config|...end で囲まれた範囲が、細かい設定を記述する箇所になります。 config. vm .box は仮想環境のOSを表します。今回は CentOS を使用します。 config. vm .network は仮想環境の IPアドレス の指定に使用します。実はこれがかなり重要で、これが設定されていないと仮に仮想環境上でWebサーバを立ち上げても、 IPアドレス がないのでPC上からアクセスできません。考えてみれば当然のことなのですが…こんな単純なことに3,4日も気づかずつまづいてしまいました… config. vm .provision で、環境の作成時にインストールするソフトを指定します。今回は前述の通りdockerを使用するので、今のうちに記述しておきます。 これだけ書いて保存したら、あとは仮想環境を作成して接続するだけです。 vagrant up vagrant ssh vagrant up でVagratfileを元に仮想環境を起動し、その環境に vagrant ssh で接続します。初回はdockerのインストール等もあるので多少時間がかかりますが、気長に待ちましょう。 しかし、気長といってもここに第二のつまづきポイントがあり、何故かVagrantfileは問題なく作成できているはずなのですが、10分経っても20分経っても起動が完了せず、 タイムアウト してしまうことがあります。 調べたところ、どうやら BIOSの設定 が邪魔をしているらしく、この設定をこちょこちょして何とか解決。 Dockerイメージの取得 接続が完了すると、ごく一般的な CentOS 上で Linux コマンドを叩けるようになります。 この環境上に、Dockerを使ってコンテナを作っていくわけですが、それには主に2つの方法があります。 Vagrantfileを作成したのと同じフォルダ内に「Dockerfile」を作成してビルドする dockerHub という、公式で提供されるコンテナの「カタログ」からDockerfileを借りてくる 細かく設定を行いたい場合は1.で行うのもいいですが、今回はとっかかりなので2.の方法で行きましょう。 プロジェクト管理 OSS である「 redmine 」と、そのデータを格納するための「 MySQL 」を作成してみます。 docker pull sameersbn/redmine:3.3.1 docker pull sameersbn/mysql:latest dockerHubからイメージを借りてくる際は、 docker pull コマンドを使用します。特に細かい設定は必要なく、dockerHubで提供されているイメージ名とバージョンを指定するだけで落とせるので便利。 こちらも時間がかかるので、気長に待ちましょう。 mkdir -p /srv/docker/redmine/mysql mkdir -p /srv/docker/redmine/redmine 続いて、 MySQL と redmine のデータを格納するフォルダを作ります。 本来データはコンテナの中に格納されていますが、このフォルダと紐づけを行う(後述)ことで両者を共有することが出来ます。 四次元ポケット これで、コンテナを動かす準備が完了しました。 実行 少し長いですが、以下2つのコマンドを実行してみてください。 docker run --name=mysql-redmine -d --env='DB_NAME=redmine_production' --env='DB_USER=redmine' --env='DB_PASS=redpass' -v /srv/docker/redmine/mysql:/var/lib/mysql sameersbn/mysql:latest docker run --name=redmine -d -p 8080:80 --link=mysql-redmine:mysql -v /srv/docker/redmine/redmine:/home/redmine/data sameersbn/redmine:3.3.1 docker run コマンドでコンテナを動かしています。以下、コマンドのオプションについて解説。 --name : 起動するコンテナの名前を定義しています。 -d : バックグラウンドで動かします。これがないと、一つ動かしている間は何も操作できなくなってしまいます。 --env : コンテナで扱う 環境変数 を設定します。 -v : コンテナの中にあるデータ配置のためのフォルダを、仮想環境の特定のフォルダと紐づけます。 -p : 起動したコンテナのポート番号と、自分のPC上で操作する時に指定するポート番号を紐づけます。 --link : 他のコンテナを指定することで、そのコンテナと連携することが出来ます。 これでPC側からアクセスができるはずなので、 http://192.168.33.10:8080 にアクセスします。 Redmine 使用者には見慣れたTOPページが表示されました！ おわりに Vagrant とDockerを使って環境を構築するやり方を説明いたしました。 正直なところ、結構噛み砕いて説明したつもりでしたがそれでも大分難しいと思います。 なんとたったこれだけのことを調べ始めてから記事にするまで約一ヶ月 ただ、当然若手エンジニアにとっては勉強になりますし、何より どんな環境でも、同じように環境を構築できる のはとても便利だと思います。ぜひ皆さんも試してみてはいかがでしょうか。 参考 acchi-muite-hoi.hatenablog.com https://qiita.com/hidekuro/items/fc12344d36d996198e96 qiita.com weblabo.oscasierra.net qiita.com www.risewill.co.jp エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com *1 : 以下、これを「コンテナ」と呼びます

はじめまして！普段業務では Java や Swift を書いていますが、本当は(?) PHP が大好きな @kawanamiyuu です。 今日は PHPer な私にとって嬉しいお知らせです！ お知らせ 関西での PHP の一大イベント、 PHP カンファレンス関西に弊社のエンジニアが登壇します。 また、 株式会社ラクス はシルバースポンサーとしてイベントに協賛します。 日時 : 2018 年 7 月 14 日 (土) 会場 : グランフロント大阪 公式 HP : https://2018.kphpug.jp/ 2018.kphpug.jp 登壇内容 タイトル チャットディーラーの高速開発を支える Laravel 概要 「 チャットディーラー 」は 株式会社ラクス が提供する、チャットを活用した Web 接客ツール ( SaaS ) です。 10 年以上 PHP でノン フレームワーク で開発・運用されてきた主力サービス（ メールディーラー ）の開発チームが、新規に姉妹サービス（ チャットディーラー ）を立ち上げる際に Laravel を選択をしました。 開発期間半年というスピードが求められる中で、チームが Laravel に抱いた理想と現実、また、Laravel (Blade) と Vue.js の組み合わせにより発生した 脆弱性 への対応など、Laravel での新規サービス立ち上げの経験を具体的にお伝えします。 最後に 当日は弊社のエンジニア数名もイベント本編および懇親会に参加します。セッションや懇親会を通して、弊社のサービス開発やエンジニアリングについてぜひたくさんお話できればと思います！

こんにちは。開発エンジニアのd_ shr ( id:d_shr )です。 前回はNode.jsのことを書いていましたが、今回は PostgreSQL のことを書きます。 前回投稿した記事 tech-blog.rakus.co.jp はじめに PostgreSQL10 変更点 ロジカルレプリケーション PostgreSQL9.6までのレプリケーション PostgreSQL10 ロジカルレプリケーション 所感 パーティショニング これまでのパーティショニング 宣言的テーブルパーティショニング 所感 パラレルクエリの強化 PostgreSQL9.6で対応していたもの PostgreSQL10で追加されたもの 所感 その他 まとめ 参考 はじめに 最近、 PostgreSQL について調査する機会がありました。 主にPostgreSQL9系やPostgreSQL10の変更点を調査しましたが、その中でも最新のPostgreSQL10について書きます。 PostgreSQL10はリリースから半年以上経っており今更ですが、新機能や変更点で気になったものをピックアップしてまとめようと思います。 PostgreSQL10 変更点 ロジカル レプリケーション 宣言的テーブルパーティショニング 改善された並列問い合わせ その他 ロジカル レプリケーション PostgreSQL10でPublish/Subscribeによる論理 レプリケーション が実装されました。 PostgreSQL9.6までの レプリケーション マスタからスタンバイに トランザクション ログを転送し適用することでデータの複製を実現していました。 対象はデータベース全体。完全な複製でスタンバイには物理的な変更はできないものでした。 PostgreSQL10 ロジカル レプリケーション レプリケーション 先に対して変更した レプリケーション 情報を送付できるようになります。 トランザクション ログを「テーブルに〇〇を挿入しました」のように論理的な変更内容として転送することができます。 データベース全体を レプリケーション するのではなく、特定のテーブルの情報やinsertだけを レプリケーション することが可能です。 レプリケーション 情報のやりとりにPublish/Subscribe(出版/購読型)モデルのメッセージ送信を用いています。 複製元でPUBLICATIONを作成し、複製先でSUBSCRIPTIONを作成することでテーブルの同期と レプリケーション が行われます。 INSERT, DELETE, UPDATEには対応していますが、CREATE TABLEなどには対応してません。 所感 柔軟に レプリケーション できるようになったという印象を受けました。 学生の頃にPub/Subモデルのメッセージングを用いた開発をしていたので興味深い内容でした。 パーティショニング パーティショニングとは、巨大な親テーブルを複 数の子 テーブルに分割することです。 今までパーティショニングの手順がめんどうだったのですが、CREATE TABLE文でパーティショニングが構築可能になりました。 これまでのパーティショニング 親テーブルを作成 親テーブルを継承する子テーブルを作成 CHECK制約を作成 親テーブルにINSERTトリガを作成 ...... 宣言的テーブルパーティショニング CREATE TABLE文で構築可能 1. 親テーブル作成 PARTITION BY構文 2. 子テーブル作成 PARTITION OF構文 所感 PostgreSQL9.5でもUPSERTが追加されていましたが便利な構文が増えたということで使ってみようかなと思いました。 パラレルクエリの強化 パラレルクエリとは、PostgreSQL9.6で追加された大きなテーブルに対するクエリを並列問合せで実行することです。 パフォーマンスの向上が期待できます。 PostgreSQL9.6で追加されたパラレルクエリ(並列問い合せ)がPostgreSQL10で強化されています。 PostgreSQL9.6で対応していたもの シーケンシャルスキャン 結合(nested loop, hash join) 集約 PostgreSQL10で追加されたもの インデックススキャン(B-tree, index only scan, bitmap heap scan) 結合（merge) 非相関副問合せ 所感 パラレルクエリ自体、バージョンアップで既存のシステムに取り入れるのは難しいのかなという印象を持っています。 これからも並列化はどんどん強化されそうな流れなので、パフォーマンス向上に繋がるなら考慮するべきなのかなと思います。 正しく理解しておきたい機能だと思いました。 その他 PostgreSQL10.3の修正で 他ユーザからの search_path を使った「 トロイの木馬 」攻撃を防御する PostgreSQL とアプリケーションの設定方法がドキュメントに記載されました。 pg_dump や他のクライアントプログラムで安全でない search_path 設定の使用が回避されました。 *1 PostgreSQL のpublic スキーマ の仕様によるもので、悪意あるユーザがpublic スキーマ に不正な挙動を行うユーザー関数を仕込んでおくことができます。 他のユーザがその不正なユーザ関数を一般のユーザ関数として実行させることで攻撃（漏えい、改ざんなど）ができてしまう問題がありました。 「 pg_dump 」「pg_upgrade」「vacuumdb」などの管理者ユーザで実行されるアプリケーション関してはsearch_pathからpublic スキーマ が取り除かれました。 PostgreSQL の仕様が原因になっていることなのでpublic スキーマ の設定を見直す必要もあり 既存のシステムで問題に直面しそうな場合は、運用面のことを考えるのなかなか辛いなという印象を受けました。 まとめ PostgreSQL10についてまとめました。 個人的に興味深い技術が使われていたものや、構文が追加され便利になったものなどありました。 また、パフォーマンスの向上に繋がることや 脆弱性 に関連した修正もあり、正しく理解しておかないといけないこともあるなと思いました。 参考 PostgreSQL 技術情報 - SRA OSS, Inc. 日本支社 PostgreSQLの“仕様”による、運用者にとって悩み深い脆弱性とは：OSS脆弱性ウォッチ（6） - ＠IT *1 : PostgreSQL 10.3 に関する技術情報 - SRA OSS, Inc. 日本支社