Creator of Ruby on Rails, Founder & CTO at Basecamp (formerly 37signals), NYT Best-selling author of REWORK and REMOTE, and Le Mans class-winning racing driver. Hunting for great names in programmingOne of the real delights of programming is picking great variable, method, and class names. But an even greater treat is when you can name pairs, or even whole narratives, that fit just right. And the
Jason Friedさんは、BasecampのファウンダーでCEOです。「Getting Real」「Remote」、そしてニューヨーク・タイムズのベストセラーで日本でも話題になった「REWORK」(邦題:「小さなチーム、大きな仕事」)の著者でもあります。本稿は、もともとIncに投稿され、Mediumにも再掲された記事をご本人から許可を得て翻訳したものです。Twitterは、@jasonfriedでフォローできます。 君はこんなことになっていない?または、他者をこんな気持ちにさせていないだろうか? グループチャットは、アジェンダのない、行き当たりばったりの参加者と共に参加する1日中続く会議のようなものだ。 2006年、僕たちは「Campfire」をリリースした。それは、SAASの現代風ビジネス向けグループチャットとメッセージツールの先駆けだった。 それ以来、Hipchat、Flowdoc
ずいぶん前のことだが、Webアプリケーション開発フレームワーク「Ruby on Rails」が00年代後半にブームを巻き起こしたとき、強い主張を持つソフトウェアとしてRailsは多くの議論を呼び起こした。その中でも最大のものはプログラマの生産性に関するもの。当時、すでにいくつも存在していたJavaベースのWebアプリケーション開発フレームワークに比べて、Ruby on Railsは10倍の生産性を達成できるという主張だ。 Rubyの生産性はJavaの10倍――。この主張が多くのエンジニアの琴線、もしくは逆鱗に触れた。「さすがに10倍は大げさだ」、「いや、現実に設定ファイルやコードを書く行数が劇的に減るのだから、そのぐらい当然だ」と意見が分かれたのだ。 2005年のリリースから約10年。Railsの生みの親で、今もプロジェクトをリードするデイビッド・ハイネマイヤー・ハンソン氏は当時を振り返り
Ruby on Rails(オープンソースのフレームワーク)の作者であり、37Signals(米のウェブアプリ開発会社)のパートナーでもあるDavid Heinemeier Hansson (デビッド ヘイメール ハンソン、通称DHH) が2008年にStartup Schoolで語ったスピーチを翻訳&書き起こし。 Ycombinator(米のベンチャーキャピタル)が主催するこのスタートアップスクールで、「ベンチャー・キャピタルからお金をもらって次のFacebookを狙うのをやめよう!」とアンチ・スタートアップ、アンチ・ベンチャーキャピタルを主張し、人が本当に幸せになれる生き方について説いた、非常に興味深いプレゼンです。 ※この記事は「TURN YOUR IDEAS INTO REALITY.」からの寄稿です。見出し等一部編集してあります。 なお、この翻訳を書くにあたって筆者がDHH氏にツ
The story of Basecamp’s disastrous policy Basecamp’s CEO published a blog post about policy changes — it may have broken the company On April 26th, Basecamp founder and CEO Jason Fried posted on his blog about some policy changes that would be happening at the company, which makes team collaboration software. One policy stuck out to many on the internet — the company would no longer be allowing it
Getting Real や Basecampなどで有名な37signals、そこのデザイナーである@jonasdowney さんがよいことを書いてらして、そうだよなーと思ったので訳してみました。英語あまり得意でないので割と勢いで適当に意訳しました。誤訳あったらすいません。 原文:Learning Rails made me a better designer by Jonas of 37signals - Signal vs. Noise (以下、翻訳)--- Railsを学んだことで私はより良いデザイナーになった Jonas Downey wrote this on Feb 22 37signalsのデザイナーはコードを書く。HTMLやCSSだけではなく、RubyやJavaScriptも書く。私たちはプログラマの手助けなしで、当然のごとく自分のアイデアを実装することができる。 新しいB
It’s been over 8 months since our workplace experiment last July, when I got an entire month to buckle down and make an iPhone app. Last Friday, Basecamp landed in the App store. It’s been a long journey of simulator runs, device testing, and app crashes, but I’m convinced that I wouldn’t have been able to ship an iPhone app at all without RubyMotion. I’ve tried to jump into mobile development a f
田口さんの「Githubではなぜ人が辞めないのか?」という記事がたまたまFacebookで流れてきた。 なんと、一人も従業員が辞めてないのは凄い。本当かと思って資料見たら、創業5年で108人も従業員いるのに本当に一人もまだ辞めてないらしい。 これは本当に凄い、Githubが大いに参考にしたであろう37Signalsでさえ数人のミスマッチがあって辞めた人はいるのに。まあ、37Signalsがこういう働き方を広めて、いろいろトライアンドエラーがあったのだろうけど。 さらっと、”How Github Works”というスライドを見たのけど、こういうスタートアップが日本でもっと増えてほしい!もっとやれ!と思ったので、紹介してみる。(ちなみに、海外はこういう会社どんどん増えてきてるみたい。こうしないと、みんなすぐ辞めちゃうのもあるのだろう。) 会社によってベストな方法は違うので、全部猿真似しても上手
Office not required. As an employer, restricting hiring to your local region means you’re not getting the best people you can. As an employee, restricting your job search to companies within a reasonable commute means you’re not working for the best company you can. REMOTE shows both employers and employees how they can work together, remotely, from any desk, in any space, in any place, anytime, a
Different models in your Rails application will often share a set of cross-cutting concerns. In Basecamp, we have almost forty such concerns with names like Trashable, Searchable, Visible, Movable, Taggable. These concerns encapsulate both data access and domain logic about a certain slice of responsibility. Here’s a simplified version of the taggable concern: module Taggable extend ActiveSupport:
David Heinemeier Hansson氏(Railsの開発者。以下DHH)が37signalsのブログに公開したRunning beta in productionというエントリによると、同社ではBasecampの開発に使われる6つのベータサーバーがすべて単一の本番環境のデータベースを参照して動いているそうです。 DHH氏曰く、「自分がいいアイデアだと思ったものが本当にそうなのかを知るには、実際のデータを対象に自分たちが日々使ってみることが必要」とのこと。 Basecampでは新機能や改良の開発、技術的なアップグレードなどを継続的に行なっており、そのために同一の本番環境のデータベースを参照する6個の異なるベータサーバーが運用されています。通常、開発中の機能は開発用のデータベースと共に運用するのがセオリーだと思いますが、DHH氏は「実際の重要なデータとともに不満を感じながら使わない
I was bouncing around the Rails API documentation yesterday, and I noticed a few rails console tricks I haven’t seen before. There’s been plenty of posts about irb and Rails before, but I’m hoping you’ll learn something new here. The following console samples were taken with Basecamp Next on Rails version 3.2.3. Dive into your app Running the app method in rails console gives you an integration se
It’s easy to convince yourself that working until your eyes bleed and your fingers cramp is simply what must be done when starting something new. You can dangle yourself the carrot that it’s just until you get out of the first hole: “Once we’re live, it’ll all calm down and I’ll be able to relax”. But that’s rarely how it goes. The reality is that you’re never going to be done. There’s always more
37signals Signal vs. Noise で投稿されたブログ記事、面白そうなので日本語にしてみた。特に許可をとってたりとかしてないし、そんな厳密に原文をなぞってないですけど、まあ緩く。原文を必ずあわせて読みましょう。 37signals でデータを取り扱う仕事の終着点のひとつとして、たくさんのバラバラの API を取り扱うことがある – 私は少なくともこの数か月間で、10以上のサードーパーティ API を利用し、それと同時に我々の持っているすべてのパブリック API と、さらに多様な内向けインターフェースを取り扱ってきた。いくつもの違った言語で書かれたラッパーを利用し、いくつかは自分自身で書いた。こんな私が API の設計 – デザインとドキュメントに関して、利用者として強い意見を持っていたとしてもおかしくはないだろう。 私の経験上、 API のユーザビリティに真に関係する要素
One of the things about working with data at 37signals is that I end up interacting with a lot of different APIs—I’ve used at least ten third-party APIs in the last few months, as well as all of our public APIs and a variety of internal interfaces. I’ve used wrappers in a couple different languages, and written a few of my own. It’s fair to say I’ve developed some strong opinions about API design
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く