他人の書いたコードに挑もう – Part 2 | POSTD
この記事の前編はこちら： 他人の書いたコードに挑もう – Part 1 慣れる 前にも言ったように、よく知らないプロジェクトのコードを探索する時は、段階を追って進めます。第一段階は、通常、様々なファイルやフォルダを大まかに見ていくことです。何がどこにあって、そのプロジェクトがどんな「モノ」を持っているのかを把握します。それを終えてやっと、自分の見たい特定の「何か」を詳細に見ていくことができるのです。 いろいろなコードを見る Spyderにあると思われる主なトップフォルダは下記のものです。 app_example/ ：明らかに何らかのアプリケーション例であり、おそらくメインのコードではない。 conda.recipe/ ： Anacondaとのある種のインテグレーションで、Spyderを簡単にインストールできるようにするもの。 continuous_integration/ ：自動の単体テス
コード読経会報告書
5. 会の流れ 1. コンパイル（参考資料参照の事） 2. まずは動かす 3. それぞれのファイルについて読経 4. 読経した結果はパワポでまとめ 6. 各プログラム解説 • init-db : キャッシュフォルダの初期化(git initっぽいもの) • update-cache : トレースファイルの追加、更新(git addっぽいもの) • write-tree : treeの作成(git commitっぽいもの) • commit-tree : データベースへ登録(git pushっぽいもの) • cat-file : ファイル名の表示 • read-tree : tree内容の出力 • show-diff : 最新コミットとの差異(git diff) 7. まずは動かす • % ./init-db • % ./update-cache README • % ./write-tre
GNU GLOBALとvimで巨大なコードでも快適にコードリーディング
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 これまでも、多くの記事にされていて、恐らくKernelや巨大なコードを読んでいる人にとっては当たり前なのかもしれませんが、あまりに快適だったのとこれをきちんとやれてなかった事に自戒をこめて記事にしようと思います。grepとかscreenを駆使していた時間を返してほしい！ 対象者 僕がLinux大好きなので、Linux上での動作を前提にしています。対象者はLinux KernelやApache HTTP Server等、数万から数十万、さらには数百万行のコードをじっくり読んでいきたいと考えている人におすすめしたいと思います。巨大なコードを何のツールも使わずに読むのはかなりきついはずです。しかし、今回はGNU GLOBALと呼ばれるソースコードタ
OTN Japan マニュアル
お探しのものを見つけるために、以下の項目を試してみてください。 キーワード検索のスペルを確認してください。 入力したキーワードの同義語を使用してください。たとえば、「ソフトウェア」の代わりに「アプリケーション」を試してみてください。 新しい検索を開始してください。
カーネルハッカー・小崎資広の「コードを読む技術」 | サイボウズ式
サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第2回（毎週火曜日に掲載、これまでの連載一覧）。「WEB+DB PRESS Vol.80」（2014年4月24日発売）に執筆した「エンジニアの学び方──効率的に知識を得て，成果に結び付ける」の続編です。（編集部） 文：西尾 泰和 イラスト：歌工房 この連載では「エンジニアの学び方」をテーマにインタビューを行い、どういう「学び方」をしているのか探求していきたいと思っています。第1弾は、富士通のエンジニアとしてLinuxカーネルの開発に参加されている小崎資広さんです。 Linuxカーネルは、ソースファイルだけで3万5000個以上、行数にして1500万行を超える、巨大ソフトウェアです。小崎さんが、どうやってこの巨大なソースコードと戦っているかは、きっと「エンジニアの学び方」の参考になるはずです。
そろそろ理解しておきたいのでDockerのソースコードをビジュアルに読む！ - Qiita
まずはツールの紹介 昨今、注目を浴びているアプリケーションコンテナを作ったり管理したりできるDocker。 そろそろ中身も理解しておきたいところ。特に最近はlibcontainerというのができて、lxc依存すら切り離されているとの噂。 ただ、結構ソースコードの量も大きくなっているので（2014/4月現在 テストコード除いて70000行弱）、 さっと大まかに理解するためのツールを書いてみました。 このツールはgoのastからパッケージの間の依存関係を読んで、graphvizの解釈するdot言語に吐き出すツールです。 たとえば、最近話題のgo-xslateの全体像をつかもうと思ったら、 のようにすることで、 拡大 こんな感じにパッケージ間の依存関係を図示することができます。 これだけでも何となくどんな構造になってるかわかってきそうですね。 不安定性の表示 govizにはdot言語の出力の他に
太一のコードの読み方メモ
太一のコードの読み方メモ 全体として太一が感覚的に実践している事を論理的に説明しようと試みている為、 説明の粒度が適切でなかったり一貫性が無いように見える部分があるかもしれない。 普段やっているけども書ききれていない事も多分きっとある。 コードを読むとは何か コードを嗜む コードを学ぶ 武器を手に入れる これは武器を手に入れるコードリーディングの話 武器とは何か プロジェクトで戦う為の道具となる知識 プロジェクト内における技能を示す為の道具となる知識 プロジェクトのやり方を自ら決められる様になる為の道具となる知識 権限と責任がバランスよく割当てられた時モチベーションは最大化する 何と戦うのか プロジェクトリスク プロジェクトをより良い状態にする為の基礎的な根拠となるのがコードである コードが全てではないが適切に動作するコードが無ければプロジェクトは終わらない これはつまり理想を体現する為の
コードリーディングについて | ありえるえりあ
コードリーディングについて アリエルネットワークCTO 井上誠一郎 自己紹介 書籍 「P2P教科書」 「パーフェクトJava」 「サーバサイドJavaScript入門」 「パーフェクトJavaScript」 今回の講義 心構えや経験談が中心 抽象論になりすぎないように実践可能な「トライ」ページ 次回講義の予告 3月1日の予定 「Webアプリのアーキテクチャの歴史と進化」 専門用語多め 反応を比較して今後の講義の参考にします コードリーディング(1) 現場で重要なスキル 既存コードベースがある場合、書くコード行数は驚くほど少ない 学習と実務でのギャップ サンプルコードは短い コードリーディング(2) 既存コードを理解できないと デバッグできない 新機能の追加ができない 既存コードと同じコードを書いてしまう(無知ゆえのコピーコード) => 更に読みづらくなる悪循環 理解できないコードは悪 多少
巨大な(あるいは、汚くて邪悪な)コードの泳ぎ方 - mizchi's blog
ロンドンへの飛行機(11時間)で暇だったから書いた文章。 自分でゼロからすべてのコードを書けるときはテストファーストでいいけど、アンドキュメントな実験的なライブラリを利用する際や、巨大なプロジェクトの一部としてコードを書く際は、テストファーストよりもとにかくコードを書きまくって挙動の変化を確かめるほうが有用な時がある。 まあ多分どっかでこういうのはハウツー化してあるんだろうけど、自分ルールが固まってきたので、メモっておく。 目的を設定する トップダウンに読むには、コスパが悪いことが多い。とにかく「アレする」「コレする」という目的を定義して、そのためにその周辺領域からボトムアップに読むことにしよう。 エンドポイントを追う 巨大なプロジェクトに放り込まれた最初の段階では、エンジニアは本当に無力だ。 最初にやることは、自分が処理を挟むべき位置を見つけることだろう。 まずはファイル名や関数名を読ん
読みやすいコードってどんなものか考えてみた -抽象化と名前重要- - tumblr
あらすじ 人の綺麗なコードを読みまくると自分のコードも綺麗になっていくのに、イケメンを見続けても僕の顔が良くならないのは何故なの?? 2012-11-30 19:41:20 via web 今まであまり人のコードを読む習慣というか機会というかがあまりなかったのですが、最近になって、デスクの上がヨドバシのiMac売り場みたいと(僕の中で)話題沸騰中の@mitukiiiさんのコードを読む事があり、この人がまたすごく綺麗でスタイリッシュなコードを書くわけで、その時に、綺麗なコードというのはこういう感じに書くものなのかと結構な衝撃を受けたわけです。 またこれも最近なのですが、別の機会で、なんと言いますか、1つの関数が数千行あったり、しかもその内の大部分が共通処理として括り出せるような恐らくはコピペされたであろう部分が大量に入っていたりまぁ不可解な部分の多い、言うなればイケメンを見続けた僕みたいな、
コードウォーキングのための準備運動
Mercurial のソースコードを参照する際に、 必要となる基本的な知識に関して説明します。 ここでは、 『じっくり読み込む』レベルの一歩手前の、 『ウォークスルー』(walk through) で概要を把握する程度の『参照』を想定しています。 extension に関する説明も併せて参照してください。 コード中での使用頻度が高い Mercurial 固有の慣用句 コード参照時の確認頻度が高い Mercurial 固有のクラス コード中での利用頻度が高い Mercurial 固有のファイル Mercurial での使用頻度が高い Python 固有の慣用句／基本文法 コード中での使用頻度が高い Mercurial 固有の慣用句 メッセージ国際化 "_()" Mercurial では、 メッセージの国際化に対応するため、 mercurial/i18n.py において、 gettext()
「Gitポケットリファレンス」を活用してカーネルソースを読んでみよう！ - めもめも
Gitポケットリファレンス 作者: 岡本隆史,武田健太郎,相良幸範出版社/メーカー: 技術評論社発売日: 2012/07/10メディア: 単行本（ソフトカバー）購入: 7人 クリック: 103回この商品を含むブログ (26件) を見る こちらの書籍を著者様より献本いただきました。ありがとうございます！ 本書は、GitHubなどの既存の共有リポジトリの使用を前提として、これから開発に参加しようという読者を想定しているため、「どういうシーンでどのgitコマンドを使えばいいのか」が明確で、わかりやすい構成になっています。実用面にフォーカスしたGitの解説書としては、今のところベストな1冊ではないでしょうか。 ところで・・・・ ちなみに私の場合は、ソースコードを書く時間よりは、読む時間の方がずっと長いのですが、実は「ソースを読むツール」としてもGitは有用です。 Gitリポジトリにはソースコードの
ソースコードを読むときの3カ条 - I am Cruby!
GCを読んでいく上で実際に使っているソースコードの読み方を紹介してみます。 個人的に大事にしているのは以下の3カ条です。 小さい疑問から先に倒すべし 正しいツールを選択するべし 必ずメモするべし 小さい疑問から先に倒すべし なんとなく読みたい時は疑問の分析からソースコードってなんとなく読みたくなるということもありますよね。 ただ、その状態でいきなり対象のソースコードを読みはじめるのはよくないです。 小さなプロジェクトだと問題ないかもしれませんが、大きなプロジェクトだと時間がかかりすぎます。 そういうときは最初にドキュメントなどを読んでみましょう。 そうすると、対象のソースコードが持つ機能が書いてあります。 機能がわかれば「どうやってこれを実装しているのか？」という疑問が浮かびます。 たとえば、G1GCの場合は論文がすでに公開されていたので、最初に論文を読みました。 読み終わったあとに論文内
Jubatus ソースコードリーディング - src/jubakeeper/main.cpp - flow and stock
自分の理解のためにメモしながら読んでみる。内容の正しさは保証しません。どこまで続くかも保証しません。 読むバージョンは現時点の最新版である 0.1.1。ソースコード総規模は *.cpp と *.hpp を合わせて13690行。 自分は機械学習よりも分散処理に興味があるので、スケールアウトの肝っぽい jubakeeper から読んでいこうと思う。src/jubakeeper/main.cpp に main() 関数がある。 L.34- コマンドラインの解析 L.42- ログ出力の設定 L.53 jubakeeper オブジェクトの生成 jubakeeper クラスの定義は src/jubakeeper/jubakeeper.cpp 内にある。第一引数はZooKeeperの「IPアドレス ":" ポート」、第二引数はこの jubakeeper が使うRPCポート、第三引数は未使用(？)、第四引
オブジェクト指向のソースを読むのが難しい理由 - 都元ダイスケ IT-PRESS
ダラダラ書かない予定だよ。ざっくり行くよ。あと、分かってる人には当たり前な事だと思うよ。 あるクラスについて知りたかったら、まずその基底クラスを知れ 例えば、Integerクラスについて知りたいと思ったら、Integer.java だけを読んでいてはダメだ。確かに「Integerに特化した責務・構造・操作」は読み取れるかもしれないが、数値としての基本的な責務・構造・操作はNumberに書かれている。それを読まずして、Integerが保つ数値という一面を知ることはできない。Integer.javaには「Integer - Number」*1の情報しか書いてないのだよ。差分プログラミング。 さらに、忘れちゃいけない。Object.javaを読め。全ての道は暗黙的にObjectにつながっている。Objectを知らずしてJavaのクラスを知る事は絶対にできない。Objectなんて、みんな「知った気
一歩先行くJavaプログラマが読むべきオープンソースソフトウェア10選 - 設計と実装の狭間で。
10万行コード読んだらJava分かるよってTwitterに書いたらすげぇ勢いでRTされたので、調子に乗って捕捉エントリ書くよ。 Java Core API JDKインストールしたディレクトリに入ってるsrc.zipを展開すると入ってるから読むと良いよ。 すぐ近くにあるのから読むってのはメンタル的に楽でいい。 厳密にはOSSじゃなくて単に公開されてるってだけなんだけども、JavaプログラマなのにコアAPIのコード読んでないとか無いよね？ どれから読めば良いか分からんかったら、 java.lang java.util java.io java.text 辺りをまずはキチンと理解すること。当然コードを読み終わったら、それを使ってコードを書く事。 OpenJDK http://hg.openjdk.java.net/jdk7/jdk7 OpenJDKを読むことで、プログラム言語してのJavaではな
ソースコード読解のハンズオン結果中間報告
ソースコードリーディングワークショップ ハンズオン，オンラインハンズオン結果中間報告 1 (2010/11/8) 当ページはハンズオンにご協力いただいた方向けのハンズオン結果の報告ページです．当ハンズオンへの御協力，誠にありがとうございました． 当ページは，これまでに結果を送付いただいた方の結果を元にした分析結果を報告するものです． 当ページはソースコードリーディングワークショップ2010(共催 日本IBM、メディア協賛 @IT)， オンラインハンズオン， ソースコードリーディングワークショップ in デブサミ2010(協力 日本IBM)， その他ご協力企業の皆様により，実際にソースコードを読解いただき，その読解時間を計測したものです． ハンズオンの趣旨と流れ ハンズオンでは，保守・派生開発プロジェクトを模した形式でソースコードの読解を行って頂きました．既存システムにあたるバージョン１ソ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - hirokidaichi/goviz: a visualization tool for golang project dependency
GitHub - taichi/rappa: This extension supports code reading method used for Ninja.