タグ

developmentに関するhiroakiunoのブックマーク (85)

  • 「レガシーコード改善ガイド」のススメ 第1回:レガシーコードの定義、テストの重要性とは

    「レガシーコード」とは何か 最初に1つ質問です。皆さんは、「レガシーコード」と聞いて何を想像するでしょうか? 多くの方はCOBOLなどで書かれたメインフレームで動くコードを真っ先に思い浮かべるのではないかと思います。しかし、当にそれだけでしょうか? ここでは「レガシーコード」という言葉を『何年も前に誰かが作り、内容が複雑で何をしているのかよく分からず、まともな仕様書もない』というコードを指すものとします。そう考えると、必ずしもメインフレームだけの話ではなくなります。この記事を読んでいる皆さんなら、そのようなコードを少なからず目にしていることでしょう。 現在の業務システムは、Java EEや.NETなどの基盤上に構築される、いわゆるオープンシステムが主流になっています。このようなオープンシステムであっても、構築されてから既に5年以上経過していることが珍しくなく、何度も手が加えられたコードは

    「レガシーコード改善ガイド」のススメ 第1回:レガシーコードの定義、テストの重要性とは
  • プログラマーが会議を嫌いな理由 | スラド デベロッパー

    家/.「Manager's Schedule vs. Maker's Schedule」にプログラマーとマネージャーのミーティングに対する認識の違いに関する面白い記事が紹介されている。 プログラマーでありベンチャーキャピタリストであり、エッセイストでもあるPaul Graham氏によるとプログラマーエンジニアは「もの作りの人のスケジュール」である「Maker's Schedule」、マネージャーは「管理する人のスケジュール」である「Manager's Schedule」という別々のスケジュールで働いているという。 「Manager's Schedule」では時間が1時間単位で区切られており、会議や人と合うスケジュールを組むには空いている時間枠をみつけてそこにアポイントメントを入れるだけで済む。何かのタスクのために数時間ブロックすることもあるが、会議などが入ればそれを分割したりずらしたり

  • 第1回 Hudsonの導入 | gihyo.jp

    継続的インテグレーションとは Hudsonの具体的な紹介に入る前に、まず簡単に「継続的インテグレーション」(⁠Continuous Integration、以下CI)のおさらいをしましょう。CIは、Extreme Programmingに端を発し、Martin Fowlerによって広められた概念で、狭義には、別々に開発された部品を持ち寄ってお互いの動作を検証する「統合テスト」を早い段階から恒常的に行うことを指します。この当初の概念には必ずしも統合テストの自動化という考え方は含まれていませんでしたが、最近では、CIは単に統合テストだけではなく、広くビルド及びテスト全般を恒常的に行うことを指すようになり、またこれを現実的な工数で実現するための必須の手段として、ビルド・テストの工程を極力自動化する、という事が重要なポイントの一つになってきました。 この考え方の背景の一つには、コンピュータの高性能

    第1回 Hudsonの導入 | gihyo.jp
  • エンジニアがタイトル買い、著者買いすべき本 - Fight the Future

    著者買いすべき! ファウラー、ジョエルは知名度もあり、改めて僕がどうこう紹介する必要はないと思うけど、ここではスティーブ・マコネルを特に推したい。 読んだ人には非常に高い評価を得ているけれど、その分厚さや価格もあってなかなか広まっていない。 特にCode Completeはすべてのエンジニアが必ず読むべきだと思ってる。 これを読んで理解する/しないが(職業プログラマとしての)初級と中級の境界だと言えるくらい。 タイトルにはCodeとあるけど、別にコーディングをターゲットにしたではない。 設計、テストも含めてコーディングを考えている。当たり前だがコーディングだけではコーディングはできないからだ。 上下巻1,200ページの大作だし、2冊で12,000円だがその価値は大いにある。 スティーブ・マコネル ソフトウェア見積り―人月の暗黙知を解き明かす 作者: スティーブマコネル,久手堅憲之,S

    エンジニアがタイトル買い、著者買いすべき本 - Fight the Future
  • 従来のソフトウェアエンジニア人事工学が決定的に間違っている点 : 404 Blog Not Found

    2009年02月06日05:30 カテゴリArt 従来のソフトウェアエンジニア人事工学が決定的に間違っている点 ここまでは、誰もが同意するだろう。 従来のソフトウェア工学が決定的に間違っている点 - kwatchの日記 仕事が高度になればなるほど、属人性は排除できないし、人材の替えはきかない。問題を解決できない人間を100人集めても、問題は解決できない。問題を解決できるのは、問題を解決できる能力を持った人間だけ。頭の悪い大人100人より、すごく頭のいい小学生1人のほうが、成果物が出る。ソフトウェア開発はそういう類いの仕事。 にも関わらず、 ソフトウェア開発も同じような体制にしたほうがいいのではないか。生産性が 30 倍違うのであれば、バカプログラマー 30 人を雇うより、スーパープログラマー 1 人にサポートスタッフ 5 人つけたほうが安くていいものができるだろう。 とならないのはなぜか。

    従来のソフトウェアエンジニア人事工学が決定的に間違っている点 : 404 Blog Not Found
    hiroakiuno
    hiroakiuno 2009/02/06
    >はじめからスーパーだったプログラマーなど滅多にいないし、スーパーな連中は自分が好きなことにかまけている。ソフトウェア産業の世界は広大で、今なお広がっている。あなたが入る余地はいくらでもあるはずだ。
  • アラン・ケイ - 「ソフトウェア工学」は矛盾語法か? [邦訳]

    アラン・ケイ Is “Software Engineering” an Oxymoron? By Alan Kay (訳注: 以下の文章は、http://d.hatena.ne.jp/sumim/20080806/p1 に紹介されていたアラン・ケイの文章 -- Is “Software Engineering” an Oxymoron? -- を訳したものです。原文もsumim さんのサイトからダウンロードしました。最初に書かれたのは 1999年から2000年ごろと少し古いので注意してください。日語で矛盾語法(oxymoron)とは聞き慣れない言葉ですが、ジーニアス英和大辞典によると an open secret (公然の秘密) や、living death (生き地獄) のような矛盾する二つの単語を組み合わせた熟語の事を言うらしいです。) 真のソフトウェア工学はまだ未来のものだ。一年と

    hiroakiuno
    hiroakiuno 2009/02/05
    エジプト的ソフトウェア開発手法と遅延結合という解決策
  • 実践オブジェクトモデリング

    入門編 はじめに Javaプログラミングのポイントはもちろんオブジェクト指向による適切なモデリングにあります。最近ではオブジェクトモデリングに関する参考書もかなり充実してきていますし、Javaプログラミングのも氾濫に近い状況になっています。それではJavaプログラミングのためのオブジェクトモデリングを行うために十分な情報が提供されているかというと必ずしもそうではないようです。オブジェクトモデリングとJavaプログラミングとの連続性という観点で勘所を押さえたものは、なかなかないのではないかと思うのです。そこで、記事では具体的なプログラミングを通してオブジェクト指向開発やオブジェクトモデリングとJavaプログラミングの接点といった、より実践的な情報について解説したいと思います。「入門編」ではユニファイドプロセスによるオブジェクト指向開発プロセスをベースに、オブジェクト指向開発のライフサイク

  • http://www.yourdonreport.com/2008/11/13/top-ten-software-engineering-concepts-v10/

    hiroakiuno
    hiroakiuno 2008/11/18
    ヨードン|Yourdon のプレゼン資料 > Technology is not the key issue
  • 宴会君の思い出 2008-10-22 - 未来のいつか/hyoshiokの日記

    YLUG (横浜Linux Users Group)ができたのが、1999年1月で、カーネル読書会の記念すべき第一回は同年4月28日だ。 http://www.ylug.jp/modules/pukiwiki/index.php?history 当時、宴会の参加登録受付はメーリングリストでやっていて、幹事が出した案内に参加したい人がリプライを出す、その時、自分の名前をリストの最後につけたす、という極めて素朴な方法というかアルゴリズムでやっていた。下記の例参照。 宴会のおしらせ 日時:吉日 場所:どっかの居酒屋 参加希望者は下記に自分の名前を書いてください。 1 よしおか(幹事) 2 linus 3 rms 4 ほげほげ 5 参加希望者は名前を付けくわえてください。まあ、参加者の10人とかぐらいだと、これはこれで全然かまわないのだけど、当時は常時接続とか定額(低額)のインターネット環境とかあ

    宴会君の思い出 2008-10-22 - 未来のいつか/hyoshiokの日記
    hiroakiuno
    hiroakiuno 2008/10/23
    3 じゃなくて 4
  • 第4回 Tracではじめるバグ管理入門

    「チケットは開発を救う」と考え,2007年のITpro Challenge!にてチケット駆動開発を提唱した。Tracを使う最大の利点はチケットとリポジトリ・ブラウザを連携できることだと考えている。 前回(第2回~第3回)までの連載で,Tracのインストールと基的な設定が終わりました。これからの連載では,Tracを上手に運用するためのコツをご紹介していきます。 Tracの主な機能には,Wikiとリポジトリブラウザ,それにチケットによるタスク管理システムがあります。Wikiとリポジトリブラウザは使っていても,チケットは使っていないという方は意外に多いのではないでしょうか。そこで第4回では,チケットの一番の用途である「バグ管理」について説明します。今回の説明には,Trac 0.11(日語版)が含まれるTrac Lightningのバージョン2.0.4を使用しますが,基的な考え方は以前のバー

    第4回 Tracではじめるバグ管理入門
  • さらに分かっておきたいトランジスタの種類 − @IT MONOist

    急速に進化するAI技術との融合により変わりつつあるスーパーコンピュータの現在地を、大学などの公的機関を中心とした最先端のシステムから探る連載。第1回は、2024年4月に稼働を開始した東京工業大学の「TSUBAME 4.0」を取り上げる。

    hiroakiuno
    hiroakiuno 2008/09/12
    >インドのソフトウェア開発会社が日本でセールスを展開する場合、殺し文句として使うのが「ウチは、CMMのレベル5の認定を受けています」でしょう
  • はてなブックマークの関連エントリー機能開発、PFI さんとの合宿 - naoyaのはてなダイアリー

    はてなブックマークに関連エントリーを配信する機能を追加しました。詳しくは 告知日記で。 この関連エントリーは、株式会社プリファードインフラストラクチャー (以下 PFI) の技術者のみなさんと一緒に開発しました。週末に2泊3日で京都で合宿をしてコア部分を作り、その後京都と東京に分かれてオンラインで連絡を取りながら2週間ほど作り込みをして、今日リリースです。 この合宿では何チームかに分かれて、今回の関連エントリーの機能以外の開発も行っています。その辺の成果はまた後日にリリースできるのではないかと思います。 はてなブックマークの一つの問題として、昔のエントリーがデータベースに埋もれてしまうという点がありました。その問題の解決策としての類似記事抽出、それから検索機能の強化を以前から考えていました。PFI のメンバーのみなさんは情報検索技術のスペシャリストです。アカデミックな研究の成果を製品化を通

    はてなブックマークの関連エントリー機能開発、PFI さんとの合宿 - naoyaのはてなダイアリー
    hiroakiuno
    hiroakiuno 2008/07/15
    >よくできたチームはコミュニケーションがコストにならずに生産性を加速させること
  • グーグル エンジニアのまじめな日常 ― @IT

    グーグルがどのようにソフトウェア開発を行っているかは、これまであまり詳細が明らかにされてこなかった。だがグーグルは6月10日、開発者向けイベント「Google Developer Day 2008 Japan」を開催し、グーグルのソフトウェアエンジニアグーグルでの仕事術を語る「Google ソフトウェアエンジニアの日常」という講演会を実施した。スピーカーは、NECITエンジニアとして勤務した経験がある藤島勇造氏。2006年からグーグルのソフトウェアエンジニアとして働いている。藤島氏は、グーグルでのソフトウェア開発方法について、グーグルのカルチャーと自身の見解を織り交ぜて語った。 グーグル ソフトウェアエンジニアの1日の流れ 藤島氏の1日は、朝10時ごろ出社し、メールをチェックすることから始まる。この時間にメールを見る理由は、米国にいる同僚に連絡が付きやすい時間帯だからだ。 午前中の主な

    グーグル エンジニアのまじめな日常 ― @IT
  • Yahoo!がまとめた「コミュニティにユーザーを参加させる方法」が興味深い件 | IDEA*IDEA

    ドットインストール代表のライフハックブログ

  • 404 Blog Not Found:(6000)人が作ったシステムは必ずどこか壊れている

    2008年05月13日17:30 カテゴリMediaArt (6000)人が作ったシステムは必ずどこか壊れている こう言い切ったら、 6000人が作ったシステムは必ず動く:ITpro 最盛期の開発要員6000人,開発工数11万人月,投資額2500億円,取引件数1日1億件。三菱東京UFJ銀行が「Day2」と呼ぶ,勘定系システム一プロジェクトの成果物である。6000人のシステムズエンジニア(SE)が作り上げた巨大システムは,2008年5月の連休明けに必ず動くはずだ。 案の定 不具合の原因は「カタカナでなく漢字だったから」??三菱東京UFJのシステム障害 - ITmedia エンタープライズ 三菱東京UFJ銀行のキャッシュカードがセブン銀行のATMで使えなくなるシステム障害が5月12日に発生した。三菱東京UFJ銀行によると原因は「カタカナで転送すべきデータを漢字で処理していたから」であった。

    404 Blog Not Found:(6000)人が作ったシステムは必ずどこか壊れている
  • Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)

    『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直

    hiroakiuno
    hiroakiuno 2008/05/07
    TDD はテストというよりは設計だという考え方が BDD
  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
    hiroakiuno
    hiroakiuno 2008/05/07
    ビヘイビア駆動開発/振舞駆動開発 (Behaviour Driven Development:BDD)
  • 第1回 Tracをオススメする,これだけの理由:ITpro

    Tracの便利さに惹かれるが,インストールに煩わしさを感じ,Tracを簡単にインストールできるTrac Lightning(旧Trac月)の開発を行う。また,日のTracコミュニティであるShibuya.tracにてユーザー補完プラグインなどのプラグイン開発にも携わる。 チーム内のタスクや分散開発におけるタスク管理の手段として,プロジェクト管理ツールのTracが注目を集めています。Tracは,Ruby on RailsやSpring IDEなどでも利用されています。連載では,開発現場を交通整理するために,Tracを利用したプロジェクト管理の効率化を,Tracの基礎から紹介していきます。 ソフトウエア開発において,プロジェクト管理はガントチャート・ベースで行われることが多いでしょう。しかし,ガントチャート・ベースの管理では,詳細を報告するために作業報告書を別途作成する必要があります。 ま

    第1回 Tracをオススメする,これだけの理由:ITpro
  • 「作っては壊す」過程があってこそ良いものが作れる

    iPhone用の「はてな人気エントリーリーダー」、そろそろ形になってきたのだが、作ってみていろいろと発見した部分もあったので、全面的にクラス構成を見直し、大幅に書き直した。 HTTPで通信をしているコードが二カ所に分かれていたので、それをDataOverHTTP/XMLOverHTTPという二つのクラスにまとめ(XMLOverHTTPはDataOverHTTPのサブクラス)、はてな独自のRSSフィードを読んでいるコードから一般的なRSSフィードを扱うコードをくくりだしてRSSFeed/RSSFeedLoaderという二つのクラスにまとめて、あとで別のアプリケーションで再利用することを可能にした。それに加えて、各種ローダーに非同期通信をさせる主体をController(HotEntryViewController)からModel側(HateneHotEntry)に移すことにより、難解になりが

  • あるSEのつぶやき: フリーで使えるプロジェクト管理ツールまとめ

    フリーで使えるプロジェクト管理ツールをまとめておきます。 ■ガントチャート 開発マイルストーン ガントチャートプロジェクト管理できるExcelツール フリーとは思えないほど高機能 ガントチャートforExcel・・・シェアウェアになりました こちらもガントチャートプロジェクト管理できるExcelツール スケジュールの表示期間を切り替えられるのが便利 OpenProj Java ベースでガントチャートプロジェクト管理ができるツール Microsoft Project のフリーのビューワーとしても利用可能 フリーの高機能プロジェクト管理ソフト「OpenProj」を試してみました TaskLine Excelのアドインとして動作するプロジェクト管理ツール(saramiさん情報) Microsoft Projectのファイル(XML形式)をExcelで表示するProjectViewerもある