タグ

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

  • 大規模な決済システムを構築する際に学んだ分散型アーキテクチャの考え方 – 後編 | POSTD

    メッセージの耐久性と持続性 分散型システムのノードは演算し、データを保存し、互いにメッセージを送信し合います。メッセージ送信の重要な指標は、これらのメッセージがどれだけ確実に届くかです。基幹システムでは、消失メッセージがゼロでなくてはならない場合がしばしばあります。 分散型システムにおける通信は、RabbitMQ、Kafkaなどの分散型メッセージングサービスを用いることがほとんどです。こういったメッセージングサービスはメッセージ配信において様々なレベルの信頼性をサポートしています(または、サポートするように設定を変えられます)。 メッセージの永続性とは、メッセージを処理しているノードで何らかの問題が起こった時、その問題の解決後に処理されるよう、メッセージはそこに残ることを意味します。メッセージの持続性は多くの場合、 メッセージキュー レベルで用いられます。持続性のあるメッセージキューを実装

    大規模な決済システムを構築する際に学んだ分散型アーキテクチャの考え方 – 後編 | POSTD
  • 機械が私たちの偏見を継承する仕組み | POSTD

    機械は言語の処理を学習する際、人が書いた文章のサンプルから性別や人種的な偏見を継承します。 トルコ語では、”彼(he)”、”彼女(she)”、”それ(it)”を表すための代名詞が、”o”の1つしかありません。”o”の代名詞が含まれるトルコ語の文章をGoogle翻訳で英語に翻訳する場合、翻訳アルゴリズムは英語のどの代名詞が”o”に相当するのかを推測することになります(性別が不明な場合、大抵は”彼”)。そして、アルゴリズムは ジェンダーバイアス(性差に基づく偏見) を反映しながら、”彼は医者です”、”彼女は看護師です”、”彼は勤勉です”、”彼女は怠け者です”のような形で文章を翻訳するのです。言語処理の学習に際して、多くのアルゴリズムは人が書いたニュース記事やWikipediaなどの文章を参考にしており、こうした言語モデルから単語間の関連付けを行っています。しかしそうすることで、例えば” 「彼」

    機械が私たちの偏見を継承する仕組み | POSTD
  • Makefileを自己文書化する | POSTD

    私たちのプロジェクトではいつも、非常に長い Makefile を使用して、インストールやビルド、テスト、デプロイメントの処理を自動化しています。ターゲット名はほとんど標準化されていますが( make install 、 make deploy )、中には説明が必要なものもあります( make run-dev 、 make restart-api )。そして、詳細なmakeターゲットを追加するほど、それらの処理内容をテキスト形式で大量に記載しなければなりません。私たちのプロジェクトでは通常、このような文書を README ファイルに書いています。 しかしCLI(コマンドラインインタフェース)を用いる場合は、主に自己文書化ツールを使っています。 make と打つだけで、利用可能なコマンドとその説明が一覧表示されたら便利だと思いませんか? それを実現するのは、実はとても簡単です。まずは各ターゲッ

    Makefileを自己文書化する | POSTD
  • なぜPythonはこんなにも遅いのか? | POSTD

    (編注:2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) Pythonは高い人気を誇り、DevOps、データサイエンス、Web開発、セキュリティの分野で使われています。 しかし、速度に関しては高い評価が全くありません。 JavaとC、C++、C#、Pythonの速度を比べるには、どうしたらいいのでしょう? 答えは、実行するアプリケーションのタイプに大きく左右されます。完璧なベンチマークはありませんが、[手始めに比べる手段](https://algs4.cs.princeton.edu/faq/)としてはThe Computer Language Benchmarks Gameが適しています。 私は10年ほどthe Computer Language Benchmarks Gameを参照していますが、Java、C#、GoJavaScriptC++などの他言

    なぜPythonはこんなにも遅いのか? | POSTD
  • コーディング面接とSnakeゲームに唯一共通すること | POSTD

    80年代か90年代に生まれた方ならおそらく、「Snake」というゲームのことをご存じでしょう。「ご存じ」とはつまり、Nokia 3310のちっぽけな画面上でたわいもない巨大ヘビを育てるのに膨大な時間を費やしていたのではないかということです。Nokiaの携帯電話について、皆さんは他にどんな特徴を覚えていますか? バッテリーが長持ちしたことではないでしょうか。 Nokiaはとても”原始的な”携帯電話であったにもかかわらず、バッテリーを使い果たすことなくSnakeゲームで何時間も遊べたのは、どういう訳だったのでしょう? 理由の大部分は、優れた強固なコンポーネントのおかげでした。しかし、貢献度はそれより低く、あまり語られることもありませんが、スライディングウィンドウと呼ばれる手法も長時間のプレイに役立っていたのです。 Snakeだけを扱った記事を1書きたいのは山々ですが、実は記事では後者の、魅

    コーディング面接とSnakeゲームに唯一共通すること | POSTD
  • ツールは解決策ではない | POSTD

    最近、『The Atlantic』に掲載された非常に重苦しい 記事 「The Coming Software Apocalypse」(きたるソフトウェア大惨事)を読み終えました。同記事は最初のうちは、人に傷害を与えたり、人の命を奪ったりした恐ろしいソフトウェアバグについて述べており、いい内容です。しかし、途中から急に残念な展開になっているのです。 同記事の著者はソフトウェア業界の多くの思想的リーダーにインタビューをしましたが、 Light Table 、 モデル駆動工学 、 TLA+ といった新しい技術を生み出したリーダーだけを選んでいます。 私はこうしたツールに何ら反対しているわけではありません。Light Tableプロジェクトに資金提供さえしました。優れたソフトウェアツールは優れたソフトウェアを書きやすくすると思います。しかし、ツールは「大惨事」に対する解決策ではありません。 著者は

    ツールは解決策ではない | POSTD
  • 分散型システム徹底入門 – Part 2. | POSTD

    Cassandra 先ほど触れたCassandraは分散型のNoSQLデータベースで、CAP定理のAとP(可用性と分断耐性)の特性を基準に最終的な一貫性が確保されています。ただ、このように言ってしまうと少し誤解を招くかもしれません。というのも、実際のところCassandraの設定は非常に柔軟性が高く、可用性を犠牲にして強い一貫性を提供することもできるからです。ですが、そうした使用ケースは一般的ではありません。 Cassandraでは、 コンシステントハッシュ法 を使って、渡そうとするデータをクラスタのどのノードが管理するのかを決めています。そしてその際は、データを複製するノード数を示す レプリケーションファクタ を設定します。 注釈: レプリケーションファクタ=3 挿入(キー、値) Cassandraのノード(コーディネータ) Cassandraのノード ハッシュ(キー)=2 ノード#2

    分散型システム徹底入門 – Part 2. | POSTD
  • 私のURLはあなたのURLとは違う : curl作者の語る、URLの仕様にまつわる苦言 | POSTD

    1996年にcurlプロジェクトの先駆けとなるhttpgetを始めたとき、私は初めてURLパーサを書きました。当時はまだ、ユニバーサルアドレスは URL : Uniform Resource Locators と呼ばれていました。その仕様は1994年にIETFによって発行されたものでした。この”URL”という用語からインスピレーションを得てツールとプロジェクトに命名したのが curl でした。 URLという用語は後に事実上、 URI : Uniform Resource Identifiers (2005年発行)に変わりましたが、「オンラインでリソースを指定する文字列のための構文と、そのリソースを得るためのプロトコル」という、基的な点は変わりませんでした。curlでは、この構文仕様RFC 3986の定義に従う”URL”を許容するとうたっていますが、それは厳密には正しくありません。その理由

    私のURLはあなたのURLとは違う : curl作者の語る、URLの仕様にまつわる苦言 | POSTD
  • GitトラブルをGetしてしまったら:バージョン管理のお話 | POSTD

    非常におかしい題名を笑ってくださってありがとうございます。しかし、おかしくないことがありますが、何か分かりますか。git repoにコミットをプッシュした時で、これを GitHubデスクトップ で見ることができます。 Googleを使ってこれが何を意味するか調べてください。 もちろん、 いけている人 が Git Tower を使い、 当に いけている人は コマンドライン のみを使っていることを知っています。我々は当にいけているので、ここではコマンドラインを使って問題を解決します。実は他に選択肢がないのです。この記事で、git専門のコマンドライン知識が全くないのにも関わらず、コマンドラインを使い、全く プログラムの書き手に非がない のに、突然git repoが壊れてしまう問題を解決する冒険に誘います。少なくとも自分に非がないのに突然壊れてしまった時のパニックの度合いを見ていただけるかと思

    GitトラブルをGetしてしまったら:バージョン管理のお話 | POSTD
  • HHVMの今後 | POSTD

    2017年1月、PHPPHP5のアクティブサポート終了を 正式に発表 しました。 私たちHHVMチームはPHPPHP7で打ち出している方向を歓迎しており、この言語とランタイムを今日の位置に推し進める役割を担ったことを光栄に思っています。PHPコミュニティがPHP5に別れを告げようとしている今、HHVMチームも同じ決断を下しました。 HHVMの次のLTSリリースである3.24は、 2018年1月 にテスト公開され、その後1年間サポートされます。また、3.24は PHP5をサポートする最後のHHVMリリース となります。これは、2018年末にPHP5のセキュリティサポートも終了するPHP自体のタイムラインと同調するものです。HHVMチームはPHP5固有の特殊な挙動に対する全てのサポートを即座に中止するわけではありませんが、それらは3.24のテスト公開後はいつでも中止となる可能性があり、ex

    HHVMの今後 | POSTD
  • 製品ロードマップの使用をやめて、GISTプランニングを試すべき理由 | POSTD

    何年にも渡り、私は相応量の製品戦略、ロードマップ、プロジェクトガントチャートを作成しました。しかし、もうこれらの資料を作ることはありません。以下に説明する優れた代替策を見つけたからです。 まず、以前のやり方はこちらです。 注釈: 戦略 ロードマップ プロジェクトプラン 実行 アジャイル このプランニング方式だと膨大な仕事が必要です。株主全員の同意を得るだけでも大変だと言うのにROIはかなり低くなります。プランはあっという間に現実と一致しなくなり、期間が長いほど、乖離も大きくなります。私の作ったすてきなロードマップやプロジェクトガントチャートが公開する時点で既に古くなっていると気づいたのは、少し経ってからでした。このプランニングもウォーターフォールのひとつなので(有名な ウォーターフォール・モデル とは異なります)、即応性はほとんど期待できません。トップで変更があると、それが波及しボトムでの

    製品ロードマップの使用をやめて、GISTプランニングを試すべき理由 | POSTD
  • Dockerコンテナが遅くなるもう一つの原因 | POSTD

    前回の ブログ記事 では、Kubernetesの話と、 ThoughtSpot がKubernetesを開発インフラのニーズに合わせてどのように取り入れたかをご紹介しました。今回はその続報として、最近の興味深いデバッグ経験について少々駆け足になりますがお話ししていきます。記事も「コンテナ化と仮想化はノットイコールである」という事実に基づいており、たとえcgroupの上限がどれも高くない値に設定されホストマシンで十分な演算能力が利用できるとしても、コンテナ化されたプロセス同士がリソースの競合を起こす場合があることを示したいと思います。 ThoughtSpotでは内部のKubernetesクラスタで 多数のCI/CDや開発関連のワークフロー を稼働させており、ある1点を除いては全てが順調でした。唯一問題だったのは、ドッカー化された製品コピーを起動すると、パフォーマンスが期待を極端に下回るレベ

    Dockerコンテナが遅くなるもう一つの原因 | POSTD
  • 15年目のVim | POSTD

    (注:2017/04/19、いただいたフィードバックを元に翻訳を修正いたしました。修正内容については、 こちら を参照ください。) Vim使用について述べた先の投稿( 1 、 2 )は好評だったこともあり、そろそろ更新が必要になりました。Vim 8には非常に要望の多かった機能がたくさん追加され、 VimAwesome のような新しいコミュニティサイトができたことでプラグイン探しと評価が容易になりました。最近では私もVim仕事をする機会がとみに増え、 ピーク効率 に向け自分のワークフローの設定に時間を費やしたりもしています。ですから、この記事は私の現在の状況を写し取ったものです。 大まかには次の内容です。 ファイル特定にはfzfとfzf.vim *ファイル検索にはack.vimと ag Vim + tmuxが勝利への鍵 ALEは新Syntastic。理由はその非同期性 …などなど多数。ぜひ

    15年目のVim | POSTD
  • ディープラーニングの限界 | POSTD

    (注:2017/04/08、いただいたフィードバックを元に翻訳を修正いたしました。 @liaoyuanw ) この記事は、私の著書 『Deep Learning with PythonPythonを使ったディープラーニング)』 (Manning Publications刊)の第9章2部を編集したものです。現状のディープラーニングの限界とその将来に関する2つのシリーズ記事の一部です。 既にディープラーニングに深く親しんでいる人を対象にしています(例:著書の1章から8章を読んだ人)。読者に相当の予備知識があるものと想定して書かれたものです。 ディープラーニング: 幾何学的観察 ディープラーニングに関して何より驚かされるのは、そのシンプルさです。10年前は、機械認識の問題において、勾配降下法で訓練したシンプルなパラメトリックモデルを使い、これほど見事な結果に到達するなど誰も想像しませんでした。

    ディープラーニングの限界 | POSTD
  • PythonとKerasを使ってAlphaZero AIを自作する | POSTD

    自己対戦と深層学習でマシンにコネクトフォー(Connect4:四目並べ)の戦略を学習させましょう。 この記事では次の3つの話をします。 AlphaZeroが人工知能AI)への大きなステップである2つの理由 AlphaZeroの方法論のレプリカを 作って コネクト4のゲームをプレイさせる方法 そのレプリカを改良して他のゲームをプラグインする方法 AlphaGoAlphaGo Zero→AlphaZero 2016年3月、DeepmindのAlphaGo(アルファ碁)が、囲碁の18回の世界王者、李世乭(イー・セドル)との五番勝負で、2億人の見守る中、4-1で勝利しました。機械が超人的な囲碁の技を学習したのです。不可能だとか、少なくとも10年間は達成できないと思われていた偉業です。 AlphaGo 対 李世乭の第3局 このことだけでも驚くべき功績ですが、DeepMindは、2017年10月、

    PythonとKerasを使ってAlphaZero AIを自作する | POSTD
  • Redux-Observable Epic vs Redux-Saga: 何が問題なのか | POSTD

    まず、このバトルに関わるには、JavaScriptとReduxの知識が必要です。知識がない人には、このブログ記事は向いていません(話についていけませんから)。残りの人は、一緒に難題を解決していきましょう。 Reduxには、副作用を取り扱うための所定の方法がありません。そう、これは 祝福であると同時に呪いでもあります。 最善策はこれだ、という結論がまだ出ていないので、かなりの数の選択肢が流布しています。SlackNetflixのような大きな会社がRxJSと Redux-Observable を選んだのに対して、Reactネイティブの開発者たちの間で人気が高いのは Redux Saga です。 うわべを取り繕った記事を書くつもりはなく、道理をわきまえるつもりもありません。私は、この対決を「戦い」に持ち込むつもりなのです。thunkで満足していて、好意的な意見を期待している人は、読まない方がい

    Redux-Observable Epic vs Redux-Saga: 何が問題なのか | POSTD
  • Haskell、OCaml、RacketでGCのレイテンシを測る | POSTD

    James FisherはGHCのランタイムシステムが彼らのHaskellのプログラム上でレイテンシに悪影響を及ぼしたケースを、ブログに投稿しています。 低レイテンシ、大きなワーキングセット、そしてGHCのガベージコレクタ:3つのうち2つを選べ この記事では、その問題(基的に、レイテンシはコピー時間の影響を受ける)を示す非常にシンプルな合成ベンチマークを提案していて、さらに「50ミリ秒のレイテンシは過剰」と言っています。それで、他のGCがどのようにこの問題を処理しているかを見るため、OCamlとRacketで合成ベンチマークを再現したら面白いだろうと思いました。 細かい話は抜きにすると、要点は次のとおりです。OCamlのGCは古い世代にある大きなオブジェクトに関しては問題はありません。コレクションをコピーするのではなくマーク & スイープで処理するためで、このベンチマークではワーストケー

    Haskell、OCaml、RacketでGCのレイテンシを測る | POSTD
  • リモートワークのストレス | POSTD

    リモートワークのストレス ソフトウェアエンジニアリング業界では、リモートワークは大いに理にかなった働き方です。大抵はPCとインターネット接続さえあれば仕事ができるからです。よって、決まったオフィスに毎日通って働く理由は比較的少ないため、リモートワークIT職の重要な要素になっています。最も先見的な求人市場とは決して言えないベルギーにおいてさえもです。とはいっても多くの場合、リモートワークが認められるのは週の一部のみ(おそらく週に1日か2日ぐらいが一般的)にすぎません。それにもかかわらず、リモートワークは大部分の企業で導入されるようになってきたのです。 リモートワークには多くの利点があると言われており、この働き方を過激なまでに擁護する声もよく耳にします。その多くには同意するものの、リモートワークを5年以上してきた経験から言えるのは、リモートワークにはストレスが付き物だということです。そう聞く

    リモートワークのストレス | POSTD
  • 「フロントエンド開発者」の終焉 | POSTD

    元記事の著者より:この記事は主に北米文化で私が見たことを反映しています。 誰かに職業をきかれたら、私は「フロントエンド開発者です」と答えます(答えは相手によって変わることもあります)。10年か20年前は、自分の仕事に必然的に伴うものが何なのかは、かなり明瞭でした。インタラクション用にHTMLCSSを書き、JavaScriptも多少は書いていました。駆け出しの頃、PHPMySQLの作業に職務の大半を費やしていたとはいえ、フロントエンド開発者として見られる方が好きです(これに関しては、後に詳しく説明します)。この状況は、2010年の初頭に変わり始めました。JavaScriptが、重要で、非常に大きな存在になってきたのです。昨年の初め頃から、たくさんのフロントエンド開発者に会うようになり、あることに気付きました。フロントエンド開発者は、もはや、私が以前から知っているフロントエンド開発者ではな

    「フロントエンド開発者」の終焉 | POSTD
  • Goでクリーンアーキテクチャを試す | POSTD

    依存がなく、テスト可能であり、クリーン。 Uncle Bobのクリーンアーキテクチャの概念を読んだので、これを私はGoで実装してみたいと思います。このアーキテクチャは、自分たちの会社である Kurio – App Berita Indonesia で使っていたものに似ていますが、少し違っています。大きな違いはなく、概念は一緒なのですが、フォルダ構造が違っています。 サンプルのプロジェクトとして、記事をCRUDで管理するリポジトリを https://github.com/bxcodec/go-clean-arch にpushしてあります。 * 免責条項 ここで使われているどのライブラリあるいはフレームワークも、利用を特別推奨しているものではありませんので、ご自身あるいはサードパーティによる同じ機能のものと入れ替えることが可能です。 基的な考え方 ご存知のように、クリーンアーキテクチャで設計

    Goでクリーンアーキテクチャを試す | POSTD