こんにちは。開発エンジニアのd_ shr ( id:d_shr )です。 これまではNode.jsや PostgreSQL について書いていましたが 今回はIoTを支える 通信プロトコル MQTT についてまとめます。 tech-blog.rakus.co.jp tech-blog.rakus.co.jp はじめに 軽量で省電力 メッセージングとTopic メッセージング Topic MQTTの機能 QoS Retain Will まとめ はじめに MQTT は、Publish/Subscribe モデルのメッセージングにより、非同期に1対多の通信ができる プロトコル です。 シンプルかつ軽量に設計されているため、機械同士が通信を行いやり取りするM2M (Machine-to-Machine) や 家電や自動車など多種多様な「モノ」が通信を行いやり取りするIoT (Internet of Things) を実現するのに適した プロトコル と言われています。 軽量で省電力 HTTPと比較すると、軽量で省電力な プロトコル です。 MQTT のヘッダサイズは２バイト〜とHTTPに比べるとかなり軽量になっており その軽量さからバッテリーが限られているモバイル通信に適しています。 メッセージングとTopic メッセージング MQTT はPub/Subモデルでメッセージングを行います。 Pub/Subモデルではメッセージの送信者をPublisher、メッセージの受信者をSubscriber、メッセージの仲介をするのがBrokerです。 Publisher はメッセージをBrokerへ送るとき、送ったメッセージがどの Subscriber に届くのかなど気にする必要はありません。 Subscriberはメッセージがどの Publisher から送られて来たのか知ることなく欲しいメッセージをBrokerから受け取ります。 Topic MQTT では、Topicと呼ばれるキーを用いてメッセージングを行います。 トピックは「/」で区切られた階層構造になっています。 例：japan/osaka PublisherはTopicを指定してメッセージを送信し、Subscriberは受信したいトピックをfilterとして指定することで、欲しいメッセージだけを手に入れることができます。 MQTTの機能 QoS MQTT ではメッセージごとに到達保証に関する QoS (サービスの品質)を指定します。 QoS0 メッセージは最高 1 回 配信される メッセージが 送信先 に届くかは保証されない QoS1 メッセージは最低 1 回 配信される メッセージが 送信先 に届くことが保証されるが重複して届く可能性がある． QoS2 メッセージは正確に 1 回 配信される メッセージが過不足なく 1 回のみ到着することが保証される． Retain Topicごとに最後にPublishされたメッセージをMQTTサーバが保持しておく機能。 MQTT はPub/Subモデルなので、PublishしたときにSubscribeしていたクライアントにしかメッセージは送信されません。 具体的には、10分ごとに更新される情報を得るために新しくSubscribeしても，最長10分間はなにも情報が得られないことになります。 しかし、Retain機能を使うとその時点での最新の情報が得ることができます。 Will Publisherが切断されてサーバとの通信ができなくなったときに 指定されたTopicとメッセージをSubscriberに送信する機能。 予期せぬ切断などが発生したときに、SubscriberはPublisherが切断されていることを判断できます。 まとめ IoTを支える プロトコル MQTT について簡単にまとめてみました。 世の中にIoTが広がってきているので、それに関連した技術は追っていきたいと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

ラク スは「 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 [アクセス]

はじめに こんにちは sts -250rrです。 前回の記事ではARをテーマに記事を投稿いたしました。 今回はテーマをガラリと変えまして「 機械学習 」について簡単にまとめてみようと思います。 昨今、 AWS の Amazon Machine Learningや Microsoft のAzure Machine Learning Studioなどで手軽に 機械学習 を利用できるようになって来たことに加え、 楽楽精算では、 iOS 向けに領収書のアップロードができるアプリをリリースしました。 楽楽精算 株式会社 ラク ス ビジネス 無料 このアプリでは 機械学習 系技術の1つである OCR （Optical character recognition）を用いて領収書データを読み取り、楽楽精算にアップロードしています。 世間的にも話題かつ、 ラク スでも 機械学習 に注目していることもあり、 良いタイミングなので 機械学習 について整理してみようということです。 今回は簡単に 機械学習 とは といった話から、 機械学習 を行うツールを使って 機械学習 を体験してみた内容をまとめていきます。 機械学習 とは？ はじめに、 Wikipedia では 機械学習 についてこう書かれています。 機械学習 （きかいがくしゅう、英: machine learning）とは、 人工知能 における研究課題の一つで、人間が自然に行っている学習能力と同様の機能をコンピュータで実現しようとする技術・手法のことである。 つまり、 人工知能 を実現する手段が 機械学習 という事です。 さらに Wikipedia を読み進めていくと概要にこう記載されています。 センサやデータベースなどから、ある程度の数のサンプルデータ集合を入力して解析を行い、そのデータから有用な規則、ルール、知識表現、判断基準などを抽出し、 アルゴリズム を発展させる。なお、データ集合を解析するので、 統計学 との関連が深い。 とあるように、実は 機械学習 は 統計学 と深い関連を持っています。 統計学 は、大量に得られたデータの性質や規則性、分類を見つけるような学問ですが、この 性質や規則を見つける事 が 機械学習 にとっての学習になるわけです。 機械学習 の種類 機械学習 について少し掘り下げていきます。 単純に 機械学習 といっても、大きく分けて「 教師あり学習 」と「 教師なし学習 」が存在します。 それぞれに学習方法やできることが異なりますので簡単にまとめていきます。 教師あり学習 学習に使用するデー タセット に対して、正解を与えておく学習方法です。 この学習では、大量のデー タセット から正解の情報を学習し、「ある特徴を持つものは、ある事柄に対して正解である」ことを判断できる学習方法です。 簡単な例だと、「赤い色という特徴を持つ果物」が「美味しい」と判断することができます。 しかし、正解として「美味しい」か「美味しくないか」のみを学習させているため、「赤い色という特徴を持つ果物」が「美しい」かは判断することはできません。 教師あり学習 を行う方法には次のようなものがあります。 線形回帰 ロジスティック回帰 ナイーブ ベイズ k近傍法 ニューラルネットワーク 教師なし学習 教師あり学習 とは反対に、学習に使用するデー タセット に対して、正解は与えません。 この学習は、大量のデータの類似度や規則性を学習し、データの分類を行います。 簡単な例だと、ある果物のデータを大量に集めてくると3つに分けられました。 機械自身には分けられたデータが何を示すものであるかはわかりませんが、次にデータが得られた時、3つのうちどこに該当するデータであるかを判断することができるようになります。 教師なし学習 を行う方法には次のようなものがあります。 主成分分析 k平均法 ディープラーニング 強化学習 *1 機械学習 を試してみる 言葉のみでは腑に落ちない部分もあるので実際どのように学習しているのかを試してみたくなりました。 そこでweka *2 というフリーの 機械学習 ツールを使っていきます。 (今回、wekaの使い方については特に説明いたしませんので悪しからず。。。) 今回は 教師あり学習 に「ロジスティック回帰」、 教師なし学習 に「k平均法」による クラスタリング を使っていきます。 これらの手法については下記の記事で詳細が紹介されていました。 qiita.com qiita.com お試し1： 教師あり学習 wekaのサンプルデータであるアヤメの品種分類データiris.arffを使っていきます。データの内容は以下の通りです。 クラス(正解):setosa, versicolor, virginica 特徴量(属性) - sepallength : がくの長さ - sepalwidth : がくの幅 - petallength : 花弁の長さ - petalwidth : 花弁の幅 上記のデータを持った150のデー タセット とロジスティック回帰を使って学習をさせてみました。 しかし、学習をさせるだけでは意味がありません。 学習の成果を見るために、10分割交差検定を用いて判別制度を見ていきます。 wekaならここまでやってくれるのでお手軽です。 検証結果の抜粋です。 === Stratified cross-validation === === Summary === Correctly Classified Instances 144 96 % Incorrectly Classified Instances 6 4 % Kappa statistic 0.94 Mean absolute error 0.0287 Root mean squared error 0.1424 Relative absolute error 6.456 % Root relative squared error 30.2139 % Total Number of Instances 150 === Detailed Accuracy By Class === TP Rate FP Rate Precision Recall F-Measure MCC ROC Area PRC Area Class 1.000 0.000 1.000 1.000 1.000 1.000 1.000 1.000 Iris-setosa 0.920 0.020 0.958 0.920 0.939 0.910 0.970 0.933 Iris-versicolor 0.960 0.040 0.923 0.960 0.941 0.911 0.975 0.933 Iris-virginica Weighted Avg. 0.960 0.020 0.960 0.960 0.960 0.940 0.982 0.955 学習による全体の判別制度96%、 それぞれの正解に正しく判別することができる確率が Iris-setosa : Iris-versicolor : Iris-virginica = 100％ : 95% : 92% という結果が得られました。 テストデータということもありなかなかの好成績ですね。 お試し2： 教師なし学習 教師あり学習 と同じようなデータで試してみます。 ただし、 教師なし学習 では正解データは必要ないため削除しておきます。 今回はk平均法による クラスタリング を行ってみました。 元データが3種に分類されていたので3 クラスタ に分類されるように設定しました。 テストデータとはいえ、綺麗に分類されるわけではなさそうですね。。。 ここで綺麗に分類するような学習ができれば、新たなデータを得た際にどこに分類するかを判別できるようになるわけですね。 かなりざっくりですが、数値や画面をみて少しだけイメージできました。 まとめ 今回は 機械学習 について簡単にまとめてみました。 しかしながら、この記事の内容は 機械学習 の表面をなぞった程度でしかありません。 今回のような内容をしっかり把握しておらずとも、はじめに述べたような Amazon Machine LearningやAzure Machine Learning Studioを利用することで簡単に 機械学習 は利用可能な世の中になりつつあります。 ただし、効率よく 機械学習 を取り入れるためにも、どんな方法が何に適しているのかは知っておくべきでしょう。 次回は今の 機械学習 の流行りをテーマに投稿してみようかと思いますのでお楽しみに。 *1 : 教師あり学習 、 教師なし学習 と同じレイヤーで分けられる場合もあります。 *2 : https://www.cs.waikato.ac.nz/ml/weka/

ラク スは「 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 [アクセス]

はじめに こんにちは、 @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