あまり知られていないPostgreSQLの機能 | POSTD
あなたが知らない既存機能があるかもしれません！ マイクロソフト社は2006年、Microsoft Officeの新バージョンで追加してほしい機能について、顧客調査を実施しました。驚いたことに、ユーザが希望した機能の90%以上はすでに実装されており、その存在が知られていないだけであることが判明しました。機能の「見つけにくさ」の問題の解決策として同社が考案したのが、現在のMicrosoft Office製品でおなじみの「リボンUI」です。 この問題はOfficeに限ったものではありません。日々使用するツールの機能をすべて把握している人はほとんどいません。PostgreSQLのように大規模なツールであればなおさらです。数週間前にPostgreSQL 14がリリースされたばかりなので、この機会にPostgreSQLのあまり知られていない機能に注目してみたいと思います。 この記事では、Postgre
Web 3.0: Webの移行が始まっている | POSTD
多くの人が気付かないうちにWeb2.0からWeb3.0への移行が進みそうです。アプリケーションの見た目は現在使っているものとほとんど変わりませんが、バックエンドで変化が進んでいきます。未来を予測する人ならば、クラウドを使うSiacoin、ソーシャルメディアのプラットフォームとしてのSteemit、さらに未来を予想する手段としてAugurも頭に浮かぶのではないでしょうか。 適正に動く最初のブロックチェーンがリリースされたことを見れば、人々がWeb2.0を離れWeb3.0へ向かっているのは明らかでしょう。なぜなら、開発者というのはテクノロジーとWeb2.0のユーザーフレンドリーな手法を身につけても、更に使いやすいと考えられているWeb3.0に着手しようとするからです。 上の図の分布では、いろいろな企業とWeb2.0のセグメントが示され、ブロックチェーンに基づいたプロジェクトのどれに勝ち目がある
大規模な決済システムを構築する際に学んだ分散型アーキテクチャの考え方 – 後編 | POSTD
メッセージの耐久性と持続性 分散型システムのノードは演算し、データを保存し、互いにメッセージを送信し合います。メッセージ送信の重要な指標は、これらのメッセージがどれだけ確実に届くかです。基幹システムでは、消失メッセージがゼロでなくてはならない場合がしばしばあります。 分散型システムにおける通信は、RabbitMQ、Kafkaなどの分散型メッセージングサービスを用いることがほとんどです。こういったメッセージングサービスはメッセージ配信において様々なレベルの信頼性をサポートしています（または、サポートするように設定を変えられます）。 メッセージの永続性とは、メッセージを処理しているノードで何らかの問題が起こった時、その問題の解決後に処理されるよう、メッセージはそこに残ることを意味します。メッセージの持続性は多くの場合、 メッセージキュー レベルで用いられます。持続性のあるメッセージキューを実装
リレーショナルデータベースの仕組み (1/3) | POSTD
リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術（ビッグデータ、NoSQL、JavaScriptなど）を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか？ 私は開発者として、理解していないものを
Dockerコンテナが遅くなるもう一つの原因 | POSTD
前回の ブログ記事 では、Kubernetesの話と、 ThoughtSpot がKubernetesを開発インフラのニーズに合わせてどのように取り入れたかをご紹介しました。今回はその続報として、最近の興味深いデバッグ経験について少々駆け足になりますがお話ししていきます。本記事も「コンテナ化と仮想化はノットイコールである」という事実に基づいており、たとえcgroupの上限がどれも高くない値に設定されホストマシンで十分な演算能力が利用できるとしても、コンテナ化されたプロセス同士がリソースの競合を起こす場合があることを示したいと思います。 ThoughtSpotでは内部のKubernetesクラスタで 多数のCI/CDや開発関連のワークフロー を稼働させており、ある1点を除いては全てが順調でした。唯一問題だったのは、ドッカー化された製品コピーを起動すると、パフォーマンスが期待を極端に下回るレベ
ディープラーニングの限界 | POSTD
(注：2017/04/08、いただいたフィードバックを元に翻訳を修正いたしました。 @liaoyuanw ) この記事は、私の著書 『Deep Learning with Python（Pythonを使ったディープラーニング）』 （Manning Publications刊)の第9章2部を編集したものです。現状のディープラーニングの限界とその将来に関する2つのシリーズ記事の一部です。 既にディープラーニングに深く親しんでいる人を対象にしています（例：著書の1章から8章を読んだ人）。読者に相当の予備知識があるものと想定して書かれたものです。 ディープラーニング： 幾何学的観察 ディープラーニングに関して何より驚かされるのは、そのシンプルさです。10年前は、機械認識の問題において、勾配降下法で訓練したシンプルなパラメトリックモデルを使い、これほど見事な結果に到達するなど誰も想像しませんでした。
Dockerの本番運用 | POSTD
以前に私が書いた「 Dockerの本番運用：失敗の歴史) 」という記事は、非常に多くの反響を呼びました。 その後、長い議論を交わして、何百件ものフィードバックや何千件ものコメントを読み、さまざまな人々や主要事業者とも顔を合わせました。Dockerでの試みが増えるほど、その失敗談は増えていきます。そうした現状を、今回アップデートしておきたいと思います。 この記事では、最近の交流や記事から得た教訓を紹介しますが、その前に簡単におさらいをして軽く背景を説明しましょう。 免責事項：対象読者 たくさんのコメントから、世の中には10種類の人々が存在するということが明らかになりました。 1) アマチュア 実際のユーザがいない試用版のプロジェクトやサイドプロジェクトを実行している人々です。Ubuntuのベータ版を使用するのが当然だと考えており、「安定したもの」は古いものと見なすようなタイプです。 注釈：書
私たちはいかにして環状線で”悪さをする列車”を捕まえたか | プログラミング | POSTD
文：Daniel Sim 分析：Lee Shangqian、Daniel Sim、Clarence Ng ここ数ヶ月、シンガポールのMRT環状線では列車が何度も止まるものの、その原因が分からないため、通勤客の大きな混乱や心配の種となっていました。 私も多くの同僚と同じように環状線を使ってワンノースのオフィスに通っています。そのため、11月5日に列車が止まる原因を調査する依頼がチームに来た時は、ためらうことなく業務に携わることを志願しました。 鉄道運営会社SMRTと陸上交通庁（LTA）による事前調査から、いくつかの電車の信号を消失させる信号の干渉があり、それがインシデントを引き起こすことが既に分かっていました。信号が消失すると列車の安全機能である緊急ブレーキが作動するため、不規則に電車が止まる原因となります。 しかし8月に初めて発生した今回のインシデントは、不規則に起こっているように見えるた
Dropboxが構築したMagic Pocketの中身：エクサバイトのストレージシステムの仕組み | POSTD
自社で構築した数エクサバイトのストレージシステム、 Magic Pocketを発表 して以来、多くの好意的なフィードバックをいただいています。この発表に続きまして、舞台裏からシステムの興味深い側面を見ていただくことができる技術ブログシリーズを投稿していこうと思います。保護の仕組み、運用ツール、ハードウェアとソフトウェアの境界線上の革新などです。しかし、まず、背景を説明する必要があるでしょう。本稿では、Magic Pocketのアーキテクチャ概略と設計で使われた基準についてお話しします。 紹介の投稿 で説明しましたように、Dropboxには、ファイルの内容と、ファイルやユーザについてのメタデータという2種類のデータが保存されます。Magic Pocketは、ファイルの内容を保存するのに使われるシステムです。保存するファイルは、ブロックに分割されて耐久性のためにレプリケーションされ、複数の地域
分散システムについて語るときに我々の語ること ― 分散システムにまつわる重要な概念について | POSTD
分散システムについては、もう随分と前から学びたいと思っていました。ただ、それは一度首を突っ込んだら最後、ゴールのない迷路に迷い込むようなものなのです。どこまでも続いているウサギの穴のようなものです。分散システムに関する文献は星の数ほど存在します。様々な大学からたくさんの論文が発表されているばかりでなく、膨大な数の書籍もあるのです。私のような全くの初心者には、どの論文を読んだらいいのか、どの書籍を買ったらいいのか、見当もつきません。 そんなとき、一部のブロガーが、 分散システムエンジニア （それがどういう意味であれ）になるなら知っておくべき論文というものを推奨しているのを見つけました。その一部を紹介しましょう。 FLP , Zab , Time, Clocks and the Ordering of Events in a Distributed Systems , Viewstamped
データサイエンスのワークフロー ― データ分析を効率に行うために | POSTD
データを扱うときに、きちんと定められたワークフローがあると助かります。具体的には、「ストーリーを伝える」（データの可視化／ジャーナリズム）ことだけを目的として分析を行いたいのか、それとも一定のタスク（データマイニング）をモデリングするためにデータに依存するシステムを構築することが目的なのか、プロセスが重要です。前もって方法論を定めておくことによって、チームの足並みが揃い、次に何をすべきか考え出そうとして無駄な時間を費やさなくて済みます。それによって早く結果が得られ、資料の公表も早くなります。 これを念頭に、Ashley Madisonの漏洩データ分析に関する 前回の記事 に続いて、私たちが現在使用しているワークフローをご紹介します。このワークフローは、データ漏洩（Ashleyのケースなど）を分析するためだけでなく、社内のデータの分析にも使用されます。ただし、重要な点として、このワークフロー
障害の事後分析を読んで得た教訓 ― 「何がシステムを停止させるのか？」 | POSTD
私はポストモーテム（事後分析）の記録を読むのが大好きです。ポストモーテムを読むと勉強になりますが、大抵の教材的資料とは違って、興味深いストーリーが含まれているのです。相当な時間をかけてGoogleとMicrosoftのポストモーテムを読みました。大きな障害を招く最大の原因について、私は（まだ）きちんと分析していませんが、何度も繰り返し目にするポストモーテムのパターンがいくつかあります。 エラーハンドリング 適切なエラーハンドリングのコードを書くのは難しいものです。エラーハンドリングのコードに含まれるバグは、 大きな 問題を引き起こす主な原因となっています。つまり、エラーによってバグのあるエラーハンドリングのコードが実行されるということは、単に個々のエラーが重なるだけという事態にはとどまらないのです。障害が重なって重大なシステム停止につながることはよくあります。それはある意味明らかなことで、
Vimの生産性を高める12の方法 | POSTD
1. LeaderをSpaceキーにする Leader は素晴らしい概念です。キーの 組み合わせ ではなく 並び によって、操作を行えるようにするものです。私はこれを使っているので、操作のために” Ctrl -何らかのキー”の組み合わせを押す必要はめったにありません。 私は長い間、 , を Leader キーとして使っていました。ですがある時、キーボードの中で一番目立つキーにマップすることを思い付いたのです。Space（スペース）キーです。 これで私のVim生活は激変しました。今や、私は Leader をどちらの親指でも押すことができ、他の指は常にホームポジションにあります。 Leader がとても使いやすくなったので、私が様々なキーバインドで用いるようになったことは周知の話です。 2. 自分が特によく行う操作をLeaderにマップする 私は、自分がVimで作業を行っている中で、その時間の
ビヘイビア駆動開発 ― ウォーターフォールモデルからのステップ | POSTD
ビヘイビア駆動開発（BDD：Behavior-Driven Development、振る舞い駆動開発ともいう）を実務に沿って簡単に紹介し、ソフトウェア開発プロセスに対してこの手法がどれほど有益かを説明します。 はじめに BDDで重視しているのは、フィードバックループを最小限に短縮することです。BDDはソフトウェア開発手法の進化の中で、理論的に一歩前進したものといえます。本稿ではBDDの概念と、その原型のモデルを説明します。 ソフトウェア開発者や、エンジニア部門のマネージャー職に就いている人ならば恐らく、以下の図のようなウォーターフォールモデルはよくご存じでしょう。 注釈: Waterfall model：ウォーターフォールモデル System Requirements：システム要件定義 Software Requirements：ソフトウェア要件定義 Analysis：要求分析 Progr
パフォーマンス分析の方法論23選 | POSTD
パフォーマンス分析のメソドロジーとは、システムやアプリケーションのパフォーマンスを分析する際に準拠できる手法です。メソドロジーを手がかりとして作業に着手できますし、根本原因やその他の要因の発見に役立ちます。異なる種類の問題を解決するのには、それぞれに適したメソドロジーがあります。目的を達成するまでに何度か方法を変えて試してみるといいかもしれません。 メソドロジーを使わない分析は手探りの探索になり、ある問題に対する手がかりが見つかるまで（もしあればですが）ずっと場当たり的にメトリクスを分析することになってしまいます。 このサイトでは以下のメソドロジーについて詳しい資料を公開しています。 USE（Utilization Saturation and Errors）メソッド ：リソースのボトルネックを見つける TSA（Thread State Analysis：スレッドステート分析）メソッド ：
Less is more：プログラミング言語設計の進歩史 | POSTD
多くの言語は冗長性を有していますが、これらの機能を省いていくことも言語設計の進歩につながります。 巷には数多くのプログラミング言語があり、新しい言語も継続的に紹介されています。でも新しいものが古いものより優れているかというと、そうとは言えません。なぜなら、何が“優れているか”を判断する明確な尺度は存在しないからです。 それでも過去からの流れを見ていくと、優れた言語を作る1つの方向性は、言語にある冗長性を特定し、それらを持たない新たな言語をデザインすることにあるように思えます。 「完璧とは、それ以上足せない時ではなく、それ以上引けない時に達成される」 – Antoine de Saint Exupéry この投稿では、現在までに知られている言語の冗長的機能を見ていくと共に、恐らく冗長性を有しているだろうと思われる機能についても触れていきます。 自ら墓穴を掘るあらゆる可能性 初めてコンピュータ
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
なぜsystemdなのか？ | POSTD
このブログ記事は2014年5月21日に行った私の講演の内容に基づいています。 ここ数年、GNU/LinuxのディストリビューションはSysV initを避ける傾向にあり、代わりに多種多様な新しいinitシステムへと移行が進んでいます。SysV initに満足しているユーザにとっては、これは予想外の流れでしょう。問題なく使えるのに、なぜ多くのディストリビューションはSysV initに背を向けているのでしょうか。 この記事ではSysV initの問題点と、それに対してsystemdがどんな解決法を提供しているのか説明してみようと思います。 私は特にsystemdの大ファンだというわけではなく、ただ広く使われているツールだという認識以上の思い入れは無いことだけお断りしておきます。 initシステムの役割とは何か？ コンピュータが起動する時には、ビルトインされたファームウェア（コンピュータの場合
「ほとんどのユニットテストが役に立たない理由」を読んで | POSTD
数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか？ 私が何かを見逃したのでしょうか？ 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト
パイプとフィルタ ~ソフトウェア工学における有用なアーキテクチャ~ | POSTD
パイプライン は、最近のソフトウェアエンジニアリングにおいて、非常に便利な（そして驚くほど活用されていない）アーキテクチャパターンです。ソフトウェアでデータの流れを制御するためにパイプとフィルタを用いる考え方は、最初のUNIXシェルが作られた1970年代からあります。もしターミナルエミュレータでパイプ” | ”を使ったことがあるなら、”パイプとフィルタ”を活用できていることになります。以下の例を見てみましょう。 cat /usr/share/dict/words | # Read in the system's dictionary. grep purple | # Find words containing 'purple' awk '{print length($1), $1}' | # Count the letters in each word sort -n | # Sort l
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
