区や会社の制度に助けられて双子を育ててる話
子育てエンジニア Advent Calenda9日目のブログです(遅れてすみません)
adventar.org
私は1歳半の双子の父で、今年の2月に育休から復帰しました。
復帰したタイミングで、妻は育休中ですが、肉体的にも精神的にも一人で双子を育てられる状況ではありませんでした。
その中でどのように今年を乗り切ったかについて書きます。
尚、LINEのソフトウェアエンジニアとして働いているのですが、エンジニアリングに関係することには一切触れないのでご了承ください。
利用した区の制度・ベビーシッター会社
妻一人で日中ずっと双子の世話をしたり、ご飯をあげたりするのは不可能な状態だったので、以下で紹介する保育支援制度を利用させていただきました。
訪問型保育支援事業“すみだ子育て支援ネット「はぐ（Hug）」” 墨田区公式ウェブサイト
区に在住するサポーターの方が来て手伝っていただける。最初は来る人はバラバラでしたが、保育士の免許も持っててすごく丁寧な方が毎回来てくださることになった。区の補助もあり、料金も大変安い。時間の上限があるので、上限まで使わせていただきました。
すみだファミリー・サポート・センター 墨田区公式ウェブサイト
上で紹介したはぐと同様、来ていただける区に在住するサポーターの方。違いは、サポーターの方が一人固定で着くという点。一人固定のため、依頼できる時間には上限があり週２回ぐらい来ていただいてました。
上で紹介した区の支援サービスだけだと足りなかったので、民間のベビーシッターサービスも活用しました。
こちらの会社は、依頼時間を指定するとその時間に都合の良いベビーシッターの方を派遣していただける形です。だいたい週３回 x 4時間くらい利用してました。
ちなみに、キッズラインも利用したことありましたが、キッズラインは自分でベビーシッターを探さないといけないので、探してメッセージ送って等のやりとりが手間でやめました。
会社の補助制度
今まで記載した通り、区や民間の保育サービスに助けられてきたのですが、合計週30時間ぐらい利用していたのと、双子だと２人分の保育料金となり、金銭的に結構な額になりました。
ただ、私の場合は運が良く、所属するLINEのベビーシッター利用支援制度が手厚いため、助けられました。
LINEでは、就労時間中のベビーシッター利用額の半額を補助する制度があります。また、内閣府ベビーシッター割引券も利用できます。
(尚、現時点の制度であり、変わることはあります。また、うちの場合は、妻は休職中のため、使えないのですが、うちは妻が体調不良で診断書もあり、利用が認められました。)
まとめ
以上のように、区や会社の制度に助けられてなんとか育休から復帰し、今年一年業務でもそれなりの成果を出すことができました。
次世代Webカンファレンス2019
SRE
メンバー
開発業務の割合
- Googleのプラットフォートチームでやっていることを取り入れていこうとしている
- ユーザーはメルカリのDevelopper
- プラットフォームそのものもやっている
- ユーザーサポートとプラットフォーム開発を5:5になるようにしている
- これがトイルかどうかの分類は結構難しい
- クオーター毎にレビューして次のクオーターの対策をマネージャーと考える
- 例えば割合が多い業務は早めに依頼してもらうようにお願いする
- タスクの割合の可視化方法
オンコール・インシデント対応
- クックパッド：オンコール対応は週次レビューを行い、重要な問題は再発防止する
- はてな：毎日振り返って緊急対応する。当番は休日はあったが、平日はない。SREだけでなく全エンジニアがポストモーテムを書くことになっている。
- メルカリ：モノリス時代はSREチームが担っていた。当番制で回していた。インシデントが起こったら関わった人たちがレポートを書くようにした。ポストモーテムは週一でSlack上で行った。
SLI/SLO
- SLOはプロダクト開発者ではなく、プロダクトマネージャーやCTOが決めるべき
- SLOをバイオレートする可能性があるものはアラート
- モニタリングはデータドッグをメイン。ワーニングはSlack、アラートはPagerduty
- オオカミ少年アラートが多いのをどうにかしたい
- GoogleのSRE本の学びとしては、チーム内全員をアラート全員が見る
- アラートのコード化を進めている
SREの今後
- ばらけていくのが理想？
- 皆がSREをやっていけば良い
- マネージドサービスに任せる
- 開発者全体に溶け込む
- スリーナインのサービスは開発者だけでは厳しい。そこにSREが入るべき。
- ML OpsについてはまだマネージドサービスがないのでそこではSREが必要になる
- SREは科学に近づいている
- 計測しやすくなる
- 研究したり、方法論を決めやすい
- 改善しやすい
- 科学に近づいていくべきだと思う
SREの生存戦略
- システムを理解したソフトウェアエンジニア
- 科学的なアプローチにトライできる人
- ソフトウェアかけるのは当たり前
- マネージドにできないことにどれだけチャレンジできるか
- SREは技術の話だけでなく組織の話だという文化が広まれば良い
用語
- トイル
- ポストモーテム
- SLI
- SLO
Security
メンバー
- コキチーズ
- セキュリティ診断
- mala
- LINEの人
- Livedoorの残党
- 障害対応
- 全社横断の対応
- 個人的にも活動
- 柳橋さん
- https://xss.moe/
- メルカリ
- 今はWebに限らずセキュリティ関連なんでも
- 徳丸先生
- セキュリティ会社やってる
- コンサルの仕事、ブログ
最近のWeb脆弱性
- CDN関連
- https://tech.mercari.com/entry/2017/06/22/204500
- キャッシュ設定していないはずがいつの間に課されていた
- 0秒設定のはずは1秒になった
- Wordpress/EC Cube
- パッケージマネージャー関連
- CVEの重要なもの読む
ブラウザの脆弱性についてどこまで意識すべきか
- 基本はない
- 何か問題あればアップデートされる
- ブラウザ側で治すべき問題をWebサイトで対応するのはしたくない
- 脆弱性のあるブラウザを使っているやつが悪い
- つけないといけないヘッダーが増えてくるのは嫌
- 脆弱性診断ツールだとアラートになる
- 意義をわからずにつけるのは良くない
- ヘッダーを一個つければよくしてほしい
cookie
CSPについて
- Mercariで入れようとしているが面倒臭い
- レベルの話？
- fastlyが設定してくれれば良い
- 問題があった時にレポートが来るようにしているが、量が多すぎる
- とってはいけない情報までとってしまっているものもある
- MicrosoftはXS FilterをやめてCSPに寄せる
プライバシー
- GDPR関連でcookieセットにも同意を求める
- 実装というか手続きの話
- 同意の形骸化になっている
- 本当に重要なものの合意ができない
- 先ずは機械的に解釈できるようにするべき
- 機械が読んでブラウザが判断できるようにする
- 人間を相手にすると厄介
- JSに同意をとる世界が来るかもしれない
- あの裁判次第★
- 既成事実を対象ユーザーが認知しているかは怪しい
- Canvas Fingerprinting
- 使うべきではない
- アドテックのカンファレンスでセキュリティ/プライバシーのセッションがない
- 知られていないのが大きい
- JSONPで広告配信すると漏れる
- ○○市に住んでいる人の特定
- セキュリティ・プライバシーはプライスレス
難読化
最後に
- コピペ問題
- 結城浩 C言語入門を改定
- 脆弱性関連の増強
- こういうところから底上げすべき
- 開発者自身が当事者意識を持ってほしい
- 法務にチェックしてもらったから大丈夫は本当か？
- 最初の一歩だけは気づいてもらいたい
- とっかかりだけは知ってほしい
Microservices
メンバー
- tagomoris
- treasure data
- fujiwara
- カヤックのサーバーサイド/SRE
- microservicesはやるしかない
- tokuhirom
- LINEで広告担当
- 自然にやってればmicroservicesになる
分散トレーシング
- トレーシングのライブラリ入れてる
- AWSのトレーシー？
- なんかあった時のログとしてとるには容量多すぎる
- 送る条件を決めて送るっていう手もある
- エラー
- 時間がかかった
- ログを串刺しに見る方法
- IDで横断的に見るのは基本
- LINEではログの収集基盤があり、串刺しで検索できるようになっている
- zeppelingがあるので見れることはみれるはず？
障害対応
- サービス毎に障害対応ポリシー作るのか
- サービス出す前にあるコンポーネント落としてみて正常に動くかをチェックしている
- カオスエンジニアリング
- アプリケーションの作り状、リトライができてれば良い
- LINEはカオスエンジニアリングに手をつけられていない
- LINEでは新しく入った人の教育で試している
- お客様に迷惑をかけなければ良いという考え方はある
- NetFlixは月額課金だから問題ない？
- 海外のビックプレイヤーがやっているからというで自分の分野考えずに導入するのは良くない
- いつかやっておかないと障害起きた時に爆発する危険性がある
- 特定のサービスが落ちた時にリトライしすぎて死ぬというのはありがち
canary deploy
- やらないで爆発するよりやった方が良い
- 常にはやらないが大きい変更の時はやる
- サービス重要度や規模次第
- 簡単にできるように作りこむのが大事(自動化必須)
サービスメッシュレイヤーのSW
- consulを導入している
- サーバー名等の登録
- DNSキャッシュ
- サーキッットブレーカー
- どの段階で入れるべきか
- 入れるのが当たり前になれば良い
- アプリケーション作成側が楽になる
- ある程度大きい会社であれば基盤部門が導入してくれれば良いはず
サーバーレス
- firebaseの世界
- 結局データ構造考える人がクライアントの人になるだけ
Microserviceの実装面
- gRPC
- クライアント言語によって対応状況の違いある
- https化
- マネージドであまり対応できていない
- スキーマ固定が必須
- 言語がバラバラになるとスキーマなしの通信は無理
- MySQLを直接たたかずにgRPCで包むっていうやり方もある
- failOver時の対応はgRPCの先
- LINEはthriftが多い。一部はgRPC
- JSON利用は減っている
- パフォーマンス的に厳しい
- 複数のプロトコルを1つのミドルウェアをしゃべるケースがある
- Kafkaへの接続
言語
- JSONは大体の言語で良いのある
- データ形式によっては言語毎に差異ある
- Amazon/Googleがサポートしている言語を使うのが良い
- Line:大体はJavaで解決するという立ち位置
- kayak:Goが多い。昔のはPerl。型付の方が変なバグ起きない。数年前にGoに決めた。
- 監視に対応しているかという観点も重要
- Goの監視
- GoのGC等のモニタリングするライブラリある
- マイクロサービスは言語の変更はしやすい
人数が増えるとMicroserviceが当たり前
- １リポジトリで開発するのは大変
- できるだけ分けるべき
- ピザ２枚理論
- S3は２百以上のマイクロサービスに分割されている
- Lineは1コンポーネント毎にサーバーサイドエンジニア3,4人が多い
- 拠点毎にマイクロサービス化するのが良い
Webサーバーサイド
- マネージドサービスによって、担当できる範囲が広くなっている
- 広くするかピンポイントに深くする必要がある
- 1つの場所にフォーカスする仕事が増えている
用語
- consul
- サービスメッシュ
HTTPS
メンバー
- @jxck
- @jovi0608
- @kjur
- @4ma_
PKI/CA
- シマンティックのディストラクト
- CAブラウザフォーラムの体制が変わった
- PKIかわいそう
- そこまでたたかれることか
- GPKI
- リニューアルとしてCAをサブミットした？
- 運用できていなかったことを指摘された
- 魔女狩りに近い？
- EV証明書は無くなると思っている
- 認証と信頼は別
- Let's Encryptで良いじゃんへの回答？
TLS
- TLS1.3の正式化
- TLSデプロイ状況
- SSL PulseによるとTLS1.3が想像より上がってきていない
- TLS1.0,1.1を消すのはどれぐらい大変か
- TLS1.3への移行
- ガイドが出ている
- gistによると1.2,1.3を並行して使うのがガイド
- TLS1.4に向けて
- ゼロRTT
- 量子コンピュータによる暗号化
- https://twitter.com/jovi0608/status/931001682493890560
- 周期性があるものを見つけるのが簡単
- 公開鍵暗号化は脆弱になる
https
- やってこうという話が4年前
- https厳格化するための対応(hstsなど)がどれも上手くいっていない
- httpsは100%であってはいけない
- alternativeがないとマジョリティがダメだった時の逃げ道がなくなる
- httpsは通信の暗号化に寄り過ぎた
signed http exchange(SXG)
- 参考
- いままでは通信の暗号化に偏っている。(土管レイヤ)
- その上のレイヤでの対策が必要
- URLで識別するのが限界になってきている
- それに変わるスキーマが必要->SXG
- SXGへ期待している
- インターネットアーカイブ等への用途の広がりもある
- コード署名と同じ考え方
HTTP3
https://http3-explained.haxx.se/ja/
メンバー
- @flano_yuki: Webとプロトコルの標準化 Watcher
- プロトコル愛好家
- 読んで実装しているおじさん
- @kazuho: CDN 等で使用される HTTP サーバ「H2O」の主開発者。HTTP, TLS, QUIC の標準策定に貢献 [blog]
- fastly
- コーディングがメインで関連する標準化活動へ参加している
- @kaname: IETF で最新プロトコルを追っているネットワークの中の人
- NTTコミュニケーションズ
- ネットワーク視点でHTTP3を見ている
- ベンチマークとってる
- @ysnysnysn: WebSocket や Streams の実装と標準化をやっていました。最近はロボットやってます
- 吉野
- 今はPFNでロボット
- 去年までAPI関連やってた
HTTP3とは
- セマンティックすはHTTP2と同じ
- 大きな特徴はQUICを採用している
- HTTP2でリクエストを投げてQuicに対応していたらQuicで通信する
- 名称
- つけたくなる気分はわかる
- QUICに対するバインディングの名前が変わった
- G-QUICとI-QUICの差がわかりづらいという混乱があった
- I-QUICをHTTP/3となった
HTTP3というプロトコルの見方
- 妥当な進化をさせようとしている
- ネットワーク事業者視点
- 輻輳制御
- NATのバイディング
- 暗号化
- インターネットの5%で既に使われている
- TCPはガタがきている
- レイテンシの壁
- インターネットのレイテンシはあまり変わっていない
- セキュリティの観点
- 平文想定
- レイテンシの壁
- 皆がHTTP3使い出したらどうなるか
UDPがどれだけ使いやすいか
- ファイアーウォール
- UDP443が通らないところが数%あったが、3年後に1/3になった
- NAT
HTTP3で何が嬉しいか
- ネットワーク品質が悪い国では効果あり
- 日本のようにネットワーク品質が良い国の効果は？
- 0-RTTで接続ができる
- ネットワークローミングができる
- wifiから公衆回線への切り替えができる
- partial relaiabilityも入れられる
Quicをどこで使えば良いのか
- WebRTCに向いてる？
- 動画
- DNS
Quicが向かない分野
- レイテンシが小さい場合は別のレイテンシの悪影響が出てくる
- パケロスが少ない
- 例. データセンター内の通信
Webの進化とプロトコル
- WebSocketを作ろうとした時の苦労を思い出す
- Httpの意味論
- 基本的に数十年は変わらないと考えている
- HttpNGで変えようとしたが、上手くいかなかった
- 将来は予測つかない
HTTP3への貢献
資本主義をアップデートせよのメモ
WEEKLY OCHIAIの内容についてのメモ。
資本主義とは何か
バーチャルの対義語はマテリアル
資本主義のキーワード
->仕組み・制度
欧米では資本主義=市場経済
- 資本主義にはイズム(主義)が含まれるが、イズムの観点で資本主義を言及している人は少ない
- イズムはどこに行ったのか？
- イズム->利益を再投資すべき
- 現代の使われ方では抜け落ちている
- アメリカの上場企業の投資の9割は自社株買いと配当に回している
- なぜ？
- materialを生産すると儲かる時代が終わった
- サピエンス全史 by ハラリ
- 再投資に回せるものをCapitalと呼ぶ
- 再投資に回せないものをWealthと呼ぶ
- Wealthは増えているが、Capitalが減っている
- 個人にも当てはめている
- お金を銀行に集めて銀行が再投資地てくれれば良いが、ゼロ金利で融資に回っていない
- ミクロで見てもマクロで見ても資本主義のイズムが崩れてきている
- 再分配
- マクロ
- 金持ちから集めて全体に回す
- ミクロ
- クラウドファンディング
- 数字から実体に投資する人は少ない
- 前澤さんがやっている芸術作品への投資はウェルスへの投資？
- マクロ
- 個人が投資を始めるには？
- 新しい商品や新しいサービスに投資すれば良い
- 企業が給料を上げるのも間接的にはキャピタルゲインになる
- 企業の内部留保が最も資本主義を阻害する
- マテリアルの壁を超えられない
- ブランド・格好良いの価値
- 周りの人が価値があると思って無くなると弾ける
Materialから見たアップデート(画一、多様化)
- 前近代->近代
- 近代->デジタル
- デジタル革命(限界費用ゼロ)
- デジタル化の利点
- デジタル化の懸念
- 独占企業が生まれ易い
- GAFAの買収
- 近代の個別化の壁を超えてきている
- 独占企業が生まれ易い
- 半導体と蓄電池への投資はマテリアルの投資の成長例
イノベーション
JAWS DAYS 2017
新訳 とあるアーキテクトのクラウドデザインパターン目録 by JAWS-UGアーキテクチャ専門支部
http://jawsdays2017.jaws-ug.jp/session/1998/
- JAWS-UG ARCH: アーキテクチャ専門支部
- コスト: 開発3割、運用7割
- Route53 as the hybrid Cloud
- AMI Maintenance Environment
- EC2にSSHログインしないでEC2を構築する
- qitaに投稿あり by はたのさん
- S3で構成管理する
- EC2, RDSで作る３層構成は維持費がかかる
- マイクロサービスアーキテクチャ
- サービス間は疎結合で外部インターフェース間でのみ通信
- サーバーに状態を持たない
- サーバーレス
- サーバーを使わずに動的なWebサービス
- URLへのコンテンアクセス時にコンテンツ生成し、2回目以降は同じ内容のコンテンツ返す
- S3でファイルがない時(404)は生成処理へのリダイレクト(307)を返す
- Qitaに記事あり
- 重たいAPI処理結果を受けて別の処理を走らせたい
- BeanWorkのWorkerでポーリングしてLambdaで処理させる
- Step Functionsでできる
- 値段とAPI制限が課題？
AWS SECURITY DEATH \m/ ～セキュ鮫様からのお告げ～ by Security-JAWS
http://jawsdays2017.jaws-ug.jp/session/1512/
- Security-JAWS
- 3ヶ月に1回のペースで開催中
- AWSにおけるネットワークの基本
- WAF, DDOS
- Who?
- 吉江瞬
- OWASP Japan Promotion Team
- DDoS
- 大量コンピュータが一斉に特定のNWやコンピューターに接続して落とす
- 種類
- L3/L4
- L7
- AWS Shield
- 2016/12リリース
- CloudFrontでShieldオプション有効化
- オンプレでも利用可能
- 防御対象: CloudFront, ELB, ALB, Route53
- 監視: 常にモニタリングしてベースラインの作成、異常検出
- 料金
- Basic: 無料で利用可能
- Advanced: 1年間の利用コミットで月額3000ドル
- WAF
- Who?
- AWS Config
EXCEL構成管理からの脱却と次世代MSPとDevOps 2.0 by OpsJAWS
http://jawsdays2017.jaws-ug.jp/session/1518/
- EXCEL構成管理からの脱却
- 次世代MSPとDevOps 2.0
- Who?
- MSPとは
- Management Services Provider
- 記号が保有するサーバーやネットワークの運用、監視、保守を請け負う業者
- 監視して生涯を見つけてつうしし、スペック提案
- パッチ適用して稼動確認
- 次世代MSP
- 次世代MSPとDevOps
- 手法とプロバイダーは両立するのか
- Opsの成長に付き合えるMPSが求められる
- DevOps 2.0
- DevOpsのイメージは運用の負荷が大きい
- 基盤構成が柔軟化 -> 構成管理サービス
- スピードアップ -> 監視自動化
- 運用から開発への提案がされるようになる(2.0)
- キャパシティ変更
- セキュアプログラム
- パフォーマンス改修
- アーキテクチャ変更
- まとめ
- 次世代MSPはツールではなく仕組み
- 次世代MSPでOPSが強くなる -> DevOps 2.0 -> OpsDev
6年前のその時、クラウドで何ができたのか 〜JAWSとタイガーチーム〜
http://jawsdays2017.jaws-ug.jp/session/1735/
- SORACOM
- クラウドSIM
- グローバル用SIM
- 赤十字社
- 関西淡路大震災は8000億円の義援金
- 震災直後の日本赤十字社の様子
- タイガーチームをこれほど早く立ち上げることができたのか？
- 次の災害時に何ができるのか？
- IOT
- 被災地の情報端末向けのSIM提供
- 野良キャッシュ、ダメ。絶対。
- 義援金詐欺
- IOT
- 普段のネットワークが大事
- 人道の敵
- 人間を救うのは、人間だ。
IAM 権限をこえて
http://jawsdays2017.jaws-ug.jp/session/1792/
- IAMとは何か
- Policyたち
- IAMの鼓動はログ
AWSデータベースアップデート 2017
http://jawsdays2017.jaws-ug.jp/session/1220/
- Amazon ElasticCache
- Redis Cluster
- 3.5TB
- 4.5 million writes per second
- 20 million reads per second
- 海外では永続化データの場所として利用事例多い
- 今後も永続化向けのアップデート予定
- Redis Cluster
- Amazon Aurora
- 既存
- 性能面でMySQL5.7を圧倒する
- PostgreSQL
- 現在Preview
- PostgreSQL 9.6.4との完全互換を目指している
- 将来使いたい場合は9.6.4以降にしておくと良い
- Performance Insight
- クエリパフォーマンスの評価
- Postgre Aurolaから導入し、順次他DBに広げていく予定
- ゼロダウンタイムパッチ
- アプリケーションから見てコネクションを切られずにDBバージョンアップ
- OnlineDDL
- Alterが1秒以内
- 今後
- Online point in time restore
- 動いているAurolaを特定時点にロールバック
- ログを見えなくすると過去の段階に戻せる
- 現在は数時間前まで対応する予定
- Database cloning
- 1TBのデータをcloneしても1TB文の課金のみ
- 変更文のみ課金される
- 本番データでテスト
- Aurora Auditing
- 監査ログを有効にしてもパフォーマンス落ちない
- Online point in time restore
- 最近の改善
- インデックスツリー作成の高速化
- Cached read performance
- Insert Performance
- 既存
- AWS Database Migration Service
- Amazon Athena
- AWS Glue
- ETL（Extract，Transform，Load）ツール
- フルマネージドETL
- データ変換も可能
- pythonコードをロードしてエラーハンドリング等を実施
dots.2周年記念パーティ
言語デザイナーが見る未来 by Matz
Who are you?
- 松江市名誉市民
- IT総合戦略本部委員
テクノロジーの変化
- パソコンのメモリは640KBで十分 by Bill Gates
- 20数年前のスーパーコンピューターはiphone5程度
エクストリーム未来予測
- ポケットに今のスパコンが入ったらどうなるか
プログラミング言語の進化
- FORTRAN(1954)
- 人工知能と呼ばれた
- Lisp
- COBOL: 帳票、データ
- C(1972): OSをかけるようになった
- Pearl(1986)
- Erlang(1986)
- Java,JavaScript,PHP,Ruby(1995)
- Windows95が出て誰でもインターネットにアクセスできるようになった
- できなかったことができるように
- 人間の脳でもできるという意味
- できたことをできないように
- goto
未来へのキーワード
- C100K問題
- テラメモリ問題
- ペタデータ問題
- 10000 Cores
- プログラマがマルチコアを活用しなければならない
- 非決定性
- ハイゼンバグ
- 新技術を身につける力が重要
- 検索力
- 世界観
- 大枠を把握すると新しい技術がどこにはまるのかを理解する
- 変化しないものの方が大事
- 数学,コンピュータサイエンス, アルゴリズム, ノイマン型コンピュータ, 基本プロトコル(SMTP, HTTP), 感性
- インターフェースの原理
- ある意味言語デザイン
- インターフェースがすべて
- 未来でもこの点は変わらない
QA
- Matzが見る未来
- 20年、30年後はプログラミングしないとできない領域が減っていくのではないか
- 注目しているフレームワークは？
今後エンジニアに求められるスキル／考え方
- 未来に必要な技術とは？どんな技術を身につけていくべき
- クズさが必要
- 変わらないもの。レイヤーの下の方は変わらない。PC自作。ネットワークの知識。
- 夢中になってつきつめていく。
- 新しい技術に追いかけていくべき
- 好きなことをつきつめている人に任せるべき
- 未来につながる、もってほしい考え方は
- 自分一人だと限界がある。
- 10年後、15年後はどうなるかわからない。何のためにプログラミングしているのかを忘れない。
- 自分の楽しいことをしたい。捻じ曲げて自分の楽しい方向にもっていく。
- どう働くべきなの？会社とし働き方を変えるべきなの？
- エンンジニアの得意なところは囲ってて良いのか？色々なところいっても良いのでは？
- 労働のオープンソース化
- エンジニアは自分のパフォーマンスが出せるようにする面でもプロフェッショナルであるべき
- 今後はこんなOSSが登場するのでは？ほしいOSSは？
- Hadoop, Sparkの後継
- Meteo
- Active Valueというコンセプト。データのアップデートやトリガーは自動でやってくれる。人間はレイアウトとデザインだけ考えれば良い。
- HashiCorp, ElasticSearch
- 運用面の知見で価値を届ける
- 売り物でも気軽にプルリク送れるような関係性が面白いのでは
- 今後注目されるような開発コミュニティは？
- 日本人がいないコミュニティに入っていくと良いのでは
- 参加する人を増やしたい。初めのいぽを手助けするような活動をしたい。
- オープンソースに必要なのは炎上力
- Hard Ware
- ネットワークプログラミングで世界が変わった
- HWエンジニアと働くのは共通知識がないから大変。ただHWの遭遇こそがIOT。
- 未来に必要な技術とは？どんな技術を身につけていくべき
