前回の記事で Haskell で BDD する基本的な構成は出来たので,これから実際に簡単なチュートリアルを書いてみる.あと HPC を Cabal に設定させてビルドテストからテストカバレッジレポートも生成させる要領もわかったので,そっちの準備等も書く その前に 前回の記事の追記公開したら,まさに「もっとスマートな方法ありますよ」という反応が.インターネットってすばらしい GHC 7.0.2 以降,Cabal 10.2 だと Test-Suite 指定が出来る自分の環境が GHC7.0.2 なのに cabal-install が 0.8.2 というあべこべな状態だったので,前回のような方法でしかビルド構成できなかったのだけど,元々,GHC 7.0.x 同梱の cabal-install 0.10.x 以降は exitcode-stdio でちゃんとテスト構成を指定する事ができる,とのこと
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 ではこれはエラーにな
ひさしぶりの Haskell ネタ 2011/12/13 追記下の例で app.cabal の設定や Setup.hs の記述などの情報が古かったので,こちらも一読してください → BDD on Haskell チュートリアル その0 経緯Haskell でそれなりのプログラムを書いてみようとしたので,HUnit や QuickCheck を使って BDD でやろうとしたのだけど,How to write a Haskell program 以上の事を誰も書いてないし,HUnit や QuickCheck の実例を書いた日本語圏のブログ記事も,その単体モジュールのテストのみ書いていて,肝心の全体テストを通しで実行するなどのネタが書かれていない. じゃあ実際に公開してるリポジトリでも見てみるかと思い,patchtag を見ても今度は公開してる人の殆どがテスト書くとかしてなかった.Haskel
以前、タイトルに「(数字)の理由」とか入れるとブクマが伸びると教えられましたが嘘だと思っています、happy_ryoです。 このエントリはiOS Advent Calendar 2011の11日目です。 昨日は、@watermint さんのエントリでした。 appCodeはJetBrains社が開発した、XCodeの代替IDEです。 InterfaceBuilderに対応する機能は無いので、その部分はXCode4を利用する必要があります。(JetBrainsの製品では他にIntelliJ IDEAが有名ですね。) それでは、末広がりという事で8つの理由、はじめます。 コード補完が強力 XCodeのコード補完を「残念だ」と思ったことはありませんか? プロパティとメソッドの順番はバラバラ…。自分が定義したプロパティ/メソッドなのか、親クラスが元々持っていた物なのか…。appCodeを使えばそん
(この記事は Node.js アドベントカレンダー不参加記事です) チャットサーバー的な使い方とか意外とみんな興味なくて、普通のウェブアプリケーションなどをかく、という用途にちょっと node.js がつかえたらいいのにな、とおもっている人がおおいようにかんじています。Node.js が人気なのは、v8 をうまくパッケージングしているのが node.js ぐらいで、そして v8 をうまくパッケージングするのが結構めんどくさいから、というところが大きいのです。ぶっちゃけ node.js が〜 とさわいでる人のうち8割は I/O multiplexing だからとかそういう理由で支持しているわけではなかったりするのです(偏見)。 さて、普通の web application のようなものを書こうとしたときに Node.js って基本シングルスレッドだし、なんかうっかり重い処理したときにどうした
実践的な DJango テクニック集として、凄くいい記事だったので、勝手に超訳してみました。 http://zeroandone.posterous.com/top-10-tips-to-a-new-django-developer 1. import にプロジェクト名を書かないこと 例えば "project3" というプロジェクトに "xyz" アプリケーションがある場合、次のようにはしないこと。 from project3.xyz.models import Author これではプロジェクトとアプリケーションの結びつきが強すぎて、以下の弊害がおこる。 アプリケーションの再利用がしづらい 将来プロジェクト名を変えたくなっても変更が難しい なので、このようにしよう。 from xyz.models import Author python パス上にある django プロジェクトならば、
全国のVimmerのみなさまこんばんは。Vim Advent Calendar 2011 : ATNDの10日目は私@choplinからお届けします。 Vimとキーボードの関係 Vimmerであれば当然常日頃からエディタとしてVimを使っていることと思います。中には単なるエディタであることに満足できずにシェルやファイラなどの環境、果ては家族としてVimと接している方もいるようです。 いずれにせよVimmerはコンピュータ側のインターフェースとしてまずVimを選択してるということです。では、物理世界はどうでしょうか?如何なるVimmerといえど物理世界のインターフェースを通さずにVimと接することはできないはずです。*1 コンピュータ型のインターフェースとしてのVimに拘りを持つ貴方は、ぜひ物理世界にインターフェースとしてのキーボードにも拘ってみてください。より貴方にマッチしたキーボードと共
**PLEASE DO NOT REPUBLISH THIS INFORMATION!** We’re planning to release the alpha preview tomorrow. Since there are a zillion things which can go wrong, I’m letting you be the first batch of testers before inviting the masses. You can download the preview here: <http://updates.textmate.org/Application/TextMate_r8926.tbz> We’re not asking for general feedback just “it didn’t launch at all” and stuf
人月計算は、悪だ。 という話はソフトウェア産業にいるエンジニアだったら、誰でも聞いたことがあるだろう。 よく言われる人月計算の悪とは、管理者の意識から個人個人の能力差などの情報が失われることが根本だと僕は考える。 悪影響の一例としてエンジニア単価に能力差が反映されないという点がある。 また別の例として「10人月の工数の作業も20人でやったら0.5ヶ月で終わるんじゃね?」 という単純計算による安易な管理が横行しデスマを生む原因となる。 「人月」の捉え方はともかくとして、すくなくとも良い評判を聞いたことがない。 しかし、僕は最近、人月計算とはとてつもない善ではないかという考え方になっている。 とくにエンジニアに対して「善」、というよりもエンジニアに対して優しさをもって考えられた仕組みだと感じて仕方ない。 人月の神話 作者: フレデリック・P・ブルックス Jr.,滝沢徹,牧野祐子,富澤昇出版社/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く