RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのエンジニアブログ

edエディタについて調べてみた

はじめに

開発エンジニアのamdaba_sk(ペンネーム未定)です。 前々回前回と弊社エンジニアへのなんちゃってインタビューで記事を書いてきましたが、今回は久々に調べものをした結果をまとめてみようかと思います。

目次

経緯

実は私は自宅では非常に貧弱な性能のマシンしか持っていません。でもやっぱり家でも趣味の開発はしたいわけですが、まずエディタ選びが悩ましい。

Eclipseは動くには動くけどどうももっさりしてて使ってられない。Atomエディタも同じ感じ。Visual Studio CodeやGeanyという軽量エディタはわりとマシだったものの、時間が経つにつれてだんだん重くなっていく…。

結果ターミナルでvimという選択肢に行き着いたわけですが、やはりあまり使いこなせない。何とか使いこなせるようになろうとvimの操作を調べるうちに、ラインエディタというものの存在を知りました。

ラインエディタ

vi(vim)はスクリーンエディタというものに分類されるそうです。

テキストエディタといえば、画面上に編集するテキストを表示し、その上でカーソルを移動させて編集を行なうものを連想しますが、そういったエディタがスクリーンエディタと呼ばれます。

対してラインエディタでは、画面上への表示は最小限です。スクリーンエディタと異なり内容の閲覧/編集はそれぞれ独立した機能であり、目的の行を抽出、編集、更新というサイクルで編集を行います。

最初期のテキストエディタの形であり、スクリーンエディタの開発以前は主にこれが使用されていたようです。

ed の概要

ed はラインエディタの一つであり、初期の頃から存在する UNIX 上の標準的なテキストエディタの一つです。今も事実上全てのバージョンの UNIXLinux に装備されています。

ただ最近では vi や Emacs、その他のスクリーンエディタにとって代わられ ed を対話的に使用することは滅多に無いようです。ただ問題が発生したときには ed が使用可能な唯一のエディタである場合もあり、そのような場合に限って ed は対話的に使用されます。

またエディタコマンドは標準入力で受け取られるので、シェルスクリプト内で使用することが出来、そういった用途で使われることはあるようです。

edの機能

コマンドライン

ed を起動するには端末で以下のようにタイプします。オプションとファイル名を引数として指定できます。

ed [options] [file]

代表的なオプションは以下のものがあります。

オプション 長い書き方 説明
-h --help 使用法を表示して終了
-V --version バージョン情報を表示して終了
-l --loose-exit-status コマンド実行に失敗しても終了ステータス0を返す
-p STRING --prompt=STRING プロンプトとしてSTRINGを指定

モード

ed には、コマンドモードと入力モードがあります。

コマンドモードではエディタを操作するためのコマンドを入力してテキストの編集や置換、行の削除などを行っていきます。存在しないコマンドなどを入力したなどのエラー時は、?と表示されます。

入力モードでは、コマンドを実行することはできません。標準入力から入力されたデータは、 直接エディタバッファへと書き込みとされます。ピリオド1つだけの行を入力すると、入力モードを終了します。

コマンド一覧

行指定

ed では常に操作の対象となる行を指定する必要があります。

ed は現在行を管理しており、コマンドに行番号が指定されない場合は、現在行がデフォルト行として用いられます。ファイルが最初に読み出された直後は、現在行はファイルの最後の行となります。一般的に、現在行はコマンドが操作した最後の行となります。

なお行番号は1始まりです。

コマンド 内容
. 現在行
n n 行目
+n 現在行より n 行後の行
+ 現在行の1行後の行。+1と同じ
-n 現在行より n 行前の行
- 現在行より1行前の行。-1と同じ
$ ファイルの最終行
m,n m 行目からn 行目の範囲。m, nは数字または単一行指定コマンドを使用可能。e.g., 5行目から10行目を指定する場合は 5,10 、ファイル全体を指定する場合は1,$
, ファイル全体。 1,$ と同じ
; 現在行から最終行までの範囲。 .,$ と同じ
指定された行の操作

テキストの編集や置換、行の削除などは、行指定とコマンドを組み合わせて行います。以下の表では括弧書きした部分が行指定で、省略時のデフォルト動作を示しています。

コマンド 内容
(.)i 指定した行の前にテキストを追加。編集モードになる
(.)a 指定した行の後ろにテキストを追加。編集モードになる
(.,.)c 指定した範囲の行を削除して、そこにテキストを追加。編集モードになる
(.,.)d 指定した範囲の行を削除
(.,.)y 指定した範囲の行をカットバッファにコピー(yank)
(.)x カットバッファの内容を指定した行の後ろにペースト
(.,.)m(.) 左辺で指定した範囲の行を右辺で指定した行の後ろに移動。右辺には0を指定できる
(.,.+1)j 指定した範囲の行を連結
(.,.)p 指定した範囲の行を表示
(.,.)n 指定した範囲の行を行番号つきで表示
(1,$)g/reg/cmd 指定した範囲の行のうち、正規表現regと一致した文字列のある行に対し、cmdを実行
(.,.)s/reg/rep/n 指定した範囲の行のうち、正規表現regn番目に一致した文字列をrepに置き換える
(.,.)s/reg/rep/ 指定した範囲の行のうち、正規表現regと1番目に一致した文字列をrepに置き換える。s/reg/rep/1と同じ
(.,.)s/reg/rep/g 指定した範囲の行のうち、正規表現regと一致した文字列をすべてrepに置き換える
($)= 指定された行の行番号を表示
その他
コマンド 内容
u 直前のコマンド実行をアンドゥ。uコマンド自体もアンドゥできる
P コマンドモード時に、行頭にプロンプト文字列を表示。コマンドライン引数で文字列が指定されていない時は、 *が使用される。
!cmd cmd で指定したコマンドを、 sh を用いて実行
w [file] fileに編集内容を書き込み
q エディタを終了。編集内容が未保存の場合はエラー
Q エディタを終了。編集内容が未保存でも強制的に終了

ed を実際に使ってみた

edコマンドの使用例として、実際にファイルの編集を行ってみました。

とりあえず ed のバージョンを確認。1.1のようです。

$ ed --version
GNU Ed 1.1
Copyright (C) 1994 Andrew L. Moore, 2008 Antonio Diaz Diaz.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

適当なディレクトリに移動します。

$ cd /some/path
$ ls -a
./  ../

ファイルが何もないですが、せっかくなので ed で作ることにしましょう。

$ ed
P
*i
hoge hoge hoge
.
*=
1
*a
fuga fuga fuga
moge moge moge
piyo piyo piyo
.
*=
4
*w test
60
*q

最初にPコマンドを使用してプロンプトを出すようにしています。iaで行を追加。=で現在行の番号を確認しています。最後はwコマンドで"test"という名前でファイルに保存しました。

確認してみると、

$ ls
test
$ cat test
hoge hoge hoge
fuga fuga fuga
moge moge moge
piyo piyo piyo

思った通りにファイルが作成されていました。

起動時にファイル名を指定するとエラーが表示されるのですが、最後の保存時に名前を指定しなくてもよくなるようです。

$ ed test2
test2: そのようなファイルやディレクトリはありません
P
*i
hoge
.
*w
5
*q
$ ls
test  test2

次に作成したファイルを編集してみます。

$  ed test
60
P
*,n
1       hoge hoge hoge
2       fuga fuga fuga
3       moge moge moge
4       piyo piyo piyo
*2c
foo bar baz
spam ham egg
.
*,n
1       hoge hoge hoge
2       foo bar baz
3       spam ham egg
4       moge moge moge
5       piyo piyo piyo
*,s/moge/toto/g
*,n
1       hoge hoge hoge
2       foo bar baz
3       spam ham egg
4       toto toto toto
5       piyo piyo piyo
*wq
70

最初に行番号付きで現在のファイル内容を確認しました。その後cコマンドで2行目を変更し、ついでに新しい行を続けて入力しています。再度行番号付きで現在のファイル内容を確認すると、確かに2行目が変更され、その下に行が追加されていました。手入力で行の中の一部分を変更することはできないので、仮に同じ部分があったとしてもその行は全部書き直しです。

最後の保存と終了は同時に出来るみたいです。vi も同じですね!

ed 終了後にファイルの中身を確認すると、きちんと変更されていました。

$ cat test
hoge hoge hoge
foo bar baz
spam ham egg
toto toto toto
piyo piyo piyo
同じedでも環境によって違うこともある

Windowsにインストールした BusyBox 1.22.1に含まれる ed は、上でまとめたものとはオプションやコマンドが若干異なるようでした。

  • コマンドラインオプションが使えない
  • デフォルトでプロンプトが表示されている
  • プロンプト文字列は:
  • Pコマンドがない
  • 他にも違いはあるかも

おわりに

古くからあるがゆえに逆に知らなかったエディタ ed について調べてみました。

実際使ってみましたが、ファイル内が今どんな状態なのかがすぐにわからないのが少し不安に思いました。いくら軽量だとは言え普段使いするならやっぱりスクリーンエディタかな、というのが正直な感想です。ただシェルスクリプトで使うこともあるかも…。

なお今回まとめたのは ed のコマンドの中でも一部にすぎません。もっと詳しく知りたいなら参考に挙げたページや、manやinfoを見てくださいね。

参考

スクラム開発のエッセンス〜スクラムチームとスクラムイベント〜

スクラムとは

こんにちは。strongWhiteです。今回はスクラムに関する解説記事です。
スクラムとは、変化の激しいソフトウェア開発の問題に対応するための開発手法です。 ソフトウェアは建築物などの三次元的な物体とは異なり、認識しにくく不透明な存在であるため、潜在的な問題(バグなど)を早期に察知するのが難しい性質を持っています。また、問題を認識できたとしても修正などの後戻りが難しい場合があります。このようなソフトウェア開発の問題を解決するのがスクラムです。
スクラムでは、あらかじめ定めた期間内に一定の成果物を作成(開発)し、徐々にソフトウェアを構築するというアプローチを取ります。ソフトウェアに「透明性」を見出し、潜在的な問題を認識しやすくするのです。
今回の記事ではスクラムを用いた開発を始める方向けの前提知識として、スクラム開発の関係者(スクラムチーム)とスクラム開発中で発生するイベント(スクラムイベント)について解説します。

スクラムチーム

スクラム開発は、以下の役割を担う人(たち)が相互に作用し合って進捗していきます。

  • プロダクトオーナー
  • 開発チーム
  • スクラムマスター

各役割とその使命については後述します。これらの役割を担い、スクラム開発を進める人たちをスクラムチームと呼びます。

プロダクトオーナー

プロダクトオーナーは開発しようとしているプロダクトのオーナーであり、プロダクトの最終責任者です。
プロダクトオーナーは「プロダクトのビジネス的価値」に着目し、プロダクトで実現したいことに優先順位をつけてリスト化したプロダクトバックログを作成・更新・管理する役割を担います。プロダクトオーナーは開発チームにプロダクトバックログを公開することで、なぜそのプロダクトを作るのかというビジョンと優先順位を理解してもらうよう努めます。

開発チーム

開発チームはプロダクトオーナーが決定した要件を成果物として実現するメンバーの集まりです。
プロダクトの開発責任を担うのが開発チームであり、プロダクトに不具合がある場合や、プロダクトオーナーの定める品質基準に達しない場合にそれらの問題解決に努めます。

スクラムマスター

スクラムマスターはプロダクトオーナーと開発チームがスクラムを実行する手助けを行います。
スクラムマスターは現場のスクラムのルールを熟知し、スクラムチームが最高のパフォーマンスを発揮できるように働きかけます。開発チームが技術的困難に遭遇している場合は解決策を提示し、プロダクトオーナーがプロダクトバックログの更新に問題を抱えている場合はアドバイスします。また、スクラムチームの進捗に影響を及ぼす要因の排除や、スクラムの理解が不足しているメンバーに対してコーチングするなど、その役割は多種多様です。

まとめ(1)

スクラム開発における各役割とその関係の理解が少しでも進めば幸いです。
「要するにプロダクトの責任者と開発チームがいて、それらのサポーターを通して開発を進めるってこと?」
...今は恐らくこれぐらいの認識ではないでしょうか。実際にスクラムを導入されるとそれぞれの役割の重要性が見えてくるかと思います。
「役割はなんとなく理解できたけど、どのように「スクラムを実行する」の?開発以外のイベントって何?」
それでは次章以降、スクラム開発で発生するイベント(スクラムイベント)について解説します。

スクラムイベント

スクラム開発では、単に開発を進めるだけでなく、ソフトウェアの「透明性」を見出すためのアプローチを取る必要があります。そのために規則的に行われる5つのイベントがあり、これらをスクラムイベントと呼びます。

  • スプリント
  • スプリントプランニング
  • デイリースクラム
  • スプリントレビュー
  • スプリントレトロスペクティブ

スクラムイベントは定期的なミーティングとは違い、自分たちのスクラムのあり方に問題があれば解決し、より良い状況を作るために行います。このようにフィードバックを織り込んだイベントを実施することで開発を円滑に進めます。

スプリント

スプリントは開発のイテレーションのことです。スクラムチーム内で適当な期間を定めますが、通常は1週間〜3週間が多いです。
決められたサイクルで開発を進めることで、スクラムチームで完了できる仕事量を把握します。

スプリントプランニング

スプリントプランニングはスプリント開始時に行われる最初のスクラムイベントです。
「スプリント期間内で何ができるか(何をするか)」を明らかにするミーティングであり、スクラムチーム全員が参加します。プロダクトバックログで優先順位の高いものから順に完了できそうなものを選び、選んだ項目について具体的なタスク量を明確化するために適当な単位でタスクを分割してリスト化したスプリントバックログを作成します。

デイリースクラム

デイリースクラムはいわゆる「朝会」であり、昨日したこと、今日やること、課題を共有する場です。
主に開発チームが行うスクラムイベントであり、スプリント期間中は決まった時間に毎日行います。そのスプリントのゴールが達成できそうかと、日々の仕事の進捗を把握します。また、デイリースクラムにはスクラムマスターも参加します。

スプリントレビュー

スプリントレビューはスプリントの成果物を披露し、プロダクトについてフィードバックを得るためのミーティングです。スクラムチーム全員が参加します。
スクラムチームの他にステークホルダースクラムチームに所属しない会社の経営陣、あるいは顧客など)を招待する場合もあります。開発チームはスプリント期間内に達成できたことと、達成できなかったことを伝え、次回以降何をどう作っていけばいいか議論します。

スプリントレトロスペクティブ

スプリントレトロスペクティブはスプリント終了時に行われる最後のスクラムイベントです。スクラムチーム全員が参加します。
いわゆる「振り返り」であり、スクラムチームの現状を見直し、次回以降のスプリントでより良い仕事を行うための改善策を出していく場です。開発チームとスクラムマスターが中心になって進め、次回のスプリントに向けてのアクションプランを出します。

まとめ(2)

スクラム開発の進め方が理解できたでしょうか。本当はもう少し細かい話もあるのでが、ざっくりとまとめると

  • 計画→開発→お披露目→振り返り→(以下、繰り返し)

となります。イテレーションが設定されているおかげで問題に気付きやすくなり、改善や後戻りしやすいシステムになっています。これこそがスクラム開発の醍醐味であり強みでもあります。これからスクラムを始める人にとって、今回の記事が少しでも参考になれば幸いです。

新しくなった大阪オフィスで Rakus Meetup Osaka #1 を開催します!

f:id:tech-rakus:20180814160204p:plain

id:radiocat です。このたび大阪Meetupの運営委員に任命されました!

9月に東京でMeetupを開催しましたが、大阪でもやります!

rakus.connpass.com

新しくなった大阪オフィスは本当に良い環境で、広くなったセミナールームを早く活用したい!ということで移転直後から準備を進めてきました。

そんな大阪オフィスの様子は↓コチラをご覧ください。

www.wantedly.com

テーマは『大阪開発チームのチャレンジ』です

せっかくの大阪初開催ですので、大阪所属のエンジニアでトークセッションを固めました。東京を中心として盛んに行われているITエンジニアの勉強会ですが、最近は大阪でも活発に行われていて私もよく同業他社の勉強会に参加させて頂いています。せっかく、梅田駅から徒歩5分という立地でセミナールームを拡充して環境も整ってきたので、我々も一緒に大阪のIT業界を盛り上げていきたいと思っています。今後はコミュニティへの会場提供もしていきたいので、この機会に新しいオフィスを覗いてみていただければと思います。

当日のトークセッションは以下を予定しています。なお、トーク内容と順番は仮のものですので当日までに変更の可能性がありますがご了承ください。

チャットディーラーの高速開発を支えるLaravel

吉元和仁(よしもとかずひと)

今年夏に開催された PHPカンファレンス関西 2018 の登壇内容をベースにお話しします。10年以上PHPでノンフレームワークにより開発・運用されてきた主力サービス(メールディーラー)の開発チームが、新規に姉妹サービス(チャットディーラー)を立ち上げる際に Laravel を選択しました。 開発期間半年というスピードが求められる中で、Laravel での新規サービス立ち上げのチャレンジをご紹介します。

Why Mob Programming? - モブプロという働き方 -

大平直宏(おおひらなおひろ)

大阪の楽楽精算の開発チームでは、スクラム開発を取り入れて新機能の開発に取り組んでいます。急成長するサービスの開発を支えるためこの1年間で4人のメンバーが増えており、メンバー同士の知識共有が課題となっています。アジャイルな開発を推進するために取り入れているモブプログラミングのチャレンジをご紹介します。

トウダン・ジャーニー

川並裕(かわなみゆう)

今年の夏に開催された PHP カンファレンス関西 2018 で、会社として初めて技術イベントに協賛し、2 名のエンジニアが登壇しました。開発組織を横断した登壇推進チームが業務として登壇プロジェクトを推進したチャレンジをご紹介します。

大阪のエンジニア同士で交流しましょう!

今回は参加者のみなさまの中からもLTを募集いたします。テーマは同じく「チャレンジ」です。みなさまが普段チャレンジしていることを共有していただければと思います。そしてトークセッション後には交流会も開催します。弊社のエンジニアも含めて参加者同士で情報を交換し合い、エンジニア同士の交流を深めていければと思っています。

f:id:radiocat:20181106013951p:plain:w500

会場の場所や参加方法については以下のconnpassに掲載していますのでご確認のうえお申し込みください。みなさまのご参加をお待ちしております!

rakus.connpass.com

大阪開発ビアバッシュ〜10月「行ってきた特集」〜

はじめに

こんにちは、strongWhiteです。ラクスでは毎月1回、開発チーム主催のビアバッシュを開催しています。
ビアバッシュとはビールや軽食をいただきながら技術内容について楽しく語り合う交流会です。
今回は10月に大阪で開催したビアバッシュの内容を記事にしたいと思います(過去の開催も記事になっていますので、よろしければ下記をご覧ください)。
tech-blog.rakus.co.jp

今回は「行ってきた特集」

大阪のビアバッシュは決められたテーマに沿って発表する「テーマ枠」と、自由なテーマで発表する「自由枠」の2セッションを設けて発表を進めます。
また、「自由枠」は質疑応答ありで15分間の発表と質疑応答なしで5分間の発表(LT枠)に分かれます。
10月のテーマは「行ってきた特集」であり、各々がこれまで参加した勉強会やセミナーの様子と、そこで得た学びを共有していただきました。
今回の記事では主に「テーマ枠」の発表の様子をご紹介いたします。

行ってきた特集(テーマ枠)

京都アジャイル勉強会に行ってきた

筆者が「京都アジャイル勉強会」に赴き、スクラムについて学んだことを発表いたしました。
スクラムとは「ソフトウェアに変更はつきもの」という前提から、要求や仕様変更に柔軟に対応するために生まれたソフトウェア開発手法です。
もともと私の所属するチームではスクラムによる開発を推進しており、私自身のスクラムに対する知識理解の向上を目的に勉強会に出席しました。
この勉強会はディスカッション形式で、会場にはスクラムを実践する人たちが集まります。特にタイムボックスはなく、開始時間になると各々が日頃からスクラムについて感じている課題や疑問を議論し合います。同じ苦難や困難に立ち向かう者同士、お互いにスクラムに対する理解を深め合うのがこの勉強会の目的です。
筆者は個人的に「スプリントバックログの作成に時間がかかる問題」を抱えており、問題解決のヒントを得るため勉強会へと足を運びました。現在は、勉強会で得た知見をもとに自身のスクラムに対する姿勢の見直しを行なっています。

ハッカソンあるある

ハッカソンに参加しているとこういう場面絶対にある!という「ハッカソンあるある」を発表していただきました。
ハッカソンによく行かれる方は、↓と同じようなことを感じられたことがあるのではないでしょうか?

  • 名刺は切れる
  • 名刺を交換すると世の中は狭いことがわかる
  • ハードウェアがわかるとありがたがられる
  • ネットワークはもっとありがたがられる etc...

ハッカソンの場合、(テーマにもよりますが)プログラマーよりハードウェアやネットワーク面に強い方がいると心強いと思います。
突発的なネットワーク障害に遭遇した場合に、すぐに原因を究明して修正してくれると勉強会もスムーズに進行するかと思います。
筆者はハッカソンに参加した経験はないですが、「名刺を交換すると世の中は狭いことがわかる」はよくわかります。
最近も、プログラミングの外部勉強会に参加したのですが、そこで大学時代の同期に出会いました。以前にエンジニアになったとは聞いていたのですが、世の中は狭いものです...「あるある」は共感するものがあるととても面白いです。

今回から新オフィスで発表

ラクスは9月末に大阪オフィスを毎日インテシオから梅田ゲートタワーへ移転しました。今回のビアバッシュは引っ越し後初のビアバッシュとなりました。
年々新卒をはじめ、社員の増加に伴ってビアバッシュの参加者も増加してきたため、旧オフィスでは開催スペースの圧迫化が問題だったのですが、新オフィスでは広々とした開催スペースとなり、より新鮮な気持ちでビアバッシュを楽しむことができました。

f:id:strongWhite:20181029205823j:plain:w500:h500

おわりに

いかがでしたでしょうか。今後も定期的にビアバッシュの様子をお伝えしていこうと思います。次回のテーマは「新機能特集」を予定しています。
最近の弊社商品のリリース機能を紹介できたらと思います。どのような発表になるか楽しみです。

参考

JMeterのシナリオ作成がうまくいかない!そんなときのトラブルシューティングガイド

f:id:northmky:20181030144050p:plain

はじめに

こんにちは、開発エンジニアのnorth_mkyです。 先日業務にて負荷検証をJMeterで行うことになり、弊社エンジニアが書いた下記の記事を読みつつ複数のシナリオ作成を行いました。

tech-blog.rakus.co.jp

ですが最初の1シナリオの作成で全然想定している動作にならず、予想よりも3倍ほど時間がかかってしまいました。。。

シナリオ作成にあたって必要な知識として、もちろんシナリオを作成する対象の画面の仕様理解も必要ですが、思った以上に小さな設定ミスが多いです。 この記事では原因箇所に気づくまでのプチ・ベストプラクティスをご紹介したいと思います。

対象読者

シナリオを作成している方には有益な記事になっていると思います。 特に少し複雑なシナリオを作成しようとしている方にはぜひ一度みていただけたらと思います。

  • JMeterのシナリオ実行はしたことがあるけどシナリオ作成は初めて/始めたばっかりの方
  • シナリオ開始から終了までの間の画面遷移が多い(サンプラーが多い)
  • 特定のリクエストパラメータの値を外部ファイル(CSV)から読み込んでセットするようにしている
  • リクエストパラメータが動的に変わる画面遷移がある

シナリオ作成トラブルシューティングガイド

ミスの原因調査が簡単なものから除々に特定が難しい原因調査へとステップを踏むと効率的ですのでそのような構成にしました。シナリオデバッグをしていると最初は直しても直しても違うエラーがでてくる...と思わせてくるところがあるのですが、多くは簡単な設定ミスなので、気にせず淡々と確認していきましょう!

Step0. 準備

まず最初にデバッグができるようにする設定が必要です。テスト計画の直下に以下2点のコンポーネントを追加します。設定を適切に行うと実際に実行したときのリクエスト・レスポンスの情報がすべて見れるようになります。注意なのですが、デバッグ用に追加するので実際に負荷検証を流すときには必ず無効にしてください。 正しく計測ができない可能性があります。

  1. リスナー > シンプルデータライタ
    実行結果をファイル出力するコンポーネント。以下のようなxmlファイル形式に設定する f:id:northmky:20181030092811j:plain

  2. リスナー > 結果をツリーで表示
    1.で出力したファイルを読み込んでリクエスト・レスポンスをわかりやすい形で表示するコンポーネント

    • 失敗したリクエストは赤字にしてくれる 1
    • まちがっていそうなパラメータを赤字にしてくれる
    • URLエンコードされたパラメータをデコードして表示してくれる

Step1. jmeter.logを確認する

  • ポイント
    • 外部ファイルが正しく読み込まれているか
      • パスの指定が誤っていないか
      • 外部ファイルの書き方とシナリオで設定したカラムの順番、情報に誤りがないか

いざテスト実行してみたものの、本来ならもっと実行に時間がかかるところが一瞬で実行が終わってしまった...という場合はそもそもシナリオを実行するための準備に不足がある可能性が高いです。そのときはまずjmeter.logを確認します。jmeter.logは実行ログとなっており、外部ファイルの読み込みがうまく行っていない場合はエラーとして記録を残してくれます。

jmeter.logをみて原因箇所が推測できたら、設定エレメント > CSV Data Set Configの設定内容であったり指定したファイルの形式があっているか確認し適宜修正してください。

Step2. リクエストパラメータの値が正しいか確認する

Step0 で設定したリスナー > 結果をツリーで表示を見て実際にアクセスしたときのリクエストパラメータを見ていきます。 このパラメータの設定のミスが割と多いので下記ポイント4つを順番に見ていくと良いと思います。

  • ポイント
    1. 変数名がそのまま出ていないか
    2. 適切にURLエンコードをしているか
    3. 前画面の値を取得する後処理 > 正規表現抽出で設定した変数名をパラメータにセットし忘れていないか
    4. 受け渡している変数パラメータの値が前画面から正しく取得されているか

1. 変数名がそのまま出ていないか
リクエストパラメータの値を見ればすぐに見つけられます。(${hoge})
大抵原因は
サンプラーに設定した変数名が定義した変数名と違う」
後処理 > 正規表現抽出正規表現が誤っていて抽出結果が空」
いづれかになります。

2. 適切にURLエンコードをしているか
マルチバイト文字であったりURLでメタ文字や利用できない文字が含まれるパラメータをURLエンコードしないでリクエストを投げているか、逆にすでにURLエンコードしているところに誤って二重でURLエンコードを行ってしまっている場合があります。「URL Encode?」チェックボックスを確認してみてください。 HTTPプロキシをたててリクエストを記録した場合、よしなにJMeterがつけてくれている場合が多いですが、正規表現を組んだりしていくうちにチェックが外れてしまった/ついてしまったことがでてくるかもしれません。緻密な作業でミスが起きやすいので自分を責めず、そしてめげずに進めていきましょう...(経験談)

3. 前画面の値を取得する後処理 > 正規表現抽出で設定した変数名をパラメータにセットし忘れていないか
リクエストを記録した場合、その記録していた値のままになっているかもしれません。もう一度変数の設定漏れがないか確認してみてください。

4. 受け渡している変数パラメータの値が前画面から正しく取得されているか
1.で書いた原因に似ていますが、正規表現抽出で前画面から抽出自体はできていても余計な文字も拾ってきていてエラーになっている可能性があります。リスナー > 結果をツリーで表示ではレスポンスのbodyに対して文字列検索ができるため、リクエストパラメータにセットした値が前画面のレスポンス内で引っかかるか確認してみてください。

Step3. シナリオ実行がどこのリクエストで落ちたか実行順に見て特定する

  • ポイント
    • リクエスト/レスポンスごとに想定の挙動になっているか確認する
      • webサーバ/アプリログなど
      • 画面

Step1,2を確認しても解消しない場合はいよいよシナリオをしらみつぶしに確認する作業になります。複数箇所でエラーが出ている場合は、だいたい上のエラーが引き継がれてエラーがでることが多いので焦る気持ちを抑えて上から順番に見ていきます。 レスポンスでエラー画面やエラー文言があれば、そこからコケた原因を考えられるかと思います。

アサーションを適切に設定していないとエラーなのに見た目は成功を表すグリーンのアイコンになるのでより原因特定が難しくなりますよね。後世のために原因がわかったらアサーションを追加して次もし引っかかったときは失敗を表すレッドのアイコンになるようにすると良いと思います。

おわりに

いかがでしたでしょうか。長いシナリオだったりパラメータの多い画面の遷移となるとシナリオに小さいミスが起きやすくなる割に原因特定に時間がかかり気味になります。 そんなときにこの記事をみていただいて皆さんのもやもやや苦痛が少しでも和らげば幸いです。


  1. 失敗かかどうかはアプリケーションに依存するのでサンプラー > アサーションで適宜エラーを定義する必要があります

連休の狭間に失敗して学んだスプリントでコールド負けしないための鉄則

id:radiocat です。

スクラム銀の弾丸ではないので、いつもうまくいくとは限りません。今回は私たちのチームの失敗事例をご紹介します。

以前の投稿 でも紹介しましたが、私たちのチームは1週間スプリントを採用しています。以下のように木曜に計画を立ててスタートし、翌週木曜にレビューを行う流れです。

f:id:radiocat:20181022202656p:plain:w500

ご覧のように開発に注力できる期間は実質4日しかありません。油断するとすぐにレビューの日を迎えるので緊張感があります。そして、その緊張感にさらに拍車をかける要素がスプリント期間中の「休日」です。

連休の狭間の期間はスクラムを進めるべきか?

ご存知の通り、2018年の9月は2週続けて月曜が休日となる期間がありました。このままだと開発が実質3日しかないスプリントが2回続きます。

f:id:radiocat:20181024002916p:plain:w500

さらに、この連休期間を利用して2人の主力メンバーが休暇を取ることになりました。5人チームなので開発力は半減します。チームはこの期間をどう過ごすべきでしょうか?

連休の狭間もスプリントを進める選択

ご察しのとおり、我々はこのままスプリントを進めました。とはいえ、さすがに丸腰でこの状況に立ち向かうほどの度胸はないので、我々なりに対策を立てて取り組もうとしました。まずはその対策をご紹介します。

連休期間のスクラムイベントは中止する

全員揃っていない状態なのでスプリントレビューは1週間スキップすることにしました。ただ、連休前の金曜から着手したスプリントを中断するのはもったいないので以下のように進めることにしました。

個々の開発は進めて良い

中途半端に作業を中断して別の事をやるのも気持ちが悪いので、出社しているメンバーは出来る範囲で開発は進めておくことにしました。ただし主力不在で開発チーム内でのフォローやレビューは手薄になるので、無理せず出来る範囲で作業を進めて、主力メンバーのレビューが必要な作業などは連休明けまで保留するようにしました。

狭間の4日間で1日分の実績を目標にする

主力2人の休暇でチーム全体のパフォーマンスは低下しますが、残りのメンバーだけでも4日あれば普段の1日分ぐらいの実績は充分達成出来るだろうと考えました。そうすることで結果的に2週間の合計が4日分の実績となるので、いつも進めている1週間スプリントと同じぐらいのベロシティを目指すことになり、感覚的にもわかりやすい目標になります。主力不在とはいえ4日で1日分なので、出勤しているメンバーにも負担がかからないはずです。

f:id:radiocat:20181028182142p:plain:w500

プランニングと共有をいつも以上にしっかり行う

念のため、休暇の前日に改めて主力メンバーが考えているスプリント中のタスクの進め方をチームのメンバーへしっかり共有して引き継いでもらいました。

下がりきらなかったバーンダウンチャート

結果的にこのスプリントでは、残タスク量を示すバーンダウンチャートの実績が次のようになりました。

f:id:radiocat:20181022214629p:plain:w500

微妙な結果です。大負けというほどでもなく、微妙な感じが逆に気持ち悪いくらいです。しかし、このスプリントのふりかえりはチームに疲弊感が漂い、私も含めてみんなモヤっとした状態で改善アクションもうまくまとめられないままスプリントは終了しました。

なぜ計画どおりにスプリントが終わらなかったのか?

いったい何が問題だったのか、後日スクラムコーチに相談してみると3つの課題が見えてきました。

スプリントを進めるのに十分な体制ではなかった

私たちのチームのメンバー構成を改めて整理すると次のようになっています。

f:id:radiocat:20181024003201p:plain:w500

現在進めているプロジェクトの在籍期間が1年以上のメンバーが誰もいない状況で、目に見える人数以上にチームの体制は弱くなっています。さらに実はこのスプリントの前半の主力メンバーが休暇に入る直前まで、チームを助けるべきスクラムマスターは出張先からリモートでチームの活動に参加しており、開発チームの状況を詳細まで把握出来ない状況にありました。いつも以上にしっかり共有してから休暇に入るという事前の対策は開発チーム内の個々のメンバーの感覚に託されており、客観的にみても対策できているといえる状態かどうかは誰もわからない状況になっていました。

バックログがReadyではなかった

さて、上記のバーンダウンチャートは狭間の4日間を1日の実績としてまとめていますが、これをそれぞれの日ごとの実績に分けてみると次のような実績になっていました。

f:id:radiocat:20181022214005p:plain:w500

主力メンバーが休暇に入った初日から実績が上がらず、残タスクが全く減っていません。すでに危険な状況に突入していることがわかります。実はこのとき、プランニング時点の想定が覆ってそのままではタスクを進められないことがわかりました。スクラムマスターはチームの状況を察知し、いったんタスクの終了条件を見直したりスプリントのゴールを見直すなどの調整を行い、一度は残タスクが減りましたが、すぐにまた別の問題が発生して逆に残タスクが増えてしまいました。

f:id:radiocat:20181028191543p:plain:w500

結果的にこの時着手していたバックログは最初からReadyではなかったのです。つまりこのスプリントは前半時点ですでにコールド負けが決まっていました。

しかし、1つ目の原因にあるとおり、チームの体制が不十分で、前半時点ではこの状況を正しく判断できるメンバーがいませんでした。スクラムマスターはチームの状況を正確に判断出来るだけの情報をキャッチできていなかったため場当たり的な対策を取ってしまい、結果的にはコールド負けしたチームにそのまま試合続行を促すことになってしまいました。

仕掛りがたまっていて手当てが追いつかず

チームはそれでもなんとかスプリントのゴールを目指そうと取り組みました。休暇が明けてから、主力メンバーの頑張りによってなんとか持ち直しますが、計画していたゴールには到達できませんでした。

バーンダウンチャートを見るとスプリントの最後で残タスクの消化が少なくなっています。実はこのとき、仕掛中のタスクがたくさ増えすぎて経験のある主力メンバーでも残りの期間で全てを手当することは出来なくなっていました。スプリント前半に発生した問題をなんとかしようとして計画時の想定とは違う進め方をしたり、いったん保留して他のタスクに手を出した結果、想定以上に仕掛り中のタスクが増えてしまったのです。

f:id:radiocat:20181028192522p:plain:w500

コールド負けしない鉄則

実はこれらの原因は既にスクラムコーチの吉羽さんが別の場で示されているものでした。

slide.meguro.ryuzee.com

この資料の中でアジャイル開発でコールド負けしないための5つのポイントが挙げられています。

  1. 十分条件で開始する
  2. Readyなプロダクトバックログ項目だけ着手する
  3. 同時の仕掛りを少なくする
  4. フィードバックサイクルを回し続ける
  5. 技術に投資し続ける

我々は5つのポイントのうち3つを犯してしまっていました。コールド負けしてしまっても仕方ないですね。スプリントを進めるにあたり、改めてこれらの3つのポイントが重要であることを痛感しました。

  • 開始するのに十分な条件か?
  • バックログはReadyになっているか?
  • 仕掛りが増えすぎる進め方をしていないか?

それでも、我々はこの1回のスプリントでとても大きな学びを得たとも思っています。今後はこれらをしっかり意識してチームで取り組もうとしています。


REGIONAL SCRUM GATHERING TOKYO 2019 のCfPを出しました!

2019年1月9日〜11日に大崎ブライトコアホールで1年に1度のスクラムのビックイベント「REGIONAL SCRUM GATHERING TOKYO 2019」が開催されます。

2019.scrumgatheringtokyo.org

私たちのスクラムの取り組みを多くの方に知っていただき、そして私たち自身が学びを得るためにプロポーザルに応募しました。下記のリンクをご確認いただき、ご興味のあるかたは是非likeをお願いします(締切が10月末ですのでご注意ください)。

confengine.com

REGIONAL SCRUM GATHERING TOKYOでは毎回たくさんの素晴らしいセッションが行われますので、スクラムに興味のあるかたはぜひチケットを入手してご参加いただければと思います。

知っていると便利かも?psqlコマンドのオプション4選

f:id:FM_Harmony:20181022092416p:plain

初めに

こんにちは!エンジニアのid:FM_Harmonyです。

前回はgitのfetchコマンドについて、記事を投稿しました。 tech-blog.rakus.co.jp

今回はpostgreSQLの対話型ターミナル、psqlのオプションについて紹介したいと思います。
普段の業務でも、psqlコマンドの-fオプションや-cオプションを利用してクエリを発行する機会が多いのですが、psqlには他にも便利なオプションが備わっています。
多くのオプションが存在しますが、今回はその中でも個人的に便利だと思う4つのオプションについて紹介します。

続きを読む
Copyright © RAKUS Co., Ltd. All rights reserved.