オーム社電子書籍直販サービス終了に関して:Geekなぺーじ
オーム社が電子書籍直販サービスを終了するというお知らせがでていました。 同社では、マスタリングTCP/IP RTP編(2004年)、インターネットのカタチ(2011年)、マスタリングTCP/IP OpenFlow編(2013年)の3冊で関わらせていただいたこともあり、今回廃止される電子書籍直販サービスで拙著も販売されていました。 オーム社eBook Storeサービス終了のお知らせ 電子書籍直販サービスが終わるということは、ネット上で話題になっていることで知りましたが、「そのうちこうなるだろうと思っていた」ということが起きました。 10月29日に「運営スタッフ退任のお知らせ」というお知らせが出ており、eBook Store企画運営担当の森田さんが「運営スタッフ退任」とあります。 そのお知らせからは社内異動のようにも読めますが、実際は運営スタッフ退任だけではなく、10月末で退職されたようです
「ひとりで何でもできるエンジニア」と時代背景:Geekなぺーじ
インターネットそのものが「新しいもの」であったころは、インターネットそのものとともにITエンジニアが成長できました。未踏な領域に踏み込む冒険心をくすぐられるミッションが、そこら中に転がっていました。「できなくてツラい」と苦しみつつも、マゾ的に心を踊らせチャレンジする環境がありました。 インターネットを利用することが珍しいことではなくなり、インターネットを活用したビジネスを実現するためのエンジニアリングの分業化も進みました。それに伴い、IT系エンジニアに求められる技能が細分化しており、「必要に応じて全部やる」ことが求められない環境も非常に多くなっています。 そういった環境の変化もあり、「昔と違って何でもできる人は育ちにくくなっている」という感想を持っている人も結構多い印象です。私の周りで「ひとりで何でもできるんじゃないかと思えるほど守備範囲が広いエンジニア」と私が思う凄い人々は、インターネッ
RFCの正規文書がXMLに:Geekなぺーじ
インターネットに関連するプロトコルなどを規定するRFC(Request For Comments)の正規文書のフォーマットが、これまでのplain-text ASCIIからXMLへと変わります。そのためのRFCが、RFC 7990 - RFC 7998として策定されました。 RFC 7990 RFC Format Framework RFC 7991 The "xml2rfc" Version 3 Vocabulary RFC 7992 HTML Format for RFCs RFC 7993 Cascading Style Sheets (CSS) Requirements for RFCs RFC 7994 Requirements for Plain-Text RFCs RFC 7995 PDF Format for RFCs RFC 7996 SVG Drawings for R
svn＋TeXでcommitするとPDF - オーム社開発部の出版システムでの書籍執筆:Geekなぺーじ
以前、オーム社開発部の出版体制を取材しましたが、今回、私自身がそのシステムを使って本を書きました。 Subversionでバージョン管理をしつつLaTeXで本を書く形式です。 複数人で本を書く時にバージョン管理ツールを使わないと、誰がどこをどういじったのかがわからなくなったり編集箇所が競合する場合が多いのですが、Subversionを使うことでそれらが解決可能です。 さらに、筆者か編集者のうちの誰かがsvn commitを行って最新版を更新すると、それに連動して最終原稿として印刷所に入稿されるものと同じ形のPDFが自動的に生成され、DTP作業がゼロになるとともに、筆者がアウトプットを細かく確認ができるという特徴もあります。 しかも、Subversionのコミットメールを編集者側も見ていて、該当部分に対する編集やコメントがすぐに投入され、こちらが文章を書いた数分後に編集側意見が含まれるPDF
Geekなぺーじ : Mac OS Xネットワークプログラミング
Mac OS Xでのネットワークプログラミングを勉強しながら、少しずつ公開していくコーナー。 コードを書く前の準備 まず、gccを使える状態にしないといけません。 Mac OS Xを普通にインストールしただけでは開発環境は入りません。 Xcodeを含むMac OS X開発環境はOS DVDなどに入っています。 次に、エディタが必要になります。 標準開発環境であるXcodeを利用して書くことができます。 一方で、UNIXやLinuxなどで一般的なエディタであるmule、emacs、xemacsなどを利用することも可能です。 個人的にはviが好きです。 Cocoa ファイル単体をそのままコピペしてgccでコンパイルできるCUIとして書いているので多少特殊な書き方をしている気がします。 GUIを使う場合はNSRunLoopではなく、NSApplicationMainを使ったりするのでご注意下さい
次世代JavaScriptの形:Geekなぺーじ
8年間の標準化活動の成果として今後変化していくJavaScriptの形を紹介しています。 なお、JavaScriptの標準化は未だ過程であるため、ここで紹介された事が将来実装されない可能性もあるそうです。 いや、でも、聞いていて思ったのですがこれはもう違う言語ですね。。。 下位互換があるので今まで作られた物は問題なく動作するはずなのでしょうが、 CとC++に微妙な互換性があるように、互換性をつけたばかりにゴチャゴチャになる事も将来ありそうな予感がしますね。。。 まあ、でも全く違う物として出してしまうと「何それ？ハァ？」という感じで世界に華麗にスルーされてしまうでしょうし、悩ましいところなのだと予想します。 以下、ビデオの要約です。 私はJavaScript初心者なので、要約が間違っているかも知れません。 また英語の誤訳などが含まれているかも知れないので、詳細はビデオをご覧下さい。 Java
オープンソースに貢献する日本人エンジニアが少ない理由:Geekなぺーじ
Mozilla Japanの金井玄氏のブログで「Open source contributors in Asia」という記事が書かれていました。 アジア地域では、OSS(Open Source Software)を使う人が多いのに貢献が少ないのは文化的な要因が大きいのではないかと書かれています。 Linux FoundationのJim Zemlin氏とLinus Torvalds氏の対談の中でTorvalds氏が文化的側面が大きいのではないか、と述べている点に注目しています。 原文では、じゃあ文化的側面とは何だ？という事に関しては明確に書かれていない気がします。 原文は「アジア人」とひとくくりにされていますが、個人的には日本とその他のアジア地域で「文化的側面」が同じとはあまり感じられなかったので、とりあえず、「日本人」というカテゴリで思いつくだけ列挙してみる事にしてみました。 思いつきで
Geekなぺーじ : 人生の全てはTCP/IPに学んだ
1. ゆずり合うこと TCPはネットワーク帯域を他のTCPセッションと譲り合います。 TCPには、ネットワークが混雑(輻輳:ふくそう)してくると、送信されるパケット量を減らす仕組みがあります。 この譲り合いがあるからこそ、現在のインターネットは多数の人間が同時に使えています。 同様に、現実世界においても無理な競い合いを行うよりも譲り合いを行った方がスケーラビリティが上昇します。 2. 信頼はきめ細やかな確認応答で実現されること TCPでは、信頼性を確保するためにAck(Acknowledgement、確認応答)を送信してデータの到着を伝えます。 TCPのセッションが確立している間は、Ackが細かく送受信され続けます。 このきめ細かな確認応答が信頼の根幹であると言っても過言ではありません。 現実世界においても、きめ細かく応答を行う事が重要です。 メールなどを受け取っても、全く返事をしない相手
Geekなぺーじ : オーム社開発部での開発体制
オーム社開発部さんでの本の作り方を取材させて頂きました。 社内で自作ツールをバリバリ作って、出版作業の効率化を行っているのが凄いと思いました。 ただし、今回取材をした内容が行われているのは、オーム社開発部のうちの1グループ(グループは約3名)です。 全体的にこの体制で行われているわけではないそうなので、ご注意下さい。 取材実現の経緯は「オーム社開発部の方とのやり取り」をご覧下さい。 Subversionでバージョン管理 著書の原稿は、XML管理されており、そのXMLはSubversionで全ての著者(監訳者)と共有されているそうです。 Subversionのサーバはインターネット上にあり、各自がリモートで作業を行える環境が整い始めているため、最近では著者と一度も会わずに本が完成するという案件もあるそうです。 フォントなどの問題から、本番環境でのPDF作成はオーム社開発部で毎日行っており、毎
オーム社開発部の方とのやり取り:Geekなぺーじ
先日、本ブログにて「退職報告及び自己紹介」という記事を書いたところ、マスタリングTCP/IP RTP編を監訳したときのご担当の方からメールを頂きました。 実はこのブログの読者だったそうでが、自己紹介文章を読んでびっくりしたとの事でした。 今回のやり取りに関して書く了承を頂けたので、書いてみました。 何度かメールをやり取りしていましたが、今度おじゃまして色々お話を聞かせて頂くお願いをしました。 今回は、お時間を頂戴してフリーな打ち合わせという形でお邪魔させて頂く予定です。 後日、先方の了解を得られた範囲内で公開したいと思っていますが、まだどうなるかは未定です。 RTP本の監訳をしているときに、昔の技術出版業界と最近の技術出版業界というような話や、出版の流れなどを色々教えていただけて面白かった記憶がありました。 それも、もう5年以上前になるのですが、当時とは多少編集方法が変わってきているようで
プログラマとは:Geekなぺーじ
例外を考える職業であり、 本流から外れた些細な出来事に関しても気になってしかたがなく、 ついつい会議などにおいても余計な事を口走り、 非プログラマから冷たい目で見られる事もしばしばである。 問題が発生した時には、全身全霊を持って問題発生箇所の特定に勤め、 目を皿にしてコードを眺めたりするが、契約等の問題によりソースコード閲覧権が認められていない場合には、 クラッカー的に様々な実験行動を繰り返しつつ、ファーブルがフンコロガシを観察するのように注意深く結果を見守り、 問題発生箇所の予測を繰り返すが、最終的には「ここが変じゃない？」と他者に詰め寄るという行動を好む。 長時間コンピュータの前に座り続ける事が多く、非プログラマからは「目が悪くならない？肩こらない？」と聞かれることが多いが、 プログラムを書く事自体を苦痛と思っていない間は不思議と目も疲れず、肩もこらないという特技の持ち主である場合もあ
Geekなぺーじ : 優秀なプログラマは取替えが利く？
恐ろしく優秀な職業プログラマは取替えが利くのではないか？と思いました。 優秀な職業プログラマは、自分のやっている事をきっちりドキュメント化します。 そのドキュメントは非常に読みやすく、内容に漏れが無いため、新しく入ってきたプロジェクトメンバはスムーズに開発に取り掛かれます。 優秀な職業プログラマは、誰でも実行できる形式でテストコードを大量に書いています。 そのため、何かを変更して予期しないバグが入り込んでも発見が早くなります。 また、テストコードを皆で共有する体制を作ってあるので、作ったものの堅牢性を新しく入ってきたプロジェクトメンバが確認することも出来ます。 優秀な職業プログラマは、他のメンバにソフトウェアの設計思想を正しく伝えてあります。 そのため、自分が行っている開発箇所を他人に委譲することも容易に可能です。 優秀な職業プログラマは、良く知られているデザインパターンを適切な箇所で利用
Geekなぺーじ : Rubyネットワークプログラミング
ここでは、Rubyによるネットワークプログラミングの説明を行いたいと思います。 ここで対象としている読者は、ネットワークプログラミング初心者（もしくは入門者）です。 TCP 簡単なTCPサーバとクライアント TCPクライアント(エラー処理付き) 何度も受信できるTCPサーバ TCPサーバ(acceptした相手の確認) UDP UDPを使う UDPでブロードキャストを使う UDPでマルチキャストを使う(マルチキャストを送信する) UDPでマルチキャストを使う(マルチキャストを受信する) UDPでマルチキャストを使う(TTLを設定する) Web 簡単なHTTP GET（Net::HTTP） HTTP HEADと全てのHTTPヘッダの表示（Net::HTTP） HTTP POST（Net::HTTP） 簡単なRSSクライアント その他 IO::selectを使う IPアドレスからホスト名への変換
Geekなぺーじ : 優秀な社員を辞めさせない方法
「16 Ways to Keep Your Best Employees -- Without Breaking the Bank」という記事がありました。 ITworld.comの記事です。 原文には、「多くの社長はビジネスのルールが変わったことに気がついていない。昔はお客様が神様だったが、最近は従業員を満足させる事で従業員がより良いサービスを提供して顧客を満足させるということが求められる。従業員がより芝が青い土地に移動すれば顧客もその従業員についていくだろう。」というような事が書いてありました。 新天地を探すというのは、既に辞める気持ちが発生しているということなので、そもそも従業員が「より青い芝」を探し始める時点で手遅れだそうです。 原文には、自分の土地をより青く保つための「種」を16個紹介しています。 以下、それらの要約です。 誤訳などがあるかも知れないので、詳細は原文をご覧下さい。
Subversionを使ってプロジェクトを破綻させるためのTIPS:Geekなぺーじ
「Subversion worst practices」というプレゼン資料がありました。 Subversionを使ってできる最悪のバージョン管理方法を解説しています。 Google社員によるOSCON(2007/7)でのプレゼンのようです。 笑えました。特にレポジトリ直編集あたりが何度か。。。(ry。 利用するバージョン管理システムについてひたすら言い争う 既存のスクリプトなどの存在を全て忘れて何が何でもSubversionへ移行する バックアップなんて気にしない、もしくは毎晩「svnadmin dump」 色々な言語のファイル名を混在させる 開発者は信用できない。Lockしまくる。無断で編集させない。コンフリクトを防ぐ。Lockしたまま旅行へ行く。ついでにsysadminも連れて行く バージョン管理システムを直接使わせずに、それを使うスクリプトを作って使わせる 全開発者に自前プランチを与
ブログ:Geekなぺーじ
「ピアリング戦記」の英訳版EPUBを無料配布します！ 英語のIT系技術書が日本語訳されて海外に届けられることは多く行われていますが、日本語版から英語版への翻訳には高いハードルがあります。 過去に、何度か私が書いた本を英語に翻訳して出版することはできないかを模索したことがありますが、これまで企画が実現することはありませんでした（中国語への翻訳はあります）。 しかし、今回、私としては初となる英訳版を上梓することができました。 2022年に出版した「ピアリング戦記 - 日本のインターネットを繋ぐ技術者たち」ですが、これを日本語だけにしておくのはもったいないという声を内外でいただき、それを受けて英訳を行うプロジェクトが去年動き始めました。 続きを読む... IPv4アドレス移転の売買価格推移および移転組織ランキング100 IPv4アドレスの中央在庫が2011年に枯渇後、IPv4アドレスの移転や、移
確実に失敗する方法:Geekなぺーじ
「10 Steps You Can Take To Guarantee Failure」という面白い記事がありました。 逆説的な表現がかなり笑えました。 以下に要約してみましたが、かなり削って意訳していますし、誤訳している可能性もあるので原文もご覧下さい。 1. 目標を曖昧にすべし 「もっと」や「ちょっと」という表現を多用した目標設定をしましょう。 例：「もっとお金が欲しい」「ちょっと体重を減らしたい」「何かの仕事をしたい」。 2. 目標を解りにくくすべし ゴールを曖昧にして、あれもこれも、あれでもいい、これでもいいとしとけば、何も達成できないようになれます。 3. 目標を後ろ向きに考えたり語ったりすべし 「できない」「難しすぎる」を多用して兎に角自分を蔑みましょう。 4. 途中経過をすっ飛ばして目標だけを考えるべし 地道にマイルストーンを積み重ねた目標を作ってしまうと失敗しにくくなるので
Geekなぺーじ：1000円の投資でプログラマの開発効率を向上させる
プログラムを書いていると、設計などに関して一緒に開発している人と議論をしたくなることがあります。 そのような時に、ちょっと書く場所があると、劇的に議論の効率が向上します。 紙に図を描いたり消したりすることも出来ますが、ちょっと書き直したいときに紙だと気楽に消せません。 また、議論を頻繁にするような場合、紙が勿体無いような気分になります。 そこで、議論をするときに、1000円以下で販売されているこの小型ホワイトボードがあると非常に便利です。 ホワイトボートというと、普通は巨大なものを想像すると思いますが、この小型ホワイトボードは非常に小さいです。 幅45cmです。 また、値段が安く、作りがちゃっちいため、非常に軽くて良いです。 なお、上記画像リンクはアフィリエイトリンクです。 ご注意下さい。 アフィリエイトリンクを踏むのが嫌な方は、お近くの文具店などでお買い求め下さい。 使ってみると結構便利
勉強は至高の贅沢かもしれない:Geekなぺーじ
学生である間は、勉強をすることが強要されます。 そして、多くの学生は勉強をすることをあまり好まないような気がします。 学生期間中は勉強をする主な目的が進学や就職をするためなので、勉強をしたいから勉強をするという人は少ないと思われます。 しかし、一度学生という身分を卒業してしまうと、もう一度学生という身分になるということは、ある種の贅沢ではないかと思われます。 まず、仕事をやめてフルタイムで学生になるには相当の覚悟が必要になります。 入学資金や学生である期間中の生活資金も必要になります。 また、ある程度の年齢になってから学生になると、卒業後に就職をするのが困難である場合が多くなります。 そのため、卒業後に就職活動をしなくても良い身分であるか、もしくは既に卒業後の職がある程度決まっているという条件が、場合により発生します。 このように書くと、再び学生に戻るというのは、既に財力がある人か、もしく
生々しい製品紹介を読みたい:Geekなぺーじ
様々な製品やサービスの開発社インタビューが雑誌やネットに載っていることがあります。 ですが、インタビューに答えているのは大抵偉い人かマーケッティング担当者か企画担当者です。 そして、インタビュー内容は製品に関する性能や、狙ったマーケット、聞こえの良い表向きの苦労ポイントなどです。 それらを読んでいると、何か物足りません。 もっと生々しい、執念のこもったような、そんなインタビュー記事を読んでみたいと思ってしまいます。 現場には無数の無名エンジニアがいるはずです。 使う人が誰も気に留めないような、ちょっとした機能を作った人の苦労を聞いてみたいような気がします。 外注先がコケて現場が騒然となった話を読んでみたいと思います。 締め切りに間に合わない状況になって土日も関係なく、ひたすら苦労した現場の修羅場具合を知りたいと思います。 例えば、オンラインサービスであれば、一つの画面が出来上がるまでの社内
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
