仙石浩明の日記: 文字化けしていなくても MySQL 内の文字コードが正しくない場合がある
MySQL 5 からテーブルごとに文字列のエンコーディングを指定できるようになった (「そんなことは知ってるYO!」という人も多いと思うので、 そういう人は「これからが本題」 の部分まで読み飛ばして欲しい)。 例えばテーブルを作るときに、 mysql> CREATE DATABASE test; Query OK, 1 row affected (0.05 sec) mysql> USE test Database changed mysql> CREATE TABLE user ( name VARCHAR(255) ) CHARSET=utf8; Query OK, 0 rows affected (0.05 sec) などと 「CHARSET=utf8」 を指定すれば、 文字列を UTF-8 エンコーディングで格納する。 「CHARSET」 すなわち 「文字集合」 と、 エンコーディ
仙石浩明の日記: 技術力が高い人こそ、ビジネスモデルの良し悪しにもっと敏感になるべき
先週参加した社外の飲み会 (私は飲めないので専らウーロン茶でしたが) で、 Linux ディストリビューションの開発や、 カーネル技術を売りにしたコンサルティングで有名な某社の カーネル技術者とお会いしました。 彼はいま伸び盛りの若手カーネル・ハッカーなのですが、 オープン・ソース・ソフトウェア (以下 OSS と略記) ビジネスについて熱く語ったり、 ディストリビューションをサポートし続ける使命感に燃えていたのが、 わたし的にはちょっと気になりまして、 ひとこと言いたくなってしまいました(お節介ですね ^^;)。 ディストリビューションのサポート体制 (カーネルのバグにも的確に即応できる体制) を維持し続けることによって、 多くの企業で Linux を安心して使ってもらうことができて、 それが OSS の発展につながるし、 それこそが自分の使命だと彼は考えているようでした。 それはそれで
仙石浩明の日記: 自身の能力をアピールすることは技術者として必須だが、上司にだけアピールするのは最悪！
私自身は、 KLab 社内の技術者たちと、 いつまでも技術者同士の関係でいたいと思っているのですが、 技術者の人数が増えてくると、 仕事上の接点がほとんどない人もでてきます。 そして社員の側からすると、 私は (いちおー ;-) 取締役なので、 おいそれとは話せない恐い人などと根拠無く思い込んでるケースも、 残念ながら皆無というわけではありません。 それではいけないということで、 日頃あまり接点のない人たちを中心に、 無理矢理 (^^;) ランチに誘って話する、ということをしています。 先日も隣の部署の N さんと二人でランチへ行きました。 彼とは入社直後の社員旅行で少し話をしただけで、 その後は話す機会がほとんどなかったのです。 それまで私は知らなかったのですが、 実は彼は高専時代にず抜けた存在で、全校で表彰されたこともあったそうです。 プログラミングが大好きで、いろんなものを作っては、
仙石浩明CTO の日記: 年功主義と実力主義 ～大企業とベンチャー～
私が大学を卒業したのはバブル (ネットバブルではなく、その前の前世紀のほう) がはじけた年でした。 当時は今ほどベンチャーは一般的ではありませんでしたし、 研究職を目指していた学生 (含む私) が就職先として大企業の研究所を選ぶのは、 ごく普通のことだったのではないかと思います。 終身雇用を信じていたわけでもありませんでしたが、 かといって自分自身が転職することになろうとは、 あまり考えてもいなかったような時代です。 今から振り返ってみれば「就職」というよりは「就社」という感覚に 近かったのだと思います。 その後の「失われた十年 (20年?)」の間に、 年功主義の綻びが誰の目にも明らかになってきて、 大企業以外の就職先を選ぶ人も増えてきましたし、 転職も一般的になってきました。 とはいえ、 就職先の選択肢が広がってきているわりには、 それぞれの企業がどんなところか実態を知ること無く、 なん
仙石浩明の日記: 人の上に立とう (2)
日経ソフトウェアの大森敏行氏の記事中の注釈に、 プログラマが「プログラミングに特別な能力が必要であること」を 強調したがるのには理由がある。 現在の日本のソフトウエア業界には 「プログラミングをしない人のほうが立場が上である」というケースが 往々にして見られ， そのせいでプログラムの質が上がらないという構造的な問題があるからだ。」 というくだりがある。 確かに一理あるし、 優秀なプログラマがエキスパートとして尊敬される土壌づくりは、 優れたソフトウェアを開発するために必須の条件であろう。 しかしながら、 「プログラミングをしない人のほうが立場が上」というのは 一面的な見方ではないのか。 プログラマ兼 CTO である私としては一言いいたくなる。;-) 「プログラミングをしない人」⇒「立場が上」 なのではなくて、 「プログラミングをする人」⇒「視野が狭い人が多い」 「視野が狭い」⇒「立場が下」
仙石浩明の日記: 人の上に立とう (1)
人の上に立とう、といっても、威張りちらしたい、というわけではない。 相手より高い視点を持てるよう努力しよう、ということだ。 大局的な判断ができる人がリーダシップをとり、 局所的な判断しかできない人は、その指示に従うことになる。 上司が指示を出し、部下がそれに従う、というわけではない。 もちろん指揮命令系統が決められている場合は、 そこから逸脱するのは難しいかも知れないが、 職種が違う場合はどうだろう？ セールスがお客様の言葉を錦の御旗よろしく振りかざして マーケタへマーケティング戦略を指示し、 マーケタが製品のあるべき姿をプランナへ指示し、 プランナが製品仕様を決めて技術者に指示する。 こうした指示の連鎖は、よく見かける光景だが、 セールス、マーケタ、プランナ、技術者は、 本来は上下関係はないはずである。 なぜこのような指示する側とされる側に分かれてしまうのか。 で、上下関係をひっくり返し
仙石浩明の日記: 好きなことをしよう
向いていることを仕事にしよう。 まさに、好きこそものの上手なれ、 嫌々やってる人と、好きでやっている人とでは、どんどん差がつく。 一生のうちのかなりの時間を仕事に費やすのだから好きなことをすべき。 好きなことやっててメシが食えれば苦労はしない、という人が いるかも知れない。しかし、 かなりニッチな分野でも、トップクラスならば飯の種には困らないもの。 ベンチャーと同じ。 市場規模が小さくても、他社に負けない競争力を持っていれば 商売になる。 市場規模がいくら大きくても、他社の後追いなら 価格競争に巻き込まれてジリ貧になる。 まさに、鶏口となるも牛後となるなかれ。 その一方で、 眠る開発屋blog から引用: ベンチャーって割と志先行になりがちだけども、 どこかでそれと距離を置かないと行き詰まるよね。 多種多様な人間を巻き込む土壌がなければバランス悪くなるもの。 ってか事業を展開させようにも志
仙石浩明の日記: 開発環境とプログラミング能力
開発環境の進化が、 プログラマのプログラミング能力を退化させていると思う。 私は、いわゆる統合開発環境というものを使ったことがなく、 いつでも emacs を愛用している。 しかも画面サイズは 20年来 80桁x24行のままである。 プログラミングは、メモを書きながら設計したあと、一気に書く。 設計さえきちんとできていれば、途中で手が止まることはあまりない。 食事も忘れて何時間も没頭することがよくある。 そして書き終えてたらコンパイル。 タイプミスとか変数宣言し忘れとかで出たコンパイルエラーを ひとつずつ修正。 で、コンパイルに成功したら実行させる。多くの場合、これで動く。 一通り動作確認して、期待しない動作をするところがあっても、 ほとんどの場合ソースを参照するまでもなく原因に思い当たる。 たいていの場合、デバッガを使うまでもなく、 ソースを見直すだけでどう修正すべきかも分かる。 という
仙石浩明の日記: 自分を変えよう
他人の考え方を変えさせるのは難しい。 人は誰しも自分の考えたいように考えるわけで、 正論を述べたって相手を説得できるとは限らない。 たった一人の考え方を変えさせるのさえ困難なのだから、 まして組織の方向性を変えるなんて至難の業。 だから、組織を変えようとするのではなく、 他人を変えようとするのではなく、 まず自分を変えよう。 どんなに非の打ち所が無い人でも 反省すべき点の一つや二つあるわけで、 ふつうの人ならいくらでも反省すべき点はあるだろう。 まして周囲に不満を持っている人なら その分、反省すべき点も多いはず。 まさに人のふり見て我がふり直せ。 自分の都合のよいように、自分の考えたいように、 考えていないか省みよう。 他人の考え方を変えさせるのはそれからでも遅くない。 そもそも考え方を変えて欲しいと思うのは何のため？
仙石浩明の日記: プログラマを目指すのに適した時代、適していない時代
プログラマの道を目指すのに適した時代、適していない時代、 というのがあるように思う。 もちろんプログラマに限らず、あらゆる職種、それぞれについて、 適した時代というのがありそうだ。 最初に断っておくが、 適していない時代だからといって、その職種を目指すな、と言っているわけではない。 ただ単に、適していない時代であることを意識し、 適していないことを覚悟して ;-)、その道を目指すべきだ、という意味である。 現代は、プログラマを目指すのには適していない時代だとつくづく思う。 そんな馬鹿な、インターネットの普及によって、何でも簡単に調べられて、 その気さえあればいくらでも高度な勉強ができて、 いくらでもプログラマとしてのスキルアップができるではないか、 という反論が聞こえてきそうであるが、 もうしばらく黙って私の話を聞いて欲しい。 「自分なりに体系化するセンス」で、長久氏曰く: 「仙石浩明の日
仙石浩明の日記: 組織を強くする技術の伝え方
ふと立ち寄った本屋で、たまたま手にした本: プログラミングでメシが食えるか!? ―成功するプログラマーの技術と仕事術 (単行本) 小俣 光之 (著) を読んでみて驚いた。 私がプログラミングについて漠然と考えていたことを、 とてもよく整理した形で説明している。 ふだん私はこの手のコンピュータ関連「読み物」をほとんど読まないのだが、 書いてあることにいちいち共感してしまって、 そのまま一気に読んでしまった。 プログラミングに関して、ここまで私と考えが似通っている本を 今まで読んだことがなかったので、 著者の小俣さんにメールを送ったところ程無く返信があり、 直接お会いして色々お話することができた。 メールの中で小俣さん曰く、 「本書は批判的なコメントが多い中、共感いただけて本当にうれしいです」。 例えば Amazon のカスタマーレビューには、 内容が古すぎます, 2007/1/29 この本の
仙石浩明の日記: 面接FAQ: 素人にも分かるように説明してください
久しぶりに「面接 FAQ」シリーズの続きを書いてみます (前回書いたのは一年以上前なのでずいぶん間が空いてしまいました)。 私の面接というと最終面接であることが多いのですが、 履歴書の備考欄に「役員との面談希望！」と書いてある場合など、 一次面接から私が面接することもあります。 (最終の) 役員面接というと、 多くの人が通りいっぺんの面接だと思うらしく、 役員面接で技術的な突っ込みを受けて、 応募者が戸惑うケースが多々ありました。 私の面接で、 比較的頻度が高い私の質問パターンを紹介し、 応募者がどう答えることができていたら採用になっていたか、 振り返ってみようというのがこの「面接 FAQ」シリーズの主旨です。 FAQ すなわち、 面接で(私に)よく聞かれること、 面接官自身が語る面接攻略法。 「面接 FAQ」は続き物ですので、 以下のページも参照して頂けると幸いです。 (1) 高い技術力
仙石浩明の日記: 「人を動かす」感情的コミュニケーション能力と 「モノを動かす」論理的コミュニケーション能力
先日書いた日記 「コミュニケーション能力の育成を第一とする教育が格差社会を救う」を とても多くの方に読んで頂けた。 はてなブックマークに頂いたコメントを読むと、 多くの方に賛同して頂けたようで、ありがたいことである。 この日記の冒頭で言及した 「某大学情報系学部が主催した、企業と学生のマッチングイベント」 では、 多くの学生さん、先生方にお会いして名刺を配りまくったので、 そのうちの何割かのかたには、 この日記を読んで頂けたはずであり、 なんらかの反応を期待していた。 私はこの某大学情報学部の学生なのですが、 コミュニケーション能力の育成が最優先だったのかと驚きました。 1年生から研究室配属の事をいってるのですかね。 私からすると、コミュニケーション能力育成が最優先に行われている気はしません。 率直な話、このようなトラックバックを頂けて、 「この某大学情報学部」の教育も捨てたものではない
仙石浩明の日記: なぜ人月見積もりが優れているのか
人月見積りでは生産性が上がらない。 IPA が警告するまでもなく、 ソフトウェア技術者ならば誰しも 人月見積りに嫌悪感を持っているのではないでしょうか。 生産性を上げれば上げるほど金額が低くなってしまうし、 そもそも開発者の生産性なんて人によって大きく異なる (私の持論は、 「ピンとキリでは 1000倍の差がある」、です) のだから、 「標準的な技術者一人が一ヶ月かかる仕事」なんて基準をおいたところで 意味がありません。 人月見積もりについては、 「人月見積もり、生産性について」に いろいろな意見へのリンクがまとめられているので参考になります。 このように人月見積もりがなぜ問題なのか、 それこそ掃いて捨てるほど主張が繰り返されていますから、 いまさら同じようなことを唱えても仕方がありません。 そこで、ここでは逆にあえて肯定してみることにします。 そもそもこれだけ嫌われ者の「人月見積もり」が
仙石浩明の日記: 面接FAQ: 「人の役に立つことをしたい」と言う技術者の卵たち
これまで 「弊社の面接で(私に)よく聞かれること、 面接官自身が語る面接攻略法」を、 「面接 FAQ」シリーズで書いてきたのですが、 タイトルでは内容が分かりにくかったのではないかと反省する今日このごろなので、 今回から より内容を表わすタイトルに変えてみます (2007/7/12追記: 以前のページのタイトルも修正しました)。 内容自体は、「面接 FAQ」シリーズの続き物ですので、 以下のページも参照して頂けると幸いです。 (1) 高い技術力って例えばどんなことですか？ (2) 何か質問はありませんか？ (3) 前職でいくらもらっていましたか？ (4) 仮に、何をしてもいい、と言われたら、何をしますか？ 続く 5 回目となる今回は前回の続きで、 「何をしたいか」と質問したときの、 応募者 (つまり面接を受けに来た人) の答についてです。 一生の時間のうちのかなりの時間を仕事に費やすのです
仙石浩明の日記: Emacsでtrampを使って /su:root@localhost:/ をアクセスする
先日書いた「su & emacsclient」にトラックバックを頂きました (_O_)。曰く: tramp は /su: や /sudo: なパスを扱う場合は内部で su や sudo を使うだけで、 なんでもかんでも ssh を使うわけではないです。 思い切り誤解してました。orz 私の場合、su は opie 使っていて、 senri:/home/sengoku % su otp-md5 416 se2369 ext root's response: などとなるので、 (setq tramp-password-prompt-regexp "^.*\\([pP]assword\\|passphrase.*\\|\n.*response\\):^@? *") と設定することにより、 チャレンジの部分を含めてプロンプトに出すことができて、 無事 tramp & su で root 権限でファ
仙石浩明の日記: キャリアにおける「鶏と卵」 ── 「卵」を後回しにして欲しくない
私は「やりたいことを仕事にすべき」と常日頃から主張しているのですが、 自分自身のことを振返ると、 必ずしも「やりたいこと」そのものズバリを 最初からやっていたわけではないことに気づきます。 「鶏がさきか、卵がさきかの議論になっちゃうんだけど」なんて枕詞があるが、 こと20代のキャリアにおいては 「まず目の前の仕事で最高の成果をだすことが"さき"で、 自分がやりたいと思う仕事をおっかけるのは"あと"」というのは 私の中では確信に近い。 確かに、何をやるにしても最初は素人であるはずで、 ずぶの素人が「この仕事をやりたい」と言ったところで、 任せてもらえることはレアケースでしょう。 仮に任せてもらえたとしても、 初めてやる仕事で成果を出せるとは限りません。 私は学校を卒業後、某大企業の研究所に就職し、 遺伝的アルゴリズムの研究に取組みました。 当時は (今も?) 大企業の研究所というのは人気職種
仙石浩明の日記: 技術者の成長に役立つ会社とは？(2)
技術者の成長に役立つ会社とは？(1) をとても多くの方々に読んで頂けました。 頂いたコメントや、 はてなブックマークに頂いたコメントを見ると、 賛同/批判 両方の立場から様々なご意見がありますね。 拙文が多くの方々の考えるきっかけになったのだとすれば、 書いた甲斐があるというものです。 特に学生さんにとっては、これから自身の人生を切り拓いていくのですから、 いま自分の将来について考えることは、 必ず後の人生にとってプラスになることでしょう。 以下に述べるのは、私が考える「技術者の成長に役立つ会社」の条件です。 他の人は異なった考えを持つかもしれませんし、 私自身も常に考え続けているので、 「役立つ会社」の条件が変ってくることがあるかも知れません。 しかし、 「技術者の成長にとって一番役に立つ会社を目指したい」というその思い自体は、 私が技術の責任者であり続ける限り、変らず持ち続けたいと思っ
仙石浩明の日記: チープ教育: 「無意味にポジティブ」のススメ
KLab 社内には、社内専用の IRC サーバがあります。 IRC (Internet Relay Chat) つまり、 ネットワークリアルタイム会議システムです。 普通の IRC はインターネットに接続できれば、 誰でも使えるのですが、 KLab 社内 IRC は、KLab のイントラネットに接続できる人しか使えません (VPNワープを使って社外からもアクセスできます)。 だから社外秘な内容も流せますし、 社内ミーティングを IRC で済ませてしまうこともよくあります。 社内 IRC が真価を発揮するのは、 コンテンツ提供用の WWW サーバ システム (DSAS) の メンテナンス作業の時など、 多くの人がリアルタイムに状況 (メンテナンス作業の進捗状況) を 共有したいときです。 メンテナンス作業は、 コンテンツ提供サービスに悪影響を与えていないか確認しつつ 慎重に進める必要があるの
仙石浩明の日記 「ソフトウェア開発」は「モノ作り」ではない
いつのころからか、 ソフトウェア開発がモノ作りに喩えられるようになった。 典型的なのは、製造業(例えば自動車製造)と IT 業界とを比較して、 前者が高度にシステム化されているのに対し、 後者がまるで家内制手工業のようだ、という批判である。 日経ビジネス online の記事に次のようなくだりがあった: 「というより、何といいますか、経営トップからすると、 ITはとにかく非常識な世界だ、としか思えないのではないかなあ。 例えば大きなシステム開発プロジェクトに取り組むと、 すぐ100億円を投資する、という話になってしまう。 100億円の経常利益を出そうと思ったら本当に大変。 ところが、100億円を投じたのに、期限までに完成しない、 出来上がってきたものが当初計画と違う、 直そうとするとさらに金がかかる。 こんなことが起きるわけですから、『一体なぜなんだ』と経営トップは思うわけです」 IT業界
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
