タグ

ブックマーク / nowokay.hatenablog.com (7)

  • 日本のSIerの技術力の低さの要因から考えるアメリカソフトウェアの強さ - きしだのHatena

    この連休はなんだかSIerについて考えることが多かったのですが、そういうことを考えると、なぜアメリカのソフトウェアが強いのかがわかってきた気がします。 まず、もちろんSIer技術力が低いといっても技術力が高いSIerもいるわけで、とくにこのブログを見てる人だと技術力の高い側にいる人が多いと思います。 けれども、DX白書2023によればSIerIT人材というのは75万人いて、技術力の高い人はその一部で、多くは技術力の低い側にいるんじゃないでしょうか。 https://www.ipa.go.jp/publish/wp-dx/gmcbt8000000botk-att/000108046.pdf 2014年、ちょうど10年前に、プログラマはSIerと自社サービスで2分化するんではないかというブログを書いていますが、そのまま現実になった形です。 プログラマ業界の二分化 - きしだのHatena

    日本のSIerの技術力の低さの要因から考えるアメリカソフトウェアの強さ - きしだのHatena
    mopin
    mopin 2024/07/16
  • 掛算の順序と学習指導要領 - きしだのHatena

    あいかわらず掛算の順序の話がもりあがってるようなのだけど、コーディングルールの話なんだから計算の定義の話をしても徒労だよなと思いながら見ていた。 で、ちょっと教育指導要領解説を見てみたのでまとめる。 学習指導要領解説の記述 「【算数編】小学校学習指導要領(平成29年告示)解説」では次のようになっています。順序は表現のときの問題で、計算では交換則を使っていいとなっています。 被乗数と乗数の順序は、「一つ分の大きさの幾つ分かに当たる大きさを求める」という日常生活などの問題の場面を式で表現する場合に大切にすべきことである。一方、乗法の計算の結果を求める場合には、交換法則を必要に応じて活用し、被乗数と乗数を逆にして計算してもよい。 このPDFの115ページ。 https://www.mext.go.jp/content/20211102-mxt_kyoiku02-100002607_04.pdf

    掛算の順序と学習指導要領 - きしだのHatena
    mopin
    mopin 2024/04/07
  • オブジェクト指向はコードを複雑に読みにくくする - きしだのHatena

    「オブジェクト指向するとプログラムが読めなくなるから禁止」のような話は昔からあって、新しい技術についてこれない人を揶揄するようなニュアンスで使われていましたが、実際にはこれはオブジェクト指向迷路にうんざりした現場での率直な意見だと思います。 オブジェクト指向は、まじめにやるほどプログラムを読みにくくするという性質をもっています。 ※ 使い方次第というコメントついてますが、だからこそちゃんと性質をしっておく必要があると思います。 オブジェクト指向の代表的な指針を3つあげると次のようなものがあります。 オブジェクト同士の連携としてプログラムを組む 単一責務の原則 インタフェースと実装の分離 まず、オブジェクト同士の連携でプログラムを組むと、コードが飛びまくって追いにくくなります。そして単一責務の原則により、小さいクラスが大量に生成されて、追いにくさがさらにあがっていきます。 ダイクストラ先生が

    オブジェクト指向はコードを複雑に読みにくくする - きしだのHatena
    mopin
    mopin 2023/02/25
  • プログラムの生産性をあげるためには - きしだのHatena

    前回のエントリで、プログラマの業界が労働集約的なものと知識集約的なものにわかれてきているという話を書きました。 プログラマ業界の二分化 - きしだのはてな 前のエントリでは労働集約的なものと知識集約的なものに完全にわかれているように書きましたが、もちろん完全に労働集約的であったり完全に知識集約的であったりすることは少なく、どのような組織でもある程度は両方の性質をもっています。知識集約的な性質の強いSI会社というのもあります。 ただ、SIに労働集約的な、サービスに知識集約的な性質が強くなる傾向はあると思います。 また、知識集約的であればよくて労働集約的であればダメということもありません。労働集約的なSIでありながら良い会社というのもあります。 という断りをいれておかないと、SIで労働集約だからといって全部ひとからげにするなという、労働集約的なSIでありながら良い会社方面から鋭利なマサカリが飛

    プログラムの生産性をあげるためには - きしだのHatena
    mopin
    mopin 2014/03/12
  • 直列加算と並列加算でdoubleの足し算の結果が変わる話 - きしだのHatena

    Javaに限った話ではないのだけど、Javaで並列加算が気軽にできるようになったので、気に留めておいたほうがいい話。 まず、次のようなコードを動かしてみます。 public static void main(String[] args){ double[] data = { 1.234E80, -1.234E80, 2, 3}; System.out.println(Arrays.stream(data).sum()); System.out.println(Arrays.stream(data).parallel().sum()); } 1.234×10^80と-1.234×10^80という、桁が大きくて符号の違う数を並べて、そのあとに2と3という1桁の数値を置いています。 これらを加算すると、1.234×10^80と-1.234×10^80は符号が違うだけなので、当然結果は0になります

    直列加算と並列加算でdoubleの足し算の結果が変わる話 - きしだのHatena
    mopin
    mopin 2013/11/24
  • プログラマの実力は経験だけであがらないことがレベル格差につながる - きしだのはてな

    プログラマというのは、道具に慣れることが、実力があがることにならないのですよね。だから、勉強せず業務経験だけだとレベルが低いままということになってしまう。 Javaを10年さわり続けて、Strutsを5年さわり続けても、それだけでは、与えられた画面を手際よく作成できるようになるだけで、たとえばStrutsすらよりよく使えるようになるわけではなかったりする。 Javaにしても、「volatileってなんですか?」という問いに、まあ知らないのはしかたないとしても、解説を見ながらですら答えられない可能性がある。 プログラムの反復生産は、プログラミング能力の向上にあまりつながらない。設定や記述に慣れるだけだ。そして、この「慣れ」というのには「難しいからそもそも実装を回避する」というようなものも含まれる。実力の向上は、作業ができるレベルで止まってしまう。 プログラマとしての実力をあげるための勉強が自

    プログラマの実力は経験だけであがらないことがレベル格差につながる - きしだのはてな
    mopin
    mopin 2012/10/11
  • MVCは死んだ。MOVEするときがきた - きしだのHatena

    Conrad Irwinさんの「MVC is dead, it's time to MOVE on.」を訳してみました。 MVC is dead, it's time to MOVE on. この訳文も原文のライセンスを引き継いでCC-BY-3.0ライセンスで利用可能とします。 追記13:58 すでに訳してた方がいました。MVCの時代は終わった。MOVEを使い始めましょう。 - ふじこのプログラミング奮闘記 MVCは死んだ。MOVEするときがきた MVCはすばらしいアイデアだ。モデルを持ち、モデルは内部に少しの状態をもつ。ビューは内部に少しのUIをもつ。そして、コントローラは内部に少しの・・・ 何を持つ? 私は確かにこのことに気づいた最初の人物ではない。しかし示されたようなMVCの問題のために、あなたは最後には過剰なコードをコントローラに詰め込むことになる。なぜなら、他にどこに入れていいか

    MVCは死んだ。MOVEするときがきた - きしだのHatena
  • 1