食事を抜く、おざなりにする 朝食、昼食、夕食を熱中しすぎて抜いてしまう。ブドウ糖は蓄えておくことができません。定期的に栄養を取らないと脳がエネルギー不足となって、生産性の低下を招きます。凡ミスが多くなってくる。 きりの良いところで必ず食事をとること。食事の間隔があきすぎることがないように注意する。 生産性のないことに2〜3時間熱くなる 落ちついてコードを読み、設定を直せばすぐに解決するバグを、憶測で○○が悪いのかな？とあれもこれもと手を出すうちに2，3時間を費やしてしまい疲弊してしまう。 感情を抑え、物事を論理的に考える落ち着きを取り戻そう。 何を完了したら仕事が終わりなのかを理解していない コードを書けば仕事は終わりですか？QAやテストやドキュメントなどはいりませんか？誰に承認をえるのですか？これら、仕事として必要なことに注意を向けずに仕事を終わったと思ってしまう。本当に足りないことはあ
コミットメッセージの1行目は”短い説明” 英数字で50文字以内にすることを推奨します。短すぎてもわかりにくくなるのでいけません。 内容・理由・意味などを知らない相手によくわかるように述べること。 — せつめい【説明】 角川必携 国語辞典 50文字以内の“説明”にしてください。オレオレ語で書かれた自分しかわからないメモにしないでください。 コミットメッセージのスタイル 日本語よりも英語を利用して、行頭に動詞（現在形のみにする）を置くことを推奨します。ある程度、統一されたスタイルは容易にコミットログを理解するための助けとなります。 日本語でコミットメッセージを書くと 決済に不具合があるバグを修正しました メンテナンスモードを追加しました 日本語の場合、動詞を後ろに持ってこないと違和感ある文章になり、最後まで読まないと文章が理解できません。 英語でコミットメッセージを書くと Fix a bug
5年ほど前に「1日中ペアプロしかしないガチペアプロ」のエントリを書き、 その後も社内でも社外の開発合宿等でも 数えきれないほどのペアプロを行ったり見たりしてきたが その中で新たに気づくこともあったので、 エントリを書こうと思う。 ペアプロは、ドライバーとナビゲーターとが 二人三脚で一つのソフトウェアを作り上げたり、 磨き上げたりしていく行為だ。 二人で作業するので、ペアプロとは会話する行為でもある。 そして忘れてはならないのは、 ペアプロでの会話は聞こえている ということだ。 バグ修正やリファクタリングの際、 既存のコードを洗練させる前向きな目的で 「この箇所、ちょっとわかりにくいね。これだとバグが出やすいよね」 「ここは本当はこういう風に書いた方がきれいだね」 「この命名は誤解を招く可能性があるから、名前を変更しよう」 というような会話をすることがある。 さらに、名前から想像しにくい動き
田口さんの「Githubではなぜ人が辞めないのか？」という記事がたまたまFacebookで流れてきた。 なんと、一人も従業員が辞めてないのは凄い。本当かと思って資料見たら、創業5年で108人も従業員いるのに本当に一人もまだ辞めてないらしい。 これは本当に凄い、Githubが大いに参考にしたであろう37Signalsでさえ数人のミスマッチがあって辞めた人はいるのに。まあ、37Signalsがこういう働き方を広めて、いろいろトライアンドエラーがあったのだろうけど。 さらっと、”How Github Works”というスライドを見たのけど、こういうスタートアップが日本でもっと増えてほしい！もっとやれ！と思ったので、紹介してみる。（ちなみに、海外はこういう会社どんどん増えてきてるみたい。こうしないと、みんなすぐ辞めちゃうのもあるのだろう。） 会社によってベストな方法は違うので、全部猿真似しても上手
ハッカーと画家 ---Hackers and Painters--- Paul Graham, May 2003 Copyright 2003 by Paul Graham. これは、Paul Graham：Hackers and Painters を、原著者の許可を得て翻訳・公開するものです。 <版権表示> 本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2003 by Paul Graham 原文: http://www.paulgraham.com/hp.html 日本語訳：Shiro Kawai (shiro ＠ acm.org) <版権表示終り> Paul Graham氏のエッセイをまとめた『ハッカーと画家』の 邦訳版が出版されました。
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
BarkeepはGitリポジトリに対応したユーザビリティ高いコードレビューシステムです。 会社でプログラミングを行っているとそのコードの品質はばらつきが出てきます。そうするとバグが多くなったり、予期しない問題に直面したりします。それを防ぐのに有効なのがコードレビューです。Barkeepはユーザフレンドリーなコードレビューシステムになっています。 メイン画面です。コミットログが並んでいます。 詳細です。差分が表示されています。 サイドバイサイド。アニメーションしながら表示されて格好いいです。 コードをダブルクリックするとコメントできます。 コメントしました。 一つにまとまっている場合もコメントできます。 レビュー依頼もできます。 ステータスです。レビューされている、されていないといった情報が一目で分かります。 検索結果です。 こちらはプロフィール。 Barkeepは検索における入力補完やフィ
「同じことは同じように書く」ことがどうして大事かを説明します。 具体例: returnの有無 先日、DevLOVE運営チーム主催のリーダブルコードイベントが開催されました。イベントの前半はリーダブルコードの訳者である角さんによるリーダブルコードの紹介で、後半は参加者が「リーダブルコードとはどういうコードか」をディスカッションしました。ディスカッションでは実際に参加者が書いたコードを読みながら「ここはリーダブルだね」「ここはこうした方がもっとリーダブルじゃないか」といったことを考えました。 さて、その中で使ったコードを見ながら「同じことは同じように書く」ことがどうして大事かを説明します。ここで使うコードはdproject21/yaruo_tdd_triangleのtriangle.rbです1。 class Triangle attr_accessor :a, :b, :c def is_eq
ご献本をいただきまして、読みました！訳者まえがきに「読みやすさを扱った本の翻訳が読みにくいというのではシャレにならない」と書いてあって、気合いのほどが感じられるわけですが、さすがの角さんです、とても読みやすい翻訳のおかげで、すいすいと読み進めることができました。感謝！ 最近も、後輩が「もっとよいコードを書きたい」と嘆いている姿を見かけたところでして、そういった子には、間違いなくおすすめする1冊です！本書を読んでから自分のコードの元に帰っていったら、きっと、コードの見え方が変わっていることでしょう。 きれいなコードを書きたい 日々の中に少しでもコードを書く機会を持っている人なら、誰しもが「もっときれいなコードを書きたい」を思ったことがあるのではないでしょうか。 文章を書く人なら「わかりやすい文章を書きたい」と思うでしょうし、手書きで文字を書く人なら「きれいな字を書きたい」と思うでしょう。それ
今年は基調講演の話者に世界的なPerlプログラマーである宮川達彦さんをお迎えしたり、夜に懇親会を行ったりと、10年目を記念した特別編成になっています。 なお、懇親会ではライトニングトークの発表者を募集していますので、何か発表したい人はぜひご応募ください。その他、イベントに関する詳細は上述の公式Webサイトをご覧ください。 さて、今回はLL Decadeで実施するセッションの中から「Language Update Decade」を紹介します。 Language Update Decade Language Updateは各言語の近況を報告するセッションで、参加者にとっては日頃愛用している言語のことだけでなく、普段使わない言語に関する情報を得たり、あるいは未知の新しい言語と出会うことができます。さまざまな言語のユーザが集うこのイベントならではのセッションであり、LLイベントではほぼ毎年実施され
市谷聡啓 / Toshihiro Ichitani @papanda 今日はリーダブルコードの #devlove 97本に続いてオライリーさんと組んでやります。DevLOVEが何が出来るというわけではないのだけど、良い本が売れてそれでまた良い本が世の中に出てきたら、それだけでこういう企画をやる値打ちはあると思っているのだった。 2012-07-06 16:50:31 Ryan Edsall @rezn #devlove "@LaurentKP: @iMMMOOO that's not what I mean I'm the dev of EasySmileys and I receive good reviews because of MegaSmiley promo ℓ☺ℓ" 2012-07-06 17:15:18
なにやらMOVEが話題です。 MVC is dead, it’s time to MOVE on. http://cirw.in/blog/time-to-move-on [翻訳]MVCは死んだ。MOVEするときがきた きしだのはてな http://d.hatena.ne.jp/nowokay/20120704 Twitterで「”MOVEは生まれた瞬間死んだ” って記事まだー？」って騒いでたら「お前が書けよ」の流れだったので息抜きに書きます。息抜きなので図が無いのは勘弁してください。 MOVEが生まれていない理由 この文中ではMOVEが生まれた理由はMVCの問題点に関わるとされており、そのMVCの問題点としてされているのは次の２点です。 MVCではControllerが肥大化する MVCは10年古い技術で設計されていて、最新のプログラミングパラダイムに対応していない。 しかしこの理由のう
はじめに わかりやすいコードを書くことはソフトウェア開発において大切なことです。では、具体的にわかりやすいコードとはどんなものでしょうか？その観点はいろいろなものがあります。その中で今回は名前のつけ方に着目します。 コードに名前をつけるということ ソフトウェア開発において、名前をつける作業というのは絶えず発生します。メソッド名、変数名、クラス名、ファイル名などなど。名前をつける機会を挙げたらキリがありません。では、そもそもなぜ名前は必要なのでしょうか？ それはソフトウェアに限らず言えることですが、複数のモノを区別したいためです。例えば、まったく違う処理をする別々のメソッドに同じ名前をつけたらソフトウェアは正しく動きません。それを防ぐためにそれぞれのメソッドにちゃんと名前をつける必要があります。それぞれのモノにそれぞれ違う名前をつけて区別できなければソフトウェアはそもそも動きません。 名前を
オライリー・ジャパン高様より献本いただきました。ありがとうございます。 「The Art of Readable Code」については過去にブログで二度触れたことがありますが*1、日本語訳の出版に際し改めて紹介すると、これはコーディングに上達したい人のための本です。良いコードとは読みやすいコードである、と明確な定義をまず述べて、具体的にどのようなコードが読みやすいのか、読みづらいコードのどこをどう改善すれば読みやすくなるのかを掘り下げていきます。 この本が素晴らしいのは、徹底して具体的かつ実践的なテクニックを取り扱っていることです。ともすれば抽象的で主観的な内容になりがちなコードの読みやすさという話題を扱っていながら、豊富なサンプルコードと的確な改善例を示すことで、誰もが日々のコーディングに取り入れて毎日のコードをより良くしていけるように配慮されています。 本書で紹介されている考え方やテク
関係各所の協力により実現した1日にとても感謝している@HIROCASTERでございませう。 スタッフとして協力してくれる仲間がいたり、突発LTやってくれたりなど、Agile渋谷のおなじみのの雰囲気がアウェイの銀座も垣間見れたのもよかったです。 1日暇になったからLTやりにきてくれる仲間がいたり、おもしろかった。 Book1st銀座コア店では、Web+DB PRESSを1冊ずつ持った人が7人以上並ぶという光景があったとか。 「The GitHub」イベント詳細発表！話題のあの人が登壇 #Agile渋谷 こちらのイベントのまとめです。 感想 個人的な感想としては、やはり感じていたとおり、GitHubを使いまくってる人とほとんど使っていない人にグッサリわかれてしまっているのかなと。 仕事じゃ使えないけど、プライベートだと使いまくってるなんて、ケースはあまり聞かない。 そして、GitHubを使って
私はすばらしいコードを「エレガントなコード」と呼ぶ@HIROCASTERでございませう。 まず、はじめに。本書はハッカーは読まなくて良い。普通のプログラマに読んで欲しい。 デザインパターンやリファクタリングよりも、本書に書かれていることの方がプログラマは毎日考えて、意識してコードを書くのだ。 よって、普通のプログラマならば本書を読んでおきたい。普通のコードを書く人にオススメの1冊だ。 例えるならば、バク転や月面宙返りをする方法ではなく、日常的におこなわれる「歩く」という行動に着目し、姿勢良く、美しく、シッカリ、確実に歩くための方法が書かれている。 本書の目的は、君のコードをよくすることだ。 「良いコード」の定義とは、コードを読んだときに最短で理解できる様に書かれていることである。そう、本書は伝えている。 では、良いコードを書くための方法を具体的に学んだり、教えられたりしたことはありますか？
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
