巨大な(あるいは、汚くて邪悪な)コードの泳ぎ方 - mizchi's blog
ロンドンへの飛行機(11時間)で暇だったから書いた文章。 自分でゼロからすべてのコードを書けるときはテストファーストでいいけど、アンドキュメントな実験的なライブラリを利用する際や、巨大なプロジェクトの一部としてコードを書く際は、テストファーストよりもとにかくコードを書きまくって挙動の変化を確かめるほうが有用な時がある。 まあ多分どっかでこういうのはハウツー化してあるんだろうけど、自分ルールが固まってきたので、メモっておく。 目的を設定する トップダウンに読むには、コスパが悪いことが多い。とにかく「アレする」「コレする」という目的を定義して、そのためにその周辺領域からボトムアップに読むことにしよう。 エンドポイントを追う 巨大なプロジェクトに放り込まれた最初の段階では、エンジニアは本当に無力だ。 最初にやることは、自分が処理を挟むべき位置を見つけることだろう。 まずはファイル名や関数名を読ん
同僚の外国人プログラマ観察記録 - rinu's blog
概要 1ヶ月くらい一緒にお仕事している外国人プログラマさんを観察した記録です。 スペック 性別: 男性 仕事内容: うちの会社のプログラマは、ざっくり JS 等のフロントエンドと、 Java 等のバックエンドエンジニアにわかれているのですが、彼はどちらもやっているようです。 好きな食べ物: はちみつ たまに、くまさんのようにはちみつを舐めていました。 性格 彼はめんどくさがり屋です。 同僚の Windows ユーザの手伝いをしている時、 "C:¥Program Files¥..." みたいなパスを打ちながら、「めんどくさい。 ああ めんどくさい」 と 100回くらいつぶやいていました。 (普段の彼の環境は mac なので /usr/local/bin) パスワードを覚えるのもめんどくさいので 1Password で管理しているようです。 PC スペック マシン: Macbook Pro メ
Programmer Time Translation Table – Passion for Coding
An experienced project manager I used to work with claimed that he took the programmers’ time estimates, multiplied by pi and converted to the next time magnitude to get the true number. 1 day converts to 3.14 weeks. He had learned the hard way that programmers are bad at estimating times. To get a more precise conversion, I’ve created a translation table for programmers’ time estimations, trying
プロジェクトにおけるTDDの重要度の話
Satoshⅰ Nakagawa @Psychs 成功したサービスを作り始めた時に、どのくらいの割合のプロジェクトが最初から TDD とかやってるのか気になる。 2012-08-09 13:33:33
cron等をつかって外部のAPIに問い合わせる場合は、毎時0分を避けるのが大人のマナー - blog.nomadscafe.jp
なんかtwitterで書いたらウケたっぽいので cronをつかって外部のAPIに問い合わせる場合は、毎時0分をさけるのオススメ！！！！お兄さんとの約束だ！！！ — masahiro nagano (@kazeburo) August 9, 2012 某サービスのAPIへの問い合わせ件数を調べると、毎時 0分台(0秒から59秒)のアクセスは1分から59分までの1分間の平均アクセス数の5倍から8倍にもなります。 これはおそらく、crontabの設定が 0 * * * * /path/to/call_foreign_api になっていることが多いからじゃないかなぁと思うのです。 その結果、サーバのロードアベレージは このように毎時0分だけ跳ね上がってしまいます。サービスを快適に提供できなくなる可能性があるので、APIの利用を制限したり、サーバを追加しなければなりません。これはサービス利用者、サー
Pythonワンライナーで数独を解いてみた
GIGAZINEに数学のエキスパートが3ヶ月かけて作成した「世界一難しい数独」なるものがあったので、即席でPythonワンライナー(一行プログラム)を作ったら1秒かからず解けた。問題を作るのは大変でも解析プログラムで一瞬とは儚い。 python -c "import sys;L=[];S=lambda D:(0in D)and[L.append(D.index(0)),[(D.__setitem__(L[-1],i),S(D),D.__setitem__(L.pop(),0))for i in set(range(1,10))-set(D[L[-1]/9*9:L[-1]/9*9+9]+D[L[-1]%9:81:9]+[d for n in(0,1,2)for d in D[L[-1]/27*27+L[-1]%9/3*3+n*9:L[-1]/27*27+L[-1]%9/3*3+n*9+3]]
ソフトウェアの肥大化について - bkブログ
ソフトウェアの肥大化について 肥大化したソフトウェアというとリソース食いでメンテナンスがしづらい厄介ものというイメージがあります。しかし、広く使われているソフトウェアは多かれ少なかれ肥大化しているように思えます。ソフトウェアの肥大化はよくないことなのでしょうか。 結論からいえば、必ずしも悪いことではありません。この話題は Joel Spolsky 氏がストラテジー･レターIV：ブロートウェアと80/20の神話で書いています。私が付け加えられることはあまりありませんが、最近、知人との間で話題になったので、少し書いてみたいと思います。 数年前、 Alan Kay 氏の Squaek についての講演を聞きにいったとき、途中でコードのサイズが話題になり、Squeak のコードはこんなに小さい（具体的な数字は忘れました）といって、何千万行もある Windows NT を引き合いに出して、Squaek
シンプル＝バッドシグナル説 - bkブログ
シンプル＝バッドシグナル説 知人と話していて、シンプルという言葉は手抜きの言い訳として使われることがあまりに多いので、シンプル＝バッドシグナル（バッドな兆候）なのではないか、という話になりました。 シンプルが言い訳としてよく使われるのは以下のような場面です。 必要な機能が足りていない デザインがださい そこらじゅう手を抜いている プログラミングにおいてよくあるのが、まじめに実装していないクラスに Simple なんとかという名前をつけるパターンです。自らシンプルと名乗っているものには疑ってかかったほうがいいのかもしれません。 以上、シンプルな考察でした。
はてなは「絶対すべきでないこと」をやらかしたのか？
おっと、タイトルだけ見て、先週から話題になっているはてなブックマークボタンのトラッキング問題の話かと思われたかもしれないが、本文でははてなブックマークの問題はほとんど扱わない。また、この問題について未だご存じない方は、ARTIFACT@ハテナ系のエントリの後半にあるこれまでの流れを辿ると分かりやすいだろう（ワタシ自身の認知にも近い）。 はてなが新サービスとしてはてなブログをリリースして4ヶ月以上経つ。当初は招待制だったが、昨年末にオープンベータに移行して現在にいたっている。 ワタシもリリース時に招待されたので少し触ってみたが、機能が何から何まで足らないことにびっくりしたものである。そして、はてなは「アレ」をやらかしたのではないかという疑念が頭をよぎったが、まさかと思う気持ちと、短時間触っただけの印象で間違った批判をしてはいけないという自制、何よりそのあたりはじきに解決するのだろうという楽観
変数とメソッドの命名ベストプラクティス15 - 杉風呂2.0 - A Lifelog -
この記事は、Cagdas Basarane 氏のブログ、 CodeBuild から 2012年2月20日の記事 "15 Best Practices of Variable & Method Naming" を翻訳したものです。 原文URL http://codebuild.blogspot.com/2012/02/15-best-practices-of-variable-method.html 十分短く十分長い変数名をスコープごとに使用する。一般的に、ループカウンタには1文字、条件やループ変数には1単語、メソッドには1-2単語、クラスには2-3単語、グローバル変数には3-4単語を使用する。 具体的な(specific)名前を使用する。例えば、"value"、"equals"、"data"といった変数名はいかなる場合も有効ではない。 意味のある(meaningful)名前を使用する。変数
DSL 概要 (DSL (Domain Specific Language))
最近は、互いの利点・欠点を補うために、 両者を混在させた開発というのがはやりつつあります。 言語といっても・・・ まあ、専用言語といっても、そんなたいした話ではないんですね。 そりゃ、中には、コンパイラ作りからやるような本格的な人もいますけど。 多くの場合は、「設定ファイル」とか「ライブラリ」程度のものです。 有名なところでは、Apache の設定ファイルなんかは結構立派な構文を持っていますし、 emacs の設定にいたっては LISP 言語で書きます。 ああいうのも、一種の DSL です。 ということで、 まず、「設定ファイル」とか「ライブラリ」が DSL の第1歩という話から始めてみたいと思います。 抽象定義と具象定義 DSL と設定ファイル、ライブラリの関係性を話す前に、 ちょっと補足的な説明をしておきます。 まあ、アプリケーションの設定を外部ファイルに持ったりすることは結構あるわけ
C言語の正しいヘッダファイルの書き方 - saito’s blog
最近、仕事でC言語での組み込み系の開発に携わっています。 開発中のコードを眺めていると、ヘッダファイル内にstatic関数のプロトタイプ宣言を記述していたり、ヘッダファイル内で不必要に他のヘッダファイルをインクルードしているなど、ヘッダファイルの書き方が分かっていないと思われる箇所が多々見られました。 実際、C言語の入門書でもヘッダファイルの書き方を詳しく説明しているものは、僕の知っている限りでは存在しないので、C言語を使っていてもヘッダファイルの正しい書き方を知らない人が少なくないのではないかと思われます。 そこで、このエントリでは、C言語のヘッダファイルの書き方について、僕が知っているテクニックをまとめてみました。 インクルードガードを書く ヘッダファイルファイルで他のヘッダファイルをインクルードしていると、いつの間にか同じヘッダファイルを2回インクルードしてしまうことがあります。 例
グーグルのバグ予測アルゴリズムを実装したツール「bugspots」、オープンソースで公開
ソースコードのなかでバグが多いのは、より高頻度に、かつ最近になって集中的に直している部分。これが、グーグルで採用された「バグ予測アルゴリズム」であることを、先月の記事「グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している」で紹介しました。 そのバグ予測アルゴリズムを実装したツール「bugspots」がオープンソースとして公開されています。 gitのレポジトリを分析 bugspotsはRubyで記述されており、gitのレポジトリから履歴を読み込んで分析し、どのモジュールにバグが含まれている確率が高いかを示してくれます。 以下のようにインストールして実行（説明ページから引用）。 $> gem install bugspots $> git bugspots /path/to/repo $> git bugspots . # (in current git directory)
アリゲーター・エッグでラムダ計算 - 言語ゲーム
計算の本質は何でしょうか？計算には、足し算引き算掛け算と色々あります。さらに因数分解や微分積分など、計算の種類を挙げればきりがありません。しかし、いくら沢山のルールを沢山覚えても、それで計算の本質を分かった事はなりません。ここで視点を逆転して、より難しい計算ではなく、より単純な計算について考えてみる事にします。 面白いことに、どんな複雑な計算も単純な計算の組み合わせで出来ています。掛け算は足し算の組み合わせですし、引き算は足し算を逆にしたものです。さらに、足し算よりもさらに単純な計算を考える事は出来るでしょうか？昔から沢山の数学者がこのパズルに挑戦し、沢山のモデルが生まれました。今日ご紹介するラムダ計算もその一種です。ラムダ計算は非常に単純な計算モデルですが、単純すぎて計算過程を追うのが難しいです。そこで、アニメーションを使うと仕組みがわかりやすいのでは無いかと考えました(Firefox,
結局、SysMLとUMLの違いは？ - ウィリアムのいたずらの、まちあるき、たべあるき
比較してみると、こんなかんじ。 灰色がUMLしかないもの、黄色がSysMLにしかないもの 共通にあるものでも、SysMLで一部拡張されている部分もある （UMLの灰色の図も使っちゃいけないというわけではない） 内部ブロック図の制約があるのがパラメトリック図らしい。 要求図により、要求（とくに非機能要件）が書ける点が、 UMLと違う点。 ＜＜参考文献＞＞ SysMLによる組込みシステムモデリング http://www.amazon.co.jp/dp/4774147249
仕事でコードを書いていますがどうしても同期と比べて仕事が遅いです。早くコードを書くコツや短くまとめるコツなどがあれば教えてほしいです。あと普段どんなことを意識してコー��
私は昔、趣味で作っていたアプリに機能を「追加」する度に、アプリケーション(実行ファイル)の総サイズを「減らす」、というのを繰り返していたよ。速度も同様に。 これによって「あるパターンはこう簡潔に直せる」というパターン知識が積み上がっていった気がするな。 さらに、それを実現する過程で、限界に見えた状況を打開するために色んな既存アルゴリズムを勉強して実際に使って身につけていくことになった。 ある問題があるときに、的確に適合するアルゴリズムや構成が発見(選択)できると、劇的に簡潔になることがある。そこにたどり着けるかどうか考えるのが楽しい。 あと、同じコードを何年も「育てる」という経験をすると、保守性の低いコードがどう困るかが身に染みるようになるよね。ソースコードは「人が読む物」でもあり、読みやすいというのも保守するなら重要なパラメータになる。これはコメントを書けという意味じゃない。コメ
専門知識の仕入れ方 - Preferred Networks Research & Development
今日は，普段どのようにして専門知識を仕入れているかについて書いてみようと思います．特に自分が得意でない分野を知りたいと思った時に，どうするかに注目したいと思います．自分の専門の場合は，いくらでも時間を注ぐことが出来るので，世界中のリソースを全て探し当てて勉強すれば良いのですが，ちょっと興味が有るぐらいではそこまでやる時間は取れません．なので出来るだけ効率的に分かった気になるのが目標です． まず，論文を直接読むのはあまり効率的では無いと思います．論文は広い分野の中の或る問題に対して一つの解決方法を書いているだけで，分野全体を俯瞰することは目指していません．論文だけ読んで分野全体を理解するには，最低50本ぐらい読む必要が有ると思います．
プログラマになるための勉強をしている人の前で話をしてきた - きしだのHatena
イデアルITスクールというところで、１時間ほど話をしてきました。 プログラマとしてやっていくために大事なことというテーマ。 資料を作らずに、というか構想すら練らずにやってしまったので、ここで整理とまとめと補足を。実際にこれをしゃべったというのではなくて、だいたいこんなことをしゃべろうとしてたという内容をかなり盛って書いてます。 当然ですが、プログラマの仕事はプログラムを書くことです*1。 プログラマとしてやっていくためには、どこで動くプログラムを書くか、なにをするプログラムを書くかということを意識することが大事です。 ということで、まずはプログラムが動くところがどう変わったかという話。 1970年代ころは、デバイスを動かすためのプログラムが多かったのではないかと。 あと、ここには書いてないけど、業務アプリはほぼメインフレームで動いてたと思います。 それが、1980年代くらいからパソコンが出
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
今更だけどPromise入門 - Qiita
アーカイブ