Quantcast
Channel: SHANON Engineer's Blog
Viewing all 210 articles
Browse latest View live

エンジニアだってデザインしたい!モックアップツールを使ってみる

$
0
0


こんにちは!ueharak です。

デザインと言っても絵心のハナシではありません。
ここでいうデザインとは設計のことです。モックアップはそのための下書きのようなものです。
気軽に作って調整を繰り返すことで、プロダクトの輪郭を徐々に明らかにすることができる便利なツールです。

今日は私がよく使う Balsamiq Mockups を紹介したいと思います。
これは手書き風のモックアップを簡単に作ることができる便利なツールです。
素早く編集するための工夫がなされており、使っていてとても気持ちが良いものです。

画面はこんな感じ:


上部のコンポーンネントを中央のペインにドラッグして作業します。


例えばコンボボックスはこのようになります。


この文字の部分を編集すると


いい感じに描画してくれます。



面倒なテーブルも


この通り。


チェックボックスなどの記法 [X] もあるため、サクサクとコンポーネントを配置できます。
ご覧の通り、このツールの特徴は各コンポーネントを簡易なテキスト表現で記述することができる点にあります。テーブルも CSV のように記述して貼り付けるだけで作ることができます。いちいち各要素にテキストを入れて位置を調節するといった手間が一切不要であるため、モックアップに集中することができます。

ダイアログボックスも作ってみましょう。


Mac と Windows では「OK」と「キャンセル」が逆なのはご存知ですか?
どちらを自然と感じるかによって、自分が Mac 派なのか Windows 派なのか分かると思います。
(ちなみに私は Windows 派です)

続いてボタンがたくさんあるものを作ってみましょう。
ボタンがたくさんあると言えばそう、電話と電卓ですね!


こちらもご存知の方も多いと思いますが、キーパッドの配列が異なっています。
配列を入れ替えてしまうと違和感があって使いづらいものになるでしょうね。

身近なところにも意外と同じに見えて異なる配置・配列があるものです。
デザインの際はこうした暗黙知をしっかり意識し、利用者に違和感のないものを作りたいものです。

みなさんもぜひ、モックアップツールでプロトタイプを作ってみてはいかがでしょうか。

それでは!


Scala 初心者が Gatling をぶっ放して負荷テストをやってみました

$
0
0
みなさま、こんにちは! munepom です。
最近、負荷テストツールの Gatlingを使い始めましたので、ちょっと記事にしておきます。

事の発端は、先月の JJUG ナイトセミナーにて。
Apache JMeterがめっちゃdisられていました
Gatling という負荷テストツールが Apache JMeter よりも良いのではないか?と紹介されていました。

どんなものかと思い、調べてみると、、、、、、
レポート画面が見やすいですね!
応答時間の分布や、同時実行ユーザ数あたりの応答時間の分布などなど。
これは使ってみたい!と思い、いざセットアップを行ったわけです。
が...
これ、Scala の DSL でシナリオを書くんですね。
自分、Scala 開発未経験なのですが。
大丈夫でしょうか...

まあ、Web で情報集めれば何とかなるでしょ!
ということで、実質 1 日、試行錯誤した末のセットアップ手順です。

IntelliJ IDEA CE 14.1.5 + sbt 0.13.9 + Gatling 2.1.7 という構成で、
sbt test 実行により負荷テストを行う場合です。
(Windows 7 Professional と、Mac OS X Yosemite にて確認しました)
(一応、Eclipse + Scala IDE + Gradle という構成でも実行できたのですが、sbt を利用した方法を書いておきますね。)

1. sbt (Simple Build Tool) インストール

最終的に Terminal で sbt を実行するため、事前にインストールしておきました。
Windows の場合は、.msi ファイルを実行するとインストールできました。
Mac の場合は、homebrew でインストールすることもできますが、
このブログを書いている段階では、バージョン 0.13.7 と古いバージョンでしたので、
Installing sbt manuallyを参考に、0.13.9 を手動でインストールしておきました。

2. IDE (統合開発環境) インストール

Scala 開発の IDE といえば、IntelliJ IDEA
ということで、無料版の Community Edition をダウンロードして、インストールしました。
※ インストール後は、下記設定を行いました。
  1. Configure → Plugins → Browse repositories より、Scala をインストールしました (IntelliJ インストール時に行っても良いですね)。
  2. Configure → Project Defaults → Settings → Editor → File Encodings にて、Project Encoding と Default encoding for properties files を設定しておくと、後で幸せになれると思います。
  3. Configure → Project Defaults → Settings → Build, Execution, Deployment → SBT → Launcher (sbt-launch.jar) にて、Custon を選択し、インストール済みの sbt-launch.jar のパスを指定しました。
  4. Configure → Project Defaults → Project Structure → Platform Settings → SDKs にて、緑色の + を選択し、JDK を選択しておきました。

3. SBT プロジェクト作成

IntelliJ 起動後、Create New Project -> Scala -> SBT を選択し、
Project name に適当なプロジェクト名を入力しました。(今回は、GatlingIdea としておきました。)
Finish を選択し、プロジェクト管理画面が開かれた後、Refresh 完了を待ちました。
※ こんなエラーログが出るかもですが、気にせず .sbt 設定へ進みましょう。

11:47:07 SBT project import
[warn] [FAILED ] org.scala-sbt#compiler-interface;0.13.8!compiler-interface.jar(src): (0ms)
[warn] ==== typesafe-ivy-releases: tried
[warn] https://repo.typesafe.com/typesafe/ivy-releases/org.scala-sbt/compiler-interface/0.13.8/srcs/compiler-interface-sources.jar
[warn] ==== sbt-plugin-releases: tried
[warn] https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/org.scala-sbt/compiler-interface/0.13.8/srcs/compiler-interface-sources.jar
[warn] ==== local: tried
[warn] C:\Users\hogehoge\.ivy2\local\org.scala-sbt\compiler-interface\0.13.8\srcs\compiler-interface-sources.jar
[warn] ==== public: tried
[warn] https://repo1.maven.org/maven2/org/scala-sbt/compiler-interface/0.13.8/compiler-interface-0.13.8-sources.jar
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] :: FAILED DOWNLOADS ::
[warn] :: ^ see resolution messages for details ^ ::
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] :: org.scala-sbt#compiler... (show balloon)
※ compiler-interface.jar は、sbt コマンド実行時に作成されるようでしたので。(おそらく、sbt 実行時に Scala バージョンをチェックし、動的に変更できるようにしてあるのでしょう。)

4. .sbt 設定

※ Gatling のバージョンにより、設定方法が変わる可能性がありますので、公式サイトを確認してください。
build.sbt

// "Expression Type (DslEntry) must conform to Setting[_] in SBT file"という警告が出ますが、気にしないでおきます。
// Stack Overflow でも、解決策見つからず...
enablePlugins(GatlingPlugin)

name := "GatlingIdea"

version := "1.0"

scalaVersion := "2.11.7"

// DNS の TTL を 0 にしたい場合など、Java のオプションを指定可能なようです。
// SSL の証明書チェックは、Gatling では行われないようなので、SSL 証明書チェックを無視する場合の -Djsse.enableSNIExtension=false 設定はいらない?
// javaOptions in Gatling := overrideDefaultJavaOptions("-Xms1G", "-Xmx2G", "-Dsun.net.inetaddr.ttl=0")

libraryDependencies ++= Seq(
"io.gatling.highcharts" % "gatling-charts-highcharts" % "2.1.7" % "test",
"io.gatling" % "gatling-test-framework" % "2.1.7" % "test"
)
project/plugins.sbt

logLevel := Level.Warn

addSbtPlugin("io.gatling" % "gatling-sbt" % "2.1.7")
ここまで完了したら、一旦、Project Refresh を実行しておきました。
(View → Tool Windows → SBT で開かれる画面の回転矢印アイコンを選択すると、実行されました。)

5. テスト用ソースコード作成

src/test/scala-2.11 ディレクトリに gatling.simulations パッケージを作成後、
TestIdea.scala ファイルを作成しました。
TestIdea.scala

package gatling.simulations

import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._

class TestIdea extends Simulation {
// URL の最後に "/"を付けると、テストが通りまへん
val httpLocal = http.baseURL("http://localhost")

// Header 設定も可能っぽいです
val httpDev = http
.baseURL("http://dev-localhost")
.acceptHeader("text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8")
.doNotTrackHeader("1")
.acceptLanguageHeader("en-US,en;q=0.5")
.acceptEncodingHeader("gzip, deflate")
.userAgentHeader("Mozilla/5.0 (Windows NT 6.1; rv:41.0) Gecko/20100101 Firefox/41.0")

var scn = scenario("Load Test").exec(http("Munepom").get("/munepom").check(status.is(200)))

var scnCheckBody = scenario("Check Body")
.exec(
http("Add").get("/munepom/add")
.check(
// 不正な XML (???) だと、XPath 解析時に SAXParseException が発生しました
// GHE にアクセスしてみた場合、こんなエラーログが
////////
// Error on line 49 column 67
// SXXP0003: Error reported by XML parser:
// 要素タイプ"meta"に関連付けられている属性名"data-pjax-transient"の後には、' = '
//文字が必要です。
//15:56:03.297 [WARN ] i.g.h.a.AsyncHandlerActor - Request 'GHE Redirect 1' failed
//: xpath(/html/head/meta[@name='csrf-param']/@content).find(0).exists failed, cou
//ld not prepare: Could not parse response into a DOM Document: org.xml.sax.SAXPar
//seException; lineNumber: 49; columnNumber: 67; 要素タイプ"meta"に関連付けられて
//いる属性名"data-pjax-transient"の後には、' = '文字が必要です。
////////
// xpath("//input[@value='${aaaa_value}']/@id").saveAs("aaaa_id"),
// css("#hoge", "data-fuga").saveAs("id_hoge_data_fuga"), // CSS セレクタが利用可能っぽいです
// regex("""<input id="HogeText" type="text" value="(.*)" />""").saveAs("hoge_text_value"), // 正規表現により、抽出も可能っぽいです
// bodyString.transform(string => string).saveAs("response_body") // response body を確認したい場合は、一旦 Session へ突っ込んでおきます
)
)
.exec(session => { // Session オブジェクトに格納された情報を、key で参照できました
// println("--aaaa_id: " + session("aaaa_id"))
// println("--id_hoge_data_fuga: " + session("id_hoge_data_fuga"))
// println("--hoge_text_value: " + session("hoge_text_value"))
// println("--body: " + session("response_body"))
session // これをお忘れなきよう (ハマりました...)
})

var scnFullThrottle = scenario("Full Throttle")
.during(1 minute) { // wait 無しで打ち放題!
exec(
http("Stress Test").get("/stress/test"))
}

// setUp は、一度しか実行できません。内部に、シナリオをごっそり書くのはアリっぽいです
setUp(
scn.inject(atOnceUsers(2)).protocols(httpLocal), // 同時アクセス2ユーザ
scnCheckBody.inject(atOnceUsers(2)).protocols(httpLocal),
// scnFullThrottle.inject(
// rampUsersPerSec(2) to(10) during(60 seconds), // 1秒あたりの同時アクセス2ユーザでアクセスを開始し、60秒間で10ユーザまで増やす
// constantUsersPerSec(10) during(60 seconds) // 1秒あたりの同時アクセス10ユーザで、60秒アクセスを行う
// ).protocols(httpLocal),
scnFullThrottle.inject(atOnceUsers(2)).protocols(httpDev)
)
}

6. Gatling 発射!

IntelliJ の画面左下のランチャーより、Terminal を選択し、
Terminal に sbt test を入力後、
Enter を押して実行しました。
※ パッケージのダウンロード終了後、compiler-interface のコンパイルを確認できました。

...
[info] Compiling 1 Scala source to C:\Users\hogehoge\IdeaProjects\GatlingIdea\target\scala-2.11\test-classes...
[info] 'compiler-interface' not yet compiled for Scala 2.11.7. Compiling...
[info] Compilation completed in 13.246 s
...
実行が完了すると、レポートが作成されます。

...
Reports generated in 1s.
Please open the following file: C:\Users\hogehoge\IdeaProjects\GatlingIdea\target\gatling\testidea-1444786144574\index.html
[info] Simulation TestIdea successful.
[info] Simulation(s) execution ended.
[success] Total time: 79 s, completed 2015/10/14 10:30:06

7. レポート確認

あとは、作成されたレポートをブラウザで表示するだけです!

Windows の場合は、Terminal で
start chrome "filepath"
を実行すると、Chrome で閲覧可能です。

Mac なら、Terminal で
open "filepath"
を実行すると、デフォルト設定のブラウザで閲覧できますね。

負荷テスト結果概要 (ソート可能っぽいです)

レスポンス時間の分布グラフ

レスポンス時間のパーセンタイルグラフ

レイテンシーのパーセンタイルグラフ

などなど。
グラフの拡大もできるので、便利です!
Qiita の情報や、めっちゃ役立つサンプルコードに助けられました。
ありがとうございます!
今夜の JJUG ナイトセミナーも楽しみですねん。

あ、※ DDoS 攻撃厳禁ですよーーー!
Enjoy!

Java Casual Talks に行ってきたよ #javacasual

$
0
0
こんにちは!ueharak です。
Java Casual Talks #1 に行ってきたよ!(カジュアルな語り口)。



カジュアルトークということで会場もカジュアルな雰囲気。
参加もカジュアルなようで開始は5分延期。

100名の募集に対し来場は半分程度の模様。ドタキャンは避けたいですね。

5分経って、さあ始めましょう!とジョブキューの話が始まるかと思いきや、登壇者がラップトップをスクリーンにつなげるとなぜかマシンがシャットダウン。順番を変えて次の登壇者に、と思ったらまた強制リブート。HDMI ケーブルを挿すとリブートされてしまうという謎の事態にざわつく会場。


HDMI はダメだ、VGA にしよう、とあれこれするも時間はカジュアルに流れ、登壇予定者が2名連続で後回しになるという事態に。

3人目の方は VGA で挑戦…

ところでヒカリエ27階はたいへん眺めがよいですね。

…VGA でつないだ結果、スクリーンにスライドが映し出されて拍手喝采の会場!


カジュアルにトラブルシュートする話が始まりました。


要約すると:
・ログを取れ
・(スタックトレースの)英語を読め
という大変ごもっともな話。HeapStats というツールは今後 Java でトラブルシュートする機会があればぜひ使ってみたいと思いました。

3名のトークがつつがなく進行し、時間が押していることもあり後半戦は休憩ナシで始めようとしたところ、VGA を挿したにも関わらずマシンがまたしてもクラッシュ!

結果的に休憩する事態に。

なんとか復旧してカジュアルにスレッドダンプの話。



このスライドは二面同時展開システムを採用しており、
スライドの左側:スレッドダンプの話
右:アーチェリーの基礎知識
を同時に紹介するという画期的なものでした。
(発表自体は左側で進行、「そんなの知っているよ」という人は右側を読むというスタイル)

おそらく新しい勉強会の企画ということで来場者の関心がどのあたりにあるかを見極めるのが難しかったのでしょう。保険としてスライドの右側にどんな人にも新しい知見が得られるようなネタを仕込むというオモテナシに感動しました。

その他ジョブキューの話(リベンジ)、Java で GPU の話、LT 等盛りだくさんで大変勉強になりました!

会場を提供してくださった LINE さん、主催の @tokuhirom さん、@studio3104 さん、進行の @yappo さん、受付&ビール&ピザを手配してくださった @941 さん、ありがとうございました!




それでは!

CloudSign(クラウドサイン)を試してみたよ

$
0
0
こんにちは!ueharak です。

先日社内で CloudSign(クラウドサイン)の話題が出て、面白そうだったので試してみました。



CloudSign とは以下の特徴を持つクラウドのプラットフォームとのことです。
  • 契約書をクラウドで管理できる
  • 「押印」により電子署名できる
  • 印紙代が不要

ペーパーワークがかなりシンプルになって良さそうですね!

というわけで、Free プランでアカウントを作成し、「肩もみ委託契約」を締結してみました。


まずは試してみる

メールアドレスとパスワードを入れると



アクティベート用のメールが来るので、ボタンを押してアカウント作成です。簡単!



ログインできたので「新しい書類の送信」をクリック



契約書類(PDF)をドロップ、タイトルと名称を記入して次へ
(肩もみ委託契約)



宛先を記入して次へ
(肩もみ委託契約を担当者へ送付するための設定)



PDF の「押印」してほしい場所に押印マークをドロップ
(押印してもらうことで肩もみ委託契約が締結される)



技術的には「同意」のタイミングで電子署名することで、書類が改ざんされていないことを担保しているもよう



内容を確認して問題なければ送信



送信した契約書は「先方確認中」になる



先方にメールが送信される
先方はこのメールから CloudSign へアクセスする



先方はメールのリンクから書類を開く



届いた書類に「押印」する

 


押印できたので同意ボタンをクリック



めでたく書類の作成が完了!



完成した書類は委託側のダッシュボードから「締結済み」として見えるようになる



同意により契約書に署名がされた様子
(ただし証明書は信頼されていない状態)



以上で書類の作成が完了しました。

まとめ
  • アップロードしたPDFは電子署名される
  • 押印、同意のタイミングで電子署名が追加されるもよう
  • 契約書の送信先を間違って見知らぬ第三者が適当に「押印」した場合でも、署名者のメールアドレスによって間違いは発見できそう

電子署名を「押印」のメタファで実装したのは面白いと思いました。
ただ生成される印影がちょっと残念なため、リアルな押印の持つ「契約感」の再現性が欲しいなと思いました。

また、事前に同意さえあればハンコ風画像は飾りにすぎないという姿勢はプラグマティックであり一つの見識だと思いました。ドキュメント単体で全てを保証するのではなく、契約のプロセス全体を通して正当性を担保しようという発想なのだと理解しました。


それでは!

perlで快適REPL生活!(2015年版)

$
0
0
こんにちは! ueharak です。

REPL、したいですよね。私はしたいです。
で、検索して「perlで快適REPL生活!」という記事を見つけました。

早速 Carp::Reply をインストールして挑戦!
(コードは上記 @sonotsさんの記事からの孫引きです)

use strict;
use warnings;
use Carp::Reply qw(repl);

my $foo = 'foo value';
Carp::Reply::repl(); #=> ここでREPLに入る
#=> ↓は、REPLをC-dが:qコマンドで抜けた後に実行される

my $baz = 'baz value';
print "$baz\n";

これでバッチリ!
…と思いきやうまくいきません。

% perl test.pl
Now at test.pl:7 (frame 0)
Backtrace:
Trace begun at test.pl line 7
Environment values must be references, not SCALAR(0x1d6f720) at /home/azureuser/perl5/lib/perl5/Reply/Plugin/Defaults.pm line 57.

調べてみると issue として報告されており、このままではダメなようです。

どうしよう…

実は上記とは別に Pry というものも検討していて、どちらにしようか迷っていました。

というわけで Pry をインストールして再挑戦!

#!/Usr/bin/env perl
use strict;
use warnings;
use Pry;

my $foo = 'foo value';
pry; #=> ここでREPLに入る
#=> ↓は、REPLをC-dが:qコマンドで抜けた後に実行される

my $baz = 'baz value';
print "$baz\n";
print "$foo\n";

実行してみると、バッチリ!

% perl test.pl
Prying at test.pl line 7
Current package: 'main'
Lexicals in scope: $foo
Ctrl+D to finish prying.
0> $foo
$res[0] = 'foo value'

1> $foo='xyzzy'
$res[1] = 'xyzzy'

2>
Finished prying!
baz value
xyzzy
%

みなさんもぜひ試してみてください!

では!


エンジニアが無料で寿司を食える冴えてるたった1つの方法

$
0
0

fujya.shです。タイトルの「たった1つの」は言い過ぎですね。すみません。釣りタイトルです。
ただし、5ステップで寿司が無料で食えるようになりますので、我こそはと思う方は是非トライしてみてください。


1:シャノンの採用ページを開く

http://www.green-japan.com/job/29900



  • プロダクトマネージャー
  • プロジェクトマネージャー
  • QA
  • 開発エンジニア


現在は4職種募集中です。
近日中にインフラエンジニアも募集する予定です。



2:応募する



3:面接 → 採用

選考は以下の流れで行います。

  • 書類選考
  • 面接(事業部長・マネージャー)
  • オンラインSPI試験
  • 役員面接
  • 採用




4:技術部ブログを書く


じゃんじゃんアウトプット出す事は非常良いことです!
アウトプットしてくれる人大歓迎です。



5:(PV数を稼げれば)寿司が食える

※ 9月に飛んできたメールから一部抜粋
   堀さん = 弊社CTOです
   来年もきっとお寿司食べれる。毎年食べれるように掛け合います。


ブログ書いて、PV数トップ5に入れば寿司が食べれます。


良い仕事をして、良いアウトプットをすると、寿司が食える
そう、シャノンならね






シャノンでは、一緒に世界を変えて寿司を食いに行くメンバーを募集中です。

http://www.green-japan.com/job/29900

話だけでも聞いてみたいという方でも一度ご連絡ください!
一緒に寿司食べましょう!

GASを使うようになってからエンジョイライフ一直線

$
0
0
こんにちは、QAエンジニアのkuramochiです☆

プログラマではない私がこだわって作ってみたGASについて紹介させていただきます!!

まず、GASとは?
Google App Scriptのことです。
バリバリのエンジニアの皆様的には、おーGASねーってかんじかもしれないですが、、、
暖かく見守ってくださると幸いです( *´艸`)


自分自身、スクラムチームのリリースプロセスを管理していたので、以下のようなメールを毎週月曜日の朝に配信していました。
************************************************
今週のリリーススケジュールの期限は以下です。
○○日(月)・・・□□
●●日(水)・・・■■

※厳守でお願いします。
************************************************
そー、これぞ、人力!!

上記、月曜日の朝はスクラムの特性、MTGがあるので忘れがちになってしまうんです。

そんな時、私の趣味であるバレーボールで、前十字靭帯損傷という怪我で入院したことがきっかけで、
自動配信できたらいいのにと調べ始めたのがきっかけです。



■やりたいこと
毎日決まった時刻に、その日の期限となっているプロセスの通知をすること
全部、ポチッ、で解決したいなー 、そう、スパムメールのように

■用意するもの
Googleのスプレッドシート
やる気と聡明な脳みそ

◇メール配信用Script以下参照
function sendMailForm(){
  var now = new Date();
  var spread_sheet_id = '(スプレッドシートIDを入力)';
  var sheet_name = 'MPスケジュールメール送信用';
 
  var today = now.toLocaleString();
  var today_date = today.match(/^[0-9/]+/);
  var ss   = SpreadsheetApp.openById(spread_sheet_id);
  var sh   = ss.getSheetByName(sheet_name);
  var rows = sh.getLastRow();

  for ( var i = 2; i <= rows; i++ ) {
    var value = sh.getRange(i, 2).getValue();
   
    if( today_date == value ) {
      var to = sh.getRange(i, 3).getValue();
      var subject = sh.getRange(i, 4).getValue();
      var body = sh.getRange(i, 5).getValue();
     
//メール配信する
      var options = {};
      if ( to ) {
        MailApp.sendEmail(to, subject, body);
      }
 
    }
  }
}
 
◇スプレッドシート内は以下参照
MPスケジュールメール送信用




ついでに、Googleカレンダーにも同じものをポチッ、で入力してます。
function createAllDayEventFromSheet() {
    var mytitle, mydate, mydescription;
    var objEvent;
    var sheet = SpreadsheetApp.getActiveSheet();
    var objCalendar = CalendarApp.getCalendarById('(カレンダーIDを入力)'); 
 
    for (var i = 2; i <= sheet.getLastRow(); i++) {
        mytitle = sheet.getRange(i, 1).getValue();
        mydate = sheet.getRange(i, 2).getValue();
       mydescription = sheet.getRange(i, 3).getValue();
        objEvent = objCalendar.createAllDayEvent(mytitle, mydate, {
          description:mydescription
    });
    }
}
そのスプレッドシートはこちら
(MPカレンダー登録用)
これ、ポチってやつとGoogleカレンダー内に対象のDateにtitleのスケジュールが入ってきます。


また、Googleカレンダーに入れるにも、スプレッドシート開いて、GAS開いて実行ってめんどうだったので、
スプレッドシート上のメニュータブから、ポチッ、でできるようにメニュータブも追加!
function onOpen(){
  var ss = SpreadsheetApp.getActiveSpreadsheet();
  var menus = [
    {name: '★MPカレンダー登録用', functionName: 'createAllDayEventFromSheet'},
   ];
  ss.addMenu('★QAリリースタスク', menus);
}
実際にはこんな感じ

※「★リリースタスク_PIVOTAL(QA)」は、作成中につき、画像では入っていますが、未対応のものです。

全ての日付文面等はセルをうまくつかって、入力値がほぼほぼ動的に生成されるようにします。
※2回ポチると、二重登録になるので、要注意です。


一つのシートで全部完了!

おかげで、毎日のようにあるプロセス期限の連絡を自動配信させることができました。
毎日おしよせる期限通知に少しひやりとしながら期限にこだわって仕事をするのもなかなかいいものです!!

メールを見てない方やメールを見る癖がない方もいらっしゃると思います。
ですが、メールを見ないで仕事はできません。
なにより、スパムのようにメールを送ることで、管理側も楽になり、受け取る側もなんかメールくるからやらなくてはいけない、ちょっと気になる、的な存在になってくれます。

なんのために通知をしているのか、
期限というものに執着してもらいたい、
技術者としてアウトプットすることにこだわりたい、
と思いながら作りました。

プログラマではないので、こういうの調べたりするにも時間かかりますが、
QAという職種上、自分ひとりで何か作り上げるにはハードル高い部分を感じながら、
自分で完結させる何かを作りたいという精神で取り組むことができました。
もちろん、とってもとっても優しい先輩方にも見てもらいました。


シャノンには、こんなことをしているQAエンジニアもいます、QAは常に改善を心がけています!!
みんなが心地よく働けるように、開発者が書いたものに対して、気持ちよくリリースOKと告げることができるように、
品質をあげる活動をしています。
(Perlを書き始めたQAエンジニアもいるとかいないとか・・・ )

QA大好きっという方、テストにこだわりたいっという方、
大大大募集していますので、採用ページは こちら!!

では、これにて、kuramochiでした♪

Jenkins の Scriptler でグローバルプロパティ経由のパラメータ受け渡しを行う

$
0
0
みなさんこんにちは!ueharak です。 

Jenkins でパラメータを渡す場合、下流のジョブへはパラメータを簡単に渡すことができますが、下流で変更されたパラメータを上流へ反映させることは難しいと思います。

今回は Scriptler を使って上流へパラメータを渡す方法を紹介します。 

Scriptler プラグインをインストールする

今回利用するプラグインをインストールします。

グローバルプロパティを設定する

グローバルプロパティはジョブを超えて同じ値を参照するのに使えるプロパティです。通常ここは読み取り専用ですが、これを書き換えられるようにすることで今回の課題を解決します。

スクリプトを作成する

グローバルプロパティ編集用のスクリプトを作成します。

スクリプトはこちらを参考にしました。

import jenkins.*
import jenkins.model.*
import hudson.*
import hudson.model.*

nodes = Jenkins.getInstance().getGlobalNodeProperties()
nodes.getAll(hudson.slaves.EnvironmentVariablesNodeProperty.class)

if ( nodes.size() != 1 ) {
println("error: unexpected number of environment variable containers: " + nodes.size() + " expected: 1")

} else {
envVars= nodes.get(0).getEnvVars()
envVars.put("$key", "$value")
Jenkins.getInstance().save()
println("$key : $value")
}


テストジョブを作る
上流に相当するジョブを作ります。

echo $GLOBAL_KEY
java -jar /var/lib/jenkins/jenkins-cli.jar -s http://localhost:8080/ build set_global_property -s
echo $GLOBAL_KEY



下流のジョブを作る
ここで Scriptler を使って $GLOBAL_KEY を変更します。

wget --spider http://localhost:8080/scriptler/run/set_global_property.groovy?key=GLOBAL_KEY\&value=modified


後続のジョブを作る
$GLOBAL_KEY が変更されたことを確認します。

echo $GLOBAL_KEY


実行してみる


上流の結果

内部で Scriptler を呼び出しました。呼び出しの前後で $GLOBAL_KEY が当初の値のままです。

下流の結果

$GLOBAL_KEYを "modified"へ変更しました。


変更された結果を確認する

$GLOBAL_KEY が変更されました。


グローバルプロパティが変更されていることを確認する

Scriptler によって値が更新されました。

いかがでしたでしょうか?
値の受け渡しで困った際にご利用ください。

それでは!


メタ勉強会に行ってきたよ #metabenkyokai

$
0
0
こんにちは! ueharak です。
勉強会についての勉強会、「メタ勉強会」に行ってきました。




社内勉強会を開くモチベーション、課題はおおむね共通しているように見えました。それぞれの工夫はたいへん勉強になりましたが、個人的な共感も踏まえてまとめると次のような感じになるかと思います。

  • モチベーション:
    • 知見を共有したい!
    • 仲間を増やしたい!
    • スキルアップしたい!
  • 勉強会は:
    • 定期的にやるのがよい
      • 順延するくらいなら「もくもく会」をやる
      • 流れを切らさないことが大切
    • 業務後よりも昼休みの方が参加しやすい
      • 食べながらだとワイワイ楽しみながらできてよい
      • 積極的に「笑う」と楽しい空気を作れる。サクラでもよいから笑うべき
    • 開放的な場所でやるのがよい
      • 周囲の目に触れることで参加を促すことができる
      • 小さな会議室でやるよりもゆったりとした雰囲気になる
  • 運営者は:
    • 無理をしない、折れない、気軽にやる
    • 極力手間をかけない工夫をする
      • 登録不要で参加への敷居を下げる
      • 椅子は各自で手配
      • 立ち見OKにして気軽に寄ってもらう
    • 同じモチベーションの人を誘う
      • 1 on 1 で直接声をかけると賛同してくれることも多い
  • 発表は:
    • テーマを縛らず、発表への敷居を下げる
      • 技術以外にも広げると事業部との交流が生まれてよい
    • 資料を作りこまなくてもできるようにする
      • ハンズオン
      • 輪読
      • もくもく会
      • 外部勉強会で得た知見を共有する

その他、勉強会あるあるが披露され会場が唸ったりビアバッシュでそれぞれの課題を交換したりなど、たいへん有意義な時間を過ごすことができました。

主催の tepさん、foostan さん、会場を提供してくださった グリー株式会社さん、ありがとうございました!

そうそう、ゴザ、すごくよい空気を作っていました。



肩肘張らず気軽に聞ける感じ、これはメタ勉強会からの、ひとつの回答だったように思いました。

それでは!


iBeaconで、朝出勤したらslackに通知してみる

$
0
0
こんにちわ。ishikawaです。
雨の日曜日なので、iBeaconを使ってプチIOTをしてみました。

ちなみに、iBeaconおよび携帯アプリを作るのは今回初めてで、
粗が目立つと思いますが、ご容赦ください。


今日作るもの

「○○さん、出社してる?」

フレックスタイム制の弊社では、よくこのようなやり取りが行われています。
出社しているのか、していないのか、来てるけど席を外しているだけなのかがわからなくて、
周りの人に聞いても「わかりません」という返事が返ってきたりします。

出社したタイミングで自動的に何かに通知されると
そういったコミュニケーションコストがおさえられて嬉しいなあ、
だけどメールよりもカジュアルなものがいいなあと考え、
slackに通知する方法でアプリを作ることにしました。


準備するもの

  • iBeacon:1台(アプリックス社ビーコンモジュール「BM1」※同僚から借用)
  • iBeacon用の単三電池:2本
  • iPhone(iOS 9.1):1台
  • mac(Xcode7.1) :1台

はい、どこのご家庭にもありますね。
では、早速アプリを作っていきましょう。


アプリの構成



  1. 出社したら、IBeaconの電波を受信し、IOSアプリから中間サーバにメッセージを送信
  2. 中間サーバはその人の出勤をログとして保存しており、その日初めての出勤であれば、ログを記録してslackにメッセージを送信する

#slackの設定

    ①「Slack Integrations」に「Incoming WebHooks」を追加します。

    「Incoming WebHooks」を利用すると、外部のサービスからSlack上へコメントの投稿ができます。
    今回はこの機能を使って、Slackの特定のチャンネルへの投稿を実現することにします。




    ②curlコマンドで動作確認します。

    「 Incoming WebHooks 」を追加すると、POSTするURLが発行されますので、
    念のため、curlコマンドで動作を確認します。
    $ curl -X POST --data-urlencode 'payload={"channel": "#rd", "username": "ishikawa", "text": "This is posted to #rd and comes from a bot named webhookbot.", "icon_emoji": ":beginner:"}' https://hooks.slack.com/services/your_webhook_url


    はい、問題なくメッセージが投稿されました。


    #iosアプリの作成

    中間サーバを用意する前に、IBeaconの電波を受信し、Slackに通知できるかどうか試してみます。

    ①Single View Applicationでプロジェクトを作成し、iBeacon受信用の実装を行います。

    IOS、iBeaconアプリ初心者なため、以下の参考ページの実装をほぼそのままコピペしました。
    参考にしたページ:
    iBeacon Receiver in Swift 2.0
    http://qiita.com/Shirade/items/ca9dcf111f2a7548cacf

    ただ、このままだと位置情報取得の許可が行われなかったため、
    Info.plistに「位置情報を使用する目的」を追加しました。

    追加したキー名
    • NSLocationAlwaysUsageDescription(使用中にのみ許可)
    • NSLocationWhenInUseUsageDescription(常に許可)


    ②Slack宛にPOSTするメソッドを作成します。

        @IBAction func postMessageToSlack() {
    // create the url-request
    let urlString = "https://hooks.slack.com/services/your_webhook_url"
    var request = NSMutableURLRequest(URL: NSURL(string: urlString)!)

    // set the method(HTTP-POST)
    request.HTTPMethod = "POST"
    // set the headers
    request.addValue("application/json", forHTTPHeaderField: "Content-Type")
    // set the request-body(JSON)
    var params: [String: AnyObject] = [
    "channel" : "#rd",
    "username" : "ishikawa",
    "text" : "ishikawaが出社しました",
    "icon_emoji": ":beginner:"
    ]
    do {
    try request.HTTPBody = NSJSONSerialization.dataWithJSONObject(params, options: NSJSONWritingOptions(rawValue: 0))
    } catch let parsingError as NSError {
    print(parsingError.description)
    }

    // use NSURLSessionDataTask
    var task = NSURLSession.sharedSession().dataTaskWithRequest(request, completionHandler: {
    (data, response, error) in
    var result = NSString(data: data!, encoding: NSUTF8StringEncoding)
    print(result)
    })
    task.resume()
    }


    ③iBeaconに乾電池をセットして、IOSアプリを起動します。

    はい、Slackに通知されましたね。



    #中間サーバの準備

    herokuに簡単なアプリをたてようと思ったんですが、本日は力尽きてしまいましたorz
    続きは次回の投稿までお待ち下さいm(_ _)m


    番外編

    #iBeaconのUUIDを取得する方法

    IBeaconはビーコン領域への出入りを監視するため、ビーコン領域の指定をIOSアプリ側でする必要があります。

    ビーコン領域指定パラメータ

    • proximity UUID
    • major value
    • minor value

    同僚から借りたIBeaconのUUIDがわからず、もじもじしていたのですが、
    Node.jsのbleaconパッケージを利用して、情報を取得することができました。

    参考にしたページ:
    たった5行!最も簡単にiBeaconの電波を「受信」する方法
    http://qiita.com/Morikuma_Works/items/c2899e548da1c5e2c28e


    まとめ


    • 雨の日は少し憂鬱ですが、IOTで時間を忘れて楽しむことができました。
    • iBeacon&Swiftのサンプルコードをネットで調べてもバージョンが古いものだと、コンパイルが通らなくて、悲しかったです。IOSの開発はバージョン周りの問題が結構しんどいなと感じました。

    休日、雨でどこにも行けなくなってしまった時、IOTしてみてはいかがでしょうか?

    それではまた!

    bugspots (Google のバグ予測アルゴリズム)を3ヶ月くらい運用してみた話

    $
    0
    0
    開発の土田です。

    bugspots が何かをご存知でない方はまず、下記の記事をご参照ください。

    Google のバグ予測アルゴリズムと bugspots の導入

    bugspots は簡単に言うと、「そのファイルはバグ修正が最近沢山されているから、次に修正するときもバグが入る可能性が高い」という考え方でスコアを算出するアルゴリズムです。コミットログを参照し、ファイルごとにスコアを算出します。前回の記事では、bugspots の簡単な紹介と、その導入について書きました。今回はその応用編として、どのように運用しているかを書いていきたいと思います。

    コミットログについて

    bugspots はバグが発生したコミットが重要な指標で、バグかどうかの判断基準にコミットログの文字列を使っています。デフォルトは「fixとかcloseっぽい文字列」(fixes, fixed, closes, closed を含むコミットログ)が対象になります。

    弊社では BTS として bugzilla を使っているので、バグフィックスをした際は bug XXX(バグ番号)みたいなコミットログが入っていることが多いです。そのため、「bug ではじまる」コミットを対象にしています。ただ、前回も書いたように、エンハンスにも bug id を切っている場合があるので、本来は機能追加でバグではないのに、(bugspots から見ると)バグとして扱われてしまう問題がありました。

    今回は開発チーム内で相談して、エンハンスの場合はコミットログに何か別の文字列をつける(たとえば「[Enhance]」などを頭に付与する)ことで、区別できるようにルールを変えてもらいました。過去のものはどうにもならないですが、bugspots はその性質上、直近のコミットのほうが重視される(スコアが上がる)ようになっているので、いずれ時間が解決してくれるでしょう。

    実行方法について

    最初は master へのコミットフックで実行していたのですが、しばらく使っていると、大きな変動は無いことが分かったので、月一回の定期実行に変えました。このあたりは、プロジェクトのファイルサイズや期間で変動してくると思うので、様子を見て最適なポイントを見つけると良いと思います。

    実行方法はシンプルで、Jenkins の定期実行を使って master に対して実行し、HTML Publisher でテキストとして保存しているだけです。Jenkins で使ってるシェルスクリプト(って言うほどのものでも無いですが。。。)は下記

    source $HOME/.bashrc
    bugspots -r "/\Abug/" . > bugspots.txt

    ついでにキャプチャも取ったので載せておきます。こんな感じで、上記スクリプトを毎月1日9時頃に流しています。


    活用方法について

    「pull request にフックして点数が高ければ警告」とか本当はやりたいのですが、結構手間がかかるので、そこまでできていません。月一回の定期実行の後に、生成されたレポートを見ています。

    bugspots のスコアの妥当性について


    ここ3ヶ月くらい、bugspots のスコアを実際に見ていますが、意外なところはあまり無く、「知ってた」、「まあココ触ればそりゃバグ出るよねぇ」みたいなモノがほとんどでした。では、「このスコアには意味がないのか?」というと、僕はそんなことはないと考えています。複雑度(Cyclomatic Complexity)等もそうなんですけど、こういうツールを使って検出した結果は大体経験と一致していることが多いです。でもそれは自然であり、良いことだと僕は考えます。

    一つは、直感とあまりに反する結果が出た場合、それを信じていいのか良く分からないからです。「bugspots のスコアが高いところを中心にリファクタリングをして、今後のバグが出ないようにする」という施策を打つ場合、結果が直感にあまりに反している場合、本当にそれをやってよいのか自信を持てません。

    二つ目の理由も同じような感じですが、たとえば、「このクラスやばいので、直したいです」という提言をする場合に、bugspots や複雑度等で高いスコアが出ていれば、それを理由にすることができます。直感的にやばそうで、かつメトリクスを見てもやばいところは、多分直したほうが良いと思うので。


    今後について

    レポートを見て、実際に修正を行って、スコアがどう変動していくか、みたいなサイクルが作れると良いな、と思っています。

    「俺たちの戦いはこれからだ!」というわけで、シャノンではソースコードのメトリクスを見ながら製品を改善していきたい開発者も大募集しています。興味のある方はこのブログの右側の「エンジニア募集」をクリックしてみてください!


    #daihansei 言語カンファレンス大反省会 2015 に行ってきたよ #eventdots

    $
    0
    0


    こんにちは! ueharak です。

    反省、したいですよね?私は反省したいです!
    今回は 言語カンファレンス大反省会 2015 へ行ってきました!

    今日は下記イベントの代表者による大反省会でした。

    • YAPC::Asia Tokyo
    • LLイベント
    • PyCon JP
    • PHPカンファレンス
    • RubyKaigi


    ざっくりまとめると、こんな感じの話でした。
    (各代表者の話を総合)

    大変な点
    • ネットワーク
    • ノベルティの袋詰め(よい業者さんがいるという紹介があった)
    • 契約、お金の取り扱い

    つらい点
    • 為替レートの変動
    • スピーカーのドタキャン
    • 担当者のバックレ
    • 人が部屋に入りきらない

    セッションの採用基準
    • 技術者としておもしろいかどうか
    • 単なる製品紹介は採択されにくい
    • フレームワークの話ってあんまりおもしろくないのでは?(作者のトークを除く)
    • パッションを感じたい
    • 壁にぶち当たって乗り越えたという話を聞きたい
    • エモい話は OK だけど落ちがち

    参加者の巻込み方
    • 当日スタッフを募集し、次の年もどうですかとスカウトする
    • 勉強会のスタッフから入ってカンファレンスのスタッフへ
    • 地域コミュニティと連携して手伝ってもらう

    いま一番やってみたい企画
    • 泊まり込み(ホテルで懇親会してそのまま泊まる)
    • 参加者同士の交流
    • カンファレンスの後のアフターパーティー

    後進の育て方
    • 毎年スタッフやってもらうことで育っていく面がある
    • ボランタリーだから自由にやればいいじゃん、というのはある
    • 新陳代謝できないなら止めるってのでもよいのでは


    各カンファレンスの代表者には横のつながりもあるようで、PyCon 開催にあたり知見を得ようと RubyKaigi の代表者にヒアリングをし、さらに ScalaMatsuri の代表者は PyCon の代表者にヒアリングをするといったノウハウの継承が行われているのが素晴らしいと思いました。

    みなさん大きなカンファレンスの代表を務めるだけあって、反省と称しつつアツいトークを繰り広げ、これまでの経験を惜しげもなく披露されていました。

    また後半からのビアバッシュでは個別にお話を伺うこともでき、契約やお金の管理といった実務の話を聞くこともでき、大変貴重な体験でした。

    個人的には大満足で、今後のカンファレンス参加に対する新たな視点を得た思いです。
    将来自分がイベントのスタッフになった際は、ぜひ今回の知見を活かしたいと思いました。さらに心強い先輩方がいるということも分かり、こうしたネットワークに接する機会を得られたことは大きな収穫でした。

    大反省会、とても楽しかったです!
    それでは!!

    第13回elasticsearch勉強会に参加してきました #elasticsearch #elasticsearchjp

    $
    0
    0
    おはようございます!munepom (@__munepom__) です。
    先日、第13回elasticsearch勉強会に参加してきましたので、ちょっとブログに残しておきます。

    elasticsearchは、全文検索・解析サーバの OSS です。
    私は、社内にある自身の開発環境で、LogstashとKibanaを使い、アプリサーバのログ検索に使っていたことがあります。
    (メモリ容量が厳しく、現在は停止していますが。。。aha。。。)
    手軽に全文検索が実行できて、嬉しいですね。
    先月、AWS で"Amazon Elastic Service"が利用可能となったようですが、クラスターやノードの管理が楽になるのでしょうか?気になるところです。

    勉強会の感想を書く前に、、、Honza Král さん、Takuya Noguchi さん、谷本 心さん、興味深い発表ありがとうございます!
    また、内容モリモリな LT をしていただいた、株式会社はてな id:takuya-a さん、ありがとうございます!
    毎度司会を務めていただいている @johtani さん、高速英語をリアルタイム翻訳していただいた @yusuke さんに大感謝でっす!

    というわけで、講演の内容メモと感想でございます。間違っている可能性がありますが、その点はご容赦願います。

    • Beyond the basics with Elasticsearch
      • Percolator (濾過器) を使うと、クエリにヒットするドキュメントが登録された際、クエリを通知することが可能になるので、トリガーやアラートの仕組みとして使えそうですね。
      • RDBMS よりも、関連性の検索に優れているようです。Function Score。
      • Aggregation を応用すると、レコメンデーションもできます。
      • Sampler Aggregation というes2.0の新機能。集計対象を小さくすることで、早くすることが可能。という仕組みのようです。

    • How did we use Found.no for our services?
      • Found という、elasticsearch のホスティングサービスを使ってみた事例の発表でした。
      • AWS のサービスとどの点が違うのか、気になるところです。

    • ログ収集の仕組みを再考しよう! あとマウンテンビューに行ってきました。
      • ログですが、アプリからストリーミングハブへ渡し、そこからElasticsearchへ、というような流れが理想的ですね。たしかにー。
      • elastic 社の次なる戦略 (自分メモを要約しただけですので、誤記があるかもしれません。)
        • API
          • Task management API
          • Reindex API
        • Logstash 自体で、情報を保持するようにする流れみたい。入り切らなければ、データキューに入る、と。
          • Clustering
          • Persistent
        • Kibana
          • Custom Apps / plugins
        • Beats
          • Packetbeat
          • Filebeat
          • Topbeat
          • Beats シリーズは、Go で書かれているようですね。
        • Commercial plugin
          • Cross-stack monitoring / management
          • Cross-stack security
          • PDF reporting
          • Orchestration / Automation

    • Elasticsearch を使った単語共起頻度の計算
      • kuromoji.js を作った方ですか!
      • タグやカテゴリーと共起する単語をカウントする。ふむふむ。
      • ナイーブベイズは、転置インデックスと相性が良いみたいです。
      • Terms Aggregation や Filtered Query や Function Score Query 、Term Vectors API など、いろいろ使われているようです。
      • query 中で、Groovy スクリプトが書ける。最高。だそうです!
      • 共起頻度などのインデックス情報から、さまざまな確率が研鑽できるとのことです。

    朝晩の冷え込みが厳しくなってきましたが、健康管理に気をつけてください!
    Enjoy!

    第7回 Quesに参加してきたよ!

    $
    0
    0
    こんにちは!
    inomata@qaです。

    去る11/20にQuesというQAのイベントに参加してきました。

    公式
    https://atnd.org/events/71474




    何気にQuesは前回も参加しています。
    http://shanon-tech.blogspot.jp/2015/05/6ques.html


    Quesは事例と学術的な話題が聞けてなかなかに面白いイベントです。
    今回の会場はヤフー株式会社さんで、オフィスがキレイすぎてうらやましいです。


    では、今回も聞いてきた話を意訳を含めつつまとめます。
    あと、発表資料はweb上にアップされるとの事です。 

    アジャイルとテスト自動化の事例

    Yahoo株式会社さんでscrumチームで自動テストを導入したときのお話でした。自動化を導入して上々の成果を挙げられたみたいです。課題に関しては弊社でも同じ問題を抱えているみたいでした。。
     

    ・開発はscrumでチームを組んで開発を行っている。開発とQAが同じチームで協調し合って作業している。また、チームはリリースの権限、責任をもっていて、独立性を持ってやっている。
    ・自動化支援チームが別に組織されていて、今回開発チームはその支援を受けて自動テストを導入した。

    ・リリース後のクリティカルな問題を防ぎたいという動機から始まった。
    ・マインドとしては頻繁にテストをしないといけないのでしんどい!けどはしょるのは嫌だ!という事で自動化の導入を決意。
    ・数々の困難を乗り越え、クリティカルの問題を事前に検知する、という目標としては上々の結果を得た。(導入後は問題が起きていない)
    ・導入は通常の開発に対して20%の作業量で実施。これで大体半年かかった。もし集中して取り組めば1月くらい?

    ・得た成果として、クリティカルな問題の事前検知に成功。また副作用としてチーム全体が品質を意識して開発に取り組むようになった。
    ・バグじゃないのにテストが失敗する、という課題があり現在試行錯誤中とのこと。

    テスト分析の話

    こちらは、うって変わってテストのプロセスのうちのひとつ、テスト分析に関するお話です。わりともやもやしていた領域なので、今回のお話を聞けて理解することができました。

    ・テストのプロセスは、
      分析→設計→実装→実行
    の工程がある。今回は分析の話。
    ・テスト分析とはテストベースを元にテスト条件を識別する活動。わかりやすく言うと、仕様書や要件定義書といったテストの元ネタになりそうな情報から、テストのポイントになる部分(テスト観点)を探しだす活動

    ・この分析という活動には以下の効果もできる。
     - ドキュメントレベルでの欠陥の発見
     - テスト対象への理解
     - テスト容易性の判断

    ・分析という行為は結果が人によって異なる。なので必ずレビューしてもらう事が大事。さらにはステークホルダーの合意を得ることが大事。

    一方結果が人によって異なる性質があるので、その表現方法も人によって異なる。つまりレビューしにくい。このあたり、方法論を確立すれば、表現方法も決まり、レビューしやすい形式になる。
    しかし分析の分野は、発展途上でこれといった方法論が確立されていない。現在提唱されているものとしては、
     - VSTeP
     - ゆもつよメソッド
     - HAYST法
    といったものがある。

    ・分析は開発の上流工程から始められる。テストはモノができてからはじめるものじゃない!

    まとめ

    自動テストは早いフィードバックを提供し、またテストを定型の作業にしてくれるので同じ品質のテストを繰り返し実行できます。またスケールされれば時間も短縮できるので、開発時間の確保も一役買います。
    一方、テスト分析は上流から品質を作りこむ作業としては重要なものであり、どちらもアジャイル開発には欠かせない要素だといえましょう。
    と、われながらキレイにまとまったところで今回はこの辺で。

    それでは、また!

    JJUG CCC 2015 Fall に参加したと思ったら、DevOps ハッカソンに参加してチームが優勝していました #jjug_ccc #devopsjp

    $
    0
    0

    な… 何を言っているのか わからねーと思うが おれも 何をされたのか わからなかった…
    (以下略
    というわけでこんばんは、munepom ( @__munepom__ ) です。

    Java ラーにとって、JJUG CCC は楽しみなイベントの1つ。
    私、シャノンでは Perl で開発をやっていますが、前職では Java をがっつり使っていましたので、Java ラーです。
    そんな JJUG CCC 2015 Fall に参加申し込みをしたら、Microsoft さんが
    開発者、インフラ技術者のための DevOps ハッカソン~ DevOps のすべてをエバンジェリストと体験し学べる 2 日間~
    なるイベントを開催するというメールが来たので、セッション聞けなくなるけど DevOps に興味があるから参加してみよー!
    ということで、2015年11月28日、29日と参加してきました。

    今回のハッカソンでは、DevOpsとは
    『開発者とインフラ技術者が協力し、ソフトウエアライフサイクルやビジネス価値の創出を改善する活動』
    という定義がなされていたので、なるほど分かりやすい!と思いました。
    (課題として、誰も明確な定義を持っていない、と現状があるようですが。。。)

    というわけで、講義の後は4チームに分かれてハッカソン!でした。

    私が所属したチームの目標は、『デプロイ承認システム』を作ってみることでした。​
    使える時間は、初日 3.5 時間、2日目 5 時間、という厳しい戦いです。
    これは、ストーリー固めないと、後で挫折した際に破綻するなー。と思い、
    まずはチームでストーリーを作る作業を (エバンジェリスト寺田さんに心配されるくらいに) やりました。
    (シャノンではスクラムで開発を行っていますので、その経験がめっちゃ役に立ちました!)

    /* ちなみに、ストーリーはこんな感じでしたw
    部下「新バージョンのアプリできました」​
    上司「どうやってリリースするんだ?後何使ってるんだ?」​
    部下「Chefで自動デプロイします。レシピはこの通りです」​
    上司「わからん」​
    部下「」​
    こんな悲劇が2度と起こらないよう、私たちのチームは誰でもわかるドキュメントを自動生成するシステムを考えました。
    */

    ストーリーは決まり、メンバーの使ってみたいツールも選定して、最終的な構成は下記のようなイメージとなりました。

    さあ、あとはゴールに向かって進むだけ!のはずでしたが。。。まあいろいろありましたねw

    初日は、初めての Visual Studio Team Services (VSTS) 環境の勝手が分からず、それを理解するのに時間がかかりました。特に認証と認可の部分です。
    幸い、簡単な Hello World Web アプリ自体は Gradle でサクっと作成していただけたのですが、
    git clone で共同開発をしようとした際、1時間近くロスしてしまいました。
    (ソースを外部に持ち出すなどするためのパスワードは、HTTPS スキームでも Azure ログインパスワードではなく、API キーなんですね)
    とりあえず、Azure 上で VM の立ち上げ、Jenkins インストールまでは無事完了し、VSTS の Git も無事使えるようになりました。

    2日目は、もくもくごにょごにょわいわい作業デー!

    Dev サイドは、git で開発を回すことができるようになったので、あとは Jenkins Hook を利用するだけや!と思いきや。。。
    プロジェクトを Team Foundation Server で作成していたため、その Git リポジトリへの git push には反応しない状態となっていそうなことが分かり、妥協案で解決するまでに1時間ほど要しましたw
    https://wiki.jenkins-ci.org/display/JENKINS/Team+Foundation+Server+Plugin も使ってはみたのですが、症状は改善せず。
    結局、今回は Jenkins 先生から polling という妥協案でいっとこ!ということにしました。
    (Jenkins の代わりとして利用できそうな VSO Agent 作成は、いつか挑戦してみたいですね)

    Ops サイドは、とりあえず手動で Dockerfile から Docker image 作成に成功したとのことでグッド!だったのですが、
    アプリが起動しない問題で大ハマりする展開に。。。この辺りは、自分にもっと知識があれば、と歯がゆい思いでした。
    その間、Docker image をどのようにデプロイするか?を調査しましたが、VS だと、JSON ベースの設定ファイルでごにょごにょできそうなんですね。勉強になりました。
    結局、Jenkins でビルド完了後にフックして、Docker image 作成用コマンドを実行する方式となりましたが、ここでもユーザパーミッション問題でハマり。。。タイムアップとなりました。

    最後は発表ターイム!

    今回のチーム目標を決定する付箋を出していただけた方と、Ops としての熱い想いを持った方にプレゼンを行っていただき、
    なんとチーム優勝という結果を頂くことができました。
    2日間という超短い期間でしたが、楽しく作業できるチームメンバーに恵まれて良かったです。感謝です!

    というわけで、1人ふりかえりです。

    Keep

    • ストーリー作成を行っておいたので、作業目的がわかりやすかった。
    • チーム全体の作業感をできるだけ見ようという意識で作業できた。(職場のスクラムマスターを見習ってみた)
    • VSTS の Backlog で、ある程度のタスクやメモが見られるようにしておいたのが良かった。
    • Gradle でサクっとアプリ作れるスキルは重要。
    • あめちゃん重要、おやつありがとうございます。
    • 2日目の朝食サンドイッチ、昼食お弁当ありがとうございます。
    Problem
    • 分からなければ、すぐ聞く!!!
    • 結局、上司説得用のドキュメントはできていない!
    • Azure (VSTS) 上での承認プロセス作成ができていない。
    • Azure と VSTS の予習をしておくと、もっと楽しめたかもしれない!
    • Mac 使いは、Parallels で Windows 環境用意しておけば良かった。。。ローカルで Visual Studio を使えるのが便利そうですね。
    Try
    • 自動化は、最初がほんとにしんどい。けど、できたら楽になるから DevOps がんばろ!
    • もっと Docker を使いこなせるようになりたい!
    • Azule CLI を使いこなせると、もう少し作業の幅が広がるかな?
    • VSTS をもっと使いこなせると、その中で Build などの一連の作業を完結できそうなので、やってみたい。

    先日の楽天テクノロジーカンファレンスでも DevOps に関する講演を聞きましたが、
    いまいちぼやけたバズワードだねぇ、というネガティブイメージを持っていました。
    今回のハッカソンに参加して、
    Dev も Ops もコツコツと協力して自動化に取り組むことが DevOps の姿の1つかな?
    と思いました。
    ネガティブイメージ払拭されました!

    enjoy!


    しゃのんあどべんとかれんだー 1日目 (JavaScript でキーボードを作ってみたよ)

    $
    0
    0

    この記事は Shanon Advent Calendar 2015の 1日目の記事です。

    というわけで、12月になり、今年も技術アドベントカレンダーの季節となりましたね!
    munepom ( @__munepom__ ) です。
    昨年は Qiita でちょっと小ネタを投稿しただけですが、今年はシャノンの技術ブログで小ネタを投稿し続けようと目論んでいます。

    とはいいましても。。。
    業務の合間にネタを作る時間がなかなか取れない現状ですので、
    本日は会社ブログ初投稿記事で作ったキーボードを弾いてお楽しみください。
    (キーボードを叩いても音が出る場合があるので、気をつけてください!!!)

    キーボード (KeyBoard) #2
    • Chrome or Firefox or Safari ブラウザで動作するはずです。
    • 鍵盤をクリックするか、表示されている文字に対応するキーボードのキーを押すと、音が鳴ります。
    • もし、音が鳴りっぱなしになったりした場合は、画面を更新 (リロード) してください。
      (Please reload if ringing...)
    • Firefoxブラウザでは、音の終わりにプチプチ音が発生します...
    表示オクターブ数 (Displayed Octave): 
    基底オクターブ (一番左のキーのオクターブ) (Octave of Left Key): 
    波形選択: 
    音量:  
    SDGHJ346780
    ZXCVBNMWERTYUIOP


    以前作ったキーボードにちょっと色付ければいいや、というつもりが、思わぬハマりどころもありました。
    Firefox ブラウザの SVG 要素に対しては、element.style.fill ではなく、element.CSS2Properties.fill なるプロパティで要素の色を変更しないと、音が鳴らなくなるとは。。。
    JavaScript もなかなか奥深いですねw
    (事前に作成しておいた Oscillator 以外のソースは blogger で書き殴ったものなので、見るに堪えないレベルかもです。ご容赦を。。。)

    Enjoy!

    しゃのんあどべんとかれんだー 2日目 (忘年会幹事のちょっとしたお悩みをちょっと解決してくれるかもしれない GAS)

    $
    0
    0

    この記事は Shanon Advent Calendar 2015の 2日目の記事です。

    というわけで、本日も私 munepom ( @__munepom__ ) がお送りします。
    本日は飲み会後の帰宅のため、どうしよう。。。30分で書けるネタが。。。あ、ありました。

    12月といえば、そう、忘年会シーズンですね!
    シャノン技術統括本部でも、やりまーす!
    私は今年の7月に入社したてのほやほやですが、早速幹事をつとめることになりましたw

    まずは、参加人数を把握せねばなりませんね。
    というわけで、出欠管理ツールとして、Google スプレッドシートを利用することにしました。
    んが、特定背景色のセル数をカウントしようとしたら、意外と手間がかかりましたので、メモしておきます。

    スプレッドシートの『ツール』メニューより『スクリプト エディタ』開き、
    下記のちょっとしたスクリプトを書いて保存して、
    セル中に定義した式と引数を与えると、すんなりと解決しました。


    // 指定範囲のセル背景色に合致するセルの合計数を返します
    // color: 背景色 rangeSpecification: 範囲指定文字列
    function countCellsWithBackgroundColor(color, rangeSpecification) {

    var sheet = SpreadsheetApp.getActiveSpreadsheet();
    var range = sheet.getRange(rangeSpecification);

    var x = 0;
    var i = 0;
    var j = 0;
    var cell;
    for (i = 1; i <= range.getNumRows(); i++) {
    for (j = 1; j <= range.getNumColumns(); j++) {

    cell = range.getCell(i, j);

    if(cell.getBackgroundColor() == color)
    x++;
    }
    }

    return x;
    }

    ん?引数として与える背景色がわからない?
    じゃあ、下記スクリプトも追加しましょ!


    // 指定セルの背景色を取得します。
    function getBackgroundColor(rangeSpecification) {
    var sheet = SpreadsheetApp.getActiveSpreadsheet();
    return sheet.getRange(rangeSpecification).getBackgroundColor();
    }

    というわけで、指定範囲の特定背景色に合致するセルの合計数を記録したいセルに、
    =countCellsWithBackgroundColor(getBackgroundColor("A8"), "A1:A31")
    のような式を書くと、無事カウントが記録されました。
    (Loading に時間がかかる場合があります!)

    さて、他にも知っておくと役立つことがありますので、またどこかで投稿するかもしれません。
    忘年会幹事のみなさま、がんばりましょう!

    Enjoy!

    しゃのんあどべんとかれんだー 3日目 (JavaScript の DOMContentLoaded について、ちょっとしたおはなし)

    $
    0
    0

    この記事は Shanon Advent Calendar 2015の 3日目の記事です。

    というわけで、本日も私 munepom ( @__munepom__ ) がお送りします。
    本日も飲み会後の帰宅のため、どうしよう。。。30分で書けるネタが。。。あ、ありました。

    JavaScript の初歩的なおはなしでございます。

    ある HTML 要素に対して何かを行いたい場合、その要素を取得できねばなりませんね。
    <div id="Hoge"></div> 要素に対して、何かテキストを加えたい場合を想定します。
    document.querySelector が使えるならば、
    document.querySelector("#Hoge") と書くと、HTML Element Object を取得できます。
    querySelector 非対応ブラウザの場合、document.getElementById("Hoge") を利用すれば良いですね。
    ところが、普通に


    <script>
    var elm = document.querySelector("#Hoge") || document.getElementById("Hoge");
    elm.innerHTML = "fuga"; // XSS の危険性があるので、innerHTML の利用には気をつけてね!
    </script>
    <div id="Hoge"></div>
    と書くと、
    Uncaught TypeError: Cannot set property 'innerHTML' of null
    という例外が発生してしまいます。
    この時、console.log(elm) を実行すると、elm = null となっています。

    下記のように、<script> タグを取得したい要素よりも後に記述すると、
    要素を取得でき、スクリプトを実行できますね。


    <div id="Hoge"></div>
    <script>
    var elm = document.querySelector("#Hoge") || document.getElementById("Hoge");
    elm.innerHTML = "fuga"; // XSS の危険性があるので、innerHTML の利用には気をつけてね!
    </script>
    5年前、社会人になりたてホヤホヤで Java と JavaScript の区別もついていなかった頃、
    どこにでも好きなスクリプトを読み込めて実行できるには、どうすれば良いのでしょうか?と悩みました。
    onload イベントにフックした場合は、画面描画完了後にスクリプトが実行されるようですし。。。

    そこで、DOMContentLoaded の登場です。

    DOMContentLoaded は、HTML5 に準拠した仕様のようですね。
    DOM 構築が完了したことを知らせてくれるので、このイベントにフックしてスクリプトを実行すれば、
    画面を描画する前に DOM を変更して目的とする画面などを構築したり、他の操作を実行したりできます。

    というわけで、下記のようなスクリプトへ修正すると、<script> タグの位置に関わらず、目的とする要素を操作できます。


    <script>
    document.addEventListener("DOMContentLoaded", function(e){
    var elm = document.querySelector("#Hoge") || document.getElementById("Hoge");
    elm.innerHTML = "fuga";
    });
    </script>
    <div id="Hoge"></div>

    あ、ここまで書いといてナンですが、、、
    DOMContentLoaded は、Firefox、Chrome、Safari といった主要ブラウザではほぼ動作するはずですが、
    IE の場合は、少なくとも IE9 以降でないと対応していなかったはずですので、ご注意願います。

    どうしても IE8 以前を使う場合は、
    『doScrollメソッドだけはDOM構築後,onload イベント前に実行できる』
    という性質を利用するのが良いかと。
    (少々古いですが、jQuery 1.7.2 の bindReady を読み解くと良いと思います。)

    Enjoy! (・ω・)ノ

    「国立国会図書館のデータを使い尽くそうハッカソン」にいってきました

    $
    0
    0
    開発のkomaDと申します。
    入社してそろそろ一ヶ月、無料寿司に一歩でも近づくため、初投稿しています。

    さて先日、「国立国会図書館のデータを使い尽くそうハッカソン」というイベントに参加してきました。
    その名のとおり、国立国会図書館が公開しているAPIを使ってなにかアプリを作ろうという趣旨のイベントですが、なんと開催場所が国会図書館の会議室です。
    (下の写真は、書庫の最下層である地下8階(!)から地上を見上げたものです。)
    国会図書館の館内で国会図書館のAPIをつかえるなんて、図書館利用者としては最高の瞬間ですよね?



    今回は、ハッカソンで知った、国会図書館が目指しているところのLinked Open Data(LOD)のことと成果物の公開に使ったKnowledge Connectorというサービスについて、ご紹介したいと思います。


    さてハッカソンのテーマでもあるLinked Open Dataですが、何となく聞いたことがあるようなないような、という感じの言葉ではないでしょうか。
    あらためて言葉の意味を復習しますとこのようになります。

    (http://www.ndl.go.jp/jp/aboutus/standards/lod.htmlから抜粋)
    LODとは、ウェブ上でデータを公開し共有するための方法で、さまざまなデータ同士を結び付けて(Linked Data)、誰でも自由に利用できるよう公開されている(オープンライセンス)ものです。ウェブの創始者であるティム・バーナーズ=リーによると、Linked Dataには次のような4つの原則があります。

    1. 事物の名前としてURIを用いること
    2. これらの名前を参照できるように、HTTP URIを用いること
    3. URIを参照したときに、RDFやSPARQLのような標準技術を用いて、有用な情報を提供できるようにすること
    4. さらに多くの事物を発見できるように、他のURIへのリンクを含むこと


    人間が閲覧できる形式だけでなく、コンピュータが解析可能な形式にすることで、よりデータを利用しやすくすることを目指しているというわけですね。
    ところで3のRDF,SPARQLについては、ちょっと聞きなれないのではないでしょうか。
    ちょっと調べてみますと……。


    RDF(Resource Description Framework)
     ウェブ上にある「リソース」を記述するための統一された枠組みであり(中略)特にメタデータについて記述することを目的としており、セマンティック・ウェブを実現するための技術的な構成要素の1つとなっている。

    (https://ja.wikipedia.org/wiki/Resource_Description_Frameworkから抜粋)

    SPARQL(SPARQL Protocol and RDF Query Language)
    RDFクエリ言語の一種である。
    (https://ja.wikipedia.org/wiki/SPARQLから抜粋)


    つまり、外部にAPIで情報公開するとき、RDF(という形式)で表現して、SPARQL(という方法)で取得してもらうことを目指しているというわけです。

    例えばですが、「コンピュータ」という言葉の下位語を検索するSPARQLはこんなふうになります。
    PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
    PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
    SELECT * WHERE {
        ?uri1 rdfs:label "コンピュータ"; skos:narrower ?uri2.
            ?uri2 rdfs:label ?label.
    }

    なんとなく、SQLみたいな雰囲気がありますよね。(上では"narrower"が下位語をあらわしています。)

    これをURIにくっつけて送信すると結果を取得できます。

    [問い合わせ発行のリンク]
    実際に国会図書館のサイトに問合せるとどうなるか、皆さんも見てみてください。

    このサービスは「典拠管理」とよばれるもので、これによって、例えば異なるペンネームで執筆する作者を同一人物だと同定したり、ある主題をもつ書籍が、他の主題を持つ書籍とどういう関係にあるのか(「ウェアラブルコンピュータ」についての本は、「コンピュータ」について書かれた本の下位カテゴリで、「PDA」の本と兄弟関係だ等)がわかるようになっています。



    こういったAPIを活用してハッカソンのチームでは、「国会図書館に所蔵されていない本を見つけるアプリ」というややマニアックなアプリを作成しました。
    本来、日本には納本制度というものがあり、出版される書籍は原則、国会図書館に所蔵されるはずなのですが、厳密にそれが運用されているかというとグレーなところがあります。
    すこしまえですが、ある作品について映像資料はあるのに、書籍がなかったみたいなこともあり話題になりました。

    チームでつくったアプリでは、国会図書館に所蔵があるかどうかを検索したうえで、実際にその本が存在しているかを別のサービスを使って調べ、所蔵の有無を確実に特定するようにしています。
    このアプリを使って古本を買いあされば、お小遣い稼ぎをしたうえに、文化的資産の拡充もできるというみんなが得しかしないアプリです。


    また今回のハッカソンではつくった成果をKnowledge Connectorというサイトに掲載しました。(http://idea.linkdata.org/idea/idea1s1349i)
    このサイトのことは、ハッカソンに参加して初めて知ったのですが、LODの取り組みに関連してハッカソンの成果物を掲載できるサイトだそうで、こんなふうにハッカソン後にどこかに残しておけるというのもなかなか良いなと思い、ご紹介させていただきました。
    (こちらに初めての方への案内があります→ http://idea.linkdata.org/about)


    最後に、図書館のなかの様子をちょっとご紹介します。
    冒頭の写真は、書庫の最下層から地上を見上げたものでしたが、その他こんな感じで、戦前の新聞やちょっと懐しい時期のマンガ雑誌など書庫に並んでいる姿を目にすることができました。



    こんな風に国会図書館では、出版された新聞や雑誌がずっとあとの時代でも参照できるように、大切に管理をしているそうです。
    データは蓄積と有効活用、両方が大切なんだなーと感じた瞬間でした。

    それでは皆様も、APIが使いたくなったら、いつでも国会図書館のAPIにアクセス! してくださいね。

    しゃのんあどべんとかれんだー 4日目 (銀の弾丸はあるのでしょうか? The Silver Searcher, The Platinum Searcher)

    $
    0
    0

    この記事は Shanon Advent Calendar 2015の 4日目の記事です。

    というわけで、本日も私 munepom ( @__munepom__ ) がお送りします。
    本日は早く寝ろと言われているため、どうしよう。。。30分で書けるネタが。。。あ、ありました。

    私が Java 屋さんから Perl 屋さんへ転向 (?) して、2番目に驚いたことは、クラスやメソッドの検索がやりづらいことでした。
    (1番目は、コード補完がされないことです。。。)
    Java だと、 IDE がよしなにやってくれて、Ctrl + クリックで目的とするクラスやメソッドへジャンプすることが大抵可能なのですが、
    Perl はなかなか自由度が高く、そのあたりはハードルが高そうです。

    さて、どうしよう?

    grep コマンド使って全モジュール検索を行い、片っ端から当たっていくしかないかなー。
    でも、grep で全検索は重いなー。Atom エディタの検索も重いなー。。。
    と思っていたところ、Perl のプロである tsucchi センパイから、ag いいよ!と教えていただけました。

    ag ???
    元素記号でいうところの銀ですか。銀の弾丸ですか!それは使わねば!というわけで、
    導入したらすっごく快適に Perl モジュール検索ができるようになりました。

    そんな ag (The Silver Searcher) のご紹介です。

    The Silver Searcher は、高速に grep を行ってくれる感じの代物でございます。


    $ ag regex
    と実行すれば、カレントディレクトリ以下で指定正規表現にマッチする文字列を持つファイル名と、該当行数と文字列を表示してくれます。
    .agignore ファイルに無視したいファイル名を書くと、それらを全て無視してくれるので、便利です!
    また、--ruby ロングオプション指定などにより、特定拡張子のファイルのみをターゲットとした検索も実行できます。
    さらに、オプションも豊富ですので (-a 指定で、無視ファイルも検索、-u 指定で、隠しファイルと無視ファイルも検索、-Q 指定で、正規表現無効、などなど。) 何かと便利です。

    ちょっと気になる!という方は、
    GitHubリポジトリの Installing や Building from source 項目を参考に、インストールして試してみてください。

    と、ここまで書いといてナンですが。。。
    ag は、検索対象が UTF-8 で書かれていることが前提となっているようです。マルチバイト厄介ですね。
    EUC-JP や Shift-JIS で保存されたファイル対策として、
    Go 言語で書かれた ptというツールも気になっています。
    プラチナ!豪華!(?) ですね。

    これだけで全てを解決する銀の弾丸とはならないのでしょうが、
    コツコツと Perl モジュールを検索して解析を進めるにあたり、キラリと光るツールであると思います!
    製作者の方々に感謝です。

    Enjoy! (・ω・)ノ

    Viewing all 210 articles
    Browse latest View live