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

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

感想

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

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

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

toyamarb.doorkeeper.jp

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

セッション

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

ビアバッシュ

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

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

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

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

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