本の虫: プリンスオブペルシャのソースコードを救ったギーク達
The Geeks Who Saved Prince of Persia's Source Code From Digital Death | Game|Life | Wired.com プリンスオブペルシャのオリジナルのソースコードが発掘され、GitHubで公開されたことは記憶に新しい。しかし、その裏話はしっているだろうか。昔の電磁的記録のサルベージがいかに難しい作業であるか、認識しているだろうか。wired.comですばらしい記事がでたので、翻訳する。 WiredのGus Mastrapaはロサンゼルスで、ゲーム史に残る重要な財産を発掘する作業に立ち会った。 Jordan Mechnerは何でも保存してきた。 彼は、兄弟が近所で飛び跳ねる様を撮影した1985年に撮影したビデオテープを保存している。この動画から、彼はApple IIのPrince of Persiaのアニメーションを作成
基金訓練の講師
基金訓練の講師をやめました。基金訓練、今は求職者支援制度に名前が変わったみたいですけど、そこの講師をやめたというか、会社ごとやめて転職しました。 何の講師をやっていたかというと、今をときめく(?)Androidの講師です。 転職先にも少しなれてきて、今までのことを振り返って書き留めてみたのですが、せっかくなので発表することにしました。もともと僕だけが読むメモのつもりで書いたので、読みやすい文書ではないですがご容赦のほど。 Androidの講師になるまでAndroidの講師になるまでは、Javaのサーバーサイドのエンジニアをやっていました。 お客様のところに常駐し、システムの一部ではあるけど、自社メンバーだけで上流行程から担当し、僕はそのチームリーダーでした。 でも、このご時世なので、仕事がどんどんなくなっていきます。 プロパーの方でも仕事がないような状況で、それでも僕らのチームは半年ほどは
C 言語や Windows プログラミングはこのようにして習得した Part 1 - 登 大遊＠筑波大学大学院コンピュータサイエンス専攻の SoftEther VPN 日記
あまり参考にならないと思いますが、私がどのようにして C 言語や Windows プログラミングを習得したのかを書いていこうと思います。 C 言語を勉強しなければならないと思ったのは、中学 1 年生の 4 月でした。多くの中学校、高校にもあると思いますが、私が入学した「高槻中学校・高等学校」にもパソコン部のようなものがあり、そこでは C 言語が流行していました。 C 言語が流行していたといっても、「C 言語が良いらしいぞ」という言葉が流行していたという程度であり、誰か C 言語によるプログラミングがものすごくできて人に教える能力がある程度の生徒や教員がクラブにいた訳ではありません。当時、クラブでは PC で動作するフリーウェアのゲームが多数流行っており、放課後や昼休みなどに皆で必死にゲームをして遊んでいました。そのときに流行っていたゲームの 1 つに、以下の「Flying Jump」という
iPhoneでJailbreak時の正規開発環境 - タナカイチロウの日記
Jailbrokenな端末で正規のiPhone Developer Programの証明書で開発ができるのかよくわからない。 http://www.iphonedevsdk.com/forum/iphone-sdk-development/19444-developing-codesigned-apps-jailbroken-device.html この辺にCode Signのエラーについて色々書かれてたり。 一応証明書偽造？してAppleの認証を回避するような方法でXcodeからDeviceを登録して正規環境と同じように開発する方法はある。以下2chからの引用 【JailBreak】非公式アプリ開発スレ【ToolChain】 http://pc11.2ch.net/test/read.cgi/iPhone/1218719962/ 73 名前: 名無しさん＠お腹いっぱい。 
最近のアプリケーション開発で理解しておかないといけない基本事項 - 丸井綜研
とくにMacやiPhoneのプログラム開発で最初にわからなくなるのがこのあたり。Appleもそれは理解していて、Your First Mac Applicationの中のUnderstanding Fundamental Design Patternsという章にまとめてあります。 僕もまだ慣れてないので、その文章を読んでの現時点での理解を下にまとめておきました。 Model-View-Controller その昔、僕がBASICでプログラムを書いていたときにはデータもコードも一緒くたで、すぐにスパゲッティ・コードになったものでした。Javaのようなオブジェクト指向言語を使うようになって、データ構造部分とその表示部分とは切り分けた方がいいと学びました。 たとえばRPGを作っているときに、体力点とか技術点のような主人公の基礎データを保管・管理する部分と、それらを画面に棒グラフなどで表示する部分
プログラムを理解させるには？
K＆RのCで書かれたプログラムを渡された（もう少し正確に言えば、VisualStudioのWizardで作られたものにK＆RのCでコーディングしてある(C++ですら無い)ので純粋なCでは無いが果てしなくK＆RのCだ）。あと、これを作った人はどうにも「ポインタ」の概念が無いらしく、無駄に多次元配列だったり、配列のアドレス渡しとかが多用されている。 作業指示は、これを流用して、C++/CLIかつ.netFramework3.5使用かつ新規案件に対応せよ、との事。 個人的にはどう見積もっても3人で4ヶ月かかる量なんだが、予算が1人で1ヶ月、と言って来た。理由は「Cからの流用だから」。 参ったな。自分としては、C++/CLIはもはや別言語だと思っているんだが。 どうにも上司と顧客に説明出来ない。説明出来ないのは、自分が理解していないせいだ、と言われればそれまでなのだが、自分の感覚で言うと、高段者が
Joel on Software - 射撃しつつ前進
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2002/1/6 ときどき何もできないことがある。 確かにオフィスにやってきて、だらだらとし、emailを10秒ごとにチェックし、Webをながめ、アメックスの請求書を支払うというような頭を使わない作業をしたりもする。しかしコードを書くフローの状態に戻ろうとしても、それができない。 このような非生産的な期間は通常1日か2日続く。しかし私の開発者としてのキャリアには何週間もの間何もできずにいたということが何度かあった。言うならば、私はフロー状態になかった。私はゾーンの中にいなかったのだ。私はどこにもいなかった。 誰でも気分のむらはある。ある人々にはそれは穏やかなものだが、他の人々には、それはもっとはっきりしていて、ときには機能不全でさえある。そして非生産的な期間は塞いだ気分と何か関係しているようだ。 それ
画期的なバグ票分析→だいたい探索型テスト支援システムをちゃちゃっと書いてみた。 - I like Ruby too.
私は最近のバグの傾向、キーワードを組み合わせて連想したネタでバグを見つけることが多いです。見つけないことも多いけど。 これを機械にやらせたらおもしろそう。 https://github.com/seki/Drip/blob/master/sample/tw_markov.rb オフレコなんだけど、githubのDripのsample/に、自分のツイートのログからマルコフ連鎖つかって自分っぽいツイートを生成するスクリプトがあるじゃん？この自分のツイート風文章作成の辞書をバグ票から作ればそのシステムに出てきそうなバグが作れるはず。 んで、やってみた。（あまりに短いのでスクリプトは載せません） うちのRWikiに入ってる数万のストーリーから直近の数千のバグっぽいチケットを集めてきて辞書を作って、バグ報告風文章を作成するシステムを書いてみたですよ。確かにそれらしいバグ報告が生成されます。次はそのバ
続・テストコードのリファクタリング - 千里霧中
「テストコードのリファクタリング - 千里霧中」の続きです。 十分に実施できる方法 テストコードを対象としたリファクタリングの回帰テストについてですが、現実性があり、十分に実施できる方法は主に次の２つとなると思います。 テストコードのインプットとなるテストケース仕様にもとづいて、ミューテーション分析を実施。ミューテーションテストと正常系のテストを実施することで、バグがなければパスし、バグがあれば失敗することを確認する。 テストコードに対する入出力・間接入力（テストフィクスチャからの入力など）・間接出力（Assertionメソッドへの出力等）を、Test Doubleやロギングで網羅的に記録。変更前と変更後で、入出力、間接入力・間接出力が変化しないことを確認する。 ただ現実性があるといっても問題もあります。ミューテーション分析については、テストケース仕様からミューテーションテストの仕様を作成
なぜUnitTestは理解されない？
TwitterでこんなTweetが流れた… エビデンスとしてNUnitのGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・ UnitTestのエビデンスって…なに？ 一般的にテストのエビデンスというと、次の2点を指す。 テスト手順を明らかにするもの（ex. テスト設計書、テスト仕様書、...） テスト結果の証拠（ex. 画面ハードコピー、DBスナップショット、...） UnitTestでは、これはこのように解釈できる。 テスト手順を明らかにするもの ＝ テストコード テスト結果の証拠 ＝ 今実行すればテストが全てグリーンになること これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。 なぜUnitTestはいつまでも理解されないのだろう。 余談。これらのことは、Seleniumなどを使
語学でもプログラミングでもスキルを高速に学習できる方法：村上福之の「ネットとケータイと俺様」：オルタナティブ・ブログ
ダメ人間のスキルの習得には下記の表のような法則が成り立つと思っています。 はてブで「これをやって英語を身に着けたぜ！」というエントリーがブックマークをのばしますが、僕個人では意味がないと思ってます。ぼくのようなダメ人間の場合、モチベーションが続かないからです。 お金払って英会話学校に行っても身には付く速度が遅いです。一方、無理やり海外の仕事を担当させられた人はものすごい速度で英語が話せるようになったりします。 ただし、こうやって無理やり身につけた知識はあまり体系性が無く、自分が使った分野しか学習できないというデメリットもありますが、それを補って余りある学習速度があると思います。 個人的には、１円でもいいからカネを取ると早く身に付くと思っています。 こう思うようになったのは、8年ほど前、こういう人に会ったからです。たしか大阪の起業フェアな何かでお会いした方だったと思います。 彼は英語にコンプ
TwitterのステータスIDが53bitを越えたお話 - tmytのらくがき
僕の記事の間違いを指摘していただいているすばらしい記事です。僕の記事よりこちらの記事をご覧ください。 http://archive.guma.jp/2010/12/twitter-json.html 先日、29日の7時過ぎごろにTwitterのステータスIDが53bitを越えました。 こんな中途半端なビット数を超えただけでなぜこんな記事にするかというと、一部のクライアントで動作がおかしくなることがあるからです。 (14:14 追記しました) (14:31 もひとつ追記しました) TwitterのAPIはXMLとJSONの2種類で結果を取得できます。このうちXMLで処理してる場合は内部で64bit INTで処理していれば特に問題は起きません。 問題が起きるのはJSONの場合です。JSONはJavascriptでevalすればそのまま中身が取り出せることからもわかるように、Javascript
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
第4回 オブジェクト指向の本質 | gihyo.jp
エンジニアとして良い仕事をするために必要なこと ソフトウェア業界で日米を往復しながら仕事をしていると、世界中のさまざまなエンジニアに会う。私のように「プログラミングを心底楽しんでいる」人から、「新3K」（きつい・厳しい・帰れない）を身をもって体験している人までさまざまだが、共通して言えることは、エンジニアとしての基礎がしっかりできている人とできていない人では、その生産効率に大きな開きがあり、それが結果的には、会社での労働環境や待遇に、そして結果として自分自身にとっての「仕事の充実度」に、大きな影響を与えているということである。 いつも締め切りに追われている、毎回バグで苦しんでいる、徹夜の連続で体力に限界がきているなど、「仕事がきつい」理由はいろいろとあると思うが、会社や上司の悪口を言う前に、自分自身がプロフェッショナルなエンジニアとしてこの業界で勝負をするうえで必要な最低限の基礎がで
第1回 良いコードを書くための5つの習慣［前編］ | gihyo.jp
本連載が書籍化されました。 『良いコードを書く技術 ─ 読みやすく保守しやすいプログラミング作法』 縣俊貴 著／A5判・240ページ 価格2394円（本体2280円） ISBN 978-4-7741-4596-9 はじめに この連載は、「良いコードの書き方」を知ることを目的としています。みなさんの周りにも「良いコード」をものすごいスピードで書き上げて、開発の原動力となっているプログラマがいませんか？ 本連載ではそのような「できるプログラマ」たちが「日常的に意識していること」に注目して、彼らの中では常識だけど一般的には気づかれていないような内容を、プログラミング初心者にもわかりやすい言葉で解説していきます。プログラミング言語はJavaを中心に説明しますが、RubyやC＃、JavaScriptなどでの例も織り交ぜていく予定です。 第1回の今回はウォーミングアップとして、良いコードを書くために
単体テストを“神速”化するQuick JUnitとMockito
単体テストを“神速”化するQuick JUnitとMockito：ユカイ、ツーカイ、カイハツ環境！（16） Quick JUnitプラグインの3つの大きな特徴 近年、JUnitとHudsonを利用した継続的インテグレーション（CI）によるテストの自動化や、テスト駆動開発（TDD）の普及などにより、ユニットテスト（単体テスト）のテストコードの作成が重要視されています。 今回紹介する「Quick JUnit」プラグインは、JUnitによるテストコードの作成と実装を支援するEclipseプラグインです。Quick JUnitプラグインは石井勝さんにより開発されていましたが、石井さんが不慮の事故により死去後、Quick JUnitプラグインプロジェクトにより開発が継続されています。優れたオープンソースプロジェクトの模範のようなプロジェクトです。 訂正のお知らせ 故人のお名前について間違いがあり、修
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
グラス片手にアジャイル開発 第1回 ― 実践的アジャイル開発とは