エンジニア的なネタを毎週書くブログ

東京でWebサービスの開発をしています 【英語版やってみました】http://taichiw-e.hatenablog.com/

CROSS2015 に参加してきました #cross2015

発表しました

CROSS2015というイベントに参加してきました！

パネルディスカッションに参加した！

今回の主目的は、パネルディスカッションへのパネラーとしての参加。

旅行ECサイト各社に聞く成長の秘訣とこれから　と題された、異色のパネルディスカッションに参加してきました。

f:id:taichiw:20150130001315j:plain


一休.comさん、Reluxさん、そして楽天トラベルと、オンライン旅行サイトのエンジニアが集まってパネルディスカッションをするというもので、
正直、始めにお話を頂いた時は、「それ、誰か聞きに来てくれるの…？」という感じだったのですが…

会場に対しては少し少なめではあったものの、多くのお客さんに来場していただけました！


旅行ECサイト各社に聞く成長の秘訣とこれから #cross2015a - NAVER まとめ


私自身は初めてのパネルで、
常に回答を考えながら、そして「これ言っていいんだっけ？」も考えながらで、
結構表情がひきつりながら話していたんじゃないかと思います…。
「子供料金あるある」など、諸々の話題で盛り上がれて楽しかったです。
お互い話し足りなかったようで、ぜひ近いうちに居酒屋で延長戦を！ということで本日は別れました。
もともとこの企画の目的の一つが、エンジニア間での横のつながりを作る　という話だったので、その点は成功だったのかな、と思います。

ただ、お客さんになにか持ってかえってもらえたのかは微妙…。パネルディスカッション難しいですね。

 

アウトプットを意識する　→　とりあえず喋ってみた！　→　いいことあった

代わって、聴講したセッションのお話。

先達に聞くこれからのエンジニア像というタイトルのセッション。
Googleの及川さん、テコラス技術研究所の伊勢さん、そして楽天の吉岡さんのお三方のパネルディスカッションでした。

90分に渡るディスカッションでしたが、特に印象に残ったやりとりを抜粋させていただきます。

自分が成長した、ターニングポイントはどういう時だったか
　→　転職や異動など、環境が変わった時が多い　（3名とも）
　→　自分は自ら環境を変えてしまう。怠け者なので自ら仕事を取りに行って必死に勉強する。IPv6の担当になった時もそうだった。（及川さん）

自らを成長させるための方法
　→　思ったことをやればいい。ただし、やりたいことをやるために、やりたくないことを倍くらいやる必要あり（伊勢さん）

これは俺、似たようなことをつい今朝FBに書いてたな…と思ったり。

f:id:taichiw:20150129231121p:plain

 

そして面白かったのが、
　→　（40歳以降の人は）若い人と話す。若い人にあってもらいたいと思われるような人間で無くてはならない（及川さん）
　→　若い人と一緒に飲んだ時に説教モードにはいってはいけない（吉岡さん）
　→　自分はむしろ説教される（伊勢さん）

このエピソード、途中から酔っぱらいの戯言みたいになっていたのですが、すごく皆さんの学びに対する意識が現れているように感じました。
皆さん年齢も、経験も重ねているのに、いろんな人から貪欲に新しいことを吸収したいのだという姿勢の現れかと！


そして、はっとさせられたのがこの一言。
　→　アウトプットを意識する。呼吸は吸うのを意識するのではなく、吐くのを意識するのが大事。
　　　勉強会に出るのがゴールになってしまってはもったいない。「質問したり」「LTしたり」「ブログを書いたり」
　　　して、いろんな人からフィードバックをもらい、そこから良い所を取り入れる姿勢が重要。（及川さん）

今日のカンファレンスでは、夜の部で1時間半ほども、アンカンファレンスという、野良LTの枠が用意されていました。
気にはなっていたものの、今日はまとまったテーマもないし準備もしてないし…　と敬遠していたのですが、
この及川さんの一言で一念発起。
5分程度の枠ならどうにでもなるわ！　と、とりあえず枠を取らせていただきました。


結局話したのが、以下の話。

f:id:taichiw:20150129231325p:plain


俺、7人位の開発チームのリーダー。
チームのタスクのプランニング／アサインについて悩んでます。
リスク分散や、スクラム的な理由では、「アサイン」をしたくない。全員がすべてのタスクを理解して、自主的にタスクを取って行って欲しい。
一方、「あなたのタスクはこれ！」の方が、よりそのタスク／プロダクトに対して責任感が生まれ、モチベーションは上がる。
悩ましいのだけれど、どっちがいいと思う？

と言うもの。
5分枠のうち、1分半ほどで上の話をさせてもらって、残りはひたすら会場に意見を求めるという、
俺も会場の人も酔ってるからどうにかなるだろ！　的な酷いセッションでしたｗ

幸い、お仲間のメンバーが盛り上げてくれたこともあり、
・2人組にすれば両者のいいところがとれるのでは
・3ヶ月位でのローテーション制
・そもそも会社に自分しかエンジニアがいないのでそんな状況ではない
などの素晴らしい回答を頂きました！


さらにさらに結果的にここで話したことがきっかけになって、この後及川さんともお話させていただくチャンスが。
おそらく、先ほどのパネルディスカッションの後に話しかけに行っても人だかりにまみれて対して話せなかったのではないかな、と思います。
やはり、アウトプットあるところにインプットありだと感じました。

なんでアジャイルなんだっけ

Agile

グループの後輩が二人、James O. Coplien氏の認定スクラムマスター研修を受けてきました。

昨年私が受けた時と同様に、たくさんの刺激を受けて、いろんなことを考え、やりたいこと、悶々としていることがたくさん湧き出ている状態のようです。

当然のことながら（？）、じゃあAgileしたいんだっけ？　Scrumしたいんだっけ？　やりたいことはそれなんだっけ？
というところに一度彼は行き着きました。
その様子を見ていて、「自分はどうだったんだっけ？」と、少し振り返ってみたので、書き記してみたいと思います。
 
自分が最初にScrumに興味をもったのは、タスクボードで皆のタスクを見える化できる点でした。
Scrumとの出会いはほんとうに偶然で、「特にAgileには興味がなく、海外もそこまで興味がなかったんだけど、とにかくプチ移動して他の環境で自分の実力を試してみたかった」という理由で申し込んだ、短期海外異動Agile研修で、Scrumらしきものと出会いました。
そこで、チーム内のタスクを自分だけが把握していることに抱いていた違和感への回答を見つけたのです。
このへんのくだりは昨年、社外で発表させていただく機会を頂きました。

 
さて、上記資料を作ったのは、今から一年ちょっと前です。
この時から、「アサインするのって違うと思うんだけどな－」と悶々としていたのですが、この後、認定スクラムマスター研修をうけて、
「群がる」スクラムのイメージがようやくハラオチします。


私、スクラムを分かってませんでした 〜Jim Coplien氏のScrum Master 研修を受けて 1〜 - エンジニア的なネタを毎週書くブログ

これがちょうど今から一年前です。
 
そしてここから一年間、「群がる」スクラムを試していたのですが、
これはこれで若干の違和感を感じ始め、今年の夏ころからもう一度「個人」にフォーカスした仕事の進め方の検討を始めてきました。

XP祭りでこのLTをした９月の段階では、一人一タスクアサインってサイロを作りがちだしやっぱり微妙かなぁ…　という思いが強かったんですが、
この後きっかけがあり、現在は、さらに各チームメンバーが「自分のタスク」に責任を持ってフォーカスをしてもらう形をとっています。
 
一見すると元に戻ってしまったようにも見えるのですが、自分なりに模索しながら進み続けてきた結果、たまたま一年ちょっと前と似たようなところに立っているのであって、
決して戻ったわけではないと思っています。
今の取組みについては、年末くらいに改めて振り返りたいと思っています。

U+FFFF以上の文字ってなんや　→　サロゲートペアってなんや　→　Spring Web Services が言うことを聞きません！　とかで一日潰れた話

Java

表題のような感じなのですが、これまで理解が曖昧だったUnicodeとか何とかが今までよりわかったのでメモ。

尚、こちらのサイトを非常に参考にさせていただきました。

Unicodeについて

コードポイントとは　文字コードとは

今日覚えた単語その一。Unicodeに限らず、文字をコンピュータ上で表現する際、1つの文字に1つの数値を対応させるわけですが、この文字に対応する数値をコードポイントというそう。
いままでASCIIコードとか呼んでました。

そして、文字と数値の割り当てのルールのことを「文字コード」と言うんだそうです。

Unicodeとは　から　UTF-XXは何が違うんじゃ　という話へ

Unicode誕生

文字コードが乱立したため、あるコードポイントで表現される文字が、文字コードによって、てんでばらばらという状況に。

ややこしいから、ひとつの統一した文字コードをつくろう！　ということで「Unicode」が作られることになりました。

Unicodeを使うときは、U+12ABのように16進数の先頭にU+をつけて表すことにして、
U+0000～U+FFFFの216パターンで世の中の文字を表そう！ってことでUnicode1.0が生まれたそうです。

サロゲートペアの誕生

ところが、特にアジア圏の文字を表そうとしたらこれでは全然足りなくて、U+10FFFFまでUnicodeを拡張することになりました。

しかしこれだと1文字表現するのに21bit必要で、2nじゃないのでとっても切りが悪いという事態に。

そこで、もともとUnicode1.0で使われていた16bitでなんとか表現するために、

たまたま未使用だったD800H～DFFFHを2つ組み合わせ、32bitを使ってU+10000以上を表現するという、むりくりな方法が発明されたそうです。これが「サロゲートペア」。

で、U+0000～U+FFFFの文字をBMP(Basic Multilingual Plane, 基本多言語面)、U+010000～U+10FFFFまでの文字をSMP(Supplementary Multilingual Plane, 追加多言語面)と呼ぶことにしたそうです。

UTF-XX

上記のような経緯を踏まえ、実際にデータ上でどう表すかという、エンコード方式がいくつか考えられたそうです。

UTF-16　→　上の通りのサロゲートペアをそのまま実装した、一文字に16bit使うエンコード方式。一番正直。

UTF-32　→　サロゲートペアはややこしいので、すべての文字に対して32bitを割り当てた方式。一番わかり易いけど、一番無駄が多い。

UTF-8　→　文字に合わせて、8bit, 16bit, 24bit, 32bitのどれかを使うようにしている。Unicodeの中では無駄が一番少なく、最も普及している。

JavaでのSMP

少し話変わってJavaのお話。

突然ですが、Javaのプリミティブ変数のchar型は、上限が (char) 0xFFFF なので、なんとSMPに割り当てられた文字が表現できないそうです！

そこで、Java5.0以降、上記のサロゲートペアの考え方を流用して、SMPは、char2つで1文字を表すようにしています。

Javaでのサロゲートペアの扱いについてはこの記事がわかりやすかったです。

Java とサロゲートペアについて - にょきにょきブログ

Spring Web Serviceが言うことを聞きません！

…と、ここまで説明してようやく私の身に起こったことを。

いろいろありまして、XML上にU+1F6ADのようなSMPを出力する必要がありました。

XMLの仕様的には単純で、数値文字参照を使って 🚭 とか 🚭 と表現できればOKです。

一方、私達のサービスではSpring Web ServiceというSOAPアプリのためのフレームワークを使っています。

こいつ、普段はなかなか便利な子でして、EndPointのレスポンスとしてBeanをReturnすると、そのBeanの階層構造をそのまま反映したXMLを作ってくれるのです。
また、XML上必要なエスケープも自動で行ってくれて、たとえば「＆」が文字列の値として含まれていたら、XMLを出力する際にはきちんと「&」と出力してくれる、という具合です。

では、このSpring Web Serviceを使った時に、
レスポンスのBeanに含まれる hoge フィールドに、🚭(U+1F6AD)が入っていたらどうなるか！？

<hoge>&#55357;&#57005;</hoge>

なんじゃこりゃぁ！？

55357 = D83DH, 57005 = DEADHで、サロゲートペアに分解された上で実体参照として表現されています。

おそらく、String hoge 内のcharの配列を頭から順に1文字ずつ処理してるんだろうなぁ…　と推測されます。

更に良くないことに、D800H～DFFFHはUnicodeでは単独で存在できない文字なので、上記&#55357;や&#57005;はXML上使えない文字で、これらが含まれたXMLは正しくパースされません。

 

結局現状で、XMLを破壊しないためには、Character#isSupplementaryCodePoint methodを使って、SMPを除外する以外方法がなさそう。

うーむ…。

おまけ　Oracle上では

じゃあこの禁煙マークがOracle（UTF-8エンコードで）に入ってた場合どうなるか

select ascii(hoge) from hoge_table;

-> 4036991661

おうふ。

これは、4036991661 = F09F9AADH でして、SMPをUTF-8で表現する場合、やたらややこしいルールで、やたらでかい数値に変換されるため…みたいです。

Javaでequalsを実装するとき -失敗するとcontainsが動かない-

Java

hashCodeはもちろん実装しましょう。

で、

public class 俺のクラス {
   
    private String ore;
    public 俺のクラス (String ore) {
        this.ore = ore;
    }
    public boolean equals(俺のクラス o) {
        return ore.equals(o.getOre());
    }
    ...
}

ってやったらダメ。一見まともに動くんですが…

俺のクラス o1 = new 俺のクラス("hoge");
俺のクラス o2 = new 俺のクラス("hoge");
俺のクラス o3 = new 俺のクラス("foo");

// true
o1.equals(o2);

// false
o1.equals(o3);

Correctionのcontainsがちゃんと動かない。

 Set<俺のクラス> os = new HashSet<>();
os.add(o1);

//もちろんtrue
os.contains(o1);

//trueになるかとおもいきやfalse
os.contains(o2);

正しいequalsの実装はこう。

     public boolean equals(Object o) {
        ほげほげ
    }

 

こんなところでしばらくハマってしまった…

 

 

ちなみにはまってる間、色々調べていてわかったのですが、
HashSetって内部的には単一のObjectをValueにもってるHashMapなんですね。(java7だと)

Mapのキーの管理にSet使うならわかるんだけど実態は逆で不思議。

 

XP祭り2014に参加してきました！ -Agileってなんなんだろう　が少しわかったお話- #xpjug

Agile XP祭り2014

前の記事に続いて、XP祭りのレポートです。

Agile　という　ものにたいしてここ最近モヤモヤしていたものが、
もやもやの輪郭が少し見えてきた　という話をまとめます。

 

アジャイルを手放して得られたこと　から

 

の続きから。

前の記事で書いたように、アーキテクチャとプロジェクトマネジメントはとても大事で、案件中にホイホイ変えるようなものではない。
とはいえ、考えすぎてもわからないことはある。

で、どーするよ　ってところから生まれたのがAgileだというお話。

だからとても画期的だった。

けれど課題があって、
一つが全体整合性の軽視。特にアーキテクチャ。

…うわ、これすげーわかる。
いくらテスト自動化とかしてたって、全体のアーキテクチャを根底から作り直すのはとても時間＆リスクがかかることなので、避けられるものなら避けるべき。
実際Scrumだって、Sprint 0で計画するんですよね。

アーキテクチャにかぎらず計画などもそうですが、
「不確実だから途中途中で見なおす機会を作る」のがAgileなんであって、「最初から全部なんてわかりっこないから、ちょっとずつ決めてきゃいいんです」ではない。

 

…ではないのだけれど、このへんわかってない人間が、
これAgileなんでっ　って、Agileという言葉を言い訳に使った状態
これをAgileのダークサイドと鈴木さんはおっしゃっていました。

 

痛い。

 

痛い痛い痛い。

 

なんか思う所ある。心がまじいてぇｗｗ

 

おっさん、心臓ザクザク刺された気がしてマジ辛くなったっすよこの瞬間。

 

 

じゃあどうするかって言ったら、

大事なのは「良い物を作りたい」という覚悟！

絶対にやってはいけないのは言い訳。
不確実性と、仲間と、プロダクトと、そういったものと向き合う覚悟が大切なのだとおっしゃってました。

それは…多分大丈夫。

 

基調講演から

順番前後しますが、関将俊さんによる基調講演についてのレポートです。

関さんのお話は初めてお伺いしたのですが、これまで数年間、
XPをカスタマイズして、自分たちにフィットする「昔XPだったやりかた」をやっていたと思っていたけれど、

XPエクストリーム・プログラミング入門

というXPの教科書を読み直したら、実はXPの枠からは出ていなくて、　守破離のまだ守でした　というお話。

これを聞いて、あ、今の俺そういう状況なのかもと。
守破離の「離」です！とか偉そうなことを思ってるつもりはないのだけれど、一方で、

スクラムとか、プラクティス多すぎてこれに全部そうとか無理ですわ　勝手にいいとこだけ頂きますわ

みたいのはずっと思ってたり。

もやもやがほんの少し明確になった経験1。

更に関さんのお話で刺さったのが、
「本当の反復は上から下までやること」というお話。
CIで毎日ビルドしてますとか、ちょっとずつ作っていますとか
と言うのは本当の反復ではなくて、ビジネスサイドも巻き込んで、ソフトウェア開発に必要なすべてのプロセスを「反復」して初めて反復であると。

関さんの現場では現在は、時間の単位として「イテレーション」という概念は残っているものの、あまりタイムボックスにこだわらずに、ストーリーの完了までを実施しているそうです。

 

XP祭り2014に参加してきました！ -アーキテクチャとプロジェクトマネジメントが少しわかったお話- #xpjug

Agile XP祭り2014

3年連続でXP祭りに参加してきました。

記憶が薄れないうちに早速レポートを。
一気に書こうと思ったのですが、いろんな言いたいことが混ざってきたのでXP祭りのレポートらしく、イテレーティブに書いていこうと思います。

アジャイルを手放して得られたこと


今回、大変刺激を受けた発表の一つです。
心にグサグサ来たのは後半の「Agileのダークサイド」のお話なのですが、
前半の、「アーキテクチャとは」「プロジェクトマネジメントとは」が、まず私にドはまり。
まさにこのへんが昨今の自分にとって＜なんなのかよくわからない＞ポイントだったのです。

ということで、まずはこの点から。

  • アーキテクチャとはシステムに関わる利害関係者（ユーザ、開発者、プロダクトオーナー、経営者、…）の要望をうまいことあわせたもの
  • これをすり合わせるのがアーキテクトのお仕事
  • アーキテクトの仕事は、事前的。開発が始まってからアーキテクチャを変えるのは大変。
  • アーキテクトは　利用時品質→外部品質→内部品質→プロセス　の順で考える。
  • プロジェクトマネジメントの要素は3つだけ。計画／計測／調整
  • 計画のズレを計測し、調整（ステークホルダーやメンバーと）するのがプロジェクトマネージャの仕事
  • 計画は重要だが、プロジェクトマネージャの腕の見せどころは「調整」。
    なのでプロジェクト開始後の、事後的な仕事がメイン。
  • プロジェクトマネージャは　プロセス→内部品質→外部品質→利用時品質

な　る　ほ　ど。

「いろんな利害が対立する中で、いい落とし所を見つけるのが良い設計」というのは、以前に先輩エンジニアの方からも聞いたことがありました。

◯◯さんはこうしてほしいと思っている
それをやったら☓☓システムに影響が出てしまう
ならばこのやり方ではどうだっ

のような、ある種の「調整作業」が設計の本質なのかもと。

 

一方プロジェクトマネジメントについて。
ガントチャートやらタスクボードやら、広い意味でのプロジェクトマネジメントにはもろもろ「見える化」の方法がありますが、
その目的は「計測」。
そしてその結果を元に「調整」することがプロジェクトマネジメントであると。

 

自分が最近抱えていたもやもやの一端が少しくっきりしたような気がした学びでした。

 

発表後半については次の記事で。

XP祭り2014に参加してきました！ -Agileってなんなんだろう が少しわかったお話-