イヤーカフのambieを買ってみた
ちょっと仕事中集中して作業したいけど、完全に耳を塞いでしまうといろいろと厄介なのでどうしようかと思ってたときに知ったのが ambie
他の人のレビューを見ると低音が残念とか書かれてたりするけど、それは事実
でいくつか曲を聞いてみたけど、ジャズが非常に良い
ピアノ曲も良い
落ち着いて作業用BGMとして流しておくことだけを考えれば最高のアイテムだと思う
集中して音楽を楽しみたいのなら別のイヤホン使うし、仕事中のBGM用に割り切って持つなら全然ありです
ロジクール 【国内正規品】UE900 密閉型インナーイヤーヘッドホン
- 出版社/メーカー: ロジクール
- メディア: エレクトロニクス
- この商品を含むブログを見る
チームビルディング?マネジメント?よくわからない
チームで働くということ
助け合い
- 全員で一つのEpic、Storyに取り組むスタンスで行きたい
今まではEpicやStoryがあったとしても誰か一人が主担当になって動いていてどうしてもチームという感覚が薄かった 今後はチーム全員で一つのEpic、Storyに取り組むスタンスで行きたい 保守チケットは暇な時にやる
私が死んでも代わりはいるもの
全員が全員の代わりになれるようにする
- 仕様を全員で共有する
新しい案件に取り組むときには内容をチーム全員に共有する できればチーム全員で案件について考える時間を取りたい 設計は二人で進める(サーバーサイドとフロントエンド一人ずつ) 設計が完了した時点でチーム全員に共有する 実装は全員で進める
- 技術を全員で共有する
サーバーサイドのエンジニアは時間がかかってもいいからフロントエンドのコードを書けるようにしたい 同じくフロントエンドのエンジニアは時間がかかってもいいからサーバーサイドのコードを書けるようにしたい まずは読めるようになることからでいい
へーきへーき!フレンズによって得意なこと違うから!
それぞれが得意な分野を伸ばして、苦手な分野は他の人で補い合えばいい それがチームで働くということ
無理はしない
頑張れる人が頑張ればよい
休みたい
一人で案件を抱えてたら休めない 全員で携わっていれば代わり代わりに休める
すべてを知っていたい
知らないことは怖いこと もし自分しかいなくなったときにわかりませんじゃ怖い ドキュメントに残すのも一つの手だが、普段からみんなで知識を共有することが一番コストが低い
最高のチームを作りたい
チームで働いているという感覚を持ちたい
責任の所在が曖昧にならないように
一人ひとりが責任を持って仕事をする 責任を取れと言うことではない 失敗は自分の責任だと思って反省する必要がある 他人のせいにするなということ
チームとして何を重視するか
生産性
そもそも生産性とは何であって何でないのか。
生産性とは 売上/コスト である。
つまり生産性を上げるには売上を上げるか、コストを下げるかの二択。
- エンジニアとして売上を上げるには機能を早くリリースして営業が売りやすくする。
- エンジニアとしてコストを下げるには機能を早くリリースして1機能のリリースまでにかける時間を減らすこと。
— 売上を上げる コードを綺麗にしておきたいが、どんなにコードが綺麗でも価値を生み出さないプロダクト(サービス)は意味がない。 とにかく機能を早くリリースするにはそれぞれが強みを活かしてそれぞれを補って動く必要がある。 まずは多少汚いコードだとしても良い。 もちろんリファクタリングの時間を取れるようにする必要はあるが、赤字垂れ流してるのにコードを綺麗にすることに熱心になってリリース遅くしてどうするの? 現実を見て!営業側にどれだけの負担をかけているのかを理解して! 自分が営業だったらどうする?「コードが綺麗なんです!」なんて営業トークしてお客さんがお金を払ってくれるの?コードが綺麗かどうかなんてどうでも良いでしょ?動くものがほしいでしょ?
— コストを下げる コードを綺麗に保つことがコストを下げることに貢献するなら、コードを綺麗に保つための施策を打てば良い。不具合を減らすことが出来て、営業の負担を減らすことができるならそうすれば良い。
コードが複雑すぎてコストが跳ね上がっているならそのためにどう動くべきかを考える。
新しい技術やアーキテクチャがあって、自分がいいと思ってやってみたいと思ったら、まずはチームに広めればいい。 チームメンバーがそれに共感しないなら、うまく伝わっていないか価値がないかのどちらか。 一人で進めるのは辛いが、それがコストを下げるために価値があると数人が感じたならそのメンバーで推進すれば良い。
— 機能を早くリリースする
機能を早くリリースする一番の近道は作らないこと。作るものを減らすこと。
— ユーザーストーリーマッピング p.14 より引用 アウトプットを最小限に抑え、最大限の成果とインパクトを獲得しよう
— ユーザーストーリーマッピング p.16 より引用 あなたがしなければならないことは、より早くより多くのソフトウェアを作ることではない。 作ると決めたものから最大限の効果とインパクトを生み出すことだ。
生産性とは個人で測るものではない。測れるものではない。
自分で作って自分で売ってるわけではない。 必ず誰かと一緒にやっている。
我々の仕事は何か
— ユーザーストーリーマッピング p.9 より引用 あなたの仕事は世界を変えることだ (中略) 製品に転化されたすばらしいアイデアは、それを使う人々からすれば、世界を少し、あるいは少なからず変えるものなのである。実際にそうなっていないなら、あなたの取り組みは失敗だ。
なぜ振り返りが必要なのか
- チームの改善
- 生産性を上げるために動けているかの確認の場
- 「どんな意識で仕事に取り組んでいるか」「どうすれば効率的に仕事ができるか」といった仕事の進め方について話し合う場の提供
チーム内ペアプロ
フロントエンドの人材が足りないのが、圧倒的にボトルネックになっている。 フロントとサーバーのペアでやってみたい
エピックのススメ方
http://qiita.com/Koki_jp/items/6aebc73bedd0a932dcb8 バックボーン(ストーリーの骨格) - PM ↓ ナラティブフロー(物語の流れ) - チームリーダー ↓ ユーザーストーリーの詳細出し - チーム全員 ↓ 詳細設計 - チーム全員(作業分担) ↓ 実装 - チーム全員(作業分担) ↓ テスト - チーム全員(作業分担)
マネジメントしようとしてはいけない?
- (悩み中
- リーダーの仕事は露払い?
- 仕事がしやすいように環境を整えること?
2段階認証について
2段階認証(2 factor authentication)
2段階認証(2 factor authentication)について
https://gist.github.com/asufana/daaa0477df93a5a2870c
https://gist.github.com/asufana/daaa0477df93a5a2870c
二段階認証(TOTP)メモ http://qiita.com/xylitol45@github/items/4f8418554a6550189341
QRコードのURLについて https://github.com/google/google-authenticator/wiki/Key-Uri-Format
Deviseを使っているRailsアプリに2段階認証を導入する http://qiita.com/Kta-M/items/e155f6e35e3e8274ff1e
考慮すること
- リカバリコード
- リカバリコードをDBに保存する
- リカバリコードでもログインできるようにする
- 使用したコードは無効化する
- 再度secret codeを作成してユーザーに提供する(?)
- 時計のズレ
- クライアントとサーバーで時計がずれていくことがあるので、ズレを吸収するためにどの程度ズレが生じているのかをサーバー側に保持しておく。次回以降はそこを起点とする。
ライブラリ
https://github.com/wstrange/GoogleAuth
import com.warrenstrange.googleauth.{GoogleAuthenticator, GoogleAuthenticatorQRGenerator}
/**
* Created by fscoward on 2017/02/01.
*/
object Main {
def main(args: Array[String]): Unit = {
val authenticator = new GoogleAuthenticator()
val credential = authenticator.createCredentials()
// この URL で QR Code を作成して読み込ませる
val url = GoogleAuthenticatorQRGenerator.getOtpAuthTotpURL("fscoward", "otp-sample", credential)
println(s"url: $url")
// QR Code に埋め込まれた secret key
val secretKey = credential.getKey
println(s"credential: ${secretKey}, verificationCode: ${credential.getVerificationCode}, scratchCodes: ${credential.getScratchCodes}")
// val totpPassword = authenticator.getTotpPassword(secretKey)
// println(s"totpPassword: $totpPassword")
// QRコードで読み込ませたときの secret key
val storedSecretKey = "JW6W56PKJJFDTRX6"
println(s"${authenticator.getTotpPassword(storedSecretKey)}")
}
}
- base32の秘密鍵を作成
- QRコードでクライアントに秘密鍵を渡す
- クライアントはGoogle Authenticatorを用いて生成
- サーバーもsecret keyを用いてtotppasswordを生成
Getting Started With Oauth 2.0
- 作者: Ryan Boyd
- 出版社/メーカー: Oreilly & Associates Inc
- 発売日: 2012/02/29
- メディア: ペーパーバック
- クリック: 4回
- この商品を含むブログを見る
ブラウザ自動テストについて
自動テストツール『Guarana』(スタンドアロン版) | 日本ナレッジ 技術WGのブログ
http://jasst.jp/symposium/jasst16hokkaido/pdf/S5-1-2-1.pdf
Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)
- 作者: 伊藤望,戸田広,沖田邦夫,宮田淳平,長谷川淳,清水直樹,Vishal Banthia
- 出版社/メーカー: 技術評論社
- 発売日: 2016/02/02
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (4件) を見る
自動化テストを考えるに当たって
目的を定義する
- 何のためにやるのか
- なぜやるのか
- 自動テストなのか
- 自動操作なのか
- http://qiita.com/PoohSunny/items/8641f24fa22e5b3beb16
結果として何が見たいのか
レポート形式での表示 スクリーンショット
Page Object Pattern
http://qiita.com/shimashima35/items/6d39be9a4fea05dcc84f
docker selenium
https://github.com/SeleniumHQ/docker-selenium
リグレッションテスト
https://www.htmlhifive.com/conts/web/view/pitalium/
キーワード駆動スクリプト(テスト)
言語をどうするか
webdriver io
SilkTest
Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)
- 作者: 伊藤望,戸田広,沖田邦夫,宮田淳平,長谷川淳,清水直樹,Vishal Banthia
- 出版社/メーカー: 技術評論社
- 発売日: 2016/02/02
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (4件) を見る
- 作者: Satya Avasarala,Sky株式会社玉川竜司
- 出版社/メーカー: オライリージャパン
- 発売日: 2014/09/18
- メディア: 大型本
- この商品を含むブログ (5件) を見る
- 作者: Dima Kovalenko,玉川紘子,太田健一郎,笹井崇司
- 出版社/メーカー: オライリージャパン
- 発売日: 2015/09/18
- メディア: 大型本
- この商品を含むブログ (4件) を見る
Angular2でHeaderにAuthorization情報を乗せる
Angular2によるモダンWeb開発 TypeScriptを使った基本プログラミング
- 作者: 末次章
- 出版社/メーカー: 日経BP社
- 発売日: 2017/01/18
- メディア: 単行本
- この商品を含むブログを見る
Angular2でFirebaseを使う
公式のものが用意されている
OAuth認証
twitterとかのOAuth認証を使うやり方は↓に書いてある。
angularfire2/5-user-authentication.md at master · angular/angularfire2 · GitHub
Angular2によるモダンWeb開発 TypeScriptを使った基本プログラミング
- 作者: 末次章
- 出版社/メーカー: 日経BP社
- 発売日: 2017/01/18
- メディア: 単行本
- この商品を含むブログを見る