ゼロからはじめるシステム開発

　こんにちは！
　ナビゲータのEVEです。

　昨日までは、DBへ接続するユーザーIDとパスワードを管理する方法について検討してきましたが、ブログアップロード後ChatGPTから以下の指摘がありました。

　今回、etcに設定し利用しようとしてるのですが、以上の指摘だとrequire_onceの記述が複雑になります。しかも、❷が気になります。以上のようなことを考慮すると、配置先は限定され、�@と�Aを利用するのは難しくなります。

なお、以上にChatGPTがプロジェクトと記述しているその内容をいろいろと調べた結果、var配下は一応Apacheは認識でき、それをプロジェクトと言って問題ないようです。但し、その調査は、十分し尽くしたと言えるレベルではないので、後日訂正するかもしれません。

[最終検討]
　ChatGPTとの長い時間会話した結論ですが、環境変数によりDBへ接続するためのユーザーIDとパスワードを設定し、設定したファイル値を$_SERVERで取得する仕様にしようと現在は、考えています。その場合、Apacheルート配下へDB接続するユーザーID、パスワードを管理するファイルを配置する必要はありません。しかも、$_SERVER変数として、プロジェクト内ならどこからでも取得することが可能です。ただ、この場合の問題は、設定するファイル名が限定されます。それは、ちょっと、いただけません。

[あとがき]
　DBへ接続するためのユーザIDとパスワードの管理方法については、問題はあるものの、今回はこれで、最後としたいと思います。$_SERVER変数への設定は、現在ファイル名が限定されるという問題はありますが、SALT値を導入することができれば、セキュリティが格段と上がります。という観点から言うと、以上の検討はEVEシステムでの利用となりそうです。ただ、Prototype EVEでは、ファイル名が限定される以上の方法は問題があると考え、別の方法で対応します。ここで、それを書こうとしたのですが、セキュリティ上問題があると思われますので、この辺までとさせていただきます。

　では、また！

　こんにちは！
　ナビゲータのEVEです。

　昨日までは、DBへ接続するためのユーザーIDとパスワードをハードコーディングする場合、どうしたらいいのかという検討をしてきました。
　本日は、同ユーザIDとパスワードをどのような形で管理をしたらいいのか具体的な検討に入りたいと思います。

[管理方法]
　ChatGPTは管理する形式について、一例ですが、以下の方法を提案しています。

　以上のファイルをどのように管理するのかその保管方法について以下の内容で提案しています。


[検討]
　ファイルを指定して、中身に定義している変数の内容を取り出すのはどの形式のファイルでも同じようです。そのため、プログラミングの生産性という意味では、�@〜�Cにおいては、同じと言うことになります。それでは、次に1)〜4)のセキュリティについて考えて見ましょう。
　1)は当然リリース時に実施します。所有者はApacheでそれ以外のユーザーに利用させないようにします。現在は以上のように設定していますが、EVEシステムでは構成管理システムで自動で行う予定としています。
　2)はどうでしょうか？DBへ接続するユーザーとパスワードのユーザを格納するファイルを暗号化した場合、当然復号しなければ利用できません。それを、データベースを利用するたびに実施するのでしょうか？この方法は現実的ではありません。私の作るシステムでは利用は難しいようです。
　3)ファイルの格納場所ですが、どこがいいでしょうか、Windowsユーザーにはあまり知られていませんが、Linux系OSの各フォルダには役割が決まっています。この機会に、Ubuntuで利用している各フォルダの役割についてChatGPTに解説をしてもらいましょう！

以上の調査結果から、etcがふさわしいようです。
　4)については、セキュリティにおいてログの管理方法を検討する機会があります。その時にどうしたらいいのか検討したいと思います。そのため、ここでの検討は省略します。

[あとがき]　
　今日も時間がきましたので、この辺までとさせていただきます。

　現在、クラスを製造していますが、そろそろ、文字クラスの製造の終わりが見えてきました。以前、以下のクラスを作ると話していました。

ただ、予定が変わり、現在は、文字クラスなら、Prototype EVEで利用していた関数をすべてクラスに変更しています。理由は、文字クラスならそのクラスで文字列に対する機能をプロパティ、メソッド等という形で提供していることを作っている途中で悟ったからです。そのため、配列Classは1つしかメソッドを記述していませんが、それ以外にもメソッドを製造しています。
　その他のクラスも同様に製造する予定です。そのような製造方針で作っていて、2月末日までに製造が完了するかどうか、あやしくなってきました。これから、速度を上げて製造していきたいと思います。

　では、また！

　こんにちは！
　ナビゲータのEVEです。


　昨日までは、Webサーバー側からDBに接続するための、ユーザーID、パスワード保存するためにどんなセキュリティがあるのか検討し、そのセキュリティの問題点について考えてきました。そして、パスワードをPHPから定期的に更新することについては、リスクの軽減になるが、同ユーザーIDとパスワードの保存方法について細心の注意が必要だとChatGPTから指摘がありました。同4項目の指摘について、現在のPrototype EVEでの対応方法について考えてみました。❶〜❸までは見通しがたったのですが、❹のユーザーIDとパスワードのハードコーディングについて問題が解決できていないので、引き続き検討していきます。


[ユーザID、パスワードのハードコーディングの検討]
　では、ChatGPTはどのような保管方法が高いセキュリティで保護されるといっているのでしょうか？

　では、重要だといっていることについてChatGPTに再質問をしてみました。

最初の解答は、セキュリティのことは一切考えておらず、DBサーバーへのアクセスするためのユーザーIDとパスワードを格納しやすいファイルとして紹介してくれたようです。この場合、�@�Aは、DBサーバーへのアクセスするためのユーザーIDとパスワードを保管する方法としては不適切だと思ったのですが、「3)ファイルの場所」を見てはっとしました。当該ファイルをApacheのルートフォルダに設定する必要はないのです。もしかしたら、etcでもいいかもしれません。それを考えたら、別にPHPファイルで保管する必要はないようです。
　なんで、こんなこと今まで気づかなかったのでしょうか？これが、1人で開発する場合の限界です。ただ、今は、ChatGPTがいます。何かあればChatGPTに相談し、問題点を洗いだし、その問題を解決しています。

[あとがき]
　今日も時間となってしまったので、この辺までとさせていただきます。
　このような検討をしていると、いろいろな部分に配慮しないといけないことが分かります。
　「4)サーバーのログに記録されないように」とありますが、これについて、Microsoft社がやってしまったことがありました。それは、システム障害が発生したとき、公開鍵暗号方式の秘密鍵をログに書き込んでしまったのです。そして運悪く、そのログを中国人ハッカーに見られてしまったということがありました。そのあとは、ハッキングのし放題です。多分ですが、機密情報を窃取されたのでしょう？

　現在は、セキュリティは、必要不可欠なもので、リリースする前には、セキュリティチェックは必須です。ただ、Microsoft社のような大企業になると、システムも巨大で、かつ、それの全てを監査するのは難しいと思われます。結局は、問題が発覚してからの対処になるのでしょうか？どうしたら、いいのか引き続き考えていきたいと思います。

　では、また！

　こんにちは！
　ナビゲータのEVEです。

　昨日は、Prototype EVEのセキュリティリスクについて検討しました。ただ、その検討結果をChatGPTにお聞きしたところ、セキュリティ上問題があるとの回答があり、本日再検討することになりました。では、ChatGPTは昨日の検討について、どんな問題があると指摘しているのでしょうか？

[ChatGPTからの指摘]
　ChatGPTは、以下の問題点を指摘しています。


[ChatGPTからの指摘]
　聞いている問題点は、PHPからDBのユーザーIDとパスワードを変更するに際し、セキュリティリスクがあるということへの質問だったのですが、ちょっと、的がはずれているようです。その原因について深掘りして聞いてみると、更新すること自体はセキュリティリスクの軽減になるのですが、そのユーザーIDとパスワードを管理する方法について問題視しているようです。
　ChatGPTの指摘を、Prototype EVEではどうなのか考えてみたいと思います。

　❶ですが、root権限では、権限が高すぎるといっています。これについては、実行するためのユーザーを複数作り、この問題に対応したいと思います。
　❷SQLインジェクションですが、プログラム的に対応しているので、問題ないと考えています。
　❸Webサイトを構築する場合、3階層にします。クライアント、Webサーバー、そしてDBサーバーです。そして、WebサーバーはDMZ上に存在し、DBサーバーは社内にあるのが通常です。ここでは、そのWebサーバーとDBサーバーの通信が暗号化されていないことを、問題としています。通常は、DBサーバーとの通信をWebサーバーに限定し、ポート番号を制限するというところまでですが、それだと、盗聴された場合、通信の内容が垂れ流し状態になります。Webサーバー（PHP）とデータベースサーバー(MySQL)間を、SSL/TLSで通信させる方法があるので、それを検討したほうがいいようです。
　❹は仕方がありません。Webサーバーからアクセスする場合のユーザーIDとパスワードなので、データベースに格納することはできません。じゃ、どこに格納するかというとやはり、Webサーバー上のどこかということになります。

[あとがき]
　また、長くなってしまったので、本日は、ここまでとします。なお、❶〜❸の問題については、解決の見通しがたったので、明日は❹のハードコーディングの問題について検討を進めたいと思います。

　❹ハードコーディングの問題はどうしても、問題は問題として認識し、それでもWebサーバーにユーザIDとパスワードをハードコーディングしなければなりません。明日は、このリスクを保有するに際し、どう対応するのか検討をしたいと思います。

　では、また！

　こんにちは！
　ナビゲータのEVEです。

　一気にと行きたいのですが、地道にプログラムを製造しています。
　中には、システム的に定義されているんだけれど、実際に使われておらず、かつ、どうやって使ったらいいのか不明だったモノがあったり、思ったより大変です。ただ、使われておらず、プログラムを見ても使用用途が分からないものは、どうしようもないので、削除しています。

[システムの脆弱性]
　Prototype EVEの脆弱性を見つけてしまいました。それは、データベースに接続するためのユーザIDと、パスワードについてです。
　Prototype EVEでは、システムを動かすのに、root権限で実行しているのですが、それは、当然、Webサーバー側に設定しています。そうしないと、データベースにアクセスできませんから・・・。開発をし始めた2004年は、テキストファイルで一元管理していたのですが、それだと、アドレスバーから当該ファイルを指定した場合、その中身が見えてしまいます。それでは、まずいので、格納ファイルをPHPファイルに変更しました。実は、それで満足し、現在まで至っています。

[どんな脆弱性]
　Prototype EVEでは、データベース接続用のユーザIDとパスワードは定数で管理しています。そのため、ハッカーがPHPファイルをアップロードする手段があり、かつ、ユーザIDとパスワードの定数が分かった場合、echoとかprintでブラウザから確認できてしまうのです。

[現在の対策]
　以前自宅にサーバーを設置していたときのことですが、そのときは、サーバーのハードニングを行い、Prototype EVEからしか、ファイルの更新や、データベース操作ができないようにしていました。それに加えて、Prototype EVEからアップロードするファイルを限定していました。だから、問題ないとは思うのですが、自分ができないと思っても、できちゃう人はできちゃうんですよね・・・。

[今後の対策]
　今後の対策ですが、ChatGPTと会話をしていて、いい方法が思いつきました。
　データベースのユーザIDとパスワードなので、データベースに格納はできません。だから、今まで通り、ファイルで管理をするのですが、データベースにアクセスする場合は、ユーザIDとパスワードにSALT値をつけたものをユーザーIDとパスワードとして登録するのです。そうすれば、定期的に、SALT値を変更するだけで、ユーザIDとパスワードを高いセキュリティレベルで守ることができます。

[あとがき]
　実は、問題点もあります。それは、最初どうするか？
　普通にやるとすれは、ユーザID、パスワードとSALT値を用意し、用意したユーザIDとパスワードにSALT値を付加し、SHA3でハッシュ値を取った値を、MySQLのユーザIDとパスワードにするという方法です。最初だけだからいいのですが、ちょっと、間抜けです。やはり、これも、EVEシステムでユーザーを管理する方法と同様に、モードを用意し、通常モードで安全に稼働するようになったら、セキュリティの高いモードで管理するという方法がいいでしょうか？
　ただそれだと、EVEシステムのフレームワークができてからということになり、Prototype EVEで運用している時はどうしましょうか？

　頭が痛い問題です。

　では、また！

　こんにちは！
　ナビゲータのEVE Sunです。

　今日から、システム製造の再開です。以前の開発体制に戻すので、平日はゴリゴリと製造するのではなく、隙間時間を利用し、1日1〜5メソッドの製造をしていく予定です。
　中小企業経営政策で時間が思った以上に取られましたが、その間、いろいろとシステム製造について考える時間を持つことができました。その考えることにより6、7月クラス関連の見直しの作業が必要なくなるかもしれません。ただ、オブジェクト指向言語でシステムを作ったことがないので、想像通りにならない可能性はありますが・・・・。


[ログインシステム製造後]
　クラス関連の製造を除けばかなり余裕をもったスケジュールです。捕らぬ狸の皮算用だと言われるかもしれませんが、ついついその先のことを考えてしまいます。
　以前、EVEシステムは以下のようなコンセプトで製造するという話をしています。


以上の全体のアウトラインは変わっていないのですが、細かい部分が少しずつこの時考えたものと違ってきています。特に�Dです。

[�Dすべての操作を一つの手順で]
　ここでいっていることは、データベースに関する開発のことを言っています。
　昔は、小さいテーブルなら普通に製造できるのですが、そのテーブルのデータ件数等が大きくなると製造方法を工夫しなければなりません。テーブルのデータ件数が多くなると検索スピードが遅くなるからです。
　ただ、ここでは、テーブルのデータ件数が大きくても、小さくても同じ製造方法になるように工夫したいといった目標でした。
　この工夫なのですが、今まで製造したことがなく、かつ、他のシステムでも見たことがありません。しかも、このシステムを脳裏にイメージしようと試みるのですが、ぼんやりと靄がかかったような状態です。
　今までに、システムを作る段階で、靄がかかったような状態だったときはありません。完ぺきにイメージできていれば、システムを作ることは可能ですし、そうでなければシステムを製造することができませんでした。そういう経験からいうと、システムは作れないと言うことになります。

[今まで通りに作ってみる]
　どんなシステムなのか、解説しようと思うのですが、複雑すぎるうえ、自分でもきちんとイメージできていないので、説明できません。
　以上のような状況で、EVEシステム開発当初は今まで通りにデータベース関連まわりを作ってみようと思います。ただ、ある程度システムが成熟してきたら、新データベースにアクセスするメソッドを作り、画面からボタン一つで、新しい構成にデータベースを再編するようにしたいと考えています。

[あとがき]
　最初っから想定しているシステムを製造したほうが、バグがないなんて言う人もいるのですが、頭の中でシュミレーションすると、どうも、作ったから終わりという分けにはいかないようです。作ってみたけれど、速度が出ないといった場合も、新データベースを再構成しなければいけないというタイミングが出てきそうなのです。だから、どっちみちそうなる運命なら、絶対動く感じでデータベースを製造し、その後、再構成するでもありかなって思うようになりました。しかも、今回プログラムはオブジェクト指向で作るので、必要な部分だけ継承して作ることができます。
　これ、いつになるのか分かりませんが、製造が完了し、思ったパフォーマンスが出たら公開し、どんなシステムなのか概要を解説したいと思います。

　では、また！

■プロローグ〜EVE〜　[YouTubeでの稼ぎ方研究室]　2023年8月5日
https://fanblogs.jp/bahamuteve/archive/34/0

　こんにちは！
　ナビゲータのEVEです。

　本日は、2014年から流行しているエモテットというマルウェアについて御紹介します。マルウェアとは、ウイルス、ワーム、トロイの木馬、スパイウェア、アドウェア、ランサムウェアなど聞いたことがある悪意のプログラムの総称です。
　それでは、どんなマルウェアなのでしょうか？情報がIPAから提供されているので、確認してみましょう！

[どんなマルウェア]
　エモテットは、いろいろな使用の方法はあるようですが、多くの場合は、個人の銀行関連の情報、例えば、口座のアカウント情報、クレジットカードに関する情報などを盗聴し、金銭を搾取するために利用しています。2014年から未だに流行している背景には、金銭的なインセンティブとエモテットの技術的な進化があるようです。

[どうやって感染する？]
　感染方法は、ソーシャルエンジニアリングです。主にメールが利用されることが多いようです。IPAで紹介されている方法は、メールに添付されたWordやExcelのマクロを使った感染方法です。ただ、これは一例であり、感染させようと思うなら、メール本文からURLをたどる方法も使用するかもしれませんし、USBなどを使用して感染させるグループもあるかもしれません。これは、あくまで一例なので、ゼロトラストのセキュリティ意識で対応することが大切です。

[感染症状]
　クライアントが感染した場合発見するのは非常に困難らしいです。ただ、以下の症状が現れることがあります。


[対策]
　では、対策については、ChatGPTに解説してもらいましょう！


　ちなみに、IPAからは以下のような対策が提案されています。

　なお、ウイルスソフトを導入していれば安心というわけではなく、そのウイルス対策ソフトを回避するエモテットもあるようです。特に、パターンファイル型のウイルス対策ソフトは発見が遅れる可能性があります。そのため、ChatGPTも指摘している通り、以下のタイプのウイルス対策ソフトの導入が望まれます。


[あとがき]
　対策したから安心なんてことはありません。狙われたら、まず90%以上の確率で感染してしまうと考えた方がいいでしょう？そのため、ChatGPTが指摘するような対策は当然行うとして、感染した場合、どのようなことをするのか事前に決めておくことが大切です。
　加えて、感染後すぐに普及し、業務を再開できるような体制をとることが重要です。

　攻撃者はかなり頭がいいのは分かるのですが、その頭脳・・・。公共の利益に利用してほしいと思うのは私だけではないと思います。

　では、また！

■Emotet（エモテット）の概要(IPA)
https://www.ipa.go.jp/security/emotet/index.html

■Emotet（エモテット）攻撃の手口(IPA)
https://www.ipa.go.jp/security/emotet/attack.html

■Emotet（エモテット）対策(IPA)
https://www.ipa.go.jp/security/emotet/measures.html

　こんにちは！
　ナビゲータのEVEです。

　久しぶりに、ブログの更新が太陽が落ちてからになってしまいました。中小企業経営政策の勉強の仕方にチョット迷いがあったからなのですが、やっと、勉強の方向性が定まりました。明日から、地に足を着いた活動ができそうです。
　それでは、夜も更けてきた本日は、先日X(旧ツイッター)につぶやいた、コンピュータウイルスの記事について調べて見たいと思います。

[ナゾロジーで紹介されていたウイルス]
　『ヤバイ「コンピュータウイルス」5選』ってタイトルだったので、本当にやばいな〜って思ってしまいました。ただ、調べて見ると、紹介していたウイルスは過去のモノで、昨年2023年に流行はなかったようです。
　紹介されていたウイルスは、下記の通りです。それと同時に、流行した年を入れておきました。

確かにやばそうなウイルスではあるのですが、防御する技術者も学習し、昨年2023年には感染報告はありません。しかも、ほとんどのウイルスはプラットフォームに依存するものばかりなので、対策したことにより消えたのと同時に、そのプラットフォーム自体も経年により消失し、そして、ウイルスがなくなったといった感じです。

[調べ終えて]
　調べ終えての感想ですが、『ヤバイ「コンピュータウイルス」5選』って記事なのですが書くネタがなくってアップロードした記事かなって感じです。
　記事の公開日は、2024.01.02 TUESDAYなので、多分そうでしょう？タイトルを見てドキドキしてしまいましたが、ドキドキするほどのモノではなかったようです。
　このウイルスが感染していたころは、システムは動けばいいと言ったもので、セキュリティまで考えてシステムは製造していませんでした。
　ただ、今振り返ると、2000年に入った直後だと思います。あるお客さまのところに行って、セキュリティについて聞かれたとき。セキュリティは現在使用しているフレームワークが保証していますと言った記憶があります。確かに仕事をする建前上そう言わざるを得なかったのですが、今から考えると、そのプラットフォームも怪しいところがいくつかありました。ただ、そのあやしさを当時の自分は気づいていなかったような気がします。しかも、当時、Yahooとか、公的機関とかしょっちゅうハッキングされていたので、そういう時代だったのかもしれませんが・・・？

[2023年のはやり]
　2023年にはやったウイルスは一体何だったのでしょうか？


　調べて見るとコンピュータウイルス名として紹介している記事が少ないことに気づきます。ランサムウェアとかいった形で紹介されるウイルスは多いのですが、昨年はウイルス名がニュース記事には、ならなかったようです。

[あとがき]
　以上については、Bingからの情報なのですが、気になるのは、やはり、エモテットです。エモテットは、2014年に登場し、現在も進化し、一昨年から去年まで流行したウイルスです。
　実は、IPAのホームページでも度々見かけます。この機会にどんなウイルスなのか知っていただき、少しでも世間のセキュリティインシデントを減らすお手伝いができればと考えています。なお、本日は、文章が長くなってしまったので、この辺で・・・。

　では、また！

■ヤバイ「コンピュータウイルス」5選(ナゾロジー)
https://nazology.net/archives/119389

　こんにちは！
　ナビゲータのEVEです。

　本日は、HTMLの話です。
　以前、お話ししたとおり、2021年1月28日にHTML5が廃止され、現在、HTML Living Standardに移行しています。ただ、2023年11月30日のブログには、デファクトスタンダードだったものが、デジュリスタンダードになっただけなのでは？ット言う話をしています。なお、デジュリスタンダードという言葉を使用しましたが、W3Cは、民間の非営利団体です。法的な効力はございませんので、この表現が適当かどうか不明です。
　そんな、HTMLなのですが、HTML2.0から利用しています。

[HTMLを初めて利用したとき]
　私が、HTMLを初めて利用したとき、それは、1996年12月25日でした。

　当時、インターネットは従量課金で非常に高価だったのですが、夜中の23時から翌日の7時までは、定額で利用できました。そのため多くの人は、23時以降にインターネットを楽しむのですが、当時、チャットというのが流行っていて、そこで、全国から集まり話をするのが、習慣となっていました。
　私は、当時からプログラミングはできたのですが、ネットワークとか技術的なことは二の次でした。そのため、当時、サーバーの接続するところから始まって、HTMLをアップロードする方法などに苦労しました。そんな技術的なサポートをしてくれたのが、チャット仲間でした。
　HTMLでホームページを作り、サンタクロースのGIF動画をみんなの協力を得てアップロードできたのは本当に嬉しかったです。それが、HTML2でした。

[HTMLの勉強]
　HTMLですが、HTMLタグ辞典を利用しています。

　懐かしいですね！久しぶりに、PDF化した本を見たのですが、Netscape Navigator3.0とかInternet Explorer3.0とか書いてあります。これ、ブラウザですから？Netscape Navigatorなんてい言われてもピンとこない人も近頃は多いのかもしれません。

[HTMLプログラミング時の工夫]
　私が作るサイトでは、以下のような工夫をしています。

�@タグを記述する場合は、必ず一番最初に、開始と終了タグを記述する。
�AHTMLのタグは必ず大文字で記述する。しかし、HTMLの要素については、小文字で記述する。

　�@ですが、複雑な画面などを作る場合、このルールを守っていないと必ず混乱します。当時からブラウザって、賢く勝手にバグを補正して画面を表示してしまいます。だから、HTML的にバグがあっても、エラーになりません。まっ、それは、それでいいのですが、JavaScriptでプログラミングをしようとした場合、タグをエレメントとして認識しないなどの弊害があります。この点は、実は、メーカー側に改善して欲しいと思っている部分です。そんなに、ごりごりとHTMLを書かない人からすると煩わしいと思うかもしれません。そんな人や私のような人のために、厳格にプログラミングしないモードと、厳格にプログラミングするモードを用意してくれればありがたいのですが・・・。
　�Aなのですが、これは、私の製造するプログラム限定なようです。私が、よく利用している、「とほほWWW入門」でも、作っているページはHTMLすべて小文字で製造しています。実は、大文字で作っているサイトはあまり見かけません。
　HTML的には、大文字、小文字は区別しません。そのため、私の場合は、HTMLのタグとその要素を後で一目で見て分かるように、タグは大文字、要素は小文字と分けて入力しています。
　ただ、少数派であるという事に対して、これから問題にならないか、ChatGPTにきいてみました。

　なお、深掘りして、どこの団体が推奨しているのかChatGPTにきいたところ、W3Cだそうです。プログラマとしては、標準のベストプラクティスが小文字だと言われると、EVEシステムでもそうしなくてはいけない気がしてきます。

[あとがき]
　現在、中小企業診断士試験の方に、かかりっきりの状態なので、もうしばらく、どうするのか考えたいと思います。
　ChatGPTは、可読性が上がるとか言っているけれど、タグと要素の記述をそれぞれ、大文字、小文字とした方が読みやすいと思うのは私だけでしょうか？

　では、また！

■開発体勢の変更　〜システム開発研究室〜(2023年11月30日)
https://fanblogs.jp/bahamuteve/archive/407/0

■とほほのWWW入門
https://www.tohoho-web.com/www.htm

　新年あけまして、おめでとうございます。
　ナビゲータのEVEです。

　昨日は、「システムエンジニアが目指す中小企業診断士」から新年のごあいさつと、抱負について書きましたが、本日は、「ゼロからはじめるシステム開発」からです。

[今年の各コンテンツの目標]
　今年の各コンテンツの目標は、以下のように考えています。

�@YouTube
　pro2grammer.comで開発したコンテンツの紹介をしたいです！
�ATwitter
　EVE、EVE2のフォローワーの合計を1,000人以上にしたいです。
�BA8
　「ゼロからはじめるシステム開発」、「システムエンジニアが目指す中小企業診断士」、「システムエンジニアから見た社会」の合計アクセス平均数が、200人を越えるようにしたいです！

　なんとか、達成したいですね！

[システム開発]
　システム開発は、以下のように考えています。

01月　クラスの製造
02月　クラスの製造
03月　Yahooダウンロード処理の製造
04月　クローニングデータ抽出条件登録・修正・削除処理の製造
05月　Yahooデータ抽出処理の製造
06月　クラス関連の見直し
07月　クラス関連の見直し
08月　ユーザ管理システムの製造
09月　権限管理システム製造
10月　メッセージ管理システムの製造
11月　パラメータ管理システムの製造
12月　コンテンツ管理システム

製造したい、またはしなければならない順番で並べると、以上のような感じになります。　まず、Yahooクローニング関連システムのクラスを製造して、Yahooクローニングシステムを製造します。
　当初話していたとおり、機能毎にプログラムを分割し、後日いろいろなサイトのクローニングが容易になるようにシステムを製造します。
　6、7月には、運用を開始するのですが、開始後システムの問題点を抽出し、クラスの見直しを2ヶ月かけて実施する予定です。
　そして、8月からは、ログインに必要な権限、メッセージ、パラメータ、コンテンツを管理するシステムを製造し、2025年からログインシステムを製造するという流れで考えています。
　製造状況については、適時報告し、最終的な報告は今年の年末に御報告致します。

[あとがき]
　昨年は、年初にたてた目標の多くが達成できました。今年はどうでしょうか？

　今までのやり方を見直しながら、プロジェクトを健全な形で運営できようにがんばります！

　では、また！