コンピュータシステムの理論と実装
TOPICS 発行年月日 2015年03月 PRINT LENGTH 416 ISBN 978-4-87311-712-6 原書 The Elements of Computing Systems FORMAT コンピュータを理解するための最善の方法はゼロからコンピュータを作ることです。コンピュータの構成要素は、ハードウェア、ソフトウェア、コンパイラ、OSに大別できます。本書では、これらコンピュータの構成要素をひとつずつ組み立てます。具体的には、NANDという電子素子からスタートし、論理ゲート、加算器、CPUを設計します。そして、オペレーティングシステム、コンパイラ、バーチャルマシンなどを実装しコンピュータを完成させて、最後にその上でアプリケーション（テトリスなど）を動作させます。実行環境はJava（Mac、Windows、Linuxで動作）。 ● 本書のサポートサイト ● 本書で使用する
共通化でモチベーションと効率が低下した話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 自分は普段ソーシャルゲームの開発に関わっていますが、群雄割拠のグリモバ全盛期にその開発を効率化するために社内ではいろいろな取り組みがなされました。そのひとつにアプリ別ではなく機能別のチームを作るということがありました。結果としてそれは失敗だったと言えるのでそのことについて書いていきます。 背景 当時のソーシャルゲームの主流はカードゲームで、クエスト・レイドをこなしつつガチャで引いたカードを合成して強化していくスタイルが一般的でした。そしてその多くがシステムはほとんど同じで見た目だけを変えた「柄替え」アプリでした。 その中で行われたのが二
ネットワーク・プログラミング／クライアント側
システム・プログラム 電子・情報工学系 新城 靖 <yas@is.tsukuba.ac.jp> このページは、次の URL にあります。 http://www.coins.tsukuba.ac.jp/~yas/coins/syspro-2004/2004-04-26 あるいは、次のページから手繰っていくこともできます。 http://www.coins.tsukuba.ac.jp/~yas/ http://www.is.tsukuba.ac.jp/~yas/index-j.html ■今日の重要な話 TCP/IP の考え方 プロトコルスタック IP アドレス(IPv4)とポート番号 ストリーム 通信路の開設 クライアント・サーバ・モデル ホスト名からIPアドレスへの変換 telnet コマンドによる接続 クライアント側のプログラム、tcp_connect() の考え方 tcp_connec
Shibu's Diary: 「納品をなくせばうまくいく」を読んでません
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 「納品」をなくせばうまくいくという本が流行っているみたいです。僕はまだ読んでいませんが、タイトルを一目見れば、倉貫さんファンからすると内容を想像するのは難しくないでしょう。きっと今まで倉貫さんが語ってこられてきたことの集大成であろうと想像しています。 「納品をなくせばうまくいく」の感想part1～ソフトウェア業界のビジネスモデルが抱える問題 こちらのブログにはこのモデルを採用することでいろいろ問題が解決するよね！ということが書かれていますが、こちらに書いてない話で、「なぜダメと分かっている方法論がまかり通っているのか」をまとめてみたいと思います。もしかしたら倉貫さんの本にすでに書かれているかもしれませんが。 ムダのない予算管理がムダを生む ダメなモデルを使い続けているのは、基本
クソコードと呼ばない - ppworks.jp
新しい現場にはいったときに心がけていること、クソコードと呼ばないこと。 誰かのコードを読んでいるとそりゃまあクソコードを見つけることがある。その時どう立ち向かうかという精神論の話。 例えソレがそうであってもソレを口にするとネガティブが蔓延する。思ってもイイ、でも言ってしまってはならない。あるフェーズに置いては必要だった し、現に動いていて価値を提供している のだ。あるべき姿を叫ぶの簡単だ。あるべき姿を見ているなら行動しないといけない。見つけたらリファクタだ。出来るところからやるんだ。 Shut the fuck up and write some code & 許可を求めるな Pull Request せよ— 🌈KOSHIKAWA (@ppworks) 2014年5月23日 クソはクソと言える空気や文化は大事。良くないものを指摘できるようにはしたい。口の前に手を動かそう。プログラマーなら
独学で 1 ヶ月間 OpenGL を学んで得た基礎知識のまとめ ~ 2D 編 ~ · けんごのお屋敷
OpenGL。その単語の響きだけで素晴らしく魅力的に思える 3D コンピューターグラフィックスライブラリは、これまで何人もの駆け出しゲームプログラマーに幾度と無く挫折を味わわせてきた。「ゲーム作るならやっぱり高速に描画できる OpenGL でしょ。でも自分が作るゲームに 3D はいらないし、しかも難しそうだし、別に 2D 描画だけできればいいや」 と、軽い気持ちで手を出したのが運の尽き、世の中そんなに甘くはなかった。OpenGL というその難攻不落城は私達の進む道を阻むように高々とそびえ立っている。 OpenGL がコレほどまでに取っ付きにくいのは 気軽に Hello World できない からなんじゃないかと思う。OpenGL の場合だとそれは何かしら 1 つの図形を表示することにあたるのかな。でもたったそれだけなのに、覚えることが山ほどありすぎて全然本題にたどり着くことができないし、O
ソフトウェアエンジニアがたどる成長過程と失敗の行きつく先 | POSTD
これからご紹介する私の試みはなかなか難しい側面があり、物議をかもすかもしれません。また、お見せするのは初めてなので完璧とは言えないかもしれません。私はソフトウェアエンジニアのスキルとその影響力を評価するシステムを開発しようとしています。少なくとも、プログラマが成長していく理想的な成長過程を大まかに描いてみようと思います。評価スコアは0.0から3.0まであり、それぞれの数字は専門能力を開発していく際の出発点を表しています。 このシステムは主にビジネスの観点から見た、ソフトウェア業界が求めるものに基づく 実務的な スケールです。数学的な才能や高速アルゴリズムを書く能力、Linuxカーネルの内部構造に関するプログラマの理解の深さなどを評価するスケールではありません。もちろんこうした能力は重要ですし、通常、エンジニアのスキルとともに伸びていく能力ですが、私のシステムが焦点を当てたいのはそこではあり
人のコードを引き継ぐときに一番困るのは「使われていないコード」 | mah365
プログラミングを生業としていると、人のコードを引き継いで開発するなんてこともままある訳ですが、そういうときに一番困るのは「使われていないコード」だなー、としみじみ感じます。 使われていないコードがもたらす弊害 特に動的言語で書かれたコードというのは前触れ無く呼び出される可能性があるため、本当に利用されていないのかどうなのか、きっちりと調べあげるのは困難なケースがあります。例えばrubyであれば、method_missingでキャッチしてsendで動的に処理先を振り分けるなんてことをしていると、単純にgrepして利用状況を見るだけでは不十分な場合があります。 そういう意味では「使われていないコード」というよりは、「使われているのか使われていないのかはっきり分からないコード」という方が適切な表現かも知れません。 そういった「はっきりと判断のつかないコード」がある状態だと何が問題なのかと言うと、
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
コードを引継いでどこから手をつけるか - ワザノバ | wazanova
http://www.se-radio.net/2009/11/episode-148-software-archaeology-with-dave-thomas/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 他人から引継いだコードを把握するのにどこから着手するかというテーマで、たまたまいくつかのエントリーを見かけました。「コードを読み切れないほど膨大にある。」「前任者、経緯のわかる人がいる/いない。」「ドキュメントがある/ない。」など様々な事情が想定されますが、全部まとめて主な声を拾ってみました。 謙虚な姿勢で臨むこと。そのコードベースがわかりづらいのは、書き方が悪いコードだからかもしれないが、自分がその専門領域の知識がなかったり、ベースにあるアルゴリズムが本当に複雑な場合もありうる。それを、全
2009-09-16
「動けば良い」と言う人はエラーが起きてから「動かないじゃないか」と文句を言う。仮令、その人の操作が間違っていたとしても言う。ある「動けば良い」と言う人が酷いバグで右往左往しているのを見て(少なくともその人の)原因に思い当たった。 その人はコードをデバッガで追うのが大好きだ。で、どこでSEGVが出たかを突き止めて、SEGVの箇所にエラーチェックを追加して修正完了とする。その結果、次々と別の箇所でSEGVが発生したり、エラー時のリカバリに失敗したりしている(ここで右往左往)。 NULL参照のエラーが出たということは、NULLであるべきでない変数にNULLが入っている、という状態になっているはずだ。この場合、NULLが代入された変数を参照した箇所は落ちるべくして落ちたに過ぎない。本当のバグはNULLであるべきでない変数にNULLを代入した箇所にある。 つまり、変数が取り得る値は何か、という観点が
エンジニアを定量化なんてしてはいけない - smellman's Broken Diary
ネタ元: 「エンジニアをつくる」という理念掲げていたら、エンジニアが社内からいなくなった件 | 新田章太の「エンジニアをつくる」ブログ 話の発端は、 俺がDMTCについて知ってること，またそれに対する所感 - 職質アンチパターン がFacebookで話題になっていて、やばいなぁと思っていたら主催者もやばかったみたいな話。 内容自体ただヤバイんだけど、その中でも明確にツッコミを入れておきたい部分があった。 僕らの強みはDMTCを通じて、沢山のお客様とのつながりがあること このつながりを活かして、 国内外のIT企業で働くエンジニアのスキルを定量化しよう というひとつのテーマにいきつきました。 http://maximum80.me/archives/821 この部分についてFacebookで俺はエンジニアをバカにしてるって書いたけど、もうちょっと具体的に落としこもうと思った次第です。 ものさし
プログラミングの生産性を上げるには - 聞かれてもいないことを喋る
Yak Shaving の誘惑に打ち克つ ソフトウェアを作っている途中で、「これを作るのを効率化するためには ○○ が必要だ」と思い、本来やっていた作業の手を止めて ○○ を作り始めてしまうことは往々にしてある。 しかしその作り上げた ○○ が最終的に本当に（長期的にみて）効率化に役立ったケースは、自分の経験からいって 10 個のうち 1 つくらいではないかと思う。 効率化のための努力をするなということではない。大事なのは、アイデアを寝かせることだ。 人はゴミみたいなアイデアでも、気付かずにこれこそが素晴らしいアイデアだと信じこんでしまう。自分の考えたアイデアには愛着が湧くものだ。 そのアイデアが本当に優れているかどうか客観的に判断するには時間が必要だ。最低でも 1 晩、できればもう 2, 3 度は同じ必要性を感じてから作るのがいい。 1 回しか必要性を感じたことのないものをその場の勢いで
TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco
C言語 Super Technique 講座
このページは、Ｃ言語の中級テクニックを中心に解説する。長らくプログラマをしていると、Ｃ言語の面白い使い方例が蓄積している。これらを一挙公開するために、このページを作ったのである。しかし、単にＣに留まらず、他の言語の面白い特徴なども紹介していく。 内容的にはかなりヘヴィである。当然のことながら、「ポインタ虎の巻」程度の内容はちゃんと使いこなせることを前提とする。意外な技、落し穴、派手なテクニックなど、内容満載だが、ちゃんとデータ構造とアルゴリズムなども説明できれば良いと思う。（まあ、ぼちぼちやってきいます...） 以下の目次には手引きのために、評価がつけてある。凡例として示す。 レベル その解説で記載されている内容のレベル 有用度 その内容が実際に役に立つものかどうか 邪悪度 その内容が薦める方法が、一般的なコーディング規約の中で「邪悪」とされがちなものであるか否か。関数ポインタの活用（濫用
iOS上で動作する革命的ものづくり環境「Pythonista 3」の魅力をとくと語る
iOS用のアプリは通常、開発アカウントを取得し、Macを使って開発します。 開発アカウントを取得するほどではないが、iOSデバイス上で何かやりたい処理がある、という人はいるでしょう。 あるいは、プログラム好きな人なら率先してiOSデバイス上でプログラミングをしたいと思うのではないでしょうか。 そうしたニーズに存分にこたえることができる、iOSデバイス上で動作する統合開発環境がPythonista 3です。 2016年9月21日に開催されたPyCon JP 2016で @equal_001 さんがPythonistaについて発表されていたのでご紹介。 Python支持者のことをPythonistaといいますが、アプリ名はそこから取ったんでしょうね。 正真正銘のPythonが内蔵されていて、ローカルで動きます。 [参考] Kazuhiro AbeさんはTwitterを使っています: 「インタプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CEDEC2014 「ライブラリを作ってはいけない ～それでも作りたいあなたへのアドバイス～」
http://coder.lv9.org/softwareEngineering.html
サービス終了のお知らせ
とある福井のstaticおじさん
