栞
Webで見つけた気になるページ。
「I had the same problem. And though my solution is not perfect it seems to work. Basically Safari seems to look for an input field with password and username and always tries to fill it. So, my solution was to add a fake username and password field before the current one which safari could fill. I tried using style .. display none but that did not work. So eventually i just used style="position:absolute; top:-50px;" this hid the input field out of sight and seemed to work fine. I did to want to use javascript but i guess you could hide it with javscript.」
「こういった状況において制御可能なポイントを増やしておく*1と、何かあったときの対処が非常にやりやすい。密結合のハイパフォーマンスサーバソフトウェアひとつよりも、疎結合のそこそこパフォーマンスサーバソフトウェアいくつもの組合せの方が、最終的に高稼働率・高スループット・低コストな環境を作りやすいのだ。」
「「重い」アプリケーションサーバーと「軽い」Reverse Proxy を組み合わせてそれぞれ自分が得意なものだけ担当することで、システム全体の系でみたときにリソース効率を全体最適させましょう･･･というのがインフラ視点で Reverse Proxy を導入したい一番の理由である。」
「At Yelp we rely heavily on pre-commit hooks to find and fix common issues before changes are submitted for code review. We run our hooks before every commit to automatically point out issues like missing semicolons, whitespace problems, and testing statements in code. Automatically fixing these issues before posting code reviews allows our code reviewer to pay attention to the architecture of a change and not worry about trivial errors.」
「上述の記事 では、マイクロサービスの特徴が九つほど上げられています。 サービスによるコンポーネント化：ライブラリではなく別プロセスで動作するサービスによってアプリケーションのコンポーネント化を実現している。 ビジネスケイパビリティに基づく組織化：役割ごとにチームが構成されるのではなく、複数の役割が混在したチームがひとつのサービスを構築する。（コンウェイの法則！） プロジェクトではなくプロダクト：コンポーネントは期限のあるプロジェクトとして開発されるではなく、継続的なプロダクトとして提供される。 スマートエンドポイント、ダムパイプ：サービス間のメッセージは、HTTP経由でAPI呼び出しされるか、RabbitMQやZeroMQといった軽量メッセージングシステムによる通信で交換される。 分散ガバナンス：サービスごとに言語やデータベースなどは統一されず、個別に適切なものが選択される。 分散データ管理：サービスごとにデータを持ち、統合されていない。 インフラストラクチャ自動化：継続的デリバリが実現され、自動テスト、自動デプロイなどが採用されている。 障害設計：構成されるサービスの障害に耐性を持つように設計されている。 進化的設計：各サービスごとに変更が行なわれ、漸進的に設計がされる。」
「Ridgepole is a tool to manage DB schema. It defines DB schema using Rails DSL, and updates DB schema according to DSL. (like Chef/Puppet)」
「1チーム1アプリケーションになるように、マイクロサービスにアプリケーションを分割することです。 アプリケーションが単機能であり、それに関わっている開発者も数名という状況であれば、マイグレーションはうまく機能することが分かっています。」
「エンジニアは「Webサービスは(言語・ライブラリ・関連しているサービスの影響などで)メンテナンスしないと壊れる。」などと思っているのに対して、非エンジニアはなんとなく「ほっとけば動いてそう。」と思ってる気がします。 なので、最近は「メンテナンス大変なんですよー」じゃなくて「ほっとくと壊れるんですよー」とかよく言ってます。なにか他にもっと気の利いた言い方あります？」
「使ってもらうのではなく、使う」
「“この店は美味しい”。行列ができている理由は、ただそれだけである。」
「株式投資をしている人の都合に、過剰に合わせているんじゃないか」
「メールを書いたり、チャットしたりということが、理由も無くできなくなることが人にはあるのですよね。だから、もっと簡単に、もっとシンプルにお互いが気持ちを伝えることができればコミュニーションのフラストレーションを減らせるんじゃないかと」「Slidropであらためて学んだことは、“今、既にあるサービスを良くした”くらいではダメだということ。Decologで似たサービスが後から沢山出てきてそれをよく知っていたはずだったのに、同じ失敗をしてしまったのですね。当たり前ですが、ユーザーにサービスを使ってもらうためには、もっとエポックである必要があります」
「オンプレミスのときはサーバの連続稼働時間を伸ばすことが正しいと思っていました。ですが、長時間稼働したサーバは不安定になり障害の芽を生みます。また、稼働時間が長くなると「動いているサーバは触りたくない」という心理的障壁を生み出し、より良い構成に変えようという気持ちを削ぎます。 これらの理由から長時間稼働したサーバはリスクと見なし、一定時間を超えて稼働しているサーバは新しいサーバに入れ替えています。 Immutable Infrastructure なのでサーバはいつでも破棄できる状態であり、新しいサーバを立ち上げるのも自動化できているので運用の手間は増えません。」
「MonjaDB is a MongoDB GUI client tool for rapid application development. It aims to provide a thoroughly straightforward way of updating MongoDB documents. It runs on Windows/Mac/Linux.」