すっげー初歩的な話。初歩的すぎて『Web API: The Good Parts』にもたぶん載ってない。 あと envelop の話はあえて無視してます。envelop を付けるべきか否かはこのエントリでは扱いません。あくまでデータの話に限定しています。 まとめ自分でお手軽に作る時に key-value のデータをそのまま返しちゃう場合があるけど、これはやめた方がよい。 つい
デザインパターンのよさが分からない人は設計に自信が持てるようになるのか問題自分語りを少々。1 目の前にあった HTML と JavaScript と PHP と SQL が渾然一体となったコードと戦うことから始め、テスタブルなコードを自分が死なないように習得していった自分にとって、鬼門の一つは 再利用のためのデザインパターン だった。 何しろ再利用可能なコードなんてほとんど何もなかったのだ。そんなもの分かるわけがない。 ところが世の中の「ためになる本」はオブジェクト指向やデザインパターンの知識が前提になってしまっているところが結構あって、歯がゆい思いをすることもそれなりに多かった。 そんなところに、少ない設定、少ない知識でもプロダクティブな開発ができる Ruby on Rails というフレームワークが登場したことで、自分にできることが広がった。2 Rails の支援していないもののうち、
ちまちま各論のメモは起こしてあるけど、ざっくり全体のメモがなかったので、自分が現時点で意識していることをまとめてみた。 Vue.jsのメリットSingle File Componentが標準で扱えるSingle File Component がすべての問題を解決するとは思っていないのだけれど、まず自分は jQuery 的な DOM 要素とそのイベント中心の書き方Unobstrusive JavaScriptの組み合わせは「操作」が「要素」と密結合しているにも関わらず、コードとしては非常に距離が遠く凝集度が低すぎると考えている。HTML と JavaScript の紐付けは class や ID で行うが、ページをまたいで影響させるのは難易度が高すぎる。またコードがイベント中心かつ操作中心になりすぎてしまい、抽象度が低すぎる。本当に考えるべき状態やロジックまで意識を到達させるのはとても難しい
巨大なアクセスを抱える大規模サイトは経験ないので分かりません。 あと、本当にレガシーな PHP しか考えてません。とにかくイマドキのフレームワークを使ってください。こんなこと気にする必要ないんでしょ? 設定できるだけphp.iniに依存しないまず、PHP のコードで設定できるものは PHP のコードで設定した方がよいそうすれば複数サイトの開発のための切り替えも比較的スムーズに行えるextension など php.ini にしか書けないものは php.ini に書けばよいこれを踏まえたうえで、自分の場合はプロジェクトごとに .htaccess および php.ini を同時に生成する setup 用のスクリプトを用意している。.htaccess に書く rewrite の設定などもここで展開するようにしている。で、このスクリプトをリポジトリに入れてある。 必要に応じて RewriteBas
Welcome to Jenkins CI! | Jenkins CI なんとなく Java はメンドイという思い込みで避けていたんだけど、先週末にちょっと思い立って Jenkins のインストールを試してみた。Debian で試したところものすごく簡単だったので職場にも起こしてみることにした。 DebianにJenkinsをインストールDebian 6 にJenkinsをインストール - cactusman日誌 を参考に。 まずインストールはとても簡単。各種パッケージシステム用にパッケージが用意されてるから。 自分は Debian を使ったんだけど、上のエントリと java のパッケージが違う以外は するだけ。ここら辺とてもよく Debianize されてる印象。 Debian + Jenkins の考え方jenkins ユーザーでプロセスが動いてjenkins ユーザーのホームディレク
ついに仕事で触っている PHP のコードがほんの一部のテストとは言え CI に乗った。 正直これは感動ものだ。 今回はここに至るまでの長大な物語をダイジェストでお届けしようと思う。 有史以前PHP 3 で作られた 1 URI : 1 スクリプト + 共通関数 時代 当然のように PHP と HTML と SQL 混在まともなテスト環境がなかったので似た環境をどうにか作るパスとか絶対で埋め込みまくりなのでとりあえず共通のパス情報の変数に差し替えまくりテスト環境用のコードと本番環境用のコードが違うオール目視 つらかった。 みなさんの予想通りバージョン管理なんてものは存在しなかった。 素朴なPHPを徐々にclassにclass になれば phpdoc を書きやすくなるいきなり実行しないようにすればテストしやすくなる これは後から気づいたんだけど、結局フロントはロクに自動テストできてない一時期 p
改めて思った 2 + 1 のこと最近、人に話すことで改めて自分の思いに気づいたことが二つある。 いい仕事をしたい中小企業には時間も人手も余裕はない軽く掘り下げて書き残しておきたい。そして書いている途中で出てきたのが 老害になりたくないである。これも残しておこう。いつか振り返ったときにいろいろ思えるかもしれない。 いい仕事したいじゃん「いい仕事」という言葉はいろいろな意味を含む。人によって定義が変わってしまう曖昧な言葉とも言えるけど、ここではとりあえず曖昧なまま行ってしまっていいんじゃないかと感じている。エンジニアにはエンジニアの、営業には営業の、会計には会計のいい仕事があるはずだ。それでいいと思う。 正直なところ自分は何もしなくていいなら何もしたくない人間だ。好きなことだけダラダラできるならこんな素晴らしいことはないと思うし、それでも恐らくヒマで困っちゃうようなタイプではないと思っている。
とりあえず吐き出しメモ。 GMailGMail を通じて受信する方法が2つあるっぽい 「Forward」は Forward のタイミングでフィルタを走らせて細かい制御ができるらしいけど、とりあえず全「Import」の方針でアカウントを追加GMail を通じて送信する方法も2つあるっぽい GMail の smtp を使う方法と使いたいアドレスのオリジナルの smtp を使う方法。使いたいアドレスのオリジナルの smtp サーバの方から送信するには、そのサーバが SMTP-Auth 対応と TLS か SSL 接続が必須SMTP-Auth に対応していない smtp サーバを指定することはできないので、その場合は必然的に GMail の smtp サーバを使う その際は Sendar に GMail のアドレスが出てしまうので、どうしても表に出したくない GMail アドレスは使わないが吉。新
svnsync は subversion repository の replication ツール。Subversion 1.4 から使える。よくバックアップって紹介されたりするけどバックアップと replication はなんか違うような気がする。RAID とバックアップが違うのと同じ感じかなぁ。 目的は忘れましたなんでこんなことをしようと思っていたか忘れました。なんかでも以下のようなことを考えていたような。 Capistrano は rsync による deploy もできるけど repository から取ってくるのがやっぱ王道?でも普段の commit 作業はローカルのサーバの方が速いし快適だしsvnsync 使えばいいの?実際にやってみた意外に準備が面倒。 sync 先を svnadmin で作るsync 先の repository を手作業で sync 先として準備(後述)sy
愚痴最近は比較的自分の中では TDD のサイクルは安定して回っているんだけど、TDD でやりにくい部分についてはそれほど必死にやらないようにしている。TDD が絶対だとも思っていないし、「技法」を編み出すための時間を用意するのも正直難しい。 それでもやはりやりにくいなりに自動化したい部分はあって、その一つが各ブラウザでの検証作業。いちいちフロントエンドを直すたびにいろんなブラウザで手作業で検証するのは面倒なのでやりたくない。 以前はあまりフロントには時間を掛けていなかったというかあまりフロントで問題が出ないようにモノを作っていたんだけど、最近は JavaScript フレームワークやそれを利用したいわゆる "Good Parts" が増えてきていて、ちょっとした味付けに利用したりすることが増えてきている。 そのまま使っている場合はいいんだけど、ちょっとしたカスタマイズを加えてほしいというケ
知らなかった。もしかして Web を支える技術には載ってました?(未読) 問題GoogleAjaxAPI を使って jQuery を読み込んでいた開発、検証環境では http だが本番では https で動くhttp での読み込みを決め打ちしてたら IE で怒られた><要件schemeの変化に自動で追随してほしいGoogle Analytics とかどうしてんの? なんか scheme の判別して URL を組み立て直してるよ。あーじゃあこれ真似すればいいか、なんかでも面倒だな。 ここで神降臨! Twitter / Yosuke HASEGAWA: @wtnabe script src="//exam … @wtnabe <script src="//example.jp/foo.js">と書けば現在のschemeで読んでくれます。 ……。ほんとだ。 RFC 2396しかし実はこの根拠が分
目前の課題はともかく、今後のことを考えるとやっぱ時間の計測は必要だなと思ったので、以下を参考にとりあえず数字を入れる場所を用意することにした。 TracTicketsCustomFields – The Trac Project 入れるだけなら以下のような記述を conf/trac.ini に書けばイケる。 [ticket-custom] time_actual = text time_actual.format = text time_actual.label = 消費時間(h) time_expect = text time_expect.format = text time_expect.label = 予想時間(h) これで ticket の末尾に予想時間、消費時間がいい感じに追加される。期待通りに「予想時間」の方が「消費時間」よりも前に出てくる感じになるんだけど、なぜ
※ 2010年3月現在の話。 思い出したように Pear パッケージの話を書くけど、個人的に どうして PHPer は Pear パッケージを積極的に利用しないのか理解できない 状態が続いている。 これは pear.php.net channel のパッケージをインストールして使うという意味じゃなくて、 せっかく作ったライブラリをなぜ Pear パッケージ化しないのか という意味ね。分かりやすい例は spyc - Project Hosting on Google Code じゃないかな。 これはたぶん PHP でいちばん有名な YAML ライブラリなんだけど、このライブラリは Pear パッケージになっていないので、いろんなプロジェクトで勝手に収録している状態になっている。ライセンス的に問題ないなら別にいいんじゃないの?と思うかもしれないけど、違う。 いろんなライブラリ、いろんなフレーム
何がきっかけかよく覚えていないんだけど、この数日、急に Cucumber のことを思い出したので試してみた。 Cucumber - Making BDD fun Cucumber は一部ではとても有名な受け入れテストの記述&実行フレームワークとでも呼んだらいいのかな。有名な記事はこの辺。 Cucumberがアツい - moroの日記UK STUDIO - Cucumberの登場でRailsのテスティング環境が変わったRuby Freaks Lounge:第21回 Railsアプリの受け入れテストをCucumberで書こう|gihyo.jp … 技術評論社まだあまり詳しく本家ドキュメントを読んでないんだけど、あちこちの記事から分かることは、これは 外部仕様あるいは要件定義を共有しやすくするフレームワーク ということでしょうか。あたかも自然言語で書いたプレーンテキストがテストを動かすスクリプト
※ CPU を食いつぶしてタスクマネージャが動かない場合のことじゃありません。タスクマネージャの表示する情報だけでは問題解決に役に立たない場合のことです。 タスクマネージャは Windows を管理するうえで最も基本的なツールの一つだと思うんだけど、これ、結構役に立たないことが多い。プロセスという考え方が Un*x と違うからなのか、結局誰が悪さしてるのかが分からないケースが以前より増えているような気がする。1 ということで困ったなと思っていたら以下のようなツールがあることを知った。いやはや、もう Windows のことは分からなくなってきたなぁ。まぁ一人でなんでもできるわけはなく、どこかに力を入れればどこかはもうついていけなくなって当然なんだけど。 話がそれた。 tasklistWindows XP 以降、標準で使えるコマンドラインツール。 @IT:Windows TIPS – Know
実は今まで diff はすべてモノクロで見ていた。Emacs の vc-diff 以外では。どうにかならんかなぁと思ってはいたがこんなもんかなとも思って長いこと過ごしていた。 しかし coderepos の commit 数ナンバー1の人が github を練習したメモ - TokuLog 改めB日記 を読んで git では設定次第で color 出力できることが分かった。だったら他のツールでもそういう方法は必ずあるはずだと思ってググったらいきなり ColorDiff が出てきた。そこら中でパッケージとして利用できるみたいなので使い始めるのは十分簡単。中身は Perl スクリプトで、diff の出力を解析してエスケープシーケンスで色づけしてくれる。 使い方は
core - Apache HTTP サーバ Allow と Require の両方が使われているときの アクセスポリシーを設定します。パラメータは All か Any です。このディレクティブはある場所へのアクセスがユーザ名/パスワード とクライアントのホストのアドレスで制限されているときにのみ 役立ちます。デフォルトの動作 (All) はクライアントがアドレスによる アクセス制限を満たし、かつ正しいユーザ名とパスワードを入力することを 要求します。Any では、クライアントはホストの制限を満たすか、 正しいユーザ名とパスワードの入力をするかをすればアクセスを許可されます。 これは、ある場所をパスワードで保護するけれど、特定のアドレスからの クライアントにはパスワードの入力を要求せずにアクセスを許可する、 というようなときに使用できます ということは AuthType ... Requi
調べると session start が auto になってて必要なファイルが読み込めてませんとかいう間抜けな事例が多いこの問題は、別に session とは無関係にオブジェクトのシリアライズを使う場面でよく出くわす。 原因はいたってシンプルで、unserialize() しようとしているオブジェクトの必要としているファイルがすべて揃っていないとこういう現象が起きる。 そもそも unserialize() してできあがったオブジェクトというのはクラス名そのものは保持しているけれどもクラス定義も、もちろんメソッドも保持していないオブジェクトで、自身が保持しているクラス名の定義を、現在読み込んである PHP スクリプトから探し出して当てはめようとする。 当然この段階で include されていないクラス定義を利用することはできず、結果、__PHP_Incomplete_Class という特殊な
PHP には php -a というインタラクティブモードが一応あるんだけど、これがビックリするくらい使えない。いちばんビックリなのは readline モジュールを読み込んでいないと <?php ?> を省略できない ってこと。何それ? PHP を書くよって最初に明示してるのに <?php を省略できないとは。 これにビックリしてインタラクティブシェルを探してみたら、いくつか見つかった。中でもこれはすごい。 ~jk php shell PHP 5 以降pear コマンドでインストールでき、irb のように実行ファイルとしてインストールされるビルド時の –with-readline ではなく、readline.so を追加する形で利用できるつまり補完が効く関数の使い方をその場で調べられるどうです。なかなかすごいっしょ。 例えばこんな風に使える。 $ php-shell.sh PHP-Shel
どっかで告知出した? なんでオレ知らなかったんだろう。 openpear.org をリリースしました - riaf-ja blogopenpear :: Open PEAR Repository ChannelPerl には CPAN があります。 この言葉の本当の意味は CPAN を知らない人には分かりません。少なくとも PHP の場合、CPAN に相当するリポジトリはありません。でした。openpear.org は PHP の CPAN、と言っちゃうと大げさですが、少なくとも Pear よりは CPAN に近いものです。Pear には規律が、CPAN には自由があります。openpear.org は pear パッケージに自由を与えます。 別な見方をすると openpear.org は coderepos にパッケージングの機能が追加されたものでもあり、rubyforge や gith
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く