2024夏休み旅行 神戸・2日目【前編】 zfinchyan.hatenablog.com ↑1日目はこちら 6:50 わたしと夫だけ先に起床 前日に買っておいたお芋のパンで朝ごはん 昨日の疲れからか、なかなか息子たちが起きてこなかったので、ゆっくり寝かせてから10:00にホテルの下にあるプレイゾーンに行って、パターゴルフやバス…
![はてなブログ | 無料ブログを作成しよう](https://cdn-ak-scissors.b.st-hatena.com/image/square/06a15c64ba0ceec233d86d71001ebb29a9dcbf5d/height=288;version=1;width=512/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
この企業の社畜として、自己の立ち位置を再確認するために読んだのだが、結局のところ、ど真ん中の一冊になった。「ソフトウェア企業の競争戦略」を紹介していただいたこの記事に感謝。好川さん、ありがとうございます。ソフトウェアでメシを食べている人は必読だろうなぁ…。理由は次の通り。 ソフトウェア・ビジネスが一般のビジネスと違いが無いのであれば、本など書く必要がない。この本は「ビジネス」としてみた場合の「ソフトウェア企業」を冷徹な視線で語っている。ソフトウェア・ビジネスとして成立させるために必要なことは「製品とサービスのハイブリット形態」なり。製品は市場に参入し、シェアを確保するため、サービスは恒常的な収入を得て、好不況の波を越えていくために必要。マイクロソフト、IBM、オラクル、SAP、シーベル、i2テクノロジーズの例を挙げて、その必要性を詳細に語っている。 世界と比較して、日本のプログラマは優秀か
Hardcoded さんからトラックバックをいただいた。 Blog 悲観論にモノ申す http://www.dmtj.net/pm/archives/000040.php 例えばの話、超優れた職業プログラマがいてさ、その人がオープンソース・コミュニティに参加もしくは貢献しないといってそれを責める権利はどこのどいつも持っちゃいないのよ。Blog だって同じことが言えると思わないか? あ、多分梅田さんの意図を誤解していると思う。 梅田 Blog論2005年バージョン(2) http://d.hatena.ne.jp/umedamochio/20050426/p1 裏切られた期待として、 大組織に属する超一流の技術者や経営者が本気でBlogを書くということも、どうも日本では起こりそうもない。 と悲観している。確かにその印象はある。日本の大企業に属する超一流の誰かが実名でBlogを書くという状況は
ひたすら実装に関するドキュメントをしこしこ書いている人がいるが、好きで書いているわけではなく、書かされているのかもしれないけれど、そーゆー無駄なドキュメントは書くな。時間の無駄である。実装は日々変化する。それに追従する形でドキュメントが更新されるということはない。断言する。実装に関するドキュメントと最新の実装は常に食い違っている。いまだかつて同期したことがない。無駄なドキュメントを書く時間があるならコードを洗練しろ。無駄なドキュメントを書く時間があるならコードをドキュメントにしろ。 ソフトウェア工学の教科書にドキュメントの重要性が書いてあるからといって信用してはいけない。ウオーターフォールモデルが商用ソフトウェア開発の現場で役にたたないように、実装に関する詳細ドキュメントは百害あって一利なしである。 コードがドキュメントだ。 http://capsctrl.que.jp/kdmsnr/wi
Webサイトで公開するコラムを書く場合,筆者は極力,何らかの実験をするように心掛けている。読者との議論を基にコラムを書き上げた例,原稿の執筆時間を計測し,それを原稿に書いた例,ある一日に聞いた話をそのまま公開した例,といった具合である。 今回は,同一テーマのコラムを3本ほぼ同時に書き,三つのサイトで公開することを試みたい。三つのサイトとは,IT Pro,製造業やハイテク産業の技術者向けサイトTech-On!,そして日経ビジネスEXPRESSである。 取り上げるテーマとして「何が技術者を殺すのか」を選んだ。技術者のやる気を失わせる諸問題について考えようということである。IT ProではIT関連技術者に向けた内容を書き,Tech-On!ではエレクトロニクス・メカニカルの技術者に向けて,日経ビジネスEXPRESSでは経営者やビジネスパーソン一般に向けて,それぞれ書いてみる。 このテーマは,筆者が
先週、ソフトウェア・エンジニアではない人たちが参加している飲み会でOSの話をする機会があったのだが、自分で説明しながら一つ自分の頭の中ではっきりしてきたことがある。私なりの 「Google OS」の解釈である。今までも、漠然とは理解したつもりでいたのだが、他人に説明することにより、私の頭の中でより明確化して来たので、ここに書いて見ようと思う。 OS(Operating System)とは、一口で言えばコンピューター上にあるファイル・システム、グラフィック・ユーザーインターフェイス・システム、タスク管理システム、などの各種システム・サービスの集合体のことである。ユーザーはユーザー・インターフェイスを介して、プログラマーはAPIを介して、それらのサービスとやり取りをする。 従来型のOSにおいては、そういったシステム・サービスは全て対象となるコンピューターそのものの上で実装されていた。そのため、
E-mail: mmura[AT]mx.biwa.ne.jpまで([AT]は@に変えてください)) Copyright (C) 2000-2005 M.Murakami, All rights reserved
プログラマの生産性が定量的に計れると仮定して。ある機能を実装するとき。 できるプログラマは、平均の半分以下の時間で高品質に実装する。 平均的なプログラマは、平均的な時間と平均的な品質で実装する。 できないプログラマは、平均の倍の時間かけても実装を終えられない。 プロジェクト管理者の管理能力を定量的に計れると仮定して。あるチームを管理するとき。 できる管理者は、チームの団結と士気を向上させ実力以上の結果に導く。 平均的な管理者は、平均的な管理でそれなりの実力並みの結果に導く。 できない管理者は、チームの団結と士気を沈滞させて実力の発揮を阻害する。 システム価格の相場が定量的に計れると仮定して。あるシステムを売るとき。 できる営業は、顧客の信頼を勝ち取り相場の倍額で受注する。 平均的な営業は、あたりさわりのない対応をして相場程度で受注する。 できない営業は、顧客の反感を買い相場の半値でも受注で
前回書いた、Marshal.UnsafeAddrOfPinnedArrayElementはハマりどころで、日本語の.NET Framework SDKの訳文が間違っていることもあって、必ずと言っていいほどハマる。 例えば、C#からOpenGLを扱うのは一筋縄ではいかないことをこの連載で示してきたが、誰かがひとたび礎を築きさえすれば、比較的容易にC# + OpenGL + NeHeなんてことも出来る。 id:Ozy:20060408 id:Ozy:20060409 id:Ozy:20060410 私はいつも『Joel on Software』の一節を思い出す。 つまり、あなたが日常使うことの90%は1週間で学習できるが、残りの10%を知るためには2、3年かかるかもしれないということだ。「やってほしいことがあれば何でも、本を見つけてやり方を覚えるよ」と言う人たちに対して、本当に深い経験を持った
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く