さて何か作ろう

データベースにXMLを使ったプロジェクト管理プログラムをC++でフリーのWindowsプログラミング環境で作ってみようと思い、いろいろ試したがXercesのビルドに辿り着くまですごく大変だった。

ちなみにプラットフォームは Windows 7 の64bit。

どなたかの役に立つかわからないけど、覚え書き。とりあえず自己責任で、真似して何かあっても責任はとれません。

必要なソフト

  1. Dev-C++(コンパイラ無し)
    Dev-Cpp 5.11 No Compiler Setup.exe

    適当に、お好きなようにインストール。

  2. MinGW64
    mingw-w64-install.exe

    インストールパスに半角スペースがあると、後でやっかいなことになるので、半角スペースの無い箇所へインストール。インストールパスをC:\mingw64 としたら C:\mingw64\mingw64がルートになるけど、それでOK。

    そのままだと、gmake.exeがないので、C:\mingw64\mingw64\bin\mingw32-make.exeを同じフォルダにコピーしてgmake.exeへリネームすると後で便利。

    C:\mingw64\mingw64\binを環境変数のPATHに追加しておく。

  3. Msys単品
    external-binary-packagesのmsys+7za+wget+svn+git+mercurial+cvs-rev13.7z

    MinGW64のルートに展開すると、パスがC:\mingw64\mingw64\msysになる。
    C:\mingw64\mingw64\msys\etc\fstabでMinGW64を/mingwにマウントしておく。

    ↓こんな感じ
    #Win32_Path    Mount_Point
    C:\mingw64\mingw64    /mingw

    C:\mingw64\mingw64\msys\binを環境変数のPATHに追加しておく。
  4. Xerces
    xerces-c-3.1.2.zip

    ダウンロードして展開して、C:\mingw64\mingw64\msys\msys.batを起動する。
    展開したディレクトリに移動して、何もオプションを指定せず ./configure で、makeができた・・・気がする(うろ覚え)。makeすると数分かかってライブラリ生成完了。

とまあ、こんな感じ。なんか src の下に全部できた・・・。

| | コメント (0) | トラックバック (0)

始まりは HelloWorld

プログラミングの話題。

しばらくC言語に触れていなかったから、C言語のリハビリとC++の勉強中。C++の言語仕様は複雑でとても洗練されている。もっと早くC++を勉強していたら良かった。

JavaでもC++でも、どんなプログラム言語もはじめは Helloworld を標準出力に表示する最も単純なプログラムから地道にコツコツと習得して、全ての言語仕様を把握するまで、とてもとても長い道のりを歩く。今はやっと8割くらい歩いたかな。

設計したシステムや苦労して書いたプログラムがやっと意図したように動くようになったときの達成感や感動は、歳がいくつになっても変わらない。SEになって良かった。

初心に返って頑張ろう。

さて、何を作るか。


| | コメント (0) | トラックバック (0)

Accessのエラー

たいして面白い記事ではないけれど、世の中の同じ現象で困っている人に少しでも役にたったら幸い。

Office 2003の後にVB6とかレジストリが競合するソフトをインストールしたら、レジストリが壊れるようで、そのパソコンだけAccess 2003 VBAからExcellのシートを出力できなくなる事がある。

例えば、CopyFromRecordset 関数でエラーになる。

430 オフィスオートメーションエラー…なんちゃら…かんちゃら…ってエラー。
MSDNで調べたら、VBAの方を修正しろとか…あり得ん…。Microsoftの都合に合わせてプログラム改修しないでしょ。

いろいろ試して、Officeの再インストールしても直らず、諦めていたら、海外の掲示板に似たような記事があって試したら復旧した。

手順は簡単。
MS-DOSコマンドプロンプトで下のコマンドを実行するだけ。レジストリが修正される。

Regsvr32.exe "C:\Program Files\Common Files\Microsoft Shared\DAO\DAO360.DLL"

| | コメント (0) | トラックバック (0)

システムアーキテクト

たまには仕事の事を書いてみる。

今の職場の事とかプロジェクトの事は情報セキュリティ上、ブログには書けないから、資格の話。

いろいろとあって、いつ会社がどうなっても自分だけは食っていけるように、そろそろシステムアーキテクトを真面目に受験する。社長ももう歳だしなぁ・・・。

システムアーキテクトはけっこうな難関資格で、会社が潰れてもこの資格があれば今の年収を下げずに(というか+で)再就職できる。

で、参考書とかAmazonで発注した。来週届く。合格論文の書き方だけで十分だとは思うけど、念のため参考書と過去問解説も発注した。


俺のように客先へ出向・派遣で契約されてシステム開発をしているSEは、小論文のお金関係の項目(システムの開発規模など)が全く書けないのだけれど、「わからない」を選択した時点で読まれないし、絶対に合格しないらしい。

そりゃそうだ。

そんなSEにプロジェクトリーダーやらサブリーダーを任せる奴はいないよな。。。。
資格がもらえるのがおかしい。

安心して仕事を任せられるようなそんなSEになりたいね。

| | コメント (0) | トラックバック (0)

eclipse

eclipse(IBM製のIDE)って便利だな。

ずっとコーディングもコンパイルもライブラリリンクもデバッグもファイルのバージョン管理もUNIXの端末エミュレータで原始的な方法でやってきたから、浦島太郎の気分。

なんで今まで使わなかったのだろう・・・
現地とか何かトラブルがあったとき、どのUNIXにも標準で備わっているエディタは vi だからとか何かそんな理由だった気がするけど、今考えるとクレイジーだ。

ここでちょいと、プログラミングの歴史
http://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0_%28%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%29

たまにおじいちゃんSEの話で聞くけど、1954年にはまだほんとうにパンチカードだったんだなぁ・・・。

この調子で行くと、近い未来にプログラミングという行為自体が無くなる日が来るかも知れない。

誰かが作った部品をより集めてシステムを組み立てるようなイメージだな。

クラウドが近いかな・・・。
あれは部品ではなくてサービスを提供しているからビジネスモデルがちょっと違うけど、出来あいの部品の寄せ集めという点では同じ。

パーツ提供ならサーバ保守とか面倒なことしなくて良いし、仕様書とかソースまるごと売ってしまって保守契約も瑕疵担保期間も無しにしたら個人でもできるなぁ。

| | コメント (0) | トラックバック (0)

標準COBOL

標準COBOL


Amazonレビューも書いたから転記
---ここから----------------------------------
業務でCOBOLを扱うから、一昨日発注して、今朝届いた。
まずそこらへんの本屋の棚にはCOBOLの本なんて並んでないからね・・・。

思っていた以上に分厚い。471ページ。
B5のネットブック(PC)よりちょっと厚いくらいかな。
その代わり、耳の部分っていうのかな。単元毎にインデックスはついているし、1ページあたりの文字数が少なくゆとりはある。よくある2色刷りとか3色刷りではなくて、グレースケールで体裁も見やすい。

他の本にしなくて良かった。

どんな単元も「この命令のそんなオプションは絶対に使わないだろう」と思うところまで細かく載っている。UNIXでmanコマンドを打ったらオンラインマニュアル出てくるでしょ。あれみたいな感じ。

だから、この本に載っている必要な部分だけを自分で抽出して応用できる人にはすごく向いている。そういう人を理工系と呼ぶなら、理工系向けだな。

始めから終わりまでひとつひとつ読む人には向いていないかな。読んだだけで頭に入ったと思ってしまうタイプとか書いてあることを全部覚えないと気がすまないタイプの人。いるよね。もしかしたら、そのタイプの人には必要な事だけを書いてある他の本の方が良いかもしれない。

しかし、これからCOBOLを覚えるような人は他人の書いたプログラムを保守しなければならないから、「自分がコーディングできれば良い」というレベルではいけないな。

他人が書いたソースを見て、わからない字句とかコードが出てきたら、この本があった方が良いね。非常に助かる。

値段相応でまあまあだから星4つ。       
---ここまで----------------------------------

仕事で必要なのだけど、こういう図書はいつも自腹で買う。
理由は、極端な話、会社が潰れても本は自分の手元に残るから。
※IT関係の会社がたちまち潰れる事はけっこうあり得る。うちの会社の場合、情報漏洩事故を出した時点で潰れるかもな。。。

何もかも会社が用意してくれて飼いならされたペットのようなSEにはなりたくないし、それに、会社の経営状態とか会社の将来とか社長からの期待とか・・・俺にとってはほんとどうでも良いのだよね。

会社も俺で駄目なら俺を解雇して他のSEを探せば良い。俺はSEという職に拘らないし、いくらでも仕事を探せる。物創りできる仕事には就きたいけどね。

顧客は俺の技術向上に金を払う必要は無いし、会社や俺の都合なんて知った事ではないから、俺で駄目ならいくらでも他の会社のSEとチェンジすれば良い。

俺は俺、会社は会社、顧客は顧客。

無責任な訳ではなくて、線引きがはっきりしている。
むしろ、「俺で駄目なら他のSEではもっと駄目だろう」くらいな気持ち。

これは個人的な思想で他人に押しつける気はないけれども、SEにとってプログラミング本やプロジェクト管理のノウハウは数ある商売道具のうちのひとつに過ぎなくて、SEには「自分が開発する(している)システム(プログラム)はどんな目的のものなのか」を考えて、「その為にはどんな手段があるのか」を選んで、脱線しないでゴールに進む力が必要だと思う。知識が少なかったら本来なら(他のSEだったら)選べるはずの手段が選べなくなる(手段が減る)。だから自腹で本を買う。

COBOLのプログラムなんてどうでも良くて、今の資産を全てPL/SQLやC言語やJavaで作り直す手段もあったけれど、自分でCOBOLを覚えて改造する手段を選択した。

あれは正しい判断だったと思える日が来ますように。

| | コメント (0) | トラックバック (0)

全ては感動の為に

明日も出勤・・・。最近、毎週末はデフォルトで休日出勤している。。。

俺はCOBOLの開発は未経験なのだけど、山ほどアサインされたようなされないような。。。
「koichiさんできるやつからやっていってよ」みたいなそんな状態。

いやいや、普通、計画を立てるでしょ・・・とは言えないから、とりあえずWBSを作ってみせた。単純な計算で俺が1日に数本コーディングしても、期限までに終わらない。

しかし、俺以外に作業できる人がいないし、誰も俺にCOBOLを教える時間がない。

まるで戦場のようだ。。。いつか援軍が来るのだろうか。。。
期待しない方がいいか。

だいぶ疲れてきた。

乗り切ったときの達成感は計り知れないな。

舞台芸術とかシステム開発とか・・・
大勢で物創りするところは似ているね。

すべては感動のために!

| | コメント (0) | トラックバック (0)

覚え書き

覚え書き(まだ転記中だけど)

http://members.jcom.home.ne.jp/3117216601/memo/tips/tips.xml

携帯のブラウザから見れるかな・・・

| | コメント (0) | トラックバック (0)

ソフトウェアの品質

昨日、ソフトウェア不具合を出して少し凹んだ…というか悔しかった。

他の不具合対応が、二次的な不具合になった。

世の中の多くのSEを悩ませる「複数のプログラムがファイルの取り合いになって固まる…」あの不具合。


知識も経験もあったからそうならないよう自分でも注意していたし、数名でソースコードレビューもしたし、試験もしたけど、防げなかった。

全く知らないところでファイル開いてた…。ありえん…。関数を呼び出す側がそんな外部の事まで考慮しなくてはいけない時点で、設計が貧弱なんだけどね。

設計した奴でてこいや〜
(高田総督?)

あ〜、でもすごく悔しい…。

再発防止策やらソフトウェア品質やらいろいろ言われて、「再発防止できない」とも言いたくないし、「再発防止する」と口先だけのSEのような事も言えず…何も言わず謝るしかなかった。

ごもっともな事なんだけれど、お金も時間も有限で、しかも人間がチェックしている限りなくならない不具合だと思う。

どんな設計資料があっても、そんなものだって人間が更新している訳で、長く保守していく間に信頼性が失われていく。

複数のコンパイル済みプログラムからデッドロックの危険性をチェックできないものだろうか…

| | コメント (0) | トラックバック (0)