°æ¾å
http://dev.ariel-networks.com/Members or http://dev.ariel-networks.com/Members/inoue ¤Ç¤¹¡£ ²áµî¤Îblog¤Ïºï½ü¤·¤Ê¤¤¤Î¤Ç¡¢¥ê¥ó¥¯¤Ï¼«Í³¤Ë¤·¤Æ¤¯¤À¤µ¤¤¡£ EoE (Ethernet over Ethernet) http://itpro.nikkeibp.co.jp/article/COLUMN/20051216/226378/ 狼¤«¤é¸ýƬ¤Çʹ¤¤¤Æ¤¤¤¿¤é¡¢¾éÃ̤À¤È»×¤Ã¤Æʹ¤Î®¤·¤¿¤È»×¤¤¤Þ¤¹¡£ Ethernet¤Ë¤è¤ëËܳÊŪ¤Ê¥ë¡¼¥Æ¥£¥ó¥°¤¬¹Ô¤ï¤ì¤Æ¤â¡¢ÉԻ׵ĤǤϤʤ¤À¤¤ÎÃæ¤Ç¤¹¡£ TCP/IP¤òC¸À¸ì¤ËÎ㤨¤ë¤
社内評価に不満の技術者こそ、外へ――Seasar開発者がメッセージ － ＠IT
2007/10/30 「偉くなりたい、金がほしいのではなく、自分のことを認めてほしいのがエンジニア。そのためには社外に出て行くしかないと思った」。オープンソースのJava軽量コンテナ「Seasar」の開発者で、電通国際情報サービスに勤める比嘉康雄氏は10月30日、「IPAフォーラム2007」で講演し、自身の経験から「エンジニアは社外に出て行くことで認められる」と訴えた。 社外に出て行かないとエンジニアは評価されない――比嘉氏がそう感じるのは自身の社内での仕事が正しく評価されていないと感じていたからだ。自身の仕事を社内にアピールできなかったことや、アピールしても仕事を上司が正しく評価してくれなかった過去のケースを挙げて、「技術者は社内で認めてもらうのが非常に難しいと思った」という。 技術者の仕事を評価するのは一般的にはその上司。しかし、管理が仕事の上司は最新の技術動向に詳しくなく、技術者が最
maeda.na@はてな - ITpro Challenge!のメモとか
やたらと豪華なメンバーで話題沸騰のイベント、ITpro Challenge!に行って来た。 定員70名の中のラッキーな一人だったのでさっそくレポート…というかただのメモ。 もし会社員のままだったら今日絶対休めてないのでいいタイミングで辞めた俺GJ。 詳しい内容は後日動画がニコニコとかに上がるそうなのでそちらをチェックされたし。 発表者とLTの面子だけでも豪華なのに、右斜め前を見ればMatz氏が、左を見れば吉岡氏がいらっしゃったり…など聴衆もスゴかった。 メモが取り切れてないので細かい点は色々はしょって印象的だった所だけ…。（聞き入ってた。） 懇親会は存在を知らずに申し込んでなかったので直帰。出来れば参加者宛にメール流してほしかったなぁ…ブログの存在知らなかった…。 参加者へのリマインドメールにブログの記載がありました。僕が勝手に見落としていただけのようです。 2007/09/10追記 もは
masuidrive on rails » Blog Archive » masuidrive的プロジェクトの方針
初めて会社員になって早3ヶ月。会社の仕組みもやっと分かってきたし、そろそろ本格的に開発プロジェクトも動いて行くということで、今後、社内で私と一緒に開発して行く人に、「私がどういう考えで仕事を進めていきたいか」という事を知ってもらうためのプレゼンを作ってみました。(今のところ一人だけど) NIFTYさんと仕事した時も、作業に入る前に「今までどうやって遠隔地で仕事を進めてきたのか」をプレゼンしていました。特に初めて仕事をする場合、「今まで自分はどういう風に仕事をしてきて、この仕事はどういう風に勧めていきたいか」を明確にしておくと、スムーズに仕事を進めることができます。 仕事、特にその上でのコミュニケーションをうまく進めていくためには、信頼と共通認識が必要だと思ってます。信頼は当たり前の話ですが、開発を進める上での共通認識についてはあまり重要視されることが無い気がしています。 仕事をする上ではコ
steps to phantasien t(2007-07-06)
昔の同僚が退社してベンチャー仕事をやるという. 門出を祝う宴会に, 昔のよしみで呼んでもらった. ついでに古巣の近況を聞く. ひとつ嬉しい知らせがあった. 以下その自慢話. ある夏, 私は社内ライブラリのチュートリアルを書いた. そのチュートリアルが, 今でも改訂されながら参照されているという. のみならず新人プログラマの研修教材として広くとりいれられつつあるそうだ. 私はとても嬉しくなった. もちろん手柄は改訂を続け, 様々な改善を続けた彼らのものだ. それでもなお私は喜びを隠せない. 自分が去った今も文章だけが生き続けている. 私は平凡なプログラマだから, 自分のコードが生き残れるとは思えない. 一方ボランティアで仕事の合間に書いた文章は読み継がれている. 価値のあるものが生き残るのなら, 私のなした価値は(コードではなく)文書にあったことにある. プログラマとしては悲しいけれど, 会
小野和俊のブログ:そして、ペア･プログラミングが始まる
ここ数日、私はずっとペアプログラミングをしている。 ペアプログラミング自体は、これまでに何度も経験したことがある。 しかし今回の試みが今までと違うのは、 一日中、ペアプログラミングしかしないという点である。 １セット1時間半、15分の休憩を入れて、 ドライバーとナビゲーターを交互に入れ替えて毎日4セットやる。 このところ、これを何日も続けている。 こうやって、ある程度ストイックに続けてみることで、 わかってきたことがある。 それは、ペアプログラミングにはメガトン級の破壊力があるということだ。 プログラマーは絶えず誘惑にさらされている。 調べ物でウェブを見たついでに何時間もネットサーフィンしてしまったり、 考えたことをメモするついでに2時間かけてブログを書いてしまったり、 仕事の用事で知人に IM したついでにしばらくだべってしまったり、 Twitter に書き込んだついでに Friends
ODD - おもいやり駆動開発：An Agile Way：オルタナティブ・ブログ
思いやり駆動開発（ODD） ソフトウェア開発を成功させる、もっともシンプルな「こころがけベース」のアプローチである。オブジェクト倶楽部2007夏イベントで発表された。ここでは、ついカッとなって私なりにこのコンセプトを膨らませてみたい。 ソフトウェア開発はコミュニケーションでできている。ソフトウェアの欠陥が発生しやすいのは、人と人の境界、プロジェクトとプロジェクトの境界。そしてそこにはコミュニケーションが生まれている。コミュニケーションには相手があり、その相手を「思いやる」ことが、大切だ。読み手のことを思いやるコードを書こう。システムのユーザを思いやる仕様にしよう。そんなシンプルな「こころがけ」だ。 具体的には、こういうこと。 システムを実際に使う「ユーザー」を思いやろう。ストレスなく使え、「思った機能がそこにある」ようなシステムにしよう。そのユーザが普段使っている言葉のUIを提供しよう。製
へ〜たのめも:Google のソフトウェア・エンジニアリング - livedoor Blog（ブログ）
2007年06月07日 Google のソフトウェア・エンジニアリング Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Google のエンジニアはどうやって開発しているのか?」 Google の研修 入社して最初の 3ヶ月は本社(Mountain View)で研修 研修中は、メンターがついて「Google での開発の仕方」を学ぶ 内部ウェブ・サイトで社内共有ライブラリの使い方などを説明する動画があるので、それで自習 Google のプロジェクト・チーム 開発拠点は米国、スイス、オーストラリア、インド、日本など 場所とプロジェクト・チームは関係なく、プロジェクト・チームが拠点をまたがることは普通。世界中の拠点全部合わせて、一つの Google エンジニアリング・チーム 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同
「ひとりで作るネットサービス」探訪に登場しました！
「ひとりで作るネットサービス」探訪に登場しました！ 2007-06-11-2 『田口元の「ひとりで作るネットサービス」探訪』に登場しました！ ITmedia Biz.ID：「サービスは半日で完成させる」--SETAKE・たつをさん http://www.itmedia.co.jp/bizid/articles/0706/11/news034.html SETAKE や EReK など、比較的最近に公開したサービスを主に取り上げて頂きました。下記の４つです。 - 有名人身長推定サイト SETAKE (ref. [2007-04-29-2]) ttp://setake.net/ - 英語例文検索 EReK (ref. [2007-05-17-2]) http://erek.ta2o.net/ - 買ったら検索 (ref. [2007-04-29-3]) http://kattara.ta2o.
Matzにっき(2007-02-15)
<< 2007/02/ 1 1. 和田英一＠日本初ハッカーはちょっと変わった絵を描く／Ｔｅｃｈ総研 2. ITmedia エンタープライズ：「PC 2.0の牽引役」--wizpyの詳細が判明 3. [言語] バベル案内 2 1. [Ruby] ユメのチカラ: Rubyで習作 添削 2. [Ruby] kiwamu日記 - RubyConf 2006 の裏番組、RejectConf の実施形式メモ 3. 西川善司の3Dゲームファンのための「ロスト プラネット」グラフィックス講座 4. [Ruby] YARVに手を入れる 3 1. [Ruby] RailsConf 2007 May 17, 2007 - May 20, 2007 Portland, Oregon 2. 仕事中に口笛を吹いて、コンピューターにコマンドを実行させる 3. [教会] 掃除→食事 4 1. [教会] 証会 5 1. [
steps to phantasien t(2007-01-11) 最近みた TechTalks: Mondrian Code Review On The Web
Python の親玉である Guido Van Rossum が, Google での初仕事(?) として Mondorian というコード・レビュー用ウェブアプリを 作ったよ, という話. ミーハー的に視聴. 前半はレビューとは何か, なぜそれが必要なのか, OSS でのレビューなどについて説明し, 後半から Mondrian 以前の Google 社内でのレビュー体制とその問題点を指摘, Mondrian の話と続く. Google では SCM に Perforce を使っており, レビューは patch + メールベース. Mondrian 以前は Perforce の CL クライアントをラップする g4 というスクリプトを使ってレビューを支援していた. これを使うと patch をメールでレビュアに飛ばしたりできる. その飛ばしたメールを起点にレビュアとレビュイが議論し, "l
デモではものができあがっているように見せない
Kathy Sierra / 青木靖 訳 2006年12月27日 (アルファ版のような)開発中のものを私たちが世間や、クライアントや、ボスに見せるときには･･･彼らの期待のレベルを設定することになる。これは3通りの方法でやることができる。磨き上げられたモックアップで幻惑するか、プロジェクトの現状に合ったものを見せるか、ほとんどできていないものを見せながら順調に進んでいるから「信用しろ」と言っていら立たせるかだ。 結論を言うなら: どれくらい「できている」ように見えるかは、実際どれくらい「できている」かに合わせるべきだ。 ソフトウェア開発者はみんなそのキャリアにおいてこのことを何度も思い知ることになる。しかしテクニカルライターもまた、デスクトップパブリッシングツールによって同様の問題に直面する——フォントやレイアウトが完璧に仕上げられたドラフトを誰かに見せるなら、その人はあなたが考えるよりも
[結] 2006年6月 - 結城浩の日記:モノクロ画像がカラーに見える錯視
目次 2006年6月25日 - 長男と完全数談義 / 2006年6月23日 - ティナからの手紙 / 2006年6月20日 - 無神論者との対話 / 2006年6月18日 - 父の日 / 2006年6月16日 - ソフトウェアは、私たちの想像よりもずっと複雑 / 2006年6月14日 - 仕事 / 2006年6月13日 - 無限羽の鳩と無限個の巣 / 仕事 / Haskell / 読書 / 2006年6月12日 - 仕事 / 2006年6月10日 - モノクロ画像がカラーに見える錯視 / 日記ダイジェストを更新 / 2006年6月8日 - www.textfile.orgのお引っ越し / 2006年6月5日 - 仕事 / 2006年6月4日 - 今日の一日 / 2006年6月3日 - 誤植 / 2006年6月1日 - 仕事 / ぜひ、感想をお送りください 日記一覧 2006年6月25日 ■
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer