2017-03-12

DroidKaigi2017参加してきた。自腹で

やっぱりブログ書くまでがDroidKaigiかなーと思うので、ブログにしてみます。

自分は基本的に勉強会参加をしないのですが、半年ぶりくらいに勉強会参加しました。実は今回がDroidKaigi初参加です。

以下の自分に関係が深かった項目について感想を記載していこうと思います。

DroidKaigiアプリ
参加者との関わり
運営
セッション
After Party

DroidKaigiアプリ

PR21、計34コミットしました。

数だけ見ると結構したっぽいですが、楽しみたいというスタンスで参加していたので、一人での開発をせずに複数人で開発するスタイルでやったことと雑プログラマーなのでコードレビュー後の修正コミットが多かっただけです。

二日目のウェルカムスピーチでPRの数が296個という話が出ていたので、絶対閉会前に300届かせるぞ！と、こにふぁーさんがモデレーターの休憩時間に横に居座って、聞く事が出来なかったResource Refactoringを直接教わりつつ、PR2つ重ねて300PRのキリ番取りました。

途中Kotlin導入議論にも参加出来たし、本当に楽しかったので、また次回があれば絶対関わりたいなーと。(Kotlinのコントリビュートしているくせに賛成しないのどうなの？って言われるかなーとビクビクしていました。)

参加者との関わり

2日続けてボッチ飯を決めましたが、パーカーのおかげで話してもらえましたし、写真まで撮ってもらいました。

ただ、もっと多くの関わったことがない人とも話したかったのです。自分のコミュ力が低すぎでした。モノやTwitterに頼ればなんとかなると信じたのが敗因です。次回はもっと目立つモノにしよう。

運営

イベント期間中運営にこうしてくれたらいいのになー。というつぶやきを2つしました。

Firebase chatのセッションデータを入れて欲しい！アプリで見れない。#DroidKaigi
— しらじ (@shiraj_i) 2017年3月10日

一時間後に対応してもらいました。実際に当日出来たセッションがアプリに反映されているのはすごい。

droidkaigiの電源タップ、間引くのは全然いいのだけど、次回からでいいので、間引くなら一個づつ間を開けてくれたらすごい助かる。真ん中だけ空いてると入れられない。（なので隣の人に一回抜いてもらわないといけない）
— しらじ (@shiraj_i) 2017年3月10日

6分後に公式アカウントから反映させてもらうという返事をもらいました。

速攻でいい返事をもらえて、ワガママ言うな！とか言われなかったし、ツイートして良かったです。

セッション

聴講したセッションは以下です。

今回は以下の観点でセッションを選びました。

自分が知らない情報が出てくる
どうしても聞きたい項目がある
大穴狙い

チラ裏でやるべき内容かもですがある発表者さんから「発表者さんらにとってはフィードバックとして欲しい」とのことなので書かせてもらいます。

（ただあくまで私の感想ですし、全てのセッションが素晴らしかったので、ネガティブな意見も批判をしているわけではないのでご容赦下さい。）

How to apply DDD to Android Application Development

あんざいさんという方がどういう方なのか聞いたことしかなかったのとDDDに関しては自分も昔から色んな著作を読んで興味があったのでウェルカムセッションの時からルーム3を陣取り聴講しました。

内容としてはDDDを全く知らない人に対して最初の一歩になるような内容でこれを聴いたらDDDやってみようか！と思える内容でした。また新しい単語をチラ見せして、後で説明するなど魅せ方もうまく、感動しました。

50分と長いためダレちゃいそうなのですが、中盤にあった「よくある勘違い」でそこまでの振り返りもしてくれ、その後の話にもすんなり入れたのがさらに良かったです。セッション聴きつつTwitterやりまくるスタイルの自分ですが、何一つツイートせずに集中して聴かせてもらいました。大満足でした。

DDDの話、面白すぎて全くTwitter業が捗らなかった。
— しらじ (@shiraj_i) 2017年3月9日

Android Security 最前線！！

セキュリティに関して知識が乏しいので、初級者〜中級者向けということで聴講しました。実装方法の説明をしつつ、セキュリティの説明をされていたのですが、初級者もターゲットであるなら、出来ればそこ分けてもらい、説明をしてから実際のコードはこう書く！という形で聴きたかったなと感じました。コードを追うので手一杯で実際に聴きたかったセキュリティの話を聴き逃してしまったり、セキュリティの話を真剣に聴いていたらコード追えなかったりしてしまいました。。。

しかし、例えば知っていたカスタムCA証明書問題であればコード読んで非常にワクワク出来たので、やっぱり自分の不勉強のせいだなーと反省させられたセッションでした。

Androidリアルタイム通信アプリ作成Tips

リアルタイム通信の実装方法を紹介しつつ、軽く実装の説明をしてくれるセッションでした。白山さんが言いたいことがいっぱいありすぎるのか、かなり早口でついていくのに必死でした。。。

それぞれの通信方法の特徴やサンプルコード量の配分などが良かったです。30分ではなく50分のセッションでこの量の説明だったら最高でした。

内容としてはリアルタイムの通信方法を検討するならぜひ参考にしたい内容でした。早口のハラハラ感もあり、楽しかったです。

あと、このセッション前の絡みが面白かったのでまとめて呟いたら、ちょっとばずってました。

30歳こえると厳しい

->

* 病院に行く回数が増える
* 夜更かしが出来ない
* 物覚えが出来ない
* Android Studioの補完ないとツラい#DroidKaigi3
— しらじ (@shiraj_i) 2017年3月9日

Android定期実行処理入門

定期実行処理といえば、AlarmManagerだろ？と時代に取り残されているので、勉強のために聴講しました。

AlarmManager以外のモノは聞いたことはあるけど使ったことがないものばかりで、その特徴をしっかりと説明してくれて助かりました。

残念ながらセッション中にあるコードの説明がうん？どこのこと言ってるんだ？と置いて行かれてしまったので、途中で追いつくのを諦めてコードのプレゼンって難しいなーとぼんやりしていました。たぶんハイライトや説明している部分だけコードを見せてくれたらもうちょっとついていけたかもと思います。

内容自体は非常に充実していたので、録画見つつ、スライドを落ち着いて読み返したいなと思います。

解剖 Kotlin ~バイトコードを読み解く~

Kotlinバイトコードを読み解くということで、実際概念としては知っていましたが、あんまり深くバイトコードに注目したことがなかったので、聴講しました。

このセッションの狙いが初学者の恐怖心を取っ払い、第一歩を踏んでもらおうという感じなんだと思いますが、本当にわかりやすく、話し方もゆっくり落ち着いていたので、理解しやすかったです。スライドのコード量も一度に出る量が少ないことや簡単なコードでひと目見ればわかるようになっていて、感動しました。Kotlin始める前に知りたかったなーという内容が多かったです。これをKotlin始める前に聴けた人たちは本当にラッキーだったのではないかと。

「KotlinはJava。」

もちろん、自分のようにある程度Kotlin知っている人でもKotlinの細かい部分を知ることが出来たので、聴けてよかったです。

オフラインファーストなアプリケーション開発

やっぱりオフラインは重要なのであることとzakiさんにお会いしたことがなかったので、聴講しました。

内容はRealmありきな話になってしまっていて、正直それならRealmをセッション説明に入れてほしかったなーと思いました。特に自分のようにRealm入れられない状況の人に対してはちょっとツラいし、他との具体的な比較がなかったので、それじゃあRealmを入れてみよかという判断が出来なかったです。Realm以外でのツラい実装をして、その上でRealmなら〜という話であればうおおお！ってなったかもしれません。

セッションの内容は中の人ということもありRealm自体の魅力を非常に感じられるセッションだったし、少し前のセッションでRealm Mobile Platformをオススメされていたこともあり、状況が変わるなら絶対検討しようと思わせてくれました。

React Nativeはクロスプラットフォームモバイルアプリ開発の夢を見るか

React Native自体触ったことがないので、このセッションを聴いて判断しよーと思い聴講しました。

Reactの説明からReact Nativeの説明にするっと入っていくところがおお！確かに！とわかりやすかったのが印象強かったです。セッションのテンポや流れもロジカルで聴いていて納得感も得られ、楽しかったです。

非常にセッションが良かったので、実際にDroidKaigi後にReact Native触ってみました。即時反映されるし、手にしっくりくる感じでした。聴いてよかったセッションの一つでした。

What’s New in RxJava 2.0

RxJava2.0への移行はある程度把握していたのですが、実際に作業を実施したことがなく(RxKotlinが2.0に正式対応していないため。現在はRxKotlinは対応中。）ライブラリのコードを読む時くらいしか利用機会がないので、これを機にしっかりと把握したいと思い、聴講しました。

Rxの初歩的な話から始まり、RxJava2.0で一番意識するようになるBackpressureの話に続き、RxJava1とRxJava2の比較があったりと流れも良かったです。スライドはシンプルで、でもアニメーションを効果的に使われていて、非常にわかりやすかったです。今までふわっとしていたBackpressure対応もこれで完璧に出来そう！と自信が持てるようになりました。

Android ORMの選び方

元々自分もORMに興味があって、Ormaを作ったgfxさんがどういう観点でORMを選ぶのか興味があったので聴講しました。この日もウェルカムスピーチを捨てて、Room3の最前列確保に走りました。

セッション内容はORMの解説から始まり、自分がまさに知りたかった観点の説明、その点でのそれぞれのライブラリの比較をしてくれました。時間が押していたので一つライブラリの説明を飛ばしたりと時間調整もうまくさすがだ！と感心しまくりでした。

内容もOrma万歳！なのかと思ったら、しっかりとOrmaの問題点を発表していたりと第三者目線での解説に徹していたように思えました。自分のORM選定にも自信が持てるセッションでした。

個人で11個のアプリを公開した結果

超激戦区のこの時間、どうするかなーと一つ前のセッションが終わってからも考えていたんですが、質問をしたくなるようなセッションとしてこのセッションを選びました。(結局質問しなかったけど)

11個それぞれの開発動機・数値・感想などを聞きました。他にも個人で開発する時のTipsやアイコン特に気にすんななど、知らないことばかりでした。終わった後に自分ももっとアプリ出してみたくなりました。またアプリとは違いますが、Intellijのプラグインいっぱい開発していて、メンテどうするか？問題をかかえていたのですが、実際に使うようなやつはそのままやって使われていないようなプラグインはバグFixくらいだけやればいいかなーと気持ちが楽になりました。

11個と量が多かったのでWearアプリとか似てるアプリをまとめちゃっても良かったのではないかなと思いました。こういう失敗も含まれたセッションって貴重なので聴けてよかったです。

How to search and improve performance

初心者~中級者向け＋使ったことあるツールだったので、あんまり期待せず、でもEaster Eggの問題点をという話だったので選択ミスだとしてもいいかなーという気軽な感じで聴講しました。

が、はっきり言って、このセッションが一番衝撃的でした。

まず、ANRなどのパフォーマンスに関わる説明があり、その後、実際のEaster Eggの問題を見せつつ、ツールを使って問題を突き詰め、改善していました。

セッション内で自発的に「感嘆の声」と「拍手」が巻き起こっていたのが印象的でした。30分という短いセッションでしたが、出来れば50分にしてもらい、もう少し細かいステップでの問題解消の説明が聴きたい気分でした。

わかりやすくて、見ていて楽しい。EasterEggの問題潰してるところがさらにすごい。初心者向けって書かれてたから悩んだけど、聴けてよかった。#droidkaigi1
— しらじ (@shiraj_i) 2017年3月10日

スライドだけでも素晴らしいのですが、セッション聴けなかった人はぜひビデオで確認してもらえたらなーと思います。

セッション後に個別で静的解析とツールを組み合わせる場合の使うタイミングなどの質問をさせてもらいました。知っているコードならまずはコードを読み込んでからやると効率があがる。全く知らないコードであれば即ツールを使ったほうが早いとのことでした。

Can You Read Your Tests? Clean and Useful Android Testing, with JUnit and Spock!

Testコードって冗長的で長くなるし読みにくいからコメントやメソッド名に頼ることが多くてこれほんとうに正しい方法なのか？と疑問に思うことが多かったので、テストの書き方を再度勉強するために聴講しました。

英語のセッションを聴くのが久しぶりで、かつ、元々コード量が多いコードから減らしていくという内容だったので、スライドを読むのも結構大変で、必死でついていきました。が、やっぱりついていけず漏れていた部分が多かったです。

AssertJとか使っていたり、結果的に実際のテストコードが短くなるのは良いのですが、メソッドで切り出した部分も全て表記してほしかったなという印象です。

セッション終わり際にCode Smellをまとめてくれたのは良い指標かなと感じました。Spockの説明はさすがで、ぜひ導入してみたいなーと感じました。

2つのアプリ、1つの設計のデザイン指針

Quipper社のデザイン指針が聞けると思い、しかも自社サービスのデザイナーは一人なので、どういうことをすればより良いデザインのサポートが出来るだろうかと思い、聴講しました。

そして、最初のほうで会社やアプリの説明だったので気が緩んでKotlinの開発始めてしまい、それが完全にミスだったっぽく、ワンソースプロダクトの定義を聴き逃してしまいました。それをずっと引きずってしまい、申し訳ないのですが、あまり理解できませんでした。フレーバーで分けてるってことなのか、デザインのソースを一つにしていて、それを各種アプリで分けているのか？ブランド違う？うん？という感じで完全にやっちゃいました。

またビデオとスライドを確認してみます。。。

本当に申し訳ありません。

Smoke and Mirrors in Android UI

Google Photoなどの動きをどう作るのか興味があり、聴講したかったのですが、他のセッションの並び列と勘違いして、聴くのを諦めた時のツイートです。

.@rallat さんのやつ聴きたかったけど、並びまくってて諦めた。井戸端会議聴きながらKotlin書こ。
— しらじ (@shiraj_i) 2017年3月10日

発表者さんに拾ってもらい、Fireside chat始まる寸前に退席して聴講させてもらいました。(Firesite chatもぜひ聴きたいので録画公開何卒！)

Google PhotoのRecyclerViewをピンチイン・アウトすることによってグリッドの数を増やしたり減らしたり、一つの画像をローテートしたりして、最終的に画面全体に表示する機能があるのですがその機能の実装方法でした。

セッションでもよく出ていましたが、本当にこんな気分でした。

improved magic gif

具体的な実装方法はActivity一つ、FragmentなしでRecyclerViewを重ねてそれを出し分けするというものでした。またViewOverlayを利用することで画像を一枚バーン！と出すようです。

他にもローテートのためのPivotの設定方法など細かい部分をわかりにくくならない限界のところで説明してくれていました。海外では普通ですが、スライドには載っていない話が多かったので、本当に生で聴けて良かったなーというセッションでした。

発表者さんとはAfter Partyでもお話させてもらい、これがベストプラクティスだということの確認も出来たし、実際Googleもそういう実装をしているからデビオ確認してみなよというアドバイスも頂きました。

テスト0から目指すクラッシュフリー率99%

テストがないプロダクトにテスト文化を根付かせたいと思ったので聴講しました。

セッション内容はActivityにあるコードをテストするなんて無茶でしょ！という話からdelegateなどで切り出し、テストしやすいコードを作ってテストしていこうぜ！という話でした。

残念ながら、テスト文化を根付かせたいという理由で聴いていたので、それが抜けてしまっていてあー！となりました。ただ、セッションの内容自体は素晴らしく、テストしやすいを意識して開発するという視点は本当に大事だなと認識しました。

セッション後に話しさせてもらったのですが、そこのお話はマイク使って話して下さいよ！と何度もお願いするほど良いクオリティでした。その話のほうが実は刺さって、テストがないならまずUIテストで画面録画しまくっちゃえとか、まずは始めることが大事（要約）というような話でした。知っている方のセッションだとこう気軽に質問出来るのでありがたいなーと。

ちなみにこのセッションでも始まる前に雑談があって、その話も結構面白かったです。場の温め方がうまいなーと感心でした。Androidの筋肉枠の一つは完全に白山さんな印象です。

全体的に

セッションの説明を読んで期待してから聴くので、このセッション説明と違ったりすると若干ネガティブな感想になってしまいました。ただ、自分の視点からはネガティブってだけで、予備知識があったり、別の人からすればすごい良かったり役立つ内容ばかりだったはずなので、ただの一観客の話だと軽く流してもらえたらなーと思います。。。

Droidkaigi終わった後にこんな生意気なツイートしているのですが

来年チャンスあったらスピーチ側に回りたい！という思いだけはあるので、次のCfP期限までに何か武器拾いたい。今持ってる武器はニッチ過ぎて、誰もいない部屋で一人で泣きながらプレゼンしてるのが目に見える。
— しらじ (@shiraj_i) 2017年3月10日

冷静にこうやってコメント書いていると、自分がスピーチしたら、来てもらったAndroiderの30分を無駄にしてしまうのでは？？？という気持ちになりました。実際にあれだけの人の前でスピーチ出来るの本当にすごいです。

After Patry

After Partyでは本当に名前をあげたら半端ない数の人と話すことが出来ました。主催者の日高さんと初めてお話することも出来て感激でした。

そして、Kotlinやりだして一年ちょいですが、ついに日本のKotlerの憧れの的のたろーさんと話すことが出来ました。今までKotlin触ってて良かったなーとしみじみしました。

ただ、嬉しすぎてテンションおかしくなってしまって、あとでこんなツイートしています。

kotlinガチ勢集まった時、写真撮ってもらえばよかった！せっかくのチャンスだったのにもったいないことした。
— しらじ (@shiraj_i) 2017年3月10日

またKotlin勢揃うチャンスがあったら絶対撮ってもらいたいです！

他にも自分が作ったdatabinding-supportを使ってくれていて、さらに修正PR送ってくれた方ともお話出来たのも本当に嬉しかったです。自分が作っているものを使ってくれている人がいた！！！って。本当に励みになりました。

Twitter上でしか知らない人たちといっぱい会えた！良かった！楽しかったです！！！#droidkaigi
— しらじ (@shiraj_i) 2017年3月10日

まとめ

スタッフの皆様ありがとうございました！また来年よろしくお願いします！

(名前を極力出さずに書きましたが、発表者の方と運営の方はどうしても必要だったので、書いてしまいました。もし消して欲しい方は@shiraj_iまでメンション下さい。即消します。)

2016-04-01

jitpack.ioではまったところまとめ

まとめ

以前から色んな箇所で取り上げられているjitpack.ioですが、ドキュメントに書いてない機能であったり、書いてあってもよくわからない機能がいくつかあったのでまとめてみました。

そもそもjitpack.ioって何か？とかどう使えばいいのか？は以下のリンクを確認して下さい。

qiita.com

以下の機能の説明をします。

compile指定以外
Multiple Module
SNAPSHOT version

compile指定以外

compile指定以外ももちろん問題なく動きます。

例えばよく使う、aptの場合

apt 'com.github.$USER.$REPO:$Module:$VERSION'

Multiple Module

一つのレポジトリで複数のmoduleを扱うことがあります。

その場合、jitpack.ioにアクセスし、repositoryのURLを貼ってみます。例えば、自作ライブラリでやってみます。

github.com

        allprojects {
        repositories {
            ...
            maven { url "https://jitpack.io" }
        }
    }

    dependencies {
        compile 'com.github.User:Repo:Tag'
    }

こんな感じで入れればいいよ！と言われるので、そのままやるとコケます。

Multiple Moduleなので、以下のように指定が必要になります。

compile 'com.github.$USER.$REPO:$Module:$VERSION'

これはドキュメント通りhttps://jitpack.io/docs/BUILDING/#multi-module-projectsなのですが、一つドキュメントに記載されていない事項があります。

例えば、自分がコントリビュートしている、PermissionsDispatcherの場合

github.com

compile 'com.github.shiraji.permissionsdispatcher:permissionsdispatcher:2.1.1'
compile 'com.github.shiraji.permissionsdispatcher:permissionsdispatcher-processor:2.1.1'

このように指定する必要が出てきます。

つまり

compile 'com.github.$USER.$REPO.toLowerCase():$Module:$VERSION'

が正しいフォーマットです。

SNAPSHOT version

SNAPSHOTバージョンはweb上では一つしか選択できないようなUIです。

ドキュメントにもbranch-SNAPSHOTと記載されているので、-SNAPSHOT付きのブランチを作成してもweb上では反映されません。しかし、ブランチが存在していさえすれば利用は可能のようです。

例えば、v1.1.1-SNAPSHOTというブランチをリモートに作成してあるとしたら、以下になります。

compile 'com.github.$USER.$REPO:$Module:v1.1.1-SNAPSHOT'

ドキュメントにも書いてあるけど、webUIには反映されないから気をつけてねってことです。

2015-09-06

リファクタリングについて伝えたいこと。

リファクタリング非エンジニア向けプログラミング職場環境

この文章は以下に該当する方へ、なぜエンジニアにリファクタリング(リファクタ)させるべきなのかを記載しています。

リファクタリングする＝サービスの開発が停止すると考えている方
リファクタリングに関して価値を見出せない方
エンジニアにリファクタリングさせて欲しいと言われる方

最初に

リファクタリングの話をする前に、一般的な職場に関する質問があります。

あなたの職場は綺麗ですか？
あなたが思い浮かべる「できる同僚・上司」の机は整理整頓されていますか？

全ての人に当てはまるわけではないと思います。しかし大抵の方は両方回答がYesになると思います。

職場を綺麗にするのはそこで働く人の健康維持やモチベーション向上に役立ちます。職場を綺麗にしてくれる専門のスタッフがいる企業もあるのではないでしょうか？また整理整頓された机で仕事することにより、ムダを省略することが出来ます。仕事をするスペースが増えることにより効率もあがります。大抵の出来る人は机を整理整頓している傾向があるそうです。著名な会社の研修でも同じようなことを説いていました。

汚い環境で働くということは、モチベーションを下げ、ムダな作業を発生させ、効率を下げるということです。汚い環境で働くのは非常に辛く、可能であれば、人はその環境から離れていきます。

リファクタリングとは何か？

さて、本題のリファクタリングについてです。wikipediaでは以下のように説明されています。

リファクタリング (refactoring) とはコンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理すること。*1

もう少しサービス開発に絡めて切り込んだ説明にすると、

「リファクタリングするということは、サービスの機能の追加や削除は一切行わず、コストをかけて、今まで動いていたコードに対して修正を加える作業です。」

リファクタリングをすることにより、バグを埋め込んでサービスを止めてしまう可能性も含まれることになります。もちろんそれを避ける術はいくつかあるのですが、手段はエンジニアが考えればいいのでここでは省略させていただきます。

リファクタリングをなぜやるのか？

なぜこんなムダな作業を行うのでしょうか？エンジニアはアホなんでしょうか？

エンジニアはコード上で仕事をしている

（実際、アホなことやる人は多いですが・・・）事自分たちが行っているサービス開発に関して言えば、プライドを持って行っているはずです。サービスに携わっている以上、そのサービスがより良くなることを望んで開発しています。そのエンジニアがコストがかかることを承知で、リファクタリングさせて欲しいという理由があります。それはエンジニアはコード上で仕事をしているということです。

デスクの綺麗さとコードの綺麗さ

私が非エンジニアにリファクタリングの重要性を説明する時は以下のように説明します。

デスクに毎日のようにいろんな人が資料を置いていくとします。
資料を置くことを目的にする社員もいるので、資料はあなたが意図した場所には置かれません。
デスクがどんどん汚くなっていき、必要な資料を探すのに苦労します。
間違った資料を使って仕事をする可能性も出てきます。
このような状況になった場合、あなたがまず最初に行うのが、整理整頓だと思います。

ではエンジニアはコード上で仕事をしているということなので、デスクを「コード」、置かれていく資料を「追加機能」と読み替えてみます。

コードに毎日のようにいろんな人が機能を追加していきます。
機能追加を目的にする社員もいるので、エンジニアが意図した場所に機能が追加されません。
コードがどんどん汚くなっていき、必要な機能を調査するのに苦労します。
間違った機能を使って仕事をする可能性も出てきます。(=バグを作り出す)
このような状況になった場合、エンジニアがまず最初に行うのが、整理整頓(=リファクタリング)だと思います。

エンジニアが作業しているコードを綺麗にすることにより、将来的にバグを作り出さなかったり、効率良く作業が出来る環境を作ることが出来ます。

エンジニアを惹きつける、引き止めるためのリファクタリング

この文章も同じように読み替えることが出来ます。

汚いコード上で働くということは、モチベーションを下げ、ムダな作業を発生させ、効率を下げるということです。汚いコード上で働くのは非常に辛く、可能であれば、エンジニアはそのコード（会社）から離れていきます。

エンジニアが働く場所の環境を良くすることとそのエンジニアを魅了するためにリファクタリングをさせる猶予を与えてあげてください。この魅力的な余裕があることでエンジニアとしてやる気が向上し、整理されたコードで仕事が出来るためパフォーマンスが上がります。働きやすい職場(コード)で最高のパフォーマンスを出すことが出来るのであれば、エンジニアが離職するのを引き止めるのに役立つはずです。

まとめ

汚い場所で人を働かせることが辛いということがわかるのであるなら、ぜひ汚い環境で働かされているエンジニアに掃除をする猶予を与えてあげてください。それが長期的に見るとサービスを改善を早くし、技術力のあるエンジニアを定着させ、変化に柔軟なサービスを提供させることが出来るようになるからです。

*1:"リファクタリング (プログラミング)". wikipedia. https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0_(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0

2015-09-05

自己紹介

はじめてはてなブログを使ってみようと思います。

普段技術ネタをQiitaにあげているのですが、技術ネタではないものを書くためにこのブログを開設しました。shirajiともうします。

Qiitaもshirajiというアカウントで記載しておりますので、そちらも確認してください。

思ったものを記載していくつもりです。更新ペースはそこまで高くないです。

よろしくお願いいたします。

2014-01-15

Eclipseの環境構築をまとめてみた

Eclipse Java

最近、Objective-cやらJavaやらRailsやらPlay frameworkやら手を出しまくっているせいか書くネタがない。。。

ということで、本題。
端末をかえることが重なってしまい、毎回Eclipseの設定をするという非常にだるいことになったので、一旦、何を毎回しているかメモ書き。あくまで自分の環境なので、設定して壊われても責任持ちません。
（いい加減、このあたりなんとかならないものか・・・。vimのvundleみたいにファイル一つでやってくれたらいいのに。）

1. インストール
面倒なので、All in one（Android開発ならADT）
URL: http://mergedoc.sourceforge.jp/
重い場合は新しいPC買えばいいと思う。（自分はお金がないので我慢。）

2. 英語化
URL: http://d.hatena.ne.jp/shiraji/20130427/1367054426

3. プラグイン

Glance（ctrl-jの上位互換）
- URL: http://code.google.com/p/eclipse-glance/
- Update Site: http://eclipse-glance.googlecode.com/svn/site/
- キーバインド設定は下に記載。

Eclipse Color Theme (Editorの色変更)
- URL: http://eclipsecolorthemes.org/
- Update Site: http://eclipse-color-theme.github.io/update/
- 設定方法
  - テーマを選ぶ
    - Window > Preference > General > Appearance > Color Themeで選ぶ（いつもWombat）
  - カーソルがある行のハイライトがうざいので消す
    - Window > Preference > General > Appearance > Text Editor > Highlight current lineのチェックを外す
  - ついでに行番号を表示する
    - Window > Preference > General > Appearance > Text Editor > Show line numbersのチェックを入れる
  - Wombat好きなんだけど、field名とクラス名の色が同じなので、かえる。
    - Window > Preference > Java > Editor > Syntax Coloring > Java > Fieldsを選択。色を変える。（色はだいたいいつも左から6番目、上から3番目）

Eclipse Theme (Editor以外のテーマ変更、4.2 - Juno以上だった場合)
- URL: https://github.com/jeeeyul/eclipse-themes
- Update Site: https://raw.github.com/jeeeyul/eclipse-themes/master/net.jeeeyul.eclipse.themes.updatesite
- 設定方法
  - テーマを選ぶ
    - Window > Preference > General > AppearanceでJeeeyul's theme - Chrome Themeを選び、再起動する
  - パディング(Shadow？)を消す
    - Window > Preference > General > Appearance > Chrome Theme > General > Sash WidthでThin Sashを選ぶ
  - さらに画面大きく
    - Window > Preference > General > Appearance > Chrome Theme > Part > Part Statck ShapeのPart Paddingを0pxにする
  - 各パネルの色がいや
    - Window > Preference > General > Appearance > Chrome Themeで、右にあるパレット？の横の下三角形から > Editor's Presets > Chrome Classic
- メモ
  - Eclipse Dark Junoというものもあるけど、ところどころ白くて嫌。全部まとめて変えられればいいのに。

4. 補完

Javaの補完の機能をもっと便利に
- Window > Preference > Java > Editor > Contents Assist
  - Enable auto activationをチェック
  - Auto activation delay(ms): 80
  - Auto activation triggers for Java: .abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_
いらない補完候補を消す
- Window > Preference > Java > Editor > Contents Assist > Advanced
- Javaの開発ならJava Proposalsだけあれば十分

5. UTF-8化
ファイルのエンコーディングをUTF-8にする。てかこれなんでデフォルトじゃないのだろう？

Window > Preference > General > Workspace > Text file encodingをUTF-8

6. キーバインド
設定する場所: Window > Preferences > General > Keys

Glanceのため、Incremental FindとIncremental Find Reverseをアンバインド
Glanceのキーバインド

Name:「Open Glance」
Binding: Ctrl+j
When:「In Dialogs and Windows」

Name:「Next Match」
Binding; Ctrl+j
When:「Glance Search Context」

上のキーバインドをコピーし、
Name:「Next Match」
Binding; Enter
When:「Glance Search Context」

Name:「Previous Match」
Binding; Ctrl+Shift+j
When:「Glance Search Context」

クリーン

Name:「Clean」

Binding; F8

When:「In Windows」

ツールバー出したり消したり

Name：「Toggle Toolbar」

Binding; Ctrl+4

When:「In Windows」

7. スプラッシュ画像を変える

変えたいsplash.bmpを以下のフォルダに置く（オススメはEclipseたんなんですが、職場ではイメージを壊す恐れがあるので、要注意）
- eclipse\plugins\org.eclipse.platform_xx
ADTの場合
- eclipse\plugins\com.android.ide.eclipse.adt.package_xx

8. ツールバーのカスタマイズ
Eclipse Junoを使っている方（特にADT）この設定はやらないほうがいいです。理由は追記に記載。

Window > Customize Perspective... > Tool Bar Visibilityで不必要なものからチェック外す。
- 自分の場合、LaunchとDebug以外全て外す。LaunchとDebugはマウス使うので。
右にある各Perspectiveのテキストがうざい
- 右にある各Perspectiveのアイコン右クリック > Show Textからチェック外す

9. コードテンプレート

新しくファイル作成するとファイルの1-3行目にコメントが入るのがうざい
- Window > Preference > Java > Code Style > Code Templates > Comments > Files > Edit > 空にする

Overrideしたメソッドのコメントが意味不明
- Window > Preference > Java > Code Style > Code Templates > Comments > Overriding methods > Editに以下を記載

/**

 * {@inheritDoc}

 */

新しいメソッドのテンプレートがうざい
- Window > Preference > Java > Code Style > Code Templates > Code > Method body > Editで以下を記載

throw new UnsupportedOperationException("havn't implemented, yet");

新しいファイル作成時、必ずコメントをつける
- Window > Preference > Java > Code Style > Code TemplatesでAutomatically add comments for new methods and typesをチェック（これもデフォルトにしてー）

10. その他

検索した結果からファイルへ飛ぶときに新しいタブを開いてほしい
- Window > Preference > General > SearchでReuse editors to show matchesを外す

フィールド名の前は「m」とかプレフィックスにする。だけど、getter/setterではmはつけない場合。(開発場所により変わる)
- Window > Preference > Java > Code StyleでFieldsを選択し、Edit > Prefix listにm

保存時に何かする（フォーマットとか）
- Window > Preference > Java > Editor > Save Actions
  - 開発場所によりかなり変わるため、なんともいえないが、必ずつけるものは以下
    - Format source codeをチェック
      - Format edited linesを選択
    - Organize importsをチェック
    - Additional actionsをチェックし、congifureをクリック
      - Code Organizing > Remove trailing whitespaceをチェック
        
        All linesを選択
      - Missing Code > Add missing Annotationsをチェックし、その下の全てをチェック
      - Unnecessary Code > Remove unused importsとRemove unnecessaray castsをチェック
  - this.とかのルールもここで設定すると便利。これ設定するようになってから、ctrl+shift+oとctrl+shift+fを押さなくなりつつある。

Package Explorerに隠しファイルを表示する
- Package Explorerの右側にある三角形 > Filters...をクリック
- .* resourcesのチェックを外す。

なんかまとめたら大作になた・・・。
設定関連はgithubにあげて管理しなきゃ。放置しているレポジトリがあるから、腰をあげてみますか。

にしてもこのブログのフォーマットうまくできない。
写真つきにしようと思ったら、かなり長くなったので、やめた。

// 追記 ////////////////////////////////////////////////
ツールバーの変更について
書いてから、気づいたのですが、現在ADTではツールバーにバグが存在しています。
ツールバーのアイコンの移動や消したものをもとに戻す機能にバグがあり、動かないと報告もあります。https://bugs.eclipse.org/bugs/show_bug.cgi?id=340695

もし、ツールバーからアイコン消したけど、やっぱり必要だったーなどがあった場合、以下のファイルを消すともとに戻ります。
workspace/.metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi
ただし、このファイルはビュー関連の設定が入っているファイルですので、消す場合、またパースペクティブなどのレイアウトをし直す必要があります。扱いには細心の注意を払って下さい。

2013-12-01

Objective-cでNSArrayのcountではまったこと。

10月くらいからObjective-cを触っている。
結構毎日触っているんだけど、まだまだわからないことが多くて大変です。
さらにプライベートではwindows使っていて、Mac持っていないので、会社でしか触れていなくて。Mac買おうかなー。

ということで初歩的なところではまったのでメモ。

// 配列

NSArray array = @[@"赤",@"青",@"黄",nil];
for (NSIntger index = -1; index < [array count]; index++) {

  if (index > 0) {

    NSLog(@"%@", [array objectAtIndex:index]);

  } else {

    NSLog(@"%@", @"以下から選んで下さい。");

  }

}

こんな感じで、ループさせてみた。まぁなにゆえ、ループ前にやらないのかとかあるけど、とりあえずそこはおいておいて。
このループ実は実行されない。なぜかというと[array count]の戻り値がNSUInteger。つまり、unsigned integer。
index=-1を比較する場合、indexがunsigned integerとして扱われ、-1はunsigned integerの一番大きな数字となる。

Javaにはないunsigned型があるので注意しましょうということでした。

2013-10-06

chef-soloでcookbookを作成する

chef

以前からJenkinsさんをchefで立ち上げるところまで自動化したのですが、
Jenkinsさんの自動起動が設定されていなかった。
ドキュメントを流し読みしてみても、Jenkinsさんの自動起動設定がない。
じゃあそういうレシピ作成してみよかと思ったのですが、数カ月前ということもあり、完全に失念！

ということで、chefのcookbook作成方法のメモです。

まず、環境を作る。

git clone https://github.com/shiraji/chef-repo.git

cd $HOME/chef-repo

bash chef_setup.sh

これで問題なければ、今回使うchefやknifeが入る。
chef-soloなので、knifeの設定（knife configure)をせずに突き進む。

以前にも書いたと思うけど、ざっくり構成についておさらい。

chef-repo/

├── cookbooks           --- 人が作ったcookbooksを保持

├── nodes               --- 実行される各サーバ固有の設定を保持

├── roles               --- cookbook利用時の設定値を保持

└── site-cookbooks      --- 自分が作成したcookbookを保持

    ├── addusers        --- 自作ユーザ追加cookbook

    └── server_settings --- 自作サーバの基本設定のcookbook

nodesとrolesはかなり重要で、この2つを意識したcookbookを作れば、拡張性が高くなる。

実際にcookbookを作成してみる。

cd $HOME/chef-repo/site-cookbooks/

knife cookbook create autorun_settings -o .

knifeが色々揃えてくれた結果がこれ

site-cookbooks/

└── autorun_settings

    ├── CHANGELOG.md

    ├── README.md

    ├── attributes        --- attributeを設定する。default.rbがデフォルトの値

    ├── definitions

    ├── files

    │   └── default

    ├── libraries

    ├── metadata.rb

    ├── providers

    ├── recipes

    │   └── default.rb   --- デフォルトのrecipe

    ├── resources

    └── templates

         └── default

Hello worldしてみる。

デフォルトのrecipe（recipes/default.rb）に以下を書き込む。

puts "Hello World"

これだけでほぼ終わりなのだけど、せっかくなので、nodes, rolesを設定する。

まずはrole。$HOME/chef-repo/roles/にjenkins_autorun.jsonを作成する。
本当はここで、knife role createとかするべきなんだけど、knifeの設定してないしーということで簡単なスクリプト作成したので、それを利用して、作成する。

cd $HOME/chef-repo/roles/

bash new_role.sh jenkins_autorun.json

new_role.shはsedでテンプレートファイルの中身を変更し、それをファイルに保存している。

#!/bin/sh
if [ $# -ne 1 ]; then

  echo "No role name"

  exit 1

fi
_role_name=$1
cat role_template.json | sed -e "s/NAME/${_role_name}/g" > ./${_role_name}.json

role_template.jsonはknife create roleすると出来るべきroleファイル

{

  "name": "NAME",

  "description": "",

  "json_class": "Chef::Role",

  "default_attributes": {

  },

  "override_attributes": {

  },

  "chef_type": "role",

  "run_list": [
  ],

  "env_run_lists": {

  }

}

上記のコマンド叩いて、出来るのがこのrole。（コピペするだけでも問題ない。）

{

  "name": "jenkins_autorun",

  "description": "",

  "json_class": "Chef::Role",

  "default_attributes": {

  },

  "override_attributes": {

  },

  "chef_type": "role",

  "run_list": [
  ],

  "env_run_lists": {

  }

}

今のところ、attributesなどはないので、設定せず、run_listに先程作成したcookbookを設定する。

{

  "name": "jenkins_autorun",

  "description": "",

  "json_class": "Chef::Role",

  "default_attributes": {

  },

  "override_attributes": {

  },

  "chef_type": "role",

  "run_list": [

    "recipe[autorun_settings]"

  ],

  "env_run_lists": {

  }

}

次にnode
run_listに上記で作成したroleを指定する。

{

  "run_list": [

    "role[jenkins_autorun]"

  ]

}

実行で必要な設定ファイル(chef-repo/solo.rb)はこんな感じ。

le_cache_path           "#{ENV['HOME']}/chef-repo"

data_bag_path             "#{ENV['HOME']}/chef-repo/data_bags"

encrypted_data_bag_secret "#{ENV['HOME']}/chef-repo/data_bag_key"

cookbook_path             [ "#{ENV['HOME']}/chef-repo/site-cookbooks",

                            "#{ENV['HOME']}/chef-repo/cookbooks" ]

role_path                 "#{ENV['HOME']}/chef-repo/roles"

$HOME直下に置いてあると想定されている。違う所に置いてある場合は、このファイルを変更すること。
拡張子で一目瞭然だけど、solo.rbはrubyファイル。＄HOMEは使えないので注意。

それでは実行

cd $HOME/chef-repo

chef-solo -c solo.rb -j nodes/jenkins_autorun.json

実行結果

Starting Chef Client, version 11.6.0

Compiling Cookbooks...

Hello World

Converging 0 resources

Chef Client finished, 0 resources updated

これで、Hello Worldはできたので、今回の目的であるjenkinsのサービスの自動起動をしてみる。
chkconfig jenkins onを実行すればいい。
resourcesというものがchefで実行されるコマンド。詳細はここhttp://docs.opscode.com/resource.html
このresourcesとrubyの文法を駆使してrecipeを作成していく。
簡単なlinuxのコマンドのため、resourcesはexecuteを利用する。
chef-repo/site-cookbooks/autorun_settings/recipes/default.rbに以下を記載する

execute "autorun" do

  command "chkconfig jenkins on"

  action :run

end

ただ、これだと、jenkinsのみのcookbookになってしまう。そこでattributeを設定し、roleで指定できるようにする。
まずはデフォルトのattributeを作成する。
chef-repo/site-cookbooks/autorun_settings/attributesにdefault.rbを作成。中身は以下。

default[:autorun][:ons] = ["jenkins"]

これを使うrecipeはこんな感じ。

node[:autorun][:ons].each do |on|

  if !on.empty?

    execute "autorun on" do

      command "chkconfig #{on} on"

      action :run

    end

  end

end

実際に実行してみると

Starting Chef Client, version 11.6.0

Compiling Cookbooks...

Converging 1 resources

Recipe: autorun_settings::default

  * execute[autorun on] action run

    - execute chkconfig jenkins on

Chef Client finished, 1 resources updated

これでもまだ、拡張性がないので、autorunの設定のON、OFFができるようにする。
まずデフォルトの設定を以下にする。

default[:autorun][:ons] = []

default[:autorun][:offs] = []

デフォルトのrecipeを以下に

node[:autorun][:ons].each do |on|

  if !on.empty?

    execute "autorun on" do

      command "chkconfig #{on} on"

      action :run

    end

  end

end
node[:autorun][:offs].each do |off|

  if !off.empty?

    execute "autorun off" do

      command "chkconfig #{off} off"

      action :run

    end

  end

end

ここで、roleでoverride_attributesを設定する。chef-repo/roles/jenkins_autorun.jsonを以下のようにする。

{

  "name": "jenkins_autorun",

  "description": "",

  "json_class": "Chef::Role",

  "default_attributes": {

  },

  "override_attributes": {

    "autorun": {

      "ons": ["jenkins"]

    }

  },

  "chef_type": "role",

  "run_list": [

    "recipe[autorun_settings]"

  ],

  "env_run_lists": {

  }

}

実行結果（上記と同じ）

Starting Chef Client, version 11.6.0

Compiling Cookbooks...

Converging 1 resources

Recipe: autorun_settings::default

  * execute[autorun on] action run

    - execute chkconfig jenkins on

Chef Client finished, 1 resources updated

これで完了。

■注意点■
私は今CentOSの環境のみしかないので、chkconfigが使えないubuntuとか気にしていない。
必要な場合はOS別のコマンドを作成すればいいと思う。