Event on yusuiked's blog

2016 年振り返り

yusuiked@gmail.com (yusuiked) — Sat, 31 Dec 2016 23:30:00 +0900

今年も早いもので振り返りの時期が来てしまった。ブログの記事一覧見たら今年結局退職エントリしか書いてない…。何もしてなかったわけじゃないはずだけど。。。とりあえず来年の自分のために書いておこうと思う。

個人的に今年は Day One に思ったこととかやったこととかを1日単位で記録するようにしていた。そのおかげで、1年何やってたかはそれを見れば大体わかるんだけど、今見直していて思うのは割と内向きにコツコツやっていた感。

仕事

今年前半は、面倒見てたシステムの移設にかかりっきりでそればっかりやってた気がする。大きなメンテをうたなければいけないこともあって、大分準備や確認に手を取られていた。大きな問題なく終えることが出来たのは良かった。

その後は、メンテされなくなっていた自作フレームワークを自分でメンテナンスしたり、化石バージョンの Elasticsearch からデータを救ったりと、とにかく落ち葉拾いをしてた。もはや日が当たらなくなっていたけど、まだまだ屋台骨を支えている部分だったし、それができそうなのがもう自分しか居なかったし、大きく作り直すこともないだろうという判断からやっていた。結果的にそのコードが今は動いているから、それは良かったんだろうと思うようにしている。たぶん。これをやるにあたって github.com

や github.com

のソースコードを読んだり、 java.nio.* を改めて読んだりそれを使って簡単なサーバ書いたりもしていた。それは自分としても大分勉強になった。

後半は組織的な課題が大きくなってきていたのを何とかすべく、どっちかというとエンジニアというよりは社内エバンジェリスト的な感じで動いてた。海外から Spring のコミッタを呼んで社内勉強会をしたり、社内で Spring + Cloud Foundry のハンズオンを開催したり。この辺は @making さんに感謝してもしきれないくらいお世話になった。

で、転職した。その辺りは退職エントリ

サイバーエージェントを退職しました

をば。前回の転職と違うのは、今回はとても多くの人の話を聞けたこと。今後を考えていく上でとても貴重な意見を多くの方にいただけました。その節はありがとうございました。

で、今は

リクルートマーケティングパートナーズにジョインしました

にて開発支援エンジニア的な立ち位置で教育系サービスに関わるエンジニアの支援をしてます。この辺りについてはおいおいこのブログでも書きたいなと思っています。

課外活動

今年は勉強会参加エントリとかも書けてなくて、これは別に急に行かなくなったわけではないんだけどどちらかというと自分の中で厳選していたのと、仕事がそれなりに忙しかった＋転職活動なんかもあったりしてそこまで力を注げなかったというのが言い訳。

そんな中でも、今年は初めての海外カンファレンスとして Spring One に参加したことが大きかった。参加レポートは前職のブログに書いたのでそれを貼っておきます。

何気に Codezine のレポート記事からもリンク貼られてました。ありがとうございます。

codezine.jp

まったくコミュニケーションが取れなかったわけじゃなくて、どっちかというと思ったよりも喋れたり聞けたりできたことで、どっちかというと自信にはなったのだけど、やっぱりまだまだ自分が喋りたいことがすっと出てくるわけじゃ全然ないので、読み書きも含めて英語は継続的にやっていかないといけないと思ったのが帰国してから思ったこと。あぁでももうあれから4ヶ月経って、英語に触れ続けられる環境じゃないとこの経験が薄まっちゃう気がして、やっぱり環境大事だな、と思う。

プライベート

そんなに出かけてないかなと思ってたけど、振り返ってみると春夏秋冬と意外と行ってた。ついでにラスベガスも。

3月台湾
6月ディズニーシー
8月ラスベガス
9月修善寺
12月富山

あと引越し

そうだ、あと引っ越ししてた。前の家は悪くはないんだけどいかんせん古くて水回りに対するストレスがやばかった。引っ越したとこは賃貸で新築のとこ入って、地理的には若干不便ではあるけど風呂がとてつもなく良くて QoL 上がりまくり。家帰ってくるのが楽しみになった。

目標振り返り

できなかったことが多くてアレな感じだけど。前半は仕事、後半は転職やら引越しやらで結局プライベートでいっぱいいっぱいだった…。

年間目標
- 結局追われてた方が多かった
ブログ
- さんさんたる結果
書くこと
- 全然できてない
GitHub
- 目を覆いたくなる
なんかライブラリ書く

2015 年振り返り

yusuiked@gmail.com (yusuiked) — Thu, 31 Dec 2015 23:45:28 +0900

紅白見つつ例年通り、振り返りやっておきます。ギリギリ。

課外活動

今年は大きめの発表をしたことが大きかった。

準備は大変だったけど、その分すごくいい経験だった。チャンスを与えていただいた皆さんには改めてお礼を言いたいです。ありがとうございました。

LT

アドベントカレンダー

何気に 100 ブクマ以上行ったの初めてだった。

Java で引数の null チェックで迷った話

yusuiked@gmail.com (yusuiked) — Tue, 15 Dec 2015 17:00:00 +0900

これは Java Advent Calendar 2015 の 15 日目の記事です。

昨日は @opengl_8080 さんの Byteman 使い方メモ＋α でした。明日は @irof さんです。

前置き

ついこないだチームでちょっとだけ話題に上って、みんなある程度指針は持っているものの、割と悩みつつ明確に答えを出せなかったので、もっと良い意見があればと思って晒してみます。まぁよくある話だし、Java 8 で Optional が使えるようになって null について語られるケースが増えたと思うので、再考するちょうどよい機会になればいいなーと思います。初心者向けです。

どう処す？処す？

こんな状況の時にあなたならどうしますか？

// Generics なのは例です。String でもなんでもいいです
public T doSomething(T input) {
    // input が null の時にどう処す？処す？
}

もちろん、呼び出し側のコンテキストとか、ライブラリを何使うかとか、Java 8 or それ以前とか、そういった前提によっていろいろ対処は変わってくるとは思うのですが、いくつか選択肢があると思います。良い悪いを置いといて、よく見るのは、

null を返す
何らかのデフォルト値を返す
java.lang.IllegalArgumentException などの例外を投げる

辺りかなぁと思います。null を返すパターンの時は、もし返り値が Collection や配列なのに、null 返しちゃうようなのを見かけたら、Effective Java をそっと差し出してあげてください。

おぬし気が効いてるのう

個人的に、以下のような実装を見たら、おお、おぬしホスピタリティを心得ておるのぅ、って思います。

Null Object パターンで何もしないオブジェクトを返す
- これも一種のデフォルト値を返すパターンと言える

public interface Command {
    void execute();
}
public class ABCCommand implements Command {
    public void execute() {
        System.out.println("ABC");
    }
}
// こいつが Null Object
public class NullCommand implements Command {
    public void execute() {
        // do nothing
    }
}
public class Main {
    public static void main(String... args) {
        Command missing = createCommand(null); // 普通こんなことやらないけど
        missing.execute();  // createCommand の戻り値が null だったら〜という null チェックが要らない
    }
    public static Command createCommand(String name) {
        if ("abc".equals(name)) {
            return new ABCCommand();
        } else {
            return new NullCommand();
        }
    }
}

ガード節を表現する実装をする

Groovy で寒い冬を乗り越える話 #gadvent

yusuiked@gmail.com (yusuiked) — Sun, 06 Dec 2015 08:00:00 +0900

これは G* Advent Calendar 2015 の 6 日目の記事です。

昨日は @saba1024 さんの [Groovy]RatpackでシンプルなWEBアプリケーションを開発する -JSONとJSONPを扱う- でした。

明日も @saba1024 さんです。

前置き

自宅、寒いんですよ。鉄筋かつ建物自体が古いのもあってか、断熱性が悪くて家に帰ってエアコン付けてから温まるまで、結構時間かかります。みなさんもこういう経験よくあるんじゃないでしょうか。先に帰宅した者負けみたいな。

マーティがホバーボードに乗ってるはずの 2015 年にもなって、出先からエアコンを付けられないなんておかしい！！！１１１

とゆーことで、買いました。IRKit。

IRKit - Open Source WiFi Connected Infrared Remote Controller

割と有名だと思うので、ここで IRKit がどういうものかという説明はしませんが、ざっくり言うと WiFi で繋がる学習機能付き赤外線リモコンです。また、HTTP をおしゃべりできるので、あんなことやそんなことがいろいろできちゃいます。

IRKit は基本的には家の中のネットワークから使うのですが、IRKit にはインターネット越しに信号を送れる Internet HTTP API もあったりして、至れり尽くせりです。ただ、一つだけ面倒な点があって、赤外線データは IRKit 自体ではなく iOS アプリが保持する仕組みになっているため、家族のスマホで共有するのが面倒という事があります。

なので、情報自体は一つにしてしまって、外部から自由に信号を送れたら、冬でも暖かい生活が送れる！と思っていろいろ調べていたら、同じことを考えている人はいるもので、すでにあるんですね。

IRKitの自分専用APIサーバ＆自分専用UIをHerokuに立てて快適生活を目指す - As a Futurist…

あるんですが、Ruby です。まぁ、そのまま Ruby で使っても良かったんですが、なんとなく、Ruby にあるなら Groovy（か Java）にもあるやろ！！と思って、探してみたんですが無いんですねこれが。

そこで、せっかくなので作りました。

Girkit
Girkit-api-server

Girkit

github.com

はい、ruby-irkit のパクりインスパイアです。本当にありが（ry

読み方は「じゃーきっと」で、これは IRKit のクライアントライブラリになっています。できることは本家と同じで、

JJUG CCC 2015 Fall で発表してきた＆参加してきた #jjug_ccc

yusuiked@gmail.com (yusuiked) — Mon, 30 Nov 2015 23:26:00 +0900

夏の JSUG の発表に引き続き、JJUG CCC でも発表させていただきました。JJUG は普段もよく参加させてもらっていましたが、登壇は初だったので緊張しまくりでした。が、滞り無く終わってホッとしています。

資料はこちらです。

jOOQ と Flyway で立ち向かう、自社サービスの保守運用 #jjug_ccc #ccc_ab1 from Yusuke Ikeda

www.slideshare.net

心境など

裏番組がどれも有名な方のセッションだったし、発表していなかったら自分も他の方のセッションを見に行きたかったくらいなので、正直見に来てくださる方は居るのかな…と不安になったりもしたのですが、逆に考えると、それでも私のセッションを見に来てくれるということは、何かしらタイトル通り運用保守で課題を抱えてらっしゃる方が多いのでは、と自分の中で勝手に思って、何か１つでも現場に持ち帰ってもらえるように心がけよう、と思っていました。

その後、感想などを見ると好意的な意見が多く、頑張って良かったなーと感じます。当日聴講していただいた方々には、改めてお礼を申し上げます。ありがとうございました。

一番伝えたかったこと

当初、テーマを何にするか悩みましたが、自分が運用保守周りで苦労してることもあって、世の中全体を見ても新規で作られたものよりも、息の長い、そして色んな人の意図が複雑に絡み合って構成されているものの方が圧倒的に数が多いですし、それに関わっている人の数もきっと多いだろう、だからこそそこで工夫したことは共有する価値もあるかなぁと思い、今回のテーマにしました。

話の内容そのものは、今の時勢においては正直当たり前の話でもあります。Rails や Play Framework などには仕組みとして DB マイグレーションは内包されていますし、その仕組みに乗っかればそのまま実現できますし、そうやって普通に回せているプロジェクトもたくさんあるでしょう。なので、「え、それくらいもう当たり前だし、今さら取り立てて言うことか？」という見方もあるだろうと思います。

それでも、自分の身の回りを見てもそうですし、まだまだその「普通」がちゃんとできていない現場やプロジェクトもたくさんあるはずです。私個人の思いとしては、そんな「普通」ができていない現場を1つでも減らせたら、少しでも楽になる人が出てくれればいいな、そういう思いでお話させていただきました。

今回お話した方法そのままじゃなくても、開発プロセスについて見直すキッカケになったとしたら、私としてもこれ以上嬉しいことはありません。

jOOQ について

正直、日本での知名度はお世辞にも高いとはいえないですが、海外では結構使われている印象です。*1現在利用している私自身の感覚としても非常に運用時に「ありがたい」なぁと感じる DB ライブラリです。セッション中にも触れましたが、決して生産性を高める類のものではありません。他のライブラリと比べると、どちらかというと面倒と思うことの方が多いかもしれないです。ある程度自動生成できるとはいえ、クエリは自分で書く必要があるし、DB アクセスのコードなんてある程度パターンが決まっているので退屈だなぁと思うことは自分でも多々あります。

それでも、運用フェーズに入ってきて確実に「助かったなぁ」とか「良かった」と感じることがあるのもまた事実です。リファクタリングをしてる時などは特にそう思います。GitHub の README や公式サイトの作者の方の考え方などを読んでも、その辺りを重視してるんだなぁと感じますし、マニュアルドキュメントの充実っぷりは素晴らしいので、ぜひ使ってみてその実感をしてほしいなぁと思っています。@irof さんのコメントが嬉しかったので、引用させてくださいｗ

「jOOQ使って楽かというとそんなことないです！どちらかというとめんどくさいです！」素晴らしい。 #ccc_ab1

— いろふ (@irof) 2015, 11月 28

とはいえ、情報源、特に日本語の情報がまだまだ少ないので、微力ながら自分も発信していきたいなぁと思っています。さしあたって、ドキュメントの翻訳を少しずつしていますので、ある程度形になってきたら公開したいと思っています。（実態は追い込みという名の強制メソッドｗ）

他参加したセッション

基調講演1 : Java は守りに入らない、これが今の Java だ

@cero_t さんのすべり芸を拝見しに Java One に参加された感想を基にした今後の Java の展望と、セッションの紹介は繋がりがわかりやすくて良かったです。でも後の方に経るに連れてだんだん雑になってきてたのは気のせいでしょうかｗ

今こそッ、始めようGrailsブートキャンプ!!!! に行ってきた #jggug

yusuiked@gmail.com (yusuiked) — Sat, 24 Oct 2015 23:39:50 +0900

いつもの NTTソフトウェアさんで。

jggug.doorkeeper.jp

Grails も3系になり、Spring Boot をベースに生まれ変わったということで以前ちょこっとだけ触ってみたことがありましたが、再度自分の理解を確かめる意味で参加してきました。

内容

Grails 3.0.9 を使って簡単な Todo アプリを作るハンズオンでした。@yamkazu さんの資料が素晴らしすぎて、これを読みながら手を動かしていくことでざっと Grails 3 での開発の流れを実体験できる仕上がりになっています。これ Grails 3 の日本語の入門資料として今のところ最適なんじゃないでしょうか。

github.com

成果物

私もこれに沿って Todo アプリを作ってみました。カンタン。

github.com

感想とかメモ

ドメインクラスを指定するだけで基本的な CRUD のメソッド（save, delete, list, get）が勝手に生えてる

class Todo {
    String content
    
    static constraints = {
        content blank: false, maxSize: 20
    }
}

def todo = new Todo(content: 'hogehoge')
todo.save() // Create

def todos = Todo.list() // Multi read
def todo = Todo.get(1) // Read
todo.content = 'updated.'
todo.save() // Update
todo.delete() // Delete

環境ごとに設定を変える仕組みが最初から備わっている

environments に development, test, production と環境ごとに設定ができる

// BootStrap.groovy で起動時の処理を記述できる
class BootStrap {
    def init = { servletContext ->
        environments {
            development {
                // run-app で立ち上げた時のモード
            }
            test {
                // test-app でテスト実行した時のモード
            }
            production {
                // war, jar で動かしている時のモード
            }
        }
    }
}

コントローラについて

Controller と Action メソッドが URL に対応している

Spring in Summer ~ 夏なのにSpring で発表してきました #jsug_sis

yusuiked@gmail.com (yusuiked) — Mon, 31 Aug 2015 18:00:00 +0900

こういう大きいイベントでセッション発表するのは初めてだったのでかなり緊張しましたが、無事発表を終えることができました。やればできるもんですねｗ*1

Report to Spring Developer from CyberAgent from Yusuke Ikeda

www.slideshare.net

時間が多少オーバーしてしまい、質疑応答の時間が取れなかったのは申し訳なかったです。ただセッション終了後には数人の方に質問しにきていただいたりもして、多少なりとも興味持って聞いていただけたのかなぁと勝手ながら思っています。

発表の機会を下さった @making さんはじめ、 JSUG スタッフの方々、その他関係者の方々、本当にありがとうございました。

補遺

私と同僚の山田の2人でのセッションで、前半が私のレガシーシステムへの導入事例、後半が山田の Spring Boot を使った運用 Tips といった構成でした。最初は私も技術的なことを掘り下げたセッションにしようかとも思っていたのですが、メリハリがないと聞く側も疲れてしまうだろうという気持ちもあってこのような構成にしました。結果的にはバランスが取れて良かったかなと思っています。

私のパートはセッション中にも何度か言いましたが、BtoC でよく話題に上がるような以下の様な問題

高トラフィック
低レイテンシ
大量データ

はあつかわず、どちらかというとどこにでもありそうな話題をテーマにしました。目新しい話題を期待されていた方には申し訳なかったです。

Spring のカンファレンスで私たちのような事業者が冠に付いたセッションに対して期待されるのは、どちらかというと上記のようなテーマではないかと思ったりもしました。ただ、私自身が Spring に絡めた話でその文脈を語れるほど経験がなかったことと、私が Spring（特に Boot）に対して魅力に感じていたのは、今回のセッションで話したような生産性の高さと柔軟性、そして簡単さだった*2ので、そこをお話したかったということが大きいです。

そういう意味でも、もし導入を検討されている方や悩まれている方がいるなら、背中を押してあげたい気持ちですｗ*3

質問されたこと

犠牲的アーキテクチャの話で、今あるものを捨ててしまうのが価値、とは？

この辺りの話はちょっと前提をすっ飛ばしすぎて、普段 Web 上の議論を追っていない方にとってはなんのこっちゃという話でした。すみません。

大元は、マーティン・ファウラーが書いたこのエントリが発端の話です。（日本語訳はこちら）

端的に言うと、今作っているものも数年後には捨てざるを得ないくらい、世の中が変わったり技術が進んだりして、要件が実態と合わなくなることがあるかもしれない。ビジネスが成長して、システムのスケーラビリティが追いつかないこともあるかもしれない。それならば、作る時に最初から捨てることを意識してアーキテクチャを選ぼう、という考え方です。ただし、捨てるからといって、それまで作ってきたものに価値はない、ということではなく、

比較的短時間で捨ててしまうソフトウェアだって多くの価値を生み出しうると認めること

ともある通り、それはそれで開発チームが得てきた問題領域に対する経験や知識が無駄になるわけではないし、また品質を置いてけぼりにしていいわけではなく、極力モジュール性を高めておくことで新しいアーキテクチャにも交換できるようにしておくことが重要だとも言っています。この辺は、今流行りの Microservices Architecture にも通じる話かなと。

兎にも角にも、これをそもそもやるべきかどうか、いつやるべきか、というのに答えがあるわけでもなく、

多くの場合、これは技術というより事業の決断なのだ。

ということなんだと思います。

この話題に関しては、犠牲的アーキテクチャという言葉ともに、神宮式年遷宮に絡めて語られたり、式年遷宮アーキテクチャなどと言われて一時議論されていました。以下に、Web 上の有用な議論のリンクを示しておきますので、興味ある方はどうぞ。特に、Rebuild.fm の Aftershow 67 を聞いてみるといいと思います。

その他参考になるリンク

チーム状況として1人と言っていたが、障害時のオペレーションはどうしているのか？

基本的に自分が対処できる状況にあればするが、休みやいない場合はもちろんローテーションするようにしている
一次対応は他メンバーでもできるようになっている
手順は Wiki にまとめるなど、明確化している

開発が1人だったということだが、インフラのキッティングやらネットワークやらまで1人でやったのか？

インフラはオンプレミスの仮想環境に乗る形なので、アプリケーションエンジニアは基本的にはミドルウェアまで見られればとりあえず回る

蛇足

1人でやってることに関して、「私も1人でやってるんで、どういう風に上手くやってるのか教えて欲しいですー」みたいな話をちらほら聞きました。意外と世の中ソロプレイを強いられている方々多いのでは…？ｗ

渋谷 JVM に行ってきた #渋谷JVM

yusuiked@gmail.com (yusuiked) — Sun, 19 Apr 2015 23:25:02 +0900

d-cube.connpass.com

JVM そのものではなく、JVM の上で動く言語についての会でした。申し込み人数が100人超えしていたけど、最終的には90人くらいに落ち着いてた。

連休に入るとサーバが故障するとか、ヘソ曲げてるとしか思えない

— Yusuke Ikeda (@yukung) 2015, 4月 18

出かける直前にサーバのアラートが来ちゃって*1、なんだかんだバタバタしてしまい10分くらい遅れて到着したけど、セッション自体はまだ始まってなかったのでセーフ。

まとめはこの辺

togetter.com

とか、

とか。shigemk2 さんの記事は素晴らしくまとまっているので、詳細な内容はそちらでどうぞ。 

Scala セッション（@takezoen さん）

竹添さんの言語遍歴と Scala に出会ってからのお話。Java 以外にも Lisp、Haskell、Clojure といろいろ変遷があって、人に歴史ありだなーと勝手に思ってました。会社入って早い段階でポール・グレアムの本を読んでいたとか、当時の自分は存在も知らなかったしすごいなーと思いつつ。2011年〜2012年辺りの Java の停滞感と、当時の Scala の Java にはなかった熱気が、竹添さんを Scala に誘ったといった辺りも、なるほどなぁと思いながら聞いてました。途中、Java の停滞期の話をしている途中で竹添さんの PC から Java アップデートのお知らせが来てスライドが中断するという奇跡が起こって会場が盛り上がってたｗ

たけぞえさんへの Java からの悲痛な叫びｗｗ #渋谷JVM

— Yusuke Ikeda (@yukung) 2015, 4月 18

JJUG CCC 2015 Spring に行ってきた #jjug_ccc

yusuiked@gmail.com (yusuiked) — Wed, 15 Apr 2015 08:00:00 +0900

少し時間が経ってしまいましたが。

前回までの会場とは違い、西新宿駅から近くなったのでより行きやすくなってた。この辺りは以前通っていた職場にも近くて、歩いて通ったことも何度もあったので、懐かしさを感じつつ会場入り。もうやんカレー昔よく行きました。

タイムテーブルはこちら。

参加したセッション

感想とか思ったこととか

参加レポートは他の方にお任せして、個人的に感じたことや思ったことなどを。セッション資料も JJUG のサイトにリンクされてますし、以下のブログでも素晴らしくまとまっているのでそちらをどうぞ。

JJUG CCC 2015 Spring ( #jjug_ccc ) - セッション資料の一覧 - 地平線に行く - 地平線に行く

基調講演1 Java 20年史

JJUG 副会長の河村さんによる Java 昔話。なんだか大学の講義を聞いているようで懐かしさを覚えつつ、前半は聞いたことが無い単語や技術要素もあったりして逆に新鮮だったのと、全体を通して Java がどう変化してきたのかを俯瞰で見ることができていい機会だった。

私は Java 触り始めたのが大学3年の頃なので 2003 年くらい。ちょうど Struts が出始めの頃で、卒業論文で分散オブジェクト技術について書いてたので、 RMI/IIOP とか EJB とかについて調べていた記憶が話を聞いていて蘇った。それから新人研修がちょうど Java5 が出たての頃で、研修の補助図書として Java5 の本を渡された記憶とかも。懐かしい。

全体として、Java はインターネットの普及とともに進化してきたのだと改めて感じた。ブラウザの覇権の歴史とか、JavaScript の復興とか、これまでのインターネットの歴史について振り返るような授業が大学にあるとすれば、必ず出てきそうな話だと思うし、それとともに Applet やら Servlet やら EJB やらが出てきて何が問題だったのか、みたいなことが教科書に乗ってると思う。そういう意味で、むしろ最近入社した新卒〜3年目くらいの人に聞いて欲しいと思った。その時どんな問題があってそういった技術が出てきて、その技術がどんな課題があって消えていったのか、といったことは、技術がどんなに進歩しても普遍的な話だと思うし。

Jenkins ユーザ・カンファレンス 2015 東京に行ってきた #jenkinsja #juc2015

yusuiked@gmail.com (yusuiked) — Sun, 11 Jan 2015 22:10:28 +0900

» Jenkins ユーザ・カンファレンス 2015 東京日本Jenkinsユーザ会

2015年最初の課外活動は Jenkins 。connpass のリマインドメールに 13 時開始とあったので、13 時めがけて向かったら川口さんの基調講演は 12 時半からだったみたい。現地に着いてから気づいたんだけど、他にもそういう人多かったみたいで、少し開始時間を遅らせていたよう。おかげで基調講演も半分くらいは聞くことができた。

カンファレンスの最後にもお詫びをしていたし、こういう大規模なイベントだとなかなか運営も大変だと思いますね。運営の方々、お疲れ様でした。

全体の感想とか雰囲気とか

数年前に参加した Jenkins カンファレンスだと、まだ導入しているところの方が少なくて、どうしたら導入できますかみたいな話が中心だったと思う。けど今日参加してみて、既にそういうフェーズは過ぎて、みんな現場で Jenkins 使って CI はしているけど、より効果的なユースケースや現場での工夫を聞いてみたい、躓いたことなどを他の現場はどういう風に解決しているのか、そういったことを聞きに来てる人が多かったように思う。各セッションの質問でも、質問者が実際にどう運用しているのかのイメージがあった上で実際にどうしているのか、みたいな質問が多かった気がする。

それは、Jenkins 単体の話ではなく、Chef や Docker などといった他のツールと Jenkins を組み合わせて問題を解決している、といったセッションが多かったことからも特に感じた。あと、インフラ構築やオーケストレーション、プロビジョニングといったインフラの分野でも Jenkins を中心として、サーバ構築のツールチェインとして使われているのが面白かった。Infrastructure as a Code が、今はもう実際の現場で工夫して当たり前のように構築されているし、Jenkins がその一端を担っているということを実感できたカンファレンスだった。

「Jenkinsがシステムの中心になりつつある」 #jenkinsja

— Kohsuke Kawaguchi (@kohsukekawa) 2015, 1月 11

参加したセッション

» Jenkins ユーザ・カンファレンス 2015 東京 – セッション/LT 日本Jenkinsユーザ会

Jenkinsプロジェクトの現状とワークフロー
はてなにおける継続的デプロイメントの現状と Docker の導入
クックパッドにおけるJenkinsの活用
「Infrastructure as a CodeにおけるJenkinsの役割」〜環境構築も継続的インテグレーションを行う時代です〜
LT大会

以下、それぞれのセッションで気になったこと、いいなと思ったことやメモなど。

Jenkinsプロジェクトの現状とワークフロー

途中からの聴講だったので、興味深かったところを。

Jenkins Workflow Plugin

第九回 #渋谷java で LT してきた

yusuiked@gmail.com (yusuiked) — Sat, 13 Dec 2014 21:37:27 +0900

前回に引き続き参加させていただいて、今回は喋ってきました。

jooq-to-send-to-sql-faction from Yusuke Ikeda

今回は割と早めに LT 登録させてもらっていたのですが、それから怒涛のように仕事が忙しくなってスライド作る時間が作れず、当日なんとか間に合わせた感じ。デモで使ったサンプルは結構前に検証も兼ねて書いたものを使いまわしてなんとか事なきを得ました。

デモプロジェクトはこちら。

yukung/jooq-sample · GitHub

次回はもっと余裕を持って行動したい（小並感）

感想

LT 内で Java の O/R マッパーのお勧め聞いたらやっぱり Doma って返ってきました。

今回はマサカリもバンバン飛んでていつもより緊張感あった気がしますｗでも、終わった後その場でソースコードレビューしてたりして、楽しかったです。

あと、@making さんからサインもらいました。Spring Boot 使い始めの時はとてもお世話になりました。ありがとうございました。

-—-

本が出るまで待てない!? Gradleハンズオン - G*ワークショップZ Oct 2014 に行ってきた #jggug

yusuiked@gmail.com (yusuiked) — Sun, 26 Oct 2014 22:48:31 +0900

最近ずっと使ってます。Gradle。

今仕事でやってるプロジェクトも Gradle を使っているので、なんという俺得なタイミング、ということで行ってきました。

Gradle 本出版記念ということで、参加者だけのありがたい特典もありました。行ってよかったデス。

コンテンツ

@nobusue さんの Gradle イントロダクションと 2.0,2.1 の主な変更点
- Gws 20141024 gradle_intro from Nobuhiro Sue
@literalice さんの Gradle プラグインハンズオン

LT

@kyon_mm さんの Gradle 2.2, 2.3 の変更点おさらい
@nobeans さんの OSS 開発の嗜み話
- すいません、資料見つけられませんでした

以下、学び

plugins ブロックとプラグインポータル

Gradle2.1 で追加された
3rd party のプラグインを使うときにより簡単になった

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath "com.bmuschko:gradle-tomcat-plugin:2.0"
    }
}
apply plugin: "com.bmuschko.tomcat"

〜2.0までこう書いていたのが、

plugins {
    id "com.bmuschko.tomcat" version "2.0"
}

これで良くなった。ただしプラグインポータルに登録されていることが前提。

インクリメンタルコンパイル

Gradle 2.1 で追加された
変更のあった Java ソースのみ再コンパイルする

第八回 #渋谷java に行ってきた

yusuiked@gmail.com (yusuiked) — Sun, 21 Sep 2014 21:53:18 +0900

http://shibuya-java.connpass.com/event/8212/

前回の参加が第4回だったので、大分お久しぶりです、という感じでした。相変わらずオサレな会場に加え、なんとオフィス内にビーチまで出来ていました。オサレ感がレベルアップしている…!!

オフィス内ビーチ！ #渋谷java pic.twitter.com/KFxZyJkFRJ

— Yusuke Ikeda (@yukung) 2014, 9月 20

資料とTogetter

感想

以下、それぞれのセッションの個人的な感想をば。思ったままに書くので読みづらいかもしれません。

QueryDSLとSpring DataでとりあえずCRUD @nabedge さん

Qyerydsl という SQL っぽい DSL でタイプセーフにRDBアクセスするフレームワークの紹介でした。資料はなく、サンプルコードを交えたコードの解説。詳しくは @nabedge さんの GitHub を見ていただければ。

Querydsl
- http://querydsl.com/
サンプルコード
- https://github.com/nabedge/querydsl-sample

リポジトリを見てもらえればわかりますが、中身は DDL + 初期データのSQL と、Spring Framework と連携する Java configuration のコードだけです。DBアクセスするためのコードは Querydsl が SQL を元に自動生成するため Maven で install 実行すると生成されます。*1

実際の使い方はテストコードを見れば大体わかります。基本的には、テーブルにアクセスするための自動生成されたオブジェクトと、クエリを文字列ではなく DSL としてメソッド呼び出しで表現*2して、タイプセーフにクエリが発行できる、という感じのものでした。更新系のクエリはコールバックを更新用のメソッドに渡すようなスタイルなため、Java8 のラムダ式で書くとシンプルに書けます。@nabedge さんもこれを調べて初めてラムダ式を書いたと言っていましたｗ

見た感じ、S2JDBC に非常に似ている印象を受けました。公式サイトを見る限り、サブクエリや検索結果オブジェクトへの射影なども表現できるようで、簡単なクエリをバシバシ投げながらコードを書く際は気持ちが良さそうだなぁと感じました。

また、私がちょうど今お守りをしている Java のプロジェクトは O/R マッパーとして MyBatis を使っていますが、アノテーションに SQL を書きまくっていて、文字列ということもあるし、気軽に SQL をペタペタ貼り付けて実行、とかをやりづらく、実際に動かしたら SQL エラー、とかになって非常につらたん(´・ω・｀)、という状況だったので、IDE の補完を駆使してタイプセーフにクエリを発行できるところに魅力を感じました。ちょっと興味が湧いたので触ってみようかと思います。

Tellurium を試してみた

yusuiked@gmail.com (yusuiked) — Tue, 27 Dec 2011 03:02:21 +0900

もう25日は過ぎてしまいましたが、自重せずに G* Advent Calendar 2011 : ATND 27日目の記事行かせていただきたいと思います。
初めまして、id:yukung/@yukung と申します。Groovistな皆様、お手柔らかにお願いいたします。

最近、ノンブロッキングI/Oな仕事をしているので、当初Grettyについて書こうかなーと思っておりました。そうしたら見事に @toby55kij さんとネタがかぶってしまったので（Grettyで割り勘計算機 #gadvent2011 - Toby55@新潟の日常）、慌ててここを漁って違うネタを探して若干焦りました＞＜
Groovy - Modules の中で、Telluriumがちょっと面白そうだなーと思ったのと、ググッてもあまり日本語の情報がなかったので*1、書いてみようと思います。というわけで、急造な記事なのでちょっと浅いかもしれませんが、ご容赦ください。

Tellurium って？

Tellurium は、GroovyとJavaで実装されたWebアプリケーション向けのテスティングフレームワークです。この分野には、Webブラウザの操作をエミュレートしてWebアプリケーションの自動テストを可能にしてくれるSeleniumという有名なツールがありますが、TelluriumはそのSeleniumを基盤にして構築されています。というか私が触ってみた感想は、平たく言ってSeleniumをDSLで書けるようにしたGroovy/Javaラッパーな感じです。

Selenium との違い

公式サイトによれば、TelluriumはSeleniumとの違いを、テストコンセプトの違いと定義しています。また、Seleniumを「C言語」のようなものであるとすれば、Telluriumは「C++」のようなものだ、とも言っています。なんだかわかったようなわからないような感じですね。

UI要素の扱い

Telluriumでは、UI要素の記述を「UI module」として扱えることをSeleniumに対するアドバンテージとして捉えているようです。
RIAやAjaxなど*2、リッチなWebアプリケーションが一般的になってきた昨今、Webのインテグレーションテストも重量級になってきがちなところに対する一つの答えとなるのがTelluriumのゴールのようです。

主なメリットとしては、

JavaScript Eventをトリガーにした動作
Ajaxアプリケーションのサポート
変更に対する堅牢性と柔軟性
メンテナンスの容易さ
UI module の再利用性
表現力（DSLで書けるなど）

といった所が挙げられています。

私はSeleniumを仕事では使っていませんし、使いたいなーと思って入るものの今のところヘビーユーザーでもないので、相違点について細かいところはあまりわからないのですが、例えばSeleniumでボタンクリックするような挙動を記述したいときは、

   selenium.click("//div[3]/input[@value='Create']");

こんな風に書くと思いますが、TelluriumではGroovyを使って、

    ui.Form(uid: "Form", clocator: [tag: "form"]){
        Div(uid: "User", clocator: [:]){
            Selector(uid: "Sex", clocator: [:])
            InputBox(uid: "Input", clocator: [tag: "input", type: "text", name: "j_username"])
        }
        Container(uid: "Finish", clocator: [tag: "tr"]){
            SubmitButton(uid: "Submit", clocator: [tag: "input", type: "submit", value: "Login", name: "submit"])
        }
    }

こんな風に、UI要素だけを分離して書くことで、テスト箇所のUI要素と、実際のテストコードを分離することができます。また、UI要素を階層構造で記述するので、モジュールとしての再利用性も期待できます。
UI要素など、変更が頻繁にかかる箇所はGroovyのDSLでライトに書いてカプセル化し、テストコードは使い慣れたJUnitやTestNGなどで書くことによって、UIの変更に大きな影響を受けず、かつUI要素をモジュール化して再利用できる、ということが主なメリットのようです。

分散バージョン管理勉強会に行ってきた

yusuiked@gmail.com (yusuiked) — Sun, 19 Dec 2010 16:01:31 +0900

最近，Gitを勉強しようと思っていたらタイミングよく勉強会があったので参加させていただきました。

DVCSについて，外観からディープな話題，ネタ発表までバラエティ豊かな発表でとても楽しかったです。特に，神速さんのゆるふわ愛されキャラ振りはすごいw
以下，各発表のメモ＆感想です。

分散バージョン管理システムってなんなん？（おかもとさん）

前説ということで，場を暖めるために様々なネタがちりばめられていましたが，会場の照明が思ったよりも明るく，スライドが見えにくくなってしまったためあまりオチなかったところが逆に面白かったw
CVS→現在までのバージョン管理ツールの変遷
- 書籍とかである程度事前知識を入れてはいたけど，改めて聞いておさらいができた
分散バージョン管理のメリットはよく聞くけど，デメリットはあまり知らなかったので勉強になった
- 特に，ロックができないというのは*1，バイナリファイルの扱いが難しいということで，Excelなどのファイルを管理するのは難しいのかな？
  - 調べたら，MercurialはTortoiseHgを使えば差分が取れるらしいので，Windowsユーザにも優しいようだ
  - この点は，現場導入するにあたってMercurialかBazaarに揺れる一つの要因になりそう。あとGitのコマンドを現場のメンバに覚えさせるのは難しい気もするし。
Git,Mercurial,Bazaarの比較
- 比較表はもうちょっとじっくり見たかった
  - スライド公開された分散バージョン管理システムって何なん 20101218
- リビジョン表示は，Gitの場合ハッシュだけど，revertする時はコミットログが頼りになるのかな？そうするとメンバーにしっかりコミットログを書かせるようにしないと厳しそう
まとめ
- デメリットも考慮して，Subversionから移行しないというのも一つの選択肢，というのは肝に銘じておこうと思った

GitとHudsonによるきれいなリポジトリの作り方（id:bleis-tiftさん）

テライケメン

前半部（ソフトウェア開発に対する思い）

ソフトウェア開発で発生する問題としての手動テスト，Excel管理，Excel設計
- まずこれらを卒業するのが先決ですよね。汎用機文化の人たちにこれをわからせるためにはどうしたら良いんだろう…*2
バージョン管理システムを使っているだけではダメで，正しく使わないとダメ
集中管理型は使っているみんなが変更を知っていないとダメ
- 使っているみんなに間違った影響が伝播してしまうから
- そもそもバージョン管理ツールの仕組みから知ってもらわないとこういうことってわからないんですよね…どうやって時間を取ってもらうか。彼らはこういう勉強などいっさいしないし…

後半部（きれいなリポジトリ）

分散バージョン管理初心者の私には結構高度なテーマでしたが，説明がわかりやすかったので聞いていて何となく理解はできました。ただ，自分でこの環境を構築しようとするのは今のレベルでは難しいかも。

ここではいつ取ってきてもビルド可能なリポジトリのことをきれいなリポジトリとして定義
- 自分がミスっても他の人に影響を与えることがない
CIを導入することで，リポジトリが更新されたきっかけでビルドを走らせることによって素早いフィードバックを得ることができる
ただし，フィードバックだけでは不足で，汚してもよい領域ときれいな（ビルドが通る）領域とに分けて管理することで，きれいなリポジトリが実現できる
ブランチ分割
- 更新をかける開発者ごとのブランチと，実際に更新されるブランチに分ける
リポジトリ分割
- きれいなリポジトリと，開発者が壊しても良いリポジトリに分ける
hookでmasterブランチを直接pushできないようにし，privateブランチの更新をhookしてビルドする
利点・欠点
- 開発者が増えたとき
  - ブランチ分割の場合，CIのジョブを増やすだけ
  - リポジトリ分割の場合，リポジトリも増やして設定する必要がある
- 最新ではないもののpush
  - ブランチ分割の場合，ロールバック？通知だけ？
  - リポジトリ分割の場合，ロールバックするだけ
- リポジトリ分割の場合，hookを差し込む場所が多くなる
- テストの分割
  - privateリポジトリで単体テスト
  - centralリポジトリにpushされたタイミングでhookして結合テスト
  - このアイデアは言われてみれば合理的だけど，すごいと思う。というか実現したのがすごい
最初に試すのはブランチ分割がおすすめ
- hudsonのgitプラグインのオプションにあるらしい

TracLightningとTortoiseHgのゆるふわな連携(id:wyukawaさん）

ゆかわさんの発表はHudson勉強会に続いて２回目の聴講でした。

Mercurialの特徴
- コマンドがSubversionに似ている
- 単機能（Gitは多機能）
- 拡張機能が豊富
  - リベース，歴史改変，チェリーピック，部分コミット，シェルフなど
  - うーむ，勉強不足なのでよくわかってません。勉強します。
- Mercurial Queue(MQ)というGitのインデックスに似たパッチ管理機能

BPStudy #31 に行ってきた

yusuiked@gmail.com (yusuiked) — Sat, 27 Mar 2010 14:15:38 +0900

最近全然勉強会に行けてなかったんですが、なんとか仕事の都合をつけて参加してきました。
テーマは、継続的インテグレーションツール「Hudson」ということで、Hudsonコミッタのid:cactusmanさん。
個人的には、最近はチーム管理の仕事がメインになってきてて、HudsonやMaven、Trac／Redmineなどのツールを使ったプロジェクト運営の領域に興味がわいてきたこともあって、今回参加させていただきました。
内容のログや、Twitterのまとめは以下でまとめてくれているので、そちらを参照推奨です。id:kashisanさん、id:ikikkoさん++

ログ
- BPStudy#31に参加しました - かたるほどでもない技術系ブログ
Twitterまとめ
- BPStudy#31 - Togetter

上記で内容はバッチリだと思うので、僕個人が期待していたこと／聞きたかったこと、話を聞いてみて思ったこと・感想などを書こうと思います。

聞きたかったこと、期待してたこと

懇親会でもid:cactusmanさんが気にされていましたがw
僕個人の立ち位置としては、Hudsonがどんなツールでどういうことを実現してくれるのか、という概念的なところの前提知識はあるレベルでの参加でした。ただ、僕は「CIって何それ？おいしいの？」というチームメンバーが多数派の悪名高き10年泥系SIerの環境に身を置いていますので、まずは導入にあたってチームメンバーへの啓蒙をどう行ったらよいのか、どの部分をメリットとして訴えればいいのか、といったところが聞きたかったところになります。
そういう意味では、CIとは何か、といった所からお話ししていただけたのはとてもありがたかったと思いました。メンバーに説明をするのに、やってること自体は今まで何ら変わらないんだよ、ただそれを楽しようとしてるだけなんだよ、ということをわかってもらえばいいのだという考えに自信を持つことができましたし。
SIerの特に客先常駐部隊に属していると、とにかく「変化」に対してものすごい抵抗に遭います。RedmineやPukiwikiなどを導入しようとしたこともありますが、今までやってきたやり方でうまくいっているのに、どうしてわざわざ新しいことをやらなければいけないんだ、覚えるのがめんどくさい、使い方がわからない、それで何がよくなるのかよくわからない、などなど。
そういう抵抗を打ち破るには、「変化」ではないことを強調するのが一つの手かなぁと思った今日この頃です。

ただ、道は長い…

そして、話の中にあった「メリットがあるのになぜ広まらないか」を聞いて、自分の環境への導入は千里の道だなぁという感想をもちましたw
その主な理由は、所謂SIer的な文化に拠るところが大きいのですが、いくつか挙げてみると

テスト必須
- テストコードが1Byteもない
- というかJUnit含む単体テストツール使ってない
- テストコードを書けるようにスキルを啓蒙する必要がある
- テストコードのメンテをキープできるか
開発途中での導入が難しい
- 保守メイン
- 新規プロジェクトもないこともないけど…
ビルドが通らない
- ビルドどころかAntやMaven使ってなくてEclipseでwar/earを作ってるだけだ
- もじビルドが通らなかったら、ログやらなんやらで自己解決できるスキルがあるメンバーがいない
上司などに理解されない
- 技術に理解がない上司なので、数字で訴えないとダメぽ
  - 今までテスト〜パッケージングまでかかってた工数がx人日/Prjで、ツール使うとx人日/Prj削減できます、だから年換算でx人月のコスト削減です、とか
- まぁここは最悪自分のローカルかなんかにたててコソーリやればいいのかもしれないけど
  - でもコッソリやって生産性向上したりしても、なんも評価されないのよね
- バグ早期発見、デグレード防止などのメリットも問題が顕在化する前につぶしてしまうと上司からは見えなくなるので品質向上しているということがわからない
  - はいはいカバレッジカバレッジ、はいはいバグ発見数発見数

などなど、ネガティブな点ばかりが上がってしまって、結局個人レベルで行える部分には限界があって、草の根でもなんでもまわりをうまく巻き込んでいけるような雰囲気作りから始めないといけないなーと思ったのが正直な感想です。

とりあえず

ローカルにHudson入れてみろ、話はそれからだ
ということで1歩ずつですかね。

懇親会、その他感想

COBOLの生産性について盛り上がったw
DLLヘル、XMLヘル、アノテーションヘルw
Python,Djangoサイコー
パッケージ、サービスをどうビジネスとして行っていくのかなど、受託開発だけの自分にはとても貴重なお話を聞けた
こういう話、職場の人とは一回もしたことないなー。懇親会こそ本番ですね。

感謝

主催の@haru860さん、今回MCのid:cactusmanさん、懇親会でお話しした皆様、貴重な機会をありがとうございました！

-—-

これは同意せざるを得ない

yusuiked@gmail.com (yusuiked) — Sun, 31 May 2009 15:16:39 +0900

エンジニアの未来サミットに行ってきた - 研究日誌
途中の会場アンケートで、SIerに勤めてる人ってのは激少だった。SEってのだってこういうコミュニティとは技術という面で強固につながっててもおかしくないはずなのに、実感としても、全然つながってるようには見えない。一応俺もそのSIerの中の人なんだけど、やっぱ技術としても方向性が違うのは感じる。会社には、行っても楽しめそうな人は・・・どうやら居ない。

平たく言うと、一人でいきましたよと。

基本大勢の関心事は結局、顧客に売り込みやすいBuzz Wordsと要件定義、設計なんだろう。それこそセッション中にもあったけど、これは無くならないだろうし絶対に今後も必要なことだろうが、俺はもういいやーと思ってる所があるし、やりたい人がやってよと。
まあこの業界、プログラミング一切できないSEってのも居るんだからやっぱりなんか違う。そんなこんなの思いもあって会社倒産に合わせてSI業界を辞めるわけですが。てか最初からSIやりたかったわけじゃないし・・・。技術主眼で就活すると、微妙に違っててもある程度は大丈夫なもんだね！

狂おしいほど同意。
自分もコミュニティや勉強会に行くけど、会社にはそういったものがあることすら知らない人ばかりで、知ったとしても「何それ？おいしいの？」という人ばかりです。
実際に何度か一緒に行こうと声をかけたことがあるけれど、「勉強会？なんで休みにそんなの行ってるの？お前変わった奴だなー」と言われ一蹴。
つくづく彼らはエンジニアではなく、サラリーマンなんだと感じたことがあります。

そんな環境に長い時間身を置くこともない。早いとこ抜け出さなきゃ。

-—-

エンジニアの未来サミットをUstreamで見た

yusuiked@gmail.com (yusuiked) — Sat, 23 May 2009 00:20:49 +0900

去年は参加したこのイベント、今年は参加は見送りました。開催概要を読んで、自分の置かれている状況とイベントのテーマにだいぶギャップを感じたので。
が、当日になったらやっぱり気になってしまったので素直にUstreamで視聴することに。といっても第2部だけなんですが。

第二部：弾 vs. 個性派エンジニア ─サバイバル討論

「新20％ルール」を掲げ，不況下のIT業界でのサバイバル術を説く小飼弾氏の元に，第一線で活躍するエンジニアたちが論戦を挑みます。激論の中に現代を生き抜くヒントは見いだせるのか？
パネラー（敬称略）：小飼弾，閑歳孝子，米林正明，山崎徳之，井上恭輔，高井直人，モデレータ：馮富久（技術評論社）

個人的な感想としては、技術や勉強法、自分の価値やそれを周りに主張（伝える）していくことなどが話題の中心で、今回の方が前回よりもエンジニア個人としての生き方や考え方にフォーカスが当たった内容だったかなと思います。なので私はお話を聞いていてだいぶよい刺激を受けました。やっぱり行けばよかったかな。

前回と今回で共通して言えることですが、やはり「自重しない」「アウトプット重要」「横のつながり重要*1」がこれから真のエンジニアとして生きていくには重要だなぁと改めて感じたというか。そして、これらを重要だと思えば思うほど、自分の身の回りの環境とのギャップを感じ、SI業界で生きていくことのしんどさというか、自分はマイノリティなのだ、ということを痛切に感じました。
ホントに居ないもの、自分の周りに。こういうイベント行ったり、勉強会行ったり、仕事じゃないコード書いたり、Blog書いたりする人。

早くゴルフ憶えて協力会社*2の社長とかと知り合いになれ、だとか、出来ないことはさっさと諦めて出来る人に擦りつけろ、とか言う上司はいるけど。
そのこと自体は間違いではないのかもしれないけど、それを技術者に対して言うのは間違ってるよなやっぱり。

私は環境が人を作る、というのは少なからずあると思っていて、そういう意味でこのまま今の環境に身を置くことは、今後自分がエンジニアとして生きていくにあたってプラスになることはもうないと感じています。遅かれ早かれ動き出すことにはなるだろうな。

*1:コミュニティ活動しかり、会社の中、外の繋がり

*2:もちろん下請け

-—-

エンジニアの未来サミット行ってきた

yusuiked@gmail.com (yusuiked) — Sat, 13 Sep 2008 01:18:51 +0900

大手町のビルだったんだけど最初入り口間違えたｗ俺についてきた人涙目ｗ
それはさておき，エンジニアの未来サミット行ってきました．danさん，naoyaさんを見たのは去年12月のTechMeeting以来でした．
エンジニアの未来サミットの開催概要はこんな感じ．

かつては日本の基幹を担うと言われたIT（Infomation Technology）業界。しかし，いつの間にか「3K，5K」「35歳定年説」など，ネガティブなイメージが定着し，さらに最近のイベントで物議を醸した「エンジニア最初の10年のキャリア」についてのさまざまな議論から，IT業界の将来すら不安視されることが増えてきました。
でも，実際のところはどうなのでしょうか？
本サミットでは，これからIT業界を目指す学生，また今IT業界に入ってきた若手エンジニア・デザイナーの皆さんからの疑問や不安に対し，業界をリードする「アルファギーク」の面々，そして今活躍している30代前後のエンジニア，いわゆる7x，8x世代の方々がお応えします。

彼らが語るIT業界の今，さらに実際の仕事への取り組み方やエンジニアの魅力について語る熱いメッセージをぜひお聞きください。

第1部はアルファギークvs学生

学生は一部アレな人も混じっていたけど，総じて自分の考えが言えてた気がする．あれだけ言えてれば問題ないと思う．
Ustで中継してたので，そのままログ残してもしょうがない気もするけど一応．

そもそもIT業界ってどんなことやってるの？

対象ドメイン

基盤系（OSとかコンパイラとかRDBMSとか）
エンタープライズ系（企業の情報システムなど）
ミッションクリティカル系（勘定系，公共基盤系）
Webサービス系（Web2.0?）
組み込み系

ビジネス形態

ソフトウェア製品開発，販売
SI
コンサルティング
運用サービス，サポート
Webサービス（Web2.0?）

担当領域

ひがさん

エンタープライズ系（金融機関向けのシステム構築）
でもOSSやってるよ
それを会社に認めてもらってやってます

よしおかさん

ソフトウェア製品開発・販売
OSとかコンパイラとかRDBMSとか基盤系

naoyaさん

Webサービス系
基本的にクライアントは存在せず，自分たちでサービスを作りこんで世の中に出す．

nipotanさん

Webサービス系
インフラもやってる（データセンタとか）
Webの受託開発も一時期やってた（今は減った．あんまりお金の周りがよくないから）

SIerは未だにそれに気づいてないね．FizzBuzzも組めないような人を大量に投入してなんとか回せばいいんだもんな．改めてみるとほんと詐欺みたいなやり口だな．

danさん

組み込み系以外は全部やった．どれに当てはまるというわけでもないが，しいていえばコンサルティング？*1
クライアントの解決したい問題を実際に手を動かして解決する

「泥のように働く」について

定義とか解釈とか

この辺はあんまり興味がなかったので聞き流してました．
自分の解釈としては，「ソルジャーになってそのあと管理者やれ」

35歳定年説について

ひがさん
- 年齢が上がって単価がペイできなくなるから会社が管理職にさせてしまう
- 35歳定年説なんてどうでもよい
よしおかさん
- 自分の人生なんだから自分で決めていくしかないじゃん
- プログラム書かせてもらえなかったら自分で仕事見つければ良いじゃん
- プログラマやってちゃいけないなんて法律ないんだから，ずーっとプログラマやってればいいじゃん
naoyaさん
- 一人前の仕事ができるようになったのは3年目から．
- 最近管理の仕事が増えてきた．一人でできることには限界があるが，自分の下で優秀な技術者とかを動かしていくと，一人でできなかったことができるようになる．
- 自分は何が好きなのか，何が面白いと感じるかを見つけ出さないと．
nipotanさん
- コード書くのは面白い．
- SIerに居る人から聞いた話で，20代後半なのに早くコード書くの止めて上流のほうやりたいと言っていた．

確かに．これは自分が学生で就職活動やってる時の同級生も言っていたし，同期も同じようなことを言っていた．自分は就職活動やってる当時，何で自分で作らないのに上流上流とかやっぱりコンサルだよなーとかって言ってるんだろう，自分で何か作ってナンボでしょ？って思ってたから，nipotanさんの意見にはとても納得．

- 35歳定年説はコード書きたくない人が作り出した話じゃね？
ここでよしおかさんが，OSSやWebサービスでは自分のコードは自分のモノだが，受託開発の世界では納品したらクライアントのモノで自分の手から離れてしまう．世にも出てこない．やはりモチベーションはぜんぜん違うのでは？
- 受託よりOSSが面白いのは，自分のコードが自分のものにできること．
学生の田村さん
- 欲しいのはプロダクトであり，コードを書くのはただの手段．自分でコード書きたいとは思わない．

これを聞いてdanさんが激しくショックを受けてたｗ　くぁｗせｄｒｆｔｇｙふじこlp＜てな感じ

エンジニアの未来サミット当たってた

yusuiked@gmail.com (yusuiked) — Mon, 08 Sep 2008 23:04:39 +0900

応募してからしばらくはメールチェックしてたのですが，一向に当選メールが来なかったので，今回は外れたと思い込んでいました．
が，今日メールを改めてチェックしてみたら，リマインダメールが届いてました．外れてるのにリマインダなんて送ってくるんだ，と他のメールもチェックしてみたら，当選メール来てましたw
危うく無断欠席するところだった．
LLFutureも楽しかったけど，今の自分の心境としてはこちらに参加したい気持ちが強かったので当選は素直に嬉しかったです．今の会社に居るか，残るか，いずれにしろ自分がエンジニアとして生きていくために，何でもいいから吸収してきたいと思います．

-—-