フルタイムのコミッターとして企業に属しながらオープンソースのプログラミング言語を開発するということ - GeekOutコラム
卜部という名前で、マネーフォワードという会社でプログラミング言語Rubyの開発に携わっているものです。 実は、この文章を書き始めるまでにずいぶんと悩みました。というのも、これまでこのコラムに登場した他の人たちと違って、自分のキャリアというのは決して戦略的に積み重ねてきたものではないのです。そもそも初回の転職からして、やりたくて転職したわけではない。 思い返せば大学院から最初に就職した会社は、受託開発で忙しいながらも楽しく、社会人としてもプログラマとしても大きく成長させてくれた職場でした。何もなければそのまま一生そこで勤めて終わる、本当にそう思っていましたし、今でもやがては戻れたらいいなあと思います。しかし現実にはそうはならなかった。どこに行っても仕事がなく、開発者が余ってしょうがないみたいな時代があり、それが十年近く前ですけど、ありていに言えば放り出されてしまった。会社都合退職です。 しょ
Ruby on Rails の魅力と思想 - ボクココ
ども、@kimihom です。 私は Web フレームワークは Ruby on Rails を利用している。かれこれバージョン2.2 の頃から使い続けているので 7年以上になる。そこまでして私が Ruby on Rails を使い続ける魅力について個人的な想いを記していく。 Rails の作者 DHH と彼の環境 Rails の作者として有名な DHH(David Heinemeier Hansson) という名前は、 Ruby on Rails を触ったことがあるなら必ずや聞いたことがあるだろう。しかし、彼のいる会社 Basecamp がどんな想いでどんなことをしているかを知っている人は案外少ない。 Basecamp はプロジェクト管理の SaaS である。今や世界中に顧客を抱える超有名サービスであり、Basecamp は Ruby on Rails の最新版をプロダクトに反映され続けて
【翻訳】RSpecのリードメンテナだけど何か質問ある？ - Qiita
はじめに 先日、Redditでこんな記事が載っていました。 AMA: The authors of "Effective Testing with RSpec 3", Myron Marston and Ian Dees : ruby この記事は書籍「Effective Testing with RSpec 3」の筆者であるMyron Marston氏とIan Dees氏が、書籍に関する質問に何でも答えます、という企画です。 この2人のうち、Myron Marston氏はRSpecの開発者（リードメンテナ）です。 Q&Aを読んでいると、RSpecの開発者ならではの意見だなと思うところがたくさんあり、なかなか興味深い議論になっていました。 というわけで、この記事では先ほどのQ&Aから「これは日本のRubyプログラマにも役立ちそう」と思ったやりとりをピックアップして翻訳してみます。 ピックアッ
依存関係をなくそう : Rubyアプリ・Gemの開発者への提言 | POSTD
本記事はRubyについて書かれたものではありますが、Python、JavaScript、Javaなど、全ての言語コミュニティに当てはまる事実を述べたものです。依存関係が引き起こす負の連鎖は誰のためにもなりません。 上の図は、私がこれまでに使用した全てのRailsアプリの依存関係を可視化したものです。以下の例はいずれも、どこかで聞いたことのあるものではないでしょうか。 何百ものエントリを含むGemfile 本番環境で読み込まれるテスト用Gem 数百メガバイトもRAMを食うRailsのプロセス Rubygemsシステムは、それを再利用する誰もが容易にRubyのパッケージを作ることができるという点で、賞賛に値するものです。しかし、その便利さが意味するところは、そうしたGemと他のGemを非常に安易に結び付け、さらにそれが、「インターネットでダウンロード」され、数百もの依存関係を持つRailsアプ
The Ruby Community Conduct Guideline
We have picked the following conduct guideline based on an early proposed draft of the PostgreSQL CoC, for Ruby developers community for safe, productive collaboration. Each Ruby related community (conference etc.) may pick their own Code of Conduct. This document provides community guidelines for a safe, respectful, productive, and collaborative place for any person who is willing to contribute t
まつもとゆきひろ氏が「生涯プログラマー」でやっていきたい若手に贈る3つの言葉 - エンジニアtype | 転職type
2015.06.03 スキル 社会人になったばかりの若いエンジニアの中には、一度この道に足を踏み入れたからには、自らの技術一本で身を立てていけたらという、強い思いを胸に秘めている人も少なくないのではないか。 そう考えて今回、Rubyの父として知られるまつもとゆきひろ氏に、あえて「これからの時代に技術だけで生き残るには？」という偏ったテーマで取材を依頼した。返ってきたメールの冒頭にあったのが、次の一文である。 「技術だけで生きるというのは幻想である」 まずはその真意を聞くところから、取材は始まった。 まつもとゆきひろさん(@yukihiro_matz) 1965年生まれ。筑波大学第三学群情報学類卒業。プログラミング言語Rubyの生みの親。株式会社ネットワーク応用通信研究所フェロー、一般財団法人Rubyアソシエーション理事長、Speeeをはじめとした複数社の技術顧問、Herokuチーフアーキテ
プログラミングは自分がやりたいと思っていることを実現する力 - 「Ruby」開発者のまつもとゆきひろ氏
日常のあらゆる場面でコンピューターが使われるようになったこの社会で、今後、プログラミングスキルはどのような意義を持つのだろうか。世界中のプログラマに愛されるプログラミング言語「Ruby」の開発者であり、安倍内閣IT戦略本部の有識者本部員にも選ばれている、まつもとゆきひろ氏にお話しを伺った。 プログラミングという"自由さ" まつもと氏がプログラミングについて語るとき、その根底にいつも流れているのは"楽しさ"である。 「私たちは普通、なにかのソフトウェアを経由してコンピューターを使っています。でもその機能は、そのソフトが提供する範囲、そのソフトを作った人が許している範囲内に限られているんです」 たとえば文章作成ソフトを使うとき、メニューに載っている機能を選ぶ他に選択肢は無い。 「仕事で求められることができればそれで良し、という考えは当然あると思いますが、自分のできることを他人に決められるのは、
Ruby だけで経験できること - komiyak
これは Ruby Advent Calendar 2014 の6日目の記事です。 昨日は igrep さんの より「普通に」書くためのTest Doubleライブラリ「crispy」 でした。 Ruby Advent Calendar に参加するということで、 何かネタを考えなければなぁと思いつつ、なんとなく Rebuild Podcast の Ruby とそのコミュニティ界隈の話を聞いていた。 そういえば、私は数あるプログラミング言語のから、 なぜ Ruby を選んで使うようになったんだろう？ 私は普段、業務システムの開発を請け負う仕事を（SI）をしていて、 プログラミング言語は何を使うのかを自分で選べないことも多く、 雑多に言語を触ってきた。 C/C++, C#, Java, JavaScript, Ruby, PHP, Objective-C などなど。 一番好きな言語をあげるとする
Matz氏語る「今ソフトウェアはソフトじゃない」 - Engine Yard Blog
先日Rubyビジネス推進評議会主催の第3回Rubyビジネスフォーラムが大阪で開催されました。 Ruby言語開発者、まつもとゆきひろさんが、『インターネットが変えるソフトウェアとビジネス。Rubyを例として』と題した基調講演を行いまいした。 その内容を紹介します。 計算機としてのコンピューター IBMの初代社長トーマス・ジョン・ワトソンの有名な言葉に、「コンピューターは全世界で5台くらいしか売れないと思う」と言ったとされています。 その数字は当時の計算技師の人数とENIACの計算性能から導かれた数でした。 ところが、今ではその数百万倍の処理能力をもつコンピューターが何億台もあります。 去年だけでPC出荷台数は3億台。スマートフォンとタブレットはそれを超える出荷がされています。 コンピューターは計算機としてのみ使われているわけではありません。 インターネットとの接続 今日、大阪まで松江から飛行
Rack::Multiplexer - r7kamura blog
Rack::Multiplexerという、複数のRackを束ねるものをつくった。 Plack寄せ この前Perl界隈の人達と鍋を囲む機会があって、 !!1;の話、livedoor BlogのPlack化の話、ISUCONの話、 各社古いアプリ抱えていて辛いね苦しいね頑張ろうね若者に1日で書き換えさせようといった話をして、 結局、何となくこの界隈は全体的に「Plack寄せ」が進んでいるねという話に落ち着いた。 Rack寄せ 一方Ruby界隈だと比較的皆Rackに寄っている傾向にはあると思うけど、 もっと寄せてみると面白いんじゃないかと思って、Rack::Multiplexerをつくった。既にありそう。 Rack::Multiplexerは、所謂WebアプリのRouter(=Dispatcher)の処理を行うための実装で、 メソッドやパスの規則に従って受け取ったリクエストを別のRack app
RubyistたちのDRY症候群との戦い
DRY症候群 Rubyistの間では「DRY原則」が浸透しているので、彼らは重複や同じことの繰り返しを極端に嫌います。コードの中に繰り返しがあると、目や肌が乾燥してきて痒くなり落ち着きがなくなります。「DRY!DRY!DRY!」と叫び出す人もいます。アサヒスーパードライを飲み始める人もいます。これらの症状を総称して「DRY症候群」と言います。 Rubyの言語仕様はプログラマーがハッピーにコーディングできるよう考えられているので、RubyistをしてDRY症候群が発症することは稀ですが、日常的にDRY症候群を発症している人たちもいるようです。 以下は、DRY症候群を検査するためのテストコードです。コードを数秒間眺め、痒みが出てきたらあなたは重度のDRY症候群を患っています。 class User attr_reader :name, :income def initialize(name,
分別のあるRubyモンキーパッチャーになるために
Rubyのクラスはオープンです。つまりRubyのユーザが既存のクラスを開いて自由に実装を弄ることができるのです。組み込みクラスとてその例外ではありません。 既存のクラスを開いてメソッドを追加したり再定義したりすることを、業界用語で「モンキーパッチ」といいます。モンキーパッチという語には明らかに批判的・軽蔑的ニュアンスが含まれていますが、多くのRubyistはそれにひるむこと無く良くモンキーパッチします。何しろドアはいつも開いてるんですからねぇ。 るびおのモンキーパッチ モンキーパッチャー「るびお」は、製作中のライブラリで多次元配列の要素に頻繁にアクセスする必要が生じました。これには通常、Array#[]または#atを使って次のようにアクセスします。 irb> arr = [[1, 2, 3], [4, 5, 6], [7, 8, 9]] irb> arr[1][2] => 6 irb> a
ええ、ハッキリ言います。私はRubyのArray#unshiftが嫌いです。
numbers = [3, 4, 5] numbers.push(6, 7, 8) # => [3, 4, 5, 6, 7, 8] numbers << 9 numbers # => [3, 4, 5, 6, 7, 8, 9]
「壊れてねぇなら直すな」という発想はRailsにはないのかも - QA@IT公式ブログ
QA@ITはRuby on Railsで構築・運用しています。で、そろそろRailsの新メジャーバージョン、Rails4のリリースが近づいているようです（と、聞くようになってずいぶん経ちますが）。いろいろと新機能がありますが、GitHubを見ていて1つ驚いたことがあります。Ruby on Railsの生みの親のDHH（David Heinemeier Hanssonさん）が、メジャーバージョンアップとなるRails4に向けて行ったこのコミットに唐突感があったのです。よく使われるAPIの名前を、こんなに簡単に変えちゃうんだという軽い驚きです。 「壊れてねぇなら直すな」（If it ain’t broken, don’t fix it.）という有名な言葉があります。米国のジミー・カーター大統領時代の行政管理予算庁長官だったトーマス・バートラム・ランス氏の1977年の発言が人口に膾炙したもののよ
るびま
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
Rubyistになりたくて – 書評「たのしい開発 スタートアップRuby」
先日、著者である@igaiga555さんから献本をいただいた「たのしい開発 スタートアップRuby」。しかし、いつも書評を掲載していただいている「晴読雨読＠エンジニアライフ」では、別の書評がすでに公開されている。 すっかり出遅れてしまった上に個人blogへの掲載で大変申し訳ない気持ちなのだが、本書はとてもいい本なので、こちらでも書評を公開させていただく。 「Rubyist」と「Rubyプログラマ」Rubyistたちの苦悩すこしだけ昔、Rubyは「あこがれの言語」っだった。 一見簡潔ながらも使い込むほどにわかる奥深さ、DSLや黒魔術的なメタプログラミングを可能にする柔軟さ、そしてRubyを取り巻くコミュニティ活動の熱心さ。それらは先進的で開発の理想を追い求めるプログラマにとって、大変魅力的なものだった。 特にコミュニティ活動は他の言語やテクノロジに比べてとても活発で、Rubyという言語本体や
あなたが理解できない，たった一行のRubyのコード （動的言語に対する静的解析の限界） - 主に言語とシステム開発に関して
あなたは，下記のコードを理解できない。 p f /g+h/i これはRubyのコードである。「p」は，コンソールに出力する関数である。 問： だいたい，何をやっているコードですか？ ※例えば，四則演算など。 構文をおおまかに説明して下さい。 どれが変数で，どれが関数で，どれが演算子か？ ↓回答 回答： 一意に決定できない。 下記に， このコードの複数の解釈方法と， この件が引き起こす問題 について述べる。 ※なお，この問題が起きるのは動的言語に限らず，静的言語でも同様に発生しうることを前もって述べておく。 （１）分数の計算とみなすパターン 先行するコードを下記のように書いた場合： test1.rb # 変数に数値を代入 f = 2 g = 1 h = 2 i = 1 # 演算結果をpで出力する p f /g+h/i 実行結果： >ruby test1.rb 4 「分数の計算」とみなされる。
デバッグしやすいHTMLのテストの書き方 - 2012-01-18 - ククログ
注意: 長いです。 一言まとめ: withinとtest-unit-capybaraを使ってHTMLのテストを書くと問題を見つけやすくなる。あわせて読みたい: デバッグしやすいassert_equalの書き方 HTMLに対するテストに限らず、開発を進めていく中でテストが失敗する状況になることは日常的にあることです。HTMLの場合は、入力フォームのラベルを変更したり、項目を追加したら既存のテストが失敗するようになるでしょう。そのとき、どのようにテストを書いていれば原因を素早く見つけられるのかを説明します。ポイントは「注目しているノードを明示すること」です。 HTMLテストのライブラリ さて、Rubyで処理結果のHTMLをテストするときにはどんなライブラリを使っていますか？The Ruby ToolboxにあるBrowser testingカテゴリを見てみると、Capybaraが最も使われてい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Program into your language, Not in it
自分のための code を書こう
