builderscon tokyo 2017 やったぞ!

builderscon tokyo 2016から引き続き運営側で参加しました。
去年より日程も規模も大きくなったので大変でしたがとても楽しかったです!

今年はドリンクの発注、モバイルアプリの作成、しゃもじの発注をやってました。

ドリンクについて

懇親会は会場側にお願いしていたので問題ないのですが、
前夜祭では自分たちでドリンクを用意する必要がありました。
カクヤスを使おうとしていたところ、日吉の範囲内の店舗が潰れてしまったようでどうするか右往左往していました。
最終的に、当日人力で駅前のスーパーに買いに行くかとなっていたのですが、プライムナウの範囲内で、
前日しか注文できないが在庫があれば問題ないとのことで、無事宅配していただけました。

アプリについて

今年は日程もトラック数も多いので、モバイルアプリで見やすいものがあるのがいいなーと思っていました。また、POとして自分でアプリの全体像をデザインして作ってみたいなと思っていたので、
同僚兼運営エンジニアの@to4ikiを誘ってアプリを作りました。結果的にタスクが少なくなるけど、気持ちが高まっている時期の直前に一気に作る形になったので、もう少し余裕のあるスケジュールになればよかったと反省しています。

AndroidアプリではDroidkaigi2017様のコードをとても参考にさせてもらいました。あのコードがなければ確実にリリースが間に合いませんでした。ありがとうございました。
DIやRxを消したのは、技術が悪いわけではなく、オーバースペック且つ導入する時間がなかったからです。Rxは知識がなかったので@to4ikiに相談しましたが、消していく作業が斬新すぎてビックリしていました。
ソースコードは以下にあります。理想のタイムテーブルを目指し、少しずつ更新していこうと思います。

github.com

また、人生2回目のLTで、初回より20倍くらい人がいて物凄い緊張しましたが、発表することができたので嬉しかったです。牧さんにも、発表内容の詳細をお伝えしていないのに、タイムテーブル被せをしてきて流石だ...と思いました!
発表慣れしていないので、正面スクリーンばかり見ていたと思うので、次回からはちゃんと正面向いて話すぞ!!

speakerdeck.com

しゃもじについて

ノベルティのしゃもじについてはどんな反応が来るか不安で不安で三日前からずっとお腹を壊していましたw
当日の反応を見ていると、最初はナンダコレハ...だったのでやっぱり駄目だったか〜と凹んでいたのですが、
全貌が見えてくる(全部違う)とドンドンいい反応に変わってきて、懇親会でも色々コラボが起きててとても面白かったです。
コミュニケーションツール(そのしゃもじ良いですねー等)としても使ってもらえたようで、作ってよかったと思いました!
上がってくる写真もとてもおもしろかったです。特に以下の流れは爆笑していました!


@uzullaさんには内容の案をたくさんもらってすごい助かりました!
180種類全部違ってこそ、あの面白さがあったのだと思います。
圧倒的なネームセンスでした 。

また、宮島工芸製作所様には素敵はグッズを作成して頂いて感謝しております。
最初に180種類全部手書きをお願いしたところ、流石にそれは...となったのですが、
180種類の.aiファイルを作って欲しいと言われ、次にこちらが流石ににそれは...となりまして、
ではやりましょう!!と言っていただけました。

最後に

しゃもじガチャの確率を明記します。
全180種、すべて確率0.56% のSSRです。

No 文字
1
2
3 採用
4 人月
5 豪腕
6 達人
7 一本
8 戻る
9 進む
10 バグ
11 競合
12 怠惰
13 傲慢
14 短気
15 純国産
16 むむっ
17 要検討
18 エス
19 前夜祭
20 マージ
21 えっ?
22 404
23 要出典
24 黄金指
25 四天王
26 仮想化
27 継続的
28 プル型
29 フリー
30 監視中
31 再現性
32 冪等性
33 コピペ
34 処理中
35 ゲット
36 ポスト
37 プット
38 空文字
39 自動化
40 匿名性
41 充電中
42 神頼み
43 生産性
44 ヴィム
45 解析中
46 脆弱性
47 審議中
48 ふぁぼ
49 いいね
50 全クリ
51 HRT
52 デプロイ
53 なるほど
54 ペアプロ
55 ざわざわ
56 おかわり
57 炎上案件
58 満員御礼
59 コミット
60 ヌル
61 アグリー
62 さいつよ
63 リブート
64 障害報告
65 納期厳守
66 リトライ
67 キャッチ
68 ギッハブ
69 給料三倍
70 バッファ
71 年間契約
72 保守契約
73 フェイル
74 サクセス
75 アナログ
76 パケット
77 ヘッダー
78 ドッカー
79 良い乱数
80 良い命名
81 本番環境
82 開発環境
83 ベータ版
84 オンスケ
85 安定稼働
86 イシュー
87 チケット
88 様子です
89 以上です
90 オレオレ
91 要するに
92 詳細希望
93 理論上は
94 趣味です
95 火気厳禁
96 夏季休暇
97 仮想環境
98 可能です
99 できます
100 トーク
101 銀の弾丸
102 金の弾丸
103 メジャー
104 都市伝説
105 仮想現実
106 営業秘密
107 予定通り
108 スクラム
109 デリート
110 デスマーチ
111 ワッショイ
112 プッシュ型
113 キルオール
114 デーモン化
115 デバッグ
116 キャッシュ
117 ワイファイ
118 ログイン中
119 リクエス
120 プラグイン
121 コミッター
122 クローラー
123 サポーター
124 スポンサー
125 バキューム
126 アジャイル
127 どうですか
128 わかります
129 そうですね
130 コンテナ化
131 アノニマス
132 ゴゴゴゴ…
133 ナイス知見
134 選択と集中
135 タイポです
136 未読消化中
137 副作用無し
138 私の秘密鍵
139 バッチ処理
140 映画化決定
141 デブオプス
142 高い可読性
143 無限ループ
144 障害対応中
145 再発防止策
146 圧倒的成長
147 次回最終回
148 本邦初公開
149 環境構築中
150 上級者向け
151 戦略的撤退
152 非公開情報
153 論より証拠
154 想定内です
155 経験者は語る
156 ナイストーク
157 あんたが大将
158 パワーワード
159 エンバグ回避
160 マージします
161 汎用的な設計
162 タイムアウト
163 進捗ダメです
164 高いバリュー
165 エラーコード
166 ノーコメント
167 ロールバック
168 イーマックス
169 ビッグデータ
170 ドットコム企業
171 リファクタリング
172 進捗どうですか
173 グローバル変数
174 スケールアウト
175 スケールアップ
176 グローバル人材
177 レガシーコード
178 ノーアイディア
179 続きはウェブで
180 アンチパターン

【書評】はじめてのiOSアプリ開発 第2版

@tomzohさんよりはじめてのiOSアプリ開発をご恵贈いただきました。 tomzohさんはiOSDCの主催者かつ、buildersconの運営スタッフをしておりとても情熱を持った方です。 この本からもその情熱が感じられ、iOSを始めるときに欲しい情報がギュッと詰まっている素晴らしい本だと感じました。

TECHNICAL MASTER はじめてのiOSアプリ開発 第2版 Xcode 8+Swift 3対応

TECHNICAL MASTER はじめてのiOSアプリ開発 第2版 Xcode 8+Swift 3対応

前提

業務で経験している経歴だと以下になります

  • サーバーサイド:Java5年, Scala6ヶ月
  • Android3ヶ月
  • iOS開発経験はなし

内容について

大まかな流れとしては、以下となっております

  1. iOSアプリについて
  2. Xcodeについて
  3. ブラウザアプリの作成
    • WebViewを使ってyahoo検索アプリの作成
  4. Swiftについて
  5. Viewの使い方ついて
    • 【表示部品】UIView, UILabel, UIImageView, UIImage, UITextView, UIWebView
    • 【入力部品】UIButton, UISegmentedControl, UITextField, UISlider, UISwitch, UIStepper
    • 【状態表示部品】UIActivityIndicatorView, UIProgressView, UIPageControl
    • 【ダイアログ】UIAlertView, UIActionSheet
  6. グルメ情報アプリを作成し改良していく
    • cocoaPodsを使ってAlamofire,SwiftyJson,SDWebImageを利用する
    • UITableViewの利用
    • APIを呼び出し、取得したJSONの画像を表示
    • UIScrollViewの利用
    • User Defaultsを使ったデータの保存
    • Core Locationを使った地図の表示
    • 写真の取り込み
    • ソーシャル連携
    • アプリの公開

所感

先に簡単なブラウザアプリを作成してから、そのあとにSwiftやViewについて説明していく流れはとても面白いなと感じました。 Androidアプリを開発しているので、大体の開発の流れは想像できるのですが、はじめて開発する場合にも問題なく開発できると思います。 また、現在もグルメ情報アプリを作成している途中なのですが、どんどん機能を追加しているのでやりがいがあります。

素晴らしい本をありがとうございました!

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さんは銀の弾丸ではない
テストを書くことがゴールでなくスタートである
現場によって戦略は異なっている
http://engineer.crowdworks.jp/entry/2015/02/09/100000engineer.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年間お世話になりました。関係者の方々、ありがとうございました。

続きを読む