読者です 読者をやめる 読者になる 読者になる

BuriKaigi2017に参加してきた

toyama-eng.connpass.com

富山で.NETとJavaが一緒になったイベントに参加してきました。

.NETはほとんど関わりがないので、ずっとJavaのセッションにいましたが、オラクルの人と日本に2名しかいないJava Championの話を富山で聞ける、というのはすごいですね。 内容も、今までとこれからのJava SE / EEについてや、新しい開発手法、Microsoftのサービスを使ったデモなど、様々なことを再確認・学べました。 会場はそんなに広くなかったですが、Java側はそこまで過密じゃなかったので、ちょうどよいぐらいでした。

合同でのLTでは、別々のLTなのに、APISQLに→SQLC#にと、神がかった流れもありました。

本番は懇親会、ということでタイトル通りのブリしゃぶも美味しかったです。 5,000円で飲放題付きで、量・質ともに良い料理でした。 2名しかいないJava Championに挟まれる、というすごい状況でしたw

3次会まで、いろんな話ができ、昔話・それぞれの人の考え・自分の考えのまとめなどできました。

個人的に考えが整理できたのは、自分のやりがいをどこに求めるか、という部分です。 プロダクトとして良いものを作りたい、というのは無くはないのですが、私としてはその中でどんなアーキテクチャ設計・実装が出来るかということが大事なようです。

人と深く話すと、自分の思いを整理・理解できていいですね。

以下は、聞きながらとったメモです。

タイトル未定

伊藤敬 氏

JavaOne 2016

過去最多の日本からの登壇者 マツダの工場でJavaが動いてる。

JavaSE Update

dockerのイメージで配布される?もう少ししたら、具体的な話がでるかも。 2017/7/27に、Java9がリリース予定。 Feature Extension Completeはされたけど、まだ機能が入る。。? Java SE9では、Applet起動時に「非推奨です」の警告が出る。 非互換 →ほとんどの内部APIが利用不可になる。JEP 260。sun.misc.*などの排除。

Java EE Update

クラウド・マイクロサービスを向いている。 リアクティブ・プログラミングの導入。 dockerとの親和性も考えてる。 パッケージングにDockerモデルの採用 Serverlessについても検討を始めている。 jarを作れば、いろんなクラウドに乗る。ようにしたいと考えている。 アノテーションベースで、Configやloggingが外部サービスの実装をInjectしてくれる。 OAuth/OpenIDのサポート。 JMSやManagementは変更しない。 MVCは議論中。 JSON-B, Security, Configuration, Health Checkあたりが、Java EE8で入りそう。(Configurationは微妙かも) Bean Validation, Servlet, CDI, JSF, JAX-RS, JSON-PがJava EE8で更新される。 そろそろ、オープンな議論が始まりそう、ってステータス。 Java EE8は、2017年中に出す。予定。 マイクロサービスサポートは、JavaEE9が本番。

WebLogic ChannelがOracle Java & Developersにリニューアル。

これまでのJavaと、これからのJava

櫻庭祐一 氏

内部・匿名クラスは、Java1.1で出てきた。マイクロソフトのおかげかも。 →継承から移譲へ。関心事の分離。ラムダ式へ。 J2SE5 Ease of Development ジェネリクス クラスのパラメタ化 Type Safe=型安全 JSR201: for-each →これも、最近はstreamで書けるようになった。 Java SE7 Coin(=small changes = 小銭) try-with-resources ダイヤモンド演算子 Java SE9 Lambda 外部イテレータ→内部イテレータ。最適化しやすい。パラレルとか。 途中状態が晒されない。イミュータブルに出来る。List<Long> nums2 = nums.stream().map(n -> n*2L).collect(Collectors.toList()); interfaceのデフォルト実装は、SDK内部のコード変更が可能に。 Java SE9 Jigsaw モジュールの導入。JARにメタデータが書けるように。

機能導入の目的 ・Performance ・Ease of Dev ・Safeness Lambdaのみが、Performanceに関するもの。それは、マルチコア世代のため。 その前に、InvokeDynamicが重要な要素だった。

Future Java SE10 Valhalla / Panama / Ambar Valhalla →Primitive TypeとReference Typeの中間にValue Typeを作る。 →型パラメータにPrimitive Typeを入れられるようになる。

ハードの変革に応じて、ソフトの作り方も変えないといけない。Javaの言語仕様も、Performance関連の変更も今後入ってくる。

Engineer is Hero !!

マイクロサービスの開発手法や IoT を採用し感情や表情を解析しより良い社会を作ろう 寺田佳央 氏

マイクロソフトは、かなりクラウドを推してる。 AIもやってる。APIやPlatform化。 Cognitive Toolkit -> Microsoft R -> Machine Learning -> Cognitive Serviceの順で手軽に出来る。 Cognitive Serviceの認識率は、人間と同等化それ以上。 HololensはMR。

開発環境と本番環境を揃えるのは大変。VMとかできてきたけど、容量がでかい。 Infrastructure as code 環境のロールバックが出来る。 構築と設定の2パターンがある。

DevOpsとは、ツールの話ではない。開発プロセス改善活動の一環。 ハックフェストは、実際のコードを使う。 →今の開発プロセスを書き出す。企画からリリース管理までを洗い出す。バリューストリームマッピング。どこに人がかかり、時間がかかってるか。 実例として、リリースまでに8ヶ月かかってたのが2,3週間になった。 feature flag付けて、実際のデータで見せたほうが、理解が得やすい。

Micro Service DepOpsの先に、Micro Service。自動化されているから、生きる。 住宅建築から、いろんなものを学んできた。 住宅の寿命は30年。リフォームするみたいに、ソフトウェアも再構築? ソフトウェアのライフサイクルはもっと短い。住宅業界から学ぶのはもうやめては? water fallでは、時間が立つに連れ、変更に対するコストが大きくなる。ただ、時間が短ければそうでもない。 Ford(車外車)がFordPassというものを作った。クラウドとかmicro servieを使って、作ってる。東海岸と西海岸でDR構成。 Azureには1年に600の機能が追加されてる。1つの不具合が全体に影響しないようにしている。

いままで:モノリシック→1つの変更、障害に対して、影響範囲が大きい。ロックインされる。 マイクロサービス:影響範囲を限定化。言語なんかも再選択出来る。 考え方を変えないといけない。分散される。システムは落ちる・通信は切れる可能性はある。 マイクロサービス・デザイン・パターンが提供されている。 (https://uramoto.wordpress.com/2015/09/21/%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3/ このあたりか)

MicroProfileなど、マイクロサービスを意識したJava framework。 Azure Service FabricはAkkaの人とかが馴染みやすい。 Pivotal Cloud Foundryのデモ。GitHubにコードが上がってる。

AIのサービス Cortana / BOT Framework / Cognitive Services / Azure Machine Learning / Cognitive Toolkit アロバビューという会社が、監視カメラと連携させている。サマーランドの入場者の男女比・年齢層がリアルタイムで分かる。Power BIで可視化。 OCRは精度高いけど、日本語英語が混じると、うまくいかない場合がある。 制限はあるけど、無料で試せる。ブラウザ上で試すことが出来る。

ブクログの本棚を、amakanにインポートしてみた

今までは、 ・本棚としてはブクログ http://booklog.jp/ ・新刊情報は新刊.net http://sinkan.net/ をGoogleCalendarにエクスポート してました。

ただ、 新しいシリーズを買ってブクログに登録しても、新刊.netにも登録しないといけない ってのがめんどうでした。

そこで、ふと思い立って、前から気になってたamakanにデータを移してみました。

chrome拡張が無い

amakankanというもので、ブクログから移行できるのは知ってました。

amakanのChrome拡張がブクログの本棚からの一括登録に対応しました - amakan

ただ、chrome extentionのリンクを踏んで見ると、404になってました。

なので、GitHubのコードをcloneしてきて、手元でビルドしました。

github.com

ghq get https://github.com/amakan/amakankan.git
cd /path/to/amakan/amakankan
yarn install
npm run pack

chrome://extensions/ に移動して、「パッケージ化されていない拡張機能を読み込む...」で、 dist/chromeを指定しました。

ブクログからインポートしてみた

http://booklog.jp/users/noboru114 に遷移して、chrome extentionのボタンを押しました。 「登録中」的なアラートは出るけど、何も起こらず。

不思議に思ってコードを見ると、 https://github.com/amakan/amakankan/blob/master/src/chrome/js/content-script-booklog.js#L42 で、「読み終わった」と書いてありました。

個人的に、設定がめんどいので、全て「未設定」にしていたので、データが取得できなかったっぽいです。なので、

-        const url = `${pathNamePart}?category_id=all&status=3&sort=sort_asc&rank=all&tag=&keyword=&reviewed=&quoted=&json=true&page=${i + 1}`;
+        const url = `${pathNamePart}?category_id=all&status=all&sort=sort_asc&rank=all&tag=&keyword=&reviewed=&quoted=&json=true&page=${i + 1}`;

のように、statusをallに変更して、試してみると、無事登録が開始されました。

コード変更後は、npm run packして、拡張機能のページで「リロード(⌘R)」を実行しました。

件数がたりない

ブクログは682アイテムあるのですが、amakanに登録されたのは666アイテムでした。 20アイテムが登録できなかったようです。差分はめんどいので追ってないです。

日付が、全部「今日」になった

「読んだ数」がグラフ化されますが、全部同じ日付になっちゃいました。

コード確認すると、read_atで取得してました。

https://github.com/amakan/amakankan/blob/master/src/chrome/js/content-script-booklog.js#L16

で、JSONを確認すると、create_onで登録日が取れそうでした。 なので、下のようにつぶやいて、r7kamuraさんに捕捉され、補足いただきました。

なので、

-    const readAt = book.read_at;
+    const readAt = book.create_on;

にして、再度packしてリロード。そして実行すると、いい感じにグラフが作成されました。

https://amakan.net/@noboru

こうやって可視化されるのは、微妙な気持ちになりますね。

というわけで

無事、インポートはできました。 新刊も、Google calendarでいい感じに取れてそうです。

ただこれ、どうやって追加登録するんでしょ。。。? https://amakan.net/tools にあるけど、いまいち、使い方がわからない。。 Androidのクライアントとか、作っちゃえばいいのかな。。。?

新しいMacBook Proを買うにあたって、スマホアプリエンジニアとしてUSB Type-C関連商品を探してみた

11/6 追記

Apple、USB-C及びThunderbolt 3対応の各種ケーブルやアダプタ、LG製4K/5Kディスプレイを期間限定で値下げ | 気になる、記になる…

Apple公式でセールしてて、ちょっと安くなってるらしいです。 上記のリンクだと元値が書いてあってありがたいですが、 公式の方では「特別価格」になってるのはわかりますが、いくら安くなってるのかわからないですね。

Lightningケーブルとかは公式のほうが安心なので、買うならこの期間の方が良さそうですね。


新しいMacBook Pro、発表されましたね。

www.apple.com

Touch Barが一番の目玉だったり、性能・ディスプレイなどいろいろな改善があるようですが、ポートがほぼUSB Type-Cになってしまうことの影響も大きそうです。

いままではUSB Type-Aからの接続が基本だったので、いろいろケーブルを買う必要がありそうです。

※まだMacBook Proが届くまでに時間があるので、まだ買ってない商品ばかりを紹介してます。 下記のような怖い話もあるので、使って何かあっても自己責任でお願いします。

ゲーマーのためのUSB Type-Cケーブル購入ガイド。安心して使えるのはどれか,全29製品で安全性を検証 - 4Gamer.net

Androidデバッグ

USB Type-C - USB Type-microBのケーブルが必要です。 仕事デスクに座って開発する以外にも、ソファーに座って開発することもあるので、単体のケーブルもあったほうが便利です。 50cmぐらいがちょうど良さそうですね。

また、新しい端末ではmicroBではなくCが入力になるものが多いですね。(Pixelとか)

そうなると、こっちでしょうか。

iOSデバッグ

同じく、USB Type-C - Lightningのケーブルも必要ですね。

Apple公式のものは、1mで¥2,800なので、ちょっと高いですね。

www.apple.com

Appleの認証が無い製品は、新しい端末とかOSで使えなくなったことがあるので、「認証」とか書いてあるものが安心ですね。

ただ、認証有りでこの種類のケーブルはあんまり見つからないですね。 「認証」を考えなければ、いくつかありそうですが。

ただ、どちらにしても0.5mのケーブルはなかなか見つからないです。

USB Type-Aポートの追加(USB HUB)

仕事デスクで仕事する場合、マイクとかCDドライブとか、いくつか付けられるようにしておきたいです。

Ankerはよく聞くメーカーですね。

HDMIでサブディスプレイを使うので、HDMIが付いたものも良いですね。 ただ、USBが2ポートしか無いので、ちょっと心許ないです。

このあたりは、いろいろ種類がありそうです。 デザインとかの好みで選んでもいいんじゃないでしょうか。

http://amzn.to/2f4JRGMamzn.to

HDMI端子の追加

サブディスプレイを接続する場合、HDMIの端子が必要になりますね。 先程のハブでも、家で使う分には問題無さそうです。

ただ、外部の勉強会とかでプロジェクターに映して発表する場合も、HDMIケーブルまでは備え付けられている場合が多いです。 なので、持ち運びも考えると、HDMIのメスに変換できるものがあれば良さそうです。

Apple公式のものは、USB Type-CやUSB Type-Aも付いているアダプタしか無いようです。 また、¥7,400ということで、ちょっと高いですね。

www.apple.com

Apple公式以外なら、もうちょっと安いですね。

ただ、4kディスプレイを持ってるので、4k対応と記載のあるものが安心ですね。

Cable Matters USB-C → HDMI 変換アダプタ【レビュー】 : ガジェおた を見る限り、MacBookでの動作は問題無さそうですし。

magsafe的な電源ケーブル

今のmacbookを使っていて、magsafeがあることでの安心感はあります。

かなり高いですね。この金額だったらmagsafeは諦めるしかないですかね。

BreakSafe Magnetic USB C Charging Cable | Griffin を見ると、$39.99なので、輸入業者がかなりマージン取ってる。。。?

11/4追記

kickstarterで早速で出てますね。

www.kickstarter.com

上に書いてたGriffinのものは、 新MacBook Proの充電ケーブルをMagSafe化「Snapnator」発表。スマホや他社製ノートPCなどUSB-C搭載機器にも対応 - Engadget Japanese に書いてあるとおり、電力的には15inchのものが保証されてないようなので、kickstarterのものに賭けてみます。

まとめ

ということで、ざっとまとめてみました。

思ってた以上にAmazon上で検索するのが難しいっす。

もうちょっといろいろ調べて追記していこうと思います。

参考

新型MacBookで使いたいオススメのUSB-C関連グッズ | 目くじら日記

MacBook early 2016用にぴったりのUSB-Cハブを探してみた! | osw48.com

MacBook ProがUSB-Cポートしかないから使えない?だったらワイヤレス環境を整えよう! - シンスペース

UI Live ! in Kanazawa に参加してきた

勉強会

90c0ba03fdaf930c0a4048bb06.doorkeeper.jp

まとまらないまとめ

  • こんな会が北陸で行われるのは良い
  • DeNADMM.comの人、それ以外の人ともいろいろ話せて良かった
  • デザイナの考えもいろいろ知れて良かった

インハウスデザイナーの新規事業開発での動き方

speakerdeck.com

elmyとCuncableのデザイン。

クライアントワークスと、インハウスの違い。

クライアントワークス

  • 作業分担されている。(ディレクタとかデザイナとか、エンジニアとか)
  • デザイナはディレクタ→代理店→クライアント(窓口)→クライアント(社長)
    • 鶴の一声でひっくり返る
  • ゴールが、前提や関係者で変わる。
  • UIデザイナ→サービスデザイナへの興味

インハウス

  • コストをかけず、スピーディーに。
  • 1チーム3人前後。意思決定スピートが早い。
    • ビジネス・デザイナ・エンジニア
  • 理解力・決断力が必要。
  • 役割の制約を作らず、できるところまでやる。
  • 最短のリリースを目指して全員が動く。
  • ビジネスの人と同じアプリを使ってみる。
  • iOS/Androidガイドラインの違いを考慮。
  • デザイナがXcodeを学習。(StoryBoardを使ってる)
  • GAなどで定量分析、ユーザ心理を定性分析。
  • PDCAを回し、壊すことを恐れない。

まとめ

  • インハウスのいいところ
    • スキルの幅が広がる
    • 本質的なモノ作り
    • ユーザの声をそのまま聞ける
  • DeNAでは100名ほどのクリエイターがいる。切磋琢磨できる環境。

質疑応答

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

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

www.slideshare.net

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

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

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

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

質疑応答

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

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

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は、思ってることを言いやすい環境。
    • 自分の作ったものに責任を持つ。
  • ターゲットユーザがチーム内にいない場合
    • まず、インセプションデッキを作った。
    • ある程度仮設を立て、作り、ユーザの動きをアナリティクスで見て、拡張していく。

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

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系に引っ張ってきたい。
  • 渋谷とかの大きな会社合同で説明会みたいなのをしては?地方の学生はまとめてあると助かる。

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

Meetup #45 - Kanazawarb

最初に感想

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

イントロ

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
  • Shippable
    • 安い
    • 設定がちょっと煩雑
  • Drone.io
  • BITRISE
    • モバイルアプリに特化
  • AppVeyor CI
    • Windowsサポート
    • OSSならfree
    • RDP接続可能
  • ブラウザテスト
  • SAUCELABS
    • SeleniumテストとUnitテスト
    • 手元のバージョンをリモートからテストも出来る。
  • BrowserStack
    • 上と似た感じ。どっちが良いかはわからない。
  • カバレッジ
  • Coveralls
  • CODE CLIMATE
    • 静的解析
  • 選び方
    • 金で解決
    • 人的リソースは有限。
    • 当たったサービス以外はそこまでリソースを割けない。
    • CI環境そのものが腐っていく。
  • 弊社の例
    • CircleCI + Codeshipの無料枠

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で通知できる。
  • 通知内容に多くの情報をのせる。連絡先とか、次のアクションとか。
  • 通知は日本語にした方が、日本人には伝わりやすい。

今月のブログ収支報告

感想

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

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

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

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

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 アクセス速度による課金っぽい。
  • 現状、既に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

第二回!チキチキ 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のマインドマップが使いやすい。
  • 他にKeepするもの
    • 設計の理由。WHY。
  • チームで話し合って、追加・削除をしてメンテしていく。
  • モノ・コト・モノ パターンと、ヘッダー・明細パターン
  • 図書館と本屋では、モデリングが違う。図書館では蔵書という概念があるが、本屋では数しか見てないはず。
  • 問題と解を得るために、分析モデルと設計モデルを分けて考える。

感想

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

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

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

勉強会

toyamarb.doorkeeper.jp

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

セッション

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

ビアバッシュ

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

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

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

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

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

富山合同勉強会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-RSCDIJSPとか。
    • HTTP/2
    • Server pushがServlet4.0の中に入ってくる。
    • CDIの範囲がMVC / JAX-RS / JavaSEに広がる。
    • 2つのパーツに分けられる。Full CDICDI 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ツールキットがある。
      • macEclipseの方がオススメ。
      • 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 rubyIDEを使わなくなった。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スプレッドシートをデータベースにすると楽。