Rails3で送信するメールの本文をbase64ではなく8bitにする方法 - 思っているよりもずっとずっと人生は短い。
メモ。一つ謎が解けたので。 Rails3ではメールを扱うクラスがTMailからMailクラスに変わりました。そのせいか、素朴に日本語のメールを送る場合、文字コードはISO-2022-JPではなく、UTF-8になります。まあUTF-8になるのはいいとして、問題はこれがbase64なのでした。ううむ。 この辺りはMail::Messageクラスの挙動になるっぽいのですが、メール送信時にContent-Transfer-Encodingヘッダを指定することはできます。 # UserMailerクラスのメソッドの中の定義 mail(:to => email, :content_transfer_encoding => '8bit', :subject => I18n.t("hoge")) ところが、ここで設定しても、実際に送信される時にはbase64になってしまうのでした。うう。 というわけで困っ
Pythonな人とRubyな人の違い - 思っているよりもずっとずっと人生は短い。
柴田さんの「Python 3.0がここ数年は初心者に非推奨なたった一つの理由」を読みました。 「Python 3.0がここ数年は初心者に非推奨なたった一つの理由」 手前味噌ですが、先日のるびまの巻頭言と比べると、Pythonな人とRubyな人の違いがよく出てるんじゃないかなあ、という気がしました。ちょっと偏見が入っていますが。 両者は、どちらの方が良いか、みたいな話ではなく、あくまで適性というか、求めるもの、目指すところの違いの話で。たぶん二人とも同じ光景を見てるんだと思うのですが、私が「1.8.6もいいけど、やっぱり1.9.1もいいよね」と表現するところを、柴田さんなら「1.9.1もいいけど、やっぱり1.8.6もいいよね」と表現するんだろうなあ、と。でも、私の知っているRubyistなら、後者ではなく前者の表現を好みそうな気がするのです。同様に、Pythonな人の間では「2.6もいいけど
2008年に出版されたもっとも大切な一冊 - 思っているよりもずっとずっと人生は短い。
メモ。 どうにも書けなくてずっと日和っていたのだけれど、これを書かないと先に進めないので、あきらめて書く。 2008年はぱかすか新刊本を買いまくった。ので、それなりに思い入れのある本はたくさんある。でも、再刊を含めてよいのであれば。この一冊に勝るものは、ない。 ひとめあなたに… (創元SF文庫) 作者: 新井素子出版社/メーカー: 東京創元社発売日: 2008/05/29メディア: 文庫購入: 6人 クリック: 35回この商品を含むブログ (54件) を見る ……もっとも、私が読んできた本の中でももっとも思い入れのある本であり、これに勝る本を読むことはおそらく一生ないと思っているので、当たり前と言えば当たり前。 それでも、長らく入手困難が続いていた本書が、装いもあらたに、そして文章にも手を入れて、新しく刊行されたことは、本当にうれしいことだった。 で、もちろん再読した。やはり、読めてよかっ
Rubyist Magazine 25号公開 - 思っているよりもずっとずっと人生は短い。
http://jp.rubyist.net/magazine/?0025 リリースされました。みなさまどうもおつかれさまでした。 ある意味、Ruby 1.9.1リリース記念号みたいな感じになりました。本文で一つ選ぶなら、「Ruby M17N の設計と実装」でしょうか。このタイミングでこれが出せたのは非常によいことだと思います。 ところで。 巻頭言は締切をだいぶ過ぎても書き終わらなかったのですが、刊行予定日直前にRuby 1.9.1がリリースされ、感極まってそれまでの書きかけを全部捨てて書き直したのがこれ。いやはやご迷惑をおかけして申し訳ない。 http://jp.rubyist.net/magazine/?0025-ForeWord 新井素子全開。泣きながら巻頭言を書いたのはひさしぶり。万感の思いを込めて書きました。終盤は論旨もおかしくなって、文体にも電波がゆんゆんしてるのは仕様です。感極
RubyConf2008のLTで、Yuguiさんとitojunさんについて話してきました
なんかもうタイトルだけで十分という気になってきましたが、一応説明も。 毎年参加しながら、まともに会話もできず発表もせずという状態では、何しに行っているのか分からないというか、なんで自分はこんなことしてるんだろうと異国の空の下で思ったりしないでもないRubyConfなので、今年はLTをやるという話を聞いて何か話をしないと、と思ってました。が、実のところ自分のプロダクトがあるわけでもなく、また日本の状況の紹介をしても受けないらしい（正直みんな興味ない、というのが２年前の発表で判明した）ので、話す内容に悩んでいました。 が、ふと「日本には興味なくても、自分が使ってるプロダクトの作者が日本人なら、そのひとへの興味はあるはず」と思いつきました。とはいえ、よくRubyConfに来ている人はさておき、たとえ日本では有名でも海外ではそれほど、という人は紹介しても仕方なさそうです。そこで考えた結果、Yugu
『初めてのRuby』についてひとこと - 思っているよりもずっとずっと人生は短い。
トークイベント前に読んだ印象を書いておきます。 『初めてのRuby』を読んで一番感心した点は、コードの説明をしないこと。Rubyが初めて、というひとに対し、Rubyの構文の説明もせずにコードを見せ、そのまま放置して先に進む、というスタイルは意表をつかれた。これは私には書けなかったな、と思った。 『初めてのRuby』は、おそらく基本的には「50000フィート上空から眺めたRuby」、なのだろう。Rubyの全体像を、ある程度「わかっているひと」向けに説明するには、それくらいの高度からの展望を一瞥させるのがいい。 もちろん、これはいわゆる普通の初心者には厳しいのではないか、と思う。きっととりこぼしてしまうところが少なからずある、と思う。ちょっともったいない。ので、もう少していねいに説明を書くべきではないかと思ってしまう。それによってスタイリッシュさが多少失われてしまうかもしれないが、読み手の得ら
優れたチームのリーダーは自らが効率化を求めるべきではない - 思っているよりもずっとずっと人生は短い。
メモ。 メンバーが優秀であれば、最適化は原則メンバーに任せるべき。リーダーのするべきことは、評価関数を作り、示すこと。 ある程度以上の権限を持っているリーダーは、いざとなれば評価関数を自由に設定・変更できるはず（状況によってはそれをしなければならない立場にある）。そういう役割の人間が「勝ち」を求めるのはよろしくない。そうではなく、適切な勝利条件を示し、そこを目指せばよいとメンバーやその他関係者に示すべき。そしてそこを目指すことはメンバーに委ねる。 メンバーが優秀であればメンバーがなんとかしてくれるし、メンバーの力に余るのであればリーダーだけが頑張ったところでどうにもできない。 メンバーが優秀でない場合、メンバーに合わせて評価関数を変えるか、評価関数に合わせてメンバーを変えるべき。どちらが良いかは、プロジェクトの目的、あるいはプロジェクトを実行することの目的（プロジェクトに対して一つメタな目
2008-02-28
（なんか更新しなくても勝手に上に上がってくるので更新してみます。） 「東浩紀２ちゃんねる降臨まとめ」より。 http://d.hatena.ne.jp/sirouto2/20080123/p2 ＞小松左京先生は戦争がなければSFにいかなかったと発言されましたが、 ＞東さんは「これ」がなければ現代思想にいかなかったものはありますか？ 作家名なら、小松左京、新井素子、押井守。これはまじです。 そして彼らがもともとベースなので、現代思想からも外れるのだと思う。 ここで素子さんの名前が出てくるのか。すばらしすぎる。 東さんは今号の「ミステリーズ！」にも素子さんについて書いてるんでしたっけ。早く読まないと。東さんの素子さん論なら、心の底から嫉妬できそうですごくすごく楽しみです。 http://www.hirokiazuma.com/archives/000367.html http://fizzbu
2008-02-01 - 思っているよりもずっとずっと人生は短い。 - MatzはSHOCK
今さらの件について。 一部では誤解があるかもしれないのですが、まつもとさんという人は、普段は温厚そうに見えても（実際温厚だと思いますけど）、プログラミング言語に関してはモヒカンなひとなのです。そして、プログラミング言語コミュニティというサザンクロスシティでは箸を上げ下げするような感覚でハンドアックスを飛ばしあっているわけですよ。なんでPHPとかはいいエサ状態になってしまっている、と。 加えて単に客観的な論評だけでなく主観的な主義主張も披露したがる（ヲタだから）わけで、もちろんそれらを混同したりはしてないかもしれませんが、ハタから見てると「おまえがいうな」的なこともありますよね。 あと、Matzは影響力が……とか言ってる方もいらっしゃいますが、なんせまつもとさんの周りにいる言語屋さんも、海外を含めれば影響力ありまくりなひとばかりなわけで（Dave ThomasとMatzの影響力を比べてみてや
2007-12-28
遅ればせながら、ようやっと1.9.1、じゃなくて1.9.0がリリースされました。www.ruby-lang.orgのアナウンスも最初に書きかけたときには1.9.0に気づかず1.9.1とか書きそうになったよ……。 そういえば、某所の記事に某所で批判が出ていたので、ちょっとアレンジしてみました(よりいい加減になったような気もするけど気にしない)。 Ruby 1.9.0登場、一気に非互換アップ - 開発者は人柱検討を 25日(日本時間-1時間)、当初の予定どおりRubyの最新版となるRuby 1.9.1ではなく1.9.0が公開された。Rubyはオブジェクト指向スクリプト言語。当初からオブジェクト指向設計はよく知らないけどオブジェクト指向プログラミングは大好きという作者の趣味に基づいて開発されたプログラミング言語で、簡単に「オブジェクト指向じゃないとプログラムが書けなくなる」というオブジェクト指向
2006-09-04
nil and FALSE (http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-list/52?1-217) [ruby-list:384] Re: bug report#3 and request#5 (http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-list/384?203-419) [ruby-list:11037] Re: inspect, to_s (http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-list/11037?10856-11769) 竹岡美穂と言えば当然 [cobalt] としたくなるのだけど、本自体はコバルトじゃないだった。悩む。 http://local.joelonso
2007-06-29
土曜日は札幌に帰ります。日曜日には東京に戻る予定。 http://blog.livedoor.jp/kazhik/archives/51051450.html http://amigomr.dw.land.to/blog/article.php?id=417 http://d.hatena.ne.jp/smellman/20070627/1182960138 もじら組の組長さんとはさほど親しくはないのですが、イベントなどではよく見かけていて、活動的な方だなあと思っています（少なくとも私よりはずっとオープンソースなイベント等で活躍されているはず）。そのような方が、このような言葉を書かなければいけなくなったのは、非常に残念です。 思うのは、「多数決」という手段のそぐわなさ。信頼関係で結びつく小規模集団にとって、多数決というのは致命的に向かない手段なのではないでしょうか。一人の代表が全ての責任を
小飼弾氏の『Rubyクックブック』評に反応する - 思っているよりもずっとずっと人生は短い。
とちぎに行ってきました。toRubyのみなさま、artonさん、どうもありがとうございました。 ※あらかじめ断っておくが、この件に関して私はまったくもって中立でも無私でもない。さらに、出版社の事情・思惑などもよく知らない。限定された情報のみを元にした、利害関係のある、偏った立場の者の意見としてお読みいただきたい。 わかっている わかっている わかり過ぎる程わかっている でも今日も 日々に追われ だから人間っていとおしいもの ――篠原美也子『誰の様でもなく』より http://www.room493.com/discography/tsuki.html#10 別に私が「日本のRubyコミュニティ」を代表しているわけではないのだが、とある日本のRubyコミュニティを代表する立場でもあり、また当該書籍にはいくばくか関与していたりもする。そのような背景を踏まえつつ、日本のRubyコミュニティに属す
ポストモダンプロジェクトマネジメント - 思っているよりもずっとずっと人生は短い。
メモ。この前角谷さんと話した内容を下敷きに。 プロジェクトマネジメントはポストモダン化しつつある。 キーワードは「感情管理」。近代的なプロジェクト管理では、作業者は機械と同様、定量的なタスクをこなす装置（機械）と考えられていたが、現代的なプロジェクト管理では作業者の感情にフォーカスする。これはチームのメンバーにもリーダーにも当てはまる（リーダーの方がより強くあてはまる）。 ポストモダンプロジェクトマネジメント技法の代表例としてコーチングとファシリテーションが挙げられる。前者は規律訓練型、後者は環境管理型の側面が強い。コーチングが主にリーダーに対し、その振る舞いを規定し、強要する一方、ファシリテーションではその意図を不明確に・あるいは隠蔽し、メンバーの感情を暗黙のうちに管理しようとする。高度なファシリテーションではリーダーすらも暗黙のうちに管理されるようになる。 プロジェクトマネジメントがポ
Softbank対応(たぶん)携帯キャリア判別クラス
PerlとPHPを参考に。 こんな感じですかね。帰ってくる文字列はまだVodafone名ですが(Softbankに変更すべき？)。 class MobileDetect DocomoReg = %r VodafoneReg = %r<(?:(?:Softbank|Vodafone|J-PHONE)/\d\.\d|MOT-)> EzwebReg = %r<^(?:KDDI-[A-Z]+\d+[A-Z]? )?UP\.Browser\/> AirhReg = %r<^Mozilla/3\.0\*1> def self.detect(user_agent) if MobileReg =~ user_agent return 'DoCoMo' if $1 return 'Vodafone' if $2 return 'EZweb' if $3 return 'Airh' if $4 end ret
GettextScaffold Plugin
日本語でのRails開発の生産性を3倍高めるためのplugin(嘘かも)。 http://rubyforge.org/projects/gettextscaffold/ Subversionが使える人は、以下から持っていけます。 svn://rubyforge.org/var/svn/gettextscaffold/gettext_scaffold Railsからなら、script/pluginを使って、 ruby script/plugin install svn://rubyforge.org/var/svn/gettextscaffold/gettext_scaffold でいける……といいなあ(自信なし) Ruby-Gettext-Package自体は事前にインストールしておいてください。
ブロックされました
メモ。 志の高い人を雇いたがるのは、志の高い企業のするべきことなのだろうか。志の高い企業は、ふつうの志の人を雇い、高い志を持たせるような企業ではないだろうか。あるいは、ふつうの志の人を雇い、ふつうの志のまま、よい仕事をさせるような企業ではないだろうか。 優れた人を雇いたがるのはよいことなのだろうか。それは極論すれば、優れていないひとはどうでもいい、ということなのではないか？ そのような企業で働きたいと思うだろうか？ そのような企業で働きたいと思う人ばかりの社会で生きていたいと思えるだろうか？ ふつうの人が9時から6時まで（または10時から7時まで）、ふつうにプログラムを書いていればふつうに生活ができる、という世界の実現は困難なのだろうか。 今のソフトウェアエンジニアリングはふつうの人に辛すぎる。ここで言う「ふつうのひと」とは、たとえば「基本的に自分で本を買わない」「就業時間以外はプログラム
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
