「ひとりで何でもできるエンジニア」と時代背景:Geekなぺーじ
インターネットそのものが「新しいもの」であったころは、インターネットそのものとともにITエンジニアが成長できました。未踏な領域に踏み込む冒険心をくすぐられるミッションが、そこら中に転がっていました。「できなくてツラい」と苦しみつつも、マゾ的に心を踊らせチャレンジする環境がありました。 インターネットを利用することが珍しいことではなくなり、インターネットを活用したビジネスを実現するためのエンジニアリングの分業化も進みました。それに伴い、IT系エンジニアに求められる技能が細分化しており、「必要に応じて全部やる」ことが求められない環境も非常に多くなっています。 そういった環境の変化もあり、「昔と違って何でもできる人は育ちにくくなっている」という感想を持っている人も結構多い印象です。私の周りで「ひとりで何でもできるんじゃないかと思えるほど守備範囲が広いエンジニア」と私が思う凄い人々は、インターネッ
「すごいエンジニア」は凄いエンジニアになることを目指してないかも:Geekなぺーじ
「すごいエンジニア」が一部界隈で話題になっています。 「すごいエンジニア」が目指すもの 私がこれまでに「この人は凄いなぁ」とか「この人には一生かなわないなぁ」と思った「すごいエンジニア」は、次のようなイメージがあります。(ここでは、元記事の文脈に沿って「エンジニア」をという単語を主に「IT系の」として表現します。) 何かに没頭する能力が高い。 好奇心旺盛。 技術に関連する話題で議論している時、すごく楽しそうに話をする。 飲み会で語り合う話題は、基本的に技術に関連する話か興味を持っている何かに関連する話を好む。無難な世間話でジャブを打ち合うような飲み会は苦手。 技術に関連する資料を読むのが好き。勉強しているという意識はなく、単に楽しいから調べている。もしくは、調べ始めたら色々と気になって深堀りした結果として知識が増えただけ。 もともと英語が得意、もしくはIT関連の調べ物や発表等で必要だったか
ノマドワーキング（笑）してて怖い目にあった話:Geekなぺーじ
タイトルは釣りです。 私はノートPCを持ち歩いて時間があれば、外でキーボードをカチャカチャさせながら原稿を書いたりするのですが、この前、地方に行った時に少し怖いおもいをしました。 一度怖いおもいをしたことだけをもって一般化するのは多少乱暴ではあるのですが、「ノマドワーキング的な話って東京近郊だからできる話なんじゃね？」とそのときは思いました。 何が起きたかというと、予定よりも早く到着してしまったので駅の目の前にあるベンチに座りながらノートPCで原稿を書いていたら、いきなり怖いお兄さんに絡まれました。 「糞ガキぃー。パソコンやってんじゃねーぞー、コラぁー」という感じです。 駅前のベンチでパソコンを使っているだけでいきなり絡まれたのは初めてでした。 まわりにある程度人は居たのですが、相手が何をどのように腹を立てたのか皆目見当がつきませんでした。 ベンチでパソコンをする前は、喫茶店を発見して珈琲
「透明性」って本当に副作用が無いの？:Geekなぺーじ
先月、ローレンス・レッシグ教授による「The New Republic: Against Transparency」という記事が公開されていました。 多くの人が単純に「透明性は良いことだ」と考えていますが、果たしてそれは正しいのだろうかという内容です。 政府による情報公開が、逆に政策を不安定化させるのではないかという考察が11ページのエッセーになっています。 そこでは、レッシグ教授が政府による過度の情報公開を「Naked Transparency」と呼び、それがどのような害を及ぼすかに関する問題提起を行っていました （今回、この「Naked Transparency」という単語は「素っ裸の透明性」と表現しました）。 Targeted Transparency レッシグ教授のエッセーでは、「素っ裸の透明性」がどのように悪用されるかを具体的に説明する前に「Targeted Trasnparen
Geekなぺーじ : 良いプログラマの見分け方
「How to recognise a good programmer」という記事がありました。 良いプログラマを見分けて雇用するためのTIPSが書いてありました。 原文前半では、Paul Graham氏が書いている「The 18 mistakes that kill startups, 日本語版:スタートアップを殺す18の誤り」というエッセーに書かれている「90年代のE-コマースで多くのベンチャーを失敗させたのが質の悪いプログラマであるが、プログラマではない起業家には良いプログラマと悪いプログラマを見分ける術がない。」といった内容に対して反論すると書いています。 見分け方をまとめると、以下のようになるそうです。 流石に全ての項目を満たすような人は少ないそうですが、どれか一つでもあてはまる項目があれば、それは良いプログラマなのかも知れないそうです。 原文には、詳細な説明があるので興味のある
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を使ったりするのでご注意下さい
プログラマが席を離れる理由:Geekなぺーじ
コーヒーを入手するため 眠気覚まし コンパイルしているから makeを走らせた cvs update中(svnその他もあり得る) 設計が思いつかないから アルゴリズムが思いつかないから 良い書き方が思いつかないから トイレ おやつの時間だから テストスクリプトが走っているから 現実逃避 部長が不穏な動きをしている 身の危険を感じた 席を離れたプログラマが帰ってこない理由 スペースの個数に関して議論していた タブがスペース何個かを議論していた クラス名や関数名を大文字で開始するか小文字で開始するかを議論していた 開発言語を何にするかの議論がまとまらなかった GPLやBSDライセンスに関する上司の理解が得られず、激しい議論をしていたから すれ違いざまにWordの使い方を聞かれたけど、どうしても問題が解決しなかったため 同僚のPCがブートしなくなったため タバコ部屋で開発会議が勃発したため 先輩
Subversionを使ってプロジェクトを破綻させるためのTIPS:Geekなぺーじ
「Subversion worst practices」というプレゼン資料がありました。 Subversionを使ってできる最悪のバージョン管理方法を解説しています。 Google社員によるOSCON(2007/7)でのプレゼンのようです。 笑えました。特にレポジトリ直編集あたりが何度か。。。(ry。 利用するバージョン管理システムについてひたすら言い争う 既存のスクリプトなどの存在を全て忘れて何が何でもSubversionへ移行する バックアップなんて気にしない、もしくは毎晩「svnadmin dump」 色々な言語のファイル名を混在させる 開発者は信用できない。Lockしまくる。無断で編集させない。コンフリクトを防ぐ。Lockしたまま旅行へ行く。ついでにsysadminも連れて行く バージョン管理システムを直接使わせずに、それを使うスクリプトを作って使わせる 全開発者に自前プランチを与
Geekなぺーじ : オーム社開発部での開発体制
オーム社開発部さんでの本の作り方を取材させて頂きました。 社内で自作ツールをバリバリ作って、出版作業の効率化を行っているのが凄いと思いました。 ただし、今回取材をした内容が行われているのは、オーム社開発部のうちの1グループ(グループは約3名)です。 全体的にこの体制で行われているわけではないそうなので、ご注意下さい。 取材実現の経緯は「オーム社開発部の方とのやり取り」をご覧下さい。 Subversionでバージョン管理 著書の原稿は、XML管理されており、そのXMLはSubversionで全ての著者(監訳者)と共有されているそうです。 Subversionのサーバはインターネット上にあり、各自がリモートで作業を行える環境が整い始めているため、最近では著者と一度も会わずに本が完成するという案件もあるそうです。 フォントなどの問題から、本番環境でのPDF作成はオーム社開発部で毎日行っており、毎
Geekなぺーじ : 優秀な社員を辞めさせない方法
「16 Ways to Keep Your Best Employees -- Without Breaking the Bank」という記事がありました。 ITworld.comの記事です。 原文には、「多くの社長はビジネスのルールが変わったことに気がついていない。昔はお客様が神様だったが、最近は従業員を満足させる事で従業員がより良いサービスを提供して顧客を満足させるということが求められる。従業員がより芝が青い土地に移動すれば顧客もその従業員についていくだろう。」というような事が書いてありました。 新天地を探すというのは、既に辞める気持ちが発生しているということなので、そもそも従業員が「より青い芝」を探し始める時点で手遅れだそうです。 原文には、自分の土地をより青く保つための「種」を16個紹介しています。 以下、それらの要約です。 誤訳などがあるかも知れないので、詳細は原文をご覧下さい。
女性に興味を示さないプログラマ:Geekなぺーじ
「LOL Joke」というタイトルで面白い冗談がありました。 プログラマはコンピュータに没頭していて女性には興味が無いというイメージがあるんですかね。 (日本ではイメージが微妙に違いそうな気もしますが。。。) なお、コメント欄には「これ、古くからある冗談だね。でも、私の知っているオチは"理系学生なんだけど"だけどね」と書いてありました。 ある男性が道路を渡ろうとしていると蛙に声をかけられました。 「私にキスをしてくれれば、美しい姫に戻ります。」 男性は蛙を拾い上げポケットにしまいました。 蛙は、また語りかけてきました。 「私にキスをしてくれれば、美しい姫に戻ります。そして貴方が私にとってのヒーローで、知的で勇敢である事を皆に言ってまわります。」 男性は蛙をポケットから取り出して、蛙に向かって微笑みました。 そして、また蛙をポケットにしまいました。 蛙は、また語りかけてきました。 「私にキス
プログラマから起業家へ転身する際の注意点:Geekなぺーじ
「10 Tips for Moving From Programmer to Entrepreneur」 という記事がありました。 面白かったです。 要約してみましたが、間違っているかも知れないので詳細は原文をご覧下さい。 1. コーディングはあなたの仕事の5％でしかない コード書きに夢中になってしまう起業家がいます。 コードを書くことも重要ですが、いくら美しいコードを書いても、誰もその製品を使ってくれないのであれば意味がありません。 税金を払い忘れて逮捕されてしまったら書いたコードは無駄になります。 ソフトウェアのライセンスに無頓着であるために訴えられたら、コードは無駄になります。 ブログやフォーラムでコードの事ばかりを話題にする起業家を見る事がありますが、多くの場合、コードよりもビジネスの側面について考えた方が良いと思われます。 もちろん、コードについて語る方が簡単ですが、そもそも起業
Geekなぺーじ：選択肢を減らすことの重要性
Google TechTalksでBarry Schwartz博士による講演が公開されていました。 「The Paradox of Choice - Why More Is Less」というタイトルでした。 最初は、UNIXコマンドのmoreがlessよりも劣っている理由の事だと思って見始めましたが、そうではありませんでした。 何でも選べてベストじゃないと満足しないというのは、アメリカ人っぽい気もしましたが、かなり面白かったです。 ユーザビリティと機能の問題は良くある問題ですが、お店で展示されている商品の種類を減らした方が売り上げが上昇する話などが新鮮でした。 以下に要約してみました。 ここでは書いていない部分も多いので、詳細はビデオをご覧下さい。 字幕も入っていますし、ゆっくりと話してくれる人なので非常に見やすいと思います。 ただ、スライド(PPT?)が見られないので、何故観客が笑ってい
Googleによるマルウェア論文:Geekなぺーじ
「The Ghost In The Browser Analysis of Web-based Malware」というUsenixの論文がありました。 PDFがダウンロード可能なので、興味のある方は読んでみる事をお勧めします。 この論文は、HotBots 07というボットネットに関してのWorkshopで、他に発表されていた論文も面白そうでした(まだ他のは読んでいません)。 NATやファイアウォールの普及によって、最近ではワーム(Worm)の勢いが衰えてきて、マルウェア作者にとってはWebが活動の主体になりつつあるそうです。 この論文は、Google社の社員5人によって書かれています。 Googleのクローラが収集しているWebページリポジトリを利用して解析を行った論文です。 この論文では、ふるいにかけたURLをバーチャルマシン上のInternet Explorerに渡して実行状況をモニタ
中小企業にプログラマはいらない:Geekなぺーじ
「Small ISVs: You need Developers, not Programmers」という記事がありました。 2003年5月の記事のようです。 半分根性論な気もしましたが、この記事の視点は非常に面白かったです。 そうなのかもと思う面もありました。 この記事を書いている人は25人の社員がいるソフトウェアベンダを運営しているそうです。 6年間会社を続けてわかったこととしては「小規模な企業にプログラマは居てはならない」だそうです。 必要なのは「プログラマ」ではなく「開発者」だそうです。 以下が駄目な「プログラマ」の特徴だそうです。 小規模企業では以下のような人は「いらない」そうです。 新しい機能を実装することばかりする たまにバグを修正する 仕様書を書かない ドキュメンテーションを書く手伝いをしない 自動化されたテストを作成しない テスト実行を手助けしない 開発環境を最新に保たな
コンピュータ関連名言(迷言)集:Geekなぺーじ
コンピュータ関連名言(格言？)を集めてみました。 「computer quotes」や「IT quotes」などの単語で検索してみましたが、そこらじゅうに同じようなサイトがあり、どれがオリジナルだかわかりませんでした。。。 いくつか楽しいと思ったのをピックアップしてみました。 他にも色々あったので、興味のある方は検索をしてみて下さい。
Geekなぺーじ：Google Code Searchの危険な使われ方
「Fun With Google Code Search」によると、 Google Code Searchを使って脆弱なソフトウェアを見つけられてしまうそうです。 実際に、Google Code Search経由で発見されてサーバを乗っ取られた事例が「How Hackers Are Using Google To Pwn Your Site」という記事で紹介されています。 ShoeMoneyが乗っ取られた事例では、恐らくWebサーバの設定ミスで.phpファイルの関連付けを行わない状態で、Google Sitemapsに登録してしまったため、Google Code Searchに自作コードが載ってしまい、それを見たクラッカーがサイトを乗っ取ったのであろうと思われます。 バッファオーバーフロー strcpy : strcpy\((\w+,\w+) lang:c sprintf : (sprin
Geekなぺーじ：クラッカーがGoogleを使って脆弱なサイトを探す方法の例
Googleを使って脆弱性のあるサーバを探す手法を「Google Hacking」と言いますが、その検索方法を大量に集めた 「Google Hacking Database (GHDB)」というサイトがあります。 そこでは様々な検索キーワードが紹介されています。 紹介されているものを、いくつかピックアップしてみました。 (ただし、多少古いです。) このような検索を行って脆弱性のあるサーバを探している人が世の中に結構いるみたいです。 サーバを運用している方はご注意下さい。 これらの情報は既に公開された情報なので、検索結果にはワザとこのような情報を流して侵入を試みる人を誘い込もうとしているハニーポットが含まれている可能性もあります。 秘密鍵を探す 秘密鍵は公開鍵と違って秘密にするものなので発見できてしまうのは非常にまずいです。 BEGIN (CERTIFICATE|DSA|RSA) filet
こんなあなたは。。。(ry:Geekなぺーじ
TOP > ブログ > こんなあなたは。。。(ry こんなあなたは。。。(ry 2006/12/7 1. この項目が1ではなく0から始まるべきだと主張する 2. ++が1を足すことだとわかる 3. 人を/dev/nullに叩き込みたくなることがある 4. 25歳なのに0x19歳だといいはる 5. 30歳ではなく32歳が区切りだと思っている 6. 飲み会でcore dumpと言って意味が通じる 7. 話題が変わる事をコンテキストスイッチと言う 8. 起床の事をbootと言う 9. 「ラクダ本」と言われて動物の本ではないと思う 10. /* この文が読めない */ 11. <!-- この文も読めない --> 12. # この文も読めない 13. #if 0 この文も読めない #endif 14. // この文も読めない 15. ; この文も読めない 16. % この文も読めない 17. dnl
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
