タグ

workとprogrammingに関するTomohiroのブックマーク (14)

  • YAMDAS現更新履歴 - Joel Spolsky選定のマネージメントトレーニング用課題読書リストの邦訳版を作ってみた

    Joel on Software の翻訳 Wiki の話は以前にも書いたが、その中に Joel Spolsky の会社である Fog Creek Software におけるマネジメントトレーニングプログラム用の課題読書リストが公開されている。二週間に一冊読んでいっても二年間かかるという長大なリストである。 ちょうど Tech 総研で「この春に読みたい!TOPエンジニア推薦のIT技術書20冊」という記事が公開されているのを見て、件の読書リストで邦訳が出ているものだけ並べてもそれなりのリストになるのではないか、それにサポートページなどの情報を加えれば他の人の参考になるかと思ったのである。実際やってみると、邦訳だけでも50冊を超えるリストになり、正直死んだ(笑) 見やすいように著者や内容で大雑把に分類させてもらった(不適当な分類があったらすいません)。正直言って、このが入るか? というようなも

    YAMDAS現更新履歴 - Joel Spolsky選定のマネージメントトレーニング用課題読書リストの邦訳版を作ってみた
  • 37signals Jason Fried氏の講演 「より少ないシンプルな機能で競争する」:Goodpic

    This shop will be powered by Are you the store owner? Log in here

  • 小野和俊のブログ:プログラマー風林火山

    アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニア仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ

    小野和俊のブログ:プログラマー風林火山
  • パラサイト・プログラミング steps to phantasien t(2007-04-16)

    2007-04-16 近況 最近の私はもっぱらサンプルからのコピペが仕事. コピペといっても Ctrl+C, Ctrl+V より少しだけインテリジェントだけれど, ライブラリが強力な上に文書の出来が良いから, 多くはサンプルの改変で済んでしまう. 面白くはないが生産性は高い. コピペ・ハイウェイの渋滞にぶつかり, サンプルのないパターンに出会うこともある. そういう時は自分でコードを書く. でもだいたい動かない. Getting Started や入門書はざっと読んである. それでもわからない. 文書化されていない不具合や common pitfall だったりする. (間抜けな間違いもあるけれど...) こんなとき Google はあまり役にたたない. 使っているライブラリやフレームワークがよほどメジャーでない限り, 解決方法はなかなかみつらない. せいぜい自分と同じところで悩んでいる人

  • Blog - Mikula Beutl - SEO Consulting

    This guide is the safest way to do a domain switch, you get all you need to change a blocked domain. What is a user flow and a user journey? There’s a macro view of a customer experience that we can analyze and partially control.

    Blog - Mikula Beutl - SEO Consulting
  • 小野和俊のブログ:そして、ペア・プログラミングが始まる

    ここ数日、私はずっとペアプログラミングをしている。 ペアプログラミング自体は、これまでに何度も経験したことがある。 しかし今回の試みが今までと違うのは、 一日中、ペアプログラミングしかしないという点である。 1セット1時間半、15分の休憩を入れて、 ドライバーとナビゲーターを交互に入れ替えて毎日4セットやる。 このところ、これを何日も続けている。 こうやって、ある程度ストイックに続けてみることで、 わかってきたことがある。 それは、ペアプログラミングにはメガトン級の破壊力があるということだ。 プログラマーは絶えず誘惑にさらされている。 調べ物でウェブを見たついでに何時間もネットサーフィンしてしまったり、 考えたことをメモするついでに2時間かけてブログを書いてしまったり、 仕事の用事で知人に IM したついでにしばらくだべってしまったり、 Twitter に書き込んだついでに Friends

    小野和俊のブログ:そして、ペア・プログラミングが始まる
  • 長文日記

  • 頭の中にプログラムを入れる

    Paul Graham / 青木靖 訳 2007年8月 いいプログラマは、自分のコードに集中しているとき、それを頭の中に保持しておくことができる。数学者が取り組んでいる問題を頭の中に入れているのといっしょだ。数学者は学校で子供たちが習っているように、紙の上で問題の解いているわけではない。彼らは多くの部分を頭の中でやっているのだ。問題の領域をよく把握しようと努めることで、普通の人が記憶にある育った家の中を歩き回れるように、数学者は頭の中で問題空間を歩き回ることができる。最高の状態で行われるプログラミングもそうだ。プログラムの全体を頭の中に入れたなら、それを思い通りに操れるようになる。 これはプロジェクトのはじめにおいては特に価値がある。それはプログラムを作り始めるときに最も重要なことが、やっていることを変えられるということだからだ。単に問題の解き方を変えるという ことではなく、解いている問題

  • 「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ

    昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保

    「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
  • IT業界に来た新社会人に本音を言っておく - ブログは死なず、ただ放置されるのみ。

    今年もIT業界にたくさんの新社会人がやってきたと思います。 そんなみなさんに、一番最初に音を言っておこうと思います。思いついたことを無責任にぐりぐりと。 全文はこちら

    IT業界に来た新社会人に本音を言っておく - ブログは死なず、ただ放置されるのみ。
  • 新人におくる、怠惰な社会人になるための7の方法 : ロケスタ社長日記

    はじめに なんだか会社のほうに新人さんが何人も入ってきて、いろいろ教育したりすることが多くなりました。 で、僕はいつも「怠惰な社会人を目指そう~」といっています。 新人さんは努力や気合いがありすぎて、無駄が多かったりするのですね。また上司もそういうのを好んだりするので、なおさらがんばっちゃいます。 というわけで、いかに怠惰に過ごすかを意識的に考えたほうが、ほどよかったりするのではないかと思っています。 以下、まとめ 1:やたらと努力でカバーしない 新人は割と「がんばります!」という宣言をして無駄な仕事までがんばってしまったりします。 その姿勢はそれはそれですばらしいのですが、努力に頼るとつらくなったときに一気にダメになるので、できるだけ努力をしないですむようにしましょう。 たとえば単純作業などをすごくがんばる人がいるのですが、結構無駄が多い。たとえば100箇所の誤字があるテキストを、いちい

    新人におくる、怠惰な社会人になるための7の方法 : ロケスタ社長日記
  • SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ

    10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変

    SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ
  • まさかの日記:MSの某氏との会話ログ

    コンピュータサイエンス系の人たちの間では、サーチのテクノロジーで人気があるのはリリバンシー、次はバーティカルサーチ。 他の要素としては、クローリングとインデキシング、クラウド系というところらしい。 サーバをグリッド化(やや死語だな)して、、みたいなのは、コンピュータサイエンスというよりはエンジニアリング。 昔、シックスアパートの某Perlギークの人と話をしたとき、「自分はエンジニアリング系じゃないんで、、」と言っていた。そのときはエンジニアリングという言葉の定義がよくわからなかったけど、なんとなくわかってきたかも。 あ、全文検索とかマイニングとかも面白いといっていた。まあこれは要素技術だけど。Luceneを作った人が別で作ってる奴が結構良いって。なんだろ。SolrかHadoopか。 あと、エンタープライズサーチ。例えばメール。誰がどんな単語を多用しているかをサマリーしたり、検索させたり。

    まさかの日記:MSの某氏との会話ログ
  • プログラミングは人生だ――まつもとゆきひろ ― @IT

    私がプログラミングを始めたのは中学校3年生のときでした。父が買ってきたシャープのポケットコンピュータ(PC-1210)でBASICを使うようになったのです。わずか400ステップしか入力できない小さなコンピュータでしたが、それでも自分の命令したとおりに動作するポケコンを見ていると、自分にはなんでもできるようなそんな「万能感」を感じさせてくれました。 それから四半世紀以上たちましたが、私がプログラミングから感じる「わくわく」は少しも減ることはありません。むしろ、どんどん増えているように感じます。長いプログラム経験を踏まえて、いま、感じるのは、 プログラミングは人生だ ということです。プログラムには人生のあらゆる側面が詰め込まれています。文字どおり、人生そのものといってもいい過ぎではないでしょう。……うーん、やっぱり、いい過ぎかな。 プログラミングはスポーツだ 皆さんの多くは若いときにスポーツに

  • 1