Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
最新版はこちらです。 http://d.hatena.ne.jp/uosoft/20091231/1262186194 そろそろネタがたまってきたので、まとめます。 アプリの作り方 iPhoneでのOpenGLの簡単な遊び方 HTMLとJavaScriptでiPhoneアプリを簡単に作る方法 Android SDK インストールからHello World実行まで iPhone SDKでOpenGLに挑戦 立方体を表示してみよう センサー等ハードウェア関連 iPhoneSDKでスリープさせない方法 iPhoneの加速度センサの使い方 画面操作関連 iPhoneSDKのUIViewアニメーション iPhoneSDKでインジケータ(待ち等に表示する回転画像)を簡単に表示する方法 iPhoneで画像のサイズ変更方法(UIImage) iPhone SDK 画面方向の変え方 サウンド関連 iPhon
プログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 風のプログラマー」を指向しており、開発速度を重要視している。 例えば平成14年未踏ソフトウェア創造事業「PICSY」では、 発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて 2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、 このときなどは、大体の要件を口頭で聞いた後は、 ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。 「はまる」時間の長さは開発速度に直結するわけだが、 プログラマーが「はまる」場合にはある程度の傾向があると思うので、 今日は「はまる」プログラマ
アツいエントリなんで思わずTBうってみる。 この業界の問題、それはプログラムが、新人〜3年目の作業と位置づけられていることだ。 プログラマーの誇りを見せ付けろ - 山本大@クロノスの日記 正確に言うと上級プログラマも初級プログラマも同じ値段で評価されるってことが弊害である、ってことだと思います。予めXXX万円で作ってねという予算が決まっていて、その予算をオーバーしないことだけが成果の基準にあることが問題だと考えます。このルールにおいては、極論ですがコード品質が高くても低くても大差が無くねっていう力学が働きます。 基本的にニッポンの受託開発のプロジェクトの場合は、大きく2つのプレイヤーがいます。 案件を立ち上げてお客さんへのコミット権限がある人・会社 立ち上げた案件をシステム化してデリバリする人・会社 ですが、今の流れでは工程が分断されちゃっているので、案件を立ち上げる人とシステム化してデリ
分散バージョン管理Git/Mercurial/Bazaar徹底比較:ユカイ、ツーカイ、カイハツ環境!(3)(1/5 ページ) Subversionとは一味違う「分散バージョン管理」とは? 最近、Linuxをはじめ、Ruby on Rails、MySQL、OpenSolarisなどのオープンソースプロダクトが次々と分散バージョン管理システムを導入し始め、「Git」「Mercurial」「Bazaar」といった、分散バージョン管理システムが注目を浴びています。 本稿では、バージョン管理ツールのデファクトスタンダードであるSubversion(以下、SVN)と分散バージョン管理システムを比較しながら、メジャーな分散バージョン管理システムであるGit、Mercurial、Bazaarについて紹介していきます。 集中型と分散型 最初に、集中管理方式(または、集中型)のバージョン管理システムと分散管理
NAISTにてMeCabの作者としても有名な工藤拓さんの講演が行われました。Googleの開発体制とそれを支えるツールのお話です。 学校と拓さんの双方からブログへの掲載許可が得られたので、まとめを公開します。この講義はNAISTのソフトウェア開発管理講義の一環です。 iPhoneカメラしかなかったので、画像が荒くて済みません・・・。 会場は大入り! 工藤拓さん NAIST自然言語処理学講座出身 Googleに入社してから大規模開発やインフラを経験 MeCabを開発 NTTコミュニケーション科学基礎研究所に所属 その後Googleへ 研究より開発寄り Googleでの仕事 日本語のウェブ検索 「もしかして」機能 ダジャレサーチ エイプリルフールネタを1ヶ月かけて実装 何千人もの開発者が単一のソースコードリポジトリの上で開発を行っている 大規模開発をサポートするインフラが不可欠 Mondria
職業柄、会社についていろいろ意見を頂くことがあります。ネット上で書いてある意見なども見たりします。中には感情的な意見もありますが、その感情に至るまでには何らかの理由があります。ですから、肯定的な意見も、批判的な意見も、製品開発やサービス開発においては非常に参考になります。でも、ひとつだけ、僕が絶対に許せないことがあります。僕は、自分の会社のメンバーが侮辱されることは、それがどんな理由であれ、許せません。 たまには感情的になったっていいじゃない。大人げなくたっていいじゃない。 IT企業が、理論を軽視していいものか。理論が好きな人間を暇人と侮辱していいものか。そもそも、ITの世界で、理論好きか理論が嫌いかという議論が意味があるのか。ITにおける理論は、僕はコンピュータサイエンスだと考えています。コンピュータサイエンスが好きとか嫌いとかの問題の前に、ITに携わる人がそもそもコンピュータサイエンス
友人の話をしよう. 先達に敬意を表し, 仮に彼を K と呼ぶ. (イニシャルは便宜的なものだ; 向上心云々と罵ったこともないし, 恋人を寝取ってもいない.) ある時期, 私は K と一緒に働いていた. 今は違う会社にいるけれど, 互いに暇なのか, このごろもよく二人で管を巻いている. 1 K は優秀なプログラマだ. いつも敵わないと思う. 一緒に仕事をしていたこともあり, プログラマとしての私は K から強い影響をうけている. たとえば私が自動テストを始めた発端には K がいる. コードレビューもそう. この日記に出てくる話も K の影響は色濃い. 私は K のあとを追いかけるようにプログラマを続けている. K と働いてはじめて, ああ, 物事とはこう改善していくものなのかと知った. 何か問題を感じると K は試行錯誤を始める. 問題は私が諦めていたものもあるし, そもそも気付かないものも
2008年05月19日11:45 カテゴリYAPC::AsiaLightweight Languages プログラミングとアプリ開発の違い ああ、YAPC::Asia::2008のトリ、Perl Is unDeadを見せてあげたかったなあ。 プログラミングのジャンルと難易度(および Web プログラミング批判) - 黎明日記 だってそうだろ? 「 Web アプリケーション」なんてカッコイイ名前の割に、受け取ったデータを簡単に加工してデータベースに突っ込んで取り出して……それで終わりじゃないか。ビデオやスライドが上がるまでしばらくかかると思うので、とりあえずは以下をご覧あれ。 はてなブックマーク - タグ yapcasia2008 Simon Cozens - YAPC Asia and talking in Japan YAPC::Asia 2008 2日め - てきとうなメモ で、Sch
ソースコードを見る上で、JavaDocやPHPDocument、RDocのように説明文がきちんと書かれていると見やすくて便利だ。しかし、書くのは良くとも後でHTMLを生成するために都度コマンドを実行するのは面倒に感じていた。 チュートリアルの構造化表示 そこでソースからそのまま読めるようになっていると便利そうだ。その目的に使えそうなのがこのソフトウェアだ。 今回紹介するオープンソース・ソフトウェアはCode Browser、ソースコードを見るのに便利なソフトウェアだ。 Code Browserはテキストエディタとして利用できるが、Code Browserで指定されるコメントの書き方をすると、ツリービューや複数ペインでの表示にするとソースを構造化して表示してくれるようになる。RDocのような4ペインでの表示もできる。 4ペイン表示 構造化した状態では関数を指定するとその関数だけを表示するよう
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら
今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる
http://q.hatena.ne.jp/1203667934 ソフトウェア開発やプログラミングのスピードを上げる方法はありませんか? プログラマーとして生きていこうと決めたのですが、いつも見積もりの3倍時間がかかってしまいます。 そのため いつもつらい思いをしています。 環境を良くしようとHHKLite2を使い、カスタマイズソフトでホームポジションから離さずにプログラミングしています。 マウスもゲーム用の高精度のものを使っています。 調べ物にもタブブラウザを使い、拡張し続けて効率化をしています。 DualCoreマシンを使いメモリもたくさん積み、障害がないように心がけがけています。 出始めのころから効率化のためにエクストリームプログラミングも取り入れていました。 単体テスト、リファクタリングも当然行いますが、余計に開発速度が落ちています。 しかし開発速度は効率化とは無縁だとすら感じてい
2008年2月13日,ソフトウエア開発者向けイベント「Developers Summit 2008」(主催:翔泳社)が始まり,米Fog Creek SoftwareのCEOであるJoel Spolsky氏(写真1)がセッションに登壇した。Spolsky氏は,ソフトウエア開発についての諸問題を皮肉とユーモアたっぷりに論じた書籍およびブログ,「Joel on Software」で有名。セッションも著書と同じく皮肉とユーモアに満ちたものになった。 セッションのテーマは「素晴らしいソフトウェアを作るということ」。機能的に優れた製品を作っても,市場で優位に立てないというよくある現象を分析し,万人に愛されるソフトウエアを作る方法を探るという流れでセッションは進んだ。 セッションの冒頭でSpolsky氏は,いきなりサッカー選手David Beckhamとその同僚Landon Donovan(どちらもLo
今回のテーマは「開発環境」 様々なアプリケーションがWeb化している。メーラーは当たり前のように使われており、カレンダーやタスク管理、さらに画像編集といったアプリケーションまでWeb上で動作するようになっている。 今回は多岐にわたるWebアプリケーションの種類について、特に基本となり得るものを取り上げてみたい。それは全てのアプリケーションを生み出す元となる、開発環境だ。すでにいくつかのWebアプリケーション、オープンソース・ソフトウェア(OSS)が登場している。Webベースで行える利点を生かしたもの、ローカルアプリケーションに見劣りしない機能をもったものなど実に様々だ。開発者の方のみならず、見ると何か作ろうかと思わせる、そんなアプリケーションが目白押しだ。 今回紹介するOSS・Webアプリ 『Workspace』 Web OS風な開発環境 『TIDE』 ステップ実行も可能なJavaSc
プログラミング, 生活ちょっとワクワクしながらつらつらと書きます。 テレビ朝日のドキュメンタリで、11歳のゴールデンエイジのテニス少年たちを教える松岡修造氏*1の番組を見た。 彼はいつも「○○をできないと世界に通用しない」と臆面もなく「世界」という言葉をだす。あたりまえのものとしてその言葉を出している。「インターハイがどうのこうの」ではなく、「世界に通用するかどうか」ということを常に話している。 そして練習が終わったあとには子供に「なぜ君を選んだのか」を語る。「君には才能があるからだ」「センスがあるからだ」「センスがあるんだから、君はがんばるしかないんだ」「今日一日できみはものすごく成長した」と、教え子のやっていることが無意味ではない、ちょっとでも前に進んでいると一所懸命に語っていた。 この言葉を聞いた子供たちは、「世界」を「手の届かないもの」ではなくて、「届くかどうかは自分次第だ」と思う
http://www.martinfowler.com/bliki/FluentInterface.html 2005/12/20 数ヶ月前、Eric Evansと一緒にあるワークショップに参加した。 そこで彼がとあるインターフェースのスタイルについて語ったのだが、 我々はそれを「流れるようなインターフェース(fluent interface)」と名づけることにした。 一般的なスタイルではないが、もっと評価されるべき代物だ。 おそらく例を示したほうがいいだろうから、そうしてみることにする。 一番簡単な例は、EricのtimeAndMoneyライブラリだろう。 時間の間隔を作るには、通常は、以下のようにする。 TimePoint fiveOClock, sixOClock; ... TimeInterval meetingTime = new TimeInterval(fiveOClock,
A few months ago I attended a workshop with Eric Evans, and he talked about a certain style of interface which we decided to name a fluent interface. It's not a common style, but one we think should be better known. Probably the best way to describe it is by example. The simplest example is probably from Eric's timeAndMoney library. To make a time interval in the usual way we might see something l
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く