はじめに はじめまして。 ラク スのインフラエンジニアのcappy_potterと申します。 弊社で提供している クラウド サービスを担うサーバに（ クラスタ ）ついて、どの程度のアクセスまでであれば 問題なくサービス提供できるのか、という限界値を知るための 負荷試験 を過去に実施しました。 Webシステムを構成するサーバ群に対し、どのようにして負荷をかけ、限界値を探るのか、いろいろ方法は あると思いますが、実際に弊社で試したやり方をご紹介しますので、参考にしていただければと思います。 はじめに サーバ構成 負荷試験環境準備 負荷試験パターンの検討とJMeter用シナリオの作成 JMeterで負荷をかける ボトルネックの調査 おわりに サーバ構成 今回負荷をかけるサーバの構成は下図のようになっています。 対象のシステムは複数のサーバからなっていますが、外部からのアクセスは全てロードバランサで受けて、 配下のサーバに通信を振り分ける形となっています。 負荷試験 環境準備 ● 本番システムと同じ構成（台数、スペック）の 負荷試験 用サーバを用意する。 今回、負荷限界値を正確に測るため、本番環境と全く同じハード構成・台数の試験用サーバを用意しました。 リソースが足りず難しい場合は、各サーバのスペックを同じ割合で落としたものを用意して試験を行うことで とりあえず「 ボトルネック はどこか」を探ることはできると思います。 ● Apache JMeter サーバの用意 試験用サーバに対して負荷をかけるためのサーバとして、 Apache JMeter サーバを用意しました。 このとき、同時に大量のアクセスをかけられるようにするため、上図のようにマスタサーバ以外に 4台のスレーブサーバを用意しました。 　※ JMeter サーバ側が貧弱だと、負荷限界に達する前に JMeter サーバ側の方が先に限界に達する 可能性が 　　ありますので、そうならないように考慮しました。 ● 各サーバのパフォーマンスデータ収集準備 負荷試験 対象の各サーバにはZabbixエージェントをインストールし、パフォーマンスデータを取得できるようにしました。 弊社では、もともとサーバの監視用としてZabbixを利用していますので、これを用いて、各サーバのCPU使用率、 ロードアベレージ 、Disk I/O、swap使用量、ネットワーク帯域のデータを収集するようにしました。 　→ 負荷をかけたときに、どのサーバの何のリソースが ボトルネック になっているかを確かめるため。 なお、データの取得間隔は30秒にしました。間隔を短くした方がブレが少ないデータとなりますが、短くしすぎると データ取得自体も負荷になる可能性があるためです。 負荷試験 パターンの検討と JMeter 用シナリオの作成 今回、 負荷試験 を行うことにより、大きく分けると以下の2パターンの限界値を求めたいと考えました。 　① Webサーバ1台あたり、秒間何アクセスまで耐えられるのか 　② システム全体として秒間何アクセスまで耐えられるのか ただ、ひと口に「秒間何アクセスまで耐えられるのか」といっても、アクセスするページやユーザの操作内容によって 変わってきますので、基準を設けなければなりません。 基本的には最もアクセスが多いページや、標準的なユーザの操作内容がわかっているのであれば、それを基準にすればよい と思いますが、定まらない場合はいくつかのパターンについて試験を行い、その結果をもとに判断するしかありません。 弊社では、①の試験を行うために9パターンのシナリオを作成しました。また、①の試験はWebサーバ1台だけに対して アクセスが流れるようにするため、 ロードバランサー での振り分け先を1台のWebサーバのみとなるように設定を変更して試験を行いました。 （②の試験のときは、3台のWebサーバに対して均等にアクセスが振り分けられるようにしました。） JMeter で負荷をかける 作成した JMeter のシナリオを使って負荷をかけますが、秒間のアクセス数限界値を探るのが目的ですので、 以下のような流れで負荷をかけていきました。 （各シナリオで同じように試験を行い、それぞれのシナリオでの限界値を探りました。） 　 １）対象のサーバに対して、まずは「おおよそこれぐらいではないか」と思う秒間のアクセス数を5分間かける。 　　　→例えば、秒間20アクセスを5分間かける場合、 JMeter の設定は以下のようになります。 　　【Ramp-Up期間：】負荷をかける時間 ＝ 300(秒) 　　【スレッド数：】Ramp-Up期間(秒) × 秒間アクセス数 ÷ 負荷をかける JMeter サーバの台数 ＝ 300×20÷4 ＝ 1500 　 ２）5分間負荷をかけた結果、 JMeter でエラーを検知しているようであれば、秒間のアクセス数を減らし、 　　　 再度負荷をかける。エラーを検知していなければ秒間のアクセス数を増やして再度負荷をかける。 JMeter でエラーを検知しているかどうかは、実行結果の画面で「Status」の部分をクリックして、 ステータス別に並び替えすることにより判断できます。 （下図のように赤い「×」マークがあれば、エラーが発生しているということになります。） 　 ３）上記２）で秒間のアクセス数を増減させながら何度かテストを行い、最終的に「これ以上秒間のアクセス数を 　　　 増やすとエラーが出る」という値が判明すれば、それが限界値となる。 ボトルネック の調査 限界となる負荷をかけられているときのZabbixデータを確認し、どのサーバの何が ボトルネック になっているか 確認します。 下図は、負荷をかけている間の各サーバのパフォーマンスデータを記録した資料の抜粋ですが、これを見ると Webサーバの CPU使用率が100% に達していることがわかります。 そのため、この場合は、「WebサーバのCPUを増設する」「Webサーバの台数を増やす」などすれば、システム全体としての 限界値は延びることが予想されます。 おわりに 本記事では、 負荷試験 によってサーバの限界値を求めるための方法に絞って記載していますが、実際は試験を実施する前に 負荷試験 を行う目的、求められた 負荷試験 結果をもとに今後どう運用していくのか 、ということを明らかにしてから 実施しないと、何度も 負荷試験 を実施しなければならなくなる可能性があるため、これらをしっかり認識したうえで 実行するようにして下さい。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

こんにちは、 ラク スひぐちです。 07/21(火) に開催された「 Developers Summit 2020 Summer」に参加しました。 https://event.shoeisha.jp/devsumi/20200721#outline 今回はオンライン開催ということで参加された方も多かったのでないでしょうか。 参加した4つのセッションの中で特に気になったセッションについて感想を書いていこうと思います。 エンジニアリングが組織に広がる「乳化」を目指すための取り組み READYFOR株式会社 VPoE伊藤 博志(通称：いとひろ)さんが登壇してらっしゃいました。 開発プロセス 枠ですね。 スライドは下記になります。 speakerdeck.com READYFORさんが掲げる「乳化」とは、 * 組織の中にエンジニアリングが自然に溶け込んでいる状態 * 既存の価値観とテク ノロ ジー が融合することによる イノベーション の創造を目指す 組織間の隔たりなく、ミッションのために協力し合える状態かなと解釈しました。 確かに同じ会社といえど、仕事の取り組み方や文化を合わせていくのって大変ですもんね。 そんな文化の中、注目すべきなのはこれです。 BPMN B usiness P rocess M odeling and N otation 訳すと「ビジネスプロセス モデリング 化と記法」で国際標準規格(ISO/IEC19510)にも指定されている概念です。 「さまざまなビジネスチームがBPMNを活用してフローを可視化してくれるようになった」 これが目からウロコの取り組みでした。 ビジネスチーム、要は営業や製品企画、サポートなどの事業部ですね。 ビジネスチームと開発間で認識合わせをするんですが、これが結構ふわっとしがちです。 開発から業務シナリオなどを図示するときにDraw.ioなんかを使ってビジネスチームに見せることは結構やります。 しかしビジネスチームがBPMNツールを使ってフローを可視化してくれる、この価値がかなり高いです。 ビジネスチームから言葉で要求の説明を受ける、開発が企画に ヒアリ ングする 上記の結果から開発が要件を文書や図に起こす 認識齟齬があるところを削る、変更する だいたい2～3を繰り返し行います。 ビジネスチームが思い描いている図示をさっとできる状況が上記の工程を短縮することにつながりますね。 もちろんはじめは開発やデザインチームのフォローが入るので、 より簡単で使いやすいツールを選ぶのが重要になってきます。 設計を図示するツールはいくつかありますが、READYFORさんが利用しているツールはこちら。 「 Camunda Modeler 」 いとひろさんが使い方をレクチャーしてくれています。 http://itohiro73.hatenablog.com/entry/2018/01/15/082158 さっそくやってみました。 すごい簡単です。 Camundaで図示 UIが直観的で触りやすいこと 無駄なツールがないこと あるとかえって使いづらくなります 図示して、というと急に足が重くなってしまいそうですが、 これならツールを利用する精神的なハードルも低く取り組めると思います。 さっそくビジネスチームにレクチャーしながら進めていきたいですね。 もう一つの取り組み、Slackの Reacji Channeler も魅力的でした。 絵文字を押すだけで特定のチャンネルに飛べるんですって。 slack.com 残念ながら弊社はSlackではないので導入ハードルが高そうですが、Slackご利用の方はぜひ使ってみてください。 こうしたいくつかの取り組みがあって、組織の乳化が進めば、開発に着手するまでの上流工程をスムーズになると思います。 READYFORさんの取り組み、必見です。 他のセッションも個性的で魅力的でした。素晴らしかったです。 自分で気づかない観点を取り入れる勉強会ってやっぱり大事ですね。 次回もぜひ参加したいです。

こんにちは。west-cです。 携わっている新規サービスにて ドメイン 駆動設計（以下、DDD）を取り入れた開発を行っていることから、去年の秋頃からDDDの学習をはじめました。 今回は、私が学習にあたり読んだおすすめ書籍を紹介します。 目次 目次 ドメイン駆動設計とは おすすめ書籍 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 ドメイン駆動設計 モデリング/実装ガイド ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本 Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 実践ドメイン駆動設計 エリック・エヴァンスのドメイン駆動設計 おわりに ドメイン 駆動設計とは 本題へ入る前に、「そもそもDDDって何？」という方へ3行でとてもざっくりと説明します。 DDDとは、ソフトウェアで問題解決しようとする領域（ ドメイン ）を中心に据えて開発を行うソフトウェア開発手法のこと DDDを実践することで、 ドメイン 知識がそのままコードへ反映されるようになる ドメイン 知識とコードが地続きになることによって、 変化に強いソフトウェアを構築できる 「変化に強い（保守性の高い）ソフトウェア」と聞いて興味を持った方は、これからご紹介する書籍を読んでみてはいかがでしょうか。 おすすめ書籍 初学者がDDDを学ぶ場合はこの順番で読むのがよいのではと思った順番に紹介します。 なお、学習前の私の状況は以下のとおりです。 Java でのプログラミング経験あり（サンプルコードの読解には苦労しない） オブジェクト指向 的なプログラミングは苦手 DDDはまったく知らない 現場で役立つシステム設計の原則 〜変更を楽で安全にする オブジェクト指向 の実践技法 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 作者: 増田 亨 技術評論社 Amazon 業務アプリケーションの保守性を高めるための設計手法について説明されている書籍です。 DDD学習の前段階におすすめです。 「 リファクタリング 」の内容にも通じるコードの見通しの良さの話から オブジェクト指向設計 による モデリング 方法まで、業務アプリケーションにおけるコードをわかりやすくするための手法が説明されています。 タイトルだけを見るとDDDとは関係無いようにも見えますが、本文中には「業務的な関心事を ドメイン モデルとして表現する」考え方やDDDで見られる実装パターンが導入されていたりと、DDDのエッセンスが要所に詰まっています。 この書籍を読んだ当初の私は オブジェクト指向 的なプログラミングに慣れていなかったため、手続き型の設計からの発想の切り替えに役立ちました。 「DDDおよび オブジェクト指向設計 を取り入れたら保守性の高いコードになりそう」と思うきっかけにもなり、学習のモチベーションにも繋がりました。 ドメイン 駆動設計 モデリング /実装ガイド little-hands.booth.pm DDDの モデリング から実装までの一連の流れが紹介されている書籍です。 全100ページほどでDDDの全体像がコンパクトにまとまっています。 初学者が「DDDとは」を理解するには、まずはこの書籍を一読するとよいのではと思います。 著者の方の YouTube チャンネルに書籍の解説動画が投稿されていますので、まずはこちらを観てみるのもアリかと思います。 動画後半の質問回答コーナーでは視聴者の方からの疑問が多く寄せられており、こちらもためになります。 little_hand_s DDD Channel - YouTube ちなみに、弊社では現在こちらの書籍の読書会を行っています。 DDD初心者から実際にDDDに取り組んでいる・取り組もうとしているサービスのメンバーまで、幅広い層が参加する会となっています。 書籍を読む中で湧き上がる素朴な疑問に対して「うちのサービスではこのような方針にしている」といったリアルな実情を聞くこともでき、活発に意見交換が行われています。 ドメイン 駆動設計入門 ボトムアップ でわかる! ドメイン 駆動設計の基本 ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本 作者: 成瀬 允宣 翔泳社 Amazon DDDにおける実装パターン（戦術的設計と呼ばれています）を中心に紹介されている書籍です。 戦術的設計の各パターンについて詳しい解説と実装指針が示されています。 戦術的設計の理解のために一読するのはもちろん、実装時にリファレンス的な用途で眺めても参考になります。 私がDDDを実践しはじめた頃はまだ刊行されていなかったため、この書籍の前身である「 ボトムアップドメイン駆動設計 」によくお世話になりました。 DDDに慣れない当初はどのように実装するのが適切なのか迷うことが多々ありましたが、サイトに記載されている詳細な説明が判断材料となり助けられることも多かったです。 ボトムアップドメイン駆動設計 │ nrslib ボトムアップドメイン駆動設計 後編 │ nrslib Domain Driven Design（ ドメイン 駆動設計） Quickly 日本語版 Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 後ほど紹介する「エリック・ エヴァ ンスの ドメイン 駆動設計」、通称「 エヴァ ンス本」をコンパクトに要約した書籍です。 重厚な エヴァ ンス本の要点を掴むことができます。 この書籍では、これまで紹介してきた書籍ではあまり詳細には触れられてきていなかった「境界づけられたコンテキスト」などの戦略的設計に関する解説も含まれています。 これから紹介する2冊は戦略的設計に関する話も登場し難易度が高くなるため、この書籍を先に読むとこの後の理解がスムーズに進むのではと思います。 実践 ドメイン 駆動設計 実践ドメイン駆動設計 (Object Oriented SELECTION) 作者: ヴォーン・ヴァーノン 翔泳社 Amazon エヴァ ンス本の内容をコードを交えて具体的に説明している書籍です。 DDDを取り入れた架空のプロジェクトを題材としており、「実際のプロジェクトではどのように実現するのだろう？」と思う部分が実装例つきで解説されています。 サンプルプロジェクトは複数アプリケーション（＝境界づけられたコンテキスト）に分割されており、これまで紹介した書籍でのサンプルプロジェクトの中でも大規模なものとなっています。 「 ドメイン イベント」など、DDDにおけるコンテキスト内外との情報連携の手段に関して詳細に述べられており、まさにDDDを実践する際の具体例が詰まっています。 エヴァ ンス本の説明は抽象的なため、先にこちらを読んでおくと エヴァ ンス本で言っていることのイメージが付きやすい印象です。 ただ、どちらの書籍も難しいため理解を定着させるためにはそれぞれ読み返す必要があると思います。 なお、この書籍の章ごとの要約が「 IDDD本から理解するドメイン駆動設計 」として連載されており、章を読んだ後の分かったようで分かっていない脳内を整理するのに役立ちました。「 「実践ドメイン駆動設計」から学ぶDDDの実装入門 」として書籍化もされているようですので、近いうちにこちらを片手に再読したいと思っています。 「実践ドメイン駆動設計」から学ぶDDDの実装入門 作者: 青木 淳夫 翔泳社 Amazon エリック・ エヴァ ンスの ドメイン 駆動設計 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス 翔泳社 Amazon ドメイン 駆動設計の原典とも呼ばれる書籍です。 原典ですが（原典がゆえに？）書いてある内容が難しく、私はひととおり読了こそしましたが理解できた感覚はありませんでした……。 対象となる ドメイン をどのように モデリング し深いモデルへ到達させてゆくかや戦略的設計について詳細に述べられている書籍は少ないため、その点は一読してみる価値はあると思います。 本文中で例として挙げられているアプリケーションは、筆者が実際に携わった業務アプリケーションが基になっているため、例示される ドメイン 知識にリアリティがある点もこの書籍ならではだと思います。 リアリティのある複雑な ドメイン を対象にしているがゆえに理解が難しい点も無きにしもあらずなのですが、対象分野が違うだけで業務アプリケーションにおける ドメイン 知識は元来複雑なもののはずですので、この内容が理解できればDDDに対する汎用的な知識が身についたということなのかなと個人的に思っています。 なお、前述の「 ドメイン 駆動設計 モデリング /実装ガイド」の読書会の前は、こちらの書籍の読書会が弊社内で開催されていました。 私はこの読書会ではじめて エヴァ ンス本に触れたのですが、「わからない」を参加者の間で共有でき、各々の解釈を語り合うことでモチベーションの維持に大いに繋がりました（一人で読んでいたら挫折していたと思います）。 「 エヴァ ンス本は難しい」という前評判に腰が引けてなかなか手を出せずにいる方（過去の私です）は、身近な方を誘って一緒に読みはじめてみるのもアリだと思います。 おわりに ドメイン 駆動設計と聞くと名前だけで内容がイメージできず難しい印象を受けますが、ここ最近は入門者向けの書籍やスライド、ネット上の記事なども多く見かけるようになり学習のハードルは下がったのではと思います。 かくいう私はDDD歴1年未満の新参者であり”完全に理解した”の域にもまだ到達できていないとは思うのですが、「 ドメイン 知識をそのままコードに落とし込むことでコードの見通しが良くなる」「他の人が書いたコードもどこに何が書いてあるのか理解しやすい」などの恩恵は現時点でも感じています。 まだ戦略的設計に関する知見は浅いと感じていますので、今後も周辺知識の習得含め学習を続けていきます。 みなさんもぜひこの機会にDDDを学んでみてはいかがでしょうか。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに こんにちは。「ChatDealer」の開発に携わっているy_kwmtです。 Excel ファイルをプログラムで楽に書き出す方法を調べていたら PHP のライブラリを用いて Excel ファイルを書き出す方法を見つけました。 はじめに PhpSpreadsheetとは PhpSpreadsheetのインストール コーディング PHPファイル実行 最後に 参考にしたサイト PhpSpreadsheetとは PhpSpreadsheetは、 Excel などの様々な スプレッドシート ファイル形式を読み書きできるライブラリです。 今回はその PHP のライブラリ「PhpSpreadsheet」について紹介します。 PhpSpreadsheetのインストール Composer を使用してプロジェクトに「PhpSpreadsheet」をインストールします。 PHP バージョンは 7.2 以降が必須となります。 composer require phpoffice/phpspreadsheet コーディング Excel ファイル作成プログラム「index. php 」を作成します。 下記のコードで簡単な点数表を作成します。 <?php require 'vendor/autoload.php' ; use PhpOffice\PhpSpreadsheet\Spreadsheet; use PhpOffice\PhpSpreadsheet\Writer\Xlsx; // スプレッドシート作成 $ spreadsheet = new Spreadsheet () ; $ sheet = $ spreadsheet -> getActiveSheet () ; // 値とセルを指定 $ sheet -> setCellValue ( 'B1' , '英語' ) ; $ sheet -> setCellValue ( 'C1' , '数学' ) ; $ sheet -> setCellValue ( 'A2' , 'Aさん' ) ; $ sheet -> setCellValue ( 'A3' , 'Bさん' ) ; $ sheet -> setCellValue ( 'B2' , '90' ) ; $ sheet -> setCellValue ( 'B3' , '80' ) ; $ sheet -> setCellValue ( 'C2' , '70' ) ; $ sheet -> setCellValue ( 'C3' , '95' ) ; // Excelファイル書き出し $ writer = new Xlsx ( $ spreadsheet ) ; $ writer -> save ( 'score.xlsx' ) ; PHP ファイル実行 php コマンドで先程作成した「index. php 」を実行します。 php index.php Excel ファイル「score.xlsx」が作成されます。 最後に 今回は「PhpSpreadsheet」を用いて簡単な点数表を作成しました。 この記事が PHP ユーザーの参考になれば幸いです。 今後、作成したコードの改良を行い、複雑な Excel ファイルをコマンド一発で作成できるようにしたいと思います。 参考にしたサイト phpspreadsheet.readthedocs.io blitzgate.co.jp blitzgate.co.jp エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

こんにちは、YSです。 2020年7月9日にシューマイ　コミュニティにて開催された Laravel の勉強会に参加してきました。 shuuu-mai.connpass.com 普段のプロダクト開発でも関わっている Laravel。 この機会に社外のいろいろな知見にも触れてみたいと思ったのが、参加のきっかけです。 以下、簡単ですがイベント内容と感想をレポートします。 発表内容 Laravel x Herokuによる開発・運用 Laravelのコンテナ運用のベストプラクティスを考えてみた 循環的複雑度80超えの現行システムに Laravel × オニオンアーキテクチャ で立ち向かった話 Laravelで小規模業務システムを作る時の要点 感想 Laravel の導入しやすさ Laravel の豊富な機能例 おわりに 　 発表内容 CTOやリードエンジニアとしてご活躍されている方々が 業務で実際に運用・開発されている Laravel について語って下さいました。 Laravel x Herokuによる開発・運用 株式会社タンバリン CTO　狩野 裕介さん speakerdeck.com Heroku を使用したサービスの設定/運用について語って下さいました。 スケールアウトが設定画面でスライダーを動かすだけで行えたり Git merge で自動デプロイされ、ボタンを押すだけ本番リリースが行える等 Heroku では、とても簡単にサービスの設定・運用が行えるようです。 自動デプロイからの Laravel の Migration の連携はまだ実施できていないとのこと。 工夫が必要な箇所もありそうです。 　 Laravelのコンテナ運用のベストプ ラク ティスを考えてみた 株式会社ROXX CTO　松本 宏太さん slides.com Amazon ECS を使用したコンテナ運用について語って下さいました。 コンテナの使い分けや、ロギングの設定等について 実際の設定値やポイントなどが書かれており、ぜひ参考にしたい情報ばかりでした。 　 循環的複雑度80超えの現行システムに Laravel × オニオン アーキテクチャ で立ち向かった話 株式会社うるる　栗原 史明さん speakerdeck.com オニオン アーキテクチャ を採用するために Laravel を導入された話についての発表でした。 オニオン アーキテクチャ 推進のため最適な フレームワーク として、なぜ Laravel を選んだのか、 実際に導入してみてどうだったのかなど、詳細な事例が興味深かったです。 　 Laravelで小規模業務システムを作る時の要点 株式会社プ ラムザ エンジニア リングマ ネージャ　荒瀧 悠さん speakerdeck.com 長く Laravel での開発に携わってきた荒瀧さんによる発表です。 小規模システムの定義と、Laravel の機能が用途ごとにわかりやすく説明されており、とても参考になる内容でした。 　 感想 今回のイベントでは大きく分けて「運用向け」「開発向け」の2種類のLTがあり、 私には、日ごろ携わっているプロダクト開発に関係する「開発向け」の発表が刺さりました。 私が興味を持った「開発向け」LT は2つあります。 Laravel の導入しやすさ 1つ目は、オニオン アーキテクチャ を採用するために Laravel を導入した話です。 Laravel を採用した観点は、「自由度の高さ」「DI サポート」「 トラブルシューティング がしやすい」という3点、とのことでした。 「自由度の高さ」「 トラブルシューティング がしやすい」という2点は、 私が開発に携わっている製品『チャットディーラー』で、Laravel を採用した条件と類似しており、親近感がわきました。 特に観点「 トラブルシューティング がしやすい」の中で説明されていた 「利用者の多さ」という点は、 フレームワーク の寿命にも関わるため フレームワーク 選定時の重要な要素だと感じています。 また、 ビジネスロジック の分離についても解説されていました。 『チャットディーラー』の開発でも ビジネスロジック の分離を意識したレイヤー設計を取り入れていますが、 より本格的に進められている印象が伝わってきました。 Laravel の豊富な機能例 2つ目は、Laravel での開発に長く携わってきた方ならではの詳細な機能説明でした。 これから Laravel で開発する方向けの発表とのことでしたが すでに見知った機能以外にも、使用したことのない機能の説明もありました。 今後の開発で活かせそうな機能も含まれており、「Laravel って便利だな」と改めて思った次第です。 今回紹介のあった機能以外も含めて、 一度、Laravel の公式リファレンスにあたって、全機能を確認しておく必要がありそうです。 　 おわりに 実は Zoom でのオンライン勉強会参加は人生初の経験でした。 話している方の「間」も普段の勉強会とはまた違った「間」があり、とても新鮮でした。 今回の参加した勉強会は、普段は東京で開催されているそうです。 大阪在住の私としては、参加が難しい勉強会に参加することができたのも、オンライン開催ならでは良い経験でした。 　 最後に宣伝となりますが、 株式会社ラクス でも PHP をはじめとした各種勉強会を開催しています。 オンライン中心となりますので、参加もしやすいと思います。よろしければぜひご参加ください。 詳しくはこちらをご覧ください。 https://rakus.connpass.com/ rakus.connpass.com

こんにちは、エンジニアの id:eichisanden です。 CentOS6からCentOS7にバージョンアップした時に謎の性能劣化に苦しめられたことがありました。 今更CentOS7という感じもありますが、恐らくCentOS8にも通じる話なのと、 CentOS6のサポートが2020/11/30に切れるのでバージョンアップする方もいると思い記事にしてみました。 同じ条件で性能を比較してみる 特定の処理が顕著に性能劣化した そもそもOS単体の性能はどうなのか ターボ・ブーストが有効になっているかの確認 ターボ・ブーストは有効だった CPUガバナーをperformanceに変更してみる tunedの設定を変更する CPUの脆弱性パッチの存在に気づく 試しに脆弱性パッチを無効にしてみる さいごに 同じ条件で性能を比較してみる まず、ほぼ同じスペックの物理サーバを2台用意して、同じアプリ、同じデータ、同じ処理を流して性能比較を行いました。 特定の処理が顕著に性能劣化した ある バッチ処理 はCentOS6では148秒で終わっていたのにCentOS7では168秒もかかる結果になりました。 ちょっと取得タイミングがずれちゃってますがvmstatをグラフ化して見てみます。 CentOS7 CentOS6 やけにCPUのsys（ Linux カーネル が使っているCPU使用率）の赤が目立つのと若干 コンテキストスイッチ が多いことが目についたのでCPU周りを疑うことにしました。 そもそもOS単体の性能はどうなのか OS単体の性能はどうなのかということでUnixBenchを取得しました。 結果をみると、 Dhrystone 2 using register variables という整数演算以外はCentOS6の圧勝という結果に。 測定したアプリに違いはないため環境自体の問題と疑っていましたので予想通りの結果になりました。 と言うことで、続けてOSの設定にミスがないかを見ていきます。 ターボ・ブーストが有効になっているかの確認 ターボ・ブースト というのは負荷がかかっているコアに対して定格の動作周波数よりも高い周波数で動かす インテル のCPUの仕組みです。 検証に使用したのはターボ・ブーストに対応した Xeon ですが、これが無効になっていないのでは？と疑ってみました。 ターボ・ブーストは有効だった cpupowerコマンド見ると、 boost state support が Active: yes になっているので有効になっているようです。 # cpupower frequency-info analyzing CPU 0: driver: intel_pstate CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: Cannot determine or is not supported. hardware limits: 800 MHz - 3.50 GHz available cpufreq governors: performance powersave current policy: frequency should be within 800 MHz and 3.50 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency: 1.20 GHz (asserted by call to hardware) boost state support: Supported: yes Active: yes 同時に、このCPUの周波数は3GHzですが、800MHzから3.5GHzの範囲で動くこと、 このコマンドを叩いた瞬間は1.2GHzの周波数で動いていたことがコマンドの結果から分かります。 低い周波数で動作しているのはCPUガバナーが powersave になっていることが原因なようです。 powersave は最 低周波 数に固定して動作するという記事もあったのですが、 UnixBench中の負荷が掛かった状態で見てみると負荷が掛かれば最大周波数で動作するようでした。 # cpupower frequency-info analyzing CPU 0: driver: intel_pstate CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: Cannot determine or is not supported. hardware limits: 800 MHz - 3.50 GHz available cpufreq governors: performance powersave current policy: frequency should be within 800 MHz and 3.50 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency: 3.50 GHz (asserted by call to hardware) boost state support: Supported: yes Active: yes 検証に使用したサーバーのCPUは performance と powersave しかサポートしていませんが、 powersave は ondemand を選んだ時のように必要に応じて周波数を上げるような動きをすることが分かりました。 CPUガバナーをperformanceに変更してみる 負荷が掛かれば周波数が最大まで上がるので意味がなさそうと思いつつ performance に変更してみます # cpupower frequency-set --governor performance Setting cpu: 0 Setting cpu: 1 Setting cpu: 2 Setting cpu: 3 再度性能測定したところ、168秒掛かっていたのが、159秒にまで一気に早くなりました！！ powersaveでも最終的にはブーストが効くのでここまで差が出るとは思っておらず意外な結果でした。 ただ、まだ思った性能が出ていないので検証を続けます。 tunedの設定を変更する CPUガバナーだけを設定してもよいのですが、CentOS7から導入されたtunedという各種パラメータを便利に設定できる仕組があるのでそれを使用して設定します。 検証に使用したサーバーは balanced がデフォルトで設定されていたので、 throughput-performance に変更しました。 # デフォルトの設定 # tuned-adm recommend balanced # 現在の設定を確認 # tuned-adm active Current active profile: balanced # throughput-performanceに変更 # tuned-adm profile throughput-performance CPUガバナーがperformanceになる以外にもいくつかのパラメータがパフォーマンス寄りの設定になりますが、どんな設定になるかは設定ファイルで確認できます。 # cat /lib/tuned/throughput-performance/tuned.conf |grep -e "^[^#]" [main] summary=Broadly applicable tuning that provides excellent performance across a variety of common server workloads [cpu] governor=performance energy_perf_bias=performance min_perf_pct=100 [disk] readahead=>4096 [sysctl] kernel.sched_min_granularity_ns = 10000000 kernel.sched_wakeup_granularity_ns = 15000000 vm.dirty_ratio = 40 vm.dirty_background_ratio = 10 vm.swappiness=10 CPUの 脆弱性 パッチの存在に気づく まだCentOS6の性能に及ばないので色々調べていると、2018年はじめに問題になったSpectreとMeltdown対策のパッチで性能劣化するという記事を見つけました。 IntelがSpectreとMeltdown修正による0〜21パーセントのパフォーマンス低下を公表 この観点で見ていくとCentOS6の検証に使ったサーバの カーネル はアップデートされておらず、 対してCentOS7は 脆弱性 パッチがしっかり当たっているので、 それが速度の違いの要因だといういうことが見えてきました。 試しに 脆弱性 パッチを無効にしてみる 本番環境の 脆弱性 のパッチを無効にするつもりはありませんが、 Meltdownのパッチを無効にすることが設定ファイルの書き換えだけで出来たので試しにやってみました。 # cat /sys/kernel/debug/x86/pti_enabled 1 # cat /sys/kernel/debug/x86/retp_enabled 1 # cat /sys/kernel/debug/x86/ibrs_enabled 0 # echo 0 > /sys/kernel/debug/x86/pti_enabled # echo 0 > /sys/kernel/debug/x86/retp_enabled 無効にして ベンチマーク を取ると僅かですが性能向上していました。 CentOS7の方は他にいくつもCPU関連の 脆弱性 パッチが当たっており、 全てのパッチを無効にしての検証が出来ないため想像になりますが、性能劣化の原因はこのあたりという結論に自分の中では落ち着きました。 ここから先はチューニングで補う方向に方針を切り替え、調査としては一旦完了としました。 さいごに 大きな構成変更をした時には前後の性能比較をすることが非常に大事だと改めて感じました。 性能測定する環境の条件は極力揃えるというのも教訓になりました。 原因が分かれば対策のしようがあるので、しつこく調べた甲斐がありました。 以上になります。最後まで読んでいただきありがとうございました。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは、takaramです。 最近業務で PHPUnit を使ったテストを書く機会が増えてきました。初めは assertEquals しか知らなかったわけですが、最近は適切な アサーション メソッドを選択できるようになってきました。そこで今回は数ある PHPUnit の アサーション メソッドの中から、一般的によく使いそうなものを独断と偏見で選んでご紹介します！ なお、以下の内容は執筆時点の最新版の PHPUnit (v9.2.6) に基づいています。 PHPUnitのアサーションメソッド assertEquals assertSame assertTrue, assertFalse, assertNull assertCount assertStringStartsWith, assertStringEndsWith, assertStringContainsString assertRegExp assertIsXXX, assertInstanceOf 最後に PHPUnit の アサーション メソッド assertEquals ある値が期待した値と等しいかどうかを判定します。 PHPUnit の初心者向け資料にもよく出てくるおなじみのメソッドですが、 基本的にはほぼ使いません 。というのも、これは 暗黙の型変換が行われる からです *1 。たとえば、以下の アサーション は全て成功します。 $this- > assertEquals(1, '1'); $this- > assertEquals(null, ''); $this- > assertEquals(null, false); $this- > assertEquals(null, 0); $this- > assertEquals('1', true); テストにおいては、こうした型変換は嬉しい場面よりも困る場面のほうが多いのではないでしょうか。引数の内容によっては型変換が起こらないケースもありますが、特に理由がない限りは使わないと思っていいでしょう。 assertSame では assertEquals の代わりに何を使うかというと、この assertSame です。型も含めた比較が行われます。 PHPUnit 初心者なら、とりあえずこれさえ知っていれば何とかなります。 $this- > assertSame('hoge', 'hoge'); // OK $this- > assertSame(0, 0); // OK $this- > assertSame(false, false); // OK $this- > assertSame('hoge', 'fuga'); // NG $this- > assertSame(0, false); // NG $this- > assertSame(7, '7'); // NG assertTrue, assertFalse, assertNull それぞれ true , false , null と等しいことを判定します。型変換は行われません。つまり、以下の2つはほぼ同等です。 $this- > assertTrue($actualValue); $this- > assertSame(true, $actualValue); どちらでもテストの成功・失敗は変わりませんが、失敗時のメッセージが assertTrue などの方が多少分かりやすくなります。 # assertSame(true, false) のメッセージ Failed asserting that false is identical to true. # assertTrue(false) のメッセージ Failed asserting that false is true. assertCount 配列や countable なオブジェクトの要 素数 を検査します。 assertSame の引数に count() の結果を渡すことでも同じテストはできますが、これもやはり失敗時メッセージが assertCount の方が分かりやすくなっています。 # assertSame(1, count([])) のメッセージ Failed asserting that 0 is identical to 1. # assertCount(1, []) のメッセージ Failed asserting that actual size 0 matches expected size 1. assertStringStartsWith, assertStringEndsWith, assertStringContainsString 文字列の内容を部分一致で検査する アサーション です。同じことを assertSame でやろうと思うと strpos() や substr() を使うことになりますが、これらの アサーション メソッドを利用したほうがテストコード上も意図がわかりやすくなりますね。 // 以下2つは同じ内容のテスト $this- > assertStringStartsWith('foo', $string); $this- > assertSame(0, strpos($string, 'foo')); // 何をテストしたいのかすぐ理解しにくい // 以下2つは同じ内容のテスト $this- > assertStringEndsWith('bar', $string); $this- > assertSame('bar', substr($string, -3)); // これも理解しにくい assertRegExp 文字列が 正規表現 にマッチするか検査します。上記の assertStringContainsString などよりも条件が複雑な場合に使えます。 assertIsXXX, assertInstanceOf 値が配列かどうかを検査するために、 assertTrue(is_array($value)) とする代わりに assertIsArray($value) と書くことができます。 is_array 以外にも is_int , is_numeric , is_string , is_bool , is_callable , is_object など、 is_xxx の関数に対応する アサーション メソッドは一通り用意されています。 また、オブジェクトの型を検査したい場合は assertInstanceOf(SomeClass::class, $value) が使えます。 最後に 今回紹介した アサーション メソッドはごく一部です。 アサーションメソッドの一覧 がマニュアルにあるので、どんなメソッドが用意されているのか、ぜひ一度見てみてください！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 : PHP の== 演算子 に似ていますが、以下の記事で解説されているように、厳密には異なります。 https://qiita.com/aminevsky/items/238b7ed77766a3d3023d

はじめに 初めまして、ntthuatと申します。 ラク スに入社して3年目になりました。時間が過ぎるのは早いですね。 さて、2020年12月末に Flash のサポートが終了するという話は皆さんもご存知かと思います。 今回、私が開発担当している「楽楽精算」で、 Flash の代わりに WebUSB という技術を用いて、 ICカード 履歴を取り込む機能をリリースすることになりました。 この記事ではその WebUSB について試したことを一部ご紹介させていただきます。 はじめに 動作確認環境 WebUSBとは PaSoRi RC-S380/Sのドライバーをインストールする WebUSBの動作確認 おわりに 動作確認環境 以下の環境で WebUSB の動作を確認します。 Windows 10 Google Chrome 83 PaSoRi RC-S380/S WebUSB とは 簡単に言うと、 WebUSB は javascript で書かれている API です。 WebUSB はPCに接続されたUSBデ バイス に Chromium 系ブラウザ（ Chrome など）から直接アクセスすることができる技術です。 USBデ バイス の認識、読み出しなどを行うことができます。 Edgeは Chromium ベースで開発していますのでEdgeでも WebUSB が使用できます。 Chrome のDeveloper Toolsで WebUSB の API を実行してみましょう。 await navigator.usb.requestDevice( { 'filters' : []} ) ドライバーをインストールせずにブラウザ自体のみでUSBデ バイス を認識できます。 今回は PaSoRi RC-S380/S経由で WebUSB の動作を確認しますので PaSoRi RC-S380/Sのドライバーのドライバーが必要です。 PaSoRi RC-S380/Sのドライバーをインストールする ソニー株式会社 | FeliCa | 法人のお客様 | 製品情報 |ソフトウェア開発環境 |ICS-DCWE9 SDK for NFC Web Client | 個人情報取得同意説明 で評価版をダウンロードできます。 Sony サイトでのマニュアルのとおり実行します。 コマンドプロンプト 等で、 NFC ポートソフトウェアを以下のオプションを指定してインストールしてください。 NFCPortWithDriver.exe /WinUSB　 注意点： NFCPortWithDriver.exeをダブルクリックすると、WinUSBを含めないドライバーをインストールしてしまいますので、WinUSBに付けて実行してください。 ドライバーインストールが完了したら、 NFC ポート自己診断(ドライバ切り換え)でWinUSBドライバーに切り換えができます。 WinUSBに切り替えしてください。 WebUSB の動作確認 PaSoRi RC-S380/S経由で ICカード を取り込みを確認しましょう。 ソニー のサポートサイトで提供されているサンプルプログラムを実行してみます。 サンプルプログラムの ソースコード につきましては、詳しくは Sony サイトでご覧ください。 PaSoRi RC-S380/SをPCに繋げてExecuteボタンをクリックすると、デ バイス を選択するダイアログが出て、RC-S380/Sを認識して ICカード 履歴を読み取りできます。 実行結果は以下のようです。 レスポンスのデータはhexのフォーマットですが、分析して日付や距離、金額などを取得できます。 おわりに Flash のドアーが閉まると WebUSB のドアーが開かれますね。(^_^) WebUSB でブラウザからUSBデ バイス を読取りできて素晴らしかったです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめまして。新規サービスの開発チームに所属しているkarabishです。 前から気になっていた Grafana Loki をローカルで試してみました。 Grafana Lokiはログ集約システムで、似たものとしては Elasticsearch や Splunk になるのかと思います。 公式ドキュメントでも Elasticsearch との 比較 が記載されています。 環境構築 1. ロギングプラグインのインストール 2. docker-compose.ymlにLokiを追加 3. docker-composeの起動 ログの閲覧と検索 初期設定 ログの閲覧 最後に 環境構築 今回は、 docker-compose でローカルにLokiを構築した手順になります。 PostgreSQL のログを転送させるようにしています。 1. ロギング プラグイン のインストール PostgreSQL のログをLokiに直接転送するためにdocker pluginをインストールします。 docker pluginについては Docker Driver Client に記載されています。 $ docker plugin install grafana/loki-docker-driver:latest --alias loki --grant-all-permissions latest: Pulling from grafana/loki-docker-driver 0974501310e6: Download complete Digest: sha256:436fb0e17e7dde023398b539b03d91d902d5293da199a6ef6bb0b8262b8801e7 Status: Downloaded newer image for grafana/loki-docker-driver:latest Installed plugin grafana/loki-docker-driver:latest $ 2. docker-compose.ymlにLokiを追加 ドキュメント に紹介されていたdocker-compose.ymlを参考に記載したものです。 PostgreSQL のログをLokiに転送するためにloggingプロパティでLokiの接続情報を記載しています。 version: "3.8" networks: loki: services: postgres: image: postgres:12.3 container_name: postgresql ports: - 5432:5432 environment: - POSTGRES_USER=postgres - POSTGRES_PASSWORD=postgres - POSTGRES_DB=sample restart: always logging: driver: loki options: loki-url: http://localhost:3100/loki/api/v1/push volumes: - postgresdata:/var/lib/postgresql/data loki: image: grafana/loki:1.5.0 container_name: loki ports: - 3100:3100 command: -config.file=/etc/loki/local-config.yaml networks: - loki grafana: image: grafana/grafana:master container_name: grafana ports: - 3000:3000 networks: - loki volumes: postgresdata: driver: local 3. docker-composeの起動 $ docker-compose up -d Creating network "grafana-loki_default" with the default driver Creating network "grafana-loki_loki" with the default driver Creating volume "grafana-loki_postgresdata" with local driver Creating loki ... done Creating grafana ... done Creating postgresql ... done $ ログの閲覧と検索 初期設定 Grafanaにログインします。 URLは http://localhost:3000/ です。 初回はEmail or username: admin 、Password: admin でログインできます。 Add your first data sourceからLokiを選択して、URL欄に http://loki:3100 を入力の上、[Save＆Test]ボタンを押せば初期設定は完了です。 ログの閲覧 サイドメニューからExploreにアクセスします。あとは、Log lablesを設定するとログが閲覧できます。 下の画像は container_name ラベルで postgresql コンテナのログを閲覧した結果です。 最後に 比較的少ない作業で PostgreSQL のログをLokiで集約してGrafanaで閲覧するまでの構築はできました。 PostgreSQL のログを見るだけであれば docker logs で問題ないのですが、他のログもあわせてみたい時があるので今後は集約するログを増やしていければと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

皆さんこんにちは。 ラク スのフジサワです。 以前、TypeScriptを始める前は 「学習コストが高そう」「今動いているサービスに導入するのは難しいんだろうなあ」 というイメージが強かったのですが、なんてことはなく、タイトルにある通り、 「TypeScript使わないという選択肢なくね？むしろレガシーなアプリケーションこそ、使っていくべきじゃね？」 と手のひらがグリングリン回転したので、ぜひ皆さんに紹介させてもらいたいと思い、この記事を書くことにしました。 TypeScriptとは Microsoft 製のAltJS( JavaScript の代替となるもの）で、 OSS で開発されている 静的型付き言語で、直感的にいえば「 JavaScript ＋型」 TypeScript コンパイラ や、webpack、Babelなどで JavaScript にトランスパイルして使用する フロントエンド（ブラウザ）、バックエンド（Node.js）双方の開発で活用できる 理由① 『TypeScriptは JavaScript のスーパーセットである』 これは、 公式サイト の冒頭に出てくる言葉なのですが、ちょっと何言ってるか分からないですよね。 簡単にいうと、 「TypeScriptは JavaScript の上位互換であり、 JavaScript の文法・知識がそのまま適用できるよ」 ということを言っています。 もちろん、TypeScript固有の言語仕様や、便利な使い方などは存在するのですが、それを習得していなくてもTypeScriptを利用することができます。 もっと言えば、「 JavaScript と思って使うこともできるし、必要に応じてTypeScriptならではの機能を使うこともできる」と表現できます。 理由②　 型推論 の恩恵により型に対する安全性を獲得できる 型推論 とは、変数や関数 シグネチャ の型を明示的に宣言しなくても、初期化の際に代入する値や、関数呼び出しの実引数などの情報や文脈から、自動的に型を推測して決定する仕組みのことを言います。 これにより、いちいち型を書くと冗長な記述になりがちな型システムによる安全性を享受しながら、冗長さを回避したシンプルな記述ができると言われています。 ※なお、 型推論 については賛否があり、 型推論 を活かしたコードは、明示的に型が表現されないので、予想外の推論結果になったり、逆にわかりにくくなってしまうという意見もあります。 TypeScriptの 型推論 がなぜレガシーコードにとって重要なのか？ 前述の通り、TypeScriptの 型推論 の機能によって、既存の JavaScript コードが型宣言を行っていなくても、型を推測し、 コンパイル 時に適切にチェックを行ってくれるようになります。 これは、「もともと型の概念が存在していないコード」であったとしても、部分的に型安全を保っていくことができるということを意味しています。 コードの具体例をいくつか挙げながら、どのように 型推論 が行われ、 コンパイル 時の型チェックに利用されるかを紹介します。 TypeScriptにおける 型推論 の例 例1 : let/const let foo = 'hello' ; // 明示的に指定していないが、fooはstringであると認識される foo = 1; // コンパイルエラー console.log(foo); 1行目でfooは string であることがわかっているので、2行目の number 型の値を代入しようとするとエラーになる 例2 : return値① function someFunc() { return 100; // 明示的に指定していないが、返却値はnumberであると認識される } let message: string = someFunc(); // コンパイルエラー someFuncの戻り値が number であることが分かっているので、 string 型の値への代入が コンパイル エラーになる 例3 : return値② function multi(a: number, b:number) { return a * b; //number * number = number } 引数が number なので、演算結果も number であると推論される 例4 : 配列 let foo = [ 0, 1, 2 ] // foo: number[]と推論 let bar = [ 0, 1, 'aaa' ] // bar: (number | string)と推論 例5 : Object const user = { name: 'Taro' , // name: stringと推論 age: 20 // age: numberと推論 } /* 以下の型を持つオブジェクトであることが推測される const user: { name: string; age: number; } */ JSON let data = [ { "id" : 100, "name" : "Taro" } , { "id" : 101, "name" : "Hanako" } ] /* 以下の型を持つオブジェクトであることが推測される let data: { id: number; name: string; }[] */ レガシーコードが、TypeScriptの導入によって恩恵を得るサンプル 下記のようなコードがすでにシステム上に実装されているコードだとします。 function someFunc(foo) { if (foo > 0) { return foo * 2; } } var bar = someFunc(1); console.log(bar.toString()); もちろん、この JavaScript は問題なく動作しますが、このコードには一つの問題が潜んでいます。 パラメータに負値を渡すとどうなるでしょうか。 var baz = someFunc(-1); // 負の値を渡すとundefinedが帰ってくる console.log(baz.toString()); baz.toString() は、 baz が undefined なので、ランタイムエラーが発生します。 しかし、これは実行しなければ検出することができません。 では、これをTypeScript環境で コンパイル するとどうなるでしょうか？ コンパイル エラーが発生する var baz = someFunc(-1); console.log(baz.toString()); // コンパイルエラー：Object is possibly 'undefined'. コンパイラ がコードを解析して 型推論 した結果は次の通りとなり、 number または undefined を返すメソッドであると認識されます。 function someFunc(foo: any): number | undefined someFunc は undefined を返す可能性があるため、その返却値を代入している baz に対する操作が危険であることを、 コンパイラ が教えてくれるようになります。 someFuncを安全に使用するには、次のようなコードに修正する必要があります。 var bar = someFunc(-1); if (bar === undefined ) { 　 // undefinedのチェック bar = 0; } console.log(bar.toString()); 上記のように記述すれば、 コンパイル エラーは起きなくなります。 bar === undefined のチェックがあることで、 toString が実行されるタイミングでは number しか到達しないことをTypeScriptが理解するようになるからです。 ※なお、このような型の絞り込み処理を「型ガード」と呼びます。 先程は someFunc を使う側のコードの問題をTypeScriptが検出してくれる例を見ましたが、実は someFunc 自体にも問題が潜んでいます。 コンパイル 時のオプション noImplicitReturns を有効にすると、次のような コンパイル エラーが発生する function someFunc(foo) { // コンパイルエラー：Not all code paths return a value. if (foo > 0) { return foo * 2; } } someFunc がすべてのパスで返却値を返しておらず、意図しないundefinedを返す可能性を教えてくれるようになります。 このように、既存コードに型宣言など、型の情報を与えていないにもかかわらず、 型推論 によって未然に不具合を検出することができるようになったのが分かるかと思います。 理由③　 JavaScript ライブラリとの連携が容易である レガシーなシステムにはすでにたくさんの JavaScript で記述されたライブラリが使用されています。 TypeScriptには、こうした JavaScript ライブラリとうまく連携する仕組みが備わっています。 JavaScript で記述されたライブラリをTypeScriptに導入する方法はいくつか存在します。 型宣言ファイルを自作する DefinitelyTypedで公開されている型定義ファイルを使用する allowJSオプションを活用する 型宣言ファイル（d.tsファイル）を自作する方法 「型宣言ファイル」を作成し、TypeScriptにライブラリの型情報を伝えることで実現する方法です。 例えば、次のような JavaScript で記述されたライブラリ calc.js があるとします。 // calc.js exports.sub = function (a, b) { return a - b; } このライブラリを利用するには、次のような型宣言ファイルを作成して配置することで実現可能です。 ※今回の例では、tsファイルと同じ ディレクト リに配置するようにしています。 // calc.d.ts export function sub(a: number, b: number): number; これにより、 exec.ts は calc.d.ts を通して sub 関数を認識することができ、 コンパイル が通るようになります。 // exec.ts import { sub } from "./calc" ; console.log(sub(100, 1)); 型宣言ファイルの定義に基づき、 コンパイル 時に 型推論 や型チェックが行われるようになります。 もちろん、 IDE にも認識されるのでコード補完なども有効になります。 DefinitelyTyped（@types）で公開されている型定義ファイルを使用する方法 jQuery やChart.jsといったライブラリをTypeScriptに導入する際にも、この「型宣言ファイル」が必要になります。 しかし、規模の大きなライブラリに対して、先ほどの例のようにこれを自分で作成するのは骨が折れる作業です。 これに対し、DefinitelyTyped( http://definitelytyped.org/ )というコミュニティプロジェクトが存在しており、ここには JavaScript で記述されたライブラリの型宣言ファイルが集まっています。 ※あくまでコミュニティによる OSS なので、最新バージョンに追従していない、正しくないという場合も無くはないので注意が必要です。 DefinitelyTypedに対象のライブラリの型宣言ファイルが存在するかは、TypeSearch（ https://microsoft.github.io/TypeSearch/ ） で検索することができます。 DefinitelyTypedに登録されている型宣言ファイルは、npmコマンドでプロジェクトに取り込むことができます。 npm install --save @types/jquery jQuery の型定義が導入された状態で、 jQuery の addClass メソッドを記述してみましょう。 $( function () { $( '#foo' ).addClass( 'bar' ); } ); TypeScriptが jQuery のメソッドを認識しているので、上記のコードは コンパイル エラーにはなりません。 では、ここで、 addClass の引数に数値を渡してみましょう。 $( function () { $( '#foo' ).addClass(1); } ); すると、下記のような コンパイル エラーが発生するようになります。 Argument of type '1' is not assignable to parameter of type 'string | string[] | ((this: HTMLElement, index: number, currentClassName: string) => string)'. 上記から、 jQuery が提供する関数の型定義が正しく認識されていることがわかります。 allowJSオプションを使用する方法 JavaScript で記述されたライブラリをTypeScriptに導入するには、 allowJS オプションを有効にする方法もあります。 ※通常は.ts拡張子のみ コンパイル され、.js拡張子のファイルは コンパイル の対象にはなりませんが、このオプションを有効にすることで、.jsファイルも コンパイル の対象にすることができます。 $ tsc --allowJS calc.js exec.ts ただし、素の状態の JavaScript は型の情報が与えられていないため、かなり緩い 型推論 結果になることに注意してください。 // calc.js exports.sub = function (a, b) { return a - b; } /* 推論されたシグネチャ sub(a: any, b: any): number */ しかしながら、もともと型の概念を持っていなかったレガシーなライブラリが、「ただ読み込ませただけ」で、多少なりとも型による安全性の能力を手に入れることができていることが注目すべきポイントです。 JSDocによって型定義をすることも可能 下記のようにJSDocを記述すると、詳細に型の定義を行うことができます。 /** * @param {number} a * @param {number} b * @return number */ exports.sub = function (a, b) { return a - b; } /* 推論されたシグネチャ sub(a: number, b: number): number */ ただ読み込ませるだけで 型推論 の恩恵を得ることができる、だけでも十分であることはすでに述べた通りですが、既存プロジェクトがきっちりとJSDocが記述している環境であれば、TypeScriptへの移行はなおさら恩恵を得やすいと言えるでしょう。 どの方法を採用すれば良いのか？ ここまで紹介した、既存のJSライブラリをTypeScript環境に導入する方法は、それぞれにメリット・デメリットがあるので、プロジェクトの状況に応じて使い分けるのが良いと思います。 型宣言ファイルについては、ライブラリ自身が型宣言ファイルを公開している場合もあります。 まずはライブラリ公式、もしくはDefinitelyTyped上のものを探し、存在していない場合はallowJSオプションを使用して、徐々に型宣言ファイルを作る、もしくはライブラリ側をTypeScript仕様に変える、というアプローチが良いのではないでしょうか。 理由④　段階的なTypeScript化を助ける コンパイル オプションがある TypeScriptには、 コンパイル 時のチェック内容を柔軟に変えることができるオプションが備わっています。 これらを使用することで、プロジェクトの状況に合わせたTypeScript導入を行うことができます。 noImplicitAny 暗黙的に 型推論 の結果 any 型となった場合に コンパイル エラーにするオプション OFFにすることで、暗黙的な any を許容できる 明示的に型指定を行わない場合、メソッドの引数などは any 型になる any 型は、その名前の通り「なんでもあり」の型なので、あまり良いものではなく、 any 型を避けるのが望ましい ただし、もともと JavaScript で記述されているコードについては、一旦このオプションをOFFにしておいて、 コンパイル エラーを目印に、徐々に型指定を増やしていくのが良いと思われる strictNullChecks null型、undefined型にのみ、 null 、 undefined の代入を許可する設定 null型： null のみを許容する特殊な型 undefined型： undefined のみを許容する特殊な型 T | null 型と null 型は別物と扱われ、T | null 型には null を代入できない これにより、意図しない undefined や、意図しない null を防ぐことができる noImplicitAny同様、最初はオプションをOFFにしておき、ONにした時に見つかる コンパイル エラーを徐々に修正すると良いと思われる ずさんなコードの匂いを検出してくれる便利な コンパイル オプション noUnusedLocals 未使用のローカル変数があるとエラーになる noUnusedParameters 未使用の引数があるとエラーになる noImplicitReturns 既出。メソッド内の全てのパスでreturn文が無い場合エラーになる noFallthroughCasesInSwitch Switch文内におけるbreak漏れがエラーになる まとめ：TypeScriptは、 JavaScript プロジェクトからうまく移行する環境が整っている TypeScriptは JavaScript のスーパーセットなので、既存のコードをそのまま使うことができる 型推論 によって、ただの JavaScript が型の力を手に入れることができる JavaScript で記述された既存資産を柔軟に組み入れる仕組みやそれを支えるコミュニティが存在する 柔軟な コンパイル オプションによって、レガシーなコードを段階的に厳密なコードに変えていくことができる おわりに TypeScriptの導入がいかに容易で、かつどれだけメリットがあるかをこの記事で紹介させて頂きました。 この記事をご覧になった方で、TypeScript導入に及び腰の方がいらっしゃいましたら、ぜひトライしてみて頂ければ幸いです！ 参考文献 本記事執筆にあたり、私が学習に使用した書籍を下記に紹介します。 速習TypeScript まずTypeScriptを「完全に理解した」状態にするのにおすすめ 速習TypeScript: altJSのデファクトスタンダートを素早く学ぶ！ 速習シリーズ 作者: 山田祥寛 WINGSプロジェクト Amazon 実践TypeScript 型やTypeScriptの便利な機能について詳しく書かれているので、「完全に理解した」状態から「色々わかってないことに気づくフェーズ」にちょうどよい 後半にReactやVue、Node.jsに導入する際の実践例の記載もあるので、名前の通り実践向き 実践TypeScript 作者: 吉井 健文 マイナビ出版 Amazon TypeScript実践プログラミング 上記２冊より広い分野の話が書かれており、知識の補完に便利でした TypeScript実践プログラミング (Programmer's SELECTION) 作者: スティーブ・フェントン 翔泳社 Amazon エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに こんにちは、 @rs_tukki です。 新型コロナウイルス の影響で大分ドタバタしていましたが、弊社ではようやく社員研修を終えた新卒社員の配属の話が本格化してきました。 新しい開発メンバーを受け入れるとき、まずやってもらうのは部署ごとの開発フローと、実際に開発するプロダクトの中身を学んでもらうことかと思います。 そこで今回は、その2点を一気に解決できる「実装過去問」について話していきたいと思います。 はじめに 実装過去問とは 実装過去問の実施手順 問題集から取り組む問題を決める プロジェクトのgitブランチから、問題を修正する前のブランチをcheckoutする 問題を解き、テスト項目書に沿ってテストを行う レビュー担当者がレビューを行う 過去問を行うメリット まとめ おまけ 実装過去問とは 実装過去問とは、私たちの部署で採用している学習プログラムの1つで、 簡単に言うと「そのプロダクトで実装された機能を学習のために後追いで実装してみる」というものです。 一般的に過去問というと、入学試験や資格試験で過去に出題された問題を集めたものですが、 この学習プログラムも「過去に開発された内容を」「いくつか抜粋して」「練習のために」やってみるという点から、過去問という名前がついています。 実装過去問の実施手順 では、実際に過去問を行う手順を紹介します。 問題集から取り組む問題を決める まずは、あらかじめドキュメント化されている過去問の中から、どの問題に取り組むかを決めます。 問題は現時点で27問用意されており、各問題に対して☆1～☆5までの難易度が振られています。 ☆1や☆2の問題は簡単なUIやUXバグの修正ですが、☆5は実装方法から悩まされるような難問。 この難易度は最初は問題作成者の主観によるものですが、過去問に取り組んだ人の感想次第で修正されたりします。 中には当初☆3だったものが☆5に引き上げられた事例も… 新規メンバーは☆3の問題から取り組んでもらい、合格(後述)なら☆4の問題へ、不合格なら同じ☆3または☆2の問題へ移ります。 そうして、☆4の問題に合格するのがひとまずの目標です。 プロジェクトのgitブランチから、問題を修正する前のブランチをcheckoutする 各問題のドキュメントには、実装内容・設計書のリンク・派生元のブランチ・制限時間などが記載されています。 私たちの部署が開発してるプロダクトは、gitでリリースバージョンごとにブランチを作成しているので、 その機能が実装される直前のリリースブランチをcheckoutすることで、修正後の実装を見ることなく後追いの実装が可能になっています。 問題を解き、テスト項目書に沿ってテストを行う あとは、設計書の通り、checkoutしたブランチに実装をしていくだけです。 このとき注意点として、以下の制限があります。要するに カンニング はNG ということです。 リリース済みの既存コードを参照することは禁止 既存コードをテスト環境で動かしてみて動作確認するのはOK 誰かにアド バイス を求めることはOKだが、実装方法を直接尋ねることは禁止 設計書などのドキュメントを参照することはOKだが、実際のPRを参照することは禁止 全て実装が終わったら、実装した人本人がテスト項目書を見ながらテストを実施します。 全ての項目をテストする必要はありませんが、当然この後レビューがありますので、そこでミスが出ないようテストはしっかり行う必要があります。 レビュー担当者がレビューを行う 実装とテストが終わったら、その内容をgitにpushしてPRを作成し、レビューを依頼します。 このときのレビュー担当者は、その過去問を解いたことがあるメンバーが実施することが多いです。 過去問ごとにレビューの観点もドキュメント化されており、PRの内容がその観点を満たせていれば晴れて合格となります。 過去問を行うメリット 過去問を行うメリットですが、 Wikipedia の 過去問題集 というページには以下のように記載されています。 ある試験を受けるにあたって過去問を解くことは、次の意味で利点がある。 試験の合否ラインと比較する形で、自分の力を測ることができる。 実際の試験問題を解く方法を直接的に身に付けることができる。 資格試験の場合は過去に出題された問題がそのまま出題されることがある。 入学試験の場合は全く同じ問題は出題されないものの、よく似た問題が出題される。（まれに出題傾向が一定でない学校もある） 早い時期に解いておくと、自分の不足している部分を把握し、その後の勉強の方針を立てることができる。 試験問題は比較的良い問題であることが多いため、他の問題を解く場合に比べて効率的に、自分の理解や知識を深めることができる。 多くの場合、問題の出題範囲が幅広くばらけているため、全体の理解度や到達度について、限られた時間で把握することができる。 入試や資格試験の過去問と違い、実装過去問では当然全てが当てはまるわけではありませんが、 実際の開発業務でやることになる問題に取り組むことで自分の力を測れる 本番のフローに則って取り組むので開発の練習になる 様々な傾向の問題があるため、実際の業務で必要となる知識を効率よく理解することができる といった点は共通しているかと思います。 まとめ 今回は、新規メンバーの受け入れに最適な「実装過去問」について解説しました。 メンバーを入れ替えながら長く開発と改修を続けていくプロジェクトでは必ず役に立つと思いますので、ぜひ取り入れてみてはいかがでしょうか。 おまけ 先日、弊社のオンラインイベントで発表する機会がありました。 SaaS の開発原則である「Twelve-Factor App」について語った内容で、資料もアップロードしていますのでぜひご覧になってみてください。 rakus.connpass.com speakerdeck.com

はじめに 技術広報のitoken1013です。こんにちは。 定期開催させていただいています ラク スMeetup、2月に大阪で盛況でした 『 SaaS を支える開発原則/DDD、 心理的 安全性、Twelve-Factor』 をテーマに、登壇者と発表内容を新たに刷新して6/24(水)に開催しました。 今回で2回目のオンライン開催となりましたが、60名の方にご参加いただき（満員！）、 Twitter や Zoom上にはコメントが溢れる盛況のイベントとなりました。 今回は当日の発表をご紹介させていただきます！ rakus.connpass.com イベントテーマ概要 ソフトウェア開発には様々な原則・法則が存在します。 これらの開発原則が ラク スの SaaS 開発でどのように活かされているか、開発チームで主要な役割を担う若手・中堅・ベテランの3名のエンジニアから紹介させていただきました。 SaaS 開発ならではの原則、拡大する開発規模を乗り越えるための原則、新たなサービス開発で ドメイン イベントを活用するための取り組みなど、幅広い内容となりました。 発表の紹介 Twelve-Factor Appで読み解く、モダンなアプリの理想とレガシーなアプリの現実 多くの方々に ラク スを知っていただくきっかけとなりました 楽楽精算 。 この楽楽精算の開発チームで活躍する矢須より、 Twelve-Factor App に存在する4つの原則を紹介させていただきました。 2009年にリリースされた楽楽精算は Twelve-Factor App よりも長い歴史を持つサービスですが、Twelve-Factor Appに存在する原則との共通点と現状のギャップに触れつつ、理想的なWebアプリケーションの姿を解説しています。 speakerdeck.com 開発グループが開発チームになるまでの歩み 同じく楽楽精算においてPMを務める紀井が紹介するのは、以下の3つの原則です。 2年間で急速に規模が拡大した楽楽精算の開発チームを軌道に乗せるために、紀井が挑戦した取り組みを紹介させていただきました。 OODAループ 心理的安全性 銀の弾などない 発表では大きく3ステージに渡る課題が取り上げられましたが、どのステージでの挑戦も参加者の皆様に共感いただける登壇となりました。 speakerdeck.com 紀井の登壇については、別途logmiでも紹介しております。 ぜひ当日の発表内容をご覧いただければと思います。 logmi.jp 結果整合性ができない開発者の ドメイン イベント活用例 ラク スの数々のサービスを成功に導いてきた峰村が紹介しましたのは、 DDD （ ドメイン イベント、集約）と 結果整合性 です。 ドメイン イベントとは、 ドメイン 内で発生する「○○したら××になる」といった出来事を表現する ドメイン モデルです。 今回は峰村がリードエンジニアとして取り組む新規サービスの開発で ドメイン イベントを活用した知見を、実例を交えて紹介させていただきました。 ドメイン イベントを導入することで得られるメリットの他、導入のための困難、そしてチームに ドメイン イベントを定着させるための取り組みを紹介させていただいています。 speakerdeck.com おわりに 多くの方に数々の共感をいただけました ラク スMeetup、ご参加いただきました皆様、ありがとうございました。 ラク スでは7月・8月もMeetupやLT・勉強会を開催予定です。 今後もエンジニアの皆様へ有益な情報を発信する場にしていければと思いますので、 どうぞ引き続きよろしくお願いいたします！ rakus.connpass.com rakus.connpass.com

はじめに こんにちは、MasaKuです。 昨今、 コロナウイルス の影響により、オフラインで開催される勉強会が自粛の流れになっており、逆にオンライン開催される勉強会が増えてきていると思います。 そこで先日、以下のイベントに参加しましたので、参加した感想について述べていきたいと思います。 nrs-seminar.connpass.com YouTube Live のアーカイブはこちら はじめに 参加したイベント 参加動機 感想 コード理解はまず全容把握から 図解はやはり強力 コードのわかりやすさも重要だがディレクトリ構造はもっと重要 PHPのマジックメソッドはコードリーディングにおいてかなり曲者になる 参加者のコメントもインプットになる おわりに 参加したイベント ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本 の著者 成瀬允宣さん主催のオンライン勉強会ということで、 他人がどんな風にコードを読んでいくか を知ることを目的とした勉強会です。 今回は、 PHP フレームワーク の Laravel の内部を見ていこうという趣旨のコードリーディングでした。 なお、今回の フレームワーク 読解の目標としては 「自作 フレームワーク を作るために参考にする」 という体で進められていました。 www.shoeisha.co.jp 参加動機 そもそも、なぜ私がこの勉強会に参加しようと思ったのかをご説明しようと思います。 ほかの人がどのようにしてコードを読んでいるのか単純に興味がある 人気の フレームワーク の中身を読んでみたいけど、一人で読んでいると行き詰ってしまう Eloquent (Laravel の標準ORM)のソースを軽く読んだことはあるが、 フレームワーク の全容を意識して読んだことはなかった フレームワーク を読み進める上でのテクニックを吸収したい 定石パターンなどがあれば今後ソースの読み書きをする上でも参考になりそう ちなみに、主催の成瀬さんについてですが、2019年のPHPerKaigiの際にアンカンファレンスにて発表されていた内容が非常に興味深かったことを覚えています。 そのことがきっかけでまたお話を伺いたいなと思ったことも動機の一つです。 （2019年のPHPerKaigi のイベントレポートは以下） tech-blog.rakus.co.jp 感想 コード理解はまず全容把握から コードを追いかけるスピードはさることながら、コードを読むテクニックについても勉強させていただきました。 例えば、 フレームワーク の様な全容の大きいプログラムは、一度にすべてを丁寧に読み込んでいこうとするのではなく、 まずは全体を眺める ことが大事です。 「この変数にはどういう値が入っていて、どういうメソッドに渡されて、ここでオブジェクトに格納されているプロパティを取得して・・・」などということをすべて頭に入れながら読み進めていくと、間違いなくオーバーフローを起こして思考が停止してしまいます。 なので、まずはざっくりと全体の流れを把握して、それから、気になるところを読み返していく、という読み方が良いそうです。 この点に関しては、私も業務で開発しているプログラムを読み進めていく際に気を付けているポイントだったので、自分の進め方が大きく間違っていないことに安心しました。 いくつもの業務ロジックが関連するような処理を読み込んでいく際は、最初から細かに処理を追いかけるのではなく、ざっと処理の流れを把握してから細かい仕様を確認するようにしています。 全容がわかっていれば各処理の細かい仕様がなぜそうなっているのかも紐づけて考えやすいと思います。 図解はやはり強力 また、 フレームワーク の全容理解を進める上では、 図解するのが一番良い と思いました。 Laravelにはリク エス ト情報をコントローラに渡す前やViewに返す前に Middleware という処理を追加できます。 この仕様については把握していたのですが、何となく把握していたことを図解してもらえるだけで、Middleware が フレームワーク のどのような位置でどのような処理をしてるのかが、より詳しく理解できたような気がしました。 自分の理解を振り返るためにも、図解しておくことは強力な理解促進につながると思います。 コードのわかりやすさも重要だが ディレクト リ構造はもっと重要 フレームワーク ではアプリケーション開発で必要になる様々な処理を実現するために、各機能を適切な粒度でグルーピングして ディレクト リを切って管理しています。 配置するプログラムがきちんとグルーピングされた ディレクト リに管理されていると、とある処理を追いかけていた際にたまたま見つけた特定処理に関連するパーツがどこで管理されているかも分かりやすくなります。 もちろん、コード内からジャンプして、 参照元 へどんどんたどっていくこともできますが、関連する処理がどこにあるのかがわかっていると、リファレンスを読まなくても フレームワーク が行っているその他の処理を知るきっかけにもなります。 逆に、 ディレクト リ構成が支離滅裂でどこに何が配置されているのかがわかりにくい状態になっていると処理を追いかける際の可読性を下げてしまうばかりでなく、管理も煩雑になってしまって保守性も低下してしまうでしょう。 PHP のマジックメソッドはコードリーディングにおいてかなり曲者になる PHP には マジックメソッド という特殊なメソッドがあります。 中でも __call() や __callStatic() はコードリーディングを難解にさせるマジックメソッドの一つです。 例えば __callStatic() は、オブジェクト内の静的メソッドを呼び出そうとする際に、アクセス 不能 な場合に実行されるメソッドです。 <?php // 以下サンプルコード class MagicMethodTest { public static function __callStatic ( $ name , $ arguments ) { echo "あなたが呼び出したメソッドは ' $ name ' " . implode ( ', ' , $ arguments ) . " \n " ; } } MagicMethodTest :: runMethod ( '引数１' , '引数２' ) ; // 実行結果 // あたなが呼び出したメソッドは 'runMethod' 引数１, 引数２ フレームワーク ではこうしたメソッドが頻繁に登場するようなのですが、普段のアプリケーション開発時はあまり目にする機会が少ないだけに、一瞬思考が止まっていしまいます。 しかし、主催者の方や参加者の方々と、まるで ペアプロ しているかのように読み進めていくことで、マジックメソッドの意味を冷静に考えながら読み進めていくことができます。 参加者のコメントもインプットになる 今回のイベントは YouTube Live で公開されていたため、他の参加者の方のコメントを読むこともできました。 コメントの中には自分と同じようなことを感じながらコードを読み進めている方がいらっしゃったり、別視点の深い内容のことをコメントされている方がいて、コードリーディングのモチベーションを高めながら参加することができました。 （参加者の中にはLaravelに非常にお詳しい方も参加されていたようで、鋭いコメントをされる方もいらっしゃいました。） 参加者間のコミュニケーションが活発であったことも非常に印象的で、終始途切れることなくコメントが流れていました。 おわりに 今回、オンラインのコードリーディングに参加させていただき、他の人がどのようにコードを読み進めているのかを拝見することができました。 フレームワーク のような巨大なコードを読む上では、まずはざっと全容を把握してから、細かいポイントを振り返って理解しながら読み進めていくべきだと思いました。 振り返っていくときのポイントとして、とある処理で利用されるクラスには他にどのようなメソッドがあるのか、というところまで視野を広げることで、 フレームワーク が実現できる他の処理を知るきっかけにもなることを理解しました。 これらをスマートに進めるためにも、 ディレクト リ構成をしっかりとルール付けして、正しく管理しておくことが重要です。 これらのノウハウは業務で開発しているプログラムを読み込む際にも使えるテクニックだと思いました。 例えば、ドツボにはまってしまって、同じところをグルグル読み返してしまう、なんてことが起きないようにするための方法として、いろいろと参考になることを得られたかなと思いました。 次回の開催も楽しみです！ なお、弊社 ラク スでもオンラインで PHP の勉強会を開催しています。 LaravelについてもLTなどで過去に何度か話題になっていますので、ご参加いただけると幸いです。 rakus.connpass.com

はじめに 技術広報のitoken1013です。こんにちは。 今回は Scrum Fest Osaka 2020 に登壇しました新卒エンジニアの 樋口（@YokoHiguchi1） からの登壇レポートを紹介させていただきます！ confengine.com ふりかえりが重要ではない！？~ふりかえりの活用方法について~ from ssusera3f4f9 www.slideshare.net はじめに Scrum Fest Osaka 2020について 樋口のイベント後記 今回のイベントに登壇しようと考えたきっかけ 発表テーマ「ふりかえりが重要ではない！？ふりかえりの活用方法について」を選んだ理由 初めてのオンライン登壇 今回の登壇を通じた学び・発見 終わりに Scrum Fest Osaka 2020について スクラム の初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場 として毎年開催されているScrum Fest、今年は初のオンライン開催となりました。 当日はDiscord上で運営が行われ、登壇者はZoomから発表を行う形式でした。 www.scrumosaka.org イベント詳細はこちらで紹介していますので、参考にしていただければと思います。 ちなみに ラク スもスポンサーとして、イベント協賛をさせていただいておりました。 tech-blog.rakus.co.jp 樋口のイベント後記 今回のイベントに登壇しようと考えたきっかけ 今回Scrum Fest に登壇しようとした"きっかけ"は 自分で得たものをアウトプットすることで、悩んでいる人でも、何かを感じてほしい と思ったからです。 以前の私は スクラム に関わらず、「ふりかえり」と呼べるもの全てに対して何故必要なのか、そもそも「ふりかえり」が何なのか分からない状態でした。 でも、分からないと思ったものは自分の中に落とし込むことが大事と考え、様々な人と会話してアウトプット・インプットを繰り返し、自分にとってふりかえりとは何かを考えてきました。 その際に得たものはきっと自分だけのものではないし、私のように悩んでいる人がいるのなら、私が発信することで何かを感じ取ってもらえるのではないか。 そう思い、登壇を決意しました。 発表テーマ「ふりかえりが重要ではない！？ふりかえりの活用方法について」を選んだ理由 「ふりかえりが重要ではない」という文字が、今回の登壇に至るきっかけでした。 私は合宿イベント LED-Camp の運営に携わっています。 ここでは参加者にふりかえりを重点的に教えたのですが、LED-Camp が終わった後の参加者アンケートの中に「ふりかえりは重要ではないと考えている」と回答がありました。 その回答が私の中に残り、「何故、ふりかえりは重要ではないのだろう？」と考えていたら、ふりかえりは何故必要か、ふりかえりはそもそも何であるか、が私自身も全く分からなくなってしまいました。 この「ふりかえりが重要ではないと考えている」という言葉が ふりかえりとは何かを改めて考える機会となり、このタイトルを選ぼうと決めました。 初めてのオンライン登壇 初めてのオンライン登壇は、ひとことで言うと”楽しかった！”です。 オフラインでは相手の顔を見ることができるため、その場の空気感によって話すスピード等を調整することができますが、オンラインだと１人で喋っている感覚があり、本当に相手に伝わっているのか？という疑問がずっと付きまとい、初めての感覚で最初は不安と緊張しましたが、 とても新鮮でいい経験ができました。 また発表中に参加者の方々からの意見がチャットで見られ、フィードバックをその場で受けるという感じはすごく面白く、その際は オフラインよりも参加者と距離を近くに感じ取れた のがとても良かったです。 今回の登壇を通じた学び・発見 たくさんの学びがあった取り組みでした。 まず登壇が決まってから、私にとってのふりかえりは何かをより一層考えるきっかけにもなり、資料を作成しながらもふりかえりについて考えることもできて、すっごく楽しかったです！ 登壇後は参加者の人達にJamboardの付箋でアウトプットしていただいたのですが、付箋にはびっしり私の話から学んだこと、疑問に思ったことが書かれていました。 それを見て、発表して本当によかったなって。 アウトプットすることの大切さを改めて実感できたイベントでした！ 終わりに 入社間もないタイミングでScrum Festへ挑戦した樋口の取り組み、いかがでしたでしょうか？ 今回樋口が発表しました内容については、7/13(月)に開催される以下のイベントで再演される予定となっています。 ご興味のある方は、是非イベントへご参加いただけますと幸いです。 retrospective.connpass.com 当社はこれからもイベント登壇やブログ発信など、エンジニアのアウトプット活動を活発に行っていきます！

id:radiocat です。6/26、27に開催されたScrum Fest Osaka 2020に参加し、登壇させて頂きました。イベントをレポートします。 Scrum Fest Osaka 2020とは？ どんなイベント？ 会場はDiscord セションはZoom 数々の企業・団体スポンサーが支援 基調講演 ちょっとした「うっ」は成長のチャンス 登壇レポート スクラムちゃうがなと言われてもやってみぃひん？ ふりかえりが重要ではない！？ふりかえりの活用方法について 非秩序を乗りこなすアジャイルなイベントでした Scrum Fest Osaka 2020とは？ www.scrumosaka.org 公式サイトには次のように書かれています。 Scrum Fest Osakaは スクラム の初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。 昨年が初開催で、今回が2回目となるイベントです。前回は2トラックで20以上のセッションが行われ、関西としては スクラム に限らずエンジニア向けイベントとして最大級のイベントです。全国から様々な境遇や立場の人が集まって、それぞれの取り組みや知見を共有しあう、参加者全員の学びの場です。 ちなみに、昨年と今回オンライン開催に変更される前まで会場となる予定だった 関西大学 梅田キャンパス KANDAI MeRISE は弊社の大阪オフィスのすぐ隣です。 どんなイベント？ 登壇者は昨年から公募され、既に決まっていましたが、コロナの影響でオンライン開催に変更となり、全国19コミュニ ティー を集めて各トラック並行で開催されるという異例の内容・規模となりました。19トラックともなると、ご覧のとおり一覧で見ることができない規模です。 19トラックのイベント一覧 オンライン開催ということで、参加者は Discord と Zoom の利用が必須となりました。 会場はDiscord 参加の申込みを行って運営側へDiscordのアカウントを連絡するとイベント専用のDiscordサーバへ招待されます。Discordにはイベントのお知らせや、各種連絡、当日のオープニングや基調講演で使われるメインチャンネル、各コミュニ ティー のチャンネルに加え、雑談、トイレ？、2次会など、参加者が思い思いに参加できる無数のチャンネルがあります。 Discordの画面 イベントの申し込みが終わるとイベント開催の数日前からDiscordに招待され、当日だけでなく準備中の状況なども確認できるようになっていました。もちろん、開催前から参加者同士で交流することができます。そして、開催後の現在も継続して交流可能です。開催当日を軸としつつも、その前後の時間も使って参加者全員でイベントを作り上げていく形が、イベントの新しいスタイルとして、オンラインイベントの可能性を感じることができます。 セションはZoom 開催当日は、セッション開催の時間になるとDiscordのチャンネルにZoomのURLが流れてきます。そこからZoom上で登壇者の発表を聞くという流れです。 セッションの様子 登壇者から聴講者への一方向のセッションだけでなく、オンラインの視聴者を巻き込んだりチャットツールを使ってディスカッションするなど、オンラインでの新たな試みを行っているセッションもありました。 数々の企業・団体スポンサーが支援 アジャイル を実践中の様々な企業・団体がスポンサーとしてイベントを支援しています。弊社もシルバースポンサーとして参加させて頂きました。 スポンサーの紹介 オープニングイベントでしっかり紹介して頂いていました。参加したイベントのスポンサーに自社が名を連ねているのはいつ見ても嬉しいものです。 基調講演 基調講演は アジャイル コーチであり、『SCRUM BOOT CAMP THE BOOK』の共著者としてもおなじみの株式会社アト ラク タの永瀬さんによる『今あえての スクラム 』でした。 真ん中が空いた、縦書きの、変わったスライドになっているのは理由があります。なんと、画面共有でスライドを投影するのではなく、ご本人が真ん中に映りながらバーチャル背景にスライドを投影するというスタイルで発表されたのです！ その様子は参加者だけのお楽しみなのでご紹介できなくて残念ですが、背景に使われたスライドを見ながらなんとなく想像していただければと思います。 ちょっとした「うっ」は成長のチャンス 今回の登壇にあたり、イベントがオンライン開催に変更されたことで最初は「うっ」と思われたとのことです。これは私も登壇させて頂いたのでわかります。オンラインという形で前提が変わって、どのようなセッションを行おうかと戸惑いました。しかし、このような状況にチャレンジすることは成長のチャンスでもあるということです。 スクラム は非秩序な状況を乗りこなすことに適した フレームワーク です。 染み付いた行動の癖で、予見できる範囲でスプリントを回していないか？ ふりかえりでプロブレムに対するトライばかりしていないか？ 行動する前に既存の価値観で判断してしまっていないか？ 変化の時代だからこそチャレンジしてみよう。やってみて、失敗して、学習しよう。そういう内容のセッションでした。そして、前述のように背景にスライドを投影するという発表にチャレンジすることでもそれを伝えていただいた内容だったと思います。この発表を聞くだけでもイベントに参加する価値のある内容でした。 登壇レポート 2日目は19トラックに分かれて各セッションが行われました。セッションだけでなく、各コミュニ ティー のDiscordチャンネルでは様々な情報交換がされていてとても賑わっていました。 ちなみに、セッションは録画され（登壇者が承諾した場合）、当日の参加者には約1ヶ月間公開されているので、19トラックの発表を後日ゆっくり見ることができます。アフターイベントとして、録画試聴会なども開催されています。これもオンラインイベントの新たなスタイルです。 最後に、弊社から登壇させて頂いた内容についてレポートさせてください。 スクラム ちゃうがなと言われてもやってみぃひん？ スクラム は理解は容易ですが、習得は困難だと言われています。実際にやろうとすると、思ったとおりできないと感じることが多々あります。特に我々のような中小企業の開発の現場では制約も多く、長年やってきた従来型の 開発プロセス を全て刷新して充分環境を整えてから スクラム を導入できるケースは稀です（もちろん中小企業ではなくても様々な制約はあると思いますが、今回の発表は我々の境遇に視点をあてた内容になっています）。同じ境遇の方々に我々の取り組みが参考になればとの思いで発表させていただきました。 スクラム ちゃうがな問題 少しずつ カイゼン する カイゼン 文化をつくるには、まず スクラム のベースとも言える PDCA を回す状態をつくることです。課題が山積していていることは認識していても、計画を立てて、実行後に振り返る流れが習慣化していなければ カイゼン は進みません。 それができたらチームで開発している状態をつくることに着手します。従来型の 開発プロセス でよくある課題が、縦割りで担当者に業務が アサイ ンされ、隣の人が何をやっているかもわからない状態で仕事をしている状態です。スケジュールマネジメントをしっかり行い、チームとして成果を出せる状態をつくることで、個の活動からチームの活動になり、 カイゼン をチームの文化にする土台ができます。 少しずつ カイゼン する（私たちの場合） ありたい姿を探る カイゼン は進みましたが、いつ スクラム になるかのゴールが見えませんでした。そこでチームとして「中小企業のエンジニアチームを楽にするモデルをつくる」というビジョンを設定し、それに到達するまでのロードマップをつくりました。ロードマップの段階を踏んでいくことで スクラム に近づき、チームのあるべき姿に到達させるのです。 チームのロードマップ 原則を土台にする チームのロードマップをつくって進めていたものの、自分たちの視点に偏っていて顧客視点が持てていないことに気づきました。自分たちの カイゼン を進めてチームをアップデートしても顧客に価値を届けられなければ意味がありません。 アジャイル の原則に立ち返れば当たり前のことができていないと気づいたのです。 原則にむきなおる 経験から学ぶ これらの取り組みから、 カイゼン とありたい姿、原則の土台を3つの柱として経験しながら学ぶことで スクラム に近づくと考えました。これは経験学習というモデルをベースにしています。 経験から学ぶチームで スクラム に近づく 「 スクラム ちゃうがな」から始まる 経験から学ぶモデルの中心には「意欲と信頼」があります。私たちは「 スクラム ちゃうがな」と感じて悩んだとき、何かを変えたいという意欲を持っています。つまり「 スクラム ちゃうがな」と感じたことは経験から学んで スクラム に近づくスタート地点なのです。 スクラム ちゃうがなから始まる オンラインならではのチャレンジ スライドではわかりませんが、イベント当日は途中でネコが合いの手やツッコミを入れる部分を、あらかじめ録音しておいた合成音声を流すことで自問自答する雰囲気を演出してみました。これも私なりのオンラインならではのチャレンジです。 ネコによるツッコミ ふりかえりが重要ではない！？ふりかえりの活用方法について 弊社からもう1名がふりかえりについて発表させて頂きました。発表は参加者と一緒にふりかえりについて考えるスタイルになっており、Discordのチャンネルで様々な意見が共有されていました。これもまたオンラインならではのスタイルです。 retrospective.connpass.com この発表は、再演イベントが企画されていますので内容の紹介は割愛させて頂きます。興味のあるかたはぜひイベントにご参加ください。 非秩序を乗りこなす アジャイル なイベントでした イベント全体を通して、参加者全員で変化に向き合って適応しようと取り組み、みんなでイベントの新しい形をつくりあげていく空気に溢れていました。イベント自体が アジャイル な体験だったと言えます。 オンラインでのこのようなイベントは世界レベルでみてもまだ事例が少ないのではないかと思います。そんな中で最終的に500人以上がDiscordに集まる大盛況のイベントとなったようです。そんなイベントを作り上げた実行委員のみなさんのコメントや裏話が Youtube で公開されていますので合わせてご覧ください。 スクラムフェス大阪 開催中に実行委員が感慨を語る Discordのチャンネルでは現在も様々な情報交換が行われており、その刺激を受けて参加者がそれぞれの現場で次のScrum Festに向けた取り組みをスタートさせています。私たちもまた次回のイベントで採択されるようにチャレンジを続けたいと思っています。 弊社でも様々なオンラインイベントが企画されており、取り組み内容を共有しています。7月末には楽楽明細開発チームの スクラム 事例の発表も予定されています。よろしければぜひご参加ください。 rakus.connpass.com

はじめに 　こんにちは、tuq376sです。今回は最近触り始めたE2Eテストの フレームワーク 、 TestCafe での初歩的な画面操作についてまとめたいと思います。 　というのも、TestCafeはTypeScriptを用いて記述するのですが。 そもそも自分がTypeScriptも初めてかつ、 JavaScript も自信を持ってすらすら書ける！　とは言えないレベルなので、 まずは「こう書けばとりあえず動作する」から覚えていこうという次第です。 　 はじめに アクセス先とテストケース 要素を取得 クリック テキストフィールドへの入力 ファイルアップロード おわりに アクセス先とテストケース 　まずはアクセス先の指定とテストケースの書き方から。 fixture("サンプル").page("https://hogehoge/"); test("テストケース1" , async (t) => { //テスト内容 }); test("テストケース2" , async (t) => { //テスト内容 }); 　 fixture は複数のテストケースをまとめるカテゴリの役割を果たします。 そして続く .page は始めにアクセスするURLを指定しています。 .beforeEach や .afterEach で事前・事後処理を記述することもできるようです。 　実際のテストケースは test で宣言します。実行結果ではこのテストケースごとに成功と失敗が返される形になります。 要素を取得 　ここからの内容は、 test の中で書いていきます。 まずは画面を操作していくために、ページ上の要素を変数に取得していきます。 const button = Selector('input').withAttribute("value","ボタン").nth(0); 　 Selector は指定した要素を取得します。ここにはタグ名だけではなく、class や id も指定することができます。 　 WithAttribute は、属性の名前と値で要素を絞り込みます。リンクやボタンなどであれば、だいたいこれで一意に絞れるのではないかと思います。 　それでも一意にならない時（自分は同じ属性を持った要素が並ぶ一覧画面でつまづきました）、便利なのが nth です。これは条件に一致した要素のうち、上から何番目の要素を取得するかを指定できます。これが素敵なのは、HTML上で何番目になるかが同じであれば、もし属性の値が変更されたとしてもテストコードを書き直さずに済むところです。 クリック 　さて、ようやく画面自体の操作です。 await t.click('#nextLink'); 　クリック操作は click で行います。要素の指定は上記のようにidを直接書いたり、先ほどのSelectorで取得したものを渡したりします。 　ここで指定したものが複数に該当してしまっていると、エラーになってしまいますので注意です。（例えば一つしかボタンがないと思っていたら、実はhidden状態の同じボタンがもう一つ存在してたりとか……ありました） テキストフィールドへの入力 　続いて、テキストフィールドへの入力操作についてです。 const textArea = Selector('input').withAttribute("name","入力場所"); await t.typeText(textArea, "入力したい値"); 　 typeText を用います。Selectorで取得したテキストエリア要素と、入力する値を指定します。 　どうやら指定した要素をクリックしてフォーカスしてから入力を行っているようで、クリックした段階で正しくフォーカスできなかった場合、書き込みは行われないようです。 ファイルアップロード 　最後に、ファイルをアップロードする操作です。 await t.setFilesToUpload(linkInputFile, "ファイルパス"); 　 setFilesToUpload を使って、ファイルを設定する要素とファイルパスを記述します。ファイルパスは [ 'ファイル1', 'ファイル2', 'ファイル3' ] といったように複数を指定することも可能です。 おわりに 　というわけで、これらがわかれば最低限テストケースを作って画面操作してみる、ということはできるはずです。 　テストと言いつつ アサーション には触れられていませんが、そちらはまたもう少し理解できたら、いずれ記事にしてみたいなと思います。

はじめに 技術広報のitoken1013です。こんにちは。 先日6/17(水) 、当社主催のMeetup 『SaaSを支える品質担保術/レガシーコード、アーキテクチャ、EOL』 を開催いたしました。 今や ラク スの恒例行事となりましたMeetupですが、今回は初のオンライン開催となり、 40名超のお客様にご参加いただけました。 今回は当日の発表内容について、簡単にご紹介をさせていただければと思います。 イベントテーマ概要 ラク スでは数多くの to B 向け SaaS の開発を行っています。 サービスにはこれから新たにリリース予定のものもあれば、 クラウド サービスの黎明期から存在する歴史の深いサービスまで、多くのお客様のご支持によって幅広く展開させていただいています。 今回はそんなサービスの中から代表し、以下の3つのサービスがどのような品質担保を行っているかをエンジニアから紹介させていただきました。 メールディーラー チャットディーラー 楽楽労務 発表の紹介 社内最長老のシステムに PHPUnit で立ち向かう方法 リリースから18年ほど稼働しているメールディーラーを担当中の柳瀬から、 EOLを迎えた PHP をバージョンアップした際の経験を紹介させていただきました。 当時 PHP 歴3カ月だった柳瀬が直面した突然の全機能テストを乗り越えた事例について、語られています。 speakerdeck.com 正攻法はあるのか !? 泥臭く戦った Node.js バージョンアップ一部始終 次は同じくEOLを迎えたNode.jsを 6系 → 10系にバージョンアップすることとなったチャットディーラーでの濃密な戦いを、西原が発表させていただきました。 調査・テスト（× 3回）・リリース後のトラブル対応、そこから得た学びが示されています。 タイトルの通り「泥臭いバージョンアップ」にピンと来る方には、共感をいただけるはずです。 Rakus MeetUp 正攻法はあるのか!?泥臭く戦ったNode.jsバージョンアップ一部始終 from masatonishihara www.slideshare.net ArchUnit で Java / Kotlin アプリケーションの アーキテクチャ を CI する 最後は当社のリードエンジニアである川並です。 開発プロセス の中でコードレビューは取り入れられていても、 アーキテクチャ 観点でのレビューや全員が同じ設計レベルで開発を行うのは、難易度が高いことかと思います。 川並が担当する楽楽 労務 ではそんな問題に対し、 ArchUnit を使った アーキテクチャ 観点での品質担保に取り組んでいます。 speakerdeck.com 終わりに 初のオンライン開催となりましたMeetupですが、ご参加いただきました皆様のおかげで、 高い満足度をいただくことができました。 Meetupは来月・再来月も開催を予定しておりますので、ご興味のある方はお申込みいただけますと幸いです。 詳しいイベント情報については、Connpassをご確認ください。 ありがとうございました！ rakus.connpass.com

今後の新サービスの立ち上げに向けて技術検証を行う技術推進課に所属している鈴木（ @moomooya ）です。今年度から新設の部署に（課長とふたりぼっちで）異動となりました。 最近マイクロサービスと関連して オブジェクト指向 について取り組んでいるので、 デメテル の法則に関する記事を書いてみようと思います。タイトルは1度くらい煽りタイトルをつけてみたかったので出来心です。 デメテル の法則って？ デメテル の法則(LoD: Law of Demeter)は ノースイースタン大学で作成されたガイドライン が原典となり、 達人プログラマー でも（あまり詳しくは書かれていませんが）紹介されています。 ちなみにみんな大好き Wikipedia ではこのように説明されています。 簡潔に言うと「直接の友達とだけ話すこと」と要約できる。基本的な考え方は、任意のオブジェクトが自分以外（サブ コンポーネント 含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 ―― Wikipedia - デメテルの法則 より抜粋 なんとなくわかりますが、実装レベルでどうすればいいのか理解するにはもう少し説明がほしいところです。具体的な対応方法としては 「メンバを直接参照せずにアクセッサ（getter/setter）経由で参照すればいい」 とか 「オブジェクトのメンバを直接参照しない」 「オブジェクトのメンバのメンバを直接参照しない」 とよく言われています。 Java のサンプルコードで見てみましょう。お題は乗り物です。 // Demeter1.java class Engine { // エンジンクラス String status; } class Vehicle { // 乗り物クラス Engine engine; Vehicle() { engine = new Engine(); } } public class Demeter { public static void main(String[] args) { Vehicle vehicle = new Vehicle(); vehicle.engine.status = "発進" ; // ×××オブジェクトの内部を直接操作しない××× System.out.println(vehicle.engine.status); } } これは vehicle.engine.status で直接参照しているため デメテル の法則に違反している例です。 「メンバを直接参照せずにアクセッサ（getter/setter）経由で参照すればいい」んでしょ？ // Demeter2.java class Engine { protected String status; // ★getter/setter作った String getStatus() { return status; } void setStatus(String status) { this .status = status; } } class Vehicle { protected Engine engine; Vehicle() { engine = new Engine(); } // ★getter作った Engine getEngine() { return engine; } } public class Demeter { public static void main(String[] args) { Vehicle vehicle = new Vehicle(); vehicle.getEngine().setStatus( "発進" ); // ★getter/setter使って更新 System.out.println(vehicle.getEngine().getStatus()); } } ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ お可愛いこと…… メンバ変数名にそのままget/setをつけたメソッドを用意したところで本質的には何も変わっていません。 ただの素直か！ メンバを protected (または private でも)にしているのでリードオンリー／ライトオンリーなどの制御は可能ですが 疎結合 にはなりません。 このへんは IDE の功罪 というかgetter/setterの自動生成によって洗脳されてしまっている人も結構いる気がします。 さらに言えば vehicle.getEngine().setStatus("発進"); の部分がオブジェクトの内部構造(Vehicle内のEngineの構造)を意識してしまっています。 「オブジェクトのメンバのメンバを直接参照しない」ようにすればいいの？ // Demeter3.java class Engine { protected String status; String getStatus() { return status; } void setStatus(String status) { this .status = status; } } class Vehicle { protected Engine engine; Vehicle() { engine = new Engine(); } Engine getEngine() { return engine; } // ★engine用のgetter/setter作った String getEngineStatus() { return engine.getStatus(); } void setEngineStatus(String status) { engine.setStatus(status); } } public class Demeter { public static void main(String[] args) { Vehicle vehicle = new Vehicle(); vehicle.setEngineStatus( "発進" ); // ★Engineのメソッドを利用 System.out.println(vehicle.getEngineStatus()); } } ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ` ﾆ|ュ _二,　　　　''''７　 _二,　 | ヽヽ_」_」_　_|＿　:/　ﾍ 入呈 　 _ノ ､　　￣（￣　 _ノ　 |__丿　} .-'　ﾉ よ　{_,,　.| 　｀￣　　　　　　　　 ｀ 　　　,,...-=ミミミミﾐヽ､ 　　/ミ////////////ﾊ 　./ミ;;;;;:////////////} 　{:::ﾐ　　｀ヾ/////////ﾘ 　.{;;;;:　　　: :.////////ﾉ 　r､ﾐ_,,,＿,,;;;::://////ｿ‐, 　{iﾊ〔i77777ﾊ77777!〕:/ 　ヽ.Ｙゝ___ノ　::ゝ_;;;;//ﾉ 　 　 ',　　::i ､,//////{　　　　　　　　,､ 　　 　',　 ,ｨ彡//////＞､＿＿＿__//〉 　　　ノヽ´￣;///////////////////ｧ-=ｭ ─''"{: : :.＼_;;;///////////////////////Ｙ ､: : : |: : : :.Ｙ /＼　//: : /　..:::".:://///////ﾊ : ﾍ: :.|: : : : :{'　　 ｀/: :／...:....::////////////ﾘ ､: :ヽ:{: : : : :.}　　 /／: :＼:://////////////ﾊ : ＼: :{: : : : :.}　 ／:::: : : : :＼/////////////ﾊ : : : ヽﾍ: : : :.!／: :::::::::..: : : : :.ヽ////////////} : : : : : ＼,ｨ'": : :.::::::::::::::.: : : ／////////////ﾊ : : : :＞'i: :::.:.:.: :::::::::::::::::: :///////////////// : ://:./:∪:::::::: ::::::::::::::::://///////////////// :（;': /::: : ::::::::: ::::::::::::://///////////∠////// Ｙ: （:::: : : :::::: ::::::://///////////'''`ミミ:ヽ://// .＼: : : : : :::: :::／///////////ノ: : :::::.: :::::///// 　 /ヽ; : : : ／////////-'''":{::::.: : : :::::::::::///// . /: r.､二､:{: : : ＞':::::: : : ::: : :ゝ: ::.:.::::::::////／ /: : ゝ-､　｀ヽ-{: : : : : : : :::::.:.:.:.:::::://////／ {: : :._／　　　　∨: : : ::::: : : : :.///////／ Vehicle と Engine の関連を Vehicle 内に移譲しているのでだいぶ良くなってはいます。これだと Engine （原動機）が Human （人力）に変わったとしても Vehicle の修正だけで済み、mainメソッドは内部構造（動力）を意識しなくてよくなりました。 しかし Engine のステータスが "発進" なのか 1 なのかはmainメソッド側では意識する必要がないものです。 さらに現実的な実装として操作先のオブジェクトが準備完了かどうかを判定してからステータス更新を行うと思います。 // Demeter4.java class Engine { // ...略... } class Vehicle { // ...略... // ★動力があるか返す boolean isReady() { return engine != null ; } } public class Demeter { public static void main(String[] args) { Vehicle vehicle = new Vehicle(); if (vehicle.isReady()) { // ★動力があるかチェック vehicle.setEngineStatus( "発進" ); } System.out.println(vehicle.getEngineStatus()); } } こんな感じ。 尋ねるな、命じろ (Tell, Don't Ask) で、結局どうするんだ。という話ですが、こうするのが良いとされています。 // Demeter.java class Engine { // ...略... } class Vehicle { protected Engine engine; Vehicle() { engine = new Engine(); } // ★進むための処理 // engineへの操作はここで行う void start() throws Exception { if (engine != null ) { engine.setStatus( "発進" ); } else { throw new Exception( "エンジン盗まれた" ); } } // ★Vehicleの状態として返す String getStatus() { // 必要に応じて整形（ここではそのまま返す） return engine.getStatus(); } } public class Demeter { public static void main(String[] args) { Vehicle vehicle = new Vehicle(); try { vehicle.start(); // ★ただ「進め」と命じる System.out.println(vehicle.getStatus()); // ★vehicleの状態として取得 } catch (Exception e) { System.out.println(e); // ★ダメなら例外処理（場合によってエラーコード処理でも） } } } こうすることでmainメソッドからは Vehicle のみを意識すればよく、 Engine とのことはすべて Vehicle 内に閉じることになります。 むかしばなし ずいぶん昔に所属していたチームで「getter/setterを経由しなければならないんDA!!」というお可愛いコードを主張する方がいたのですが int getA() { if (A == null ) { return B; } return A; } といったコード書いてたのを発見したときに、「[検閲削除]」「[検閲削除]」「[検閲削除]」といったことを心の中で叫んだ記憶が蘇りました。 まとめ イケてるインタフェース設計を心がけましょう。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに こんにちは、 id:FM_Harmony です。 Rakus Developers Blogでは約一年振りの投稿になります。 さて、今年から楽楽精算の スマートフォン アプリ開発 に携わることとなり、業務知識としてSwiftを学習しています。 そこで、今回はSwiftのいいなと思った箇所について、簡単にまとめてみました。 これからSwiftの学習を始める方に、Swiftの良さが伝えられれば幸いです。 はじめに いいところ①：型推論 いいところ②：nullの取り扱い いいところ③：文字列補完 おわりに 参考文献 いいところ①： 型推論 Swiftは静的型付け言語ですが、 型推論 を持っています。 そのため、変数宣言時は定数かどうかのみを意識すればよく、簡潔なコードを書くことができます。 var n = 1 print(type(of : n )) // → Int いいところ②：nullの取り扱い Swiftでは、変数にnull（ nil ）を代入するためには、Optional型として宣言する必要があります。 // var m = nil → コンパイルエラー var n : Int ? = nil print(type(of : n )) // Optional<Int> Optional型はアンラップしなければ利用できないため、nullかもしれない値を安全に利用することができます。 アンラップする方法の一つに、 if - let 構文があります。 var n : Int ? = 1 print(n) // Optional(1) // n += 1 → コンパイルエラー if let m = n { print(m) // 1 m += 1 } また、 guard - else 構文により、Optionalの値がnullだった場合はリターンし、そうでない場合はアンラップした値を変数に代入する、といったこともできます。 guard let n = hoge() else { return } print(n) // → hoge()の戻り値がnilでなければ、その戻り値を表示する guard - else 構文では、複数の変数に代入することもできます。 guard let m = hoge(), let n = fuga() else { return } print(m) print(n) // ↑ hoge()、fuga()の戻り値がnilでなければ、その戻り値を表示する いいところ③：文字列補完 文字列 リテラル に、 \(変数) という形で変数の値を埋め込むことができます。 変数の値と文字列 リテラル の結合もできるのですが、文字列補完を利用した方が簡潔なコードを書くことができます。 let year = 2020 let month = 6 let day = 24 print( " \(year) 年 \(month) 月 \(day) 日" ) // 2020年6月24日 おわりに いかがでしたでしょうか。 Swiftを使うことで、簡潔かつ安全なコードを書けるということが伝えられていれば幸いです。 他にも、extensionやprotocol、 クロージャ というように、過去の記事で紹介されている文法があります。 tech-blog.rakus.co.jp tech-blog.rakus.co.jp そういったものについても今後理解を深めていき、 スマートフォン アプリの機能開発に活かせればと思います。 参考文献 詳細！Swift 4 iPhoneアプリ開発 入門ノート Swift 4+Xcode 9対応 作者: 大重 美幸 メディア: Kindle 版

はじめに こんにちは。itoken1013です。 今回は Markdown （マークダウン） の超入門として、利用度が高い記法10選を紹介します。 入社研修が終わって配属先の上司や先輩とコミュニケーションをとられている新入社員の方や、在宅勤務で以前よりもオンラインコミュニケーションの機会が増えた方には是非とも覚えていただきたい記法ばかりです。 皆様の日々のコミュニケーションにお役立てください！ はじめに そもそもMarkdown（マークダウン）とは何か Markdownが使えると何が便利か コミュニケーションがスムーズ になる ツールが変わっても使える これだけ覚えれば安心な記法10選 1. 見出し オープニング Meetupの発表内容 ①Twelve-Factor Appで読み解く、モダンなアプリの理想とレガシーなアプリの現実 ②開発グループが開発チームになるまでの歩み ③結果整合性ができない開発者のドメインイベント活用例 2. 改行 3. リスト（箇条書き） 4. 番号付きリスト 5. 表（テーブル） 6. 強調、太文字 7. 取り消し線 8. リンク 9. 引用 10. 水平線 終わりに そもそも Markdown （マークダウン）とは何か 文章に見出しや箇条書きなど、文章に簡単に装飾を施すための記述法が Markdown （マークダウン）です。 簡単な記述ルールに従って文章を作成するとHTMLへ変換され、装飾が施された文章が出来上がります。 例として以下は ラクスのConnpassページ でのイベントの紹介文ですが、ただの文字の羅列である上図よりも、 Markdown によって装飾された下図の方が圧倒的に読みやすいことがお分かりいただけるかと思います。 Markdown なし Markdown あり ちなみに ラク スでは社内のチャットツールにMattermostを採用していることもあり、 若手から部長まで Markdown を使ったコミュニケーションが毎日行われています。 エンジニア以外でも利用できる方は多いです。 Markdown が使えると何が便利か コミュニケーションがスムーズ になる 上述のように文章に手軽に装飾を加えることができ、圧倒的に意見を伝えやすくなります。 日常のコミュニケーションの他、議事録やIssueでも読みやすい文章を作成することができるようになるでしょう。 ツールが変わっても使える Markdown を採用しているツールやサービスは数多く（以下）、一度記法を覚えてさえしまえば、利用するツールが変わっても同様の記法で文章を作成することが可能です。 ちなみにこのブログも Markdown で書いています。 GitHub Qiita 各種エディタ Mattermost Backlog ...etc これだけ覚えれば安心な記法10選 それでは代表的な記法を紹介していきます。 ここで紹介する10個の記法を身につければ、普段のコミュニケーションに困ることは無くなるはずです。 1. 見出し まずは見出し（例. 1章、第5節など）です。 見出しを表現するには 「 # + 半角スペース 」 の後、見出し名をつけることで表現できます。 また # を重ねることで、見出しの階層を表現することもできます。 議事録や アジェンダ を示す際には、以下のような見出しがあると読みやすいですよね。 例として、以下では見出し4と5を組み合わせています。 書き方例 #### オープニング #### Meetupの発表内容 ##### ①Twelve-Factor Appで読み解く、モダンなアプリの理想とレガシーなアプリの現実 ##### ②開発グループが開発チームになるまでの歩み ##### ③結果整合性ができない開発者のドメインイベント活用例 表示例 オープニング Meetupの発表内容 ①Twelve-Factor Appで読み解く、モダンなアプリの理想とレガシーなアプリの現実 ②開発グループが開発チームになるまでの歩み ③結果整合性ができない開発者の ドメイン イベント活用例 2. 改行 次はシンプルですが、改行です。 改行は文末に 半角スペース2つ をつけることで実現できます。 書き方例 文末に半角スペースを2つ付けると、改行できますよ→ 改行できました。 表示例 文末に半角スペースを2つ付けると、改行できますよ→ 改行できました。 3. リスト（箇条書き） 先頭にハイフン をつけることで、箇条書きを表現することができます。 また 半角スペース2つでインデント をつけることで、階層構造を示すことできます。 ロジカルに考えを伝えたい場合など、多用するシーンが非常に多い記法です。 書き方例 - 好きな言語 - Java - PHP - 好きなエディタ - VSCode - Vim - Typora - 好きなメディア - はてなブックマーク - Qiita 表示例 好きな言語 Java PHP 好きなエディタ VSCode Vim Typora 好きなメディア はてなブックマーク Qiita 4. 番号付きリスト 先頭に番号をつけたリストを表示したい場合には、 先頭に番号 を付けて表現します。 また箇条書きと同様、インデントによって階層構造を示すことも可能です。 書き方例 1. 住みたい町 1. 鎌倉 1. 神楽坂 1. 荻窪 1. 部屋の条件 1. 騒音 1. ペット可 1. 駅から徒歩3分 表示例 住みたい町 鎌倉 神楽坂 荻窪 部屋の条件 騒音 ペット可 駅から徒歩3分 5. 表（テーブル） 表は少し複雑ですが、 パイプ と ハイフン で作成できます。 またヘッダーと各行の間の1行にはハイフンを指定する必要がありますが、 ハイフンの左右に コロン を指定することで 右寄せ、左寄せ、中央揃え を指定することができます。 書き方例 |日付 | カテゴリー | イベントテーマ | |---:| :---: | :--- | |2020/6/17 | Meetup | SaaSを支える品質担保術| |2020/6/19 | PHP | TechCafe| |2020/6/24 | Meetup | SaaSを支える開発原則| |2020/6/26 | オブジェクト指向 | オブジェクト指向LT会| |右寄せ| 中央揃え | 左寄せ | 表示例 日付 カテゴリー イベントテーマ 2020/6/17 Meetup SaaS を支える品質担保術 2020/6/19 PHP TechCafe 2020/6/24 Meetup SaaS を支える開発原則 2020/6/26 オブジェクト指向 オブジェクト指向 LT会 右寄せ 中央揃え 左寄せ 6. 強調、太文字 文章の中で強調したい文言がある場合、 文言の前後を アスタリスク で囲む ことで表現できます。 一見して注目ポイントがアピールできるため、利用頻度が高い記法の一つです。 ※ツールによって アスタリスク の個数が異なる場合があるため、各ツールのガイド等を確認ください。 書き方例 7月もラクスの** Meetup **と** 勉強会 **が目白押しだよ！！ 表示例 7月も ラク スの Meetup と 勉強会 が目白押しだよ！！ 7. 取り消し線 取り消し線は 文言の前後を チルダ （~~）で囲みます。 一度書いた文面に誤りや変更があった場合、私はよくこの取り消し線を使います。 書き方例 アンケートの結果、先月は実に~~80%~~ 90% の方から高い満足度が得られました！ 表示例 アンケートの結果、先月は実に 80% 90% の方から高い満足度が得られました！ 8. リンク 日々のコミュニケーションで、参照先のURLを紹介することは多いかと思います。 URLを貼り付けて示してもよいですが、分量が多くなってしまう場合、こちらのリンク記法が便利です。 リンクは 角カッコと丸カッコ を組み合わせて記述します。 書き方例 ラクスのイベント情報は、[Connpass](https://rakus.connpass.com/)をチェックしてね！ 表示例 ラク スのイベント情報は、 Connpass をチェックしてね！ 9. 引用 メールの返信で、複数の話題に触れる際には引用を使うことがあるかと思います。 Markdown でも引用をする際には、 > を使うことで表現をします。 書き方例 > 次回の勉強会のテーマについて オブジェクト指向です。 > イベント開催日 6/26(金)です。 > 場所 オンラインです。 https://rakus.connpass.com/event/178556/ 表示例 次回の勉強会のテーマについて オブジェクト指向 です。 イベント開催日 6/26(金)です。 場所 オンラインです。 https://rakus.connpass.com/event/178556/ 10. 水平線 まとまった情報を示したり 文面にメリハリを加えることができます。 水平線は ハイフン3つ を挟むことで、簡単に記述できます。 書き方例 ラクスのイベント情報を紹介したいと思います。 下記の内容をご確認ください。 --- - [【オンライン】SaaSを支える開発原則/DDD、心理的安全性、Twelve-Factor](https://rakus.connpass.com/event/178046/) - [【オンライン】PHP::LT会 【LT枠@2：途中参加OK】](https://rakus.connpass.com/event/178724/) - [【オンライン】オブジェクト指向LT会 vol.2（途中参加OK）](https://rakus.connpass.com/event/178556/) --- たくさんの皆様のご参加、お待ちしています！ 表示例 ラク スのイベント情報を紹介したいと思います。 下記の内容をご確認ください。 【オンライン】SaaSを支える開発原則/DDD、心理的安全性、Twelve-Factor 【オンライン】PHP::LT会 【LT枠@2：途中参加OK】 【オンライン】オブジェクト指向LT会 vol.2（途中参加OK） たくさんの皆様のご参加、お待ちしています！ 終わりに 利用度が高い Markdown の記法を紹介してきました。 まだまだ便利な記法はありますが、この10記法を覚えておけば、 十分にご自身が伝えたいことを読みやすく文章を起こすことができるはずです。 Markdown が使えるツールやサービスは日々増えていますので、このブログをご活用いただけましたら嬉しいです。 ではでは。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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