新しい 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 とかを見てみました。 やっぱり、遅延なく見れます。 また、AndroidのYoutubeアプリ上部にあるキャストボタンから、Fire TV Stickに飛ばして、テレビで動画見ながら次に見る動画を快適に選択できました。
感想
5,000円ぐらいかけるだけで、テレビでプライムビデオ・Youtubeが見れるようになるので、かなりお買い得かと。 あと、なんだかんだで物理リモコンもついてくるのがいいですね。音声認識とか使うかわからんけど。
BuriKaigi2017に参加してきた
富山で.NETとJavaが一緒になったイベントに参加してきました。
.NETはほとんど関わりがないので、ずっとJavaのセッションにいましたが、オラクルの人と日本に2名しかいないJava Championの話を富山で聞ける、というのはすごいですね。 内容も、今までとこれからのJava SE / EEについてや、新しい開発手法、Microsoftのサービスを使ったデモなど、様々なことを再確認・学べました。 会場はそんなに広くなかったですが、Java側はそこまで過密じゃなかったので、ちょうどよいぐらいでした。
合同でのLTでは、別々のLTなのに、APIをSQLに→SQLをC#にと、神がかった流れもありました。
本番は懇親会、ということでタイトル通りのブリしゃぶも美味しかったです。 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してきて、手元でビルドしました。
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="ed=&json=true&page=${i + 1}`; + const url = `${pathNamePart}?category_id=all&status=all&sort=sort_asc&rank=all&tag=&keyword=&reviewed="ed=&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さんに捕捉され、補足いただきました。
@noboru_i 再実行すると日付は上書きされるようになってます👌
— ホームページビルダー (@r7kamura) 2016年12月26日
なので、
- const readAt = book.read_at; + const readAt = book.create_on;
にして、再度packしてリロード。そして実行すると、いい感じにグラフが作成されました。
こうやって可視化されるのは、微妙な気持ちになりますね。
というわけで
無事、インポートはできました。 新刊も、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、発表されましたね。
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なので、ちょっと高いですね。
Appleの認証が無い製品は、新しい端末とかOSで使えなくなったことがあるので、「認証」とか書いてあるものが安心ですね。
ただ、認証有りでこの種類のケーブルはあんまり見つからないですね。 「認証」を考えなければ、いくつかありそうですが。
ただ、どちらにしても0.5mのケーブルはなかなか見つからないです。
USB Type-Aポートの追加(USB HUB)
仕事デスクで仕事する場合、マイクとかCDドライブとか、いくつか付けられるようにしておきたいです。
Ankerはよく聞くメーカーですね。
HDMIでサブディスプレイを使うので、HDMIが付いたものも良いですね。 ただ、USBが2ポートしか無いので、ちょっと心許ないです。
このあたりは、いろいろ種類がありそうです。 デザインとかの好みで選んでもいいんじゃないでしょうか。
HDMI端子の追加
サブディスプレイを接続する場合、HDMIの端子が必要になりますね。 先程のハブでも、家で使う分には問題無さそうです。
ただ、外部の勉強会とかでプロジェクターに映して発表する場合も、HDMIケーブルまでは備え付けられている場合が多いです。 なので、持ち運びも考えると、HDMIのメスに変換できるものがあれば良さそうです。
Apple公式のものは、USB Type-CやUSB Type-Aも付いているアダプタしか無いようです。 また、¥7,400ということで、ちょっと高いですね。
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で早速で出てますね。
上に書いてたGriffinのものは、 新MacBook Proの充電ケーブルをMagSafe化「Snapnator」発表。スマホや他社製ノートPCなどUSB-C搭載機器にも対応 - Engadget Japanese に書いてあるとおり、電力的には15inchのものが保証されてないようなので、kickstarterのものに賭けてみます。
まとめ
ということで、ざっとまとめてみました。
思ってた以上にAmazon上で検索するのが難しいっす。
もうちょっといろいろ調べて追記していこうと思います。
参考
新型MacBookで使いたいオススメのUSB-C関連グッズ | 目くじら日記
UI Live ! in Kanazawa に参加してきた
90c0ba03fdaf930c0a4048bb06.doorkeeper.jp
まとまらないまとめ
インハウスデザイナーの新規事業開発での動き方
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に情報を詰め込み過ぎない。
「使いやすい」だけではユーザー体験が上げられないサービスでのデザイン手法
Material Designスタイルでプレゼン。
グラフィック→WEB/INTERACTIVE→サービス
iPhone出て早9年 当時は、専門的なデザイナがおらず、エンジニアだけで作っていた。 今では、UIデザイナの地位が確立され、ガイドラインが作られた。
1→2的なグロースハック系は、「使いやすい」というのが役立つ。 0→1的な新規事業では、雰囲気みたいなものが大事。
UI/UXの記事を鵜呑みにして適用しても、うまくいかない。
さんぽジスタを作るときに、「使いやすい」ではただの歩数計になってしまう。
今日の歩数:達成感・やる気を起こさせる。 キャラ:「何が変か」を具体的に調整していく。 背景:画像検索で世界観を知る。
自分で使ってみて、つまらなかったので、コンテンツ追加。ブラッシュアップ。
質疑応答
- 自分で使って、客観的に見る。
- 何か変えてみて、また使ってみる。
- 社内でターゲットになるような人に使ってみてもらう。
- DeNAは、思ってることを言いやすい環境。
- 自分の作ったものに責任を持つ。
- ターゲットユーザがチーム内にいない場合
- まず、インセプションデッキを作った。
- ある程度仮設を立て、作り、ユーザの動きをアナリティクスで見て、拡張していく。
これからの「フロントエンド開発」の話〜(デザイナー所属の)フロントエンドエンジニアでも知っておきたいこと〜
認証会員基盤のエンジニア フロントエンドのチームリーダー
金沢すきま旅というのを作った。
エンジニア目線な話
UXセミナーのストーリーボードを見て衝撃を受けた。
エンジニアは、細かく検証し、問題があればすぐ修正したい。
Dockerをローカル開発環境として使う。 継続的インテグレーションの流れを、デザイナにも知っておいて欲しい。
質疑応答
- Dockerを布教中
- ハンズオンを開催し、体験してもらう
- GUIもあるおかげか、デザイナ側も抵抗感が少なそう
- ストーリーボードの何が衝撃を受けたのか
- いままでは、完成されたワイヤーから関わっていた
- そのワイヤーに至る理由が見えるので、理解できる
フロントエンドエンジニアが、機能開発の企画オーナーとなってリードした話
エブリスタに関わっている。 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 に参加してきた。
最初に感想
- あらためて、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
- CircleCI
- CodeShip
- GitHub / Bitbucket
- Shippable
- 安い
- 設定がちょっと煩雑
- Drone.io
- BITRISE
- モバイルアプリに特化
- AppVeyor CI
- ブラウザテスト
- SAUCELABS
- SeleniumテストとUnitテスト
- 手元のバージョンをリモートからテストも出来る。
- BrowserStack
- 上と似た感じ。どっちが良いかはわからない。
- カバレッジ
- Coveralls
- Travis CI / CircleCI対応
- CODE CLIMATE
- 静的解析
- 選び方
- 金で解決
- 人的リソースは有限。
- 当たったサービス以外はそこまでリソースを割けない。
- CI環境そのものが腐っていく。
- 弊社の例
- CircleCI + Codeshipの無料枠
JAWS-UG金沢 第10回勉強会 に参加した話
https://jawsug-kanazawa.doorkeeper.jp/events/43543
AWSトラブルシューティング!早期復旧のための心掛け
と同じ資料っぽい。
- 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に飽きた。
- インフラ持ってれば、試せることが増えそう。
- 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
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 に参加してきました。
表示してたスライドは、たぶんこれみたい。
Modeling in the Agile Age - JP
メモ
- 全体像を知るために、モデリングが必要。
- 捨てるモデルと、保存するモデルを分ける。
- コードからリバース出来るものは、捨ててしまう。
- コードに現れないものは、保存してメンテする。
- Keeps
- Architecture
- Domain Model
- Key UseCases
- Architecture
- システム全体の構造的な表現
- MVCの依存関係を、パッケージ階層で示すなど。
- Domain Model
- 問題領域の概念とそれらの繋がり
- 現実世界をモデリングするのは難しい。対象となるシステムがベースになる。
- 唯一正しいモデル、というものは無い。
- Key UseCases
- アクターが大事。"ユーザ"ではなく"開発者"など絞る。
- コミュニケーション図で、何が同動くかを記述する。
- astahのマインドマップが使いやすい。
- 他にKeepするもの
- 設計の理由。WHY。
- チームで話し合って、追加・削除をしてメンテしていく。
- モノ・コト・モノ パターンと、ヘッダー・明細パターン
- 図書館と本屋では、モデリングが違う。図書館では蔵書という概念があるが、本屋では数しか見てないはず。
- 問題と解を得るために、分析モデルと設計モデルを分けて考える。
感想
メンテ出来なくて、特に重要じゃないモデルは、書いても捨ててしまえばいい、というのはいいと思った。 書いてもメンテしなきゃ、と考えると書きづらいし。
また、用語集・辞書を最初に作って、それをメンテしていくのはやっぱり重要なんだなーと。 メンテに際しては、誰もが見える場所で、更新が通知されることが重要っぽい。(みんなで作ってる感というか。 ただ、誰もが見える場所とはいえ、プロジェクト関係者以外に見えたらダメだと思うので、どこに置けばいいのかなーと。
「リモートチームでうまくいく」倉貫義人さんと語らう会に参加しました。
に参加してきました。 自分もリモートワークしてるので、そのへんのつらみの解決策が聞ければなーとなんとなく考えてました。
セッション
- 求人で来る人が地方が多い。都内は比較的少ない。
- 会社としては、リモートワークが前提。都内にいても、行っても行かなくてもいい。
- 間口広げるために、募集をリモート前提にした。
- Skypeで音声繋ぎっぱなしは、人数が多くなるとつらい。
- Results-Only Work Environment アメリカのものは、完全に個人のもの。
- ただ、アメリカでも個人主義の考え方をやめ始めている。チームで助け合う。
- エンジニアの評価は、短時間では出来ない。悪いコードを量産した方が、短期的には良く見える。
- チームでやるとは、スポットの仕事をさせるわけではない。受発注ではない。
- リモートワークという言葉の定義を浸透させたい。クラウドソーシングではない。
- 会社とは概念的なものであり、ソフトウェアで表現できる。
ビアバッシュ
ビアバッシュでは、いろんなことを聞けましたが、立ってピザ食べながらだったのでメモもなく、印象に残ってるものだけ。 (ニュアンスが異なっていることは多々あると思います)
- SonicGardenでは、営業活動をほぼ(?)していない。お問い合わせから依頼来る。
- これまで、新卒採用はフォームすらなかった。その中で応募してきた人たちなので、その教育などは他では流用出来無さそう。
- セキュリティ対策とかでガチガチにするぐらいなら、そういうのが必要無い人を採用するところにコストをかける。「なんでそんなに信頼ならない人を採用してるの?」
- 毎週の振り返りで、「先週は夜遅くまでやって、ここまで出来ました!」がKではなくPである、という風に教育していく。何が良い・悪いなどの社風はそうやって受け継がれていっている。
- 基本リモートワークしてるので、会社の椅子的なキャパが余ってる。家を借りようかと考えてる。
- 会社では、Skype打ち合わせが輻輳するようになってきている。(他の打ち合わせの声がうるさい、みたいな)
- SonicGardenは裁量労働制。
- リモートワーク推進協議会的なものを進めている。"リモートワーク"の言葉の定義を正しく認知してもらう。推進する会社を増やしていく。
なんとなく、SonicGardenはエンジニアにとっての理想郷を目指している感じは受けました。 さらにそれが一般認知されており、お客も採用も上手く回っている感じ。 売上の向上とかを至上命題にしなければ、こんな会社の運営の仕方もあるんだなぁと。
全員がリモートワーク前提でやっている、というのはかなりうらやましい。 Monstar Labでは、ほとんどが中目黒で、他に島根(4人)、鹿児島(1人)、富山(自分)という状態なので、リモートがマイノリティ。 なので、認識の内外で、リモートだから、、、という遠慮はある気がしてる。 なので、SonicGardenのやり方がそのまま持ってくることは出来ないけど、参考になるところを取り入れていきたいとは思う。
先週の富山合同勉強会もそうだけど、こういった有名な人の話を富山で聞けるってのはありがたいなー。 運営側はお疲れ様でした。 2週間後には平鍋さんの話も聞けるので、楽しみ。 Meetup #42 - Kanazawarb