今週お話しするのは、誤りの検知についてと、さらに誤りの訂正についてです。 我々が住んでいる世界は完璧ではなく、デジタルの信号(on/off)を扱う時でさえ誤りが生じます。電力の異常によりビットが反転することがあるのです。ハードウェアも失敗を起こすことがあり、信号が歪められることもあります。 デジタル信号に生じた誤りを検知する方法については既に過去に書いたことがあります。もっとも一般的なやり方は、ある種のパリティビット(ご存知なくともご心配なく。以下でパリティの意味を説明します)です。ある長さの単語に対し、シンプルなパリティビットをたった1つ加えることで、単語中のビットが1つ反転した場合にそれを検知することができます。「エラーが起こったことがわかる」ということは有益ですが、1個のパリティビットだけではその誤った信号を修復することができません。また、信号中に2個以上の誤りがあった場合、その誤り

POSTD読者の皆さんはじめまして、本メディアでキュレーターを担当させていただいている古川陽介と申します。 株式会社ニジボックスでデベロップメント室室長を務める他、株式会社リクルートでプロダクト開発部署のマネージャーも兼務しています。 また、Japan Node.js Associationの代表理事として、Node.js の普及を目指す活動なども行っています。 私が普段の仕事や活動の中で強く感じているのは、フロントエンドエンジニアの役割が大きな変換点を迎えているということです。 端的に表現するとスマートフォンの登場をきっかけとしたデバイスの多様化によって、フロントエンドエンジニアの領域が拡大したと言うことになると思います。 パフォーマンスや開発の生産性を著しく上昇させる、ReactやVueを駆使したモダンフロントエンド開発と、それを実現するための組織構築は、今後のサービスやプロダクト開発

一般ユーザー向けの大規模なWebサイトや、モダンWeb上で動作するWebアプリケーションを運営する場合、CDNなどのキャッシングサービスによって静的コンテンツをキャッシュすることが極めて重要です。 しかしこうしたサービスは、非常に複雑で分かりにくいものです。 幸い、IETF（Internet Engineering Task Force）のHTTPワーキンググループがこの状況を改善すべく、HTTPの新標準策定に取り組んでいます。 最近、同ワーキンググループでは、キャッシングのデバッグとキャッシュ設定の管理を容易にすることを目的とした、HTTPヘッダに関する2つの新標準案の発表に向けて活発な動きがありました。 このことが何を意味し、どのように機能するのか、そしてWeb制作に携わる開発者全てがなぜ注目すべきなのかについて見ていきます。 新標準 この記事で取り上げる標準案は以下の2つです。 Ca

「CDN」（content delivery network）という言葉からは、Googleのような大企業がいくつもの巨大なハードウェアを管理し、1秒当たり何百ギガビットものデータを処理する様子が想像されます。しかし、CDNは単なるWebアプリケーションです。私たちのイメージとは違いますが、それが事実です。8年前に買ったノートパソコンを使って、コーヒーショップの席に座りながらでも、きちんと機能するCDNを構築できます。この記事では、これから5時間でCDNを開発しようとするときに、直面するかもしれないことを紹介します。 まずはCDNの機能を明らかにしておきましょう。CDNはセントラルリポジトリ（通称：オリジン）からファイルを吸い上げ、ユーザーに近い場所でコピーを保存します。初期のオリジンはCDNのFTPサーバーでした。現在、オリジンは単なるWebアプリとなり、CDNはプロキシサーバーとして機

Webパフォーマンスの向上は、コンバージョンの改善と利益の増加につながります。これに関しては極めて多くのケーススタディが存在しており、テクノロジーの専門知識を持たないプロダクトマネージャーでさえこの事実を知っていることも珍しくありません。それでは一体なぜ、最後の差し迫った緊急事態に至るまで、場合によっては顧客のネガティブなフィードバックが殺到し、Webサイトのパフォーマンスの悪さが浮き彫りになるまで、パフォーマンスへの取り組みは後回しにされることが非常に多いのでしょうか？ 私は幸運にも、それぞれ独自の背景と課題を有する幅広いプロジェクトのパフォーマンス面に長年取り組むことができました。しかし、経験を積むにつれて、私はほとんどの時間をコードの最適化ではなくプロセスの最適化に費やすようになりました。私は元々ソフトウェア開発者なので、コードを精査してボトルネックを発見し、別の選択肢を提案・実装し

Dockerを使い始めた人がよくする質問といえば、「どうすればコンテナに入れますか？」です。その質問に対して、「コンテナ内でSSHサーバを起動すればいいよ」と答える人たちがいますが、これは非常にマズいやり方です。なぜその方法が間違いなのか、そして代わりにどうすればよいのかをこれから紹介します。 注：本記事へのコメントやシェアは、 Dockerブログ にアップされた標準版から行ってください。よろしくお願いします。 コンテナでSSHサーバを起動すべきではない …もちろん、コンテナ自体がSSHサーバである場合は除きます。 SSHサーバを起動したくなる気持ちは分かります。それはコンテナの”中に入る”簡単な方法だからです。この業界の人ならほぼ全員がSSHを一度は使ったことがあります。多くの人がSSHを日常的に使用し、公開鍵や秘密鍵、パスワード入力の省略、認証エージェント、そして時にはポート転送やその

デスクトップ ここでは、実際にデスクトップアプリケーションにならしめているデスクトップアプリケーションの一部についてお話しします。特定のスキルセットを必要とするデスクトッププラットフォームは大量に存在しています。例えば、Photoshopは画像を扱うアプリケーションなので、Photoshopなどで何か書きたければ、画像の処理を行うアルゴリズムと技法を絶対に知っておく必要があります。Dropboxなどで何か書きたい場合は、ソケットプログラミングを絶対に知っておく必要があります。そしてVisual StudioなどでコンパイラやIDEをビルドしたければ、コンパイラの操作方法を絶対に知っておく必要があります。ここではその詳細には触れません。デスクトッププラットフォームに取り組みたい場合に最も使う可能性のある言語について見ていきます。 デスクトッププラットフォームに関して言えば、プログラマはC++

情報科学科の卒業生やプログラマの中には、UberやNetflixのような新興企業や、 Amazon 、 Microsoft 、 Google のような大企業や、InfosysやLuxsoftのようなサービスを基本とする企業で、プログラミング、コーディング、ソフトウェア開発の仕事に就きたいと考える人が大勢います。しかし、実際にそういった企業で面接を受ける場合、大半の人が プログラミングに関してどのような質問をされるか 見当もつきません。 この記事では、 新卒生からプログラマになって1〜2年までの 経験値が異なる人たち向けに、それぞれの プログラミングの面接でよく聞かれる質問 をいくつか紹介していきます。 コーディングの面接では、主に データ構造とアルゴリズムに基づいた質問 がされますが、 一時変数を使わずにどのように2つの整数をスワップするのか 、というような論理的な質問もされるでしょう。

バックエンドに関する経験があった私は、2年前にモバイルソフトウェアエンジニアとしてUberに入社しました。担当することになった仕事は、決済機能の構築を含む アプリの刷新 です。その後、 技術管理の側に回る ことになり、チームそのものを率いることになります。配下のチームは、決済を行うバックエンドシステムの多くを担当していたため、責任者となった私もバックエンドに触れる機会が以前にも増して多くなりました。 Uberで働く前は、分散型システムの経験はなきに等しかったと言っていいと思います。 それまでの私は、一般的なコンピュータサイエンスの学位を取得後、フルスタックのソフトウェア開発に10年間、関わっていました。分散型システムについては、一応、大まかな仕組みやトレードオフなどは知っていましたが、一貫性や可用性、冪等性などの概念に精通していたとはお世辞にも言えません。 この記事では、大規模で可用性が高

(編注：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#、Go、JavaScript、C++などの他言

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

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

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

(注：2017/04/20、いただいたフィードバックを元に翻訳を修正いたしました。修正内容については、 こちら を参照ください。) 要約 HTTP/2 にはHTTP/1.xに比べて多数の改良点がありますが、 カオステスト を行ったところ、HTTP/2のパフォーマンスがHTTP/1より劣る状況があることが分かりました。 ネットワーク上にパケット損失がある場合、TCP層での輻輳制御によって、少数のTCPコネクションの中に多重化されているHTTP/2ストリームがスロットリングされます。さらに、TCPリトライのロジックにより、リトライが行われている間、1つのTCPコネクションに影響しているパケット損失が、いくつかのHTTP/2ストリームに同時に強い影響を与えます。言い換えれば、ヘッドオブラインブロッキングが事実上、ネットワーク階層の レイヤ7 から レイヤ4 へ移動したということです。 背景とサー

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

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

64ビットモードへの移行 Kernel booting process もパート4になりました。4回目の今回は、 プロテクトモード での最初の一歩についてご紹介します。CPUがサポートする ロングモード 、 SSE（ストリーミングSIMD拡張命令） 、 ページング方式 、そしてページテーブルの初期化やロングモードへの移行のお話しです。 注：このパートでは、アセンブリ言語のソースコードが頻出しますので、知識がない方は、事前に参考書を読むなどして理解を深めておいてください。 前回の パート では、 arch/x86/boot/pmjump.S 内にある32ビットのエントリーポイントにジャンプするところで終了しました。

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

Goスケジューラの仕事は、1つまたは複数のプロセッサ上で実行する複数のワーカOSスレッドに、実行可能なGoルーチンを配分することです。マルチスレッドのコンピュータ処理では、スケジューリングに2つの考え方が登場してきています。 * ワークシェアリング： あるプロセッサが新しいスレッドを生成したとき、idle状態か十分に活用されていないプロセッサが利用してくれることに期待して、生成したスレッドのいくつかを他のプロセッサに移行させます。 * ワークスティーリング： 十分に活用されていないプロセッサが他のプロセッサのスレッドを積極的に探し、そのいくつかを「スティール」ます。 スレッド移行の発生頻度は、ワークスティーリングではワークシェアリングよりも少なくなります。実行すべきワークがどのプロセッサにもあるときは、移行されるスレッドはありません。そして、あるプロセッサがidle状態になれば、直ちに移行

こんにちは。私はSergey Kamardin（セルゲイ・カマルディン）です。Mail.Ru（ロシアの電子メールサービス会社）で開発者をしています。 この記事では、どのように私がGoを使って高負荷対応のWebSocketサーバを開発したかについて説明したいと思っています。 パフォーマンス最適化のアイデアやテクニックを通じて、WebSocketの知識はあるもののGoについてはほとんど知らないという方のお役に立てれば幸いです。 1. はじめに まずは開発に至った経緯について、どうして私たちがこのサーバを必要としたのかを説明しておきましょう。 Mail.Ruには多くのステートフルなシステムがあります。ユーザのeメール保存もその1つです。システム内、およびシステムイベントの状態変更を追跡する方法にはいくつかの種類がありますが、それらは主に状態変更に関するシステム通知、または周期的なシステムのポーリ