システム投資のパターン～SI案件以外のビジネスモデルは何があるのか - プログラマの思索
システム投資のパターンをまとめてみた。 自分が業務システムを購入する立場ならば、高価で使いにくいし、中身がブラックボックスなので、購入には躊躇するだろうと思う。 ラフなメモ書き。 【0】業務システムの投資には、3つのパターンがあるように思う。 「ユーザ企業の資産」「ユーザ企業のリース資産」「ユーザ企業の利用料支払い」の3パターンについて、以下に考えを書いてみる。 【1】ユーザ企業の資産：普通のSI開発 【1－1】発注元はSIにシステム開発を委託し、SIが受託開発していくパターン。 通常の受託開発案件であり、一番事例が多いだろう。 納品されたシステムは、運用後に数年かけて減価償却される。 発注元(ユーザ)：資産、受託先(SI)：売上として計上される。 SIから見れば、受託開発のプロジェクトさえ黒字で完了できれば、運用保守費用で毎月売上が計上されるので、安定的な収入源になる。 だから、SIの受
「挫折しないRedmine」の資料が分かりやすい - プログラマの思索
僕が使い始めた2008年頃と違って、現在はかなりRedmineが普及している。 ソフトウェア開発者だけでなく、製造業や製薬業、営業や事務、勉強会のタスク管理に使っている事例も多い。 最近特に目立つのが、初心者がRedmineを使っているものの、Redmineの良さを出し切れていない場面。 上記の資料では、「Redmineは、チームでチケットを消すゲーム」と定義して、わかり易く説明しているのがすごくいい。 アジャイル開発では、XPの計画ゲーム、Scrumのプロダクトバックログのように、ストーリーやタスクをチケット化して、イテレーション(Redmineならバージョン)単位にグループ化して、リリースしていく戦略を取る。 すると、チケット管理とは、チームでチケットを消すゲームなのだ、と感覚で分かるようになる。 この辺りの感覚は、40代以上の中年SEよりも、20代の若手PGの方がすぐに馴染んでくれる
メールからRedmineのチケットを自動登録する時の注意点 - プログラマの思索
メールからRedmineのチケットを自動登録する時の注意点をメモ書き。 【1】第8回RxTStudy勉強会で、@g_maedaさんは、顧客からの問合せメールをRedmineのチケットに自動登録する機能によって、ヘルプデスク管理をチケット管理に置き換える事例を紹介している。 第8回勉強会の感想～RedmineはCRMや情報系システムにも適用できる #RxTStudy: プログラマの思索 メール対応に付随する苦労の多いヘルプデスク管理をRedmineのチケット管理に置き換えたことによって、チケット管理の恩恵が得られる利点を強調されていた。 その反面、下記の課題がまだ残っていると話されていた。 (1)返信時のSubjectのチケットNoが間違っている場合、別チケットのコメントに追加されてしまう。 (2)メールソフトとRedmineを行ったり来たりして面倒。 メール対応という一つの目的で2つのツー
ERPの落とし穴part5～コード設計の難しさ - プログラマの思索
業務システム開発で、マスタテーブルを新規に作る場合、コード設計を事前に深く考慮する必要がある。 考えたこと、経験したことをラフなメモ書き。 【元ネタ】 Hot Heart, Cool Mind.: コード設計の話 データベースエンジニアへの道（4）：システムの寿命はコードで決まる！ (1/3) - ＠IT データベースエンジニアへの道（4）：システムの寿命はコードで決まる！ (2/3) - ＠IT データベースエンジニアへの道（4）：システムの寿命はコードで決まる！ (3/3) - ＠IT うぃっとWorks: 有意コードと無意コード ゼロからのデータモデリング入門（10）：ビジネスの変化に強いデータモデルを作る (1/3) - ＠IT ゼロからのデータモデリング入門（10）：ビジネスの変化に強いデータモデルを作る (2/3) - ＠IT ゼロからのデータモデリング入門（10）：ビジネスの
Springフレームワークをバッチ処理やHadoopにも適用する - プログラマの思索
最近、JavaのSpringフレームワークが熱いと思っている。 ラフなメモ書き。 【元ネタ】 Spring Framework | TECHSCORE(テックスコア) Eclipseを使ったJava開発入門/フレームワーク/ライブラリ/Spring/DIでHelloWorld | DI wdsdx.com 今必要な人のための速習 Spring Framework - 今必要な人のための速習Spring Framework---目次：ITpro Spring3入門―Javaフレームワーク・より良い設計とアーキテクチャ：書籍案内｜技術評論社 VMware が Spring Hadoop を発表 Hadoop開発を容易にする「Spring for Hadoop 1.0」が登場 - SourceForge.JP Magazine : オープンソースの話題満載 【ハウツー】概説 Springプロダク
GitHubによるソーシャルコーディングが法律や出版物を変革させる可能性 - プログラマの思索
デブサミ2013で最も感銘をうけたのは、GitHubによるソーシャルコーディングがとてつもなく大きな可能性を秘めていることに気づいたこと。 考えたことをラフなメモ書き。 【参考】 Twitter / iR3:ほ? アイスランドでは皆で憲法を書こうという取り組みがあるのか。大規模で、民主的な取り組み。オープンソースのしくみが政治を変えるというのは現実の流れとして動いているのね。 Twitter / tiny_mina: 昨日撮ったNHKのTED番組「スーパープレゼンテーション」を見た。Githubを使った立法ができれば、日本は官僚政治から脱却できるんだな。でもいったい何百年後だろう。アイスランドはすでに議員がこんな動きを始めてるらしい。 Twitter / iR3: しかしソフト開発には今ふたつの踏み絵があるな。ひとつはGit ふたつめはGithub まだまだGit以前のところが沢山存在する
最初から完璧な開発環境を作ろうとする時の罠 - プログラマの思索
良い記事があったのでメモ。 自らも肝に銘じておく。 未知の領域で開発を始める時には、環境を整えすぎてはいけない - 愛と勇気と缶ビール (引用開始) 未知の領域って何ぞいな、というとだいたい以下の二つ。 ・開発経験のないプラットフォーム。場合によっては触ったことのない言語を含む。(e.g. iOS, Android) ・今まで触ったことのない言語を用いた開発。 世の中にはエディタ・IDEからCIまで沢山の開発を支援するためのツール・枠組みがあるが、新しい領域に挑戦する時にはこれらの開発環境をあまり整えすぎない方がいい気がしている。 というのは、最初から「エディタも完璧に設定して、テストも全部書いて、JenkinsでCIするようにして、デプロイの前にビルドが走るようにして…」というようなセットアップを全部やろうとしてしまうと、それ自体に時間がかかって、それだけである程度満足してしまうから。単
アーキテクチャ設計のアンチパターン集～44のアンチパターンに学ぶDBシステム - プログラマの思索
「44のアンチパターンに学ぶDBシステム」を読んでみて、とても優れたアーキテクチャ設計のアンチパターン集に思えた。 過去の経験上、あるあると思う箇所がたくさんあった。 感想をラフなメモ書き。 【元ネタ】 44のアンチパターンに学ぶDBシステム - give IT a try あなたの現場にも必ずあるDBシステムの"悪い例"が満載！「44のアンチパターンに学ぶ DBシステム」 | oracletech.jp 『44のアンチパターンに学ぶDBシステム』 - 虎塚 44のアンチパターンに学ぶDBシステム : 賢者の図書館 (Under Construction) : livedoor Blog（ブログ） 【本】SQLをしっかり学習したい人におすすめミック本。 | ﾌﾟﾗﾌﾟﾗ式技術系 Access流! 【本まとめ】44のアンチパターンに学ぶシステム構築時の失敗パターン。もっとはやく言ってよーとな
RedmineでSubversion リポジトリ表示を高速化する方法 - プログラマの思索
RedmineでSubversion リポジトリ表示を高速化する方法について、丸山さんが回答されていたのでメモ。 【元ネタ】 Subversion リポジトリ表示に時間がかかる - Google グループ 小技(0.9): コミットと同時にリポジトリの情報を取得する | Redmine.JP Blog バージョン管理システムとの連携 | Redmine.JP メーリングリストで以下の問題を提起されている。 (引用開始) 実プロジェクトで問題が起きたので、相談させてください。 ・環境 Redmine 1.3.3 / Ruby 1.8.7 ・設定 管理→設定画面のリポジトリタグで「コミットを自動取得する」はOffになっています ・症状 Subversionのリポジトリを表示させると、時間がかかる →270程度のリビジョンを含むリポジトリで、およそ6秒かかる(100 ms程度の誤差で再現性あり、
astahの品質スイートプラグインとSVNプラグインが凄い - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Pandocでテキストファイルからドキュメント生成 - プログラマの思索
以前から、テキストファイルからWord、PDF、epub出力するツールを探していた。 Haskellで作られたツールPandocでようやく意図できたものが出力できたのでメモ。 【元ネタ】 『ソフトウェアの基礎』のePub版を公開しました。 - みずぴー日記 Pandocのリンク: プログラマの思索 Pandoc - Demos 【インストール】 Windowsでは、ワンクリックインストーラーを使えば、HaskellのGHCを入れなくてもツールを導入できる。 Pandoc - Installing pandoc --help で認識すればOK。 Rubyのgem、Pythonのeasy_installに相当するHaskellのライブラリインストールコマンドcabalをインストールするのは面倒だったから。 【epub, word出力方法】 Pandoc - Creating an ebook
Redmineの初心者向け資料 - プログラマの思索
(引用開始) はじめてRedmineに触れる方向けに、Redmineとは何か、Redmineを使うと何が便利になるのかを紹介するスライドです。 (引用終了) ソフトウェア開発者以外の人にRedmineを使ってもらおうとする場合、IT技術者の立場を押し通すと多分使ってくれないだろう。 普通の人がイメージするタスク管理は、RememberTheMilkやGmail ToDoのイメージであり、Redmineは入力項目が多すぎるし、たくさんの機能があって理解しにくいようだ。 Redmineによるチケット駆動開発が障害管理ツールから発展した歴史を考えると、チケットは本来は障害報告票ゆえに、どうしても入力項目は多くなる。 でも、きちんとチケットに作業内容を記録してもらえれば、強力かつ多種多様なチケット集計機能によって、色んな観点でタスクの進捗状況を分析することができる。 特に、アジャイル開発で出てくる
定量的プロジェクト管理ツールはIT企業の基幹システムを目指す - プログラマの思索
IPAが出版していると思われる雑誌にチケット駆動開発の記事を見つけたのでメモ。 【元ネタ】 SEC journal_No28 IPAの定量的プロジェクト管理ツール #redmine: プログラマの思索 Redmineを業務システム化するアイデア～メトリクス集計の本質は集計バッチ処理: プログラマの思索 「定量的プロジェクト管理ツール(IPF)の紹介」の記事で、IPAが作った定量的プロジェクト管理ツールがどのような目的で作られて、どの範囲を適用しようとしているのか、を解説している。 その記事の中で、このツールがRedmineやTracを元ネタとして、プロジェクトの状況を各種のメトリクスで出力する時に、チケット駆動開発のアイデアを適用していると書かれている。 本来、チケット駆動開発は軽量なプロセスであり、チケットをタスクカードとして扱うという簡単な発想から発展してきた。 だが、このアイデアを突
SVNバックアップの復習 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
ドメイン駆動設計は設計のアジャイル化～オブジェクト指向設計の先祖返り - プログラマの思索
エリック・エヴァンスのドメイン駆動設計の本を一通り読んでみて、何かすっきりしない感想を持っていた。 @sakaba37さんや@jp_watanabeさんと議論して、すっきりしない原因がようやく分かったのでメモ。 ラフなメモ書き。 【元ネタ】 ドメイン駆動設計: プログラマの思索 ドメイン駆動設計よりもパターン本が好き: プログラマの思索 ドメイン駆動設計はソフトウェアプロダクトラインとオブジェクト指向分析のミッシングリング: プログラマの思索 DOAとOOAの違い: プログラマの思索 Agile開発に足りないもの～モデリング技術: プログラマの思索 ドメイン駆動設計の本の違和感は二つある。 一つは、分析と設計を区別せず、設計中心の技法ばかり説明していること。 もう一つは、過去のオブジェクト指向設計との違いがはっきり理解できていなかったこと。 前者は、「ドメイン駆動設計」というタイトル通り「
ドメイン駆動設計の感想～OOAは過ぎ去りDOAはもう一度舞台に上がるのか - プログラマの思索
【1】増田さんによるドメイン駆動設計の話は、「エリック・エヴァンスのドメイン駆動設計」の本の目次に従って説明してくれたので、とても分かりやすかった。 OOAに関しては「実践UML」「アナリシスパターン」「ストリームラインオブジェクトモデリング―パターンとビジネスルールによるUML」などを2000年代前半に勉強会で読みこなしていたから、ドメイン駆動設計では、オブジェクト指向設計をどのように生かしているのか、が理解できたからかもしれない。 増田さんの職歴を聞いた所、OracleのデベロッパーからJavaなどのオブジェクト指向設計へ転向したとのことなので、DOAの良さもOOAの良さもよく理解されているのだろう。 また、ドメイン駆動設計だけでなく、ICONIXやSpringによる実装も組み合わせたオブジェクト指向設計なので、要件定義から外部設計、実装に至るまでの経験が豊富なことは感じられた。 【2
次世代Webフレームワークの設計思想～RESTful Webサービス - プログラマの思索
「RESTful Webサービス」本を買ってみた。 まだ読んでないけれど、この本を買った動機を振り返ってみる。 【1】Webフレームワークの歴史とその限界 Webアプリは最初はオモチャみたいなものだった。 普通は、掲示板のようなアプリをPerlでCGIを書いて作っていただろう。 そして次第に、ViewからControllerを分離する設計をするようになった。 Javaの場合、JSP＋Servletという仕組み。 だが、システムが巨大化していくうちに、Webフレームワークが必要とされるようになってきた。 そのWebフレームワークの基本思想として、MVC2モデルが叫ばれるようになった。 MVC2モデルは、GUIアプリのMVCモデルのWeb版といっていい。 この思想によって、大概のWebフレームワークは、MVC2モデルを標榜するようになった。 そして、Javaはこの思想を突き詰めて、Model部
SOAPからRESTへ - プログラマの思索
InfoQの記事「InfoQ: SOAP から REST へ - その方法と意義」が良かったのでメモ。 【元ネタ】 InfoQ: SOAP から REST へ - その方法と意義 次世代Webフレームワークの設計思想～RESTful Webサービス: プログラマの思索 REST思想とHTTPメソッドの関係: プログラマの思索 Ruby on Rails + Curl リッチクライアントCRUDアプリを作成する（1/5）：CodeZine RedmineのRESTful APIを使う: プログラマの思索 SOA(サービス指向アーキテクチャ)はバズワードだ。 SOAこそが今後の設計の将来だ、と言われた時期があったけれど、結局使いづらかったのではないか。 SOAを支えるエンタープライズ系技術としてSOAP、WSDLなどが声高に叫ばれたが、結局廃れてしまったか、傍流の技術になってしまったように思う
git-flow による構成管理とRedmineの関係 - プログラマの思索
「git-flow によるブランチ管理」という記事で、分散バージョン管理ツールを使った構成管理手法をとても分かりやすく書かれていた。 以前僕が書いた記事を見直して、理解が足りなかった部分があったと感じたので、もう一度まとめてみた。 【元ネタ】 git-flow によるブランチの管理 - O'Reilly Japan Community Blog A successful Git branching model を補助する git-flow を使ってみた - Twisted Mind 見えないチカラ: A successful Git branching model を翻訳しました A successful Git branching model: プログラマの思索 Mercurialで独立並行リリース管理: プログラマの思索 Mercurialによるチケット駆動開発は強力だ！: プログラマ
プログラマの思索: 日本のパッケージベンダーが駄目な理由
ひがさんのBlogを読んで、日本のパッケージベンダーが駄目な理由が垣間見えた気がした。 スルガ銀行のIBM提訴にみるパッケージビジネスの難しさ SIerが自動車産業をまねしようとするのはいい加減やめなさい 日本のパッケージベンダーが駄目な理由は2つある。 一つは、パッケージそのものが変化に対応しきれないこと。 もう一つは、分業化しすぎて技術力そのものが劣化していること。 金融系の勘定系システムは、大手SIベンダーのメインフレーム上のパッケージ製品が多い。 だが、それは余りにも大きすぎて、誰も仕様も技術も全部は分からない。 パラメータTblに顧客ごとの値を設定してカスタマイズすれば、すぐにできると宣伝するが、実際は、顧客の要求に合わせていくうちに、元々のパッケージと似て似つかぬシステムになる。 品質も保守性もボロボロになるのがいつものパターン。 ソフトウェアプロダクトラインの発想が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
