はじめに こんにちは。Engawaです。 最近の業務でOAuthについて触れる機会がありました。 それまでの業務では担当経験はなく全く仕組みを理解できていなかったため、これを機に仕組みについてちょっと学習してみました！ 参考にした書籍は以下になります。 https://www.amazon.co.jp/dp/484437818X www.amazon.co.jp OAuthとは OAuthとは「 サードパーティ アプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可 フレームワーク 」です。 上記だけだと意味が分からないので、画像編集アプリを例にします。 画像編集アプリで Google Photo上の画像を編集する際、ログインアカウントには Google アカウントを使いたい場合を考えてみましょう。 　 サードパーティ アプリ→画像編集アプリ HTTPサービス→ Google Photo 限定的なアクセス：ユーザーが許されている操作は画像のダウンロードのみで、それ以外の操作をしようとした場合は、HTTPサービスはアクセスを拒否しなくてはならない 認可 フレームワーク ：アクセス トーク ン発効方法のルール（全てのアクセスに対して、許可していいアクセスかどうかをアクセス トーク ンを用いて判断する。） 上記の例を踏まえてOAuthの「 サードパーティ アプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可 フレームワーク 」を言い換えると 『画像編集アプリによる Google Photoへの限定的なアクセスを可能にするための「アクセス トーク ン発効方法のルール」』となります。 各役割の関係性 各役割 OAuthの基本的な役は大体以下の4つになります。 リソースオーナー リソースの所有者。 サードパーティ アプリにリソースへのアクセス権限を委譲しており、決められた権限の範囲内でリソースへのアクセスが可能になります。 クライアント 保護されたリソースにアクセスしようとするアプリケーション。 リソースサーバー データや機能を提供するサービス。一般的にはWebAPIの形で提供されている。 リソースサーバーはリソースオーナーが許可したアクセスを受け入れる必要があり、その手段がアクセス トーク ンとなります。 アクセスのたびにアクセス トーク ンの確認を行い、許可していいアクセスかどうかを判断する。 認可サーバー 認可サーバーの機能は以下の３つになります リソースオーナーを認証する(ログインの認証ではなく、リソースのオーナーであることを確かめるための認証) クライアントのリソースへのアクセスについてリソースオーナーの同意を得る アクセス トーク ンを発行する 上記例だと、リソースオーナーが Google アカウントにログインし、「画像編集アプリが Google Photoにアクセスすること」について同意すると、クラアントに対してアクセス トーク ンを発行します。 それぞれの関係 続いてそれぞれの関係についてざっくりまとめます。 ① 認可サーバに対して「リソースへのアクセス権」を要求する ② 認可サーバーは「クライアントへのアクセス権の委譲」についてリソースオーナーに確認を行う ③ リソースオーナーはアクセス権の委譲に対して同意をする ④ 認可サーバーはアクセス権が委譲された証であるアクセス トーク ンをクライアントに発行する ⑤ クライアントはアクセス トーク ンをもってリソースへのアクセスを実施する 終わりに 今回はOAuthについて、学習を行った内容を簡単に書かせていただきました。 まだまだ理解できないことがたくさんあるので引き続き学習を行なっていき、OAuthに関する記事の作成を行なっていければなぁと思います。

はじめに はじめまして。 ラク スの iketomo （いけとも） と申します。 弊社のオフショア開発拠点（ ラク ス ベトナム ）は2014年に新規で立ち上がり、今期で7年目に突入してます。 私は4年目～6年目までの3年間を拠点長として ベトナム 現地で務めさせていただき、今年6月に帰任させていただきました。 私自身 ベトナム では色々と楽しいことや、苦労したこともありました。 そこでの実体験・経験を踏まえたお話をさせていただきます。 ネット記事を漁ればオフショア開発に関する記事は散見されると思います。 そういった あるある記事 と、 ベトナム 現地での3年間の オレオレ経験 とを照らし合わせて紹介させていただきます。 そこからオフショア開発の現実・真実を感じ取ってもらえればと思います。 下記の5つの観点からご紹介させていただ、最後にまとめとして感想を少し述べさせていただきます。 はじめに (1). コスト (2). 技術・品質 (3). コミュニケ―ション (4). IT人材 (5). 離職・定着率 ベトナム現地での3年間のオレオレまとめ この記事では ベトナム （ ホーチミン ）での弊社での経験が主軸となっており、他の国の事とは事情が異なる点や、主観が混ざっている点もありますのでご了承ください。 いきなり話が脱線しますが ベトナム人 に「いけとも」と自己紹介しても「いけもと」って呼ぶ人が多かったです。 なぜかというと ベトナム では 味の素（ あじ のもと） が昔から根付いていて「いけもと」の方が呼びやすいのでしょう。に気づくのに3年かかりました。 では主軸の話へと移らさせていただきます。 (1). コスト ● あるある記事 一般的にオフショア開発では コストが安価 だとされています。 現在の ベトナム において、IT人材は初任給で言えば日本の 1/4 ～ 1/3 といったところでしょうか。 ただし成果を鑑みると、そのまま人件費がそのまま直結してコストが 1/4 ～ 1/3となりません。 ITにおいて、日本と同じ成果がでるわけではないので、上記の給与差がそのまま反映されることはないです。 ●オレオレ経験 弊社でも3年前は日本の 1/4 ～ 1/5 位の給与でした。 が、後述しますが、 ベトナム においてIT人材は売り手市場であり、年々給与アップしています。 現在では日本の 1/4 ～ 1/3 位まで上がりました。 ではコストはどうでしょう。 弊社では成果から計算した開発コストを日本と比べると、日本の 1/1.5 ～ 1/2 となっております。 現状において ベトナム のオフショア開発をやればコストメリットは出ると確実に言えます。 ただし、給与が上がっていくので、数年後にコストメリットがでるかどうかは、オフショア開発拠点の成果と品質によるところが大きなウエイトを占めると言えます。 給与の増加と共に、成果を大きくしないと、コストメリットはどんどん下がっていきます。 なので 給与アップに負けない成長や独自性 が必須だと言えるでしょう。 弊社においては ラク スの クラウド サービスの開発において、成長と独自性を追求する事としました。 半期、通期で ベトナム の成果や目指すべき方向（ ベトナム においての Saas 開発No1）、そして本社の業績を定期的に報告・共有しメンバーと会社の成長を感じてもらうようにしました。 最近ではコストメリットというところを脱し、 ラク スの クラウド サービス拡大していく中で純粋に絶対必要な開発チームという位置づけに変わりつつあります。 ※普段は陽気ですが仕事中は真剣 (2). 技術・品質 ● あるある記事 一般的には、日本よりオフショア開発拠点の技術・品質は低いと言われています。 ただし ベトナム の IT技術 者は他の東南 アジア諸国 より技術力が高い とされています。 ベトナム ではテストを苦手とするエンジニアもおり、案件によっては品質が高かったり、低くなる時もあります。 QC(テスター)を実装を行うメンバーとは別に アサイ ンすることもあります。 ●オレオレ経験 弊社のオフショア開発立ち上げの初期では、技術・品質が低いと感じることも多くありました。 が、年数を重ね ベトナム の 開発メンバーが成長することで、日本の技術・品質に近づいていくことができました。 最近では技術・品質が日本を上回っているケースも散見され、 一部のメンバーは日本メンバーよりもコード・仕様に詳しくなってきています。 ベトナム人 の IT技術 者のレベルが低いか？と聞かれれば、個人的にそうではないと考えています。 では何の差があるかと言うと 「日本と持っているスキルセットが違う」 「日本のベテランメンバーが近くに居てすぐに聞きアド バイス を貰うということができない」 という2点の差があります。 「日本と持っているスキルセットが違う」 日本人は品質の部分では優位性を持っています。 一方で ベトナム人 は新しい技術をすぐに吸収するといった特性があります。 それぞれに良いところがあり、どちらが優れているという優劣はないと感じています。 日本では新卒は研修を数か月した後に、ようやく開発に入ったりすることがありますが ベトナム では新卒が入社後に直ぐに開発に入って活躍することができます。 スキルセットは環境が整えば日本と同様のスキルセットを吸収します。若ければ若いほど吸収の速度が速いのは自明の理でしょう。 「日本のベテランメンバーが近くに居てすぐに聞きアド バイス を貰うということができない」 これは日本でも開発メンバーが離れていたり、コミュニケーションが上手くいかないと同様のことが発生すると思います。 聞ける人が近くにいて認識齟齬をなくして開発できる。これが良い開発環境における大きくウエイトを占める部分と考えています。 言葉・文化が違い、距離が離れている異国間ではこういった良い環境を保ちづらいデメリットがあります。 こういった日本との差は、日本側の開発メンバーとのコミュニケーションの風通しが良くしたり、オフショア開発拠点にベテランメンバー（該当会社での在籍が3年以上）が増えてくれば徐々に環境の差を縮めることができます。 また日本化することもできます。なぜなら ベトナム人 は向上心が強く、日本をリスペクトしており日本から学ぼうとする姿勢が強いからです。 日本→ ベトナム または ベトナム →日本へ出張することで日本風のやり方・文化を学んでもらうことも効果があります。 弊社では改善・ PDCA ・振り返りを繰り返し行うことで次第にメンバーは自発的に考えながら自己成長していく組織へと変貌していきました。 ※コードレビュー指摘の振り返り (3). コミュニケ―ション ● あるある記事 オフショア開発ではどういったコミュニケーションをするのでしょう。 コミュニケーションをするには以下の方法があります。 「コミュニケーター（通訳兼翻訳）を介す」 「 BSE (ブリッジSE)を介す」 「英語でやりとりする」 リソースとスキルによりいずれかの方法を選択することになります。 コミュニケーターでもＯＫですし。 社内の英語スキルが高ければ英語でやるのも良し。 優秀な BSE を採用できるのであれば BSE でも良し。 ベトナム は 親日 な人が多く日本語ができるコミュニケーター、 BSE が数多くいるといった特徴があります。 時に言葉・文化の違いからか時に認識齟齬が発生することもあり、思ったように指示が通らなかったり、思った成果がでないこともあります。 ●オレオレ経験 弊社では 「コミュニケーターを介す」 を選択しました。 設計書などのドキュメントは日本語←→ ベトナム語 に翻訳します。 単純な質問は英語で行っています。 難しい質問は、チャット上で翻訳してもらうか、 MTG を開いてコミュニケーターに通訳してもらいます。 で、結果がどうだったかと言われると、現在では幸いなことにコミュニケーションによる認識齟齬は殆ど発生していません。 がそこに至るまでは、色々な障壁があり対応してきました。 ●コーディングなどの専門的な難しい内容になると通訳の品質が落ちる。 これに対しては週１でIT勉強会をして、通訳を BSE に近い状態になってもらいました。 Webサーバとはなんぞや？というところからプログラミング演習まで行い、ＩＴ知識を自学できるとこまで成長してもらいました。 コミュニケーターは沢山いても、ITコミュニケーターは多くはいないという考えで自ら育てるという方針でいきました。 ●わからない時でも質問をせずに進め、後に認識齟齬が発生する。 これには2つの要因があります。 「なるべく早くすることを良しとする ベトナム 文化」 開発においては認識齟齬が一番駄目だ！ 報連相 が大事だ！ということを繰り返し伝え、質問文化を醸成しました。 もう1つは「日本との上下関係から委縮して質問できなくなってしまう」ことです。 日本メンバーが ベトナム人 を褒めたり、質問には即答してもらうことで、質問しやすい状況を作り、徐々に解決していきました。 ●大事な内容が伝わっていない。 重要な事と認識するポイントに文化間の差があり、日本が重要視することが見落とされていて、逆に重要視しないところに重きを置くことがあります。 私は難しい話をする時は、先にコミュニケーターにじっくりと説明して理解してもらい、実際の通訳の時に落ち着いて通訳してもらうようにしました。簡易でもいいので口頭だけではなくアウトプットがあるとさらに通訳の難易度が下がり理解度が上がります。 通訳はリアルタイムで難しい作業です。いきなり専門的な難しい話をして、口頭で話して、はいこれを通訳してくださいと言っても、なかなかできるものではありません。 まずは内容を理解するという時間でしっかり理解してもらい、それをベースに通訳してもらえば、私たちの意図を効率よく伝えてもらうことができます。 ※チームワークとコミュニケーションが大切 (4). IT人材 ●あるある記事 オフショア開発と言ってもいろいろな国があります。 ベトナム は他の東南アジアより優秀なIT人材が豊富に揃っていると言われています。 若く優秀な人材を安いコストで獲得することができるというのが通説です。 が、日系や欧米企業の参画が多く近年では 「需要 ＞ 供給」 で売り手市場となっており 年々給与ベースが上がってきています。 ●オレオレ経験 優秀なIT人材が他の東南アジアの国より多いというのは事実です。 また日本よりIT人材を獲得しやすいか問われればその通りです。 では自社が求めるIT人材を簡易に獲得できるかと言われれば、そんなことはないです。 上記しましたが「需要 ＞ 供給」 となっている中では各社で創意工夫が必要です。 ただし、 親日 の国であり、日本企業に入りたい！日本企業で学びたい！と思うIT人材も数多くいます。 そういった人材の中から自社に合った人材を獲得することになります。 スキルや性格にこだわりがなければ、簡易に獲得することができますが 弊社では求める部分も多く、色々な努力をしつつ、なんとか獲得できているといったところです。 「良い人材へのオファーは当日中に出す」「 Facebook で魅力アピール」「過去の面接者にも再度連絡」「 リファラル採用 のキャンペーン」等、できることはなんでもトライしました。 ※表彰することでモチベーションアップ (5). 離職・定着率 ●あるある記事 ベトナム においては 日本と比べてIT人材の 離職率 は高く、定着率は低い とされています。 ジョブ ホッピング も当たり前で、新卒は2年位で転職することが普通とされています。 せっかく育てたメンバーが、、、と各日本企業の頭を悩ませています。 離職が多くとも成り立つ組織。または離職しない組織を目指すことになります。 ●オレオレ経験 弊社でも例にもれず、2年、3年前は 離職率 が高かったですが、最近ではかなり低くなってきました。 離職率 が高くなると、会社としてのノウハウの蓄積ができず、組織としての成長は望めませません。 離職率 が高く、定着率が低いことは、どの会社でも大きな課題 です。 弊社では最初の3年間はスタートアップということもあり、それ程 離職率 は高くありませんでした。 その後、弊社での経験をベースに他社に転職することもあり、 離職率 が高くなりました。 そして現在 離職率 は低くなっています。 では、何が変わったのか？変えたのか？ 弊社では 「会社の独自性と居心地の良さ」というところを強め他社との差別化を図りました。 「自発的な組織」 言われたことをやるだけではなく自発的に動く。 トップダウン ではなく ボトムアップ の行動をより評価する。 「改善・ PDCA 」 の徹底。昔は拒否感が強かったですが、繰り返し実施することでチームとしての成長を感じてくれ、今ではこれが普通になり何も言わずとも振り返りＭＴＧを行ってくれます。 「とにかく楽しい」 を目指す。何が楽しいかを自分たちで議論させ、実行・主催してもらうようにしました。 「給与アップ」することである程度転職を防ぐことはできます、がそれは青天井で限界があります。 給与を求めるメンバーは給与アップしたとしても、さらに高い給与を目指して転職してしまいます。 そういったメンバーはいつか去る事になるので引き留めない方が良いでしょう。 ※コアバリューの浸透で社内文化の醸成 ベトナム 現地での3年間のオレオレまとめ 他文化・他言語ということもあり、いろいろ苦労した側面がありました。 が、いつでも ベトナム人 の優しさと明るさ が私を支えてくれました。 結果としては私が想像していた以上に、 ベトナム人 の向上心は強く、大きく成長してくれ 、今では思った以上の成果を出せる誇らしい組織と変貌することができました。 個人的には 安易にコストメリットだけを見てオフショア開発をやってみることはおススメできません。 コストメリットは何もしなければ風化していくからです。 彼らと一心同体となって成長することを決心してください。 その気持ちが伝わり、適切な仕組みやアド バイス をすれば必ず成長してコストメリットを超えた 期待以上の成長と成果を出してくれます。 会社独自の戦略で社員の定着率を高めてください。 離職率 を抑えることができたなら、あとは成長が待つのみです。 上記のご紹介した内容が皆様のオフショア開発を始めるきっかけや、課題や懸念の解決の糸口になれば幸いです。 長文になりました。最後まで読んでくださった方ありがとうございます！ ※誕生日はちょっとした社内パー ティー エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに こんにちは、itoken1013です。暑い毎日が続きますね！ 今回紹介するのは、実務でも個人開発でもオススメのHeroku（ヘロク）の基礎的な使い方になります。 Herokuを使うことで、開発したWEBアプリケーションを手軽に公開することができます。 この記事ではHerokuの概要を説明した後、簡単な公開（デプロイ）の手順を紹介することで、初心者でもHerokuを使った開発者に入門できる内容となっています。 今回の記事を参考に、ステイホーム中の スキルアップ を進めていただければ幸いです！ はじめに Herokuの概要 まず、PaaSとは それでは、Herokuとは 多様な言語・FWをサポートしている プランによっては無料で使える Gitコマンドで操作できる 拡張機能が非常に多い Herokuを使ってみる Herokuのアカウントを登録する Heroku CLIをインストールする Windows の場合 Mac の場合 Herokuにログインする デプロイを行う アプリケーションの取得 デプロイ実施 動作確認 おわりに Herokuの概要 まず、PaaSとは クラウド サービスは大きく SaaS 、PaaS、IaaSの3種類に大別されますが、Herokuはこのうち、PaaS（Platform as a Service）に分類されます。 PaaSとは、開発したWEBアプリケーションを開発・実行するための基盤（プラットフォーム）を提供するサービスを指します。 PaaSを利用することで、それまで必要だったサーバーの購入やOS、DB、WEBサーバなどの ミドルウェア 類のセットアップが不要となり、開発者はインターネット越しでPaaSを操作するだけで、手軽にWEBアプリケーションの ホスティング ができるようになりました。 また画面や コマンドライン 上でスケールアップ／アウトを手軽に行うことができ、この点もWEBアプリケーションの公開のハードルを下げた一因です。 このようにPaaSが普及したことで、開発者は本質的な開発作業に集中することが可能になりました。 それでは、Herokuとは 上記で説明しましたPaaSであるHerokuを使うことで、作成したアプリケーションを手軽に公開することが可能となります。 他のPaaSと比較した際のHerokuの特徴には、以下の点が挙げられます。 多様な言語・FWをサポートしている 元々は Ruby 向けのPaaSだったHerokuですが、現在では国内で扱われている主要言語とFW（以下）をほぼカバーしています。 この対応言語の広さが、PaaSの中でもHerokuが多く活用される一因でしょう。 Ruby （ Rails 含む） PHP Java Node.js Python Go Scala （Play含む） Clojure また公式サポートされている上記以外にも、buildpackと呼ばれる機能を利用することで、希望の言語・FWをHeroku上で利用することもできます。 jp.heroku.com プランによっては 無料 で使える Herokuが普及した最大の要因といっても過言ではないのが、利用プランです。 Herokuには数種類の利用プランがありますが、 Freeプランを利用の場合、無料でHerokuを利用することができます。 もちろん無料であるが故に制約は存在しますが、個人的な スキルアップ を目的とした利用にあたってはFreeプランで差し支えないはずです。 （少なくとも私がプライベートで個人利用している中では、一度もプラン変更は発生していません） 収入を目的にアプリケーションを公開する場合ではFreeプランでは耐えられないかと思いますが、あくまで スキルアップ のための利用であれば、Herokuを無料活用することが可能です。 ただし、今後プランの見直しが発生する可能性はありますので、ご利用の際は事前に以下の公式ページを参照いただければと思います。 jp.heroku.com Gitコマンドで操作できる Herokuではアプリケーションをデプロイする操作として、エンジニアならお馴染みのGitコマンドを利用します。 このため、Herokuへのデプロイ作業のために覚えることは最小限で済みます。 Herokuをリモー トリポジ トリとして git push するイメージですので、普段からエンジニアの手慣れた操作で手軽にアプリケーションを公開することができます。 なお、後続の手順ではGitを使った操作が必要となります。 Gitを未インストールの方、Gitコマンドの利用経験が浅い方は、まずはこちらを参照いただければと思います。 tech-blog.rakus.co.jp 拡張機能 が非常に多い 今回は紹介しませんが、Herokuには数多くの 拡張機能 （アドオン）が存在おり、自前で実装せずに便利な機能を利用することができます。 中には無料のプランを提供している機能もあり、代表的な 拡張機能 を以下に紹介しておきます。 興味のある方は、ぜひご自身の開発で活用してみてください。 SendGrid：メール配信 PaperTrail：ログ管理 New Relic APM ：監視 Herokuを使ってみる Herokuのアカウントを登録する それではここから、Herokuを利用するための操作を簡単に紹介していきます。 まずはHerokuのアカウントを取得しましょう。 以下の画面より必要事項を入力の上、「無料アカウント作成」をクリックしてください。 signup.heroku.com 上記で入力したメールアドレスに認証メールが届きますので、メール内のリンクをクリックしてアカウントを有効化します。 最後にパスワード設定を求められますので、任意のパスワードを設定してください。 ここまで完了し、以下の画面が表示されればアカウント登録の作業は完了です。 Heroku CLI をインストールする 次にHerokuを コマンドライン 上から操作するためのツールをインストールします。 後続のデプロイ作業には、こちらのツールが必要となります。 以下のページにアクセスし、ご利用のOSに応じた手順でインストールを行っていきます。 devcenter.heroku.com Windows の場合 Windows 用の インストーラ が提供されていますので、ダウンロードの上、 インストーラ を起動してください。 今回は全てデフォルトの状態で進んでいただき、「Install」ボタンをクリックいただければ問題ありません。 Mac の場合 Mac では インストーラ を用いず、上記ページにあるコマンドをターミナル上で入力してください。 ※パッケージマネージャである Homebrew がインストール済である必要があります。 brew tap heroku/brew && brew install heroku ここまで完了しましたら、 CLI を起動してみましょう。 Windows であれば コマンドプロンプト やGit Bash 、 Mac であればターミナルを起動し、以下のコマンドを入力してください。 無事にバージョン情報が表示されれば、 CLI のインストールは完了です。 $ heroku --version heroku/7.42.6 win32-x64 node-v12.16.2 Herokuにログインする 先ほど作成したアカウントを使い、 CLI 上でHerokuにログインします。 heroku login -i を入力すると コマンドライン 上でログインを求められますので、アカウント作成時のメールアドレスとパスワードを入力してください。 ※ iオプション を付けない場合、ブラウザ上にHerokuのログイン画面が立ち上がりますが、同様にログイン認証を進めれば問題ありません。 $ heroku login -i heroku: Enter your login credentials Email: メールアドレス Password: パスワード Logged in as メールアドレス デプロイを行う ここからは、実際にHeroku上にアプリケーションをデプロイしてみましょう。 GitHub 上のサンプルプログラムを使い、デプロイの手順を紹介していきます。 簡単なデプロイのイメージを示します。 アプリケーションの取得 まずは任意の場所に ディレクト リを用意しましょう。 今回は「rakus」という ディレクト リ配下で作業を進めていきます。 $ mkdir rakus rakus ディレクト リへ移動後、次にデプロイ用のアプリケーションを GitHub より取得します。 git clone を使い、任意の リポジトリ （今回はHerokuのサンプルアプリケーションを使います）からクローンを行います。 ※実際の開発ではここが開発対象の リポジトリ となり、ローカル リポジトリ を最新化しておく必要があります。 $ git clone 'https://github.com/heroku/java-getting-started.git' Cloning into 'java-getting-started'... ・ ・ ・ Resolving deltas: 100% (179/179), done. デプロイ実施 Heroku上にデプロイを行うためのアプリケーション作成を実施します。 まずはクローンしたアプリケーション配下へ移動します。 $ cd java-getting-started/ 次に heroku create コマンドを入力すると、デプロイ用のアプリケーションが作成されます。 この際、 コマンドライン 上に表示されるURLを控えておいてください。 また、以下に示す XXXX-ZZZZ-123456 （例）が作成したアプリケーション名を表しています。 ※アプリケーション名は heroku create コマンドの引数で指定可能です。 指定がない場合、「XXXX-ZZZZ-123456」のようなランダムな名称が割り振られます。 $ heroku create Creating app... done, XXXX-ZZZZ-123456 https://XXXX-ZZZZ-123456.herokuapp.com/ | https://git.heroku.com/XXXX-ZZZZ-123456.git 最後に git push heroku master を入力すると、Heroku上へのデプロイが行われます。 $ git push heroku master Enumerating objects: 400, done. Counting objects: 100% (400/400), done. Delta compression using up to 4 threads. Compressing objects: 100% (190/190), done. Writing objects: 100% (400/400), 178.59 KiB | 25.51 MiB/s, done. Total 400 (delta 152), reused 400 (delta 152) remote: Compressing source files... done. ・ ・ ・ remote: https://XXXX-ZZZZ-123456.herokuapp.com/ deployed to Heroku remote: remote: Verifying deploy... done. To https://git.heroku.com/XXXX-ZZZZ-123456.git * [new branch] master -> master これでデプロイ作業は完了です。 動作確認 ここまででデプロイ作業は完了ですが、最後にデプロイしたアプリケーションを確認してみましょう。 上記の デプロイ実施 で表示されたURL（上記であれば https://XXXX-ZZZZ-123456.herokuapp.com/ ）をブラウザに入力してください。 以下のような画面が表示されれば、正常にデプロイが完了しています。 無事に画面が表示されましたか？ 今回の作業は以上で完了となります。 お疲れ様でした！ おわりに 今回はHerokuを使ったアプリケーションの公開手順を紹介してきましたが、いかがでしたでしょうか？ 思っていたよりも簡単な手順だと感じた方が多いのではないでしょうか？ 実際の開発でHerokuを応用的に活用していくためには、Heroku固有の概念（DynoやHeroku Flowなど）への理解がまだまだ必要です。 ですが、最低限のプラットフォームとしての機能と利便性は、この記事を使って理解いただけたはずです。 今回の内容を足がかりにしていただき、今後の開発にお役立ていただけると幸いです。 ではでは、またの機会に。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに 技術広報のitoken1013です。こんにちは。 いつも ラク スのイベントにご参加いただいている方々、本当にありがとうございます！ 今回は8月1回目のMeetup 『レガシーを吹き飛ばすPHPer実践テクニック』 について、コンテンツを紹介させていただきます！ イベントテーマ概要 今回は 『レガシーを吹き飛ばす』 という強力なイベントタイトルを掲げさせていただき、 リリースから10年以上 の以下サービスに携わるエンジニア3名が登壇させていただきました。 これらのサービスは多くのお客様に長くご利用いただき、現在でも新たな機能追加を進めています。 その一方で長い開発で蓄積しているレガシーな面とも向き合う必要性が高まっており、開発速度と品質を落とさないための取り組みが求められています。 今回はそんな取り組みの中でも、より実践的なテクニックを紹介させていただきました。 楽楽販売 メールディーラー 配配メール ちなみにご参加の方へ利用言語をお聞きしたところ、（当然ではございますが…）大半が PHP 使いの方でした。 また、登壇者と同じように レガシーシステム の開発に携わっている方もいらっしゃり、今回のイベントで得たテクニックを早速活用したいと言っていただける場面もありました。 ラク スでは PHP 中心のイベントを頻繁に開催しておりますので、今後もイベントにご参加いただけますと嬉しいです！ 発表の紹介 それでは3名のエンジニアによる発表を簡単に紹介させていただきます！ 「指摘の 見える化 」SonarQubeを使って、新規不良コードをデビューさせない仕組みづくり 楽楽販売の開発に携わる凪から、静的コード解析ツール 「SonarQube」 を使ったコードレビューの改善についての発表となります。 主にレビューを中心に担当する凪ですが、日に日に増大するレビュー負荷という課題を踏まえ、静的コード解析ツールの導入を決定しました。 数あるツールからSonarQubeを選択した背景、実際に運用を開始してからの効果について詳細に語られています。 サービスの急拡大に伴ってレビューが追い付かない！、という悩みをお抱えの方には是非ご参考にしていただきたい内容です。 speakerdeck.com PHP 標準関数との闘い PHP のバージョンアップ（7.1 から 7.3）に伴う count()関数 の仕様変更にまつわる、 ラク ス最古参のサービスであるメールディーラー（2001年4月リリース）でのエピソードを加納より紹介させていただきました。 リリースよりおよそ20年、メールディーラーではありとあらゆる場所でcount()関数を呼び出しており（呼び出し数は、ぜひ資料をご覧ください…）、あるべき論だけでは語れない戦いが繰り広げられることとなりました。 さらには開発体制に起因する新たな問題も生まれてしまい…という苦労を抱えたエピソードになっております。 言語や フレームワーク の仕様変更は、ソフトフェア開発では避けては通れない戦いです。 今回は歴史を抱えたサービスを支えるための戦いではありますが、ご紹介のノウハウはどの開発でも活用できるはずです。 ぜひ多くのエンジニアに役立てていただければと思います。 speakerdeck.com 13年続くレガシーサービスを安全にリリースし続けるための、E2Eテストと カバレッジ ツールを利用したテスト戦略について リリースから13年が経過した配配メールにおける、吉元が取り組むテスト戦略をお話させていただきました。 名著のレガシーコード改善ガイドでは『自動テストが無いコードはレガシーコードである』と触れられていますが、吉元の携わる配配メールではまさに自動テスト環境が存在せず、高い品質を保ったリリースに課題を抱えていました。 www.amazon.co.jp 「プロダクトコードの複雑性」や「計画の不確実性」といった課題を抱えていた開発チームですが、これらに向き合った「重要機能テストの自動化」や「 テスト駆動開発 」などの戦略が語られています。 詳細で実践的な内容であるため、ご自身の開発現場でも活用できそうと感じていただけるはずです。 speakerdeck.com おわりに レガシーに向き合う ラク スエンジニアの取り組み、いかがだったでしょうか。 簡単な課題は1つも存在しませんが、多くのお客様にご利用いただける期待に応えるため、日々レガシーを吹き飛ばすテクニックに取り組んでいます。 さて、次回のMeetup（8/25開催予定）は 『新サービス』 がテーマです！ すでに100人以上の方に申し込みいただけており、大イベントになりそうな予感がしています。 rakus.connpass.com また PHP に関するイベントも8月中に2回開催予定です。 こちらもたくさんのご参加をお待ちしています！ rakus.connpass.com rakus.connpass.com

はじめに 技術広報のitoken1013です。こんにちは。 6月に多くの方にご参加いただきました ラク スMeetup、7/29(水)にも 『 SaaS 開発リーダーが実践する開発速度向上プ ラク ティス/海外拠点、 スクラム 、時間管理』 をタイトルにオンライン開催させていただきました。 今回も当日の発表を簡単に紹介させていただきます！ イベントテーマ概要 ラク スでは『企業で働く人々の生産性を向上し、より豊かな社会の実現』を掲げて、多様な SaaS をお客様に展開しています。 そのために ラク スのエンジニア自身も日々、開発速度や生産性向上に向けたプ ラク ティスに取り組んでいます。 今回は多くのお客様にご支持をいただいています 楽楽精算 と 楽楽明細 の開発に携わるエンジニア3名が登壇し、それぞれが挑戦中の取り組みをご紹介させていただきました。 個人・チーム・オフショアの3つの視点からのプ ラク ティスが紹介され、多様なポジションの参加者の方からコメントをお寄せいただけました。 発表の紹介 25 + 5分で開発速度を上げる時間管理術！ ポモドーロテクニック の紹介 まず楽楽精算で開発・運用とマルチな役割を担う平山から、作業時間を管理するための ポモドーロテクニック を紹介させていただきました。 開発に限らず生産性向上のテクニックとして広く知られる ポモドーロテクニック ですが、今回は平山の具体的な課題のエピソードと実践後の効果が語られることで、日々のお仕事で取り入れてみたいと感じていただけたのではないでしょうか。 若手・中堅・ベテランのどのエンジニアにもお勧めしたいテクニックです。 www.slideshare.net スクラム 開発ドキュメンタリー ～なぜなぜ、落ちる スクラム 開発速度～ 次は楽楽明細で スクラム 開発を実践中の柴田より、開発デモで起きてしまった、とある苦いエピソードを紹介させていただきました。 開発サイドとビジネスサイド（もしくはユーザー）で生まれる認識のズレややり直しは、どの企業様に所属するエンジニアの方でもご経験のあるトラブルかと思います。 柴田が所属する楽楽明細チームではこれらのトラブルに対し、 スクラム の枠組みに捕らわれずに柔軟に開発スタイルを変更することで改善を図っていきました。 いまだ試行錯誤を続けながらの取り組み、今後の成果に期待です。 speakerdeck.com Quality First & Fastを実現するオフショア開発のポイント9選 今回のラストは、楽楽明細の開発リーダーを務める樋口です。 ラク スの子会社である ベトナム の『RAKUS Vietnam Co., Ltd.』のエンジニア陣をマネジメントする樋口ですが、開発速度と品質の両立のために駆使するテクニックを具体的に紹介させていただきました。 『日本が特殊な国だということを理解する』『日本の設計観点を伝える』など、複数国の方との仕事経験が豊富な樋口ならではの発表でした。 またオフショアをテーマにした内容ではありますが、日本人のエンジニア同士でも参考にしていただけるプ ラク ティスを見つけていただけるはずです。 speakerdeck.com おわりに 今回は特定の技術スタックに偏ったイベントテーマではなかったこともあり、さまざまなレイヤーの方にご参加いただけました。 プロジェクトマネジメントに課題を抱える方、個人のスケジュール管理がうまくいかない方などの参考にしていただけますと幸いです。 ラク スでは8月以降もMeetupやLT・勉強会の開催を予定しています。 すでに多くの方にお申し込みいただき、ありがとうございます！ 今後も ラク スエンジニアからの情報発信をどうぞお楽しみに！！ rakus.connpass.com rakus.connpass.com

技術広報の syoeshin です。 当社では最近、下記２つの定期的な読書会を企画し、スタートしました。 社内の有志達がリードして、それぞれが好きな本を読み/紹介しあう読書会 社内の 有識者 達がリードして、選定した技術書の理解を深める読書会 定期的な読書会を組織の取組みとして始めた目的は "個と組織の成長" です。 成長のプロセスは 知識を得る (勉強会で話を聞く、本を読む、ニュース/記事を読む など) 訓練する (繰り返し修練、習慣にする など) 実践する に分解できます。 定期的な読書会の機会をつくり、参加してもらう事で 成長の源泉となる 知識を得る 　 × 　 訓練する のサイクルは定着させる事ができます。 もちろん 実践する はとても重要ですが 私たちの開発組織は 支援の厚い実践シーンの連続 ですので 知識を得る 　 × 　 訓練する サイクルが定着すれば 個の成長が加速する事は、言うまでもありません。 さて まずは 知識を得る 　 × 　 訓練する のサイクル定着を目的として始めた読書会は 早速、以下のようなうれしい副次効果も見られ始めました。 組織内コミュニケーションの ダイバーシティ 化 要約/意見をまとめる/人前で話すスキルの向上とリーダーシップの育成 組織内での専門性/ アイデンティティ の確立 ーー組織内コミュニケーションの ダイバーシティ 化 私たちの開発拠点は 東京・大阪・ ベトナム と分かれており これまで社内イベントは拠点を中心とした開催が主で 業務外のコミュニケーションも拠点が中心となっておりました。 密を避けるべき状況下で、読書会はオンライン開催となったため これまでの様に拠点別の開催ではなく 東京、大阪、 ベトナム から社員が一斉参加できる読書会は 拠点を問わず、若手・中堅・ベテランを問わず 業務外コミュニケーションも交わせる機会の一つとなりました。 ーー要約/意見をまとめる/人前で話すスキルの向上とリーダーシップの育成 読書会にはさまざまな形式がありますが、当社が実施している 社内の有志達がリードして、それぞれが好きな本を読み/紹介しあう読書会 の参加目的は「それぞれの自由でよし」としています。 こちら読書会の参加者には 会の冒頭で 「今日はどこまで読む」と読書宣言をしてもらい 1~1.5ｈの読書後 に 読んだ本/部分を要約し、参加メンバーに伝えてもらうようにしております。 また、参加者から ファシリテーター (簡単な司会進行)を選出し 会の進行をしてもらいます。 ・読書宣言 ・読んだ本/部分の要約を発表 ・読書会の司会進行 をしてもらう事で　 知識を得るためだけの読書会ではなく ・人前で話す ・意見をまとめる ・人の意見を聞きながら結論を導く場を作る というト レーニン グになり、スキルを磨くことができる仕組みで 参加者は 心理的 負担が小さい中で リーダーシップに必要な要素が身に付けられるようになってます。 ーー組織内での専門性/ アイデンティティ の確立 社内では ・ アーキテクチャ に詳しい 人 ・ アジャイル 開発や スクラム に詳しい 人 ・フロントエンドに詳しい 人 等々 おりますが そういったメンバーは”特定分野の知識と経験が豊富”と社内で認識されており 特に知識面では、その分野に関わるたくさんの本を何度も深く読んでいる事が多いです。 社内の 有識者 達がリードして、選定した技術書の理解を深める読書会 では 特定分野や技術テーマに沿って読書会が開催されており 読書会を主催するメンバー達は、 ”特定分野に詳しい人” と社内で認識され 自身の専門性と アイデンティティ を確立しています。 また 当社では有志達が始めた社内勉強会から発展した 「 TechCafe※ 」という 社外向け勉強会コミュニ ティー を運営しており 社外向けに特定分野/技術のベントを主催する事で 社内だけでなく社外にも自身の専門性と アイデンティティ の確立を進めています。 ※TechCafe詳細「TechCafeができるまで」 tech-blog.rakus.co.jp ーーまとめ 読書会の開催/参加メリットは世間でさまざまに言われてますが 社内で読書会を開催してみて 世間で言われているどのメリットも得られる というのが現時点での所感です。 まだまだ開催の実績は少ないですが 中核メンバーや管理職、開発組織以外メンバーの参加が増えていけば ・組織コミュニケーションの ダイバーシティ 化 ・組織メンバーのリーダーシップ育成 ・組織メンバーの専門性/ アイデンティティ の確立 の進化ができ ”個と組織の成長”を加速できる と考えているため 今後もより多くのメンバーが参加しやすく 何より楽しめる「読書会」を企画していこうと考えております。 当社運営の勉強会コミュニ ティー は以下サイトからご参加ください。 rakus.connpass.com また、私たちは一緒に働くメンバーを募集しています。 ご興味を持たれましたら以下のサイトからお問い合わせください。 career-recruit.rakus.co.jp

はじめに はじめまして。 ラク スのインフラエンジニアの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 当社はこれからもイベント登壇やブログ発信など、エンジニアのアウトプット活動を活発に行っていきます！