はじめに おはようございます、こんにちは、こんばんは、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

こんにちは、技術広報の yayawowo です。 今回は、 ラク スの開発組織メンバー達に 『2021年の気になったニュース』と気になった理由・ポイント を聞きました。 なお、昨年実施した内容もまとめておりますので、ご興味ありましたら是非 こちら をご確認ください！ 質問：皆さんの「2021年の気になったニュース」 を教えてください！ 目次 『2021年の気になったニュース』ランキング 1位：log4j ゼロデイ脆弱性 2位：みずほ銀行システム障害 3位：iOS15リリース 3位：GitHub漏洩 4位：NTTドコモ通信障害 4位：IE サポート終了 5位：Windows11 リリース 5位：PHP8.1 リリース 5位：Java17 リリース 5位：AlmaLinux リリース 5位：Apple AirTag 発表 5位：キャリアメール持ち運び 5位：Facebook 社名変更 5位：小説の続きを書いてくれるAI その他気になったニュース 終わりに 『2021年の気になったニュース』ランキング 以下は当社 ラク スの開発組織メンバーが選んだ『2021年の気になったニュース』ランキングです！ 調査概要 調査手法:任意アンケート( ヒアリ ングシート)※複数回答可 調査対象:当社開発組織メンバー(テッ クリード ・開発マネージャー含む) 調査項目:2021年12月22日迄のニュース 有効回答数:111回答 ランキング内容:得票数2票以上の2021年の気になったニュース 順位 ニュースタイトル(概要) 得票数 1 log4j ゼロデイ 脆弱性 12 2 みずほ銀行 システム障害 8 3 iOS15リリース 4 3 GitHub 漏洩 4 4 NTTドコモ 通信障害 3 4 IE サポート終了 3 5 Windows11 リリース 2 5 PHP8.1 リリース 2 5 Java17 リリース 2 5 AlmaLinux リリース 2 5 Apple AirTag 発表 2 5 キャリアメール持ち運び 2 5 Facebook 社名変更 2 5 小説の続きを書いてくれるAI 2 1位： log4j ゼロデイ 脆弱性 www.itmedia.co.jp ◆ ラク ス開発メンバーが気になった理由・ポイント 社内でもかなり盛り上がっていた話題です。 気になったニュース、これに持ってかれました。 噂になっていたのと、丁度ＷＡＦ触る機会があったので気になりました。 マインクラフトにも影響があったので我が家の子供も知っていた点で影響の大きさを実感しました。 ログ出力というきわめて基本的なライブラリに 脆弱性 が見つかったことで、多くのソフトウェアが影響を受けた印象です。ライブラリを正しく最新に更新している企業ほど影響を受け、EOLになったv1.xを使い続けていた企業は影響を受けなかったというのも何とも皮肉な話だと思いました。 　 などなど 2位： みずほ銀行 システム障害 www.jiji.com ◆ ラク ス開発メンバーが気になった理由・ポイント 超上流工程が与える影響の大きさを垣間見た。 体制云々の話はさておき、今後この巨大なプロジェクトをどう改善していくのかが気になります。 定期的に話題が上がり、中の人大変だろうなと思いました。 修正の目途が立ったのか気になります。 　 などなど 3位：iOS15リリース support.apple.com www.commerble.com ◆ ラク ス開発メンバーが気になった理由・ポイント ユーザ視点では嬉しい限りですが、サービスへの影響がすごそうだなと思いました。 セキュリティはもちろん大事ではあるが 開封 にしても Cookie にしても影響の大きさのわりに本来の課題の解決を実感できていないもどかしさはある。 業界に与える影響が大きいと感じました。 　 などなど 3位： GitHub 漏洩 news.yahoo.co.jp www.itmedia.co.jp ◆ ラク ス開発メンバーが気になった理由・ポイント 開発者の初歩的なミスによって甚大な被害が出たという内容に驚愕しました...。 もちろんそんなことはしないが、gitという意味では同じものを使っているので、そういうところは意識していかないとマズいと再認識させられた。 リモートワークが当たり前になって便利半面、企業セキュリティの抜け穴ができやすくなっているのかなと思いました。 今年で一番ヒヤッとしたニュースです。 　 などなど 4位： NTTドコモ 通信障害 japan.zdnet.com ◆ ラク ス開発メンバーが気になった理由・ポイント いかにNTTの通信網が広く普及しているのかが実感できました。 切り戻し時の作業で障害が発生したとのことで、１つのケースとして学びがありました。 通信 輻輳 (性能)の調査・テストはしっかりすべきだということが染みた。 　 などなど 4位： IE サポート終了 blogs.windows.com ◆ ラク ス開発メンバーが気になった理由・ポイント Microsoft は2022 年 6 月 15 日に IE のサポート終了を発表している点が気になりました。 ブラウザ互換性の面で開発者に苦労させてきた IE のEOL日程が、とうとう決まり感慨深いです。 フロントエンドエンジニアとしては IE 対応で苦しんだ経験があるので、時代の変わり目を感じました。 　 などなど 5位：Windows11 リリース www.itmedia.co.jp ◆ ラク ス開発メンバーが気になった理由・ポイント 早く使ってみたいですが、私の個人PCにはまだインストールできていません・・・。 個人的にはWindows10以前の無骨なデザインが好きでした。 　 などなど 5位：PHP8.1 リリース www.php.net ◆ ラク ス開発メンバーが気になった理由・ポイント ラク スが主催する技術イベントやブログでも話題になりました。 技術イベント PHP8.1 の新機能について語り合う PHP TechCafe 【PHP8.1リリース記念】PHPerのためのPHP8.1をもっと語り合うPHP TechCafe ブログ PHP8.1 の新機能について語り合う・前編【PHP TechCafe イベントレポート】 PHP8.1 の新機能について語り合う・後編【PHP TechCafe イベントレポート】 　 などなど 5位：Java17 リリース www.oracle.com ◆ ラク ス開発メンバーが気になった理由・ポイント Java17(LTS)が今年の9月にリリースされました。新しい機能だけではなく以前のバージョンよりパフォーマンスが良いということです。 Java 11から3年ぶりのLTSとなる Java 17がリリース。新しいライフサイクルポリシーのもと継続的に新しいバージョンがリリースされるようになったことは望ましいと言えるが、更新についていけない組織は辛そうだと思いました。 　 などなど 5位：AlmaLinux リリース codezine.jp ◆ ラク ス開発メンバーが気になった理由・ポイント CentOS7のサポート切れも迫る中、将来的にAlmaLinuxにお世話になるのかが気になってます。 ContOS8の代替先を見つけるのに苦労していた。 　 などなど 5位： Apple AirTag 発表 www.apple.com iphone-mania.jp ◆ ラク ス開発メンバーが気になった理由・ポイント 4個入りを買って持て余しています。 悪用されそうだなと思っていたので、 Android 対応も確かに必要と思いました。 　 などなど 5位：キャリアメール持ち運び iphone-mania.jp ◆ ラク ス開発メンバーが気になった理由・ポイント 妻にドコモメール持ち運びできることを教えてあげたら大喜び、結構キャリアメールに紐づけしていることが分かった次第です。 文字コード の影響がないか気になりました。 　 などなど 5位： Facebook 社名変更 www.businessinsider.jp ◆ ラク ス開発メンバーが気になった理由・ポイント GAFA の一角が メタバース に本腰を入れたことに驚きました。Oculusの新モデルに期待しています。 サマーウォーズ のような世界が実現するのかとワクワクしました。 　 などなど 5位：小説の続きを書いてくれるAI otona-life.com ◆ ラク ス開発メンバーが気になった理由・ポイント 既存の作品や登場人物なんかを入れると、うまいこと関連を出してくる。これを一人で作ったらしい。すごいです。 Twitter の趣味アカウントで盛り上がってました。結構自然な仕上がりになるのがすごいです。 　 などなど その他気になったニュース ラク ス開発メンバーが気になったニュースはランキング入りしたもの以外にも多くありました！ サイボウズ の“駆け出しエンジニア”向け研修資料が話題　Web アプリ開発 やIT文化の基礎を無償公開 www.itmedia.co.jp 「 Visual Studio Code 」がインストール不要に。 Webブラウザ で動作 pc.watch.impress.co.jp Flutter 2.0リリース developers.googleblog.com Remix、 OSS 化 remix.run AWS がデータ管理の改善を目的とした4つの新たなストレージサービスを発表 jp.techcrunch.com Scala3リリース www.scala-lang.org Docker Desktopが有料化へ www.itmedia.co.jp Amazon EKS Anywhereが正式リリース www.publickey1.jp 終わりに ラク ス開発メンバーが選ぶ『2021年の気になったニュース』はいかがでしたでしょうか？ 今回、開発メンバー達から100以上の回答がありました！ ラク スでは日常からビジネスチャットの中で、話題性のあった技術ニュースの見解を発信し、意見を募っているのを良く目にします。 改めて、開発メンバー達の関心の高さを感じました！ 最後になりますが、本内容が皆様の情報探索の一助となれば幸いです。 では、2022年も引き続きよろしくお願いいたします！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに こんにちは、弊社サービス「配配メール」の開発に従事している id:soachr （そーく）といいます。 以前は id:north_mky というユーザで投稿していましたが結婚を期になんとなくユーザを変えました。 ID の由来はとくにありません。 今回は、駆け出しエンジニアさん向けに「 オブジェクト指向 」を PHP でプログラミングしようと思います。 対象読者 オブジェクト指向 の実務イメージがわかない・しっくりきていない駆け出しエンジニアさん if/for/配列などは理解して実装できる カプセル化 ？継承？ ポリモーフィズム ？なにがいいの？と思っている 記事を読んでわかること オブジェクト指向 で書かれたプログラムの良さがイメージできる オブジェクト指向 の入門書を改めて読み返して理解を深められるようになる オブジェクト指向 、正直よくわからんってなっていませんか？ オブジェクト指向 は プログラミング言語 によらない概念の話なので抽象的でわかりづらいですよね。 今回、言語は PHP でわかりやすく説明していきたいと思います。 はじめに 対象読者 記事を読んでわかること 身近なあのシステムをオブジェクト指向で書いたら…? なぜブログを題材にしたのか ブログにはどんな要素があるか見てみましょう 1. 記事 2. できる操作 3. ユーザ オブジェクト指向でこれらをプログラムに変換していきましょう 記事クラス ユーザクラス オブジェクト指向の良いところ カプセル化 継承 ポリモーフィズム（多態性） おわりに 身近なあのシステムを オブジェクト指向 で書いたら…? なるべくイメージがつきやすい題材として今回は 今まさに見ている”ブログ”を オブジェクト指向 でプログラミングしていくことにします。 なぜブログを題材にしたのか BtoC, BtoB のサービスに問わず、システムによくある画面・機能があるからです。 すべて書きだすと記事の文字数がすごいことになるのと、かえって情報が多すぎてわかりづらくなるので割愛します。 よくあるシステムの画面・機能 ブログ 閲覧画面 記事の閲覧画面 閲覧画面／ユーザが操作できるボタンなど 記事に対する”いいね” 編集画面 記事の編集画面 ブログにはどんな要素があるか見てみましょう ブログってどんな要素があるでしょうか。考えてみてください！ 1. 記事 ぱっと思い浮かぶのは、ブログと言えば「記事」ですね。 記事 タイトル 本文 "いいね"するアイコン 2. できる操作 ではできる操作はなんでしょうか。色々ありますが、 よくある操作は以下ではないでしょうか。 記事を作成する 記事を公開する 記事を閲覧する 記事に”いいね”する 3. ユーザ ここまでで見える部分や、よく行う操作についてはわかりました。 でも、目には見えないけれど暗黙的にある情報があります。 たとえば、 「ユーザがログインをしているかどうか」 です。 ブログは世界中の人がログインしなくても見られますし、一方でログインしていても見られます。 でも、両者では”できること”が違いますよね。 ログインしていない人は、”いいね”というアイコンを押したとしても、”ログインもしくは新規登録してください”と表示されることが多いと思います。 といったように、 そのシステムはだれが使うのかという情報 があります。 ログインしているユーザ ログインしていないユーザ（システムからみたら、閲覧画面を利用者に提供しているのでユーザですね） ブログを構成する要素をみてきました。 では、これを PHP を使って、 オブジェクト指向 プログラミングをしていきましょう！ オブジェクト指向 でこれらをプログラムに変換していきましょう 前章でみた情報を PHP を使い、 オブジェクト指向 で書くと以下のようになります。 記事クラス <?php class Article { // 1. 記事 private string $ title ; // タイトル private string $ body ; // 本文 private array $ likes = [] ; // "いいね" // 2. できる操作 // 記事を作成する public function create () : void { $ this -> title = "" ; $ this -> body = "" ; } // 記事を公開する public function publish ( string $ title , string $ body ) : void { $ this -> title = $ title ; $ this -> body = $ body ; } // "いいね"を追加する(ここはあとで説明します！) public function addLike ( LoginUser $ user ) : void { array_push ( $ this -> likes, $ user ) ; } } まず、記事に関する情報とできる操作を class Article{} でひとまとめにしました。 実際のシステムのイメージをそのまま落とし込んだ ようになって見やすいですね。 情報と操作が別々にあると、操作に必要な情報がどこにあるか探すのがとても大変になります。 実務だとプログラムの行数がかなり大きくなったり、プログラムファイル数が数十〜数百いったりすることはよくあります。 ですので、 意味のあるまとまり にすれば楽に理解できたり、修正できたりします。 （このことを「 保守性が高い 」といいます） ユーザクラス 一方、ログインしている・していない人は以下のように class xxxxUser{} を書きました。 一見ややこしく見えますが、このあとで良さが効いてきます。 ポイントは以下の通りです！ ログインしているユーザ、していないユーザも記事に対して"いいね"する関数 addLike() を持っている ログインしているユーザは、プロパティに ID とユーザ名を持っている 逆にログインしていないユーザは、ブログに登録していないので ID とユーザ名は持っていない <?php abstract class User { abstract public function addLike ( Article $ article ) ; } // ログインしているユーザ class LoginUser extends User { private int $ id ; private string $ name ; public function __construct ( int $ id , string $ name ) { $ this -> id = $ id ; $ this -> name = $ name ; } public function addLike ( Article $ article ) { // 記事にいいねを登録する $ article -> addLike ( $ this ) ; } } // ログインしていないユーザ class TempUser extends User { public function __construct () { // ログインしていないので、IDやユーザ名を持ちません } public function addLike ( Article $ article ) { // ログイン画面へ遷移する処理 } } // "ユーザ"を作るだけのクラス class UserFactory { public static function create ( ? int $ id , ? string $ name = null ) : User { $ user = null ; if ( is_null ( $ id )) { // ログインしていないユーザを作る $ user = new TempUser () ; } else { // ログインしているユーザを作る $ user = new LoginUser ( $ id , $ name ) ; } return $ user ; } } オブジェクト指向 の良いところ ここまでで、なんとなく良さそう・でも周りくどい書き方では、など色々思うところがあると思いますが、 オブジェクト指向 の良さを以下のキーワードを通して見ていきましょう。 1. カプセル化 2. 継承 3. ポリモーフィズム （ 多態性 ） カプセル化 カプセル化 は クラスの内部情報や操作を外部から見せないこと を指します。 1 プログラム上ではアクセス修飾子が実現してくれます。 PHP ではそれぞれ以下の違いがあります。 2 public どのプログラムからも呼び出せる protected 定義したクラス自体、子クラス、親クラスであれば呼び出せる private 定義したクラス内でのみ呼び出せる 今までお見せしたプログラムでは LoginUser クラスでアクセス修飾子を実は使い分けていました。 ( コメントアウト の ①,②) <?php class LoginUser extends User { private int $ id ; // ① private string $ name ; // ① public function __construct ( int $ id , string $ name ) // ② { $ this -> id = $ id ; $ this -> name = $ name ; } // 中略 LoginUser クラスは他のプログラムから呼び出そうとすると、 public をつけいてるコンスト ラク タと addLike() 関数しか呼び出せません。 プロパティ $id , $name は呼び出せません。 直接 $id を書き換えるシーンを想像してみてください。 ユーザを一意に特定する ID を書き換えるシーンは、ほとんどないと思います。 繰り返しになりますが、実務で扱うシステムは規模が大きいことが多いため、 内部仕様を完全に理解し記憶することはほとんどできません。 もし public で定義したプロパティを色々なプログラムで呼び出すと、 不具合が発生して修正するときに、 呼び出されている箇所をすべて調査し、関連するすべての操作や画面の仕様を理解する必要があります 。 また修正した場合に、呼び出されている箇所ですべてに対して修正前と同じ挙動になっているかを確認しないと、もしかすると 二次被害 で別の不具合が発生するかもしれません。 度々不具合が起きてしまうと利用者への信頼を失ってしまいます。 そのため、なるべくクラスの外で呼び出せるプロパティ・関数は少なくする →呼び出す側は内部情報を知らない →つまり カプセル化 したほうが、 保守性が高い のです。 継承 継承はより簡単にいうと、”引き継ぐ”という意味です。 ブログはログインしているユーザ、そうでないユーザが存在しますが、ログインの有無にかかわらず「”いいね”をする」という操作が存在します。 このように、 役割や立場は多少違うけれど共通の操作や情報を持つ ときは、継承を利用します。 前の章のプログラムを見返してみますと、User クラスの addLike() 関数が LoginUser , TempUser クラスに引き継がれています。 ポイントは「継承先クラスは継承元のアクセス修飾子が private 以外のプロパティ・関数であれば、 必ず 引き継ぐこと」です。 必ずがキモで、逆を言えば継承先クラスは必ず継承元のプロパティ・関数を持っています。 逆に持っていなければ、エラーとなるような制約もあります。 3 これでなにが嬉しくなるかですが、 結論からいうと開発や運用（利用者が不便なく使えるようにシステムを動かし続けること）をする人がシステムを理解し、どうプログラムを修正すればよいかがわかりやすくなります。 実業務ではほとんどの場合は、 1 つのシステムを複数人で開発したり運用したりします。 人によってそのシステムに対する仕様の理解度はまちまちです。 ですが、残念なことに開発には納期が決まっているのです。 限られた時間の中で、より早く必要な分システムを理解しなければなりません。 そのときに継承が使用されていれば、以下のように早くシステムを理解できます。 継承元クラスの役割を知ると、継承先クラスの役割がだいたい把握できる 継承先クラスの理解は、継承元との差分だけを確認すればよい 追加で継承先クラスを作成するときに、必要な関数を考える手間や書く手間を省ける ポリモーフィズム （ 多態性 ） ポリモーフィズム は今まで書いてきた クラスを利用する処理（=業務ロジックといいます） で良さがわかります。 <?php /***** 業務ロジック *****/ // 記事の投稿 $ article = new Article () ; $ article -> create () ; $ article -> publish ( "ブログのタイトル" , "ブログの本文" ) ; // 中略 // "いいね"をする $ user = UserFactory :: create ( $ id , $ name ) ; // ログインしている場合はID,ユーザ名が渡される $ user -> addLike ( $ article ) ; "いいね"をする処理をみてください。 ポイントは new をする処理がないことです。 引数にキーとなる情報（今回で言えば $id ）を UserFactory::create() という関数に渡しているだけです。 業務ロジックは、具体的にどのクラスを new する必要があるのか考える必要がなくなります。 次には 2 行目 addLike() ですが、ログインしているかどうかで 実際に実行される処理は異なります 。 ユーザはログインしていれば"いいね"ができ、ログインしていなければログイン画面へ遷移する処理が実行されます。 ではなぜ ポリモーフィズム が実現できているかですが、それには 継承 が関わっています。 4 もう一度ユーザに関連するプログラムを見てみましょう。 コメントアウト している ①②③ を順に見てください。 ① で User クラスを継承すると、②で定義された User クラスの関数を、③で $user が どのクラスかを意識することなく使用することができます 。 <?php abstract class User { abstract public function addLike ( Article $ article ) ; // ② } // ログインしているユーザ class LoginUser extends User // ① { private int $ id ; private string $ name ; public function __construct ( int $ id , string $ name ) { $ this -> id = $ id ; $ this -> name = $ name ; } public function addLike ( Article $ article ) { // 記事にいいねを登録する $ article -> addLike ( $ this ) ; } } // 中略 // "いいね"をする $ user = UserFactory :: create ( $ id , $ name ) ; $ user -> addLike ( $ article ) ; // ③ この 「やること（いいねをするという操作）」は決まっているけれど実際にどのように「処理」が実行されるかは隠蔽されている （業務ロジックで知る必要がない） ことを ポリモーフィズム （ 多態性 ）といいます。 おわりに 今回の例のようにすべて一人で書く場合は、プログラムの全容を理解しているので旨味は分かりづらいですが、実務では存在するすべてのプログラムを理解する機会はほぼないです。（時間がいくらあっても足りません） それなのに、そのシステムを修正するには修正する箇所のプログラムを理解する必要があります。 本内容から オブジェクト指向 を使うことで、"楽"にシステムを開発・運用することができるイメージを持てれば嬉しいです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com カプセル化 は人によって色々な意味合いを持つため今回はフォーカスを絞りました ↩ 最近の プログラミング言語 にはだいたいあると思いますが、言語ごとに仕様が異なります。筆者は Java を先に学んでいたので PHP との言語仕様の違いに戸惑いました。 ↩ この表現は正確ではありません。理解のしやすさのために 予約語 abstruct に触れていません。 ↩ この表現は正確ではありません。理解のしやすさのためにこのように表記しています。より厳密に言えば ポリモーフィズム という概念は継承という概念を含む概念です。 ↩

こんにちは。 株式会社 ラク スで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（ @moomooya ）です。 ラク スの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「技術推進プロジェクト」 というプロジェクトがあります。 以前、社外の方にこの取り組みについて紹介した際に好意的な反応を得られたので、この場でも紹介してみようと思います。 取り組みの発端 これまでの軌跡 継続のための試行錯誤 割り込み作業対策 認知度向上 取り組みのサイクル 大まかな進め方 おわりに ――この取組のつらみ 成果が出るまで時間がかかる 知見がいくらあっても足りない 取り組みの発端 ことの発端――と言っても何か目立った事件が起きたわけではないのですが、今から4年前の2017年2月に当時の開発部長（現在は開発本部長）の提案で、社内で比較的経験の長いエンジニア達が集められました。そこで ラク スの開発組織として技術的なノウハウ蓄積についての課題が語られ、それらについて ブレインストーミング する機会が生まれました。 かれこれ4年前の話なので、どういった議論が行われたのか詳細な内容は記憶に残っていないのですが、 ビールとつまみを用意して議論していたことは覚えています 以下のような議論をしていました。 新サービス立ち上げ時に新しい技術を使おうとしても時間的に余裕がない 新サービス立ち上げ自体が高リスクなので、技術面でのリスクを取れない 技術刷新行っていかないとエンジニア採用滞りそう 古い技術だらけになったら社内のエンジニアもやめていきそう 個人で使った経験があってもプロダクションレベルでの利用がないとリスキーと判断されがち とはいえ実サービスでは問題が出ない限りコストメリットの見えない技術刷新の優先度低い これらのことは結構どこの会社でも同じように抱えている悩みなのかな、と思います。 こういう議論を何度か繰り返した結果、 「普段から少しずつ検証しておくしかない」 という結論に至りました。 経営層もこういった課題感（特に人事面の課題（採用の停滞、エンジニアの流出）が強かったのではないかと 1 2 ）を共有してくれていたということもあり、4人で週1回午後を検証に充てる（＝週5時間）取り組みが始まりました。 これまでの軌跡 2017年5月ごろから サービス横断で集められた3名 のチームでスタート このときの検証テーマは「マイクロサービスの導入是非」 2017年10月ごろから 更に2名参加 2018年下期の半年間は 新サービス 立ち上げのために一時休止 2019年上期から活動を再開 再開時の検証テーマは「 あいまい検索の実現方法 」だったが、検証データを用意するために副次的に「 データ匿名化 」が必要になり、 2テーマ並行して検証 することに これまでは1テーマずつの検証だった 検証チームが2つに分かれ、 3人1チーム で検証 【データ匿名化】 tech-blog.rakus.co.jp ・ 『全文検索の探求 Elasticsearch(1) 』: プロジェクト方針およびElasticsearch概要 ・ 大量データを検索するサービスでElasticsearchはRDBの代替候補になりうるか？ ・ データ匿名化 第1回：匿名化された個人情報とは何なのか ・ データ匿名化 第2回：個人情報は匿名化しても意味がないのではないか？ ・ データ匿名化 第3回：個人情報を匿名化するプロセス ・ データ匿名化 第4回：匿名化のために行うデータ項目の一般化とは ・ データ匿名化 第5回：データ匿名化の指標 ・ データ匿名化 第6回：実際の匿名化 【 機械学習 プロジェクトの進め方】 ・ 失敗しない機械学習プロジェクトの進め方入門 2020年4月にプロジェクトを運営する課として組織化 プロジェクト名も「技術推進プロジェクト」に改名 同時検証テーマ数が更に増え、 年間で7テーマずつ検証 を進行 検証チームの人数も 2, 3人と削減 【 機械学習 プロジェクトの進め方 続】 tech-blog.rakus.co.jp ・ 機械学習をコモディティ化する AutoML ツールの評価 ・ 機械学習モデルを組み込んだ Web アプリを Python 初心者が作ってみた 【サービス分割を見越した ドメイン 層設計】 ・ サービス分割に備えたモノリス（モジュラーモノリスとかアグリゲートとか） 【無停止リリース】 ・ 無停止リリース実現にむけていろいろ考えてみた（途中経過） ・ 無停止リリースを試してみた ・ サービスを止めずにアップデートを行う無停止リリース構成の検証 【モバイル クロスプラットフォーム 】 ・ モバイルクロスプラットフォームの技術検証 【GraphQL】 ・ GraphQLのアプリケーションへの組み込みを考える 2021年も継続的に技術刷新中 【静的解析】 tech-blog.rakus.co.jp 【 CSS プラットフォーム】 ・ PostCSSは開発標準ツールになるのか検証しました 【ユーザー認証】 ・ 認証規格まとめ 2021年版 - OpenID Connect & FIDO と OAuth 2.0 や SAML との違い 【ドキュメントDB】 ・ MongoDBについて調査・検証しました 継続のための試行錯誤 検証自体は 時間が与えられた 検証に必要な予算が与えられた 小規模なシステムを AWS 上で構築するために必要なくらいの予算 内部事情を把握しているエンジニア が揃っていたので、最初こそ手探りでしたが概ね順調に進んでいました。 割り込み作業対策 しかしこの手の従来業務と並行した取り組みは「従来業務の割り込みが増えて立ち消えになっていく」という展開はよくある話です。 本取り組みでも「ある程度経験のある現場のエンジニア」が参加しているため従来業務の割り込みが発生することは懸念されていました。 対策としては（当時はオフィスにも余裕があり会議室も確保しやすかったので）午後の5時間会議室を1つ占拠して自席から離れて作業するといった対策を取りました。 こういう話で「業務に影響でないの？」と心配される方もいるかも知れませんが、有休で休んだりすることを考えれば半日いなくても業務に問題が出ることはないんですよね。最初から毎週5時間いないことがわかっていればスケジュールもそれに合わせて引くだけです。 認知度向上 各所からの協力を得るために取り組み自体を認知してもらう工夫もしました。 成果を社内に還元する都合上、検証プロジェクトが社内で動いていることを知っていてほしいのですが、当初はプロジェクト名が決まっていないため「あの件」とか言われていたり、そもそもこういった取り組みをしていることも一部のメンバーしか知らない状態でした。 とりあえず取り組みに名前をつけようということで付いた名前が「 開 （ か ） 発の 未 （ み ） 来に 先 （ せん ） 手をうつプロジェクト（通称：かみせんプロジェクト）」 です。私が面白がって提案した名前がそのまま採用されました。 やはり 命名 というのは大事で、名前をつけたことで社内の開発部門以外（広報や人事の方や、製品企画の方）にも「かみせんプロジェクト」として取り組みが認知され、採用活動の惹きつけの際にも紹介してもらえるようになりました。 その後、運営する部署が出来たので部署名にあわせて「技術推進プロジェクト（通称：ぎすい）」と呼ばれるようになっていきます。 取り組みのサイクル 本取り組みは実際に検証を始める8ヶ月前から準備を行っています。 まずは先数年間に渡って会社として身につける必要がありそうな技術要素を 技術ロードマップ としてまとめます。これは各サービスで技術選定を担当している担当者に ヒアリ ングを行い、その結果を元に毎年更新しています。 技術ロードマップとしてまとめられた技術要素群はサービス開発の中で採用していけるのが理想ですが、すべてを即採用するというのは難しいです。 そこで各サービスの翌年度開発計画で扱われない技術要素を、技術推進プロジェクトの検証テーマとしてピックアップしています。 ピックアップされた検証テーマに必要な人員を見積もり、翌年度の人員稼働計画に組み込みます。 もしかしたら「随分準備に時間をかけているのだな」「こんなに準備に時間をかけてはコストがかかりすぎるのでは」と思う方もいるかも知れませんが、例えば突然各サービスのエンジニアの稼働を「来月から12%ほど（＝週5時間）捻出してほしい」と相談しても無理な話です。協力したくても出来ませんし、直接的に売上に直結するわけではない活動に直近の開発計画を曲げてでも参加させるというのは良くない選択です。 そのため弊社では、翌年度の計画を立てる段階で考慮してもらい、各サービスの機能開発を妨げないようにエンジニアに参加してもらうようにしています。 期間やコストはかかるやり方かもしれませんが、このようにした方が継続的に技術刷新を行うことができると考えています。 大まかな進め方 本プロジェクトは旗振り役として「技術推進課」という組織が存在しているものの、検証を行う主なメンバーとしては各サービスのエンジニアに横断的に参加してもらい、週5時間（＝約12%の人員稼働）を確保して検証を進めています。 先述の通り前年度から計画を立てて進めているので、各サービス開発チームから提供してもらう人的リソースはおおむね確保できた状態で検証を進めることが出来ています 3 。 このように時間をかけてでも「各サービスのエンジニアによる検証」にこだわるのは検証した成果をサービスに還元していくためです。検証のみをフルタイムで行う検証専任チームを作れば、検証時間の確保は確実に出来ますし、突発での検証テーマの組み換えも比較的容易になります。しかし、検証チームとサービス開発エンジニアが分離することで成果の共有や、取り組みの認知に課題が生まれます。 本プロジェクトのような先行検証の取り組みは成果が出るまで非常に時間がかかる取り組みです。 開発組織内の認知度や、成果の共有により生まれる有用性の認識がなければ、いつ廃れてしまってもおかしくはありません。実際に他社のエンジニアの方と話していると「過去に有志で取り取り組んでいたけどなくなっちゃった」といった声もよく聞きます。 検証成果がまとまってから実際に活用されるまでに年単位のタイムラグがあるので「成果発表」という形式には限界があります。しかし「経験者がチーム内にいる」という状況であれば（離職しなければ）チーム内にノウハウとして残りますし、必要となったときにノウハウを引き出してもらえます。 おわりに ――この取組のつらみ 成果が出るまで時間がかかる 4年前から種を蒔き始めて、最近少しずつ芽が出てきた感じです 4 。 扱うテーマ数を増やしたのは去年からなので、2年後くらいにはもっと成果が活用されていくのではないかな、と思っています。どうしても目に見える成果が出るのが数年後になってしまうのがこの手の取り組みの辛いところです。自分たちが取り組みの意義を信じて、各部署に意義を理解してもらって、粘り強く取り組んでいかなければなりません。 知見がいくらあっても足りない サービス拡大とともに検証すべき技術が増えていることもあり、取り組みの規模が大きくなっている事自体は良いのですが、旗振り役を担うメンバーが足りません。現在は旗振り役を担う技術推進課の実働メンバーは私を含めて2名（東京大阪1名ずつ）なので、東京大阪それぞれもう1人ずつ欲しいところです。 純粋に人的リソースが欲しいということもさることながら、知見の範囲が不足しています。 例えば、私の場合はこれまでのキャリアから要件定義、プロジェクトマネジメント、アーキテクト、フロントエンド、バックエンド、サービス運用とそれなりの範囲の知見はあるもののあくまで ウェブアプリケーション エンジニアとしてのキャリアが主軸なので、インフラやセキュリティに関する知識や勘所といったところにはあまり自信がありません 5 。社内のインフラエンジニアの方々に話を聞きながらなんとかやっていますが、不自由なくコミュニケーションできるレベルの実務知識はないと効率の悪さを感じます。 なので、アプリケーションもある程度理解しているインフラエンジニア経験がある人が「技術推進課」に参画してくれると助かるなぁ、と日々思っています 6 。 というわけで株式会社 ラク スでは一緒に働いてくれるエンジニアを募集しています。詳細はこの下の各種リンクからお願いします。カジュアル面談などで「この記事見て興味持ったよ」って言ってもらえると私のモチベーションが上がるかもしれません。 「技術推進プロジェクト」のこれまでの取り組みは、以下もご参考ください！ ◆ 技術 スペシャ リストへのインタビュー記事 career-recruit.rakus.co.jp ※2021/12/16時点での情報です。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 career-recruit.rakus.co.jp イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com 採用コストは直接的なコストでも1人あたり数百万かかりますし、ノウハウの蓄積という意味でも長くいてもらった方が効率が良くなるはず。 ↩ マザーズ に上場して1年ちょっと経って開発メンバーもちらほら入れ替わっていたというのもあるのかも。 ↩ 実際には障害対応であったり、サービスの開発プロジェクトが佳境を迎えていたりすると参加できない週があったりはしますが、多少は「仕方のないこと」として割り切っています。 ↩ 計測できていないものも含めれば「この技術は使わない」と判断する材料として成果を活用している事例もあるので結構ありそうですが。「当面の間はマイクロサービス化しない」とか。 ↩ 自宅でESXiサーバー運用したり、壁内LAN工事したりといったことはしているものの本職のインフラエンジニアのような実務に即した知識はたりません……。セキュリティ知識もテクニカルエンジニア（情報セキュリティ）（現 情報セキュリティスペシャリスト ）くらいは持っていますが本職の方がいてほしい……。 ↩ 知見の不足という意味ではモバイルアプリの知識や、AIとか ブロックチェーン の知識なども足りていないのですが、現状ではインフラ知識不足が一番の課題領域。 ↩

こんにちは。 ラク スインフラ部門にて従事しているas119119です。 ユーザ名に119という数値を2回使用しておりますが、特段意味はございません。 アルファベット順でaが1番目、sが19番目だったので、便宜的に使用しているだけとなります。 裏を返せば、asasasというユーザ名となるわけです。早速主題から脱線してしまいました。 今回、こちらのブログでは、 「仮想化について主観的に考えてみた」と題して、今後より一層の一般化・汎用化が想定される技術である仮想化について割と自由かつ奔放に考察 を交えて取り上げてみます。 今回のブログ構成は以下の通りとなります。 1. 仮想化について 仮想化の利点①／コストカット 仮想化の利点②／拡張性 仮想化の利点③／保守性 仮想化の利点④／柔軟性 仮想化の利点⑤／運用管理の負荷軽減 2.ラクスにおける仮想化についての現状 3.仮想化関連製品及びツール Nutanix Zerto Docker Kubernetes 負荷分散 死活監視 スケーリング 4.今後の仮想化活用にむけて 5.まとめ・総括 1. 仮想化について ここでは仮想化という概念について主観的な形で内容をまとめてみます。 新しい技術が次々と登場するICT業界において、比較的新規性があるような印象があるが息の長い技術ともなりつつあるのが 仮想化 ではないかと考えております。 仮想化とは、一般的にはハードウェアリソースを抽象化する技術であるとされています。具体的には、1台の物理的なサーバ内部のハードウェアリソースを論理的に分割し、複数の仮想サーバを同時に動作させることを可能とするものです。このことから、より規模の大きなサービスやシステムで積極的に活用されている技術の一つとなっています。 論理的という表現がやや抽象度が高い印象があるのですが、仮想化については端的には物理的な資源を別の資源であるように扱えるということで、実体を偽ることのできる技術だと考えることができます。 仮想化技術も複雑化してきており、その種類も ・サーバ仮想化 ・ネットワーク仮想化 ・デスクトップ仮想化 ・ストレージ仮想化 ・アプリケーション仮想化 などの複数の分類が可能となっています。 本稿では、最も一般的なサーバ仮想化を主として扱っていきます。 サーバ仮想化のイメージ※物理サーバ上で2つの仮想サーバが動作 では、仮想化の利点をいくつか挙げてみます。 仮想化の利点①／コストカット 仮想化技術を採用する利点はいくつかありますが、まずはコストのカットを挙げることができます。 物理サーバで構築していた場合でも、仮想化技術によって論理的な分割をすることで 仮想マシン を構築することができれば、活用されていないCPUやメモリなどのリソースを最適利用することができ、結果物理サーバ台数の減少につながり、最終的にはコストの削減につながると言えます。 仮想化の利点②／拡張性 次に拡張性があるという点です。 仮想化技術によって分割されたサーバに対し、必要に応じてCPUやメモリ、サーバ自体についても容易に追加や削除が可能となっており、柔軟かつ拡張性の高いシステムの構築を実現することが可能となります。 仮想化の利点③／保守性 待機させていたサーバへ稼働していたOSをオンライン状態で切り替えることによって、システムを継続させたままメンテナンスをすることが可能となります。 仮想マシン の実体はファイル *1 となるので、バックアップを作成し、当バックアップファイルから同じ仮想環境の復元が可能となります。 これによって同一機能を必要とする仮想OSを短い時間で大量にデプロイすることが可能となります。これを利用した技術としては、オートスケール機能を挙げることができます。 仮想化の利点④／柔軟性 サーバ構築作業が柔軟に可能となるという点も利点の一つとなります。 構築する際の 仮想マシン （ゲスト）のOSについては、必ずしもホストOSと同じにする必要はないということからも柔軟性の高い技術です。 仮想化の利点⑤／運用管理の負荷軽減 運用管理の観点からは、物理サーバを運用する場合と比較し、管理における負担が軽減されます。 例えば、従来の物理サーバで機材メンテナンスを行う場合には、システム停止の為に関係各所に調整、メンテナンス時間も深夜帯になることもあり得ます。 一方、仮想化環境で構築されたシステムのメンテナンスはそこで稼働している仮想OSをオンラインで別の物理機に移行できますので、特に事前の調整も必要なく、いつでもメンテナンスすることが可能となります。 仮想化技術に関して上記5つの利点を抽出してみましたが、システム構築を実現する上で検討する必要があるのは、コストであるのは間違いないと言えます。 仮想化実現のために必要なハードウェアやソフトウェアは有償である場合が多いと言えますが、小規模なシステム構築や安価な物理サーバでシステムを構築する場合には、仮想化を採用したことによって逆にコストが割高になってしまうこともあり得ます。 初期投資を抑えるためにサービスの立ち上げは クラウド を選択する会社も多数出てきています。 クラウド を選択した場合、そのままシステムが肥大化すると逆にオンプレミスのシステムの方が安くなる分岐点が存在します。 その分岐点に達した時にオンプレミスに戻す際は仮想化を選択することでよりリーズナブルにシステムを集約、低コスト化を実現できることも忘れてはならないポイントとなります。 仮想化として事実上の標準となっている VMware 社製品や追随する製品であると個人的には考えているNutanix社製品、 VMware の仮想環境ベースでの活用を可能とするZerto製品など、各社製品とのコラボレーションや仮想化技術をベースとした新しいサービスが続々と登場してきており、今後しばらくは仮想化技術の活用がより加速化していくのではないかと予想されます。 こちらについては、項目3のところで取り上げます。 2. ラク スにおける仮想化についての現状 現在 ラク スにおいては、旗艦製品と位置付けることができる楽楽精算を筆頭に楽楽販売、楽楽明細、楽楽勤怠といった楽楽シリーズ、メールディーラ等の多様な製品群を擁しております。 これらの製品群において、仮想化がメイン基盤となっている商材もあるようですが、一部の商材においては物理機での構築や運用を主としており、仮想化技術の導入についてはこれからという商材も存在します。 一方、販売増に伴いシステム規模が拡大している商材においては、運用コストの低減、メンテナンスの容易さなどを加味すると仮想化の検討や導入を行う動きはより推進されていくことが予想されます。 3.仮想化関連製品及びツール 仮想化技術において既に 業界標準 となっていると言える VMware 製品が導入候補として挙げられるかと思いますが、昨今、仮想化関連製品も多様化を極めている状況であると言えます。 ここでは 個人的に別のプロジェクトでも扱ったことのある製品をはじめ、仮想化を取り巻く製品群の一部について取り上げ、考察してみたい と考えております。 仮想化プロダクトとして既に一般化している VMware 製品や Hyper-V については、敢えてこちらで取り上げることは致しません。 現在の個人的な業務範囲内においても、深く扱っている技術や商品であるというわけではありませんが、過去に別のプロジェクトに参画した際に扱った製品もあり、仮想化技術を取り扱う際に重要な商品及び技術ではないかという認識を持っているので、個人的な経験も含めてここで取り上げておきたいと思います。 Nutanix Nutanixは、米国発祥の クラウド ソフト会社 として2009年からサービスを開始し、日本市場には2012年より 日商 エレクトロニクスによって導入が開始されました。 Nutanixという名前は製品名としても使用されており、最先端のハイパーコンバージドインフラスト ラク チャ（HCI：Hyperconverged-infrastructure）と呼ばれています。 ハイパーコンバージドインフラスト ラク チャ（HCI）においては、物理的なストレージ筐体を不要とし、複数サーバ上のストレージを仮想的な共有ストレージとして利用できる点が一つの特長となっており、仮想サーバやストレージ、付随するネットワーク等をまとめて管理できることから、シンプルな構成管理を可能としています。 個人的には複数のカタカナ用語を連結されると意味が把握しにくいイメージがあるのですが、仮想化ベースのITソリューション提供会社であり、より多くの機能を一括的な形で提供された仮想化製品となります。 実際、私自身が ラク スへ入社する前にNutanixの担当者とお話をする機会があり、そこで質問をしてみたのですが、Nutanix製品の実体は、 VMWare 製品と同じようなサービスやソリューションを提供しているものといった認識で概ね間違いないとのことでした。 提供されているサービスとして、まず挙げられるのが、Nutanixのハードウェアです。 サーバのようなものですが、ブロックという単位で区切った1ユニットまたは2ユニットサイズの筐体の中にノードを1台から4台まで収納できます。 筐体自体には電源ユニットとファンのみが搭載され、 ファームウェア アップデートの手間を省いている点 が特徴の一つとなっています。 Nutanixのハードウェアイメージ※2Uの筐体 ここでNutanix的観点から定義されているノードという表現が少々難解なのですが、 ブレードサーバ に格納する各サーバ単位のことを指すようです。 各ノードには仮想化されたCPUやメモリ、独自機能によってストレージ化されたディスクを 保有 しており、わずか2ユニットのスペースに仮想化基盤の構築が可能となります。 また、こちらのノードはオンラインでのスケールアウトが可能となっています。 ノード関連の特徴として、 RAID を採用しておらず、ノード単体での管理が可能 であるという点があります。 ノード単体が破損した場合でも稼働の継続ができ、ノードはオンラインでの交換が可能であり、さらには交換後に自動データコピーによる復元機能もあるので、高い可用性機能が実装されていると言えます。 次に、 ソフトウェアで制御できる範囲が広い点が特徴 の一つとなります。 CPUとメモリの仮想化機能、ディスクストレージ化機能、リソース一元機能など多様な機能をNutanixの専用ソフトで管理することができます。 ノードごとに仮想基盤を分散させることで、ノードの自由な拡張やバックアップによる可用性を確保できるなどの柔軟性が高い点は、大きな特徴であると言えます。 このことをSoftware-defined *2 と呼ぶそうですが、ここでも個人的にはあまり意味の理解が容易ではないのですが、要するにソフトウェアによってNutanixが管理する多様な機能をコン トロール するといったニュアンスであると理解しました。 各機能の管理については、 GUI 形式のPrismと呼ばれるコントローラによって実現されています。 Prismにおいては、 VMware vSphere Clientで確認するような要領で ダッシュ ボードが実装され、CPU使用率、メモリ使用率、ディスク使用率、IOPS、帯域、遅延状況などを 見える化 し、障害状況も一発で確認可能なようです。同様に 仮想マシン の作成、削除、バックアップ等の設定も可能となり、統合管理機能の一元化を図っていると言えます。 上記から、Nutanixに関しては、ハードウェア筐体のみならず仮想化実現ツールを含めてAll in oneで提供されているサービスであるということが大きな特徴となります。 基本は VMware の仮想化ソフトに似ているが、多様な機能の一元管理が可能となっており、その利便性から今後より一般化していくのではないかと予想しております。 Zerto Zertoは、2009年に米国はボストンにおいて創業された企業で、現時点ではHP社の傘下に入っています。 主力製品はZerto IT Resilience Platformと呼ばれるもので、主に仮想化基盤向けのDR *3 対策ソフトに強みを発揮しています。 個人的にも前職で 仮想マシン のシステム移行作業へ従事していた際に使用していたプロダクトでした。 他製品と比較してもユーザーフレンドリーなWebUIが印象的で、移行作業自体も失敗することは稀なケースと言えるほどで、パフォーマンス的にもかなり安定した製品でした。 主観的に言えば、 VMware 製品ベースでの使用が想定されているようにも見受けられます。 個人的にも間接的に聞いた話では、 VMware 社側からのZerto製品への評価も高いらしいとのことで、今後一層重要度が増すDR対策製品・サービスとして デファクト のプロダクトとして主流となっていくのではないかと予想しております。 Zerto製品の最大の強みは、とりわけ仮想化における仮想環境の レプリケーション 機能である と言えます。 これは、 プライベートクラウド 、ハイブリット クラウド 、 パブリッククラウド 上の異なるストレージ間や、異なるハイパーバイザー間でも レプリケーション が可能なことを売りにしていることからも伺い知ることができます。 前職で参画したプロジェクトにて扱った際にもサーバのハードウェア保守期限切れ対策として実施した マイグレーション 時に大きな効力を発揮しておりました。 Zerto主要機能の一つである Zerto Virtual Replicationの特徴 について取り上げたいと思います。 基本的な機能としては、仮想環境のレプリカ作成となります。 想定状況は多岐に渡るかと思いますが、例えば災害発生時などに仮想環境において稼働するサーバを素早く別のプラットフォームへ移行することで、サービス停止を回避する対策として用いられることが多いようです。 また、昨今、目に付くようになってきた ランサムウェア 対策としても有効性があるように見受けられます。 ランサムウェア によってサーバへのアクセスが制限された場合、 レプリケーション 機能を用いて仮想環境を復元することによって、データへのアクセスを可能とする手法も用途の一つとしてあるようです。 いずれにしても、サービス可用性の確保という昨今における最大の課題への対処製品としても有効なプロダクトと言えるのではないかと考えます。 Zerto一般情報によると、 レプリケーション 時には、 VMware vSphere、 Hyper-V 、 IBM Cloud（ベアメタル）、 AWS 、 Microsoft Azure間での利用ができ、異なる仮想環境間においてもプラットフォームに依存しない柔軟なデータの保護が可能となっているそうです。 実際には、 VMware vSphere上で使用するケースが多いのではないかと思いますが、多様な仮想環境下において互換性の高いサービスとなっています。 実際に VM の仮想化環境で利用したケースで考えると、ESXiホストにVRA *4 、vCenterへの紐づけが必要なZVM *5 のインストールが必要という状況でした。 これ以外には特に複雑な設定作業等は発生しなかったと記憶しております。 Zerto移行時のイメージ 次に、実際に参画プロジェクトにて実施したプラットフォーム間の移行作業について簡潔に触れてみたいと思います。 私が参画したプロジェクトでは、基本的に VMware 環境の 仮想マシン を別のESXiへ移行する際にZertoを移行ツールとして用いていたのですが、作業自体は通常2日間のスケジュール感で実施しておりました。 初日は、当時の現場では事前同期を実施する日として位置付けられ、ZertoにおけるVPGの作成日として設定されていました。 VPG（Virtual Protection Group）というのは、 リカバリ ーサイト（移行先）での復旧の単位であるとされています。 例えば、移行時に移行グループを作成して複数の 仮想マシン を分類し、まとめて処理できる機能があるようです。 ただ、私が参画したプロジェクトの現場では 仮想マシン のグルーピングはせずに、1台単位でVPGを作成して移行を実施しておりました。 その意味で、当時の現場では、VPG作成というのは単に本番移行実施前の事前同期を作成するといったものが一般的な認識となっておりました。 他方で、同日に複数のVPG作成が必要な場合もあり、1アカウントで6パラ（6チーム体制）にて6種類のVPG作成を実施した実績もありました。 しかしながら同時並行による影響のためか、VPG作成自体は問題なく完了しましたが、各VPG作成に当初の想定以上の時間を要したこともあったため、同じアカウントでの多数同時並行でのVPG作成作業は可能な限り避けるのが無難であると言えそうです。 ディスク容量の大きい 仮想マシン については、VPG作成が完了するまでに時間を要することが多く、午前中にVPG作成作業を実施、そのまま放置し翌日に作成が完了したことを確認するなどということもありました。 他方で容量が少ないものに関してはVPG作成も短時間で完了し、そのまま同日に移行作業自体を続行することも可能でしたが、顧客と移行スケジュールを調整済みとなるため、VPG作成日と本番移行日は別日で実施するのが通例となっておりました。 Zerto上での操作はVPG作成や本番移行を含めて基本的には全て GUI 形式のインターフェースで非常に操作が容易であった記憶があります。 プロジェクト内において通常は事前に設定値を記載したパラメータシートを仮想環境ごとに作成し、当シートを元に作業を進める形となっておりました。 蛇足ですがこのパラメータシートがかなりの曲者でして、入力項目が多岐に渡る上、移行対象が多数となる場合には、シート自体の デグレ や更新漏れ等が発生し、場合によっては移行当日にパラメータ内容を修正（レビュー済みであるにもかかわらず）といったこともありました。 状況によって柔軟に対応することも必要ということを痛感するとともに、Zerto製品の使いやすさによって設定値の間違いに気づけたことについても思い起こしました。 VPG作成時における設定値最終確認画面のイメージ VPG作成中のイメージ※State欄で進捗状況の確認が可能です 無事にVPGの作成が完了すると、翌日にはいよいよ本番移行を迎えます。 VPG作成自体は 仮想マシン を停止させる必要はなく、作成に何時間要したとしてもサービス停止は発生しないのですが、本番移行を実施する際にはサービス停止を伴います。 そのため、サービス停止の許容時間やマストのサービス再開時間を想定した上でスケジュールを立てなくてはなりません。 Zertoを利用した移行時では発生件数自体は僅かであった記憶がありますが、他方、他社製品を利用した移行時に移行先環境で正常に 仮想マシン を起動させることができず、結果ステップバックと呼ばれる移行前の状態への切り戻しが必要となる事態も発生しました。 その意味でZerto マイグレーション 機能は VMware 仮想環境の移行において相性がよく、移行作業時における安定性が高い印象を受けました。 本番移行については、同じくZertoの GUI 画面にて、下段の「Actions」から「Move VPGs」を選択します。 前提作業としては 仮想マシン の停止が必要となります。 この本番移行作業は前日に作成したVPGの実際の移行を行なうものとなり、前日のVPG作成時点からの本番移行作業における差分同期もセットで実施する形となります。 よって、通常はVPG作成後の翌日に移行を実施すれば同期すべき差分は最小で済み、実際の本番移行にそれほど時間を要しないため、VPG作成時点からMove VPGs実施までの間隔は可能な限り短縮すべきであると言えます。 VPG作成からMove VPGs実施までに何日も空いてしまうとそれだけ多くのデータ差分が発生するので、本番移行作業も時間がかかってしまう結果となるためです。 本番移行実施イメージ 無事に本番移行作業が完了すると、移行先の環境にて 仮想マシン がパワーオンの状態で立ち上がってきます。 その後は新環境に合わせて ネットワークアダプタ の修正を含む各種設定変更を実施し、旧環境からの移行が完了となります。 Zerto製品は非常にシンプルかつ安定性があり、障害発生が少なく高いパフォーマンス性能を備えたプロダクトとして、またDR対策製品としても、今後普及が加速化していくのではないかと予想しています。 Docker Dockerは、コンテナ型仮想化の代表的なソフトで2013年に登場しました。 一般的にはコンテナの実行やコンテナイメージの作成や配布を実行するためのプラットフォームであるされています。 コンテナ自体はOS上で実行されているプロセスのことを指し、それゆえOS上で共有されることになるため、OSのバージョン等による差分が発生した場合に動作しない等の影響を受ける場合があります。 コンテナ型とは、サーバ仮想化の一類型のことで、アプリケーションと実行環境をひとまとめにし、OS単位ではなくアプリケーション単位で仮想化を実現する仕組みのことを指します。 仮想マシン やゲストOSが不要となるというメリットがあり、ホストOS上にコンテナ型仮想化ソフトウェアをインストールすることでコンテナ同士を組み合わせて使用することも可能となります。 コンテナ型仮想化のイメージ※ゲストOS不要 一般的にデータはコンテナに含めないことで使用されることになるため、アプリケーション用のコンテナを破棄してもデータ自体が喪失することはなく、新しいコンテナを作成することでデータの継続的な使用が可能となります。 Dockerはコンテナ技術の デファクトスタンダード ツールであるとされ、設計思想としてユーザーファーストを掲げている通り、一般的には使用しやすいというフィードバックも多いようです。 その理由としては、オンプレミスから クラウド への移行が容易であったり、高い可用性及び有用性からアプリケーションを開発しやすいプラットフォームである点が挙げられています。 また、Docker Hubと呼ばれるライブラリのようなアプリケーション導入済みのコンテナイメージを集めたサービスも豊富に提供されており、必要なコンテナは容易に入手可能となっています。 Docker Hubについてですが、これはDocker社提供のコンテナ レジストリ サービスのことであり、ここからコンテナイメージの取得及びソフトウェア実行が可能となっています。 コンテナ レジストリ というのは、Dockerにて使用するコンテナイメージの保管および配布を担う構成要素のようなものとなります。 上記の通り、コンテナはその実体はプロセスであるがゆえ、プロセスごとにコンテナを分類することが推奨されています。 これは、分類することによって、負荷分散によってパフォーマンス低下の改善や共有プロセスへ同時にアクセスすることによる競合状態の発生回避にも寄与できるためであるとされています。 他方、コンテナが分類されることでシステムによっては増加した複数コンテナの管理が複雑かつ困難となったり、1つのシステムにパッチ適用をする場合などに、コンテナごとに対応が必要になったりするなどの煩雑さが発生するというデメリットもあります。 増加し過ぎたコンテナ管理の問題に対応するために、Swarm modeと呼ばれる クラスタ 管理機能も備えています。 Swarm とは日本語で言うところの「群れ」のことであり、Swarm modeで有効・無効を選択し、有効とされたノード群を クラスタ としての集合体として管理することが可能となります。 Web系システムのコンテナイメージ コンテナの管理については、コンテナの作成や削除による方法がありますが、削除する際には注意が必要となります。 コンテナ自体を削除すると、コンテナ上のデータも消えてしまうためです。 対処方法としては。Dockerに備えられた「ボリューム」と呼ばれる機能を使用することが考えられます。 ボリュームというのは、Dockerが管理する ディレクト リのようなものであり、通常の ファイルシステム と同様に名前での管理が可能であり、複数コンテナにデータを配布するなどのマウント機能も備えています。 またこのボリューム機能を使用すれば、複数コンテナでの ファイルシステム 共有も可能となります。 Dockerの機能の一つとして、コンテナを実行するためのテンプレートであるコンテナイメージの中にある ファイルシステム に「差分管理」という仕組みがあります。 これは、マスター的な情報がベースとしてあり、そのマスターとの差分点を記録することによって変更内容を管理する手法であり、これによりファイルの高速なデプロイを実現しています。 Kubernetes Kubernetes はDockerと同様にコンテナ型の仮想化ソフトの一種として、Dockerより1年遅れの2014年に登場しました。 開発したのは Google 社であるとされています。 なお、 Kubernetes というのは ギリシャ 語で「操縦士」という意味があるそうです。 コンテナ オーケストレーション ツール *6 とも呼ばれている通り、コンテナの指揮が可能ということで、自動化することによってコンテナの管理及び運用を容易化するものとされています。 コンテナの運用管理における必要な作業としては、 負荷分散、死活監視、スケーリングの3種類 を挙げることができます。 負荷分散 負荷分散については、複数コンテナがある場合に特定のコンテナへのリク エス トが集中しないようにする処理のことを指します。これにより処理時間の短縮や単位時間あたりに処理可能なリク エス ト数を増加させ、システム性能向上へ寄与します。 死活監視 死活監視については、コンテナが正常に稼働しているかを確認及び監視する機能のことを指します。 死活監視の方法としては、各コンテナへリク エス トを送信し、返答の有無を確認する手法があります。返答がある場合には正常稼働していると判断できるため、 Ping 疎通確認のようなものと同様であると言えます。 スケーリング スケーリングについては、コンテナへのリク エス トの規模に応じてコンテナ数を増減させることを可能とする機能です。 例えば、CPUやメモリ等に 閾値 を設定し、ある基準を超える場合にはコンテナを追加するといったような設定が可能となります。 Kubernetes がコンテナ管理をする上で、最小となる単位のこと「Pod」と呼びます。 1つのPod内では複数のコンテナ起動が可能となります。この複数のコンテナ起動管理を可能とするのが、 Kubernetes の特徴の一つであると言えます。 他方で、同じタイミングでの起動が必要ではないコンテナは別のPodで管理するのが効率的であるとも言えます。 また、各Podをグループ化して管理する単位のことを「レプリカセット」、レプリカセットをグループ化して管理する単位のことを「デプロイメント」と呼びます。 Pod、レプリカセット、デプロイメント対応関係イメージ Kubernetes のコンテナへのアクセスを実現するのは、「サービス」という機能です。 サービスは、コンテナへアクセスするためのエンドポイントを提供する役割を担っています。 エンドポイントは仮想の IPアドレス を持っており、当仮想 IPアドレス へアクセスすることで、エンドポイントにてコンテナの仮想 IPアドレス への変換が行われ、コンテナへのアクセスが可能となります。 エンドポイントはいわば、各コンテナへのアクセスの仲介を行なっている機能であると言えます。 また、サービスには負荷分散の機能も実装されています。 ラウンドロビン 方式で各Podへのパケット転送をサービスが制御することで、負荷を分散し、サービス可用性を高めています。 Pod内に複数のコンテナを 保有 している場合、コンテナ間の通信は localhost にて可能となります。 他方、Pod間通信にはPodに割り当てられた一意の仮想 IPアドレス を介して実行されます。 コンテナという手法に関しては、仮想化技術の中でも比較的新しい範疇に分類されるのではないかと思います。 Dockerが誕生してから僅か1年後に管理機能を向上させるように Kubernetes が登場してきたように非常にスピーディなペースで次々と新たなものが開発されてきている分野であるという印象を持っており、今後、更にコンテナの進化版のような技術が登場することになるのではないかと予測しております。 4.今後の仮想化活用にむけて 今後、仮想化環境をメインプラットフォームとする方向性へシフトしていく可能性は十分にあり、むしろかなり高い確率でそうなっていくのではないかと予想しております。 運用面で考えると本質的には物理環境と仮想環境で大きな差分はなく、仮想サーバが1台でもあれば、オンプレミスと近い運用設計が必要となります。 オンプレミスでの運用管理方法をそのまま再利用とまではならないまでも、これまでの運用方法を参考にしながら仮想化環境の運用方法を再設計することも可能となるのではないかと考えます。 コスト的な観点では物理サーバに対して仮想サーバが安価であることは一般的な共通認識であると言えます。 他方で、安価な物理サーバを利用した運用を実施する場合、必ずしも仮想サーバが常に優位な選択肢であるとは限らない場合があるというのも事実です。 仮想化導入時に プロプライエタリ な製品等の導入を選択肢とする場合、費用対効果を含め多様な視点から比較したうえで仮想化技術を導入すべきなのかを検討することが重要です。 パフォーマンスの安定性を考慮する場合は仮想化技術の導入を無思慮に推進するよりも、物理サーバでの安定した性能を追求する手法も一つの手段です。仮想化を推進する際、オンプレミスなシステムと性能を比較した場合、性能はオンプレミスよりも劣る場合があることは考慮が必要な点となります。 パンデミック など、昨今の予想できない事態の発生に備え、リモートワーク等を含めて遠隔で操作するVDI、 リモートデスクトップ の仮想化といった手法の採用も一般化しています。 その潮流の一環として、仮想化技術の活用も有効な選択肢の一つとなっていくのではないでしょうか。 5.まとめ・総括 いかがでしたでしょうか。 ここまで仮想化について個人の主観的な視点に依拠して奔放闊達な形で考えてみた内容を記述してきました。 仮想化の デファクトスタンダード とされる VMware 社製品のみならず、 VMware 製品と類似する機能を強化してAll in oneとリニアにスケールする性能を提供するNutanix製品、 VMware と合わせて利用されることで効果を発揮すると思われるZerto移行ツールなど、ソフトウェアの形態も多種多様に変化してきていると言えます。 それほど昨今の技術進化のスピードは著しく、ICT業界従事者としては常に動きをウォッチすることが求められていることには変わりなく、この風潮は一層加加速化しうると言うこともできるかと思います。 仮想化技術自体は一定の市民権を獲得しているようにも思われ、とりわけ VMware 製品が築いた牙城はそう簡単には崩壊しないのではないかとも言えます。 Nutanix製品が仮想化製品として VMware 製品にとって代わることがあれば、個人的には興味深いことであると思っております。 新しい技術や製品は最初に開発した事業体が大きなシェアを占めることになるのは明白であり、どれほど模倣に長けた企業であっても二番煎じの位置から秀でるのは容易なことではないと考えられます。 それを踏まえると、標準化された製品をベースに如何に更なる利便性を高めて、付加価値のあるサービスを提供できる技術、とりわけ クラウド との連携によるハイブリットDC化が次の動向となっていくのではないかと思われます。 仮想化関連技術に関して言えば、前述したZerto製品のように今後は仮想化技術とその他商品とのコラボレーション的な活用方法も、仮想化技術の主流の一つとなっていくのではないかと予想しております。 当ブログを最後まで読んでいただき、ありがとうございました。 ◆ 関連する求人情報はこちら！ ・ インフラエンジニア／マネージャー（東京） | 株式会社ラクス ・ インフラエンジニア／マネージャー・管理職（大阪） | 株式会社ラクス ・ インフラエンジニア[東京/楽楽明細] | 株式会社ラクス ・ インフラエンジニア（大阪） | 株式会社ラクス ・ インフラエンジニア[東京/楽楽労務] | 株式会社ラクス ・ SREエンジニア[東京/インフラ] | 株式会社ラクス ※2021/12/15時点での情報です。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com *1 : 一つのファイルとしてパッケージ化して扱うことを カプセル化 と呼びます *2 : 「ソフトウェア的に定義」といった意味合いになる認識です *3 : Disaster Recovery：災害時におけるシステム復旧の仕組みや体制のこと *4 : Virtual Replication Appliance： レプリケーション に必要なエージェントのようなもの *5 : Zerto Virtual Manager： レプリケーション 管理用のソフトウェア *6 : コンテナの管理運用を自動化するツールという意味合いがあります

注意 カスケードレイヤーは正式実装の機能ではないため、これから仕様変更の可能性があります。 目次 注意 目次 はじめに カスケードについて Origin and Importance Context Specificity Order of Appearance カスケードレイヤーについて The Style Attribute Layers 従来のCSS カスケードレイヤーの記述方法について 複数レイヤー 使用例（リファクタリング） 修正前のコード リファクタリングの準備 FLOCSS化 リファクタリング後 カスケードレイヤーをブラウザで使う方法 Windows Mac 注意 最後に 参考 はじめに こんにちは、フロントエンドチームのta_kameです。 今回は、今後実装されるかもしれない CSS の新機能カスケードレイヤー（ Cascade Layers）について紹介します。 CSS 設計では詳細度をなるべく均一に保つよう行いたいですが、 レガシー案件であったり、 サードパーティー の CSS が導入されている案件だと、 なかなか管理が大変です。 そこで紹介したいのがカスケードレイヤーです。 カスケードについて そもそもカスケードとは何か、ということになりますが、簡単に言うと、スタイルを適用するための優先順位のルールをまとめたものになります。 CSS ファイルを複数読み込んだり、同 CSS ファイル内でも複数箇所で書かれていたり、そういった場合どのスタイルが適用されるのか…ということです。一番よく気にする機会は詳細度かもしれません。 詳細度以外ではとくに意識することは少ないかもしれませんが、カスケードレイヤーについて紹介する前にまずは現在の仕様について確認してみます。 現在の CSS が適用される優先順位を決めるためのカスケードのルールはこちらです。 Origin and Importance Context Specificity Order of Appearance 英語の記述をそのまま引用してきたために、このままではわかりづらいので、1つずつ説明します。 Origin and Importance Originとはユーザーエージェント スタイルシート 、ページ作成者 スタイルシート 、ユーザー スタイルシート など、スタイルがどこで宣言されているかを示しています。 そしてImportanceとは CSS に記述する!importantのことです。 Origin and Importanceとはそれらの組み合わせの優先順位によるもので、下記の優先順位で適用されます。 トランジション ユーザーエージェント (!important) ユーザー (!important) 作成者 (!important) アニメーション 作成者 (通常） ユーザー (通常） ユーザーエージェント (通常） Context ContextとはShadow DOMなどのネストされたコンテキストの優先順位です。 異なる カプセル化 されたコンテキストからの宣言では、下記のルールで優先されます。 通常：外部コンテキストからの宣言が優先 important：内部コンテキストからの宣言が優先 言い換えると通常の宣言同士であれば外側から容易に書き換えることができるが、内側のimportantは外側からは書き換えられないということになります。 Specificity 詳細度による優先順位です。 ID セレクタ ーや要素 セレクタ ーなどの種類や数によって、一番詳細度の高い宣言が優先されます。 Order of Appearance 宣言が登場する順番による優先順位です。 ドキュメントの後ろの方で登場した宣言が優先されます。 カスケードレイヤーについて カスケードレイヤーが実装された場合のカスケードのルールは下記の通りになります。 Origin and Importance Context The Style Attribute Layers Specificity Order of Appearance The Style Attribute style属性の優先順位です。 現在style属性は Order of Appearance内 で定義されており、すべての スタイルシート のあとに宣言されるとされています。 カスケードレイヤー実装のタイミングではわかりやすく、 独立 となるようです。 Layers カスケードレイヤーは 新設 で配置されます。 カスケードレイヤーにより詳細度や登場順の影響を受けることなく、制御ができることになります。 従来の CSS 従来のカスケードのルールとカスケードレイヤーが実装された場合の違いを確認したところで、まずは従来の CSS のサンプルコードを紹介します。 < main id = "container" > < div class = "block" > < p class = "text" > カスケードレイヤー </ p > </ div > </ main > # container . block . text { color : blue ; } p { color : red ; } 大げさに詳細度を高めていますが、こちらは当然テキストのスタイルは 青 です。 カスケードレイヤーの記述方法について それではカスケードレイヤーを使用してみましょう。 具体的な記述方法ですが、@layerのあとに好きなレイヤー名をつけて、その中にスタイルを書いていくだけです。 @layer main { # container . block . text { color : blue ; } } p { color : red ; } color:blueの方が詳細度は明らかに高くみえますが、テキストは 赤 です。 つまり レイヤー化されていないスタイルが一番強くなります 。 詳細度がいくら高くても関係なく、レイヤー順の方が優先されます。 複数レイヤー レイヤーは複数記述することも可能です。 先にレイヤー名を宣言しておくと、順番を並び替えるだけでスタイルが適用されるので、より管理が楽になります。 @layer main ; @layer second; @layer main { # container . block . text { color : blue ; } } @layer second { # container . block . text { color : green ; } } 最初の宣言で@layer secondが後に宣言されているので テキストは 緑 です。 ここでmainレイヤーとsecondレイヤーの宣言を逆にしてみます。 @layer second; @layer main ; @layer main { # container . block . text { color : blue ; } } @layer second { # container . block . text { color : green ; } } すると、この場合のテキストは 青 になります。 現在mainレイヤーがあとに宣言されているのでmainレイヤーのスタイルがあたっています。 もしmainとsecondの別々のレイヤーで詳細度がそれぞれ異なる場合はどうなるでしょうか。 ためしにmainレイヤーの詳細度を下げてみます。 @layer second; @layer main ; @layer main { p { color : blue ; } } @layer second { # container . block . text { color : green ; } } 少し違和感があるかもしれませんが、 この場合でもテキストは 青 になります。 詳細度よりとにかくレイヤー順の方が優先されます。 使用例（ リファクタリング ） ※ リファクタリング 後の CSS は後述する起動オプション付きでブラウザを実行しないとスタイルが適用されませんのでご注意ください。 それではカスケードレイヤーはどのような場面で活躍するか…今回はカスケードレイヤー設計の観点で考えてみます。 たとえば、既存プロジェクトで大きな CSS ファイルがあるとします。 ファイルを分割したいと思うのですが、まずは1ファイル内で安全に行うべく、カスケードレイヤーを使用して リファクタリング を試みます。 そこで多少ひどい CSS をここに用意しました。 修正前のコード こちらのHTMLと CSS を使って、 CSS の リファクタリング を行っていきます。 リファクタリング の準備 まず、今回機能として紹介していませんが@importで CSS 内に別の CSS を読み込むことができます。 @import はすでに 実装済 みの機能ですが、カスケードレイヤーと組み合わせると名前付きでimportが可能となります。せっかくなのでHTMLでは1つの CSS を読み込むようにして、名前付きimportしてみます。 そして、いったん リファクタリング 用のレイヤーに既存の CSS をすべて入れます。 余談ですが、 CSS の@importはパラレルロードではないため、 CSS 設計を考える段階でSassの導入を検討してみてもよいかもしれません。今回はあくまでPureCSSということを前提としています。 @import url( https://cdnjs.cloudflare.com/ajax/libs/normalize/8.0.1/normalize.min.css ) layer(normalize); @layer refactoring { body { font-size : 16px ; } # header { padding : 20px ; } # header . logo { height : 50px ; width : 200px ; background-color : blue ; color : #fff ; display : table ; } # header . logo span { vertical-align : middle ; display : table-cell ; text-align : center ; } . headline1 , . headline2 , . headline3 , . title { font-weight : bold ; } h4 . title { font-weight : 500 ; } . container { padding : 16px ; } . container . list { list-style : circle ; } . container . list . item { letter-spacing : 1px ; } . container . list . item : nth-child( 2 ) { color : red ; } . container . box { display : flex; flex-wrap: wrap; } . container . box . media { padding : 8px ; margin : 4px ; width : calc( 50 % - 8px ) !important ; box-sizing : border-box ; background-color : yellow ; } . container . box . media . img { width : 100 %; height : 100px ; background-color : green ; } } FLOCSS化 ここからFLOCSS化します。 まずはHTMLにクラスを付与するのですが、ためしにlist部分へ手を入れます。 < h2 class = "headline1 c-headline1" > LIST </ h2 > < ul class = "list c-list" > < li class = "item c-list__item" > HTML </ li > < li class = "item c-list__item c-list__item--em" > CSS </ li > < li class = "item c-list__item" > JavaScript </ li > </ ul > クラスを足しただけなので、何も変わりません。 そこにカスケードレイヤーを足します。 @layer c-list; /* ① */ @layer refactoring; /* ② */ @layer refactoring { ... } @layer c-list { . c-list { list-style : circle ; } . c-list__item { letter-spacing : 1px ; } . c-list__item--em { color : blue ; } } 試しにc-list__item--emへcolor:blueのスタイルを適用させようとしていますが、 現在の状態はrefactoringレイヤーの方があとに宣言されているので結局何も変わりません。 何も変わっていないことが確認できたので、①と②を入れ替えます。 @layer refactoring; /* ① */ @layer c-list; /* ② */ c-listレイヤーのスタイルが適用されました。 うまくいっているので、同様に切り分けながら リファクタリング を進めます。 どこまで分割するかという問題があるかもしれませんが、今回は以下のようなコードになりました。 リファクタリング 後 ※後述の起動オプション付きでブラウザを実行しないとスタイルが適用されないのでご注意ください。 1つの css ファイル内で分割が完了しました。 ここからファイルを分割していき、@importを使用して読み込むようにすれば完成となります。 カスケードレイヤーをブラウザで使う方法 使い方ですが、現在実験的機能のため Firefox Nightlyか Google Canaryでしか試すことができません。 起動オプションを設定して実行すると使えるようになりますのでご紹介します。 Windows Windows はショートカットのプロパティに起動オプションを追加して実行するだけで使えるようになります。 "C:\Users\username\AppData\Local\Google\Chrome SxS\Application\chrome.exe" --enable-blink-features=CSSCascadeLayers 画像のように「サポートされていない コマンドライン フラグ --enable-blink-features=CSSCascadeLayersを使用しています。 これにより安全性とセキュリティが損なわれます。」と表示されていたらカスケードレイヤーが使えるようになっています。 Mac Mac の場合はターミナルから起動します。通常起動は下記コマンドで実行できます。 open -a /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary こちらに起動オプションを追加して実行します。 open -a /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --args --enable-blink-features=CSSCascadeLayers Windows と同様にメッセージが表示されていればカスケードレイヤーが使用できるようになっています。 また、毎回コマンド入力するのは手間なので、よく使う場合は Automator の設定を行います。 Automator はLaunchpadから起動できます。 「 シェルスクリプト を実行」から、起動オプション付きのコードを貼り付けます。 完了しましたら、メニューバーより「ファイル」→「保存」を選択して保存します。 この時フォーマットは「アプリケーション」としておきます。 これで次回以降はアイコンをクリックするだけで起動オプション付きの Chrome Canaryが実行できます。 注意 開発者向けの機能のため、ブラウザが意図しない挙動をするかもしれないので、使用についてはあくまで機能の確認程度に留めていた方がいいかもしれません。 最後に 今回はカスケードレイヤー(@layer)について紹介しました。 まだ実験的機能としてですが、カスケードレイヤーが CSS 設計や リファクタリング で活躍する日がくるかもしれません。 Sassのような記述ができる CSS ネスティングや、条件分岐ができるwhenなど、 CSS には他にも実装が期待されている機能はたくさんあります。 興味のある方はぜひ調べてみてくださいね。 参考 Cascade Layers? - CSS-Tricks The Future of CSS: Cascade Layers (CSS @layer) – Bram.us CSSのCascadingに追加されようとしているLayerという概念 CSS Cascading and Inheritance Level 4 CSS カスケード入門 - CSS: カスケーディングスタイルシート | MDN Takao Kamenoue エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは、技術広報の yayawowo です。 Windows の真っ黒い画面、「 コマンドプロンプト 」を聞いたこと・触ったことはありますでしょうか？ 中々触る機会が少ない方にとっては、抵抗のある画面ですよね…。 今回は、そんな抵抗をお持ちの方に向けに、 「 コマンドプロンプト 」について起動方法や基本的なコマンドをまとめさせていただきました！ コマンドプロンプトとは？ コマンドプロンプトの起動方法 プロパティの設定 オプション フォント レイアウト 画面の色 ターミナル 基本的なコマンド一覧 ファイル・ディレクトリ操作 実行結果例 OS操作 実行結果例 ネットワーク操作 コマンドプロンプト まとめ コマンドプロンプト とは？ コマンドプロンプト は、 Windows 上の「 コマンドプロンプト 」の画面を起動し、 「コマンド」と呼ばれる命令文を入力して操作するものです。 通常マウスを使って操作しているものを、キーボードを使って操作するインターフェースです。 ちなみにこれを CUI （Character User Interface ）とも言います。 後程、基本的なコマンド一覧をまとめておりますので実際にご自身のPCで操作を試してみてください！ コマンドプロンプト の起動方法 では早速、 コマンドプロンプト の起動方法についてご説明します。 コマンドプロンプト を起動する方法は、4通りありますので使いやすい方法をお選びください！ ① アプリ一覧から起動 ■ デスクトップ左下のスタートボタンをクリック ■ [ Windows システムツール]から[ コマンドプロンプト ]をクリック ■ [ コマンドプロンプト ]が起動 ② 「ファイル名を指定して実行する」から起動 ■ デスクトップ左下のスタートボタンをクリック ※[ Windowsキー ]＋[R]キーにて、「ファイル名を指定して実行」ダイアログを表示することも可能です。 ■ [ Windows システムツール]から[ファイル名を指定して実行]をクリック ■ ダイアログが表示されたら、[cmd]と入力 ■ [ コマンドプロンプト ]が起動 ③ 検索ボックスから起動 ■ デスクトップ左下の検索ボックスに[cmd] or [ コマンドプロンプト ]と入力 ④ ショートカットキーで起動 ■ [ Windowsキー ]＋[X]キーにて表示したダイアログから、[ コマンドプロンプト ]を起動 プロパティの設定 次に、 コマンドプロンプト のプロパティについて説明します。 ここでは、「オプション」「フォント」「レイアウト」「画面の色」の設定を変更することが可能です！ まず、[" コマンドプロンプト "のプロパティ]を以下の手順で開きます。 ■ [ コマンドプロンプト ]画面の左上にあるアイコンを右クリック ■ [プロパティ]をクリック オプション 【 出来ること 】 ・カーソルのサイズ　：カーソルの大きさを小/中/大に変更可能 ・コマンドの履歴　　：バッファーサイズ/バッファー数、古い履歴の破棄の設定 ・編集オプション　　：デフォルトは全てチェックが入っている状態 ・テキスト選択　　　：行の折り返し/テキスト選択キーの拡張設定 ・現在のコードページ： 文字コード の確認が可能 フォント 【 出来ること 】 ・サイズ　：サイズの変更 ・フォント：フォントの変更 レイアウト 【 出来ること 】 ・画面バッファーのサイズ：画面全体のバッファーサイズの変更 ・ウィンドウのサイズ　　：ウィンドウサイズの変更 ・ウィンドウの位置　　　：起動時の表示位置が設定可能 画面の色 【 出来ること 】 ・以下項目の色が変更可能 　- 画面の文字 　- 画面の背景 　- ポップアップの文字 　- ポップアップの背景 ターミナル 【 出来ること 】 ・ターミナルの色　：ターミナルの色変更 ・カーソルの形・色：カーソルの形と色の変更が可能 基本的なコマンド一覧 コマンドプロンプト の中でも良く使うコマンドを、用途別にまとめました！ 操作例、実行例も載せておきましたので、是非ご参考ください。 ファイル・ ディレクト リ操作 コマンドプロンプト 説明 cd ■指定したフォルダに移動 cd フォルダ名 ドライブ名: ■指定したドライブに移動 D: type ■指定したファイル内容の全表示 type ファイル名 more ■指定したファイル内容の部分表示 more ファイル名 find ■ファイル内で指定した文字列を検索 find "Hi" ファイル名 sort ■ファイル内容を行単位でソート表示 sort ファイル名 fc /n ■指定した2つのファイルを比較し、差分表示 fc /n ファイル名1 ファイル名2 comp ■指定した2つのファイルを比較結果を表示 comp ファイル名1 ファイル名2 where ■ファイルの場所表示 shere ファイル名 dir ■フォルダ/ファイルの一覧表示 dir ■フォルダ/ファイルの一覧を横表示 dir :d ■更新日時の昇順表示 dir /O:d ■更新日時の降順表示 dir /O-d tree ■ ディレクト リ構造のツリー形式表示 tree copy ■ファイルのコピー copy ファイル名1 ファイル名3 xcopy ■フォルダをコピー(コピー先有) xcopy /I ファイル名1 ファイル名3 ■フォルダをコピー(コピー先無) xcopy /Y ファイル名1 ファイル名3 move ■ファイル/フォルダ移動 move ファイル名 移動先フォルダ名 move フォルダ名 移動先フォルダ名 ren ■ファイル/フォルダ名の変更 ren ファイル名 変更後ファイル名 ren フォルダ名 変更後フォルダ名 mkdir ■フォルダの作成 mkdir フォルダ名 rmdir ■フォルダの削除 rmdirフォルダ名 del ■ファイルの削除 del ファイル名 実行結果例 上記にまとめた、ファイル・ ディレクト リ操作の実行結果例を一部まとめてみました。 ◆ type C:\Users\ユーザー名\Desktop> type test.txt Hello HelloHelloHello HelloHelloHelloHello Hi ◆ find C:\Users\ユーザー名\Desktop> find "Hi" test.txt ---------- TEST.TXT Hi ◆ fc /n C:\Users\ユーザー名\Desktop> fc /n test.txt test2.txt ファイル test.txt と TEST2.TXT を比較しています ***** test.txt 3 : HelloHelloHelloHello 4 : 5 : ***** TEST2.TXT 3 : HelloHelloHelloHello 4 : HelloHelloHelloHelloHello 5 : ***** ◆ comp C:\Users\ユーザー名\Desktop> comp test.txt test2.txt test.txt と test2.txt を比較しています... ファイルのサイズが違います。 ほかのファイルを比較しますか (Y /N )? N ◆ tree C:\Users\ユーザー名\Desktop\test> tree フォルダー パスの一覧: ボリューム OS ボリューム シリアル番号は 00000 XXX XXXX :XXXX です C:. ├─folder1 ├─folder2 └─folder3 ◆ ren C:\Users\ユーザー名\Desktop> ren test.txt test1.txt C:\Users\ユーザー名\Desktop> dir ドライブ C のボリューム ラベルは OS です ボリューム シリアル番号は XXXX :XXXX です C:\Users\ユーザー名\Desktop のディレクトリ 2021/ 12 / 06 15 : 32 < DIR > test 2021/ 12 / 06 14 : 58 52 test1.txt 2021/ 12 / 06 15 : 21 77 test2.txt OS操作 コマンドプロンプト 説明 path ■バスを全表示 path ■1つのパスを1行表示 echo %PATH:;=&echo.% set ■ 環境変数 の表示 set % ■指定した 環境変数 の表示 echo %JAVA_HOME% ver ■OSのバージョン表示 ver whoami ■ログインユーザーの表示 whoami vol ■ボリュームシリアル番号の表示 vol chcp ■ 文字コード の表示 chcp cls ■ コマンドプロンプト の画面をクリア cls Ctrl + c ■コマンドのキャンセル Ctrl + C 実行結果例 ◆ path C:\Users\ユーザー名\Desktop> echo %PATH:;=&echo.% C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\WINDOWS\System32\WindowsPowerShell\v1.0\ C:\WINDOWS\System32\OpenSSH\ C:\Users\ユーザー名\AppData\Local\Microsoft\WindowsApps ◆ % C:\Users\ユーザー名\Desktop> echo %JAVA_HOME% %JAVA_HOME% ◆ ver C:\Users\ユーザー名> ver Microsoft Windows [Version 10 .0.XXXX.XXXX] ◆ whoami C:\Users\ユーザー名>whoami rakus\ユーザー名 ◆ chcp C:\Users\ユーザー名\Desktop> chcp 現在のコード ページ: 932 ネットワーク操作 コマンドプロンプト 説明 ipconfig ■ IPアドレス の表示 ipconfig ■ IPアドレス の詳細表示 ipconfig /all getmac ■ MACアドレス の表示 getmac arp -a ■ ARP テーブルの表示 arp -a netstat ■使用中ポートの表示（ホスト名取得有） netstat ■使用中ポートの表示（ホスト名取得無） netstat -n ■使用中ポートの表示（待ち受け有） netstat -a ■ netstat のオプション確認 netstat /? nslookup ■ DNS に問い合わせる nslookup ping ■ネットワーク接続の確認 ping IPアドレス tracert ■ネットワーク経路の確認 tracert IPアドレス/ドメイン名 コマンドプロンプト まとめ コマンドプロンプト の基本をまとめさせていただきましたが、ご参考になりましたでしょうか？ コマンドプロンプト は、 Windows のPCをお持ちの方でしたらデフォルトで入っているツールになります。 是非、ご自身のPCで試しながら理解を深めることをおすすめします。 改めまして、 コマンドプロンプト を使う人にとって、少しでも一助となれば幸いです。 最後までお読みいただきありがとうございました！ Linux コマンドや bash を別記事にてまとめております。 ご興味ありましたら是非ご参考ください！ ・ よく使うLinuxコマンド一覧【最新版】 - RAKUS Developers Blog | ラクス エンジニアブログ ・ 【bash入門】bashシェルスクリプトの書き方 - RAKUS Developers Blog | ラクス エンジニアブログ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに こんにちは、 id:FM_Harmony です。 今回は自身の iOS アプリ開発 における、 Xcode 周りの体験談についてまとめてみました。 　 iOS アプリ開発 には IDE として Xcode を使うのが一般的だと思いますが、 元々 Eclipse でサーバサイドの開発に携わっていた身として Xcode を使った開発は新鮮なものでした。 　 そんな体験談の中から、今回は3つを記事にしています。 この記事を読んで、「こんな使い方があったのか」といった気付きを得たり、「あるある」と共感いただけたり、 逆に「こういう使い方もあるよ」といったご意見をいただけたりしますと幸いです。 　 Xcode の紹介やインストール方法については、RAKUS Developers Blogに詳しい記事が投稿されています。 こちら記事もぜひご覧ください。 ・ 【超入門】Xcodeのインストール方法-iosアプリを実機にインストールするまで - RAKUS Developers Blog | ラクス エンジニアブログ お知らせ この記事は ラク ス Advent Calendar 2021 6日目の記事です。 よければ、Advent Calendarも見てください。 qiita.com 目次 はじめに 目次 体験談①：Xcodeでの画面作成 iOSアプリの画面とxibファイル 部品を配置する Auto Layoutの設定 部品とコードの紐づけ 使ってみた感想 体験談②：Xcodeでのデバッグ UI Hierarchy Memory Graph Hierarchy lldb 体験談③：Xcodeのバージョンアップ iOSのSDKとXcode 具体的な動作確認方法 新旧Xcodeを混在させる おわりに 体験談①： Xcode での画面作成 楽楽精算の iOS アプリ開発 における、 Xcode を使った画面作成について語ります。 iOS アプリの画面とxibファイル 2021年現在、 iOS アプリの画面作成における最新技術はSwiftUIだと思いますが、 楽楽精算の iOS アプリでは xibファイル を使った画面作成を行っています。 xibファイルは iOS アプリにおけるHTMLファイルのようなもので、 XML として保存されますが Xcode 上で直感的に画面の部品を配置していくことができます。 xibファイルの編集画面 この画面で以下を行うことができます。 xibファイルへ画面の部品を配置する 配置した部品同士のAuto Layoutを設定する 配置した部品とSwiftのコードを紐付ける 部品を配置する 画面に部品を配置するには、まず Xcode の画面右上にある「+」マークのボタンをクリックします。 上記のボタンをクリックすると、ラベル、ボタンといった部品の種類が表示されるので、 その中から配置する部品を選択すると、画面に配置されます。 部品の選択画面 Auto Layoutの設定 iOS には Auto Layout という仕組みがあり、設定することで部品の間隔やサイズを、 端末側で適切に表示させることができます。 Auto Layoutの詳細は割愛しますが、この設定もxibファイルの編集画面で行う事が出来ます。 やり方は、まずcontrolキーを押しながら一つ目の部品を選び、間隔や位置を設定する先の部品を選びます。 自身のサイズを設定する際などは、二つ目の部品として自信を選びます。 すると、設定するAuto Layoutの種類が表示されるので、その中から設定するものを選びます。 部品同士を選んでAuto Layoutを設定する 間隔やサイズのパラメータは、初期値として画面に配置されている部品同士の位置などから入力されるので、 変更したい場合は該当のAuto Layoutの値を編集可能です。 Auto Layoutの編集画面 部品とコードの紐づけ 上記の通り作成した画面の部品はSwiftのコードと紐づけることで、 タップされたときの処理を呼び出す、テキストを取得するといった事が出来ます。 紐づけ方はAuto Layoutと同様、まずcontrolキーを押しながら紐づけたい部品を選びます。 次に紐づける先として、対象のコードで何もない箇所を選択します。 あとは、プロパティ（outlet、outlet collection）として紐づけるか、 関数（Action）として紐づけるか選択すれば、 Xcode がコードを作成してくれます。 一連の操作はxibファイルとSwiftファイルに跨るので、エディタを二つ画面に表示させておくとやりやすいです。 部品とコードの紐づけ 使ってみた感想 このように、部品の配置を始め Xcode でのxibファイルの編集は直感的に行う事が出来ます。 また、上記以外でも端末ごとやダークモードのON / OFF、回転している / していないといった状態ごとに、 画面へどう表示されるかプレビューすることが出来ます。 もちろん、最終的には実機で画面崩れが無いか確認することにはなるのですが、 予め編集画面で確認することができるのは良いと思いました。 ただ、直感的に配置された部品とxibファイル内の記載を対応させて把握するのは難しく、 コードレビューではコミットされたコードではなく、 Xcode 上で見てみないと分からないのが辛いところです。 ※ Xcode というよりはxibファイルの話ですが 体験談②： Xcode での デバッグ Xcode を使った デバッグ について語ります。 UI Hierarchy デバッグ ポイントで止めている間は、画面左の Debug Screen で様々な情報を確認することができます。 確認できる情報は4つあるのですが、その内の一つが UI Hierarchy で、 その時表示されている画面の構造を確認することができます。 例えば、画面上のボタンが押せないといった事象が過去にあったのですが、 原因としてボタンの表示がビューのサイズを超えていたということがありました。 そういった事象があった場合の調査に使っています。 例：UI HierarchyでCoreNFCのサンプル画面を見てみる Memory Graph Hierarchy Debug Screenで見ることのできる情報の内、もう一つ Memory Graph Hierarchy を使う事もあります。 例えば、楽楽精算の ICカード リーダーアプリ（ iOS ）はCoreNFCを使って ICカード を読み取っているのですが、 他のアプリで ICカード を読み取るセッションが既に起動していると、セッション起動時にエラーになります。 が、他にアプリを起動していなくても、読み取りをリトライするだけでエラーになることがあり、 セッションのオブジェクトが削除されていないタイミングでリトライしているのではという仮説の下、 オブジェクトを調査するのに使いました。 例：Memory Graph Hierarchy でCoreNFCのサンプルコードを見てみる Debug Screenでは、他にもスレッド毎やキューごとにプロセスの状態を見ることができますが、 今回は割愛します。 lldb Debug Screen 以外にも、 Xcode では lldb というデバッガを使って、 Swiftコード の デバッグ を行う事が出来ます。 私は主に p 、 po というコマンドを使っており、前者は変数の値を確認するのに、 後者は式の評価、関数実行に使っています。 コード中に ブレークポイント を設定しておいて、アプリが止まっている間に、 画面右下のコンソールで(lldb)とある箇所にコマンドを打つことで実行可能です。 変数の値は止まっている間に変数にカーソルを合わせる、コンソール左のVariable Viewで見る、 といったことでも確認できますが、個人的にlldbの方が必要な情報を絞り易いのでよく使っています。 例：lldbで変数を見てみる 体験談③： Xcode のバージョンアップ 楽楽精算の iOS アプリ開発 における、 Xcode のバージョンアップについて語ります。 iOS の SDK と Xcode Java 等とは違い、 iOS アプリの SDK は Xcode に含まれています。 そのため、アプリの SDK バージョンを上げる = Xcode のバージョンを上げることになります。 また、 Apple はアップロード可能な SDK バージョンを定期的に上げていくため、 Xcode を定期的に上げないとアプリがアップロードできなくなります。 直近の例 developer.apple.com 2022年4月以降、App Storeに提出するiOSおよびiPadOS Appはすべて、Xcode 13およびiOS 15 SDKでビルドする必要があります。 なお、楽楽精算の スマホ アプリ開発 では、リリース予定のアプリをアップロードした際、 SDK のバージョンアップが必要なことに気づき、急ぎ Xcode のバージョンアップを進めたこともありました。 その時のエラー ERROR ITMS-90725: "SDK Version Issue. This app was built with the iOS 13.7 SDK. All iOS apps submitted to the App Store must be built with the iOS 14 SDK or later, included in Xcode 12 or later. 上記のように、 Apple はアップロード可能な SDK バージョンに関するニュースを出しているので、 iOS アプリ開発 者の皆さまは Apple の開発者向けニュースを定期的に確認するようにしましょう。 developer.apple.com 具体的な動作確認方法 上記の通り、 Apple はアップロード可能な SDK バージョンを定期的に上げていくため、 楽楽精算開発では定期的なバージョンアップのタイミングに合わせて Xcode をバージョンアップできるよう、 バージョンアップ後の Xcode でアプリがビルドできるか ビルドしたアプリが問題なく動作するか を確認しています。 特に動作確認については、アプリの全機能が問題ないか確認しています。 この辺りは自動テストを用意して 工数 を削減するのも手だと思いますが、いまのところそういった仕組みは無く、 NFC を使った ICカード の読取り機能、端末のカメラでの領収書撮影機能といった、 実機でないと確認しづらい機能もあり、動作保証対象のOSバージョンごとに手動でテストを行っています。 機能、動作保証対象バージョンを網羅した動作確認となると総テスト項目数は 764項目 ！ 直近行ったXcode13のバージョンアップ対応では、動作確認だけで3人日（= 24時間）かかりました。 このように、定期的に Xcode のバージョンを上げるのにも、それなりの 工数 を要しています。 新旧 Xcode を混在させる 楽楽精算としては定期的なバージョンアップで Xcode の新バージョンへ対応するということになっていますので、 それまでの間にリリースを行う場合、古いバージョンの Xcode でビルドを行う必要があります。 幸い、 Apple は旧バージョンの Xcode をダウンロードできるようにしているため、 必要な場合はそちらからダウンロードしてビルド用に使うことが可能です。 旧バージョンの Xcode が公開されているページ https://developer.apple.com/download/all/?q=Xcode また、楽楽精算の iOS アプリは fastlane でビルドを行っているため、 fastlaneが旧バージョンの Xcode を使ってビルドするような設定も必要です。 いまのところ、楽楽精算開発では開発者の MacBook でビルドを行っているため、 上記の設定は xcode -selectを使って行っています。 設定変更の例 // 旧Xcodeはそれとわかるように名前を変えておくと良い xcode-select --switch /Applications/Xcode_13_0.app fastlaneのビルド情報 ↑ xcode_path に設定したものが表示されている。 おわりに いかがでしたでしょうか。 個人的な感想として、コードを書く以外にも デバッグ やビルドにも関わってくるなど、 iOS の アプリ開発 には Xcode が付きまとうという印象を受けました。 また、定期的なアップデートが大変といった点はありますが、画面作成を直感的に行う事ができ、 今までの アプリ開発 では得られなかった体験も得ることができたと感じています。 将来的にどうなるかは分かりませんが、 iOS アプリ開発 では Xcode を使っていくことになると思いますので、 これからも Xcode に慣れ親しんでいければと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 です。 フロントエンドエンジニアの皆様、今のフロントエンドを楽しんでおりますでしょうか？ 　 変化の多いフロントエンド領域を楽しむために・・・ ラク スが開催している 「フロントエンド LT会」で発表された資料をご紹介します！ フレームワーク や開発言語別にまとめておりますので、興味があるところだけを少し摘まむのも大歓迎です。 9月に開催した「フロントエンドLT会 - vol.4」は、参加者が500名越えとなるイベントなりました。 2022/1/19(水)に「フロントエンドLT会 - vol.5」を開催しますので、ご興味ある方は是非登壇/視聴申込よろしくお願いいたします！ rakus.connpass.com では、早速見ていきたいと思います！ イベント詳細はこちらからご確認ください。 ・ フロントエンドLT会 vol.1 -2020夏祭り- ・ フロントエンドLT会 vol.2 - 2020冬まつり ・ フロントエンドLT会 - vol.3 ・ フロントエンドLT会 - vol.4 フレームワーク Preact で手書き文字採点アプリを作ってみた React + Amplifyで アプリ開発 新規開発を止めないフロントエンドReactリプレイスの進め方とTips ピュアなJSしか使ったことのない人がReactを触った後の感想 SWRと状態管理 ユーザーが編集中の状態管理について考えよう Vue CLIプロジェクトにViteを導入検討してみた Vue.js と Chart.js でチャートを描画する Vue OptionsAPIからCompositionAPIに変換するツールを作ってみた VS Code Remote Containersを使った Angular開発 Nuxt.js + firebaseでハマったこと Blazor Web Assembly (C#) を触ってみた 開発言語 javascriptでも条件式を使いたい話 再帰関数を使ってみよう iframe sandboxでユーザー入力スクリプトを実行する HTML だけで UI を作る限界、あるいは無理なくユースケースと向き合っていくためには 疑似要素によるCSSセレクタ CSS のルールセットを高速に出力する VS Code 拡張を作った Lit Astro Something その他 Firebase + Bolt で もくもく会用のSlack botを作った話 docker-compose × Firebase Emulator でローカル環境構築 SVGでボーンアニメーションできない世界に絶望しないためのLT モナコインの投げ銭機能付きQiitaみたいなサービスを作った話 フロントエンドエンジニアの採用情報 終わりに フレームワーク Preact で手書き文字採点アプリを作ってみた 発表者： choo さん docs.google.com ◆ 発表のポイント ・フロントエンドの工夫3点 　① CSS フレームワーク は使わない 　②定義ファイルなどでサイズが多きものは遅延読込み 　③軽量版 React の Preact の導入 ・Preact は、ほぼ React と同じように使えるので、React 使いの人にはPreactめっちゃオススメ！ React + Amplifyで アプリ開発 発表者： nishikichi244 さん React + Amplifyで アプリ開発 from 虎の穴 開発室 www.slideshare.net ◆ 発表のポイント ・ API が自動生成できたり管理画面の実装の手間が省ける 　→ フロントのロジックの開発に集中できる！ ・ AWS のサービスになじみがある人は特におすすめ ・GraphQLを使った気になれた ・自分のト レーニン グを記録して振り返るアプリにしたい 新規開発を止めないフロントエンドReactリプレイスの進め方とTips 発表者： YuitoSato さん note.com ◆ 発表のポイント ・機能ごとにリプレイスしていく 　→小さくリリースすることで、新規機能開発と並行してすすめる ・変更が多い機能からリプレイスをする 　→二重の変更を避ける。早いタイミングでチームに布教できる ・副業、業務委託の方に協力してもらう 　 →フロントエンド特需に耐えるため。他社から設計を学ぶため ピュアなJSしか使ったことのない人がReactを触った後の感想 発表者： lcpj さん docs.google.com ◆ 発表のポイント ・JSXに使われる技術について 　→トランス コンパイラ Babel ・ステートについて ・ コンポーネント について 　→ ガンプラ を組み立てるようにコードを書く SWRと状態管理 発表者： koki さん speakerdeck.com ◆ 発表のポイント ・SWRの基本知識と特徴について ・SWRの自動再検証 ・ReduxからSWRを採用した理由 　→コードがとてもシンプル！ ・SWRを使った実装例の紹介 ユーザーが編集中の状態管理について考えよう 発表者： りゅーそう さん speakerdeck.com ◆ 発表のポイント ・Create⇔Update⇔Deleteの⇔の状態をどうデザインするか ・microCMSの事例紹介 ・ユーザーが「編集中」の状態は重要だが、本筋ではないためそれを念頭においてデザイン・実装すべし！ Vue CLI プロジェクトにViteを導入検討してみた 発表者： hatsune_k さん speakerdeck.com ◆ 発表のポイント Viteを導入してみて… ・アプリ起動まではできた ・想像より設定変更が面倒、コード変更も必要 ・導入には以下の3つの壁が残っている 　①SCSSの~@の エイリアス が読めない 　②Vuetifyの利用 コンポーネント を個別読み込みする必要がある 　③細かいデザイン崩れがあるのであたってないスタイルがありそう ・開発時ビルドは噂通り爆速 ・プロジェクトによっては即導入する価値はある！ Vue.js と Chart.js でチャートを描画する 発表者： SAW さん speakerdeck.com ◆ 発表のポイント ・Vue-chartjs の基本的な使い方を紹介 ・データの変更を検知してチャートをリアクティブに描画 ・実際の利用例を紹介 Vue OptionsAPIからCompositionAPIに変換するツールを作ってみた 発表者： miyaoka さん miyaoka.dev ◆ 発表のポイント ・Vue2のOptions API で書かれた コンポーネント をcomposition API を使った書き方に自動変換するツールの構築 ・どういう変換をしているのか？ 　１．入力値として Vue の SFC コンポーネント の文字列を受け取る 　２．vue-template-compiler で SFC から script 部分を抽出する 　３．TypeScript の compiler API で AST にする 　４．export default しているところの 各 options の値を読み取り、 新しい export に変換して出力する ・変換用の CLI として作ろうとしていたが、結局ブラウザで入出力の確認画面があったほうが分かりやすい ◆ リポジトリ GitHub - miyaoka/vue-composition-converter: Vue composition API converter ◆デモ Vue composition converter VS Code Remote Containersを使った Angular開発 発表者： honma12345 さん VS Code Remote Containersを使った Angular開発 from ShuheiHonma www.slideshare.net ◆ 発表のポイント ・remote containers導入前の問題点 →フロント開発の環境構築に時間がかかる ・remote containersの良い点 →フロントの開発構築が何より早い →ローカルマシンの構成に影響を与えない ・ AWS Amplityを利用したケースにも活用可能！ Nuxt.js + firebaseでハマったこと 発表者： Logy さん speakerdeck.com ◆ 発表のポイント ・ハマったこと 　①currentUser入ってない問題 　②コンソールエラー地獄 ・慣れない技術であっても基本に立ち返ることがトラブル解消への近道！ ・多少ハマったものの、認証機能はすぐに実装できた 　→Nuxt.js + firebase最高！ Blazor Web Assembly ( C# ) を触ってみた 発表者： nt-7 さん Blazor Web Assembly (C#) を触ってみた from Naito Oshima www.slideshare.net ◆ 発表のポイント ・Blazorとは？ →.NET( C# )を使って、SPA開発ができる フレームワーク ・どんな人に嬉しいの？ 　① ASP.NET 、 ASP.NET Coreあたりを触ることが多い方 　② C# 割と得意な方 　③今後 SPA 開発に興味がある方 　④Wasm で動く .NET ランタイム上の Blazor 開発に興味がある方 開発言語 javascript でも条件式を使いたい話 発表者： philomagi さん speakerdeck.com ◆ 発表のポイント ・条件文と条件式の違い 　→文は値を返さない、式は値を返す 　→条件式が使えると、細かいところでコードが簡略ができて便利 ・ JavaScript のif/switchは条件文 ・ JavaScript で条件式を使うために、ライブラリ化してみた 　→TypeScript対応 　→遅延評価対応 　→非同期にも対応 ◆ライブラリ ceiocs - npm 再帰 関数を使ってみよう 発表者： ita_3y さん speakerdeck.com ◆ 発表のポイント ・オブジェクトの探索等、 再帰 的な処理をしたい時は 再帰 関数が使えるかも ・ 再帰呼び出し をするときは、必ず終了条件があることを確認しよう ・等間隔の遅延を入れたい時は、setTimeout の 再帰呼び出し が良いかも ・ JavaScript で 再帰呼び出し をするときスタックオーバーフローに注意しよう iframe sandboxでユーザー入力 スクリプト を実行する 発表者： syumai さん speakerdeck.com ◆ 発表のポイント ・ユーザー入力 スクリプト の安全な実行には別OriginのWindowが使える ・別OriginのWindowは、iframe sandboxで簡単に使える ・Window Object間のmessage送受信にはpostMessageが使える ◆デモ GitHub - syumai/sandboxed-eval: iframe-sandboxed eval working on the browser. HTML だけで UI を作る限界、あるいは無理なく ユースケース と向き合っていくためには 発表者： yamanoku さん docs.google.com ◆ 発表のポイント ・フロントエンドとは、「すべてできる」それは本質ではなく表層の部分に責任をもつこと ・UIにまつわる責務を分解していく 　→詳細度に依存しない見た目（Utility CSS ） 　→ Webブラウザ 上の振る舞い（Web API （& JavaScript ） 　→UIの意味づけ（WAI- ARIA ） 疑似要素による CSS セレクタ 発表者： Takao Kamenoue さん speakerdeck.com ◆ 発表のポイント ・ セレクタ ーの種類 　①基本となる セレクタ ー（要素・クラス・ID） 　②属性による セレクタ ー（a[disabled],input[type="text"] ） 　③疑似クラスまたは疑似要素（a:hover,div::before） ・疑似要素を使用する際はブラウザでサポートされているかを確認する ・疑似要素ではそれぞれ利用できる CSS プロパティが異なる ・疑似要素を扱う際には アクセシビリティ にも気をつける。 アクセシビリティ に問題が発生するようならば代替案を検討する CSS のルールセットを高速に出力する VS Code 拡張を作った 発表者： kubosho_ さん speakerdeck.com ◆ 発表のポイント ・eCCStractor for VS Code の紹介 　→HTMLのクラス名やID名を抽出する 　→HTMLの他に、JSXと TSX も対応している ◆eCCStractor for VS Code のインストールページ eCSStractor - Visual Studio Marketplace ◆ GItHub GitHub - kubosho/vscode-ecsstractor: Extracting selectors from HTML / JSX / TSX and generate CSS file. Lit Astro Something 発表者： takanorip さん zenn.dev ◆ 発表のポイント ・LitでTailwind CSS を使う方法として、大きく2つの道がある 　①Shadow DOMを使わないようにする 　　・ createRenderRoot を使用してすべてをShadow DOMの外に出す 　②Shadow DOMのstyleの中にどうにかしてねじ込む 　　・windicssを使う： Windi CSS 　　・PostCSSで頑張る 　　・rollupを使う： GitHub - takanorip/lit-tailwind その他 Firebase + Bolt で もくもく会 用のSlack bot を作った話 発表者： RyoKawamata さん speakerdeck.com ◆ 発表のポイント ・Bolt + Firebase Functions で Bot は手軽に作れる ・勉強会開催前に Bot を温めておこう ・processBeforeResponseの設定を忘れずに！ docker-compose × Firebase Emulator でローカル環境構築 発表者： meijin さん zenn.dev ◆ 発表のポイント ・Firebase の使いどころと課題 ・Emulatorの概要とセットアップの全体的な流れ ・Dockerコンテナ作成手順 ・React Native Emulator と接続する方法 SVG でボーンアニメーションできない世界に絶望しないためのLT 発表者： miyanokomiya さん docs.google.com ◆ 発表のポイント ・ SVG でボーンアニメーションを作った話 ・資料作りの時間 < アニメーション作りの時間 ・岡田ーマンの SVG 素材+プロジェクトファイルをLT記念特別配布中 　→ 2021_06_30_LT_配布素材 - Google ドライブ ・主な使い方は以前zennにも書いたので参考に 　→ SVG岡田ーマンに命を吹き込む9のステップ モナコ インの 投げ銭 機能付きQiitaみたいなサービスを作った話 発表者： 石橋　龍（らいう） さん drive.google.com ◆ 発表のポイント ・ユーザ認証でデジタル署名を利用する（パスワード不要でユーザ認証！） 　→クライアント側に必要なもの：クライアントで発行した 秘密鍵 　→バックエンド側に必要なもの：ユーザの公開鍵 ・フロント側のロジック + ブロックチェーン で 投げ銭 ができる ・投機以外の用途で暗号資産を見てみると面白い応用がおもいつくかも？ ◆ GIthub GitHub - Raiu1210/omaemona_front フロントエンドエンジニアの採用情報 ラク スでは、フロントエンドエンジニアを募集中です！ ご興味ある方は以下内容をご確認ください。 ポジション 募集内容 マネージャー フロントエンドエンジニア／マネージャー（東京） | 株式会社ラクス エンジニア フロントエンドエンジニア（東京） | 株式会社ラクス ※2021/12/02時点での情報です。 開発拠点は 東京 です。 SaaS プロダクトの技術スタックは以下ブログをご参考ください！ tech-blog.rakus.co.jp 終わりに フロントエンド LT会で発表された内容はいかがでしたでしょうか？ 少しでもフロントエンドの初学者や、現役フロントエンドエンジニアの皆様のご一助となれば幸いです。 なお、冒頭でお伝えしましたが、「フロントエンドLT会 - vol.5」は2022/1/19(水)に開催予定です！ 毎度大盛況のイベントとなっておりますので、登壇/視聴されたい方は是非お申込みをお願いいたします。 イベントの詳細は以下をご確認ください！ ・ フロントエンドLT会 - vol.5 #frontendlt - connpass 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com