2020年4月
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    

最近のコメント

最近のトラックバック

無料ブログはココログ

« 2019年5月 | トップページ | 2019年7月 »

2019年6月

2019年6月19日 (水)

64bitのIIS(Internet Information Services)で32bitのアプリケーションを動かす方法

先日、古いASP.NETのWebアプリケーションの開発環境の構築を頼まれて、PCに構築していたら、Visual Studio上ではコンパイルが通るのに、ブラウザで動かそうとすると、エラーメッセージが出てきて悪戦苦闘しました。

エラーメッセージ「ファイルまたはアセンブリ’・・・’、またはその依存関係の 1 つが読み込めませんでした。間違ったフォーマットのプログラムを読み込もうとしました。」

何だろうか、見当がつかずあれこれやっていたら、そう言えば、サードパーティー製の古いdllを読み込んでいたなと思い出し、64bitのIISで32bitを動かすときは、IISの設定しないと思い出しました。

設定することは、下記の内容になります。
IISのアプリケーションプールの詳細設定で、「32bitアプリケーションの有効化」をTrueにする

設定したのはWindows8.1のIISです。多少他のバージョンでは、画面の構成が異なると思いますが、同じ設定で動くと思います。
IISのアプリケーションプールの詳細設定画面

2019年6月12日 (水)

節約料理 人参と玉ねぎのかき揚げ

人参と玉ねぎのかき揚げ
かき揚げとか天ぷらはお金のないときに少ない食材で、沢山作れる節約料理だと思います。
特に、野菜のかき揚げは、野菜自体がそんなに高くないこともあり、特に節約ができるかと思います。

人参と玉ねぎのかき揚げですが、どちらも3個で99円(一個当たり33円)ぐらいのものを買っていますので、2人分ですが、野菜だけで50円ぐらい、それに卵・小麦粉・片栗粉・油などをどんなに多く考えても100円には届かないと思います。(1人当たり50円を超えない)

難点は、ちょっと調理時間がかかることと、油者ですので片付けが大変なことでしょうか?

材料

  • 人参・・・1/2本
  • 玉ねぎ・・・1個
  • 小麦粉・・・大さじ4~5杯程度
  • 片栗粉・・・大さじ1.5~2杯
  • 卵・・・1個
  • 水・・・ 20cc
  • サラダ油・・・フライパンに2~3cm程度

作り方

  1. 人参を細切りにする
  2. 玉ねぎは皮をむき、繊維に沿って1cm程度に切る
  3. 小麦粉・片栗粉・卵をボウル混ぜ、水を加えて衣を作る
  4. 3の衣に人参・玉ねぎを混ぜる、衣が足りない場合は、小麦粉・片栗粉を適宜追加する
  5. フライパンに油を張り、箸や串を突き立てて、周りが泡立つようになったら、ボウルから、適当な量をつまんで油に入れる
  6. 最初は強火にして、焦げる前に火を弱火程度にする
  7. 片面が揚がったら、ひっくり返してもう片面を揚げる。茶色くなる前にフライパンから取り出す

 

2019年6月 7日 (金)

詳細設計書が役立たずになる理由や解決策について

※以下の内容は、中規模~小規模なシステムの開発で要件定義~テストまで同一グループで行う場合に当てはまるであろうことで、大規模システムの開発では、通用しないことは断っておきます。また、ユーザの頭の柔らかさや、開発手法の違い等も影響するので、ある一例と考えてもらいたいです。

詳細設計書は、だいたい役立たずになります。あんなに時間をかけて、コードと1対1になるようにExcel方眼紙に文章書いて、SQL文は印刷に収まるように加工したのに、役に立つのは最初だけ、その後は、不具合報告を潰しまくっているうちに、どんどん設計書と乖離していく始末。

教科書通りでは、「詳細設計書を直したうえで、プログラムを直すように」なんて言われますが、その時間は遅れているプロジェクトでどこから捻出できるのでしょうね?

教えて偉い人(プロジェクトマネージャー)
プロジェクトマネージャー「そんなの自己責任だ、どうにかしろ!」

出ました自己責任、新自由主義者かアンタは。

あんまり書くと、パワハラのフラッシュバックが来て「近所迷惑」をしでかすかもしれないので、これぐらいにしておきます、文章が進みませんし。

詳細設計書を書いてからプログラミングという流れって、開発環境がまだ十分でなかったころ(COBOL全盛の頃とか)の名残だと思うのですよ。昔は、端末でコーディングする前に、入念にコーディングシートに記載して、机上デバッグしてから、端末でコードを打ち込むのとよく似ているなと思いまして。

でも、当時と今では、開発する内容も高度化していますし、複雑さも増していて、更に低価格受注、短納期となっていますので、古き良き時代(?)のようには、行かなくなっているかなと思います。

それなのに、このコーディングシートの後継と思われる、詳細設計書は名前を変えながらに残っている。
しかも、JavaやC#を使っているプロジェクトなのに、使用関数と書いてあったりしている。

愚痴をだらだら書くだけでは、居酒屋のサラリーマンと変わらないので、解決策というか、この詳細設計書を誤魔化した実例を載せておきます。上には極秘でこっそりやった方法になります。(色々な要因があるので、「銀の弾丸」では無いと思っていますが、この時は比較的、上手く行きました)

今の時代だと、Excel方眼紙と睨めっこして、プログラムを脳内で作ろうとするよりも、テーブルの定義をとりあえず作ってみたり、考えるためにプログラミングをした方が、開発効率が良いと考えて、実際そうしました。脳内妄想よりは、実際動かして試行錯誤できる分だけ、信頼性は上がるのではと思います。

こんな方法で、プログラムを書くと、品質の悪いコードが出来上がりそうですので、その汚いコードをリファクタリングして綺麗にするか、もう一度、綺麗に清書する必要はあります。

そのときに、最終的にプログラムを完成させるために、上記の未修正のコードと直す指示を出すためのものとして、ドキュメントを作って、プログラム担当者に渡す必要がありました。
(自分で直すなら、大規模修正でない限り、要らないと思いますが)

それで、プログラムが完成した後に、プログラムの説明を記すものとして、プログラムの説明書は作っておいた方が、良いかと思いますが、コード1対1のようなものは、作りませんでした。例えば、画面だったら、ボタンを押すとこういうイベントが発生して、どのメソッドが呼ばれるかなどでいいかなと思います。それ以上細かいことは、コードを読みましょうでいいと思うのです。(実際そうなるのだし)

それ以上に、クラス図などプログラム間の繋がり等を俯瞰できる設計書は必要と思っています。

そもそもプログラムを書くという工程は、製造ではなく設計の最終工程と思っています。プログラムが製造されるのは、コンパイルで、実行可能ファイルが出来上がるところだと思います。(コンパイル不要な言語でしたら、適宜読み替えましょう)

でも、「プログラムは人件費の安い中国(この頃は東南アジア?)にオフショアだ」とお考えの方々には、プログラミングは、製造なんでしょうね。

2019年6月 3日 (月)

会社標準の開発プロセス(ウォーターフォールモデル)に関する、あるユーザー側の評価と私見

今、勤務している会社はウォーターフォールが大好きです。
ウォーターフォールを必要としないような、小規模開発などについても、ウォータフォールに沿った手順を踏まされます。
では、ウォーターフォールで上手くできているかというと、決してそういう訳ではないのですが...

先日、システムを導入した会社の担当者(システム担当でなく、業務担当)と話をする機会があり、そのとき、ウォーターフォールに関する進め方についての、ユーザー側の意見を訊きました。

前提

  1. 弊社開発のパッケージソフトの導入で、パッケージ部分の導入については、ほぼパッケージ通り(一部カスタマイズあり)
  2. 小規模なサブシステムを機能を新規で追加する(マスター・帳票含めて10画面程度)
  3. ユーザー側は、システム担当1名、業務担当1名という状態で、とてもドキュメントの確認に手が回らない状態
  4. 会社の方針で、標準に定められているウォーターフォールで勧めろとの指示(パッケージ導入とカスタマイズ部分を同時に導入しろとのこと)

これに対する意見

  1. 要件を出してくださいと言われても、いざ動かしてみないと分からない箇所や見落としがあるので、要件定義・基本設計で仕様凍結をしてしまうのは、問題がある
  2. バインダーに挟まれた大量の紙資料をもらっても、システムの動くイメージまではどうしてもできなかった。
  3. 動かせる部分は、早く操作して、業務との乖離を確認したかった。(多少の設定ミスのバグなどは気にしないとのこと)

開発担当者だった私の意見としては、さっさとパッケージのパラメータ設定してパッケージのままで動かしてしまい、パッケージのカスタマイズ部分と小規模なサブシステムを反復的に開発した方が良かったと思っていましたが、会社の方針でダメだったと伝えました。

そうしたら、担当者からは「そうして進めてもらえれば、良かったかもしれない」との意見でした。

開発プロセスの標準化も結構ですが、あくまでも「標準」であって、絶対では無いと思うのです。標準通りに進めることが「お客さんのため」ではなく、開発側の都合(ISO9000の審査のためなのか、いちいち考えるのが面倒と思っているかは分かりませんが)だと思っています。

プロジェクトでは開発側、ユーザ側、双方が使える資源(費用、人手、時間、技術レベル等)の中で、どのような手段をもって実現していくかを考えて行かないといけないかと考えています。標準の開発プロセスに無理に合わせるのではなく、プロジェクトによってカスタマイズないしは、従わないという選択肢もあっていいのではないかと思います。

それに、管理者は「会社の決まりだから従え」というのではなく、「自分の頭」で考えてもらいたいものだと思います。

« 2019年5月 | トップページ | 2019年7月 »