builderscon tokyo 2019 で使用したスライドです。 本セッションでは、形式手法 (formal methods) を用いた分散アルゴリズムの検証について解説しました。形式手法は、数学的な表現を用いて対象となるシステムを定式化することにより、システムの挙動の「正しさ」を厳密に保証するための方法論です。 なお解説として取り上げたのは、AWS による事例論文でも有名なモデル検査器 TLA+ です。講演前半で形式手法の一般論に触れたのち、後半では分散トランザクションを実現するための TCC (Try-Confirm/Cancel) Pattern のモデリングと検証を行いました。 講演概要：https://builderscon.io/tokyo/2019/session/fa356ee3-6be9-4850-ac9e-037bd34aabaa 録画：https://www.y

将棋の局面数は10の220乗だと言われることがあります。実は、この見積もりは正しくないとされており、実際の局面数はもっと小さいと推定されています。この「220乗」説の検討は次回にまわすとして、今回は将棋の局面数をざっくりと見積もってみたいと思います。 将棋の局面数については、篠田正人先生の見積もりが有名であり、「将棋における実現可能局面数について」（pdfファイル）という論文において、10の60乗以上70乗未満と下限・上限を厳密に算出し、さらに68～69乗程度ではないかという推測を述べておられます。篠田先生は数学者らしく“はさみうち”の方法を用いて慎重に見積もっておられるのですが、ここでは、物理学的な近似計算を用いて大胆に見積もりたいと思います。 まずは、以下の仮定で局面数を計算します。 王手については考慮しない。 持ち駒、成り／生駒、先手／後手駒は全ての数の組み合わせの場合に分けて積算す

アドテク本部の黒崎( @kuro_m88 )です。 2019/08/23にAWSの東京リージョンで特定のAZ内で大きめの障害がありました。 私が開発しているプロダクトもAWSの東京リージョンを利用していて、常時数百インスタンスが稼働しているため、今回の障害の影響範囲に含まれていました。 何が起きたのか？ AWSから公式発表が出ています。 東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要 データセンタ内の冷却の障害が原因で一部のハードウェアホストが過熱し電源が失われてしまったようです。これにより影響を受けたハードウェアホスト上で稼働していたEC2インスタンスやEBSボリュームは電源が失われているため、外部から見ると突然応答がなくなったように見えました。 担当サービスでも公式発表と同じくらいの時刻にELBやその配下のサーバ

これは仮説というか自分がこうだという話なのだが、自分のアイデンティティを侵食されると怒りが湧く。たとえば、自分が非常に大事にしている価値観に対して、同僚から「君のその価値観は間違っている」と言われたり、あるいは、作品とか、経歴とか、家族とか、そういう自分自身と非常に密になっていて同一視されるようなものをけなされたら、腹が立つということだ。 プログラマーにとって、ソースコードというのは一つの作品だ。仮に経験が浅い開発者であっても、あるいは経験が浅いからこそ、1行1行に時間をかけて考えながら作りあげる。それに対してこれはクソコードだと言われたらどうだろうか。考えてみる。 よく、クソコードというのはコードがクソだと言っているのであって、お前がクソだと言ってるわけではないから切り離して考えるべきだという言説がある。僕はこれには微妙に賛同できない。その人が生み出したコードは、少なくともその人のいくぶ

大学病院などで診療しても給与が支払われない「無給医」の問題。取材を始めてから１年近くたち、私はようやく医学界の重鎮に会うことができました。「無給医についてどう考えていますか？」こう問いただしたところ、返ってきた答えは意外なものでした。（社会部記者 小林さやか） ことし６月、文部科学省が、無給医の調査結果を公表。2191人の無給医の存在を初めて認めました。 このテーマを１年近く取材してきた私は“ようやく国が動いた”と少しほっとしましたが、不安な気持ちが消えることはありませんでした。なぜなら、本当に各大学病院が無給医の待遇を改めるつもりがあるのか、確証をもてなかったからです。 だからこそ、話を聞いてみたいと思っていた人たちが、“白い巨塔”のトップでした。そこで、私が取材を申し入れたのが「全国医学部長病院長会議」です。聞いたことがない人がほとんどかもしれませんが、実は全国の医学部長らが集まる大変

たとえば設計について議論するときや、コードレビューで指摘をするときに、「なぜその設計が良いと思うのか？」について言語化するのが上手だと、確実に良いことがあります。 言語化が上手にできるかが一つの壁なのではないか、と感じることもあります。後輩を育てたりチームをリードするような立場になると、特に必要性を感じるのではないかなと。 自分も、うまく言語化できたことですんなり議論を進められていると感じることは多いですし、逆に直感的な良さを言語化できなかったことで直感に反する方向に進んでしまい、結果よくなかったというような苦い経験もあります。 前提: ソフトウェア設計の良さは静的には決まらない良い設計・良いコードとは何なのか。という質問に一言で答えるなら、「保守性が高い」ことだと思います。つまり、今後の変更・拡張を、高速にバグが少なく行えるような状態が良い設計・良いコードです。(一般的にはこれで70%く

すえなみチャンス暑気払い

https://cloudnativedays.jp/cndt2019/ での登壇資料です

CNDT 2019での発表資料になります。 Day 2 Room H 12:00 - 12:40 検証環境を作成し、検証し問題なければリリースするというフローはよくあるフローかと思います。 検証を行う前提として、検証環境と本番環境の差がないことが理想かと思います。 では、検証環境と本番環境の差をなくすためにはどうしたらよいのでしょうか DockerやKubernetesを使えば解決ですか？ いいえ、それだけでは不足しています。 今回、差をなくすための取り組みとして行った下記のトピックについて話します。 * コードの実行パスの一致 * 実行環境の一致 * データの一致

Microservices Meetup vol.9 (FiNC App & Frontend) - connpass https://microservices-meetup.connpass.com/event/105174/ の発表資料です。 「クライアント・サーバ間のコンテキスト境界をどこに置くか」 という話を、ドメイン駆動設計の概念などを引きながら検討しました。

エンジニアリングマネジメントトライアングル エンジニアリングの話をする前に、プロダクトマネジメントトライアングルという言葉と聞いたことはありますか？ それは、プロダクトマネジメントという言葉の定義、責任をまとめたグラフィックモデルのことです。これはプロダクトマネジメントを探求するために作られました。 かたやエンジニアリングマネジメントも組織やフェーズによって役割が違う、責任もさまざまということから、プロダクトマネジメントトライアングルと同じように思考を整理できるのではないかと考えました。*1 では、このトライアングルをエンジニアリングマネジメントで作るとどうなるのか。Engineering Manager Meetup の有志が作ったので紹介します。 エンジニアリングマネジメントトライアングル 中心にエンジニアリングを置いて、テクノロジー、プロダクト、チームでトライアングルを構成しています

Developers Summit 2019 Summer [C-9] 「本気で実践している人たちにしかできない話が聞きたい」の中の Lightning Talk です。 より詳細な内容は https://scrapbox.io/qsona/devsumi_LT_2019-07-02 を参照ください。

従来のプロジェクトマネージメントでは管理された調整が行われてきました。スクラムでは集中管理ではなく、分散と自己組織化された調整と統合に価値があると考えます。LeSSでは必要十分な境界線と構造を提供し、カオスな状態になるのを回避し、分散型で調整が可能な状態になることを重視しています。 ただ話す チーム間の調整にもっとも良い方法は単純に、ただチーム間の調整をすることです。課題があれば自己管理されたチームの誰もが他チームの所に行って議論することが期待されています。もし、「ただ話す」ことが出来ない状況なのであれば、電話したり、最悪の場合にはメールを送れば良いわけです。調整の為に形式張った場は不要で、調整が遅れるだけです。立ち上がって話に行ってください。 コードでのコミュニケーション LeSSを導入しているグループでは継続的インテグレーションが取り入れられており、全てのコードは１つのレポジトリにチェ

Oracle Database Technology Night #79 - Oracle Database 23ai 新機能 Oracle Advanced Cluster File System (ACFS)

はじめに。自分のことをあまり知らない人にもこの記事を読んでほしい気持ちがあるので、簡単な前書きから始めさせてもらいます。 僕は26歳の会社員で、会社にいる時間以外はほとんど対戦ゲーム（スマブラSP）をプレイしています。「競技として」と言って差し支えないくらいに時間やお金、なにより情熱をかけてプレイしています。 そんな僕ですが、6月28日をもって会社員を辞めました。 この記事では、会社員を辞めた理由と、今後の活動についての話を書いていこうと思います。 会社員を辞めた理由僕が会社員を辞めた理由をざっくり書くと、人生がもったいないと感じたからです。これだけではざっくりが過ぎるので、何をもったいないと感じたのか、少し長くなるかもしれませんがつらつらと書かせていただきます。 僕は学生時代に将来の夢や、興味のある分野などを見つけられないまま、有休が取れて残業が少なければ…となんとなくで就職をしてしまい

前回のエントリからの続きである。今回はアソシエイトからマネージャーへの昇進を目指す際に留意するべき点を述べていく。 まず詳細に入る前にマネージャーの仕事を少し述べていく。プロジェクトのデリバリーにおいてはマネージャーロールは花形といっていいだろう。コンサルティングを長く続けようと思っていない人でも「マネージャーまではやりたい」と思っている人も多い。（あるコンサルティングファームの日本史社長を務めた人物も「マネージャーは本当に面白いと思ったし昇進せずにずっとマネージャーをやっていたいとすら思った」と述べていた。）プリンシパル以上は一つのプロジェクトのデリバリーに100%の時間は使うことはないため、デリバリーの文脈ではマネージャーが最も詳細を知っている立場にあるしそうなるべきである。 マネージャーはこのように一つの花形職位であるが、自分以外の仕事の成果にも責任を負うという観点でそれまでのアソシ

Tochigi RubyKaigi 08 http://regional.rubykaigi.org/tochigi08/ にて、6 分 29 秒の枠をもらったのでお話してきました。

大人の悩みに、はるかぜちゃんが答えます！ 怒りを“エンタメ化”しよう。はるかぜちゃんに「怒りをコントロールする方法」を相談した 最近話題の「アンガーマネジメント」。 ついつい怒りをあらわにしてしまう人、怒りを我慢してしまう人…自身の「怒り」との向き合い方に悩むR25世代も多いのではないでしょうか。 そういう筆者も、仕事をしていてけっこうイラっとしてしまったりするんですよね…。 今回は、4歳でブログ、9歳でTwitterを開設し、現在に至るまでSNS上で数多の大人たちと論戦を繰り広げてきた春名風花さん（通称・はるかぜちゃん）に、「自分の怒りをコントロールする方法」を聞きました。 「昔はTwitterをしながらずっとイライラしていた」というはるかぜちゃんは、今年18歳。“大人の悩み”をどのように解決してくれるのでしょうか…？ 〈聞き手＝高城つかさ〉