「子どもが体験するべき50の危険なこと」のタイトルだけ元ネタ。 http://www.oreilly.co.jp/books/9784873114989/ プログラマ一般ではなくソフトウェア開発業界寄りになってます。 「危険な体験談」「あるある」で終わらずに、そこからもう少し考えるきっかけに出来るんじゃないかと思ってます。 「プログラマが体験するべき50の危険なこと」と「きのこ本」 続きを読む
「プログラマが体験するべき50の危険なこと」
「子どもが体験するべき50の危険なこと」のタイトルだけ元ネタ。 http://www.oreilly.co.jp/books/9784873114989/ プログラマ一般ではなくソフトウェア開発業界寄りになってます。 「危険な体験談」「あるある」で終わらずに、そこからもう少し考えるきっかけに出来るんじゃないかと思ってます。 「プログラマが体験するべき50の危険なこと」と「きのこ本」 続きを読む
ギークがデザインしないのはなぜか - 恐縮です
皆様にあられましては、日々健やかでいらっしゃいますでしょうか、ハヤシです。 さて、いわゆるウェブデザインというものを皆様はご存じでいらっしゃるかと思いますが、ウェブ制作界隈を見渡してみるとこれへ苦手意識を抱いているプログラマは少なくないものと見受けられます。 これはなぜでしょうか、世の中でギークと言われるような方たちにおいては、より顕著です。情報工学に傾倒しきっているせい？僕はそうではないと思います。 なぜならば、視覚的な美しさと数学的な美しさは同じ視点で評価出来るためです。黄金比に代表されるよう、数理の美的感覚はそのまま視覚に反映出来るのです。 なぜなのでしょう。 数学的知識が豊富で知性に富んだギークが、なぜウェブデザイン、つまり視覚的な装飾についてこだわりを見せないのでしょうか。僕が至った一つの結論は”練習不足”です。 では、これにどう取り組めば良いのでしょうか。デザイナー、特にウェブ
「ひとりぼっちのプログラマ」に読んで欲しい、『 プログラマが知るべき97のこと』 - ただのにっき(2011-01-08)
■ 「ひとりぼっちのプログラマ」に読んで欲しい、『 プログラマが知るべき97のこと』 オライリーの高さんから献本いただいた。いつもありがとうございます。 この本はねぇ、「ひとりぼっちのプログラマ」にぜひ読んで欲しいなぁ。 ここでいう「ひとりぼっち」にはふたつの意味があって、ひとつは「ひとりでがんばっているプログラマ」。 Twitterやブログを読んでいると、仕事でいろんなことにチャレンジしたり、業務を改善したりしたいと思っているのに、職場の文化が壁になったり、上司の理解が得られなくて歯がゆい思いをしている若いプログラマの叫びが、それはもう、かなり頻繁に聞こえてくる。10年前ならいざしらず、今ならさっさと転職してしまうのが正しい道だろうけど、そうもいかない事情を抱えている、でも現状をなんとかしたい……そう感じているひとりぼっちのプログラマにとって、本書はいい味方になってくれると思う。というか
高木浩光＠自宅の日記 - 岡崎市に求められているものは何か 岡崎図書館事件(12)
■ 岡崎市に求められているものは何か 岡崎図書館事件(12) 9月の20日の週、遅れた夏休みをとって帰省した私は、東海環状道をひとっ走りして、岡崎市立中央図書館を訪問した。そこのカフェで中川氏と面会するためだった。中川さんからは、じっくり事件の詳細*1をうかがったのだが、せっかく図書館にいるのだからということで、その場の思い付きで、三浦主任に会ってみますかという話になり、カウンターに伝言を残したところ、三浦主任はカフェまでお越しくださり、夜遅くまで3人でお話をした。 実は、中川さんは、釈放されるときに、真っ先に図書館へ謝りに行く*2つもりだったのだそうだ。ところが、釈放の間際に、O警部補から「図書館には行かなくていいから」「俺が代わりに伝えておいてやるから」「図書館には言っておくから」と、止められたのだという（「Librahackメモ」の6/14「不起訴で釈放された」に詳細な記述がある）。
プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお
コード否定≠人格否定
よく（？）勘違いされるんですが、 「このプログラムのこの部分の書き方ないわー」 と言われた人は 自分自身が全て否定されていると受け取る人が多いような気がします。 もちろんプライドをもったプログラマーであれば、 自分の書いたコードが否定されることは気持ちのいい事ではないと思います。 あと、コードの問題点を指摘する側の人がもう少し配慮した言い方をすればいいのになと思う節がない訳ではありません。 しかし、私がいつも思っている（思うようにしている）事は、 「指摘されるうちが華」という事です。 指摘されるという事は何かしらの事情はあれ、 自分の書いたコードに興味を持って見てくれる人が居る。 もしくは一緒に仕事をして居る間柄だとすると、問題点を指摘してくれたり、 もっといい書き方あるよという自分の足りない部分を補ってくれるているのです。 なんとありがたい事ではないですか。 こんなありがたい事を無償で
「無料モデルに興味はない」「プログラマは創造的だ」～セオドア・グレイ氏インタビュー
2002年のイグ・ノーベル賞に輝いた経歴を持つセオドア・グレイ（Theodore Gray）氏は、iPadアプリ「元素図鑑」の作者であり、爆発などの危険を伴う科学実験を紹介した異色の書籍「Mad Science −炎と煙と轟音の科学実験54」の著者だ。その一方で、世界の研究機関が活用する技術計算ソフト「Mathematica」の開発元であるWolfram Research社の重役、という硬派な顔も持つ。 「クレイジーな科学オタク」？ それとも「理性的なビジネスマン」？ その素顔は、「職人的表現者」だった！ 金属ナトリウムと塩素ガスでポップコーン調理 セオドア・グレイ氏（以下、グレイ）グレイ氏（以下、グレイ） 「Mad Science −炎と煙と轟音の科学実験54」は、「Popular Science」という雑誌で毎月、5年間担当していた連載をベースとした書籍です。1つのネタごとにプロの広告
プログラマが直面する２つの「世界」 - elm200 の日記(旧はてなダイアリー)
プログラマというのはとてつもなく難しい仕事だ。 職業的なプログラムは、それが会社であれ、個人であれ、顧客の何らかのニーズを満たすために存在している。プログラマは、顧客の要求を満たすように、プログラムを設計・実装する。ここで注意しなければならないのは、「顧客の要求」と「プログラムの設計・実装」という全く異質な 2つの仕事を同時にこなさなければならないということだ。 顧客の要求は、社会というシステムに属し、プログラムは、技術というシステムに属する。この2つは全く似ていないし、何の関係もない。それが、「顧客要求を表現したプログラム」という一つの場で切り結ぶ。異質な2要素がぶつかり合い、プログラムコードはまさに戦場と化す。 書かなければならないプログラムの種類によって、この緊張度は異なってくる。たとえば、組み込みソフトウェアや科学技術計算などの場合は、要求自体がかなり技術的であるから、プログラムと
ギークたちの耐えがたい部分最適性 - elm200 の日記(旧はてなダイアリー)
東京でフリーランスのウェブプログラマをしていたころ、技術勉強会によく参加した。こういう勉強会に参加する人たちは、意欲も技術力も高い人たちが多かった。技術者としては、幸せな時間を過ごすことができた。 だが、疑問もあった。参加者たちの多くは、職業プログラマであったのだが、カネの話をしない。技術が最終的にどのようにビジネスに役立ち、利益を増進し、社会に寄与するのか、ということに興味をもっている人はほとんどいなかった。彼らの多くは、ただ純粋に新しく登場した技術をオモチャのように慈しんでいた。 シンガポールで Barcamp に参加したときの風景はかなり違っていた。技術的なセッションもあったが、マイクロファイナンスなど IT をいかに社会の進歩に結びつけるかについての真剣なセッションも多かった。 日本の優秀な技術者たちにとって、IT はある種のオタク的消費対象であり、その社会的応用については、自分た
ITドカタを笑ってすましてちゃだめだろ - 紅茶屋くいっぱのあれこれ日記
情報関係のエンジニアがシステム土方の話を聞いて、鼻で笑って読みながしてしまうのはあまり健全ではないとおもいます。紅茶屋からみてもわらいごっちゃない。 彼らにはスキルが無いんだ。 彼らには新しい技術を学ぶ学習意欲がないんだ。 彼らはバカだからそうやっているのだ。 そのように結果からだけ断じ評価してしまうのは簡単ですが、本当にそれでいいのでしょうか？ 本当に他人事でいいの？ 元ねた 派遣PG時代の思い出 http://togetter.com/li/41782 情報を共有しないシステムエンジニア 情報通信産業の従事者数は建設や小売、飲食と並ぶほどの人数が従事しています。また、産業規模としては自動車産業を抜いて日本で一番の産業です。統計上は日本の産業はすでに情報通信産業が基盤になっています。今年の情報通信白書によれば、雇用誘発数は319万人、波及効果をみれば755万人にものぼります。 エンジニア
エンジニアの生きる道は開発の現場だけじゃない - GoTheDistance
今まで1ミリも考えたことが無いのですが、せっかく定番のネタ｢エンジニア35歳定年説｣で色々エントリを拝見できたので、自分の｢モヤっと｣を整理しておきたいと思います。 発端となったyusukeさんの新プログラマ35歳定年説、あるいは2010年問題 (arclamp.jp アークランプ)は拡散的なので難しい所なのですが、言わんとしていることの1つに｢プログラミングだけを武器に35歳以降を戦っていくのはすごく大変だし、それができるのは一握り｣ってことがあると思います。僕もそう思います。 僕はプログラマとしての自分は凡庸よりちょっとマシぐらいだと思っているので、正直な所｢35になろうが40になろうがコードで力の差を見せ付けるぜ｣という気持ちがありません。常に前を走れる自信がありませんし、僕には必要無い。 ｢いやーこの案件は○○さんの腕が無いと決して出来なかったよ！｣って感じで純粋な技術力をもって自
スーツとギークのエコな関係を斬る - GoTheDistance
久しぶりにスーツとギークのお話。一説にはスーツ女子とめがねっ娘ギークの萌え論争だと言われています、ええ。 ｢要件決めて話をつけるのは誰でも出来る仕事であって、それをプログラムに落としこむのが大変｣ということがわかっていない、というトピックをあるブログのエントリで見つけました。もっと言ってしまえば、｢何かトラブルが起きた時にお前らは何の役にも立たない。技術者がいなかったらスーツは何が出来るんだ｣という話に発展する。お気持ちわかります。 ここで言わんとしていることは、｢技術がわからないスーツはいつも｢このボタンを押すと注文明細が出る｣レベルの要件しかもってこない。そんなもん誰でも出来る。そこからプログラムに落とし込む所が大変。｣だという話だと思います。確かに｢このボタンを押すと(いくつかのルールを元にDBを更新して)帳票(フォーマットやレイアウトは？)が出力されてグラフ(レイアウト・縦軸と横軸
スモールビジネスを興すのに本当に必要なこと - GoTheDistance
スモールビジネスにトライしている僕がやってきました。 利益率の高い商売 在庫を持たない商売 定期的に一定額の収入が入ってくる商売 資本ゼロあるいは小資本で始められる商売 競合商品に比べ低価格 商品の再生産が容易（労働集約型でない） 協力（購入や顧客の紹介）してくれる仲間やメンターがいる 貪欲な学習意欲 顧客、従業員、商材、社会とのトラブルリスクが少ない商売 スモールビジネスを興して成功するための9条件 - 人と組織と、fukui's blog 書かれていることは正におっしゃるとおりだと思うのですが、殆どの場合こういうのはビジネスモデルに対する結果論なので部分的にしか参考にならない。この条件をほとんど兼ね揃えていたけど、｢その条件を売上に転化できなくて｣くたばる会社っていっぱいいる・・・。この条件を否定するのではなくて、モデルは良くてもコケるビジネスがいっぱいあるのはなぜか、ってことを考えた
Mitaka.rb meets Twitterに参加してきた + α
Mitaka.rb meets Twitterに参加してきた。以前参加したのがMitaka.rbの初回で今回が一周年記念ということでもう1年たったのかという感じ。はやいものだ。 実は元々参加する予定はなかったのだけれど、ちょっと前に榊さん達と飲む機会にあってその時に「@fshin2000さん呼ぶんだけど話何聞きたい?」と聞かれ、好き勝手要望を出してたらいつのまにか参加する流れになっていたのでATNDの参加ボタンを押すことにした。にもかかわらず、今日は肝心のfshinさんの発表が終わる頃に到着したわけだけど。 なにはともあれ、今日はおいしい食事と楽しく色々な方と話が出来てよかった。主催の榊さん、スタッフ、発表された方々、それと会場提供のCafe Hi Famigliaさん、どうもありがとうございました。 ちょっと話が変わって少し暗い話。大して内容のある話でもないので適当に読み流してください。
どうしてプログラマがPMになりたくないのか - GoTheDistance
SIerでプログラマ(PG)からプロマネ(PM)までやった僕が通ります。 ＰＭになりたくない症候群 - ベテランIT営業が教える「正しいITの使い方、営業の使い方」 - ZDNet Japan 一度でも失点をしたらそこからリカバリーすることが困難な立場に放り込まれるし、放り込まれたら現場の裁量で何とかするしかないというデフェンシブなやり方に起因する構造的なPM疲弊体質。確かにコレは、嫌悪される理由の１つにあると思います。ただ、それだけではないな、と。技能という側面で考えても嫌悪される理由があるのかな、と思いました。 要はPG→SE→PMというキャリアパス、についてですね。 色々な議論がありますが、何が問題かと言えばプログラマとして未来を奪い去ってしまう所が過多あるってことに尽きるように思います。技術は移り変わるわけですから、プログラマでありたいなら保有スキルが陳腐化しないようにしなくてはな
メモcache: gitを知らないデザイナとgitで共同作業するには？
2009/12/14 gitを知らないデザイナとgitで共同作業するには？ デザイナとgitで共同作業するまでの過程をログに残しておきます。 第一段階 会社で使っているフレームワークの Vの部分(いわゆるテンプレートまわりとか)はデザイナもさわるので、 .gitignore で無視することにして、 フレームワークのMVCのVの部分を除いてプログラマしかさわらない部分だけの リポジトリを作ってgitでバージョン管理することにした。 第二段階 ところが、Vの部分はデザイナしか関わらないわけではありません。 当然のごとく、プログラマ側から 「できればVの部分もgitでバージョン管理したい」 との要望がでてきました。 第三段階 そこで、デザイナに「バージョン管理は何を使っていますか？」 と聞いてみたところ「Mac の Time Capsule です。」 と言われ若干放心状態に…。 確かにバージョン
はよプログラマとかエンジニアとかから脱却せんかい。 - レベルエンター山本大のブログ
プログラマの誇りがどうこうと書いていていうのもなんだけど、 プログラマが下手に誇りを持ちはじめた昨今。 いい加減、うんざりしてきた。職業ぷろぐらまな面々に。 作る技術がスキルのすべてだと勘違いしてるぷろぐらまに。 誰をターゲットに吠えるわけではないけれど、 我慢してることを言います。 仕事＝きれいなコーディング 仕事＝疎な設計 仕事＝きれいなドキュメント とか、そんなことで満足してんなって。 作る技術をバックボーンにして、 話をまとめる力をつけて、 要件をまとめる力をつけて、 交渉をまとめる力をつけて、 費用抑える力つけて、 お客さんの要件を引き出して、実現して、貢献して、 初めて仕事が成り立ってるんだろうが、 ビジネスが成り立つんだろうが。 目指さんかい、営業からテストまで1人で全部実現できるぐらいの境地を。 一周して来いって。 それができるまではずっとワーカー。 #追記 ワーカーは煽り
プログラマの東京集中は止まらない - 田舎Ruby親方
この流れは止まらないんだろうな。ふと思う。 別にプログラマだけの話じゃないんだけど、某Hな人の転職を見て思った。 いや、以前から思ってはいたのだが、また思わされたと言うべきだな。 tlucからはじまり、この手のOSSのコミュニティで知り合いになった人で 東京に移り住んでしまった人はチラホラいる。 そもそも地方出身で東京に就職する人が多数だし。 地方でプログラマというのは至難の業なんだろうなとここ最近は思う。 そしてまたそう思った。 地方でプログラマが幸せにプログラムを書き続ける方法はないものだろうか。 いや、それが自分の夢のはず。地方に住むのにこだわりを持っている。 Rubyの忘年会2009の二次会で向かいに座ったJ氏が本当は地方に住みたいと言った。 東京で子育てをする気にならないと。 本当はみんな地方に住みたいんだろうか。 私は地方に住みたくて、どうやったら地方に住みながら 好きなプログ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
not found
ＣＨＡＮＧＥ ＭＡＫＥＲＳ 変革者たち「カリスマプログラマー」: 週間番組表 : 番組情報 : テレビ東京