文字化けやエラーや条件分岐でうんうん悩んだりしながら、何とか形にできましたが、今度受注するときは、もっと早く作れるようにしないと全く元が取れません…

プログラミングについてはこれまで本格的な業務にもしていなかったし、ほぼ独学でやってきました。
もちろん、基本的なセキュリティ対策はできるだけ勉強しているのですが、いわゆる「あまりサンプル集には載ってない細かいこと」がいろいろとわかりません。

開発オフに行くたびに聞くのを忘れてしまうので、めもめも…φ(。。

変数の命名ってどうしたらいいのだろう

今のところ、同じ関係のものは接頭辞を揃えて

$hogeCnt / $hogeTitle

のような感じで、二単語目以上になったらキャピタライズしたりしてます。
でも処理が長くなると、どんどん命名がぐちゃぐちゃになってきてしまって…

$fuga['cnt'] / $fuga['title']

みたいに配列で管理すべき？

データベースの接続と切断

データベースを利用するときは、まずPDOなどで接続するのですが

$piyo = new PDO('mysql:host=' . DB_HOST . '; dbname=' . DB_NAME . ', ' .  DB_USER . ', ' . DB_PASS);

一定の処理が終わったら都度切断した方がいいのでしょうか。
PHPスクリプトの先頭で接続、最後で切断…とかまずいでしょうか。

一時変数

複数の変数を組み立ててSQL文やURLを作るときは、一時的な計算のために変数を作ったりするのですが、万一のファイル改ざんが怖くて、処理が終わったらすぐunsetで消してます。

unset($hoge, $fuga, $piyo);

もちろん、クラス定義してプライベート変数にするのがいちばんだろうと思うのですが、PHPのサンプルやTIPSを見ても、一時変数はそのままになっています。
ここまでする必要はないのでしょうか。むしろ処理の無駄？

$hoge = NULL;

それとも、ぬるぽにした方がいいのかな。

三項演算子が嫌い

$hoge = ($fuga == 'abc') ? 'abcが入っています' : '別の値が入っています';

だって一行にされるとなんか読みにくいし。

if($fuga == 'abc')
  $hoge = 'abcが入っています';
else
  $hoge = '別の値が入っています';

だと、プログラマさん的には冗長なんでしょうか。

md5って大丈夫なのか

PHPサンプルで、パスワードの暗号化などによくmd5が使われているのですが、みんなが使っているアルゴリズムを取り入れてしまって大丈夫なんでしょうか。
他にもsha1とかいろいろあるらしいですが、md5が選ばれる理由って何？強固だから？

ログイン認証にはセッションに何を渡したらいいんだ

いやいやいや（°Д°三°Д°）
どうしたかは書かないです書けないです。

ユーザー登録時にDBにパスワードとは別のランダムな認証キーを保管しておいて、ログインのときはそれを発行した方がいいのでしょうか。
んー、この辺は簡単なCMSをいくつか自分で見て調べてみるかな。

難読化って？

ソースコードの著作権の話をしていたら、こいわさん(@koiwa)が教えてくれました。

それって、プログラミングでもするのでしょうか。
a-blog cmsは暗号化されていますね。でも読みにくくなった分、保守が大変そうです。

考えはじめたらどんどん出てきそうですが、この辺でやめておきます…

PEARもCakePHPも何それおいしいの？な今は、まだまだ勉強が必要そうです。
それでも、お仕事でプログラミングをすると「他の人が利用することを考える」分、確実にスキルアップできることはわかったので、これからも時間を見つけていろいろなことに挑戦してみようと思います。

Twitterで記事を紹介して下さい（-人-）

私は、Twitterでは公式のアカウント(@webbingstudio)の他に「@pianojac_fan」というのも運営しています。

最近気に入っている、インストロメンタルユニット「→Pia-no-jaC←(ピアノジャック)」を応援するために作ったアカウントで、数時間に一回

• メンバー(HAYATO / HIRO)がほぼ毎日更新しているブログの新着
• 公式サイト・メルマガ配信されるライブ情報

を、自動でpostしています。

限定グッズ販売などの細かい情報はボットじゃ無理なので、これは私が手動で更新しています。
お陰さまでぼちぼちfollowしてくれる人が増えてきたようです。

→Pia-no-jaC←はまだ新進のアーティストですが、全国にたくさんのファンがいます。
彼・彼女らはmixiに地方ごとのコミュを作って、ファン同士のコミュニケーションを取ったり、寄せ書きを集めてHAYATOとHIROにプレゼントしたりと、熱心な活動を続けています。
→Pia-no-jaC←の運営元の会社もほとんどの活動はmixiの公式コミュが中心です。

ですが、mixiは純粋なSNSですから、その活動内容が検索エンジンなどを通してWEB上に広まることはありません。
現状のファンは充分に満足しますが、私のようにヴィレッジヴァンガードから→Pia-no-jaC←に興味を持った人は公式サイトしか情報ソースがないのです。

9月にニコニコ動画で生ライブをしたとき（これも1200人が集まる大盛況でした）、→Pia-no-jaC←の二人は
「武道館でのライブを目指したい！」と宣言しました。

インストロメンタル系のアーティストが武道館って、大変な目標だと思います。
ファンが増える必要があるので、ヴィレバン・Youtube・ニコ動・mixiのどれにも縁がない人にも「→Pia-no-jaC←」の活動を伝えなければいけません。

今、最もWEBでの情報拡散力が高いのが「Twitter」です。
WEB屋として応援できることはないかしら、と思って作ったのが、Twitterの@pianojac_fanなのです。
→Pia-no-jaC←のファンのことは「→JackerS←」というので、@pia_no_jackersでも良かったかもと思ったりします。

→Pia-no-jaC←は、とにかくライブが楽しいアーティストです。
なので武道館まで行ってしまうと、正直ちょっと寂しかったりしますが、私の地味なボットがちょっとでもファンを増やす役に立ってくれればいいなと思います。

今月末には、4thアルバムやスクエニの名曲アレンジ集「Love SQ」への参加、
年末には四大都市でのツアーもあります。
お仕事のテンションを上げたい人は是非是非、→Pia-no-jaC←を聴いてみてくださいね。

Twitterで記事を紹介して下さい（-人-）

コンストラクタとかメンバ変数なんて難しい言葉使うなよー＞＜

でも、昨日の晩ふと「夕飯のメニュー」に例えて考えてみたら、ちょっと理解できたかもです。
メモしておこう。

関連：ひとり暮らしのしあわせヘビロテ食材
何故こんな記事を書いてるんだ…笑

スーパーで食材を買ってくる

夕飯のメニューは大体、スーパーに行ってから考えたりします。
思いつかないことも多いので、「使い回しのきく食材」を選びます。

この食材を「メンバ変数」と考えると

となります（たぶん）

食材からレシピをイメージする

使い回すレシピを考えるために、食材をイメージします。
これを「コンストラクタ」と考えると

です。
実際には冷蔵庫には既に調味料（しょうゆやみそ）も入っているので、継承されたクラスと考えてもいいのかもです。

定番レシピをセットしておく

上の食材があると、定番レシピがいくつかできます。
これを「メンバ関数」と考えてみると

メンバ関数に入る値は、基本的に「肉」「にんじん」「きゃべつ」でなければならないですが、
肉が「100g88円の切り落とし」でも、「100g300円の無菌豚」でもいいわけです。にんじんもブランド品だろうがキズものだろうがバラものだろうがなんでもいいわけです。
レシピさえ確定していれば。

さて作るか

で、レシピに添って食材を実際に買ってきて作ります。

レシピが確定しているので、いちいち本を読むこともなく、材料を買ってきては粛々と実行していきます。

と、ここまで妄想してみたのですが、なんか違う気がしてきました…；；
とりあえずclassの流れと使いどころは理解したので、今日のところはこれで良しとしよう…

追記：shuji_w6eさんが説明してくれました＾＾参考にどうぞ。
クラスとは変数をまとめて使う事のできるテンプレート

Twitterで記事を紹介して下さい（-人-）

沖縄県でSaaS型のWEBサービスを展開されている、AQUASYS（アクアシス）様のウェブサイトリニューアルを行いました。
所属のプログラマ様との共同制作で、デザイン・コーディング・サイト構成の改編を担当しています。

http://www.aquasys.co.jp/

この案件は、制作前のプレゼンテーション（ユルいものではありましたが）を求められました。
そこで社内の方に特に言ったのが、「現状のサイトは不安を煽る」という点でした。

前のデザインは（外注したらしいです）一見無難なのですが、コンテンツに行き止まりがあったり、サービスについて概要しか書いていなかったり、欧米圏独特の強い言い回し（AQUASYSの代表は外国の方）が残ったままだったからです。

IT企業というのは実体のないものを扱っているので、ちょっとした不安が「契約しない」という選択につながってしまいます。

とにかく、一般の人には理解しにくい「SaaS」や「CRM（顧客管理システム）」を、障害なく伝えられるかを、プログラマさんから会社としてのデザインの希望や、社内の営業計画を聞きながら制作していきました。
自分でもできるだけ、SaaSやCRMについて予習したつもりです。

制作時に、ディレクションを担当したプログラマさんに、以下のような要望を出されました。

• サイトの共通部分の管理に「Genshi」を使いたい
• Subversionでのバージョン管理に協力してほしい（TortoiseSVN）

「Genshi」はPythonのテンプレートエンジンです。基本的にはSOYCMSに似た、HTML内に属性値を書き込み内容を置換する形式で動作します。
実際の組み込みはプログラマさんに行っていただきましたが、独自タグの位置・ページ毎のHTMLの指定方法など、都度指示をもらいながらコーディングをしました。

また、Dreamweaverに入っているSubversionでは機能にまだまだ不備があって管理しにくい、ということだったので、TortoiseSVNを利用しました。

正直、これまではSubversionのメリットがわからなかったのですが、丁寧に使いかたを説明してもらって導入してみると、プログラマさんといちいち連絡を取らなくても作業を進められるし、バックアップ・復元も簡単にできるので良かったです。

今回の案件で、初めて本格的なプログラマさんとお仕事をしました。
前の記事でも書いたことですが、デザイナーとプログラマの共同作業でいちばん大切なのは、綿密なコミュニケーションだと痛感しました。

お互いの作業に関する要望を出し、どちらかが譲歩することになった場合、譲歩してもらう側は具体的な説明をする。
デザインの反映に関してはプログラマ、作業環境に関してはデザイナーの譲歩が多くなるのですが、ここで説明が足りないともやもやしたまま進んでしまうので、納得のいかないお仕事になってしまうのではないかと思います。
とにかくSkypeチャットは必須ですね。

いつもと違い勉強することがたくさんありましたが、得るものもたくさんありました。

Twitterで記事を紹介して下さい（-人-）

北海道WEBコンソーシアム定例会「デザイナー・プログラマーの連携のベストプラクティス」

WEBデザイナーは、WEBサービスやCMS等の制作で、プログラマと協業することが多くなっています。
私はまだプログラマさんとの協業経験は少ないですが、かなりの確率でトラブルが起こって、ひどいときは業務に影響するようです。
何故そんなことになってしまうのでしょうか。

今月のWEBコン定例会はLocalのPHP部と共同開催という形で、“デザイナーとプログラマの双方の不満から、それを解決するためにはどのようなことをしたらいいのかを導き出すセミナー及びディスカッション”が行われました。

セミナーでは、デザイナー側の長谷川さん（@h2ham）、プログラマ側の松井さん（@ketaiorg）がそれぞれ

1. 協業で困ったこと
2. 自分の業種側が歩み寄るべき点
3. 相手の業種側に希望する点

を挙げていきました。

…のですが、打ち合わせをしたわけでもないのに、お互いの内容がほぼ一致する結果になりました。
表にしてみます。

デザイナーとプログラマの反省点・要望は、ほとんどの形で一致しています。
つまり、お互いの歩み寄りが足りないまま協業している状況に、原因の一端があります。

これ以外の細かい部分は、

• 思想的な問題（オープンソース至上のプログラマ／著作権と意匠を重視するデザイナー）
• 業態の問題（初期から入り納品まで集中するプログラマ／中期から入り納品後も改修を続けるデザイナー）
• 金銭的な問題（長期案件をまとまった見積で請け負うプログラマ／短期案件を手頃な見積で請け負うデザイナー）
• 雇用関係の問題（プログラマが雇用側／デザイナーが雇用側／どちらもフリー）

が複雑に絡んでくると思います。
こればっかりは、コミュニケーションを重ねるしかないでしょう。

また、表を見たらすぐわかることですが、トラブルの半分は相手の性格によるもので、業種以前の問題です。
WEBコンの定例会に参加するような人たちは勉強熱心だったり、自分からコミュニケーションを望むような人たちだから、上の表に載るような人はそもそも今回のセミナーを聞いてないのです。

じゃあどうするのか。

改善意識を持ったデザイナー・プログラマが結束して、外堀を埋めてしまうしかなさそうです。
情報を交換して、協業経験をためて、ワークフローやルールを整えて、困ったさんが出たら注意できる環境を作るということです。

簡単ではないですけど…＞＜

「本当は歩み寄らなきゃならないのは、僕らプログラマの方なんだよね」

と、懇親会でプログラマさんに言われました。

確かにデザイナーはよくしゃべる人間が多いですが、それがコミュニケーション能力につながっているのでしょうか？一方的に文句言ってるだけかもしれません。

それに、私は最近の案件ではじめてSubversionを使うことになったのですが、正直「難しそう…めんどくさい（´A｀）」と思いました。実際にちょっとがんばって使ってみると、バックアップも楽だし協業相手に迷惑をかけないし、とてもいいツールなのに。

どっちかが引くのではなくて、双方が歩み寄れればいいですよね。

Twitterで記事を紹介して下さい（-人-）

株式会社えにしテック

「えにしテック」は、最近設立されたばかりの札幌の企業です。
プログラミングの会社にも関わらず、準備中の段階からデザイン会社並みのきれいなサイト。正式公開が楽しみです。

代表の島田さんと設樂さんは、プログラミング言語「Ruby」のコミュ「Ruby札幌」の主幹でもあります。
Ruby札幌が本の出版などで全国的に活動している影響もあるのか、北大生を中心に札幌はRubiestが多いです。
日本人が開発した言語なので日本語との親和性が高く、構造的にも優れた言語であるようです。

そんなこんなで私も近頃Rubyに興味を持っていて、本を読むこともあるのですが、WEBデザイナーとRubyの関わりはまだとても薄いのが現状です。

WEBデザイナーが最も関わることが多い言語は「PHP」です。著名なメールフォームやCMSののほとんどがPHPでできているし、レンタルサーバーのほぼ全てが、PHPを何の設定もなく扱えるからです。

私もある程度は習得していて、お仕事でカスタマイズの際に書くことも多いです。
それ以外の言語で普及している（というより数年前は主流だった）のはPerlくらいです。

WEBデザイナーは、覚えなければならないことがやたらとあります。
XHTML＋CSSはもう当然ですが、AdobeCSシリーズの操作、デザインや色彩の知識、アクセシビリティ、SEO・SEM、言語ではPHPだけでなくJavaScriptやActionScriptも書くことがあります。
PDFファイルの作成、CMSの構築スキルなんかもあります。

プログラマよりずっと勉強してるぜ！という意味では絶対ないです。
ぶっちゃけ「広く浅くのなんでも屋」、「いっこうにレベルが上がらないWizardryのビショップ」です。
それだけに、どうしても学習コストを考えざるを得ません。

「私たちは理論的なこだわりがあってPHPを選択しているわけではないです。現場で有用な技術やアプリがPerlで書かれていればPerlを勉強しますし、Rubyで書かれていればRubyを勉強するのです」

以前、プログラマの方に尋ねられて、そう答えたこともあります。

なので、私がRubyに期待しているのが
「WEBデザイナーがよく扱うWEBアプリケーションで、キラーアプリが出てくれること」です。
CMSだと牙城は崩せないので、オープンソース・カスタマイズフリーのフォーム、Wiki、携帯サイトの運営ツールなどでしょうか。

また「初心者がWEBアプリを作れる学習本」などがたくさん出てくれると嬉しいです。
（プログラマの皆さんはそういう本がお好きでないようです；；）
そうなったら、PHP一辺倒の市場が変わるんじゃないかと思います。実際PHPもそうやって言語的に微妙であるにも関わらず主流になったわけです。

もちろん、学習する側の努力も必要ですよね…もっとがんばらないと。

意外と知られていないことですが、ゲーム作成ソフト「RPGツクール」シリーズの近作は、Rubyで全てのイベント処理を書くことができます。

RPGツクールXP（バリュー版）

RPGツクールVX

私は元々ツクーラーで、この段階でRubyのことを知っていたのですが、結局ツクールXP以降を購入することはありませんでした。

もしツクールXPを購入して、Rubyに親しんでいたら、私も今頃Rubiestくらいにはなれていたかもしれません。
そう思うとくやしくてくやしくてしょうがないですwww

Twitterで記事を紹介して下さい（-人-）