読者です 読者をやめる 読者になる 読者になる

builderscon tokyo 2016にスタッフとして参加した

ブログを書くまでがbuilderscon!
当日のセッションはとても楽しかったです!
セッションについての感想は参加者にお任せし、スタッフとしてどう思ったかを書きます。

スタッフとして何をしたか

  • スポンサー様にメールを送る
  • ケータリングやごみ処理業者の発注
  • 当日はほぼほぼメインホールにいた

メール送信や、電話することは普段コードしかおらずとてもいい経験になりました。
特にメールは原文作って添削してもらうと、すごい丁寧な文章に書き変わったので感動しました。
圧倒的昭和力*1を目にしました!

なぜスタッフとして参加したか

もともとは会社内イベントの運営に入っており、ノウハウが分からず苦労していたところ
イベントノウハウ集(フレームワーク)としてのbuildersconを発見し、
社外イベントの運営スタッフなりたいと思っていたのと、楽しそうだったので参加しました。
あとはBBQにも行きたかったんです!端的に言うとサイコーでした
lestrrat.ldblog.jp

参加してみて

個々人のやる気とパワーみなぎっていて、すごい楽しく進められました。
また、牧さんの目指している方向性に合うように作業を進めようとして動いていたのですが、
折角参加してるんだから自分のやりたいようにやらないとダメだよ!ただのおっさんだよ!と言われ、
心の中ですごい人という壁と作っていたましたが、同じ人間なんだな!って思えたのがすごいいい収穫だったと思います。
次はもっと自分で企画考えたり、スピーカー側に行けたらいいな!

builderscon 2017 tokyo

なんと来年も開催されることが発表されましたね!
2017.tokyo.builderscon.io

興味ある方は、とりあえずSlackに入るといいですよ!
slack-invite-dot-builderscon-1248.appspot.com

開発を活性化するためのポイントとテストに関する勉強会に参加しました

開発を活性化するためのポイントとテストに関する勉強会
connpass.com
こちらに参加しました。偶然気づいた時は26人いて補欠だったけど、
最終的に15人になって入れました。
とても濃厚な内容だったと思うのですが、何であんまり人来なかっただろう・・・。
以下メモ書きです。

OSS 活動の活発さと評価の関係について

  • Social Codingがもたらしたもの

階層構造(コミッタ様)からフラット構造へ
Social Codingの世界 // Speaker Deck

  • OSSに必要なもの

OSSは公開しただけでは使われない。(意味がないわけではない)。
積極的にissueやPを受け入れる等の継続的な開発・メンテナンスが重要

  • コミュニティを作るために必要なこと

 1. 情報をオープンにすること。身内での決定など行わない。
 2. コントリビューションの手順を明確にする
 3. 企業のサポート(ある程度の規模で続けていくためには必要)
tagomoris.hatenablog.com

  • English

 英語を使え!日本語を使ってしまうと海外の人が逃げる(敷居があがる)。OSSとしては致命的。
 世界で使われることを意図するなら英語を使うべき。

  • GitHubでプロジェクトを見る場合にどこをみるか

 1. Star数(人気あるの?)
 2. 最終コミット日(更新してるの?)
 3. Issues数(対処してるのか?)

  • モジュール公開サイトの場合にどこをみるか

 1. Download数(数が多いほど、質が高い可能性が高い)
 2. 最終リリース日
 3. バージョン番号(0.0.1ならすごい不安)

  • セマンティック バージョニング

The power-assert Leaves From Moratorium | CodeLunch.fm
をきいてね

緊張関係について

t-wada.hatenablog.jp
一時話題となったこちらの話がありました。
OSSとして積極的にSocial Codingを行いどんどん機能をつけていくと、
良いソフトウェア設計が崩れるてしまうのではないか。
いかに活発に活動しつつ、良い設計を保つのかという話題とミスリードしていました。
実際はうまく設計されたソフトウェアは最小限に必要なものを詰め込んだものであり、
変更点があまり必要ない->開発が活発でないように見える->避けるようになる
こうならないように、どうやって両立するかという問題でした。

解決方法

 1. 地味な更新
 動作検証結果をいれるなどドキュメントを更新する
 (例:memcachedは機能は完成しており、細かい更新をしている)
 MITのライセンス年数更新(チョイ技)
 2. ダウンロード数を見せる。
 3. プラグイン機構
 プラグインで拡張できる仕組みを作る
 The Architecture of Open Source Applications
 4. エコシステム
 d.hatena.ne.jp

社会問題

燃え尽き症候群(+1等で心を痛める。同じIssueが何度もあがる)


code of conduct

正しいけど窮屈間
SJW (Social Justice Warrior) がたくさん出現している

OSSプロジェクトの必要要素

 1. みんなに使われる
 2. メンテナーがアクティブでコミュニティも活発
 3. 経済的な支援を受ける基盤がある
 ->近年OSSのメインコミッターは企業に雇われる傾向があり、業務としてOSSに貢献している

質問

  • Q:power-assertの戦略はどう考えているのか(活発なOSSとして積極的に機能を追加していくのか、完成されいるものとして扱うのか)
  • A: やることは決まっているモジュールなので、ズルイけどプラグイン機構を作りたい。機能としてはシンプルで形は完成している。

 権限は、もし自分が死んでしまっても開発が続くようにオーガナイザーに渡している。(バス係数?)
 しかし、創立者がいなくなると寂れてしまい続かない傾向があるのでそこはどうにかしたい。  

組織にテストを書く文化を根付かせる戦略と戦術

戦略編

t-wadaさんは銀の弾丸ではない
テストを書くことがゴールでなくスタートである
現場によって戦略は異なっている
engineer.crowdworks.jp

ストレスが増える⇒テストが減る⇒ストレスが増える・・・

  • ケントベック

自動テストが増える⇒ストレスがる⇒自動テストが増える

  • James Grenning

テストを書く時間がないのではなく、テストを書かないから時間がない
3人とも同じことを言っている!!!

文化を変える

文化の醸成は年単位の事業になる。
動くコードに触れるなに戦う。
触らないといつか死ぬ(自分自身が変わらなくても、周りは変わっていく)

  • はじめ方

 1. 夢を見過ぎない。隣の芝生は青い。急な成長などしない。
 現状を踏まえ、方向性を決める。
 日本人には「まわりはみんなやってますよ」は劇薬。すごい効果的。使いすぎ注意
 みんなやってます - アンサイクロペディア
 2. 人を知る
 人によって価値観が違う。ex.リファクタリングの快感,カバレッジの増加,ビジネスの価値に繋がる等
 人は急な変化を恐れる。後でやろうはやらなくなる。理想と現実の狭間
 リファクタリングのTODOタスクは着手されない->リファクタリングのジレンマ
 サボった結果として、機能追加が遅れるのがリファクタリングされていない企業の傾向
 事前に許可を得るより、後で許してもらうほうが楽(Grace Hopper)
 3. 変化に備える
 仕様のfixなんてない。すべては変化する。
 理解は常に変化する。スキルや技術も進化する。
 大切なのは意識外でやるべきだったことをひろうこと(マーチンファウラーの四象限)

  • テストは品質をあげるのではない。品質がわかるようになる

体重計に乗るだけでは痩せない。結果を踏まえてアクションを行うことで痩せる。
品質を上げるのは設計とプログラミングであり(テストを書いて分かるのは悪いということだけ)
それを支えるのがテストである

戦術編

1. どこからやるか
 いきなり全部やると破綻する。
 小さなこと、一番困っているところに対して実行する。
 (ex ECサイトでの決済や個人情報,新機能,バグの改修)
 バグが起こっているところはバグの発生率が高いので効果的
 静的解析で複雑度を測定してコードの臭いを探る
 リーン開発の現場がお勧め。リスク・手動テストのコスト・自動化コストによって決める。
2. だれとやるか
 仲間を増やしていく。育てるのではなく、育つような環境を作る。
 教えられる人を増やし、改善の芽を増やしていく。
3.こだわりすぎない
 TDDにこだわらない。申し訳なさそうに言われることがおおいが、
 TDDが正しい、えらいというわけではなく、ひとつの手法なだけ。
 「ユニット」テストにこだわらない。
 テストの実行速度・網羅性にこだわらない。
 正常系のテストがあるだけで大幅な改善
4. ここにはこだわろう
 再現・繰り返し可能(Repetable)
 ->テストは何回実行しても人手を使わずに実行できる。
 独立している(Independent)
 ->テストの中に依存関係を作らない。テストを高速でまわす場合は並列を使う。並列で走らせる場合の障害となる。
 レガシーコード改善ガイドを読むべし!
5. 見える化
 割れ窓理論:割れている窓を直すとニューヨークの治安がよくなっていった。
 少しずつでもきれいにしていくことも効果的
 メトリクスをとる。特にテストカバレッジが低いうちは目に見える効果が大きくモチベーションがあがりやすい
 時間変化の傾きを見ることが大事
 静的解析も重要。
 コードレビューのインフラに投資し、プルリクエストという概念を導入し、
 コードを見る文化・見られる文化を形成する->品質・スキルの向上つながる
6.背中を見せる
 サンプル・デモが大切。0からかける人はいない。真似してもらう土台を作る。
 一度自動化のスキルと身に着けると、続く傾向が多い。

感想

t-wadaさんが2時間ほど話していましたが、気づけばあっという間でした。
周辺の資料含めて今一度復習したいです。
企画してくださった日本OSS推進フォーラムさんありがとうございました!

サービスの切り出し

ここ3ヶ月くらいずっと既存のサービスの切り出しを行っています。
モノリシックなサービスの重要な基盤となっている部分(全体の30%くらい)を、
フレームワークを変えて作っています。
sturts2&spring3&hibarnate3 →spring4&hibarnate4

最初は、JavaEEかSpringにするか調査して相談したのですが、JavaEEの過去の印象が強いのと、
既存がSpringなので学習コストがあまりかからないだろうということでSpringになりました。
個人的にはJavaEEを押したので、残念でした。

今回やったこと

  • struts2を捨てて全部Springに
  • svnからgitlab環境を構築して、マージリクエストを可能にした。
  • RESTfulなAPIになるようにURI変更
  • Java7からJava8記法に
  • antからGradleに変更

今後やりたいこと

  • gitフローの構築(現在リリースがまだないので、masterしかない)
  • テストコードを書く
    • 過去のコードを持ってきて、不要な処理を消しているだけなので、消した部分に関連する場所しかテストコードを書いていない。(既存にテストコードはない)
    • 永続層との依存が大きく、モックをたくさん作って、テストとしてBeanに想定通りの格納されていることを確認するものって意味あるのかな?
    • RESTでこのアクセスが来たら、このjsonが返ってくるぐらいのテストでいいものか。
  • ログをNoSQLに格納する
    • 例外発生時のエラー解析で一々コンソールを叩く作業をなくしたい。
    • エラーが発生したリクエストと、レスポンスとその処理を行ったプロセス全体を入れたいが、いい知見はないものか・・・。

困ったこと

Egitの挙動がおかしくて最初すごいはまった。競合しているファイルがあると、同期化ビューで見ると全ファイルが競合する。
最新版のEclipseとEgitでautocrlf=falseにしてもダメだった。情報でなかったけど、みんなどうしてるんだろうか。
対処法としては、同期化ビューを使わない 。(gitコマンドかsoruceTreeで見る)
寧ろEclipseを捨ててIntelliJを使おう!!!qiita.com
Eclipse Community Forums: EGit / JGit » Synchronize view shows non-existent white-space and other outgoing changes

Java Fan Meeting 2014に参加しました

得られた知見

  • JavaのマスコットはDuke
  • SwingやめてJavaFX使おう
  • Struts,tomcatはやめよう。Eclipseは考え直そう
  • SE8で重要なのはラムダ周りではなく考え方。なぜ導入されたかを理解し正しく使おう ■参考
  • Javaが書けるならJSもかける時代が来るかも・・・
  • 情報発信しよう。文章力の向上にもなるし、転職時の自分の技術アピールにもなる。

感想

若者向けイベントで、Oracleの人も多かったような気がするけど、色々な話が聞けて楽しかったです。
疑問に思ったのが、Javaができれば組み込みでもなんでも色々できるよーってお話しです。
Javaができるの定義について質問したかったのですが、時間がありませんでした(´・ω・`)

「Javaが使えます」という人の基準 - しんさんの出張所 はてな編

Javaできませんでした…

Javaについて

完全な主観なのですが、Java=ダサいという風潮ありませんか?
スタートアップ回りを見ていてもRoRでイケイケという感じがします。
僕も一時期ダークサイドに落ちて、転職するならRubyの会社に行こうと思っていました。
ただ、去年のデブサミ関西に参加したときに、某イケメンさんの考えを聞いてダークサイドから帰ってきました。
Oracleさんも若者に情報発信してほしいそうなので、このようなイメージを無くすに頑張ってほしいです。

まとめ

Javaださくない

地方エスアイアーを退職しました

本日が最終出社日であり、2012年4月に入社した地方SIerを退職しました。

新卒から入社してから2年間お世話になりました。関係者の方々、ありがとうございました。

続きを読む

wasabi触ってみた

Kotlin Advent Calendar 2013 - Adventarの16日目のエントリです。
前回書いたランキングで漏れていたwasabiを触ってみました。

wasabiとは

Kotlinで書かれたJVMで動くsintra風のHTTP Frameworkです。MVCフレームワークではなく、viewがありません。Angular.jsかEmber.js等のクライント側のMVCで実装する必要があります。

Hello world

本当はtools配下のgradle.build使えばいいんでしょうけど、どうもうまくいかないので本体を直接cloneして実行ファイルを作成しました。

import org.wasabi.app.AppServer
 
fun main(args: Array<String>) {
    val server = AppServer()
    server.get("/", { response.send ("Hello world.") })
    server.start()
}

f:id:morizo999:20131216011420j:plain

オブジェクトのGET

Less Than Dot - Blog - Wasabi a sinatra/nancyfx inspired webframework for kotlin
ここを参考にオブジェクトのGETをしてみました。Content NegotiationがデフォルトでTrueになったので、
import org.wasabi.interceptors.parseContentNegotiationHeaders
import org.wasabi.interceptors.negotiateContent
が不要になってました。

import org.wasabi.app.AppServer

fun main(args: Array<String>) {
    val server = AppServer()
    var person = Person("test","test2")
    server.get("/", { response.send (person) })
    server.start()
}

class Person(var firstName: String, var lastName: String)

f:id:morizo999:20131216011425j:plain

おわりに

POSTとPUTやAngular.jsの連携も試したかったけど余裕なかった(´・ω・`)
あんまり動作するサンプルが無いみたいなので、今後に期待ですね!

kotlin関係のgithubレポジトリ人気ランキング

Kotlin Advent Calendar 2013 - Adventarの12日目になります。
第1回 かわいいKotlin勉強会でgithubのkotlin関連はコンパイル出来ないものが多いだそうで
気になったのでとりあえずスター数TOP10で見てみました。
※スター数同じ物は更新日が新しいものの順位を上にしています。

10位:vertex-kotlin ★11

Vert.xをkotlinで動かすためのレポジトリ。最終更新が2012年6月でコンパイル不可でした。

9位:koolapp ★12

6位のkoolと統合

8位:kotlin-samples-for-android ★12

Snake,WeatherListWidget,Wiktionary(Android SDKで標準で用意されているサンプル)をKotlinで書いた場合の例があります。コンパイルまで確認。

7位:kotlin-euler ★12

やったね!コンパイル可能!Project Eulerにある問題をKotlinで解いてます。
例えば

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.Find the sum of all the multiples of 3 or 5 below 1000.

1000未満の3か5の倍数の和を求める問題です。その回答が

 fun main(args: Array<String>) {
    val limit = 1000

    val result = (1..limit - 1).iterator().filter { n -> n multipleOf 3 || n multipleOf 5 }.sum()

    println("the sum of all the multiples of 3 or 5 below $limit is $result")
}
fun Int.multipleOf(n: Int) = toLong() multipleOf n
fun Long.multipleOf(n: Int) = this % n == 0.toLong()
fun Iterator<Int>.sum() = fold(0) { (a, b) -> a + b }

//return the sum of all the multiples of 3 or 5 below 1000 is 233168

となります。

6位:kool ★16

同期通信を行うためのKotlin出できたフレームワークだそうです。公式もつながらず最終更新も1年前なので諦めます!

5位:Exposed ★16

Kotlinで書かれたSQLライブラリ。僕の環境では動かせなった(´・ω・`)
参考サイト:KotlinでDBアクセスしてみた(原始的な方法、標準ライブラリ、3rdパーティライブラリ) - 算譜王におれはなる!!!!

4位:kotlinAndroidLib ★21

Androidの記述を簡略化させるためのライブラリ。第一回勉強会で分かりやすい資料があったのでそちらに。これも動かせなかった。

3位:AndroidRivers ★41

Android Rivers | Home PageKotlinで作ったAndroidアプリのソースコードが公開されています。コンパイルしてテストコード実行まで確認。

2位:kara ★69

Webフレームワークです。余裕が無いのでたろうさんのサイトで…
kara/README.md at ja · ntaro/kara · GitHub

1位:kotlin ★524

kotlin本体です。

まとめ

実力不足もあってあんまりコンパイルできませんでした(´・ω・`)
Androidについては初めて触って実機で上手く動作しなかったので勉強したい。
まともに動かせたのkotlin-eulerくらいという…。
あとこのレポジトリが分かりやすいな~と思いました。
kotlin-projects/introduction-to-kotlin · GitHub

追記


見逃していたレポジトリがありました!★33なので4位ですね!
動きそうな感じなので、次はwasabiに絞って書いてみようかな(`・ω・´)