ゲームエンジンUnity - Radium Software
最近、仕事９割、趣味１割ぐらいの気持ちで、Unityに触れている。 UnityはiPhoneゲームなどでよく使われているゲームエンジンだ。個人的にはGame Blenderに近いものがあるかなと思う。３Ｄシーン上に配置されたオブジェクトに対して、各種のコンポーネントとスクリプトを組み込んでいくと挙動が構築され、それが最終的にはゲームになる、って感じだ。 Game Blenderは元がＣＧツールということもあって複雑過ぎるきらいがあったのだけれど、Unityはゲーム専用に特化して設計されており、それでいてまとめ方のセンスもいい。 プログラマー向けの技術的な情報については、Blurstの中の人によるこちらの解説が参考になると思う。 Unityの基盤となっている技術は、.NETフレームワークのオープンソース版代替物であるMonoプラットフォームだ。Unityは表向きJavascriptによるスク
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
近況 - "チームがよくなる" 感じについて - steps to phantasien(2009-12-31)
2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー
継続した学習: 柴田 芳樹 (Yoshiki Shibata)
ソフトウェアの世界は、ずっと変化してきており、今後もその変化は続きます。私が初めてコンピュータに触れてから31年が経過していますが、学ぶべきことや面白そうなことが毎年のように登場してきます。 一方で、2、3年以上を要するソフトウェア開発では、その開発で使用される技術は開発期間中は固定化されます。そのため、業務をこなすのに最低限必要な技術を学習しかしなくても、そのプロジェクトが続いている限り、問題なく仕事をこなしているような感覚になるかもしれません。 常に継続して学習しているかしていないかで、ソフトウェアエンジニアとして技量は大きく差が付きます。たとえば、JavaあるいはRubyを使用して開発しているプロジェクトであれば、長い開発期間中に『プログラミング言語Java』、『Effective Java』、『プログラミング言語Ruby』などの使用している技術に関したきちんとした書籍を並行して読む
幸せなエンジニアになるための仕事術/まつもとゆきひろ＆平鍋健児 - tmtms のメモ
幸せ 平鍋: 1. 技術的な困難を達成。 2. お客様に感謝された。 最初は1だったけど最近は2。 まつもと: 理不尽な目に合わないこと。 思うようにツールが動かない→自分でつくる。 OSSは自分で手を入れられる。 平鍋: 自分一人の幸せじゃない。 プロジェクトが終わっても続く人間関係。 人のつながり。信頼。 まつもと: 通勤が3時間。理不尽→地方。 納得行かない変更が顧客から言われたくない 平鍋: エンジニアで不幸せな人へ。仕事は選べる。極端なこと言えば辞めればいい。 ワークライフ・バランス実現の戦略（例：地方に住むこと） 平鍋: 1995.子供を育てられるかを考えたときに自分の中での都会の価値がさがってきた。 田舎に帰ってから、世界のことを考えた。JUDE,アジャイルをやり始めた。 まつもと: 鳥取→つくば→島根 1997. OSSビジネスを始めようと声をかけてもらって島根へ。 理不尽
金曜にバグを発生させるコミットが多い - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
コードポケット - アプリケーションをささっと作るコツ - （ひ）メモ
誰に教えられたのでもないのですが、ぼくは冬眠前のリスのようにコード片を溜め込んでいます。 コード片とは、ライブラリにするほどまとまった大きさではない、数行〜十数行のコードのことで、溜め込んだコード片は、アプリケーションやツールを作るときに使っています。 例えば「Perlでメール送るのどう書くんだっけかな」とか「Pythonでファイル開いて全部読むのどう書くんだっけかな」とかというときに、溜め込んだ中からコード片をさっと取り出してコピペした後、なじむようにちょっと修正して使っています。 コードポケット コードを溜め込んでいるディレクトリをぼくは「コードポケット」と名付けていて、コード片を取り出すことを「ポケットからコードを取り出す」と呼んでいます。先日、知り合いが似たようなことを実践していて、その人は「コードスケッチ」と呼んでました。いい名前ですね。 ぼくの場合、コードポケットは ~/lan
オトコの生きる道
2008年初頭に、MySQL ABがSunに買収されて非常に驚いた。400人弱の会社を10億ドル（1000億円程度）で買収するという破格の買収劇だった。単純計算でいうと、一人頭2.5億円で移籍したわけである。そして俺もその400人の中に含まれていた。。。 MySQL ABは素晴らしい職場だった。Sunに買収されてから現在に至るまでも、Sun自体の業績が良くなかったために人員の増加が出来ない（超忙しいヨ！）といった問題はあったものの、基本的にはMySQL ABと同じ労働環境を維持することができた。MySQLサポートチームの同僚は世界中に住んでいて、仕事を始めると社内のIRCにログインして挨拶を交わし、電話とPCとインターネットさえあればどこでも仕事をすることが出来た。（だから殆どが在宅勤務である。）そして同僚の技術レベルが素晴らしく高かった。早いときには30分以内にソースコードを確認して回答
実践的な Haskell の本 - あどけない話
Perl6 は何年経っても正式にリリースされません。そんな Perl6 を Audrey Tang さんは、たったの数ヶ月で作りました。その実装は Pugs と呼ばれています。短期間の開発を可能にした秘密兵器は Haskell です。 その Audrey さんが、2006年に日本で Haskell について説明してくれました(資料)。残念ながら、そのころの僕は Haskell に興味がなかったのでチュートリアルは受けていませんが、その概要にはこう書かれています。 コーナーケースを探すのにユニットテストを書くのに疲れた？ QuickCheck を使ってコンピュータに書かせちゃいましょう。正規表現ベースのパーサはメンテナンスしにくいのに気づいた？ Parsec を使って 15分で Perl6 の完全なパーサを書く方法を勉強しましょう。デッドロックやレースコンディションはもううんざり？ STM
Perl/XSが得意なこと - Islands in the byte stream (legacy)
最近ひたすらXSを書いていて思ったのが，XSはやっぱり速いということ。 ただ，いつでも無条件に速いというわけでもなく，何も考えずに書くとPurePerlのコードより遅くなることも珍しくない。実際，最近書いたShikaやMOPのXS版もいきなり高速だったわけではなく，一番最初のコードはPurePerlのほうが10%-30%ほど高速だった。 いろいろベンチマークをとった結果の感触として，XSの得手・不得手が分かってきたのでメモしておく。ちなみに下記で「注意を払う」というのは内部で呼ばれるmalloc()を極力減らすという意味で使っている。SVの生成自体はmalloc()を伴わないことが多い*1が，文字列の生成/連結や配列の生成/push/unshiftでは内部でmalloc()が呼ばれる可能性が高く，速度を落とす原因となる。 得手分野 ループ - XSのループが早いというより，Perlのループ
なぜ関数プログラミングは重要か
John Hughes, Institutionen för Datavetenskap, Chalmers Tekniska Högskola, 41296 Göteborg, SWEDEN. rjmh@cs.chalmers.se この日本語訳は原著者の承諾を得て山下がここに公開するものです。 この訳文についての、御指摘などは山下伸夫(nobsun .at. sampou.org)までおねがい いたします。 翻訳最終更新日 : 2011-09-17 原文 "Why Functional Programming Matters" 日本語訳PostScript この論文は1984年以来何年ものあいだChalmers大学のメモとして回覧された。 1989年と1990年に幾分か改訂をしたのが[Hug89]と [Hug90]である。この版はもとのChalmer大学のメモ のnroff原稿をもとに
Emacs で C とか Perl とか Ruby のデバッグをすると気持ちいい | フッ君の日常
全国のprintデバッグ愛好家の皆様、こんにちは。VSとかEclipseとかのIDE以外でデバッガを使ったことのない僕がやってきましたよ。 最近、C言語でヒーコラ言ってる真っ最中な訳ですが、C言語だとprintデバッグがやりにくい訳で、デバッガ様の力を借りてみたくなった訳です。という訳で、巷で有名な gdb をちょっと試してみました。 基本的な使い方は、以下を参考にしてます。gdb を用いたデバッグ方法GDBウノウラボ Unoh Labs: gdbの使い方 で、なんだか Emacsからも使えるみたいなんで、試してみたんですが、これが使いやすくてびっくり。"M-x gdb" で起動すると、Emacs のソース上に、現在の行が黒三角で、ブレークポイントが赤丸で表示されます。後は、コマンドラインでの操作と同じように、s とか n でステップ実行できます。 あー、もしかして、Perl とか Rub
Google Japan Blog: 日本のデベロッパーの要望に応え、多くの技術ドキュメントを日本語化しました
メディア関係者向けお問い合わせ先 メールでのお問い合わせ: pr-jp@google.com メディア関係者以外からのお問い合わせにはお答えいたしかねます。 その他すべてのお問い合わせにつきましては、ヘルプセンターをご覧ください。
極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ
今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる
steps to phantasien t - It's time for ...
HTTP の神 Roy Fielding による Apache 3.0 の 講演をストリーミングで拝聴した. (スライド PDF.) スライドの副題にもあるとおり, Apache 3.0 の計画は大風呂敷 (tall tale) で しばらく実現の見込は薄そう. ただ, コミュニティが大きな書き直しに至るまでの話は面白かった. http-dev メーリングリストの流量を時系列にプロットした Fielding は, 書き直し(メジャーバージョンアップ)開始の手前では ML の流量が減衰していると指摘する. 開発者コミュニティが活力を失っているのだと. そんな時に "がばっと書き直して刷新しようぜ" と言い出すとコミュニティは活気づく. そんな話だった. 2.0 もそうだったし, 3.0 も似た状況にあるという. 実際には言いだすだけでなく, コードが伴う必要もある. 調べてみると, 2.0
Re:Re:プログラマーに比べ、バイオ研究者に飛び抜けた才能が現れない理由のひとつ - ミームの死骸を待ちながら
プログラマーに比べ、バイオ研究者に飛び抜けた才能が現れない理由のひとつ - ミームの死骸を待ちながら 思ったより大量の反応が来てびっくり。170ブクマって……うひー。初のホッテントリ入りで、一時はid:fromdusktildawnさんと並んではてなトップに載り、しかもブクマまでいただき光栄の極みです（ふろむださんのファンなので）。 他に、同じくファンであるid:blackshadow氏やid:umedamochio氏のブクマが付いていました。ニヨニヨしてしまう。 はてなで注目されると言うことは情報系の人々の目に触れると言うことで、優秀なプログラマがバイオに参入してこないかなぁとご都合主義思考が頭をよぎった。 貴重な意見として受け止めて返します。ブコメは敬称略させていただきますm(_ _)m 共感・提案派 いつも以上におもしろい。IT側の視点からたしかにそうだなぁと思わせる。いいシミュレー
コードを憎んで人を憎まず, あるいは. - steps to phantasien t(2008-04-02)
社会人になって最初に配属されたチームのコードはひどいもので, 私は同期の新入社員仲間 Y に "ひどいコードなんだ. あの先輩はろくでもない." と愚痴た. すると Y はぽつりとこう答えた. "<コードを憎んで人を憎まず> だよ." Y の言葉は私の座右の銘となった. コードと人格を切り離す. あたりまえの事に思えるけれど, いまより輪をかけて狭量だった私はひどいコードの書き手を見下していた. もちろん自分は棚にあげて. たかがコードで友情や信頼を失うのは愚かなことだ. Y はそう言うのだった. 件の先輩社員は寛大だった. 私は勢いと趣味に任せて彼のコードを書き換えていたが, 彼は文句もいわず, 雑用を押し付けてくることもなく, 他所からのメールやバグを黙々と片付けていた. 私が同じ立場なら, 間違いなく戦いの火蓋を切っていただろう. (実際, 翌年の私は毎日のように後輩と口論していた.
2008-02-15 - ひがやすを blog - アーキテクト以外は「限定されたことだけやっとけ」
> 私の個人的な意見としては、一部の人(例えばアーキテクト)だけ、 > フレームワーク全体を把握していて、残りのメンバーは >「限定されたことだけやっとけ」みたいなことは好きではありません。 大規模だと好き嫌いに関わらずこういったアプローチになるのでは？ アーキテクト以外の学習コストはむしろ減ると思いますが… きっとこのコメントを書いてくれた人は、本気でこう考えているんだと思いますが、私は、このようなアプローチが嫌いというだけではなく、効率が悪いと思っています。 一番の理由は、開発者のモチベーション。「限定されたことだけやっとけ」という状況で、開発者のモチベーションが上がるとは思えません。実際、モチベーションは下がるでしょうから、それにあわせて、生産性も落ちるでしょう。 二番目の理由は、開発者が成長しないこと。開発者というのは、いろんなプロジェクトに参加し、いろんな経験をつみながら成長して
複数種類のエンティティを扱うロジックをどこに書くのか - ひがやすを技術ブログ
「複数種類のエンティティを扱うロジックをどこに書くのか」、これは、非常に難しい問題です。エンティティに持たせると、どこのエンティティに持たせるのかを判断するのが難しい。 だから、アクションにもたせるのが良いと書いてきました。 でも、売上金額 = 売上明細.商品.単価 * 売上明細.数量みたいなロジックがあって、JSPに売上金額を表示する場合に、このロジックをアクションにもたせるかというと微妙ですね。 売上金額が1つしかないなら、それでもいいけど、複数あった場合は、うまくいかない。コメントで答えたように、これくらいの計算なら、ELでやっても全然いいんだけど、複雑な計算だとどうするのか。 売上明細エンティティが複数あって、複数の売上金額を表示するなら、売上エンティティで計算したほうが全然楽です。 <c:forEach var="e" items="salesDetailItems"> ${e.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
iPhoneアプリ開発に役立つ31のサンプルを公開する「Appsamuck」 【増田(@maskin)真樹】 | TechWave（テックウェーブ）
