タグ

ブックマーク / higayasuo.hatenablog.com (14)

  • おい、kawango、本当の受験勉強をおしえてやる - ひがやすを技術ブログ

    タイトルは釣りです。 ただ、kawangoさんが、だめな受験勉強をしている人を例にあげて、だから受験勉強はだめなんだと結論付けているので、当の受験勉強とはどんなものか説明しましょう。当っていっても、自分の経験と周りを観察した範囲のことですが。 個人でやらないとお金が足らなくなるからといって、個人でやれば成功するという理由にはならない。けれども成功する道は必ずあるはずだからとドラマの熱血主人公のように思い込んだとき、それは個人でやるという道の中に隠されているはずだという結論がでてしまうんだと思う。 でも、それって、解答が必ずある試験問題の解き方なんだよね。 受験では、「正解を出すことが重要だ」という思考パターンで動いていると思われているようですが、実際は「正解を出すよりも点数を取ることのほうが重要」です。説明不足で答えだけあってる答案よりも、最後の結論は間違っていても、答えを導き出す仮定

    おい、kawango、本当の受験勉強をおしえてやる - ひがやすを技術ブログ
    t-murachi
    t-murachi 2009/07/06
    うはwwwwこれはいい反証wwwwww / まぁ最後のはそうは思わんけどね。上には上がいることは当然分かっていながらも、結果および現状に十分 (うまくやれたと) 満足しちゃう人がほとんどだと思う。
  • 梅田望夫にオープンソースを語るなとガツンと申し上げたい - ひがやすを技術ブログ

    例えば、インターネットが社会にもたらしたインパクトのひとつに「オープンソース」という考え方があります。これは元々ソフトウエア開発に端を発した概念なのですが、いまやそれにとどまらず、世の中をより良い方向に導くと思われるテーマがネット上で公開されると、そこに無数の知的資源が集結して課題を次々に克服していくといった可能性を含む、より広い応用範囲での思考や行動原理を意味しています。サブカルチャー領域への応用は少しずつ進んでいるのですが、全体として、こうした動きがいまだに日では根付いていません。政治とか社会変化がテーマとなると特に、陰湿な誹謗・中傷など「揚げ足取り」のような側面の方が前に出てきていて、ウェブのポジティブな可能性──何か知的資産が生まれそうな萌芽がネット上に公開されると、そうしたことに強い情熱を持った「志向性の共同体」が自然発生して、そこに「集合知(ウィズダム・オブ・クラウズ)」が働

    梅田望夫にオープンソースを語るなとガツンと申し上げたい - ひがやすを技術ブログ
    t-murachi
    t-murachi 2009/06/18
    敵はそいつじゃないと思うんだがな…。
  • いっちゃ悪いけどGAEでJavaを選択する場合の最大の理由をわかっちゃいないね - ひがやすを技術ブログ

    いっちゃ悪いけど、 GAE で Java を選択する場合の最大の理由をちゃんと解ってて話をしているとは思えない。 タイトルの通りだけど、Javaはすでに十うん年を一線で過ごしてきた言語だ、過去のコード資産が莫大にあるはずで、それを活用する場合は GAE で Java を選択する事のメリットがある。 「うん十万行の既存コードをそのまま投入できる。それにインターフェースするために多少オーバーヘッド気味のコードが数100行必要なのが何の問題がある?」これを言えないJava 使いはコード資産って物が無い貧乏人だし、過去資産に物を言わせないJavaなど相手にするのがあほくさいぐらい貧弱なものだ。 そのままの言葉で返すけど、いっちゃ悪いけどGAEでJavaを選択する場合の最大の理由をわかっちゃいないね。Javaの豊富な標準ライブラリを使えるというのは、大きな利点だと思うけど、過去に自分たちで作ったよう

    いっちゃ悪いけどGAEでJavaを選択する場合の最大の理由をわかっちゃいないね - ひがやすを技術ブログ
    t-murachi
    t-murachi 2009/06/13
    つか、Java に限らずどの言語、どのシチュエーションであっても、「過去の資産」とやらが役に立つケースはヒジョーに限定的だと思う。ていうか多くの場合、書き直したくて悶絶する。w
  • ぼくがLLのひとに「ガツン」と申し上げたこと - ひがやすを技術ブログ

    ぼくは水曜日にTokyo Cloud Developerの集まりに出た。 そこで、LLのひとから、「Google App Engineは、Python版以外にJava版も出たけど、サンプル見たけど、たくさんコード書かなければいけなくて、正直どこがいいのか教えて欲しい」という質問があった。 blogに名前を出していいかの了解を得ることを忘れたので、ここには、LLの人としか書けない。 ぼくは、そこで一言申し上げた。あるいはそれは、「申し上げた」というような生やさしいものではないかも知れない。端的な言い方をすれば、ガツンと言ってやった。 客観的に見て、ぼくはガツンと言ってやったと思う。LLな方々を前に、「いまどきのフレームワークは進化しているから、言語による差なんて余りない。仮に、Javaのほうが二倍コードを書く必要があったとしても、開発の中でコードを書いている時間より考えている時間のほうが圧倒

    ぼくがLLのひとに「ガツン」と申し上げたこと - ひがやすを技術ブログ
    t-murachi
    t-murachi 2009/06/13
    LLにはLLの、静的型付言語には静的型付言語の「気持ちよさ」が、コーディングする人にはある。ちょこっと書いてさくっと動かせるのも気持ちいいし、いろんなチェックをコンパイラ任せにできるのも気持ちいい。
  • 2009年SI企業の不況の乗り切り方 - ひがやすを技術ブログ

    不況の嵐が吹き荒れていますが、SI業界の中の人はどうお感じでしょうか。たぶん、仕事が減ってきている気はするけど、製造業ほどひどくないと思っているのではないでしょうか。 ただこれは、不況の波が押し寄せてくるのが、遅いだけです。 SI業界では、プロジェクトが一年くらいかかることも多いので、まだ不況じゃないときに受注した案件分でそれなりにっていけるのです。しかし、SI業界の主なお客様である製造・金融業界は、案件を凍結したりなど、新規の受注案件はかなり減ってきているので、今やってる仕事が一息ついたら、やることがなくなってくるでしょう。 仕事が減ってまずすることは、人減らしですね。元請なら、下請けをきることが最初に検討されるでしょう。ある程度はこれで調整できますが、直ぐに限界が来ます。今の元請は、下請けに任せていたようないわゆる下流工程を自分たちでは行えないので、単純に下請けをきるだけではすまない

    2009年SI企業の不況の乗り切り方 - ひがやすを技術ブログ
    t-murachi
    t-murachi 2009/01/11
    零細下請けは地獄を見るな… / 日本電産の例は「大前提」であるべきで、そもそも上流工程だけで商売しようってのが当面は通用する訳がないのだから、別業種への舵切りこそが急務だ。技術評価に基づく正当な淘汰を…。
  • 「ずば抜けているコンプレックス」を克服する方法 - ひがやすを技術ブログ

    404 Blog Not Found:それって勉強じゃないよ http://d.hatena.ne.jp/pollyanna/20081224/p1 なんかかみ合ってなくて残念だけど、弾さんは「天才コンプレックス」、pollyannaさんは「秀才コンプレックス」を持っているんじゃないかと思う。嫉妬の意味でのコンプレックスではなくて、「できる人」の悩みのほう。他人と自分のギャップに戸惑っている。 弾さんの「天才コンプレックス」については、この辺を見ると良くわかる。 私にとって、天才とは天災以外の何者でもなかった。かといって、「能ある鷹は爪を隠す」(これまた耳に胼胝が出来るほど言われた)というほど器用にもなれなかった。 pollyannaさんの「秀才コンプレックス」はこの辺。 それ以来、私には「頭のいい子」という称号がついて回った。 賞賛の意味でそう呼ばれることが多かったが、「変わってる」「す

    「ずば抜けているコンプレックス」を克服する方法 - ひがやすを技術ブログ
    t-murachi
    t-murachi 2008/12/25
    大学のプログラミング演習で、できない人にいろいろと教えていた経験あり。教えているうちにそもそも理解する気がないことを察してしまうと、相手もそれを察したことを察してしまって、微妙な空気が漂った。
  • NTTデータとの決闘シリーズ第二幕 - ひがやすを技術ブログ

    昨日は、NTTデータとの決闘シリーズ第二幕。戦闘服には、かりゆしウェアを選びました。 今回は、データの顧客であるユーザ企業からも参加していただきました。この人はKさんと呼ぶことにします。Kさんは、現在Seasar2(SAStruts, S2JDBC)を使って、プログラミングファースト開発を実践されている先進的なユーザです。BtoCのサイトを作っていると考えてください。 プログラミングファースト開発の詳細はこちら。 http://d.hatena.ne.jp/higayasuo/20080501/1209636051 http://d.hatena.ne.jp/higayasuo/20080721/1216607451 最初のテーマは「品質」。データとしては、 テストコードのカバレッジやバグ密度などで品質を確保しようとしている。 でも、品質に問題があるプロジェクトも残念ながら存在する。 品質

    NTTデータとの決闘シリーズ第二幕 - ひがやすを技術ブログ
    t-murachi
    t-murachi 2008/08/29
    要件定義 (特にユースケース) を設計だと思っているのか、それともユーザーに任せればいいと思っているのか、それすら不要と思っているのか。どんだけ「作り直す」つもりか。なるほど street view が全肯定されるわけだわ
  • 優秀なプログラマの給料が低いわけ - ひがやすを blog

    昨日の開発生産性が低い方が収入が多いって変だよねのエントリでは、企業レベルの話だと、生産性が低いほうが売上が上がるという話をしたんですが、実は同じようなことが、個人レベルでも言えます。 生産性の高い超優秀なプログラマより、社交性の高いそこそこ優秀なプログラマのほうが、評価が高く給料も多くもらえるようになるのです。さすがに、個人レベルだと生産性の低い人が評価が高いということはあまりないけどね。一時的には残業が多くて給料が増えるときもあるかもしれないけど、それはあくまでも一時的なこと。 評価が高いということは、上司にそれだけ認めてもらっているということですが、それではなぜ、優秀なプログラマは、上司に高く評価されないのでしょうか。 「上司技術をきちんと評価する力がないから」それも多少はあります。でも、主な原因ではありません。会社によって違うと思いますが、評価における技術力の部分は2,3割りに過

    優秀なプログラマの給料が低いわけ - ひがやすを blog
    t-murachi
    t-murachi 2008/07/24
    Paul K.Nakagome は挫折を経験したことがない人なんだね。打ちのめされてみて、初めて自分が評価なんてくだらないはずのものを期待してしまっていたことに、気がつくものなんだよ。
  • プログラミングファースト開発の必要性 - ひがやすを技術ブログ

    ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動

    プログラミングファースト開発の必要性 - ひがやすを技術ブログ
    t-murachi
    t-murachi 2008/07/22
    フィードバック重視の斜め上。規模次第ではこれはこれでありなのかも。作ったものを見せるより構想を説明した方が手っ取り早い場合もあるから全面適用は難しいんじゃないかな。あと doxygen 超便利。
  • SIerが必要としているのは業務知識だという都市伝説 - ひがやすを blog

    SI業界が開発するシステムの目的は何か? それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。 金融(ディラーが使うようなポジション計算をするフロントシステム、リスク計算をするようなミドルオフィス、勘定系のバックオフィス)、流通、輸出入、製薬など、いろんな業務をやってきたおいらが通りますよ。 確かに金融は業務知識がないと歯が立たない。でも、自分の経験した限りでは、それ以外の業務は、案件が始まってから勉強しても十分間に合います。 一週間以内の勉強で、お客様のところにいってシステムの仕様を話し合うことはできるようになります。もちろん、この道何年って人にはかないませんよ。でも、仕様を決める分には困らない

    SIerが必要としているのは業務知識だという都市伝説 - ひがやすを blog
    t-murachi
    t-murachi 2008/06/19
    こっちの方が頷けるなぁ。同業者 (特にお年寄り) にはなかなか理解してもらえないけど。。。
  • SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ

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

    SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ
    t-murachi
    t-murachi 2008/06/03
    おいらが最初にいた某社は、実はそういう意味では良い会社だったのかなぁ? あるいはおいらが居た部署だけだったのかなぁ。でかい会社だったからなぁ。。。その点メーカーはやっぱり良いよなー。
  • 10年間泥のように働いて花が咲きました - ひがやすを技術ブログ

    蓮の素晴らしさを語りたかったら、まずは花を見せるべきなのだ。花がわかってはじめて泥の重要さがわかってくるんだから。 2008-05-29 - ひがやすを blog 小飼弾のアルファギークに逢ってきたのメンバーと学生会の討論会を開くのだ。 もちろん、司会は、ダンコーガイ。いいよね、弾さん。 もちろんOK。というよりもすでに同様の話がいくつも来ているので、この通りになるかとにかく、ちゃんと「花」がある討論会はできるだろうし実現するだろうしすでにいくつか実現している。 しかし、これはこれでどうしても偏りが出る。10年も泥の中にいた人というのはさすがにこのメンバーの中から見つけるのは難しい。そしてIT業界の広さを考えれば、当にそういう人がいてもおかしくないはずなのだ。 10年間SIerで泥のように働いたおいらが通りますよ。 おいらが、最初に就職したのは、電通国際システムという会社で、今のうちの会

    10年間泥のように働いて花が咲きました - ひがやすを技術ブログ
    t-murachi
    t-murachi 2008/06/01
    なるほど。
  • 「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ

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

    「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
    t-murachi
    t-murachi 2008/03/27
    必要以上のドキュメントは要らないと思う。末端の解釈をかえって混乱させるだけだし。(多分そういう話じゃないw) / つか、ドキュメント書く側もどの程度の文書が必要なのか分かってないケースが多いんでね?
  • 「JavaからRubyへ」についてそろそろ本音を書いておくか - ひがやすを技術ブログ

    今回は、TKSKがおいらに乗り移って書くよ。おいらの文章じゃないので、誤解しないでね。(笑) TKSK開始 「JavaからRubyへ」を読んで、みんなおかしいとは思わなかったのかい。「Javaはフレームワークが乱立しているからだめで、RubyRailsただ1つ(103ページ2行目)だからいいんだ」という主張がさ。 オープンソースなんだから、みんなが作りたいもの作っていいじゃん。競争があるから切磋琢磨していいものが生まれるんだろう。 お前(著者)はプロだろう。なんだよ45ページの3行目は。 激動するJavaの最新技術の動向に遅れをとらないようにするのが つらくなっていました。 選択肢の多さに圧倒されていました。情けねぇ。 今じゃ、Rubyも選択肢がいろいろあるよ。また、選択肢の多さに圧倒されるのかい。難しいことは考えられないから、無難にRailsを使い続けるのかい。それじゃ、JavaでSt

    「JavaからRubyへ」についてそろそろ本音を書いておくか - ひがやすを技術ブログ
    t-murachi
    t-murachi 2008/03/12
    Ruby を知らなくても RoR コミュニティの雰囲気が大体わかっちゃうなぁ。。。フレームワークに群がる人々なんて所詮そんなもんなのかなぁ。
  • 1