コンピュータやソフトウェアのあれこれ@道民(&元道民)
Planet
実践アジャイルテスト読書会 01に参加しました
2月 23rd
2月20日(月)に開催された、実践アジャイルテスト読書会 01に参加しました。
今回から始まった読書会、どのようなものかというと(ATNDより)
- 「 実践アジャイルテスト 」をベースにテストに関して学ぶ
- 勉強会の中では書籍の読み合わせ(輪読)は行わない
- あらかじめ該当の章を読み進めて来ることが前提(書籍の購入は必須)
- 担当者が予習して文書(sphinx)にまとめておきそれを元に発表していく形式
大学時代のゼミを思い出します。
1回1回が結構ヘビーになりそうです。
(Head First JavaScript読書会もあるし、アジャイルサムライ読書会もあるし…)
ただ、第1回と第2回は概要についての話になると言う事で「書籍購入不要」。
本を購入せずにどのような勉強会か空気をつかもうと思い参加しました。
まぁ、書籍を持っていなかったの、私だけだったんですけどね…。
アジャイル開発の中でのテスターの重要性
今回の範囲は「1.アジャイルテストとは?」。
大きく分けて以下の3つについて話をしました。
- アジャイルについて
- アジャイルな現場のテスターの役割
- アジャイルなテストについて
アジャイルについて
アジャイル宣言なども読みながら、何に価値をおいているかを理解する。
- アジャイルの価値 “ごく短いリリースサイクルで、ビジネスの価値の小さな塊を提供すること”
- アジャイルの前提 “チームが個々の役割以上の事をする – 職能横断的”
- アジャイルで重要なことは “スピードではなく、高い品質を提供し続ける事”
他の読書会などでも考えていることなので、大きなずれはありませんでした。
スピードではなく高い品質のものを提供し続ける事が大事、と言う部分は絶対に忘れてはいけない。
アジャイルな現場のテスターの役割
チームが個々の役割以上の事をする中で、テスターとはどのような位置づけになるか。
- テスト以上の事をしなければいけない
- バグを見つける事を第一目的とするのではなく、「製品をよくする」為に改善点を探す事を一番大事にする
- テストの中で得られた情報を元に、よりよい方向に “テストを変化させる”
- テスターはお客さんとプログラマの橋渡しができる立場にいる
- テスターの仕事は、顧客がイテレーション毎に実現したいことは何かを顧客が言えるようにすること
ソースコードのテストはプログラマも行う事が多いですが、それによりテスターのやる事がなくなるわけではなく、もっとさらに高い次元のテストを行える事を喜ぶべき、と書いてありました。
プログラマーであっても、テストをする時はテスターの帽子をしっかり意識しないとな。
アジャイルサムライ読書会では開発者各自がどのようなポジションでどのような事をやるかまでは突っ込んでは書かれていない(心構えやチーム作りの話が多い)ので、具体的な「誰はどのような目的でどんな事をやる」というのを整理できたのがよかった。
顧客チームと開発チームの相互作用のベン図はとてもわかりやすかった。
しかし、「顧客がイテレーション毎に実現したいことは何かを顧客が言えるようにすること」って、難しいですね。とてもハードルが高い。
アジャイルなテストについて
アジャイルテストの4象限のうち、アジャイル開発のテスターが行う事は主に「ビジネスに面したテストや要求機能に対するテスト(右上寄り)」となる。
目的は上記テスターの心構えで書いた通り。そのためのテストタイプはたくさんある。
20の質問
今回はその中でも重要になる「探索的テスト」のアプローチを学ぶと言う事で「20の質問」ゲームをしました。
担当者@shuji_w6eさんが頭に思い浮かべたものを、他の人が「Yes/No」で答えられる質問をしながら何かを当てていく(絞り込んでいく)ゲーム。ゲーム?のようなもの。
2回やったのですが、面白かったです。
ちょっと長いですが質問を全部載せてみます。(取りこぼしがあるかも)
<1回目>
現実に存在するか Y
お店に売っているか たぶんN
食べられるか N
自ら動く事ができるか N
さわることができるか N - 触るものじゃない
日本で生まれたものか N
私たちが目にするものか われわれはY 普通の人はN
電気を通す事ができるか N
目に見えるか Y
生き物か N
かべにかかるものか Y かかる時もある
やわらかいものか わからない
光るか N
今日それとかかわったか N
におうか N
カラフルなものか Y カラフルな場合は結構ある
それは絵ですか N 近い
それはホワイトボードか N ホワイトボードに関連する事もある
いろいろなものがまとまっているものか Y
作る事はできるか Y
変化しないものか N 通常は変化する
自分で作った事はあるか Y
アジャイルに関係するか Y する場合もある
それは言語か N
それは工場にあるか Y よくある
それは何かを書くものか わからない
それは何かが書かれるものか Y
それは カンバンですか N 近いけど違う
一般的にあるか 一部の業種の会社にはよくある
一部の業種とは営業か N
一部の業種とは飲食業か N
それは貼る事ができるか Y
それはポスターか N
それがないと使っている人は不便か Y
それは工程表か Y
1回目が終わった時に
「得られた情報を共有しようとする気持ちが足りない、誰が当てるかのゲームではない、チームで当てるために得られた情報から絞り込むというアプローチを考えた方がよい」
と指摘されました。
それをうけてもう一回。
<2回目>
さわれるか Y
食べられるか N
目に見えるものか Y
重いものか 通常はY - 感覚的なものは忘れた方が良い
動くか N
売っているか Y
中に何かを入れるものか Y
どの家庭にもあるものか 通常はY ない家庭もある
独身の家庭にはありますか Y ある場合もない場合もある
それは台所にあるか Y ある場合もある
もつ/もたないは所得に関係するか N
子供がいるかどうかに関係するか N
それでインターネットをする事ができるか N
男性が使うものか N 男性だけのものではない
マンションにあるものか だいたいY
高齢の人が使うものか Y
寒冷地の家庭には必ずあるか Y
沖縄にあるか N 基本的にない ある場合もあるかも
火に関連するものか Y
赤いものか Y 赤い場合もある
冬に使う頻度が上がるものですか Y
それは暖房(ストーブ)ですか Y
「どのような家庭にあるか?」という観点で絞り込みをかけていっているのがわかると思います。
また、1回目に比べてゴールまでの質問数も少なくなりました。
このような感覚やアプローチする方法が「探索的テスト」では必要になるそうです。
なるほどなー。
20の質問ゲームはとても楽しかったです。
皆さんならどんな質問をしようと思いますか?
いろんな人とやってみるとアプローチの方向性が見えて面白いかもしれない。
1回目を終えて
本の内容として、とても高い所を目標にしているので、現実で実現しようと思うと困る所や足りない所がたくさん見えてきそうです。心が折れそうになることもあるようです。
また、本自体も厚く、読み進める事自体がかなり難しそう。
しかも予習必須…! とてもハードな読書会です。
でも、だからこそ、1人でやっても無理なので読書会で学んでいくのが良いのかな、と思いました。
(ということで、読書会中に書籍を購入しました
)
次回もがんばってついていきたいです。
第14回アジャイルサムライ読書会 @札幌道場 開催
2月 15th
第14回アジャイルサムライ読書会 札幌道場を開催しました。
参加者は9名。いろんな方向の話をまとめるのは難しいなあーと感じた回でした。
今回の範囲で「グっときた」ところ
全員が正しい方向へ向かっているかを絶えず確認できるようにしなければならない
お客さんが隣に座っている
勉強会として
自宅に帰って本を読み返しつつまとめのwikiを書いていて、若干文脈が違うディスカッションがあったかもしれないなと感じました。
「必要な分だけ、必要なときに」分析すること
“そのイテレーションで必要なものだけを分析していたら全体像が見えなくならないかな?”という話題がでました。
ここでいう「分析」がどういうものを示すのかをきちんと考えておくべきだったなあ。
見知らぬ土地に連れて行かれて「君のフィールドはここだ!さあ武器と防具を選んで!」というイメージではなくて、
見知った自分の土地のうち「今回はあの区画を耕そう、そのためには何の準備が必要かな」そんなイメージ。
(あまりに抽象的すぎますが。)
本章Ⅲ部の計画の段階で下地ができていて、それをさらに落とし込むという段階での「分析」だと思うのだけど、この段階では全体像はどこまで共有できていて、どこまで準備できているんだろう。
決して「行き当たりばったり」でも「今までの経験とスキルでなんとかなる」ものでもないと思う。
実際の業務の場合、この段階での「分析、設計」ってどんな事をするのかな。そしてその段階で揃っている情報はどんなものなんだろう。仕様面だけじゃなくて、技術的・アーキテクチャの面はどこまで固まっているんだろう。
この本で文書は不要と言っているかどうか
“会話とちょっとした文章だけで伝わるから文書はそんなに必要ないというのは文書化できない事に対する言い訳じゃないのかな?”という話題がでました。
家に帰って気がついたのだけど、完全に議論の途中で自分が文中から読み落としてしまっていたところがありました。
この本で、同じ机を全員が囲めるような小さなチームに必要はないだろうと言われているのは「形式的な」文書、ですね。
文書そのものが全くなくて良いと言っているのではなく、2,3人のチームでは「基本設計書」「○○仕様書」みたいな形式的な文書を作る必要はないよね、というニュアンスなんじゃないかなと、読み返して感じました。
「形式的な」って原著だとどのような単語になっているのだろう。
重要な事は「全員が正しい方向へ向かっているかを絶えず確認できるようにしなければならない」事。
その方法として文書が必要なチームは必要な文書を作ればいいし、膝を突き合わせてじっくり話し合う事でイメージが共有でき、それでプロジェクトを進める事のできるチームは、話し合いの時の絵や図、カードのメモだけでプロジェクトがうまくすすんでいくんじゃないかなあという個人的な結論に今は至っています。
ペアプロの話
今日はペアプロやってどうだった?得たものは何か?という話ができなかったのでここに書いておきます。
何度かペアプロをして、自分が一番変わったなと思った事は「名前を付ける」事に対する意識です。
クラス名とかメソッド名、パッケージ名(Javaなので)、1人で作っている時はそれなりの名前を付けて終わっていたのだけど、ペアプロをしているときは「本当にこの名前でいいのか」考える時間が増えました。
(そういうペアに恵まれた事が多かったと言う事もあるのかな)
新しいクラスやメソッドを作る、ということはペアプロ中の大きなイベント事なので
「さてどうする」とじっくり話し合うきっかけになる時だったのですよね。
それからは1人でコードに向かう時にも「名前大事」を忘れないようにしています。
みんなはどういう風にペアプロしているのかな、どういう時に困るんだろう。
また今度聞かせてください!
運営の立場で
「適切な話題をきちんとテーブルに載せる」「話をぶった切らない、雑にまとめない」「きちんとした言葉を選んで伝わるように話をする」、とっても難しいなあ。
「この本が本当に伝えたいポイントはどこか」をもっとしっかり考えたいなと思いました。
どうやって進めるのが良いか、14回開催しながらまだまだ試行錯誤中です。
あと今回は時間配分をミスりました。
ちょっと長めの休憩時間を取ったのもあって、途中で終わってしまったセクションには進まなければ良かったかなーと思っています。
実際にどうやってペアプロをやっているか、困った事、ペアプロをやって良かったと思った事、変わった事とかみんなの話を聞く時間を持ちたかった X(
反省点が多い回です。
でも、今回も楽しく充実した時間を過ごせました。
バレンタインデーと言う事で、皆さんにコーヒーとチョコレートを差し入れしました ![]()
(写真を撮るのを忘れたのでありました。ご想像でお楽しみください)
ディスカッションをまとめたwikiはこちらになります。
https://github.com/agile-samurai-ja/support/wiki/Readingagilesamuraiinsapporo20120214
最後に、場所を提供してくださっている弊社に感謝。
(今回はコーヒーもいただきましたありがとうございます)
また次回から頑張りたいです!
Head First JavaScript読書会 01に参加しました
2月 14th
2月13日に行われたHead First JavaScript読書会 01に参加しました。
この読書会は、Head First JavaScriptの決まった章を読んできて、追加説明を交えながらJavasciptを基礎から学んでいく勉強会です。
しょっぱなから今日の範囲(1章と2章)、流し読みで参加してしまいまして・・・苦労しました。
次回からはちゃんと読んでいきます。
知らなかった事いろいろ
へえ!そうなんだ!と思った事色々を箇条書きにしておきます。
外部ファイルとして定義したスクリプトファイルのキャッシュを適切に制御する
<script type="text/javascript" src="hogehoge.js?20120102"></script>
ファイル名の後ろに任意の文字列をつける事ができる。
内容を変更したタイミングで末尾の文字列を変えると別ファイルとして認識されるのでキャッシュクリアされる。
あと、scriptタグは外部ファイル定義するときも /> で閉じてはいけない。
prompt
使った事なかった・・・。
constで定数定義、遅延初期化はできない
const A; A = 10; alert(A); // undefined
こんな形で使う事ないけど、しらなかった。
constで定義した定数のスコープってどうなるんだろ。
+演算子のルール
前から評価、前から型を推測。
1 + 2 => 3 "1" + "2" => 12 1 + "2" => 12 1 + 2 + "4" => 34 "1" + 2 + 4 => 124 true + 3 => 4 false + 3 => 3 true + true + "3" => 23 true + "3" => "true3"
parseIntとisNaN
isNaNの方が数値の定義が厳しい。
isNaN("200aaa")
=> true
parseInt("200aaa")
=> 200
parseIntとN進数
0が先頭だと8進数、0xが先頭だと16進数に勝手に解釈される。
文字列から適切な進数に変換するためには第二引数を指定する。
parseInt("077")
=> 63
parseInt("077", 10)
=> 77
ルート、ノード、リーフ、エレメント
(この辺はもう頭が沸騰していてアレでした)
親がルート、末端がリーフ、それぞれがノード≒エレメント。
エレメントのidは重複しちゃだめ、絶対。
今日の発見、ここまで。
—–
学ぶ形式の勉強会、仕事終わりだとなかなかハードですね。
アジャイルサムライ読書会や達人プログラマ読書会とは違った部分の脳を使います。
終わり30分前くらいにはぐったりしていました(電池切れ)。
体力つけないと、と感じた勉強会でもありました。
次回、リベンジできるかな。
Ruby勉強会@札幌-22に参加しました
2月 13th
2月11日に開催されたRuby勉強会@札幌-22に参加しました。
今回はオーストラリアよりアンドリュー グリムさんを迎えての勉強会でした!
初めてのRuby読み合わせ
今回は6.3.5 for式からでした。
覚えたこと
6.3.5 for式
for と each のスコープの違いについて。eachはブロック内で定義した変数のスコープはブロック内だけだけど、forの場合はブロックの外側でも変数を参照できる。
for i in [1,2,3] do a = "hello" end puts a // できる
[1,2,3].each do |i| b = "hi!!" end puts b // NameError: undefined local variable or method `b' for main:Object
このため、ループ内でlumbdaを定義した時の実行結果も変わる
a = []
for i in [1,2,3] do
a << lambda{puts i}
end
a.map{|e| e.call}
--
3
3
3
b = []
[1,2,3].each do |i|
b << lambda{puts i}
end
b.map{|e| e.call}
--
1
2
3
こうして比べてみるとiが定義されている場所が違うんだな。なるほど。
みんなforはほとんど使わないみたいだった。
6.3.6 イテレータ
rubyにはいろいろな繰り返し処理の方法がある
- loop: 無限ループを提供
- n.times: n回繰り返す
- n.upto(m): nからmまでカウントアップ
- n.downto(m): nからmまでカウントダウン
- n.step(m, x): nからmまでxずつ増やす/減らす
カウントアップとカウントダウンは n < m (upto), n > m (downto) となっていないと実行されない。
6.3.7 脱出
break, next, redo.
Javaのbreak + ラベルを使う話がでました。実際ラベルを使った事がほとんどなかったのですっかり忘れていました。
ループを一気に抜けるため、にあるのかな?つかわないけど。
pythonの loop else は何のためにある?という話題もでました。
次回は6.4例外処理からです。
アンドリューさんのお話
[1,2,3].map(&1.method(:+))
という書き方ができるよ、と言う話。
関数の部分適用というらしい。
["9","1","2"].map(&method(:Integer)) => [9, 1, 2]
class MyClass
def to_proc
puts "to_proc called"
Proc.new{puts "doing something"}
end
end
m = MyClass.new
1.times(&m)
--
to_proc called
doing something
こんな順番で説明をしてくれました。
1というオブジェクトの+メソッドを[1,2,3]に適用させている。
・・・・ようなのだけど、話を聞いている時はなるほどと思っていたのだが、難しくて説明できません。
誰か教えてください(;_;)
source_loactionの使い方とto_iとmethod(:Integer)の違いは理解した。
"a".to_i => 0
Integer("b")
// ArgumentError: invalid value for Integer(): "b"
懇親会
また次回もよろしくおねがいします!
第25回北海道開発オフに参加しました
2月 7th
2月4日(土)に行われた第25回北海道開発オフに参加しました。
人数が多すぎなかったこともあり、やりたいと思っていたことを集中してやることが出来ました。
当日やったことは次の3つ(実質2つ)です。
はじめる!Rails3を読みながら体系的にRailsを学ぶ
Railsのソースを見たり、機能を追加したり、修正したことはあったのだけど、ゼロから環境を作ってじっくり理解しながら学習したことがなかったので、本を読みながらプロジェクトを作っています。
開発オフでもその続きをやっていました。
自分の環境はRails3.1で開発しているのだけど、本書はRails3.0。そんなに大きな違いはないだろうなと思っていたら、結構違った。
しかし、 『はじめる!Rails3 (1)』をRails 3.1で読み進めるときのポイント というピンポイントで自分が困っていたことをアウトプットしてくれている記事があり、大きく躓かずに進むことが出来ました。
プロジェクトはgitで管理していて、練習問題はGitHubにもおいておくことにしました。
(途中で投げ出さないようにするため)
コミットの頻度や意味のあるまとまりでコミットすることを意識して進めました。その結果
git commit --amend git reset
などのコマンドを覚えることができました ![]()
さらに、git関連のエイリアス設定も充実してきた。
データ投入までできたので、次はデータ表示だー。
マシン起動時にMoinMoinDesktopを起動させるスクリプトを作る
ローカル環境のメモとしてMoinMoinDesktopを使っているのですが、MacBookのPythonのバージョンが上がってしまい、起動エラーが出ていました。
なので、
- Pythonのバージョン指定をしてWikiサーバーを立ち上げる
- ターミナルのログコンソールが立ちっぱなしにならないようにする
スクリプトを作りました。
#!/bin/sh nohup /usr/bin/Python2.6 /Users/xxxx/Develop/moin-1.9.3/wikiserver.py &
この前覚えたnohup。これでログは外部ファイルに記録されるはず。
この.shファイルを右クリックしデフォルトの起動アプリケーションをターミナルにしたうえで
このアプリケーションで開く → ターミナル
システム環境設定 → ユーザーとグループ → ログイン項目
に追加すればOK。
まだ1回しか再起動していないのだけど、うまく行っている模様。
3ヶ月以上放置していた気になることが1個すっきりしました。
もろもろ
ソースコードをEmacsで書きながら覚えていないショートカットを調べて使うなど。
(プラグインには手を出せていない。)
gitにマシン名(本名漢字)でコミットしてしまったソースをGitHubに上げてしまい、本名でググるとソースが出てくる件の修正は
途中まで調べたのだけど完了せず。
あとはみなさんとのおしゃべりて
- よい技術書の選び方
- XSSについて
とか話せたのは良かったなー。
お昼ごはんはsuage+のスープカレー、ハニーマスタードチキンとアボカドの辛口。
ということで、今回も楽しかったです!次回も楽しみです。
これはYAPC効果?
2月 3rd
最近、ひしひしと感じている。
なので、書き残しておこうと思う。
思えばいろいろあったので、振り返ってみる。
Hokkaido.pmの発足
すべてはここから始まった。
いわゆるキックオフミーティングから。
はじめてのLT
これも鮮明に覚えてる、すごい緊張したことを。
この時からYAPCを意識し始める。
正確には、YAPCの存在を知った。
LDD’10/Fall in KUSHIRO
LOCALさんと、ちゃんと交流したのはこの辺りだと思う。
そして、OSC 2011 Hokkaidoに繋がった。
そして、月日は流れ・・・
LTハッカソンとか、MTハッカソンとか、MT勉強会に、Hokkaido.pmがあって、
会う人、会う人に影響を受けて・・・。
YAPC::Asia 2011 Tokyo
ここで凄いショックを受けた。
うまく表現できないけど、雑に表現すると、
「もっと関わりたい欲」が出て来た。
そして調子に乗って、自分にも何か出来るんじゃないかって思い上がって。
結果的に、こうやってブログを書いてる。
そして、現在に至る
何か変わったのだろうか?
変わったんだとしたら、Perlを覚えたいとか、
いつかWebサービス始めたいとか、MovableTypeを使いこなしたいとか。
どれも、今の仕事とは関係ないことばかり。
そして、何より寂しくない。
こういうのは、多分、PerlとかYAPCに限った話じゃなくて、
ただ、自分の場合は、書籍だったりネットの記事がすべてだった訳で、
もちろん、仕事ではMSDNにお世話になった訳だけども、
そういった本の著者だったり、記事を書いた方に会ったりっていうのは、
憧れのあの人に会うのに等しくて、テンションが上がる訳で。
それに、YAPCで何かしゃべるという夢も叶ったし、
次の目標だったり、夢も出来たりして、欲も出て来たので、
どっかで踏ん切り付けて、ステップアップしたいと思う。
どういう形であれ、もっともっと貢献できるようにがんばりたい。
おしまい。
SSLのwebページにPOSTしても値が渡らなくなった話
2月 2nd
やあやあ。お仕事の山がひと段落して昼寝していたら怒涛の不機嫌な電話で叩き起こされた僕様ですよ。こんにちは。
SSLのwebページでフォームの値をPOSTで取得しようとしても値が取れないという謎事象。ついでにCSSが取れない、と。検索してもあまり情報当たらなかったから、メモだけ書いておきます。同じことで困った人いたら参考になれば。
環境
- apache 1.3.41 mod_ssl 2.8.31-1.3.41 openssl-0.9.8b
- 色々事情があって上げられないのです察してください
事象
- chrome/IE8 SSLのページでPOSTしてもPOST値が渡らない
- firefoxは大丈夫
- POSTリクエストの直後のGETリクエストが失敗する。apacheのerror_logを見ると、次のようになっている。
Invalid method in request hoge=&fuga=&…. GET /css/nantoka_base.css HTTP/1.1
推察
- この例だと、CSSにPOSTリクエストのパラメタを渡そうとしてしまっているが、CSSファイルはPOSTパラメタなんて受けないので、invalid methodと言ってる気がする(httpd.conf次第だけど)
- 原因はSSLの脆弱性対応でブラウザの動作が変わったこと。POSTデータの投げ方が変わった。このリクエストは受けられない方が標準から外れている。参考リンク
- httpsでバウンダリ文字列が分割されてpostされる (google groups forum)
- https ではじまる Plesk にログインできません。 (google groups forum)
- 通信を保護する「SSL/TLS」の脆弱性を突いたhttps攻撃、研究者が発表へ (セキュリティーホールmemo)
- MS12-006 SSL/TLS の脆弱性のちょっと詳しい解説 (Microsoft 日本のセキュリティチーム)
- たぶんこの、分割してPOSTっていうのに対応できてない。splitting とか fragment とか、その辺がキーワードっぽい。
対策
- chromeのフォーラムにあった「chrome に –
disable-ssl-false- startを付けて起動」を試してみたところ、期待通りの動作になったので、この問題で間違いなさそう - 可能ならApacheとかopensslとかその辺を新しくしちゃえばいい気がする
- やんごとなき理由により出来ない場合(だった)、Microsoftさんの記事の対策が僕の場合は参考になった
- サーバー側で RC4 を優先するよう設定する (Windows Server 2008, Windows Server 2008 R2)
- TLS 1.1 を使用する
- 今回はIE6を捨てられないので RC4のみを使えるようにapacheを設定したところ回避できた。以下のブラウザとりあえずOKぽい
- chrome 16.0.192.77
- IE 8.0.7601.17514
- Fx 3.6.16
- IE 6.0.2900.5512.xpsp_sp3_gdr.080814-1236 (@WindowsXP)
謎のメモ
[root@hagehgae conf]# openssl ciphers -v 'ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM:-SSLv2:!AES:!3DES' DHE-DSS-RC4-SHA SSLv3 Kx=DH Au=DSS Enc=RC4(128) Mac=SHA1 KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=MD5 KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM:-SSLv2:!AES:!3DES
ほか
- たぶん Lotus Notes も同じ対策ぽい
- みんな困ってない?こんな古いの使ってないって話かな
- もし誰かの役に立てばということでまあご容赦を.
- てか、とりあえずのワークアラウンドとしてはこれでいいと思うんですが、抜本的対策法(ARCFOURに絞らない)をご存じの方いらっしゃったら教えてください。
第13回アジャイルサムライ読書会 @札幌道場 開催
2月 1st
第13回アジャイルサムライ読書会 札幌道場を開催しました。
参加者は5名。実際のプロジェクトの運営方法の話だったのでいろんな職場の話が聞けて良かったです。
今回の範囲で「グっときた」ところ
お客さんと膝をつきあわせて、どうすれば力になれるのか、その方法を真剣に模索する
信頼のおけるアドバイザーたりうるには、お客さんに選択肢を示せる事が大事
勉強会として
実際のところ、どういう形でバーンダウンチャートを使っているの?という質問から、バーンダウンチャートで達成したい目的をそれぞれがどのような形で実現しているのかという話を聞く事ができました。
他の所がどのような形で仕事をしているのかを聞く事ができるのはとても楽しいです。
最近、55億円の残念なニュースがあった事もあり、どうすればあのような残念なプロジェクトを減らす事ができるのだろうかという話もしました。
本当に、何故、良くない事とわかっているのにその文化が消えないのだろう。
それは文化、だからなんだよなぁ。
きっとまだまだ、しばらくは、「思考停止文化」は残ると思う、残念だけれども。
ケーススタディだった事もあり、「8.7 現場で実践する」でも皆さんの現場の話を聞く事ができました。
なににせよ、信頼貯金が大切。
信頼貯金を得ようにもお客さんの顔もわからない事もあるからな・・・。
ただ、信頼貯金を得るために、準備できることがたくさんある。
本当にお客さんの事を考え、一番いい形を提案する、その場面にきた時に手持ちのカードがなければ何もできないもんね。
現状を嘆く前に、もっとできる事がたくさんあるんだよね、自分には。
「選択肢を示せるか?」の問いに自信を持って「YES」と言えるように努力しよう。
運営の立場で
今日は「マスター・センセイと熱心な弟子」の項を会話形式で読んでもらいました。
一息入れつつ、面白い試みだったのでまたやりたいと思います(!)
気がついたら時間を30分ほどオーバーしてしまっていたのは反省。
次回はバレンタインデーに開催なので、皆さんに何か甘いものを持っていこうと思います!(予告)
読書会のディスカッションのwikiはこちらになります。
https://github.com/agile-samurai-ja/support/wiki/Readingagilesamuraiinsapporo20120131
最後に。毎回会場を提供していただいた弊社に感謝。
次回もよろしくお願いします。
Sapporo.js-2012.01.28に参加しました
1月 30th
1月28日(土)にSapporo.jsの勉強会、Sapporo.js-2012.01.28に参加してきました。
だいぶ間が空いた久しぶりの参加です。
読み合わせをする本、JavaScript: The Good Partsを購入して臨みました。
配列
6.7 次元から。
配列の初期化について、多次元配列の初期化の注意、単位行列を生成するメソッド。
単位行列・・・については、そもそもそれが何か良くわからなかったのでその場でぐぐりました。
オブジェクトが参照されるので代入時に注意する事、Objectをコピーする場合はJSONコピーを使う事。
JSONコピーの方法は知らなかった。
JSONコピーはプロトタイプはコピーしないのを確認したコード。
var hoge = {a:1};
hoge.__proto__ = {c:3}
console.log(hoge); // {a:1}
console.log(hoge['c']); // 3
var hoge_json = JSON.stringify(hoge);
console.log(hoge_json); // {"a":1}
var foo = JSON.parse(hoge_json);
hoge['b'] = 2;
console.log('hoge', hoge, hoge['c']); // hoge {b: 2, a: 1} 3
console.log('foo' , foo, foo['c']); // foo {a: 1} undefined
for-inの話も面白かった。ちょうど業務で「each使いたいけど使えない、その結果なんかすごいコードがかっこわるい」状態になっているのがあって。(結局for-inはあまり使わない方がいいという話になったのだけど)
あのかっこわるいコードどうしようかな・・・。
(jQueryを入れるほどの画面でもないテスト画面のコードなのだけど気になる)
正規表現
魔術みたいな正規表現
var parse_url = /^(?:([A-Za-z]+):)?(\/{0,3})([0-9.\-A-Za-z]+)(?::(\d+))?(?:\/([^?#]*))?(?:\?([^?#]*))?(?:\?([^#]*))?(?:#(.*))?$/;
を読み砕いていきました。
部分ごとに分けて考えると、なるほどーとなっていくところが、勉強会の楽しいところだなあ。
最初の
(?:([A-Za-z]+):)
が一瞬顔文字に見えていた私、一人だったらページを流し読みして終わりそう。
上記はURLを判定する正規表現の例です。
たぶんすべての()内に文字が入るとこういうURLになる、はず。[]はキャプチャグループで区切ってみた。
[[http]:][//][terakonya.sarm.net][:[8080]][/getList][?huge][#top]
node.jsをインストールした
マシンに入れずじまいだったnode.jsを、写経中にインストールしました。
といっても、
$ sudo brew install node.js
v0.6.9がさくっとインストールされました。
りゅうのすけ君がスクリーン上でnode.jsを使いながらサンプルをタイピングしてくれていたので、見よう見まねで実践する事ができました。また少しjsと近くなれた気がします。
今回は会社の同僚も勉強会に参加していました。
一緒に仕事をしている人に勉強会で会うと、嬉しいですね ![]()
またよろしくお願いしますー!

