React Server Componentsの仕組み：詳細ガイド | POSTD
React Server Components（RSC）は、ページの読み込みパフォーマンスやバンドルサイズのほか、Reactアプリケーションの書き方に近い将来大きな影響を与えることになる、素晴らしい新機能です。 Plasmicでは、Reactのビジュアルビルダーを開発しており、Reactのパフォーマンスには大きな関心を持もっています。 当社のクライアントの多くは、Plasmicを使用して高いパフォーマンスが求められるマーケティングサイトやECサイトを構築しています。 したがって、RSCはまだReact 18の初期実験機能ですが、Plasmicではその仕組みを詳しく調べています。 このブログ記事では、これまでに分かったことを紹介したいと思います。 Plasmicのメンバーによるツイートまとめもご覧ください。 React Server Componentsとは何か サーバサイドレンダリングとの
大規模な決済システムを構築する際に学んだ分散型アーキテクチャの考え方 – 後編 | POSTD
メッセージの耐久性と持続性 分散型システムのノードは演算し、データを保存し、互いにメッセージを送信し合います。メッセージ送信の重要な指標は、これらのメッセージがどれだけ確実に届くかです。基幹システムでは、消失メッセージがゼロでなくてはならない場合がしばしばあります。 分散型システムにおける通信は、RabbitMQ、Kafkaなどの分散型メッセージングサービスを用いることがほとんどです。こういったメッセージングサービスはメッセージ配信において様々なレベルの信頼性をサポートしています（または、サポートするように設定を変えられます）。 メッセージの永続性とは、メッセージを処理しているノードで何らかの問題が起こった時、その問題の解決後に処理されるよう、メッセージはそこに残ることを意味します。メッセージの持続性は多くの場合、 メッセージキュー レベルで用いられます。持続性のあるメッセージキューを実装
大規模な決済システムを構築する際に学んだ分散型アーキテクチャの考え方 – 前編 | POSTD
バックエンドに関する経験があった私は、2年前にモバイルソフトウェアエンジニアとしてUberに入社しました。担当することになった仕事は、決済機能の構築を含む アプリの刷新 です。その後、 技術管理の側に回る ことになり、チームそのものを率いることになります。配下のチームは、決済を行うバックエンドシステムの多くを担当していたため、責任者となった私もバックエンドに触れる機会が以前にも増して多くなりました。 Uberで働く前は、分散型システムの経験はなきに等しかったと言っていいと思います。 それまでの私は、一般的なコンピュータサイエンスの学位を取得後、フルスタックのソフトウェア開発に10年間、関わっていました。分散型システムについては、一応、大まかな仕組みやトレードオフなどは知っていましたが、一貫性や可用性、冪等性などの概念に精通していたとはお世辞にも言えません。 この記事では、大規模で可用性が高
機械が私たちの偏見を継承する仕組み | POSTD
機械は言語の処理を学習する際、人が書いた文章のサンプルから性別や人種的な偏見を継承します。 トルコ語では、”彼（he）”、”彼女（she）”、”それ（it）”を表すための代名詞が、”o”の1つしかありません。”o”の代名詞が含まれるトルコ語の文章をGoogle翻訳で英語に翻訳する場合、翻訳アルゴリズムは英語のどの代名詞が”o”に相当するのかを推測することになります（性別が不明な場合、大抵は”彼”）。そして、アルゴリズムは ジェンダーバイアス（性差に基づく偏見） を反映しながら、”彼は医者です”、”彼女は看護師です”、”彼は勤勉です”、”彼女は怠け者です”のような形で文章を翻訳するのです。言語処理の学習に際して、多くのアルゴリズムは人が書いたニュース記事やWikipediaなどの文章を参考にしており、こうした言語モデルから単語間の関連付けを行っています。しかしそうすることで、例えば” 「彼」
React.jsのアプリにNeo4jの日付と空間のタイプを扱う | POSTD
Neo4j、Mapbox、React、Nivo Chartを使ってダッシュボードのアプリを構築します。 このシンプルなダッシュボードReactアプリは、特定の場所を示す円内で特定の期間内にレビューがあったビジネスを探すことができます。 こちらでお試しください。 概要 Neo4j 3.4は新たに空間と時間の機能をサポートしました。位置と日付というタイプを持ち、クエリで使用してインデックスに使えるようになっています。空間と時間の機能を備えたシンプルなアプリを構築するのはきっと楽しいでしょう。 本記事では、React.jsによるダッシュボードタイプのアプリの構築について段階を追って記していきます。アプリでは、特定の期間内の位置情報を使ってレビュー情報を持つビジネスを検索したり、レビューの総括に基づいた幾つかのチャートを表示させたりします。これから、新しい空間と時間のタイプを用いた neo4j-i
2018ワールドカップのGraphQL APIを作りました | POSTD
ワールドカップ2018の2次予選が始まった後で、私たちは、参加チームについての人々のあらゆる問いに答える 簡単な手段 を作りたいと思いました。 要約 ワールドカップ2018のために、グラフデータベースNeo4jを使ったGraphQL APIを作成しました。試してみたい人は、 ここをクリック してください。 グラフデータベースNeo4jを使ったGraphQL APIの作成 既に私たちは、 ワールドカップについての全てのデータのデータベース を作成して、人々がクエリに使えるようにしましたが、これを、Neo4jのクエリ言語、Cypherを知らない人でもアクセスできるようにしたいと思いました。 GraphQLに助けてもらおう GraphQLの話をする前に、まず、私たちが作ったNeo4jグラフモデルを見てください。 グラフの中央に WorldCup ノードがあって、その周りにモデルの他のパーツが散ら
分散型システム徹底入門 – Part 2. | POSTD
Cassandra 先ほど触れたCassandraは分散型のNoSQLデータベースで、CAP定理のAとP（可用性と分断耐性）の特性を基準に最終的な一貫性が確保されています。ただ、このように言ってしまうと少し誤解を招くかもしれません。というのも、実際のところCassandraの設定は非常に柔軟性が高く、可用性を犠牲にして強い一貫性を提供することもできるからです。ですが、そうした使用ケースは一般的ではありません。 Cassandraでは、 コンシステントハッシュ法 を使って、渡そうとするデータをクラスタのどのノードが管理するのかを決めています。そしてその際は、データを複製するノード数を示す レプリケーションファクタ を設定します。 注釈： レプリケーションファクタ＝3 挿入（キー、値） Cassandraのノード（コーディネータ） Cassandraのノード ハッシュ（キー）＝2 ノード#2
分散型システム徹底入門 – Part 3. | POSTD
BitTorrent BitTorrentは、Web上でtorrentを使って大容量ファイルを転送する際に広く使われているプロトコルです。その主な目的はメインサーバを経由することなく、ネットワーク内のさまざまなピア間でのファイル転送を容易にすることです。 BitTorrentクライアントを使うと、世界中の複数のコンピュータに接続してファイルをダウンロードします。.torrentファイルを開くと、コーディネーターのような役割を果たすマシン、いわゆる トラッカ に接続されます。トラッカはピアを見つけ出し、欲しいファイルを持っているネットワーク内のノードを示してくれます。 注釈： トラッカ ・オンラインのノードをトラッキングする ・ノードが何のファイルを提供しているかを認識する Seeder：シーダ Leeche： リーチャ 破線：ファイル転送 実線：メタデータ転送 ネットワークのサンプル ユー
GraphQLはWeb APIの次のフロンティアか？ | POSTD
RESTの規約。URLはリソースであり、CRUDはHTTP動詞にマップされる。 RESTの規約に1つ問題があるとすれば、規約が十分でないということでしょう。上記で”通常”、”多くの場合”、”時に”という表現を使ったのは、これらのやり方は仕様で推奨されているものの守られるとは限らないためです。実世界では、大抵のAPIはRESTishがせいぜいです。例えばStripeでは、リソース更新に PUT ではなく PATCH を使うべきですが、歴史的理由でそうはなっておらず、おそらく現時点では変更に値しないでしょう。いずれにしても開発者はドキュメントを読む必要があり、その時、 POST メソッドのユビキタスな使い方があることに気づくのです。 RESTには他の問題もあります。必要なものだけでなく全てが返ってくるため、リソースのペイロードが非常に大きくなることがあるのです。そして多くの場合、クライアントが
製品ロードマップの使用をやめて、GISTプランニングを試すべき理由 | POSTD
何年にも渡り、私は相応量の製品戦略、ロードマップ、プロジェクトガントチャートを作成しました。しかし、もうこれらの資料を作ることはありません。以下に説明する優れた代替策を見つけたからです。 まず、以前のやり方はこちらです。 注釈： 戦略 ロードマップ プロジェクトプラン 実行 アジャイル このプランニング方式だと膨大な仕事が必要です。株主全員の同意を得るだけでも大変だと言うのにROIはかなり低くなります。プランはあっという間に現実と一致しなくなり、期間が長いほど、乖離も大きくなります。私の作ったすてきなロードマップやプロジェクトガントチャートが公開する時点で既に古くなっていると気づいたのは、少し経ってからでした。このプランニングもウォーターフォールのひとつなので（有名な ウォーターフォール・モデル とは異なります）、即応性はほとんど期待できません。トップで変更があると、それが波及しボトムでの
より良い製品案を選択するために役立つツール | POSTD
あなたはスモールビジネスの顧客サポートに役立つ製品を管理しているとしましょう。目指しているのは、顧客のエンゲージメントとリテンションのレベルを向上させることです。検討中の案が2つあります。 * 事業主がエンゲージメントの統計と傾向をモニターできる、 ダッシュボード * 事業主が顧客とのコミュニケーションを自動化するのに役立つ、 チャットボット ダッシュボード案は顧客との話の中で何度か話題にのぼり、潜在的需要が高いと思われますが、使うのがパワーユーザだけかもしれないというリスクもあります。チャットボットは会社の皆が気に入っていて、経営陣は強気でこれを推しています。顧客は大いに喜ぶでしょうし、クールなプロジェクトですし、なにより、チャットボットは大流行しています。 あなたなら、どちらを選びますか？ 画像提供： Matthew Henry このような優先順位付けの問題は、製品管理の核心です。選択
Dockerコンテナが遅くなるもう一つの原因 | POSTD
前回の ブログ記事 では、Kubernetesの話と、 ThoughtSpot がKubernetesを開発インフラのニーズに合わせてどのように取り入れたかをご紹介しました。今回はその続報として、最近の興味深いデバッグ経験について少々駆け足になりますがお話ししていきます。本記事も「コンテナ化と仮想化はノットイコールである」という事実に基づいており、たとえcgroupの上限がどれも高くない値に設定されホストマシンで十分な演算能力が利用できるとしても、コンテナ化されたプロセス同士がリソースの競合を起こす場合があることを示したいと思います。 ThoughtSpotでは内部のKubernetesクラスタで 多数のCI/CDや開発関連のワークフロー を稼働させており、ある1点を除いては全てが順調でした。唯一問題だったのは、ドッカー化された製品コピーを起動すると、パフォーマンスが期待を極端に下回るレベ
カオステストでHTTP/2の問題を見つけ出す | POSTD
(注：2017/04/20、いただいたフィードバックを元に翻訳を修正いたしました。修正内容については、 こちら を参照ください。) 要約 HTTP/2 にはHTTP/1.xに比べて多数の改良点がありますが、 カオステスト を行ったところ、HTTP/2のパフォーマンスがHTTP/1より劣る状況があることが分かりました。 ネットワーク上にパケット損失がある場合、TCP層での輻輳制御によって、少数のTCPコネクションの中に多重化されているHTTP/2ストリームがスロットリングされます。さらに、TCPリトライのロジックにより、リトライが行われている間、1つのTCPコネクションに影響しているパケット損失が、いくつかのHTTP/2ストリームに同時に強い影響を与えます。言い換えれば、ヘッドオブラインブロッキングが事実上、ネットワーク階層の レイヤ7 から レイヤ4 へ移動したということです。 背景とサー
15年目のVim | POSTD
(注：2017/04/19、いただいたフィードバックを元に翻訳を修正いたしました。修正内容については、 こちら を参照ください。) Vim使用について述べた先の投稿（ 1 、 2 ）は好評だったこともあり、そろそろ更新が必要になりました。Vim 8には非常に要望の多かった機能がたくさん追加され、 VimAwesome のような新しいコミュニティサイトができたことでプラグイン探しと評価が容易になりました。最近では私もVimで仕事をする機会がとみに増え、 ピーク効率 に向け自分のワークフローの設定に時間を費やしたりもしています。ですから、この記事は私の現在の状況を写し取ったものです。 大まかには次の内容です。 ファイル特定にはfzfとfzf.vim *ファイル検索にはack.vimと ag Vim + tmuxが勝利への鍵 ALEは新Syntastic。理由はその非同期性 …などなど多数。ぜひ
PythonとKerasを使ってAlphaZero AIを自作する | POSTD
自己対戦と深層学習でマシンにコネクトフォー（Connect4：四目並べ）の戦略を学習させましょう。 この記事では次の3つの話をします。 AlphaZeroが人工知能（AI）への大きなステップである2つの理由 AlphaZeroの方法論のレプリカを 作って コネクト4のゲームをプレイさせる方法 そのレプリカを改良して他のゲームをプラグインする方法 AlphaGo→AlphaGo Zero→AlphaZero 2016年3月、DeepmindのAlphaGo（アルファ碁）が、囲碁の18回の世界王者、李世乭（イー・セドル）との五番勝負で、2億人の見守る中、4-1で勝利しました。機械が超人的な囲碁の技を学習したのです。不可能だとか、少なくとも10年間は達成できないと思われていた偉業です。 AlphaGo 対 李世乭の第3局 このことだけでも驚くべき功績ですが、DeepMindは、2017年10月、
ディープラーニングにおけるセマンティックセグメンテーションのガイド2017年版 | POSTD
Qureでは、私たちは通常、セグメンテーションとオブジェクト検出の問題に取り組んでいます。そのため、最先端技術の動向について検討することに関心があります。 本稿では、セマンティックセグメンテーションに関する論文を検討します。セマンティックセグメンテーションの研究の多くは、自然界・現実世界の画像データセットを使用します。その結果を医療用画像に直接適用できるわけではありませんが、現実世界の画像に関する研究は医療用画像のものよりもずっと成熟しているので、これらの論文を見直してみたいと思います。 本稿は、以下のような構成です。最初に セマンティックセグメンテーションの問題を説明 し、 アプローチ方法に関する概略 を述べます。最後に いくつかの興味深い論文を要約します。 今後の記事で、医療用画像が現実世界の画像となぜ異なるのかを説明する予定です。更に、今回の再検討から得たアプローチが、医療用画像の代
100万回のWebSocket接続とGo | POSTD
こんにちは。私はSergey Kamardin（セルゲイ・カマルディン）です。Mail.Ru（ロシアの電子メールサービス会社）で開発者をしています。 この記事では、どのように私がGoを使って高負荷対応のWebSocketサーバを開発したかについて説明したいと思っています。 パフォーマンス最適化のアイデアやテクニックを通じて、WebSocketの知識はあるもののGoについてはほとんど知らないという方のお役に立てれば幸いです。 1. はじめに まずは開発に至った経緯について、どうして私たちがこのサーバを必要としたのかを説明しておきましょう。 Mail.Ruには多くのステートフルなシステムがあります。ユーザのeメール保存もその1つです。システム内、およびシステムイベントの状態変更を追跡する方法にはいくつかの種類がありますが、それらは主に状態変更に関するシステム通知、または周期的なシステムのポーリ
Unixコマンド”yes”についてのちょっとした話 | POSTD
知っているUnixのコマンドで一番シンプルなものは何ですか？ 例えば echo という、stdoutに文字列を出力し true を返す – すなわち常に0の終了コードで終了するシンプルなコマンドがあります。 シンプルな、と言えば yes もそうでしょう。引数なしで実行すると、改行されたyが無限に出力され続けます。
SQLトランザクション分離 実践ガイド | POSTD
(注：2017/10/16、いただいたフィードバックを元に翻訳を修正いたしました。) (注：2017/10/11、いただいたフィードバックを元に翻訳を修正いたしました。) データベースのドキュメントで分離レベルを目にして、軽く不安を感じつつ、あまり考えないようにしたことはないでしょうか。トランザクションの日常の使用例できちんと分離について言及しているものはほとんどありません。多くはデータベースの初期設定の分離レベルを利用しており、後は運頼みです。しかし、本来、理解しておくべき基本的なトピックであり、いくらか時間を投入してこのガイドの内容を学習すれば、もっと快適に作業できるようになるでしょう。 私はこの記事の情報を学術論文、PostgreSQLドキュメンテーションから集めました。分離レベルの 何たる かだけでなく、適用の正確さを保持しつつ最大速度で使うにはいつ使うべきか、という疑問に答えるべ
ファイルシステムよりも35％高速に | POSTD
1. 概要 SQLiteを使うと小さなBLOB（例：サムネイル画像など）を読み書きする場合、fread()やfwrite()を使って個別のファイル上に記録されたBLOBを読み書きするよりも35％も速く (*1) 読み書きができます。 さらに、10キロバイトのBLOBを扱うようなSQLiteデータベースを考えた場合、個別のファイルにそれぞれのBLOBを格納する場合に比べてディスク領域を約20％も節約可能です。 このようなパフォーマンスの差が生じる理由は、（私たちの考えでは）SQLiteデータベースの場合、open()やclose()システムコールが呼び出されるのが1回だけなのに対して、個別のファイルに格納されているBLOBを使用する場合は、open()やclose()がBLOBの数だけ呼び出されるためだと思われます。どうやらopen()とclose()を呼び出すオーバーヘッドは、データベース
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
