英語圏のオープンソースプロジェクトにおける翻訳ドキュメントの問題点とその解決のための一方策
(追記：2014-02-17) togglateの仕様を変更しましたので、最新情報については下記記事を参照してください。 英語圏のオープンソースプロジェクトにおける翻訳ドキュメントの問題点とその解決のための一方策（仕切り直し版） オープンソースプロジェクトの大半は英語ベースです。素晴らしいプロジェクトには大概、素晴らしいドキュメントが付属しており、そのドキュメントを読むことがそのプロジェクトに係る技術を理解する第一歩になります。しかし、英語を母国語としない私たちにとって、英語のドキュメントを通して技術を理解することには一定の困難と苦痛が伴います。 このような背景からいくつかのプロジェクトでは、多言語によるドキュメントをそのプロジェクトの一部として含んでいるものがあります。また、それとは別に有志により翻訳が別リソースとして公開されているケースもあります。このような翻訳ドキュメントの存在が非英
僕が考えた最速・最小投資でRubyを学ぶ方法またはステマ乙
そろそろ軽くRubyをやってみたいけどなんか情報多すぎてどこから手を付けたらいいかわからない、リファレンス的なものとか言語論的なものとかコミュニティー的なものとかの情報は結構あるけど、もっとカジュアルでかと言ってどの言語でも使いまわせる的な説明じゃなくRubyらしさが浮き出てるようなもので、しかもちょっとしたCLIツールとかWebアプリとかを作れる程度に理解の手助けをしてくれるものがほしいけど、今の段階で大枚叩きたくないしという人向けに僕がRubyの道案内を致します。 ステップ１（所要時間：０〜１０分、投資額：０円） あなたのコンピュータでRuby2系を使えるようにします。 Macなひと => Mavericksをインストールする。 Windowsなひと => RubyInstaller for WindowsでRuby2系をインストールする。 Linuxなひと => ご自由に。 ターミナ
怠惰で短気で傲慢な君に贈るRubyの遅延評価
Ruby2.0ではlazyというメソッドがEnumerableモジュールに追加されるらしいよ。 yhara/enumerable-lazy · GitHub lazyはリストに対する遅延評価を実現するメソッドなんだけど、それで意味がわからないって言うなら、それは、怠惰で短気で傲慢な君のためのメソッドだってことだから、喜んでほしいよ。 君のような怠惰で短気で傲慢な人っていうのは、よく次のようなことを言うんだよ。 君 「おい、雑誌持って来い！」 部下「どの雑誌ですか？」 君 「全部だよ！」 部下「全部って、日本で発行されてる雑誌全部ですか？」 君 「全部ったら、全部だよ、バカが」 ... 部下「全部持って来ました。ぜぇ、ぜぇ..。全部で、えっと..」 君 「冊数なんて、どうでもいんだよ！じゃあ、そこからＡＫＢの記事、全部切り出せ！」 部下「全部ですか... はっ、はい、分かりました...（まじ
Excelデータを最速でWebアプリ(Heroku)にする<del>１０</del>９のステップ
ローカルには映画の視聴記録とか食べ歩きのお店評価とか投資履歴とかガラクタコレクションリストとかの自身の活動記録的なデータが溜まります。そしてどういうわけかそれらのデータは大概表計算ソフト「Excel」の上に置かれているのです。その結果、溜めたはいいが有効に活用されない、場合によっては見ることすらしないという事態に陥ります。それらのデータが本来的に置かれる場所が「データベース」であり、その活用によりデータ価値が向上するということに誰も異論はないとしても、データはExcelに置かれるのです。 理由は一つ。そう、データベースは敷居が高いのです。 データベースの敷居が下がれば、みんながローカルのデータをもっともっと大量に公開して世の中はもっと便利になるに違いありません。 まあ、実際のところはよくわかりませんが。 そんなわけで… データベースの敷居を下げるべく、CSVデータを簡単にデータベース化する
あなたのプロジェクトを美しく視覚化する
(追記：2013-11-01) DirFriendのバージョンアップについての記事を書きました。 あなたはファイルシステムに美を見るか？ プロジェクトにおけるディレクトリ構造をさっと把握したいという欲求があります。そういうときは通常treeします。 % bundle gem gem_project -bt % tree gem_project gem_project ├── Gemfile ├── LICENSE.txt ├── README.md ├── Rakefile ├── bin │ └── gem_project ├── gem_project.gemspec ├── lib │ ├── gem_project │ │ └── version.rb │ └── gem_project.rb └── spec ├── gem_project_spec.rb └
Rubyのcaseを〇〇(言語名)のswitch文だと思っている人たちにぼくから一言ガツンと申し上げたい
「Rubyのcase」を一瞥し「あー要は〇〇(言語名)のswitchね」などと早合点し、その後もその真の価値を知ることなく一生を終えるプログラマが近年跡を絶たない。加えて、「今更条件分岐？RubyはOOPなんだからポリモフィズムじゃね？」とか「HashにProc突っ込んでcallするのがオレ流。」とかうそぶく人たちもまた増加の一途を辿っている。 そんな世の中にあって、ぼくは一言、できればガツンと一言申し上げたい。生まれも育ちもRubyなぼくから、是非ともそんな人たちに「Rubyのcase」について一言申し上げておきたい。 ─ 問題１ ─ 名前name、レベルlevel、ポイントpointの各属性を持った複数のCharacterオブジェクトcharlie, liz, benがある。 class Character < Struct.new(:name, :level, :point) def
((Rubyで) 書く (Lisp) インタプリタ)
Peter Norvigさんの((Pythonで) 書く (Lisp) インタプリタ)(青木靖さん訳)という記事がすごい。100行ほどのPythonコードで、Schemeのインタプリタの基本部分を書いている。Pythonのコードは見た目がRubyのコードとよく似ているので、Rubyしか知らない僕でも何となく読める。 この記事を解読してRuby版Schemeインタプリタを書いたら、インタプリタ Pyhon Scheme それからRubyのことも、もう少し分かるようになるかもしれない。こんなお得な勉強方法はないぞ。きっと。 そんなわけで… 以下では上記記事を参照しながら、Ruby版Schemeインタプリタを書いていきます。本文では適宜Norvigさんの解説およびコードを引用しつつ、自分の理解とRubyのコードをpythonのコードと対応させていきます。Rubyのインタプリタ名はlisr.rbと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
