最近macにスイッチ中です。
mac自体は今年の4月頃に会社の同僚から売ってもらったものの埃をかぶった状態でした。
開発者の中でmacが流行ってるし、とりあえずのっとこかなと思ったくらいの動機だったので飽きるのも早かったです。
ただ、今家にあるマシンの中で一番スペックがいいのがそのmacのcore duo 1.8Gだったことに気づいてleopardを購入して、再度macを触りだすとすんごい快適！
懸念してたwindowsじゃないとできない仕事っていうのは、この記事を読んでもわかるようにけっこうないです。
web専門のプログラマには、やはりサーバーさえあればなんとかなるもんだとひしひしと感じました。
オフィス系もNeoOfficeを使えば全然問題なし。
結局bootcampもparalellsも使わず一ヶ月がすぎました。
それでも完全にmacに移行できない理由は２つ。
- adobe系のソフトがない。
- ノートなのでハードの用量が少ない。
プログラマといえども多少のwebデザインはします。
多少はGIMPでもカバーできるけど、やはり使いなれたphotoshopやfireworksがほしいが高すぎる。
用量の問題は増設したいいやん、って話だけど動画や音楽を詰め込みたいので300Gはほしい。
動画をちゃんとみるためにはLANやUSBで繋げたやつでなく内蔵型がいい。
でも、macbookでは増設ではなくリプレースになってしまうので、ここで少し躊躇してしまう。
一ヶ月後、自分がまだmacを触ってるかが楽しみ。
tracの理解度50%、subversionの理解度60%くらいの俺がまとめてみる。
まず、trackが何っていうのが曖昧だったので、まとめると３つの機能に分かれる。
自分が一番納得できた言葉は「プロジェクト管理機能」。
1,Wiki
そのままwiki
2,subversionリポジトリブラウザ
subversion、リポジトリ、ブラウザの言葉一つ一つは分かるけど、「subversionリポジトリブラウザ」といわれる分からなかった。
リポジトリ(ソースコードのDB)がWEBでみれるもの。
ソースコードそのものやバージョンによっての差分などなど。
3,チケットシステムによるBug Tracking System
roadmapが大きいタスク、ticketはそれをさらに分割したタスクってのがわかれば使っていけばある程度は分かる。
誰が何をするか？誰に何を頼むか？ってのを設定できる。
そのticketの完了具合でroadmapの進捗具合がわかる。
なので、tracとsubversionの仕組みを作ってやる。
tracとsubversionをyumでインストール
# yum install trac
# yum -y install subversion
tracのもろもろを入れるprojectフォルダを生成
# mkdir -p /home/trac/project
trac.confを設定する
<LocationMatch /cgi-bin/trac\.f?cgi>
SetEnv TRAC_ENV /home/trac/project
</LocationMatch>
<IfModule mod_python.c>
<Location /cgi-bin/trac.cgi>
SetHandler mod_python
PythonHandler trac.web.modpython_frontend
PythonOption TracEnv /home/trac/project
</Location>
# ちょっと気持ち悪いけどログインするためのIDパスを設定
# /home/www/trac/.htpasswdにIDパスを書いたやつをここで読み込む
<location /cgi-bin/trac.cgi/login>
authtype basic
authname "trac authentication"
authuserfile /home/www/trac/.htpasswd
require valid-user
</location>
</IfModule>
subvarsionのリポジトリを生成
# mkdir -p /home/trac/rep
# svnadmin create /home/trac/rep
tracを対話形式で設定
# trac-admin /home/trac/project initenv
apacheからみれるよにパーミッションを変更
# chown -R www:www /home/trac/project
# chown -R www:www /home/trac/rep
hogeにすべての権限を許可
# trac-admin /home/trac/project permission add hoge TICKET_ADMIN
# trac-admin /home/trac/project permission add hoge MILESTONE_ADMIN
# trac-admin /home/trac/project permission add hoge REPORT_ADMIN
# trac-admin /home/trac/project permission add hoge WIKI_ADMIN
もう少し理解を深めて実際いじりまくってその2は書きます。
やろうやろうと思ってやってなかったのが、このtracとsubversion
便利なのかどうなのかもわからないまま手をつけてないものに片っ端から手をつけていきたい。
とり急ぎこの相反するPHPの開発環境
eclipse(デバッグにはsambaで繋いlinuxのphpを使って)
emacs
こんな便利なのがあるとは。
pear install --alldeps pear名
高速でいいね。
find hoge | wc -l
これもいっつも忘れてしまうのでここにメモ。
sshのエラーログを眺めてたけどどう考えてもめんどい。
本番環境では使わないけどテスト環境ではこれをつけておくとブラウザにエラーが出力される。
これ忘れるの！？って言われるようなことだけど、こんなことでもがんがんブログに書かかなくては。
ini_set('display_errors', 1);
ini_set('error_reporting', E_ALL);
いっつも忘れるのでメモ。
ファイル名とか出さずにhogeディレクトリの容量だけチェック
du -sh hoge
２００６年に購入した「ほぼ日手帳」。
3日ほど、書いて自分のスタイルに合わないなーと思い放置していました。
そもそも、手帳使ってなかったし内勤なんでそんなに予定もない、どちらかというと左に週のカレンダーで右がフリースペースという形が好き。なのに買ってしまったほぼ日手帳。
2007年は手帳自体使いませんでした。
IT人ぽくgoogle calendar使ってみたりしたけど今イチ手に馴染まず挫折。
ほぼ日よりましだったけど。
そして、来年。
またしてもほぼ日手帳を買ってしまいました。
未だに自分のスタイルとは合わないと思うけど、こんなに人気があるんだから使っていけばそのうち「何か」がわかるかもしれないという安直な理由です。
きっと手帳は予定を書くものという概念が頭にあるからダメなのかな。
でも、予定以外にどうやって使えばいいのだろうとgoogleで検索してる自体おっさんになった気がする。
そして、ほぼ日に戻ったもう一つの理由が2006年に買ったカバーがもったいないから。
ほとんど個人的な備忘録。
metaタグはこれでひとまずOK
<meta name="viewport" content="width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable=no;"/>
width
touchの横幅です。現状のtouchでは320にしとけば問題ありません。
initial-scale
ページロード時の拡大縮小率です。ここでは1.0倍です。
完全にtouch用のサイトは、これ以上拡大縮小する必要はありません。
maximum-scale
拡大縮小率の上限です。ここでは1.0倍です。
ここも完全にtouch用のサイトは、これ以上拡大縮小される必要はありません。
user-scalable
ユーザーが指のタッチで拡大縮小できるようにするかを指定。ここではnoです。できません。
■appleで推奨されてる書き方です。
テキスト
テキストはすべて、黒色のHelvetica、20ポイント
テキストはなるべく読みやすくするために太字で、あまり重要でないコンテンツには標準フォント
bodyに「-webkit-text-size-adjust:none;」というセレクタをいれる。
線
項目間の区切り線はR=217、G=217、B=217
マージン
テキストは左端から10ピクセル内側に、セルの下端の線から14ピクセル内側に設定
「>」こんなマーク
セルの右端から10ピクセルに配置し、垂直方向では中心に配置。
これさえ頭にいれときゃ、iPod touch用サイトがつくれます。