Linuxシステムコール徹底ガイド | POSTD
要約 この記事では、LinuxカーネルにてLinuxプログラムがどのように関数を呼び出すのかについて紹介していきます。 システムコールを行う様々な方法、システムコールを行うための独自のアセンブリの作成方法（例あり）、システムコールへのカーネルエントリポイント、システムコールからのカーネルイグジットポイント、glibcのラッパ関数、バグなど多くの点について説明します。 要約 システムコールとは？ 必要条件に関する情報 ハードウェアとソフトウェア ユーザプログラム、カーネル、CPUの特権レベル 割り込み モデル固有レジスタ（MSR） アセンブリコードでシステムコールを呼び出すことの問題点 レガシーシステムコール 独自のアセンブリを用いたレガシーシステムコールの使用 カーネル側での int $0x80 エントリポイント iret を使用したレガシーシステムコールからの復帰 高速システムコール 3
色：ヘキサコードから眼球まで – Part 1. | POSTD
注釈： 波長（um） 網膜錐体の励起 私たちの目が、 background-color: #9B51E0 を、この紫色だと知覚するのはなぜでしょうか。 長い間、私はその答えを知っていると思っていましたが、よく考え直してみると、かなり大きな思い違いをしていることに気付きました。 そこで、この思い違いを、電磁放射、光生物学、測色学、表示用ハードウェアについて探求しながら解消していこうと思います。本文の構成は次のようになっています。飛ばし読みしたい方は好きな章から読んでください。 電磁放射 可視光線 人間が知覚する輝度 色の定量化 視覚の生物学的メカニズム 色空間 ライトとギルドの等色実験 色空間と色度の可視化 色域とスペクトル軌跡 CIE XYZ色空間 画面のサブピクセル sRGB sRGBヘキサコード ガンマ補正 ヘキサコードから眼球まで 輝度設定について 書き切れなかったこと 参考文献 で
障害の事後分析を読んで得た教訓 ― 「何がシステムを停止させるのか？」 | POSTD
私はポストモーテム（事後分析）の記録を読むのが大好きです。ポストモーテムを読むと勉強になりますが、大抵の教材的資料とは違って、興味深いストーリーが含まれているのです。相当な時間をかけてGoogleとMicrosoftのポストモーテムを読みました。大きな障害を招く最大の原因について、私は（まだ）きちんと分析していませんが、何度も繰り返し目にするポストモーテムのパターンがいくつかあります。 エラーハンドリング 適切なエラーハンドリングのコードを書くのは難しいものです。エラーハンドリングのコードに含まれるバグは、 大きな 問題を引き起こす主な原因となっています。つまり、エラーによってバグのあるエラーハンドリングのコードが実行されるということは、単に個々のエラーが重なるだけという事態にはとどまらないのです。障害が重なって重大なシステム停止につながることはよくあります。それはある意味明らかなことで、
–cap-dropオプションを使ったDockerコンテナの安全性を高める工夫 | POSTD
DockerにはLinuxのケーパビリティを削除するためのオプションがあるのをご存じでしたか？ docker run --cap-drop オプションを使うと、コンテナのルートを隔離することができ、コンテナ内でのアクセス権を制限することができます。悲しいことに、ほとんどの人はコンテナやそれ以外の場所でも、セキュリティを強化していません。 翌日では手遅れ ITの世界ではセキュリティへの配慮が遅すぎるという残念な傾向があります。 セキュリティが破られた翌日に初めて、セキュリティ対策システムが購入されているのです 。 ケーパビリティを落とすことで、コンテナのセキュリティを大変手っ取り早く改善することができます。 Linuxのケーパビリティとは? ケーパビリティのmanページ によると、 capabilities とは、個別に有効無効を設定することができる特権の集まりのことです。 私流に説明すると
Dockerコンテナ内でsshdを実行してはいけない理由 | POSTD
Dockerを使い始めた人がよくする質問といえば、「どうすればコンテナに入れますか？」です。その質問に対して、「コンテナ内でSSHサーバを起動すればいいよ」と答える人たちがいますが、これは非常にマズいやり方です。なぜその方法が間違いなのか、そして代わりにどうすればよいのかをこれから紹介します。 注：本記事へのコメントやシェアは、 Dockerブログ にアップされた標準版から行ってください。よろしくお願いします。 コンテナでSSHサーバを起動すべきではない …もちろん、コンテナ自体がSSHサーバである場合は除きます。 SSHサーバを起動したくなる気持ちは分かります。それはコンテナの”中に入る”簡単な方法だからです。この業界の人ならほぼ全員がSSHを一度は使ったことがあります。多くの人がSSHを日常的に使用し、公開鍵や秘密鍵、パスワード入力の省略、認証エージェント、そして時にはポート転送やその
2017年JavaScriptのテスト概論 | POSTD
本稿は、JavaScriptのテストについて最も重要な根拠、用語、ツール、アプローチなどの知識を身に着けることを目的とした簡略版ガイドブックです。本稿で検討する数々の側面に関する最新の秀逸な記事も紹介しつつ、私たちが経験的に得たことも多少付け加えたいと思います。 Facebookによるテスト用フレームワークであるJestのロゴをご覧ください。 見てお分かりのように、このフレームワークは「苦痛のない」JavaScriptのテストをスローガンに掲げています。しかし、 “次のように言う人” もいます。 苦痛のないテストなんてあり得ない。 実際、Facebookはこのスローガンを掲げるだけの素晴らしい理由があります。一般的にJSのデベロッパは Webサイトのテストにあまり満足していません 。JSのテストには制限があり、実装が難しく、低速である傾向があります。 一方、正しい戦略を立てて適切にツールを
マイクロサービスはもう十分 | プロダクト・サービス | POSTD
モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。要旨 モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。 – Martin Fowler 明確に構造化されたモノリスを構築できない時、なぜマイクロサービスがその答えだと思うのか。 Simon Brown 始めに マイクロサービスの利点と欠
Dockerの本番運用 | POSTD
以前に私が書いた「 Dockerの本番運用：失敗の歴史) 」という記事は、非常に多くの反響を呼びました。 その後、長い議論を交わして、何百件ものフィードバックや何千件ものコメントを読み、さまざまな人々や主要事業者とも顔を合わせました。Dockerでの試みが増えるほど、その失敗談は増えていきます。そうした現状を、今回アップデートしておきたいと思います。 この記事では、最近の交流や記事から得た教訓を紹介しますが、その前に簡単におさらいをして軽く背景を説明しましょう。 免責事項：対象読者 たくさんのコメントから、世の中には10種類の人々が存在するということが明らかになりました。 1) アマチュア 実際のユーザがいない試用版のプロジェクトやサイドプロジェクトを実行している人々です。Ubuntuのベータ版を使用するのが当然だと考えており、「安定したもの」は古いものと見なすようなタイプです。 注釈：書
私たちが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も備えていま
ジョエル･テストは（もはや若干）時代遅れ―今ならこう質問しよう | POSTD
ジョエル･テストとは、面接時に求人応募者が面接官に聞くものとして広く受け入れられている「12個の役立つ質問」のことです。このテストはJoel Spolsky氏が考案しました。彼のブログは開発者の間では有名で、この12の質問も広く知られていました。そして、スタック･オーバーフロー（創設者の1人がJoel Spolsky氏）によって、さらに普及することになります。スタック･オーバーフローの求人ページでは、求人を出す側の企業向けにこの質問を使ったチェックリストが用意されています。以下がそのジョエル･テストです。 ソース管理の仕組みを導入していますか？ １ステップでビルドを行えますか？ ビルドは毎日実行していますか？ バグデータベースを持っていますか？ 新しいコードを書くまえにバグを修正していますか？ 最新スケジュールを常に社内で共有していますか？ 仕様書を持っていますか？ プログラマは静かな作業
私がどのようにしてAtomの奇妙なバグを修正したか : 正規表現が暴走を起こすとき | POSTD
Atom は、今注目の最新テキストエディタです。私は、このエディタをソフトウェア開発に使用しているのですが、オープンソースになっているので、少しでも貢献できればとAtomが抱えるIssuesについて検証してみることにしました。私は、 ある奇妙なバグ を見つけました。それは、Atomのユーザ speter がテキストを1行書き、行末で Enter を押した時に起こりました。新たな行が書けるようになるまで、Atomは30分も計算していたのです。私は、そんな単純かつよくあるオペレーションもろくにできないことに大きな衝撃を受け、早速その原因を探ることにしました。 検索 これが、問題のテキストです。 vVar.Type().Name() == "" && vVar.Kind() == reflect.Ptr && vVar.Type().Elem().Name() == "" && vVar.Typ
ジェダイ流・Pythonの内包表記 | POSTD
醜いより美しい方がいい。暗示するより明示する方がいい。 Pythonの禅 より 私はよく、ドロイドやジェダイ、惑星、ライトセーバー、スターファイターなどのコレクショングッズを題材にしてプログラムを書きます。Pythonでプログラミングをする際は大抵、これらをリストやセット、辞書として表現するわけです。私は日頃からコレクショングッズをさまざまな形に変身させたいと思っています。そして、その願望を叶えてくれるのが、内包表記という強力な記法です。内包表記は私がさまざまな場面で使っている手法であり、Pythonを使い続けている理由の1つでもあります。では、いくつか例と共に、内包表記がいかに便利かを説明していきましょう。 以下の例に出てくる処理はどれも、種類豊富なPythonの標準ライブラリがあれば実装できます。その中には、より簡潔で効率の良い処理に改善できるものもあるでしょう。とはいえ、私は標準ライ
Go言語の並行性を映像化する | POSTD
Goというプログラミング言語の強みの１つは、 Tony Hoare考案のCSP に基づくビルトインの並行性(Concurrency)です。Goは並行性を念頭にデザインされているため、複雑に並行したパイプラインの構築を可能にしています。でも、それぞれの並行性パターンがどのように見えるものなのか気になったことはありませんか。 もちろん、気になったことはあると思います。恐らくそれぞれ形は違っても、誰もが頭に描いているのではないでしょうか。もし、「1から100までの数字」について聞かれたら、無意識に頭の中で数字のイメージを思い浮かべると思います。例えば、私の場合、自分の前から1から20までがまっすぐに並び、21以降は90度右に曲がり1000以降まで続くイメージが浮かびます。これは多分私が幼稚園の時に教室の壁に沿って数字が貼られていて、ちょうど角に数字の20があったからなのだと思います。別の例えをす
クレジットカードフォームの解剖学 | POSTD
オンラインでクレジットカードを使って支払うことは簡単ですよね？この答えはYesでもNoでもあります。Yesの理由は、インターネットが普及された初期からずっとそうしていたから（例：Amazon）。Noの理由は、まったく同じクレジットカードフォームは2つとないからです。 過去20年以上で、私たちはオンライン支払のメンタルモデルを作り上げてきました。「財布からクレジットカードを取り出して、ウェブのフォームに必要なカード情報を入力、そして申込みボタンを押す」というものです。しかし、ユーザーが答えないといけない質問でいっぱいなので、全てを入力するのはとてもややこしい行為になってしまいます。そして言うまでもなく、誰も取扱い説明書なんて読みたくありません。 さまざまな有名ウェブサイト・アプリのクレジットカードフォーム 何かの代金をオンラインで支払う時は、人へ支払う時より2,3倍遅れをとります。端末のボタ
GitHubでの”Merge pull request”の弊害 | POSTD
私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション （寄与貢献）を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
