友人の話をしよう. 先達に敬意を表し, 仮に彼を K と呼ぶ. (イニシャルは便宜的なものだ; 向上心云々と罵ったこともないし, 恋人を寝取ってもいない.) ある時期, 私は K と一緒に働いていた. 今は違う会社にいるけれど, 互いに暇なのか, このごろもよく二人で管を巻いている. 1 K は優秀なプログラマだ. いつも敵わないと思う. 一緒に仕事をしていたこともあり, プログラマとしての私は K から強い影響をうけている. たとえば私が自動テストを始めた発端には K がいる. コードレビューもそう. この日記に出てくる話も K の影響は色濃い. 私は K のあとを追いかけるようにプログラマを続けている. K と働いてはじめて, ああ, 物事とはこう改善していくものなのかと知った. 何か問題を感じると K は試行錯誤を始める. 問題は私が諦めていたものもあるし, そもそも気付かないものも
Go Conference 2014 Autumnレポート 鵜飼文敏氏「Goに入ってはGoに従え」可読性のあるコードにするために～Go Conference 2014 Autumn基調講演2人目 この記事では2人目の鵜飼文敏氏の基調講演についてレポートを書きたいと思います。この基調講演では「Goに入ってはGoに従え」というタイトルで、Go言語らしく書く方法について話がされました（スライド）。 写真1 鵜飼文敏氏の講演の様子 Go言語の可読性レビュー Go Readability Approver まずはじめに、「Go Readability Approver」と呼ばれる、GoogleにおけるGo言語のReadability（可読性）をレビューするチームについて話がありました。このチームは、コードレビューを通じてGo言語の良いコードの書き方を教えることを目的としているそうです。メンバー
Go Conference 2014 Autumnレポート Go言語の父と呼ばれるRob Pike氏による基調講演～Go Conference 2014 Autumn基調講演1人目 2014年11月30日（日）に、楽天タワーにてGo Conference 2014 Autumnが開催されました。Go Conference（GoCon）は2013年に始まり、年に2回、春と秋に開催される日本最大のGo言語のカンファレンスで、今回で4回目となります。今回は基調講演にGo言語の父と呼ばれるRob Pike氏と日本のGo言語の第一人者の鵜飼氏を招いていることもあり、今までで最も大きい規模となりました。 写真1 会場の様子 この記事では1人目のRob Pike氏の基調講演についてレポートを書きたいと思います。この基調講演では「Simplicity is Complicated」というタイトルで、Go言
Goのコードを読んでいると変数名がやたらと短いことにすぐ気がつくと思う。c, i, nみたいな1文字変数や、br, wr, errみたいな2〜3文字の変数がいたるところで使われている。これは他の言語、特にJavaみたいな言語と比べるとぱっと見でずいぶん違うところだ。 どうしてこんなに短い変数名でよしとしているの？ という疑問を抱くのはもっともなことだ。でもそれに対しては、なぜそんなに変数名が長くなくてはいけないの？ という質問を返すことになると思う。 Goは、最近では当然のものとして受け止められている（が昔は特にそうでもなかった）「プログラミングの常識」を改めて問い直した言語だ。 たとえば、複雑なクラス階層のあるオブジェクト指向言語機能は、本当にプログラミングを簡単にするのに役立っているのだろうか？ 例外機構はそれが持ち込むややこしさに見合う存在意義があるのだろうか？ ジェネリクスやテンプ
[Podcast] http://5by5.tv/changelog/100 GoogleのRob PikeとAndrew GerrandがThe Changelog PodcastでGoプログラミングについてインタビューを受けてます。 Goは３年半前に最初にリリース。Cのようなローレベル言語とRubyやPythonのようなスクリプト言語と中間の位置づけ。C++のようい何でも機能があるものではなく、シンプルであることがコアバリューで一貫性がある言語。 使ってもらうとどれだけ生産的で早いが実感できる。先日のプロジェクトで全部のテストプログラミングが8ミリ秒で実行できた。プログラマにとって効率的だが、コンピュータにとっても効率的。 Rubyのように同じことをあらゆる書き方で実現できるのではなく、一つではなくてもある程度決まった書き方でロジカルに解決するのが、プログラマー間での共通の理解、コード
私はVillehardouinが書いた第4次十字軍の年代記を少なくとも2回、多分3回読みました。それにもかかわらず、覚えている内容を全部書いてみろと言われたら、1ページくらいしか書けなそうです。このようなことが増えてきて、私は自分の本棚を見て不安な気持ちになります。内容をほとんど覚えていないなら、これらの本を全部読んだところで一体何の役に立つのでしょうか？ 2、3か月前、Constance Reidが書いたHilbertの優れた伝記を読んでいた私は、この問いに対する答えを見つけたわけではないのですが、少なくとも気が楽になりました。彼女はこう書いています。 Hilbertは、学生たちに事実を詰め込むような数学の講義に我慢ならず、問題の定式化の方法や解き方を教えませんでした。彼は学生たちに「問題の最適な定式化を行うことは、その問題の半分を解いたも同然だ」とよく話したものです。 私にとってこれは
ずいぶん前のことだが、Webアプリケーション開発フレームワーク「Ruby on Rails」が00年代後半にブームを巻き起こしたとき、強い主張を持つソフトウェアとしてRailsは多くの議論を呼び起こした。その中でも最大のものはプログラマの生産性に関するもの。当時、すでにいくつも存在していたJavaベースのWebアプリケーション開発フレームワークに比べて、Ruby on Railsは10倍の生産性を達成できるという主張だ。 Rubyの生産性はJavaの10倍――。この主張が多くのエンジニアの琴線、もしくは逆鱗に触れた。「さすがに10倍は大げさだ」、「いや、現実に設定ファイルやコードを書く行数が劇的に減るのだから、そのぐらい当然だ」と意見が分かれたのだ。 2005年のリリースから約10年。Railsの生みの親で、今もプロジェクトをリードするデイビッド・ハイネマイヤー・ハンソン氏は当時を振り返り
The Art of UNIX Programming 作者: Eric S.Raymond,長尾高弘出版社/メーカー: アスキー発売日: 2007/06/19メディア: 大型本購入: 4人 クリック: 91回この商品を含むブログ (62件) を見る TL;DR Unix Philosophyにおいては、「一つのことをうまくやり、協調する仕組みを持つ」という事が大事 Node.jsのモジュールにおいても同じで、「一つのことをうまくやる、Stream APIで協調する」と良い 「一つのことをうまくやる」にはどうするのが良いのか、ということで substack のモジュール実装例 Simple と Easyの違い ちょっと今回長くて文字が多いので、最初と最後にまとめを用意しました。時間がない方はこれを読むだけでもいいかと。 Unix Philosophy さてさて、Unix Philosoph
1分でわかるまとめ ジャック・ドーシーが紹介してた本はアメフトのマネジメントの本 著者のビルさんはNFL殿堂入りした名監督で、厳格なのが売りの人 チームでは、 Standard of Performance (SoP) こそ全て リーダーとは、SoPを定義し、行動と言葉をもって教え、SoPのチーム全体への浸透図るために、全力を尽くす存在 SoPは、以下のようなこと チームが大切にしていること チームのパフォーマンスを最高に高めるために取るべき行動 チームのあるべき姿 あなたのチームのSoPは、明確に定義され共有されているか？ The Score Takes Care of Itself: My Philosophy of Leadership Bill Walsh Steve Jamison Craig Walsh Portfolio Trade 2010-06-29 Sales Ran
はじめに「現代のベートーヴェン」と呼ばれる全聾の作曲家・佐村河内守氏が話題になっていますね。自身の楽曲のすべてを他の作曲家に外注していたばかりか、そもそも譜面は一切書けないとか、実は耳が聞こえるのではとか言われています。被爆二世とされていますが、それも怪しいのではないかと言われていますね。彼の発表した交響曲第1番『HIROSHIMA』は大ヒットし、その CD は Amazon の2013年のクラシック部門の売り上げランキングのトップにもなっていました。この作品の評判はなかなか悪くないようなのですが、それに作曲者についての「物語」がどのように影響を与えているか、様々な意見が飛び交っています。楽曲と、その楽曲の持つ物語。それらをどう受け入れるべきかは興味深い問題です。楽曲と物語とを切り離して個別に楽しむのはほとんど不可能なように思われます。一方で、物語ばかりを重視することは音楽の健全な楽しみ方
Google の使命は、世界中の情報を整理し、世界中の人がアクセスできて使えるようにすることです。
Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience. sidebar#close mouseup->tweet#update input->tweet#update keydown->tweet#update scroll@window->tweet#update" data-bookmark-id="/gettingreal"> ��6 �� s �� Getting Real The smarter, faster, easier way to build a successful web application Start reading →
技術者としての職を得てからこのかた「技術的につまらないことに時間を費やし過ぎているのではないか？」という不安がふと脳裏をよぎることがある。他の人々は、優れた技術を次々に獲得していっているのに、自分は日々をどうにかやりくりするだけで精一杯で、技術的な面で差をつけられていく一方なのではないか？という。 もちろん、一般的な意味での「仕事」において成果を出すべき道具としての技術に、つまらないも優れているもない。成果を出す技術はいつだって正しい。当たり前のことだ。ここでいっているのはそれとは別に、技術者としての個人にとっての話。まあ、技術者ならわかってもらえるだろうから、これ以上説明はしない。 そういう雑念とは無縁に、単純に好きだからとかできちゃうからとかで夢中になってやれたらいいんだろうけど、そうであるには僕は技術者でなさ過ぎる。「成果」を出すことが一番重要で、そのためにたまたま自分が少しはできる
GeekWire：失敗に立ち向かって行く勇気。誤解を恐れずに発言する勇気。そして子どものような心を持ち、世界への好奇心を失わないこと──。 米アマゾンドットコムの創業者であるジェフ・ベゾスによると、革新的なことをして成功したいと思うのであれば、あなたが経験25年のベテランでも小学校6年生でも、必要なものは同じです。 近頃完成したBezos Center for Innovationで学生グループそしてミュージアムメンバーへ向けて、どうやったら革新的でいられるのかについて自ら語った内容をご紹介。 失敗に立ち向かって行く勇気 ベゾスがイノベーターとしてもっとも大切な要素だと考えるのが、失敗する勇気を持つこと。ご存知の通り、彼が創設した会社はインターネット時代の世界を文字通りリードしてきたわけです。 「失敗することに前向きでなくては、革新的なことはできない。なぜならば前向きな意志にこそイノベーシ
俺は、2009年のクリスマス・イブ（＝これを読んでいるリアル充実の皆さんが熱い濃厚なセックスに励んでいたあの夜）に、700×23cロードバイクで四国八十八霊場・非モテお遍路さん野宿の旅へ - Blue-Periodさんの日記という記事をはてなダイアリーに投稿した。 それから4年になろうとする今でもなお、この記事を読んで、"私も自転車で逝ってきました"、"写真が綺麗ですね" というコメントをもらうことがある。四国だぜ? Blog、素晴らしい。 その頃に俺が使用していたのは、CASIOのEX-FH20というコンパクトカメラで、携帯端末を除けば、自分が初めて自分で購入したカメラだったと思う。ダイヤルを山マーク、夜景マーク、どちらにに合わせるか、それ以外はなにも考えずに撮っていたカメラである。 それとちょうど同じ年の同じ日に、カメラ・レンズの辛口レビューサイトで有名な Ken Rockwell 氏
たいしたページではありません｡ あるのは言葉だけ｡ それをあなたは読んでいます｡ オシャレなデザインや､レスポンシブなレイアウト､魔法のようなスクリプトに私たちは魅了されてしまいました｡ でも､ウェブで一番強力な道具は､今も昔も言葉です｡ 私が書いた言葉を､あなたが読んでいる｡これこそ魔法です｡ 私はブリティッシュコロンビア州の小さな都市にいますが､あなたは別のどこかにいることでしょう｡私は2013年6月20日の早朝にこれを書きましたが､あなたは違う日時にこれを読んでいることでしょう｡私はノートパソコンでこれを書きましたが､あなたは携帯電話でこれを読んでいるかもしれないし､タブレット端末やデスクトップ端末で読んでいるかもしれません｡ 私とあなたがこうして繋がることができたのは､私が書いた言葉をあなたが読んでいるからです｡ウェブとはそういうものです｡場所や端末､タイムゾーンが違っても､このシ
本人による回答です。Evan Priestley 氏は知る人ぞ知る、Facebook を代表する (元) エンジニアの一人です。Facebook には 2007 年から 2011 年の間に在籍していました。 手短かに言えば: 何年もの歳月の賜物というか。ぼくはただひたすらプログラミングが大好きで、(フェイスブックで働いていた) 過去４年間、ほとんど他のことをしていない。その前も２.５年ほどプログラマーとして働いていたし、そのさらに前も６年くらい趣味でプログラミングをしていた。ぼくは高校も大学も中退しているので、それで空いた時間もプログラミングに費やした。つい最近フェイスブックを辞めたけど、未だに起きている時間のほとんどはプログラミングだ。 もっと詳しく言えば: 月並みだが、ぼくはちっちゃい頃からコンピューターが好きで、我が家にあったヤツで（最初はMac Plusで途中からIIsiになった）
地方創生の取り組みが始まって、２０２４年に１０年を迎えました。これまでに浮かび上がった課題とこれから求められること、そして何がカギを握るのか考えていきます。
Engine YardのアプリケーションエンジニアのKevin Hollerさんが自身のブログに投稿した記事がHacker Newsで話題になっていました。記事では彼が14歳の時に始めた地元のパブでのアルバイトを通じて学んだ仕事への姿勢について触れています。バイトを始めた当初は平凡な作業の繰り返しの仕事を稼いだお金で何を買うかを考えたり、時計に注意してシフトが終わったらすぐに帰るという姿勢で乗り切っていたようです。一年後には仕事も覚え、仕事に行く事が一番大変という状況だったようです。そんな中で彼が昼休みに見かけたバーテンダーの仕事ぶりが彼の意識を変えます。 ある日曜の午後、店は殆ど空っぽで私はランチを食べながらバーテンダー達と話していた。バーテンダのうちの1人はバーを整頓するのに忙しそうで、他のバーテンダーは普通の作業をしたりすることが無さそうだった。私は何故彼が整頓に忙しいのかを尋ねると
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
