CDNは5時間で開発できる | POSTD
「CDN」（content delivery network）という言葉からは、Googleのような大企業がいくつもの巨大なハードウェアを管理し、1秒当たり何百ギガビットものデータを処理する様子が想像されます。しかし、CDNは単なるWebアプリケーションです。私たちのイメージとは違いますが、それが事実です。8年前に買ったノートパソコンを使って、コーヒーショップの席に座りながらでも、きちんと機能するCDNを構築できます。この記事では、これから5時間でCDNを開発しようとするときに、直面するかもしれないことを紹介します。 まずはCDNの機能を明らかにしておきましょう。CDNはセントラルリポジトリ（通称：オリジン）からファイルを吸い上げ、ユーザーに近い場所でコピーを保存します。初期のオリジンはCDNのFTPサーバーでした。現在、オリジンは単なるWebアプリとなり、CDNはプロキシサーバーとして機
プログラマの採用面接で聞かれる、データ構造とアルゴリズムに関する50以上の質問 | POSTD
情報科学科の卒業生やプログラマの中には、UberやNetflixのような新興企業や、 Amazon 、 Microsoft 、 Google のような大企業や、InfosysやLuxsoftのようなサービスを基本とする企業で、プログラミング、コーディング、ソフトウェア開発の仕事に就きたいと考える人が大勢います。しかし、実際にそういった企業で面接を受ける場合、大半の人が プログラミングに関してどのような質問をされるか 見当もつきません。 この記事では、 新卒生からプログラマになって1〜2年までの 経験値が異なる人たち向けに、それぞれの プログラミングの面接でよく聞かれる質問 をいくつか紹介していきます。 コーディングの面接では、主に データ構造とアルゴリズムに基づいた質問 がされますが、 一時変数を使わずにどのように2つの整数をスワップするのか 、というような論理的な質問もされるでしょう。
私の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”を許容するとうたっていますが、それは厳密には正しくありません。その理由
リモートワークのストレス | POSTD
リモートワークのストレス ソフトウェアエンジニアリング業界では、リモートワークは大いに理にかなった働き方です。大抵はPCとインターネット接続さえあれば仕事ができるからです。よって、決まったオフィスに毎日通って働く理由は比較的少ないため、リモートワークはIT職の重要な要素になっています。最も先見的な求人市場とは決して言えないベルギーにおいてさえもです。とはいっても多くの場合、リモートワークが認められるのは週の一部のみ（おそらく週に1日か2日ぐらいが一般的）にすぎません。それにもかかわらず、リモートワークは大部分の企業で導入されるようになってきたのです。 リモートワークには多くの利点があると言われており、この働き方を過激なまでに擁護する声もよく耳にします。その多くには同意するものの、リモートワークを5年以上してきた経験から言えるのは、リモートワークにはストレスが付き物だということです。そう聞く
Unixコマンド”yes”についてのちょっとした話 | POSTD
知っているUnixのコマンドで一番シンプルなものは何ですか？ 例えば echo という、stdoutに文字列を出力し true を返す – すなわち常に0の終了コードで終了するシンプルなコマンドがあります。 シンプルな、と言えば yes もそうでしょう。引数なしで実行すると、改行されたyが無限に出力され続けます。
Dockerの本番運用 | POSTD
以前に私が書いた「 Dockerの本番運用：失敗の歴史) 」という記事は、非常に多くの反響を呼びました。 その後、長い議論を交わして、何百件ものフィードバックや何千件ものコメントを読み、さまざまな人々や主要事業者とも顔を合わせました。Dockerでの試みが増えるほど、その失敗談は増えていきます。そうした現状を、今回アップデートしておきたいと思います。 この記事では、最近の交流や記事から得た教訓を紹介しますが、その前に簡単におさらいをして軽く背景を説明しましょう。 免責事項：対象読者 たくさんのコメントから、世の中には10種類の人々が存在するということが明らかになりました。 1) アマチュア 実際のユーザがいない試用版のプロジェクトやサイドプロジェクトを実行している人々です。Ubuntuのベータ版を使用するのが当然だと考えており、「安定したもの」は古いものと見なすようなタイプです。 注釈：書
#/usr/binとその同種の周辺を探る | POSTD
(注：2017/04/10、いただいたフィードバックを元に翻訳を修正いたしました。) はじめに 私はLinuxが大好きです。コンピュータとのやりとりが楽しくなるし学ぶことも多くなります。OSとハードウェアの基盤となる基本原則を学びたい人にとって、Linuxはとてもいい出発点と言えるでしょう。 ご存じのとおりLinuxとは大抵の場合プログラム（コマンド）を通してやりとりします。Linuxと他のUNIX系システムが持っている特徴は、コマンドラインと、パイプのコンセプトです。プログラムの提供する入力と出力を統合すれば、データを操作するのに非常にパワフルなプラットフォームになります。 Linuxのコマンド、プログラム、バイナリ（何と呼んでもいいのですが）の大部分は、/usr/bin、/usr/sbin/、/binそして/usr/local/binに存在しています。これらのディレクトリを見れば、プロ
H.264の秘密 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) (2016/12/11、いただきましたフィードバックをもとに翻訳を修正いたしました。) H.264は、動画圧縮コーデックの標準規格です。ネット上の動画、Blu-ray、スマホ、セキュリティカメラ、ドローンなどなど、今やあらゆるところでH.264が使われています。 H.264は注目すべき技術のひとつです。たったひとつの目標、つまりフルモーションビデオの送信に要するネットワーク帯域を削減することを目指した30年以上の努力の結晶なのです。 技術的な面でも、H.264はとても興味深い規格です。この記事では、その一部について概要レベルでの知識を得られることでしょう。あまり複雑だと感じさせないようにするつもりです。今回おはなしする概念の多くは動画圧縮全般にあてはまるものであり、H.264に限ったものではありません
何でもSSHでやってしまいませんか？ | POSTD
私はかつて、 ssh-chat というプログラムを書きました。 ssh http://t.co/E7Ilc0B0BC pic.twitter.com/CqYBR1WYO4 — Andrey ???? Petrov (@shazow) December 13, 2014 アイデアは単純なもので、ターミナルを開いてこのようにタイプするだけのことです。 $ ssh chat.shazow.net たいていの人はこの後に続けてlsコマンドをタイプするのでしょうが、ちょっと待って。よく見てください。そこにあるのはシェルではなく、なんとチャットルームですよ！ 詳しいことはわからないけど、何かすごいことが起こっているようですね。 SSHはユーザー名を認識する sshでサーバーに接続するときに、sshクライアントはいくつかの環境変数をサーバーへの入力として渡します。その中のひとつが環境変数$USERです。
C/C++中規模プロジェクトのための超シンプルなMakefile | POSTD
私は多くの小規模プロジェクトで Make を使ってきましたが、より大きな規模のプロジェクトになると、それは非常にうんざりするようなものでした。最近までは、自分のビルドシステムに行いたいことが4つあったのですが、Makeでの方法が分かりませんでした。 out-of-sourceビルド（オブジェクトファイルが、ソースとは分離されたディレクトリにダンプ出力されます） 自動生成される（かつ正確！）ヘッダの依存関係 オブジェクト／ソースファイルのリストの自動的な決定 インクルードディレクトリのフラグの自動生成 以下にこれらの全てを行える、C、C++、およびアセンブリで動作するシンプルなMakefileを紹介します。 MAKEFILE TARGET_EXEC ?= a.out BUILD_DIR ?= ./build SRC_DIRS ?= ./src SRCS := $(shell find $(S
RustとDNSの1年 | POSTD
(注：2016/09/28、いただいたフィードバックを元に翻訳を修正いたしました。) この記事は、RustやDNSの使い方を皆さんにお教えするためのものではありません。むしろ、私がDNSクライアント/サーバをRustで開発した時に面白いなと思った点について書く日記のようなものです。 約１年半前のことですが、私は史上最高とも言えるプログラミング言語と出会いました。それは私がGo言語を学んでいる最中のことでした。Goは学習していて楽しい言語で、Java出身の私は特にひとつの点を素晴らしいと評価しました。それは、シングルバイナリをコンパイルできるし、それをデプロイしたり実行するのも早くて簡単だという点です。正直言って、Goでプログラムを書いて初めて、C言語のスタティックバイナリをどれほど気に入っていたか気付いたのです。クラスパスはないし、デフォルトのメモリ設定をいじることもなく、デフォルトのガベ
AWSで避けるべき5つの間違い | POSTD
今年からAWS（Amazon Web Services）クラウドコンサルタントとして、中小規模のAWSデプロイの相談を受けています。その多くは典型的なWebアプリケーションです。ここで、ぜひ避けたい5つのよくある間違いを紹介します。 インフラストラクチャを手動で管理する。 Auto Scaling グループを使わない。 CloudWatchのメトリクスを分析しない。 Trusted Advisorを無視する。 仮想マシンを活用しない。 典型的なWebアプリケーションにおける間違いを防ぎたい人は、次に進んでください。 典型的なWebアプリケーション 典型的なWebアプリケーションは最低限次の要素で構成されているものを指します。 ロードバランサ スケーラブルなWebバックエンド データベース そしてこのアプリケーションは、次の図のような仕組みを持っています。 注釈：（左から）DNS、CDN、静
私たちがAmazon Web ServicesからGoogle Cloud Platformに乗り換えた理由 | POSTD
https://flic.kr/p/os8Taq 要約：AWSは素晴らしいが、Googleはその グーゴル 倍素晴らしい。 AWS re:Invent （参加料は1,600ドル）に参加したり、チーフ･エバンジェリストの Jeff Barr をフォローしたりすれば、あなたはたちまち、Amazon Web Servicesのとりこになるでしょう。 毎年何百もの新機能が登場しており、食べ放題・融通が利く・運用担当者不要の、オンデマンドサービスのビュッフェのようです。まあ、実際に食べてみるまでは、の話ですが…。 Amazonは素晴らしいです。しかし、Google Cloudは「開発者によって、開発者のために構築された」ものであり、それが一目で分かるのです。 移行した理由 App Engine GAE はきちんと機能し、オートスケーリング機能も持ち、ロードバランサや無料のmemcacheも備えていま
GoogleのQUICプロトコル：TCPからUDPへWebを移行する | POSTD
QUIC（Quick UDP Internet Connections）プロトコルは、TCPではなくUDPをベースとして開発された、全く新しいWeb向けのプロトコルです。 （冗談で） TCP/2 と呼ぶ人までいます。 私がQUICについて知ったのは数週間前のことです。 SysCast Podcastのcurlとlibcurlについてのエピソード を聞いていた時でした。 QUICプロトコルの本当に面白い点は、UDPへの移行というところだと思います。 現在、Webの伝送プロトコルは、信頼性を確保するため、TCP上に構築されています。このTCP接続を開始するためには、 3wayハンドシェイク が行われています。つまりこれは、接続を開始するたびにラウンドトリップ （ネットワークパケットの往復） が追加されるということであり、新たな接続先に対し大幅な遅延を生じさせているのです。 （出典： UDPを介
Amazonのソフトウェアエンジニア面接 | POSTD
最近、Amazonのエンジニア採用担当者から連絡を受けました。Amazonは、ベルリンオフィスのチームのソフトウェアエンジニアの採用面接をしていたのです。 連絡を受けてから契約書にサインするまでのプロセス全体は、2カ月でした。採用プロセスで経験したことと、私が合格できた理由として思い当たることをお知らせしたいと思います。 この記事で、もし私が何か重要なことに触れ忘れていたら、ぜひコメント欄に書いてください。出来る限りの詳細を回答に書きます。 4月27日：最初の連絡 採用担当者からの連絡は、 LinkedIn 経由でした。ベルリンオフィスのチームのソフトウェアエンジニアを募集しているので、もし興味があれば、最新のレジュメを送って欲しいとのことでした。私は、常にレジュメを最新にしていたので、翌日、Eメールに添付して送りました。 彼女からの返信には、募集しているソフトウェアエンジニアの役割と面接
初心者のためのSQLガイド???? : SQLを直感的に理解しよう | POSTD
SELECT * WHERE a=b FROM c ？ それとも SELECT WHERE a=b FROM c ON * ？ もしあなたが私のようなプログラマだったら、SQLは、初めは優しく見える言語の1 つかもしれません（ただ単に普通の英語通り読めばいいですから）。ですが、何かしらの理由で、なんてことのないクエリにもいちいち正しいシンタックスをググらなければいけないでしょう。 いずれJOINにAGGREGTATION、サブクエリにたどり着くでしょうが、読んだとしてもさっぱりでしょう。例えば次のような感じです。 SELECT members.firstname || ' ' || members.lastname AS "Full Name" FROM borrowings JOIN members ON members.memberid=borrowings.memberid JOIN
私がどのようにしてキーロガーをクラックし、最終的に第三者の受信トレイに行きついたか | POSTD
(訳注：2016/9/28、頂きましたフィードバックを元に記事を修正いたしました。) ことの始まりは、あるスパムキャンペーンでした。画像1は、スパム向けに仕掛けた罠に最近引っかかった、疑わしいドキュメントファイルが添付されたメールです。文面の英語がとても稚拙なことに気付くかと思いますが、この稚拙さがメール受信者への警告サインとなります。 画像1：スパムサンプル 添付のファイルは、”.doc”のファイル拡張子を使っていますが、実際はRTF（リッチテキストファイル）ファイル形式で、特別に細工されたRTFファイルによるスタックオーバーフローの脆弱性が含まれています。この脆弱性は、CVE-2010-3333で文書化されており、”pFragments”の形をしたプロパティを扱う際にMicrosoft Word RFTパーサを攻撃するものです。これに対する修正モジュールは5年以上前にパッチされています
リレーショナルデータベースの仕組み (1/3) | POSTD
リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術（ビッグデータ、NoSQL、JavaScriptなど）を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか？ 私は開発者として、理解していないものを
私がsystemdを嫌う理由 | POSTD
(訳注：7/24、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注2：8/4、いただいた翻訳フィードバックを元に記事を再修正いたしました。) この2010年代にLinuxシステムの管理者をしていれば、systemdに関して何かしら思うところがあるでしょう。そして私は管理者たちの意見が両極端に分かれていることに驚きました。ほとんどの人（少なくとも意見を表明している人達）はsystemdが「大好き」か「大嫌い」かのどちらかのようです。私の場合、systemdをきっかけに昨年OpenBSDを使うことになったのですが、これを話したことで私がsystemdを「大嫌い」だと思われたようです。でも、それは違います。 本当は、systemd自体は私がOpenBSDに移った理由のほんの一部にすぎません。しかし、この経験によって2つの重要な点に気付きました。まず、最近のLinuxの設計の問
30日間で300回のプログラミング面接をしてわかったこと | POSTD
プログラマの採用方法を改善するため、1カ月程前にTriplebyteを立ち上げました。昔から変わらず、履歴書、コードをホワイトボードに書かせるプログラミングテスト、そして直感など、これらを判断基準に面接を行う企業が多すぎます。私たちは、より良い採用方法について最初に考えたアイディアを マニフェスト に記しました。それから1カ月と少しが経過し、この30日間で、300回の面接を行いました。私たちはアイディアを実行に移し、どの方法が有効で、どの方法が有効ではないかを確認し、そのプロセスを繰り返すということを始めたのです。この投稿には、300回の面接を通して私たちが学んだことを書いていこうと思います。 投稿では、細かい内容についての説明が多くなりますが、キーとなる発見は以下の通りです。 私たちが作ったオンラインのプログラミングクイズの結果を見れば、高い確率でプログラミング面接の結果を予測できる。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
