githubって色んな機能がありますが、好きな機能のひとつが、READMEを置くと勝手に表示してくれる機能。(README.rdocとかでもいいみたいです)
これってRailsプラグインだと”“init.rbにプラグインインストール後にコンソールにREADMEを表示するように書いておく”“なんて慣習もあるので1人3役みたいでお徳な感じです。
プラグインやライブラリを探す時なんかはどうせプログラマー向けなんでREADMEさえ出てれば必要十分で、Wikiすら見なくていいので便利です。
githubって色んな機能がありますが、好きな機能のひとつが、READMEを置くと勝手に表示してくれる機能。(README.rdocとかでもいいみたいです)
これってRailsプラグインだと”“init.rbにプラグインインストール後にコンソールにREADMEを表示するように書いておく”“なんて慣習もあるので1人3役みたいでお徳な感じです。
プラグインやライブラリを探す時なんかはどうせプログラマー向けなんでREADMEさえ出てれば必要十分で、Wikiすら見なくていいので便利です。
まだこのサイトへのコメントの実装方法を考えています。
調べていたところ、JS-Kitのやり方にとても感心しました。
JS-Kit: CommentsをカスタマイズするRSSをセットアップする。
以下のURLを使えば、RSSを通じて全部のコメントがアクセス可能になります。:
http://js-kit.com/rss/your.site.com/path
pathが、有効なpermalink属性あるいは有効なpath属性の値のどちらかである場合。
別のやり方として、DNSエントリーを設定する方法もあります。:
js-kit.your.site.com. IN CNAME js-kit.com.
シンプルなのにスゴイ分散システムです。DNSとHTTPで大抵のことが解決できるんですな。
さっそくJS-Kitを使ってみたんですが、どうも機能が多過ぎて気に入らないところが色々。単に見た目とかの問題なんですが。最初はシンプルだったんでしょうが、商売にしようとするとこうなっていくんですかね。
自分で似たようなものを作るか・・・? いや、しかし・・・。
このサイトもAutoPagerizeに対応してみた。
面倒かと思ったらwill_paginateプラグインは最初からrel=”“next”“が設定されてるのでスゴイ楽!やってよかった。
このサイトのコメントの実装についてまだ悩み中です。
テキストの抽象化 – p0t構造化/非構造化テキスト
テキストには構造(親や子となる何か)を持つものと持たないものがあるようです。一般的なブログコメントはブログエントリを親に持つテキストということになる。
実際に実装しようとすると、テキストを構造化していない(構造化テキストを扱わない)ことが現在シンプルでいられる一番の理由だということがわかった。
非構造化テキストと構造化テキストをわけつつ、直交性を保ったまま統合する方法を考え中です。
簡単SQLite設定
SQLiteはDBがファイルだからCapistranoで困る。
# config/database.yml
production:
adapter: sqlite3
database: ../../shared/production.sqlite3
pool: 5
timeout: 5000
productionだけsharedに置けばOK!
svnをexportにする
vi config/deploy.rb
:deploy_via, :export
ここにコメント機能を追加しようとしてまた悩んでしまった。
「コメントって何?」
テキスト/ドキュメントの定義を”“ある程度の長さと意味を持つ文の集まり”“とするならコメントもテキストだ。日頃よく扱うテキストの種類を考えてみた。
現状このシステムで扱えるのは1と2だけだ。他のテキストも扱うには特徴を調べて抽象化する必要がある。
テキストが持つデータ
構造化/非構造化テキスト
テキストには構造(親や子となる何か)を持つものと持たないものがあるようです。一般的なブログコメントはブログエントリを親に持つテキストということになる。
メモやブログは基本、親を持たない。 つぶやきは時に他のつぶやきを親に持つ。(返信) メールは時に他のメールを親に持つ。(返信) チャットはスレというテキストを親に持つ。
テキストの指向性
テキストが”“誰が誰に向かって書いたのか”“という指向性の概念を取り入れると複雑化する。なぜなら、閲覧・編集権限が変化するからだ。また”“テキストの作者”“というリソースも新たに定義する必要がある。
ここは思い切って、”“作者とは名前とプロフィールで表されるテキストである”“と定義してしまえば単純化する。(匿名はAnonymouseリテラルで表現する)
各作者が使えるメソッド
認証したものはプライベートなテキストも含めた閲覧、作成、更新、削除ができる。(通常のブログポスト) 認証してないものはパブリックなテキストの閲覧、作成(POST)ができる。(コメントやメール送信)
![]() |
|
これからCakePHP使うので借りて読みました。分かりやすかったです。1.2が出そうなのだとしたら読むタイミング悪かったかな?
郷に入っては郷に従え。
ディストリビューションの流儀に従ってSSL自己認証。
これでDebian原理主義者の先輩にも気に入られること間違い無し。
a2enmod ssl
a2ensite default
make-ssl-cert generate-default-snakeoil
「スネークオイルって誰ですか?」
などと質問すればポイントアップ!
# /etc/apache2/ports.conf
Listen 80
Listen 443
気を抜いてコレをapache2.confに書くと嫌われるぞ!
# /etc/apache2/sites-available/default
NameVirtualHost *:80
<VirtualHost *:80>
...(snip)...
</VirtualHost>
NameVirtualHost *:443
<VirtualHost *:443>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
</VirtualHost>
デフォルト期限の30日が嫌だったら /usr/sbin/make-ssl-cert をチェック!
.box {
border-radius: 15px;
-webkit-border-radius: 15px;
-moz-border-radius: 15px;
}
TwitterもIE諦めてこれ使ってる・・・。
Suppression of double printing by ATM二重印字防止
問題は、移行期間である。ATM 導入以前の通帳には磁気ストライプがない。取引内容を印刷すべきページと行の検出には、磁気ストライプに頼れない。新型用の通帳でも、旧型の端末で印字すると、磁気ストライプの情報と実際の印字行数が異なる。
既印刷行の上に二重印字すると前の取引の内容が消えるので、銀行としては絶対に許せない。既印刷行の次に空行があると、銀行の信用にかかわる。
したがって、通帳の型いかんに関わらず、最後の既印刷行を確実に検出する必要がある。 検討の結果、通帳の各行を光学的にスキャンして既印刷行をスキップし、最初に現れた空行に印刷するというのが結論だった。
この技術の開発を私が命じられたが、見事に失敗した。私の能力不足もあるが、お偉いさんの一言もかなり関係する。あるお偉いさんは顧客に向かって「端末のインクリボンは百万字まで使えます」と断言したらしい。
ATMでの通帳記入でどうやって最終行から印刷するのかという話。
たしかに少し疑問に思ってた。これ自体かなり昔の話なので最近ではどうなってるのかな?
感心するのは、技師というのは物理的なものもひっくるめて問題を解決する仕事だったんだなあ、ということ。
「未経験のOS/言語/ミドルウェアだから無理」
なんて言ったらぶん殴られそうだな。