Linusが2週間でgitを作った話。 - 未来のいつか/hyoshiokの日記
Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記という日記がとんでもなく読まれていてビビる。ブックマークもいっぱいついた。はてなブックマーク - Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記 Linusがgitを２週間で作ったという話はわりと知られていなかったようなので、その話である。 gitっていつから作られているのだろうか。ということで、本家のリポジトリから引っ張ってくる。 $ git clone https://github.com/git/git わたしのしょぼいネット環境でも2分はかからない。 最初の10個のコミットは次のようになる。 $ git log --oneline|tail 9426167 Add "-lz" to link line to get in zlib. 7660a18 Add new fsck
Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記
誰でも知っていることだけど、LinuxというOSというかカーネルはLinus Torvaldsが学生のときに趣味で作ったのがはじまりだ。それは1991年ころの話で彼が21歳の頃だ。個人の趣味で作ったものが、いつの間にかに世界中のコンピュータだけでなく、携帯や家電や様々な機械の制御に使われている。 Linus Torvalds - Wikipedia 1994年ころには、PCで動く個人向けOSとしては十分な機能を持っていた。Xもあるし、gccなどのコンパイラもあるし、GNU Emacsやbashもあるので、ちょっとしたプログラムを作るには十分な機能を持っていた。 当時、勤め先のマシンはSunのワークステーションで仕事でLinuxを使う機会は全然なかったのだけど、自宅のPCにSlackwareのCDを入れてみたりした。日常的に使うことはなかったけど、1998年にOracleがLinux版を出し
データベースでもっとも重要な３つのアイデア。（世界でもっとも強力な９つのアルゴリズム） - 未来のいつか/hyoshiokの日記
昨日の日記には山のようにブックマークがついた。( 世界でもっとも強力な9のアルゴリズムを読んだ。 http://d.hatena.ne.jp/hyoshiok/20140209/p1 ) データベースはアルゴリズムじゃないだろうというツッコミもあるけど、偉大なアイデアということだろう。それは多分誰も異論はないと思う。そこで紹介されている３つのアイデアは ログ先行書き込み(WAL) 2段階コミット リレーショナルデータベース トランザクションと言う概念が70年代以降発展してきて、その実装にはログ先行書き込みが多大な貢献をした。 2段階コミットによって分散型データベースが信頼性をもって実装できるようになった。 リレーショナルデータベース（というよりもリレーショナルデータモデル）は全ての基盤になっている。 これらの発展は70年代のSystem Rの先駆的な研究開発から始まったといっても過言ではな
世界でもっとも強力な９つのアルゴリズム、読了。 - 未来のいつか/hyoshiokの日記
世界でもっとも強力な9のアルゴリズムを読んだ。 コンピュータサイエンスの優れたアイデアを紹介している。それらは私たちの生活を変えた。世界を変えたにもかかわらず広くは知られていない。 偉大なアルゴリズムというものは何なのか？本書はその偉大なアルゴリズムを次の基準で選定した。１）普通のコンピュータユーザが毎日使っているもの。２）現実世界の具体的な問題を解決するもの。３）コンピュータサイエンスの理論に関係のあるもの。 そのような基準から著者が選んだのが下記のアルゴリズムだ。 検索エンジンのインデキシング ページランク 公開鍵暗号 誤り訂正符号 パターン認識 データ圧縮 データベース デジタル署名 決定不能性 最初の二つのアルゴリズムのおかげでわたしたちは日々検索エンジンで有用な情報を入手できる。公開鍵暗号やデジタル署名のおかげで安全にインターネット上でクレジットカード情報などを交換できる。誤り訂
集中型バージョン管理システムと分散型バージョン管理システムって - 未来のいつか/hyoshiokの日記
集中型バージョン管理システム（以下CVCSとする）と分散型バージョン管理システム（以下DVCS）って何がどうよかったり嬉しかったりするのだろうか。というようなことをつらつら考えてみた。きっかけは、gitの話とか、そのあたりから。（gitって難しいのかなー http://d.hatena.ne.jp/hyoshiok/20140201/p1 ） バージョン管理システム（VCS）のキモは複数人での共同開発を支援するということにつきるかと思う。http://d.hatena.ne.jp/hyoshiok/20140204/p1 一人で開発していればコミュニケーションロスはないので、ひたすらズンズン開発するだけである。一方で複数で開発していれば、どのようにしてコードを共有し統合しテストするかという問題があって、その作業を支援するのがVCSやソフトウェア構成管理と呼ばれるものである。ソフトウェア構成
達人プログラマーの思考法と学習法 - 未来のいつか/hyoshiokの日記
無理してベストセラーを読む必要はない。自分にあった本を自分にあったペースで読んでいけばいい。GW中に昔（1年くらい前）献本された「リファクタリング・ウェットウェア」を読んだ。 達人プログラマでお馴染みのAndy Huntの著書である。正直言って、この本のタイトルにぐっとこなかったので、本書を1年近く寝かせておいたのであるが（献本いただいた宮川さんすいません）、ふと思いたち、読んだ。面白かった。副題の「達人プログラマーの思考法と学習法」が本書の内容を的確に表現している。 情熱プログラマーを読みながらも感じたことなんだけど、プログラマーとして、どのように学ぶかという問題にはもちろん正解はない。だけど、人間は弱いものなので、そのような正解を求めて本を読む。様々な自己啓発書が本屋にあふれているのがその証拠だ。私自身、そのような自己啓発書の類の書籍にはあまり興味がないので、買うことも読むこともほとん
2010-02-14 - 未来のいつか/hyoshiokの日記
例えば、次の言葉の意味を知りたい、聞いたことがあるけどよく分かっていないプログラマにとって、お勧めの書籍だ。Unicode/UTF-8/UTF-16/USC-2/JIS X0208/JIS X0212/JIS X0213/SJIS/EUC-JP/CP932/ISO-2022-JP/ASCII/Latin-1/ISO 10646/ISO 8859-1/サロゲートペア/文字化け/機種依存文字/半角カナ/絵文字… JIS X0208やJIS X0213の解説などは圧巻である。書籍にはWebにない利点がある。Webには即時性があるが、文字コードの解説においては、即時性はそれほど求められない。字体ないし字形の差異についてWebではその字体ないし字形がなければ表現しようがないが、書籍であれば細部までこだわって表現できる。 例えば、包摂された「辻」という字の一点しんにょうと二点しんにょうの字体の差はWe
仕事で文書を書く必要がある人は理科系の作文技術を読むべきだ - 未来のいつか/hyoshiokの日記
仕事で文書を書く必要がある人は「理科系の作文技術」(ISBN:9784121006240)を読むべきだ。 ここでいう仕事で書く文書というのは他人に読んでもらう文書をさす。他人に読んでもらうことを前提としないメモの類や狭義の日記などはこれにあたらないので、どう書こうが構わない。他人に読んでもらうことを前提とした文書は、相手に内容が伝わらなければ意味がないのだから、間違いなく相手に通じるように表現しなければならない。 小説、詩などの文学作品は、ここでいう「仕事で書く文書」に含めないことにする。文学作品と対比して、仕事で書く文書の特徴はどこにあるのか。それは、読者に伝えるべき内容が事実と意見にかぎられていて、心情的要素を含まないことである。 仕事の文書を書くときの第一の原則は、「必要なことは洩れなく記述し、必要でないことは一つも書かない」ことである。何が必要かは目的により、また相手の要求や予備知
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
