2026
2025
2024
2023
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2005年07月の記事
全58件 (58件中 1-50件目)
-
スターウォーズＩＩＩ
昨日、スターウォーズを見た。オープニングから音が妙で、連れが「音が割れてる」と耳打ちする。さて本編開始。やはり音が妙で、オビ＝ワンがシディアスと戦う場面で中断。デジタルでの上映は無理らしく、フィルムで頭から再上映することとなった。なかなかできない経験だった。スターウォーズって、オイラが中学生の頃に始まったんだよな。エピソードI～IIIをリアルで楽しんでる中高生は、IV～VIはどうやって知ったんだろう？スターウォーズ初演に合わせるように「２００１年宇宙の旅」がリバイバル公開されたっけなあ。スターウォーズの雑誌記事を読むうちに、「１０年も前にこんな偉大なＳＦ映画が作られていた」っていう情報が頭に入ってきて、「２００１年…」も見たいと思ったんだった。＜エピソードI～IIIを見ていつも思うこと＞I～IIIに出てくる兵器や都市が、IV～VIに出てくるものよりも近代的に見える。
2005/07/31
コメント(0)
-
【目指せプレーオフ！】９回一点差まで迫る
９回、アルモンテのヒットに代走が新庄。ここで最近好調の金子が２塁打。坪井がヒット、小笠原がホームラン（今日４安打で打率も.277！）一点差まで迫ったのに、セギ様は三振でゲームセット。そこそこ盛り上がったんで、帯広のお客さんも喜んでくれたことでしょう。オリックスとのゲーム差は７に広がっちまったけど…。まだまだオイラは諦めないぞ！
2005/07/31
コメント(0)
-
構造化技法によるソフトウェア作成（資料）
ユーザ基本方針 マネジメント│ ┌───────┐ ┌───────┐ の制約└────┬→│１現行物理シス│ │５費用効果分析│←─┬──── │ │ テムの文書化│ └───────┘ │ │ └───────┘ ↑選択肢 │数量化 │ │ │ │ │した │ │ ↓ │ ↓選択案 ↓ │ ┌──────┐ ┌──────┐ ┌──────┐費用効果 │ │２論理モデル│ │４マンマシン│ │６選択案を │報告書 │ │ 作成 │ │ 境界設定 │→│ 絞り込む │→ │ └──────┘ └──────┘ └──────┘ │ │現行システム ↑次期システム │選択済ＤＦＤ │ │論理モデル │論理ＤＦＤ、 │ │ ↓ │データ辞書 │プロジェ │ ┌───────┐──┘ ↓クト憲章 └→│３次期論理シス│ミニ仕様書、 ┌───────┐│ │ テム定義 │次期システムデータ辞書│８仕様書を │└────┬→└───────┘──────────→│ パッケージ化│ │ │ └───────┘ │ │次期システム論理ＤＦＤ ↑ │ ↓次期システムデータ辞書 │ └→┌───────┐ │マネジメント │７システムの制│────────────┘制約 │ 約条件の決定│ 物理的制約条件文書──────→└───────┘
2005/07/30
コメント(0)
-
【目指せプレーオフ！】金子マルチ
今日も金子が２安打打った。最後の打席もひょっとしたらと思ったのもつかのま、結果は三振でした。とほほ。これでオリックスとは６ゲーム差？道は遠いなあ…。なんか眠たくなってきた。一眠りして明日に備えよう。
2005/07/30
コメント(0)
-
構造化技法によるソフトウェア開発（１４）
■■14.スケジュール、予算、プロジェクト管理に与える影響■■■14.1 見積とスケジュール作成に与える影響・開発プロジェクトの見積について、科学的、道理的で過りのない方法を知らない。・スケジュール遅延の大部分は、システム・テストおよびインテグレーションと称する雲をつかむような工程で起こっている。■14.2 従来型のマイルストン法（標識点）に与える影響■14.3 マイルストンと構造化技法・構造化技法を導入した後では、システムのバージョンごとにマイルストンを設定することになる。これは、開発状況が目に見える点で優れている。■14.4 まとめ・見積方法は従来通りでよい。・最初のいくつかのマイルストン（システム分析が終わるまで）は、従来通りで良い。・以降に続く従来のマイルストンを廃止し、トップダウン開発によるバージョンをマイルストンにする。従来のマイルストン例 新しいマイルストン－－－－－－－－－－－ －－－－－－－－－－システム要求書の受領 ┐システムスタディ開始 ├従来通り 〃 完了 ┘新システム仕様書完成 ┬保守的トップダウン方式では 〃 承認 ┘従来的新システム設計完了 詳細モジュール設計完了 バージョン１システム稼働コーディング完了 〃 ２ 〃単体テスト完了 〃 ３ 〃システムテスト完了 ：受入テスト完了 システム本番稼働 バージョンｎ本番システム稼働■■15.どんな問題が起こるか■■■15.1 社内根回しのコツ・管理者でない場合は、「静かな改革」を起すべきである。・構造化プログラミング、ウォークスルー、構造化分析を密かに進めるのだ。・成果が出れば、手法を問われることになる。■15.2 個人的問題・現在のプログラマやアナリストは、一日８時間職業的にプログラムを組んでいれば生活できる。・彼らの多くは自分の仕事に興味を持てず、でたらめに手慣れた方法でプログラムを書いているに過ぎない。■15.3 時間的ズレの問題・構造化技法が全社的に効力を発揮するまでには、軽く２～３年はかかる。■■16.パソコンのもたらすインパクト■■■16.1 はじめに■16.2 ユーザの分類□経験レベルでの分類・アマチュア…コンピュータは恐ろしい。ディスケットの挿入もできない。・初心者…表計算やデータベースの簡単な処理経験を持つ。 アプリケーションも同じように簡単にできると思いがち。・熟練者…若年層に多いだろう。■16.3 パソコンに潜む危険性・エンドユーザは自分でシステムを運用できることを知ってしまった。・しかし物事はパソコンのコマーシャルのようにうまくはいかない。□危険性(1)テスト不足・第４世代言語やスプレッドシートの結果をきちんとテストすることは少ない。(2)ローカル・データベースの存在・あらゆる部門のユーザが勝手にデータベースを持つことになれば、 データベースの冗長度、同期化、一貫性の問題はかなり深刻になる。(3)バックアップとセキュリティ・どちらも全く対処されていない。(4)関係文書の不足・プライベートなシステムは人がいなくなればなくなってしまう。■■17.第４世代言語と構造化技法■■■17.1 はじめに・第１世代…マシン語・第２世代…アセンブラ・第３世代…COBOL、FORTRAN、PASCAL、PL/I…■17.2 第４世代言語の特徴・データベースの定義と作成が簡単。・言語はコンパイラではなく、インタプリタで処理することが多い。・ユーザフレンドリ機能を備えている。・リポート作成の細部は自動的に処理してくれる。・特定情報の検索/照会機能。■17.3 第４世代言語の利点・システム開発プロジェクトにおいて、プログラミング工程の生産性を１０倍に上げることができる。・プログラミングの細部を作り直す必要がない。・プログラムメンテナンスの生産性は飛躍的に向上する。■17.4 第４世代言語の欠点・システム分析工程の改善効果はない。・既存データベースとの互換性がない。・処理効率の問題・第４世代言語自体の機能不足■17.5 結論・利用環境さえ適当ならば、第４世代言語は情報処理の強力な武器になる。■■18.プロトタイピング■■■18.1 はじめに・プロトタイピングは構造化技法と併用してこそ意味がある。■18.2 プロトタイピングを採用する理由・ユーザとシステム・アナリストとの間の意思疎通を図る手段。・作成と変更が迅速に、しかも簡単にできる。■18.3 プロトタイピングに適した環境の前提条件・対象システムのユーザが唯一人であるか、同一部門に所属し、所在地も同一地域内にある少人数の集団であること。・既存のデータモデルがあるか、簡単に作成できること。・対象アプリケーションが小規模～中規模であること。■18.4 プロトタイピングに潜む危険性・プロトタイピングといえども本格的な業務が可能。・プロトタイピングは使い捨てされる。・プロトタイピングは論理モデルの考え方を排除する。・プロトタイプは時間の浪費か？■18.5 結論とコメント・プロトタイピング自体は良い考え方である。・どんなに素晴らしいツールでも凡庸な人が使えば多くを期待できない。 むしろ有害なこともある。・プロトタイピングの考え方と構造化技法の概念は、双方が互いの存在を許さないなどというものではない。■■19.データ・モデリング■■■19.1 はじめに・すべてのシステムはある程度の機能とデータ、それに時間的要因に依存する。■19.2 現状の認識・機能モデリングの考え方、データ・モデリングの視点、状態遷移という見方は相互に矛盾するものではない。むしろ補完し合うシステムの見方なのだ。■19.3 現状の問題点・データベースの管理チームがあるならば、機能モデルから作成するべき。（データモデルは上記チームが作成する）・データモデルを作成してない場合は、機能モデルとデータモデルを同時並行して作成する。・全社的なデータモデリングを実施しておらず、データ自体もそう複雑でないならば、機能モデルだけで充分である。■■20.構造化技法の将来■■■20.1 はじめに■20.2 自動化ツール・1980年代半ばになって、充分使い物になる自動化ツール製品が現れた。□できること・図作成のサポート・データディクショナリのサポート・一貫性チェック■20.3 再利用可能コード□再利用可能コードのライブラリ化が失敗している理由・機能の範囲が曖昧で、あらゆる機能を取り込んだプログラムは再利用されない。 特定アプリケーションの要求を満たさないから。・ライブラリに登録するのは簡単だが、検索して利用するのは難しい。 テスト中のものがある時はなおさら。■20.4 複雑さのモデル■20.5 正しさの証明・テストとはエラーが存在しないことの証明ではなく、エラーが存在することの証明である。（Edsger Dijkstva）・今日稼働している重要システムのほとんどには、まだ日の目を見ないバグが潜在している。■20.6 プロジェクト・マネジメント
2005/07/30
コメント(0)
-
構造化技法によるソフトウェア開発（１３）
■■13.構造化技法の標準化■■・構造化技法を導入しても、既に設定済の開発標準には、ほとんど影響しない。＜影響の出そうな標準＞1.特定のプログラミング用ステートメントを違法と決めつける硬直的な規則。2.マイクロ秒単位で効率の善し悪しを指摘する標準。3.パッケージ化に関する標準化規則のほとんど。■13.1 標準を設定する時期・構造化技法を経験する前に、適切な標準を考えることは不可能だ。■13.2 がんじがらめの標準規則は無視される・プログラマやアナリストを画一的な規則で縛り付けることは、しばらくはできても、いずれ誰も従わなくなる。
2005/07/29
コメント(0)
-
構造化手法によるソフトウェア開発（１２）
■■12.パイロット・プロジェクトの選定■■■12.1 パイロット・プロジェクトには適正規模がある・中規模システムを採用すべき。３～６人月程度が良いだろう。・小さすぎると、構造化技法を習得する時間が無視できなくなる。■12.2 目に見える効果が期待でき、リスクの少ないプロジェクトを選ぶ・理想的なパイロット・プロジェクトがあるとすれば、既存システムを設計しなおす場合である。■12.3 パイロット・プロジェクトは評価可能であること・プログラマ１人日あたりのデバッグ済みコード作成行数・システムの本番稼働度に見つかったバグ数・実行効率（新旧の比較）・ウォークスルーに要した時間数・ウォークスルーで発見したバグの数・分析工程に費やした時間総数
2005/07/29
コメント(0)
-
【目指せプレーオフ！】金子だけ長打で勝利と豚丼
昨日は金子の２塁打から始まった７回の攻撃で岩隈から大量点をもぎ取り、金村、建山のリレーで勝利しました！１イニングに８点なんてなかなか無いことだよなあ、と思ってスポーツニュース見てたら、阪神は９点取ってました。何も同じ日に取らなくてもよさそうなもんだが…。この週末は釧路、帯広。オイラは行けないけど、札幌からも大量に流れ込むんだろうな。本場の豚丼とか、MOOで海鮮ラーメンとか、うらやましい。豚丼食いてえ！そういえば吉野家が似て非なる豚丼の販売を開始するとき、十勝豚丼協会（だかなんだか）の代表の人が、「吉野家さんにはかなわないと思いますが、広めていきたい」みたいなコメントを出していたのを思い出した。弱気な発言だ。吉野家が豚丼出すというのは十勝の豚丼にとっても絶好のビジネスチャンスだったんだよ。「本場の豚丼は十勝です。吉野家さんには負けませんよお、ガ、ハ、ハ」くらい言ってほしいところだ。入来は豚丼食べないんだろうな。新庄もかな。ひちょりは食べてどう思うだろうか？ カルビ丼もうまいけど。それはそうと小笠原と新庄はちょっと心配だ。
2005/07/29
コメント(0)
-
構造化手法によるソフトウェア開発（１１）
■■11.どの技法から導入すべきか■■■11.1 全技法を一気に全面採用する・小さな情報処理システム部門なら可能■11.2 組織変更を伴う構造化技法・はじめは構造化プログラミングからが無難だろう。・それがうまくいけば、少しずつ手を加えていくことができる。■11.3 構造化コードだけを採用する。・コーディング工程の生産性と信頼性については高い評価が得られた。・長期的なメンテナンス性については、まったく見るべきものはなかった。・構造化設計、構造化分析を同時に導入することが必要だ。■11.4 トップダウン設計とトップダウン開発を採用する。・プロジェクトの初期に何らかの成果をユーザに見せることができる。・ただし、プログラマの十分な理解を得なくては成らない。■11.5 形式張らないウォークスルーを最初に実施する。・ウォークスルーは構造化プログラミング、構造化設計、構造化分析と並行導入してこそ意味がある。
2005/07/28
コメント(0)
-
struts再入門（１）
■strutsとフレームワーク・struts…Javaフレームワークの一つ。・フレームワーク…定型処理をまとめたライブラリ。アプリケーション開発の共通基盤となる。WEBアプリケーションの場合、特にセッション内でのデータの持ち回りをフレームワークに任せることが多い。自前で書く場合は、COOKIEを使ったり、セッションIDをWEBページ内にhidden属性で持ちまわらせて、サーバ側のデータとリンクさせたりする。・主なフレームワーク ・struts…Jakartaプロジェクト提供のフリーフレームワーク。 WAS+Oracleで使った。 MVCモデルに基づく。 ・wacs…IBMのフレームワーク。WAS,DB2,WSADとの組合せが多そう。 ・Interstage Apcoordinator…富士通■strutsの機能□カスタムタグライブラリ・View(JSP)で使用するタグライブラリ。・分岐、繰り返し、エラー処理などを記述するために使う。※strutsではJSP内にスクリプト要素を混在させるのは推奨されないため、 それに変わるものとして提供されている。 （覚えるべきものが増えただけのような気もするが…）＜主なカスタムタグライブラリ＞・HTML…form機能を提供。・Logic…条件分岐、繰り返し、比較などの機能を提供。・Beans…Modelから引き継がれたJava Beansにアクセスするための機能を提供。・Nested…名前空間の制御機能を提供する。・Tiles…テンプレート機能を提供。統一されたデザインの維持とデザインパーツの分割管理を可能とする。□アクションサーブレット・設定ファイルに基づいて、入出力データの振り分けや画面遷移の制御を行う。・この機能のおかげで、Controlの記述はほとんど不要となる。 （ロジックの代わりに設定ファイルを書けば良い）□アクションフォーム・ユーザからの入力データを格納し、ビジネスロジックに渡す。・ダイナミックフォームBeanを使えば、Beanの記述は不要。□Validator・入力データのチェック機能を提供する。・チェック内容は定義ファイルに記述する。■参考リンク○Strutsを使うWebアプリケーション構築術(http://www.atmarkit.co.jp/fjava/rensai3/struts01/struts01_1.html)○strutsで作るWEBアプリケーション入門(http://www.itmedia.co.jp/enterprise/special/0310/struts/index.html)
2005/07/28
コメント(0)
-
【草稿】拝啓 団藤保晴 様
ご無沙汰しております。「ブログ時評」(http://dando.exblog.jp/)を読んでペンを取りました。団藤さんは、ブログ界では有名なんですね。なかなか面白そうな記事が多いので、じっくり読んでみようと思います。オイラ、団藤さんから二度ほどメールをいただいたことがあります。最初は１９９７年かな。脳死臓器移植法が話題になってきた頃で、インターネットもやっと世間に広まり始めてました。Internet Watchで記事を書いていた団藤さんが、リンク付きで紹介してくれるということでした。わたしは驚きの余り、しばらくは大量アクセスと意見・質問メールという不安と期待に苛まれる日々を送りました。実際にはほとんど何も起きませんでしたが…。当時はインターネット上に今ほど豊富な情報は無くて、脳死・臓器移植に関するサイトなんて数えるほど。紹介に値するサイトが少なくて、やむなくオイラのサイトを取り上げてくれたんですよね。どこの団体も情報発信に躍起になっている現在では考えられないことです。もっとも最近は読むに値しないコンテンツも多くなっていますが、良質のものが出てくるためには我慢しなければならないことなのかもしれません。あれから８年...。臓器移植法は成立したものの、移植医療はあまり増えず、何度か法改正の噂も聞きましたが、実現には至っていないようですね。団藤さん、これからも第一線でのご活躍を祈っております。敬具PS団藤さんの脳死・臓器移植に関する最新批評を読みました。臓器移植法改正２案でますます混迷 [ブログ時評24](http://dando.exblog.jp/2830597/)議論のポイントは８年前とあまり変わっていないようで、不思議な懐かしさを感じました。
2005/07/28
コメント(0)
-
構造化手法によるソフトウェア開発（１０）
■■10.構造化ウォークスルー■■■10.1 エゴの無いチーム・チーム作業の目的…個人技から開かれた技術へ転換する。□エゴの無いチーム・責任者がいない。・構成員は警察に協力し合って仕事をする。・お互いに相手のコードを読み、責任を分担しあい、互いの長所と短所を理解する。・成果物にはチーム全体で責任を持つ。■10.2 ウォークスルーの種類1.仕様書ウォークスルー ：ユーザ、アナリスト、数名のプログラマ2.設計ウォークスルー ：ユーザ、アナリスト、プログラマ3.コード・ウォークスルー：プログラマ（作成者、チーム内、チーム外）4.テスト・ウォークスルー：テストデータの適正さを検証する。 プログラマ、テスト担当者、アナリスト、ユーザ■10.3 ウォークスルーの目的・誤りの発見…ウォークスルーの実施でエラーは1/5に減ると言われる。・品質の向上…ウォークスルーを意識するだけで品質が向上する。・意識の向陽…若手はベテランから開発手法を習得し、ベテランは若手からフレッシュな発想を手に入れる。■10.4 ウォークスルーはいつ開いたらよいか・ある単位の文書がまとまり、レビューが可能になったらスケジュールを立てる。・コードウォークスルーについては、コンパイル完了直後が一般的。■10.5 ウォークスルーを開催する・ウォークスルーは、仲間同士の気楽な検討会で、議長が再拝をふるわないと進まないなどということは、そもそもありえない。・説明は作成者自身が行う。■10.6 その他のウォークスルーの注意事項1.ウォークスルーの開催スケジュールは前もって通知し、一日程度の余裕を見込んでおく。 関係資料は前日までに配布しておく。2.管理者は距離を置く。3.バグだけでなく、指摘された変更すべき箇所や改善点も記録する。4.レビュー終了後に出たバグはレビュー参加者全員の責任である。5.あくまで誤りを検出するのが目的。 修正案が簡単にはでないようなら、それは修正者に一任する。6.一時間で終わらせる。■10.7 ウォークスルーにかかわるマネジメントの問題(1)多くの人間を一時間占有することの経済性1.担当者の考え方にバグがあるなら、テストでもバグは現れない。2.プログラマ一人では見つけられないバグがある。3.構造化技法が十分に使われているかを確認する手段はない。(2)テストとデバッグはコンピュータ上で行うべき1.コンパイルにYouする時間（リスト入手まで含む）2.(1)-1と同じ理由によるバグの未発見。(3)新人は不要。チーフプログラマがコードを見れば済む1.１対１では主張がぶつかり合う。2.チーフプログラマは多忙。3.人数が多い程、バグは多く発見される。4.「無垢なる者の口からこそ金言が生まれる」
2005/07/27
コメント(0)
-
【目指せプレーオフ！】入来は肉を食べない？
今日の試合のことは置いといて...。オフィシャルショップのテープカットに参加した入来のインタビュー記事がＨＢＣの携帯サイトに出ていた。どうも入来は肉を食べないらしい。魚中心の食生活ということは、ガッツが通っているという眉唾な評判の「だるま」にも行ったことないのか？オイラも無いけど。入来に大リーグ行きのことを質問したファンがいたみたいで、回答は「気持ちは無いわけではないが、今は日ハムで精一杯やりたい」というような感じとオイラは取った。最も印象に残ってる試合は、先日の札幌ドーム対楽天戦だそうな。まあ、そうだよね。（と、無理矢理あの試合に話をつないで）実はあの７月１７日の試合のスコアブックを付けてる人がいました。LUDWIGのペナルティボックス(http://lvcranes.exblog.jp/d2005-07-17)あの試合はひょっとすると、今年の日ハムのベストゲームになるかもしれません。一生もんですよ。一昨日は入来が勝利投手。良かった。最後に、今日は小笠原とひちょりが３安打。横山も久しぶりに三振を取れていた。目指せ！ プレーオフ。
2005/07/27
コメント(0)
-
広瀬様は怒ってらっしゃる
今朝の道新のコラム「がんばれファイターズ」を読んだですか？広瀬様はかなりお怒りのご様子です。金石様も先週の中継では相当ご機嫌斜めのご様子でした。「プレーオフ進出を口にするのは奇麗事でしかない」そうです。でもオイラは信じますよ。まだまだ諦めるものか！賢介と上田の応援歌にもあるじゃないですか。「僕らは待つよ、輝く瞬間」「輝きある大きな夢を掴むまで」明日はリーで勝利だ！
2005/07/26
コメント(0)
-
［目指せプレーオフ]後半戦の初戦を勝利で飾る
フルキャスト宮城での後半戦の初戦、日ハムは最近好調の楽天に勝利でスタートしました。いやあ、良かったなあ。楽天の足音が聞こえてきた日ハムには、この４連戦は重要ですよね。ここで負け越すようなことがあると、万が一のことが現実味を帯びてくる…。勝ち越せば、まだまだプレーオフに望みをつなげる。入来は８回まで好投、そして最終回はトーマス。ちょっと心配だったけど、見事に三者三振。見直したゼ、トーマス。小谷野は今日はガムを噛まずにヒーローインタビューで、どこぞの掲示板に苦情書かれなくて済みそうだ。
2005/07/25
コメント(0)
-
鶴岡がＭＶＰ奪取！
宮崎で行われたフレッシュオールスターで日ハム戦士が大活躍しました！う～ん、久しぶりの満足感だ。ＭＶＰは先制ホームランなどの鶴岡。先発のダルビッシュも２イニング好投で、優秀選手賞を受賞。信二も實松も好きだけど、鶴岡が上がってくるならなおうれしい。昨日の木元、おとといの小笠原と、流れは良くなってるゾ。明日からの楽天戦、入来の好投と打線の爆発を待つ！
2005/07/24
コメント(0)
-
脳死関連本紹介
脳死・臓器移植のいろんな書籍を紹介するページを作ってみた。BLOG TARANCO 脳死関連本紹介(http://plaza.rakuten.co.jp/taranco/4000)本家WEAKLY TARANCOは脳死・臓器移植に関心のある方がよく訪問してくれるので、ちょっとはお役に立てるかもしれないと思って。
2005/07/24
コメント(0)
-
未来のファイターズ戦士は、加登脇卓真？ 林裕也？ 松橋拓也？
高校野球南北海道大会の準決勝を見てきた。噂の好投手、北照の加登脇卓真は北海をキッチリと抑える。駒大同士の一戦では、林裕也がセンターバックスクリーン横へのホームランなどで活躍したものの、松橋拓也は出番無し。４校の応援がそれぞれに個性的でおもしろかった。北海はケツ振りダンスとトランペット無しの声だけの応援。名の知れた応援歌をみんなアカペラで歌っている。迫力もあってかなり面白い。駒大苫小牧は見事に組織化されていて、ブラスバンドの人数も多いし、チアダンスも息がぴったりあっていた。序盤は彼らの応援を鑑賞するのに忙しくて、野球をあまり見てなかったくらい。出身校でもない高校の試合を見に行くなんて、去年までなら考えられなかったことだ。これも日ハム効果だな。その日ハムはオールスターで木元が好プレーを見せたものの、金村は登板無しだった。明日はダルビッシュ登板のフレッシュオールスター。テレビ中継があるなら見ようかな、と思う。
2005/07/23
コメント(0)
-
公式の掲示板（２）
昨日、厳しく接するべきというファンは自分の子供が運動会でビリになったら叱るべきと言うだろう、ということを書いた。今日、公式の掲示板を見てみたら、まさにそんなことが書いてあった。部下育成でも最近はコーチングの手法が使われるようになってきてるというのに…。叱るときは叱るにしても、叱り方っていうのがあると思うんだよね。上甲マジックに操られた笑顔の済美野球“やればできる”が魔法の合言葉 ビジネス・コーチング入門５月くらいのYAHOOの掲示板では、古参ファンが厳しく、新規ファンは優しい、という印象を持っていたんだけど、今では逆になってるような気がする。なんか恩着せがましいし。巨人ファンだった人が多いせいだろうか？ちょっと負けが混んだくらいでガタガタしない心構えは、僕の場合はロッテファン時代に身に付けたのだと思う。体罰で育った人は親になった時、子供に体罰を与えがちだと聞いた。そこまで結びつけるのは、飛躍しすぎだろうか？
2005/07/22
コメント(0)
-
公式の掲示板
北海道日本ハムファイターズの公式ホームページにある掲示板がすごい状態ですねえ。不満ぶちまけることで鬱憤をはらしてる人はまだいいけど、「厳しく接することこそがチームを強くする」と考えている人は質が悪い。彼らは自分の子供や恋人や部下にも同じように接するのかもしれない。「(C)応援系日ハム式」のBBSで、管理人さんが「息子の徒競走」に例えた記事を書いていた。心打たれる名文で、僕も目を覚まされた。でもきっと彼らはこう言うのだ。「徒競走で子供がビリになったら厳しく叱らなくてはならない。そうしないと向上しようとしなくなり、次もビリになるから」僕は、日ハムの今のカラーが気に入っていて、今後もこの方針を貫いて欲しいと思っている。「バントをしない」とか「１００球で交替」とかじゃないス。そういった細かい部分ではなくて、明るさと友好的なムードと自主性を重んじる姿勢といったことだ。もはやカラーが変わったとしても応援しなくなるのは難しいけれど、去年あっという間に僕を引き込んでくれた理由の一つは、そのチームカラーのように思う。オフィシャルファンクラブに入ってないので公式掲示板には書き込めないのが、ちょっと残念かも。
2005/07/21
コメント(0)
-
小宮山登場
予定とは逆の展開でしたが、９回裏に小宮山が登場しました。稲葉がヒットを打った球はシェイクかと思ったんだけど、さっき録画を見直したら、光山さんはナックルと言ってましたね。最近さかんにトーマスが投げていたのは、吉崎の調子が悪かったせいだったんですね、きっと。客席で見てるだけじゃわからないことは多いなあ。次の札幌ドームは８月の西武ライオンズ戦。それまでに少しでも借金を減らせますように。小笠原の調子が戻ってきたみたいなのが救いです。オールスターでまたセ・リーグのピッチャーと当たって、調子を落としたりしないでほしいです。
2005/07/20
コメント(2)
-
トラックバック（２）
記事の内容に関連が感じられない、よくわからないトラックバックをもらった。あらためてトラックバックについて調べてみたら、こんな記事が見つかった。【ブログ初心者講座】トラックバックがありがたいとは限らない(http://blog.heartlogic.jp/archives/000348.html)この中にある「俺のブログも読めや」と相手のブログから強制的にリンクを張ってしまうのが、トラックバックの働き大量トラックバック送信の常習者にとって、あなたのブログは単なる踏み台、スコア稼ぎのためのマトのひとつであり、対等なコミュニケーションをしようという意識もない」というのが言い得ていて気に入った。オイラのブログでは、スパムやアクセス数増加が目的のように見えるトラックバックはどんどん削除することに決め、さっそく一件削除してみた。クレームは、まだ来ていない。
2005/07/20
コメント(0)
-
上田のタイムリーを久々に見た
ダルビッシュ登板も、観客は１万５千。６連戦の５戦目、しかも３連休明けなので、止む無しか。ダルビッシュは今日も好投。毎回走者を背負いながらも、７回1/3を２点で抑えたんだから、勝ち投手になっていてもまったく不思議でない内容。一時同点となった上田のタイムリーは、久々にいいもの見た。オープン戦の活躍で慌てて覚えた応援歌を、やっと歌えたよ。上田のタイムリーの後、闘将会の人が、「逆転したらファイターズ讃歌です」とアナウンスしていた。ぜひやりたかったんだが、追いつくのがやっとでした。明日こそ！小宮山は今日も出番無し。小坂は嫌らしい選手だ。
2005/07/19
コメント(3)
-
道外遠征
こっちのブログの「道外遠征してる人いますか？？」で、道外遠征について調査してるみたいです。個人での調査みたいですが、彼氏さんがパックの企画をしてくれれば、ひょっとしたら安いパックツアーができるかもしれません。そうすれば、福岡ドームや千葉マリンスタジアムで日ハムの選手たちにもう少したくさんの声援を送れるかもしれません。彼氏の仕事への情熱と能力と、上司の方の後押しに期待します。
2005/07/18
コメント(1)
-
小宮山出ず
日ハムが北海道に来る前は浅いロッテファンだったんで、特にベテラン勢には愛着がある。中でも小宮山は格別。川崎球場とオリオンズを知る貴重な存在だ。「１０－２でハムがリードしていて小宮山が出てきたら、シェイクボールを投げるときにセンターから息を吹いていい？」と連れに聞くと、苦笑いされた。試合はそんな点差にはならず、緊迫した展開で小宮山が出てくることも無かった。もし最後の満塁でもう一点取っていたら、ひょっとしたら小宮山が出てきただろうか？さすがにそれは無いか。明日、明後日も小宮山が投げる姿を待ちます。願わくばその時は、日ハムが大量リードしていて欲しい…。あ、今日ヒルマン監督はお休みでしたが、ブライアンナちゃんはいらっしゃいましたね。もう一個だけ。今日は小笠原が４安打でした。このペースで打っていけば、まだ首位打者も可能かも。
2005/07/18
コメント(0)
-
入来イリキいりき
勝ったあ～。今まで祝杯上げてました。今日は入来に尽きます。１０回１安打。喧嘩投法。なんとか作ったチャンスをモノに出来ない中で１０回の森本も凄かった。永池もきっと、森本の走りが目に入ったために送球が反れたに違いない。明日は調子を落としてるロッテ戦。頼むぞ、リー。
2005/07/17
コメント(0)
-
北海道新聞を見て岩本に思いを馳せる
今朝の北海道新聞のスポーツ欄、ハム記事で一番大きな写真はアルモンテでした。右打者で打率も出塁率も高くて、一発も期待できる選手なら、岩本を上げて代打で（も）使う、ってのはどうでしょう。これならファンも納得する、かもしれない。武田は空席待ちで札幌に来たらしいです。お疲れ様でした。土曜の午前中の東京－札幌は空席無いですよね。武田投手は朝６時に鎌ヶ谷を出たそうですが、比較的空席が出るのは朝イチの便（６：３０くらい）。その後はほとんど出ないですよ。しかも３連休だし。ＡＮＡとかＡｉｒＤｏとか、融通利かせてくれないんですかねえ。僕がチケット持ってて、事情を知ったら変わってあげたのに。ＡＮＡはオフィシャルスポンサーなんだし。せめて事情をアナウンスして変わってくれる人を探すとか。今日、明日の午前中は空席もたっぷりあると思うので、ぜひ岩本を呼んでください。彼ならトーマスとアルモンテの二人分の結果を残しますよ、きっと。
2005/07/17
コメント(0)
-
立石、橋本、武田好投！
新聞に投壊とか書かれていたけど、今日は立石、橋本、武田が好投でした。うん。９回には小笠原の二塁打に幸雄、信二、稲葉が続いて、盛り上がった。うん。だいぶ現実逃避することにも慣れてきた気がするゾ。うん。帰りは豊平公園で荒んだ心を癒やし、近くのカレー屋で豆のカレー（ダルカレー？）を食べて帰ってきた。カレーはおいしかったです。立石投手はスープカレーでないカレーにはそんなに興味ないのかな？よければ一度行ってみてください。ううう。単純に考えると、打率２割５分のバッターが３人続けてヒットを打たない確率は1 - (3/4 X 3/4 X 3/4) = 1-(27/64) = 37/64 = 0.578125２度に１度強はこういうこともあると、そう考えれば腹も立たない…、かなあ。
2005/07/16
コメント(0)
-
江尻、横山、轟沈。
序盤から安定しない江尻が５回持たずに降板すると、続いて出てきたのは横山。よぎる不安…、そして的中。明日は勝つぞ、ファイターズ！
2005/07/15
コメント(0)
-
江尻Ｔシャツ
公式ホームページによると、江尻のＴシャツが販売されるそうです。春先に、今年Ｔシャツが発売される選手が誰かをカミサンと予想したとき、一番手が江尻だったので、待ってました、という感じだ。最近もうひとつパッとしないのが気になるものの、開幕からローテーションを守っているのは立派。明日の楽天戦、岩隈に投げ勝つ姿が見たい！ちなみに他にＴシャツが出ると思ってたのは、小田、正田、ミラバル。
2005/07/14
コメント(2)
-
構造化手法によるソフトウェア開発（９）
■■9.プログラム・ライブラリアン■■＜役割＞・ドキュメンテーション自動化ツールを利用して、プロジェクト・チームのドキュメンテーション関連業務を調整、支援することにある。■9.1 ライブラリアンの目的・プログラマを煩雑な事務作業から解放して、本来の仕事の生産性を上げる。・チームが作成する情報を組織的に管理して、プロジェクトの混乱状態をなくす。■9.2 ライブラリアンの資質・事務能力…タイプ/キーパンチができ、ファイル管理に熱意を持っている。・プログラミング能力…オペレータと対等に話ができ、プログラマの仕事を理解できる。・管理能力…存在感のある個性的存在。■9.3 ライブラリアンの仕事・ソース・プログラムの原稿の受け取り・コンピュータに入力可能なソース・プログラムの作成・コンパイラ/アセンブリの準備・ライブラリ中の必要な文書のファイルコピー・編集、再コンパイルなどのメンテナンス・プログラムの実行とテスト■9.4 開発支援ライブラリ・手書あるいはプリントした文書・コンピュータ処理可能な文書・プログラム・リスト・運用指示書・ライブラリ・メンテナンス情報■9.5 ライブラリアンにかかわるマネジメントの問題□9.5.1 マネジメントとの問題・職位や給与はどうするのか。予算的な裏付けも無い。・プログラマ経験者はそんなことは自分でするもんだと言うだろう。□9.5.2 プログラマとの問題・コンピュータとプログラマの間にもう一人人間を介入させるだけだ。・息抜きもなくコンピュータに向かうなんてとんでもない。□9.5.3 ライブラリアン自身の問題・仕事がよくわからない。用語も技術もチンプンカンプン。・プログラマと一緒に仕事をするのは嫌だ。・あきた。プログラマになりたい。
2005/07/14
コメント(0)
-
構造化手法によるソフトウェア開発（８）
■■8.チーフ・プログラマ・チーム(CPTO)■■■8.1 CPTOの背景＜動機＞・ピーターの原理(*1)の認識が広まる。・プログラマ間の能力差が大きいことに気付く。・従来方式による大規模プログラミング組織に特有の意思疎通上の問題に気付く。(*1)ピーターの原理組織内において、人間は自らの能力を超える地位に達するまで昇進する。・チーフ・プログラマという地位は、他の分野の専門職名で言う、チーフ・サイエンティストなどと同列になる。・プログラマの能力差は、経験ある有能なプログラマ間でも２５倍に達する。■8.2 CPTO誕生の経緯■8.3 チーフ・プログラマ・チームの特性□チーフ・プログラマ・チームの要員・チーフ・プログラマ、コパイロット、アドミニストレータ、エディタ、秘書、ライブラリアン、ツール担当者、テスト担当者、言語専門家、プログラマ□8.3.1 チーフ・プログラマ・卓越した才能と１０年の実務経験、対象システムが応用数学か事務処理かを問わず、アプリケーションとシステムについての十分な知識が必要である。・単にスーパープログラマであるだけではなだめである。機能仕様書を一人で作成し、ユーザに分かりやすく説明できなくてはならない。文章作成能力も欠かすことはできない。□8.3.2 コパイロット（バックアップ・プログラマ）・チーフ・プログラマの分身として働く。チーフ・プログラマの訓練生。□8.3.3 アドミニストレータ・資金や予算のやりくり、マシンタイムの割り振り、その他のペーパーワークを行う。現在のプロジェクト・マネージャに相当する。□8.3.4 エディタ・チーフ・プログラマの作成した文書の公正や文書作成の機械的工程を管理する。□8.3.5 秘書・タイプやファイル管理。アドミニストレータの補佐とエディタの補佐で２名必要。□8.3.6 プログラム・ライブラリアン・技術的な記録を管理する。□8.3.7 ツール担当者□8.3.8 テスト担当者・大規模プロジェクトでは、テストデータの作成やテスト用ユーティリティの作成は片手間ではできない。□8.3.9 言語専門家・オペレーティング・システム、データベース、マネジメント・パッケージ、コンパイラ、JCLなどの実務に通じていなければならない。□8.3.10 プログラマ・中小規模のシステム開発プロジェクトの場合、プログラマは不要である。■8.4 チーフ・プログラマ・チームにかかわるマネジメントの問題1.チーフ・プログラマとなす人材を見つけだすのが難しい。2.チーフ・プログラマに適正な給与を保証することは難しい。3.上位の仕事を求めるものを止められない。4.現在のプロジェクト管理者をどうするか。5.既存のアナリストが不要、または降格させることになる。6.現在抱えているプログラマはどうするのか。
2005/07/13
コメント(0)
-
明後日からは札幌ドーム
また負けました。ホークスに勝てません…。弱いチームのファンでい続けるためには、コツがあると思う。一試合一試合の勝ち負けに一喜一憂しないことだ。負けるたびにショックを受けていては、正直体がもたないから。心が勝手に防御壁を作ってくれるのかもしれない。ひょっとすると、同じことが選手にも起こるのかもしれない。負けることに慣れるのは、自身の精神状態を守るために必要なことなのではないだろうか？そしてその心理的機構こそが負け癖と呼ばれるものなのかもしれない。だとすると、負け癖の払拭というのは、並大抵のことではないですねえ。以上、今日のGAORA解説を聞いていて思ったことでした。解説の住友さんが「札幌ではいい動き見せるんですけどね」と言うのが本当なら、スタッフの方にはその辺の分析もしてほしいです。札幌のファンは、球場には行けなくても内地でのゲームをラジオやケーブル/衛星テレビを通じて応援していることも、忘れないでください。今週末から札幌ドームで６連戦。できるかぎり応援に行くので、良い動きを見せてもらいたいもんです。
2005/07/13
コメント(2)
-
終盤よく粘るも延長負け
最大６点差を終盤の粘りで追いついた。幸雄のホームランと小笠原の３塁打。しかも延長１０回にはロッテ戦を思い出させる小笠原のエラーを木元が好守で盛り返したというのに。トーマスと建山が打たれて、もう抑えがいない感じです…。悲しいッス。ダルビッシュは負けが付かず、持ち前の強運を発揮と言ったところでしょうか。今日は札幌ドームで巨人－中日戦がありました。３万２０００人とかなり入ったみたいですが、試合は中日が大勝しました。一方の東京ドームは１万６０００。ダル効果も東京ではあまり有効ではないんですね。明日は金村が先発。勝利を期待してます。
2005/07/12
コメント(0)
-
2ちゃんねるデビュー（鳴物応援）
気づいたら、本家サイトのページが２ちゃんねるで紹介されていた。【新球団】鳴り物応援禁止希望！！【ｵｰﾅｰ様】423 ：無礼なことを言うな。たかが名無しが ：2005/06/04(土) 19:21:25外圧に期待しましょう。 大リーグ参加のワールドカップが開催されるようになれば、 やりたくても出来なくなるだろうから。 鳴り物賛成派が唯一の拠り所としているのは、 １「メガホンの売上」 ２「観客動員」 この２点だけ。 つまり、鳴り物を一掃すると、現ファンがプロ野球から離れてしまう、と。 でも、"鳴り物アリ"の現状況でもファンが減りつつある訳だから、これらの論理は説得力が無い。 新たなファンを獲得する、という発想が欠けているんだよなあ＞鳴り物賛成派・・425 ：無礼なことを言うな。たかが名無しが ：2005/06/05(日) 11:16:13騒ぐ事が主目的の応援ファンは要らない。 そんなに騒ぎたいなら、弱腰外交で責められてる外務省を応援してやれよw http://taranco.hp.infoseek.co.jp/fighters/narimono.htm 鳴物応援禁止を検証するw423へのコメント鳴物応援の是非を話している時に「新たなファンを獲得する発想」っていうのはどうなんですかねえ。反論するなら「～だから鳴物禁止の方が観客動員が増える」とか言ってくれないと。どういう考え方をすると「観客動員が増える」と思えるのか、興味あるし。「新たなファンの獲得」は鳴物応援に関係なく大事なこと。鳴物応援禁止or反対論をきちんと説明しているサイト探してるんだけど、見つからないんですよ。わかりやすく論理立てて話してくれないと、いつまでたっても「批判してるだけ」って言われるのに。あと、多少重箱の隅ですが、「唯一の拠り所」が「２点」というのも変です。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－○横道に逸れて…他者の意見に批判はするけど自ら立論はしないという姿勢は、ひと昔前の社会党、共産党に似てると思う。オイラも十代半ばは同じような行動様式だったし、考え方をしていたので、人のことはあまり言えないなあ。でも批判だけでは周りは納得してくれないので、自分で立論することを早く覚えてください。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－425へのコメントこれは何なんでしょう。反論ですら無いみたいです。「外務省の応援」っていう発想が不思議。こういう発言には、どういう楽しみが隠されているんだろうか？本人のいないところでちゃかすような感じかな。とはいえ、紹介してくれてありがとうございます。■２ちゃんねるのスレッド【新球団】鳴り物応援禁止希望！！【ｵｰﾅｰ様】(http://sports7.2ch.net/test/read.cgi/npb/1096505240/)■Googleのキャッシュhttp://www.google.com/search?q=cache:KbS9IOk1YS8J:sports7.2ch.net/test/read.cgi/npb/1096505240/+taranco&hl=ja&lr=lang_ja■紹介されたWEAKLY TARANCOのページ鳴物応援禁止を検証する(http://taranco.hp.infoseek.co.jp/fighters/narimono.htm)
2005/07/12
コメント(0)
-
仕様変更雑感
ITプロフェッショナルの記事へのメモ。仕様変更とは、ハンバーガーショップで食べていくつもりで頼んだハンバーガーを、途中で知人から電話がかかってきて急いでそこへ行かなくてはならないために、持ち帰りに変えるようなものだ。店の方針や、店員の機転の利き方で、店の対応はいろいろとありえる。(1)「もう作ってしまったので、変えられません」と断られる。(2)持ち帰り用にすべて詰めなおしてくれる。あなたが客なら、(1)(2)のどちらの対応をしてほしいか？普通は(2)を選ぶと思う。店員の態度や表情も重要な要素になる。(1)だって店員が申しすまなそうに頭を下げながら言われれば、こっちの事情だししょうがないとあきらめもつく。(2)でも、ふてくされた態度で嫌々やられれば、こちらが悪いとは言えもうこの店には来たくない、と思う。「食べていくって言ったじゃないですか」なんていう店は論外だ。同じ結論に導く場合でも、対応の仕方しだいで次につながる場合もあるし、それきりになることもある。仕様変更対応の話でした。
2005/07/12
コメント(0)
-
構造化手法によるソフトウェア開発（７）
■7.2 手続き設計のためのドキュメンテーション□問題・プログラムが実際に動き出してから、フローチャートを作る。 この結果、フローチャートはプログラマの頭の中を表現し、実際のプログラムと一致しているとは限らない。・メンテナンス作業中にフローチャートが最新の状態に保たれているとは思えない。→構造化設計によってシステム設計を行えば、メンテナンスでは、デバッグしようとする以外のモジュールについて何も知らなくてもメンテナンス作業ができる。□7.2.1 擬似コード・コンピュータのエスペラント語とも呼ばれる。・他動詞一つと単数形の目的語一つで記述するドキュメンテーション技法と定義できる。＜長所＞・記述の構成がしっかりしていて正確。・プログラマ以外でも十分に理解できる。・フローチャート定規を使わないので、迅速に書ける。・端末からの入力が可能。□7.2.2 詳細HIPO図（機能HIPO図、IPO図）・モジュールの入力、処理ロジック、出力を抽象度の高い図で表現する。□7.2.3 ナッシ－シュナイダーマン図（N-Sチャート）□まとめいずれもプログラムのメンテナンスを正確に反映しているとは言えない。しかし、詳細HIPO図、N-S図ともに図警笛記述を必要とする。これは、メンテナンス時に大きな負担になる。また、HIPO図の処理部もN-S図のボックスの内部も、擬似コートと同じものである。■7.3 システム分析のためのドキュメンテーション・構造化分析に用いるドキュメンテーションツールは構造化設計や構造化プログラミングに使用するものと同じである。■7.4 ドキュメンテーション技法にかかわるマネジメントの問題・文書をメンテナンスする上での問題は、自動化ツールによって解消できる。・ドキュメンテーション技法は構造化設計の原則とは違う。
2005/07/11
コメント(0)
-
帰札
報われない神戸遠征を終え、今日は京都で生麩カレーを食べてから札幌に帰りつきました。今回の旅行では、食い物についてはなかなか当たりでした。ANA機内誌を見て出かけた新開地の串カツが特にうまかった。スポーツ新聞によると、「ヒルマンもこの時期に大阪ドームではなくスカイマークスタジアムを使う理由がわからない」というようなコメントをしていたそうな。まったくその通りだ。オイラの場合は、何かと評判の良い神戸グリーンスタジアムが見たい、というのがあったので、大阪ドームだったら遠征したかどうかはわからないけど。ホテルのロビーで、埼玉から夜行バスで来たというバファローズファンの方とちょっと話をした。彼は金曜のナイターから見たそうで、１試合見られただけでもうらやましいです。来年の遠征は梅雨時を避けるようにしたい。でもそうすると、バースデー割引が使えないのが悩みの種だ。
2005/07/11
コメント(0)
-
構造化手法によるソフトウェア開発（６）
■■７ 構造化技法のためのドキュメンテーション■■■7.1 構造化設計のためのドキュメンテーション・自分たちが形作るシステムの内容を見ることが出来るようにだけで、設計工程の品質の改善は十分達成できる。□7.1.1 データフローダイアグラム(DFD)・プログラフ・グラフ、バブル・チャートとも言う。・システムを論理的、抽象的に表現したフローチャートである。□7.1.2 HIPO階層図・HIPO図はモジュールの実行順序や判定、ループなどの詳細を明らかにしない。□7.1.3 構造図・手続き的な詳細部分を、細部に拘らずに示している。・重要なのは、構造図自体がモジュール間インタフェースを表現することである。HIPO階層図 ┌──┐ │Ａ０│ └──┘ ┌──┴┬───┐ ┌──┐┌──┐┌──┐ │Ｂ０││Ｃ０││Ｄ０│ └──┘└──┘└──┘ ┌─┴─┐ │┌──┐┌──┐ ┌──┐│Ｂ１││Ｂ２│ │Ｄ１│└──┘└──┘ └──┘ │ ┌──┐ │Ｄ２│ └──┘構造図もどき ┌──┐ 実際の構造図は、 │Ａ０│ ・折れ線ではなく、直線でモジュールをつなぐ └──┘ ・連結線の横にパラメータを書く ○ ┌──┴┬───┐ │ │ ◇ ┌──┐┌──┐┌──┐ │Ｂ０││Ｃ０││Ｄ０│ └──┘└──┘└──┘ ┌─┴─┐ │ │ ◇ │ ┌──┐┌──┐ ┌──┐│Ｂ１││Ｂ２│ │Ｄ１│└──┘└──┘ └──┘ ○ │ ┌──┐ │Ｄ２│ └──┘
2005/07/10
コメント(0)
-
ノーゲーム
今日も雨でノーゲームとなりました。小笠原のヒットもセギノールのタイムリーも無かったことのようです。今回は一試合も見れずに帰ります。今日は串カツを食べました。明日はお好み焼きを食べよう…。－－－－－－－－－－（翌日追記）お好み焼きは生麩入りカレーとなりました。昨夜の天気は、中止が決まった後１０分後くらいには小降りになり、三宮に戻った頃には星が見えそうなくらいに雲が薄くなってました。まったく、残念です。スカパーで見ると、ベンチの中ではけっこうパフォーマンスがあったみたいで、球場のスクリーンにも映して欲しかったなあ。
2005/07/10
コメント(0)
-
構造化手法によるソフトウェア開発（５）
■■６．構造化プログラミング■■■6.1 構造化プログラミングのあらまし・どのような複雑なロジックも、以下の３つのパターンの組合せで作り上げられる。(1)連続(2)選択(IF-THEN-ELSE)(3)繰り返し(DO-WHILE)(1)連続 ┌──┐ ┌──┐ ┌──┐→│処理│→│処理│→│処理│→ └──┘ └──┘ └──┘ (2)選択(IF-THEN-ELSE) ┌──┐ ┌→│処理│─┐ │ └──┘ │→◇ ├→ │ ┌──┐ │ └→│処理│─┘ └──┘(3)繰り返し(DO-WHILE) ┌───────┐ ↓ ┌──┐ │─→◇→│処理│─┘ │ └──┘ └───────→■6.2 構造化プログラミングにかかわるマネジメントの問題□6.2.1 GOTO分の是非を巡る論争・GOTO文を使った方が効率が良く、メンテナンス性も向上し、あるいは分かりやすいと信じているならば、GOTO分を使うことに特に問題はないだろう。・十分な構造化設計が行われていれば、とんでもないGOTO文は現れない。□6.2.2 構造化コードは良いコードという神話・GOTO文を無くしたからといって、エラーのない、わかりやすいプログラムがすぐに出来るわけではない。構造化プログラミングでも難解なプログラムを作ることはできる。□6.2.3 高級プログラム言語の弱点・PL/Iは冗長だとか効率が悪いという苦情をよく耳にする。しかしそれは、言語自体の問題であって、構造化プログラミングには関係ない。・COBOLはまだしも、FORTRANはひどいものだ。しかし、いずれも弱点ははっきりしており、新しいバージョンが登場する可能性は高い。□6.2.4 プログラム言語を知らないプログラマ・教育コースで各言語の基本機能をもう一度おさらいさせると良いだろう。□6.2.5 構造化プログラミングをアセンブラ言語に適用する難しさ□6.2.6 古参プログラマの態度や問題□6.2.7 効率が悪いという苦情・IF-THEN-ELSE文はGOTO文より実行効率が悪い。しかしそのサハCPU時間で1,2マイクロ秒、メモリ容量で1バイト程度だ。・余分なフラグやスイッチも1,2マイクロ秒の余分な処理を必要とする。・同じコードを各場所に散りばめることもあり、コードがやや長くなる。□6.2.8 旧来のプログラミング標準との矛盾□6.2.9 構造化プログラミングを標準とすることの難しさ・構造化プログラミングが標準通りにおこなわれているかどうかはウォークスルーによって確認する。□6.2.10 構造化プログラミングをメンテナンスに採用する難しさ□6.2.11 入れ子構造のIF文の難しさ・デシジョンテーブルを使って、すべての組合せを漏れなく調べたか、また重複や曖昧さ、矛盾はないかを確認するのが最良の方法である。
2005/07/09
コメント(0)
-
雨で中止
今日は雨で中止です。年に一度（予定）の遠征で神戸まで来たのに、ちょっとがっかりですね。しょうがないので、琵琶湖を見て、明石焼きを食べました。明日は晴れてくれますように。
2005/07/09
コメント(0)
-
希望が丘野球場＆tsuboiＴシャツ
先週のことですが、北海道の道東にある音更町に新しい球場ができたそうです。音更メールそこに金田正一、衣笠祥雄、北別府学らに混ざって、われらが亀ちゃんも来ていたのだそうです。今月末には帯広で試合がありますので、その際も是非お越しください。亀ちゃんのブログにも、オープンした球場のことを書いてほしいなあ。モール温泉として名高い十勝川温泉のある街です。－－－－－－－－－－－それはそうと、tsuboi7.com(http://tsuboi7.com/blog/index.html)が久しぶりに更新されたこの日、日ハムは見事な攻撃を見せて勝ちました。初回の坪井のヒットから始まった計１４安打、５本塁打の攻撃でした。神戸は今日は浴衣デーだったんでしょうかねえ。やけに浴衣の女性が目に付きました。坪井デーもtsuboiＴシャツ着てる人は割引とかどうでしょうか？アクアブルーの人は５０％引き、白や黒の人は３０％引きとか。雨の可能性が高いですが、明日も頼んます。
2005/07/08
コメント(0)
-
構造化手法によるソフトウェア開発（４）
■5.2 構造化設計に関わるマネジメントの問題□5.2.1 設計者は抽象的設計という考え方をよく理解していない・構造化設計は適度の理解力を備えた人であれば、誰でも利用できる、確実な高価を持つ方法論である。・理解力のある要員を開発メンバに加入させよ。□5.2.2 設計方針の間の矛盾・かつてはコンピュータの実行効率が第一であったので、論理的凝集やコミュニケーションの凝集を招きやすかった。・現在ではほとんど意味を失っている。・時代遅れになった標準規則は思い切って廃棄すべきである。□5.2.3 小規模プロジェクトで構造化設計を採用する難しさ・プログラマが所要工程１～２日程度の小さなプログラムを個別に作成している場合を考えると、確かに構造化設計の原則は約にたつものの、あえて厳密に実施しなくてもよいだろう。・プログラマが２～３人で所要開発期間が数ヶ月程度の中規模の開発プロジェクトのときは、ある程度厳密に構造化設計の規則を適用するのがよい。・この条件を越えるような大規模なプロジェクトであれば、構造化設計の規則を必死に守らせなければならない。□5.2.4 効率が悪いという苦情・プログラムの処理効率は、リアルタイム・システムは大量データ処理システムでは極めて重要な設計ポイントである。好んで効率の悪いシステムを作る者もいない。・それでも、現代のコンピュータシステムでは、処理効率がよくなければダメだという主張のほとんどは無意味である。＜無意味の説明＞1.原稿のシステムの効率は誰にもわからない。上げられるかどうかもわからない。2.処理効率は、手法よりもプログラマに依存する。3.構造化手法によるCPU時間及びメモリーの増加は、10%程度である。4.'90-10'の法則…コードの10%がCPU時間の90%を消費する。 処理効率に影響を与えるのは全体のごく一部であり、必要なら後から対処できる。5.システムをまず稼働させ、効率を上げる方が、その逆よりも容易である。6.設計段階で難しかった箇所が効率を下げているとは限らない。□5.2.5 システムアナリスト、設計者、プログラマの適切な役割分担の難しさ・構造化設計はシステムアナリスト、プログラマとも習得しなければならない。・さらにシステムアーキテクトと呼ばれる職種が必要である。(1)業務システム設計・ユーザと話し合って彼らが望むシステムを見つけだす。(2)コンピュータシステム設計・十分に使用化された命題を解くためのモジュール構造を決定する。(3)プログラミング・各モジュールの詳細手順を設計する。
2005/07/08
コメント(0)
-
オールスターに小笠原とSHINJO 古田も
ファン投票の最終結果が出た。最終中間発表と比べると結構違っていて驚きだ。日ハムからは小笠原とSHINJOが入った。ノリが大リーグに行っちゃったので、今年の成績でも小笠原が楽勝だったね。このままじゃ来年はわからないので、後半は活躍期待してますぜ。SHINJOは甲子園でもう一回暴れてくれるそうです。セ・リーグでは、古田が入ったのがうれしいね。今年はなんとしてもファン投票１位で入ってもらいたかったので。そして今年もSHINJOにヒーローになるようにサイン出してください。広島の黒田も意外。川上か上原のどちらかだと思ったんだけど。今年は甲子園とインボイスという事で、見には行かれませんが、見応えのある試合を期待します。
2005/07/08
コメント(0)
-
構造化手法によるソフトウェア開発（３）
■■５．構造化設計■■■5.1 構造化設計のあらまし・構造化設計はトップダウン設計とは別のものである。トップダウン設計でもとんでもないシステムを設計することができる。□構造化設計を構成する５つの概念(1)ドキュメント技法・システムを手続き的な視点からではなく、構造的、階層的な視点から見たグラフィックツール。(2)評価基準(3)ヒューリスティック（発見的）法(4)設計戦略(5)開発戦略□構造化設計の基礎となるその他の考え方(1)結合度・あるシステム内の異なるモジュール間の相互関係の強弱を表す。(2)凝集度・一つのモジュール内部における構成要素間のまとまりの強さを表す。(3)病的結合・あるモジュールが他のモジュール内部を参照すること。(4)変換中心型設計(5)パッケージ化
2005/07/07
コメント(0)
-
落ち込まずに次へ
今日は試合がありません。最近の負け方でファンはいらつき気味ですが、選手の方々にはあまり気にせずに次の試合に臨んでほしい。失敗で落ち込んでも良い結果は出ない。反省はしても落ち込むな。僕らの仕事でも、それは一緒だな。
2005/07/07
コメント(0)
-
構造化手法によるソフトウェア開発（２）
■■４．トップダウン設計とトップダウンテスト■■■4.1 トップダウン方式のあらまし・トップダウン設計と構造化プログラムは根本的に別物である。□トップダウン設計・規模の大きい複雑な問題をより規模の小さい簡単な問題に分割する設計手法。□トップダウンコーディング・上層部の管理モジュールの設計を終えると直ちにそのコーディングを始めるやり方。□トップダウンテスト（トップダウン開発）・下層部のモジュールのコーディング開始前に、システム雄上層部のモジュールのテストを行うやり方。■4.2 トップダウン方式の長所・トップダウン設計の長所…複雑で大きな問題を解決可能な小さな問題に分割する。□主要なインタフェースは開発プロジェクトの開始時からテストできる。□ユーザはシステムの稼働をその目で確認できる。・システムのスケルトンバージョンが実際に稼働するところをユーザに見せられる。□スケジュールの問題がもっとうまく扱える。・トップダウンでもボトムアップでも、スケジュールの問題は存在する。しかし、トップダウン方式で開発を進めていれば、はるかに政治的に強い立場に立つことができる。□デバッグが楽になる。・テスト…対象とするプログラム又はシステムが正しく動作すること、あるいは誤って動作することを実証するための工程。・デバッグ…プログラムのバグを見つけて、とことん追いつめていく作業。・トップダウン方式のテスト環境では、何故デバッグが容易になるのか。→スケルトンモジュールにあるモジュールを追加してバグが発生した場合、それは追加したモジュールか、インタフェースのどちらかにある場合がほとんどだ。もしわからなければ、ダミースタ部をもう一度戻せばよい。□トップダウン方式ではテスト時間を分散する。□プログラマの士気が高まる。・開発段階の早いうちから、仕事の結果や進捗状況が目に見える形で把握できる。・たいていのプログラマはペーパーワークは嫌いである。しかしプログラムを作ることは好きだ。たとえスケルトンプログラムでも。□テストのための仕掛けは不要。・スケルトンモジュール自身が自然にテストドライバの役目を果たす。■4.3 トップダウン方式に関わるマネジメントの問題□革新的トップダウン開発と保守的トップダウン開発の混同 ┌──┐ │Ｍ１│ └──┘ ┌─┴─┐┌──┐┌──┐│Ｍ２││Ｍ３│└──┘└──┘革新的：Ｍ１設計→Ｍ１ＣＤ→Ｍ１テスト→Ｍ２設計→…捕手的：Ｍ１設計→Ｍ２設計→Ｍ３設計→Ｍ１ＣＤ→…・ユーザが気まぐれである程、革新的である方が望ましい。・時間的に余裕が少ないときは、革新的手法で成果を出す。・見積が正確に必要ならば、保守的手法をとるべき。・革新的トップダウン方式が適切でない状況においては、ユーザ側の圧力に屈してこの開発方法を採用してはならない。・ユーザが希望するシステムを十分に把握できないうちに、保守的トップダウン方式により、完全なシステム設計を狙ってはならない。・開発管理者たるもの、トップダウン方式ではプロジェクト開始直後から自由にコーディングを始めて良いなどと、騙されてはいけない。□マシンタイムの不足・ボトムアップ方式に比べて早い時期にマシンタイムが必要になる。これが時としてマシンタイムの不足を招く。担当者はトップダウン方式のテストを放棄しがちになる。・既存のスケルトンモジュールに一つずつ新しいモジュールを追加するという基本手順の代わりに、ある快走のモジュールをまとめて追加する。□テスト用ハードウェアの不足・実際と同じハードウェアを用いたテストは高価になる。開発プロジェクトの期間を通して、高価なハードウェアを遊ばせるのを懸念するわけだ。□要員問題・開発の中期以降の要員を当初から確保する場合、彼らも上位モジュールの設計に参加させるべきだ。たとえコーディングレベルやレビュー、W/Tだけだとしても。必要かどうかわからないような最下層モジュールのコーディングを担当させるよりは、はるかに有益である。□下位モジュールを変更すると最上位モジュールに影響が波及することへの懸念・この懸念が特に大きい場合は、保守的トップダウン方式を採用する。□トップダウン方式のプログラムテストとボトムアップ方式のシステムテストを抱合わせるという過ち□複数チームで編成する開発プロジェクトでの意思疎通・ミーリーの法則…やがて姿を現すシステムの構造は、そのシステムを開発した組織構成を反映したものになる。□トップダウンバージョンを視覚化する難しさ・ユーザを何とかシステムの初期段階のバージョンに参加させることだ。□開発スケジュールと予算の再交渉・ユーザは都合のよいようにシステムの仕様が変更でき、しかもスケジュールの追加や開発コストのオーバーを考えなくて良いと彼らに思わせるのは間違いだ。従って、変更に伴う追加作業が無い場合でも、スケジュールと開発コストに関する交渉段階を必ず踏むべきである。■参考本ソフトウェア構造化技法
2005/07/07
コメント(0)
-
構造化手法によるソフトウェア開発（１）
■３．４ 構造化分析に関わるマネジメントの問題□1.構造化分析がうまく機能しないのではないか、という危惧が出てくる・ストレートに反論する。「うまくいかないと、どうして言えるのか。膨大な仕様書はエンドユーザは読まないし、状況に変化に追いつけずに陳腐化している」・常識で反論する。「構造化分析は今や常識ですよ」・証拠をあげて反論する。□2.分析の所要時間についての懸念・成功事例によって有効性を実証してみせる。□3.なぜ原稿システムを分析するかを正当化しなければならない・ユーザが今、何をしているか理解できない限り、ユーザが必要としている新しいシステムがどんなものかわからない。・今、どうやって仕事をしているかを知りもしない人間が口を出せば、ユーザは腹を立てる。・エンドユーザとの会話は、ユーザ側のごく普通の言葉で行う必要がある。□4.構造化分析が従来の分析方法と違うことを認めたくない□5.仕様書の凍結を防ぐ・仕様書を凍結できる者がいるとすれば、それはユーザ以外に考えられない。変更に伴うコストを負担するユーザには、変更を強制できるだけの力がある。変更要求を管理する手段を身に付けなければならない。□6.図で表現したモデルは、維持が難しい。・プログラム・ライブラリアン、アナリスト・ワークベンチ□7.ユーザは構造化モデルを見たがらないのではないかという懸念「現在の業務がどのようになっているか、私の理解した範囲を図にしたのがこれです」□8.このモデル化技法がリアルタイム・システムに適用できないのではという懸念・状態遷移図が重要なアイテムになっている。□9.パソコンユーザをどうするのか・複雑なシステムはパソコンであってもモデル化が必要。□10.仕様書は完璧でなければならないと言う神話
2005/07/06
コメント(0)
-
日ハムは、ロッテに勝ち越して神戸へ行けるか？→駄目でした
エース金村とキャッチャー信二のコンビで、今日はカード勝ち越しを目指します。ホームとしては愛称の良い東京ドームでぜひとも勝利し、気持ちよく神戸に行こう！昨日は試合前に内野の連携を練習したそうな。プロ野球ニュースの加藤さんは「選手にとっては嫌なこと」と言っていた。恥ずかしいという意味と思うが、連携の練習とかはシーズン中はやらないものなのかしらん？さすがに試合直後に外野の守備練習をやった西武には驚いたけど、試合前ならどんどんやれば、という気がする。○試合後６，７回のピンチを金村の粘投で１失点で乗り切り、９回表ツーアウトまでいった時は勝ったと思ったんだけど…。１日休んで次は神戸。今日のことは忘れた、忘れた。
2005/07/06
コメント(0)
全58件 (58件中 1-50件目)
-
-
- ★資格取得・お勉強★
- 令和8年度社労士試験 合格発表
- (2026-10-01 22:23:53)
-
-
-
- 今日のこと★☆
- コリウスを植えた、博多鋏、内出血
- (2026-10-07 14:06:41)
-
-
-
- 【楽天ブログ公式】お買い物マラソン…
- ポチした歯ブラシ早速使ってみました…
- (2026-10-07 16:17:43)
-
