建築では多重下請けでやれてるのに業務システムでだめなのはなぜ？ - きしだのHatena
建築では多重下請けでやれてるのに業務システムでだめなのはなぜ？という質問がブコメであって、似たような話もいくつか見かけたのですが、建築などの施工図面に相当するのはソースコードで、建築現場で多重下請けでやってる作業は、ソフトウェアだと(でも？)ビルドです。なのでソフトウェアでは自動化されています。 もしも業務システムの納品物が、バベッジの階差機関のような歯車を組み合わせた機械式の計算機で、ビル一棟分に歯車をつめこんで組み立てて納品するというようなことになれば、多重下請けで分業してビルドするのが最もよい方法ということになると思います。 追記 「継続的デリバリーのソフトウェア工学」では、「ソフトウェア開発を選んだ私たちがバカでない限り、私たちにとっての製造とは、ビルドボタンのクリックです」とあります。橋梁建設を例に、物理的な製造・生産との違いが説明されています。 継続的デリバリーのソフトウェア工
多重下請けでは構造的にいいソフトウェアが作れない - きしだのHatena
多重下請けではエンジニアが育たないという話を前回のブログで引用していたのですが、そもそも多重下請けではまともなソフトウェアは開発できないんではないかという気持ちになりました。 多重下請けでは、上位受け会社の「SE」が「設計」を行い、下位受け会社の「PG」が実装を行うという役割分担があります。というか、今回の話はそういう役割分担がある多重下請けを前提とします。 そうすると、設計というのは会社間をまたがった契約文書であり、発注のための作業指示書であるということになります。ソフトウェア開発で本質的に必要な文書というよりは、ビジネス構造によって必要になったビジネス文書です。ちなみに派遣ではなく業務委託のはずなので詳細な作業指示になってはいけないのもポイントです。 ※余談ですが「設計は必要である」という人の話をきいてみると、必要なのは実装のための設計ではなく保守のためのドキュメントということがほとん
時代がstaticおじさんに追いついてきた(追記あり) - きしだのHatena
この文章みてください。 オレはもう20年以上システム業界にいるけどな、その長い経験から言うと、オブジェクト指向なんてものは、理論としては面白いけど、およそ実用的とは言い難いものだな。まぁ、例えばGUIのコンポーネントとかはオブジェクト指向に基づいて作られているようだから、そういうツールとかを作る人には必要なものなのかもしれない。しかし君たちがいずれ作ることになる業務アルゴリズムにはまったく無縁のものだと思ってもらって間違いない。どうもこの業界、オブジェクト指向でなければダメ、というような風潮がまかりとおっているけどな、オブジェクト指向なんか本当に使っている人はほとんどいないよ。オレも少し勉強してみたけど、カプセル化とかポリ何とかとか、どうにも利点が理解できなかったね。実際、実業務で使ったことなどないしな…… 「またお前、オブジェクト指向の話をしてるのか」と思ったかもしれませんが、2010年
サーブレットを「JavaでのWebアプリケーションの基礎」として最初に勉強させるのをやめてあげてほしい - きしだのHatena
研修がはじまるという画像でサーブレットJSPの本が並んでて、サーブレットを最初に勉強させるのをやめてあげてほしいと思った話。 オブジェクト指向もそうなんだけど、現状で使わなくなっているにもかかわらず情報更新がされずオブジェクト指向やサーブレットJSPが教えられ続け本が売り続けられるという現状がある。 でももうさすがに変わってほしさ。 ただ、JSPはそこまで悪くないので、サーブレットで話を進める。(ただし、サーブレットが動かない環境ではJSPは動かない) 使われていない まず、いまの案件の多くがSpring / Spring Bootになってて、サーブレットをさわるということは少ない。 2020年のJetBrainsの調査ではこんな感じ https://blog.jetbrains.com/ja/idea/2020/10/a-picture-of-java-in-2020-ja/ 2021年
Rinnaの新しい3Bモデルを試してみる - きしだのHatena
CyberAgentのモデルを試したところですが、Rinna社も新しいモデルを出しました。 rinna、日本語に特化した36億パラメータのGPT言語モデルを公開｜rinna株式会社のプレスリリース ここですね。 https://huggingface.co/rinna/japanese-gpt-neox-3.6b ということで試します。 あれーいろいろ試したときはちゃんと東京、いや大阪って答えて面白かったのだけど、ちゃんと答えてくれない・・・ GPUメモリは14.8GB使っています。 torch_dtype=torch.float16を付けても8GBちょうどくらいのGPUメモリを使うので、8GB VRAMだとつらそうです。12GB VRAMであれば大丈夫そう。 そして、今回はチャット向けにトレーニングされたモデルも用意されています。 https://huggingface.co/rinna
CyberAgentの日本語言語モデルを試してみる - きしだのHatena
CyberAgentが日本語LLMを公開していたので、とりあえず動かしてみました。 サイバーエージェント、最大68億パラメータの日本語LLM（大規模言語モデル）を一般公開 ―オープンなデータで学習した商用利用可能なモデルを提供― | 株式会社サイバーエージェント モデルは次のように6サイズ提供されています。 ※ Rinna社も同時に新しいモデルを出したので試しています。 Rinnaの新しい3Bモデルを試してみる - きしだのHatena open-calm-small(160M) まずはopen-calm-small。160Mパラメータです。 このあたりは動作確認用なので、内容は気にしない。 GPUメモリは1.3GBくらいの消費です。 open-calm-medium(400M) 次にopen-calm-medium。400Mパラメータです。 このへんも細かいことは気にしないけど、なんかま
Javaのインストール2023年版 - きしだのHatena
ちょっとJavaのインストールについて調べてみました2023年版。 Javaにはディストリビューションがたくさんあるので、目につくインストーラーをWindowsで全部ためしてみました。 初心者が勉強するためにJavaをインストールするというときにどれを使うのが手軽か確認するというのが主な目的です。 Oracle JDK Temurin by Adoptium Amazon Corretto Azul Zulu Liberica JDK Microsoft Build of OpenJDK SapMachine OpenJDK SDKMAN! winget OpenJ9 / Semeru Runtime Red Hat Build of OpenJDK GraalVM Scoop いろいろあるので、結論を先に書いておくと次のようになります。 いまPATHの設定が必要なJDKインストーラはない
ChatGPTのヤバさは、論理処理が必要と思ったことが確率処理でできるとわかったこと - きしだのHatena
ChatGPTのヤバいところは、論理処理が必要だと思っていたことが、じつは多数のデータを学習させた確率処理で解決可能だと示したことだと思います。 たとえば、このように正規表現にマッチする文字列を生成するには、特別に専用の論理処理が必要だと思っていました。 前のブログのときには特殊処理が必要だと考えてましたね。 ウソはウソと見抜ける人じゃないとChatGPTを使うのは難しい - きしだのHatena けど、123_45678world.mdはマッチするのにマッチしないと言っているので、そのような誤りが入ることを考えると、どうも確率処理だけでやっているようです。 考えてみると、3層以上のニューラルネットであれば論理素子を再現できるので、ディープラーニングで論理処理を模倣することは可能なんですよね。 バックプロパゲーションでニューラルネットの学習 - きしだのHatena そもそも論理は、多数の
さよなら「あなたとJAVA」 - きしだのHatena
みんなから愛された「あなたとJAVA」の役割が終わったようです。 「Java」で検索するとjava.comのサイトがひっかかるのですが、このサイトは古いまま放置されていて、Javaの学習を始める人にとっての罠になっていました。 https://www.java.com/ja/ 「あなたとJAVA」というキャッチコピーの脱力感と、「ダウンロー」で改行され「ド」だけが目立ってしまう間のヌケかたから大人気のサイトでしたが、かっこいいものではない・・・ もともとはJAVA+YOUで、2008年JavaOneのキャッチコピーでした。これは大文字だけのデザインだからよかったのだけど、日本語訳するときJAVAだけ大文字で残ってしまい「JAVAではなくJava」の説得力をなくさせてくれていました。 それに、ほとんどの人がJavaのプログラミングの勉強をしようとして「Java」を検索するのにJREの配布サイ
JavaScriptはJavaのScript版(であろうと努力はした) - きしだのHatena
JavaとJavaScriptを混同する人に、名前がかぶってるだけの別モノという指摘がされることもあります。間違いではない。 技術的にも実務的にもコミュニティ的にもそのとおりではあります。 ただ、そう言い続けられた結果、ほんとに単にLiveScriptの名前にJavaをもってきてJavaScriptにしただけという誤解があるようです。 JavaScriptはJavaのScript版、少なくともそうであろうという努力はされていました。 JavaScriptリリース時のCNETの記事には「JavaScript is based on Java」という記述があります。 Netscape and Sun Unveil JavaScript - CNET 実際には、LiveScriptにJavaから文法やライブラリなどを持ち込んでリリースにこぎつけたというのがあります。 JavaScriptのDat
オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだのHatena
某所でオブジェクト指向についていろいろ書いたのでまとめておく。 問題意識としては初学者がなにかというと「オブジェクト指向できるようになりたい」のようなことを言うけどそこまでの優先順位でがんばるものではないんでは、というところです。 まず前提として、オブジェクト指向は1980-2000年くらいに流行って発達したものの、それ以降は時代にあわせた進歩はしていない20年以上前の技術ってのがあります。 そのころは今だとCPUのキャッシュにも満たないようなメモリをやりくりしてプログラムを書く必要があったので、オブジェクト指向はメモリ上のデータをコピーすることなくうまく使いまわせるようなプログラム技術になっています。 そしてオブジェクト指向にはそこから目だった更新はなく、タイトルに書いたように、カメラがやっとついたくらいのガラケーのような古い技術という感じがします。 オブジェクト指向について、アプリケー
一人暮らしならトイレのドアを閉めては いけない - きしだのHatena
一人暮らしならトイレのドアを閉めては いけないし、トイレのドアの前に段ボールなど立てかけてはいけない。 トイレのドアが開かなくなったら死ぬ。 「トイレ 閉じ込め」で検索すると事例が結構でてくるけど、通話中であったり同居人に助けられたり約束していた人が110番してくれていたり、だいたい他者によって助けられている。 あと、助かった人はおもしろおかしくツイートしてバズるのだけど、おそらく亡くなった人はツイートしないので広まりにくい。 こういうの見ると怖い。 近所のマンションでトイレに閉じ込められての死亡事故がありました。独身のサラリーマンの方で、会社も欠勤し電話も出ないため、まさかトイレに閉じ込められていたことは想定外だったようです。 https://qa.itmedia.co.jp/qa9578401.html 携帯を持って入ればいいのだけど、こういう事故というのは たまたま携帯もってないとき
組み込みソフトウェア業界というナゾの裏世界の話 - きしだのHatena
ここまでのあらすじ 我々の住むソフトウェア業界は、SI、サービス・パッケージ、ユーザー企業という大小３つの大陸にわかれ、時々いさかいがありながらも平和に暮らしていた。 そして、我々の住む世界とは別に、同規模の技術者が暮らす、組み込み業界という世界の存在も知られていた。 組み込み業界は、存在はすることは確かなのだが技術者の姿は見えず、そのプロダクトの存在も、わかるものにしかわからないのであった。 我々は、組み込み業界と交信できる唯一の手段、C言語を使って、その世界の住人と交信するしかなかった。 しかしあるとき、FPGAという次元ホールをみつけたワカモノ達が、組み込み業界に迷い込んでしまう。ワカモノ達の前に立ちはだかる屈強な組み込み技術者。彼らの前にワカモノたちは、あるものは倒され、あるものは捕らわれ、そして、命からがら表の世界に逃れてきたワカモノも「べり・・・ろ・・ぐ・・・」というナゾの言葉
プログラムの生産性をあげるためには - きしだのHatena
前回のエントリで、プログラマの業界が労働集約的なものと知識集約的なものにわかれてきているという話を書きました。 プログラマ業界の二分化 - きしだのはてな 前のエントリでは労働集約的なものと知識集約的なものに完全にわかれているように書きましたが、もちろん完全に労働集約的であったり完全に知識集約的であったりすることは少なく、どのような組織でもある程度は両方の性質をもっています。知識集約的な性質の強いSI会社というのもあります。 ただ、SIに労働集約的な、サービスに知識集約的な性質が強くなる傾向はあると思います。 また、知識集約的であればよくて労働集約的であればダメということもありません。労働集約的なSIでありながら良い会社というのもあります。 という断りをいれておかないと、SIで労働集約だからといって全部ひとからげにするなという、労働集約的なSIでありながら良い会社方面から鋭利なマサカリが飛
Java8日付時刻APIの使いづらさと凄さ - きしだのHatena
いままでのJavaでは、日付時刻を扱おうとするとめんどくさい割に非常に低機能でした。 Java8では、新たに日付時刻APIが導入され、めんどくささが増しつつ非常に高機能になりました。 (以降、Java8で導入された日付時刻APIを単に「日付時刻API」と表します) もちろん、慣れてきて、ちょっとしたサポートメソッドを用意してやれば、結構使いやすいのですが、それは「このAPIは使いやすい」という評価にはなりません。 つまり日付時刻APIは、慣れないとぜんぜんわからないし、サポートメソッドがないと面倒なコードが必要ということです。 いろいろあってよくわからない 日付時刻では、時点を扱うInstantや期間を扱うPeriod、時間量をあらわすDurationなど多くのクラス・インタフェースが導入されています。 これらは、IDEの補完でAPIを探りながら機能を推測すれば、それなりにドキュメントなし
ファーストサーバの手順の問題点 - きしだのHatena
えらいことなってますが。 正規手順と今回の現象の説明などを含めた中間報告が出されています。 http://support.fsv.jp/info/nw20120625_01.html ここで、正規手順で、途中でオペレーションミスがあったときに復旧できない状態になってしまう可能性があることがわかります。 具体的には「原因3：メンテナンス仕様」のこの部分。 脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用する この時点でこの更新プログラムに不具合があった場合には、リストアできなくなることになるわけです。そして今回はそれがおきたようです。 より安全な手順であれば、バックアップ側にパッチをあてている間は正常系がバックアップのバックアップということになるはず*1ですが、どこにもバックアップがない状態になってしまったわけです。 手順１
プログラマが解くのに1時間かかるという問題が普通にプログラマな方法で5分で解ける話 - きしだのはてな
こういう問題が流れてきた。 まつひろのガレージライフ: 幼児が数分で解けるのに大人が解けない算数（？）の問題 「幼稚園児が５〜１０分で解けるのに、プログラマなどの頭脳労働職の高学歴の方が解くのに１時間もかかる」とあるけど、これ1時間かかるの、プログラマとしてあまりよくないんじゃないのかなーと思った。 ので、プログラマ的に解いてみる。 改めて書き出すとこう。 8809=6 3333=0 7111=0 5555=0 2172=0 8193=3 6666=4 8096=5 1111=0 1012=1 3213=0 7777=0 7662=2 9999=4 9313=1 7756=1 0000=4 6855=3 2222=0 9881=5 3333=0 5531=0 5555=0 2581=??? 問題は英語だし語呂合わせじゃない。幼稚園児にわかるということでそこまで複雑なルールでもない。なんらか
ネットワークに自信のない人は東大講義の情報工学概論Ａを見よう - 2012-01-28 - きしだのはてな
東大にUTオープンコースウェアというのがあって、いろいろな講義資料が公開されています。 http://ocw.u-tokyo.ac.jp/ その中には動画授業があるものもあって、そのほぼすべてがおもしろいです。ただ興味がもてるかどうかという違いだけ。 その中で、情報工学概論Ａというのがあって、授業内容としてはネットワークの概論になってます。まだ全部見てないけど、ネットワーク全般の話からTCP/IPの話、セキュリティまでの講義が公開されてるみたい。 こういう一貫した話がちゃんと語られてる講義というのはなかなか公開されてない、公開されてたとしてもネットワーク設定程度だったりするので、これは貴重だと思います。 http://ocw.u-tokyo.ac.jp/lecture?id=11314&r=609526321 ネットワークの勉強をしたことがない人は、テレビのかわりにこの講義を流しておくとい
Google App Engineのプロパティ名は可能な限り短いほうがいいかもしれない - 2010-02-05 - きしだのはてな
他の話を期待してる人も多いと思うのだけど、まとめるのに時間がかかりそうなので小ネタを。 まず、このエンティティ使用状況をみてください。 これ、http://kistools.appspot.com/rateで格納されているエンティティのひとつなんですけど、Metadataが85%になってます。 内訳はこんな感じで、Integerのプロパティが２つあって、あとはMetadataです。 同じIntegerでも利用率が違うというのも面白いところですが、確かに上のプロパティのほうが桁数が大きいデータが入ってるとはいえ、これは誤差かも。 ところで、Metadata。 Google App Engineのデータストアは、それぞれのエンティティにプロパティ名まで格納しているはずです。 ということは、長いプロパティ名を使うとそれだけMetadata容量が増えてしまう。特にログのように量の増えがちなデータに
3年後にRubyを勉強し始める人の動機は何になるだろう？ - 2009-11-26 - きしだのはてな
たとえば、JavaだとAndroid、Google App Engine。あと、期待してるのがGWT。 PythonはGoogle App Engineでたくさんの人が触るようになってると思う。 PHPは、なんだかんだでデザイナに近いところの人には欠かせないだろう。Flashも。 Perlはゲノム系の人は使うんだろう。WebのためにPerlの勉強を始める人というのは、今の時点でもいない気がする。 C#はマイクロソフトの続く限り。C/C++はコンピュータの続く限り。 という感じで考えたときに、既存プロジェクトがRubyで書かれてるとか会社の方針とか、そういうしがらみがないとき、3年後にRubyの勉強を始める人は、何を動機にしてるだろう？ あと、Javaに関して、もしGoogleがPythonしかサポートしていない会社だったら、ぼくはJavaを今 積極的に触ってない自信がある。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
