もやぶろ

moyashidaisukeのブログだからもやぶろ。フリーランスのエンジニアのダイスケです。QOLあげて色々楽しくチャレンジして良く生きたい。プログラム関連とかギター関連とか旅行関連とか色々。

なぜアジャイルをやってみたいのか考える

退職しましたで、「アジャイルやりたいなぁ」と書いたのですが、もう少し掘り下げてみます。


経験した現場の何がダメだった?

  • 成果
    • 予算・期間:オーバー
    • 品質:低い
      • 使いにくい
      • バグ多い

いわゆる失敗プロジェクトですね。

経験した現場がなぜダメだった?

  • 工程
    • 無駄とおもえる作業が多い
      • 大量のドキュメント
      • 生産性が低いフレームワーク、開発の規約
      • 明らかになっているリスクへの無対策により発生するコスト
      • 単体テストまで完了させたのにリリースしない機能(予算超過のため)
    • コミュニケーションエラー
      • 仕様について言った言わない
      • ここからは契約外なのでできません(追加費用が発生します)
      • 追加要求のみしてくるユーザー、1次受け
  • 体制、組織風土
    • 改善提案を受け入れられない
    • PDCA・カイゼン活動をしない
    • リスクコントロールしない
    • 名ばかりの管理者(1次受けの人)
    • 形だけのレビュー
  • 技術力不足
    • 明らかなテスト不足による障害
    • 保守性・拡張性に乏しいコード

集約するとこんな感じかと思います。

  • 開発工程・契約
  • 顧客・開発のプロジェクト管理能力不足
  • 開発の技術力不足


じゃあどうしたらいい?

そこでアジャイルという可能性に出会いました。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。

そう、これだよ!

決められているやり方に縛られて契約上にしか価値の無いドキュメントを作るのをやめて開発作業にもっと力を注いで、「契約だからできない」ではなくてどうやったらお互いにWinWinになれるか考えて、実際には必ず発生する変化を前提に取り組めば、プロジェクトが成功する確率はもっと高くなると思いました。


さらに

ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。

プロジェクトの成功には顧客側の積極的な関わりが必須。

意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。

ヤル気ない人、定時内に出勤している事が仕事だと思っている人はプロジェクトにとってマイナス。いない方がいいです。

技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。

技術者は技術に対する努力をし続けるべき。

最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

組織は人の寄せ集めでは無いです。人員を代替可能なものとして見積もるやり方はもうやりたくないです。



というわけで、考え方にとても共感できました。

この考え方に共感できる人が集まっているプロジェクトなら、とても良い仕事ができるんじゃないか、と。

で、どうする?

SI業界でもアジャイル化の動きが出ていますが、結果が出るのはもう少し先かと思います。
となると、Webサービス系の企業にチャンスがありそうです。
でも、今までやってきたBtoBのSIを、ちゃんと成功させてみたいなぁ、という気持ちもあります。むむむ。





参考

アジャイルサムライ 読書会 埼玉道場(第4回)

超ゴージャスだった第1回に続き、久々に参戦。2回目。


第四回 アジャイルサムライ読書会 埼玉道場


以下、めも。

第3章 みんなをバスに乗せる

  • 基本的にインセプションデッキの内容や目的は、PMBOKのプロジェクト憲章と同じ。でも継続的にメンテをする。
  • 完璧に作れなくても(というか無理)良いので、できる範囲で作成すればおk。ぼやっとしてる部分はぼやっとしている事を明確になっていればおk
  • プロジェクトが立ち上がる前(キックオフの前)に作成するのが効果的?
    • プロジェクト憲章と同じ。

第4章 全体像を捉える

  • 「司令官」って誰の事? => プロジェクトの目標・目的を司令官に例えてるだけなので、具体的にきまっているわけではない。
  • パッケージデザインを作る必要性は?エレベーターピッチと何が違う?
    • パッケージデザインはエンドユーザーから見たメリット。後、作るのが楽しいのでチームの一体感が出るのでは?

第5章 具現化させる

  • 荒ぶる四天王でスコープだけが変更可能としてあるけど、ウォーターフォールでは時間と予算を伸ばすことの方が多かったため、いまいち実感できない。
    • スコープの変更とは機能を削るだけでなく、機能の簡素化(画面の共通化とか)も含まれる。
    • ウォーターフォールの場合、時間と予算には予めバッファを積んである事が常なので、変更しやすいのでは?
  • ステークホルダーとご近所さんの違いは?
    • 第5章の最終判断の下りでの「ステークホルダー」は利害関係者ではなく出資者の意味では?
    • ご近所さんにはステークホルダー(利害関係者)も含むと捉えて良いのでは

その他

インセプションデッキの日本的プロジェクト用翻訳版がある。

インセプションデッキとか、エレベーターピッチとかウォーターフォールでは使わない単語を良い感じに翻訳しているので、「アジャイル」という単語を出さずに進めたい場合に良さそうです。

第31回 HTML5とか勉強会 JavaScript MVCフレームワーク に参加してきた #html5j

行ってきました。

第31回 HTML5とか勉強会
togetter

HTML5勉強会は初めてです。こちらの記事でAngularJSが紹介されてて、面白そうと思ったのがきっかけです。


補欠でしたが、当日キャンセルが出てらしく参加できました。ラッキー。

  • Backbone.js
  • Spine.js

素のJSにかなり近いイメージ。シンプルなので、元々JSが得意な人には小回りが効いて良さそう。Twitter見てると、Spine.jsは勉強に向いているとか。Coffeescriptから勉強しなきゃなんだけど。

  • Ember.js

先の2つに比べると、かなり厚い?感じ。どことなくRORっぽい。

  • Angular.js

さらに厚い感じで、ほとんどJSっぽくない。HTMLベースでちょいちょい動きを変えられて作りやすそう。Play1系のテンプレートみたいだな、と思った。楽しそう。




JS本当に知らないのですが、フレームワークレベルなら違いがわかって結構面白かったです。
Coffeescriptの勉強がてらSpine.jsと、Angular.jsは少し触ってみようと思います。

退職しました

少し前の話ですが6月末を以って、4年と3ヶ月働いた会社を退職しました。


大学を中退し、プロを目指して音楽活動
→音楽を仕事にする事をやめる決断
→未経験で大学中退でもまともに働ける業界って何があるだろう。。。
→IT業界いけんじゃね!年功序列じゃなくて実力主義っぽいし!
→うわ!この業界いろんな意味でksだな。。ITコンサルが一番儲かるっぽいけど、まずはちゃんとエンジニアとしての経験を積まないとだめだな。
→就職!

でした。


SIerからの2次受けが中心の中小企業でしたがとても良い会社だったと思います。

  • 技術支援制度が充実していた
  • 評価もそれなりに実力主義だった
  • 会社の規模の割には給料も良かった
  • 経営(売上・利益)が安定していて、安心して働けた


おかげ様で、SIer系の業界で働く分には1人前のSE、リーダーになれたと思います。


やって来た事(プロジェクト編)

2つの現場を経験しました。

1つ目は基幹システムのリプレース作業(COBOL→Java)で、なかなかひどいプロジェクトでした。。いきなりIT業界を満喫できました。

  • 延期につぐ延期
  • 尽きることのない仕様変更
  • 作業効率最悪の開発環境(Cerlonはやめて。。。)
  • お客様作成のオレオレフレームワーク
  • 作業の足を引っ張るコーディング規約(staticメソッドのみ許可、List禁止・配列でetc...)
  • 本当にテストしたのか疑問が残る他チームの作成モジュール

自分の所属していたチームだけは順調でしたが、それ以外が尽くダメなので、まぁ大変でした。

全体しては色々と問題有り有りでしたが、個人的にはプログラマー→SE→サブリーダー→リーダー という王道(?)を経験できましたし、Seasar2のコミッターの方と一緒に仕事ができたりしました。



2つ目はエンドユーザー会社のIT部門と直契約で、グループ会社への倉庫のパッケージ導入支援でした。
最初から導入したいパッケージが決まっていた状態でしたが、プロジェクトの立ち上げからという、ウォーターフォールで言う超上流に関われました。



やって来た事(プロジェクト以外編)

まず、資格を取りまくりました。

  1. 経験が無いけど、知識としては持ってるよ!が証明できる。
  2. 勉強する人ですよ!が証明できる。
  3. ITの知識無い人でも1,2がわかるよ!

というメリットがあると考えたためです。3番目は資格ならではだと思います。単価上げやすいらしいです。


で、とったのは(順不同)
I-Tパスポート

  • 基本情報処理技術者
  • ソフトウェア開発技術者試験
  • DBスペシャリスト
  • システムアーキテクト
  • SJC-A
  • SJC-P
  • SJC-WC
  • OracleMaster Silver 11g
  • Silver Oracle PL/SQL Developer
  • 簿記3級
  • LPIC Level1

です。最後の1年はとってないので、3年間でけっこう取りました。
また別の記事で詳しく書こうと思います。



後は社内勉強会を作りました。
ここで悩んでますが、約半年間、毎月定期的に開催してとりあえずは軌道に載せることができました。

これも今度詳しく書きたいです。



退職する理由

とまあ、それなりに順調だったのですが、こんな疑問ややりきれない気持ちを抱くようになってきました。

  • 自分がどんなに頑張って成果を出してもプロジェクトとしては成功していない。。。
  • 政治的・契約的な環境に評価が影響を受けすぎていて、成果物が評価されない。。
  • Excelとパワポを作るだけの日々はつらすぎる。。。
  • 技術的な下積みが浅すぎるで将来が不安。。
  • 技術的に刺激を受ける人物が現場にはいない。。。
  • 管理職になる以外のスキルパスが存在しない。

もちろん、自分の影響の輪を大きくしてこれらを解決するという方法もありますが、29歳という自分の年齢を考えると退職して別の環境に身を置く事にしました。


次はこんな環境がいいなぁ、と思ってます。

  • 成果物によりユーザー、社内の評価が決まる
  • 技術重視
  • 新しい技術を積極的に試そうとする
  • すごい人がいる
  • 管理職以外のスキルパスがある
  • 客先常駐ではない
  • ワークライフバランスを重視している(計画的に長期休暇が取れる)
  • 企業理念が明確である
  • アジャイルやってみたいなぁ


これから

すぐには転職活動をせずに充電期間を置きます。

長期の休暇となりますので、やりたい事をやろうと思います。

  1. 普通免許取得(7/11完了!)
  2. 海外旅行
  3. 技術のほりさげ、やりたい技術キーワードの確定

3番目が大事で、プログラミングをちゃんとやりたいんだぜ!と言って退職したものの、何やりたいのかが不明確なのです。なので転職活動もできません。
2012年中にやりたい事が明確になって、マッチする企業さんに転職できればとなんとなく考えています。

しばらくはあちこちの勉強会に顔出してつまみ食いしてみますので、みなさまよろしくお願い致します。

java-ja『LOG.debug("nice catch!")』に参加してきた

参加してきましたー。

http://connpass.com/event/607/

イベントの詳細はしんやさんが素晴らしいレポートを提供されているので省略します。感想だけ。
[勉強会][Java]java-ja『LOG.debug("nice catch!")』に参加してきた #java_ja"]

java-jaと自分

java-ja自体は昔から(3年位前?)知っていたのですが、当時はTwitter等のSNSやATNDのようなイベント管理サービスは無く、興味はあるけどなんか怖い状態でした。

で、やっと参加できる機会がやってきたわけです。うれしい!

感想

すごく楽しかったです。小学生みたいな感想で申し訳ないですが。

言語とか主催者によってイベントの雰囲気はすごく違いますが、java-jaはとても緩いです(懇親会10分!)。でも心地良い。

心地良いのは、きちんとしたバックグラウンドの知識を持っているという前提が、共有できているからだと思います。今回は人数が多すぎて、直接お話する時間があまり取れなかったのが少し残念でしたが、それは次の機会という事で。


結論

  • 関数型も身につけよう→積本になってるコップ本を再開しなきゃ。。。
  • 達人プログラマーとかEffectiveJavaとか、もう一度ちゃんと読もう→読書会形式とかにしようかなぁ。
  • GREEぱねぇ!

Webサービスを作るってみるその2 OpenIDでmixiと連携

今回はOpenIDを使用して、mixiとの連携機能を作成します。

Play1系で、しかもJavaで、しかもmixiと連携しようという方はきっと少ないでしょうが。。。。

ちなみに、PlayにはOpenID用のライブラリが標準で用意されてますので楽チンです。


mixiのOpenID仕様

オフィシャルはこちら。

単純にmixiにログインしているかどうかだけでなく、マイミクシィ認証とコミュニティ認証という機能があるのが面白いですね。
コミュニティ認証を使って、見られる範囲の制限なんかに使えそうです。(所属しているコミュニティのセッションだけ参加できるとか)


概要

下記を参考に、認証機能を作成していきます。

想定する動作は、

  1. 画面上で [mixiでログイン] のアイコンをクリック。
  2. サーバから mixiの URL へ OpenID を要求する。
  3. mixi からリダイレクトで認証レスポンスの呼び出し。認証に成功していれば OpenID を取得。
  4. OpenID に含まれるmixiのnicknameをセッションに保存する。

※ログインしていない場合は、必ずログイン画面に遷移させる


ログイン画面

まずはログイン画面。

まずはログイン用のボタンをmixi公式から取得して、public以下に配置します。

で、ログイン用のviewを作成。

#{extends 'main.html' /}
#{set title:'ログイン' /}

<div class="container">
<div class="row">
<div class="span8 offset4">
<div id="login">
	<h1>&{'secure.title'}</h1>
		<div class="control-group" >
			#{if flash.error}
				<p class="error">
	    			<div class="control-group error">
		    	        <label class="control-label" for="inputWarning">&{flash.error}</label>
	            	</div>
				</p>
			#{/if}
			#{if flash.success}
				<p class="success">
					&{flash.success}
				</p>
			#{/if}
		<a href="@{Auth.mixi()}">
		<img src="@{'/public/images/login_btn002.png'}" ></a>
	</div>
</div>
</div>
</div>
</div>

ログインボタンにAuth.mixi()へのリンクを作成しただけのViewです。


認証Controllerの作成

認証用のControllerであるAuthを作成します。

package controllers;

import play.libs.OpenID;
import play.libs.OpenID.UserInfo;
import play.mvc.Before;
import play.mvc.Controller;

public class Auth extends Controller {


	@Before(unless = { "login", "mixi", "logout" })
	static void begin() {
		if (!isLoggedIn()) {
			login();
		}
	}

	private static boolean isLoggedIn() {
		return session.contains("username");
	}

	public static void login() {
		render();
	}

	public static void mixi() {
		authenticate("https://mixi.jp");
	}

	private static void authenticate(String url) {
		// 認証完了のレスポンスでなければ OpenID の検証を要求する
		if (!OpenID.isAuthenticationResponse()) {
			OpenID.id(url).required("nickname").verify(); //nicknameも要求する
			return;
		}

		// 認証処理の結果を評価
		UserInfo user = OpenID.getVerifiedID();
		if (user == null) {
			flash.put("error", "認証に失敗しました");
			login();
		} else {

			// 認証完了
			String nickname = user.extensions.get("nickname");

			session.put("username", nickname);
			render("@Application.index");
		}
	}

	public static void logout() {
		session.clear();
		login();
	}
}


ポイントはいくつかありますが、

  • @Beforeでログイン有無を確認(@Withと組み合わせ。後述)
  • OpenID.requiredに"nickname"を指定することで、戻りにニックネームを含めてもらう
  • OpenID.extensions.get("nickname")で、戻りのニックネームを取得

でしょうか。

認証完了の処理はとりあえずニックネームを取得しているだけですが、アプリで管理するユーザーとのひもづけとか、色々やる予定です。



他Controllerとのひもづけ

「※ログインしていない場合は、必ずログイン画面に遷移させる」を実装します。

他のControllerに@Withを使うだけです。

@With(Auth.class)
public class Application extends Controller {


確認

いいですね!


でもこれ、テストどうすればいいんですかね?
mixiのログイン状態に依存するので、すごい難しそうですが。。。。

Webサービスを作るってみるその1

Webサービスを作ってみる事にしました。


アプリ概要

自分は趣味でギターをやってるんですが、セッション会という名のオフ会によく参加しています。
で、事前にmixiのコミュニティで選曲やらパート分けやら、アレンジの相談をして当日に臨むのですが、掲示板の機能だけではわけがわからないので、みんなgoogle docや、自作のHTMLや、Wikiで管理してます。

これを、誰でもできるようにしちゃおうぜ! というシステムです。超絶ニッチですね。



アーキテクト

play framework1.2.4 + twitter bootstrap + Heroku で。

とりあえずScalaは使わない。
一気に新しい事に挑戦しすぎちゃうと、自分の実力ではいつまでたってもリリースできませんorz


バージョン管理はgithub。タスクもgithubのissueで管理。DBはとりあえずHerokuの無料範囲で。


というわけで

とりあえずなんとなく画面イメージがわかる位まで作って公開しました。

http://miximusicsession.herokuapp.com/




ちまたでは良く言われてる事ですが、とりあえずでも公開まで持ってくというのは勉強になりますねー。

なんとなく良さそうなのでこのまま作り続けます。6月末位までに一段落が目標です。

話かわりますが、playframework使いやすいです。良い意味でJavaっぽくなくて楽チン。

NULLデータとINDEX

現場ではまったのでメモ。



RDBで、SQLのWHERE区に「IS NULL」をつけるとINDEXが効かないというのは普通だと思ってたのですが、最近はどうやら事情が違うみたいです。





■Oracle
△(限りなく×に近い)
[http://docs.oracle.com/cd/E16338_01/server.112/b56306/indexiot.htm#sthref293:title=マニュアルより引用
]

Oracle Databaseでは、すべてのキー列がNULLの表の行には、索引は作成されません。ただし、ビットマップ索引の場合や、クラスタ・キーの列値がNULLの場合は例外です。

ビットマップ索引は使い所が限定されるので、基本効かないと思って良いでしょう。



■SQL Sever
◯らしい
参考
参考

オフィシャルは見つけられませんでした。。


■DB2

参考
マニュアル
ユニークキーに対するINDEXならNULLはOKだよ、という風にも読み取れる??



■MySQL

参考



■PostgreSQL
◯(8.3以降)
参考
参考




Oracleだけダメみたいですね。せめてオプションで使えるようにならないかなぁ。

天災の時の会社(現場)の対応を考える


今日2012/04/03は爆弾低気圧の影響で交通機関が大きく乱れています。(真っ最中)
自分は15時に現場を出て無事に帰宅しましたが、帰宅困難者がこれから発生すると思われます。

  • 3/11で緊急時の対応について、一旦は考えられたはず
  • 交通機関の乱れが発生する事が予め判明している
  • にも関わらず電車が止まってから早退許可が出た会社(現場)がある
  • そもそも早退許可を出そうという発想が無い会社(現場)もある

現場の状況もあるので敢えて帰宅させないという判断もあるとは思いますが、恐らく一部の話しで、
ほとんどは誰が決定権を持っているのか良くわからず、判断を保留にしていたら本当に嵐が来て、慌てて許可を出したんじゃないかと思います。


残念ながら上記のような判断になってしまった会社(現場)は、「リスク管理が出来ていない」「従業員を人と思っていない」「失敗から学ぶことがない」のいずれかなので、3/11のような大震災・何らかのトラブルの時も同じ結果になります。

予見されているリスクに対して、しっかりとした対応がとれない会社(現場)は残念です。そうじゃない会社(現場)は良いですね。本当はそれが当たり前のようになって欲しいですが。



でも、最終的に自分の身を守るのは自分という意見も当然で、会社を選ぶ権利も、緊急だからという判断で自主的に帰宅する判断もあるわけです。会社のために自分がいるのか、自分のために会社に所属しているのか。

HerokuでPlay!を動かす その2

Egitというプラグインで、EclipseでGitを使う。
Herokuで動かすので、GitHubで管理する。

IDEに慣れてしまっていて、エディタだけで開発できるほどのスキルは自分には無い。。(慣れの問題かもしれないが。)

こちらを参考に進めるも、pushするために接続するところでエラーが発生する。

The authenticity of host 'github.com (207.97.227.239)' can't be established.
RSA key fingerprint is ほげほげ
Are you sure you want to continue connecting (yes/no)? yes


sshの仕様で、known_hostsに設定が無い接続先に初回接続すると出るアラート(エラーではない)らしい。
コマンドであれば「yes」と打てば終わりだが、Egitでは先に進めないっぽい。

なので、コマンドから一度pushしてあげると、Egitからでもpushできるようになった。
多分known_hostsの設定をしてあげてもうまくいく。

アジャイルサムライ 読書会 埼玉道場(第1回)+@

行ってきた。

アジャイルサムライ 読書会 埼玉道場(第1回)


最近横浜とかでやっているのは知ってたけど、ちょっと遠いのと平日は出張が続いているので難しいなーと思ってたら、なんと土曜日開催。場所も埼玉。
自分のためにあるような会じゃないっすか。というわけで参加。

自分のレベルはこんな感じ。でもウォタ−フォールは正直もう嫌です。

  • アジャイルサムライは一通り読んだけど、実践した事はない。
  • 具体的なプラクティスは概要レベルしかしらない。


午前中の社内勉強会が押して30分遅れで行ったら
「あれ?何か外人さんがいる。」

なんと、アジャイルサムライの著者Jonathan Rasmussonが来てるではありませんか。Jonathanに会いにAgile Samurai Dojo Gathering申し込んだのに、フライングで会えるとはラッキー。すごく気さくな良い方でした。

翻訳者の西村直人さんも途中からいらっしゃいました。



第1章〜第2章の途中まで読み合わせ&小グループで気になる事について議論。



■第1章 ざっくりわかるアジャイル開発
詳細はあまり出てこないとこなのであまり無いけど、

3つの真実
1.プロジェクト開始時点にすべての要求を集めることはできない
2.集めたところで、要求はどれも必ずといっていいほど変わる
3.やるべきことはいつだって、与えられた時間と資金よりも多い

これは激しく同意。ウォーターフォールの場合、不可能な事(基本的に手戻り無し)を前提にしてるから、現実的には破綻しちゃうよね、そりゃ。


■第2章 アジャイルチームのご紹介
顧客大事。

ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。

アジャイルは大変だと思うけど(うまく行けば成果は大きい)、実践する上で一番ボトルネックになりそうだなーと思う部分。
自分は開発側だから、がんばれば影響の輪の中に開発T全員を入れる事はある程度可能なんだけど、顧客はなかなか難しそう。顧客にもアジャイルについて理解してもらって、実践してもらわないといけない。

BtoBだと、SIerに丸投げみたいなのが良くある話で、顧客側にも意識改革してもらう必要がある。

対策として、とりあえず2週間で成果を出して信頼を得るという方法を提示してあるけど、足りない。何か考えないと。


ゼネラリストはアジャイルプロジェクトに向いている。

ありがたいお言葉。純粋なコーディング力だと全然勝負にならないけど(でもSIer業界の中ではかなりましな方)、一応要件定義〜リリースまで一通りできるので。燃えてるチームに配属されて火消しをしまくってた事も無駄じゃなかった。。。


後半は、マスターセンセイ(Jonathan)に質問コーナー。

本に書いてある事は省略するとして、

Q「QDCS(品質、納期、費用、スコープ)の話が他のアジャイル本に比べて良く出てくるのはなぜ?」
A「QDCSの中でスコープだけが唯一変更可能。スコープの大事さを開発Tも顧客も理解して欲しいから。」


Q「なぜアジャイル『サムライ』?」
A「『ピースフルウォリアー』という本がすごい好きで、自分のBlogを『アジャイルウォリアー』という名前にした。本も同じ名前にしようとしたけど、編集者と話し合って今の名前になった。正直サムライの事は良く知らないんだけど、ばったばったと切っていく感じがイメージにあってる。」
※関係ないけどこんなの見つけた

アジャイル ウォーリアー

アジャイル ウォーリアー


Q「期待をマネジメントとは?」
A「最初の期待が低めに設定してあって(low expectation)、思ったより成果が良かったらすごいうれしい(Secret Happiness)。逆に、できない事をできると言ってしまうとうまくできなかった時の失望は大きいので、そんな事は決して言ってはいけない。」

スコープだけ変更可能(調整可能)である事を熱心に説明してた。


池袋のジュンク堂でトークセッション「Agile Meets UX〜アジャイル開発とユーザエクスペリエンスの遭遇〜」があるという事で、打ち上げを途中で切り上げてこちらにも参加。

あまりUXを気にした事がなかった(というかそこまでの期間・コストの余裕があるPJの経験が無い)自分には、初めての知識ばかりで良かった。
アジャイルやるからには色々しらないと。


UX(ユーザビリティ)テストの歴史の話+3人でアジャイルとかテストとか色々。

特に印象に残った内容は↓

  • どんなテストでもやらないよりはマシ。
  • UXテストは予算に比べてコストが高くなってしまう事が多いので、まずは関係無い部署の人とか友人とかを利用すると◎
  • 全員が全ての事を知ってればPJは上手くいくんだけどそんな事はありえないので、みんなで取り組みましょう。


いやー、濃い一日だった。著作者と翻訳者の3人に一度にお会いできるとは。
参加者もBtoCとかソーシャルゲームとか、コンシューマーゲームとか色々な経歴をお持ちで、お話するだけで面白かった。

主催のinda_reさんを始め、皆様ありがとうございました。
そして英会話を勉強しよう。。。

社内勉強会を盛り上げたい

去年の12月から社内での勉強会を主催してます。

会社は70人位で、客先常駐でJavaのWebシステムを作る事が多いです。2次受けが多いかな?

もうすぐ3回目なのですが、いまいち参加人数が増えずに困っています。というわけで振り返ってみました。


■なぜ勉強会を開催したのか
ずばり、技術軽視の傾向を打破したかったから。

  • ある程度SEとして1人前になったら管理職になる以外のキャリアパスが無い
  • 開発は何年もやってなくて客交渉だけやっている人が高給をもらってる

というわけで、もっと手を動かしたい自分としては色々不満があったわけです。

転職しようかとも思いましたが、ちょっと悪あがきをしてみる事にしました。

勉強会という名目で、色々な技術に触れる機会を作れば、多少はこの空気が変わるといいな、と。

技術を軽視しているソフト会社に未来は無い、と個人的に思っているので、恩返しの意味も込めてます。



■勉強会の内容
平日の夜だと頭が回らないので、土曜日のAMに月一回の頻度で開催してます。
1回目は「Java7」。
2回目は「Androidアプリ」。
3回目は「Scala」。
後はJenkinsとかHadoopやりたいです。

ペアプロでハンズオンで、@ITとかの入門用ソースを動かして遊んでます。



■開催してみて
参加者は毎回7名程度。ほんとは15人くらい来て欲しい。
参加者からは好評なんですが、元々社内では意識が高い人が集まっているので、そもそもの目的はまだ果たせてないです。


                                                                                                                                            • -

どうしたもんかなー、と思いぐぐってみた所、こんなのを見つけました。
「社内勉強会」から透けて見えるもの

ふたを開けてみると、
その早朝勉強会の常連出席者は、
意欲があって実績も出しているような、
成長まっさかりの若者ばかりになってしまったというのです。

成績が上がらず悩んでいる人こそ、
成績の普通なみの人に追いつくためにも、
人一倍の勉強をしないといけない。

にもかかわらず・・・、

実績を上げつつある人たちこそが、
「もっと学びたい!」と考えて
早朝の勉強会に集まってくるという、このパラドックス。
皮肉なものです。


むむむ。



これも見つけました。
社内勉強会のきっかけ

どうして人が集まらないのか?
①”勉強会”から連想するイメージが重い。
②自分が誘われていると思っていない。
③勉強会に参加する理由が分からない。

まさに今の状況。特に②③。

ujtommyさんはラブレターを後輩に送ったとの事ですが、
まずはメールなり口頭なりでみんなに声をかけてみようと思います。

社長に参加してもらうってのも面白いですね。


よし、やってみよう。

HerokuでPlay!を動かす その1

動かしてみました。

最近Scala絡みで注目しているPlay! にネイティブ対応してるという事で、
今後使う機会がありそうだなーと思ったのと、デブサミでセッションに参加したから。



■参考
Getting Started with Play! on Heroku/Cedar
Play! on Heroku 翻訳



基本的にオフィシャルの通りなんだけど、詰まった所を。

■公開鍵でエラー
git push heroku master でエラー
「permanently added the rsa host key for ip address」
ssh 接続しようとすると「WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!」が表示されるときは


heroku loginで作られるはずが、Gitで作ったやつを見て新規で作らないという判断をしてた??


何はともあれ、Heroku用に作成。

$ heroku keys
=== 1 key for hogehoge@gmail.com


これでOK。


■no Rails or Rack app detected

$ git push heroku master
Enter passphrase for key '/c/Documents and Settings/user.XXXXXXXXXXXX/.ssh/id_rsa':
Counting objects: 34, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (26/26), done.
Writing objects: 100% (34/34), 38.41 KiB, done.
Total 34 (delta 2), reused 0 (delta 0)

          • > Heroku receiving push

! Heroku push rejected, no Rails or Rack app detected

To git@heroku.com:gentle-snow-9959.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'git@heroku.com:gentle-snow-9959.git'

実は凡ミスで、heroku create する時に一回オプションつけ忘れて、
オプション付けてもう一回createしたのが原因。

gitのremoteが最新のcreateさらた先にじゃなくて、1回目の方を見続けてしまうらしく
間違ってcreateしたやつを一生懸命デプロイしようとしてた。

なので、gitのremoteを変更してOK.


■画面
表示はされたんですが、#{welcome /}の部分が出てない。。。


今日はここまで。

デブサミ2012 2日目

2日目だけですが行って来ました。(一日目は仕事の調整がつかず断念)
初参加です。


セッション一覧とtogetterまとめ
レポートまとめ

以下、概要と感想。
※スライドはまだあがってないみたいなので、確認できしだい追記します。


■【17-A-1】Continuous DeliveryとJenkinsアブストラクト/川口 耕介 氏
※途中参加
本当はこれじゃないのに参加予定だったんだけど、会場が変わってたっぽい。
元々こっちみたかったのでラッキーだった。

Jenkins使って、開発とかテストとか全行程でトレーサビリティー実現しようよ、という話。


■【17-B-2】JavaOne Tokyo と Java の今後について/寺田 佳央 氏
Developer summit2012
あまり新しい話は無し。(去年のJavaOneとほぼ同じ)
満席になっておらず、Javaの没落っぷりを感じてしまった。。。

  • J2EE6をもっと使おう!(7は6前提だから、ますます世界から置いて行かれるよ!)
  • 2年毎にJ2SEリリースします!
  • Duke知ってるよね!

との事でした。J2SEの2年毎ってのはけっこう驚き。本当にできたら良いですね。



■【17-D-3】Androidの最新技術動向/安生 真 氏
デザイン関係のリンクの紹介と、4.0での障害の紹介。
4.0以前ではたまたま動いていたのが、4.0で動かなくなったというのが多いっぽい。
(ブラウザを起動するのに明示的なIntentでデフォルトブラウザーを直書き指定とか)

きちんとお作法に則っていれば大丈夫そうなのが多そう。

経営者なのかな?お年を召した方がちらほらいたのが印象的。


■【17-B-4】マイクロソフトの変化を体現するAzureエバンジェリスト2人が語る今後10年を見越したオープン戦略/砂金 信一郎 氏 / 佐藤 直生 氏
Devsumi2012 Node.js on Azure
MSもオープンソースWelcomeになりました、Azure使ってね!という話。時間切れ。
Node.jsに対応しているのは良いですね。

メガネ属性持ちじゃないので、ななみの方が好きです。
http://msdn.microsoft.com/ja-jp/windowsazure/gg194745



■【17-E-5】震災とHackとクラウドと/冨田 順 氏 / 菅 祐貴 氏 / 亀渕 景司 氏
デブサミ2012_震災とHackとクラウドと
個人的にはベストセッション。
震災時に、ミラーリングサイト作った話。

  • 国内のクラウドベンダー総動員
  • Indexページはサクラで、ファイルは他のクラウド環境にリンク。JavaScriptで乱数による負荷分散(!)。
  • 48時間後にはほぼ形ができてスタートできていた。

1年前、GoogleとかTwitterとかITの力を目の辺りにして、自分は何もできなくて悶々としてたのですが、
技術力の問題ではなく「やる」か「やらない」かという違いでしか無かったらしい。

亀渕氏は、セッションのリスナーの方との境目なんて無いとおっしゃっていましたが、
「やる」か「やらない」かという違いはものすごく大きいです。


自分の技術力なんてたかが知れていますが、まだまだ人が足りないとの事で、
調べてアクションしていきます。



■【17-B-6】Building scalable web apps/Christopher Stolt 氏
Herokuの中の人。
英語だったのでほとんどわかりませんでしたorz_

PaaSの一般的な話に近いですが、インフラとかはHerokuがやるのでアプリ開発に専念できるよ!
という趣旨でした。

まだちゃんと使った事ないですが、PaaSの中では変な縛りが少ない方で使いやすそう。


■【17-B-7】ソーシャルコーディングの世界/松田 明 氏
ソーシャルコーディングというか、GitHubの世界の話。

誰でも自由に公開ができるオープンな世界→基本的人権の獲得!

という事でした。切り口が面白かったです。
こういう世界を持ってる人と持ってない人(主にSIer)は、どんどん差が広がっていくと思います。

趣味の音楽の話しになりますが、mixiのお陰でセッションが気軽にできるようになり、
世界が広がったのと同じですね。




他のセッション含めて、情報量が多すぎるので1週間くらいかけて確認してこうと思います。

LTO Ultrium

現場で棚の整理をしていたら、出てきました。

HP(旧コンパック) HP LTO4 Ultrium 1.6TB RW データカートリッジ C7974A

HP(旧コンパック) HP LTO4 Ultrium 1.6TB RW データカートリッジ C7974A


テープなんて未だにつかってんのね、と思ったのですが、
最近のテープメディアを舐めてました。

http://ja.wikipedia.org/wiki/Linear_Tape-Open


LTO-5 [編集]
2010年1月19日に規格がリリースされた
2010年第2四半期に出荷された
容量が更に倍になり、1.5TB に
転送レートは最大140 MB/s に
デュアルパーティショニングをサポート。各社共通のファイルシステムLinear Tape File System(LTFS)をサポート。


1.5TB!!!すげーーー!!

新しい規格での開発も進めていて、まだ増えるみたいですね。