「入門 機械学習」を献本していただきました - EchizenBlog-Zwei
「入門機械学習」を献本していただきました。ありがとうございました。 というわけで早速読み終わったので感想を書いておく。 機械学習の入門書ではない 本書はタイトルから連想されるような機械学習に入門するような内容は書かれていない。一切数式は登場せずアルゴリズムはすべてブラックボックス化されている。では本書はダメな本なのかというとそんなことは全くない。少なくとも「入門 機械学習」というタイトルに興味をもって本書を手にとった人にとっては大変有益な本だと思う。 大きなデータを扱って何かしたい人が最初に読むべき本 繰り返すが本書は機械学習の仕組みについては書いていない。仕組みはブラックボックスとして割り切ることで従来の機械学習の入門書が触れていない部分を非常に大きく扱っている。それは何かというと「汚いデータからどうやって機械学習の入力データを作るか」「機械学習の手法をどのように選択するか」「機械学習に
Objective-Cを書く人も書かない人も必読『iPhoneアプリ設計の極意』 - ninjinkun's diary
@fladdictさんが監訳されたことで話題の、オライリー本『iPhoneアプリ設計の極意 ―思わずタップしたくなるアプリのデザイン』、早速会社で購入してもらって読みました。読み終わってまず思ったのは、これはiPhone開発に携わるすべての人に必読の本になるだろうということです。エンジニア、デザイナー、企画者と分担が分かれている場合は、全員が読むといいのではないでしょうか。この本はiPhone開発に必要な共通言語を提供してくれます。それも、コードを使わずに。 本書から得られる内容としては大きくふたつあると思います。ひとつはiPhone開発のプロセスを解説書としての側面。もうひとつはiPhoneのUIカタログとしての側面です。 アプリ開発プロセスの解説書 この本に書かれている開発プロセスは、ベストプラクティスと言えるものになっていると思います。ユーザーニーズを探ること、シンプルさを追求するこ
Webプログラミング素人が利用者9万人のmixiアプリを作るまで - 毒蛇は急がない
はじめに 最近、 文系ド素人がmixiアプリを開発〜リリースするまでのまとめ http://d.hatena.ne.jp/kazu0620/20100412/1271071223 というエントリーが話題になりましたね。自分もwebプログラミング素人でmixiアプリを作ってみたので、ちょっと便乗して、自分がmixiアプリを作るまでのプロセスをまとめてみました。 これからアプリを作る人の参考になれば幸いです。 kazu0620さんは、個人で作っていたみたいですが、自分は会社で作りました。会社といっても、自分含め従業員数3人の超零細企業でフリーランスの延長線上みたいなかたちでやっている会社ですが。 ちなみに会社のサイトはこちら。 作ったアプリ 「ふしぎな生き物 ふにゃもらけ」 http://mixi.jp/run_appli.pl?id=9443 リリース日：3/23 実質開発期間：8ヶ月 週間
パッケージから学ぶ4大分野の業務知識 - プログラマの思索
ERPを勉強するために「パッケージから学ぶ4大分野の業務知識 (開発の現場セレクション)」を読んでみた。 感想をメモ。 【1】業務の裏に会計あり～ERPは会計帳票を出力するためにある いわゆる基幹システムと呼ばれる大規模業務システムは、日々の業務データは最終的には会計システムへデータが送られる。 販売、製造、経費精算などの業務は、仕訳データを日次または月次でバッチ処理で作り、夜間バッチで会計システムへ送る。そして、月次ないし四半期次で会計帳票を出力する。 だから、業務システムをマスターするなら最終的には簿記の知識が必要になる。 業務が発生したら、必ず取引として記録されて、仕訳が発生し、それらは損益決算書や貸借対照表などの会計帳票の元ネタになる。 「パッケージから学ぶ4大分野の業務知識 (開発の現場セレクション)」にあるフォースの教えには、「業務の裏に会計あり」というフォースとしてまとめられ
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
システム開発ジャーナル Vol.12が25日発売 - 特集は「開発ツール連携」 - たけぞう瀕死ブログ
毎日コミュニケーションズのシステム開発ジャーナル Vol.12で開発ツールに関する特集記事を書かせていただきました。 この特集記事で紹介している開発ツールは以下の通りです。 Eclipse Subversion Maven Trac Hudson Git 上記のツールそれぞれについて基本的な利用方法から各ツールの連携方法までを約60ページに渡って解説しています。特にこれらのツールをはじめて使う方や、使い始めて日が浅いという方にオススメできる内容になっていると思います。 表紙には「保存版」と銘打たれていますが、Eclipseのキーボードショートカット一覧や、Gitのコマンド、TracのWiki記法などリファレンス的に使える情報も意図的に入れてありますので、実際にこれらのツールを使う際に手元に置いてご活用いただければと思います。 それにしても60ページというのは相当な分量で、見本誌をいただいて
ソフトウェアアーキテクトが知るべき97のこと:Kenn's Clairvoyance
表題のコラム集が出版されました。 ソフトウェアアーキテクトが知るべき97のこと 海外のソフトウェアアーキテクト97人が書いたエッセイ集 "97 Things Every Software Architect Should Know" の邦訳版ですが、それに加えて日本人のアーキテクト11人によるコラムも追加されています。監訳者の鈴木雄介さんからお誘いいただいて、私も一篇寄稿させていただきました。「受動的アーキテクトと能動的アーキテクト」という表題で、冒頭部分を以下に引用します。 アーキテクトには2種類います。一方は、お客様からビジネスの要件をいただいてシステムを構築する「受動的」アーキテクト。もう一方は、自分たちでビジネスを立ち上げて収益を上げるためのシステムを構築する「能動的」アーキテクト。こうしたビジネス上のポジションの違いはアーキテクトが様々な意志決定をする上での色眼鏡になっているでし
男児たるものGoogle App Engine実践クラウドシステム構築を買うべきだ - ひがやすを技術ブログ
なぜなら、Google App Engineを学ぶために一番必要なのは、「何ができないかを知ること」だからだ。そして、この本にはそれが書いてある。それしか書いていないといってもいい。 App Engineは、Googleのインフラを最も効率よく使うことにフォーカスしている。Genericなアプローチではなく、Specializedなアプローチだ。 何かを得ようとするならば、それと等価の何かを支払わなければいけない。App Engineは、Googleのインフラを最も効率よく使うために、「いくつかのAPIが使えない」という対価を支払った。 だからこそ、App Engineを知るためには、最初に何ができないのかを知らなければいけないのだ。 あなたは、その制限という対価と引き換えに、Googleから安価なスケールするプラットフォームを手に入れることができる。 EC2はGenericなアプローチだ
DOAはRailsの銀の弾丸か - 書評:エンタープライズRails - ひがやすを技術ブログ
Railsは、最初に素早く動くもの(scaffoldなど)を作って、そこからフィードバックをもらい、少しずつ動く状態を保ちながら、改良していくスタイルです。 スモールスタートを切るには最も向いているスタイルです。しかし、最初はそれで良かったものの、プロジェクトへの要求が増えるにしたがって、コードは複雑になっていき、だんだんメンテするのが大変になってきます。 これはRailsの問題ではなく、システムのアーキテクチャの問題です。 システムでやらなければならないことがたくさん増えたときでも、急にコードが複雑になることなく、きちんとメンテナンスし続ける方法があるなら、誰でも学んでみたいと思うでしょう。 その方法を教えてくれるのが、エンタープライズRailsなのです。 エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術 作者: Dan Chak,高井直人,笹井崇司出版社/
続・書評『アジャイルな見積りと計画づくり』 - Be Happyman!!
先日の書評ではもの足りない気がしたので、もう少し書いちゃいます。 アジャイルのチャンスとTo-Beの前にある壁 私も厳しい状況を肌身で感じていますが、不景気は中小ソフトハウスのチャンスになりうるとも感じています。 小さい企業は間接費が小さい分もともと低コストです。そして、さらに短納期を実現する仕組みを持つことによって、今までは喰い込めなかったお客様に食い込めるチャンスが生まれます。 そのための武器にアジャイルを。って話はTo-Beの形としてはよく語られますが、アジャイル（アジャイルプロセス）それ自体はお客様の嬉しさに直接訴求しにくく、ここに大きな壁があります。ブレークスルーするためには、既存のお客様の既存のやり方や仕組みとしばらく付き合っていく必要はあります。 As-Isに横たわる大きな課題 現在の中小ソフトハウスの主戦場では、 一括契約 機能ベースの事前コミットメント 指定される開発プロ
capsctrldays - 現場リーダー本を語る会
1 現場リーダー本を語る会 機会があって参加させていただきました。お誘いくださってありがとうございます。某社SD事業部の働きを垣間見ることができました。 この本は本当にスゴくって、 今日のお昼に読み返したんですが、 議事録テンプレート 3Pフレームワーク キャラクタマップ なんかは何度読んでもイイ。まだ初版が買えるなんて信じられん。 大事なことがありすぎてちょっと読みにくい感じもするんですが、 ちゃんと読むと本当にいいことが書いてあります。 正直、自分は「リーダーって何なの？」って思ってるわけですが、 それでも得られるものがあるんです。 今日新しく得たこと 魔法の瞬間はない ふりかえりは自分を解放する時 タスクの終了条件を明確にする（期限はイテレーション終了時までなので明白） プロジェクト・ナラティブ（リーダーが期待することをメンバーに伝える） 二丁野帳
ついに永和の秘密を公開 - 受託開発の極意 - ひがやすを技術ブログ
出版社より献本御礼。 永和システムマネージメントといえば、平鍋さんのプロジェクトファシリテーションや角谷さんのRubyへの愛で有名だ。しかし、その内部で、プロジェクトが実際にどうやって行なわれているのかは、神秘のベールに隠されている。 本書は、そんな永和さんの秘密を包み隠さず教えてくれる。ソーシャルブックマークをお使いの方は、[これはすごい]タグのご準備を。 受託開発の極意―変化はあなたから始まる。現場から学ぶ実践手法 (WEB+DB PRESS plusシリーズ) 作者: 岡島幸男,四六出版社/メーカー: 技術評論社発売日: 2008/04/08メディア: 単行本（ソフトカバー）購入: 25人 クリック: 1,381回この商品を含むブログ (91件) を見る大手SIerに丸投げされて苦しんでいるあなた。3章の「丸投げされても前進する」「丸投げドキュメントの読み方」は、バイブルになるだろう
2008-01-07
１年も前に書かれたエントリを今更ながら見つけたよ。 ゼネコン系SIerに身を置く者としては華麗にスルーできないネタではあるな。 これはこれで「そんじゃ委託で」って事になりそうだが，一時請負元と顧客は割を食らうんだろな。 MercurialってGlassfishで話題になった程度でしか知らんのだが，分散リポジトリって実際どうなの？ 実のところSubversionにこれという不満も無いんだけど，こうゆう記事読むとちょっと食指が動いてしまうのう。 Mercurial の利用 ここのシステム構成例をみると，ちょっとうらやましくなる。 一応，IDEAのプラグインもあるっぽい。 TSS.comより。ExcelやWordをオーバレイにできる帳票ソリューションみたい（むろん商用）。出力フォーマットにPDFやRTFの他にWordML，SpreadsheetMLやXLSも指定できるらしくステキ度数UPだ。 「
ITにおける品質と効率とは (arclamp.jp アークランプ)
先ほどのエントリを最後にしようと思っていたのですが、トヨタ信奉への違和感へのnakagomeさんからのコメントが秀逸だったので。 自動車産業の製造というのは、金型作った後にやることで、何千、何万という製品を、殆ど機械的に複製することを指す。これは、ソフトウェア産業でいえば、コンパイルやビルド、または媒体コピーなどに相当するものだ。 しかし、ソフトウェア産業で製造と呼ばれるのは一般に、原始コードを書いたりすることなどを指している。自動車産業でいえば、むしろ金型を作るまでの部分に似ている。デザインの延長であって、知的で創作的で、かつ技芸的な要素の色濃い作業なのだ。 これを行灯で何とかしようとすることをナンセンス以外になんと形容できようか。 この問いかけは真剣に考えるべきことです。確かに製造業における品質向上や効率化は確実に先を行っていますし、積み重ねられてきた実績も大きい。でも、それがITにお
ソフトウェア開発のチームビルディング - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
capsctrldays - 『アジャイルレトロスペクティブズ』――ふりかえり本が出ますよ
1 『アジャイルレトロスペクティブズ』――ふりかえり本が出ますよ 私が翻訳しました『アジャイルレトロスペクティブズ』（オーム社）という書籍が9/26（水）に発売されます（オーム社!!オーム社!!）。 本書はPragmatic Bookshelfの『Agile Retrospectives - Making Good Teams Great』の全訳で、日本でいう「ふりかえり」にフォーカスした奇特な1冊です。 ふりかえりというと、日本では「KPT」が取り上げられることが多いですが、実はそれ以外にもふりかえりのプラクティスは存在します。 本書では、ふりかえりを5つのフェーズに分け、それぞれのフェーズで使用可能なプラクティスをカタログ的に紹介しています。いずれも30分程度の簡単なプラクティスです。ふりかえりをまだ導入されていない方、もっとふりかえりをうまくやりたい方、KPTに飽きた方ｗ、は是非ご一
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
