クライアントワークでは、いろんなものを作れ、経験にはなる。
Xcodeを使うにあたって、まずは心理的ハードルがあった。
- 毎日数時間とか、ちょっとずつやることで、ハードルが下がった。
- GUIで直せるのが良い。
- エンジニアがsketchを勉強したり、相互に歩み寄る姿勢が大事。
属人性は社内勉強会で、ワークショップしてみたり。
ビジネスとは、同じアプリを使うことで、共通言語を増やす。
- 毎日30分とか話す。
- XXアプリのYYの画面、とかって言える。
- 読んだ記事、本を紹介し合い、互いの理解を深める。
新規事業でユーザの学習コストを減らすため、一般的なアプリを使い、そのデザインを盗む。

プリプリしないアプリ開発

プリプリしないアプリ開発 from Aya Matsuda

www.slideshare.net

動画配信アプリなどの開発。

アプリのデザインは経験1年ぐらい。

人任せにするから、プリプリする。そうなる前に、デザイナが出来ること。

アプリ開発の流れ
- デザイナ・ディレクタ・システムエンジニア
画面イメージを決定する際に、システムの人間が関与する方が良い。
- イメージ決定する際に、デザイナからシステムさんにも承認を得る。
パーツ書き出し
- デザイン：パーツ受け渡し用のスプレッドシートを作る（画面ごとにタブ）
- デザイン：画面イメージをそこに貼る
- システム：欲しいパーツを書いていく（ファイル名も決める）
- デザイン：パーツ書き出し
- デザイン：基本のトンマナはシート分け、画面イメージに追記していく
- システム：確認し、問題なければ終了
アプリ実装で、デザインが確認してない。
- 毎日、作られた分を確認し続ける。

質疑応答

反省会を開き、そこで改めて相談することで、今回の解決策を思いついた。
- 次のアプリでは、今回の解決策を適用して、上手く行った。
アプリの動きについては、文字ベースや口頭で伝えている。
文字だけでなく、質問・回答しやすい状況にする。

良いUIをエンジニアに作ってもらうために、デザイナーができること

良いUIをエンジニアに作ってもらうために、デザイナーができること from 石橋啓太

www.slideshare.net

デザイン5年、フロントエンド1.5年

運用・改善をしていくサービスのUI、良いUIを作り続けることが、今回の対象。

デザイナもエンジニアも、担当領域が違うだけで、作るものは同じ。

デザイナの仕事は、PSDを作ることではない。

どう実装されているか、エンジニアが何を考え行動しているか、を知るべき。デザイナが頑張るところなのか、エンジニアが頑張るところなのか。

UIデザイナが作るのは、サービス。例：スタイルガイドを作るなど、エンジニアが使いやすいアウトプットを作る。

スタイルガイドの運用・保守はデザイナが行う＝サービス全体のデザイン。

エンジニアに無理難題を求めない
- 要求を下げるのではなく、手を取り合うこと
デザイナ語は使わない
- 抽象的な言葉ではなく、サンプルアプリを伝えたりする
Photoshop仙人にはならない
- 便利なツールがいろいろ出てくる
- 例えばsketch

質疑応答

情報共有
- 自分の見つけたものを、必要なチャンネルに共有する。
- それを相互に行う。
1つのPSDに情報を詰め込み過ぎない。

「使いやすい」だけではユーザー体験が上げられないサービスでのデザイン手法

speakerdeck.com

Material Designスタイルでプレゼン。

グラフィック→WEB/INTERACTIVE→サービス

iPhone出て早9年当時は、専門的なデザイナがおらず、エンジニアだけで作っていた。今では、UIデザイナの地位が確立され、ガイドラインが作られた。

1→2的なグロースハック系は、「使いやすい」というのが役立つ。 0→1的な新規事業では、雰囲気みたいなものが大事。

UI/UXの記事を鵜呑みにして適用しても、うまくいかない。

さんぽジスタを作るときに、「使いやすい」ではただの歩数計になってしまう。

今日の歩数：達成感・やる気を起こさせる。キャラ：「何が変か」を具体的に調整していく。背景：画像検索で世界観を知る。

自分で使ってみて、つまらなかったので、コンテンツ追加。ブラッシュアップ。

質疑応答

自分で使って、客観的に見る。
- 何か変えてみて、また使ってみる。
- 社内でターゲットになるような人に使ってみてもらう。
DeNAは、思ってることを言いやすい環境。
- 自分の作ったものに責任を持つ。
ターゲットユーザがチーム内にいない場合
- まず、インセプションデッキを作った。
- ある程度仮設を立て、作り、ユーザの動きをアナリティクスで見て、拡張していく。

これからの「フロントエンド開発」の話〜（デザイナー所属の）フロントエンドエンジニアでも知っておきたいこと〜

Ui live資料 from Ryota Iida

www.slideshare.net

認証会員基盤のエンジニアフロントエンドのチームリーダー

金沢すきま旅というのを作った。

エンジニア目線な話

UXセミナーのストーリーボードを見て衝撃を受けた。

エンジニアは、細かく検証し、問題があればすぐ修正したい。

Dockerをローカル開発環境として使う。継続的インテグレーションの流れを、デザイナにも知っておいて欲しい。

質疑応答

Dockerを布教中
- ハンズオンを開催し、体験してもらう
- GUIもあるおかげか、デザイナ側も抵抗感が少なそう
ストーリーボードの何が衝撃を受けたのか
- いままでは、完成されたワイヤーから関わっていた
- そのワイヤーに至る理由が見えるので、理解できる

フロントエンドエンジニアが、機能開発の企画オーナーとなってリードした話

speakerdeck.com

エブリスタに関わっている。 6年ぐらいあるサービス。

負債が多い状態で走り続けている状態だった。

使いづらいものを、抜本的に改善したいけど、既存文化や技術障壁を考慮する必要がある。

現状を分解する。
原因を探る。
- 「なぜ？」を問う
- →ガラケーのUIを引き継いでいた
- チームの共通認識とする
解決の方向性を定義する
- 他のアプリを参考にしたり
解決案を試作する
- プロトタイプ作ってみたり

チャンスを掴む働き方

状況を作る
- "何か"を期待して雇われている
- コアスキルを使い、チームが抱える課題・問題を解決する
- 重要なのは期待を超えること
- 圧倒的な能力を持っている必要はない
- チームの課題を、チームメンバーが感じられる状態にする
仲間に入っちゃう
- 呼ばれてないけど、MTGに入ってみる
- 他のメンバーが困ってそうな仕事を、会話してみる
- 信頼を得る→期待が生まれる

生存戦略

フロントエンドエンジニアのキャリアパスコアスキル以外のところも鍛えておく。プライベートで何かを作ってみる。

質疑応答

出来無さそうな話が流れていたら
- 自分のできるところまで分解してみる。手伝えることはいろいろありそう。
タスクのトレードオフ
- コアスキルの部分を終わらせるのが大前提
- 事前に素振りしておくことで、工数を減らして、時間を余らせる
- 上司に相談して、アサインを変える
  - 優先度をつけて、今のタスクが本当に必要なのかを問う
だれにリソース管理されている？
- 個人でタスクをアサインしている。
- 1日5hの作業をタスクとしてあてる。
  - 見積もりミスのバッファに使ったり、改善に使ったり。

パネルディスカッション

3年前との違い

与えられた情報を鵜呑みにしていたけど、そこから疑問を持つようになった
ユーザ体験だけでなく、ビジネス的な目線もついた
コアスキルへの自信がついた
受け身だったけど、今は取りに行くぐらいになってる
井の中の蛙だったのを今は知っている
言ってみたら変わることを知った

会社間で聞きたいこと

キャリアプラン
- デバイスが増えていくところに対応できるように
- デザイン→フロントでの、フロントを極めていきたい
- デザインとフロントがやりやすいチームが作れるように
- 新規事業を作るためのブランディング
- デザイナの地位を上げたい。ビジネス寄りに。
- デザイナでもコードが書けるようになりたい。コード書きたくないデザイナと繋ぐ
デザイナ・フロントエンドエンジニアの不可侵領域
- 入ってきてほしくないと言われることが多い。作業に入る前に確認する。密にコミュニケーションをとる。
- 色を変えるとか、簡単なものはしてもらっている。
- デザインしてもらいたい。意見も欲しい。元々の理屈はあるけど、気づかない視点もある。
- サービスデザインは論理的に出来ている部分が多い。
- いちユーザとしての意見は欲しい。
- てきとーに作業はしてもらいたくない。
- 自分が責任を持てるところまで踏み込む。
- システムからの意見はうれしい。
- 知識としては、領域外のこともしていくべき。
- 領域外のことをすることで、作業効率が上がるかも
- もっと踏み込んでいって良さそう。

他職種とのコミュニケーションのコツ

単語の意味をちゃんと伝えて、その単語を使う
1回飲みに行くのが良かったり、話しかけてみたら意外とwelcomeだったり
わからない話をそのまま流さず、質問する
相手のやりたいこと・時間がかかることを理解する。
いろんな職種の人に話しかけに行く。
- 自分の影響範囲を知る。やりたいことの根回し手段を知る。
相手の郷に従う。相手のコミュニケーション文化に乗っかってみる。
相手の領域を経験することで、相手のことを知れる。
前提条件を合わせる。話し合うことで、お互いの認識を合わせる。

具体的なコミュニケーションツール

Slackは常に入ってる。
メールやLINEも使ったり。
静かだけど、Slackだと話していたりする。
デザインの思考プロセスを、Slackに流している。アイコンも使ったり。
esaを使って日報を書いている。もやもやを吐露していたり。
コミュ症の翻訳をしたり。
Skypeで文字ベースでやりとり。東京とはfacetimeで対面で喋ったり。
Slackの絵文字。reactionとか。
Prottを使って、プロダクトについて会話。絵があると、話が進みやすい。
Slackで雑談部屋。英語専用の部屋。
ホワイトボードに意見を貼るとそこから話が始まる。

懇親会

リモートワークに関心は高いらしい。いろんな人に聞かれた。
Dockerを本番運用しているところもあった。ただ、そこではユーザに直接開放する部分じゃないっぽい？
いまだにObj-CでiOSの実装を始めることもあるっぽい。企業の体質に依るのかな。
ポケモンgoの話題は誰にでも通じるぐらい。
- 飲み屋にポケストップあると回し放題（喋ってると忘れるけど）
PSDの切り出しまでエンジニアがやるのは、やりすぎだと思うデザイナもいるらしい。
Androidのソフトキーのために、縦横比が変わるってのを、あまり気にしてないデザイナもいる。普段iOSを使ってると気づかないだろうな。
- リスト系の画面だと、あんまり気にする必要無いし。
デザイン系学部の人たちが、電博にいってしまう。それをIT系に引っ張ってきたい。
渋谷とかの大きな会社合同で説明会みたいなのをしては？地方の学生はまとめてあると助かる。

2016-05-23

Kanazawa.rb meetup #45 に参加してきた。

Meetup #45 - Kanazawarb

最初に感想

あらためて、CIとはなんのためにやっていたのか、を再認識出来た。
様々なCIサービスがざっくり紹介されたので、あとで調べる。
CircleCIとGitHubの連携はやっぱり便利。ハンズオンの時間が余るぐらい簡単。
内容は知ってることが多かったけど、DMMのオフィス綺麗だったし、いろんな人と関われて良かった。
Gitの運用を悩んでるところは多いんだなー。
LTっぽいものしたけど、スライド無くてもなんとか喋れた。内容はほとんど伝わってないだろうけど、キーワードでも刺さってればいいな。あとQiitaのストック増えてよかった。
飲み会で飲めないのはまだなんとかなるけど、酒のうまそうなバーに行って酒が飲めないのはつらいｗ

イントロ

https://www.thoughtworks.com/continuous-integration

CIとは、ビッグバンテストではなく、継続的に結合する。
3ヶ月前に書いたものは覚えてない。
問題を速く発見する。

俺とCI

むかしむかし、「ビルド担当者」というものがいた。
- ソースコード集め→マージ
- ビルド担当者が槍玉に上がる（自分のところでは動くけど、マージされたら動かないとか）
そもそも、人間がやることが間違い。
Jenkinsとの出会い。
時は流れ、ビルド担当者→デプロイ担当者
DepOpsという単語が出てきた。
日経メディアで、Jenkins Redmine Chefが三種の神器とか言われた。
iOSとかで、またビルド担当者が出てきたらしい。
さまざまなモチベがあり、それの導入を容易にするために様々なツールが出てきている。

CIサービス紹介

https://speakerdeck.com/wtnabe/introducing-todays-ci-services

基本的にはSaaSで使えるもの。
基準：メジャー、OSS版がある、Windowsとか、おまけ
TravisCI
- OSSなら無料。
- ssh接続可能
- 古参で、perlとかもサポート
CircleCI
- 1コンテナならprivateでも無料。
- ssh接続可能
- 権限管理はGitHubと同期
CodeShip
- GitHub / Bitbucket
Shippable
- 安い
- 設定がちょっと煩雑
Drone.io
- GitHub / Bitbucket
- Browser標準搭載
- OSS版あり。Apache License。
BITRISE
- モバイルアプリに特化
AppVeyor CI
- Windowsサポート
- OSSならfree
- RDP接続可能
ブラウザテスト
SAUCELABS
- SeleniumテストとUnitテスト
- 手元のバージョンをリモートからテストも出来る。
BrowserStack
- 上と似た感じ。どっちが良いかはわからない。
カバレッジ
Coveralls
- Travis CI / CircleCI対応
CODE CLIMATE
- 静的解析
選び方
- 金で解決
- 人的リソースは有限。
- 当たったサービス以外はそこまでリソースを割けない。
- CI環境そのものが腐っていく。
弊社の例
- CircleCI + Codeshipの無料枠

2016-05-14

JAWS-UG金沢第10回勉強会に参加した話

https://jawsug-kanazawa.doorkeeper.jp/events/43543

AWSトラブルシューティング！早期復旧のための心掛け

dev.classmethod.jp

と同じ資料っぽい。

Developer.IO 2016で喋った内容
日次・月次・年次・不定期で分ける
- 日次は可能な限り自動化
データリストアを、運用前に確認する必要がある。
監視で障害があったとき、次のアクションを明確にする。
リソースではなく、サービスや処理状況を監視する。
URL監視がこけたら急いで対応。
SESのバウンス率が高いと、
メールをチケット化するサービスを使っている。
- 障害→CloudWatch→Zabbix→Twilioで電話がなる
AWSの障害も結構ある。
- 春と秋はEC2のリタイアメントが多い。
- APIの呼び出しに失敗することもある。
Design for Failure
負荷試験ではなく、限界試験をやるように言っている。
EC2Configが古い
APIコール失敗の場合は、エラー判定して、Exponential Retryするべき。
AWSサポートが最後の砦だけど、ちゃんと情報を送らないとあしらわれる。（このログを送って下さいで返ってくる）
緊急度 x 重要度 = 優先度
調査には、システム構成図・ELB/CloudFrontのログ・CloudTrail・MySQL show full processlist
- システム構成図には、データの流れがわかるように。
- ELBのログがoffのままの場合がつらい。
- CloudTrailは全リージョンで有効にすべき。Keyが漏れた時に、10分後に全リージョンでEC2を立てまくられた。
負荷試験では、3〜10倍の負荷をかける
限界試験で、どこがボトルネックになるかを知っておく。
フルボッコというCloudFormationテンプレートがある。
トップページ・ランディングページの試験は重要。一番リクエストがくるはず。
負荷試験後、ディスク使用量を確認する。
障害試験
- サーバを止めてみる。
- DBをファイルオーバーさせてみる。再接続するか確認。
- 障害が検知できるかを確認しておく。
- 検知されたメールを確認する。何に問題があるかが、メールだけでわかるか。
オペトレ
- 手順書を、書いた本人以外が試してみる。（情報に抜けが無いか確認）
Trusted Advisor
- リリース前には必ず見る。
- REDは無くす。

俺と「AWS外部から観測」

立場が違えば、"通常"の意味が変わる。
ゲームなどのサーバが止まると、ユーザはありとあらゆる手段で連絡を取ってくる。
- 機会損失も含め、かなりの損害。信頼を取り戻すのにも時間がかかる。
内部からの観測では、実際のレスポンス時間などは計れない。
内部からのアクセス用に管理ツールを表示してたのに、外部からも見れてたりってのは開発者は観測しづらい。
さくらのシンプル監視。月額21円。Slackに通知したりも出来る。
外部のJenkinsからレスポンス速度を定期的に取得しておくと、簡単にグラフ化したり出来る。

センターSEがインスタンスので止め忘れを監視してみた

大きいインスタンス1台を、1週間立ち上げてるだけで3万円かかってしまう。
CloudWatch Eventsのcron指定でLambdaを叩く。

Zabbix 監視と課題

障害対応は、こちら側で先に対応したい。主導権を握りたい。
Zabbixでアイテム数3万以上、トリガー4,000以上。
RSSの更新情報もZabbixで通知できる。
通知内容に多くの情報をのせる。連絡先とか、次のアクションとか。
通知は日本語にした方が、日本人には伝わりやすい。

今月のブログ収支報告

https://github.com/PharaohKJ/aws_billing2 Gem化しました。

感想

なれるSEを読んで、運用って部隊が必要なことは知ってたけど、自社ではそこまできっちり分かれてなくて、そんな世界もあるんだなーと実感。大抵RDSで詰まるとか、Trusted Advisorは必ず見ましょうとか、具体例が多くてためになった。

運用保守のことも、ちゃんと考えていかないといけないのかも。

懇親会で、日付変わるまで金沢の飲み屋にいて、そこから富山市の自宅まで帰ったら2時ぐらい、ってのはつらい。ただ、終電とか気にしなくて良いのは楽。終電でバタバタ帰るより、こっちの方が気持ちは楽かも。酒飲めないけど。

2016-03-12

詰め共円のサーバ移行で悩んでいる件

toyamarb.doorkeeper.jp で書きました。

前提

現在、Google App Engile + Cloud Datastoreで、無料の範囲内に収まっているサーバを、AWSに移したい。意図としては、

GAE/Pythonに飽きた。
- Python仕事で使うこと無いだろうし。
- Railsのアプリケーションを遊ぶために持っておきたい。
インフラ持ってれば、試せることが増えそう。
- Let’s Encryptとか。
- WebSocketとかやってみたいし。（Channel APIってので出来るらしい？でもgaeにロックイン。
オプション：Dockerとか使ってみたい。
オプション：AWSのサービスをいろいろ使ってみたい。（SNSとか）

データストアの検討

DynamoDB

テーブル数 x アクセス速度による課金っぽい。
- http://qiita.com/YU81/items/e1e336990ed8cfb938d9
- 5テーブル x 最低限だと、500円/月ぐらいになりそう。
- でも、SIMPLE MONTHLY CALCULATORでてきとーに入力しても、$0。謎。
現状、既にNoSQLなので、移行コストもそんなではない気がする。
- ただし、データの移送とかは考える必要あり。
DynamoDBを操作するGemも発見。 https://github.com/Dynamoid/Dynamoid
- 1系がリリースされて、aws-sdkの依存も2系になったっぽい。

Cloud Datastore

安い。
今使っているものをそのまま使えるので、移行コスト0。
良いGemが見つからない。

RDS, ElastiCache

時間課金なので、高い。
ElastiCacheの一番安いので、$20弱/月

コンピューティングの検討

ElasticBeanstalk

ELBだけで$19.77/月over
EC2は1年リザーブドだと、$14.64 -> $10.5に。（t2.micro）
EBSは必要だけど、30GByteで$3.6/月
合わせると、$33.87。高い。
ElasticBeanstalkとして書いたけど、結局EC2+ELBなので、直接でも良いかも。

Google Container Engile (GKE)

5ノードまで無料。（よくわからんけど、安い）
インフラ持てないじゃん。→却下。

Heroku

$7/月
インフラ持てないじゃん。→却下。

まとめ

AWSで、インフラを持ってみたい、ということでEC2を直接使うしかない感じ。
- ElasticBeanstalkを使うのか、OpsWorksとか使うのか、Terraformとか使うのかは検討。（レイヤーバラバラだけど。。
Google Cloud Platformは安いけど、Railsを動かす環境としては、ちょっと大変そうな印象。（Gemの量とか）

結論

$30over/月ぐらい。なのか？ http://calculator.s3.amazonaws.com/index.html?lng=ja_JP#key=calc-9C121C01-B126-43EC-8F3F-8D37D455C46F

2016-02-21

第二回！チキチキ Agile x Kanazawa.rb に参加してきました。

勉強会

Meetup #42 - Kanazawarb

表示してたスライドは、たぶんこれみたい。

Modeling in the Agile Age - JP

メモ

全体像を知るために、モデリングが必要。
捨てるモデルと、保存するモデルを分ける。
- コードからリバース出来るものは、捨ててしまう。
- コードに現れないものは、保存してメンテする。
Keeps
- Architecture
- Domain Model
- Key UseCases
Architecture
- システム全体の構造的な表現
- MVCの依存関係を、パッケージ階層で示すなど。
Domain Model
- 問題領域の概念とそれらの繋がり
- 現実世界をモデリングするのは難しい。対象となるシステムがベースになる。
- 唯一正しいモデル、というものは無い。
Key UseCases
- アクターが大事。"ユーザ"ではなく"開発者"など絞る。
- コミュニケーション図で、何が同動くかを記述する。
astahのマインドマップが使いやすい。
- D&Dで移動できたり、それをUMLにリンクさせたり。
- マインドマップは半構造データ。
他にKeepするもの
- 設計の理由。WHY。
チームで話し合って、追加・削除をしてメンテしていく。
モノ・コト・モノパターンと、ヘッダー・明細パターン
図書館と本屋では、モデリングが違う。図書館では蔵書という概念があるが、本屋では数しか見てないはず。
問題と解を得るために、分析モデルと設計モデルを分けて考える。

感想

メンテ出来なくて、特に重要じゃないモデルは、書いても捨ててしまえばいい、というのはいいと思った。書いてもメンテしなきゃ、と考えると書きづらいし。

また、用語集・辞書を最初に作って、それをメンテしていくのはやっぱり重要なんだなーと。メンテに際しては、誰もが見える場所で、更新が通知されることが重要っぽい。（みんなで作ってる感というか。ただ、誰もが見える場所とはいえ、プロジェクト関係者以外に見えたらダメだと思うので、どこに置けばいいのかなーと。

2016-02-08

「リモートチームでうまくいく」倉貫義人さんと語らう会に参加しました。

勉強会

toyamarb.doorkeeper.jp

に参加してきました。自分もリモートワークしてるので、そのへんのつらみの解決策が聞ければなーとなんとなく考えてました。

セッション

求人で来る人が地方が多い。都内は比較的少ない。
会社としては、リモートワークが前提。都内にいても、行っても行かなくてもいい。
間口広げるために、募集をリモート前提にした。
Skypeで音声繋ぎっぱなしは、人数が多くなるとつらい。
Results-Only Work Environment アメリカのものは、完全に個人のもの。
ただ、アメリカでも個人主義の考え方をやめ始めている。チームで助け合う。
エンジニアの評価は、短時間では出来ない。悪いコードを量産した方が、短期的には良く見える。
チームでやるとは、スポットの仕事をさせるわけではない。受発注ではない。
リモートワークという言葉の定義を浸透させたい。クラウドソーシングではない。
会社とは概念的なものであり、ソフトウェアで表現できる。

ビアバッシュ

ビアバッシュでは、いろんなことを聞けましたが、立ってピザ食べながらだったのでメモもなく、印象に残ってるものだけ。（ニュアンスが異なっていることは多々あると思います）

SonicGardenでは、営業活動をほぼ（？）していない。お問い合わせから依頼来る。
これまで、新卒採用はフォームすらなかった。その中で応募してきた人たちなので、その教育などは他では流用出来無さそう。
セキュリティ対策とかでガチガチにするぐらいなら、そういうのが必要無い人を採用するところにコストをかける。「なんでそんなに信頼ならない人を採用してるの？」
毎週の振り返りで、「先週は夜遅くまでやって、ここまで出来ました！」がKではなくPである、という風に教育していく。何が良い・悪いなどの社風はそうやって受け継がれていっている。
基本リモートワークしてるので、会社の椅子的なキャパが余ってる。家を借りようかと考えてる。
会社では、Skype打ち合わせが輻輳するようになってきている。（他の打ち合わせの声がうるさい、みたいな）
SonicGardenは裁量労働制。
リモートワーク推進協議会的なものを進めている。"リモートワーク"の言葉の定義を正しく認知してもらう。推進する会社を増やしていく。

なんとなく、SonicGardenはエンジニアにとっての理想郷を目指している感じは受けました。さらにそれが一般認知されており、お客も採用も上手く回っている感じ。売上の向上とかを至上命題にしなければ、こんな会社の運営の仕方もあるんだなぁと。

全員がリモートワーク前提でやっている、というのはかなりうらやましい。 Monstar Labでは、ほとんどが中目黒で、他に島根（4人）、鹿児島（1人）、富山（自分）という状態なので、リモートがマイノリティ。なので、認識の内外で、リモートだから、、、という遠慮はある気がしてる。なので、SonicGardenのやり方がそのまま持ってくることは出来ないけど、参考になるところを取り入れていきたいとは思う。

先週の富山合同勉強会もそうだけど、こういった有名な人の話を富山で聞けるってのはありがたいなー。運営側はお疲れ様でした。 2週間後には平鍋さんの話も聞けるので、楽しみ。 Meetup #42 - Kanazawarb

2016-01-31

富山合同勉強会2016

JavaOne 2015 San Franciscoフィードバック、そしてJava EE 8についてのアップデート

JavaOne 2015は1万人超
Sunの頃よりはまだ少ないけど、近づいてきている。
IoTの活用が強めに話された。
2016のJavaOneでは、さらに事例がふえると予想。
Java8が出た後で増えてきている。
JCPへの参画拡大。営利団体でも無償化。
キーワードはIoT, DevOps, microservice
IoT
- JavaMEとかJavaSE embededとか。
- マイコン上でJavaが実装されている。
DevOps
- Pirates of DevOpsという動画が公開されている。
- 2014のJavaOneでは7つ、2015では107にセッションが増えた。
- セッションの選考委員会側が意図的に選んだ？
- 自動化するツールは徹底的に使用しましょう。
- その成果を継続的にチェックをしましょう。
Microservices
- Gilt.comのセッション。ブランド品ディスカウントのECサイト。
- 毎日昼12時から数十倍数百倍のアクセスがある。
- 2011まではJavaEEベースのシステムを運用。
- 2015にMicroservicesの導入。
- Playでフロント、Scala,Java,JavaScriptの小さなサービスと連携。
- 1つのサービスは1000や2000行。
- オンプレ→AWS上に移行している。
- dockerを利用する。
JavaEE8アップデート
最初のドラフトのレビュー中やレビュー完了の状態。
クラウド絡みのものは遅れ気味。
7,8団体がレビューしている。
early draftの策定中であれば、まだ意見が通りやすい。後ろになれば通りづらい。
HTML5 / Web Tier
- JSON-BはJacksonがメインで考えられている。
- プロバイダの変更も可能。XML
- JSON-PにJSON-Pointerが追加される。
- "/0/phones/mobile"とかで特定のデータを取得・更新できる。
- JSON-Patchでは、JSON形式で変更出来る。
- MVC1.0が策定中。
- 既存のJavaEEテクノロジーを組み合わせて実現。
- JAX-RSとCDIとJSPとか。
- HTTP/2
- Server pushがServlet4.0の中に入ってくる。
- CDIの範囲がMVC / JAX-RS / JavaSEに広がる。
- 2つのパーツに分けられる。Full CDIとCDI Light。
- Junit内でインジェクションが、標準で出来るようになる。
Adopt a JSR https://glassfish.java.net/adoptajsr/
まずは見るだけでも。
JavaOne 2016に行こう。

Project Jigsawではじめるモジュール

http://www.slideshare.net/skrb/module-programming-with-project-jigsaw

使い方を中心に。
Client Side Javaを中心にやってる。Java SE, JavaFX。
Huge Standard Lib
Hadoopは130のjarを読みこんだり。
JARが抜けてたり、依存関係のバージョンがズレてたり。
No Dependency, No Version, Public is TOO Public
始まりは2005年。friendsを入れよう、という話が出た。
JSR 277は炎上中断、JSR 294はmoduleとして続く。
2009年にProject Jigsawが始まったけど、2017のJava SE9に入る。
スコープの問題（OSGiをどうする？とか）で混沌とし、スコープをかなり狭めてSE9に入れる。
SE9で入る、ということが重要。
module extends JAR { dependency; exportation; version; }
module-info.javaに書く。src直下に置く。
module (モジュール名=パッケージ名にすることが多い) {}
requires javafx.controls;とかで依存関係を明示する。
exports (パッケージ名);で外部に公開する。
mainメソッド持ってるクラスはexportsに入るようにする必要がある。
requires public javafx.graphics;とやると、第三者にもpublicになる。
gradleはJigsaw対応を進めている。
コンパイル時には"-mp"を付ける。
モジュール作るときは"--create"が必要。"--module-version"でバージョンを指定できる。以上・以下は比較出来ない。
実行時にも"java -mp"とかする。
rt.jarを全部読み込む必要が無いので、メモリに優しい。ちょっとだけ。
classpathに指定すると、unnamed moduleとして扱われる。
JavaSE8から、rt.jarを分けれる。循環参照とかをきれいにした。
module-info.javaに書かなくても、jdepsというツールで確認できる。
JLINKというカスタムJREを作れる。IoTとかでメモリの使用量を減らせる。
https://jdk9.java.net/jigsaw/ に既にあるので、すぐ使える。

Microsoft Java

AzureはLinuxでもdockerでも立てれる。
MicrosoftはJavaVMのパフォーマンス改善とかにも参加してる。
Azure上でのホスティングの選択肢
- IaaS
  - クラシック or not。新しい方は、マシンだけじゃなく、グルーピングまで出来る。
  - MarketPlaceからも選択できる。WebLogicがインストールされているものとか。Microsoft＋ベンダーが管理している。
  - VM Depotはコミュニティが作ったイメージがある。
  - 設定情報をJSONテンプレートとかに書いておけば、そこから構築できる。
  - サンプルはGitHubで公開されているので、それをもとに作れる。
  - 3rd partyのクラウドサービス
- Cloud Services(PaaS)
  - OSまでを提供。JDKとかはメンテが必要。
  - 監視ツール、OSメンテ用の機能が提供されている。
  - ステージング・本番みたいなものを持っている。
  - スケール設定も簡単。
  - リモートデスクトップも出来る。
  - Eclipse, IntelliJ ツールキットがある。
  - macはEclipseの方がオススメ。
  - JDK, APサーバ, 作ったものをGUIで選択してデプロイ出来る。
- App Services(PaaS)
  - Tomcat or Jettyを選択し、そこまで管理してくれる。
  - warファイルのデプロイで動く。
  - Windows Server上で実行される。
  - Java以外にも、PHP / .net / pythonを動かせる。
  - Tomcat / Jettyは古いバージョンしか選択できない。
  - 継続的（自動）デプロイ機能を持ってる。
  - 障害・監視機能なども提供
- Container
  - DockerはJava界隈でもトレンドになってきている。
  - マイクロソフトがDockerと提携してる。
  - 仮想マシン配ろうとすると、数G・数十GByteかかる。
  - Dockerは容量をかなり削減できる。
  - Windows Server 2016 TP3からDockerを利用できる。
  - Dockerを使うときはtutumが便利。
マイクロソフトはFeedBackを、本気で求めている。

Ruby 2.3 のてざわり

Java to rubyでIDEを使わなくなった。REPLで試しながら書くようになった。
self navigation operator=ぼっち演算子。
SQUIGGLY HEREDOCはインデントを取り除ける。
digはJSONとかで便利
Enumerable#grep_vはgrepの否定。正規表現マッチしないものを取得できる。
the did_you_mean gemはirbとかrails consoleで便利。
NameError#receiverはdid_you_meanで使われている。デバッグのときにも使えそう。
Hash#to_procは使いどころが思いつかない。。。

わたしの Ruby の楽しみ方

rackアプリケーションでTwitterのOmniAuth使ったアプリが100行レベルで書ける。

エンジニアが出来る貢献

災害支援をITで。
維持費がかからないように。サーバを持たない。
Google Formをお客さん作ってもらうと、仕様が固まる。
Google スプレッドシートをデータベースにすると楽。

2015-12-30

IoTで除夜の鐘を作った話

IoT

正確には、除夜の鐘"っぽいもの"ですね。

http://www.bonno.xyz/ が完成した物です。

ぜひ、Twitterで #煩悩付けて、今年やり残したこととかをつぶやいてください。

経緯

会社でラボスペースってのがありまして、週１でそこでIoTとか新しい技術について話をしています。そこで、年末に向けて何かやりたいねー、という話が出て、除夜の鐘とか作ったら面白いんじゃね？となり、作ってみた感じです。

本題

物理的な部分は、鐘を目覚ましのベル部分、撞木をドライバーで作りました。

撞木を動かすのにサーボモータを利用して、それをArduinoで制御、それをmac book経由で遠隔操作する流れです。（ホントは、raspberry piでやりたかったのですが、時間がなかったのでmacでやってたのをそのまま使っています。）

Arduino

Arduinoの方は単純で、シリアル通信を受け取ったら、サーボモータを回転→逆回転させます。

#include <Servo.h>
Servo myservo;  // create servo object to control a servo
int dir = 0; // -1: back, 0: stay, 1: ahead
int val = 0;
void setup() {
  pinMode(8, OUTPUT);
  myservo.attach(9);  // attaches the servo on pin 5 to the servo object 
  Serial.begin(9600); // some servos doesn't work without Serial
}
void loop() {
  int inputchar = Serial.read();
  if (inputchar != -1 ){
    Serial.write(inputchar);
    dir = 1;
  }
  if (dir == 1) {
    val += 4;
  } else if (dir == -1) {
    val -= 4;
  }
  if (val < 1) {
    dir = 0;
  }
  if (val >= 130) {
    dir = -1;
  }
  String valString = String(val);
  Serial.print(val);
  myservo.write(val);
  delay(16);
}

スケッチの書き方があまりよろしくない気はしています。とりあえず動いたからいいかなーと。

mac book上のArduino制御プログラム

こちらは、websocketによるイベントを受信すると、Arduinoにシリアル書き込みを実行します。

const client = require('socket.io-client');
const socket = client.connect('http://www.bonno.xyz');
// Serial setting
var SerialPort = require("serialport").SerialPort;
var serialPort = new SerialPort("/dev/cu.usbmodem14221", {
  baudrate: 14221
});
serialPort.on('open', function () {
  console.log('serial open');
});
socket.on('kane-wo-tsuke', function() {
  serialPort.write("1\n", function(err, results) {
    console.log('err ' + err);
    console.log('results ' + results);
  });
  
  setTimeout(function() {
    socket.emit('kane-wo-tsuita');
    console.log('kane-wo-tsuita emitted');
  }, 700);
});

websocketとシリアルポートの準備をしておき、websocket経由でkane-wo-tsukeを受信すると、"1\n"をシリアルポートに書き込む感じ。

サーボモータが行って返ってくるのに数百msecかかるので、それが大体終わったぐらいで、kane-wo-tsuitaをwebsocketサーバに送信します。（実際には、それ以上にustreamが遅延しているので、意味ないですが。。。）

組み立て

100均でいろいろ買ってきました。

f:id:suzaku114:20151229120209j:plain

鐘を吊ったりするのにやぐらが要るだろうと思ったので、割り箸と結束バンド（タイラップ？）で作りました。

f:id:suzaku114:20151229141821j:plain

目覚まし時計のベルがいい感じの（？）音だったので、これを鐘にしました。

f:id:suzaku114:20151229141958j:plain

やぐらの土台として割り箸をボンドで立てました。また、鐘の中心にいい感じに穴があったので、割り箸を突っ込み、結束バンドで落ちないようにして、ボンドで固めました。

f:id:suzaku114:20151229143455j:plain

撞木をドライバーにすると、想像以上に音が出かかったので、ビニールテープで裏から押さえました。自宅でやってるので、近所迷惑にならないか、ビクビクしながらやってます。。

f:id:suzaku114:20151230153153j:plain

ドライバーに、「ケーブルまとめるねじねじするやつ」を2つ付け、それぞれからビニール紐を伸ばし、サーボモータに付けました。これが、割り箸でやると軽すぎて上手く当たらなかったり、1本の紐で吊るとくるくる回っちゃったりで、無駄に時間がかかりました。ティッシュ箱2つ分の高さがいい感じだったので、その上にサーボモータを置いています。

f:id:suzaku114:20151230160009j:plain

そんなこんなで除夜の鐘が出来ました。

サーバサイド

サーバサイドはGitHubに全部上げちゃってるので、見て頂ければと。後で、詰まった所とかは細々書く予定。 Heroku上で動いています。

github.com

その他環境周り

mac bookでは、ブラウザ上でustreamの配信を行っており、

マイク：ECM-PCV80U カメラ：UCAM-DLE300T

を使っています。

あと、実際に動かしてみると、動いている感が全く無かったので、時計を置いて動いてる感を出しています。

余談

ページ見てもらえば分かる通り、デザインとライティングの能力の無さを再確認しました。誰か助けて。。。

2015-11-23

Android Bazaar & Conference Diverse 2015 Kanazawa（2日目）

テクノロジー＆クリエイティビティ

team Labは400名いる。
エンジニアが70%。
デジタルアートはだいたい5年前から。海外の評価が先行。
もともとWebのエンジニアの人が、機械学習とかやる。
画像処理は結構アカデミックなところから人引っ張ったりしてる。
障害はほぼ発生しなかったが、キャリアの基地局がパンクした。
アートだけではなく、テクノロジーと繋げる。
キャンドルリレーは音で伝えた。機種依存が大変だった。
ペッパーのイベントでは、四方にスピーカーを置いて、それらの音から三点測量的に位置を検出した。
共創をキーワードに、他との差別化を図っている。

RoBoHonのRoBoHonによるRoBoHonのためのプレゼン

https://www.youtube.com/watch?v=HQtIlxe_ZkY&feature=youtu.be ツッコミたいところが幾つかある動画ｗ
コンセプト動画にあるものは、基本的にやる。
四角いスマホに喋ったり、喋りかけられたりするのは違和感がある。
COCOROBOという喋る掃除機も作ってる。
ディスプレイはいちおう付いているが、基本的には音声で。
意外と激しく踊る。たまにコケるらしい。
OSはお察し下さい。
CEATEC JAPANでは大盛況。
ロボホンを輸送するときは、100均のタッパが便利。
作る側とマーケ側がCEATEC出すときに結構戦った。
まだ開発中なので、個体差がある。踊れない子もいる。
2016年の前半に発売予定。
価格はまだ。
開発ツールも検討中。
IS01を開発してた人と、新しい人と
電池としては、1日持たせる（踊り続けはしない）
サーボの電流は大きい。
騒がしいところでも使えるように。
学習機能もある。
人格を複数とかもやりたいけど、コンセプトがブレる。
サーボの制御はオープン化出来るように考えている。

Androidアプリのマーケティング/マネタイズ

Androidアプリ出してる人、広告入れてる人は、会場には少なめ。
AARRRモデル
獲得・活性化・継続・紹介・収益
本日は獲得と紹介の話。
Androidは項目多すぎて、上位アプリしか見られてない。iOSはシンプルなので、100位ぐらいまで見てくれる。
Google Playのランキングは、DL数・アクティブ率・評価が指標になっているっぽい。
有効ダウンロード率が意外と重要。
Google Playのランキングで上位に上がるのは難しい。
iOSは直近数時間の断続的な新規ダウンロード数で、ランキングが変動しやすい。
検索は、タイトル・説明文で触れてるアプリだけではなく、関連度の高いアプリも出てくる。
タイトルには重要ワードを突っ込む。
説明文は、濃度が重要。ターゲットワードは5個ぐらいにする。
検索結果数が多いキーワード＋自分のアプリならではの部分。
ASO対策することで、DL数が10倍になることも。
Androidでは、レビューサイトに紹介されてもそれほど伸びない。積み上げるしかない。
流入に対して、一番自分たちでコントロール出来るのは、ASO。
1日に100DL取れてれば、結構良い。
紹介を得るためには、ツイートへのインセンティブ or シェアしたくなるコンテンツ。
カジュアルゲーム作ってた会社は、最近廃業が多い。
音楽再生（動画）・ゲーム攻略・マンガ・定番ゲーム

UE4ハンズオン

ゲームエンジン自体のハードルが上がってきてる（いろんな機能はあって当たり前）
アーティストやデザイナーがコーディング無しで使えるように。
エンジニアはもっと深い部分に注力できるように。
四半期30万を超えるぐらいにならないと、費用は発生しない。
E3 2015で65タイトルがUEを使ってた。
ドキュメントの日本語化も、数日遅れとかで反映されてる。
Youtubeでは、半日かけてやったようなハンズオンも上がってる。
Perforceがオススメ。20人まで無料のライセンスもある。Gitとかだと、バイナリが辛い。

今さら聞けないVRコンテンツの作り方

追体験型なのか、非日常型なのか。
スマホ前提なのか、専用HMDなのか。
oculusは基本WindowsPCでしか開発できない。
Cardboardで綺麗なものを表現しようとするのは辛い。
VRコンテンツ製作は3Dゲーム制作の延長上にある。
Cardboard向け開発
- Unityが楽。（OpenGLとか、UE4とかより）
- そんなに高性能なPCは必要無い。
Oculus Rift向け開発
- UnityやUE4を利用。
- Oclus社で作ってるのは、UE4
- スペックの高いWindowsPCが必要。
- 理想のPCとしては、58万ぐらいで売ってる。現実的には20万程度のゲーミングPC。
アセット（データ）が無いとゲームは作れない。
ネット上にある3Dデータを使うのも可能。ただし、権利関係に注意。
中野シスターズは便利。
ステージは比較的作りやすいので、自分で作ればいいと思う。
VRでは、手元が見えない。コントローラあってもボタン配置が見えない。
視線・モーション・Oculus Touchで操作。
不用意な挙動をすると酔う。
座って体験するのが前提。
13歳以下は体験不可。
ソードアート・オンラインは見たほうが良い。
ゲームウォーズも同じく。

アプリ開発者が社会課題に取り組むABC

オープンデータ・Civic Techはまだあまり知られていない。
「寄り合い」という地域コミュニティが強かった。
テクノロジーで社会貢献ができる。
オープンデータは国としての重要課題。
5374や保育園マップの事例。
エンジニア・デザイナだけではなく、市民・行政など様々なプレイヤーを混ぜる。
経済的効果ではなく、教育や市民参画など社会にどれだけ広く影響を与えたか。＝social impact

東京から地方へ〜ピグマルはなぜ拠点を地方に移したのか

ドロイド君ロボットとか作ってた。
FourBeatはAPI提供している。
上田市は16万人。
上田に行き着くまでに、国内・海外含めていろんなところに1ヶ月程度とか暮らしてみた。
どこにいてもある程度開発出来るけど、ではそこにいる意味は？社会的異議。
長野県が募集していた。
長野市 or 上田市は県の判断だった。
仕事場はコワーキングスペース。多業種の人が集まる。
東京と地方の違いは、人の多さ。
- バスに人いない。勉強会が無い。口コミが機能しない。
- 東京は人が多い分、同じ興味分野の人でも集まれる。異業種の人と関わるしかない。
それぞれの分野では、それぞれの課題がある。エンジニアが当たり前にやってることがありがたがられることもある。
Try & Errorのやり方はエンジニアの得意領域なのでは？
成功・失敗に関わらず、客観的に評価できるアウトプットを出す予定。
2/20-21で上田でメイカーとメーカーが出会うイベントを開催予定。
半年後に上田にいて欲しいと思われるように頑張る。

研究室の活動や進路の話

高専の5年って、外で言っても伝わらない。
インターンシップや共同研究から就職に繋がるケースがある。
http://www.ishikawa-nct.ac.jp/info/20140820-0840.html プロジェクションマッピングとかやった。
小矢部ともイルミネーションとか、プロジェクションマッピングとかいろいろやってる。

LT大会

JAGがAndroidのアプリ教材を作りました。 http://techinstitute.jp/material/02/ 気持ちよくなる系が多い中で、結構網羅的な教材。日本語。 NPOとしてと、コミュニティーとしての日本Android（アンドロイド）の会

https://kzgame.doorkeeper.jp/events/33759 第4回 Oculus Game Jam in Japan 石川会場の告知。

授業変更が多い。 WEBで学内なら見れるが、自動スクロールしかない。とりあえずAndroidアプリ化したけど、外では古いデータがみれるだけ。オープンデータ化は大人の事情で出来なかった。 Googleアカウントが配布されているので、その認証を必須にすることで回避。今後はネイティブ化してPUSH通知を付けたい。他データとの結びつきもつけたい。球技大会の予定＋結果速報表示も作った。

アンドロイドな女の子 OSじゃないアンドロイド質量を持った仮想現実機耳（ロボミミ）思考を現実化する。

hackforPlay HPを書き換えることで、ボスを倒したり。小学生が楽しみながらプログラミングを学べる。

Raspberry piでラズベリーパイを焼ける。（釜の開閉を制御） Huginで展開できる。 h264が扱いづらかったのでrtspで。フレーム描画崩れたりした。 Unityでもやってみたけど、MotionJPGである必要が。 three.jsに乗り換え。時間が来たので終了。また、今のAndroidで動くかは不明。

ABC来てね。コミュニティなので、暴走・逸脱する人もいる。誰かがやらないと、楽しいイベントは開催できない。イベントに参加する人は、全力で楽しんで下さい。

全体的な感想

金沢でこんなにいろんな人の話を聞けて、ありがたかった。富山や石川にいる人はもちろん、それ以外からの人も多く、色んなエンジニアと話せてよかった。 VRコンテンツが結構簡単に作れたのも驚きだった。ちょっと何かに使ってみたい。あと、石川高専すげぇ。なんで富山に無かったのか。（違