Rubyでは、すべてがオブジェクト。じゃないよ！ - このブログは証明できない。
Rubyでは、すべてがオブジェクト。と説明される場合があります。確かに、「1」も「+」もクラス自体もすべてオブジェクトです。ですが、「ほぼ」すべてがオブジェクトであって、すべてではないんです。 修正(2010-04-30)： Rubyでは、メソッドはオブジェクトではありません。トラックバックで教えていただきました。また、まつもとさんも「メソッドはオブジェクトではない」と発言しています。メソッドを「オブジェクト化」することは可能です。ちなみに、Pythonの場合は、メソッドもオブジェクトだそうです。 例をひとつ。ブロックはオブジェクトではありません。 ary.each {|x| puts x} と書けますが、 block = {|x| puts x} とは書けません。 以前、このような記事を書きました。 Rubyのblock、Proc、lambdaを理解する - このブログは証明できない。
あなた以外はみんなFacebookを使っています。 - このブログは証明できない。
日本でもふつうの会話の中にFacebookという言葉が聞こえてくるようになった気がする。カフェとか定食屋とかで。Facebookが日本でも一般的な社会インフラになりうるのか。なんとなく、なりうる気がする。いまの状況って、携帯電話が普及し始めたころに似てる。 Facebookやばい。 Facebookは先日、大幅な機能追加を行った。TickerやWallでは友達の「いま」を把握しやすくなった。そしてTimelineでは、その人の過去に容易にアクセスできるようになった。APIも強化されて、Open Graphを使ったらすごいことになりそう。 Open Graph Beta - Facebook Developers 意識してないと個人情報だだ漏れな状況。Facebookが日本語対応した当時、匿名性は受け入れられないなどと言われていた。ところが、Twitterによって状況が変わったように見える。
Titanium Mobileの暗黒ノウハウを公開します。 - このブログは証明できない。
WEB+DB PRESS Vol.61の特集は、Titaniumでした。実際にアプリを作りながらのチュートリアルになっています。正統派な入門記事です。 でも。期待してた内容ではありませんでした。私は、Titaniumの暗黒面が知りたいのです。いつものWEB+DB PRESSなら、そんな記事が多いのですが、さすがにまだ開発者が少なそうなTitaniumではアッサリ目に仕上げるしかないのでしょう。そこで、このどうでもいいブログで、Titaniumのバッドノウハウ、いや、暗黒ノウハウをメモっておきます。 アプリを1本開発しただけですので、そこまでTitaniumのことを解っているわけではありません。間違っているところなどがありましたら、指摘してもらえるとありがたいです。暗黒ノウハウをみんなで共有しましょう。あと、スシなどをおごってもらえると、もっとありがたいです。 前提。 Titaniumのバー
Rubyでコマンドライン引数を扱うOptionParserが便利。 - このブログは証明できない。
夕飯を食べていて、おかずが足りないとき、納豆を出してくるかRubyでコマンドラインツールをつくるか迷うときってありますよね。コマンドラインツールでコマンドライン引数を扱いたい場合、納豆では役に立ちません。奥さん、RubyにはOptionParserがありますよ。 「-a」と「-b」という引数をとりたいとき。こんな感じで書いておきます。 require 'optparse' OptionParser.new do |opt| opt.on('-a [A]') {|v| puts v} opt.on('-b [B]') {|v| puts v} opt.version = '3.14' opt.parse!(ARGV) end 実行します。 % ruby order.rb -a "とんかつ" -b "豚抜きで" とんかつ 豚抜きで 自動的にヘルプもつくってくれます。 % ruby order.
Web Applicationを綺麗に設計するためにMVACは必要ない。 - このブログは証明できない。
MVACというアーキテクチャを解説した記事が人気っぽいです。はてな発祥なのでしょうか、解説してる記事が他には見当たりません。 Web Applicationを綺麗に設計するためのMVACという考え方 - Dive into the Tech World! 補足 - Web Applicationをきれいに設計するためのMVACという考え方 - Dive into the Tech World! この記事だけを読んだとして、結論から言うと、Aは必要ありません。ここで言うAは、MVCのMに含まれます。あえてAを分離する必要性はありませんし、むしろ、分離できるものではありません。（追記）と思ったんですが、書いてるうちに、Aの役割が曖昧だから議論できないよなという結論に達しました。 先に書いておくと、id:shiba_yu36を攻撃する気は微塵もありません。勉強熱心な人は無条件で応援したくなります
iPhoneアプリ開発者があえて言う。iPhoneは終わる。 - 医者を志す妻を応援する夫の日記
私は、もともとWindows開発者(.NET)で、パッケージ基幹業務アプリケーションのベンダーで働いていました。同時に、家ではWeb開発をやっていました。最近は、フリーランスになって、iPhoneアプリ開発がメインになっています。ところが、iPhoneアプリ開発の比重が高まるにつれ、そのことに対する不安感が大きくなってきました。最近では、iPhoneアプリ開発の比重を減らすにはどうすればいいのか考えています。 iPhone 3GSが出てから、かなり売れてるみたいですね。私の住む熊本ではiPhoneユーザーはまだまだ少ないと思いますが、企業、団体、個人によるiPhoneアプリ開発に対する関心が高まっているのを感じています。東京あたりに行くとiPhoneアプリ開発者がゴロゴロいると聞きますが、熊本や福岡では開発者が足りていない状況です。 このような状況で、なぜ私がiPhoneアプリ開発の比重を
Ruby on Railsは「えせMVC」じゃないよー - このブログは証明できない。
Life is beautifulのこのエントリーは「釣り」でしょ？ no title 先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 ということで、MVCの解説をされています。それは、OK。で、Railsが「えせMVC」だという理由。 ActiveRecordそのものはとても便利なもので全く問題はないのだが、問題はRailsの解説書などでActiveRecordを使って抽象化されたデータベースをModelと読んでいるケースが多く見受けられる点だ。 上に述べた通
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
