Codeigniterで設計(?)

CodeIgnigter
ちっともまとまっていませんが、Codeigniterで設計勉強会の資料を作ったらどうなるかな的に作ってみました。


第二回設計勉強会

課題(?)ほどには深いところまで書けては無いのですが、
ここしばらくCodeigniterを使っていての自分なりのまとめになったような気がします。理解はまだまだ浅いのです (>_< ) 1ヶ月後、3ヶ月後ぐらいに同じ課題で再度資料をつくってみたいなと思います。

追記:2008.10.31
こうしたら、こんな効果があったとか、足りないことを少しずつ自覚中。
やはり1ヵ月後には再度同じテーマで資料を作ってみたいな。

TRACチケット駆動開発(試行錯誤中)

現在自社サイトリニューアルのため、CodeIgniterでサイトを構築中です。
で、1人作業をしているわけですが、開発タスクのTracのチケットを仕様、設計メモにしてみました。

  • チケット登録時に実装する機能の資料をチケットに記載
  • 関連するDBのテーブル定義
  • コーディングルール(意識して気をつけて書いてる点)
  • Class,function,責務,URLの一覧
  • 各責務の特徴、主な役割
  • 実装作業したリビジョン番号をメモ的に記載

実際に作業をしてみると、作業最中は、作っている機能のチケットのページをずっと開きっぱなしで作業をしてます。

修正すべき項目は即時に修正。
ドキュメントとして保存しておくべき項目をすぐに追記。

そのチケットが終わる頃にはチケットが最終のドキュメントになることを狙っています。
実際作業をしてみると、チケットに書いてある内容を元に、PHPdoc形式で書くのに作業がスムーズでした。
目の前の作業中に目の前に資料がある状態のおかげで作業にも集中できました。

しばらく一人作業の場合はこの方法を練ってみて、
うまくいくようであれば事務所に導入してみようと思います。

今日買ってきた本。

久々に本屋へ行き、本を物色♪
もうすこしデザインよりの本を買うつもりが、アプリの開発系の本ばかりとなりました。
本命のJQuery系の本はなし・・・

ずっと受けたかったソフトウェアエンジニアリングの授業(1)

ずっと受けたかったソフトウェアエンジニアリングの授業(2)

[入門] はじめてのオブジェクト指向設計

はじめて学ぶUML 第2版

git勉強会をふりかえってみる。

「歴史」という言葉が勉強会の中で何度も何度もでてきます。
この部分に作る姿勢の差がもっと先の世界を感じました。

勉強会で何度も耳にした「歴史」という言葉。

「履歴」を残しているのではなく「歴史」を作ってる。

SVNを使ってソースコードの履歴を残そうという段階ではなく
たくさんのコミットから、ソースコードの「歴史」を紡いでいく。
そんな風に感じました。

良い意味で
カルチャーショックを受けました。

参加できて本当によかったです。

動画ではうまく画面を撮影できませんでした。
申し訳ないです。
(動画の再生回数をみてみると、皆さん3本目手前で心が折れてる様子・・(><))
分散してるけど、離散するわけじゃない、コミットを紡いで繋がっていく「歴史」の姿はなかなか壮観で、
とても興味深いデモでした。

git勉強会(動画)

1本目をUPしなおすかもしれませんが、とりあえず公開しちゃいます。
資料については、すでにはまのさんが公開をされています。

http://www.kernel.org/~junio/200810-tut.pdf
(主催者のkunitさんのブログコメントから転記)

:追記:git勉強会で検索した結果を勝手にはりつけておきます(笑)

追記
m-takagiさんが、動画の見所をまとめてくださいました
http://d.hatena.ne.jp/takagimasahiro/20081008/1223413046

設計勉強会に参加してきました。

events.php.gr.jp – Event

設計勉強会に参加してきました。
すでに発表くださった方々が資料をUPしてくださってます。

sotarokさんの資料:http://d.hatena.ne.jp/sotarok/20080927
yandoさんの資料:http://docs.google.com/Presentation?id=dct5hfpk_1p2hvp6gg

haltさんの発表。

Actionの中で、DBの処理を書いちゃってるコードがあるよ。
Viewの中でロジックいっぱい書いちゃうコードがあるけど、これってどうなのよという感じのお話でした。

Smartyは使うべき?使わないべき?という話題

  • フレームワークの便利な機能を使おうとすると、Smartyは使いにくいので使わなくなってきている。
  • Smartyは使うと重い。
  • Smartyじゃないとデザイナーがコードさわれない。
  • Smartyであってもデザイナーはコードさわれない。
  • Smartyの中でif文書くの禁止。
  • テンプレートの本来の役割は何か?
  • Viewはテンプレートのために何をしなければならないのか?

デザイナーなお仕事をさせていただく時の自分と、実際PHPでコードを書いてる時とで、矛盾があったなぁなんてことを思いました。

過去に自分自身が書いたSmartyのテンプレートに
foreachとifがいっぱい入っててしまっているダメな自分。
後でtplファイルを見た別のヒトが唖然としそうなカオスなテンプレート。
今思えばとてもとても恥ずかしいわけで、
涙が出そうなぐらいダメなわけで・・・・・

がんばれ、私・・・・

  • htmlを作らせていただくときに個人的に意識していること。

    • 位置情報としてのコード
    • 文書データのフォーマットとしてのコード
    • 役割としてのclass,ID(CSS的なアレ)
    • 無駄なid,classを指定しなくても良い、構造化されたhtmlとCSSの構造
  • 現実
    • IE6とFirefoxの挙動の差のために追加されるタグの存在(けっこう悔しい)
    • デザイン(画面絵図)とマークアップとコーディングが同時進行な罠
    • 開発途中で変わる画面デザインという罠

挙手での「現在Smartyを使っているヒトは?」アンケートがあり、結果は半分ぐらいが使用中とのこと。
全員使ってるのかと思っていたので、意外でした。

もっと既存のフレームワークの中身や構造を知っていれば、もっと参加された皆さんが話していることがわかったのではないかなという部分で、自身の勉強不足を猛反省。

Ethna的ActionとView@設計勉強会

sotarok さんの資料とお話はとてもわかりやすくて、嬉しかったです。
sotarok さんが公開されている資料の15、16、17の絵図で構造の説明があり、
その上で決まりごとのお話、
その決まりごとに対して意識されていること、
その結果と効果のお話。

感想

懇親会でいっぱいnekoyaさんとお話ができました。
WEBアプリケーションに関わるデザイナーよりな方とお話をさせていただく機会は、よくよく考えてみるとあまりなかったなぁと。
とても貴重な体験と、お話でした。

全体像を作る。
レイヤーに分ける。分解する。
パーツに分ける。分解する。
全体像をレンダリングする。

絵を描く時も設計してる。
デザインをしてる時も設計してる。
プログラムを書く時も設計してる。

もっと設計を知りたい。わかりたいと思ったことは
勘違いじゃないし、間違いじゃないんだなと思えました。

参加してよかった!

読書会

昨日一昨日と読書会に参加しました。

風邪を引いてしまったようで、超体調不良・・・・・まだ頭の中は、ぐるぐるしていて考えがまとまっていないので
内容については改めてじっくり書きます。

追記:2008.09.26
紙にノートに書いたものをスキャナで読み取って貼り付けってのもありなのだろうか・・・・・文書にしようとするとうまくまとまらない(><)