Google+ のコミュニティですが、答えるとなると長文が書ける・・・。 質問をする為の掲示板は昔からありましたが、Google+ はちょっと作業しづらい感があります。そのせいか、他の内容がだいたいにおいて漠然としていて、とても本腰入れて返答したようには見えないし、質問側も返答に対するレスポンスがぱっとしない・・・。プログラマ専用にもっと広いフィールドが欲しいですよね。 開発経験の無い人は、『スケジュール』という文言の意味するところが実感できていません。単なる『予定』と思っている人が多いです。開発は、納期が必ず決まっているのでそこからの逆算で、人員を用意しています。個々のスケジュール管理は全体から見た微調整で、遅れれば、なにらかのテコ入れが必要ですし、進めば 前倒しが必然となります。 また、そうした前提でスケジュールを立てるにしても、持ち時間を全てプログラミングに使えるわけでは無く、移動や休憩や会議もあります。それらをふまえて週間単位で予定を考えるところから『スキル』が必要である事になります。全く持って単純では無いわけなんですが・・・・ 学生なんかのやってるのは、全く殆ど『ままごと』です。 1) プログラム一覧 スケジュール管理に必要になります スケジュール管理するには、時間見積りが必要です 時間見積りするには、見積りする単位が必要です 一般的にはエンドユーザのタスク単位になります 2) 入力設計書 画面設計書と入力項目単位のチェックや属性 できればエラーメッセージの定義も欲しいです 3) 出力設計書 広い意味では、画面に対する編集処理も含まれますが 一般的には、テーブルに対する更新方法の定義です さらに、印刷帳票のフォーマット設計も含まれます 4) テーブル設計 これは基本設計として、システムに必要な項目を プロが並べ替えたものですが、エンドユーザへの 確認資料にもなります。 5) 概要書 これ一枚でプログラム単位の一つの全体像が全て 認識できるものです。このフォーマットが会社単位で 違いますが、1) 〜 4) は目的に沿っておれば内容は皆同じです 6) オブジェクト定義 今時の開発ではこれらも必要となるのでしょうが、これこそ 会社によって全く違うものになると思います。 正直ここは良く解りませんが、昔は機能定義とか関数定義 等で、ブログラマ寄りの設計書であったため、作られる事 がまれではありました。 7) スケジュール 本来は、開発メンバの為に存在するのでは無く、会社が クライアントの納期を守る為にあります。ですから、 プログラム単位のスゲジュールと、担当者単位の スケジュールで管理者が管理します。 8) ガントチャート スケジュールはこの方式で語られる事が多いようですが、 予定と実績が管理できるものが、週間・月間で検証できる ものであれば良いです。 とは言うものの、見積りが無い以上スケジュールは 無意味ではあります。また、一日に使える時間を把握 していないと、また無意味です。 最初は、その見積りができるようになる為に、仮のスケ ジュールで開発し、それに使われた時間を記録しておいて プログラム単位でのボリュームを理解する必要があります
|
|
2013年12月14日
仕様書の書き方?? スケジュール管理??
2013年11月18日
MVC と WEBデザイナーさんの憂鬱(2)
お返事いただいたのでもう一回頑張ってみました。>ModelやControllerのPHPも読めないと作業になりません。 デザイナーさんにこれを求めるのは酷です。ご苦労をお察しします。 そもそも、CakePHP を使っている時点で、プログラマも自分のコードがどういう影響を VIEW に与えるか解っていない可能性があります。 まず、Ajax のお話ですが、jQuery で呼び出す相手先が 通常PHP になります。何が返されるかは、プロジェクトの仕様によって自由ですが、理想的なものは JSON 文字列です。しかし、その場合は jQuery 側で JavaScript のオブジェクトに変換して、VIEW 内の要素に対してなんらかの変更を加える為のデータとする必要があります。 ここはもう、全くプログラマの領域です。 $.get(url) .done(function(data){ 成功した時の処理 }); これが最もシンプルな jQuery の ホスト呼び出しですが、data が php の返した内容です。ここでは成功したかどうかはあまり重要ではありません( 成功したという前提の処理です / ただ、 インターネットを介した物理的な呼び出しは成功していても、PHP内部での論理的な処理は失敗しているかもしれません ) たいていの場合この data が VIEW を構成する部品となっていますので、 1) このデータのフォーマット 2) このデータをどう扱うか 3) このテータをどこに使うか という設計書がなければ、プログラマでも何もできません。まして、デザイナーさんがここを読み解くなんて想像もできません。 とは言え。 この部分を勉強なされて、読めるぐらいになれば、これからの世の中にとって貴重なハイブリッドのデザイナーさんになれるのは間違い無いと思います。ここまで書いて、『まず、Ajax のお話ですが』と書き出してしまっているのに気づいて、二つ目頑張りました。>PHPで出力しているからデザイン加えるのは無理 要素の成り立ちを変更するのはおそらく無理かもしれません。例えば TABLE 要素で一覧形式で出力されている場合、DIV 等に変更は無理です。 しかし、要素にクラスが設定できるとは思うのですがプログラマのレベルに依存します。 後は、 CSS でどうにかするしかありません が、その場合 jQuery は威力を発揮します。jQuery でどこまでやってもいいかというプロジェクトのルールにもよりますが、プログラマに全てを委ねるのならば、その表示部分を総入れ替えする事も可能は可能です。 ただ、業界的に言うと、JavaScript を使ってそこまでできる人材は少ないと思われます。ですから『無理』のボーダーラインを誰がどうやって見極めるかが最終判断の分かれ目です。 それと。 現実的には、JavaScript で画面を作成する事は最低限に留めておかないと、本番での責任の所在が問題になってしまいますので、そこはうまく避けて通る必要があると思います。WEB で出来る事が際限なく増えていく中で、それを全てマスターなんでできない現状を世の中というモンスターは現実をどう受け止めていくんでしょうね。 関連する記事 MVC と WEBデザイナーさんの憂鬱
2013年11月14日
MVC と WEBデザイナーさんの憂鬱
Google+ のコミュニティで質問されていたので頑張って返答しました。結構長文になったのでこちらに持って来ました。 -------------------------------------------------- >ViewにはどこまでPHPのコードを書いてよいのでしょうか？ 仕様では無いのでそのような決まりはありません。プロジェクトのえらい人が決める事ですが、どんな場合にでも例外はあります。 >PHPがHTMLに食い込みすぎていて 既にプログラマ側がルールを設けていない事を読み取れます。つまり、あなたのほうでプログラマの邪魔にならないようにしておられる気配りが感じられます。ですが、これに関してはそのコードに関する責任者と話し合ったほうがいいと思います。その話し合いの為に必要な知識を求めておられると判断致します。 当たり前の事ですが、基本的には HTML・CSS 部分のみを見つめて下さい。その際気になると思われるのが、PHP の変数埋め込み部分です。 <?= $value ?> または、 <?php function() ?> といった部分です。ここは、たいていにおいて HTML の中に埋め込まれているので、MVC において普通に使われるものです。ですが、この場合、$value の中が全て HTML の場合もあります。そういったものは、MODEL の位置付けとなる、関数またはメソッドの中で生成されています。 次に気になるのは、条件が記述されている部分です。 <?php if ( condition ) { ?> ここに HTML <?php } ?> この部分がもし存在する場合は、デザイナーとしてはお手上げです。話合いによる確認が必要です。 MVC は、本来デザイナーが混乱しないで済むようにプログマー側が認識するべきルールを旗揚げして守る事によって効率やメンテナンス性を上げる事が目的だと思います。ですから、デザイナーが混乱する時点でその意図が中途半端であると思われます。これらは、話し合いで好転させるしか無いとも思いますが、そうそう完全に切り分けれるものでもありません。 >JSのAjaxも使っていて、クライアントサイドとサーバサイドの区別がますます難しく Ajax と呼称される技術の守備範囲はあくまでクライアント側です。サーバーサイドにデータがあるのは事実ですが、VIEW 内で管理されるテクノロジーです。 ですが。 そもそも、デザイナーとして JavaScript を書かなければならないという事実があるのならば、MVC における VIEW とはかけはなれた守備範囲になります。JavaScript は完全にプログラマーの守備範囲で、デザイナーは要素とその位置と CSS による装飾を設計するという立場になると思います。 つまり、誰か偉い人が能力に合わせて管理しながら旗を振ってくれないと、MVC なんてものは意味が無く、個人が勉強して苦労するしかいいものは作れないというのが現実です。 悲しいですけれど。 関連する記事 MVC と WEBデザイナーさんの憂鬱(2)
Seesaa の各ページの表示について
Seesaa の 記事がたまに全く表示されない場合があります。その場合は、設定＞ 詳細設定＞ ブログ設定 で 最新の情報に更新の『実行ボタン』で記事やアーカイブが最新にビルドされます。 Seesaa のページで、アーカイブとタグページは要注意です。タグページはコンテンツが全く無い状態になりますし、アーカイブページも歯抜けページはコンテンツが存在しないのにページが表示されてしまいます。 また、カテゴリページもそういう意味では完全ではありません。『カテゴリID-番号』というフォーマットで表示されるページですが、実際存在するより大きな番号でも表示されてしまいます。 ※ インデックスページのみ、実際の記事数を超えたページを指定しても最後のページが表示されるようです 対処としては、このようなヘルプ的な情報を固定でページの最後に表示するようにするといいでしょう。具体的には、メインの記事コンテンツの下に『自由形式』を追加し、アーカイブとカテゴリページでのみ表示するように設定し、コンテンツを用意するといいと思います。※ エキスパートモードで表示しています アーカイブとカテゴリページはこのように簡単に設定できますが、タグページは HTML 設定を直接変更して、以下の『タグページでのみ表示される内容』の記述方法で設定する必要があります
<% if:page_name eq 'archive' -%> アーカイブページでのみ表示される内容 <% /if %> <% if:page_name eq 'category' -%> カテゴリページでのみ表示される内容 <% /if %> <% if:page_name eq 'tag' -%> タグページでのみ表示される内容 <% /if %>この記述は、以下の場所で使用します
|
|
