ソフトウェア設計ツール、UMLモデリングツール astah*のチュートリアルです。
■1 大事なほうのUML Unified Modifying Language。統一変更言語、とでも訳せばよいかしら。標準ツールはdiffとpatch。チーム開発では主に、cvsやsvnのようなSCM(ソフトウェア構成管理? ソースコード管理?)ツールと組み合わせて使われる。 もうすぐSI系企業では新人研修のカリキュラムが始まったりすると思うのだけれど、システム開発をする新人の人たちには、Unified Modeling Language(kakutani.comでは以後、「大事じゃないほうのUML」と呼称する*1。)よりもpatchを読んだり充てたり作ったりする演習を行った上で各自素振り、これを基礎スキルとして身につけておいてもらいたい。 現場としては「patchと書かれたファイルを見たらdiffが入っていて面食ら」うところから始めて、SCMツールの重要性を知って、タグとブランチの基本的
■1 Quick JUnit 0.0.4 のEclipse 3.0.xでの動作について 基本的には動作するのですが、3.0.x系では: 「テスティングペアを開くときにエディタを分割する」をオンにすると動かなくなる 複数のテスティングペアが存在する場合の切り替えが、マウスクリックでしか行えない という既知の問題があります。ご注意を。 「テスティングペアを開くときにエディタを分割する」は、masarlさんが「こんな余計な機能入れるんじゃなかったなあと後悔してるんですけど.」と言っていたこともあってか、0.1.0では無くなる予定です……というかmasarlさんがソースをリポジトリにimportした時点で既に無くなってました。 複数テスティングペア間の切り替えの問題は、0.1.0でFIXされています。 Quick JUnit 0.1.0のリリース時期について だいたいコードは動作確認できているので
★GoF のデザインパターンは、図らずも Java/C# の脆弱さを露呈する結果となりました。Ruby/Python などより洗練されたオブジェクト指向の支援が得られる環境下では、いくつかのパターンは単純なイディオムに過ぎず、言語によっては組み込みの機能として提供されているものも珍しくありません。また、GoF の事例を鵜呑みにすると、迂遠なアプローチを余儀なくされるばかりか、Ruby/Python などのより洗練された特徴を活かせません。GoF を模写しても始まりません。GoF が模写したそのルーツを探ることで、パターンの本質に迫れます。★Eclipse/VisualStudioは真の統合開発環境って言えますか?格差社会は、IT 業界も例外ではありません。Eclipse/VisualStudio の生産性の低さには居た堪れず、まるで二十年前にタイムスリップしたかのような錯覚に陥り、先祖返り
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く