VOYAGE GROUP エンジニアブログ

voyagegroup_techのブログ
VOYAGE GROUPエンジニアブログです。

カンファレンスに行こう(その2)

こんにちは、ECナビの開発・運営に携わっております小芝と言います。
前回はカンファレンスに出向くまでの参加するまでのノウハウについて書きましたが、今回は参加中と終わってからのノウハウについてまとめてみました。

■能動的に話しかける

カンファレンスを存分に楽しむには、単に聴講するだけでなく能動的に講演者や他の参加者に話しかけるようにしましょう。
とはいえ、なかなか自分から急に話を向けるのはとても難しいもの。でも下記のような話しやすい場作りをカンファレンス側で行っている場合があります。
  1. セッション中の質疑応答時間
  2. ask the speakerコーナー
  3. ダイアログセッション

これらに参加することで、割合容易に話しかけることができます。

1.セッション中の質疑応答時間

ここで質問をするコツは、一番最初に手を挙げることです。一番目に質問することは一番敷居が低いのです。
あとのほうになると質問のハードルがどんどん高くなって、ちょっとした事を質問することが難しくなりがちです。
一番目だとその質問が基準点となるので、手を挙げる勇気だけ振り絞れば、どんなことでも質問ができます。
講演者としても、質問の手がすぐ上がるのはとてもうれしいことです。講演者はセッションの中では一番孤独なのです。
ありがたがれることこそあれ、最初の質問に嫌がることはないので、是非実践いただけると嬉しいです。

2.ask the speakerコーナー

講演者に対して自由にお話伺ったり質問したりできる場所として、このコーナーがよく設置されます。
セッション中の質問は一問一答的になりがちなので、ここでさらに突っ込んで話をしたり、講演者と議論を深めることができますので、積極的に行って話をすると大変得るものが大きいです。 時には常連っぽいような人や、講演者の知己っぽい人がたむろしていてちょっと入りずらいときもあるかもしれませんが、別に誰も来室した参加者に対して危害を加えたり一見さんお断りと言ったりされるわけではないので、安心して話かけてみましょう。

3.ダイアログセッション

カンファレンスのつくりにもよりますが、参加者同士でダイアログ(対話)やディスカッションを行うセッションが設けられることがあります。
こういうセッションでは熟練ファリシテータが話をしやすい場を整えてくれるので、大変発言しやすいです。
他の参加者の意見や考えから様々なフィードバックを受けることができるので、この手のセッションを見つけたら是非飛び込んでください。

■休みを入れる

詰めすぎないようにしようと事前に気をつけていても、せっかくのカンファレンスだからと色々参加するセッションを詰め込んでしまうもの。
また、気合い入れてセッションを聴講したり発言したりすると、精神力の限界が予想以上に早く到来することがよくあります。
その場合は無理せず昼食を長めにとる、喫茶でお茶をする、ロビーでまったりするなど、適宜休息を入れましょう。
特にホテルを会場としているカンファレンスの場合、ホテルのレストランやカフェに行くと普段とは違った気分になりリフレッシュも図れます。少し値は張りますがランチは割合リーズナブルなので、せっかくのチャンスを活かしましょう。

■フィードバックをする

仕事の一環でカンファレンスに参加する場合、仕事場にフィードバックを行う必要があるでしょう。
仕事場に向けてのフィードバックのコツは、”カンファレンスで聞いた事を話さない”ことです。
何を言っているのが全くわからないかと思いますのでもう少し補足すると、カンファレンスで知ったことは自分の仕事場という文脈でどのように活かすことができるかについて話すということです。
よくあるアンチパターンとして、参加したセッションの概要全てを列挙して読み上げるということが行われがちです。
これでは聞いてるほうには何も伝わりません。もっと自分の言葉で話さないと相手の心には届きません。
そこで、自分の言葉つまり自分の考えた結果を中心に話を組み立てましょう。
もし自分の仕事場では活かせそうにもないとか、すでに知ってることだらけだったと思った場合は、どういう理由で活かせそうにないと考えたのか、知っていることがカンファレンスでも語られていた事についてどういう考察をしたかを話すと、仕事場の仲間にとって大変有益なことになると思います。
また、許可を得ることができたならば、講演者や他の参加者に対して自分の考えたことを伝えることができると、よりよいノウハウの循環が作れるでしょう。
具体的には、フィードバックした話をブログに載せたり、資料をslideshareに載せたりした上で、そのことをTwitterでつぶやいたりりリプライしたりすることで容易に伝えることができます。

■終わりに

2回にわけてカンファレンス参加ノウハウについてまとめてみましたがいかがでしたでしょうか。可能であれば早速カンファレンスに参加して実践してもらうと一番いいと思います。
そして、自分なりの楽しみ方やいい関わり方を見つけられたら、是非教えて下さい。

■お知らせ

ECナビグループのPeXが、世界最大級のプログラム言語Rubyのカンファレンスである日本Ruby会議2010ゴールドスポンサーとして支援しております。
まだチケットをお求めでない方は予めご購入の上是非ご参加下さい。私を含むECナビのクルーもスタッフの一員として動いておりますので、現地でお会いできることを願っています。

脆弱性(vulnerability)トリビア

こんにちは, 株式会社ECナビ システム本部の春山(@haruyama)です.

セキュリティに関係する仕事をしていると, 「脆弱性」という言葉を聞かない日はありません. コンピュータセキュリティにおいては「脆弱性」とは, セキュリティ上の弱点という意味です. 「脆弱性」に関するニュースは毎日報じられています. 最近も, 「YouTube」にスクリプトを埋め込める脆弱性、現在では修正済み - ニュース:ITpro, Adobe Reader/Acrobatのアップデート公開、ゼロデイ脆弱性を修正 -INTERNET Watch などがニュースサイトで報じられています.

「脆弱性」は vulnerability という英語の訳です. 私が知っている vulnerability が 脆弱性と翻訳されたもっとも古い記録は, ロンドン海軍軍縮会議(1930年)です. 阿川弘之「山本五十六」で紹介されています. 新潮文庫「山本五十六」(上)三十三刷72ページから引用します(原文は縦書きです).

そして, 日本が「ナショナル・プレステージ」という言葉を持ち出すのに対し, 英国はしばしば「バルネラビリティ」という言葉を持ち出して議論した.
(略)
「バルネラビリティ」vulnerabilityという英語を, 溝田は「脆弱性」と訳したそうだが, それだけではちょっと通りが悪いかもしれない.
「バルネラビリティ」が大きいと英国側が言うのは, アキレスの踵がたくさんありすぎることである. 守備範囲が広すぎて, どこからでも刺されやすいという言葉である.

ここで出てくる「溝田」とは, 溝田主一という海軍の名通訳と言われた人です. 溝田主一がなぜ vulnerability を脆弱性と訳したかはわかりません. もともとそういう訳が先にあったのか, 彼が作った語なのか? もしご存知の方がいらっしゃったらブログのコメント覧や@haruyamaまでご連絡お願い致します.

原文には, この直後に「バルネラビリティ」についての記述があります. 「山本」は山本五十六です.

もっとも山本自身は, この言葉を生でよく理解出来たはずである. 何故なら, vulnerable というのはブリッジの勝負で終始使われる言葉であったから.

私はブリッジはやったことがないのですが, コントラクトブリッジでゲームを1度勝ったチームを、バルネラブル(バル)と呼ぶ。そうです.

以上, 「脆弱性」に関するトリビアでした.

MySQL InnoDBでのネクストキーロックの落とし穴

はじめまして、株式会社ECナビ システム本部 情報システムグループの三浦と申します。

私は主にデータベースの運用、管理を行っています。

ECナビでは様々なサービスを展開しています。そしてそれと同じ数と言っても良い程のデータベースが稼動しています。

リレーショナルデータベースがメインでサービスを支えていますが、それを補う形でキーバリューストア的なデータベースも多数存在しています。

メインで活躍しているリレーショナルデータベースは用途によりOracle、MySQL、Netezza等と多岐に渡っています。

今回はMySQL InnoDBで実装されているネクストキーロックの落とし穴をデッドロックと絡めて説明したいと思います。

評価環境のMySQLのバージョンは5.1.39、トランザクション分離レベルはデフォルトのREPEATABLE READ、InnoDB Pluginは未導入にて今回は行いました。

下記のテーブル、データにて実施します。

mysql> SHOW CREATE TABLE HOGE\G;
*************************** 1. row ***************************
       Table: HOGE
Create Table: CREATE TABLE `HOGE` (
  `ID` int(11) NOT NULL AUTO_INCREMENT,
  `COL_INT` int(11) NOT NULL,
  `COL_CHAR` char(1) NOT NULL,
  PRIMARY KEY (`ID`),
  KEY `COL_INT` (`COL_INT`)
) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

mysql> SELECT * FROM HOGE;
+----+---------+----------+
| ID | COL_INT | COL_CHAR |
+----+---------+----------+
|  1 |      35 | A        |
|  2 |      40 | B        |
|  3 |      20 | C        |
|  4 |      25 | D        |
|  5 |      50 | A        |
|  6 |      10 | B        |
|  7 |      45 | C        |
|  8 |      15 | D        |
|  9 |      30 | A        |
+----+---------+----------+
9 rows in set (0.00 sec)

テストケース1

テーブル「HOGE」に存在するレコードをDELETEした後に新規レコードをテーブル「HOGE」に INSERT

トランザクションAトランザクションB
mysql> DELETE FROM HOGE WHERE COL_INT = 25;
Query OK, 1 row affected (0.00 sec)
 
 mysql> DELETE FROM HOGE WHERE COL_INT = 45;
Query OK, 1 row affected (0.00 sec)
mysql> INSERT INTO HOGE (COL_INT,COL_CHAR) VALUES ( 44,'B');
WAIT状態
 
 mysql> INSERT INTO HOGE (COL_INT,COL_CHAR) VALUES ( 29,'C');
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
トランザクションBがエラーとなったことを受け
Query OK, 1 row affected (7.51 sec)
 

テストケース2

テーブル「HOGE」に存在しないレコードをDELETEした後に新規レコードをテーブル「HOGE」に INSERT

トランザクションAトランザクションB
mysql> DELETE FROM HOGE WHERE COL_INT = 28;
Query OK, 1 row affected (0.00 sec)
 
 mysql> DELETE FROM HOGE WHERE COL_INT = 43;
Query OK, 1 row affected (0.00 sec)
mysql> INSERT INTO HOGE (COL_INT,COL_CHAR) VALUES ( 44,'B');
WAIT状態
 
 mysql> INSERT INTO HOGE (COL_INT,COL_CHAR) VALUES ( 29,'C');
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
トランザクションBがエラーとなったことを受け
Query OK, 1 row affected (11.76 sec)
 

テストケース3

テストケース1と同じくテーブル「HOGE」に存在するレコードをDELETEした後に新規レコードをテーブル「HOGE」に INSERT

但し、COL_INTを非UNIQUEからUNIQUEに変更

mysql> SHOW CREATE TABLE HOGE\G;
*************************** 1. row ***************************
       Table: HOGE
Create Table: CREATE TABLE `HOGE` (
  `ID` int(11) NOT NULL AUTO_INCREMENT,
  `COL_INT` int(11) NOT NULL,
  `COL_CHAR` char(1) NOT NULL,
  PRIMARY KEY (`ID`),
  UNIQUE KEY `COL_INT` (`COL_INT`) ★UNIQUEに変更
) ENGINE=InnoDB AUTO_INCREMENT=14 DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
トランザクションAトランザクションB
mysql> DELETE FROM HOGE WHERE COL_INT = 25;
Query OK, 1 row affected (0.00 sec)
 
 mysql> DELETE FROM HOGE WHERE COL_INT = 45;
Query OK, 1 row affected (0.00 sec)
mysql> INSERT INTO HOGE (COL_INT,COL_CHAR) VALUES ( 44,'B');
Query OK, 1 row affected (0.00 sec)
 
 mysql> INSERT INTO HOGE (COL_INT,COL_CHAR) VALUES ( 29,'C');
Query OK, 1 row affected (0.00 sec)
エラーとならず正常終了エラーとならず正常終了

まとめ

非UNIQUE、UNIQUE INDEXの違いだけでも動きが違いました。

また、トランザクション分離レベルがREAD COMMITTEDの場合ですとテストケース1、2共にトランザクション間で干渉は起こらず正常終了します。

このようにINDEXの種類やトランザクション分離レベル、今回は実施していませんがデータの並び等のその他の要素によっても動きは違ってきます。

今回のような単一行単位でのDELETE&INSERTのようなアプリケーションはどこにでもあると思います。

まずは複数のDML(Data Manipulation Language)でトランザクションを構成する場合にこういう動きがあることを念頭に置くことが大事だと思います。

記事検索
QRコード
QRコード