Snapnator が届いた!

新型のMacBook ProにMagSafeを取り戻すために買った、 Snapnator が届きました。

www.kickstarter.com

今見ると、 2016/11/04 にKickstarterでbackしてました。 半年ぐらいで届いたんですね。

外箱はこんな感じ。微妙に凹んでましたが、国際郵便でプチプチに包まれてただけなので、仕方ないっすかね。

説明書と本体。

MacBookにつなげてみたらこんな感じ。

MacBookとの間に微妙な隙間空いてるし、微妙に汚い。。。

隙間空いてるせいか、動かすとちょっとぐらぐらする感じもありますね。

てきとーに引っ張ったら、磁石でちゃんと外れました。

ピンぼけしてますが、磁石の部分はこんな感じ。

で、これはなんだろう。。。?

Twitterとか見てると、熱くなるとかって話がありましたが、そもそも製造精度が微妙な感じ。 あと、思ったよりMacBook側の出っ張りが大きいっすね。

・・・使わないかなぁ。

新しい Fire TV Stick を買ってみた

ここ1,2週間はやる気が出なくて、Youtubeばっかり見てます。

寝室ではchromecastで快適に見れているのですが、リビングのFire TV Stick(旧バージョン)の調子が悪く、音と映像がずれるようになってました。

新しいのが出るということで待ってたのが、ようやく届きました。

Fire TV Stick (New モデル) ってやつですね。

最近は(?)、名前は変えずに"New"とかつけるのが流行ってるんですかね。(iPadとか)

というわけで、開封しました。

開けてみた

やっぱ、箱でっかいっすね。

外箱はこんな感じ。

で、中には2つ折りで黒い入れ物。

全部出してみた。 電池も、Amazonの電池。

上が古いやつ。下が新しいやつ。 ちょっとでかくなったみたいですね。

使ってみた

とりあえず、設定して、使ってみました。

まずは、プライムビデオを。

最初はネットワークの調子を測ってたのか、動画がかなり荒かったのですが、数分もしたらきれいな画質になりました。

で、感動したのが10秒送り。 全然遅延なく、押した瞬間10秒後の動画が始まる。 Youtubeとか、nasneの動画をAndroidタブレットで見るのに慣れてると、感動的な操作性。

次はYoutube。 最近はまってる カズチャンネル/Kazu Channel - YouTube とか 瀬戸弘司 / Koji Seto - YouTube とかを見てみました。 やっぱり、遅延なく見れます。 また、AndroidYoutubeアプリ上部にあるキャストボタンから、Fire TV Stickに飛ばして、テレビで動画見ながら次に見る動画を快適に選択できました。

感想

5,000円ぐらいかけるだけで、テレビでプライムビデオ・Youtubeが見れるようになるので、かなりお買い得かと。 あと、なんだかんだで物理リモコンもついてくるのがいいですね。音声認識とか使うかわからんけど。

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

感想

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

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