タグ

ブックマーク / postd.cc (10)

  • SQLトランザクション分離 実践ガイド | POSTD

    (注:2017/10/16、いただいたフィードバックを元に翻訳を修正いたしました。) (注:2017/10/11、いただいたフィードバックを元に翻訳を修正いたしました。) データベースのドキュメントで分離レベルを目にして、軽く不安を感じつつ、あまり考えないようにしたことはないでしょうか。トランザクションの日常の使用例できちんと分離について言及しているものはほとんどありません。多くはデータベースの初期設定の分離レベルを利用しており、後は運頼みです。しかし、来、理解しておくべき基的なトピックであり、いくらか時間を投入してこのガイドの内容を学習すれば、もっと快適に作業できるようになるでしょう。 私はこの記事の情報を学術論文、PostgreSQLドキュメンテーションから集めました。分離レベルの 何たる かだけでなく、適用の正確さを保持しつつ最大速度で使うにはいつ使うべきか、という疑問に答えるべ

    SQLトランザクション分離 実践ガイド | POSTD
    Sixeight
    Sixeight 2017/10/11
  • コーディングに対する考え方を変える6つのプログラミングパラダイム | POSTD

    私は時折、コーディングに対する考え方を変えさせられるような、従来と非常に異なるプログラミング言語に出会います。記事では、その中でも特に気に入っている発見をいくつかご紹介したいと思います。 これは、先賢による「関数型プログラミングは世界を変える!」的な投稿ではありません。記事で挙げるのは、もっと「知る人ぞ知る」的なリストです。多くの読者の方にとって、以下の言語やパラダイムは聞いたことのないものが大半だと思いますので、私が経験したように、これらの新しい概念を学ぶ楽しさを感じていただければ幸いです。 注:私は以下の言語の多くに関して最低限の経験しかありません。その発想に引き込まれたのであって、専門的知識は持ち合わせていないため、訂正すべき点や誤りがあればどうぞご指摘ください。また、記事で取り上げていない新しいパラダイムや概念に出会った方は、ぜひお知らせください。 最新情報:記事が r/p

    コーディングに対する考え方を変える6つのプログラミングパラダイム | POSTD
    Sixeight
    Sixeight 2017/06/21
  • Dockerの本番運用 | POSTD

    以前に私が書いた「 Docker番運用:失敗の歴史) 」という記事は、非常に多くの反響を呼びました。 その後、長い議論を交わして、何百件ものフィードバックや何千件ものコメントを読み、さまざまな人々や主要事業者とも顔を合わせました。Dockerでの試みが増えるほど、その失敗談は増えていきます。そうした現状を、今回アップデートしておきたいと思います。 この記事では、最近の交流や記事から得た教訓を紹介しますが、その前に簡単におさらいをして軽く背景を説明しましょう。 免責事項:対象読者 たくさんのコメントから、世の中には10種類の人々が存在するということが明らかになりました。 1) アマチュア 実際のユーザがいない試用版のプロジェクトやサイドプロジェクトを実行している人々です。Ubuntuのベータ版を使用するのが当然だと考えており、「安定したもの」は古いものと見なすようなタイプです。 注釈:書

    Dockerの本番運用 | POSTD
    Sixeight
    Sixeight 2017/04/21
  • Reduxのパターンとアンチパターン | POSTD

    Redux は、 Flux のようなアーキテクチャを使用してアプリケーションの状態を管理できる非常にシンプルなライブラリです。私たち Affirm では今、 Reduxのタイムトラベル機能 に注目しています。Affirmの主要事業は、透明性の高い消費者ローンを提供することなので、ローン申し込み時の全過程をユーザ視点で再現できると非常に有用なのです。 Reduxはフレームワークというよりも、パターンの適用に役立つ関数セットです。よって、適切なパターンを慎重に適用しないと、Reduxを使ったことを後悔する結果になりかねません。この記事では、Affirmで確立したReduxのベストプラクティスや、ミスを犯しやすいポイントについて説明します。 ImmutableJS ImmutableJS は、不変の永続データ構造を扱うためのライブラリです。私たちがこのライブラリを好んで使う理由は2つあります。

    Reduxのパターンとアンチパターン | POSTD
  • 私たちはいかにして環状線で”悪さをする列車”を捕まえたか | プログラミング | POSTD

    文:Daniel Sim 分析:Lee Shangqian、Daniel Sim、Clarence Ng ここ数ヶ月、シンガポールのMRT環状線では列車が何度も止まるものの、その原因が分からないため、通勤客の大きな混乱や心配の種となっていました。 私も多くの同僚と同じように環状線を使ってワンノースのオフィスに通っています。そのため、11月5日に列車が止まる原因を調査する依頼がチームに来た時は、ためらうことなく業務に携わることを志願しました。 鉄道運営会社SMRTと陸上交通庁(LTA)による事前調査から、いくつかの電車の信号を消失させる信号の干渉があり、それがインシデントを引き起こすことが既に分かっていました。信号が消失すると列車の安全機能である緊急ブレーキが作動するため、不規則に電車が止まる原因となります。 しかし8月に初めて発生した今回のインシデントは、不規則に起こっているように見えるた

    私たちはいかにして環状線で”悪さをする列車”を捕まえたか | プログラミング | POSTD
    Sixeight
    Sixeight 2017/02/26
  • コードの半減期とテセウスの船 | POSTD

    プロジェクトが発展する際は、単純に新しいコードが古いコードの上に追加されているのでしょうか。もしくは、時間をかけて徐々に古いコードが新しいコードに置き換えられているのでしょうか。これを解明するために、手ごわい GitPython プロジェクトの助けを借りて、Gitプロジェクトを分析する 簡単なプログラム を構築してみました。履歴を年ごとに振り返り、 git blame を実行してみようと思ったのです(この処理を多少でも速くすることは簡単ではないと分かりました。しかし、ファイルのキャッシングを便宜的に含ませることや、変更された点を履歴から見つけること、 git diff を使って変更したファイルを無効にすることなどの詳細を、いつかお伝えします)。 頭がさえている時に、 テセウスの船 をダサくもじって、 “テセウスのGit” と名付けました。私は父親になって、ひどいダジャレを作れるようになった

    コードの半減期とテセウスの船 | POSTD
    Sixeight
    Sixeight 2016/12/27
    めちゃくちゃおもしろい
  • ひどいダッシュボードの法則 | POSTD

    白状しますが、私にはひどいダッシュボードを構築してきた責任があります。個人的に、この記事に書いた間違いのほとんどを犯してしまいました。ユーザに謝罪するとともに、同じ過ちを繰り返さないことを誓います。これらの過ちが悪い見として、プロジェクトマネージャやデザイナ、エンジニアがひどいダッシュボードを構築したり確認したりする無駄な時間を少し減らすのに役立つことを願います。 法則1:ほとんどのソフトウェアのダッシュボードはひどい ひどいと言うのは このGoogle画像検索 のようなひどさ(まだ吐いていませんよね?)のことではありません。退屈で、設計が不十分で、有用性も一切ないという意味です。 信じられませんか? では、今すぐ優れたダッシュボードのソフトウェア名を3つ挙げてみてください。 見つかりましたか? ええ、そうだと思いました。しかし、ダッシュボードはどこにでもあります。あなたが使っているSa

    ひどいダッシュボードの法則 | POSTD
    Sixeight
    Sixeight 2015/07/09
  • Goはオブジェクト指向言語だろうか? | POSTD

    “オブジェクト指向”の意味を当に理解するには、この概念の始まりを振り返ることが必要です。最初のオブジェクト指向言語はSimulaという言語で、1960年代に登場しました。オブジェクト、クラス、継承とサブクラス、仮想メソッド、コルーチンやその他多くの概念を導入した言語です。おそらく最も重要なのは、データとロジックが完全に独立したものであるとする、当時では全く新しい考え方をもたらしたことでしょう。 Simula自体には馴染みがない方も多いかもしれませんが、Simulaからインスピレーションを得たとされるJavaC++、C#、Smalltalkといった言語は皆さんよくご存知でしょう。さらにそこからインスピレーションを得たものとしてObjective-CやPythonRubyJavaScriptScalaPHPPerlなど様々な言語があり、Simulaは現在使用されているポピュラーな

    Goはオブジェクト指向言語だろうか? | POSTD
    Sixeight
    Sixeight 2015/05/23
  • 開発者の仕事が遅いわけではない!納期が遅れるホントの原因 | POSTD

    “なぜ納期を守れなかったのだろうか?” 我々マネージャが、納期に遅れることを自分のチームのせいにするのは簡単です。しかし、納期に遅れる原因は当に開発者の仕事が遅いせいでしょうか? Sprintly は、開発者のサイクルタイムに関する膨大なデータを保有しています。当社は、タスクのサイズごと(S、M、L、XL)、また種類ごと(ストーリー、テスト、バグ)に、完了までにどれくらいの期間がかかるかを追跡しています。 当社が調査した動向について 1点目:開発者は非常に平均的です。ユーザ全体で見たサイクルタイムはほぼ同じであることを当社のチケットデータが示しています。システム内の全チケットの75%は、開始後およそ175時間で完了しています。 ^(1) 2点目:変動があるのは、ほとんどがチケットが開始される前(SomedayからBacklogまで)の段階です。これは、関係者が仕様を理解して作業の優先順位

    開発者の仕事が遅いわけではない!納期が遅れるホントの原因 | POSTD
  • RESTのベストプラクティス | POSTD

    現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR

    RESTのベストプラクティス | POSTD
    Sixeight
    Sixeight 2015/01/06
  • 1