あとデザインさえあれば・・・を若干のお金で解決する #OSS #docker #99designs #startup
エンジニアとしてサービスを作ってる時にどうしても行き詰まるのが、デザイン。
仮に、それがデザイナーと組んでチームとしてやっているときは良いのだけど、エンジニアの自分だけでやっているような場合特に困る。
Webサービスを作るのであれば、最近はTwitterBootstrap等を使えば、それっぽく見えるようになってきたし、また、iOSに関しては標準のUIKitのデザインでまあまあ綺麗。プロダクトとしてもMVPは達成できると思う。Androidに至ってもかつてはデフォルトだとなにこれ感がつよいUIだったけど、最近はよくなってきているし、**Bootstrap系なデザインライブラリを使えばそこそこ綺麗につくれる。その上で、残る課題がアイコン。ロゴ。
OSSをGithubで公開しているような方の場合は、ソースコード自身がプロダクトのため、デザインは不要かもしれないけど、やはりロゴ。ロゴが欲しくなると思います。
いけてるサービスやOSSってみんなロゴかっこいいですよね！！！
クラウドソーシングでロゴデザインを調達
最近は、デザイナー不在プロジェクトで、クラウドソーシングでデザイン調達をするケースが増えてきています。例えば、下記のDocker、AngularJS、Norikra、Embulk、Spark、Kafkaなどの有名OSSおよびStackoverflow（最近デザインの微調整はいりましたが・・）はどれも
99designs.jp
というデザイン特化のクラウドソーシングサービスでデザインされています。
99designsでは世界中の100万人のデザイナーがコンペ形式で応募してくれます。
どんな感じかというと、コンペ形式でコンペが開催されており、世界中のデザイナーからデザイン案が応募され、その中から優勝者をきめてその優勝者にお金を支払うという仕組みです。（最低2万円台くらいで出来る）
例えば、Dockerのコンテストの結果ページを覗いてみると・・・・。
99designs.jp
優勝作品はお馴染みのクジラ＆コンテナのロゴですが。
ほかがキリンｗｗｗｗ
Slackoverflowはこんな感じ。
99designs.jp
Embulkはこんなかんじ。
99designs.jp
Norikra
99designs.jp
Apache Spark
99designs.jp
Lift（Scala）
99designs.jp
Kafka
99designs.jp
Finagle（Scala）
99designs.jp
AngularJS
99designs.jp
PostgreSQL Studio
99designs.jp
全体的に質が高いですねー。普通に見てて面白い。
日本では、デザインが可能なクラウドソーシングとして、クラウドワークスやランサーズがありますが、登録しているデザイナーがどうしても日本人デザイナーであるため、最初から国境を超えていくようなエンジニアのOSSのようなデザインには99designsのような海外（の感性がある）デザイナーにデザインしてもらうのがよいかなと思ったりします。
自分のOSSにロゴが欲しい方、是非使ってみてはいかがでしょうか。
Developers Summit 2015とDevelopers Summit 2015 Summerで発表してきました #devsumi #natsumi
もう数ヶ月前のことですが・・・、Developers Summit 2015で発表してきました。 そして、先日のDevelopers Summit 2015 Summerにて発表＆表彰をして頂きました。
デベロッパーズサミットというと数年前の自分からしたら神々がそれぞれのマサカリでもって斬り合いする天下一武道会みたいなもので、まさか自分が登壇することになるとは（しかも2回も連続で）夢にも思っていませんでした。 今でも想像するだけで脇に変な汗かくくらい鮮明に覚えていますが、この壇上から300人くらいの方々に話すというUXはとてつもなかったです。高校時代はバンドをやっていましたが、人の前で演奏しているときの感覚とすごく近い体験でした。色々なコミュニティの勉強会で登壇させていただくことはありましたが、それらとは全くの別物でした。程よい緊張感と楽しさが同居する感じ。もうそんな機会はないと思いますが、何か話せるネタを作ってまたダメもとで応募させていただこうと思います（2年連続とかでは登壇出来ないルールぽいけどｗ）
はじまるよー！ #devsumi #devsumiB pic.twitter.com/XFocsSeeUa
— Itsuki KURODA (@i2key) 2015, 2月 20#devsumi @i2key すごくいいトークだったわー。みんな笑って、パシャパシャ写真撮って、スライドをガン見して、うんうん頷いてたわー。 pic.twitter.com/dRDxR2JKHU
— Yusuke Kawasaki (@kawanet) 2015, 2月 20そのときのスライドがコチラです。
www.slideshare.net
夕方のセッションで早朝のセッションよりも参加率が高く、また、業務を早めに切り上げてこられる方がちょうど参加できる枠であった（と思われる）ため、また、あえて共感を頂きやすいような言い回しをしたりして、、、会場票をたまたま多く頂くことが出来まして・・・、その結果、まさかの賞を頂くことができました。色々な偶然のファネルが積み重なった上なのだと思いますが、ありがとうございました。 codezine.jp
そして、昨日、7月29日のDevelopers Summit 2015 Summerにて、受賞者枠？で、もう一度登壇させていただく機会をいただきました。 当日は、ドレスコードは無しと書いてあったので、気楽にいつもどおりの格好で、半袖短パンでいったところ、スーツな方々がほとんどで、TPO力の低さを露呈してしましました。
わいスーツ大勢の中で、短パン半袖。
— Itsuki KURODA (@i2key) 2015, 7月 29ベストスピーカー様（@i2key）が短パンwww
Developers Summit 2015 Summer [Enterprise] デブサミアワード2015冬・あの人気セッションの再演＆アワード表彰式 #natsumi
http://t.co/t5prSlD7PZ
— すぎい まさかつ (@sugiim) 2015, 7月 29受賞者枠として頂いた時間が約20分であり、前回の160枚のスライドを短縮で発表することが出来そうになかったので、別の発表をさせていただきました。 （スライド内では、小さく検証しろとか、MVPつくれとか言う割に、こと自分事になると肥大化したスライドしか作れないという・・・・）
www.slideshare.net
授賞式の際に簡単にはお話させていただきましたが、一貫して伝えたかったことは、実際に現場でものを作っている人が一番偉いとされるようなチームを作りたかった。これにつきます。 今後もエンジニアが輝けるような場を作るために精進していきたいと思います。
関係各所の皆々様に素晴らしい機会を沢山いただけたことに感謝します。ありがとうございました。
「Devlove現場甲子園2014 日本シリーズ編」で発表してきた。 #devlove
先日開催されましたDevLOVE現場甲子園2014 日本シリーズ編 〜東西開発現場の集結〜 - DevLOVE | Doorkeeperで発表させて頂きました。 会場でのMVP投票にて1位と2票差で2位でした。投票して下さった方々、本当にありがとうございました！
発表資料をはっつけておきます。
あと、補足で社内でリーンスタートアップについて説明する機会が最近多いのでそのために作った資料ものっけときます。
ZapierでSlackを佐野ひなこちゃんで埋め尽くす #apijp
本ポストは下記のアドベントカレンダー13日の記事になります。
Web API Advent Calendar 2014 - Adventar
ところでみなさん、Zapierってご存知でしょうか？
The best apps. Better together. - Zapier
一部界隈では便利ツールとして凄く有名ですが、ご存知ではないかたのために簡単に説明いたします。 APIとAPIをコーディング無しで連携させることが出来るハブサービスになります。 Yahoo PipesとかIFTTTのようなイメージです。 ただ、連携可能なサービスがものすごく多く、300以上あります。SlackやTwitter、Instagram、Facebook、JIRA、Trello等有名どころは大抵連携できます。 Twitterでファボッたツイートを自動的にインスタペーパーに登録したりとか、そういう連携です。 あとはWebhookも出来るので、例えばTwitterで「パイルダーオン！」とツイートするとそれがCIサーバとWebhookで連動し、ビルドが開始するとか出来ます。
ということでやってみた。
左がインプットでそれを右のサービスで何かをするという構造です。プルダウンで対応している各種サービスが出て来ます。今回でいうとインプットがInstagramで、それのアウトプットがSlackになります。
それぞれ各サービスの認証を行います。
Instagram側のSearch条件の設定をします。今回はハッシュタグで #佐野ひなこ に該当するものとしました。やろうと思えばもっと細かく設定できます。どれくらいかというと、InstagramのREST APIの戻り値であれば何でも条件にすることが出来ます。
次に出力先であるSlackへの投稿設定を行います。ここでは Slackの #test というチャンネルに投稿するようにしています。また、前述しましたが、InstagramのREST APIで取得可能な値であば何でも入力アシストで候補にしてくれます。凄く便利。これ対応しているサービス300個くらいすべてこういう用な入力補完があります。Slackへの出力値として、「スタンダード解像度の画像のURL」を指定しています。
下記が便利な入力補完になります。
これで設定完了。実行すると！！！！！
佐野ひなこちゃんきたああああああああああああああああああああああああああああああああああああ！！！ かわいいいいいいいいいいいいいいいいいいいいいいい
これでInstagramの #佐野ひなこ ハッシュタグに投稿がされるたびにSlackにひなこちゃんが流れてきます。 はかどるわああああああああああああああああああああ。
便利な時代になりましたねー。
Hello Swift
Social.frameworkとAcount.framework使ってTwitter投稿とTableViewへのタイムライン取得＆表示でSwiftをハローワールドしました。
xcodeでコード補完が殆ど効かなくて苦行でした。
コードをおいときます。（実行環境はxcode6-betaなので、いつ動かなくなってもしらんです） https://github.com/i2key/HelloSwift
こんな感じね。
AndroidのBitmapを扱う際のTIPSメモ
Androidの実装をOSのバージョンが2.xの頃からしておらず最近のコーディングの仕方をキャッチアップしているので、メモを残して行きます。
- 画像キャッシュ
- メモリキャッシュ
- ディスクキャッシュ
- 大きなBitmapをメモリに読み込むときに気をつけること
- inPreferredConfigで画像の質を下げメモリ使用量を減らす
- inPurgeableでGC時に解放されるようにする
- inJustDecodeBoundsとinSampleSizeでメモリ読み込み時にメタ情報のみを先に読み込み、1/nサイズにしたものをロードする
- Bitmapオブジェクトのリサイクル
画像キャッシュ
メモリキャッシュ
Twitterのタイムラインを実装するような時に、APIレベル12以前は下記のように画像キャッシュをしていたと思います。WeakHashMapのがいいかもですが。
public class ImageCache { private static HashMap<String,SoftReference<Bitmap>> cache = new HashMap<String,SoftReference<Bitmap>>(); private ImageCache() { } public static Bitmap get(String key) { if (cache.containsKey(key)) { Log.d("cache", "cache hit!"); return cache.get(key).get(); } return null; } public static void put(String key, Bitmap image) { cache.put(key, new SoftReference<Bitmap>(image)); } public static void remove(String key){ cache.remove(key); } }
しかしながら、APIレベル12からLruCacheというものが導入されたことにより、画像キャッシュはもっぱらそっちのようです。同じクラスを書き換えてみます。
public class ImageCache { private static final int CACHE_SIZE_BASE = Build.VERSION.SDK_INT > 10 ? 5 : 1; private static final int CACHE_SIZE = CACHE_SIZE_BASE * 1024 * 1024; private static LruCache<String, Bitmap> sLruCache; static { sLruCache = new LruCache<String, Bitmap>(CACHE_SIZE) { @Override protected int sizeOf(String key, Bitmap value) { return value.getRowBytes() * value.getHeight(); } }; } private ImageCache() { } public static Bitmap get(String key) { return sLruCache.get(key); } public static void put(String key, Bitmap bitmap) { if (get(key) == null) { sLruCache.put(key, bitmap); } } public static void remove(String key) { sLruCache.remove(key); } }
ディスクキャッシュ
GoogleがDiskLruCacheのサンプルコードを公開しています。こちらを参考にしましょう。
http://developer.android.com/training/displaying-bitmaps/cache-bitmap.html Use a Disk Cache The sample code of this class uses a DiskLruCache implementation that is pulled from the Android source. Here’s updated example code that adds a disk cache in addition to the existing memory cache:
大きなBitmapをメモリに読み込むときに気をつけること
写真系のアプリを作っていて画像をメモリに読み込むことが多いのですが、何も考えずに作るとすぐメモりが一杯になり落ちる（OutOfMemory）。そんなときの対策。
BitmapFactory.Optionsでいろいろやりくりする
http://developer.android.com/reference/android/graphics/BitmapFactory.Options.html
inPreferredConfigで画像の質を下げメモリ使用量を減らす
ARGB_8888からRGB_565にすると大体メモリは半分くらいになる。
http://developer.android.com/reference/android/graphics/Bitmap.Config.html#ARGB_8888
| EnumValue | Desc |
|---|---|
| ALPHA_8 | Alphaのみ8bit |
| ARGB_4444 | A,R,G,Bそれぞれ4bit ※クオリティがPoorという理由でAPIレベル13から非推奨 |
| ARGB_8888 | A,R,G,Bそれぞれ8bit |
| RGB_565 | R,G,Bを5,6,5bit |
inPurgeableでGC時に解放されるようにする
decodeFileやdecodeResourceをするときに指定しておくと、ここで生成されたBitmapはAndroid上のメモリが足りなくなった場合に解放されるようになります。
inJustDecodeBoundsとinSampleSizeでメモリ読み込み時にメタ情報のみを先に読み込み、1/nサイズにしたものをロードする
Googleの公式ページに乗っています。
http://developer.android.com/training/displaying-bitmaps/load-bitmap.html
Setting the inJustDecodeBounds property to true while decoding avoids memory allocation, returning null for the bitmap object
下記のように、inJustDecodeBounds = trueにすることでDecode時にメモリに画像がアロケートされるのを防ぐことができるようです。
BitmapFactory.Options options = new BitmapFactory.Options(); options.inJustDecodeBounds = true; BitmapFactory.decodeResource(getResources(), R.id.myimage, options);
これで、まずは画像のメタ情報(縦横幅等)のみ取得し、画像を何分の1にリサイズして取得するかを計算します。下記、calculateInSampleSizeメソッド参照。 そこで取得したinSampleSizeをOptions.inSampleSizeにセットすることで、次にDeocodeするタイミングで1/inSamplesizeにリサイズされた画像データがメモリにロードされます。 コードは以下。（Google本家サイトから引用）
public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId, int reqWidth, int reqHeight) { // First decode with inJustDecodeBounds=true to check dimensions final BitmapFactory.Options options = new BitmapFactory.Options(); options.inJustDecodeBounds = true; BitmapFactory.decodeResource(res, resId, options); // Calculate inSampleSize options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight); // Decode bitmap with inSampleSize set options.inJustDecodeBounds = false; return BitmapFactory.decodeResource(res, resId, options); } public static int calculateInSampleSize( BitmapFactory.Options options, int reqWidth, int reqHeight) { // Raw height and width of image final int height = options.outHeight; final int width = options.outWidth; int inSampleSize = 1; if (height > reqHeight || width > reqWidth) { final int halfHeight = height / 2; final int halfWidth = width / 2; // Calculate the largest inSampleSize value that is a power of 2 and keeps both // height and width larger than the requested height and width. while ((halfHeight / inSampleSize) > reqHeight && (halfWidth / inSampleSize) > reqWidth) { inSampleSize *= 2; } } return inSampleSize; }
Bitmapオブジェクトのリサイクル
Bitmapオブジェクトを使う場合は、使い終わったらrecycleをすること。これをしないとメモリ上から解放されない。これはBitmapFactoryでdecodeする際の実装が、2.x系ではNativeHeap領域に画像メモリを確保するため、それを解放するための明示的なコールになる（3系からはJaveHeap領域に画像メモリを確保するようになった）。
つまり、Bitmapオブジェクトのメモリ解放処理は、DalvikのGCとC++レイヤでのdeallocの併用なので、recycleメソッドで明示的に教えてあげないとダメという理解。(間違ってたら教えて下さい・・・）
http://developer.android.com/reference/android/graphics/Bitmap.html#recycle()
コードでは下記のようにリサイクル。
//インスタンス化 Bitmap bitmap = BitmapFactory.decodeXXXXX(); //解放 if(bitmap != null){ bitmap.recycle(); bitmap = null; } //もっかい使う if(bitmap.isRecycled()){ bitmap = BitmapFactory.decodeXXXXXX() }
Play2.1.3でplay testをしてもテストを認識してくれない不具合について
Play2.1.3 Javaで発生したけど、こうするとなおるよ。Play2.1.3 Scalaはしらぬ。
@kara_d さんに教えてもらたのでメモ。
Build.scalaのmainに以下を追加
testOptions in Test ~= { args =>
for {
arg <- args
val ta: Tests.Argument = arg.asInstanceOf[Tests.Argument]
val newArg = if(ta.framework == Some(TestFrameworks.JUnit)) ta.copy(args = List.empty[String]) else ta
} yield newArg
}
こんな感じ
val main = play.Project(appName, appVersion, appDependencies).settings( // Add your own project settings here javaOptions in Test ++= Seq("-Xmx1024m","-XX:MaxPermSize=128m", "-Dfile.encoding=UTF-8", "-Dconfig.file=conf/application_dev.conf"), testOptions in Test ~= { args => for { arg <- args val ta: Tests.Argument = arg.asInstanceOf[Tests.Argument] val newArg = if(ta.framework == Some(TestFrameworks.JUnit)) ta.copy(args = List.empty[String]) else ta } yield newArg } )
