はてなブックマーク

Fitzpatrik と Collins-Sussman「Team Geek」を読んだ。体系化された方法論として書かれているわけではないので、内容をそのまま紹介することが難しい。この本で問題であると指摘されていることのうち、自分がやってきたこと、どう対処しようとしているかを書いておく。 ※ 誤字脱字、分かりにくい表現、スタイルをリライト。ロジックはそのまま。-- 2014/04/24 8時半ごろ で、でたーw 天才じゃないのがばれるのが嫌だから、途中の成果を隠奴〜w Most programmers are afraid to share work they've just started, because it means peers will see the mistakes and know the author of the code is not a genius. これは自分に

生まれてはじめて PyPI にコードを登録した。Python 2.7 と 3.3 で使えるようにするにあたり、ライブラリの実装とは直接関係ないところで、とまどった。現時点での手順を記録しておく。 以下を前提とする。 OS X 10.9.1 (Mavericks) homebrew でパッケージを管理 pyenv, pyenv-virtualenv で OS 上の Python 環境を管理 PyPI に登録するライブラリは Python 2.7 と 3.3 に対応 まず始める shimizukawa によるハンズオン資料と公式ドキュメントを併読しながら進める。基本的な作業はハンズオンでだいたい分かる。とはいえ、あなたが持っているライブラリは、必ずしもチュートリアルどおりではないだろうから、公式ドキュメントのガイドが必要になるだろう。 ところで、ナウなヤングは egg じゃなくて wheel

Go の型は First-class ではない、ということにゴールデンウィーク最終日に気づき、悶々としています。（何も Go が悪いわけではない） ことの発端は、以下の様な関数を定義したところから始まります。 func getName(x interface{}) string { return reflect.TypeOf(x).Elem().Name() } この関数に、任意の型のポインタをわたすと、型の名前を取得できます。けど、ポインタを渡さなければならないのですね。 var foo *Foo name := getName(foo) foo は使わないのに！ 使わないというのはウソですね。けど、ちょっと違うんですよ。まあこれは私がPython 脳だからであって、別にGoが悪いわけじゃない。 何をしたいかと言うとですね、Google App Engine datastore のクエリ

Web API をもつアプリケーションのテストを、Python と requests ライブラリを使って書いています。それはよいのですが、テストが通らなかったときですよ。酔ってますよ、もう、休日に仕事してぜんぜんはかどらなくて。それと、これとは別ですけど。 アプリケーションが Python で書かれていない場合、開発者が Python 環境を自由に使えない場合があります。テストのレポートを再現するためだけに、Python モジュールをインストールしてもらうのも気が引けます。 というわけで、requests を使ったアクセスを、 curl で再現するように hooks に追加することにしました。最初から curl 使えよとか、いろいろあると思いますが、すでにレイヤをまたいで requests 使ってたもので。 import curledrequests as requests request

git-flow/hg-flow を使ったブランチ方針に、不満というか不都合というか、気になることが出てきたのでメモしておきます。結論めいたものはありません。

なんの自慢にもならないどころか、完全に自戒エントリです。まず、そもそも受け入れテストを自動化する試みは有効だという仮説を持っています。 言葉の定義が曖昧で申し訳ないですが、V字モデルを考えた時に右上のほうにあるテストのことを想定しています。ですが、あまり厳密にシステムテストとの違いとか、パフォーマンスや負荷はとかを区別していません。「右上のほう」くらいを考えます。 要求分析 -------> 受け入れテスト 基本設計 -----> システムテスト 機能設計 ---> 結合テスト 詳細設計 -> 単体テスト コーディング 反復的に、スパイラルになど、とにかく少しずつソフトウェアを開発していくのが、バグ発生のリスクが少ない印象があります。仕様変更にも耐えやすい。そうすると、受け入れテストが自動化されていると、容易にテストでき、要求とことなる状態になったことがすぐわかります。あるいは、要求との差

ソースコード管理でのブランチの切り方を模索してきました。いったん落ち着いたので書き残しておきます。 前提条件は以下のとおりです。 iPhone アプリがアクセスするウェブAPIを開発する。 サーバサイドの開発者はふたり。大阪と東京。 他の案件とかけもち。 行き着いたところ Mercurial git-flow/git-daily に似たブランチ方針 機能追加、開発中機能のバグ修正: default ブランチから、XXX ブランチを切って機能追加/変更し、default へマージする。 リリース: default ブランチから、release/XXX ブランチを切って、ステージングでテスト/修正。終わったら、default と master へマージし、master の先頭を本番サーバにデプロイする。 リリース済不具合の修正: master ブランチから、hotfix/XXX ブランチを切っ

patch はコンテクストマネージャでもあるので、with を使った書き方ができます。with でつくられたブロックの中でだけ、モックが機能するようになります。 >>> from mock import patch >>> with patch('random.random') as m: ... import random ... random.random() # もうモックになっている。戻り値は Mock オブジェクト ... m.return_value = 0.5 ... random.random() # 戻り値は 0.5 ... <mock.Mock object at 0x423ed0> 0.5 >>> random.random() # モノホンの random 関数 0.84432022018162511 with ブロックの中に入った時点で、random.random

mock を使ったニットテストの、シンプルなシーンをまとめました。例として「Twitter アカウントのスクリーンネームを指定し、そのアカウントの最新のツイートの内容を取得する」という機能を実装する場合を考えます。 まず、簡単にユニットテストを書けるような場合から考えます。create_user_timeline_url() 関数を定義し、Twitter アカウントの screen_name を渡すと、そのアカウントのつぶやきを取得するために URL が返される、としましょう。たとえば Twitter アカウントのスクリーンネーム wozozo を渡すと、 http://twitter.com/statuses/user_timeline/wozozo.json が返ってくることを確認します。 実装とテストは以下のようになります。URL のテンプレートを定数にしたほうがいいとかありますが、

大規模ウェブサービスのプラクティスを紹介している、High Scalability の記事「15 Ways To Make Your Application Feel More Responsive Under Google App Engine」を訳しました。 記事は Java 前提で、私は Python で Google App Engine を使っているのですが、それでも面白いなと思ったので、有効な方法は使っていこうとしています。ついでなので翻訳したものを残しておくことにしました。 軽量な査定用フィードバックサービスを提供している Small Improvements が、Performance issues on GAE, and how we resolved them という素晴らしい記事を書いている。どのようにして、ほとんどのリクエストを 300ms から 800ms でさば

2011 Python アドベントカレンダー のエントリです。Python 2 と Python 3 の差異を吸収するラッパ集として six というライブラリを触ってみました。 Python 3 に同梱されている 2to3 というツールは、ひとつの Python 2 のソースから、 Python 3 用のソースを自動生成します。したがって、もとの Python 2 用コードと Python 3 用コードのふたつのバージョンを持つことになります。 一方、six がやろうとしているのは、ひとつのソースコードを Python 2 と Python 3 からも呼び出せるようにすることです。提供されるのは、基本的な定数や、ラッパ関数です。 文字列リテラルのフェイク Python 3 と言えば文字列です。 # coding: utf-8 print(u'うほ') Python 3 ではこれはエラーにな

初めて参加した Python 温泉で、 @voluntas と @aohta に開発プロセスの教えを乞いました。いろいろ教えてもらった中で、実際に手を動かし始めたことを書きます。@voluntas のブログ記事をベースに書いていますが、ふたりに教えてもらったことを混ぜています。

単体テストというのは、本来、あるコンポーネントの依存先に影響されないように、対象をテストします。が、これまでは比較的てきとーで、依存先のテストが通っていれば、依存先を完全に分離せずにやってきました。 これには2つ問題があって、(1) そもそもそれは単体テストではない、(2) 依存先が外部だったらどうするんだ、と。例えば、Twitter からタイムラインをとってくる、とかですね。 def get_user_timeline(user) """タイムラインをとってきて、辞書で返す""" twitter = Twitter() response = twitter.get_timeline(user.id, user.access_token) timeline = [{'text': tweet.text} for tweet in response['tweets']] return tim

LabVIEW で、複数の並行処理を開始/停止させるアプリケーションを開発する機会があったので、メモ。 このアプリケーションは、画面を操作するとデータの集録を開始したり終了したりする。あるいは、データ集録開始後、一定時間が経過すると、自動的に集録を終了する。こういうのは、Producer/Consumer パターンで実装するのが、LabVIEW では定石みたいになっていると思う。 ところがサンプリングレートやタイミングが異なるような、複数のデバイスからデータを集録するようなときは、ちょっとだるい。 たとえば アナログ電圧のデバイスから、サンプリングレート 10k/s で 0.1秒ごとのかたまりで取得 シリアルポートに繋がった電流計から、0.7秒ごとに電圧を取得 CAN ポートにメッセージが到達するごとに集録（いつ届くかは分からない。届かないこともある） デジタル信号のデバイスから（以下略）