Bashアプリケーションをテストする | POSTD
以前、bashスクリプトをテストする仕事に取り組んだことがあります。最初、Pythonユニットテストを使うことにしましたが、プロジェクトに外部技術を持ち込むのは気が進みませんでした。そこで、仕方なく、悪名高い bash で書かれたテスト用フレームワークを使いました。 既存ソリューションの概要 手に入るソリューションを探してGoogle検索しましたが、選択肢はほんの少ししかありませんでした。そのうちいくつかについて、詳しく見ていきましょう。 重要になるのは、どんな基準でしょうか？ 依存関係： bass のテスト用フレームワークを選ぶときに、 python 、 lua などのシステムパッケージも一緒に引きずり込むのは嫌ですね。 インストールの難しさ：継続的な開発の実装とTravis CIでの継続的な統合も仕事の1つだったので、私にとってインストールにかかる時間と手間数が妥当だということは、重要
Go言語のリアルタイムGC 理論と実践 | POSTD
(編注：誤訳、意味の分かりづらい訳を修正しました。リクエストありがとうございました。) 毎日、Pusherは数十億のメッセージをリアルタイム、つまり送り元から宛先まで100ms未満で送信しています。どのようにしてそれを可能にしているのでしょうか。重要となる要因はGoの低レイテンシのガベージコレクタです。 ガベージコレクタはプログラムを一時停止させるものであり、リアルタイムシステムの悩みの種です。そのため、新しいメッセージバスを設計する際には慎重に言語を選びました。Goは 低レイテンシを強調している ものの、私たちは懐疑的でした。「本当にGoを使えば実現できるのか？ もしできるならどうやって？」 このブログ記事ではGoのガベージコレクタを、どのように機能し（トリコロールアルゴリズム）、なぜ機能し（こんなに短いGCによる一時停止時間の実現）、そして何よりも、それが機能するのかどうか（GCによる
#/usr/binとその同種の周辺を探る | POSTD
(注：2017/04/10、いただいたフィードバックを元に翻訳を修正いたしました。) はじめに 私はLinuxが大好きです。コンピュータとのやりとりが楽しくなるし学ぶことも多くなります。OSとハードウェアの基盤となる基本原則を学びたい人にとって、Linuxはとてもいい出発点と言えるでしょう。 ご存じのとおりLinuxとは大抵の場合プログラム（コマンド）を通してやりとりします。Linuxと他のUNIX系システムが持っている特徴は、コマンドラインと、パイプのコンセプトです。プログラムの提供する入力と出力を統合すれば、データを操作するのに非常にパワフルなプラットフォームになります。 Linuxのコマンド、プログラム、バイナリ（何と呼んでもいいのですが）の大部分は、/usr/bin、/usr/sbin/、/binそして/usr/local/binに存在しています。これらのディレクトリを見れば、プロ
C言語、知ってるつもり？ | POSTD
「Cならわかるよ」というプログラマーは大勢います。確かにCの文法はよく知られているし、44年の歴史を誇るわけだし、あいまいな機能に悩まされることもありません。簡単ですよね！ あ、「Cならわかるよ」と 言うだけなら 簡単ですよねっていう意味ですよ。学校で習った人もいるだろうしお仕事で使ったことがある人もいるでしょう。覚えることもそんなに多くないし、完璧だという人もいるかもしれません。いいでしょう。でも、Cって実は、そんなにシンプルではないのです。 嘘だと思うなら、今から挙げる問題を解いてみましょう。たった5問です。基本的にはどれも同じで「戻り値は何ですか？」という問題ばかりです。四択方式で、どの問題も正解はひとつだけです。さあどうぞ。 第1問
Blue. No! Yellow! : プログラミング言語の進歩史と生産性にまつわる問答 | POSTD
世界初のプログラム内蔵方式コンピュータに搭載された、最初のプログラムを書くのに使われた言語は何だったでしょうか？ もちろん、バイナリの機械語です。 なぜですか？ えー、当然ながら、シンボリックアセンブラがなかったからです。最初期のプログラムは、バイナリで書かなければなりませんでした。 バイナリの機械語と比較して、アセンブリ言語でプログラムを書くと、どのくらい簡単ですか？ ずっと 簡単です。 数字を言ってください。何倍ぐらい簡単ですか？ えー、まあ、アセンブラは、あなたの代わりに面倒な事務処理を全てしてくれますからね。つまり、全ての物理アドレスの計算です。全ての物理的な命令を構築するわけです。あなたが範囲外にアドレス指定するなど、物理的に不可能なことをしないよう確認します。そして、簡単にロードできるバイナリの出力を生成します。 それによって、軽減されたワークロードは、 膨大 です。 どのくら
Pythonのオブジェクトとクラスのビジュアルガイド – 全てがオブジェクトであるということ | POSTD
Python開発者が大好きな言葉があります。それは”全てはオブジェクトである”です。実際、私自身もPythonのクラスを教えているときに何度も口にしています。多くの人が何度も聞いた言葉かもしれないのですが、私が言う度に生徒は賛同の相槌をしてくれます。結局のところ、Javaにおいて全ては（対象がそうでない場合を除いて）オブジェクトであり、.NETにおいても全てはオブジェクトであると、よく言われています。 しかしPythonにおいて全てがオブジェクトであると言う時、（私の生徒は驚いていましたが）「 全て 」にはクラスも含まれているのです。これはとても筋が通っていて、オブジェクトシステム全体が理解しやすくなります。しかしそれでも、広い視野で物事を見ることは難しいのです。 今回のブログ記事では、Pythonのオブジェクト間のつながりをざっと見ていきたいと思います。そして”全てはオブジェクトである”
障害の事後分析を読んで得た教訓 ― 「何がシステムを停止させるのか？」 | POSTD
私はポストモーテム（事後分析）の記録を読むのが大好きです。ポストモーテムを読むと勉強になりますが、大抵の教材的資料とは違って、興味深いストーリーが含まれているのです。相当な時間をかけてGoogleとMicrosoftのポストモーテムを読みました。大きな障害を招く最大の原因について、私は（まだ）きちんと分析していませんが、何度も繰り返し目にするポストモーテムのパターンがいくつかあります。 エラーハンドリング 適切なエラーハンドリングのコードを書くのは難しいものです。エラーハンドリングのコードに含まれるバグは、 大きな 問題を引き起こす主な原因となっています。つまり、エラーによってバグのあるエラーハンドリングのコードが実行されるということは、単に個々のエラーが重なるだけという事態にはとどまらないのです。障害が重なって重大なシステム停止につながることはよくあります。それはある意味明らかなことで、
正規表現：悪い表現、いい表現、最良の表現 | POSTD
わずかな文字がいかにしてパフォーマンスに大きな違いを生めるかというお話 正規表現は、私たち開発者がことあるごとに駆使する呪文のようなものですが、私たちはそれをどんな時も巧みに使いこなしていると言えるでしょうか。正規表現は繊細で精密な言語です。入念な慎重さで記述してやれば、ボウリングで一瞬にして完璧なストライクを取るような強力なテキストとなり得ます。 しかし、正規表現が精密さに欠ける状態で投げ出されると、さながら酔っ払いがよろよろとつまずきながらテキストの上を歩くがごとく、そのボールはぎこちなくボウリングのレーンを転がり、ピンを1つか2つ倒すだけで終わってしまうのです。 これら2つの正規表現の違いは何なのか。何がいい表現と悪い表現を分けるのか。正規表現に素晴らしい力を与えるメカニズムを、この投稿で明かしてみようと思います。効果的な表現とそうでない表現との大きな違いをきっと分かってもらえるはず
Python 2.7.x と 3.x の決定的な違いを例とともに | POSTD
Pythonを始めたばかりのユーザーの多くが、どちらのバージョンを使えばいいのか迷っています。私の答えは、「気に入ったチュートリアルに書かれているバージョンにしましょう。そして、あとで違いを調べてください」という言葉につきます。 それでは、新しいプロジェクトを始めるときにはどちらを選べばいいのでしょうか？ 使おうとしているライブラリを全てサポートしているなら、2.7.x系と3.x系のどちらを使ってもよいでしょう。そうはいっても、この2つのメジャーバージョンについて大きな違いを見ておくのは良いでしょう。どちらかのみでコードを書いたり、プロジェクトに使おうとしている時によくある落とし穴を避けられるからです。 __future__ モジュール Python 3.x で導入されていて Python 2 で使えないキーワードについては、 __furute__ モジュールをインポートすることで Pyt
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
