// ワークブックを作成
DataDynamics.SpreadBuilder.Workbook sb = new DataDynamics.SpreadBuilder.Workbook();
// シートの追加
sb.Sheets.AddNew();
// セルに書き込む
sb.Sheets[0].Cell(0,0).SetValue("セルA1にこれを出力");
// 保存
sb.save("C:\\example.xls");

詳しくはインストールフォルダのチュートリアルを見るといいかも
C:\Program Files\ActiveReportsNET3\Tutorials\VS2005\CS\SpreadBuilderの使用
（普通にインスコしたらこのフォルダだと思う）

Excelと比べてどうか？

単純にデータの出力はSpreadBuilderの方が鬼速いです。
A1-A10000セルへの文字の書き出しの実測が、SpreadBuilderでは10秒程度に対してExcelオブジェクトでは5分ぐらい掛かったような。後でもう一回測定してみる。

指定できる要素

DDSheet ddSheet = sb.Sheets[0];

ddSheet.Name = "シート名"; // シート名
ddSheet.Rows(iRow).Height = (short)sHoge; // 行の高さ
ddSheet.Columns(sCol).Width = (int)iHoge; // セルの幅
ddSheet.AddVerticalPageBreak(sRow, sColBegin, sColEnd); // 印刷時の改ページ
ddSheet.Cell(iRow, iCol).SetValue("セルの値"); // セルの値
ddSheet.Cell(iRow, iCol).FontName = "ＭＳ Ｐゴシック"; // フォント
ddSheet.Cell(iRow, iCol).FontSize = 10; // フォントサイズ
ddSheet.Cell(iRow, iCol).FontBold = true; // フォントをボールドにする
ddSheet.Cell(iRow, iCol).FontItalic = true; // フォントをイタリックにする
ddSheet.Cell(iRow, iCol).FillColor = System.Drawing.Color.FromArgb(255, 255, 255); // セルの背景色
ddSheet.Cell(iRow, iCol).Alignment = DataDynamics.SpreadBuilder.Style.HorzAlignments.Center; // 横配置
ddSheet.Cell(iRow, iCol).VertAlignment = DataDynamics.SpreadBuilder.Style.VertAlignments.Center; // 縦配置
ddSheet.Cell(iRow, iCol).WrapText = true; // 折り返して全体を表示する
ddSheet.Cell(iRow, iCol).Merge(2, 5); // セルの結合。iRowから縦に2行、横に5列をマージ（3x6の結合）
ddSheet.Cell(iRow, iCol).NumberFormat = "#,##0;[Red]-#,##0"; // セルの書式設定（SetValue()で数値を設定した場合のみ有効）

// セルの罫線
ddSheet.Cell(iRow, iCol).BorderTopStyle = BorderLineStyle.Hair; // セルの上部に点線を引く
ddSheet.Cell(iRow, iCol).BorderBottomStyle = BorderLineStyle.Thin; // セルの下部に通常線を引く
ddSheet.Cell(iRow, iCol).BorderLeftStyle = BorderLineStyle.Double; // セルの左側に二重線を引く
ddSheet.Cell(iRow, iCol).BorderRightStyle = BorderLineStyle.Hair; // セルの右側に（ｒｙ
ddSheet.Cell(iRow, iCol).BorderDiagonalEnum = BorderDiagonalStyles.Up; // セルの斜めに（ｒｙ
// 他の罫線書式
public enum BorderLineStyle { None = 0, Thin = 1, Medium = 2, Dashed = 3, Dotted = 4, Thick = 5, Double = 6, Hair = 7, MediumDashed = 8, DashDot = 9, MediumDashDot = 10, DashDotDot = 11, MediumDashDotDot = 12, SlantedDashDot = 13, }

// 画像の貼り付け
Image image = System.Drawing.Image.FromFile("C:\\example.png");
DataDynamics.SpreadBuilder.Imaging.ImageInfo ii = new DataDynamics.SpreadBuilder.Imaging.ImageInfo();
ddSheet.AddImage(image, ii, Color.Empty, Color.Empty, 1, 0, 0, 256, 5, 0, 4, 0, null);

// 余白
ddSheet.PageSetup.TopMargin = 2.5 * 72 / 2.54;
ddSheet.PageSetup.BottomMargin = 2.5 * 72 / 2.54;
ddSheet.PageSetup.LeftMargin = 2 * 72 / 2.54;
ddSheet.PageSetup.RightMargin = 2 * 72 / 2.54;
ddSheet.PageSetup.HeaderMargin = 1.3 * 72 / 2.54;
ddSheet.PageSetup.FooterMargin = 1.3 * 72 / 2.54;
// ページ設定
ddSheet.PageSetup.Orientation = DataDynamics.SpreadBuilder.Printing.PagePrintOrientation.Landscape; // 用紙向き
ddSheet.PageSetup.PaperSize = System.Drawing.Printing.PaperKind.A3; // 用紙設定
ddSheet.PageSetup.Zoom = 75; // 倍率

多分どうしようもないこと

既存のExcelファイルを読み込んで、そのファイルに追記すること。
http://www.datadynamics.com/forums/117128/ShowPost.aspx

BookのベースフォントがArialになっている。

Excelの行番号や列名を表示している部分が、普通にExcelアプリでファイルを作ったときに比べて小さい。

普通に作成したブックにサイズを合わせるために、行の高さ・セルの幅を数値（ポイント？）を調整すると見た目で合わない。ピクセルで合わせると見た目は合うが印刷プレビューで見ると小さく見える。

ページ設定＞シートの「印刷タイトル」にある「行のタイトル」「列のタイトル」の設定ができない

オートシェイプの貼り付けができない。

解決法があったら教えてください

使ってみた感想

やはり速いってのはいいですね。

ダメな点は、ファイルの読み込みができないこと。この為お客さん作成のExcelテンプレートを使うことができず、一からどの座標に何を出力するかを作る必要があります。んでベースフォントが違うせいなのか完璧なレイアウトのコピーを作るのはできなかった。多分Excelファイルっぽいものを作れるけど正式なExcelファイルじゃないのかも。Excelアプリで開いてすぐ保存すると若干ファイルサイズが増えたので。

余談ですけど、SpreadBuilderで出力したファイルもブックを開いたときに選択できる色のパレットが標準と変わってしまうのですが、これはアプリでExcelファイルを出力すると必ず変わってしまうんですかね？以前の案件でMicrosoft.Office.Interop.Excelを使ってExcelファイル出力したときもパレットが変わっていました。

2010-02-19

デブサミ2010行ってきました（二日目）

devsumi2010

今シーズンは二日とも行ってきました。

【19-C-2】本当に問題ないですか？〜大規模RIA案件50社をこなしてきたプロが語るエンタープライズにおけるCloud＆RIAアーキテクチャ

失敗事例を聞くことができたのが嬉しかったです。こういう情報こそ知りたかったですから。

データを物理的に何処で管理するかを求められる場合がある。
国内かもしくは何処で蓄積されるかの明示化。
ロサンゼルス市はGoogleの政府専用のクラウドを提供されているので問題ないが、日本国でクラウドを利用する場合はユーザのポリシーを確認すること。
パブリッククラウドはお安いが、プライベートだと高くつくので、安い見積もりを出した後プライベートに変えるのは受け入れられない。
データの特性によってパブリック・プライベートの併用も視野に入れると良い
パブリッククラウド上のデータセキュリティも日々進化しているの

アプリケーションの動きが遅いときがある
処理に問題がなくても、レイテンシが悪い場合がある。
サーバの処理が同じ処理でも時間が異なる。
通信はどうしようもないので、クライアントアプリ側の工夫がいる
変更のないデータは再取得しないなど、転送量が小さくなる工夫がいる
サーバのパフォーマンスが悪くても何とかなる設計がいる
既存システムのリプレース案件だと、今までやらなかった操作をやるようになり、当初想定のデータ転送より多くなる場合がある

まとめ

小さく始めたい、実験的なことをやりたいなら適していそう
大量データを扱うものは、レスポンス面で厳しいかも（たとえばどこかの会社の業務システム）
情報保護として、データが何処にあるかを明示するのも難しい（そのうち日本国にサーバを置くようになると思う）

【19-B-3】三周遅れのXP -僕とドワンゴのXP-

1週目はケントベック
2週目は@kakutaniさん
3週目が@yoshioriさん

4つの価値

コミュニケーション
シンプルさ
フィードバック
勇気

おやつ神社というブースを作ってそこを集まって気軽に話せる場所にしているらしい。タバコルーム以外でもこういう場を作れるのは良さそう。
テスト駆動は、品質管理やテストの話ではない。開発手法の話。
ペアプロの会があるらしい。今までやったことないのでちょっと体験してみたい。

TDDをやると

自分の解決すべき問題を明白に
すぐにテストを実行
開発するためのテストを書く
品質を担保するためのテストでない

　が、TDDという開発手法自体が品質アップにつながる

今日リリースの案件があっても、チームリーダーがイベントでスピーカーをやりにいくこともできる！

Q:UnitTestになってしまい、網羅的にテストを書いてしまう
A:不安をテストする

文化を根付かせるためには

社内でTDD写経会（Web+DB Press Vol.35を参考。1〜36の総集編CDに入っているのかな？）
ペアプロ（コードの共有をしていると認識しやすくなる？）
新人にブログを書かせ、返信もブログでする。コードを晒す事に慣れる

ちょっと疑問
僕が今まで関わってきた案件だと、自分で実装したところを自分で修正するという文化がある。これはほかの人が直してしまうと間違った本人が何処がおかしいかを認識しないからという事らしいのです。これにも一理あるなあと思うのですがどうなんですかね？

CI（継続的結合）ツールを使う

Hudsonなど。テストを自動実行し、落ちたらメールで教えてくれる。
使い出すとSlowtest問題に直面するらしい。

　テストに時間がかかる→select系はデータを入れ替えないでやるなど

見積もりと計画

苦手
苦手でなくやってないだけ
社内で読書会など
アジャイルな見積りと計画づくり（http://www.amazon.co.jp/exec/obidos/ASIN/4839924023/flare-22/ref=nosim）を読むといいよ
ユーザストーリーに分割

　プランニングポーカーでストーリーポイントを割り振って、期間内に何ポイント消化できるかを肌でつかむ
　2週間1イテレーションがちょうど良かったらしい
　ユーザストーリーでなく、機能別にやっている

タスク

いつでも誰でも見られるように、ホワイトボード＋付箋でやってる
Tracにも登録しているけど

進捗管理

バーンダウン
正直に書く（FF13のような大型タイトルが出るとスケジュールに影響が出るのでそれを見越す、など）

XPにするのが困難なら、それにもアジャイルで対応する

入力項目の仕様をExcelで提出しなければならない
・プログラムでExcelを読み込んでバリデーション
・DB→Excel、Excel→DBができる環境を作っておく

個人のローカルで動いているプログラムも多数ある

大きなものは把握できるように小さく分ける
小さい単位で1つずつ相手する
知見を

とりあえず個人で導入してみる
そこからチーム→会社→社会に展開

結果だけを求めない

余談：iPhoneをプレゼンのリモコンにしているのが見ていて良い感じに思えた。

【19-E-4】クラウド開発に役立つ OSS あれこれ

オージス総研のオブジェクトの広場を見るといいよ

企業のサービスをクラウドを使って再構築する場合、既存システムと連携がいる場合がある
テストには社内にも環境がないと、テスト実行にお金がかかる
デプロイを簡単にしたい。たくさんの環境に人の手でやるのは怖い

とりあえず繋げて
エレガントに繋げる

プレゼン資料のアップを待とう・・・・

【19-B-5】パネルディスカッション　出張！ DDD難民救済キャンプ〜ドメイン駆動設計をあきらめない〜

なぜ今DDDか？
海外ではかなり流行っている（日本ではほとんどない）
ドメインモデル貧血症
ユーザのドメインに関連した問題を解決する能力
TheBook　ドメイン駆動設計
ドメイン＝知識・組織・活動の領域
複雑なドメインは、モデルに基づいて設計すべきだ（実装の手法でなく、建築物のようなもの）
知識の噛み砕き

ユビキタス言語
ユーザの言葉で作られたドメインモデルを作る

モデル駆動設計
設計から実装をトレース可能に作る
実装からモデルにフィードバックもある

深いモデル
ドメイン自体をインクルメンタルで作る
ある時点まで到達するとブレイクスルーが起こる

自分にとってのDDD

佐藤

　ソフトウェア開発が目指すべき最終形
　テクノロジーが変わっても、活動は変わらない

角田

　銀の弾丸などない
　DDDは開発の生産性を上げるものではない。むしろ長くなる。納期に間に合わなくなる
　全てに適用できるわけではない。開発の90%は適用しない

渡邊

　複数のアプローチを持っておくことは、技術者としての嗜み
　90%の案件をRailsでさくっと作っていても、10%の時の方法を持っておくべき

和智

　同じ言葉で同じものを見る
　新しい言葉を見つけると、見えていなかったものが見えてくる

明日から始めるDDD
・敷居が高い
　要アジャイル開発
　洋書
・入門者向け
　http://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap1.html
　（パターンの紹介に偏っているので注意）
　http://www.infoq.com/jp/minibooks/domain-driven-design-quickly
　http://www.amazon.co.jp/exec/obidos/ASIN/4798116173/flare-22/ref=nosim
・実装者向け
　普段使っているDAOをリポジトリに名前を変えてみるｗ（概念から考える）
　DAOで一番良くないのは、結合表を返すもの
　DDDサンプルでググる
・設計者向け
　エクセルで設計書を書いて終わりでなく、実装の視点を持つ
　実装者と近くなる
　レビューで実装者と意識あわせをする
　プロジェクトの用語集をきちんとメンテし、設計書やモジュールに反映させる
　ユビキタス言語を中心に使う
・マネージャ向け
　戦略的設計（本の1/3を占める内容）
　チーム設計
　　アプリケーションエンジニアの復権。共通基盤だけでなくアプリ作りにも優秀な人を入れる

【19-D-6】Programming Amazon Web Services/EC2,SQS,S3,SimpleDB

Amazon Web Service Use Case

Backup / Archive
Media Sharing
Media Distribution
Academic Computing
Website Hosting
Programing Trading（金融）
Media Rendering
Search Engine Crawler
Social Network（mixiなど）
Online Gaming

S3=Simple Storage Service
物理ディスクを送って、import/exportをしてもらえる

EC2=Elastic Compute Cloud
OSはLinux, WindowsServer2003, 2008, OpenSolaris

シンガポールにセンターを作るらしい（2010のH1）

2010-02-18

デブサミ2010に行ってきました

devsumi2010

去年に引き続き、今年もDevelopers Summit 2010 に行ってきました。
情報は生ものといいますので、忘れないうちに書き起こしておきます。メモ書きからの転記ですので間違いがありましたらご指摘ください。

ソースコード・リーディング・ワークショップ in デブサミ2010

ソースコードを読む力を養うために、実際にコードを読んで参加者同士数名のグループに分かれて語り合う会。JavaAppletの動くコードを読んで、さらに機能追加差分のコードを読んで組み込んでも問題ないかを評価する課題です。
僕も数日前にコードを読んでいたのですが、開発スタイルが少し書いて動かしてみるやり方をしているので、コードを読むだけなのは難しかったです。とは言うものの、現場でも経験の浅い人がリポジトリにコミットした時には、一つ前のバージョンと比較して差分を読んでいますね。難しく感じたのは読みが足りなかったからかな。

セッションメモ

ソースコードメトリクスと読解時間の関係
変数の数が多いと、読解に時間がかかる
呼び出しメソッドが多いと、読解に時間がかかる
変更差分の行数は、読解時間に影響は少ない
日本では開発者と研究者の連携が不十分
Apache Mavenでメトリクス計測ができるので、とりあえずそれから使ってみるといいかも

変更の種類
変更メソッドの複雑さ
変更の規模
差分の複雑さ
差分から参照される外部定義

【18-C-3】アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-

「実践アジャイルテスト」の訳者の方がスピーカー。アジャイルテストとは何ぞや？という事を本を読んだ気になれるセッションです。

Q.アジャイルテストとは？
A.アジャイルチームのテスト

内容

高品質なソフトウェア開発に重要
ビジネス面、技術面の軸と、チームを支援する目的か製品を批評する軸の4象限
プラクティスがある
これから取り組む人へのアドバイス

プログラマでなくテスターの視点

従来型テストの視点

標準（IEEEなど）
テストタイプ、テストレベル
インシデント管理
テストケース作成
網羅性

メソドロジ

プロセス記述(WBS)
ガイド
作成済みサンプル

4象限

技術よりでチームを支援する：単体テスト・コンポーネントテスト
ビジネスよりでチームを支援する：機能テスト（ストーリーテスト・プロトタイプ・シミュレーション）
ビジネスよりで批評する：探索的テスト・シナリオ・ユーザビリティ・ユーザ受け入れ・アルファ/ベータ
技術よりで批評する：パフォーマンス/負荷テスト・セキュリティテスト・「〜性」テスト

高品質を目指すチームのプラクティス
1.チーム全体のアプローチを取る
　　会議に参加する
2.アジャイルテストの考えを採用する
　　より良い方法を常に探す。良い本やブログを読みアイデアやスキルを身につける。
3.自動リグレッションテストを適用する
　　自動リグレッションは開発者・テスターどちらかでなくチームの仕事。シンプルにはじめる
4.フィードバックを与え、受ける
　　フィードバックはアジャイルの中心的な価値である
5.コアプラクティスの基礎を築く
　1.継続的インテグレーション
　2.テスト環境を管理する
　3.技術的な負債を管理する（未解決の技術的課題の累積）
　4.段階的に作る
　5.コーディングとテストはひとつのプロセスとする
　6.各プラクティスの相乗効果を図る
6.顧客と共同作業をする
　　テスターはまとめ役になる
7.広い視野を持つ
　　現在のストーリーがビジネスの重要なスキームに合うか評価できるようにする

アジャイルテストへの移行
1.文化的なチャレンジ
2.チーム運営
3.プロセスの移行（できるところから始める、既存のプロセスに従うべきものもある）

Rational Team Concertの宣伝

【18-E-4】データベースの品質を守る。-22年間のノウハウを終結させたデータベース開発・運用改善手法の紹介-

データベースを読み書きするアプリの品質を良くするためには？

ソフトウェア品質を追求する大きな課題
・確率でないと語れない。
・10回連続で動いても、次に動くとは限らない。
・ハードでもリコールが起こるなら、ソフトでは当然（常に確率論）

ソフトウェアほどいい加減なものもない。動かなくても責任取らないよとたいていのソフトに書いてある。

良いアプリケーションとは
・正確（機能を満たす。バグフリー）
・効率
・運用効率（今日も明日も一年後も動く。誰でも修正できる）
　天才の仕事でなく、努力の結果

高品質なアプリを作るには？
　テスト

開発の標準化はテストの標準化にあり

これらのことが正しく行われていれば、最適化する必要のあるコードは5%ぐらいになる
・計測可能なテストケースの作成（成功か失敗か）
・コードのテストユニット化
・デバッグの自動化
・標準化されたコード規約の適用

SQLチューニングの課題
・最適なSQLを証明することは事実上不可能
・SQLの性能は、本番直前までテストされない
　データ数や同時アクセスユーザ数は考慮しているか？

Toad for Oracleの宣伝

【18-B-5】クラウドの構築事例「クラウドサービスAmazon EC2を活用した「SKIPaaS」構築事例」

実際にAmazonEC2を利用してクラウドサービスを立ち上げた際の体験談です。本にまとめて出版されているようです。

Amazon EC2/S3とは？
・EC2：仮想サーバ
・S3：オンラインストレージ
・初期費用無料で1h/1GBごとの従量課金
・インフラにかかわるコストを小さくできる
・VPNにより自社内ネットワークのリソースとして利用できる
・APIで操作する（HTTP API）

基本機能
・AMI
　仮想OSイメージ。バックアップ・リストアで環境のコピーが容易
・KeyPairs
　リモートログイン時に必要となるキーの生成
　ログインセキュリティの強化
・SecurityGroup
　仮想サーバへのアクセス制限

ネットワーク遅延の対策
・日本とアメリカ・ヨーロッパのRTTは、200ms程度かかる
・Amazon CloudFront（キャッシュサーバ）もしくは国内に静的コンテンツサーバを併設

ストレージ
・Amazon EC2（ローカルディスク）複製されない
・Amazon EBS 書き込み時に複製。同一のZONEのみ
・Amazon S3 書き込み時に複製。2つ以上のZONEに複製
・仮想サーバのローカルディスクは、サーバを停止させると消える。ロストしたくないデータはEBSの利用が必須

利用例
・EC2　基本的に変更しないシステムデータ
・EBS　ファイル、DB、ログなどのアプリデータ
・S3　バックアップデータ、カスタムAMI

バックアップ
・システムはAMI化してS3にとる
・EBSのデータをS3にスナップショット
・S3Sync

メールサーバ
・EC2のインスタンスで使うIPアドレスが、スパムメールのDULに登録されていることがある
　spamhaus.org / mail-abuse.com (maps)
・DNSの逆引き設定をAWSに申し込む。この後スパムリストに解除申請を出す

オペレーションミスの影響範囲
・本番用とテスト用で別のアカウントIDをとるといいよ

インスタンスの障害対応（すべて英語）
・AWS Health Dashboard
・AWS Developer Community Forum
・AWS Premium Support（有償）

アクセスできなくなった場合の復旧パターン
・自然復旧
・API経由でリブートによる復旧
・AWSサポートスタッフによる復旧
・別インスタンスへのマイグレーション（ユーザ側、AWS側）
対応フローを準備しておく

OSより上のレイヤはユーザが責任を持って運用する
・バックアップ、セキュリティパッチの適用、HTTP死活監視

【18-E-6】RDB入門〜アプリケーション開発者が陥りやすいDB開発の落とし穴〜

DBにまつわる問題とその対応。僕の周りでも同じような事例がありました。

1.システムがとまった
2.プログラムのパフォーマンスが出ない
3.Viewを使っているのだがパフォーマンスが出ない
4.マルチコアCPUが有効に利用されていないようだ

1.システムがとまった
　特定の処理でフリーズするが、毎回発生しない。テスト環境で再現しない。
　原因は、ある処理がトランザクション分離レベルをReadCommitedに設定していた（システムはReadUncommitedが前提）
　.NETの仕様で、プールされているコネクションは直前に使用された分離レベルを継承する。
　解決方法は、処理開始・終了時に必ず分離レベルの設定を行う
　RDBMSによって実装の仕方が違う（Oracleではこのケースは発生しない。読み取り一貫性）

2.プログラムのパフォーマンスが出ない
　要求仕様を単純にSQLに置き換えると、何回もSQLを実行する場合があるので効率の良いSQLを検討する

3.Viewを使っているのだがパフォーマンスが出ない
　Where句のつけ方でViewを使うほうがパフォーマンスを低下させることがある。
　マテリアライズドビューを使う解決方法もあるが、Refreshの管理やデータ領域に気を配る必要がある。

4.マルチコアCPUが有効に利用されていないようだ
　ディスクIOがボトルネックになっている場合があるよ

あとSQLAnywhereの宣伝

【18-C-7】アーキテクチャに憧れろ - 『ソフトウェアアーキテクトが知るべき97のこと』著者パネルディスカッション

アーキテクトが知るべきの本にはあまり触れずに、アーキテクトの人がどんなことを考えているかという会でした。

普段触れているアーキテクチャ
　Swing, Silverlight, MVC, データスパイダー（パッケージ）

考えること
　クラウドのデータはスケールアウトすると、コミットしたデータが反映されるまで時間がかかる
　これをどう利用するかがアーキテクトが考えるところ

　インターネットのクラウドと企業のクラウドは別物と考えたほうがいい
　今何か新しいサービスを立ち上げるならクラウドを使うことも考える

アーキテクチャで失敗したこと
　フレームワークのような土台になるものは、きちんと作りこまないと後で後悔する
　フレームワークはコミュニケーションツールのようなもの
　コストの高いフレームワークを作ってしまった
　完璧なものを作っても、既存のものは捨てられない
　理想を求めすぎるとよろしくないものができた

アーキテクチャは後方互換性も考える
　Windowsは意外と後方互換に気を使っている（これも戦略）

ライフサイクルが短い製品を作るときに、いろいろ実験する
　メインの製品に依存しないように

社会的なアーキテクチャ
　 Twitterはなぜこれほどまでヒットしたのか

はてブのホッテントリに表示されるジャンルがIT以外も出てくるようになった
　IT以外の量が増えたわけでなく、ITの表示を絞った。
　各ジャンル2位まで表示

企業情報システムは使われていないものが多い
　なぜ使われないかを追跡する機会が少ない
　運用をやれば機会があるかも

お金を払わせるサービスは？
　人の感情を刺激するものがヒットするかも。サンシャイン牧場やブラウザ三国志

スーパーマリオのジャンプは計算され尽くしている
　気持ちのいいジャンプ
　とあるゲーム会社で入社試験にジャンプをするだけのプログラムを作らせているところも
　センスが見られる

ペアプロは良いものだ。
メソッド名を考えるのは大変だ。

使い方