アメリカにおける離婚率と職業の関連を調べたお話。
アメリカでは結婚したカップルのうち実に半分は離婚でその関係を終えているという。
その離婚率はカテゴライズすることで一定の傾向が見えてくる。
例えば、非正規雇用者のほうが正規雇用者に比べて離婚率は高い。
アジア人のほうが離婚率は低い傾向にある。
この記事では2015年のACS(American Community Surver)の調査結果を基に、
各職業による離婚率の傾向を計算している。
最も離婚率が低いのは保険数理士であり、最も高いのはバーテンダーやゲームマネージャーであった。
カテゴリ別に見ると、最も低いのは建築とエンジニアで最も高いのは輸送業であった。
結果的に、教育の水準の高低がそのまま離婚率にも反映されているように見えている。
また、給与の高低も相関があるように見える、とのこと。
原文：www.ory.am
自前のOAuth2.0サーバーを構築するお話。
OAuth2.0サーバーにはORY HydraというGolangで書かれたオープンソースのものを使っている。
まず、この記事のターゲットは、
既に世の中にはOAuth2.0サーバーはあるが、ユーザー管理のやりかたを強制してきたり、自由にならないことが多くあった。
そのため、ORY Hydraでは、数行のコードを実装するだけで独自のユーザー管理をすることが出来るようになる明確なフローが存在する。
第三者の開発者が使用したり、他の全てのアプリケーションが使えるように、ORY Hydraがユーザー情報をOAuth2.0のアクセストークンとOpenIDのConnect IDトークンに変換する。
以下に簡単な流れを記載する。
原文：The art of over-engineering your side projects – Liam Symonds
お金を稼ぐことを目的としたプロジェクトのアンチパターンのお話。
筆者はそのようなプログラミングの傾向として、過剰な機能をもたせすぎるとしている。
そのようなアンチパターンを撲滅するために、筆者がかつて経験した間違いを列挙している。
素晴らしいアイディアとどのようにそれを達成するかの見通しを持っているとして。
論理的に、アプローチの計画を並び替えたものをひとまとめにしようとする。
しかしながら、当初の計画にフォーカスしすぎてしまい、「プロジェクト管理」という罠に落ちてしまっている。
つまり、顧客のストーリーを描いたり、バックログの作成やまだ始まってもいないプロジェクトのツールを探し出したり、質実な管理のために大量のお金をかけたりしている。
解決策：
未だ存在しないプロジェクトを管理しようとしないこと。
アイディアとざっくりした時期間だけをノートに書き留める、これだけで良い。
2ヶ月後にそのプロジェクトで何をしているのか予測し始めたとしても、予測通りに行くことはほとんどない。
プロジェクトの見通しが立ち、その未来を考えられるようになると、
「サービスに100万の人が訪れるようになったらどれくらいスケールすべきだろうか？」とか
「どのようにマルチゾーンの冗長性をもたせようか？」とか
「100%の稼働率をどのように達成しようか？」などと考え始めるかもしれない。
読んでいる人の中にはバカげていると感じる人がいるかもしれないが、その感覚は正しい。
多くの人々は、ユーザー数が適正になるよりも前にその要件を満たすような行き過ぎたインフラ構成になっている。
解決策：
まずは実装すること。
実装したら、アプリケーションが動く最低限のアーキテクチャに展開すること。
多くのユーザーを獲得し、モニタリングをして、負荷と冗長性を考慮したインフラに変更すること。
多くのエンジニアは潜在的な顧客が裏側でどう動いているかを気にしている、と考えている。
顧客はRubyで動いていようが、GoだろうがPHPだろうが気にしない。
気にしているのはパフォーマンスと目的を満たせるかどうかだけである。
解決策：
自分の書きやすい/経験のある言語で書くこと。
Bootstrapはつまらないし、Materializeは大きすぎるし…。Foundationはなしだな…。自分で作ったほうがマシだ。
以前はそのようにも思ったけれど、一度完成させてみるとそのような願望はなくなっていた。
解決策：
フレームワークを使って、それをカスタマイズすること。
自分が明確に必要な部分だけをリファクタリング/ビルドをして。
「2. 過剰に設計されたインフラ」と似ているが、何一つ提供する前に、継続的に機能を提供する仕組み設計してしまう。
JenkinsやDrone, Travisは素晴らしいツールであるが、それらの設定に時間をかけるよりも、稼働させるべき。
解決策：
まずはビルドする。それから継続的機能提供を考える
