はじめに はじめまして。開発エンジニアのamdaba_sk（ ペンネ ーム未定）です。 ラク スに新卒で入社し、今年で2年目になります。 先日 ラク スオフィス内にあります共用本棚に「知識ゼロから学ぶ ソフトウェアテスト 【改訂版】」を見つけました。 ちょうどテストコードの書き方に悩んでいたところで 勝手に 自主的にこれを読みましたので、少し内容をまとめてみようと思います。 少しネットで「 ソフトウェアテスト 」検索するとたくさんの記事がヒットしますが、めげずに書きます。 目次 はじめに 目次 ソフトウェアのテストを分類してみる 工程による分類 開発者側の工程に対応するテスト 顧客側の工程に対応するテスト 品質の観点による分類 実行方法による分類 技法による分類 テストケース作成技法をまとめてみる ホワイトボックステスト（制御パステスト） ブラックボックステスト 同値分割と境界値分析 例えば… デシジョンテーブル 例えば… 状態遷移テスト ランダムテスト おわりに 参考 ソフトウェアのテストを分類してみる ○○テストという言葉はたくさんありますが、まずは大きく 工程・品質の観点・実行方法・技法 に区別されます。 工程による分類 開発の工程に対応させた分類です。 開発者側の工程に対応するテスト 単体テスト ソフトウェアを構成する最小の要素に対するテスト 言語や 開発プロセス によって「単体」の定義が異なる 統合（結合）テスト 単体同士を組み合わせた全体に対するテスト システムテスト ソフトウェアの全機能に対するテスト 運用時と同じインフラ、ハードウェア、 ミドルウェア を用いて行う 顧客側の工程に対応するテスト 受入テスト 顧客が納品されたソフトウェアに対して行うテスト 自社開発など、行われない場合も多い 品質の観点による分類 どういった品質を確かめる目的で行われるのかという視点に基づく分類です。 機能テスト 機能が正しく実装されているかどうかのテスト 性能テスト・負荷テスト ストレスなく使用できる程度の実行速度がでるかどうかのテスト 負荷テストでは必要な性能を満たせる限界を見極める ユーザビリティ テスト 「使いやすい」かどうかを確認するテスト セキュリティテスト 外部からの攻撃に耐えられるかどうかのテスト etc... 実行方法による分類 その名の通り、テストの実行方法による分類です。 動的テスト テストのためにソフトウェアを実行するテスト方法 静的テスト ソフトウェアを実行せずに行うテスト コードレビュー、静的解析、etc... 技法による分類 テストのためにはどのような操作をして何を確認するかを定めた「テストケース」を作成します。テストケース作成に用いる技法による分類です。 ホワイトボックステスト ブラックボックステスト （グレーボックステスト） テストケース作成技法をまとめてみる ホワイトボックステスト （制御 パステ スト） ホワイトボックステスト はプログラムの論理構造が正しいかどうかのテストです。デバッガでステップ実行などしながら、それぞれの行、それぞれのブロックで実行される文は正しく書かれているか、if分やswitch文の条件は適切か、きちんと終了まで実行されるかを確認します。 このテストの実行によって カバレッジ 率 が算出され、プログラムの品質を計る一つの指標となります。 ホワイトボックステスト で焦点となるのはあくまでプログラムの論理構造なので、以下のような不具合は見つけられません。 要求仕様自体の誤りや不備 データに関するバグ マルチタスク や割込みに関するバグ ブラックボックステスト ブラックボックステスト は名前の通りプログラムを一種の ブラックボックス として扱うテストで、様々な入力に対して妥当な出力が返されるかどうかを確認します。 ですが多くのプログラムでは可能な入力の組み合わせは膨大で、それらをすべて試すことは不可能です。そこで効果的な入力をもれなく選び取る方法が考案されています。 同値分割と境界値分析 同値分割と境界値分析は、 ブラックボックステスト 手法の中でも基本的な手法です。 同値分割 では入力全体の集合を「 同値クラス 」という部分集合に分割します。 同値クラス は、同じ 同値クラス の入力であればプログラムの動きに本質的な違いが出ないような入力の集合です。多くはプログラムが期待する入力値である「有効同値」、そしてそれ以外のあらゆる入力値である「無効同値」に分けられます。 それぞれの入力項目ですべての 同値クラス の入力を行えば、あらゆる入力に対してテストされたことになります。 境界値分析 では 同値クラス 同士の境界に注目します。 同値クラス の境界は条件文によって分けられることが多く、これを書き間違えることでバグになります。 そこで境界をまたぐもっとも近い入力の組を入力とすることで処理の切り替えがきちんとなされていることを確かめます。 例えば… 1から10までの 自然数 を受け付ける入力項目に対して 0を入力 1 （無効同値①、境界値）⇒ 入力エラーになる 1を入力（有効同値、境界値）⇒ 正常に処理される 2 5を入力（有効同値）⇒ 正常に処理される 10を入力（有効同値、境界値）⇒ 正常に処理される 11を入力（無効同値②、境界値）⇒ 入力エラーになる デシジョンテーブル 同値分割や境界値分析は、入力項目が複数 ありさ らにそれらが相関している時には大変ややこしくなります。 デシジョンテーブル ではそれらの入力の組み合わせを表にして、各組み合わせに対して期待される出力をまとめていく方法です。 複雑な状態が絡み合う機能のテストで有効です。 例えば… 入力項目が2つあって、両方に1から10までの 自然数 が入力された場合のみ処理がされる場合 条件 組み合わせ 入力項目Aが1-10の範囲内 Yes Yes No No 入力項目Bが1-10の範囲内 Yes No Yes No 動作 処理実行 エラー エラー エラー 状態遷移テスト ソフトウェアによっては「状態」が複数存在し、操作することでそれらの状態間を行き来する場合があります。状態によって受け付ける入力や出力を変化させています。 状態遷移テスト はそういった場合に、入力に対して正しく状態遷移（出力）するかどうかをテストします。 ランダムテスト ランダムテストはこれまでの ブラックボックステスト 手法とは毛色が違っていて、事前にテストケースなどを作成せずにやみくもに入力や操作を行うテスト手法です。 結構なバグがこれで見つかるようですが、機能要求に対するテストでは あまり有効でない とのことです。ただし、セキュリティに対するファジングテストという形でランダムテストが活用されています。 おわりに 参考図書、参考ページをもとに、 ソフトウェアテスト の分類と、その中でテストケース作成技法についてまとめてみました。簡単ではありましたが、この記事を読んでくれた方が ソフトウェアテスト の勉強をするきっかけになれたなら幸いです。 参考 高橋 寿一 (著) 知識ゼロから学ぶ ソフトウェアテスト 【改訂版】 http://gihyo.jp/dev/serial/01/tech_station/0001?page=1 http://b.hatena.ne.jp/entry/qiita.com/ktarow/items/8c3d94d6c21a0c86b799 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 0はいろいろな意味で特別なので、仕様的に境界値でなくともテストした方が良いです。 ↩ 実際はここは仕様に合わせて具体的に書きます。 ↩

先日、仕事で JMeter を使わせていただく機会がありました。Y-Kanohと申します。 とはいえ、新卒2年目の私には何のことかさっぱりで...先輩に教えていただきながらの作業でした。 せっかくブログを書く機会があるので、同じ境遇の人が、「え、LatencyとSample Timeってどう違うの？」「実際にテストしたらコンピュータがフリーズした!!」「2時間たっても終わらないけど、どうすれば...(焦)」とならないように、簡単な例を用いて JMeter の使い方を紹介します。 そもそもJMeterって？ スレッドグループの追加 送信するHTTPリクエストの追加と設定 スレッドグループの設定 Ramp-Up期間 スレッド数とループ回数 テスト計画作成の注意点 リスナーの追加 テスト計画の実行と結果の見方 おわりに 　 そもそも JMeter って？ JMeter は Apache ソフトウェア財団が開発している オープンソース の負荷検証ツールです。 サーバに対して指定した量のリク エス トを送り、そのレスポンスを受けることで、パフォーマンス計測することができます。 JMeter は Apacheの公式サイト からダウンロードできます。 （ Java を入れていない方は、インストールしてからご使用ください。） JMeter は GUI モードとNon- GUI モードがありますが、ここでは GUI モードの説明をします。 今回は例として、サーバ192.168.99.100のtest.htmlに2つのパラメータ「param1」と「param2」を送信する例を考えます。 スレッドグループの追加 以下が JMeter の起動画面です。 ダウンロードしたファイルの bin ディレクト リにある jmeter.bat ( Windows ) もしくは jmeter ( Unix )を実行することで開きます。 まず、テスト計画を作成するため、スレッドグループを作成します。 左上の「テスト計画」を右クリックし、 追加 > Threads(Users) > スレッドグループ を選択してください。 新しいスレッドグループが作成されます。 スレッドグループの設定画面でも設定することがあるのですが、今はひとまず置いておきましょう。 送信するHTTPリク エス トの追加と設定 次にスレッドグループで送信するリク エス トを設定します。 今回は一番基本的なHTTPリク エス トを送るため、 左画面のスレッドグループ名を右クリックし、 追加 > サンプラー > HTTPリクエスト を選択し、 作成された「HTTPリク エス ト」にてWebサーバとリク エス トの設定を行います。 まず、リク エス トを送信するWebサーバの設定。 「 プロトコル 」にはhttpを入力し、「サーバ名またはIP」には負荷検証を行うサーバを指定します。 次に、HTTPリク エス トの設定です。 「メソッド」には、送信メソッドを指定します。とりあえず、今回は「GET」を指定。 「パス」 には、リク エス ト 送信先 のリソースを指定します。 送信するリク エス トパラメータを設定します。 画面下の「追加」ボタンから複数追加することができ、パラメータの名前と値をそれぞれ指定することができます。 これで、送信するHTTPリク エス トを設定できました。 スレッドグループの設定 さて、HTTPリク エス トが設定出来たら、スレッドグループの設定に戻りましょう。 スレッドグループでは、先ほど設定したHTTPリク エス トをどのように、どれぐらいの量、どれぐらいの期間で送信するかを設定できます。 *1 これらを決定するのが、スレッド数、Ramp-Up期間、ループ回数 です。 Ramp-Up期間 Ramp-Up期間が一番わかりやすいでしょうか。 Ramp-Up期間は、全リク エス トの作成時間です。 「スレッド数」で設定したリク エス ト群を、何秒間で作成するかを決めるのがRamp-Up期間です。 例えば、Ramp-Up期間を100(秒)、スレッド数を10とすると、 JMaterは100秒かけて10スレッド分のリク エス トを送信しようとします。 ただし、Ramp-Up期間はあくまで「リク エス トの作成時間」であり、テストの実行時間ではありません。 負荷検証するサーバの処理速度がテストに追いつかない場合は、この時間を大幅にオーバーしてしまいます。 もし、一定時間でテストを中断したい場合は、同画面の「スケジューラ」にチェックを入れて、終了時間を設定してください。 スレッド数とループ回数 スレッド数は、「リク エス ト群を送信する回数」のことです。 ここで重要なのことは、スレッドは「リク エス ト」ではなく「リク エス ト群」であること。 1スレッドでは複数のリク エス トを送信することができます。 では、この「リク エス ト群」内のリク エス ト数はどうやって設定するかというと、「ループ回数」で指定します。 要するに、ループ回数は「1スレッドで送信するリク エス トの量」を決める値です。 テスト実行時に送られる総リク エス ト数は、この「スレッド数」と「ループ回数」の積によって決まります。 総リクエスト数 = スレッド数 × ループ回数 ※ スレッド数 = 総リクエスト数 ではありませんよ。 この3パラメータの関係を時系列で図にまとめると、以下のような感じですね。 また、スレッドグループでは、スケジューラを用いることでテストの開始時間や終了時間を設定できます。 テスト実行中はリク エス トを送信する端末にも負荷がかかるため、これで夜間などにテストを実行させておけば楽(?)できますよ。 テスト計画作成の注意点 スレッド数、Ramp-Up期間、ループ回数 を用いてテスト計画を作ることができますが、ここであまりに大量のリク エス トを投げようとすると、 JMeter を実行する端末のCPUが食い散らかされてしまします。 デフォルト設定の JMeter は、たとえRamp-Up期間が長時間だったとしても、テスト開始と同時に、スレッド数で指定したスレッドを作ってから、テストを実行するそうで、スレッド数の量によっては、一発でフリーズしてしまいます。 *2 この場合、スレッドグループの設定画面にある Delay Thread creation until needed にチェックを入れることで、スレッドの作成をずらすことができます。 *3 JMeter has an option to delay thread creation until the thread starts sampling, i.e. after any thread group delay and the ramp-up time for the thread itself. This allows for a very large total number of threads, provided that not too many are active concurrently. Apache JMeter - User's Manual: Best Practices リスナーの追加 テストの実行結果を表示するリスナーを追加します。 左画面のスレッドグループを右クリックし、 追加 > リスナー > 結果を表で表示 を選択します。 続けて 追加 > リスナー > 統計レポート も追加しておきます。 他にも下図のように様々な結果の表示方法があるので、用途によって使い分けてください。 ただし、あまりリスナーを増やしてしまうと、メモリをたくさん使ってしまいますので、必要最低限にする必要があります。 （特に、今回用いる「結果を表で表示」は、全サンプルの結果を表示するのでたくさんメモリを使ってしまうそうです。） また、各リスナーは、テスト実施前にファイル名を指定することで、全てのデータをファイルに出力することができるので、 テスト結果に対して実行後に何らかの処理を加えたい場合は指定してください。 ここまでで作ったテスト計画は、ファイルとして保存できます。 テスト計画を選択したうえで保存ボタンを押下し、保存しておきましょう。 テスト計画の実行と結果の見方 いよいよテスト実施です。 まずはあまり負荷が高くない条件で動かしてみましょう。 画面上部の「開始」ボタンでテストを開始でき、テストを開始すると、画面右上のアイコンが緑色になり、終了すると灰色に戻ります。 以下の画面では、スレッド数:5、Ramp-Up期間:10秒、ループ回数:20 でテストを実施した場合の「結果を表で出力」画面です。 表項目それぞれの意味は次の通り。 項目名 意味 Sample リク エス トの番号 StartTime リク エス トの送信を始めた時間 Sample Time(ms) リク エス トの送信からレスポンスを受け終わるまでにかかった時間 Status レスポンスのステータスを示す Bytes 受信データのバイト数 SendByte 送信したバイト数 Latency リク エス トを送ってからレスポンスが届いた時間 Connect Time(ms) JMeter がサーバとの接続確立にかかった時間 ちょっと時間にかかわる用語がややこしいので、図で説明します。 また、結果をファイルへ出力する際に出力できる「Elapsed time」についても併せて説明します。 JMeter が1リク エス トを送信してレスポンスを受信するまでの処理は、上の図のように行われます。 Start Time はその名の通り、処理を開始した時刻です。（結果をファイル出力した場合はマシンタイムで表されます。） JMeter は、処理開始後、サーバとのHTTP接続の確立を行います。この接続の確立にかかる時間が Connect Time です。 もし、このConnect Timeに時間がかかる場合、 JMeter からの接続要求が待たされている可能性があるので、サーバの同時接続条件などを見直したほうがいいかもしれません。 JMeter は、接続が確立されると、リク エス トを送信し始めます。 全てのリク エス トが送信されると、サーバの処理が終わるまで待機し、サーバからレスポンスが返ってくるとレスポンスを受信し始め、すべてのレスポンス情報を受け取ると処理終了となります。 余談ですが、 JMeter はブラウザと違い、受信したレスポンスに対して処理を行いません。 したがって、（当たり前ですが） JavaScript のようなブラウザ側での処理は、 JMeter の結果に影響することはありません。 Elapsed Time はリク エス トを送信し始める直前から、すべてのレスポンスを受信した直後までの時間です。 Latency は、日本語に訳すと「潜時」と言って、「刺激が与えられてから反応するまでの時間」のことです。 JMeter では、「処理開始時間」から、「最初のレスポンスが返ってきた直後」の時間を指します。 （少しややこしいのですが、 JMeter の公式リファレンスの「Connect Time」の項によると、LatencyはConnect Timeを含んだ時間になるそうです。そのため、接続エラーが起きたリク エス トでは、 Connect Time = Latency になります。） *4 Sample Time は、これらの処理すべてにかかった時間です。 ちなみに、全リク エス トの通し番号である「Sample」は、この終了時間の昇順で割り当てられているらしいので、Start Timeが前後していても気にしなくていいそうですよ。 *5 「統計レポート」リスナーには、全サンプルの統計情報が記載されます。 たくさんのリク エス トを送信するテストの場合、どうしてもすべてを見ることは不可能なので、統計情報を参考にしてください。 おわりに さあ、これでざっくりですが、 JMeter の基本的な機能は使えるようになりました。 リク エス ト数を増やして、いざ、テスト！ ...と考えた方、ちょっと待ってください！ これだけ説明しておいてですが、 Apache は GUI モードでの本番テストを推奨していません!! *6 Don't run load test using GUI mode ! 　 GUI mode should only be used for creating the test script, NON GUI mode must be used for load testing Apache JMeter - User's Manual: Getting Started Non- GUI モードのほうがより正しい結果を得られるため、 GUI モードはテスト計画の作成のみに使い、実際のテストはNon- GUI モードを使ってほしいそうです。 斯く言う私も、この記事を書くため公式ドキュメントを読んで気づきました(^^;) より正確な結果が求められるテストを行う場合は、 GUI モードでテスト計画を作成、上部メニューの保存ボタンから保存したのち、 Non- GUI モードから読み込んでお使いください。 以上、基本的な内容ですが、私が業務で使った JMeter の使い方について、説明しました。 もし、はじめての負荷検証であたふたしている人の助けになれば、幸いです。 　 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 *1 : http://qiita.com/PlanetMeron/items/a604645d6f89b6ce3a14 *2 : http://keis-software.com/2013/09/02/jmeter-%E3%81%AE%E5%88%A9%E7%94%A8%E6%96%B9%E6%B3%951-ramp%EF%BC%8Dup%E3%80%81%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89%E6%95%B0%E3%80%81%E3%83%AB%E3%83%BC%E3%83%97%E5%9B%9E%E6%95%B0%E3%81%AE%E8%AA%A4/ *3 : http://jmeter.apache.org/usermanual/best-practices.html *4 : http://jmeter.apache.org/usermanual/glossary.html *5 : http://www.checksite.jp/jmeter-check-result-research/ *6 : http://jmeter.apache.org/usermanual/get-started.html#overview

はじめに はじめまして。開発エンジニアのstrongWhiteです。 ラク スに入社して今年で2年目になります。 今回は、仕事を進めていく上で WIPを制限する大切さ をお伝えしようと思います。 堅苦しい 話にならないように、あるゲームの内容をもとにお伝えできればなと思います。 WIP WIPとは「work in progress」の略で、仕事が進行中である あるいは 仕事が完了状態ではないことを意味します。 簡単にいうと、やりかけの作業 ということになります。 突然ですが、みなさんは仕事ができる人 や 仕事が早い人と聞くと、どんな人をイメージされるでしょうか。 いろいろな仕事を同時並行的にこなしている人をイメージされますか？ 実は仕事を同時並行的に行うと、かえって完了が遅くなります。 仕事ができる人 や 仕事が早い人は、 ひとつひとつの仕事を確実に終わらせる 人です。 ここが今回の記事の肝になりますので、念頭に置いておいてください。 コインゲーム 先日、社内で開催された勉強会で コインゲーム を開催しました。 このゲームはWIPを制限する大切さを実感できるゲームです。 ゲームに必要なもの コインをひっくり返す「作業者」 作業者の作業時間を計測する「管理者」 1人の「顧客」 テーブル 同じサイズのコイン20枚 ストップウォッチ（あるいはストップウォッチ機能付き携帯電話） 結果を書き出す紙 遊び方 作業者と顧客はテーブルを囲んで着席します。 1人の作業者の後ろに1人の管理者が付き、管理者はストップウォッチを持ちます。 また、顧客もストップウォッチを持ってスタンバイします。 作業者・管理者・顧客の役割はそれぞれ以下の通りです。 作業者…すべてのコインをひっくり返して、次の作業者に渡す。（最後の人は顧客に渡す。） 管理者…作業者がコインをひっくり返すのにかかった 実質作業時間 を計測する。 顧客…最初のコインが届くまでの時間とすべてのコインが届くまでの時間（最後のコインが届くまでの時間）の2つを計測する。 ゲームは3回繰り返してプレイします。 最初は20枚のコインを一括で行い、2回目は5枚ずつに分けて行います。そして最後は1枚ずつに分けて行います。 勘のいい方はこの時点で気付いたかもしれませんが、このゲームでは、コインがひとつの WIP を示しています。 3回とも全く同じようにプレイしますが、違うのは WIPが徐々に小さくなっていく ことだけです。 今回、勉強会では作業者3名、管理者3名、顧客1名の計7名でゲームを行いました。 結果は以下の通りです。 20枚 5枚 1枚 Aさん 20秒 28秒 28秒 Bさん 23秒 26秒 28秒 Cさん 21秒 28秒 29秒 最初のコイン 67秒 23秒 4秒 合計時間 67秒 42秒 31秒 ゲームから学べること WIPが小さくなるにつれて作業者の作業時間は長くなりますが、最初のコインがゴールするまでの時間と合計時間は短くなります。 つまり、同時に作業する作業項目を減らすと、リードタイムが短くなるということになります。 ひとつひとつのコインを皆さんが仕掛っている仕事に当てはめると、同時並行的に仕事をするとすべての仕事が完了するのにとても時間がかかってしまうということになります。 この点から、WIPを減らすことによる重要性が理解できるかと思います。興味がある方はぜひ周りの人とゲームをプレイしてみてください。 まとめ 今回はWIPを制限する大切さをお伝えしました。効率的に仕事を進めるには、ひとつひとつの仕事を確実に終わらせるように立ち回ったほうがいいということが少しでも伝われば幸いです。 抱えている仕事が多いと、つい気が焦って何でもかんでも手をつけてしまいがちです。ですがそのまま進めても何もかもが中途半端に終わってしまい、何ひとつ完了している仕事がないという状況に陥ります。 そんなときは今回の記事を思い出していただき、WIPを制限していま取りかかっている作業を終わらせることに集中してみてください。 参考 Marcus Hammarberg、Joakim Sunden 著 『カンバン仕事術-チームではじめる 見える化 と改善』

はじめに はじめまして。エンジニアのnorthmkyです。 ラク スに新卒で入社し、今年で2年目になります。 他エントリが技術の内容だったので少し趣向を変えて ラク スが行っている技術交流会、 ビアバッシュ を紹介したいと思います。 ビアバッシュとは "ビア"とついている通り 「ビールなどのアルコールを片手に(+軽食)フランクに技術内容について発表したり語り合う交流会」 のことを指します。 だいたい月に一度くらいの頻度で有志が集まって開催しています。 参加費は...なんと無料です。 というのも技術交流会を会社が応援してくれていまして 補助金 がでるのです。 そのおかげもあり、 ラク スでは本イベントが3年も途切れることなく続いています。 (実はここまで会社内で技術イベントが続いてる事例は少ないんだそうです) ビアバッシュの流れ 以下のような流れでやっています。 ビアバッシュ開始 お酒をたしなみつつ... 発表スタート!! (発表 + 質疑応答) x 3名ほど 発表が終わりと思いきや... 飛び入り参加枠スタート ビアバッシュ終了 発表後半になると聴いていた参加者側の人が登壇したくなり、 飛び入り参加枠で話し始める...ということが結構あります。 気になる発表内容ですが...実に幅広いです。 話題の技術を使ってみた 勉強したことを整理してみた 実務をしていて身につけたTips紹介 読んだ本(技術書あるなし問わず)の紹介 実務をしていて感じたこと・大事だと思うこと 勉強会レポート 趣味について熱く語る 新卒一年目で感じたこと などなど。 熟練エンジニアから新卒で入りたての人まで、様々な人が登壇します。 前回の様子はこちら では実際に前回ビアバッシュの様子の一部を紹介したいと思います。 開催前、司会進行のスライドです。 開催前に参加可否のアンケートをとり、発表者とそのテーマをタイムテーブルに落とし込みます。 たまに発表はじまりの前、後に個人で宣伝したいことを宣伝する時間をとることがあり、 そのときもこの資料に記載しています。 「平日毎○曜日、勉強会開催してるよー」だったり「趣味のイベント参加者募集！」だったり 技術以外の宣伝もあります。 軽食といいながらお寿司がでちゃいます。 その会の運営している人のさじ加減で内容は変わります。 写真では伝わりませんが、BGMも流しています。 テンションがあがります。 実際の発表風景です。 お気づきかもしれませんが、本ブログのTOP画像の場所、 通称「 コワーキングスペース 」にて行いました。 この写真の登壇者の発表内容は数学よりの話だったので皆さん真剣に耳を傾けています。 上記のような感じで毎月やっています。 飛び入り枠の雰囲気もお伝えしたかったのですが、自身が飛び入りをしたのでお見せする写真はありませんでした... ビアバッシュのよいところ 私が参加してみてよいなあと思うところは 「普段仕事で関わる/関わらない人にかぎらず興味深い話が気軽に聞ける」 ところかなと思います。 なかなか他部署のエンジニアの方と話す機会って業務ではなかなかないのではないかと思います。 また同じ部署でも話さなかった人って実はいたりして、そのいう方々の話を聴くと 案外自分が気になっている情報を持っていらっしゃったりして、そこからより関係性が深まることもあります。 自分の好きな技術の話になりますと、やはり発表者もイキイキした表情と声で発表しているので、 伝染して楽しい気持ちになりますし、もっと知りたい！という知識欲をかりたたせられます。 おわりに ラク スでのビアバッシュを紹介しました。 お酒が入った中自由に技術の話をする/聴くのはやはり楽しいです。 そしてこのイベントを会社が推奨してくれるのもありがたいなと思います。 これからも続いていけるようにしていきます。 実は、外部の方を招いて勉強会をしようという声も上がっています。 その時はまた周知しますので気になった方はぜひ参加してみてくださいませ。 以上northmkyからのビアバッシュ紹介でした。

はじめに はじめまして。開発エンジニアのCarboxyです。 ラク スに新卒で入社して、今年で２年目になります。 今回は、新卒（≒エンジニア初心者）が、効率の良いプログラムを書けるようになるきっかけになればと思い、プログラムの計算量の求め方とその比較方法をソート アルゴリズム （選択ソート）を例に紹介します。 計算量とは ある問題を解くためにどのくらい計算が必要かどうか（どのくらい時間がかかるか） → アルゴリズム の性能評価に使用できる。 O(オーダー)記法を用いて示す。 ※計算量には時間計算量と空間計算量があるが、この記事では時間計算量の事を指す。 O(オーダ）記法 計算量の一般的な記述方法。大まかな時間計算量を表す。 例として、入力サイズ n の関数として表される時間計算量T(n)が で与えられる場合、オーダー記法では最も次数の高い項の係数を省いて となる。なぜこのように最も次数の高い項（主要項）の係数を省くような、漸近的な評価が使われるかというと、入力サイズ n が十分に大きい場合は、時間計算量は主要項にのみ依存するからである。 選択ソート 選択ソートを例に計算量を考える。 選択ソートは最も基本的なソート アルゴリズム の１つで、次のようなア イデア に基づきソートを行っていく。 1,入力データの中から最大のデータを見つける。 2,見つけた最大のデータをソートの対象から除外する。 3, 1と2 の操作を n - 1 回繰り返す。 ソースコード 入力サイズ n の配列 D[0]、D[1]、・・・、D[n-1] for (i=n-1; i>0; i=i-1) { max = D[0]; maxIndex = 0; for (j=1; j<=i; j=j+1) { if(D[j]>=max) { max = D[j]; maxIndex = j; } } swap(D[maxIndex],D[i]); } この アルゴリズム は、２重のfor文により構成されている。変数 n に依存する i , j の２重ループなのだからO(n^2)になることは安易に想像できるが、計算すると次のようになる。 外側のfor文の繰り返し実行回数は n - 1 回であり、内側のfor文は外側のfor文の変数 i に依存し、i 回の繰り返しとなっている。したがって、この アルゴリズム の計算量は、以下の式で表される。 計算量の比較 複雑になるため詳細は省略するが、その他のソート アルゴリズム の計算量を計算すると、例えば クイックソート の場合はO(n logn)になる。オーダー記法の漸近的な大小関係は以下のようになることから、選択ソートと クイックソート を比較すると クイックソート のほうが計算量が小さい事が 数値的に わかる。 まとめ オーダ記法によって漸近的な時間計算量を示すことができる。 プログラムを実行して時間を測定しなくとも、入力サイズ n に対してどの アルゴリズム が一番速いか数値的に比較できる。

はじめに はじめまして。開発エンジニアのwest-cです。 ラク スに新卒で入社し、今年で3年目になります。 ラク スでもエンジニアブログをはじめることになりました。 記念すべき1エントリ目を書くことになり光栄です。 本題 そんな1エントリ目のテーマですが、現在、私自身が新卒メンバーの育成を担当していることもあり、今年入社した新米エンジニアを対象にお話をしたいと思います。 大学や会社の研修でプログラムは学ぶかと思いますが、ログの見方・調査方法についてしっかり学んだことのある方は少ないのではないでしょうか。 個人で作成したプログラムであればエラーが発生したとき程度しか見ないログですが、お客様に提供するアプリケーションとなると話はちょっと変わってきます。 ログは、ユーザがとった行動の証跡（証拠）となることから、利用状況の把握から問題が発生した場合の原因特定まで非常に重要な役割を担います。 ログの形式はソフトウェアによって異なるためそれぞれの公式ドキュメントに譲るとして、ここでは ログ調査にあたり知っておくと便利な Linux コマンド を紹介したいと思います。 なお、今回は Apache のアクセスログ を例として説明を行います。 リアルタイムでログを監視したい $ tail -f access_log ファイルの末尾が更新されると自動的に追加分が表示されます。 例えば、検証環境にて画面遷移をした瞬間のログを確認したい場合などに重宝します。 長い スタックトレース を確認する場合は、予めEnterキーでいくつか改行を入れておくとログの切れ目が分かりやすくなり便利です。 ログをスクロールして表示したい $ less access_log 行数の長いファイルの場合、 cat でファイルの中身を見ようとすると画面に収まり切らず、目的のログに辿り着くのにひと苦労します。 そのようなときに less を利用すると、スクロールしながら閲覧することができます。 less コマンド内で利用できる操作のうち、個人的によく使うものは以下になります。 キーバインド 説明 b 1画面分上にスクロール スペース 1画面分下にスクロール g ファイル先頭に移動 G ファイル末尾に移動 /文字列 ファイル内を文字列で検索 n 次にヒットした検索文字列の行に移動 N 前にヒットした検索文字列の行に移動 F リアルタイムで監視（ tail -f と同様） q less コマンドを終了する 表示する行を絞り込みたい 以降は、以下のような アクセスログ を前提として説明を行います。 （GET or POST の前の数値はリク エス ト処理にかかった時間（単位：秒）、末尾の数値はレスポンスサイズと解釈してください） $ cat access_log 192.168.10.11 - - [10/Oct/2000:13:55:36 -0700] 1 "GET /index.php HTTP/1.0" 200 2326 192.168.10.11 - - [10/Oct/2000:13:55:36 -0700] 0 "GET /top.jpg HTTP/1.0" 200 310 192.168.20.8 - - [10/Oct/2000:13:56:01 -0700] 10 "POST /login.php HTTP/1.0" 200 1793 192.168.30.50 - - [10/Oct/2000:13:57:11 -0700] 5 "GET /mypage.php HTTP/1.0" 200 831 192.168.30.50 - - [10/Oct/2000:13:57:11 -0700] 0 "GET /room.png HTTP/1.0" 200 4530 特定の文字列が含まれる行のみを抽出したい場合は grep の出番です。 $ grep "login" access_log 192.168.20.8 - - [10/Oct/2000:13:56:01 -0700] 10 "POST /login.php HTTP/1.0" 200 1793 ファイルから「login」という文字列が含まれる行のみが抽出されました。 逆に「login」という文字列を含まない行を表示する場合は、 -v オプションを付けましょう。 $ grep -v "login" access_log 192.168.10.11 - - [10/Oct/2000:13:55:36 -0700] 1 "GET /index.php HTTP/1.0" 200 2326 192.168.10.11 - - [10/Oct/2000:13:55:36 -0700] 0 "GET /top.jpg HTTP/1.0" 200 310 192.168.30.50 - - [10/Oct/2000:13:57:11 -0700] 5 "GET /mypage.php HTTP/1.0" 200 831 192.168.30.50 - - [10/Oct/2000:13:57:11 -0700] 0 "GET /room.png HTTP/1.0" 200 4530 grep -E または egrep を利用すると、検索文字列に 正規表現 を利用することができます。 上記を組み合わせると、画像ファイル（ *.jpg , *.gif , *.png ）を除外したログを表示したい場合に、以下のように記述することができます。 $ egrep -v "\.(jpg|gif|png)" access_log 192.168.10.11 - - [10/Oct/2000:13:55:36 -0700] 1 "GET /index.php HTTP/1.0" 200 2326 192.168.20.8 - - [10/Oct/2000:13:56:01 -0700] 10 "POST /login.php HTTP/1.0" 200 1793 192.168.30.50 - - [10/Oct/2000:13:57:11 -0700] 5 "GET /mypage.php HTTP/1.0" 200 831 表示する列を絞り込みたい 例えば以下の3つの情報がログ調査に必要であるとします。 アクセス日時 リク エス トURL リク エス トにかかった時間 この3つ以外の情報は今回は必要の無いノイズ情報ですので、 awk で表示する列を絞り込みましょう。 awk で列を絞り込む場合、デフォルトでは空白（スペース）またはタブ単位で区切られます。 今回の例だと、4列目（アクセス日時）・6列目（リク エス トURL）・8列目（リク エス トにかかった時間）だけを表示したいことになります。 $ awk '{print $4,$6,$8}' access_log [10/Oct/2000:13:55:36 1 /index.php [10/Oct/2000:13:55:36 0 /top.jpg [10/Oct/2000:13:56:01 10 /login.php [10/Oct/2000:13:57:11 5 /mypage.php [10/Oct/2000:13:57:11 0 /room.png 必要な情報のみが表示され、見通しが良くなりました。 $ の後の数字には、区切り文字で行を分割した際の順番が入ります（1始まり）。 区切り文字を変更したい場合は、 -F '区切り文字' とオプションを付与すれば良いです。 ちなみに cut コマンドでも同様のことは実現できますが、次に紹介する話との関連で、ログの確認時には awk を利用することをおすすめします。 条件に合致するログのみを抽出したい ひとつ前の例に追加して「リク エス トに3秒以上かかったログのみを抽出したい」場合を考えてみましょう。 awk は プログラミング言語 なので、条件分岐を記述することもできます。 $ awk '$6>=3{print $4,$6,$8}' access_log [10/Oct/2000:13:56:01 10 /login.php [10/Oct/2000:13:57:11 5 /mypage.php このように「○番目の項目が□□だった場合」と記述することができるため、単純な文字列一致の条件の場合でも grep よりも細かく絞り込みを行うことができます。 まとめ 私自身、入社したての頃にログファイルをviで開いて怒られたりログファイルを根こそぎ Excel に貼り付けてちまちま絞り込みを行ったりと苦い経験があったため、今回このテーマを選ぶことにしました。 今回取り上げた内容は基本的なものであり、さらに高度なログ集計を行おうとすると、 sort や uniq 、 sed なども必要になるかと思います。 まずはこの記事を足がかりに、その他のコマンドも習得してステップアップしてもらえると嬉しいです！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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