Microservices Casual Talks 後日談 | Toru Maesaka
株式会社オライリー・ジャパン主催の「マイクロサービスアーキテクチャ」出版記念イベント (Togetter) で久しぶりに話してきました。 制限時間 20 分で Microservices アーキテクチャを語るのは厳しいので、開発現場のリアルな話や、Microservices に対して厳しい内容に絞りました。 どの帽子をかぶるべきか Microservices を人前で語るときは、どの帽子をかぶるべきかで悩みます。 ソフトウェアエンジニアとしては、Microservices アーキテクチャに手を出したくなります。 自宅で無駄に巨大なファイルシステムを構築するのと似た感覚ですね。 一方で、例えば幼いプロダクトを育てている立場だと手間のかかる Microservices アーキテクチャに対して否定的になります。 今日の正解は明日の不正解 テクノロジー業界は動きが速く、システムというものは状況の変
トラブル原因分析を、責任追及の場にしてはいけない | タイム・コンサルタントの日誌から
新製品の出荷を2ヶ月後に控え、新しい製造ラインの試運転前調整に入っていたある日、工務部門の担当者であるあなたのところに、ライン設置工事を請け負っていたエンジニアリング会社のプロマネから、とんでもない知らせが舞い込んできた。その会社の技術者が機械の操作ミスをしたらしく、製造機械の一部が破損してしまったというのだ。さっそく現場に飛んでいって様子を見てみる。残念ながら機械カバーがねじ曲がり、内部もダメージを受けている。幸い、人がけがをするようなタイプの破損ではないので、労働災害はなかったが、明らかに修理・再製作が必要だ。 エンジ会社のプロマネは装置のメーカー技術者を呼んで調べさせたが、いったんラインから取り外して、自社の工場に持ち帰る必要があるという。まずいことに、その装置はラインの中核近くにあり、周囲の機械設備をとりはずさないと動かせない。あなたは搬出と再製作にどれくらい時間がかかりそうかたず
エンピツとキーボード | アートと書評、ときどきシステム. 最近は、システムの話におされ気味。
どうも。 1年ぶりのブログ更新。 それもこれも、すべてはDevLOVE Advent Calenderのため。 本エントリーは、DevloveAdventCalender7日目のエントリーでございます。 昨日のぽざうねさん、 5年前からすこしずつ成長された結果が大きなdiffとして現在、実っておられるようです。 そういえば私事だけど、ちょうど1年前ぐらいに転職をした。 前職ではWeb広告系のシステムのおもに保守と開発、運用をしていた。 再度、「人の役に立つ」という視点でしっかりとしたシステムを作りたい、と思い、ふたたびSI業界に出戻った。 いわゆるWebのベンチャー企業とは180度異なる環境に再度身を起き始めたので、やはり苦戦する部分があった。 そんなときに、自分を奮い立たせるためにできること、それが、過去の自分とのdiffを取ることだ。 具体的には、毎週KPTやYWTをおこなって、過去の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
