エンジニア向け #マインドフルネス 入門
社内でマインドフルネスの30分ワークショップをやったのでメモとして残しておきます。 本当は長期にわたる研修なので、こんな簡単な話ではありません。
以下の様な禅語があります。
- 調身
- 調息
- 調心
正しい姿勢を保ち、正しい呼吸法で坐禅を組めるようになれば、心身ともに整うという意味です。 このように、本来は、正しい姿勢のとりかたに始まり、さらには、正しい睡眠のとりかたについて、食生活について、などなど、様々なことを学んで実践した上で、やっと調心(マインドフルネス)のフェーズになります。が、今回はそういうの全部すっ飛ばして要素のみを。興味を持った方へのググラビリティを提供するという意味で。
マインドフルネスって何よ。
日本でいうところの「瞑想」になります。ただし、瞑想というとどうしても伝統的な、宗教的な意味あいが入ってしまうのですが、マインドフルネスはそういうのを一旦全部除外して、サイエンスなアプローチで瞑想の効果を科学し、再現可能なものにリビルドしたものになります。なので、ある意味、瞑想の逆輸入にあたります。(ちなみに、ヨガも同じでインドのそれが、いつのまにか、先進国で科学的に意味のあるものと実証されて、いまや日本で女子力を高めるツールになっています。) 最近はGoogle等の先進的なIT企業が、生産性を最大化するための取り組みとして実践しており、実際にGoogleでマインドフルネスの講師をしているかたに全10回くらいの研修をしてもらい教えて頂きました。
マインドフルネスってどういう状態?
感情を自身によるフルマネージドな状態にすること。
そのために感情のイベントハンドラーを脳みそに実装するためのトレーニングが必要。
そして、感情の状態をハンドリングできれば、コントロールすることが可能。
最初に感情の操作の方法。次に、注意のイベントハンドリングについて説明します。
瞑想(呼吸)によって感情をコントロールする
ジョジョの波紋みたいですねwwww
目をつむってもあけててもいいので瞑想する。
ポイントは、姿勢を正すこと(ドローイン)。姿勢が悪いと肺が圧迫され、横隔膜のワークが弱まる。
すると呼吸が浅くなり、呼吸による感情コントロールの効果が弱まる。
瞑想時の呼吸には吸うときと吐くときで下記の効果がある。(血中二酸化炭素濃度に比例)
- 息を吸うとき 交換神経利用 イライラ/ネガティブ/集中(思考は浅いけど突き進むとき)
- 息を吐くとき 副交換神経利用 リラックス/ポジティブ/発散(遠い記憶と遠い記憶がつながる)
これらの時間をコントロールすることで、集中モード、発散モードの スタンスチェンジが出来る。(構えを変えて戦う格闘ゲームみたいwww)
- 息を吐く時間 < 息を吸う時間 集中突撃モード
- 息を吐く時間 > 息を吸う時間 発散クリエイティブモード
試しにやってみよう
- 目をつぶって、息を吸う時間を長め、吐く時間を短めで2〜3分くらい呼吸してみてください。 なにか、焦りのようなハラハラする感覚になりましたか?多分なってますよね。 それが、交感神経を沢山つかっている状態です。
- 逆に、息を吸う時間を短く、吐く時間を長くするとリラックス出来てきます。 これが副交換神経を利用している状態になります。
例えば、数学的な難しい問題をとくとき
最初の問題解決策を洗い出してクリエイティブに考えるときは、まずは 息を吐く時間 > 息を吸う時間 で5分間瞑想し、発散モードに。 解決策が決まり、あとはやるだけになったら、 息を吐く時間 < 息を吸う時間 で集中モードにスタンスチェンジ。
宮﨑駿氏の例が面白い。 どんな映画をつくろうか考えているときは、楽しそうにニコニコしてる。 ただ、作るものがきまったら、終始毎日イライラしている。 そうやって感情(集中・発散)のコントロールをしている。
注意のイベントハンドラーを実装する
次に自分の感情の変化をハンドリングするために、退屈な刺激、小さな刺激へ注意を向ける練習です。 同様に瞑想をしてください。瞑想中は今回は、自分の呼吸回数を数えて見てください。 タイマーで5分くらい時間を区切り、ひたすら呼吸の回数を数えてください。多分、途中で別のことを考えてしまうと思うので、それをハンドリングしてもう一度、呼吸を数えるタスクに強制的に戻してください。これを繰り返すことで、自分の注意をコントロールできるようになります。しかしながら、これはたくさんの練習を要します。今日明日では身につけられません。日々の練習が必須です。 このハンドラーが装着できると、自分の感情の変化もフックできます。
マインドフルネスの3要素
上記のようなことが全てワークしていくと、下記のマインドフルネスの3要素が満たせてきます。
- 感情の制御
I am angry ではなく I feel angry - 注意のコントロール
退屈な刺激に注意を向ける - メタ認知
注意への注意
簡単に以上がマインドフルネス入門編でした。お昼休みにでもやると午後はスッキリまちがいなし!
あとデザインさえあれば・・・を若干のお金で解決する #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
優勝作品はお馴染みのクジラ&コンテナのロゴですが。
ほかがキリンwwww
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年連続とかでは登壇出来ないルールぽいけどw)
はじまるよー! #devsumi #devsumiB pic.twitter.com/XFocsSeeUa
— Itsuki KURODA (@i2key) 2015, 2月 20
デブサミ当日は、エンジニアの大先輩(当時入社面接してもらた)の @kawanetさんや、前職の上司、先輩、同僚、大学時代の友人、勉強会コミュニティで知り合った方々、知り合いたくさんがきてくださりとても精神的にリラックスして発表することが出来ました。ありがとうございました!!!
#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() }