技術広報の yayawowo です。 いつも ラク スのエンジニアブログをお読みいただき、ありがとうございます！ 今回は2022年2月8日(火)に ラク スとして初めて開催したテックカンファレンス 「RAKUS Tech Conference 2022」の発表内容を当日利用した発表資料 と合わせて、ご紹介させていただきます。 ◆ 関連記事 現場最前線のエンジニア達から普段の活動や開発・運用で得た知見などの技術情報してきた、 ラク スMeetupの発表実績をまとめている記事です。 tech-blog.rakus.co.jp なお、本イベントの アーカイブ 動画を見たい！という方は 以下フォームより「 ラク スDevelopers」にご登録いただけますと、 後日 アーカイブ 動画をお送りさせていただきます！ ➡ 申込は終了しました！ forms.gle イベント概要 開催概要 発表の紹介 ラクスのエンジニア組織について 楽楽精算のサービスと共に成長するエンジニア組織の3年間とこれから トラブルゼロで乗り切ったTypeScript移行 息の長いサービスのPHP8バージョンアップで見えた課題と解決法 進化を止めない、"レガシー"との向き合い方 SaaS マルチヒットメーカーラクスのインフラ戦略 クロージングトーク おわりに イベント概要 RAKUS Tech Conference2022 は ラク スが初めて開催するオンラインテックカンファレンス です！ ラク ス開発組織は「顧客をカスタマーサクセスに導く圧倒的に使いやすい SaaS を創る」というミッションを掲げ、 お客さまに必要とされる高品質な SaaS を生み出すべく開発に取組んでおります。 開催概要 日時　：2022/2/8(火) 14:00-18:00 会場　：オンライン 参加費：無料 主催　： 株式会社ラクス Twitter ハッシュタグ ： #RAKUSTechCon contents.rakus.co.jp 発表の紹介 それではここから各発表内容と資料を共有させていただきます！ ラク スのエンジニア組織について 登壇：公手 真之 [ 執行役員 開発本部長 兼 第一開発部長] オープニングでは、 ラク ス開発本部長の公手より、 以下内容を紹介させていただきました！ ラク スについて エンジニア組織について ラク ス開発本部のこれからのチャレンジについて 200名→500名強の組織へ ラク スの開発組織は、 「日本を代表する SaaS エンジニア集団となる」 をビジョンとして掲げています。 完成された組織ではなく、むしろ遅れている部分が沢山あるということを踏まえていただきながら、各々のセッションをご確認いただけますと幸いです！ speakerdeck.com 楽楽精算のサービスと共に成長するエンジニア組織の3年間とこれから 登壇：間澤 創 [開発本部 第三開発部長] 　　　森山 純 [開発本部 第三開発部 楽楽精算開発2課長] 　　　稲垣 剛之 [開発本部 第三開発部 楽楽精算開発3課長] 年間売上高55億円を超える SaaS である 楽楽精算 のエンジニア組織がどのような成り立ちをしてきたのか、またその今後を楽楽精算の開発に携わる間澤、森山、稲垣よりご紹介させていただきました。 楽楽精算を立ち上げたエンジニア中心の組織から脱却し、オフショア開発、モバイル開発、 プロダクトマネジメント 、QAなど様々な組織を再構成しながら、徐々に大規模な開発組織となっていきました。 さらに、今後どのようにして開発力や組織を強化していくことになるのかを是非ご確認ください！ speakerdeck.com 【求人情報】楽楽精算 ・ エンジニアリングマネージャー ・ Webアプリケーションエンジニア／Java ・ Androidエンジニア ・ オフショア開発マネージャー ・ ブリッジエンジニア ・ プロジェクトマネージャー ・ プロダクトマネージャー ・ プロダクトサポートエンジニア ・ QAエンジニア ※2022/2/16時点での情報です。 トラブルゼロで乗り切ったTypeScript移行 登壇：三田 英一 [開発本部 第三開発部 楽楽明細開発課] 楽楽明細 の開発に携わるテッ クリード の三田より、 8年ほど運用しているjQueyで実装されたサービスをTypeScriptに移行した事例を紹介しました。 発表ポイントは以下の通りです。 機能開発を止めずに安全かつ低コストで移行するノウハウ 移行するメリット／デメリット うまくいったこと／苦労したこと speakerdeck.com 発表時に話しきれなかった内容は、以下のQiitaにて別途まとめております！ 合わせてご確認ください。 qiita.com 【求人情報】楽楽明細 ・ エンジニアリングマネージャー ・ Webアプリケーションエンジニア／Java ・ オフショア開発マネージャー ・ ブリッジエンジニア ・ プロジェクトマネージャー ・ プロダクトマネージャー ・ プロダクトサポートエンジニア ・ QAエンジニア ・ フロントエンドエンジニア／マネージャー ・ フロントエンドエンジニア ※2022/2/16時点での情報です。 息の長いサービスのPHP8バージョンアップで見えた課題と解決法 登壇：頓花 貴俊 [開発本部 第ニ開発部 楽楽販売開発課] 続いて、 楽楽販売 の開発に携わる頓花より、 リリースから10年以上経つサービスがPHP8へのバージョンアップで起きた課題・解決法について紹介しました。 ご紹介した具体的な課題と対応策は、以下の通りです。 影響範囲の調査と対応範囲の検討 後方互換 性の無い変更に対する対応 静的チェックが難しい変更点 サービスの品質担保について など speakerdeck.com 【求人情報】楽楽販売 ・ Webアプリケーションエンジニア／Java,PHP ・ プロジェクトマネージャー ※2022/2/16時点での情報です。 進化を止めない、"レガシー"との向き合い方 登壇：矢成 行雄 [開発本部 第四開発部長] 私たち ラク スでは多くの SaaS プロダクトを開発・運営しています。 中にはリリース以来20年を超える歴史を持つようなサービスもあります。 ともすれば、"レガシー"の一言で片づけられてしまいかねないプロダクトであっても、 ラク スでは決して進化を止めることはありません。 EOLや新 フレームワーク など新技術要素との向き合い方 モダンな開発スタイルとのハイブリッドなアプローチ 中核となる技術（＝ PHP ）にかける ブランディング 戦略 など、私たちがどのように"レガシー"と向き合ってきたかを MailDealer 、 ChatDealer 、 配配メール 、 Curumeru の開発部長である矢成がお話しました。 speakerdeck.com 【求人情報】MailDealer/ChatDealer/配配メール/Curumeru ◆大阪 ・ Webアプリケーションエンジニア／Java,PHP ・ プロジェクトマネージャー ・ ブリッジエンジニア ◆東京 ・ フロントエンドエンジニア／マネージャー ・ フロントエンドエンジニア ※2022/2/16時点での情報です。 SaaS マルチヒット メーカー ラク スのインフラ戦略 登壇：金本 宏司 [開発本部 インフラ開発部 副部長] ラク スでは9割以上のシステムをオンプレミスで構築し運用しています。 何故オンプレなのか Saas 企業のインフラで考慮すべきポイント IT市場の変化に伴いオンプレでの kubernetes 環境構築も視野に入れた今後のインフラ戦略 について話しました。 speakerdeck.com 【求人情報】インフラ開発課 ◆東京 ・ インフラエンジニア／マネージャー ・ インフラエンジニア ・ AWSエンジニア ・ アーキテクト・テックリード ・ SREエンジニア ◆大阪 ・ インフラエンジニア／マネージャー・管理職 ・ インフラエンジニア ※2022/2/16時点での情報です。 クロージング トーク 登壇：公手 真之 [ 執行役員 開発本部長 兼 第一開発部長] 　　　間澤 創 [開発本部 第三開発部長] 　　　矢成 行雄 [開発本部 第四開発部長] 　　　金本 宏司 [開発本部 インフラ開発部 副部長] 最後のクロージング トーク では、公手、間澤、矢成、金本を交えながら 「RAKUS Tech Conference 2022」の振り返り ミッション/ビジョン/バリューの目的・背景 ラク スのエンジニアカルチャー 各部門の雰囲気 など、生の声で発信させていただきました！ こちらについては発表資料がないため、 アーカイブ 動画の公開 までお待ちいただければと思います。 おわりに 「RAKUS Tech Conference 2022」はいかがでしたでしょうか？ 開催時間が日中にも関わらず、多くの方にご参加いただきました。 改めて、お礼申し上げます。 RAKUS Tech Conference 2023も開催する予定でおりますので、今回参加できなかった方は次回是非ご参加ください！我々 ラク ス開発部もエンジニアの皆様、 SaaS 開発に携わる方の一助となるような技術発信ができるよう、日頃から精進したいと思います！！ 最後までお読みいただきありがとうございました。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは、技術広報の yayawowo です。 Web制作をする際に、 ・このテキスト強調したいな… ・この見出しをおしゃれにできないかな？ と思うことはないでしょうか。 そこで今回は、 CSS で下線を引く方法に加え、太さや色付け、点線にする方法を解説したいと思います！ HTMLと CSS のコード例も記述しておりますので、是非ご参考ください。 CSSで下線を引く方法 ① text-decoration text-decorationのコード・実行結果例 ② border-bottom border-bottomのコード・実行結果例 ③ background backgroundのコード・実行結果例 まとめ ◆ CSS 関連のブログ ・ CSS（スタイルシート）の書き方【初心者向け】 ・ 【CSS実装予定】カスケードレイヤー「@layer」について CSS で下線を引く方法 早速、 CSS で下線を引く方法を解説します。 方法は大きく3つあり、使いたい線の種類や用途によって、 CSS のプロパティが異なります。 最適なものをご選択の上、ご活用ください！ ① text-decoration まずは、 CSS で一般的な下線を引きたい時に便利な text-decoration の使い方です。 text-decoration は、「線の位置」・「線の種類」・「線の色」を指定することができます。 text-decoration: 線の位置 線の種類 線の色 では、 CSS で下線を引くためにはどのように指定すればよいのでしょうか？ 以下の表を参考にしつつ、「線の位置」「線の種類」を指定してみましょう。 「線の色」はお好みの色でお願いします。 指定内容 指定方法 説明 線の位置 none 線なし line-through 取り消し線 overline 上線 underline 下線 線の種類 solid 一重線 double 二重線 dotted 点線 dashed 破線 wavy 波線 text-decorationのコード・実行結果例 ◆ コード例（HTML） < html lang = “ja” > < head > < meta charset = “UFT-8” > < title > text-decoration 使い方 </ title > < link rel = "stylesheet" href = "style.css" > </ head > < body > < h2 > text-decorationの使い方 </ h2 > < p class = "text-decoration1" > 一重線の下線（赤） </ p > < p class = "text-decoration2" > 二重線の下線（青） </ p > < p class = "text-decoration3" > 点線の下線（緑） </ p > < p class = "text-decoration4" > 破線の下線（橙） </ p > < p class = "text-decoration5" > 波線の下線（紫） </ p > </ body > </ html > ◆ コード例（ CSS ） /* 一重線の下線 */ .text-decoration1 { text-decoration : underline solid red } /* 二重線の下線 */ .text-decoration2 { text-decoration : underline double blue } /* 点線の下線 */ .text-decoration3 { text-decoration : underline dotted green } /* 破線の下線 */ .text-decoration4 { text-decoration : underline dashed orange } /* 波線の下線 */ .text-decoration5 { text-decoration : underline wavy purple } ◆ 実行結果 See the Pen Untitled by yasuko ( @yayafu_ ) on CodePen . text-decoration では、「線の位置」・「線の種類」・「線の色」を指定することで簡単に CSS で下線が引けることが分かりました！ ② border-bottom 続いて、 border-bottom の使い方です。 border-bottom は、「線の種類」・「線の太さ」・「線の色」を指定することができます。 border-bottom: 線の種類 線の太さ 線の色 text-decoration との違いとしては、 「線の太さ」 が指定できるところです。 「線の種類」は、以下の表を参考にし、実際にコード例と実行結果を見てみましょう。 指定内容 指定方法 説明 線の種類 solid 一重線 double 二重線 dotted 点線 dashed 破線 border-bottomのコード・実行結果例 ◆ コード例（HTML） < html lang = “ja” > < head > < meta charset = “UFT-8” > < title > border-bottom 使い方 </ title > < link rel = "stylesheet" href = "style.css" > </ head > < body > < h2 > border-bottomの使い方 </ h2 > < p >< spna class = "border-bottom1" > 2pxの一重下線（赤） </ span ></ p > < p >< spna class = "border-bottom2" > 4pxの二重下線（青） </ span ></ p > < p >< spna class = "border-bottom3" > 6pxの点線下線（緑） </ span ></ p > < p >< spna class = "border-bottom4" > 8pxの破線下線（橙） </ span ></ p > </ body > </ html > ◆ コード例（ CSS ） /* 一重線の下線 */ .border-bottom1 { border-bottom : solid 2px red } /* 二重線の下線 */ .border-bottom2 { border-bottom : double 4px blue } /* 点線の下線 */ .border-bottom3 { border-bottom : dotted 6px green } /* 破線の下線 */ .border-bottom4 { border-bottom : dashed 8px orange } ◆ 実行結果 See the Pen Untitled by yasuko ( @yayafu_ ) on CodePen . 太さを変えたい場合は、 border-bottom を使うと便利です！ ③ background 最後は、 background の使い方です。 CSS に詳しい方はご存知かと思いますが、こちらは背景関連のプロパティを指定するものです。 background を活用することで、まるで 蛍光ペン で引いたような線を CSS で引くことができます。 その際、 linear-gradient の指定が必要ですので注意ください！ background: linear-gradient(transparent 蛍光ペンを引かない線の幅, 線の色 0%); コード例を見た方が分かりやすいかと思いますので、さっそく… backgroundのコード・実行結果例 ◆ コード例（HTML） < html lang = “ja” > < head > < meta charset = “UFT-8” > < title > background 使い方 </ title > < link rel = "stylesheet" href = "style.css" > </ head > < body > < h2 > backgroundの使い方 </ h2 > < p >< spna class = "background1" > 蛍光ペン幅20%の下線（赤） </ span ></ p > < p >< spna class = "background2" > 蛍光ペン幅40%の下線（青） </ span ></ p < p>< spna class = "background3" > 蛍光ペン幅60%の下線（緑） </ span ></ p > < p >< spna class = "background4" > 蛍光ペン幅80%の下線（橙） </ span ></ p > </ body > </ html > ◆ コード例（ CSS ） /* 蛍光ペン幅20%の下線 */ .background1 { background : linear-gradient( transparent 80% , red 0% ) ; } /* 蛍光ペン幅40%の下線 */ .background2 { background : linear-gradient( transparent 60% , blue 0% ) ; } /* 蛍光ペン幅60%の下線 */ .background3 { background : linear-gradient( transparent 40% , green 0% ) ; } /* 蛍光ペン幅80%の下線 */ .background4 { background : linear-gradient( transparent 20% , orange 0% ) ; } ◆ 実行結果 See the Pen Untitled by yasuko ( @yayafu_ ) on CodePen . 　 transparent では、「 蛍光ペン を引かない線の幅」を指定する必要があります。 また、「 蛍光ペン を引かない線の幅」は、【100% -「 蛍光ペン を引きたい幅」】で簡単に求めることができますよ！ 「線の色」は、HTMLカラーコードでも指定することができます。 是非、 CSS で自分好みのおしゃれな下線を作ってみてください！ See the Pen Untitled by yasuko ( @yayafu_ ) on CodePen . まとめ CSS で下線（アウトライン）を引く方法はいかがでしたでしょうか？ CSS のプロパティは大きく分けて3つあるため、用途に応じてプロパティをお使いください！ 改めまして本ブログが、 CSS を使う方の一助となれば幸いです。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに こんにちは、 @rs_tukki です。 12月に ラク スのAdvent Calenderで Cordovaについての記事 を寄稿しましたが、今回もCordovaについての話をさせていただきます。 はじめに Cordovaとは？ Cordova Pluginを自分で作ってみる Cordovaプロジェクトの作成 Pluginの定義(plugin.xml / package.json) ネイティブコードの実装(CheckIsDebugPlugin.java) ネイティブコードを呼び出す(checkIsDebugPlugin.js) 動作確認 おわりに 参考 Cordovaとは？ さて、まずはCordovaについて軽く触れておきます。 Cordova(Apache Cordova) とは、 オープンソース の開発 フレームワーク です。 平たく言えば Spring Framework 等と似たようなものです。 Cordovaの特徴は、同じ ソースコード で、 Android 、 iOS 、ブラウザの3つのプラットフォーム向けにアプリのビルドができることです。 いわゆる「 クロスプラットフォーム 」というやつです。 また、基本的にHTML/ CSS / Javascript で動作するため、バックエンドの知識に明るくないエンジニアでも単純なアプリケーションの開発であればできてしまうのもメリットです。 Cordova Pluginを自分で作ってみる 先ほど「(Cordovaは)基本的にHTML/ CSS / Javascript で動作する」と書きました。 基本的に、というのは文字通り基本的な動作しか実現できないという意味で、 Android や iOS 特有の機能、例えばカメラなんかにアクセスすることはそのままではできません。 そこでどうするかというと、 JavaScript から Java やSwiftのコードを呼び出して使えるようにするわけです。 こういったネイティブ特有の機能を呼び出すためのコード群を「Cordova Plugin」といいます。 Cordova自体はかなり成熟した フレームワーク ですから、主要なネイティブ機能は Apache 公式が プラグイン を整備していたりしますし、 Github を漁ってみればそれこそCordovaユーザが独自に開発した プラグイン が山のように見つかります。 ただし、そういった第 三者 の作成した プラグイン はあまりメンテナンスされていないものが多く、最終更新が3年前、4年前といったものもザラです。 使いたい機能のためのCordova プラグイン を見つけた！と思ったらろくにアップデートもされておらずエラーになって使用できない……というのはよくある話。 そのような プラグイン はフォークして自分でメンテナンスしてもいいですが、折角なので0から自分で プラグイン を作成するやり方を学んでみましょう。 Cordovaプロジェクトの作成 Cordova Pluginを作成する前に、まずは土台となるCordovaプロジェクトを作成します。 npm installでCordovaをインストールしたら、 cordova create [プロジェクト名] でテンプレートを作成してくれます。便利。 $ sudo npm install -g cordova Password: + cordova@ 11 . 0 . 0 added 129 packages from 59 contributors, removed 36 packages, updated 125 packages and moved 2 packages in 15 .838s $ cordova create testApp Creating a new cordova project. $ Cordovaプロジェクトの作成直後は、以下のようなツリー構造になっています。 $ tree . ├── config.xml ├── package.json └── www ├── css │   └── index.css ├── img │   └── logo.png ├── index.html └── js └── index.js 4 directories, 6 files www ディレクト リがCordovaで画面表示や画面遷移を実現するための核となる部分です。 これだけでも最低限アプリは動くようになっていますが、今回は Android 向けのCordova プラグイン を実装して、 「今開いているアプリがdebugビルドかどうか」を判定できるようにしてみましょう。 先に結論から言ってしまうと、 プラグイン の実装後は以下のようなツリー構造になります。 $ tree . ├── config.xml ├── package.json ├── plugin │   └── cordova-plugin-checkIsDebug │   ├── package.json │   ├── plugin.xml │   ├── src │   │   └── android │   │      └── CheckIsDebugPlugin.java │   └── www │   └── checkIsDebugPlugin.js └── www ├── css │   └── index.css ├── img │   └── logo.png ├── index.html └── js └── index.js 10 directories, 11 files Pluginの定義(plugin. xml / package. json ) まずは、Cordova プラグイン を利用するために必要な設定を記載していきます。 まずはファイル全体をぺたり。 <? xml version = "1.0" encoding = "UTF-8" ?> <plugin xmlns = "http://apache.org/cordova/ns/plugins/1.0" id = "cordova-plugin-check-is-debug" version = "1.0.0" > <name> Check is Debug Plugin </name> <description> check whether cordova app is debugMode </description> <author> rs_tukki </author> <license> MIT License </license> <engines> <engine name = "cordova" version = ">=7.0.0" /> </engines> <js-module src = "www/checkIsDebugPlugin.js" name = "pluginBridging" > <clobbers target = "checkIsDebug" /> </js-module> <platform name = "android" > <config-file target = "res/xml/config.xml" parent = "/*" > <feature name = "CheckIsDebug" > <param name = "android-package" value = "com.rs.tukki.testapp.plugin.checkisdebug.CheckIsDebugPlugin" /> </feature> </config-file> <source-file src = "src/android/CheckIsDebugPlugin.java" target-dir = "com/rs/tukki/testapp/plugin/checkisdebug/" /> </platform> </plugin> Plugin. xml ではこの プラグイン の名前やバージョン、どのようにその プラグイン を呼び出すかといった情報を定義しています。 特に重要なのは <engines> 、 <js-module> 、 <platform> の各ディレクティブです。 では一つづつ解説していきます。 <engines> <engine name = "cordova" version = ">=7.0.0" /> </engines> <engines> ディレクティブでは、この プラグイン を使用するのに要求されるCordovaのバージョンを指定できます。 省略しても問題ない項目ではありますが、あまりにも古いCordovaを使用していると使えないケースもありますので、ひとまず7.0辺りを指定しておくとよいでしょう。 <js-module src = "www/checkIsDebugPlugin.js" name = "pluginBridging" > <clobbers target = "checkIsDebug" /> </js-module> <js-module> ディレクティブでは、Plugin内で外部から参照させるためのjsファイルを指定できます。 今回のPluginではCordovaプロジェクト本体とネイティブコードの橋渡しとして、 www/ ディレクト リ内に checkIsDebugPlugin.js を追加していますので、これを src 属性に指定します。 name 属性は開発者が参照することはないので、任意の名前をつければOKです。 重要なのは内部の colobbers 要素で、ここの target 属性で指定した値を使ってCordovaプロジェクトから関数として呼び出すことになります。 <platform name = "android" > <config-file target = "res/xml/config.xml" parent = "/*" > <feature name = "CheckIsDebug" > <param name = "android-package" value = "com.rs.tukki.testapp.plugin.checkisdebug.CheckIsDebugPlugin" /> </feature> </config-file> <source-file src = "src/android/CheckIsDebugPlugin.java" target-dir = "com/rs/tukki/testapp/plugin/checkisdebug/" /> </platform> <platform> では、各プラットフォームごとにどのような設定やネイティブコードが必要かを定義しています。 今回は Android に絞って解説します。 最初の <config-file> ディレクティブでは、「この プラグイン はこのような形でこのクラスを呼び出します」という情報を config.xml に追記するための設定を行なっています。 <feature> 要素の name 属性が特に重要で、この値は cordova.exec というネイティブコードを呼び出すための関数で第三引数に指定する必要があります。(後述) <param> 要素の value 属性には呼び出す対象となるクラスをパッケージ名を含めて記載してください。 <source-file> 要素には、 Android 向けにプロジェクトを構築する際、ネイティブコードをプロジェクトに含めるために追加する必要がある項目です。 この記載がないとプロジェクト内にネイティブコードが含まれず、当然呼び出しに失敗します。 src 属性はこの plugin.xml からの 相対パス で java ファイルを指定します。 target-dir 属性は構築されたプロジェクトでのファイルの配置先の指定に使います。 ここまで記載できればネイティブコードを呼び出す最低限のPlugin. xml としてはOKです。 (実際はネイティブコードを一切呼び出さないCordova プラグイン もあったりしますが...それはまた次の機会に) 続いてpackage. json を作成します。 ここでは依存性の注入や最初に呼ばれる スクリプト の設定などが行えます...が、 プラグイン を OSS として公開する必要がなく、最低限の実装だけ行いたい場合は必須の2項目だけ記載しておけばよいでしょう。 { " version ": " 1.0.0 ", " name ": " cordova-plugin-check-is-debug " } そのほかの設定項目は以下を参考にしてみてください。 qiita.com ネイティブコードの実装(CheckIsDebugPlugin. java ) さて、次は プラグイン の本体となる Java クラスを実装していきます。 Java でCordova プラグイン を実装する場合、 CordovaPlugin クラスを継承したクラスを作成し、 executeメソッドをOverrideして処理を記載していきます。 今回はdebugビルドかどうかを取得したいので、 java コード上で判定処理を組み込み、返却用の JSON オブジェクトに格納します。 package com.rs.tukki.testapp.plugin.checkisdebug; import org.apache.cordova.CordovaPlugin; import org.apache.cordova.CallbackContext; import org.json.JSONArray; import org.json.JSONException; import org.json.JSONObject; import io.cordova.hellocordova.BuildConfig; public class CheckIsDebugPlugin extends CordovaPlugin { @Override public boolean execute(String action, JSONArray args, CallbackContext callbackContext) throws JSONException { JSONObject result = new JSONObject(); if (BuildConfig.DEBUG) { result.put( "isDebug" , true ); } else { result.put( "isDebug" , false ); } callbackContext.success(result); return true ; } } 最終的に、executeはbool値を戻り値として返します。 trueなら成功時のcallbackが、falseなら失敗時のcallbackが呼ばれます。 この前に、callbackContextのsuccessメソッドもしくはerrorメソッドにパラメータを格納しておけば、callback内でその値を参照することができます。 ネイティブコードを呼び出す(checkIsDebugPlugin.js) さて、次はこのネイティブコードをフロント側から呼び出せるようにします。 ネイティブコードは直接Cordovaプロジェクト側から呼び出す方法もなくはないですが、基本的には一旦 プラグイン 内のjsコードを挟むことになります。 const CheckIsDebugPlugin = function () { } ; CheckIsDebugPlugin.prototype.isDebug = function (success, fail) { cordova.exec(success, fail, "CheckIsDebug" , "isDebug" , [] ); } ; const checkIsDebug = new CheckIsDebugPlugin(); module.exports = checkIsDebug; cordova.exec はネイティブコードを呼び出すためのメソッドです。 第一引数と第二引数はそれぞれ成功時、失敗時のコールバック、 第三引数は plugin.xml の feature 要素で指定した値、 第四引数はネイティブコード内で処理を判別するための文字列、 第五引数は任意のパラメータを取ります。 この関数をexportsすることで、 Plugin.xml の clobbers 要素で指定したtarget名で呼び出すことができます。 すなわち、実際に呼び出す際は以下のような形になります。 成功した場合のコールバック処理でははdebugビルドかどうかを表示するようにしておきましょう。 window .checkIsDebug.isDebug(result => { console.log(result.isDebug); document .getElementById( "isDebug" ).textContent = "debugMode is " + result.isDebug; } , err => { console.log(err); document .getElementById( "isDebug" ).textContent = "error!:" + err; } ); 動作確認 さて、これでPluginを導入したCordovaアプリのサンプルが作成できましたので、 早速実機で動作確認をしてみましょう。 アプリの動作確認は、以下の順序で行います。 なお、 Android でビルドを行う場合は SDKにパスを通す 必要があるので忘れずに行っておきましょう。 cordova plugin add [フォルダパス] で作成したCordova Pluginを登録する cordova platform add [プラットフォーム名] で各プラットフォーム向けにビルドの準備をする cordova run [プラットフォーム名] でアプリをビルドし、実行する release向けにビルドを行う場合はもう少し詳細に設定が必要ですが、debug版での動作確認はひとまずこれだけできれば十分です。 $ cordova plugin add plugin/cordova-plugin-check-is-debug Installing " cordova-plugin-check-is-debug " for android Adding cordova-plugin-check-is-debug to package.json $ cordova platform add android Using cordova-fetch for cordova-android@^ 9 . 0 . 0 Adding android project... Creating Cordova project for the Android platform: Path: platforms/android Package: io.cordova.hellocordova Name: HelloCordova Activity: MainActivity Android target: android-29 Subproject Path: CordovaLib Subproject Path: app Android project created with cordova-android@ 9 . 1 . 0 Discovered plugin " cordova-plugin-whitelist " . Adding it to the project Installing " cordova-plugin-whitelist " for android Adding cordova-plugin-whitelist to package.json $ cordova run android Checking Java JDK and Android SDK versions ANDROID_SDK_ROOT =/Users/your_name/Library/Android/SDK ( recommended setting ) ANDROID_HOME =/Users/your_name/Library/Android/SDK ( DEPRECATED ) Using Android SDK: /Users/your_name/Library/Android/SDK Starting a Gradle Daemon ( subsequent builds will be faster ) Deprecated Gradle features were used in this build, making it incompatible with Gradle 8 . 0 . You can use ' --warning-mode all ' to show the individual deprecation warnings and determine if they come from your own scripts or plugins. See https://docs.gradle.org/ 7 . 3 /userguide/command_line_interface.html #sec:command_line_warnings BUILD SUCCESSFUL in 7s 1 actionable task: 1 executed Subproject Path: CordovaLib Subproject Path: app Downloading https://services.gradle.org/distributions/gradle -6 .5-all.zip ............. 10 %.............. 20 %.............. 30 %.............. 40 %.............. 50 %.............. 60 %.............. 70 %.............. 80 %.............. 90 %.............. 100 % Starting a Gradle Daemon ( subsequent builds will be faster ) Deprecated Gradle features were used in this build, making it incompatible with Gradle 7 . 0 . Use ' --warning-mode all ' to show the individual deprecation warnings. See https://docs.gradle.org/ 6 . 5 /userguide/command_line_interface.html #sec:command_line_warnings BUILD SUCCESSFUL in 1m 57s 40 actionable tasks: 40 executed Built the following apk ( s ) : /Users/your_name/workspace/testApp/platforms/android/app/build/outputs/apk/debug/app-debug.apk Checking Java JDK and Android SDK versions ANDROID_SDK_ROOT =/Users/your_name/Library/Android/SDK ( recommended setting ) ANDROID_HOME =/Users/your_name/Library/Android/SDK ( DEPRECATED ) Using Android SDK: /Users/your_name/Library/Android/SDK Deploying to device 0B161FDD4001VQ Using apk: /Users/your_name/workspace/testApp/platforms/android/app/build/outputs/apk/debug/app-debug.apk Package name: io.cordova.hellocordova INSTALL SUCCESS LAUNCH SUCCESS コマンドを実行してアプリを起動すると、 デフォルトのTOPページに新しく追加した DEBUGMODE IS TRUE の文字が確認できるかと思います。 おわりに 今回は、Cordovaプロジェクトの新規作成から、 Android 向けのCordova プラグイン を作成して動作確認するところまでを実装してみました。( iOS はまた機会があれば……) 仕組みさえ理解してしまえばKotlinやSwiftのネイティブアプリと遜色ないアプリを作れますし、なによりフロントエンドの知識で画面制御を実現できるのが圧倒的に便利ですので、まず何かアプリを作ってみたい！という方はCordovaを試してみてはいかがでしょうか。 参考 Apache Cordova Cordovaを使って、Androidの実機実行するまで - Qiita MacでCordovaのインストール・実行・ビルドまで (iOS, Android, Web) | 株式会社TKS2 Cordova PluginのJavaScript部分の実装 - Qiita package.jsonの中身を理解する - Qiita BuildConfig クラスでアプリの動作を切り替える | まくまくAndroidノート Cordova Pluginの基本事項 - Qiita Cordovaプラグインを開発してみよう！ – モナカプレス エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

勤怠開発課のy_konnoです。 暇があるとNoSQLを漁りだす癖があるんですが、今回はRethinkDBが気になったので試してみたので書いてみようと思います。 NoSQLとは RethinkDBとは セットアップ 基本的な使い方 接続 DB作成・テーブル作成 INSERT UPDATE SELECT DELETE Change Feeds いじってみた感想 NoSQLとは まず先にNoSQLについて軽く触れておきましょう。 NoSQLとはデータを関係テーブルとは異なる何らかの方法で保存するタイプのデータベースです。 キーバリュー、ドキュメント、グラフなどがNoSQLでよく用いられます。 NoSQLは特定のデータモデルに特化した設計がなされています。 このためNoSQLを用いるとより柔軟なデータ設計ができたり、パフォーマンスを高めることが容易になったり、簡単にスケールアウトする構成をとれたりします。 代表的なNoSQLプロダクトは以下のとおりです。 NoSQLプロダクト例 キーバリュー：Redis ドキュメント：MongoDB グラフ：Neo4j RethinkDBとは RethinkDBはNoSQLの一つで オープンソース のドキュメント指向データベースです。 当初RethinkDB社が開発やサポートを行っていたようですが、紆余曲折を経て現在は Linux Foundationに寄贈され、開発が継続されているようです。 データの操作はRethinkDB query language(ReQL)によって行います。 複数のReQLをチェーンしたり、遅延実行することが可能です。 大きな特徴の一つとして、更新結果をリアルタイムでPUSHする機構があります。 これにより変更をポーリングすること無く連続的に取得する事が可能となっています。 その他にも クラスタリング やMap Reduceなどの大規模向けの機能や、テーブルのJOIN、複数の2次インデックスのサポートなど非常に多岐にわたる機能が提供されています。 公式のクライアントは JavaScript 、 Python 、 Ruby 、 Java の4つが用意されています。 他の処理系であってもコミュティによる開発が行われています。 セットアップ サーバーは Windows 、 Mac 、 Linux いずれの環境にも対応していますが、公式のDockerイメージが用意されているのでそちらを利用します。 本稿執筆時点でのバージョンは2.4.1を利用しています。 https://hub.docker.com/_/rethinkdb docker pull rethinkdb Pullが完了したら起動します。 RethinkDBにおける通信のポートは28015なので割当てます。 また、Webの管理コンソールも同梱されているのでついでに利用できるようにしておきます。 そちらのポートは8080です。 docker run -d -p 8080:8080 -p 28015:28015 --name rethink1 rethinkdb RethinkDBのWeb管理コンソールはブラウザから localhost :8080でアクセスできます。 テーブルの確認・作成・削除やドキュメントの確認などの操作を行えます。 ひとまず、これでRethinkDBの利用準備が整いました。 基本的な使い方 まずは、RethinkDBの基本的な使い方を見てみます。 ここでは一通り CRUD をしてみようと思います。 クライアントは Java です（ JDK は11想定）依存関係の追加方法はそれぞれ以下になります。 ・Gradle dependencies { implementation 'com.rethinkdb:rethinkdb-driver:2.4.4' } ・ Maven <dependencies> <dependency> <groupId> com.rethinkdb </groupId> <artifactId> rethinkdb-driver </artifactId> <version> 2.4.4 </version> </dependency> </dependencies> 接続 まずはRethinkDBへのコネクションを生成します。 RethinkDB r = RethinkDB.r; Connection connection = r.connection() .hostname( "localhost" ) .port( 28015 ) .connect(); これだけです。 RethinkDBの インスタンス の生成時の名称（ r ）に若干ぞわぞわしますが、それ以外は至ってわかりやすいかと思います。 なお、コネクションの取得時に タイムアウト や認証系の情報も設定できます。 以降は、このコネクションを使ってINSERTやSELECTなどの操作を行っていきます。 DB作成・テーブル作成 RethinkDBでは、一般的な RDB のようにデータベースとテーブルがあります。Dockerのコンテナ作成時に、デフォルトで test というデータベースを作成してくれるようです。 仮に test データベースが無い場合は、以下で生成できます。 r.dbCreate( "test" ).run(connection); 今回は用意された test データベース上に、 sales というテーブルを作成してみます。 r.db( "test" ) .tableCreate( "sales" ) .run(connection); DB コマンドで test データベースを選択し、そこに tableCreate コマンドで sales を指定、あとは run コマンドでRethinkDBサーバーへコマンドを送信するという流れです。 すでに sales テーブルが存在する場合は、 ReqlOpFailedError 例外が発生します。 なお、 CREATE IF NOT EXISTS のような便利機能はないので、同等のことをやる場合は tableList コマンドでテーブルをリストアップし、存在しなければ tableCreate を実行するという手順を踏む必要があります。 INSERT テーブルができたので、データを追加してみます。 一気に3件のデータを入れてみます。 List<Object> insertData = r.array(r.hashMap( "name" , "apple" ) .with( "price" , 100 ) .with( "quantity" , 5 ) .with( "payment" , "cash" ), r.hashMap( "name" , "banana" ) .with( "price" , 200 ) .with( "quantity" , 3 ) .with( "payment" , "cash" ), r.hashMap( "name" , "melon" ) .with( "price" , 5000 ) .with( "quantity" , 1 ) .with( "payment" , "credit" ) ); r.table( "sales" ) .insert(insertData) .run(connection); 実行後、Web管理コンソールで確認すると以下のようなデータが入っています。 id name payment price quantity 29f94218-1ef9-4c3b-9dfb-1f92a231b9e8 apple cash 100 5 1fbf055e-48ba-4061-9001-98ecf8053c1f banana cash 200 3 d94a7dba-4d33-482b-ae0d-2164557469b3 melon credit 5000 1 INSERT時にはidを指定していませんが、これはPKをテーブル作成時に指定しなかったために作成されているデフォルトのカラムになります。 値はUUIDが自動的に挿入されるので、上記の値は一例です。 UPDATE 次にUPDATEをしてみます。 先程INSERTしたmelonのドキュメントを変更してみます。 r.table( "sales" ) .get( "9769473a-eeb5-4b7f-b877-218cb6942796" ) .update( r.hashMap( "price" , 10000 ) .with( "quantity" , 10 ) ) .run(connection); 特定のドキュメントだけを更新するにはまず、 get で対象のIDを指定してUPDATEする対象を制限する必要があります。 あとはUPDATEしたい項目だけ、新しい値を指定すればOKです。 get をしない場合は、テーブル内のすべてのドキュメントを一括で更新する挙動になります。 また、ID指定ではなく特定の条件でUPDATEする場合は以下のように filter を使います。 r.table( "sales" ) .get( "9769473a-eeb5-4b7f-b877-218cb6942796" ) .update( r.hashMap( "price" , 10000 ) .with( "quantity" , 10 ) ) .run(connection); SELECT 次にSELECTをしてみます。 UPDATEと同じく、全件取得か特定のドキュメントを取得するかで若干処理が変わります。 まずは全件取得をしてみます。こちらは非常にシンプルです。 ・全件取得 Result<Object> selectAllResults = r.table( "sales" ).run(connection); selectAllResults.forEach(e -> /* Do something. */ ); 単純にテーブルを指定して run するだけです。 戻り値の Result<Object> を回せば、各ドキュメント内容を個別に処理できます。 もちろん、Streamにも対応しています。 次は、特定の項目だけフィルタして取得してみます。 ・特定の項目だけ取得 Result<Object> selectFilteredResult = r.table( "sales" ) .filter(e -> e.g( "payment" ).eq( "cash" )) .run(connection); selectFilteredResult.forEach(e -> /* Do something. */ ); filter に条件を指定します。 ここでいう filter は Java のStreamのものではなく、ReQL独自のものです。 上記の例では、 payment が cash に合致するものだけを取得するようにしています。 取得後の イテレーション も全件取得と同じです。 なお、UPDATEのときのように、GETでPKを指定してドキュメントを取得することも可能です。 DELETE 最後にDELETEをしてみます。まずは簡単な全件削除から。 ・全件削除 r.table( "sales" ).delete().run(connection); テーブルを指定して、 delete を呼ぶだけという非常に簡素で直感的な作りです。 挙動としてはTRUNCATEみたいなものですね。 次に条件にマッチしたドキュメントだけ削除してみます。 ・特定の項目だけ削除 r.table( "sales" ) .filter(e -> e.g( "price" ).gt( 200 )) .delete() .run(connection); やはりここでも、 filter を使って条件を指定します。 上記では price が200超のものだけが削除されます。 Change Feeds さて、ここまで基本的な操作をみてきましたが、やりたいのはそんなことじゃなくて、リアルタイム機能の中核であるChangeFeedsです。 Change Feedsは、RethinkDBにおけるリアルタイム機能の中核をなすものです。 テーブルやドキュメント、あるいは特定のクエリの結果などの変更を、その都度クライアントが受け取ることができます。 ほぼすべてのReQLクエリがChange Feedsの処理対象にできるようです。 早速、変更を受け取る側のコードを組んでみましょう。 ・Change Feeds（サブスクライブ側） Result<Object> changeFeeds = r.table( "sales" ).changes().run(connection); for (Object change : changeFeeds) { // Do something with change feeds. } そう、たったこれだけです。 あとはループの中でやりたいことを記述すれば終わりなのです。 上記の例では、 sales テーブルに何らかの変更が入る都度ループ内の処理が実行されます。 このループ部分はそのままだと永久に終わらないので、ループの後かつ外に記述した処理はそのままでは実行されません。 この手の機能を使う場合、通常は稼働する限り変更を受け取って処理しようとするのでそれで問題はありませんが、任意のタイミングで止めたいようなケースでは何らかの方法でループを抜け出すように手を加える必要があります。 いじってみた感想 ここまで、RethinkDBの基本的な使い方とChangeFeedsについてみてきました。 ReQLは癖がなく記述しやすい印象を受けました。 あと、ChangeFeedsによる変更の受け取りが極めて楽なことには驚きました。 NoSQLは数も多くそれぞれ得手不得手が分かれるので、うまいことハマる ユースケース があったら採用してみたいところですね。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは、技術広報の yayawowo です。 株式会社 ラク スは、継続して技術イベントを開催し日々の業務で培った技術コンテンツの発信を行っております。 有難いことに、 connpass 上で開催しているイベント参加者は、延べ年間1万人を超えており、多くのエンジニア/デザイナーの皆様からも反響をいただいております。 そして・・・今回ついに！ その集大成として2/8(火)に 「 RAKUS Tech Conference2022 」 を開催させていただきます！ ◆こんな方にオススメ！ ・ ラク スの開発における挑戦や現状の課題、今後のビジョンを知りたい方 ・ ラク スの開発組織戦略/インフラ戦略を知りたい方 ・ 新技術を取り入れたい方（フロンエンド分離,React.js,TypeScript,GraphQL) ・ レガシーシステム のバージョンアップ対応をされる方（PHP8,Laravel） ・ モダンな開発スタイルとハイブリッドなアプローチ方法に興味がある方 ・ オンプレ環境における Kubernetes 導入の難しさを知りたい方 などなど 本ブログでは、 RAKUS Tech Conference2022 の見どころだけでなく、 現場最前線のエンジニア達から普段の活動や開発・運用で得た知見などの技術情報してきた、 ラク スMeetupの発表実績をまとめさせていただきました！ 是非ご確認ください！ RAKUS Tech Conference 2022 RAKUS Tech Conference 2022の見どころ 開催概要 タイムテーブル 参加申込方法・申込特典 参加申込はこちら 申込特典のご案内 活動実績 2018年度 2019年度 2020年度 2021年度 2021年度最後のラクスMeetup 最前線エンジニア達が語るSaaS開発の裏話／API連携、自動化、インフラ さいごに RAKUS Tech Conference 2022 RAKUS Tech Conference2022 は ラク スが初めて開催するオンラインテックカンファレンス です！ ラク ス開発組織は「顧客をカスタマーサクセスに導く圧倒的に使いやすい SaaS を創る」というミッションを掲げ、 お客さまに必要とされる高品質な SaaS を生み出すべく開発に取組んでおります。 contents.rakus.co.jp RAKUS Tech Conference 2022の見どころ ラク スは「ITサービスで企業の成長を継続的に支援します」をミッションに掲げ、 メール共有・管理システムのメールディーラーや、経費精算システムの楽楽精算など、 延べ70,000社を超えるお客様に自社開発した クラウド サービスを提供しています。 今回の「 RAKUS Tech Conference2022 」では、開発本部の開発マネージャーやテッ クリード が、 日々の業務で培った技術コンテンツの発信を多数予定しております。 大規模 SaaS に携わる業務の中での課題や教訓が、 SaaS 開発に携わる方の一助となれば幸いです！ 開催概要 日時　：2022/2/8(火) 14:00-18:00 会場　：オンライン 参加費：無料 主催　： 株式会社ラクス Twitter ハッシュタグ ： #RAKUSTechCon タイムテーブル 発表内容の詳細につきましては、 イベント公式ページ も合わせてご確認ください。 開始時間 タイトル 登壇者 14:00 オープニング 執行役員 開発本部長 公手 真之 14:30 楽楽精算のサービスと共に成長するエンジニア組織の3年間とこれから 第三開発部長 間澤 創 楽楽精算開発2課 マネージャー 森山 純 楽楽精算開発3課 マネージャー 稲垣 剛之 15:00 トラブルゼロで乗り切ったTypeScript移行 楽楽明細開発課 テッ クリード 三田 英一 15:30 息の長いサービスのPHP8バージョンアップで見えた課題と解決法 楽楽販売開発課 エンジニア 頓花 貴俊 16:00 進化を止めない、"レガシー"との向き合い方 第四開発部長 矢成 行雄 16:30 SaaS マルチヒット メーカー ラク スのインフラ戦略 インフラ開発部 副部長 金本 宏司 17:00 クロージング 執行役員 開発本部長 公手 真之 ※発表内容、タイムテーブルなどは変更となる場合がございますのでご了承ください 参加申込方法・申込特典 参加申込はこちら イベントへの申し込みは、以下3つのいずれか経由でお申込みください！ RAKUS Tech Conference 2022 公式サイト 申込フォーム RAKUS Tech Conference 2022 connpass 申込フォーム RAKUS Tech Conference 2022 TECHPLAY 申込フォーム 申込特典のご案内 RAKUS Tech Conference 2022のイベント アーカイブ 動画を後日配信させていただきます！ 当日参加できない方も対象です。 活動実績 株式会社 ラク スでは、現場最前線のエンジニア達から普段の活動や開発・運用で得た知見などの技術発信の場として ラク スMeetup を開催してきました。 2018年～2021年までの実績をまとめましたので、見逃してしまった方は必見です！ また、当日の雰囲気を楽しんでいただくためのコンテンツとして、公式 Youtube チャンネルにて アーカイブ 動画を公開しております。合わせてご確認ください。 2018年度 ◆ Rakus Meetup Tokyo #1 tech-blog.rakus.co.jp ◆ Rakus Meetup Osaka #1 tech-blog.rakus.co.jp 2019年度 ◆ Rakus Meetup Tokyo #2 tech-blog.rakus.co.jp ◆ Rakus Meetup Osaka #2 tech-blog.rakus.co.jp ◆ Rakus Meetup Tokyo #3 tech-blog.rakus.co.jp ◆ Rakus Meetup Osaka #3 tech-blog.rakus.co.jp 2020年度 ◆ SaaS を支える品質担保術/レガシーコード、 アーキテクチャ 、EOL tech-blog.rakus.co.jp 【 Youtube 】 youtu.be ◆ SaaS を支える開発原則/DDD、 心理的 安全性、Twelve-Factor tech-blog.rakus.co.jp 【 Youtube 】 youtu.be ◆ SaaS 開発リーダーが実践する開発速度向上プ ラク ティス/海外拠点、 スクラム 、時間管理 tech-blog.rakus.co.jp 【 Youtube 】 youtu.be ◆ 大規模 SaaS 、レガシーを吹き飛ばすPHPer実践テクニック / 自動化、機械化、静的解析 tech-blog.rakus.co.jp 【 Youtube 】 youtu.be ◆ SaaS 新規プロダクトの技術 / フロントエンド、RESTful、 AWS サービス、テスト自動化 tech-blog.rakus.co.jp 【 Youtube 】 youtu.be ◆ 持続可能な大規模 SaaS 企業の開発戦略/IaC、技術的負債、オブジェクトストレージ、デリバリー tech-blog.rakus.co.jp 【 Youtube 】 youtu.be ◆ SaaS プロダクトのフロントエンド／Vue.js、React、TypeScript、E2Eテスト tech-blog.rakus.co.jp 【 Youtube 】 youtu.be ◆ PM・ リファクタリング 戦略 tech-blog.rakus.co.jp 【 Youtube 】 youtu.be ◆ PdM・インフラ戦略 tech-blog.rakus.co.jp 【 Youtube 】 youtu.be 2021年度 ◆ 10年以上続く SaaS プロダクトの開発戦略／オール仮想化、E2Eテスト、 リファクタリング tech-blog.rakus.co.jp ◆ SaaS 新規プロダクト開発のプ ラク ティス／ アーキテクチャ 、 AWS 、技術選定、技術的負債 tech-blog.rakus.co.jp ◆ SaaS を支える開発戦略・マネジメント／GraphQL、Flutter、大規模チーム開発、 スクラム tech-blog.rakus.co.jp ◆ 大規模 SaaS のフロントエンド開発／レガシー改善、Vue.js、マルチブラウザ対応 tech-blog.rakus.co.jp ◆ 急成長 SaaS の生産性向上戦略／オフショア、SRE、属人化対策 tech-blog.rakus.co.jp ◆ 大規模 SaaS を支えるインフラ組織の取り組み／自動化、障害対応マニュアル、CI/CD、SRE tech-blog.rakus.co.jp 2021年度最後の ラク スMeetup 最前線エンジニア達が語る SaaS 開発の裏話／ API 連携、自動化、インフラ rakus.connpass.com 3月開催の ラク スMeetupは、新卒ルーキーから主力となったメンバーたちが『最前線の現場とキャリア』について語ります。 内容 登壇者 インフラエンジニアとしての成長記 大阪インフラ開発課／前川 侑輝 右も左も分からない1年目が上流工程を理解するまでの話 楽楽精算開発2課／永田 光一 入社して3年間で『Rundeck』を使って自動化した「面倒」な作業たち 東京インフラ開発3課／金森 聖人 入社してから1～4年目までに経験した課題や教訓を発信し、大規模 SaaS の開発に携わりたい方や、 ラク スの技術領域ご興味をお持ちの学生・若手エンジニアの一助となれば幸いです。 たくさんのご参加をお待ちしています！ さいごに ラク スの技術イベントはいかがでしたでしょうか？ 今回冒頭でお伝えした「RAKUS Tech Conference 2022」は ラク スMeetupとは異なり、 あまり表にでてこない開発本部長や、東京・大阪の開発/インフラのTOP、テッ クリード から若手までが登壇する大型イベントとなります。 大注目のイベントとなりますので、申込だけでもよろしくお願いいたします！ 申し込みはこちら 最後までお読みいただきありがとうございました。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

本稿では、 ベトナム とのオフショア開発において利用できるよう、"リーダブルコード" の内容をもとに筆者が解釈したものを、社内用資料として日本語と ベトナム語 の両方で解説したものです。 *1 この記事を日本チームと ベトナム チームのメンバに読んでもらうことで、"リーダブルコード" の知識がチーム間の共通認識となり、プログラムコードの品質が向上することを目的としています。 全2回を予定しており、第1回である本稿は、「表面上の改善」について解説します。 Trong bài post này, tôi sẽ tóm tắt nội dung của "Readable code" và giải thích bằng cả tiếng Nhật và tiếng Việt, để có thể sử dụng trong việc phát triển Offshore với Việt Nam. Khi team Nhật Bản và team Việt Nam đọc bài viết này, sẽ có cách hiểu chung về kiến ​​thức "Readable code" giữa các team và hướng tới mục đích là để nâng cao chất lượng program. Dự định tổng cộng là có 3 chương, và bài post này là Chương 1, giải thích về "Cải thiện về mặt hình thức". 記事一覧 第1回 表面的な改善 / Cải thiện về mặt hình thức 第2回 ループとロジックの単純化 / Đơn giản hóa Loops and Logic INDEX はじめに / Lời nói đầu コード品質の問題点 / Điểm vấn đề về chất lượng code コード品質向上を目指して / Hướng tới mục đích nâng cao chất lượng code この記事の使い方 / Cách sử dụng bài viết này チーム内の共通言語として / Dưới dạng là ngôn ngữ chung trong team ベトナムでの学習資料として / Dưới dạng tài liệu học ở Việt Nam リーダブルコードについて / Về readable code 1. "見た目" を整えるテクニック / 1. Techniques điều chỉnh "giao diện" 1-1. Consistent Line Breaks and Indents 1-2. Grouping of Code 1-3. Meaningful Order 2. 命名のテクニック / 2. Naming technique 2-1. Not Use Too Generic Names 2-2. Specific Words 2-3. Attaching Information to a Name 2-4. Not Use Abbreviations 2-5. Choice Easy Word 3. コメントのテクニック / 3. Technique về comment 3-1. Comments at Correct Situation 3-2. Recording Your Thoughts 3-3. Add Comment on Constants 3-4. Avoid Ambiguous Pronouns 3-5. Write Examples 3-6. Named Arguments 3-7. Use PHPDoc おわりに / Lời kết ベトナム メンバと理解する「 PHP リーダブルコード」 〜第1回 表面的な改善〜 「 PHP Readable code」hiểu được cùng với member Việt Nam 〜Chương 1 Cải thiện về hình thức〜 はじめに / Lời nói đầu 私 Y-Kanoh は、ここ3年ほど ベトナム にある ラク スの子会社 RAKUS Vietnam とのオフショア開発に携わっています。 私が所属しているチームでは、国内での開発ももちろん行いますが、要件が固まった後の設計から実装、テストまで ベトナム のチームへ依頼することが多く、サービス開発にとって欠かせない存在です。 また、我々のチームでは、オフショア開発でよく言われれる言語や文化の違いによる認識齟齬や、大きな品質低下は少なく、むしろ一部のメンバは日本のメンバよりシステムの理解が深い場合もあるほどです。 しかしながら、この数年でいくつか課題も見えてきました。 その一つが「コード品質」です。 Tôi là Y-Kanoh đã tham gia vào Offshore development với Việt Nam tại Rakus trong khoảng 3 năm qua. RAKUS Vietnam Tất nhiên là tôi cũng phát triển trong nước (tại Nhật) với team mà tôi đang trực thuộc, nhưng chúng tôi thường nhờ Team Việt Nam từ phase thiết kế sau khi đã xác định yêu cầu đến implement và test, và việc phát triển ở Việt Nam đối với phát triển service là sự tồn tại không thể thiếu. Ngo ài ra, trong team của chúng tôi, có rất ít mâu thuẫn về cách hiểu hay sự suy giảm chất lượng lớn bởi sự khác biệt về ngôn ngữ và văn hóa mà thường được cho là vì Offshore development, ngược lại còn có một số member có thể hiểu sâu về hệ thống hơn các member Nhật Bản ... Tuy nhiên, trong vài năm gần đây, chúng tôi cũng nhìn thấy một vài vấn đề. Một trong số đó là "chất lượng code". コード品質の問題点 / Điểm vấn đề về chất lượng code ラク スの ベトナム メンバは品質に関する意識がとても高く、バグを含まないコードを作成していただけてはいるのですが、コードの "保守性" については日本との認識の違いを感じる場面があります。 これは、大きく以下の2点に問題があると考えています。 Các member Việt Nam của Rakus có ý thức rất cao về chất lượng, và đã có thể tạo ra code không có bug, nhưng về "tính bảo trì" của code, đôi khi tôi cảm thấy có sự khác biệt trong cách hiểu với Nhật Bản. Tôi nghĩ rằng điều này có 2 vấn đề chính sau đây. 一つ目は、 日本からフィードバックがしづらい という点です。 弊社では、 ベトナム チームとのコミュニケーションを通訳の方を介することで行っています。通訳の方々にはいつもスピーディに翻訳をしていただいていますが、日本からコードの修正を依頼する場合、【修正を依頼 → 翻訳作業 → ベトナム メンバによる修正 → 翻訳作業 → 修正結果を日本へ提出】 と、時間的なコストがかかってしまうため、修正依頼を躊躇してしまうことあります。（スケジュールに余裕がないときは特に...） 仕様通りにコードは動いているのでバグは生じていませんが、フィードバックを行わなければ、 ベトナム メンバにどのようなコードが保守性が高く、読みやすいのかを伝える機会が減ってしまいます。 また、日本での実装時にはベテランの開発者が画面を指し示し、時には実装者の隣でコードを書きながら「良いコードとはなにか」を伝えることができますが、遠隔地である ベトナム のメンバとはそれができません。同じオフィスで働いていれば、こまめに声かけをして悩んでいる部分にアド バイス を出しながら実装を進めることができますが、 ベトナム での開発時は、遠隔地ゆえに詳しい状況がわからず、コードの実装やテストが終わって日本へ成果物が送られてきた時には、すでに良くない書き方で全てのコードが出来上がった状態であり、修正を依頼するには遅すぎる状態になってしまいます。 Đầu tiên là rất khó để đưa ra Feedback từ phía Nhật . Tại công ty chúng tôi, việc giao tiếp với team Việt Nam được thực hiện thông qua phiên dịch viên. Phiên dịch viên luôn dịch nhanh chóng cho chúng tôi, nhưng khi có yêu cầu chỉnh sửa từ phía Nhật, nếu [Yêu cầu chỉnh sửa → Thực hiện dịch → Member Việt Nam chỉnh sửa → Thực hiện dịch → Gửi kết quả chỉnh sửa cho phía Nhật], thì sẽ làm tốn cost về mặt thời gian, vì vậy đôi khi bị ngại yêu cầu chỉnh sửa. (Đặc biệt là khi schedule không cho phép...) Vì code vẫn đang hoạt động đúng theo specification nên không xảy ra bug, nhưng mà nếu không thực hiện feedback, sẽ làm giảm cơ hội nói cho member Việt Nam biết code như thế nào là có tính bảo trì cao và dễ đọc. Ngo ài ra, khi implement ở phía Nhật, các developer kỳ cựu có thể vừa chỉ vào màn hình và đôi khi ở bên cạnh implementer, vừa viết code vừa chỉ cho biết “thế nào là good code”, nhưng đối với member Việt Nam nơi xa xôi, thì không thể làm điều đó. Nếu làm cùng văn phòng, có thể thường xuyên gọi nhau, vừa đưa ra advice cho phần đang lo lắng, vừa tiến hành implement, nhưng khi phát triển ở Việt Nam, thì không biết tình hình chi tiết vì xa xôi, khi implement hay test code xong và thành phẩm được gửi cho phía Nhật, thì sẽ ở trạng thái tất cả các code đã được hoàn thành theo cách viết không tốt và sẽ quá muộn để yêu cầu chỉnh sửa. 二つ目の理由は、 ベトナム における学習のしづらさ です。 以前、私が ベトナム に行った時、現地のメンバは学習に英語の書籍を使っていると聞きました。 ベトナム では日本のように技術書が翻訳されて販売されていることがまだ少なく、開発者の スキルアップ のためには英語での学習が必須だそうです。 私は英語が全く読めないので、私が英語でのみの学習をしなければいけない状態になったとしたら、スキルの上達はほぼ見込めなくなると思います 笑 ベトナム のメンバは少なくとも私より英語が得意ですが、やはり母国語でない言語での学習は負荷が高いのではないのでしょうか。 Lý do thứ hai là khó khăn trong việc học ở Việt Nam . Trước đây, khi tôi sang Việt Nam, tôi có nghe nói rằng các member ở đây sử dụng sách tiếng Anh để học. Ở Việt Nam, sách kỹ thuật mà được dịch và bán như ở Nhật Bản vẫn rất ít, để nâng cao kỹ năng của các developer dường như là bắt buộc phải học bằng tiếng Anh. Tôi thì hoàn toàn không thể đọc tiếng Anh, vì vậy nếu tôi chỉ học bằng tiếng Anh, thì tôi nghĩ là gần như không thể mong đợi nâng cao được kỹ năng của mình ( lol ) Các Member Việt Nam ít nhất cũng giỏi tiếng Anh hơn tôi, nhưng việc học bằng ngôn ngữ không phải tiếng mẹ đẻ có thể là một gánh nặng không phải sao. コード品質向上を目指して / Hướng tới mục đích nâng cao chất lượng code これらの問題を解決するために、日本からのフィードバックがやりやすくなり、かつ ベトナム メンバが簡単に習得できるよう、有名な書籍「リーダブルコード」の内容をまとめ、 ベトナム語 に翻訳し、 ベトナム チームに共有することにしました。 せっかくまとめるのであれば、ブログで公開することで他のオフショア開発を行なっているチームにも活用してもらえるかもしれないとの思いから、本記事を書くにいたります。 また、 ラク スのブログで公開するにあたり、サンプルコードは我々の強みでもある PHP で記載することにしました！ 翻訳した文章も載せると、ブログの本文がかなりの文字量になってしまいます。そのため書籍の内容を3回に分けて解説します。 Để phía Nhật dễ feedback hơn và các member Việt Nam có thể học một cách dễ dàng, chúng tôi đã tổng hợp nội dung của cuốn sách nổi tiếng “Readable Code”, dịch sang tiếng Việt và chia sẻ cho team Việt Nam. Nếu đã cất công tổng hợp, thì tôi sẽ viết bài này và xuất bản trên blog, vì tôi nghĩ rằng các team đang phát triển offshore khác cũng có thể sử dụng được. Ngo ài ra, tôi đã quyết định là khi xuất bản trên blog của Rakus, sẽ viết sample code bằng PHP là thế mạnh của chúng tôi! Nếu post cả văn bản đã dịch, thì văn bản của blog sẽ có một lượng ký tự khá lớn. Vì vậy, tôi sẽ chia nội dung của cuốn sách làm 3 phần để giải thích. この記事の使い方 / Cách sử dụng bài viết này チーム内の共通言語として / Dưới dạng là ngôn ngữ chung trong team 各テクニックを日本語と ベトナム語 の両方で記述しています 各テクニックには、英語での名称をつけています 日本も ベトナム も使える英語のテクニック名があることで、フィードバック時に指し示しやすくなります 英語名は原著をもとに、簡易な単語を利用しています フィードバックや議論時に、この記事のリンクを貼るとさらに伝わりやすくなります Mô tả từng technique bằng cả tiếng Nhật và tiếng Việt Từng technique sẽ có đặt tên bằng tiếng Anh Khi có technique name tiếng Anh mà phía Nhật và Việt Nam đều có thể sử dụng, thì sẽ dễ dàng chỉ ra hơn khi feedback Tên tiếng anh sẽ dựa trên bản gốc và sử dụng từ đơn giản Khi feedback hoặc thảo luận, nếu gắn link của bài viết này thì sẽ dễ truyền đạt hơn Sample 1： [Japanese] ここの関数名は分かりづらいです。「2-2. Specific Words」を意識しましょう [Vietnamese] Tên hàm ở đây bị khó hiểu. Hãy lưu ý「2-2. Specific Words」 https://tech-blog.rakus.co.jp/entry/20220201/ReadableCodeWithVietnam01#2-2-Specific-Words Sample 2： [Japanese] この定数は何を示しているのかコメントを残して欲しいです。 詳しくはこちらの「3-3. Add Comment on Constants」を参照してください。 [Vietnamese] Tôi muốn là để lại comment rằng constant này chỉ điều gì. Về nội dung chi tiết thì hãy tham khảo「3-3. Add Comment on Constants」ở đây https://tech-blog.rakus.co.jp/entry/20220201/ReadableCodeWithVietnam01#3-3-Add-Comment-on-Constants ベトナム での学習資料として / Dưới dạng tài liệu học ở Việt Nam ベトナム語 に翻訳しているため、 ベトナム の方でも読みやすいはずです プロジェクトに参画した ベトナム メンバの学習資料として利用できます Vì có dịch sang tiếng Việt nên chắc là đối với người Việt cũng sẽ dễ đọc Có thể sử dụng làm tài liệu học cho member Việt Nam tham gia vào project リーダブルコードについて / Về readable code www.oreilly.co.jp The Art of Readable Code リーダブルコード より良いコードを書くためのシンプルで実践的なテクニック 有名なより良いコードを書くためのテクニックがまとめられた書籍です。上記の通り、日本語の翻訳本があります。 この記事では、この"リーダブルコード"の内容を、解釈して ベトナム語 に翻訳しています。 Readable Code là Technique đơn giản và mang tính thực tiễn để viết code tốt hơn Đây là cuốn sách nổi tiếng và tổng hợp technique để viết code tốt hơn. Như đã nói ở trên là có bản dịch tiếng Nhật. Trong bài viết này, tôi sẽ tổng hợp, điều chỉnh nội dung “readable code” này và dịch sang tiếng Việt. それでは、さっそくいきましょう！！ Vậy thì, cùng bắt đầu ngay thôi nào！！ 1. "見た目" を整えるテクニック / 1. Techniques điều chỉnh "giao diện" コードは"動けばいい"ものではありません。 コードを作成したのちに、保守運用を行うのは私たちです。そのためには、できるだけ他の編集者や未来の自分が読みやすいコードであることに気を配るべきです。 Code không phải "chỉ cần hoạt động là được". Sau khi viết code, chúng ta cần vận hành và bảo trì nó. Để làm được điều đó, cần phải lưu ý rằng phải là code càng dễ đọc càng tốt cho developer khác cũng như cho chính mình trong tương lai. 例えば、プログラムコードではなく、雑誌を想像してください。 雑誌では、読み手が読みやすく、重要なことはすぐ目に着くよう、余白や配置、情報のグルーピングに気を使って紙面が設計されています。 Ví dụ, hãy tưởng tượng là một tạp chí, chứ không phải program code. Trong tạp chí, trang giấy được thiết kế với sự chú ý đến margin, bố trí và grouping thông tin để người đọc dễ đọc và những điều quan trọng sẽ được chú ý ngay lập tức. プログラムコードも同じで、次の開発者が誤解なくスピーディに修正が行えるよう、レイアウトには気を配るべきです。 まずはこの「コードの見た目」を整えるためのテクニックを紹介します。 Program code cũng vậy, cần phải chú ý bố cục để các developer tiếp theo không bị hiểu nhầm và có thể chỉnh sửa nhanh chóng. Trước hết, tôi sẽ giới thiệu technique để điều chỉnh "giao diện của code" này. 1-1. Consistent Line Breaks and Indents 統一された改行とインデント Ngắt dòng và thụt lề đã được thống nhất #見た目 #インデント #改行 #統一感 #HìnhThức #Indent #NgắtDòng #CảmGiácThốngNhất 以下のように、インデントがあっていないコードは読みづらくなってしまいます。 見やすくチームで決められたインデントをつけましょう。 Code không có thụt đầu dòng sẽ khó đọc, như dưới đây. Hãy thụt đầu dòng đã được quyết định theo nhóm cho dễ nhìn. ❌ Bad Code <?php class Task { public $ taskName ; public $ status ; private $ user ; private $ deadline ; public function __constractor ( $ name , $ user ) { $ this -> taskName = $ name ; $ this -> user = $ user ; } } 同じように、改行位置も周りと合わせなければ読みづらくなってしまいます。 以下の場合、 toManagerMail のみ改行位置がおかしいので、同じ インスタンス が作成されていることに気づきにくくなっています。 Tương tự, nếu vị trí ngắt dòng cũng không phù hợp với xung quanh, thì sẽ rất khó đọc. Trong trường hợp sau đây, chỉ có toManagerMail có vị trí ngắt dòng bị kỳ cục, vì vậy rất khó để nhận thấy rằng instance tương tự đã được tạo. ❌ Bad Code <?php $ toUserMail = new createMailObject ( $ subject , $ toAddress , $ fromAddress , $ header , $ body , $ attach ) ; $ toCustomerMail = new createMailObject ( $ subject , $ toAddress , $ fromAddress , $ header , $ body , $ attach ) ; $ toManagerMail = new createMailObject ( // Tại sao chỉ có ngắt dòng ở đây?? なぜここだけ改行されてる?? $ subject , $ toAddress , $ fromAddress , $ header , $ body , $ attach ) ; 1-2. Grouping of Code コードのグループ化 Code grouping #見た目 #HìnhThức コードを読む時、コードが意味のある「グループ」にわかれていると読みやすいです。 文章や報告書を作成する時、内容によって段落を分けたり改行を入れたりすることと一緒です。 Khi đọc code, sẽ dễ đọc hơn nếu code được chia thành các "group" có ý nghĩa. Nó cũng giống như việc khi tạo một câu văn hay báo cáo, phải tách đoạn văn và ngắt dòng tùy theo nội dung. ❌ Bad Code <?php function suggestNeverUseRecipes ( $ userId ) { // Lấy recipe (công thức) mà user đã từng tạo và so sánh với recipe đã đăng ký // Sau đó, hiển thị recipe mà chưa từng làm // ユーザが作ったことがあるレシピを取得し、登録されているレシピと比べる // その後、まだ作ったことないレシピを表示する $ user = new User ( $ userId ) ; $ recipeList = $ user -> getMadeRecipeList () ; $ recipeBook = new RecipeBook () ; $ allRecipeList = $ recipeBook -> getAllRecipeList () ; $ suggestRecipeList = array_diff_key ( $ allRecipeList , $ recipeList ) ; $ display [ "user" ] = $ user ; $ display [ "suggestRecipeList" ] = $ suggestRecipeList ; return render ( "sugestRecipe.html" , $ display ) ; } ✅ Good Code <?php function suggestNeverUseRecipes ( $ userId ) { // Lấy recipe mà user đã từng tạo // ユーザが作ったことがあるレシピを取得 $ user = new User ( $ userId ) ; $ recipeList = $ user -> getMadeRecipeList () ; // Lấy tất cả các recipe // 全てのレシピを取得 $ recipeBook = new RecipeBook () ; $ allRecipeList = $ recipeBook -> getAllRecipeList () ; $ suggestRecipeList = array_diff_key ( $ allRecipeList , $ recipeList ) ; // Xử lý hiển thị màn hình // 画面表示処理 $ display [ "user" ] = $ user ; $ display [ "suggestRecipeList" ] = $ suggestRecipeList ; return render ( "sugestRecipe.html" , $ display ) ; } 書いてあるコードが一緒ですが、グルーピングをすることで理解しやすくなりました。 また、グループごとにコメントを入れると、さらにわかりやすくなります。 Code được viết là giống nhau, nhưng nó sẽ trở nên dễ hiểu hơn khi grouping lại. Ngo ài ra, nếu thêm comment cho từng group thì sẽ dễ hiểu hơn nữa. 1-3. Meaningful Order 意味のある順番を選ぶ Chọn thứ tự có ý nghĩa #見た目 #順番 #HìnhThức `#ThứTự ロジックに影響を与えなくても、コードを記載する順番は揃えた方がいいでしょう。 いくつかのデータを同じ処理で処理する場合、場所によって順番が違うと、理解の妨げになります。 以下の例では、 $mailaddress がどこにあるのか不思議に思った時点で、脳のリソースが余計なことに使われてしまっています。 Ngay cả khi không ảnh hưởng đến logic, cũng nên canh chỉnh thứ tự mô tả code sẽ tốt hơn không phải sao? Khi xử lý một số dữ liệu trong cùng một xử lý, nếu thứ tự khác nhau tùy vào vị trí, thì sẽ rất khó hiểu. Trong ví dụ dưới đây, khi phải thắc mắc, suy nghĩ xem $mailaddress nằm ở đâu, thì bạn đang sử dụng chất xám lãng phí. ❌ Bad Code <?php $ userName = $ request -> ( "userName" ) ; $ mailaddress = $ request -> ( "mailaddress" ) ; $ phonNumber = $ request -> ( "phonNumber" ) ; $ zip = $ request -> ( "zip" ) ; $ location = $ request -> ( "location" ) ; : : : if ( $ userName === "" ) { $ errorMessage [] = USER_NAME_EMPTY_ERROR; } if ( $ phonNumber === "" ) { // Ủa? $mailaddress đâu? あれ? $mailaddress は? $ errorMessage [] = PHONE_NUMBER_EMPTY_ERROR; } if ( $ zip === "" ) { $ errorMessage [] = ZIP_EMPTY_ERROR; } if ( $ location === "" ) { $ errorMessage [] = LOCATION_EMPTY_ERROR; } if ( $ mailaddress === "" ) { // Thì ra là ở chỗ này !! こんなところにあった!! $ errorMessage [] = MAILADDRESS_EMPTY_ERROR; } 2. 命名 のテクニック / 2. Naming technique 変数や関数、クラスなど、コード内に記載される "名前" は、"短いコメント" と考えるべきです。 しかし、名前をつけた本人は「わかりやすい」と思っている名前でも、他の人にとってはわかりづらい場合も多いのではないでしょうか。 そのため、常に他者にとって理解の助けになる名前になっているかを考えて名前をつける必要があります。 "Tên" được ghi trong code, chẳng hạn như biến, hàm và class, nên được coi là "comment ngắn". Tuy nhiên, cho dù nó là cái tên mà người đặt tên cho rằng nó "dễ hiểu" thì cũng có khi khó hiểu đối với người khác không phải sao? Vì vậy, cần phải luôn xem xét đặt tên xem liệu cái tên đó có giúp người khác hiểu được hay không. 2-1. Not Use Too Generic Names 一般的すぎる単語を使わない Không sử dụng từ ngữ quá chung chung #命名 #英語 #Naming #English 前述した通り、変数名/関数名は、ある種のコメントです。 いい名前がついていた場合、そのコードを読む人のヒントになります。 コードを書くときに 命名 を考えない場合、次回そのコードを読む人はヒントなしでコードを解読する羽目になります。 わざわざチームメンバや未来の自分にハードモードのステージを用意する必要はありません。 Như đã đề cập trước đó, tên biến/hàm là một loại comment. Nếu gắn một cái tên hay, thì nó sẽ là hint (gợi ý) cho người đọc code đó. Nếu không xem xét đến việc đặt tên khi viết code, người tiếp theo đọc code sẽ rơi vào tình thế đọc code mà không có gợi ý nào. Không cần phải mất công chuẩn bị một cái gì đó quá khó cho các member trong team hoặc chính mình trong tương lai. 以下のような単語は、 命名 をサボったようなものです。 あまりに抽象的で、なにをするための変数名、もしくは関数名なのかわかりません。 このような名前を使いそうになったら、もっと目的に適した具体的な名前があるはずなので、名前をしっかり考えましょう。 もし、どうしても使いたい場合は、スコープが短く、誰が見ても用途が明らかな場合にのみ使用するようにするべきです。 Những từ ngữ như sau đây giống như là lười biếng, tránh né đặt tên. Nó quá trừu tượng nên không biết tên biến hoặc hàm dùng để làm gì. Nếu có vẻ như bạn đang sử dụng một cái tên như vậy, thì chắc là cần có một cái tên cụ thể hơn cho mục đích đó, vì vậy hãy xem xét tên thật kỹ. Nếu thực sự muốn sử dụng nó, thì chỉ nên sử dụng khi phạm vi ngắn và dù ai xem cũng hiểu rõ được công dụng. ❌ Bad Code <?php $ tmp // ... mang tính tạm thời, là cái gì? // 一時的な...なに？？ $ myForm // Bằng với là không có thông tin “my form” // "私のフォーム" 情報が無いに等しい $ retval // Không có thông tin nào ngoài “Giá trị trả về”. Không cần đặt tên biến cũng biết // "戻り値"以外の情報がない。変数名にしなくてもわかる $ i , $ j , $ k // Loop iterator. Chắc là có một cái tên hay hơn // ループのイテレータ。もっといい名前があるはず $ result // Là kết quả của cái gì. Tôi muốn thêm một vài từ // なにかの結果。もう一言欲しい。 2-2. Specific Words 明確な単語を選ぶ Chọn từ rõ ràng #命名 #Naming 以下のような名前は簡単に思いつくので使いやすいですが、いまいち情報不足です。 Ví dụ như cái tên dưới đây vì rất dễ nghĩ ra trong đầu nên dễ sử dụng, nhưng mà không đủ thông tin lắm. ❌ Bad Code <?php function getPage (){ ... } function setLog (){ ... } function checkMailAddress (){ ... } get や set は、明確に何を行うかがわかりづらくなります。 アクセサ（ getter や setter ）のように、特にルールがなく、もっと処理内容を表現できる単語がある場合は使用を避けるべきでしょう。 get và set khi ến bạn khó biết rõ là thực hiện cái gì. Nên tránh sử dụng nó khi không có rule nhất định, và khi có những từ có thể diễn đạt rõ nội dung xử lý hơn, chẳng hạn như Accessor（ getter và setter ） load や fetch ような単語に置き換えてはどうでしょうか。単にget（取得する）だけではなく、どのように取得するのかが伝わりやすくなる単語です。 また、 get や set は、「何か簡単な、負荷のかからない処理」であるイメージがあると思います。 一方で load と聞くと、何か時間のかかる処理に聞こえませんか？ 命名 をするときには、その名前を見た他の開発者がどういう処理を想像するかを考えることも重要です。 （ get って書いてあるから軽い気持ちで使っていたけど、すごく処理に時間がかかる処理だった！なんて事故を減らしましょう。） Nếu thay thế thành từ như là load hay là fetch thì bạn thấy sao? Không chỉ đơn giản là get (lấy), mà là từ “lấy như thế nào” thì sẽ dễ hiểu hơn. Ngo ài ra, tôi nghĩ là get và set làm cho có hình dung là”một xử lý gì đó đơn giản và nhẹ nhàng”. Mặt khác, khi nghe từ load , thì nghe có vẻ như là xử lý gì đó tốn thời gian không phải sao? Khi đặt tên, “việc mà xem xét làm sao cho các developer khác khi nhìn vào tên đó sẽ tưởng tượng ra xử lý như thế nào” cũng quan trọng. (Vì viết là get sẽ sử dụng với cảm giác nhẹ nhàng, nhưng nó là xử lý mất rất nhiều thời gian để xử lý！Nên hãy giảm thiểu sự cố.) ✅ Good Code <?php function downLoadPage (){ ... } function registerLog (){ ... } function isValidMailAddress (){ ... } 明確に意図が伝わらない例として、たとえば以下のような関数があったとします。 この関数は、 filter の意味が曖昧なので、2つの意味で解釈できてしまいます。 Lấy ví dụ về việc ý định không được truyền đạt rõ ràng, tôi giả sử là có hàm sau đây. Hàm này có thể hiểu theo hai cách vì ý nghĩa của filter bị mơ hồ. ❌ Bad Code <?php function filterMailBySendDate ( $ date ){ ... } 解釈1：メール送信日が $date のメールを取得する 解釈2：メール送信日が $date のメールを除く 解釈1の場合、 select を使った方がいいかもしれません。 また、解釈2の場合は、 exclude を使うことで明確になります。 Cách hiểu 1：Lấy mail có ngày gửi mail là $date Cách hiểu 2：Loại trừ mail có ngày gửi mail là $date Nếu là cách hiểu 1 thì có lẽ là nên sử dụng select Ngo ài ra, nếu là cách hiểu 2, thì sử dụng exclude sẽ rõ ràng hơn. ✅ Good Code <?php function selectMailBySendDate ( $ date ){ ... } function excludeMailBySendDate ( $ date ){ ... } 以下にもう少し意味が伝わりやすくなる単語の例をあげました。 もし、置き換えられる言葉があるのであれば、積極的に置き換えましょう。 Tôi đã nêu ra một số ví dụ về các từ giúp truyền đạt ý nghĩa dễ dàng hơn một chút ở dưới đây. Nếu có từ nào có thể thay thế, thì hãy tích cực thay thế nhé! 曖昧な単語 / Từ mơ hồ 明確な単語 / Từ rõ ràng get, set load, fetch, register, add, store send deliver, dispatch, announce, distribute, route find search, extract, locate, recover start launch, create, begin, open make create, set up, build, generate, compose, add, new check isValid, enable, isEmpty, isSaved, exist filter select, exclude 2-3. Attaching Information to a Name 名前への情報追加 Thêm thông tin vào tên #命名 #Naming 変数名には、できるだけ具体的な名前をつけることで、どのような意図で変数を使うかがわかりやすくなります。 それに加えて、なにか"絶対に伝えないといけない情報"があるのであれば、変数名に付け加えることで事故が少なくなります。 Khi đặt tên cho biến cụ thể hết mức có thể, thì sẽ dễ hiểu bạn định sử dụng biến để làm gì. Thêm vào đó, nếu có "thông tin bắt buộc phải truyền tải" nào đó, thì thêm nó vào tên biến sẽ giảm thiểu được sự cố. 🤷‍♂️ NOT Good Code <?php // Không tệ, nhưng nếu có thể bổ sung thêm thông tin thì nên mô tả // 悪くはないが、もう少し情報を付け加えられるのであれば記載するべき $ password $ comment $ fileSize $ delay $ length $ html ✅ Good Code <?php $ plaintextPassword // Hiểu được rằng nó không được encrypte // 暗号化されていないことがわかる $ escapedComment // Hiểu được rằng nó đã được escape // エスケープされていることがわかる $ fileSizeMb // Hiểu được rằng nó là đơn vị MB // MB単位であることがわかる $ delaySec // Hiểu được rằng nó là đơn vị giây // 秒単位であることがわかる $ widthLength // Hiểu được rằng nó là độ dài chiều ngang // 横の長さであることがわかる $ htmlTextUtf8 // Hiểu được rằng nó là UTF-8 // UTF-8になっていることがわかる $fileSizeMb のように、単位を変数に含めるテクニックはぜひやりたいところです。 コードを遡って、この変数に入っている数値の単位がなんなのか、探すのに時間がかかってイライラしたことはありません？？ Tôi muốn nhất định phải thực hiện một technique bao gồm đơn vị trong biến, chẳng hạn như $ fileSizeMb . Bạn đã bao giờ cảm thấy bực bội vì “mất thời gian quay ngược lại code và tìm đơn vị của giá trị số trong biến này là gì” chưa ?? 2-4. Not Use Abbreviations 略語を使わない Không sử dụng chữ viết tắt #省略 #GiảnLược 具体的に、そしてわかりやすく名前を決めようとすると、どうしても長い名前になってしまいます。 しかし、名前を短くするために、意図が伝わらなくなってしまっては意味がありません。 短い名前の方が見やすくていいかもしれませんが、他の人に伝わる名前にすることを優先して考えましょう。 Nếu bạn định là quyết định một cái tên cụ thể và dễ hiểu, tự nhiên thành ra một cái tên dài. Tuy nhiên, vì rút ngắn tên mà không được truyền đạt được ý đồ thì sẽ không có ý nghĩa gì. Tên ngắn có thể dễ đọc hơn, nhưng hãy ưu tiên cái tên có thể truyền đạt cho người khác. また、同じ理由で無理な略語も避けるべきです。 賛否両論あると思いますが、一般的な開発者なら理解できる uid や dao 、 str 、 env のような単語であればまだ利用しても問題ないかもしれません。 ただし、チームに参画したばかりの開発者が読んでわからないような システム独自の略語 は避けるべきです。 たとえば、以下のような名前です。 Ngo ài ra, vì lý do tương tự, bạn cũng nên tránh những từ viết tắt không hợp lý. Tôi nghĩ là sẽ có 2 luồng ý kiến, nhưng có lẽ vẫn ổn khi sử dụng những từ như uid , dao , str , và env mà một developer bình thường có thể hiểu được. Tuy nhiên, bạn nên tránh các từ viết tắt của riêng hệ thống mà các developer mới join vào team đọc vào sẽ không hiểu được. Ví dụ, như là tên sau đây. ❌ Bad Code <?php $ mBox // Viết tắt của MailBox. Mới nhìn lần đầu sẽ không biết “m” là gì // MailBox の略。初見で"m"が何かわからない $ cUrl // Viết tắt của ClickedUrl // ClickedUrl の略 $ BEManager // Viết tắt của BackEndManage // BackEndManage の略 どこまでの略語が許されて、どこからが許されないかの線引きは難しいと思います。 そのため、私は基本的に「迷ったら略語は利用しない」方針で名前を決めるべきだと考えています。 また、「変数名が長くて入力しづらい」と思うのであれば、略語を使う前に IDE の補完入力を覚えましょう。 Tôi nghĩ rất khó để vạch ra ranh giới giữa việc “được viết tắt đến đâu” và “chỗ nào là không được viết tắt”. Vì vậy, về cơ bản tôi nghĩ rằng nên quyết định tên theo phương châm "nếu phân vân thì không sử dụng chữ viết tắt". Ngo ài ra, nếu bạn nghĩ "tên biến dài và khó nhập", hãy nhớ việc IDE completion input (nhập hoàn thành của IDE ) trước khi sử dụng các từ viết tắt. 2-5. Choice Easy Word 簡単な単語を使う Sử dụng các từ đơn giản #命名 #英語 #単語 #Naming #English #Word ここまで、具体的で明確な単語を使うことを述べてきました。 しかし、いくら具体的でも、難しすぎて意味が通じない単語を選んでは意味がありません。 線引きは難しいですが、必要以上に難しい単語を選ばないようにしましょう。 Đến đây, tôi đã mô tả xong việc sử dụng từ một cách rõ ràng và cụ thể. Tuy nhiên, cho dù cụ thể đến đâu, thì nếu chọn 1 từ quá khó không diễn đạt được ý nghĩa thì cũng không có ý nghĩa gì. Rất khó để phân định ranh giới rõ ràng, nhưng hãy cố gắng không chọn những từ khó hơn mức cần thiết. ❌ Bad Code <?php $ investigateRecipe $ manufactureBook ✅ Good Code <?php $ searchRecipe $ createBook 3. コメントのテクニック / 3. Technique về comment コメントは、そのコードを作成した人が残すことができる未来の開発者へのヒントです。 将来そのコードを修正する他者や自分のため、価値のある情報を記載しましょう！！ Comment là hint mà người viết code đó có thể để lại dành cho developer trong tương lai. Vì người khác hoặc chính mình sẽ chỉnh sửa code trong tương lai, hãy mô tả thông tin có giá trị !! 3-1. Comments at Correct Situation 正しい状況でコメントを使う Sử dụng comment với tình huống đúng #コメント #コメント内容 #Comment #NộiDungComment コメントの目的は、" 書き手の意図を読み手に伝えること " です。 そのため、以下のようなコメントは不要です。なぜなら、コードを読めば すぐに 伝わるからです。 Mục đích của comment là " để truyền tải mục đích của người viết đến người đọc ". Vì vậy, những comment như sau đây là không cần thiết. Bởi vì, nếu đọc code, thì sẽ hiểu ngay lập tức . ❌ Bad Code <?php // Lấy thông tin account // アカウント情報を取得する $ account = new Account ( $ id ) ; // Setting user name cho account // アカウントにユーザ名を設定する $ account -> setUserName ( $ name ) ; // Xóa thông tin account // アカウント情報を削除する unset ( $ account ) ; 以下のように、短いコードでも読んですぐにわからないようなコードであれば、コメントをつけるべきです。 Nếu là code ngắn mà đọc vào không hiểu ngay lập tức được như dưới đây, thì nên thêm comment ✅ Good Code <?php // Biểu thức chính quy để kiểm tra xem số điện thoại có dấu gạch nối hay không // ハイフン付きの電話番号であるかを確認する正規表現 $ phoneNumberReg = "/^[0-9]{2,4}-[0-9]{2,4}-[0-9]{3,4}$/" ; 3-2. Recording Your Thoughts 考えを記録する Ghi lại suy nghĩ #コメント #コメント内容 #Comment #NộiDungComment コードには処理内容を記述することはできますが、コードを書いていたときにあなたが考えていたことまでは記述できません。 そのコードを書いていたときに考えていた内容こそ、コメントに記載して後世に残すべきでしょう。 たとえば、以下のような内容です。 Bạn có thể mô tả nội dung xử lý cho code, nhưng khi viết code bạn không thể viết hết những gì bạn đang suy nghĩ. Những gì bạn đã nghĩ khi viết code nên được đưa vào comment và để lại cho thế hệ sau. Ví dụ, nội dung như sau. ✅ Good Code 注釈としてのコメント / Comment như một chú thích <?php // Xử lý này có tốc độ xử lý nhanh hơn mô tả trong loop // この処理はループで記述するより処理速度が速い また、コードを記載しているうちに、そのコードを触るときに注意すべき点があれば、コメントに記載することで他の開発者が罠を踏むことはなくなります。 Ngo ài ra, trong lúc viết code, nếu có điều gì cần phải lưu ý khi đụng vào code đó, thì bạn có thể viết nó trong comment để các developer khác không bị mắc bẫy. ✅ Good Code 罠の警告 / Cảnh báo bẫy <?php // Xử lý này có sai sót và không nên chỉ định mảng có chứa NULL trong phần tử làm đối số. Tại vì …. // この処理には欠陥があり、要素にNULLを含む配列を引数に指定するべきではない。なぜなら... // Lưu ý rằng xử lý sẽ mất thời gian nếu Nest của tag HTML bị sâu. // HTMLタグのネストが深いと処理に時間がかかってしまうので注意 コードを理解するときに、全体像がわかっていると理解が速くなります。 そのため、コードの最初に以下のような全体像を把握できるコメントを書くべきです。 Khi hiểu code, nếu hiểu được bức tranh tổng thể thì sẽ hiểu nhanh hơn. Do đó, bạn nên viết comment ở đầu đoạn code để có thể nắm được bức tranh tổng thể như dưới đây. ✅ Good Code 全体像の共有 / Share về bức tranh tổng thể <?php // Class này là class trao đổi với service liên kết bên ngoài. // このクラスは外部連携サービスとのやりとりを行うクラスです。 // Class này là code xử lý DB từ business logic. Không được phép gọi từ application. // このクラスはビジネスロジックからDBを扱うコードです。アプリケーションから呼んではいけません // Tạo mảng mà chỉ bao gồm user cần hiển thị // 表示すべきユーザのみが含まれる配列を作成する 3-3. Add Comment on Constants 定数にコメントをつける Thêm comment vào constant #コメント #コメント内容 #定数 #Comment #NộiDungComment #HằngSố いわゆる”マジックナンバ”は良くありません。なぜなら、その数値がなんのための数値かわからないからです。 Nói nôm na là “magic number” không được tốt lắm. Lý do là vì không biết được giá trị số đó là giá trị để làm gì. ❌ Bad Code <?php if ( $ fileSizeMb < 20 ) { // "20" là số gì? "20" ってなんの数字？ return FILE_SIZE_ERROR; } しかし、このマジックナンバを定数にしたところで、あまり解決になっていません。 Tuy nhiên, khi set magic number này thành constant, thì nó vẫn chưa được giải quyết nhiều. ❌ Bad Code <?php const FILE_MAX_SIZE_MB = 20 ; if ( $ fileSizeMb < FILE_MAX_SIZE_MB ) { return FILE_SIZE_ERROR; } たしかに、定数名( FILE_MAX_SIZE_MB )から"ファイルの最大サイズ"であることはわかりますが、なぜファイルの最大サイズが20MBなのかはわかりません。 仕様上決まっているのかもしれませんし、もしかしたらこのシステムではそれ以上のファイルを処理すると問題が発生するのかもしれません。 このような場合、マジックナンバを定数にするだけで満足せず、コメントを残すべきです。 Chắc chắn là có thể biết từ constant name ( FILE_MAX_SIZE_MB ) rằng đó là" size tối đa của file", nhưng không biết được size tối đa của file là 20MB. Có lẽ là đã quyết định trên specification, hoặc có thể sẽ xảy ra vấn đề khi xử lý file lớn hơn trong hệ thống này. Trong những trường hợp như vậy, bạn không nên hài lòng với việc chỉ set magic number thành constant mà nên để lại comment. ✅ Good Code <?php // Size tối đa của file // Nếu đăng ký file lớn hơn, thì sẽ không thể đính kèm vào mail thông báo để gửi cho user. // ファイルの最大サイズ。 // これ以上のファイルを登録すると、ユーザへ送信する通知メールに添付できなくなってしまう。 const FILE_MAX_SIZE_MB = 20 ; if ( $ fileSizeMb < FILE_MAX_SIZE_MB ) { return FILE_SIZE_ERROR; } 3-4. Avoid Ambiguous Pronouns 曖昧な代名詞を避ける Tránh các đại từ không rõ ràng #コメント #コメント内容 #Comment #NộiDungComment 代名詞を使うと、意図を正確伝えづらくなります。 とくに我々は母国語が違うので、代名詞が何を指し示しているのか勘違いして理解することが他の開発現場よりとても多いでしょう。 そのため、代名詞はできるだけ使わず、直接的な表現を心がけましょう。 Nếu sử dụng đại từ thay thế sẽ khi ến bạn khó truyền đạt ý định chính xác. Đặc biệt là vì chúng ta có ngôn ngữ mẹ đẻ khác nhau, nên sẽ có rất nhiều khả năng hiểu sai là “đại từ thay thế đang chỉ cái gì” hơn so với các nơi phát triển khác. Do đó, hãy cố gắng sử dụng cách diễn đạt trực tiếp mà không sử dụng đại từ thay thế càng nhiều càng tốt. 日本のメンバは高校での英語の授業を思い出してください。 よくある「Q.下線部Aの"it"が指し示していることはなんですか？」という問題です。 わざわざ高校英語で出てくる読解問題をコメントに含める必要はありませんよね？？ Các member phía Nhật hãy nhớ lại các buổi học tiếng Anh ở trường trung học. Là vấn đề thường gặp như là "Q."it" trong chỗ A được gạch dưới đang chỉ đến điều gì?". Không cần phải đưa các bài tập đọc hiểu xuất hiện trong tiếng Anh cấp 3 vào phần comment nhỉ ??? ❌ Bad Code <?php // Cho data vào Cache. Trước đó, sẽ xác nhận size đó // データをキャッシュに入れる。その前にそのサイズを確認する ✅ Good Code <?php // Cho data vào Cache. Trước đó, sẽ xác nhận size của data // データをキャッシュに入れる。その前にデータのサイズを確認する ✅ More Good Code <?php // Sau khi xác nhận size của data thì cho data vào Cache // データのサイズを確認してから、データをキャッシュに入れる 余談ですが、私は普段の作業指示書作成時にも代名詞や指示語を使わないようにしています。 ただでさえたくさんの翻訳を依頼している翻訳チームのメンバを、これ以上困らせるわけにいかないので。。。 Tôi xin nói ngo ài lề một chút là, cả khi tạo tài liệu chỉ thị công việc bình thường, tôi cũng cố gắng không sử dụng đại từ thay thế hoặc từ chỉ thị. Vì đã yêu cầu dịch rất nhiều rồi nên không thể làm cho các member của team phiên dịch khó khăn (khó dịch) hơn .... 3-5. Write Examples 入出力の具体例を使う Sử dụng ví dụ cụ thể của in/output #コメント #コメント内容 #Comment #NộiDungComment 無理に言葉を使って説明するより、具体例を書いた方がわかりやすいこともあります。 ましてや我々は母国語が違います。言葉で語らずコードで語った方がわかりやすい時もあります。 Đôi khi , việc viết ra một ví dụ cụ thể sẽ dễ hiểu hơn là cưỡng ép giải thích nó bằng lời. Hơn nữa, chúng ta có ngôn ngữ mẹ đẻ khác nhau. Đôi khi sẽ dễ hiểu hơn nếu nói bằng code thay vì bằng lời. ✅ Good Code <?php /* * Xóa các ký tự có trong $char ở đầu và cuối $targetStr * Sample: trimEachStr("abcabcba", "ab") trả về “cabc” * * $targetStr の先頭や末尾にある $char に含まれる文字を取り除く * Sample: trimEachStr("abcabcba", "ab") は "cabc" を返す * **/ function trimEachStr ( $ targetStr , $ char ) { ... } 3-6. Named Arguments 名前付き引数 Đối số có kèm tên #PHP #コメント #Comment PHP には PHP 8.0 の新機能として 名前付き引数 が採用されました!! 名前付き引数は、引数の位置を指定して引数のデフォルト値の利便性を高めるだけでなく、関数呼び出し元でのコメントとして使うことができます。 PHP đã áp dụng Đối số có kèm tên như một tính năng mới của PHP 8.0 !! Đối số có kèm tên không chỉ có thể chỉ định vị trí đối số và nâng cao tính tiện lợi của giá trị mặc định của đối số, mà còn có thể sử dụng làm comment ở nơi gọi hàm. ❌ Bad Code <?php connect ( 10 , false ) ; // Không hiểu ý nghĩa của 10 và false // 10 と false の意味がわからない : : : // connect の定義元を確認して、やっと 10 と false の意味がわかる // Xác nhận nguồn định nghĩa connect, cuối cùng cũng hiểu ý nghĩa của 10 và false function connect ( $ timeOutSec , $ useEncryption ) { ... } ✅ Good Code <?php // Ngay cả khi không xác nhận nguồn định nghĩa connect cũng hiểu được ý nghĩa // connect の定義元を確認しなくても意味がわかる connect ( timeOutSec : 10 , useEncryption : false ) ; : : : function connect ( $ timeOutSec , $ useEncryption ) { ... } 3-7. Use PHPDoc PHPDocを利用する Sử dụng PHPDoc #コメント #PHPDoc #PHP #Comment PHP は、変数の中にintegerもbooleanも、arrayもすべて入れることができてしまうため、期待していない型が変数に入ってしまうことも多々あります。 意図しない値が変数に含まれてしまう可能性を減らすためには、 IDE とPHPDocを利用します。 PhpStormを使っている場合、関数の引数に、PHPDocで記載されている型と違う値が含まれていると警告を表示してくるなど、PHPDocを使って型指定のサポートを行う機能がたくさん含まれています。 そのため、PHPDocは正確に、漏れなく記載しましょう。 また、近年の PHP では引数や戻り値の型を指定できるようになっています。できるだけ型を指定して、その後の修正によって意図しない値が利用されるリスクを減らしましょう。 Vì PHP có thể đặt tất cả các integer, cả boolean, cả array trong các biến, nên thường xảy ra trường hợp “kiểu không mong muốn” được đưa vào các biến. Sử dụng IDE và PHPDoc để giảm nguy cơ các giá trị không mong muốn được bao gồm trong biến. Khi sử dụng PhpStorm, có rất nhiều chức năng sử dụng PHPDoc để support chỉ định kiểu, chẳng hạn như hiển thị cảnh báo nếu đối số của hàm chứa giá trị khác với kiểu được mô tả trong PHPDoc. Do đó, PHPDoc nên được viết chính xác và không thiếu sót. Ngo ài ra, trong những năm gần đây PHP đã có thể chỉ định đối số và kiểu giá trị trả về. Để giảm nguy cơ sử dụng các giá trị không mong muốn, hãy chỉ định kiểu đối số và kiểu giá trị trả về. おわりに / Lời kết コメントや 命名 にここまでこだわって何になるんだ。と思うかもしれませんが、こうした工夫が仕様変更や追加開発に強い"保守性が高いサービス"を作り出します。 仕様変更や追加開発が行いやすいということは、我々自身が楽しんで開発を行うことにつながります。 特にこの記事で取り上げた内容は、今すぐにでも実践できる内容ばかりですので、サービスの発展のためにも、我々自身が楽しくコーディングをするためにも、ぜひ積極的に実践しましょう!! Có lẽ bạn sẽ nghĩ việc quá để ý chi tiết về comment và naming thì sẽ được gì, nhưng việc đầu tư công phu như vậy sẽ tạo ra một "service có tính bảo trì cao " để dễ thay đổi specification và phát triển bổ sung. Khi dễ thực hiện thay đổi specification và phát triển bổ sung sẽ dẫn đến việc chúng ta thích thú thực hiện phát triển hơn. Đặc biệt là nội dung được đề cập trong bài viết này đều là nội dung có thể thực hành ngay lập tức, vì vậy chúng ta hãy tích cực thực hành để phát triển service và để chúng ta coding một cách thích thú !! さて、次回は「ループとロジックの単 純化 」についてまとめます!! Và sau đây, lần tiếp theo tôi sẽ tóm tắt về "Đơn giản hóa Loop and Logic" !! ◆ ラク スのオフショア開発に関連する記事も、是非ご参考ください！ tech-blog.rakus.co.jp career-recruit.rakus.co.jp RAKUS Vietnam Co.,Ltd Rakus Việt Nam đang tích cực tuy ển dụng kỹ sư ( Java , PHP ) và member QA. Bạn có muốn cùng tạo ra những sản phẩm SaaS với chất lượng như blog này không? Nếu bạn quan tâm, hãy ứng tuy ển nhé. ラク ス ベトナム では、エンジニア( Java , PHP )やQAメンバの採用を積極的に行っています。 このブログのような品質を意識した自社 SaaS プロダクトを一緒に作りませんか？ ご興味ありましたら、是非応募をお願いします。 www.rakus.com.vn エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com *1 : 原版の翻訳や要約ではありませんのでご注意ください。

Y-Kanoh です。普段は PHP による開発を行っています。 先日、株式会社 ラク スは PHP の繁栄と継続的な開発を支援するため、 The PHP Foundation へ寄付を行いました。 The PHP Foundation について The PHP Foundation は、 PHP の長期的な存続と繁栄を目的とした 非営利団体 です。 PHP のトップコントリビュータである Nikita Popov 氏が活動の中心を PHP から他へ移すことに起因して、 PHP の開発者を金銭的に支援するために、 PHP を扱ういくつかの団体によって設立されました。 blog.jetbrains.com 詳しくは インフィニットループ 様の記事をご覧いただければと思います。 The PHP Foundation がどのような経緯で設立されたのか、 また現在の PHP がどのような状況におかれているかなどがとてもよくわかるかと思います。 www.infiniteloop.co.jp 我々も、改めて確認すると近年の PHP コミュニティにて話題になった新機能のほとんどは Nikita Popov 氏によって提案されていることに気づかされ、 同氏が PHP にもたらしたものの大きさを改めて実感するとともに、 PHP のような OSS がどうやって成り立っているかを再認識することができました。 ラク スにとっての PHP とは PHP が ラク スにもたらしている利益は計り知れません。 我々が提供しているサービスのうち、主に以下のサービスでは PHP が利用されてます。 中には20年近く PHP で開発が続いているサービスもあり、 その間、 PHP 開発者によるセキュリティリスクを減らすための 脆弱性 対応や、 サービス強化に有用な PHP の新機能などを取り入れることで、サービスの開発と運用を続けることができました。 このように、今日までこれらのサービスが継続的に利益を生み出せていることは PHP によるところが大きく、 サービスを開発する我々の業務は PHP の発展と継続に依存している状態です。 ラク スの主な PHP サービス 参考： SaaSプロダクト別の技術スタックを一挙公開！ このような PHP による利益享受の還元を PHP に関するコミュニティへの貢献という形で行うことができないかと考え、 ラク スでは数年前から PHP に関係するコミュニティ/イベントへの参加や協賛を行い始めました。 社内では PHP コミュニティを盛り上げようとの思いから、聴衆としての参加だけでなく、 登壇者としての参加や以下のようなイベント後のアウトプットも積極的に行うことを推奨することにしています。 PHP カンファレンス 2021【参加レポート】 PHPカンファレンス沖縄2021【参加レポート】 オンラインでも大盛況！PHPerKaigi2021参加レポート ラクスのPHPエンジニア12人によるPHPカンファレンス2020参加レポート また、他団体の支援という形だけでなく我々自身の手で PHP を盛り上げるために、 Web× PHP TechCafe というコミュニティの運営も始めました。 Web× PHP TechCafe では、あえて対象者を「初級エンジニア ～ シニアエンジニア」に固定し、 あくまで新しく PHP を扱い始めた開発者が PHPer として成長するための場としてのコミュニティを維持することで、 参加した PHPer がもっと大きなコミュニティに参加できるようになるための足掛かりとなり、 PHP コミュニティ全体の活性化に貢献することを目的としています。 Web× PHP TechCafe が支える領域 connpass.com 私自身も Web× PHP TechCafe の運営をさせていただいている一方で、まだまだ開発者としての経験は浅く、 まさに Web× PHP TechCafe が対象とする「初級エンジニア ～ シニアエンジニア」に当てはまります。 そのため、このコミュニティで自身の知識を増やしつつ、 微力ながら PHP の発展に貢献し、多くの PHPer と楽しく技術の話をしながら仕事がしたいとの思いから、 運営を行わせていただいています。 ラク スが PHP を支援する理由 このように、日ごろから PHP の恩恵に預かり、 その還元を PHP に関するコミュニティに対して行おうとしている我々にとって、 PHP の開発自体に支援を行えることは、願ってもいない機会でした。 我々は今後もこれまでと同じように PHP を扱った開発を行い、サービスを提供して、これによる利益を得ることでしょう。 この利益は Nikita Popov 氏のような OSS 開発者によってもたらされているものであるため、 これを機にできるかぎり PHP 開発者への支援に協力しようとの結論にいたりました。 おわりに PHP の開発に対して金銭的支援を行うことについては、組織ごとに事情があるかと思いますし、 PHP を扱う世界全体のコミュニティにおいても、可能な組織が支援を行い、 新規の開発者は気軽に PHP の導入を決断できる状態が PHP の発展のためだと思います。 また、 PHP への貢献は金銭的支援だけではなく、 バグ報告やドキュメントの翻訳などを含む OSS 活動、 コミュニティでの活動などを通じても行うことができます。 もしよろしければ、我々と一緒に PHP を盛り上げていきましょう!! PHP Foundation - Open Collective エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは、弊社サービスのインフラを運用している id:keijiu (ijikeman)です。 今回は、「 ラク スサービスを管理するAnsibleコードの共通テンプレートを作った話」を記載します。 [対象読者] 対象読者: Ansibleでサーバの管理を行っている人 またはこれから行いたいと考えている人 記事を読んでわかること: Ansibleの実装方法(汎用化) パラメータ(vars)の記載箇所 Ansibleの学習資料の作成 Ansibleコード規約 目次 目次 背景 1. コーディング規約策定 ■ポイント コーディング規約一部例 2. 共通処理の標準化 [カテゴリ] [共通設定]のAnsible実装例 ■ポイント [OS標準機能の設定] ■ポイント [OS標準機能の設定]: ネットワーク設定の一部 ホスト名の設定 ■ポイント 3. 各サーバの構成管理情報(パラメータ)の記載場所の固定化 具体的には？ 各パラメータの記載場所 4. マニュアル、Howto用意 一部Howtoサンプル 5. 自動Lintチェック 6. 取り組みの効果について 背景 私が入社した2018年時点では ラク スのインフラはAnsibleの導入が進んでおらず、何度か勉強会を行った状況でした。 またAnsibleはおろかChefや古くはPuppetなどの構成管理ツールの導入は行われておりませんでした。 そこで前職でChefを使って Linux サーバの提供サービス設計・開発に携わった経験から、 Ansibleの本格導入への白羽の矢が立ったということで、導入までの活動をまとめましたのでその内容を紹介 致します。 1. コーディング規約策定 ラク スでは年々社員数が大幅に増えており、インフラ開発部でも毎年のように新卒や中途社員が増えています。 後から入社しAnsibleに携わる方にもできるだけ統一した書き方でAnsibleコードを書いていただく必要がある為、 Ansibleの基本構文となる YAML のコーディング規約を策定しました。 ■ポイント ルールを単に記載するだけではわかりにくい為、記述例を挙げる 記述例によって文章よりも視覚的に理解が深まる狙いです ルールを以下の2種類に分けて記載 [MUST] ... 必ず必要 [SHOULD] ... より望ましい コーディング規約一部例 #### 拡張子 - [MUST] YAMLファイルは.ymlとする。 #### タブ/スペース/行間 - [MUST] インデントは2スペースとする。 - [MUST] 変数名の前後に空白を入れる。 - [MUST] コロン:のあとには半角スペース１つを必ず入れる。 - [MUST] ハイフン-のあとには半角スペース１つを必ず入れる。 - [MUST] debugを除く各モジュールには必ず、- name:を付けて処理内容にコメントを記述する。 #good --- - name: StdOut 'hoge' shell: {{ BIN_ECHO }} 'hoge' #bad --- -name:test shell:{{BIN_ECHO}} 'hoge' --- ### Command/Shellについて - [SHOULD] 冪等性を保証が困難となる為、できるだけansibleのモジュールで実装し、やむ負えない場合のみ使用する。書き換えはsedを使わずlineinfileモジュールを使うなど - [MUST] バックグランド実行(&)やパイプ、リダイレクト(>, >>)を利用しない場合はcommandを利用する。 #good --- - name: Exec command A command: {{ BIN_ECHO }} 'hoge' - name: Exec command B shell: {{ BIN_ECHO }} 'hoge' > /etc/fuga #bad --- - name: Exec command A shell: {{BIN_ECHO}} 'hoge' --- 2. 共通処理の標準化 次に行ったことが、共通処理の標準化になります。 Linux サーバを構築する場合に必要な処理を、大きく３つのカテゴリにわけて共 通化 しております。 [カテゴリ] [共通設定]: 無駄なサービス停止、パッケージ削除、パッケージ追加、グループ操作、ユーザ操作、 ディレクト リ操作、ファイル操作等 [OS標準機能の設定]: selinux 設定, sysctl設定、ネットワーク設定、 リポジトリ 設定等 [起動するデーモン毎の処理]: テンプレート化して各デーモン用のrole毎に複製して実装 [共通設定]のAnsible実装例 パッケージの一斉インストール処理を共 通化 しています。 ■ポイント with_itemsを定義することで、リストを使ってループ処理しています パラメータの記載箇所を分けることで、適用する影響範囲を限定することができます( 次章 にて説明します) $ roles/common/tasks/main.yml --- - name: Install Packages yum: name: "{{ item.NAME }}" state: 'installed' enablerepo: "{{ item.ENABLEREPO | default() }}" with_items: - "{{ COMMON_INSTALL_PACKAGES | default([]) }}" - "{{ COMMON_HOSTGROUP_INSTALL_PACKAGES | default([]) }}" - "{{ INVENTORY_INSTALL_PACKAGES | default([]) }}" - "{{ INVENTORY_HOSTGROUP_INSTALL_PACKAGES | default([]) }}" - "{{ INVENTORY_HOSTVARS_INSTALL_PACKAGES | default([]) }}" --- [OS標準機能の設定] ■ポイント OSの設定は設定種別が多い為、同じカテゴリの処理をまとめてsetup_*.ymlとしています main.ymlはimport_tasks:を使用し各処理をまとめたsetup_*.ymlを読み込んでいます。こうすることでosロール全体の見通しがよくなります。 $ roles/os/tasks/main.yml --- - name: Setup Network import_tasks: setup_network.yml - name: Setup Sysctl import_tasks: setup_sysctl.yml - name: Setup Selinux import_tasks: setup_selinux.yml [OS標準機能の設定]: ネットワーク設定の一部 ホスト名の設定 ■ポイント NETWORK_SETTINGS.HOSTNAMEを定義することでホスト名の構成情報を管理 ホスト単体の設定なので、host_vars/[HOSTNAME].ymlに記載するとよいでしょう もし適用ステージを分けたい場合は、inventories/[STAGE_NAME]/host_vars/[HOSTNAME].ymlに書くとよいでしょう $ host_vars/[HOSTNAME].yml --- NETWORK_SETTINGS: HOSTNAME: 'hoge.fuga.rakus.co.jp' $ roles/os/tasks/setup_network.yml --- - name: Setup Hostname hostname: name: "{{ NETWORK_SETTINGS.HOSTNAME }}" when: - NETWORK_SETTINGS.HOSTNAME is defined 上記のように、どの種類のサーバでも同じような構築ルールで実装を行うことが多いと思います。 (例えば IPv6 は基本的に無効とか) そういった処理を共通処理化することでAnsibleコードの共有が行えます。 同じ実装でも記載する人によって微妙に変数名等の 命名規則 が違ったりすることで、Ansibleコードの流用ができないなど、保守性が下がることを避けることが出来ます。 3. 各サーバの構成管理情報(パラメータ)の記載場所の固定化 Ansibleでは、構成管理情報を多くの箇所に記載することができます。 これは便利な反面、複数名によるコーディングを行う場合は管理面で煩雑となります。 例えば以下のような場面が考えられます。 複数種別のサーバを1つのAnsibleコードで管理している場合、同じパラメータ名が別々のファイルに記載されることで値が上書きされ、設定が変更されてしまう。 具体的には？ もともとのAnsibleコードに以下内容が記載されていたとします。 $ group_vars/all.yml --- GATEWAY: 192.168.0.254 上記設定があることに気が付かず、誰かが以下のような設定を追記したとすると。。。 $ group_vars/webserver.yml --- GATEWAY: 10.0.0.254 Ansibleの仕様では、ファイル同名のパラメータは優先度によって上書きされます。 この場合group_vars/webserver.ymlの方が優先度が高い為、webserverグループに属しているサーバ群の GATEWAY は書き換えられてしまいます。 この様に1人でAnsibleコードを記載している場合には問題ないかもしれませんが、 複数名ともなると共通認識を合わせコーディングする必要がある為、ルールの策定が必要です。 よって、構成管理情報の記載箇所にも共通ルールを作成しています。 各パラメータの記載場所 group_vars/ └ all.yml ... COMMON_INSTALL_PACKAGES (全ての環境) └ HOSTGROUP名.yml ... COMMON_HOSTGROUP_INSTALL_PACKAGES (特定のグループにのみ) inventories/ └ [STAGE_NAME]/ └ group_vars/ └ all.yml ... INVENTORY_INSTALL_PACKAGES (特定のステージのみ) └ HOSTGROUP名.yml ... INVENTORY_HOSTGROUP_INSTALL_PACKAGES (特定のステージのみ 且つ 特定のグループにのみ) └ host_vars/ └ HOSTNAME.yml ... INVENTORY_HOSTVARS_INSTALL_PACKAGES (特定のステージのみ 且つ 特定のホストにのみ) この様に、記載場所と 命名規則 を予め決めておくことで、互いに影響しあったり値が上書きされることを防いでいます。 以下は、 [共通設定]のAnsible実装例 で紹介したパッケージインストール共通処理でも記載されている部分です。 with_items: - "{{ COMMON_INSTALL_PACKAGES | default([]) }}" - "{{ COMMON_HOSTGROUP_INSTALL_PACKAGES | default([]) }}" - "{{ INVENTORY_INSTALL_PACKAGES | default([]) }}" - "{{ INVENTORY_HOSTGROUP_INSTALL_PACKAGES | default([]) }}" - "{{ INVENTORY_HOSTVARS_INSTALL_PACKAGES | default([]) }}" ですので例えば、 管理しているサーバ全部に対して適用したい -> group_vars/all.ymlにCOMMON_INSTALL_PACKAGES:を定義する 管理しているWebサーバ全部に対して適用したい -> group_vars/webserver.ymlにCOMMON_HOSTGROUP_INSTALL_PACKAGESを定義 本番環境のWEBサーバにだけ適用したい -> inventories/production/group_vars/webserver.ymlにINVENTORY_HOSTGROUP_INSTALL_PACKAGESを定義 といった様に、パラメータを定義していきます。 4. マニュアル、Howto用意 前述した多くの仕様を、新しく参加してきたメンバーに理解してもらう為に勉強会を毎回開くにわけにもいきません。 とはいえ、一定のレベルになるまで学習してもらう必要がありますので、品質のばらつきが出ることを防ぐ為のHowto形式で学べるマニュアルを用意しています。 なお、テキストのみの教育プログラムではなく、理解度向上を狙い、 サンプルとAnsibleの実行画面のキャプチャ画像のアニメーションGifを使ったマニュアルを用意しました。 一部Howtoサンプル # 3. 全てのサーバに対してパッケージの一括インストール ## 3-1. コードの解説 - 必要なパラメータは"NAME"と"ENABLEREPO"が設定できる - ENABLEREPOは省略可能 - NAMEとVALUEを設定する必要がある --- 設定例: $ group_vars/all.yml --- COMMON_INSTALL_PACKAGES: - NAME: 'curl' - NAME: 'libc-client' ENABLEREPO: 'epel' HOWTO01 5. 自動Lintチェック Ansibleのコードはgitlabにて管理しています。 そのため、gitlabにコードをPushする度に、Jenkinsが連動し YAML Lint, Ansible Lintのチェックを自動で行っております。 細かな実装に関しては長くなる為、今回は割愛させていただきます。 機会がありましたら別途記事にしたいと思います。 6. 取り組みの効果について がんばったおかげ？かわかりませんが ラク スが展開するサービスのサーバを管理するAnsibleコードでは私が作ったAnsibleベースコードが使われるようになりました。 どのサービスのAnsibleコードを見ても基本的な構成が同じである為、他のサービスに関わっていた人が別のAnsibleコードを見てもパラメータの記載場所や処理の記載箇所処理内容が同じであったり、追加機能や修正箇所の移植が簡単に行えるなど運用管理が行いやすい状態となりました。 この様にコードの統一性の効果は高く、またそれによって品質の安定化にもつながる為、メリットは非常に高いです。 組織の拡大及び、管理対象範囲が増えていく毎にさらに効果が高まっていくと考えられます。 以上ありがとうございました。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに おはようございます、こんにちは、こんばんは、rks_hrkwと申します。 もう1月も終わりですね。皆様いかがお過ごしでしょうか。 この記事はGo言語といえばの機能の一つである、 ゴールーチン(goroutine) の入門記事となっております。 この記事は Go触ってみたけどまだゴールーチンは勉強してないよ Go触ったことないけどGoでの平行処理に興味があるよ という方向けです。 ※入門記事のため細かい箇所や複雑な箇所は説明を省いている可能性がありますご了承ください。 また、Goの環境構築については以下の記事をご参照ください。 tech-blog.rakus.co.jp 目次 はじめに 目次 並行処理って何？ ゴールーチン ゴールーチンを書いてみよう 1行消す前の処理順 1行消した後の処理順 syncパッケージ sync.WaitGroup さいごに 参考文献 並行処理って何？ 並行処理 とは、ある期間において質の違う複数の処理を同時に行うことです。 ある期間と書いてあるように全く同時にスタートする必要はありません。 ある期間内に複数の処理が行われていれば良いのです。 また、質の違う処理というのもミソです。 並行して〇〇やってるよ、という時に全く同じことをしていることは基本ありませんよね。 混同しやすいのが 並列処理 でこちらは質の同じ処理を同時に行うことを言います。 今回Goで行うのは、記事のタイトルの通り 並行処理 の方です。 Goでは、 ゴールーチン という機能を使用して並行処理を実現します。 ゴールーチン Go言語では、 go文 を使用してゴールーチンを作ることができます。 go文とは、関数呼び出しの前にgoを付けて呼び出すことを言います。 go文はゴルーチンを新たに生成して、並行して処理される新処理の流れをランタイムに追加します。 早速ですが・・・実際にゴールーチンを書いてみましょう。 ※今後出てくるプログラムは、プログラム下に貼ってあるリンクからWeb上で実行できます。 ゴールーチンを書いてみよう まずは、"おかえり"と返してくれるwelcomeBack関数を作成して go を先頭につけて呼び出してみましょう。 package main import ( "fmt" "time" ) func welcomeBack() { fmt.Println( "おかえり" ) } func main() { fmt.Println( "ただいま" ) go welcomeBack() time.Sleep( 50 * time.Millisecond) } Go Playground - The Go Programming Language [実行結果] ただいま おかえり 上手く実行できましたね。 "ただいま"の後に"おかえり"を返してくれる関数を呼んでいるだけなので当然です。 これでしたら、go文を使ってwelcomeBack関数を呼び出さずに普通に呼び出しても実行結果は同じですし、結局並行処理が何なのかよくわかりません。 ただ、main関数の最後に変な1文があります。 これを消してもう一度実行してみましょう。 func main() { fmt.Println( "ただいま" ) go welcomeBack() // time.Sleep(50 * time.Millisecond) } Go Playground - The Go Programming Language [実行結果] ただいま 今度は、"おかえり"を返してくれませんでした。 どこかにバグがあり、"ただいま"と表示した時点でプログラムが終了してしまったのでしょうか？ 結論を言ってしまえば、これはプログラムとして正しい動作をしています。 これが、並行処理を行っている何よりの証拠なのです。 動作を簡単に図にしてみましょう。 Go言語はmainのゴールーチンが終了したタイミングで、プログラム全体を終了させます。 今回のパターンだと、welcomeBack関数はgo文で呼び出されているのでmainとは別のゴールーチンで実行されます。 そのため、mainと新しく作られた"おかえり"を言うゴールーチンが並行に処理されていきます。 結論を言うと、welcomeBack関数側のゴールーチンで"おかえり"を出力する前にmainのゴールーチンが終了したと言うことになります。 先ほども述べたように、mainのゴールーチンが終了した時点でプログラム全体は終わってしまいます。 消した1文は、welcomeBack関数側のゴールーチンが終わるまでを待つための遅延処理だったわけですね。 以下に行った処理をまとめます。 1行消す前の処理順 "ただいま"の出力 別のゴールーチンを作成してwelcomeBack関数を実行 main関数はtime.Sleepで止まる "おかえり"の表示 指定の時間待ったmain関数が終了 プログラム全体も終了 1行消した後の処理順 "ただいま"の出力 別のゴールーチンを作成してwelcomeBack関数を実行 main関数が終了 プログラム全体も終了 syncパッケージ 先程のうまく行っている方のプログラムではtime.sleepを使用して、指定の時間main関数をストップさせていました。 ここで誰しもが一つの疑問を抱きます。 もし、新しく作成したゴールーチンの処理が30分かかったらどうするの？ 当然処理は最後まで行かず、main関数が先に終了します。 だからと言って、ゴールーチンを呼び出すたびに取り敢えず30分止めていたらキリがありません。 処理速度も毎回変わってきますし、そもそも別のゴールーチンを作るたびにその部分の処理の実行時間計測をすることになってしまいます。 それでは、並行処理をする利点が無くなってしまいます。 理想としては、新しく作ったゴールーチンの処理が全て終了するまで待ってくれればそれでいいわけですよね。 そんな理想を叶えてくれる機能を次に紹介します。 sync.WaitGroup WaitGroupは、複数のゴールーチンの完了を待つためのものです。 内部に数値(初期値0)を持っており、メソッドのwait()を呼ぶと、その数値が0になるまで待つことになります。 従って、別のゴールーチンを呼び出す数だけ内部の数値をインクリメントしてあげて、ゴールーチンの処理が終わるたびにデクリメントしてあげれば、wait()を呼んだmainゴールーチンは全ての並行処理が終わるまで待ってくれると言うわけです。 文で読んでも分かりづらいので、実際にコードを書いてみましょう。 package main import ( "fmt" "sync" ) func welcomeBack() { fmt.Println( "おかえり" ) } func main() { fmt.Println( "ただいま" ) var wg sync.WaitGroup // WaitGroupの生成 wg.Add( 1 ) // カウンタをインクリメント go func () { welcomeBack() wg.Done() // カウンタをデクリメント }() wg.Wait() // mainのゴールールは新規のゴールーチンが完了するのを待つ } Go Playground - The Go Programming Language [実行結果] ただいま おかえり 今回は待つ時間を直書きで指定して止めなくても、ちゃんと想定通りにプログラムが動いてくれました。 このように、sync.WaitGroupを使うことでmain以外のゴールーチンが終了するまで待つといったような動きができるようになります。 さらに多くのゴールーチンを管理する場合も同様に、インクリメントとデクリメントを行うだけです。 処理の流れをまとめてみましょう。 "ただいま"の出力 WaitGroup wgの生成 WaitGroup内のカウンタを並行処理したい別のゴールーチンの数だけインクリメントする(今回は1) go文で新しくゴールーチンを作成する 新しく作ったゴールーチン内の処理と並行でmainのゴールーチンの処理も進んでいくがwait()で止まる(カウンタが1のままなので) 新しく作ったゴールーチンで"おかえり"の出力 こちらのゴールーチンで作業が終わったことを伝えるためDone()でカウンタをデクリメントする(1 → 0) カウンタが0になったのでmainのゴールーチンで呼んでいたwait()が終了する(待ちが終了する) mainのゴールーチンが一番最後まで行ったのでプログラム全体も終了 処理としては以上の流れになっています。 Add()した数だけDone()することを忘れないようにしましょう。 Goには他にも様々なゴールーチン間で 同期を取る 方法が存在しますので、気になった方は色々調べてみてください。 さいごに 本記事では、ゴールーチンの基本の基本に焦点を当てて紹介していきました。 Go言語の並行処理、ゴールーチンには欠かせないチャネルの説明などは敢えて省かせていただきました。 理由としては大体どの記事やサイトでもゴールーチンとチャネルがまとめて紹介されており、インプット量が多すぎて初心者に優しくないと思ったのと、別になっている記事があってもそれはそれで選択肢の一つとしていいだろうという考えに至ったためです。 また、タイミングがあればチャネルの説明やもう少し実践的な並行処理を行うような紹介記事が書ければと思います。 全部読んだよという方も一部だけ読んだよという方も、お読みいただきありがとうございました。 これでよりGoに興味を持っていただけたなら幸いです。 よきGoライフを！ 参考文献 Goでの並行処理を徹底解剖！ 並行計算 - Wikipedia The Go Programming Language Specification - The Go Programming Language sync package - sync - Go Packages エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

こんにちは、技術広報の yayawowo です。 Webサイトやブログを作成する際に 「 Twitter や Facebook などのアイコンを表示させたい・・・」 「ここに矢印のアイコンがあれば読みやすいのに・・・」 と思う方がいるのではないのでしょうか？ そんな際にとても便利なのが、 " Font Awesome " です！ 本記事では、Font Awesome の基本知識や使い方だけでなく、カスタマイズ事例も交えてご紹介します。 ※ 利用バージョンについて 　2022年1月現在、Font Awesome 6のベータ版が公開されています。 　Font Awesome 5も継続して利用可能であり、アイコンの種類もほぼ変わらないことから、 　今回はFont Awesome 5を使ってご紹介します。 【 目次 】 Font Awesomeとは？ Font Awesomeの事前準備 アカウント作成 サーバーにアップロード CDNの利用 Font Awesomeの使い方 【応用】カスタマイズ サイズ変更 色変更 アイコンの幅を統一 線で囲む 回転・反転 アニメーション アイコンを重ねる まとめ 　 Font Awesome とは？ Font Awesome とは、 Webサイトにアイコンフォントを簡単に表示させることができる Webサービス です。 提供されているアイコンフォントは商用利用可能となっていますので、個人開発されているWebサイトやブログに導入できます！ また、Font Awesome の アイコンフォントはサイズ・色の変更ができるだけでなく、サイズを大きくしても画質が悪くならないといったメリット があります。 無料版でも利用できるアイコンフォントは多くあるので、まずは本記事を基にお試しいただければと思います。 Font Awesome について詳しく知りたい方は、以下公式ページもご参考ください。 　 👇Font Awesome の公式ページ fontawesome.com Font Awesome の事前準備 Font Awesome を利用するためには、事前準備が必要です。 アカウント作成 Font Awesome公式ページ にアクセスし、アカウントを作成します。 １．「Start for Free」をクリック 「Start for Free」をクリック ２．メールアドレスを入力 メールアドレスを入力 ３． 受信メールを確認し、認証する 入力したアドレス宛に「Confirm Your Font Awesome Account Email Address」という件名でメールが届きますので、認証を行ってください。 　 　 以上で、アカウント作成は完了です。 続いて、アイコンフォントを使うための設定を行います。 2通りの方法がありますので、適切な方をご選択ください！ サーバーにアップロード まずは、サーバーにアップロードする方法です。 サーバー上に画像を置くのと同様、Font Awesome のアイコンフォントをサーバーにアップロードします。 Font Awesome のアイコンフォントをダウンロードする手順は以下の通りです。 １．「icons」→「アイコンフォント」をクリック Font Awesome 公式ページの上部メニューから「icons」をクリック し、無料アカウント範囲で選択できるアイコンフォントを選択します。 （今回は Twitter のアイコンにしました！） 　 「icons」→「アイコンフォント」をクリック ２．「ダウンロードボタン」をクリック 以下赤枠の「ダウンロードボタン」をクリックし、画像をダウンロードします。 「ダウンロードボタン」をクリック ３．サーバーにアップロード 通常の画像をアップロードする時と同様、ダウンロードした画像をサーバーにアップロードしてください。 CDN の利用 続いて、 CDN を利用する方法をご説明します。 CDN とは、Content Delivery Network（コンテンツデリバリーネットワーク）の略でWebコンテンツを効率的に配信できるように工夫されたネットワークのことを言います。 今回は、 CDN を読み込む方法として CSS ・ JavaScript の記載方法を以下にまとめました！ head内に以下を記載することで読み込むことができます。 ◆ CSS < link rel = "stylesheet" href = "https://use.fontawesome.com/releases/v5.15.4/css/all.css" > ◆ JavaScript < script defer src = "https://use.fontawesome.com/releases/v5.15.4/js/all.js" ></ script > ※バージョンや読み込みたいアイコンフォントを限定したい場合などでURLが異なりますので、ご注意ください。 CDN については、 Font Awesome公式ページ からも以下手順で確認することができます。 １．右上にあるアカウントアイコンをクリック ２．「Font Awesome CDN 」をクリック 「Font Awesome CDN 」をクリック ３． CDN をコピー 利用できるアイコンフォントの種類は、Solid、Regular、Brandsがあります。 こちらの画面にて設定を行い、表示された CDN を利用ください。 CDN をコピー Font Awesome の使い方 事前準備が完了しましたので、実際にFont Awesome を使ってアイコンフォントを表示させてみましょう。 今回は、 CDN を利用するパターンを使ってご説明したいと思います。 ◆ HTMLでの使い方 HTMLでは、以下のように記述します。 See the Pen Untitled by yasuko ( @yayafu_ ) on CodePen . <i class="　　　"></i> に使いたいアイコンフォントのコードを設定します。 コードは以下の赤枠部分をクリックすることでコードがコピーされ、取得することができます。 HTMLコードの取得 試しに Twitter ／ Facebook ／Shareのアイコンを3つ表示してみます！ See the Pen Untitled by yasuko ( @yayafu_ ) on CodePen . ◆ CSS での使い方 CSS でFont Awesome を使う際は、 ::before という疑似要素を使います。 以下記載例です。 See the Pen Untitled by yasuko ( @yayafu_ ) on CodePen . CSS の content に、 Unicode （ ユニコード ）を設定します。 以下の赤枠部分をクリックすることで Unicode がコピーされ、取得することができます。 Unicode のコピー なお、 font-family の設定は表示させたいアイコンによって異なりますのでご注意ください！ ブランド系アイコン（ Twitter や Facebook など） "Font Awesome 5 Brands" それ以外のアイコン "Font Awesome 5 Free" 【応用】カスタマイズ 応用編では、アイコンフォントのカスタマイズをご紹介します！ 今回はすぐに実践できる、サイズ/色/アニメーションなどで設定方法をまとめました。 サイズ変更 サイズの変更を行うには、クラスの設定を行います。 クラス、スタイルの一覧を作成しましたので、ご参考ください。 クラス名 スタイル 記述例 表示例 fa-xs 75em <i class="fab fa-twitter fa-xs"></i> fa-sm 875em <i class="fab fa-twitter fa-sm"></i> fa-lg 1.33em <i class="fab fa-twitter fa-lg"></i> fa-2x 2em <i class="fab fa-twitter fa-2x"></i> fa-3x 3em <i class="fab fa-twitter fa-3x"></i> ～　 ～　 ～　 ～　 fa-10x 10em <i class="fab fa-twitter fa-10x"></i> 色変更 style タグにて色の設定を行い、色を変更することもできます。 色 記述例 表示例 青 <i class="fab fa-twitter" style="color:blue;"></i> 赤 <i class="fab fa-twitter" style="color:red;"></i> 黄 <i class="fab fa-twitter" style="color:yellow;"></i> 緑 <i class="fab fa-twitter" style="color:green;"></i> 黒 <i class="fab fa-twitter" style="color:black;"></i> なお、 CSS で色の指定をする際は color:#0000ff; のように、色の指定を行います。 See the Pen Untitled by yasuko ( @yayafu_ ) on CodePen . アイコンの幅を統一 アイコンを複数利用する際、表示してみると幅がずれている！ということもあるかと思います。 そんな時は、クラス fa-fw を追加することで幅を統一することができます。 実装例は以下の通りです。 See the Pen Untitled by yasuko ( @yayafu_ ) on CodePen . アイコンの幅を統一することができました。 線で囲む Font Awesome のアイコンを線で囲んでみます。 囲み線を追加するには、 fa-border クラスを追加することで設定できます。 囲み 記述例 表示例 なし <i class="fas fa-bomb"></i> あり <i class="fas fa-bomb fa-border"></i> 回転・反転 アイコンフォントを回転・反転することもできます！ クラス名 スタイル 記述例 表示例 fa-rotate-90 90°回転 <i class="fas fa-child fa-rotate-90"></i> fa-rotate-180 180°回転 <i class="fas fa-child fa-rotate-180"></i> fa-rotate-270 270°回転 <i class="fas fa-child fa-rotate-270"></i> fa-flip-horizontal 水平に反転 <i class="fas fa-child fa-flip-horizontal"></i> fa-flip-vertical 垂直に反転 <i class="fas fa-child fa-flip-vertical"></i> アニメーション アイコンフォントを自動で回転させてみましょう！ クラス名 スタイル 記述例 表示例 fa-spin 自動で回転 <i class="fas fa-spinner fa-spin"></i> fa-pulse 自動で8ステップ回転 <i class="fas fa-spinner fa-pulse"></i> 無料且つ、自動で回転するのに最適なアイコンフォントは「 Spinners 」というカテゴリーのものです。 以下も是非ご参考ください！ fontawesome.com また、回転以外のアニメーションを利用したい場合は Font Awesome Animation を利用ください。 適用方法は2通りあります。 ① ダウンロードファイルを読み込む < link rel = "stylesheet" href = "font-awesome-animation.min.css" > ② CDN で読み込む < link rel = "stylesheet" href = "https://cdnjs.cloudflare.com/ajax/libs/font-awesome-animation/0.3.0/font-awesome-animation.min.css" > 以下の人の動きは、 <i class="fas fa-running fa-7x faa-wrench animated"></i> にて設定しております。 その他設定は、 Font Awesome Animation をご確認ください！ See the Pen Untitled by yasuko ( @yayafu_ ) on CodePen . （アニメーションつけるの楽しいですね・・・） アイコンを重ねる まずは、重ねたい2つのアイコンをご準備ください。 今回は、 と を重ねてみたいと思います！ １．重ねたいアイコンフォントを準備する < i class = "far fa-heart" ></ i > < i class = "far fa-bell" ></ i > ２．親要素（span要素）に「fa-stack」クラスを追加する < span class = "fa-stack" > < i class = "far fa-heart" ></ i > < i class = "far fa-bell" ></ i > </ span > ３．土台となるアイコンに「fa-stack-2x」、重ねるアイコンに「fa-stack-1x」を追加する < span class = "fa-stack" > < i class = "far fa-heart fa-stack-2x" ></ i > < i class = "far fa-bell fa-stack-1x " ></ i > </ span > ４．表示例は以下の通り ※ 色の表示を反転する方法 「fa-stack-1x」を追加したアイコンに「fa-inverse」と言うクラスを更に追加すると色の表示が反転します！ 【反転前】 < span class = "fa-stack" > < i class = "fas fa-square fa-stack-2x" ></ i > < i class = "far fa-bell fa-stack-1x" ></ i > </ span > 【反転後】 < span class = "fa-stack" > < i class = "fas fa-square fa-stack-2x" ></ i > < i class = "far fa-bell fa-stack-1x fa-inverse" ></ i > </ span > まとめ Font Awesome の使い方はいかがでしたでしょうか？ 今回実際に試してみて 誰でも簡単に 、アイコンフォントを利用できることが分かりました。 また、無料プランの範囲内で「 」など、様々なブランドロゴが利用できるのも大変有難いです…。 2022年1月現在において、Font Awesome 6のベータ版がリリースされておりますので、今度Font Awesome 5とFont Awesome 6の比較をしてみたいと思いました！ fontawesome.com 改めまして本ブログが、Font Awesome を使う方の一助となれば幸いです。 最後までお読みいただきありがとうございました！ 　 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 https://rakus.hubspotpagebuilder.com/visit_engineer/ rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

弊社で毎月開催し、 PHP エンジニアの間でご好評をいただいている PHP エンジニアのための勉強会 『 PHP TechCafe』。2021年9月に開催されたイベントでは「 PHPUnit の始め方」について語り合いました。 社外の 有識者 にも参加頂いてアド バイス を受けながら PHPUnit の使い方やテストコードの書き方を学びました。 今回はその内容についてレポートします。 rakus.connpass.com PHPUnitテストコードの書き方 setUpメソッド アサーション データプロバイダ アノテーション モック 結果の確認方法 テスト実行時に値が変わるケースの実装方法 イベント参加者からの質問コーナー おわりに PHPUnit テストコードの書き方 以下のShowNoteをベースに、「 PHPUnit 導入の目的」 ～ 「入門にあたり押さえておくべきポイント」などに ついてディスカッションしました。 hackmd.io 以前の『 PHP TechCafe』では、 PHPUnit の アサーション について取り上げました。 今回はその続編として、 「 アサーション のみならず、テストコード全般について語っていこう！」という趣旨の企画となっております。 まず初めに、「テスト」とは ・品質を担保するための工程 ・プログラムが期待通りに動いているかの確認 次に、「 ユニットテスト 」とは ・ 単体テスト ・クラスや関数などの単位で動作を確認するテスト ・アプリケーション全体ではなく、アプリケーションを構成する個別のモジュールを対象としたテスト など、「小さい単位で動作を確認していくテスト」となります。 最後に、「 PHPUnit 」とは ・ PHP プログラムとして作成・実行可能な ユニットテスト です。 今回はこの「 PHPUnit 」をテーマに、 「PHPUnit テストコードの書き方【入門】」 の記事に沿って 説明が行われていきました。 この記事では、「 さいころ プログラム」を例に、実際に PHPUnit を使ったテストケースの作成から テストコードの実行までが簡潔にまとめられています。 tech-blog.rakus.co.jp setUpメソッド ・各テストメソッドの実行毎に、毎回実行される ・テスト対象としているクラスの インスタンス 化や、各テストで利用する共通処理の初期化などの目的で利用 <?php declare ( strict_types = 1 ) ; use PHPUnit\Framework\TestCase; final class StackTest extends TestCase { private $ stack ; protected function setUp () : void { $ this -> stack = [] ; } public function testEmpty () : void { $ this -> assertTrue ( empty ( $ this -> stack )) ; } } 上記サンプルコードの場合、 以下のような処理順となります。 [1] setUpメソッドの実行：配列stackの初期化 [2] testEmptyメソッドの実行：配列stackの初期化チェック 上述の「 さいころ プログラム」では、 以下のような実装例で説明が行われました。 <?php class DiceTest extends TestCase { protected Dice $ dice ; protected function setUp () : void { $ this -> dice = new Dice () ; } public function testInstanceOf () { $ this -> assertInstanceOf ( Dice :: class , $ this -> dice ) ; } public function testEmpty (){ $ this -> assertTrue ( empty ( $ this -> dice -> sided )) ; } public function testSided (){ $ this -> dice -> setSided () ; $ this -> assertCount ( 6 , $ this -> dice -> getSided ()) ; $ this -> assertContains ( 1 , $ this -> dice -> getSided ()) ; $ this -> assertContains ( 2 , $ this -> dice -> getSided ()) ; $ this -> assertContains ( 3 , $ this -> dice -> getSided ()) ; $ this -> assertContains ( 4 , $ this -> dice -> getSided ()) ; $ this -> assertContains ( 5 , $ this -> dice -> getSided ()) ; $ this -> assertContains ( 6 , $ this -> dice -> getSided ()) ; return $ this -> dice; } /** * @depends testSided */ public function testRoll ( $ dice ){ $ dice -> roll () ; $ this -> assertTrue ( 1 <= $ dice -> getNumber () && 6 >= $ dice -> getNumber ()) ; } } ここで、参加者からの質問が挙がります。 「（ インスタンス 化は）どのテストでも最初にやらないといけないからここ（setUp）にあるということですよね？」 ここから、「 インスタンス 化はどこで実行するのがベストなのか！？」という議論が始まります！ ・setUpメソッドで インスタンス 化するのか！？ ・各テストメソッドの中で インスタンス 化するのか！？ 議論の結果、 ・場合によって切り分けるのがベスト！ という結論に至りました。以下の切り分けでよいのではないか　という考え方です。 ・「入力によってコンスト ラク タに入れたい」ようなケースであれば各テストメソッドに ・「状態を持たない」ようなケースであればsetUpメソッドに 「setUpの場合はテストケースの実行ごとに毎回呼ばれるので、 インスタンス に状態を持っても次のテストケース には持ち越されない。」 そのため、全部のテストで共 通化 したい処理をsetUpに書くというよりは、 「あくまでコンスト ラク タに何か値を直入したいかどうか決めていいだろう」 というのが 有識者 のコメントでした。 参加者はみんな「なるほどなぁ」と納得の様子でした。 このように、 サンプルコードに対して参加者からのコメントが入り、そこから活発に議論が展開されて 有識者 からの貴重なアド バイス が得られるのも『 PHP TechCafe』の大きな魅力 です！！ ここでの議論はsetUpメソッドだけに留まらず、記事の中では触れられていなかった 「setUpBeforeClass」 にも 話題が及びます。ここでもまた、 ・重たい初期化や、「次のテストに持ち越す必要がある」場合は一度だけ実行される「setUpBeforeClass」 を ・そうでなければ「setUp」をそのまま利用する といったアド バイス をいただきました。 アサーション ・値を比較・検査して想定通りの値になっているかを確認する ・テストコードを記述する上で最も重要 assertSame ：厳密な型チェックも含めた値の比較を行う <?php $ this -> assertSame ( 'hoge' , 'hoge' ) ; // OK $ this -> assertSame ( 'hoge' , 'fuga' ) ; // NG $ this -> assertSame ( 0 , 0 ) ; // OK $ this -> assertSame ( 0 , false ) ; // NG assertTrue ：Trueが返却されることを確認する <?php $ flag = FALSE ; $ this -> assertTrue ( $ flag ) ; $ this -> assertSame ( TRUE , $ flag ) ; 「assertSame」メソッドでも同様のケースが記述できるが、テスト結果がわかりやすくなるというメリットがある <?php # assertTrueのメッセージ Failed asserting that false is true . # assertSameのメッセージ Failed asserting that false is identical to true . phpunit.readthedocs.io ここでは、「 アサーション は種類も多く、奥が深い」というポイントが、話題に挙がりました。 ・テストの目的に応じた適切な アサーション メソッドを選択していく というのが重要なポイントとなります。 とはいえ、これだけ種類も多く、全てを把握することが困難なことから、 「どれを選択すべきかの判断が難しい」との意見が出ました。 ・実行結果も同じになるので、どれを選択すればよいのか分からない ・assertSameで書けないケースはあるのか？ ここでも、 有識者 からは「 基本はassertSameを使うのがよい 」というアド バイス を頂きました。ただし、以下のような場合はassertEqualsを使うのが良いとのことです。 ・assertSameではなくassertEqualsを使うケースの例 　- 連想配列 で、キーと値の関係はチェックしたいが、 キーの順番は気にする必要がない場合 　- インスタンス 化されたオブジェクトのpropertyや値は全て一緒で、ハッシュだけが異なる場合 　など また、 アサーション がエラーになった時にログへ出力される差分情報の分かりやすさも考慮して 「 assertEqualsの引数の順番に気を付ける必要がある 」というアド バイス も頂きました。 　- 第一引数：expected　第二引数：actual となっているため、順番を揃えないと差分が分かりにくくなる 　- あらかじめ 期待値は $expected 、テスト対象から取り出した値は $actual という変数に入れておくと分かり易い データプロバイダ ・テストメソッドへの引数をまとめて記載することができる ・ アノテーション @dataProvider を指定して利用する ・配列や、反復が可能な値を返すようにする必要がある <?php use PHPUnit\Framework\TestCase; class DataTest extends TestCase { /** * @dataProvider additionProvider */ public function testAdd ( $ a , $ b , $ expected ) { $ this -> assertEquals ( $ expected , $ a + $ b ) ; } public function additionProvider () { return [ [ 0 , 0 , 0 ] , [ 0 , 1 , 1 ] , [ 1 , 0 , 1 ] , [ 1 , 1 , 3 ] ] ; } } ?> phpunit.readthedocs.io アノテーション ・各テストメソッドに対するメタ情報 @depends ：テストケースの依存性を表す <?php use PHPUnit\Framework\TestCase; // @depends アノテーションを使った依存性の表現(PHPUnit のドキュメントより転載) class StackTest extends TestCase { public function testEmpty () { $ stack = [] ; $ this -> assertEmpty ( $ stack ) ; return $ stack ; } /** * @depends testEmpty */ public function testPush ( array $ stack ) { array_push ( $ stack , 'foo' ) ; $ this -> assertSame ( 'foo' , $ stack [ count ( $ stack ) -1 ]) ; $ this -> assertNotEmpty ( $ stack ) ; return $ stack ; } /** * @depends testPush */ public function testPop ( array $ stack ) { $ this -> assertSame ( 'foo' , array_pop ( $ stack )) ; $ this -> assertEmpty ( $ stack ) ; } } 上記サンプルコードの場合、 以下のように実行が行われます。 [1] testEmptyの実行 [2] testEmptyの実行結果を引数に、testPushを実行 [3] testPushの実行結果を引数に、testPopを実行 「テストの実行結果をもとに、他のテストを実行したい」ようなケースで利用します。 phpunit.readthedocs.io ここでは、 「よく使う アノテーション はあるか？」 という質問が挙がりました。 いくつか話題に挙がったものをご紹介します。 @runInSeparateProcess ：テストを別プロセスで実行する <?php use PHPUnit\Framework\TestCase; class MyTest extends TestCase { /** * @runInSeparateProcess */ public function testInSeparateProcess () { // ... } } テストケースの中で グローバルな情報を書き換えても別のテストに影響を及ぼさないようにする ことが可能。 前のテストが後続のテストに悪影響を与え、期待した結果にならないようなケースを回避できる。 @test ：テストメソッド先頭の「test」をつけずに、テストメソッドとして実行可能 <?php /** * @test */ public function initialBalanceShouldBe0 () { $ this -> assertSame ( 0 , $ this -> ba -> getBalance ()) ; } テストメソッドに日本語を利用したい場合など。 参加者の中では @test を使って日本語のメソッド名にする以外に、「test_日本語」 のように先頭の「test」を残して@testを使わずに日本語のメソッド名を使っている人もいるようでした。 モック ・テスト時に実際のオブジェクトの動作をシミュレートしてくれる模造品オブジェクト ・依存するオブジェクトが何らかの理由でテスト時に利用できないときなどに使用 phpunit.readthedocs.io 結果の確認方法 すべてOKの場合 $ vendor/bin/phpunit Test.php PHPUnit 7 . 4 . 5 by Sebastian Bergmann and contributors. .... 4 / 4 ( 100 % ) Time: 87 ms, Memory: 4 . 00 MB OK ( 4 tests, 10 assertions ) ４つのテスト、その中に10個の アサーション があり、それらすべてがOK NGがある場合 $ vendor/bin/phpunit Test.php PHPUnit 7 . 4 . 5 by Sebastian Bergmann and contributors. ...F 4 / 4 ( 100 % ) Time: 78 ms, Memory: 4 . 00 MB There was 1 failure: 1 ) Test::testRoll Failed asserting that false is true . /var/www/html/Test.php:40 FAILURES! Tests: 4 , Assertions: 10 , Failures: 1 . ４つのテスト、その中に10個の アサーション があり、うち1つがNG テスト実行時に値が変わるケースの実装方法 最後に、「テスト実行時に値が変わるケースはどのようにテストを書くか？」という話題について議論しました。 まずは、 「現在時刻などの時刻を扱う場合」 についてです。 ここで挙がった案をご紹介いたします。 ・外部から値を注入できるようにしておき、モッククラスで固定の値を返すようにしてパターン網羅する ・標準関数を強制的に上書きすることで、任意の値を返すようにする ・「 php -timecop」拡張ライブラリを使い、基準時刻を設定することでdate関数が任意の結果となるようにする ・まだDraftの段階ではあるが、「PSR-20のClock インターフェイス 」を実装した時計オブジェクトを用意することで任意の時刻を返す方法もある 上記のように、なかなか個人だけでは思いつかないような案も含めて、様々な実現方法が見つかりました。 github.com scrapbox.io 次に、 「ランダム値の場合」 です。 ここでも様々な意見が飛び交いましたが、ピックアップしてご紹介します。 ・「srand」を使用し、固定のシード値を指定することで同じ結果を得る ・ランダマイザのようなオブジェクトを外出しにし、モックに差し替える ・「srand」を使用すると全体に影響するため、他のテストに依存させたくない時は前述の @runInSeparateProcess を使用する このように、 具体的な実装案を学ぶことができるのも 『 PHP TechCafe』の魅力 です！！ 以上が、今回のイベントテーマに沿った大まかな流れとなります。 イベント参加者からの質問コーナー イベントの途中で頂いた参加者の皆様からのコメントについて、議論する時間をご用意しています。 ここでいくつかピックアップしてご紹介いたします。 ・テスト毎にDBの中身はクリアしてテストデータを投入するか？ ・最初からテストデータが入ったDBを使うか？ これについては、 テストケース毎にリセットするのがよい という結論に至りました。 具体的には ・「setUpBeforeClass」でTRUNCATEする ・重たい処理でなければ「setUp」で毎回削除する その理由については以下のような意見がありました。 DBに依存する処理をモック化しておけば局所的にテストができるので毎回作成しても問題なさそう 局所化せずにやっているとテストがむちゃくちゃ重くなってしまう 毎回リセットしないと順序に依存したテストを作り込むことになる ・PHPUnit以外を検討したことはあるか？ これについては、 スタンダードであり使い慣れた PHPUnit を使いがち という意見が多数でした。 しかし、 PHPSpecにはおもしろい機能があり、使いこなせると便利そう といった意見もありました。 BDD（ビヘイビア駆動開発）の機能が備わっているとのことです。 ja.wikipedia.org 「先にSpecを書いてSpecのための空の実装を自動生成して、それに合うようにテスト実行して、、のように実装とテストを交互に埋めていくようなことが出来る」とのことです。 github.com ただし、「便利に使えたら面白いんですけど、便利に使いこなせないので PHPUnit 使ってます。」 「情報量の多さが違う」ということで、やはり PHPUnit がスタンダードという意見に異論は無いようでした。 『 PHP TechCafe』では、イベント参加時の「テーマに関するアンケート」や、 イベント中にも、随時チャットコメントを募集しております。 おわりに 『 PHP TechCafe』では今後も PHP に関する様々なテーマのイベントを企画していきます。 是非、皆さまのご参加をお待ちしております！ connpass.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

こんにちは、技術広報の yayawowo です。 当社 ラク スの開発本部はエンジニアとデザイナーのメンバーで構成されおり SaaS プロダクトデザインを手掛けるUI開発課 コーポレートデザインを手掛けるクリエイティブ課 という組織にそれぞれデザイナーが所属しております。 今回は全デザイナーメンバーたちに・・・ デザイナー歴、応募のきっかけ、入社の決め手 だけでなく、 業務以外での 趣味、休日の過ごし方、情報収集手段 についても教えていただきました！ 株式会社 ラク スのデザイナーたちはどんな人がいるのか、ご参考いただけますと幸いです。 ◆ 関連ブログ UI/UXデザイナー語る、デザイン Tips【20選】 当社にて定期的に開催している、デザイナーによるデザイナーの為のデザインLT大会をまとめた記事となります。 当社メンバーも登壇しておりますので、是非ご一読ください！ tech-blog.rakus.co.jp ラクスのデザイナーたちはどんな人？ 男女比は？ デザイナー歴は何年？ ラクスの入社前の経歴は？ ラクスへの応募きっかけは？ ラクス入社の決め手は？ 趣味/特技は何ですか？ 休日の過ごし方は？ デザイン知識の情報収集手段は？ 一緒に働きませんか？ 関連ブログ/イベントのご案内 UI/UXデザイナーLT会 ラクスの技術/デザインスタック 採用イベント 終わりに ラク スのデザイナーたちはどんな人？ 男女比は？ 図１：男女比 ※デザイナー24名にアンケートを実施 男女比は、女54%：男46%とで約半々となっております。 男女関係なく、多くのデザイナーが活躍されているのがお分かりいただけるかと思います！ デザイナー歴は何年？ 図２：デザイナー歴 ※デザイナー24名にアンケートを実施 なんと5年未満のデザイナーが約半分！ その次に15年以上が30%となっております。 5年未満のデザイナーがどのような経緯で ラク スに入ってきたのか、この後の質問をご確認ください！ ラク スの入社前の経歴は？ 図３：入社前の経歴 ※デザイナー24名にアンケートを実施 デザイン関連の仕事をされていた方が多い中、エンジニア・営業経験を経て ラク スのデザイナーとして活躍されている方もいるようです！ ラク スへの応募きっかけは？ ◆事業内容 ・ SaaS のBtoB製品デザインを長期で担当したいと考えたためです。 ・ SaaS 業界に興味がありました。 ・ マーケティング デザインのノウハウが得られそうと思ったためです。 などなど 　 ◆研修・制度 ・ インターン （新卒採用） ・勤務条件で選ばせていただきました。 ・もう一段上がって、全体管理や組織管理をしたいと思ったためです。 ・最初は システムエンジニア の経験から興味がある プログラマー も範囲に入れていました。たまたまインターネットで出てきて調べていくうち、未経験ながらも教育などサポート環境があったことがきっかけです。 などなど 　 ◆スカウト・紹介 ・転職エージェント ・社員 リファラ ル ・ wantedly のスカウト などなど ※デザイナー24名にアンケートを実施し、自由記入を一部抜粋 事業内容への魅力を感じ、応募された方が多くいました。 デザイナー部門は、 ラク スグループ内で横断的に業務を対応しているため多くのプロダクトに携われる環境があるため常に新鮮な気持ちで業務に邁進していただけます！ 　 もし応募に悩んでいるという方は、手始めにカジュアル面談でデザイナーと話をしてみませんか？ rakus.hubspotpagebuilder.com ラク ス入社の決め手は？ ◆ 事業内容 ・組織構築の自由度があり、またビジネスモデルが今～未来に必須な内容だと感じたためです。 ・ マーケティング からプロダクトまで一貫してデザイナーとして関われる業務範囲の広さへの魅力です。 ・ マーケティング から受けるイメージの良さがありました。 ・いろんな種類/フェーズの商材があって面白そうだと思ったから。 ・待遇面、事業面やチームとして伸びしろがあると思ったからです。 ・BtoB SaaS 企業の中でもより多くのユーザーに自分の関わったプロダクトや機能改善を提供できるからです。 などなど 　 ◆ 環境・組織文化 ・待遇（残業が少ない、休みが取れる等）と社風（面接官の雰囲気等）。 ・ライフワークとのバランスや福利厚生の充実さだけでなく、面接時にお話した一緒に働く方々の印象が決めてとなりました。 ・ ラク スの見学や社員との会話で、アットホームな雰囲気や仕事環境の配慮などを確認できて、安心して働きやすく、仲間たちとともに自分を成長できる場所だなと思い、入社を決めました。 ・成長企業、面接での会話、経験を活かして自己研鑽しながら働いていけそうと思ったためです。 ・デザインとコーディングを両方出来る部分と、働きやすそうな環境と感じた部分です。 　 ・会社の雰囲気が真面目な感じで、面接の雰囲気も良かったから。 などなど 　 ◆ その他 ・デザイナーのnoteなどの記事 などなど ※デザイナー24名にアンケートを実施し、自由記入を一部抜粋 入社するまでにどんな方と一緒に働くのか不安になる方は多いかと思います。 ラク スでは社内の雰囲気を知ってもらうために、社内見学の機会も提供させていただいておりますので是非ご活用ください！ 趣味/特技は何ですか？ ◆ アウトドア派 1位▶キャンプ、サウナ、サッカー観戦、散歩 2位▶旅行、バイク、ゴルフ、 スノーボード などなど 　 ◆ インドア派 1位▶イラスト制作、音楽(ピアノ/ギター) 2位▶映画鑑賞 3位▶料理 4位▶ゲーム、ペット、動画制作、漫画、読書　などなど などなど ※デザイナー24名にアンケートを実施し、自由記入を一部抜粋 今回はアウトドア派とインドア派で集計をとらせていただきましたが、 デザイナーの皆さんはとても多趣味ということが分かりました！ 中には燻製づくりを趣味にしているという方もいたくらいですよ。 クリエイティブな発想は、このような多様な趣味からうまれているのかもしれませんね！ 休日の過ごし方は？ 1位▶家族と過ごす 2位▶学習（動画制作/ハンドレタリング/デザイン情報集め） 3位▶ペットと過ごす、映画/テレビ鑑賞 4位▶散歩、スポーツ、ゲーム などなど ※デザイナー24名にアンケートを実施し、自由記入を一部抜粋 24名中10名が休日はご家族と過ごされていることが分かりました！ ワークライフバランス も取りながらデザイナーとしてのスキルを磨ける、そのような背景を改めて理解することができました。 デザイン知識の情報収集手段は？ 図４：情報収集手段 内容 投票数 Web記事（note、 はてなブログ など） 10票 SNS （ Twitter 、 Instagram など）　 7票 会社・仕事 3票 書籍 2票 全部 2票 ※デザイナー24名にアンケートを実施 デザイナーたちが日々の生活の中でアンテナを高くしてみているのが、Web記事、次いで SNS という結果でした。 noteを見ている方のおすすめは、以下「 #デザイン記事まとめ 」とのことです！ また、 ラク スでもデザイナーたちがnoteにて情報発信をしております。 是非宜しければ覗いてみください！ ◆ ラク スデザイナーnote ・ Rakus Designers note 　☞　 プロダクトデザイナー のnote ・ Rakus Service Designer note 　☞　楽楽精算とMailDealer担当サービスデザイナーのnote 一緒に働きませんか？ ラク スでは、デザイナーを積極的に募集しております！ 本内容にてご紹介させていただいたデザイナーたちの雰囲気を知っていただき、ご興味もっていただいた方は是非以下より応募ください。 職種 求人内容 UIUXデザイナー／マネージャー hrmos.co UIデザイナー hrmos.co Webデザイナー hrmos.co ※2022/1/21時点での情報です。 是非一緒に良いものを作り上げていきましょう！ 関連ブログ/イベントのご案内 UI/UXデザイナーLT会 次回2/22(火)に「UI/UXデザイナーLT会 - vol.6」が開催されます！ 登壇/視聴枠でのお申込み、お待ちしております！！ rakus.connpass.com ラク スの技術/デザインスタック デザインの技術スタックについて以下記事にまとめております。 是非、ご参考ください！ tech-blog.rakus.co.jp 採用イベント 2/1(火)19:00～UIデザイナーの仕事紹介を行います。 少人数制の座談会となりますので、是非宜しければこちらもご参加ください。 rakus.connpass.com ※2022/1/21時点での情報です。 終わりに デザイナーインタビューはいかがでしたでしょうか？ 私の業務の一環として多くのデザイナーたちとお話をさせていただいておりますが、デザインに対しての興味関心が高いだけでなく、とても人柄が良い人たちが多い印象です！ また、組織としてもすごくアットホーム！ 次回はデザイナーたちに聞いたオススメ書籍や、ニュースなどもご紹介しようと思っております。 公開までしばらくお待ちください！ 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

■ 目次 ドメイン駆動設計のプラクティスでカバーできること、できないこと 前提知識： DDDの目的 スムーズに進んだこと 苦戦したこと・していること プロダクトを活用していただくための取り組み まとめ 巨大レガシーシステムの戦略評価とリファクタリングにおけるDDDの活用事例 DDDの導入理由① コアドメインを定めて開発の費用対効果を高めるため 取り組んだこと 苦戦したこと DDDの導入理由② レガシーシステムの技術的負債解消 苦戦したこと 苦労していること 基幹システムの変更を楽で安全にする 参画していた案件 参画案件のテーマ 現場でやっていること 結果 感想 こんにちは 配配メール開発課所属 Jazumaです。 1/17 (月)にオンラインで ドメイン 駆動設計導入事例の勉強会がオンラインで開催されました。 modeling-how-to-learn.connpass.com 平日の夜にも関わらず500人以上の方が参加しており、設計に関心を持っているエンジニアが多いことを実感しました。 今回の勉強会では以下3名の方がが登壇されました。 松岡@ログラス/DDD,アジャイル (@little_hand_s) | Twitter さん ミノ駆動 (@MinoDriven) | Twitter さん 増田 亨． (@masuda220) | Twitter さん ドメイン 駆動設計というとそのメリットや成功例が取り上げられがちですが、今回は ドメイン 駆動設計で苦労したことや解決できなかったことも紹介されました。 ドメイン 駆動設計のプ ラク ティスでカバーできること、できないこと 松岡幸一郎さんの発表です。DDDの導入にあたって上手くいったこと/ いかなかったことが紹介されました。 前提知識： DDDの目的 ソフトウェアの機能性を高める ⇒ 機能性 = 顧客の役に立つこと ソフトウェアの保守性を高める ⇒ 保守性 = 長期間にわたり機能拡張が容易であること。 DDDの目的： 顧客の役に立つソフトウェアを頻繁な更新に耐えられるものにする スムーズに進んだこと 松岡さん主導の モデリング モデル図をもとにしたコーディング 新規開発時、モデル図を見ながら開発ができたので役に立った コーディング標準 普及 標準的なコード手本があると実装の横展開がしやすかった 規約ではなく「こんな風にするとやりやすい」、というようなお手本的なもの テスト実装 テストのメリットを実感してもらうと浸透しやすかった テストコードの量が増えた時、「 モデリング したいので一緒にモブ作業してくれませんか？」と言われたときに変化を実感できたようです。 苦戦したこと・していること 「何を作るか」から「どうすれば活用してもらえるか」への踏み込み 作ったものをより顧客の役に立つものにすることが難しい お客様の解像度を上げる PMやCSと協力して ヒアリ ングと仮説検証を繰り返す DDDを導入した後、プロダクトの機能性を高めることに苦労したと仰っていました。 プロダクトを活用していただくための取り組み 新機能を先行体験する顧客を選定してPdMが ヒアリ ング、フィードバックを受ける 既存機能についてお客様の声を聴く機会を設ける。そこからスプリントの案件として計上する まとめ DDDは保守性・機能性改善に効果が大きい 社内の人間だけでは機能性を上げきれない とにかくお客様の声を聴いて業務を理解することが重要 巨大 レガシーシステム の戦略評価と リファクタリング におけるDDDの活用事例 ミノ駆動さんによる発表です。DDDを用いて レガシーシステム の品質向上に取り組んだというお話です。 DDDの導入理由① コア ドメイン を定めて開発の費用対効果を高めるため 限られた開発リソースを有効に利用するためにシステムのコア ドメイン が何なのか見定める必要があった 「問題領域」(実現したいこと)と「解決領域」(実現手段)と整理することから始めた ※ コア ドメイン ： システムの競争優位性を発揮し、最も付加価値を高めるべき領域 取り組んだこと ドメイン エキスパートと思われる関係者に ヒアリ ング 例： 解決したい問題等... ⇒ 事業領域を明確化し、コア ドメイン を特定できた 苦戦したこと 必要な情報量が多い 入社したて＆リモートワークで ドメイン エキスパートが分からず、チャットを巡回した時期もあった コア ドメイン の知識を収集・整理するには人手がもっと欲しかった DDDの導入理由② レガシーシステム の技術的負債解消 巨大な Rails アプリの負債で変更容易性が落ちる 負債を産みにくいような設計にしたい という目的のもと設計改善が行われました。 しかし、開発組織全体に意図や目的が共有されていなければ混乱を招くという懸念があり 実際に最初のうちは他のメンバーが Rails の手法に乗っ取って開発して負債が解消されませんでした。 苦戦したこと 現場の課題とDDDという技術をどう結び付けて説明するか DDD: コア ドメイン の価値を高めて長期的に成長させるための設計思想 現場の課題： ActiveRecord をRepositoryに隔離して ドメイン の知識を独立させる 結果： 技術負債に困っているメンバーが多かったので「FatModelを意味の違う概念単位で分割する」という考えに賛成するメンバーは多く、技術負債は次第に低減 苦労していること 設計が Rails の仕様に引っ張られて品質が落ちる ActiveRecord を中心に機能が集約されているため、 Rails の実装に設計が引っ張られる Ruby という言語の特性 型のサポートがないので依存関係を正確に追跡できない。 リファクタリング 効率がどうしても落ちる。 基幹システムの変更を楽で安全にする 増田亨さんによる発表です。松岡さんとミノ駆動さんは比較的若い会社でのケースでしたが、 増田さんは伝統的な大手企業におけるDDDの実践例について発表されました。 参画していた案件 損保会社のシステム 巨大 ECサイト の基幹システム 参画案件のテーマ ビジネスの要求にこたえるシステム変更スピード ソフトウェア開発コストの削減 修正コストの削減 現場でやっていること whyの合意形成 悪い設計で失っているものの数値化・ 言語化 悪い設計で得られるものの 言語化 ・数値化 howについての認識合わせ ビジネスルール(計算判断ロジック)中心の設計 事実の記録中心のテーブル設計 一覧網羅ではなく濃淡づけとカテゴライズ(要点を見定める) 結果 DDDの導入によりシステム仕様の管理が膨大な Excel シートから業務マニュアル + ソースコード に変化しました。 また、 ビジネスロジック が ドメイン オブジェクトに集約されたことで機能改修に伴うコードの変更量が減少しました。 感想 DDDを頭ごなしに導入するのではなく、小規模なところから始めてチームのメンバーにメリットを実感してもらうのが大切だと思いました。 DDDはソフトウェアの価値を高める手段であり、最も重要なのはシステムのコア ドメイン を関係者とのやりとりから見定めることだということが実際の導入事例を通して理解できました。 エンジニアだからと言ってシステムが扱う事業に無関心ではいられないと再認識しました。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめまして。rks_mnkiです。 ラク スでひっそりとインフラエンジニアやってます。 特技は、蚊に刺されないことです。 さて今回は、 「 Apache アクセスログ に関するログ解析手法」 について、実際に検証を行った一例も踏まえながらご紹介したいと思います。 目次： １．Apacheのアクセスログとは ２．「ログ解析」の必要性 ３．確認したい具体的な情報 ４．利用するツールの紹介 ElasticSearch Logstash Kibana ５．実際に導入してみる WEBサーバの準備 dockerコンテナによるログ解析環境を構築 各種設定 データ投入 ６．結果と考察 ７．まとめ 備考 参考文献 １． Apache の アクセスログ とは 私たちがホームページやブログサイト（当ブログもそうですけど）にアクセスした際に、コンテンツデータをブラウザに返してくれるのが、「WEBサーバソフトウェア」となります。 このソフトウェアの1つとして、メジャーに利用されているのが" Apache （正式名称： Apache HTTP Server）"です。 オープンソース ソフトウェアのため、誰でも無料で利用できる点が大きな特徴となります。 そして、このWEBサーバ( Apache )にアクセスした際の情報が記録されるのが、「 アクセスログ 」です。 ▼サンプル # tail /var/log/httpd/access_log xxx.xxx.xxx.xxx - - [20/Dec/2021:09:41:38 +0900] "GET / HTTP/1.1" 200 108 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36" こちらは、とあるWEBサイトのTOPページにアクセスした際の アクセスログ の一部抜粋となります。 ぱっと見では、なんなのかよく分かりませんが、予め定義されたフォーマットに沿って情報が表示されています。 標準で用意されているログフォーマットもありますが、管理者が任意にカスタマイズすることもできます。 ２．「ログ解析」の必要性 ITインフラの運用業務においては、この アクセスログ を確認するケースが多々あります。 例えば、稼働中のサーバが急激にパフォーマンス高負荷になった場合、 WEBアクセスが急増していないか？ どのURLにアクセスしているケースが多いか？ 不正なアクセスは発生していないか？ などの状況を アクセスログ を元に確認し、原因調査を進める事になります。 しかし、ログを眺めているだけでは、「アクセス急増している時間帯はあるか」「海外からの 不正アクセス はあるか」といった情報の判別は瞬時にできません。 そのため、特定情報を元に手動で集計するなど工夫しながら調査を行う事になりますが、これがなかなかの手間になります。 アクセス頻度が多く高負荷になりやすい環境であれば、調査頻度も多くなるのでなおさら面倒なことに。。 もちろん、ある程度の知識や慣れも必要となりますので、 アクセスログ のデータを自動集計して「パッと見て」分かるように可視化できれば、誰でも簡単に確認することができるかなぁ？と考え、とりあえず検証してみる事にしました。 ３．確認したい具体的な情報 一般的に「 アクセスログ 解析」とは、ユーザがいつ・どこからアクセスしたのか・どのページに頻繁にアクセスしているかなど、WEBサイトの利用状況を把握するために、データを集計して分析することを指します。主に、 マーケティング で利用するイメージです。 ここでは、インフラ視点に立って以下の要素を実現するために、「ログ解析」の手法を取り入れて検証していきます。 WEBアクセス数の推移 アクセス元のロケーション情報 どのページに頻繁にアクセスされているか 上記の情報をグラフィカルに表示 ４．利用するツールの紹介 前述の要件を満たすため、以下のツールを利用します。（よくある組み合わせです） いずれもElastic社が開発・提供しているソリューションで無償で利用できますが、有償オプションも存在します。 ElasticSearch あらゆるデータタイプに対応した検索/分析エンジン。 Logstash サーバサイドデータ処理パイプライン。 あらゆるデータを構造化・整形して、指定された場所にデータ転送。 Kibana ElasticSearchデータを可視化することができるユーザ インターフェイス 。 ▼利用イメージとしては、下記図のとおり。 ELK利用イメージ図 ５．実際に導入してみる WEBサーバの準備 まず、アクセス先となるWEBサーバを AWS 環境上に1台構築します。 テスト環境のため、このWEBサーバに対するHTTP通信については制限を設けず公開した状態とします。 EC2 インスタンス すると、デフォルトのWEBページを公開しているだけにも関わらず、どこからともなくアクセスが来ている事が分かります。 # tail /var/log/httpd/access_log 135.125.246.110 - - [21/Dec/2021:09:18:02 +0900] "POST / HTTP/1.1" 200 108 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36" 3.239.174.91 - - [21/Dec/2021:10:24:27 +0900] "POST / HTTP/1.1" 200 108 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36" 209.17.96.250 - - [21/Dec/2021:10:31:58 +0900] "\x16\x03\x01" 400 226 "-" "-" 130.211.54.158 - - [21/Dec/2021:11:03:24 +0900] "GET / HTTP/1.1" 200 108 "-" "python-requests/2.26.0" このアクセスは、主に海外などからボットを使った 不正アクセス と思われます。 dockerコンテナによるログ解析環境を構築 それでは、いよいよこの アクセスログ を解析するための環境を構築します。 今回は Github で公開されている、ElasticSearch＋Logstash＋KibanaがパッケージングされたDockerイメージを使います。 （利用バージョンは、7.15.2） また、docoker-composeにより各サービスのコンテナを立ち上げてログ解析環境として稼働させます。 docoker-compose構成イメージ ※KibanaへのアクセスをNginxでリバースプロキシするために、Nginxのdockerイメージも利用。特に必須ではありません。 各種設定 Dockerに関する説明は、今回は省略致します。 ここでは、主にLogstashとKibanaに関する設定内容についてご紹介致します。 Logstashの設定ファイルは、インプット/フィルター/アウトプットで構成されます。 インプット input { file { path => "/var/log/httpd/access_log-*" sincedb_path => "/dev/null" type => "apache" start_position => "beginning" } } 読み取り対象となるファイルのpathを指定しています。 その他パラメータとして、start_position => "beginning"ではLogstashを起動した際に、ログファイルを先頭から読み取るように指定しています。 フィルター filter { grok { match => { "message" => "%{COMBINEDAPACHELOG}" } break_on_match => false tag_on_failure => ["_message_parse_failure"] } date { match => ["timestamp", "dd/MMM/YYYY:HH:mm:ss Z"] locale => en } geoip { source => ["clientip"] } } grokセクションで Apache の アクセスログ を各フィールドに分割します。今回対象のログは、combinedフォーマットとなっているため、予め用意されている"%{COMBINEDAPACHELOG}"にmatchさせています。 dateセクションでは、 アクセスログ が記録された日時をtimestampとして書き換えます。（デフォルトでLogstashで読み込んだ日時がtimestampとして記録されるため） また、どこの国からのアクセスか判別させるために、geoipセクションでは「アクセス元 IPアドレス 」から国名や緯度経度などの情報を付与します。 これらのフィルタ処理を施すことで、以下のようなフィールド構造に変換されます。 { "type": "apache", "clientip": "212.107.231.174", "ident": "-", "message": "212.107.231.174 - - [01/Dec/2021:16:23:41 +0900] \"GET / HTTP/1.1\" 200 108 \"-\" \"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36\"", "host": "1c3067174f38", "geoip": { "longitude": 84.8328, "postal_code": "636019", "continent_code": "EU", "country_code2": "RU", "latitude": 56.6133, "location": { "lat": 56.6133, "lon": 84.8328 }, "country_code3": "RU", "region_name": "Tomsk Oblast", "timezone": "Asia/Tomsk", "country_name": "Russia", "ip": "212.107.231.174", "city_name": "Seversk", "region_code": "TOM" }, "@timestamp": "2021-12-01T07:23:41.000Z", "timestamp": "01/Dec/2021:16:23:41 +0900", "request": "/", "bytes": "108", "referrer": "\"-\"", "auth": "-", "agent": "\"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36\"", "@version": "1", "httpversion": "1.1", "response": "200", "path": "/var/log/httpd/access_log", "verb": "GET" } アウトプット ElasticSearchに対してデータを投入する設定を記述。 output { elasticsearch { hosts => "elasticsearch" index => "test-apache-%{+YYYY.MM.dd}" user => "elastic" password => "*****" } } データ投入 一通りの設定が完了したのち、dockerコンテナを立ち上げて各種サービスを起動させます。 そして、テスト用WEBサーバから アクセスログ を取得し、Logstashに投入します。（所定の ディレクト リに配置） すると、ElasticSearch上で以下のようにインデックスが作成されている事が確認できます。 ▼インデックス確認結果の抜粋 # curl -u elastic:*** http://127.0.0.1:9200/_cat/indices?v | grep "test-apache" yellow open test-apache-2021.12.19 OfhZz8QCQlWYsM5_huC51Q 1 1 124 0 154.4kb 154.4kb yellow open test-apache-2021.12.13 eNHowDZkRx-Xv_Bv1_Hxxg 1 1 204 0 167.2kb 167.2kb yellow open test-apache-2021.12.14 13nhNv_lRa6_81j4EvuLlg 1 1 148 0 135.9kb 135.9kb それでは、いよいよKibanaにログインします。 [Discover]の画面を開くと、以下のように各フィールドに分離されたパラメータがタグ付きで格納されている事が分かります。 格納データの中身 このデータをもとに、必要となるグラフやマップ設定を行い、 ダッシュ ボード画面を整理していきます。 [Visualize Library]の画面で『Create visualization』のボタンを押すと、以下のようにグラフを生成することができます。様々な種類のグラフから選択することができるので、自分の表現したい形に合わせてセットアップします。 Kibanaの設定画面一例 ６．結果と考察 まず、アクセス元の情報を国別にまとめたMapが以下となります。 色のついた国の枠内に表示されている数字がアクセス回数となり、赤色に塗られている国がアクセス数が多いことを示します。 ロケーションMap情報 次に、アクセス数の推移やリク エス ト先URL情報などをまとめたグラフです。 その他、グラフ情報 アクセス数の増加タイミングや、アクセス頻度が多いリク エス トURL、または送信元 IPアドレス の情報を一目見て確認することができます。 さらには、 ダッシュ ボード画面に可視化された情報を集約することで、より見やすくなりました。 こうやって 視覚的に判別しやすい可視化された情報 として出力することで、当初思い描いていた形を実現できたと思います。 また、同じフォーマットの アクセスログ であれば、今回構築したログ解析環境に投入していくだけで、同様の解析結果を得ることができるため、運用オペレーションコストの削減にも繋がると考えます。 なお、今回解析した情報を詳しく見てみると、テスト用に構築したWEBサーバを約 20日 間放置しているだけで、回数は少ないものの世界中からアクセスされている事が分かります。恐らくは（というかほぼ確実に）、悪意を持った 不正アクセス による影響と考えられますので、セキュリティ対策の必要性を改めて実感しました。 ※ロケーション情報については利用するMapデータベースに依存するため、正確ではない部分もあるかもしれませんが、今回は「日本以外からのアクセスがある」という事が分かれば十分なので、そこまで吟味しておりません。 ７．まとめ ここまで、ツールを使った Apache のログ解析と可視化についてご紹介しました。 直接ログを見たほうが分かりやすい・効率的といったケースもあるかもしれませんが、 素早く傾向を把握したい ケースにおいて、有効活用できそうと感じました。 また、可視化することでメンバー間での情報共有もスムーズになり、より調査効率の向上も期待できそうです。 今回は、シンプルに Apache の アクセスログ のみ解析対象としましたが、インフラ部門ではOSやメールソフト、データベースなど各種ログを対象に調査する事もありますので、今後も解析対象の範囲を拡大していきたいと考えています。 さらには、 【ログの取得】→【解析環境への投入】 を自動化できる仕組みも構築していきたいと妄想しています。 以上です。最後までお読みいただき有難うございました。 備考 ▼ Apache アクセスログ の標準的なフォーマット設定 LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined このフォーマットに沿って、 アクセスログ が出力されます。カスタマイズも可能です。 ﾌｫｰﾏｯﾄ文字列 説明 %h リモートホスト %l リモートログ名 %u リモートユーザ %t リク エス トを受付けた時刻 \"%r\" リク エス トの最初の行 %>s 最後の ステータスコード %b レスポンスのバイト数。HTTPヘッダは除く。 \%{ Referer }i\ リファラ ー（ 参照元 ） \%{User-Agent}i\ ユーザエージェント 参考文献 mod_log_config - Apache HTTP サーバ バージョン 2.2 Elasticsearch | オフィシャルの分散型検索/分析エンジン | Elastic | Elastic Logstash | データの一元化、変換、保管 | Elastic | Elastic Kibana — データを探索、可視化、分析 | Elastic GitHub - deviantony/docker-elk: The Elastic stack (ELK) powered by Docker and Compose. エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

2021年 新人インタビュー記事 データで見るラクス 卒業区分 卒業学部 応募経路 応募きっかけ 入社の決め手 ラクスの魅力 終わりに 技術広報の yayawowo です。 別記事にて、2021年4月に入社した ラク ス新人エンジニアの皆さんに 応募きっかけ 入社の決め手 現在の業務内容 ラク スの魅力 今後の展望 をインタビューしてきました。 本記事は、2021年に入社した新人エンジニア10名の結果を分析し、まとめてみました！ どのような学生が ラク スに入社するのか、データ面から是非ご参考ください。 2021年 新人インタビュー記事 新人エンジニアの皆さんのインタビュー記事は以下のリンクより、ご確認ください。 配属部署ごとに記事を作成しておりますので、部署の雰囲気や配属後の業務内容など、ご参考になるかと思います！ ◆フロントエンジニア編 【2021年 新人インタビュー】入社して6か月、フロントエンジニアに今の心境を聞いてみた ◆インフラエンジニア編 【2021年 新人インタビュー】入社して6か月、インフラエンジニアに今の心境を聞いてみた ◆バックエンドエンジニア 関西 前編 【2021年 新人インタビュー】入社して6か月、バックエンドエンジニアに今の心境を聞いてみた ～ 関西 前編 ～ ◆バックエンドエンジニア 関西 後編 【2021年 新人インタビュー】入社して6か月、バックエンドエンジニアに今の心境を聞いてみた ～ 関西 後編 ～ ◆バックエンドエンジニア 関東編 【2021年 新人インタビュー】入社して6か月、バックエンドエンジニアに今の心境を聞いてみた ～ 関東編 ～ データで見る ラク ス 卒業区分 図１：卒業区分 院卒、学部関係なく入社しております。 卒業学部 図２：卒業学部 理系学部出身の方が多い傾向ではありますが、研修制度もしっかりしておりますので文系学部出身の方でも安心して入社いただけます。 応募経路 図３：応募経路 応募経路は、直接応募・ インターンシップ と半々という結果でした。 ※2021年度の インターンシップ 募集は終了しました。 　2022年度の インターンシップ をお待ちください！ 応募きっかけ 図４：応募きっかけ ※新人10名にアンケートを実施し、自由記入を集計 前述の通り、 インターンシップ を通じて応募しようと考えた方が多いです。 また、70,000社を超えるお客様に自社開発した クラウド サービスを提供できる事業内容もきっかけの一つになったようです。 入社の決め手 図５：入社の決め手 ※新人10名にアンケートを実施し、自由記入を集計 最後に最も重要な入社の決め手です。 応募きっかけでも上位にあった、事業内容が約半数を占めております。 また、エンジニアが所属している開発本部のミッション 「日本を代表する SaaS 開発エンジニア集団へ」 になるべく、チャレンジできる環境や研修面もしっかりとしております。 ラク スの魅力 カテゴリ 内容 環境・制度 挑戦がたくさんできる 働きやすい 研修が手厚い 学習のサポート制度 社風 成長を考えてくれる 周りのメンバーがとても親切 社員の方々は業務に積極的 向上心のある方が多いので、いい刺激になる 周りの先輩や上長等全員が尊敬できる ※新人10名にアンケートを実施し、自由記入を一部抜粋 環境・制度、社風という大きなカテゴリで整理してみました。 挑戦ができる環境であり、エンジニアの成長を考えてくれるそんな ラク スに皆さんも入社してみませんか？ 終わりに 2021年の新人エンジニアインタビューのまとめはいかがでしたでしょうか？ 今回データで 見える化 したことで、より ラク スに入社した新人エンジニアの特徴などがお分かりいただけたのではないでしょうか。 また、 ラク スは継続して新卒採用を行っております！ ラク スはまだまだ成長をし続ける会社のため、チャレンジできる環境が多々ございます。 是非一緒に働いてみたいという方は、以下サイトをご確認くださいませ。 エンジニア新卒採用サイト https://fresh-recruit.rakus.co.jp/ 一緒に働く仲間をお待ちしております。 では、今後ともよろしくお願いいたします！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

技術広報の yayawowo です。 今回は昨年に続き、2021年4月に入社した新人エンジニアの皆さんに 応募きっかけ 入社の決め手 現在の業務内容 ラク スの魅力 今後の展望 などなど、をインタビュー！ 是非、新卒入社を検討している学生の皆様に ラク スの魅力が伝われば幸いです。 バックエンドエンジニア関東編では、関東開発拠点にある 楽楽精算 開発課に所属する新人エンジニア3名をご紹介します！ ラク スの中でも特に大型開発となる楽楽精算に配属となった皆さんの心境はいかがなものでしょうか？ 楽楽精算開発3課 大熊隆寛さん Q まずは自己紹介をお願いします Q ラクスへ応募しようと思ったきっかけは何ですか？ Q ラクスへ入社した決め手は何ですか？ Q 現在、どのような業務をされていますか？ Q 入社半年で見えたラクスの魅力を教えてください Q 今後の抱負を教えてください Q 就活中の学生の方々にメッセージをお願いします 楽楽精算開発1課 瀬谷遼太郎さん Q まずは自己紹介をお願いします Q ラクスへ応募しようと思ったきっかけは何ですか？ Q ラクスへ入社した決め手は何ですか？ Q 現在、どのような業務をされていますか？ Q 入社半年で見えたラクスの魅力を教えてください Q 今後の抱負を教えてください Q 就活中の学生の方々にメッセージをお願いします 楽楽精算開発2課 Nguyen Hoang Sonさん Q まずは自己紹介をお願いします Q ラクスへ応募しようと思ったきっかけは何ですか？ Q ラクスへ入社した決め手は何ですか？ Q 現在、どのような業務をされていますか？ Q 入社半年で見えたラクスの魅力を教えてください Q 今後の抱負を教えてください Q 就活中の学生の方々にメッセージをお願いします エンジニア新卒採用サイトのご案内 終わりに 楽楽精算開発3課 大熊隆寛さん 楽楽精算開発3課 大熊 隆寛さん Q まずは自己紹介をお願いします 名前　　：大熊隆寛(オオクマ　 タカヒロ ) 卒業区分：学部卒 卒業学部：文系 趣味　　：Bar巡り、カクテル、日本酒、 ボードゲーム 、筋トレ 応募経路： インターンシップ 　 大学は文系だったためプログラミングを学ぶ機会はなかったのですが、リビングに置かれていた情報学部の弟の教科書を見たことがきっかけで、3年の始め頃から独学で学んでおりました。 そこでIT業界に興味を持ち、エンジニアに絞って就活をしました。 ご縁があって ラク スに入社しました。 Q ラク スへ応募しようと思ったきっかけは何ですか？ 応募しようとしたきっかけは、 インターン で行われていたアプリ製作が楽しいと感じたからです。 また、良い経験が積めそうだと考えたのもあります。 Q ラク スへ入社した決め手は何ですか？ 大きく3つほどあります。 ①：会社の規模感と成長中であった 　　大企業で全体像が見えない中その他大勢として働くのは嫌でしたし、 　　かといって、スタートアップで不安定な中働く想像もできませんでした。 　　 ラク スは成長、拡大中ながら基盤がしっかりしており安定しているという良いところ取りだったのが 　　惹かれたところの一つです。 ②：財務諸表や経営戦略に違和感を抱かなかった 　　この会社はまだまだ伸びそう！と感じましたね。 　　他、ミッションやリーダーシッ ププリン シプルにも共感があったのもポイントとなりました。 ③： インターン で関わった先輩や上長の方々の雰囲気いわゆるフィーリング 　　最終的に決めたポイントです。 　　ここでなら働けそう、この人たちと働いてみたいと感じたことが決め手でした。 　　実際、入社した今もその感覚は間違っていなかったと実感しております。 Q 現在、どのような業務をされていますか？ 私の部署では、配属後もしばらくは学習が中心でした。 学習では業務で使われている フレームワーク の学習や製品知識など、改めて基礎から幅広く学びます。 その後はバグ修正をメインに、カスタマーサポートでは対応できないお客様からの技術的な問い合わせへの回答や日常的な運用業務などを担当しております。 結合テスト への参画等、少しずつできる業務が増えていっている段階です。 Q 入社半年で見えた ラク スの魅力を教えてください どんどん改善されていく社内環境・制度やもさることながら、最も魅力を感じているのは、周りの先輩や上長等全員が尊敬できる方々ということです。 プログラミングに対する知識はもちろん、製品知識の豊富さ、視野の広さ、思慮深さ、他部署との連携や物事の受け答えなど尊敬するところばかりです。 正直私もなれるだろうか・・・と思ってしまいますが、頑張るしかないと毎日先輩方の背中を追いかけ精進しております。 中でも特にすごいなと感じるのが、教えてもらう際に一切上から目線を感じないことです！ 教えるというのは少なからず上から目線が含まれてしまうものというのが一般的かと思いますが、ご指導してくださっている方々から感じません。 これはまた頭ごなしに決めつけず、真摯に向き合ってくださるからこそなのかなと考えております。 Q 今後の抱負を教えてください PdM、 プロダクトマネジメント に寄ったエンジニアになりたいと思っております。 もっと大きく言うと設計側ということでしょうか。 楽楽精算はどうすれば今以上に成長できるか的確に考えられ、また他部署との連携を潤滑にするようなことをエンジニア側として行ってみたいと思っております。 より具体的な理想像なら、先輩方のような抜けがないレビューができるようなエンジニアになりたいです。 現在の所属から影響されたので当たり前ですが、 ラク スでこれらは叶えられると思っております。 先輩方も丁寧に指導してくださっているので、自分が努力する心を忘れなければいつかはなることができそうです。 Q 就活中の学生の方々にメッセージをお願いします 世間一般で言われるいい会社というだけでなく、ぜひ自分に合った会社を意識して探してみてください！ そのためにはいろいろな会社を見る、改めて自分について考えてみるというのが大切です。 就活は大変かもしれませんが、なかなかない良い機会でもあります。 悔いの残らないよう積極的に取り組んでみてくださいね！ 楽楽精算開発1課 瀬谷遼太郎さん Q まずは自己紹介をお願いします 名前　　：瀬谷遼太郎(セヤ　リョウタロウ) 卒業区分：院卒 卒業学部：理系 趣味　　：麻雀 応募経路：直接応募 　 瀬谷です。 大学ではプログラミングを学んでいました。 研究でアプリケーションを作ったことがきっかけで、開発職に興味を持ちました。 Q ラク スへ応募しようと思ったきっかけは何ですか？ 求人サイトでたまたま目に留まり、説明会で社員の方などとお話しする中で働きやすそうな会社だと感じことがきっかけです。 Q ラク スへ入社した決め手は何ですか？ ラク スの業績や働きやすさです。 Q 現在、どのような業務をされていますか？ 私の部署は製品自体の歴が長いこともあり、6月末に配属されてからも3、4カ月は学習期間でプログラミングの学習や製品についての理解を深めました。 その後は軽微なバグ修正やテスト、お客様からの質問に答えるなどの業務でさらに製品への知識を増やしていき、現在は新規機能の開発に取り組んでいます。 Q 入社半年で見えた ラク スの魅力を教えてください 入社前から感じていた通り非常に働きやすい環境が魅力です。 特にメンターの方や上司の方とのコミュニケーションがチャットなどで気軽に行えることと、分からないことはすぐに質問できる雰囲気になっていることが魅力です。 仕事においては下手に時間をかけて悩むより聞いてしまった方がいいケースが圧倒的に多いので非常に助かっています。 Q 今後の抱負を教えてください まだまだメンターの方や上長の方などにお世話になりっぱなしなので、できるだけ独力でも仕事を進められるようになっていきたいです！ Q 就活中の学生の方々にメッセージをお願いします 本当にやりたい仕事ができるかは入社してみないと分からない部分も多々あると思いますが、後悔のないようにいろんな企業を見るのがいいと思います。 楽楽精算開発2課 Nguyen Hoang Sonさん 楽楽精算開発2課 Nguyen Hoang Sonさん Q まずは自己紹介をお願いします 名前　　：Nguyen Hoang Son(グエン・ホアン・ソン) 卒業区分：院卒 卒業学部：理系 趣味　　：写真撮影 応募経路：直接応募 　 ホアンソンです。 私は ベトナム 出身で、日本文化や日本の最新技術を学ぶために5年前日本に来ました。 日本語が使える ベトナム人 として両方の国の架け橋になり、両方の国に貢献したいと思っています。 Q ラク スへ応募しようと思ったきっかけは何ですか？ ラク スはRakus Vietnamという子会社があって、BrSEとして働けると思っていました。 また、自社のサービスを開発できるのが魅力です。 Q ラク スへ入社した決め手は何ですか？ ラク スで自分の知識を活躍し、成長できると思いました。 Q 現在、どのような業務をされていますか？ 私の部署では、配属後の最初の3、4ヶ月くらい学習を中心にしました。 開発に必要な基本知識を学習を行いながら製品の理解を深めた後、バグ修正や 結合テスト といった開発に関するタスクを実施しています。 未経験者なので、実施する前にしっかり説明など行っていただけました。 また、定型作業もやっています。 サーバーまたは製品に問題点があるかどうかの確認の作業です。 こちらの作業は共通性がありますので、部署の新卒の皆と一緒に楽しくやっています。 Q 入社半年で見えた ラク スの魅力を教えてください 私にとって魅力は２点があります。 ①：親しみやすい環境 　　同期だけではなく先輩や上司にも気軽く相談できますし、 　　日本語といった作業で分からないこともありますが、すぐに先輩から教えて頂けています。 　　さらに作業中でも仕事に関係がないことをはなしたり、雑談したりすることもできます。 ②：学習のサポート制度 　　仕事で必要な学習だけではなく自分の成長のための学習もサポートして頂いています。 　　例えば、日本語の学習のための本や試験料なども ラク スから頂けるというところです。 Q 今後の抱負を教えてください 現時点、 ベトナム 側に関係がある作業を実施できていません。 そのため自分の能力を高めてBrSEの仕事ができるようにしたいと思っています。 Q 就活中の学生の方々にメッセージをお願いします 会社が自分に合うかどうかを判断するのが難しいと思いますが、 後悔のないように、まず応募し、少しでも会社の雰囲気を感じてみたらいかがでしょうか。 エンジニア新卒採用サイトのご案内 是非一緒に働いてみたいという方は、以下サイトをご確認ください！ https://fresh-recruit.rakus.co.jp/ 終わりに 関東編では、大熊さん、瀬谷さん、ソンさんにお話しをお伺いしました！ 東京開発拠点では、 楽楽明細 というプロダクトもあり、こちらの開発にも携わることができます。 本インタビューをきっかけに、 ラク スが関東在住の学生や 第二新卒 の方の就職先の1つとなれば幸いです！ 最後までお読みいただきありがとうございました。 本記事にて2021年新人インタビューは終了になります。 2022年の新人エンジニアへのインタビューをお楽しみに！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

新規サービスの開発チームに所属しているkarabishです。 2021年11月に JJUG CCC 2021 Fall にて「勤怠管理サービスでの継続的テストの取り組み」というテーマで登壇しました。 パフォーマンステストの自動化について発表したのですが、発表時はどういうことをやったのかのみをお伝えしましたので本ブログでは具体的な方法をお伝えできればと思います。 JJUG CCC 2021 Fallとは 登壇資料はこちら なぜパフォーマンステストの自動化を取り組みしたのか パフォーマンステストの自動化で利用したもの Ansible/JMeter/Grafana/InfluxDB/PostgreSQLの環境構築 Ansible JMeter Grafana/InfluxDB/PostgreSQL パフォーマンステストを自動化される前は 1. 負荷がかかるサーバを構築する 2. 負荷をかけるサーバを構築する 3. JMeterシナリオを実行する 4. JTLファイルをインポートする 5. 統計情報をインポートする 6. GrafanaでInfluxDB/PostgreSQLにある結果をグラフ化する まとめ JJUG CCC 2021 Fallとは JJUG CCCは毎年2回、春と秋に開催する日本最大の Java コミュニティイベントです。 Java 関連の技術や事例に関する良質なセッションが行われ、また異なる分野で活躍する Java 技術者が集まる場ともなっています。 https://fortee.jp/jjug-ccc-2021-fall 登壇資料はこちら 関連ブログとして以下も合わせてご確認ください！ tech-blog.rakus.co.jp なぜパフォーマンステストの自動化を取り組みしたのか そもそもなぜパフォーマンステストを自動化する取り組みしたのかですが、パフォーマンステストを自動化する前は3つの問題がありました。 この3つの問題があり気軽にできていなかったことで、パフォーマンスの改善をすることが難しかったため改善に取り組みました。 パフォーマンステストの自動化で利用したもの こちらのツールを利用したのですが、各ツールの役割は以下の通りです。 Gitlab CI パフォーマンステストのイベントを発火する Ansible JMeter にパフォーマンステストを実行してもらう JMeter の実行結果をInfluxDB/ PostgreSQL にデータを永続化してもらう JMeter パフォーマンステストを実行する Grafana パフォーマンステスト結果をグラフ化する InfluxDB パフォーマンステスト結果のHTTPリク エス トごとの結果を永続化する PostgreSQL パフォーマンステスト結果の統計情報を永続化する Ansible/ JMeter /Grafana/InfluxDB/ PostgreSQL の環境構築 Ansible Gitlab CI上でAnsibleがインストールされたDockerを利用しています。 JMeter JMeter の構築は JDK のインストールと、公式サイトからバイナリファイルを解凍すれば利用可能になります。 チューニングする箇所は JMeter が利用する メモリ や GC くらいを環境に合わせる必要がありそうです。 Grafana/InfluxDB/ PostgreSQL Grafana/InfluxDB/ PostgreSQL は podman 上に構築しています。利用している CentOS がdockerをサポートしていなかったためpodmanを利用しています。 CentOS へのpodmanのインストールは yum でインストール可能です。 podmanは以下のように マニフェスト を記載し、 podman play kube {マニフェスト} を実行すればpodを構築してくれます。 apiVersion : v1 kind : Pod metadata : labels : app : dashboard name : dashboard spec : containers : - name : grafana image : grafana/grafana ports : - containerPort : 3000 hostPort : 3000 protocol : TCP - name : influxdb image : influxdb env : - name : DOCKER_INFLUXDB_INIT_MODE value : setup - name : DOCKER_INFLUXDB_INIT_USERNAME value : root - name : DOCKER_INFLUXDB_INIT_PASSWORD value : password - name : DOCKER_INFLUXDB_INIT_ORG value : org - name : DOCKER_INFLUXDB_INIT_BUCKET value : performancetest - name : DOCKER_INFLUXDB_INIT_ADMIN_TOKEN value : admintoken ports : - containerPort : 8086 hostPort : 8086 protocol : TCP volumeMounts : - name : pv-influxdb mountPath : /var/lib/influxdb2 - name : pv-influxdb-config mountPath : /etc/influxdb2 - name : postgres image : postgres env : - name : POSTGRES_USER value : postgres - name : POSTGRES_PASSWORD value : postgres - name : POSTGRES_DB value : performancetest ports : - containerPort : 5432 hostPort : 5432 protocol : TCP volumeMounts : - name : pv-postgres mountPath : /var/lib/postgresql/data volumes : - name : pv-postgres hostPath : path : /usr/local/dashboard/data/postgres type : Directory - name : pv-influxdb hostPath : path : /usr/local/dashboard/data/influxdb/data type : Directory - name : pv-influxdb-config hostPath : path : /usr/local/dashboard/data/influxdb/config type : Directory パフォーマンステストを自動化される前は パフォーマンステストの自動化について説明する前に5つのステップで作業を行っていました。 基本的にはこの作業を自動化しています。 1. 負荷がかかるサーバを構築する Gitlab CIからイベントを受け取り、Ansibleにて負荷がかかるサーバを構築します。 AWS だとterraformを実行するようなイメージです。 2. 負荷をかけるサーバを構築する Ansible/JMeter/Grafana/InfluxDB/PostgreSQLの環境構築 を参照ください。 3. JMeter シナリオを実行する JMeter シナリオは jmeter -n -t {シナリオファイル} -l {JTLファイルの出力先} -e -o {レポートの出力先} を実行することで可能です。 JTLファイルはHTTPリク エス トごとの結果でこの後InfluxDBに永続化し、レポートの出力先は統計情報でこの後に PostgreSQL に永続化します。 4. JTLファイルをインポートする JTLファイルをInfluxDBに永続化は influx write --org {DOCKER_INFLUXDB_INIT_ORG} --token {DOCKER_INFLUXDB_INIT_ADMIN_TOKEN} --host http://{エンドポイント}:8086 --bucket {DOCKER_INFLUXDB_INIT_BUCKET} --file {CSVファイル} を実行することで可能です。 5. 統計情報をインポートする 統計情報は JSON 形式で保存されているため、 SQL に変換し psql コマンドでINSERTしています。 6. GrafanaでInfluxDB/ PostgreSQL にある結果をグラフ化する まずはGrafanaからInfluxDBと PostgreSQL に接続するためのData Sourcesを設定します。 InfluxDBのData Sources設定は こちら を参照ください。 PostgreSQL のData Sources設定は こちら を参照ください。 InfluxDBと PostgreSQL に接続できるようになったため、あとは表示するグラフ設定を こちら を参照に設定するのみとなります。 また、今回は GUI から各種設定をしたのですが、起動時にプロビジョニングすることも こちら にある通り可能です。 まとめ パフォーマンステストのイベントを発火する作業をすればテストが自動化されるようになりました。 これで本来やりたかったパフォーマンス改善に取り組みができるようになるのではと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

技術広報の yayawowo です。 いつも ラク スのエンジニアブログをお読みいただき、ありがとうございます！ 今回は、12月に開催した 【ラクスMeetup】大規模SaaSを支えるインフラ組織の取り組み／自動化、障害対応マニュアル、CI/CD、SRE の発表内容について紹介させていただきます！ Meetupのテーマは、『インフラ』です！ 以下10プロダクトを支え、最前線で活躍している3名のエンジニアがインフラ業務における自動化に向けた取り組みや、障害対応事例についてご紹介します。 楽楽精算 楽楽明細 楽楽販売 楽楽労務 楽楽勤怠 MailDealer ChatDealer 配配メール クルメル blastmail イベントの詳細は以下をご確認ください。 ・ rakus.connpass.com 発表の紹介 普段の生活で感じる自動化とインフラ仕事の自動化について チームとしての障害対応時間削減に向けて取り組んだこと 新サービス立ち上げに向けたCI/CD環境の構築 おわりに 発表の紹介 それではここから各発表内容と資料を共有させていただきます！ 普段の生活で感じる自動化とインフラ仕事の自動化について 登壇：松本 隆二 [所属：東京インフラ開発1課] 普段の生活でも自動的に行われることで便利なもの、増えてきています。 それが頻発する作業であればあるほど、『楽』にするに越したことはないというのは、日常生活も、インフラ仕事も変わらないですよね。 東京インフラ開発課の松本より、身近にあふれている自動化の話などをさせてもらった後に、 身近なインフラ仕事の自動化への変遷の話を以下のポイントですこしだけお話しさせていただければと思いました。 日常生活とインフラ業務との共通点 システムの成長の経緯 運用コストの増加と納期との闘い 自動化による省略化の話 speakerdeck.com チームとしての障害対応時間削減に向けて取り組んだこと 登壇： 西江 正義 [所属：大阪インフラ開発課] メールディーラーとチャットディーラーで合わせて1000台近いサーバを運用していると、様々な障害が発生します。 中でも仮想基盤機器やネットワーク機器の障害は大規模になりやすく、主にそういったものに対し、 　 どうすればチームとして迅速に対応できるようになるか？ 　 ということを考え、実践したことについて大阪インフラ開発課の 西江 がお話させていただきました。 speakerdeck.com 新サービス立ち上げに向けたCI/CD環境の構築 登壇：見形 親久 [所属：SRE課] 最後は、SRE課の見形による発表です。 現在、SRE課では新サービスの立ち上げに向けてCI/CD環境の準備を進めています。 これまでの ラク スではオンプレミス環境で運用が多かったのですが、新サービスは クラウド ネイティブな環境での運用を考えています。 新しい取り組みなので四苦八苦しているところですが、どのような点に注意しながら環境を構築しているのかご紹介させていただきました。 speakerdeck.com おわりに 「【Meetup】大規模 SaaS を支えるインフラ組織の取り組み／自動化、障害対応マニュアル、CI/CD、SRE」はいかがでしたでしょうか？ 　 着想から1年…今回インフラ組織に特化したMeetupを開催させていただきました！ また、大規模 SaaS に携わる業務の中での課題や教訓をインフラ組織だからこその目線で発信させていただきました。 本内容が SaaS 開発に携わる方やインフラ技術にご興味をお持ちの方の一助となれば幸いです。 最後に宣伝です！ ラク スのインフラ組織ではインフラエンジニアを積極的に募集しております！ 是非ご興味ありましたら以下をご確認の上、ご応募ください。 拠点 募集職種 東京 インフラエンジニア／マネージャー（東京） | 株式会社ラクス インフラエンジニア[東京/楽楽明細] | 株式会社ラクス インフラエンジニア[東京/楽楽労務] | 株式会社ラクス SREエンジニア[東京/インフラ] | 株式会社ラクス アーキテクト・テックリード[東京/インフラ] | 株式会社ラクス 大阪 インフラエンジニア／マネージャー・管理職（大阪） | 株式会社ラクス インフラエンジニア（大阪） | 株式会社ラクス ※2022/1/14時点での情報です。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめまして！2021年4月に入社したnkumaです！ 入社から9か月ほど経ち、徐々に業務に慣れ始めてきた今日この頃、改めて新人研修のことを思い出してみました。 去年に引き続きコロナ禍のため、大半が在宅での研修となっていました。 社会人になったばかりの在宅研修でさぞかし不便かと思いきや、かなり充実した研修だったと自負しています。 ということで、今回は私が受けた新人研修の流れとそこで得たことについてご紹介いたします。 コロナが新卒研修に与えた影響 工夫例⓵：演習する際は3～4人のブレークルームを作る 工夫例②：画面共有や遠隔操作を利用する メリット①：作業中の雑談がしやすい メリット②：質問がしやすい メリット③：予習・復習の時間がとれた 在宅での新卒研修を総じて 新卒研修の概要 新卒研修で主に使用した技術 新卒研修のカリキュラム 新卒研修で得たこと チーム開発のメリット・デメリット 適切な質問の仕方 報・連・相のタイミング モノづくりの楽しさ まとめ コロナが新卒研修に与えた影響 まず最初にお話ししたいのがコロナの影響についてです。 私たちが技術研修を受けていたのは、大まかに4月中旬~6月末の2か月半でした。その間、まん防(まん延防止等重点措置)や緊急事態宣言が相次ぎ、最初の基礎学習と最後の成果発表以外はずっと在宅だった覚えがあります。しかし、講師の方が工夫してくださったおかげで、あまりデメリットは感じず充実した研修を受けることができました。 下記ではその工夫の一部と在宅で研修を受けて感じたメリットをあげさせていただいています。 工夫例⓵：演習する際は3～4人のブレークルームを作る 皆で一部屋で演習するのではなく、演習のタイミングでランダムに3～4人のルームに分けられ、そこを講師が巡回するという形式でした。 お互いの状況が把握しやすく、新卒間で様々なことを共有しやすかったです。 全員が一つのルームで演習すると、講師の方が常にいて下さるのはメリットですが、コミュニケーションはとれず、声をあげづらく、集中しづらいため効果的な工夫だったと思います。 工夫例②：画面共有や遠隔操作を利用する Zoomの機能である画面共有、遠隔操作等をフル活用することで、リアルで学ぶよりもやりやすかったような気がします。遠くからモニターを見るのではなく、直接自分の画面に映し出されるため見づらい思いをすることがありませんでした。 また、一度に複数人で同じコードを見れるので他人のコードを勉強しやすかったです。 メリット①：作業中の雑談がしやすい 演習時間の大半は3～4人だけなので、周りを気にせずにコミュニケーションをとることができました。 常に誰かが画面共有をしておいて、他人のコードを見ることで良いコードの書き方を話し合ったこともあります。 そのおかげで、通常より多くのことを新卒間で共有できたと思います。 メリット②：質問がしやすい 講師の方が巡回に来たときに質問すればいいので、質問のタイミングをとりやすかったです。 それまでに同期間で問題を共有し、考えて、教え合うことで内容がより身につきました。 コードを画面共有すれば他人と自分のコードを簡単に複数人で見比べることができるので違いも見つけ出しやすく、 ケアレスミス を見つけるときにも便利でした。 また、チームの皆が画面共有を見れるので他人への指摘も自分のものにすることが容易でした。 メリット③：予習・復習の時間がとれた 朝夕の通勤時間が丸々空くため、予習・復習の時間をとりやすかったです。 また過去のテキストやPCが常に手元にあり、暇なときがあれば手に取りやすかったのも一つの理由かと思います。 基礎を固めるフェーズにおいて、しっかりと予習・復習ができるのは大きなメリットかと思います。 在宅での新卒研修を総じて 講師の方の工夫のおかげで、在宅で受けた新卒研修はメリットしか感じませんでした！ 在宅ではコミュニケーション不足になるとよく言われますが、私たちの研修ではむしろ対面よりもしっかりとコミュニケーションが取れていたように思います。コロナ禍で在宅とならなければ今以上に同期が仲良くはなれなかったとさえ感じるほどです。 学習の上で大切な予習・復習がしやすく、説明が効きやすく、質問がしやすいなどこれ以上にないほど最高の環境でした。 しかし、上記にあげたメリットは研修を在宅で受けるメリットであり、業務を在宅でするのとは少し異なることに注意が必要です。 学習と業務は別物のうえ、同期間ではない先輩後輩、上司部下の関係で円滑なコミュニケーションがとれるかは微妙なところなので…。 コロナ禍で在宅でも研修は良いものでした！というのをお伝えできたなら幸いです。 新卒研修の概要 新卒研修では、各種制度の説明やビジネスマナー、商材の説明も受けますが、メインは技術研修となっています。 2か月半ほど技術研修をした後は配属されて、各商材に合わせた研修に入ることとなります。 技術研修では、基本的に「説明を受けて演習」を繰り返します。 説明を聞いて覚えるのではなく、実際に動かすことによって実感の伴った理解をすることができました。 終盤はそれまでに得た知識を総動員していくつかの実践演習を行います。個人演習から始まり最後にはチームで ECサイト を作るという課題に至ります。 「手を動かして学ぶ」ということが重視されていることを全体的に実感する流れです。 新卒研修で主に使用した技術 Java PostgreSQL SpringBoot その他 HTML/ CSS JavaScript JQuery Linux Git プログラミングの学習は主に Java を中心に実施していました。 SQL には業務でも利用している PostgreSQL を使って学習いたします。 アプリ作成にはSpringBootを利用しています。 新卒研修のカリキュラム 以下では新卒研修の内、メインである技術研修で学習したことを大まかにご紹介いたします。 こちらに書かれていることが全てではなく、また年々改善しているためご参考程度にお目通し下さい。 ⓵基礎知識 基本情報技術者試験 などを利用しつつ、ITに関する基礎知識を学びました。(2進数や プロトコル など) ②プログラミング基礎 Java を利用して、変数からメソッドなどのプログラミングとしての基礎についてです。 ③ オブジェクト指向 「継承」「 カプセル化 」「 ポリモーフィズム 」といった オブジェクト指向 のキホンを学びます。 ④データベース基礎 SQL 文の書き方について学習します。 ⑤DBアクセ スプログ ラミング プログラムからDBにアクセスする方法としてDaoパターンを学びます。 ⓺ フレームワーク ThymeleafやSpringJDBCなどSpringBootを扱う上で基本となることを学びました。 ⑦Git チーム開発をするのに必要なGitの考え方や基本的なコマンドを学習します。 ⑧ ソフトウェアテスト 入門 テスト仕様書の作り方から JUnit の使い方までを学びます。 ⑨HTML/ CSS 、 JavaScript 、 JQuery 、 Ajax フロントの最低限の知識を学び、 Ajax を扱えるようにします。 ⓾サービス運用・保守 実務的なエラー処理のやり方やセキュリティ対策を学びます。 ⑪ Linux 基礎 基礎的な Linux コマンドからデプロイの考え方・やり方を学びました。 ⑫実践編（従業員管理システム、 掲示 板システム、 ECサイト ） テスト仕様書を書いてプログラムを組むといったことや、用意されているシステムのバグ修正を行うなどかなり実践的な内容となります。 それまでに学習した内容を活用していて自分のものにしていくといった過程です。 ECサイト 制作では実際にチームに分かれ、最低限の仕様は実装しつつ、各々の工夫をして、管理職や現場の方に発表します。 新卒研修で得たこと チーム開発のメリット・デメリット 最後の ECサイト の学習でチーム開発の良さ、難しさを学びました。 良いと思ったことは「得意なことを分担できる」ことです。 ひとりはフロントが得意なのでデザインを、ひとりは難しめの実装を、もう一人は細かいことによく気付くのでバグ探しをといった具合に分担することで、効率よくかつより良いものを作ることができました。 研修全ての集大成としては微妙な動きだったかもしれませんが、仕事の本質を実感したように思います。 自分の得意なところを探して伸ばすことが最も貢献できることだと理解しました。 また、「お互いに支え合える」というのもメリットに強く感じます。 複雑なシステムに取り組む際、何度も折れそうになりましたが、チームの励ましでなんとか形にすることができました。どうしようもなく行き詰ってしまったときも、それぞれで案を出し合い最善のものを作ることができ、 文殊 の知恵というのを実感しました。 対して難しさを感じたのは「コミュニケーション不足での行き違い」です。 仕様に対する考え方が違っていたり、誰かが後回しにしていた実装が完了しないために他の人の進めている部分がストップしてしまうこともありました。 円滑なコミュニケーションをとるには認識合わせを欠かしてはいけないことを知りました。 適切な質問の仕方 新卒研修を受ける過程で多くの質問する機会に恵まれました。 そのため質問するポイントが掴めたように思います。 当たり前のことですが、整理整頓して話すということを忘れてはいけないことに気づきました。 整理整頓して話すことのポイントは２つと考えています。 「何がしたいかの目的、何をした結果どうなったかの過程、自分で試した事とその結果」を整理してお伝えすることが一つです。次に「事実と意見」を分けて伝えるということです。 上記の2つを意識するようになったところ、格段に手ごたえのある質問ができるようになった気がします。 当然のことですが、慌てて質問すると忘れがちとなってしまうので、少し時間をかけてでも整理して質問するよう意識しています。 報・連・相のタイミング 報連相 自体は学生時代から意識していましたが、その認識が甘いことを改めて学びました。 何かをしたら報告、つまづいたら相談といった「後」の 報連相 ではなく、何かをする前にその方針でいいのか相談するといった「前」の 報連相 が大事だと知りました。 研修内で難易度の高いプログラムを組む際に、予め実現できそうな方法をいくつか想定しておいて取り組む前に相談したところ、自分の考慮できてない点を指摘していただけました。その結果、同じ時間でもより品質の良いプログラムにすることができたと思います。 モノづくりの楽しさ チーム開発で ECサイト を作った際にモノづくりの楽しさを実感しました。 スタート地点は同じなのに各チームで個性が出ており、デザインに力を入れたサイトもあれば、動作が軽くなるよう意識されたサイト、管理者用のメニューを作ったサイトと、各々のチームの考えによって違いが表れていました。 どうすればより良いモノが作れるのか、そう考えて違いを出していくことが楽しさの一つだと知りました。 また、あーだこーだと言い合いながら、互いに助け合い、一つのモノを作り、完成させた喜びは言葉にできません。 他のなによりも貴重な経験として、今後を支えるものとなっていくと思います。 まとめ 新卒研修の全てがそのまま役に立ったかと言われるとそうでないかもしれません。 しかし、確実に研修を受ける前と後では成長を実感しており、その経験は色々な部分で結びついています。 研修では悩む箇所も多くありましたが、挫けずに完了することができたのは偏に講師の方の尽力と同期間で励ましあえたからです。恵まれた環境にいることを自覚しました。 学んだ技術や考え方も大事ですが、何よりやり遂げた自覚が自分の中で一番大きいです。 コロナ禍で例年とは異なる研修体制でしたが、私は今年このような研修を受けられたことに感謝しています。 今後は実務を通して仕事を覚えていき、早くお力になれるよう努力していきます！ エンジニア新卒採用サイト https://fresh-recruit.rakus.co.jp/ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは、技術広報の yayawowo です。 突然ですが、 はてなブログ をご利用されている方、 アイキャッチ 画像の作成に困ることはないでしょうか？ ブログだけではありません。 昨今、 SNS （ Twitter や Instagram ）、 Youtube のサムネイル、HPのロゴなど もご自身でデザインすることが多くなってきていると思います。 　 とはいえ、 ・デザインソフトである Adobe Illustrator を買うほどでもない ・デザイナーに頼むほどでもない ・デザイン力はないけど、自分で効率的に作成したい といった悩みがあるかと思います。 そんな方にオススメしたいので、誰でも無料でおしゃれなデザインを作成できる Canva というデザインツールです！ 私は技術広報の仕事上、ブログ/イベント/ SNS で多くCanvaを利用しております。 ラク スの活用事例もまとめておりますので、是非ご参考ください！ Canva（キャンバ）とは？ Canvaの魅力 利用時の注意点 Canvaの使い方 ラクスでの活用事例 テックブログ ラクス主催のイベント Canva 使い方 まとめ Canva（キャンバ）とは？ Canvaは、オーストラリアで2013年に誕生し、全世界で月間6,000万人以上のユーザが利用している オンラインの無料デザイン公開ツール です。 これまでに作成されてたデザインは70億以上で、100もの言語に対応しております。 Canva公式サイト　➡　 https://www.canva.com/ja_jp/ パソコンをお使いの方は、ブラウザで上記公式サイトを開く、 スマートフォン からは Android 版、 iOS 版の両方に専用のアプリをインストールすることでご利用いただけます！ いつでも、どこでも、簡単にデザインを作成することができるのはとても魅力出来たと思います。 Canvaの魅力 Canvaの魅力は、前述した内容の他にも多くあります！ 以下3ポイントに絞ってご紹介したいと思います。 ①無料で始められる Canvaにアカウントを無料で登録することで、すぐにデザインを作成することができます。 アカウント登録するには、3つの方法があります！ 図１：Canvaで始める ◆ 登録方法 ・ Google アカウントで登録 ・ Facevookアカウントで登録 ・ メールアドレスで登録 登録後、以下内容をご利用いただけます。 ◆ 無料アカウントでできること ✔　25万点を超える無料テンプレート ✔　100種類以上のデザインタイプ ✔　数多くの無料の写真とグラフィックス ✔　メンバーをチームに招待する ✔　リアルタイムでのコラボレーションやコメント ✔　5GBの クラウド ストレージ ✔　 PDF、 JPEG 、 PNG 、MP4、GIFなど、用途に応じたダウンロード形式を選べる 引用元「 https://www.canva.com/ja_jp/pricing/ 」 ※2022/1/6時点の情報です。 ②豊富なデザインテンプレート Canvaには、様々な用途で利用できるようにデザインテンプレートが幅広く準備されております。 デザインテンプレートを活用する前にまず選択すべきなのが、コンテンツです。 目的 コンテンツ プレゼンテーション ・プレゼンテーション資料(16:9、4:3) ・動画プレゼンテーション ・ ブレインストーミング SNS ・ Instagram の投稿、ストーリー ・ Facebook の投稿、カバー、広告 動画 ・動画メッセージ ・ Facebook ビデオ ・ YouTube 動画、広告 ・フィード広告 印刷製品 ・ポストカード ・チラシ ・招待状 ・ポスター ・マグ カップ ・ギフト券 マーケティング ・ポスター ・ロゴ ・チラシ ・名刺 ・ラベル ・パンフレット オフィス ・履歴書 ・A4文章 ・レポート ・ToDoリスト、予定表 ・手紙 ・提案書、企画書 目的に応じてコンテンツを選択後、準備されたデザインテンプレートを利用することができます。 例えば、 「ロゴ」 を選択した際のデザインテンプレートは以下の通りです。 図２：Canva　ロゴ 病院、ドクター、教会、イベント、アニメーション、ゲームなど様々なロゴのデザインテンプレートが準備されております！ ③豊富な素材 Canvaは、コンテンツやデザインテンプレートだけでなく素材も豊富に準備されております。 いくつかピックアップしてみましょう。 ◆ 線と図形 図３：Canva素材　線と図形 ◆ 虎 図４：Canva素材　虎 ◆ テキスト 図５：Canva素材　テキスト ◆ 背景 図６：Canva素材　背景 ◆ 写真 図７：Canva素材　写真 以下サイトからもCanvaの写真イメージを検索することができます！ Canvaストックフォト　➡　 https://www.canva.com/photos/ これらの特徴を活かしつつ、自分だけのおしゃれなデザインを作成してみてください！ 利用時の注意点 無料でおしゃれなデザインが作成できるのはとても嬉しいのですが、Canvaを利用する際に注意も必要です。 注意点①　使用素材の 著作権 Canvaにて提供している素材、及び作成したデザインは商用利用して問題ございません。 詳しくは、以下をご確認ください。 https://www.canva.com/ja_jp/learn/commercial-use/ ◆ 商用利用OK例 ✔　自社のホームページに掲載する ✔　 SNS 投稿に使用する ✔　 マーケティング 素材（広告、営業資料など）として使用する ✔　名刺を配布する ✔　取引先に年賀状を送る ✔　Tシャツを作成して販売する　など ◆ 商用利用NG例 ✔　Canvaの素材（写真・音楽・動画など）を無加工の状態で、販売、再配布、クレジットの取得を行う ✔　Canvaで作成したデザインをつかって商標登録をする ✔　Canvaの素材をストックフォトサービスなどのサイトで販売する 引用元「 https://www.canva.com/ja_jp/learn/commercial-use/ 」 ※2022/1/6時点の情報です。 注意点②　無料プランの制限 Canvaにて作成したデザインは、Canva内にあるストレージに保存されれます。 無料プランのストレージは 5GB となりますので、もし5GG以上のデータを保存したい場合は有料プランへのアップグレードが必要です。 注意点③　有料のテンプレート購入時の制限 デザインを作成する上で、利用したいテンプレートや素材が有料ということもあるかと思います。 有料のものは、1デザインを$1（約110円）で購入することが可能です。 なお、有料のデザインを購入した場合、24時間以内にデザインを完成する必要があります！ 24時間経過後は再度購入が必要となりますので、注意ください。 Canvaの使い方 これまでCanvaの基礎的な内容をご紹介させていただきましたので、ここからは実際にCanvaを使ってデザインを作成してみたいと思います！ 今回は、パソコンのブラウザ上で実践してみます。 １．コンテンツを選択する 赤枠で囲んでいる部分にて、コンテンツを選択します。 ※今回は「ロゴ」を選択 図8：コンテンツ選択 ２．デザインテンプレートを選択する 左メニューの「テンプレート」を選択します。 図９：デザインテンプレート選択 「テンプレート」の中から利用したいデザインを選択します。 ※今回は「コーヒーのロゴ」を選択 図１０：コーヒーロゴ ３．デザインをカスタマイズする 左メニューの「素材」「テキスト」「スタイル」「背景」を利用し、自分好みのデザインを作成しています。 「素材」を利用し、コーヒーの画像変更します。 図１１：コーヒー画像変更前 図１２：コーヒー画像変更後 「テキスト」を利用し、ESPRESSOの文字とフォントを変更します。 図１３：テキストの選択 図１４：文字とデザインの変更 「スタイル」を利用し、色を変更します。 図１５：スタイル変更 「背景」を利用し、背景画像をつけてみます。 図１６：背景変更 ４．完成したデザインをダウンロードする Canvaの画面右上にある「ダウンロード」をクリックします。 図１７：ダウンロード ダウンロード形式を選択し、紫色の「ダウンロード」をクリックします。 クリック後、PCのローカルフォルダに制作物がダウンロードされていますので、ご確認ください。 図１８：ダウンロード画面 Canvaにてダウンロードできる形式は以下の通りです。 ◆ ダウンロード形式一覧 ・ PNG ・JPG ・PDF（標準） ・PDF（印刷） ・ SVG 　　　　　　※有料プラン ・MP4形式の動画 ・GIF 以上、簡単ではありますがCanvaを使ったデザイン作成方法でした。 誰でも簡単に利用しやすいUIとなっていますので、まずは何か一つ作成してみることをおすすめします！ ラク スでの活用事例 技術広報の具体的な活動として、テックブログの運営と ラク ス主催のイベントがあります。 その活動の中でCanvaを使って作成した、各コンテンツをご紹介します！ 技術広報の取り組みは以下をご確認ください！ tech-blog.rakus.co.jp テックブログ テックブログの アイキャッチ 画像をCanvaにて作成しました。 ラク ス主催のイベント Cnnpassにて開催している ラク ス主催のイベントの アイキャッチ 画像もCanvaにて作成しています！ Connpassにて開催しているイベントは、以下をご確認ください！ rakus.connpass.com 上記の通り、Canvaを活用して様々なデザインを作成できることが分かりますね！ Canva 使い方 まとめ Canvaの基本的な使い方、活用事例はいかがでしたでしょうか？ デザインスキルがなくても、誰でも簡単におしゃれなデザインを作成することがご紹介できていれば幸いです。 （ちなみに今回活用事例で紹介しているものも、デザインスキルがない私が作成したものです！） 無料アカウントでも、豊富な機能を使える便利なツールですので、ぜひお試しください！ また、デザイン専門の組織があり、デザイナーを積極的に募集しております。 是非ご興味ありましたらご応募ください！ Webデザイナー（東京） | 株式会社ラクス UIデザイナー（東京） | 株式会社ラクス UIUXデザイナー／マネージャー（東京） | 株式会社ラクス 最後までお読みいただきありがとうございました。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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