csv 形式のデータを DynamoDB に import したい
どうも。いつもよりダイエット気分が高めな僕です。
パフォーマンス改善をするにはまず観測から...ということで、だいぶ前に wi-fi 接続できる体重計を購入し観測 & ロギングする作戦をすすめていました。しかしこの体重計、データがwithingsというサービスにストアされることになります。APIが公開されているものの、自分でデータを触ろうと思うと途端にめんどくさくなります。ということで自分がアクセスしやすいところにストアしてしまうことにしました。
今回は 1. 過去データを DynamoDB に移行する をまとめた記事です。
やったこと
過去データを取得しよう
withings は親切なサービスで、画面ぽちぽちするだけで過去のデータを丸ごと csv export することができました。
日付,"体重 (kg)","体脂肪 (kg)","骨量 (kg)","筋肉量 (kg)","体水分率 (kg)",コメント "2019-11-19 10:09:38",77.00,,,,, "2019-11-18 22:54:40",78.20,,,,, "2019-11-17 16:42:13",77.80,,,,, "2019-11-13 15:45:27",77.40,,,,, "2019-11-11 09:45:55",77.20,,,,, "2019-11-07 10:06:58",77.00,,,,, "2019-11-04 22:02:42",77.80,,,,, "2019-10-30 08:32:27",78.00,,,,, "2019-10-28 10:09:25",77.20,,,,, ...
最近体が重いなーと感じてましたが、物理的要因だったようです
DynamoDB に import したいのだが...
元ネタは取得できましたが、残念なことが発覚。DynamoDB に直接 csv を import することはできませんでした。ぱっと調べた感じで取りうる選択肢は3パターン。
- S3 に cvs をアップロードして、AWS Data Pipeline を経由して import
- AWS CLI を利用して import
- AWS SDK を利用して import ( put_item のほうが正確かも)
どうやったか
デスクトップを作り替えたばかりでローカル環境がすっからかんでキレイな状態でした。そのため、環境整備もかねて AWS SDK を使うことにしました。よく見る Python + boto3 ( AWS SDK for Python ) の組み合わせです。内容は csv を読み込んで 1レコード毎に put_item する感じです。
やったこと一覧
※ローカル環境整備は除外
- DynamoDBに MyWeight テーブルを作成
- csv を参照するとわかるように、有効な値がある列は
日付と体重 (kg)のみです。- 今回作るテーブルもデータにあわせて datetime, weight と最低限のカラムにしました。
- 今回作るテーブルもデータにあわせて datetime, weight と最低限のカラムにしました。
- csv を参照するとわかるように、有効な値がある列は
- csv header を日本語からカラム名に変更
日付->datetime体重 (kg)->weight
- csv の値がない列を削除
- AWS アクセスのため、IAM で DynamoDBのアクセス権限を付与したユーザを作成
めんどくさかったので一度のみの実行かつ、誤操作リスクも低かったため、AmazonDynamoDBFullAccessを割り当てました。
- 適当に Python のスクリプトをかきかき
- 実行
- 一時的に作成していたユーザを削除
結果
csv を DynamoDB に入れることができました。わーい🎉
これでデータがいじりやすくなりました。しかし、データを入れたとたん weight 列から重みを感じるようになりました。錯覚だとよいのですが (´-ω-`)
コード類
d.py
import boto3
import csv
import json
CSV_PATH = './weight.csv'
DYNAMO_TABLE_NAME = 'MyWeight'
ACCESS_KEY = 'xxxxxxxxxx'
SECRET_KEY = 'yyyyyyyyyyyyyyyyyyyyy'
REGION = 'xx-xxxxxxxx-x'
def main():
session = boto3.Session(
aws_access_key_id=ACCESS_KEY,
aws_secret_access_key=SECRET_KEY,
region_name=REGION
)
dynamo = session.resource('dynamodb')
table = dynamo.Table(DYNAMO_TABLE_NAME)
with open(CSV_PATH, 'r') as f:
for r in csv.DictReader(f):
j = json.loads(json.dumps(r))
table.put_item(Item=j)
if __name__ == "__main__":
main()
weight.csv
datetime,weight "2019-11-19 10:09:38",77.00 "2019-11-18 22:54:40",78.20 "2019-11-17 16:42:13",77.80 "2019-11-13 15:45:27",77.40 "2019-11-11 09:45:55",77.20 "2019-11-07 10:06:58",77.00 "2019-11-04 22:02:42",77.80 "2019-10-30 08:32:27",78.00 "2019-10-28 10:09:25",77.20 ...
余談
2. 今後のデータを 1日1回 withings API 経由で取得して、DynamoDB に反映する。 につづく...予定
jQuery: [] を含む name要素の selector
やりたいこと
jQuery で <input name="user[password]"> な要素を選択したい
ためしたこと
普通に書くと Syntax error になる。
> $("[name=user[password]]")
> Uncaught Error: Syntax error, unrecognized expression: [name=user[password]]
しらべた
ピッタリの記事があった。感謝。
http://ria10.hatenablog.com/entry/20130203/1359900755
できた
$("[name=user\\[password\\]]")
jQuery.fn.init [ ... , selector: "[name=user\[password\]]"]
WhoMeetsReact#1 に参加してきました。
参加したしたもの
WhoMeetsReact
参加理由
このTweetをみて「会場提供なら協力できるかな...」という優しい心が芽生えました。
【募集】ちょっとほんまにお金ないので、今週か来週かの休みの日にでも有料でReactハンズオンやるので、参加してくれる人いません…？
— こばしゅん (@ksyunnnn) September 19, 2019
- フロントの人と会話するためにReact知っておきたいデザイナー
- フロント少し興味あるバックエンド
- Reactから始めたい駆け出し
とかくらいの、本業で(続く)
というのが1割で、残りはReactを触るきっかけづくりです。
運営の方々
- 主催
- アドバイザー / ヘルプ
- shotaCoffeeさん
- 自らを追い込んでレベルを上げる強くてストイックなエンジニア。
- あんどさん
- アイコンそっくり。ピアスがかわいい。
- shotaCoffeeさん
内容
AM (11:00 - 12:00)
Codesandbox を利用して React の雰囲気を体験しました。
- Codesandbox が便利でした
- ワンクリックで動作環境が立ち上がる。
- メジャーなFW(React, Vue, Angualr, etc)は大体揃っている。
- コードを同時編集できる。
- Codesandbox上で作成したプロジェクトを、GitHubのPublic Repository として取り込める。
PM (13:00-17:30)
- TODO リスト作成
- 前半: 大まかな機能を実装
- 後半: 前半に作成したものをベースにペアプロしながら拡張
AMと同様のCodesandboxを利用して開発しました。LocalStorageでなく、jsonboxというサービスを利用してデータを永続化したのが特徴的でした。jsonboxについてはデータ中身さえ気にしなければ利便性の高いサービスでした。
懇親会とその後とその後 (17:30-)
開発状況や手法、WordPressの知見、求人/採用状況、コイバナなどなど脱線しつつ盛り上がりました。活動範囲が違う人と話すのは知見が広がって楽しかったです。
感想
内容的にはこの辺りの記事と同じ粒度でした。しかし運営メンバーが的確にフォローしてくれたことで、疑問や躓きをスムーズに乗り越えることができました。そのおかげもあり久しぶりに触れる Frontend(React) はとてもおもしろかったです。今日の影響でなにか作りたい欲も高まり、React入門 + モチベージョン向上 の2面で得るものが多い Handson となりました。次回は未定ですが、こばしゅんさんのお財布事情によって開催されるかもしれません。
銀座Rails#12@DeNA に参加しました。
参加した勉強会
なんと 銀座Rails は1周年だそう！
🎉Happy First Anniversary!🎉
そして、1周年記念(?)で リンクアンドモチベーション さんと DeNA さんの粋な計らいがあるようです。 やきうの民(とくにDe)は #ginzarails でつぶやいておくと素敵なことがあるかもしれません！⚾
会場
渋谷(論理銀座)のDeNAさんのオフィス。
きれいでキン肉マンがいたのが印象的でした。(写真撮り忘れ)
本日は渋谷で銀座Rails.
— yrinda (@yrinda_) August 29, 2019
(今回の論理銀座はちかくてうれしい☺️)
内容
出張Railsウォッチ in 銀座Rails
Masato Mori さん (@morimorihoge)
OreKanegon さん (@hachi8833)
感想
Rails6の複数DBの解説で、database.ymlやmigrationオプションのはまりどころをまとめてくださっていました。現在の環境では複数DBに縁がありませんが、頭の片隅に置いておきます。時間の関係でサッと流されましたが、きになっているGemの中に自分も Production で使おうとしている Jets あったのでうれしかったです。(そしてここで ruby-jp の serverless チャンネル で Jets の知見を流してくれている方だと気づきました。ありがとうございます！)
Rails使いのNuxt.js入門
nof さん (@ssh_nof)
感想
きにはなっているもののまだ触っていなかった Nuxt.js の入門編。わかりやすくまとまっていました。週末は npx create-nuxt-app？
プログラマがコードを書きながら考えること
Junichi Ito さん (@jnchito)
今回実装されたクローラー
感想
クローラーのライブコーディング(動画化したものを視聴)でした。伊藤さんが動画内の自分に突っ込みされていて面白かったです。”自分が実装するときとおなじ部分、違う部分を気にしてみてね”と仰られていたのでざっくりまとめてみました。
ちがった部分
にていた部分
この発表は気づきが多くとても勉強になりました。
余談
にぎにぎしてストレス発散するやつを入手
— yrinda (@yrinda_) August 29, 2019
けっこうきもちよい😊
DeNAさんありがとう#ginzarails pic.twitter.com/jAr4cKXA9J
Tama Ruby会議01 運営してきた
Tama Ruby会議01とは
地域RubyコミュニティのTama.rbが2019年7月6日に開催したはじめてのカンファレンス。
多摩と名を関しているが、開催場所は渋谷(曰く論理多摩)
tama-rb.github.io
なんで運営に参加したのか
2019年1月ごろにTama.rbのSlack内(コチラ)で運営者募集していたので、手をあげた。
理由は"やったことがないから"という単純な理由。
これが自分にとっては初めてのカンファレンス運営経験となった。
運営してよかった点
気づきや提案に対して、即座にフィードバックされる嬉しさ
運営メンバーは8人。所属もバラバラだったためオフラインミーティングのハードルが高かったのだが、意識の高い(?)メンバーが揃っていたため、勉強会の後や休日に集合したりとなんだかんだで集まりは非常に良かった。Slackがあるとはいえ、やはり直接会話すると話が早い。時折脱線するも、個々の気づきや提案が即時に取り込まれていくことは非常に嬉しく、おもしろい経験だった。
運営してつらかった点
情報共有不足
前述に続くのだが、オフラインで集まると議論がすすむ。すすむのだが、誰もメモや議事録をまとめていない日があり、後日Slack上で「xxxってどうなったっけ？」「Aじゃない？」「いや、Bだよ！」なったことが数回。また、一部のメンバー間のみで決めた事項が展開されないこともあり、これも同様の事象が発生。
-> 議事録かこうね！(自戒)
まとめ
Tama Ruby会議01 の運営経験を通してカンファレンス運営は大変だ、ということを実感した。初開催ということも大変さを押し上げる要因だったと思う。
反面、無事に開催できたことの嬉しさはひとしおだった。また、運営メンバーには個性的で最高なRubistがそろっており、運営活動を通してその背中を眺めながら"もっと成長したい"と強く思った。
次回も開催されるなら、また運営に参加してみたい。
探しています
探していますみつかりました。
2点お忘れ物がございます。
— yrinda (@yrinda_) July 6, 2019
1. ype-c、HDMI変換ケーブル
2. 傘
心当たりの方はご連絡ください。#tamarubykaigi01 pic.twitter.com/PcpmXzE9Ys
参加レポート
TODO: Write
Developers Summit 2019 Summerに参加してきた
Developers Summit 2019 Summer？
通称デブサミ
https://event.shoeisha.jp/devsumi/20190702
おすすめ
編集がめんどかったためメモをそのまま載せています。
長文のため、個人的なおすすめのセッションをピックアップ。
- 開発系
- インフラ系
- 組織系
聞いたセッション
- メルカリのエンジニア組織とマイクロサービス化への取り組み
- アプリケーションの全てを計測せよ！〜DevOps文化醸成における計測の重要性
- 新卒社員研修からはじめるアジャイルソフトウェア開発チームのつくり方
- 組織にテストを書く文化を根付かせる戦略と戦術
- Infrastructure as Codeでインフラチームはもっと強くなる 〜ぼくのかんがえたさいきょうのいんふらちーむ〜
- 顧客が使いたくなるアプリを作る方法
- エンジニアとマネージャーは、いつも勝負をしているのだと思う
- クラウドネイティブ時代のマルチテナントアーキテクチャとデータ設計
- 本気で実践している人たちにしかできない話が聞きたい
- 後日: 参加して
以下メモと簡単な感想
メルカリのエンジニア組織とマイクロサービス化への取り組み
キャリア
職務
- Front, Back, SREの職種割からドメイン毎に縦割りにしようとしてる
システムのマイグレーション
- オンプレからの移行
- GCP
- Micro Service Archite
感じた事
- メルカリのキャリアラダー見てみたい
アプリケーションの全てを計測せよ！〜DevOps文化醸成における計測の重要性
DevOpsやってますか
こんなDevOpsはいやだ
- スーパーエンジニアに2人分の働きをしてもらう
- スタートアップ時は必要かもしれないが、スケールしない
- 社内でDevOpsを推進しようとしても、現場に浸透しない
- 推進者 -> App... | インフラ...
- 組織のサイロを解消しないといけない
- 推進者 -> App... | インフラ...
- 自動化ルールを導入すればいいんでしょ？
- ツールは行動に影響を与えるが、DevOpsの十分条件でない
DevOpsは文化
DevOpsの文化とは
- 個人同時のコラボレーション
- チーム同士のアフィニティ
- DevOpsというチームやロールはない <> SRE
- ゴールを共有する人たち全てが関係者
- Dev, Ops, 営業, マーケ
- 最終形態ではなく、継続的なプロセス
ツールを活用しているかが重要 ステークホルダーが関わり合って改善し続ける文化
秘伝のタレを各人が守っている
- どうするか
スタート
- 現状をしり共有認識を得る
- アプリケーションを計測
- 現状をしり共有認識を得る
DevOpsにおいて計測は文化情勢の手助けとなる
- ステークホルダーがこれらを計測する
- システムの変化
- 日常的な変更を前提としている
- ビジネスの変化
- 顧客の思考・行動は日々変化する
- システムの変化
- 変化を計測した情報がDevOpsに関わる人々の間で何をすべきかの共通認識となり、協業が生まれる
こんなことが実現可能に
- スーパーエンジニア(辛い人)が減る
- 組織のサイロの解消
- 自動化ルールも進化を発揮
DevOpsの成熟度評価基準
- CALMS
- Measurement(計測)
- 高度に成熟したDevOpsチームの66%はキーとなる
- システムメトリックの計測を自動化し、34%はビジネスレベルの計測をオンデマンドで取得可能な状態にしている
- Measurement(計測)
- 高度に成熟していれば
- 頻繁にコードをデプロイ
- コミットからデプロイまでのリードタイムが短い
- 更新っぱい率低い
- 復旧早い
DevOps計測のチャレンジ1 ツールのサイロ化
- ポジションによって、計測したいことが異なる
- それにより利用ツールが分散
- 計測したいことは実際には
- 綿密に関わり合っているのでツールも共通化するのがベスト
- それにより利用ツールが分散
計測チャレンジ2 複雑で動的なシステム
- 従来のシステムと比べて構成要素が多く、動的に変化する
計測チャレンジ3 そのために時間をとる
New RelicにとるDevOpsの計測ソリューション
フルスタック
- 全てを計測し、見通すための場所
特徴
- DevOpsに必要な全てを計測できる
アプリ、インフラのパフォーマンス計測
カスタマーエクスペリエンス
ビジネスゴールの計測
クライドに最適化される
- クラウドコスト
- サービス利用状況
導入が楽
- Agent入れるだけ
ガイド
- 手を付ける場所がわからない
- ソリューションガイド有
New Relic自体のDevOpsを実践経験をもとに。
準備
- SLO策定
- アラート設定
- 活性化
- Dashbordで可視化
- 最適化
- アプリ、体験、インフラなど
まとめ
- DevOpsは動的な環境変化に対して上手く対処するための司式文化
正しく計測することで成熟度や硬貨の工場が期待できる
-
- バックエンド側の人間もフロント側の品質を意識できる
感じた事
- DevOpsの認識を正した
- 複数チームが協力するのがDevOpsって感じだったが、組織全体での活動だった。
- New Relic入れてみたい
- DevOpsへのソリューションガイドがある
- 部門毎に利用ツールや情報が分散している問題を解消できそう
新卒社員研修からはじめるアジャイルソフトウェア開発チームのつくり方
ざっくり
- セゾンの新卒研修
- BizとDev役員の指摘のベクトルが別.
- 内容をどっちに倒すか困った
- BizとDev役員の指摘のベクトルが別.
- 研修者のレベル差
- ペアプロさせた
感じた事
- 前職ネタ
組織にテストを書く文化を根付かせる戦略と戦術
- 疲弊仕切った現場
- 荒みきったコード
- 屋根の上に更に増築..
- 爆弾処理のようなリリース
テストが無いコードはレガシーコード
レガシーコードの定義
- テストがないコード
- 言語は関係ない
- テストがないコード
2つのならわし
- テストを書く時間がない
- 因果ループ図
- 自動テストから入れる
- 自動テストで浮いた時間で更にテストをかける良いループに入れる
- 自動テストから入れる
- テストを書く時間がないのではなく、テストを書かないから時間がなくなるのです。
- 因果ループ図
- 動くコードに触れるな
- 現代において、関連ソフトのアップデートが入るので勝手に落ちる可能性がある。
- 動かなくなっていくので競争力がおちる
- コードフリーズしても動かなくなる
- Edit & Pray(しんどい) には死が待っている
- Cover & Modify
- リリースに自信がもて、すぐに巻き戻せるようにしたい
- この要素の一つがテスト自動化
- テスト文化がない企業にテストを書かせるようになるためには、2-5年かかる
銀の弾丸はない
- 地道に.
イマココから始める
- Tobeではなく、AslsとNotTobeから始める
- 隣の芝は青い。きにしないこと
- ひとは自分の速度でしか成功できない
- プロジェクトも同様
- まわりがやってるから。は劇薬
- 刺さりすぎる
理論武装する
- 不具合の発見が遅れれば遅れるほどコストがかかる
- TDDすると
- 15-35%ぐらいかかるが、不具合8割減る
- TDDはデバッグ時間がへる
テストは品質をあげない
- 品質がわかるようになる
- 体重計のよう
- わかるところを増やしていく
- 品質を上げるのは設計とプログラミング
- 再設計とリファクタリングをテストで支える
テストでは品質は上がらないですと。テストはあくまでも品sつを上げるきっかけ。品質をあげるのはプログラミングです。昔から層。
組織にテストを書く文かを根付かせる 戦術編
みちしるべ
- レガシーコード改善ガイド
- コードを変更するためにはテストを整備する必要がある。
多くの場合、テストを整備するためには、コードを変更する必要がある。
- コードを変更するためにはテストを整備する必要がある。
- レガシーソフトウェア改善ガイド
- 改善ガイドより抽象度が高い
- 3つ選択肢
- リファクタリング
- リアーキテクエィング
- 一部を切り崩していく
- ビッグ・リライト
- 成功確率ひくい
- 旧システムとのsyncとか。期間が伸びていくと死ぬ.
- 成功確率ひくい
どこにテストを書いていくか
- 一番やばいところは？
- 困っているところは？
- 金
- 個人情報
- 新機能
- バグ修正
- おすすめ
- 不具合が発生するポイントは固まっているため
- 傷んだ部分 or 価値の高い部分
自動化コストを見積もる
- トリアージ
- テストケース, リスク, 受動テストのコスト, 自動化コスト
どうやって書いていくか
- 書籍
こだわるな
- 最初から全部やらない
こだわろう
- 良いユニットテストの指標にも優先度がある
- 再現、繰り返し可能
- 独立している
- 他はそれからでよい
設計の可動域を確保する
自ら体験して、背中を見せてテストを書く
感じた事
- レガシーコード = テストのないコード って概念に納得した
- とりあえずテストを書く
- 短期的に見るとテストはコストだが、継続した開発サイクルにおいては、テストをしない事のほうがコストだと感じた。
レガシーコード改善ガイドを読む- ぽちった。
nfrastructure as Codeでインフラチームはもっと強くなる 〜ぼくのかんがえたさいきょうのいんふらちーむ〜
課題
- 構築手順のロスト、陳腐化
- ノウハウが蓄積しない
- オレオレ作業
- 人の作業が多い
チームメンバーなら誰でも対応可能な、交換可能なしくみ・組織にしていく必要がある
IaC (Infrastructure as Code)
リソース管理
- Terraform, Ansibleを両用
- Ansiblehはクラウドリソースの管理がし辛い
- Terafformは状態を持つが、Ansibleは持てないため
- クラウドリソース管理はTerraformがデファクトになりつつある
- 情報収集やすい
本番環境以外の管理
開発環境は検証などでリソース変更ありがち 厳密にIaC管理すべきだが難しい そこで - 本番環境以外はDevでも触れるようにしているが、修正内容を確認できるようにした - Terraformは状態を保持しているので、リソースを修正したら差分が発生する - terraformingなどで差分抽出 -> BotでSlack通知
インフラチームの方針
- マネージドサービスを使う
- 自前ツールを作らない、まず探す
- それでもなければ作る
GCP上のCron
感じた事
- 序盤にいっていた交換可能なしくみ・組織を実現しようとしていた。
- そのためにいろいろと思考錯誤をしていた
- 自作ツールの考えについては納得
- とはいえ自分で作るとその分技術が上がるメリットもあるのでTPOを考えるようにする
- RUNDECK便利そう
- AWS環境下でも使えるのかな
顧客が使いたくなるアプリを作る方法
顧客が使いたくなるアプリを作る方法
伝説の定義はPOとの共同作業
プラクティス集
- Open Practice Library
- 事例
取り組むべき課題の掘り下げ
- 顧客が存在するのか
- 解決に値する(💰をはらってもいい)課題が見いだせるか
課題に対する解決策が妥当か
サロン立ち上げ失敗
- 会計士狙い
- SNS以前かつ、会計士は内気
- まったくつかわれなかった
- SNS以前かつ、会計士は内気
- 会計士狙い
仮設を検証可能な形式で表現する
- プロダクトバックログアイテム(PBI)の形式へ落とし込む
- 顧客に対しる理解
- ビジネスモデル作成
- メンバー感で共有理解の情勢(合意形成)
- ここでつまづきポイント
- POとの合意形成を促すしかけが必要
- MBPを定義
- プロダクトバックログを明確化
POとの合意形成を促す仕掛けの作り方
- 複数のプラクティスを組み合わせたワークショップ
- イベントストーミング
- Open Practice Library に乗ってる
- contributeできるぜ
まとめ
- 製品リスクに対処
- アジャイル開発の説明、POとの向き合い方あたり
感じたこと
- Open Practice Libraryを覗いてみよう。
エンジニアとマネージャーは、いつも勝負をしているのだと思う
- 技術力の高いエンジニアを管理するマネージャー
きっかけ
- 優秀なメンバーの転職
- 自分に腹がたった
よくある悩み
- メンバーの成長
- マネージャーの重要トピック
- どれぐらいフォーカスするのかわからない
- マネージャーの重要トピック
- 成長は事業にとって良いこと
- 成長: 事業成果に還元される変化
- 失敗を許容するために能力不足は許容できない
- HarbardBizSchool
- 不確実な環境では知識は動く標的になるが、そんな環境で新たなスキルを学ぶことが、およそどの業界でも競合するうえで不可欠になっている
- チームが機能するとはどういうことか
成長
- Will
- 本人の望む成長
- Need
- 組織が望む成長
- 重なりが大きくなるように努力する
- Will
重ならないNeedへの対応
- WillとCanが重なる別メンバーを探す
- 専門集団として組織化
- グループ外連携
- Needを動かす
- 事業ニーズのハックBizDev
Willを動かす
- 本人のきづきを見逃さない
- Visionが重要
- なにを目指しているのか。動かすきっかけになる
- Visionが重要
- 自主性を見逃さない
- 本人のきづきを見逃さない
チームと指定成長していく
- NEEDが重要である以上、特定業種のみ成長すればよいわけではもちろんない
- 基本的に全てのメンバーの成長
事業という制約条件
- 成長環境の制約条件に議場貢献があるよ言う割り切り
- 事業成長、事業衰退ともにメンバーの成長に大きな影響を与える
- 競合他社や技術発展も成長環境整備の制約条件
メンバーのWillがないプロジェクトは寝かせる,待つ
まとめ
- メンバーの能力向上や学習が必要
- 本人のWillと周囲のNeedを上手く調整する仕事が必要
洗浄を定義
- プロは自分にも他人にも厳しい
技術力勝負はきびしい(マネージャー側)
マネージャーの弱み
- 技術力
- 自分より優秀な人材を採用する ゆえのジレンマ
- マネージャーの成長のためにメンバーがいるのではない
- マネージャーの脅威
- ライフイベント
- 強み
- 組織構造の決定権
- システム構造の決定件
- 評価の基準の決定権
- 予算を取りに行く力
- 機会
- 上司が偉い人
- 部下が優秀な人
💰でかいけつできることがある
- 書籍
- カンファレンスの参加費
- 計算機料金
勝ち筋を整理する
- 強みと機械を最大限活用して成長環境を整備仕様
事例
成長フェーズの分類
- キャッチアップフェース
- ある程度まかせられるが、自分より強いメンバーがいる
- 開拓フェーズ
- 学習すべき事柄に、自分より強いメンバーがいない
- キャッチアップフェース
キャッチアップのサポート
- 1 on 1
- 成長が早くてわかりやすい
- 気をつけていること
- 偉い人との 1 on 1 をすることで成長している事に安心できる
- 成長期間をちゃんとつたえる
- 1年かかるとか
- 開拓のサポート
- 新サービスの開発リーダー
- リーダーは会社に残りやすい
- サポートをお願いしたメンバーは転職していくことが多い
- とはいえリーダーを絞るのは大原則
- 新サービスの開発リーダー
研究開発案件は兼任体制で
- 研究の定義
- 重要だけど緊急でない問題
- チームを分けるべきか？
- メンバーの成長にフォーカスすると、波及効果があるため分けていない
- 技術力向上の手段としてアカデミアをレバレッジ
出向
- 中にいなかれば外の専門家に面倒をみてもらう
技術顧問制度
- 外の専門家に見てもらう
- 効果が微妙
- 受け側のエンジニアリソースが足りてない
- 効果が微妙
早くからマネージャーにしない
- アンチパターン
- 本人のWillがないのに、望まない形でマネージャーにしない
- 何人も失敗した
新卒動機を集める
- 雑談しやすい(ごはんとか)
- 情報共有とか勉強とか発生しやすい
- マウントを取るメンバーが発し絵しづらい
- 一般化すると社内のソーシャルグラフを利用する
ファシリテーター
- スクラムマスター
- マネージャでなく、1メンバが仕切っているのが非常に助かっている
- 同じPMチーム所属でもPMチームのマネージャーが仕切るのと、メンバーが仕切るのではおそらくエンジニアメンバーのやりやすさに違いが生じる
- 指示系統ラインがつよくないｒすぎないようにする
- 開発が企画側の考えや進捗を把握できない
- 除法格差が生まれやすい(登壇者主観)
- 開発が企画側の考えや進捗を把握できない
まとめ
みれんかった
入社メンバーの受け入れ
開拓フェーズ
マイグレーションの良いこと
- Good
- 仕様をきらなくていい
- 技術選定できる
- Bad
- 泥臭い仕事がある
- マイグレーションしやすいシステムにしておかないと辛い
感じたこと
- Will(本人の望む成長)とNeed(組織が望む成長)が重なるといいな
- 逆に重ならない時の対処は考えないといけない
- 定期的な 1on1 して指向性のすりあわせは必須と感じる
- Will変化があるのでなるたけ適度に短いサイクルがいいのか。
- 定期的な 1on1 して指向性のすりあわせは必須と感じる
クラウドネイティブ時代のマルチテナントアーキテクチャとデータ設計
技術
DB
- サーバーで分離
- サーバー、機能で分離
- 機能で分離
- MongoDB
- 共有
シャーディング利用してない
- ので自前で振り分け処理をやっている
ES
- マネージドサービスでは利用したい機能が消されてたので、自社運用
- Javaのバージョン問題なのでクラッシュしていた
- マネージドサービスをおすすめする
リクエストのテナント識別方法
おすすめは1, 同時に複数テナントログインとかできる
パフォーマンス
- 影響が広がる傾向にになる
- Cloud Watch Logs Insightsによるパフォーマンスチェックしてる
- API呼び出しよりも少し細かいログ出力にしている
- 処理時間もだしている
- 重たいAPI問題
- LBで重たい処理の振り分け
- 特定ユーザーによる資源専有
- あとから制限は難しい、事前に初期に計画しておくことが大事
感じたこと
- 設計大事
- あとで移行しやすいような設計にしておくことはもっと大事
本気で実践している人たちにしかできない話が聞きたい
登壇者の選定
- 理論と実勢の違い
- 悩んで答えを出した人たちを集めた
- 本気でやってき人たちの言葉を持って帰ってほしい
まだ見ぬかちへたどり着くためのデータプロダクト開発と組織づくり
- データプロダクト
- データ活用に価値
- レコメンドとか
- データ活用に価値
- チームメンバーを他チームに社内留学だした。
- 他チームのリソースをくわなくするため
マイクロサービスにおける技術と組織の衝突に向き合う
- マイクロサービスは組織論？
- 理想系
- ビジネスドメインで切り出される
- 1 サービス, 1チーム
- 公明の法則下痢主義がいる
- 組織が目的になっているのはNG
- 技術、組織の両輪ですすめるもの！
協力の組織デザイン
技術目線
技術と組織が衝突する実例
- 共通機能サービス
技術と組織がconflict コンウェイ？
組織本能の考察
https://speakerdeck.com/dskst/consideration-and-adaption-for-organizational-instinct
- 白い🍚を食べる文化を急に🍚NG, パンの文化にしようとすると争うが起こる
民族が民族を変えようとする時
- 分断される
組織本能
組織本能を変えるには
- 経験
- 断言
- 反復
- 感染
- 経験
エトス、パトス、ロゴス
圧倒的なトップダウンと言う強カードもある
エンジニアリングマネージャーは何をする人なのか
https://speakerdeck.com/yunon_phys/what-are-roles-of-engineering-managers
組織を変える前に変えること
- ラリー・ペイジ
- こんな広告は糞だ。
- Googleだからできた？
- 自分のところでは？
- 自分はできない。
- こんな広告は糞だ。
- 心理的安全性さえもマウンティングの対象となる
- 威嚇と嘲笑
- NG
- 普段からの人との向き合い方
- 心から相手を気にかけれるか
- 超属人的
- 継続できるか
感じたこと
- 組織を変えたい場合、かならず対立がおきる
- 新しい概念を経験させる
- 断言
- 反復
- 感染
- 考え方よりも感情を揺さぶったほうが通じる
- 新しい概念を経験させる
- 解消したい事がEngineering Managerの領域をかぶる部分がある
- 手法を学んで適用できるかもしれない
- 勉強する
- EM.FMきく
- 手法を学んで適用できるかもしれない
- 心理的安全性がおまじないみたいに使われている
- もっと具体的に、普段からの人との付き合いを考える
- EQ上げる(あがるのか)
参加して
TODO: 追記する...!
AWS Lambda から Spotify Web API を呼び出したい
前提
Spotify Web API を使おうと考えた - yrinda の続き
やりたいこと
Lambda 上でどの言語を使うか
方針
- とりあえずローカルで動くスクリプトを作る
- Lambdaにのっける
- 動作確認
の3本でお届け。
1. とりあえずローカルで動くスクリプトを作る
Lambdaで動くPythonは3.7なので、開発機(Windows)のバージョンをチェック
>python -V Python 3.6.4
oops... 3.7にバージョンアップしなきゃ
開発環境のPythonバージョンアップ(Python3.6 -> 3.7)
- 公式サイトからWindowsのインストーラーをDL
- インストール
- 古いバージョンは残しておきたいので"Customize installation"をクリック
- ここはそのまま"Next"をクリック
- Customize install locationを編集して"Install"をクリック
- しばらく待てば完了
Disable path length limitのオプションが表示されるけど無視して"Close"をクリック
- 古いバージョンは残しておきたいので"Customize installation"をクリック
- Windowsの環境変数を変更
- 確認
>python -V Python 3.7.3
バージョンアップできた。
次回
- とりあえずローカルで動くスクリプトを作る の続きから
