レガシーコードを糾弾する人は、そのコードがもたらす不利益ばかりに目を向けがちだけど、そのコードがどれだけ価値を生み出してきたのかに敬意を払うべき。最新の技術と価値観で、古きものを貶めるのは簡単だけど、古くて、汚くて、でも沢山稼いだコードは、すごく尊いものだと思う。何で古くなってしまったのか、なんで汚くなってしまったのかを考えるべき。経済的な価値を生む事が工学の本質だし、美しくあり続ける事を目的にするのはアートであってもエンジニアリングではない。
プロジェクトホスティングサービスで高い成長率で注目を集める「GitHub」(ギットハブ)。2008年4月の一般公開から5年足らずで利用者数が300万人を突破(2013年1月中旬)した。これはソフトウェア開発者向けサービスというニッチ市場では破竹の勢いといっていい。2012年7月には有力ベンチャーキャピタリスト、アンドリーセン・ホロウィッツを中心に1億ドル(約91億円)という大きな投資を受けて注目を集めた。 GitHubがローンチした時点で、すでに同類のサービスは多くあったが、過去5年を見れば、一人勝ちといっていい勢いだ。この強さの秘密は何なのか? 来日中のGitHub共同創業者らに話を聞いた。 Googleトレンドを使って、「github」「gitorious」「bitbucket」「sourceforge」「codeplex」を検索ボリュームの推移を比較した。青線のGitHubが類似サー
あらすじ 人の綺麗なコードを読みまくると自分のコードも綺麗になっていくのに、イケメンを見続けても僕の顔が良くならないのは何故なの?? 2012-11-30 19:41:20 via web 今まであまり人のコードを読む習慣というか機会というかがあまりなかったのですが、最近になって、デスクの上がヨドバシのiMac売り場みたいと(僕の中で)話題沸騰中の@mitukiiiさんのコードを読む事があり、この人がまたすごく綺麗でスタイリッシュなコードを書くわけで、その時に、綺麗なコードというのはこういう感じに書くものなのかと結構な衝撃を受けたわけです。 またこれも最近なのですが、別の機会で、なんと言いますか、1つの関数が数千行あったり、しかもその内の大部分が共通処理として括り出せるような恐らくはコピペされたであろう部分が大量に入っていたりまぁ不可解な部分の多い、言うなればイケメンを見続けた僕みたいな、
「ウェブオペレーションエンジニアはリリース前のソースコードのココを見る!」みたいな記事があればいいね — masahiro nagano (@kazeburo) November 20, 2012 ちょいと前にツイートしたこの件のまとめ。新規サービスのリリースや既存サービスに新しい機能が追加される際に、しばしばそのソースコードを確認しているのですが、僕がどんなところを見ているのかまとめてみました。 そのサービスへの導線とランディングページの確認 まず、そのサービスへの導線やランディングページを確認します。そしてその一番アクセスがあろうページ、一つか二つに確認対象を絞ります — masahiro nagano (@kazeburo) November 20, 2012 どんな素敵なサービスも、機能も適切な誘導がなければ使われる事はありません。また誘導次第では大量のアクセスが一度にサーバに対し
SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。
注: 記事中の「解説」の部分のライセンスは「Creative Commons 表示 - 非営利 - 継承」です。「解説」は「クリアコード」(「ClearCode Inc.」)によって変更されています。変更前の原著作者は「オライリー・ジャパン」です。「Creative Commons 表示 - 非営利 - 継承」なので再配布や変更や翻訳などはライセンスに従って自由に行えますが、営利目的で利用することはできません。 https://amazon.co.jp/dp/B0064CZ1XEの翻訳である「リーダブルコード」が今月(2012年6月23日)発売されます。すでに予約できるようです。 https://amazon.co.jp/dp/4873115655 本書の内容は原書の紹介記事を参照してください。 日本語版の訳者は角さんです。これまでの訳書と同様にとても読みやすく訳されています。翻訳なので読
コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式 コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque
「なんだこの糞コードは!(怒)」「書いた奴出てこい!(怒)」 こんな声を聞いたり、叫んだりしたことはありませんか? ウンコードについて学ぶことによってウンコードを撲滅しましょう! とりあえず、趣のあるウンコード鑑賞から始めて下さい お知らせ 2013-06-27 profile image をTwitter API1.1に対応しました。Thanks for Profile Image API For Twitter 2013-06-16 Twitter API1.1に対応しました。 2012-12-05 職人ランキングを追加しました。 2012-11-21 レコメンド機能を追加しました。 Twitterアカウント @unkode_mania で更新情報をつぶやいてます 障害情報 2012-08-14 障害情報: 19:20 - 21:59 くらいの間、internal server err
こんにちは、SHIMADAです。 今日は現場の泥臭いRSpec話を書きます。 新しいフィーチャーを追加するとき、specがなかなか通らない、実装が思い通りに進まない、ということがありますよね。 そんなとき、自分の書いたコードが実際にはどう動いているのか確かめる方法が欲しいです。 一番簡単で広く使われているのはデバッグプリントという手法です。 コードの中に p 変数名 と書くと、specの実行途中にその変数の中身がどうなっているか確認できます。 ここで問題になるのが、specがたくさん書いてあるとデバッグプリントが一杯出てきて肝心の調べたいケースが埋もれてしまうという点です。 ちなみに今携わっているプロジェクトのspecを見てみると、examplesの数が1,000を超えてました。 これが一般的な水準で多いのか少ないのか分かりませんが、ここまできてしまうとデバッグプリントがどかどかっと表
Latest topics > FirefoxやThunderbirdを必ずクラッシュさせるコード 宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! « tabFx2Compatible.xul、tabFx2Compatible.css、tabFx2Compatible.xmlを使わないようにした Main 文字入力中に補助的な情報や機能をポップアップとして表示するとキャレットが消えてしまう件について分かったこと » FirefoxやThunderbirdを必ずクラッシュさせるコード - Mar 02, 2012 クラッシュレポーターの挙動を調べたい時に。以下のコードを改行無しでエラーコンソールあたりで実行すれば一発で落ちる。 Components.u
Twitter に join してから、今日でちょうど1か月になる。 入る前は、もうだいぶ人数が増えてしまってるし、大きい会社っぽくなってないか心配してたんだけど、ぜんぜんそんなことないみたい。いい感じの居心地で、毎日が楽しい。 いまいるチームのエンジニアはみんなかなり優秀で、学ぶことが多い。 一番すごいと思ったのは、成果を出すための思い切りの良さ。限られた時間の中で目的を達成するために、多少デメリットがあっても、最短と思える方法を取ってくる。少々コードが汚くても、パフォーマンスが悪くても、目的を達成できればいい。あとで時間が取れたときに、ゆっくり直していけばいいという考え方のようだ。 1日で80%動くものをリリースしたほうが、1週間で100%動くものをリリースするより価値が大きいというわけだ。 ぼくは、なんでもわりと丁寧に作ってしまうほうなので、目的に応じて手の抜き方を工夫していくと、も
【教えてくん】コミュニティーなのです。 なんかニュースとかあったらここに書こうかと思ってますよ。とりあえず、おいらのブログ 注意力と読解力について 先日、twitterでこんなことを書いてみました。 「明るくアットホームな会社」と自称する勤務先のブラック会社率の高さは異常。 http://twitpic.com/8fd8df 嘘というのは、予測の範囲内だと、騙されやすいんですよね。 この広告画像のように、「早朝から深夜まで、時には翌朝まで様々な業務が体験できる」とか、本当に書いちゃうバカな会社はあるかも?とか思っちゃうわけです。 でも、ちゃんと見ると、電話番号の桁数とか、会社名がおかしいとか、そもそも「社蓄スタッフ」なんていって、募集しないよ、、、とか、真実としては許容できない部分が見つかるわけです。 なので、嘘なんだなぁ、、とかわかるんですが、twitterの反応を見てると、本当だと思っ
Twitterに流したら思ったよりも好評でしたので、ブログにも上げておきます。 こちらがiOS 2地点でのNSURLConnectionクラスを使った非同期通信のテストケース。 こちらがiOS 5でのNSURLConnectionクラスを使った非同期通信のテストケース。 Blocksはやっぱり偉大です。一つしかテストケースがないうちはまだマシなのですが、これが10個とかになると楽さが全く違ってきます。ぜひためしにURLだけ変えて同じテストケースを10個作ってみてください。iOS 5のBlocksを使ったコードはほとんどコピペだけで終わりますが、iOS 2でのdelegateを使ったコードは他にも変更しなければならない点が多数出てくるはずです。 また実際にこのコードを走らせてみると、理由はよくわからないのですがiOS 5で追加されたAPIを使ったコード(Blocks)のほうがそうでないコード
2011年12月6日火曜日 「ぐへへお姉ちゃんパンツ何色」から始めるクラス解説 「ぐへへお姉ちゃんパンツ何色」はこれ以上ないほどオブジェクト指向であり、しかも理想的な実装をしていることに気づきました。これを用いてオブジェクト指向を説明してみようと思います。 ある人が「ぐへへお姉ちゃんパンツ何色」と質問するのは、お姉ちゃんオブジェクトの保持するpants_color変数を取得しようとする手続きと見ることが出来ます。つまり oneechan.pants_color を取得しようとしているわけです。 ではどうすればいいのでしょうか? 考えてみましょう。直接パンツを見ればpants_colorを取得することができますね。 クラスを使わないとすればこんな書き方が考えられます。 struct oneechan{ int pants_color; }; 構造体でひな形を宣言します。
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
1. あえてECMAScript3.0以前の実行環境を使う あえてECMAScript3.0の実行環境を使うようにしましょう。そしてATNDで好みの男がいたらLT参加を告知し、わざとらしく発表準備段階でコンソールを出していじってみましょう。そして「あ~ん! この実行環境本当にマジでチョームカつくんですけどぉぉお~!」と言って、男に「どうしたの?」と言わせましょう。言わせたらもう大成功。「ECMAScriptとか詳しくなくてぇ~! ずっとコレ使ってるんですけどぉ~! Object.keysが使えないんですぅ~! ぷんぷくり~ん(怒)」と言いましょう。だいたいの男は新しい実行環境を持ちたがる習性があるので、ECMAScript5の実行環境を使っているはずです。 そこで男が「新しい実行環境にしないの?」と言ってくるはず(Object.prototypeの拡張を勧める男はその時点でガン無視OK)。
iPhoneで動く、オープンソースのQRコード読み取りソフトとして ZXing ("Zebra Crossing") があります。このプロジェクトには iPhone 用のサンプルアプリ barcodes が入っていますが、色々な機能を持たせているのでQRコード読み取りライブラリーの使い方を知るには複雑すぎます。そこでカメラで画像を撮りQRコード読み取りを行う簡単なアプリを作ってみました。 サンプル アプリ ZXingのQRコード読み取りライブラリー Decoder は Decoder.hのメソッドと、DecoderDelegate.hに定義されているデリゲートメソッドを以下の流れで使います。 Decodeの初期化は initWithNibName:bundle:内で行います decodeImage:cropRect: メソッドで画像と画像の範囲を指定して読み取りを開始 decoder:di
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く