2017年11月18日土曜日

「秋のJavaScript祭 in mixi 2017」に参加しました


知らなかったことも色々とあって、とてもよい勉強会でした。新しく知ったキーワードはちゃんと調べなければ!

p5.jsによるサウンドパフォーマンス
Processing的に書いたコードを実行できるJavaScriptライブラリ「p5.js」は、グラフィカルな表現を簡単に表現できるだけでなく、p5.soundライブラリを使うことで、音楽的な表現も手軽に実現できます。
JavaScriptでの表現では、音が扱われることはあまり多くないように思いますが、p5.jsを使ったサウンドパフォーマンスを通じて、楽しみながら、音のプログラミングへのきっかけになればと思います。
Webサイト 佐藤 好彦
iPadを動かしならが音の高低などを変えるデモからはじまって、ノイズなMIDIなど様々な演奏をキーボードで。もはや、Webで楽器がつくれる時代に。

演奏は次のサイトで試せる!

Nuxt.jsで変わる開発フローとUniversal JavaScriptのイマ
Vue.js で作られたフロントエンド開発のフレームワーク Nuxt.js の正式版がいよいよ公開されようとしています。
ここ1年ほど、徐々に実例が増えてきたサーバーサイドレンダリング。そのサーバーサイドレンダリングを簡単に行うことができ、かつフロントエンドとサーバーサイドレンダリングを共通のコードで動かすことが可能な「Universal」なSPAを開発する第一歩となればと思います。
花谷 拓磨
HTML5Experts.jpでNuxt.jsの基本を紹介。今日は概念的な話。Isomorphicと呼ばれていた概念が、Universalに形を変えた。今はSSR(Server Side Rendering)は自作しないことが多い。React向けのSSRエンジンとしNEXT.jsが、Vue向けのSSRエンジンとしてNuxt.jsがでた。これらを使うと、コマンド一発でSSRできる。SSRは作るモノから自然とついてくるモノに。

Nuxt.jsはSSRのためだけのものではない。Babel、webpackなんかの面倒な作業をまとめてやってくれる。starter-templateも充実。SPAを静的サイトとして書き出しすこともできる。SPAのヤクの毛刈り、SEO対策などの面倒な問題を解決してくれる。

Vueの開発パターンの統一、静的サイトジェネレータの必要性、SEO対策を解決。Nuxtによって、コーダー的なWeb屋もSPAエンジニアもどちらもハッピーになる。

three.js基礎
ブラウザだけで本格的な3D表現ができる、threejsについて話します。はじめにthree.js公式のhello worldを教材として、必要となる基本的な考え方を説明します。次に自作モデル読み込み方法、テクスチャアニメーション、HUDレイヤ作成等のthree.jsのTIPSを紹介します。
株式会社オープンストリーム 竹内 佑介
立体がくるくる回るHello World的なコードでさえ複雑。しかし、難しく見えるのは3D特有の概念を知らないから。Render、Camera、Scene、Mesh、Geometry、Materialの6つの概念。

これがわかると、難しくみえたコードも、6つの概念を初期化とrequestAnimationFrameを使った無限ループだけ。

キャラクターのアニメーション、画面を動かしても固定にするゲージなど、各種Tipsは以下のサンプルで。

ゼロから始める? Service Worker
Webkit の Indevelop 事件以来、Service Worker に希望が持てるようになりました。Service Worker で何ができるのか、基本的な機能や挙動から導入の際の注意などをお話します。
株式会社 Nagisa 宮崎優太郎

Service Workerはブラウザとサーバーの間に位置する。主にCacheやWeb Pushで使われる。同一オリジンのスクリプト、HTTPSが必要がある。

ライフサイクル。Resister, Installed, Activatedで一度止まる。2回目のアクセスから有効になる。初回から有効にするには、clients.claim()を使う。アプリを使っている途中でふるまいが変わるおそれがあるので、なるべくならclients.claim()を使わない方がよい。

バージョンを上げるなどの条件で、Updateが走る。そこで一度止まる。理由は同じ。skip.waiting()を使うとこれもスキップできる。

Pre CacheはSWインストール時にキャッシュ。Runtime CacheはFetchイベント時にキャッシュ。これらのコードは単調なので、GoogleChrome/workboxなどのツールを使うとよい。webpackだったら、workbox-webpack-pluginなどを使うとよい。

Web Pushは、通知の送信者、受信者に加えて、Push ServerやブラウザベンダーごとのGatewayがあり、なかなか難しいので、PushWooshなどのサービスを使うことが多い。

Polymer の update に見る Web Components の過去/現在、そして未来
Polymer Summit 2017 にて Polymer 3.0 の tech プレビュー版が発表/公開されました。そこで見えてきたのはブラウザサポートにおける Web Components 仕様の変化でした。
本セッションではそれらを含めたWeb Componentsの過去から未来まで解説します。
永和システムマネジメント
ブログ@sizuhiko
岸田 健一郎
スライド「Polymer の update に見る Web Components の過去/現在、そして未来 / jsfes-2017-autumn」

Web ComponentsはCustom Elements, Shadow DOM, HTML Templete, HTML Importsの4つの仕様からなる。これらを簡単に使えるのがPolymer。仕様が変わったりしても、Polymerを使っていれば吸収できるメリットもある。

今や8割がアプリからのアクセスでWebからのアクセスは2割のみ。それをなんとかしようとWebの人がPWAなどでがんばっている。日本では、Polymer Japanというコミュニティができた。

PolymerはHTML Importsではなく、JS Modulesを採用した。これによって、ほぼ全てのブラウザで動くことに。
最新のPolymerでは、BowerからYarn + npmに変更された。Yarnは使わなくなるかもしれない。
Polymerは他のフレームワークからも使える。Angular, Vueは問題なし。Reactは少しうまくいかないことも。

MongooseOSでJavaScript IoT事始め
MongooseOSは、マイコンに直接書き込むことのできるIoT特化型OSです。ブラウザ上でJavaScriptを使ってIoTプログラミングをすることができます。
今回はMongooseOSを使ったJavaScript IoTの紹介と、その技術を応用した実際のモノづくり事例をお話します。
オイシックスドット大地株式会社 Engineer 
篠原弘光
スライド「Mongoose OSとIFTTTでJavaScript IoT事始め / IoT with Mongoose OS and IFTTT」

IoTはハードウェア、組み込みといったイメージがある。フロントエンドの技術で手軽にIoT開発ができる。

Wi-FiとBluetoothを搭載した開発ボード(ESP32など)が3000円くらいで手に入る。また、Grove Systemというものがあり、差すだけで簡単につなげられるセンサーがたくさんある。

MongooseOSはコマンド一発で開発ボードにOSを書き込める。MongooseOSエディタでを起動すると、すぐにJavaScriptで開発ができる。

IFTTTのWebhooksをたたいて、イベントをおこす。例えば、Push Bulletというサービスにつなげば、Push通知がだせる。

RxJSで始めるリアクティブプログラミング
Angularが正式採用したことから注目を浴びている「RxJS」。RxJSは多機能で色々な事ができる反面、慣れるまで使い所が難しかったりします。今回はそんなRxJSの基本と学び方、そして使い方などのお話をいたします。
株式会社トゥーアール 
to-R
西畑 一馬
RxJSは敷居が高い。サンプルコードをみると、jQueryだと簡単なものもたくさん書かなければならないので、面倒そう。100種類位の関数があるのでそれを使いこなす必要がある。Lean RxJSというページが便利。

RxJSの利点はある程度使いこなさないとみえてこない。ただし、そこまでいくのは大変。理解するポイントは3つ。非同期、リアクティブ、データストア。

非同期は、forkJoin、concatAllなどを使う。JSでもできるが、非同期処理をうまくさばける。
リアクティブは、ストリームの値に応じて処理を実行するということ。一つのイベントで複数の処理をできるのも特徴。SPAでは1つの情報変更で多くの処理が発生。
データストアは、Angularでデータストアのために使える。

GAS(Google Apps Script)がつくりだすJavaScriptとIoTハードウェアの禁断の関係 
JSでIoTというと、Johnny-Fiveが有名です。しかし、安価なマイコンボードでは、Johnny-Fiveをその上だけで動かすことは困難で、必ず母艦となるPCなどのデバイスが必要になってきます。
そこでGASのWebAPI機能を使って、母艦のPC不要を不要にしつつ、マイコンボードへのプログラミングを最小限にして、メインのロジックをGAS上で書く手法を紹介します。
ブログ 
Twitter
ポキオ
今、WiFiが使える安価なマイコンボードがいっぱいある。Rasbrry Pi, ESpr, Nefry, ESP32など。

マイコンボードによっては母艦PCが必須に。ラズパイとJonny-FiveがあればOK。非力なマイコンボードでどうするか?

例えば、外部のサーバーからAPIでデータをとると、認証とかパースとかが大変。それを、GAS (Google Apps Script)でやるとマイコンボードはハードに関する処理だけに。GASはWeb APIを簡単につくれるのでいろいろとできる。

サンプルコード
https://github.com/pokiiio/2017-11-19_JSFES

2017年5月30日火曜日

「Mesos Meetup Tokyo #1」に参加しました


「Mesosってなに」からデモもあって初心者にとってはとてもわかりやすいMeetupで、非常に勉強になりました。資料だけでなく動画もイベントページで公開とのこと。すばらしい!

Opening、会場説明


Mesos User Groupsは世界で25都市が登録。Mesos Conなどが開催されている。
Mesos User Group Tokyoは、2ヶ月に1回位勉強会を実施予定。

Mesosは、2009年の論文からスタートし、2016年頃にコンテナ技術の発展とともに盛り上がり始めた。今、最も注目されている技術の1つ。

Mesosってなに



質問「Mesos使ったことある人?」 => 半分くらい

Apache Mesosの概要


仮想化環境のシステム管理では、クラスタのリソースを効率的に管理するのが難しい。今までは、クラスタは組めても、クラスタ個別の最適化まで。
データセンターのリソース全てを管理するのがMesos。Lunuxカーネルのリソーススケジュールと同じ原理でデータセンター全体を管理する。

Apache Mesosのメリット


これまではクラスタ個別の管理のため、リソースの有効活用に限界があったが、Mesosを使うと、データセンター全体でリソース配分ができ、データセンター全体で最適なリソース配分ができる。

Apache Mesosの生い立ち


2009年の論文がスタート。
2010年にはTwitterが使い始める。
2011年にMesosという名称になり、データセンターのリソース最適化というコンセプトになる。
2013年にMesosphereという会社が立ち上がる。
2016年にコンテナオーケストレーションが盛り上がり、その1つとしてMesosも盛り上がりはじめる。

Apache Mesosの主な特徴


http://mesos.apache.org/


  • LINEAR SCALABILITY
  • HIGH AVAILABILITY
  • CONTAINERS
  • PLUGGABLE ISOLATION
  • TWO LEVEL SCHEDULING
  • APIS
  • WEB UI
  • CROSS PLATFORM


Mesosの導入企業


airbnb, NETFLIX, UBER, Twitter, yelpなどモダンなサービスの多くでは既に採用されている。

Apache Mesosのアーキテクチャー


基本はこの3つ。

  • Mesos Masters
    マスターはスレーブのタスク調整と管理を行う。スレーブ、フレームワークを管理し、リソースの割り当てと最適配置を行う。冗長化構成が基本で、ZooKeeperを用いて冗長化を実現している。
  • Mesos Slaves
    スレーブはどれだけタスクを処理できるかをマスタに報告し、マスタからの要求に応じてタスクを実行する。タスクの1つ1つをコンテナ化して実行するため、コンテナオーケストレーションの技術と言われることがある。
  • Framework
    ユーザーが利用するインターフェイス。SchedulerとExecutorで構成される。SchedulerはMesosマスターへのJobの登録を担当し、オファーを処理。Executorはタスクをs実行するスレーブ上のプログラム、コマンドなど。DevOps tooling, Long Running Services, Mechine Learning, Big Data Processing, Batch Scheduling, Data Storageなどの分野で多くのツールがMesosに対応しており、Mesosのフレームワークとして用いることができる。


重要なフレームワーク



  • Marathon
    長期実行アプリを起動するよう設計されたフレームワークの1つ。Mesosを使うならMarathonも使うというくらい定番。コンテナオーケストレーションには必須。


  • Chronos
    バッチアプリを起動するように設計されたフレームワークの1つ。Airbnbによってcronの代わりに開発されたフレームワーク。

Mesosphere DCOS


Mesosをカーネルとするならば、MesosphereはデータセンターOS。Mesosの上にMesos SDK, Marathon, Chronosが乗っている。MEsosphere Enterprise DCOSは、Enterprise製品としてのMesosのディストリビューション。
Mesos単体ではカーネルレベルなので活用が難しい。MesosphereにはOSS版もある。

MesosとDCOSで実現できるあんなことこんなこと


Mesosのデモ。
MesosはThoughtWorks Tech Radar Vol.16でも紹介されている。

AWSからDC/OSをインストール


https://dcos.io/install から。
入力項目はほとんどない。お金がかかるので注意。

クラスタ環境へのアクセス方法いろいろ


ブラウザからのアクセスが簡単。慣れてくるとCLIが便利。

サービスの起動方法いろいろ

  • App JSON
    JSONでサービスを定義してコマンド1発で起動できる。
  • Universe
    GUIでパッケージを選択して簡単に起動できる。

コマンド1発でAzure上にDC/OS環境を作る方法


https://www.slideshare.net/ToruMakabe/1azuredcos

Azure上にDC/OS環境を作るデモ。
先程のプレゼンでAWSは15分だったけど、Azureはコマンド1発でいける。10分以内でできる。 => 今回は7分41秒で成功!

Azure Container ServiceはIaaS+。Managed PaaSではない。インフラとDC/OSの環境構築を楽に早く作る仕組み。DC/OS、Kubermetes、Docker Swarmを選択可能。




Mesos・DCOS Deepdive(English)


データセンターは、ハード、OS、アプリという単純な構造から変化している。マイクロサービスによって柔軟で、効率的で、頑強で、個別にスケールできるより複雑な構造になっている。アプリの言語の種類もバージョンも違う。全てがコンテナの上で動く。

データ処理は、バッチ、マイクロバッチ、イベントプロセッシングと変化している。イベントプロセッシングはマイクロ秒のレベルの高速処理。

Apache MesosはTwitterが採用し、今ではApacheのトッププロジェクトで、多くの先端企業が採用している。

DC/OSはモダン分散アプリケーションを可能にする。コンテナ上のマイクロサービスとビッグデータ分析を実現する。

ユースケースの1つ。esriはScalaでイベントソーシング、Kafkaでメッセージブローカー、Spark、Elasticsearch、JavaScriptの地図アプリというスタックで処理をしている。=> デモ

設定変更、バイナリの変更、クラスターのメンテナンス(バックアップ、リストア、再起動)などを管理することができる。

多くのコンテナで動くサービスにおける、モニタリング、ログ分析、アップグレード、障害対応、トラブルシューティングなどの課題に対処できる。

DC/OSの中のクラスターは他のクラスターからアクセス可能な仮想IPを持つ。DNSが仮想IPを指し示すことでServieに名前でアクセスできる 。

LT: おぷすた開発者がDC/OS on OpenSUSEでMesosに入門してみた的ななにか


Meoss, DC/OSをOpenSUSE(Linux)上で動かす。OpenSUSE, VirtualBox, Vagrant, DC/OSとインストール。 いろいろ大変だけど、なんとか動くよ。

LT: RancherでMesosクラスタをデプロイしてみる的ななにか


Rancherを使ってMesosを簡単に立ち上げるデモ。Rancherはコンテナ環境を管理するためのOSS。RancherでGUIでコンテナを立ち上げて、監視もできる。
Rancher ♡ Mesos

LT: サービスカタログと夏フェスにまつわるなにか


https://www.slideshare.net/cyberblackvoom/ranchermesosmarathon?next_slideshow=1

初心者が、Mesosを学ぶための情報紹介。

  1. Mesosってなに?のリンク集。
  2. RancherとMesos。Rancherにはオーケストレーション環境を簡単に構築できる環境テンプレートがある。Mesosも。本家のカタログもコミュニティのカタログもある。
  3. Rancher, Mesos, Marathonをつくる手順。



2017年2月23日木曜日

「Polymer.co-edo meetup #1」に参加しました


Reactでアプリつくって、最初はよかったんだけど段々と「うーん」となって、Vue.jsやRiotがいいと聞いてさわってみても「うーん」で、Angular2はTypeScriptが苦手なので「うーん」で、そういえば、昔Polymerさわったなぁと思っていたらちょうど勉強会があったので参加してみました。
結果、とても好きになりました。なんでPolymer0.5のときイマイチと思ったのかなぁ。


Extensible Web


Polymerの説明の前に主催者の岸田さんからExtensible Webの話がありました。
その詳細はオリジナルをみてもらうとして、私は次のムーブメントだと理解しています。

Web 標準化団体がWebをつくるのではなく、全てのエンジニアでWebをつくっていこう

これまでも、jQueryなど外部のライブラリで実現されていたことが標準仕様に取り込まれてきた歴史はあるけれど、はっきりと変えていこうという意思表示に美しさを感じます。


Web Components / コンポーネント指向


Extensible Webの次はWeb Components。
Web Componentsが何かというのはW3Cの仕様のとおりということになります。
Web Componentsはコンポーネント指向の仕様で、Webのコンポーネント指向について、私は次のように理解しています。

開発者が(HTMLとCSSとJSを使って)新しいコンポーネント(タグ)を定義して再利用できるようにする

この考えにあてはめると、ReactもVue.jsもRiotもコンポーネント指向です。
でも、これらはW3CのWeb Components仕様に準拠しているわけではなく、準拠しているものには、MozillaのX-TagsやGoogleのPolymerなどがあります。
X-TagsとPolymerを比べると、Polymerの方はGoogleらしく、Material Design、Google API、Progressive Web Appsを取り入れたものがすぐ使えるという特徴があります。


Progressive Web Apps


Progressive Web Appsは、Googleが提唱しているWebアプリです。
仕様がある訳ではないようですが、私は次のとおり理解しています。

ネイティブアプリと同じように、インストールできて、ホームから素早く起動できて、オフラインでも使えて、プッシュ通知もできるなどの特徴を兼ね備えたWebアプリ

Googleのサイトに従ってやれば、できなくないですが、Polymerを使うとPWAが簡単にできるとのこと。


Polymerを使ってみる


岸田さんがGoogleのCodelabsに登録されているチュートリアルのうち、 Polymerに関連したものピックアップしてくれています。
今回は「コーディングなしでGoogleMapを作ってみよう」をやってみました。

Polymerには、すぐに使えるWeb Componentsが用意されているので、HTMLとCSSがわかれば、JSを使わなくてもある程度のことができてしまいます。
その他のWeb Componentsも使えて、WEBCOMPONENTS.orgでは開発者が自作のweb componentsを公開できるそう。


Polymer.co-edo meetupは定期的に開催するそうだし、Polymer 2.0は2017年の第1クオーターのリリースを目指しているそうなので、今年中に何かアプリをつくってみようと思います。

2016年12月19日月曜日

優秀なエンジニアになる方法

最近、私なりに優秀なエンジニアになる方法がみえてきた。
優秀なエンジニアといってもレベルはいろいろあるけれど、ここでは、仕事をする中で、複数の人から「あの人は優秀」と言ってもらえるという基準で考えてほしい。

どれも、普通のことだけど、この普通のことを続けるかどうかで大きな差が生まれるのだと思う。
大切なプロジェクトから去るにあたり、後を任せる若い2人に向けてこの気づきをシェアしておく。

技術書を読む


昔、先輩にこんなことを言われたことがあった。

気になった本があったらすぐ買え。
積読でもいい、わからなくてもいい、はずれでもいい。
後から役に立つものもあるし、ずっと役に立たないものもある。
それでも気にせず、気になった本があったらすぐ買え。 

結局、本が一番学習のコスパがいい。
若くてお金がないうちは、ハズレの本を買ってしまうと損をしたと思ってしまうかもしれないけれど、トータルで考えると決して損をすることはない。

勉強会にでる


勉強会にでるだけで優秀になるということはない。
勉強会のよいところは、新しい技術のキーワードをひろえたり、ファーストステップを楽しくクリアできることと、社外の優秀なエンジニアとのネットワークが築けることだ。
単純に、楽しいのでモチベーションがあがるという効果もある。

知識があまりないうちは、有名そうな勉強会やカンファレンスにでてキーワードを拾ってくるだけでいい。
ハンズオン勉強会があれば、積極的にでるといい。
新しい技術を学ぶときは、ハンズオン勉強会にでると、変なところでつまずいて嫌にならないのでとてもおすすめだ。
まずは、勉強会の情報をチェックできるようにすることだ(dots.とかを使って)。

実際にサービスやツールをつくってみる


学んだことを活かして、小さくてもいいから、サービスやツールを自分でつくってみると、世界が広がる。
何をつくっていいのかわからないのなら、ハッカソンにでてみるのがおすすめだ。
初心者歓迎のハッカソン(はじめてのハッカソンとか)もあるので、臆せずに飛び込むといい。

自分で何か思いついたら、大したものでなくても、似たようなものがあっても、気にせずにとにかくつくってみる。
学習という意味では、車輪の再発明は決して悪くない。
必ず得るものがある。

コミュニティにとびこんでみる(ウィークタイズ)


興味をもって学んでいくと、気になるコミュニティがでてくる。
そのときは、自分の実力なんて気にせずにとにかくドアをノックしよう。
多くの場合、優しく受け入れてくれるし、強く束縛されることもない。
最近では、こういった弱い結びつき(ウィークタイズ)がとても重要だということがわかってきているらしい。

ワークライフシナジー


そんなことをやっていると、ただでさえ忙しいのにプライベートの時間がなくなってしまう。
ワークライフバランスといって、ワークとライフを分けてバランスをとるのはエンジニアには難しい。
その代わり、エンジニアはワークライフシナジーをしやすい。
今やITはライフと密着しているので、エンジニアとして成長すると、ハッカソンにでてライフを楽しくするアプリをつくったり、自分で自分の趣味に役立つアプリをつくったりできる。
ワークでもない、ライフでもない、ワークとライフが混ざりあった領域をつくって楽しめるエンジニアになるのが一番だと思う。

2016年9月4日日曜日

「HTML5 Conference」に参加しました


カンファレンスに参加しただけで新しい知識や技術が身についたなんてことはないけれど、新しい技術のキーワードがインプットできて、色々な刺激を受けることができました。
講演資料を探していたら、まとめを発見。

http://qiita.com/hidenorly/items/40ac3e9dbf757ce4df52

私が参加したのは次のセッション。

Reactの最新動向とベストプラクティス
小林徹(株式会社TOLOT)

丁寧に説明という感じではなく、キーワードと簡単な説明だけで歴史や特徴から最新動向まで幅広にという感じでした。
基礎については、これまで何となくわかっていたことを体系的に説明してもらえたので、自分の頭の中が整理されました。
知らなかったことは、聞いてもよくわからなかったけど、キーワードはインプットできました。

講演資料
https://speakerdeck.com/koba04/reactfalsezui-xin-dong-xiang-tobesutopurakuteisu

AudioとガジェットをWebで遊ぶ
河合良哉(Yamaha Corporation of America)

普通に音の再生や録音をする話なのかと思っていたら、シンセサイザー的なことが比較的に簡単にできるという、もっと面白い話でした。
また、音楽だけでなく、Bluetoothの話もあって飽きさせない。
自分としては、実際に使うシーンは浮かばないけど、簡単にシンセサイザーみたいなことができて、とてもおもしろかった。

講演資料
https://ryoyakawai.github.io/html5conference2016/index.html

Material Design を使ったマルチデバイスに対応するデザインの作り方
鈴木 拓生(Google)

Material Designの基本的な考え方から、フレームワーク、ツールまでの一通りをわかりやすく解説してくれました。
ご本人もおっしゃっていたとおり、内容は[Google Design](https://design.google.com/)に全てあるし、基本なんだけど、対面で説明してもらえると腹落ち具合が違う。
もしかしたら勘違いなのかもしれないけど、少なくともやってみようというモチベーションはサイトをみるよりも圧倒的。
とてもよいセッションでした。

Webアプリケーションにおける機械学習活用の基礎
中井 悦司(Google)

Linuxで有名な中井さんがなんと2年前に機械学習に興味を持ち、今はGoogleにいらっしゃるとのこと。
できる人は何をやってもできてしまうのか。。。
データを2種類にわけるような基本的な機械学習の原理から、顔認識の方法まで解説されました。
手書きの数字の認識の機械学習の説明を交えたデモが面白く、機械学習に非常に興味が持てました。
tensor flowについては結局よくわからなかったので、紹介された本をポチりました。
おまけのGoogleの顔認識APIはすぐにでも使えそう。

講演資料
http://pt.slideshare.net/enakai/web-65150969

Progressive Web Apps の導入基礎
片山 雄介(株式会社リクルート住まいカンパニー)

PWAってWebアプリでもネイティブアプリのレベルのUXにというくらいでしか理解できていなくて、実際に使う事例はとてもためになった。
もう、すぐにでも使いたい!
紹介されたSumoで使っている機能の事例は次の3つ。

  • Add to Home Screen
  • Push Notification
  • Offline Cache

特に3つめがメインで、次のような紹介がありました。

オフラインクックブック

※オフラインでWebアプリを使う際のベストプラクティス

App Shellアーキテクチャ

※テンプレートは全てキャッシュして、データだけネットワークにとりにいくアーキテクチャ





2015年12月28日月曜日

「トマトHack!!」に参加しました



少しハッカソン疲れして、最近はハッカソンお休み中だったのですが、トマト好きとしては出ずにいられないということで参加してきました。
参加して、ホンダの小林三郎(エアバックの開発者)の次の2つの言葉を思い出しました。

「イノベーションは若者からしか生まれない」
「スペシャリストはイノベーションリーダーにはなれない」

私の場合、このアイディア、この時間、このメンバーならここまでは固くて、このあたりにリスクがあると、無意識に計算してしまいます。
それが無意識のブレーキになって突き抜けられない。
突き抜け感を得られるまで、これからもちょいちょいハッカソンに参加しようと思いました。

1日目 アイディアソン



  • 午前:オリエンテーション、キーノートスピーチ、技術紹介、食材紹介
  • 午後:課題討議、課題解決のアイディアだし、ピッチ、チーミング
  • その後、Hack!、その後、トマト料理で懇親会

という流れ。

アイディアソン


アイディアがあまりソフトウェアよりではなかったのが印象的でした。

優勝したチームのアイディアはトマト売り場に、その日のトマト情報をしゃべって教えてくれるトマト大使キャラクターをつくるというもの。

私が参加したのは、トマト王子ことトマト生産者大畑さんのアイディア。
数ある高知のブランドトマトをコンプリートするために、食べて記録したり、現地にいってスタンプラリー的なことをするアプリ。
アイディア交換のときにお話した自分のアイディアを取り入れてくれていたので迷わずこのチームに参加しました。

チーム構成


リーダー(トマト生産者)
プランナー:1名
エンジニア:2名(私含む)
エンジニア兼料理:1名

最終的なアイディア


高知トマト八十八箇所 〜トマト博士の通った道〜

  • 地図のうえに、高知のブランドトマト約50種類があって、タップするとコメントや写真を記録できる
  • 各ブランドトマトごとに、記録するとレベル1、誰かにシェアするとレベル2になる
  • 1種類のトマトでもレベル2になると、御朱印帳がもらえる
  • 高知のブランドトマト(約50種類)をすべてレベル3にすると、高知県がトマト博士に認定してくれる


1日目のHack


開発方針は次のとおり。


  • 地図はGoogle Map
  • バックエンドはNiftyのmBaaS
  • HTML5/CSS3/JavaScriptでつくってMonacaでモバイルアプリに変換


もう1名のエンジニアがネイティブのiOSアプリの方が得意だったのだけど、私ができないのでHTML5にしてもらいました。

1日目でmBaaSからとってきた情報をGoogle Map上にのせるところまでつくり、MonacaでiOSアプリに変換するところまで完成。
並行して、カメラで写真をとって、Data URIに変換する(mBaaS上に保存するため)ことろも完成。
Google Map上にD3.jsで画像をのせるところに時間がかかりましたが、想定の範囲内だったのでOK。
懇親会の後、うちに帰って、画像をクリックしてモーダル画面を起動してコメントや写真をmBaaSにアップするところをつくりました。


2日目 クック&ハッカソン


2日目は作業が14:00までと短いので、機能を追加していくよりも、デザインを少し調整したり、料理をして実際にアプリを使ってみたいなぁと思っていました。
ところが、バグがいくつかみつかり、バグFixに時間が。。。
さらに、MonacaでiOSアプリに変換したら、まったく動かなくなっている!
最終的にはMonacaで1からプロジェクトをつくりなおして、解決しましたが、かなり時間のロスがありました。

並行してメンバーがトマトパンやおいしいトマト料理を作ってくれていたのですが、ほとんど会話ができませんでした。
2日目はもう少しメンバーと会話しながらアプリのコンセプトを成長させたかった。。。

発表・審査・表彰


発表はパワポではなく、模造紙くらいの大きさのポストイットで。
あえてアナログの紙でプレゼンというのもよかったですし、メッセージの伝え方もうまくて、同じチームなのに聞いていて楽しかったです。
デモもとどこおりなくでき、審査員の反応もまずまず。
アプリづくりという意味では一番しっかりしていると思ったので、もしかしたら賞も狙えるかもと思いましたが、残念ながら何も賞はもらえませんでした。

優勝したチームは、実際のトマトにプロジェクションマッピングで顔をつけて、トマトの紹介をするというもの。
凝った作りこみはないけれど、実際のものが目の前にあってインパクトがあるし、かわいいし、審査員が言っていたように、すぐにでも全国のスーパーで使えるので優勝は納得。

感想


1日目の懇親会やHack中に生のトマトやトマト料理をたくさん食べられたので、トマト好きとしては、本当に楽しめました。
日本酒にあうトマト料理のアイディアも考えていたので、それを試せなかったのは少し残念ですが。
技術的には、mBaaSとMonacaを使って短時間でスマホアプリをつくるのは良い経験になりました。
反省点としては、開発にもっと非エンジニアを巻き込んで、自分の壁を壊してもらって、もっとおもしろいものにしていく必要があると感じました。

身内へのダメ出し


とてもよいハッカソンだったのだけど、身内が主催をしているので、あえてダメ出ししてみます。

説明が長い


高知、ハッカソン、トマトと内容自体が多いのでしかたないのかもしれませんが、ギュッと凝縮してほしかったです。
あえて全部伝えずに、Hackの最中にコミュニケーションとってもらうようにしてもよかったのではないでしょうか。

説明がくどい


コンサルの職業病だと思いますが、手法などの説明がくどかったです。
価値は説明をうけて感じるものではなくて、やってみて感じるものなので、説明は最小限でよかったのではないでしょうか。
やった後に、あれってどんな手法なのかを参加者から聞かれるくらいが一番ちょうどいいし、かっこいいと個人的には思います。

2015年9月8日火曜日

とあるソフトウェア開発者と品質管理者の戦い

ソフトウェア開発は、製造業と違って品質データのバラつき大きく、定量的品質データ分析が適用しにくい業界です。
そのため、うまく品質管理ができていないことがよくあります。
以下は、私の体験をもとにしたフィクションです。



キャラクター


高見
品質管理担当者。
ソフトウェア開発の仕事をしているが、設計もプログラミングもできない。協力会社に発注してルールを守らせるのが主な仕事。



板垣
開発者。
意味がわからないルールを強制されるのが大嫌い。






戦い(その1)〜いい具合の指標値!?〜




板垣さん、お客様がコンサルタント会社の品質指標はダメだら考えてほしいって言われたので、考えてみました。
とりあえず、基本設計工程分だけみてもらえませんか
かなり、いい具合だと思いますよ。




<基本設計工程品質指標>
項目下限指標値上限
レビュー密度(人時/ページ)-20%0.3+20%
欠陥密度(件/ページ)-20%0.3+20%
※数値はフィクションです。

<選定方法>
・類似プロジェクト2つの平均値を入手。
・その2つの間をとって指標値を設定。
・そこから+-20%で、2プロジェクトの平均値が入るので、上下限は+-20%に設定。




(どこがいい具合!?)
いや、ダメでしょう。これじゃ品質分析できないですよ。
そもそも、この上下限に何%のデータが入る想定ですか?
上下限に入らなかった場合はどのようなアクションを想定していますか?





(うるせーやつだ)
いきなり、そんなに質問されても困りますね。
何%のデータが入るかとかデータ分析のことは指標値を決めた後に考えます




一度に色々言い過ぎましたね。順番にいきましょう。
上下限外はOK/NGの判断ではなく、現物・現場・現実の確認を効率的に実施する(対象絞り込み)ための道具という認識でよいですか。





(うるせーな、何でもいいよ)
そうですね。その認識です。






そうですよね。
ソフトウェア開発のデータはバラつきが大きいので。
ちなみに、同一仕様、同一プロセス、同一開発規約、同程度のスキルのチームで多数の開発を実施(12開発Gr)しても、品質データは大きくばらついたというデータもあるんですよ。





(しらねーよ)
へー、そうなんですか。勉強になります。






次に、この上下限に何%のデータが入るかです。
IPAが毎年品質データを出しているので、それをみてみましょう。
とりあえず、下限:第1四分位、指標値:中央値、上限:第3四分位として、ご提示の値と比較してみましょう





SEC BOOKS:ソフトウェア開発データ白書2014-2015
<基本設計工程品質指標>
※下限:第1四分位、指標値:中央値、上限:第3四分位
※カッコ書きは品質管理者の提示値
項目下限指標値上限
レビュー密度(人時/ページ)0.074
(0.24)
0.243
(0.30)
3.636
(0.36)
欠陥密度(件/ページ)0.099
(0.24)
0.250
(0.3)
0.514
(0.36)





IPAゆるいですねー。
ところで、第1四分位、第3四分位って何ですか?






例えば、データが100個あったときに、小さい方から25番目のデータが第1四分位、50番目が中央値、75番目が第3四分位です。
つまり、ゆるいとおっしゃっいましたが、統計的にはこの上下限に50%しかはいりません。






こんなにゆるい範囲でたったの半分ですか!?
IPAのデータって3581プロジェクト分も集めてるからデータがばらついてるんじゃないですか?




逆ですよ。
少なくとも、たった2つの標本からつくったデータよりは信頼できます。







わかりました。
他の方の意見も踏まえて、修正します。








戦い(その2)〜混ぜるな危険!〜




他の方の意見も踏まえて、次のように変えてみました。
今度はどうでしょうか。






<基本設計工程品質指標>
項目下限指標値上限
レビュー密度(人時/ページ)0.10.33.0
欠陥密度(件/ページ)0.10.30.5

<選定方法>
・品質管理者提示値、IPAの数値、お客様のコンサルタントの提示値が近い場合は、品質管理者提示値を採用。
・品質管理者提示値、IPAの数値、お客様のコンサルタントの提示値が離れている場合は、それらの平均値を採用。



最悪ですね。
統計的土台があってはじめて品質分析できます。
数値をいじって、統計的な意味付けをなくしてしまったら品質分析できませんよ。




(本当にうるさいやつだ、早く決めたいんだよ)
指標値と品質分析方法をリンクさせる意味がわかりません。






以前もいいましたが、「上下限外はOK/NGの判断ではなく、現物・現場・現実の確認を効率的に実施する(対象絞り込み)ための道具」です。
本当は全量をしっかり分析するのがベストですが、それが難しいので怪しいところを探すための言わばソナーなんです。




それはわかりました。







例えば、レビュー密度を横軸、欠陥密度を縦軸にとったとき、下限、上限を決めると、次のように9つの領域にわけられます。
レビュー密度と欠陥密度に関係がなく、下限が第1四分位、上限が第3四分位なら、平均的には、7の領域には1/4 * 1/4 = 1/16のデータが入ると考えられます









なるほど。
担当プロジェクトのデータをあてはめて、例えば7の領域に1/16より多くのデータがあるとおかしいということですね





おかしいかどうかはわかりません。
そのプロジェクトの特性上、そうなるのが自然かもしれませんから。
ですから、やはり、現物・現場・現実の確認が必要なんです。
データはあくまでソナーです。





難しいですね。






どういう意味で難しいと言っているのかわかりませんが、定量的品質分析は簡単ではありません。
例えば、どれくらい差があったら有意な差といえるのかは、本当は検定しなければわかりませんし





(あー、小難しくてめんどくさい)
で、話を戻して、何で私の指標値の案はダメなんですか?







数値を色々混ぜてしまったので、さっきの例で言えば「7の領域には平均的にはどのくらいのデータは入るはずか」というのがわからなくなってしまいます。
これはあくまで一例で他の分析も同様にできなくなってしまいます。





(よくわかんねーな、めんどくせー)
わかりました。
とにかく早く指標値を決めないとまずいので、板垣さんのご提案に従ってIPAのデータをそのまま採用しますよ。




別にIPAのデータを推しているわけじゃないですよ。
例えば、上下限は第1四分位、第3四分位でいいのかとか、対数変換しないと正規分布にならないとか、そういうことは考えてますか?
どのように分析するのかを考えないと指標値も決められないということをわかってほしいんです。




(めんどくせー)
わかりました。勉強します
とにかく、指標値は承認してください。






おしまい(続かない)


イラストは いらすとや の素材を使っています。