頑張りました。
#TATTA
情報Ⅰの試験の配点しないと表明した学校が出てきた。
オワコンだ。
間違いなく他のとこに貴重な人材が流れるだろうな。
それはそれで差別化出来るだろうけど対応無理って言ってたら、いつまで経っても現状維持。
エクセルとアクセスは、例えるなら空港での航空会社全部のシステム部分と、管制や入管業務や税関などの法律等のルールや法則といった環境に近い部分の違いに似ている。
大体の事は、エクセルのように航空会社が接客などの見えるおもてなしでデータ(お客様)に対応しているのに対して、アクセスはほとんどが見えないけれど確実に重要な決まりに則って、事故の起こらないように世界全体を網羅しつつ動いている。
アクセスの入力のチェックなどの動きは、税関業務のようだし、弾かれたらどこにも行けないという動きの点では良く似ている。
現実世界では、どちらも相手の動きを把握しつつ動けて初めて一人前の仕事、安全な仕事が可能になるのだが、エクセルとアクセスは両方を使う者は、その能力に左右されてて安全が保証される。
例えば、エクセルで高速処理したいとすると、大容量のデータを扱う場合だと表示という機能がネックになってしまう。
遅いなと感じたら取り敢えず非表示にするのをお勧めする。
ただ非表示だと動きがイメージしにくいので、パイロットだと計器だけで飛行するぐらい難易度が高くなる。普通は計器だけで飛んでも高速化するわけでも無いが、エクセルは見ないで動かすだけで有り得ない程の高速化が可能なのだ。
特に単純なコピー作業などには、リスクとリターンを考えると一番向いているパターンになる。
アクセスは、ある程度はユーザーフレンドリーな作りになっているが、標準的なSQL互換になってもいるので、入り口は簡単に作ってもチューニングかけて標準SQLに翻訳してゆけばかなり高速化が見込める。
アクセスだけを扱うだけではそのレベルまで中々上がら無いだろうけど、他のSQL言語を扱ってセンスを身に付ければ比較的簡単に高速化も可能だ。
色々とやった上でSQLサーバに変換することも有りだが、シングル動作で良いならアクセスで完結出来る。
年々、バージョンアップする度にエクセルのデータベース機能がアップしてはいるが、スキル的にはアクセスのそれと同系列に有るのでどちらをどれだけ使って作っても構わないがシステム全体では統一して棲み分けた作り方にしないと、後々メンテナンスしづらいだめなシステムになってしまう。
数年前からかなり安定していて各種デバイスでの採用がみられているが、これと言って内容の説明が出来なかったので
空き時間で一冊完読。
あらゆる基礎的技術の総結晶で出来ているブルートゥースだが、目指しているのは規格の安定と性能の向上。
一昔前から省エネに特化した仕様も出てきて、高性能化と省エネ化が混在している。省エネでは、ICチップやら非接触の
使い方をする仕様もブルートゥースとは違うが流通しているので、棲み分けが今後も進みつつ技術の吸収合併が
進みそうだ。
自由度が高くて、技術が成熟しているのはWiFiもそうだが目的とする物の使われ方次第でどれが良いのか選ばれている。
ブルートゥースは、1対1や1対多で接続するが主従関係が周波数やタイミング・プロトコルを決定する主と、それを
受け入れる従とで上手く通信を確立して仕事をこなしている。
一秒間に３２００のサイクルや１６００のサイクルで動き、高速とは言えないけどもデータ量の少ない周辺機器との接続には
かなり使い勝手が良い。データの冗長化も同じデータを３回送ったり、周波数を変えたり電波の形を変えたりで対応していて
安定したデータ伝送を実現している。リアルタイム伝送にも同時相互通信やFMラジオやAMラジオの電波技術を流用たりして
問題なく実現出来ている。
今まで理由が分からなかった、繋がらなないスマートウォッチとデバイスとはアプリ側でシンクロさせないと無理なのが分かった。
逆に時々勝手に繋がってしまう、スマホとノートパソコンも適当なアプリを見つけると面白い事が出来そうに思った。
勉強の合間に、PCビルドシミュレーターやったりしていたが、最新バージョンが出たようで
それも買ってみた。
去年度ぐらいまでデバイスの各種更新かかっているようなのが、目新しい。
あと、赤外線カメラで見たまま温度が計れたり、店に組み立てＰＣを並べられるのが
新しい。
推奨レベルが結構高い感じだが、何とかＬｖ１０までは動かせた。
一番の売りだと思うフリービルドモードが使えるので、それをメインに使ってゆきたい。
前回購入したＰＣはPCBS2ではまだ組み立て検証していないが、過去に目にした構成の
いくつか思いつくまま組み立てて、リアルで散財せずに済むようにしたい。
希望としては、難易度が高くなると思われるノートにも対応してもらいたいが、各メーカーの
独壇場になってしまっているので大人の事情という理由で無理かも？
パソコン工房でカスタマイズしたOSレスパソコンを手に入れて、３日になる。
１日目
とりあえず手元にあったUbuntuを入れてみる。
今まで使っていたUbuntuとはちょっと感触が違った、慣れるのも有りだったがここ１年ほど手に馴染んでいたSparkyを入れてみた。
前回は、USBメモリー起動でインストールした経験があったが、やり方がどうも思い出せないのかうまく行かない。
DVD起動に変更してインストール。容量に余裕が出来ているので名前がゲームオーバと面白いバージョンを選んだのだが、
これ、ゲーム盛り沢山というDVD版だった。ゲーム対応になっているのなら、ゲーム開発も出来るかも？って訳でそのまま使うことに。（３日目のこと）
２日目
結論から言うと、Ubuntuを一度起動HDDなどに入れてしまっていると普通には別のOSをインストール出来ない。
理由は、セキュリティの強化でUEFI側でロックをかけてくれていたので、起動領域の更新がそのままでは無理だった。
一応、古いタイプも選べるBIOSだったのでUEFI機能なしでの起動に変更、これで起動時に数秒だけ長く待たないといけないのだが、これ以外に選択肢は
ないので良しとした。
３日目
そのSparky、日本語化が自動になっていなかった。インストール時に間違えているのかも？だが、ここから設定の変更をやることにした。
どうやら色々とそれらしきものが設定やシステムなどに並んでいる。
「sparky 入力の変更は、セッティングでなくsystemを選べばOK」どんどん変更点が取り込まれて行き使えるところまでになった。
正確には Settings と System のところに同じような名前で選べる項目が羅列しているのだが System で文字入力変更が可能だった。
これで、普通に使える所まではセットアップ出来たので雑誌などではUbuntuを例に上げてやっていることを翻訳しながらSparkyでやってみたい。
カスタマイズしているPCではSparkyの方が向いているように思えるがどうだろう。
使っているPCの状態に合わせたカスタマイズしたOSにアップデートの度になってゆく感が強く出ているような。
毎回、コンパイルの設定を使用PCに合わせてOSやアプリケーションを作り変えているようなので、改造しても好きな設定に変えても
それを分かった上で変化してくれる。痒いところに手が届くOSなのだ。と私は思う。
ちょっと前まで使っていたPCはしばらくはお払い箱になりそうだ。なぜなら新しいPCは、静かで冷たく処理が速い。
クールビューティな美人秘書のよう。
去年の夏は、クーラもない部屋でPCの放熱に悩まされていたが、過冷却というぐらい冷やす構成にしていて今年の夏が楽しみ。
ちなみに、CPU温度は３5度くらいで低体温を通り越しているぐらい低い。
ソフトの性能と言えば、第一に使いやすさが上がるが私のNo.1はMifesで２番はOfficeかな。どちらもWin環境でしか使っていないが外せないソフトになっている。当然、どちらも資格は取っていなくてもエキスパートだと自負している。どこが良いかと言えば、どちらも数通りのアプローチで操作が可能。自動化などはお手の物で、普通にマクロが使えるようになっている。なぜ１番と２番の差がつくかと言えば、私の意見が反映されている割合が高いかどうかだ。Mifesは、今まで何度か意見かクレームか分からない戯言を言ったことがあったのだが、どれも次に出してきたバージョンに反映されていて、ユーザ冥利に尽きると思ったものだ。このどちらも、発売当初からお世話になっているから永い付き合いになる。
個人で購入したり、会社で購入したりと様々な形で関係が続いているが、私の中では伴侶に近い存在になっている。使えて当たり前、阿吽の呼吸といった感じでマニュアルなどは覚え始めの頃は何冊も購入して、マニュアルの間違いが打ち消されるぐらい覚えたものだ。今はほとんどマニュアルの誤植や間違いも見当たらないし役に立つ内容も、一冊あたりひどいものなら数行と少なくなっていて、立ち読みやHelpを読むだけでで十分になってしまっている。良い時代に成ったものだ。
Webや人工知能で調べる手間は少なくなったが、直感で判断する基礎にはなかなかなれない。プログラムを作ることがこれまで何度かあったが、取り敢えずそのアプリケーション関連の機能を一通り覚えて、更にOSやマクロやらで出来ることを覚えて、それぞれの特徴や時間的なコスパなどを勘案した上でプログラムしていた。難しいのが特殊機能で、次のバージョンでは消える運命だったりと覚えても無駄になることがあったりしたが、その辺りはMifesは消えずに発展的消化で解決したりしている点がお気に入りなところだ。
古いバージョンで、全然バグが取れなかったやつでも最新バージョンで実行したらエラーが全く出なくなったりしたことも何度かあった。とても有り難いと思った。
それ以外のアプリケーションも必要なら覚えて使うようにしているが、全てを覚えるのは無理になっている。
師匠から言われていたことだが、「使えるものは使って、それが無いなら自分で創る。」それを座右の銘にしたいなぁ。なかなか今現在、やりたいことが見つかってもアプリケーションで実現不可能な物が無いのが贅沢な悩みになっている。
今まで公開したソフトなどのポリシーとしては、誰も作ったことが無いのは勿論だが、パット見で簡単に見えて使える物といったやつを目指しているので、ゲームなら糞ゲーと言われるのが理想だ。
前回との違い、サスペンションのないタイプに変更。（家族の反対が強かったから
ギアが若干よくなっている。１８段から２４段変速で中ぐらいにいい部品。
フレームサイズを３９０から４６０に上げた。店の方は小さいサイズがかっこいいと推していた。
ギア比がハイギアになった分、速い速度での走行が可能になる。まぁーそんなに飛ばさないけど。。。
サスの分と、タイプ変更で４Kgほど軽量化されているので合わせて体重も落としたいがまだ無理かも。
分割が効いたので、払い終わるまでは寿命を保たせなくては。
画面が、今まで使っていたブラウン管の2倍ほど広くなっているが、繊細な画質だ。
家族はとても喜んで観ている。おじさんありがとう。
昨日、私の作ったコードジャムの練習問題の回答は、数ヶ所のバグが有ったので修正した。
大きな所では、フィールド名のダブリがあったのにも関わらずテーブル名の指定もされていなかった。＜ー修正済
勘違いで、重要な回路設計ルーチンの抜けが有った。＜ー修正済
出力ファイルにつなぐ所で、連係をかけて使うテーブルが大きいかなとも思ったが、新たに１つテーブルを作っても一桁減少で、8割容量アップになる逆転現象が発生するのでそのままにした。
検証はしないつもりだったが、ブログにカキコした以上。製造者の責任も多少はあるだろうと思ったので、Largeは無理でも、Smallはやっておかないとと思った。
決勝は来週土曜だ。前回の終わったといったが、最中と言うのが正解だ。制限時間にも間違いが有ったＳｍａｌｌで4分、Largeで8分だ。
早速、時間の方は直しておこう。
P.S.
ああー。
回路の生成の際に、肝心のキーの処理してないのに気が付いた。うっかりすぎだ。
当然即修正。
忘れるって、ありえないしＯｒｚ。
もう少し、ゆっくり見直さないとおかしなまま放置してしまうとだめだ。コンテストに参加しているつもりで高速作成したのが仇になった様だ。
もう少し、ゆっくり見直さないとおかしなまま放置してしまうとだめだ。コンテストに参加しているつもりで高速作成したのが仇になった様だ。
googleのコードジャムというのが先ほどまで有った。本番の問題をコンテスト中に解くと大問題になるだろうが、今回は数珠繋ぎという練習問題の回答を私なりに考えてみた。ただただ、考えてみた。
次に実行してみようとも思ったが、得意の容量計算をすると現在使用しているPCでは限界を大幅に超えていると思ったので実行は思いとどまった。Small inputのみに対応ならいけるだろうが。。。
おおまかにMySQLでの動作を想定しています。このプログラムの実行に関してと構文エラーなどは例の如く保証はしていません。雰囲気のみで見てください。
<<以下その考えた内容>>
/* 設問の回路を最初に用意するパターンを逆に取って、通電及びONとOFFの状態で回路生成する。人手の再現より手間がかかるパターンだが同様の結果が得られる条件に変更している。条件の一致する時だけ回路を用意する分、シミュレーションの高速化が図れる。(プログラムってこうでないといけない気がする。)
今回の設問以前の大きな条件が高速計算と言う点なので、命題の範囲を超えた考えに変更 これで、全体の回路のパターンテーブルが完成。結果、回路を用意するといった命題も最終的にデータテーブルとして用意してカンストしている。入力を見てからの計算でなくて、全入力パターンを網羅するテーブルを用意してそれから検索する点でスピードが違う。データマイニング若しくは、達観的な手法か?*/
create fanction tc returns integer;
create fanction n returns integer;
create fanction k returns integer;
create fanction @1 returns integer;
create database snapper;
use snapper;
create table snapper (id int,i char(1),s char(1),o char(1),k int,n int);
/* idはsnapper回路の通し番号、iはインプット(通電ありなし),sはスイッチ(On,Off),oはアウトプット(通電ありなし),kとnは設問と同じ。
create table snapper1 (id int,i char(1),s char(1),o char(1),k int,n int);
create table mondai (n int,k int);
create table mondai1 (rownum int,n int,k int);
/* ここからは、回路設計ルーチン */
n1=1;
n_loop: while n1< n+1 do;
/* id=1 の初期化 (k=0)*/
insert snapper select set id=1,i='1',s='0',o='0',k=0,n=n1;
k1=1;
k_loop: while k1 < k +1 do;
/* id>1 の初期化 (k=0)*/
n2=n1;
id_loop: while 1 < n2 do;
insert snapper select set id=n2,i='0',s='0',o='0',k=0,n=n1;
n2=n2-1;
while end id_loop;
/*通電状態の再現(スイッチの状態をここでは保存しているのがミソ)*/
delete from snapper1;
insert snapper1 select snapper2.id,'0',snapper2.s,'0',k1,n from snapper,snapper as snapper2
where snapper.i='0' and snapper.id=snapper2.id-1 and snapper.k = k1 and snapper.n = n or snapper.s='0' and snapper.id=snapper2.id-1 and snapper.k = k1 and snapper.n = n1;
insert snapper1 select snapper2.id,'1','1','1',k1,n from snapper,snapper as snapper2
where snapper.i='1' and snapper.s='1' and snapper2.s='1' and snapper.id=snapper2.id-1 and snapper.k = k1 and snapper.n = n1;
insert snapper1 select snapper2.id,'1','0','0',k1,n from snapper,snapper as snapper2
where snapper.i='1' and snapper.s='1' and snapper2.s='0' and snapper.id=snapper2.id-1 and snapper.k = k1 and snapper.n = n1;
insert snapper select * from snapper1;
/*音に反応した場合の再現(通電可能なスイッチの状態だけ変化させているのがミソ)*/
delete from snapper1;
insert snapper1 select id ,'1','1','1',k1+1,n from snapper where s='0' and i='1' and snapper.k = k1 and snapper.n = n1;
insert snapper1 select id ,'1','0','0',k1+1,n from snapper where s='1' and i='1' and snapper.k = k1 and snapper.n = n1;
insert snapper select * from snapper1;
set k1=k1+1;
while end k_loop;
set n1 = n1 + 1;
while end n_loop;
/*後は、そのパターンテーブルと入力ファイルを連係して答を得るルーチン(実際に計算時間の間に行う処理で、最終行はコマンドラインでは不使用*/
/* input.sql: */
use snapper;
/* ファイル名は適当。当然入力ファイルの場所と名前が入ります。*/
load data infile "/home/my/download/input.dat" into table mondai;
insert mondai1 select @i:=@i+1 as rownum,k,n from (select @i:=-1) as dummy,mondai where mondai.n is not null;
/*以下tc.data出力用の処理*/
select n from mondai limit 1;
/* output.sql:(limit の処理部分は命題通りの動作を再現しているだけで、実稼動では削除OK) */
select "case #"+rownum ,':',case o when 1 then "on" when 0 then "off" from mondai1,snapper where mondai1.k=snapper.k and mondai1.n=snapper.n limit 2,tc;
/* select "case #"+rownum ,':',case o when 1 then "on" when 0 then "off" from mondai1,snapper where mondai1.k=snapper.k and mondai1.n=snapper.n; */
/* コマンドラインから実行 tcはトータル行数の数このプログラムの実際の計算には使わない */
mysql < input.sql > tc.data
mysql < output.sql > output.txt
/* output.txt をupしたら完了 */
/* 注意:設問のデータ量上限のパターンを実際に実行するにはテーブルの容量が少なくとも16GBほど必要(減らす方法もあるがここでは書かない)。メモリー32GBほどをラムディスクの設定にしてあれば余裕で計算出来ると思う。回答の制限時間Ｓｍａｌｌで４分、Ｌａｒｇｅ8分だが、これなら実際の計算では無いのでmaxの5000件だったとしても3秒も掛からないやり方になる。(反則?)。時間やコストを無視するとHDDに書きこんで出来る。しかしHDDをクラッシュする確率も高く検証はする予定なし。(特にdelete処理の部分が心配)*/
/* snapperテーブル 回路データ推移の例 n=<3、k=<8
1,"1","0","0",0,1 snapper回路1つで処理開始時のsnapper回路1の状態
1,"1","1","1",1,1 snapper回路1つで処理開始後1度音が鳴った時のsnapper回路1の状態
1,"1","0","0",2,1 snapper回路1つで処理開始後2度音が鳴った時のsnapper回路1の状態
1,"1","1","1",3,1 snapper回路1つで処理開始後3度音が鳴った時のsnapper回路1の状態
.
.
1,"1","0","0",0,2 snapper回路2つで処理開始時のsnapper回路1の状態
1,"1","1","1",1,2 snapper回路2つで処理開始後1度音が鳴った時のsnapper回路1の状態
1,"1","0","0",2,2 snapper回路2つで処理開始後2度音が鳴った時のsnapper回路1の状態
1,"1","1","1",3,2 snapper回路2つで処理開始後3度音が鳴った時のsnapper回路1の状態
1,"1","0","0",4,2 snapper回路2つで処理開始後4度音が鳴った時のsnapper回路1の状態
1,"1","1","1",5,2 snapper回路2つで処理開始後5度音が鳴った時のsnapper回路1の状態
1,"1","0","0",6,2 snapper回路2つで処理開始後6度音が鳴った時のsnapper回路1の状態
1,"1","1","1",7,2 snapper回路2つで処理開始後7度音が鳴った時のsnapper回路1の状態
1,"1","0","0",8,2 snapper回路2つで処理開始後8度音が鳴った時のsnapper回路1の状態
.
.
2,"0","0","0",0,2 snapper回路2つで処理開始時のsnapper回路2の状態
2,"1","0","0",1,2 snapper回路2つで処理開始後1度音が鳴った時のsnapper回路2の状態
2,"0","1","0",2,2 snapper回路2つで処理開始後2度音が鳴った時のsnapper回路2の状態
2,"1","1","1",3,2 snapper回路2つで処理開始後3度音が鳴った時のsnapper回路2の状態
2,"0","0","0",4,2 snapper回路2つで処理開始後4度音が鳴った時のsnapper回路2の状態
2,"1","0","0",5,2 snapper回路2つで処理開始後5度音が鳴った時のsnapper回路2の状態
2,"0","1","0",6,2 snapper回路2つで処理開始後6度音が鳴った時のsnapper回路2の状態
2,"1","1","1",7,2 snapper回路2つで処理開始後7度音が鳴った時のsnapper回路2の状態
2,"0","0","0",8,2 snapper回路2つで処理開始後8度音が鳴った時のsnapper回路2の状態
.
3,"0","0","0",2,3 snapper回路3つで処理開始後2度音が鳴った時のsnapper回路3の状態
3,"1","0","0",3,3 snapper回路3つで処理開始後3度音が鳴った時のsnapper回路3の状態
3,"0","1","0",4,3 snapper回路3つで処理開始後4度音が鳴った時のsnapper回路3の状態
3,"0","1","0",5,3 snapper回路3つで処理開始後5度音が鳴った時のsnapper回路3の状態
3,"0","1","0",6,3 snapper回路3つで処理開始後6度音が鳴った時のsnapper回路3の状態
3,"1","1","1",7,3 snapper回路3つで処理開始後7度音が鳴った時のsnapper回路3の状態
3,"0","0","0",8,3 snapper回路3つで処理開始後8度音が鳴った時のsnapper回路3の状態
.
*/
UbuntuのアップデートでQtのドライバを複数更新した。あまりQtを知らないので、調べることにした。
知ってると言うのを合わせるとかなりの数になるが、Ｌｉｎｕｘのアプリケーションは覚えているのが偏っているのでそろそろ全般的に動きが分かるようになりたいと、常々考えていることもある。
データベースは、そもそもDOSの頃からやっていてその頃はカード式のデータベースが多かった中、主流になりつつ有った、dBASEやクイックシルバーを使って動作を覚えていた。
その後、システム開発の部門に配属になってコボルやらを覚える傍ら、SQLも覚えた。なんで覚えようかと思ったかと言うと、一番マニュアルが薄かったからって言うのが理由だ。それまでは、SQLってデータベースの一種？と言うぐらいしか分かっていなかったのだ。
覚えるのに時間はかからないかと思ったのが間違いだと気がついたのは、1年ほど経ってからだった。
確かにマニュアルは薄いけど、最適化や正規化など覚えることや経験を積まないと難しいパターンが多すぎるのは、他の言語には見られない特徴だ。
SQLだけで動かそうと思っても無理が多いし、他の言語やそのシステム全体を知って組み合わせないとダメだと1年かかって理解したのだった。だが、それらの環境を網羅した知識を生かしたら、最強の武器になるのも分かった。
システム開発では、覚えたてと言うことも有ってSQLを実際の現場では使えなかったが、コボルなどでは開発をしていた。
当時は、コンピュータ室と言う所だったが開発よりも帳票作成のお手伝いなどが業務の大半を占めていて、開発といってもコンバージョンがその大半の仕事で、新規開発を少々やったぐらいだ。
私が作ったのは、一般業務が楽になるような修正を頻繁にやったので逆に使いにくい物になったかも知れない。
失敗でもないが、一度はシステムを止めてしまうぐらいの事もやったりした。これは、かなり重くて最初は３０分は計算に時間がかかっていた利益計算を、開発担当者が辞めたのをきっかけに私に回ってきたので、すぐにその30分のプログラムを修正して、1分以下で動くようにしたのだ。その反動で、それでなくても重かったこのプログラムの影響はでかくて、システム全体が止まってしまった。
思うに、コンピュータの力量と私の扱った事案のバランスが悪かっただけの話だろう。そもそも企画の時点で気が付くべき物だ。
その解決策としては、デフォルトの優先順位を変更して全体をややゆっくり動かすように変更して、問題のプログラムの優先順位を最後ら辺にしたようだった。
結局、優先順位を下げても10分以下で処理が終了していたので普通に使えるようになった。
私が、今それを扱うなら、同じシステムを使っていたとしてもシステムを止める事もなしに、SQLにプログラムを変更しただけで１０秒ぐらいで実行出来る事だろう。
それから今ではシステムも更新されている効果もある事から、1秒以内という事も有りだと思う。
コンピュータ室の頃も、勉強はしていたが異動になってからの方が更に勉強したようにも思う。
ことデータベースに関しては、手かせ足かせが外れたように勉強した。だってコボルを扱う必要がなくなったんだからやれることって、仕事上ではエクセルを極めるかアクセスを極めるかぐらいしか残っていないからだ。MIFESは、仕事と関係なしに普通に極めていたので、それ以上は必要なかったのだった。ＭＩＦＥＳのバージョンアップ毎に、その差分の知識を増やしてゆくだけだった。
コンピュータ室に入る前からUNIXは扱ったりしていて全然抵抗なしにＬｉｎｕｘが有ったら使ってみようと思った。
一番覚えたピークの頃が２００１年ぐらいで、MySQLをＬｉｎｕｘで扱ってその高速性を楽しんでいた。これといった案件が無かったが、データマイニングに使えるかと倉庫のデータをコツコツMySQLのデータベースに溜め込んだりしていたが、本社でもデータをもっているので元のデータを変換をする方が実は簡単なのだ。練習の為にやっていたと言うのが本音だ。
もしやるならそっちに話をつけてやる方が早いだろう。で、今はそのMySQLのプログラムも止まったままになっている。一応は動くし役に立たせればいいのだが。。。
会社以外でも、友達と携帯のサービスをやってみようかと計画して、一応動くSQLを考えたりもした。
これは、後で分かった事だがほぼ同時に別の所でも開発が行われていたので、買ってもらう所まではいかなかったが、システムの出来はこちらが良かったのが幸いだったと思っている。ことデータベースの扱い方では数倍は良かったのだった。相手方の一番悪い所を言うのもなんだが、「検索結果 なし」と言うのを、間違った検索をしてしまった場合にだが、手間を色々かけさせた最後に表示させるって所だ。私の作ったSQLでは、検索対象は検索可能な項目のみを表示して選ばせて、その結果のみ表示という方法だったので、携帯のパケット代の節約や操作時間の点でも便利な物だった。
システムを入れ替えてもらうって所まで強引にやってたら変わっていたかも知れないが、契約の早かった相手を立ててこっちは引いたのだった。
今では携帯のサービスも色々と出ているが、あの時に押しが強かったりタイミングが良かったらデビューしていたかもって時々思う。
同時にその時覚えたのが、LAMPという便利な組み合わせでＬｉｎｕｘ＋Ａｐａｃｈｅ（ｈｔｔｐｄ）＋MySQL＋PHPというものだ・
LAMPはサーバサイドのデータベース＋Ｗｅｂサービスで、検索やメニューなどにデータを表示して選択させられるものだ。
ネット通販や、ちょっとした辞書のサイトでは良く使われているのがLAMPのようです。
PHPは、動的なホームページが簡単に作れるのが長所で、フレームを使ったりすると出力毎に微調整の必要がほとんどなくなる便利なものです。
PHPからデータベースを呼んで、データの出し入れをして一般ユーザには直接データベースを触らせない点でセキュリティ上も優秀なものです。当然SQLインジェクションなどの対策を取ったという前提での話ですが。
MySQLは、対応するOSや扱えるプログラム言語が豊富だったので、私が扱っていたその当時は最速などと言われていました。方言もほとんど無くて、コマンドや動きもシンプルに見えたものです。
当時のアクセスとの比較に自作のベンチマークを動かして処理時間の比較したところ、当然ウインドウズ上での比較になりますが、MySQLはアクセスの１０倍は速く処理が終わっていました。それをＬｉｎｕｘに移植したら、更にMySQLのOS間の比較で数倍はＬｉｎｕｘの方がウインドウズより速かったです。これで、やるなら当然LAMPかなって気持ちになってました。
安い、速い、簡単と3拍子揃っているのがLAMPなんです。
今まででも、PCの生きていて余っているものが有ったらそれをサーバに変更して、LAMPを動かしたりしているけど、現在余っているPCは一台もないのでやってない。もうすぐこどものPCが戻ってくる予定なので、又、LAMPを練習がてらやってみたいと思う。
サーバは、NEC PCー９８の頃にＦｒｅｅＢＳＤでやり始めてから、ＬｉｎｕｘにしたりＦｒｅｅＢＳＤやその他のBSDにしたり試行錯誤しつつ、Ｄｏｓ/V互換機になってからは、ＬｉｎｕｘでもＶｉｎｅやその頃無料版もあったＲｅｄｈａｔを使い、ここ5年ほどはCDブートのＬｉｎｕｘをインストールする事が多かったです。簡単にインストール出来るのが最大の魅力なので、インストールしては試していました。他には時々ＦｅｄｏｒａやＶｉｎｅも入れたものです。
Ｕｂｕｎｔｕに出会ってからは、これを使うことが多くなって今ではウインドウズよりＵｂｕｎｔｕを使う時間が多いです。その関係で、大元のDebian GNU/Linux を使ったりしました。これまで使わなかったのは巨大過ぎて自分の持っていたPCや取れる時間的余裕がない人には向いていないと思ったのが理由です。
現在11.04を使っているが11.10の方が良さそうに思うのでPCを買い換えたらそちらを入れたいと思っています。Ｌｉｎｕｘのカーネル３番台も使ってみたい。当然だが、次号機は６４ビットを購入するだろう。メモリーも今の倍以上にして、グラフィック性能はスペックしか見ていないが3倍ぐらい上がるだろうと思う。楽しみだ。
それまでは、戻ったPCにLAMPやら入れて楽しもうと思う。
話は戻るがQtも覚えておくとしよう。
調べると、C＋＋で作られた総合環境でクロスプラットフォームになっているそうだ。一番後発なので馴染みが少なかったがKDEなどもこれで作られているようなので、応用範囲は広そうだ。
ＵｂｕｎｔｕでKDEが標準インストールからこの頃は外されたが、綺麗で便利なデスクトップ環境を作りたいならやはりKDEがいいので、覚えていて損はないかなぁ。
今、標準のＧＮＯＭＥを使っていてそこでQt SDKを実行してみたが、他のIDEなどよりちょっと軽いような感じに思った。これは、モジュールの追加をほとんどやっていないからだと思う。KDEに変更したりしてやってみるとまた違った感じになるでしょう。
LINUXにインストールしたがウインドウズにも入れて、そっちでエディターの変更などやってみて使い方をマスターしようかなと考えてます。
予告通りに、フォームの作り方について書きたかったが、レポートの機能と被る所が多いと思ったので、今回はフォームとレポートについてカキコ。
アクセスのフォームやレポートは、デザイン的にはエクセルやワードのテキストボックスやVBの画面設計・印刷設計に近いものだ。
直接テーブルやクエリーをデータとして扱える点で簡単なのが特徴で、ウイザードを使うとある程度は使えるデータベースのフォームが簡単に作れる。
ちょっと凝ったものでもフォームのウイザードでは対応しているが、それを開いた時や閉じた時のタイミングで各種クエリーを実行したら、後で見てもデータの流れが掴み易い。データを編集したとして、そのデータのチェックをデータのフォームを閉じる時にやったり、キーを付け補足説明を読み込んだりするのをこの開いた時や、閉じた時にやると入力中の待ちは少なくてストレスなく使えるフォームになる。
どうしても必要な場合には、ボタンを押して更新とか追加や削除をする方がいいが、自動更新をやたらと使うなら変なタイミングで更新されたりして、制御が難しいかもだ。
他に、画面に出しているデータと画面の中に隠しデータとして持っているデータがあって、それを上手く使うことで新たにテーブルを開いたり、編集に使ったりしなくても途中計算や変換を簡単に出来るので、関数などでは複雑になる計算、わざわざテーブル作りたくない処理などの応用が利く。
例えば、表示されているデータの集計作業。これをテーブルに書きだして、集計クエリーで計算して、フォームに呼び出すというパターンが有ったとしよう。同様の計算結果を得るにはフォームの隠しデータに集計関数を入れて集計して、結果を表示にすると、テーブルやクエリーの更新タイミングを考慮しないくて済む簡便なフォームに出来る。一種の表計算を使っている様な見た目は簡単に出来るのだ。（作る場合も表計算のやり方と同じになるので、その点で簡単とは言えないが。。。）
そういったちょっとした計算作業等に、隠しデータはすごく向いている。
フォームに出来る操作のうち、入力以外の操作はレポート上でも一応は出来る。
見せるだけのパターンだとプレビューでレポートを見せるほうが、出力範囲を細かい調整なしに大きな範囲で取ったり出来るし、表示の大きさなどはその都度、自由に変えられるので、どっちがいいかは吟味して使うと使いやすいと思う。
先ほどレポートでは出来ないといった入力も例えば選択クエリーの一種であるパラメータクエリーを組み合わせると、その弱点を補える動作可能だ。
私の変わった使い方をしているレポートのパターンとしては、期首データのみパラメータクエリーで渡して、その後の計算と、元データはデータベース内の各種テーブル・クエリーから貰って表計算のような集計作業で当日の生産量と使用量を縦に算出し、翌日残を求めてというルーチンを一日毎で一ヶ月分を1つの表にしたものを作った。
これは、中間原料の日々の増減に使えたが、中間原料の生産量とその使用量の追っかけデータを並列に並べて同日の増減を求めて翌日の計算に繋いでいるだけなのだが、複数のデータを平行して見ないと作れないのでエクセルには難しいかと思いアクセスで作った。
生産量が増減する関係で、レポート出力を使うとデータの増減に合わせて表の行数が自動変動する関係で、意識しなくても綺麗な出力になる。
当然、計算もレポート上で出来るので、集計も楽に出来て見易い表になった。
他に、フォームではプルダウンメニューも、ウイザードでなら簡易テーブルをフォーム内に作る、データボックス。件数が限られている場合や、少数だが固定データが必要な場合に使いやすい。
隠すというと、テーブルやクエリーなどで隠して置いた方が都合がいい物。例えば、削除不可にしたい時や、開発中のみ必要なテーブルをテーブル作成クエリーで作った場合など、一旦作ってしまえば消してもいいが残しておくと参考資料になるような場合、プロパティの表示を隠すのチェックを入れると、簡単に隠すことが出来る。
他には、自分でSQLを空で書いても何とかなるが、ちょっと複雑でデザインモードなどを使ったら簡単に出来る場合、デザインモードで書いてからそれをSQLで開き直し、微妙な調整をした後（これが無ければ、言うことないソフトなのだが。。。）コピーして、モジュールやマクロに組み込む。その後、使ったクエリーの表示を消す。といった作業の流れでやると、後々見ても分かりやすいデータベースになる。モジュールのコメント欄に参照元クエリーなどを書き込んで置くと、更に分り易くなる。
早い話が、アクセスの自動作成のSQLはそのままでは使えないと言うこと。ちょっと便利だが、悪く言えば言葉を覚えたてのこどもにSQLを作らせているような基本機能のみで、癖が強くて使用者の用途とは違う動きに勘違いしているSQLコーディングを自信を持って作ってこられても困るのだ。
自動のフォームも、無駄に罫線が入ったり表示位置の見栄えが悪かったり、結局は修正が入らないと使えないと思う。
一通りはフォームやレポートを手動で作る事も出来ないと、この自動作成機能は使いこなし出来ないかと思う。
フォームとレポートの話では、さすがにアクセス専用の説明に偏ってしまうが、それ以外のデータベースでのやり方は守備範囲や私の少ない知識では説明出来ないので、そちらは他に譲る。アクセスの説明でも趣味の色が出ている。それを他のデーターベースでやると、さらに軸がブレてしまってまとまらないのが見て取れるので今回は外しました。一通りは扱えるぐらいは理解しているのが私です。
このデータベースの話を通して言えることは、淡い期待でアクセスを使い始められると、すぐに裏切られるようなると思う。アクセスは汎用性を重視して作られているソフトと割り切って使って欲しいです。汎用性を重視すると、どうしても余分な処理や機能が付属してしまって、見ても分かり難くなる傾向がある。SQLやフォーム・レポートの肝心な部分を抜き出せるまで、使いこなせたらアクセスも面白いソフトになると思います。
具体的な使い方まで、このブログに入れたらすぐに利用可能な物ったけど、作り方から入るのは珍しいブログになると思ったのでここまで勢いで書きました。
プログラムを作るのに時間が掛かったのが、ちょっとした修正作業。
これがなくても動いただろうけど、見た目も悪いし人に使って貰うのが前提だったので、ちょっとでも見易くしたいというので苦労しました。
プログラムの修正などでもMIFESを使って、データの修正や書き込みを何度もアクセスの編集画面と往復して仕上げたりしていたので、MIFESが無かったらと思うとゾッとします。
テーブル名を一括変換して、別のクエリーに使ったり。フィールド名の変更を間違いなく全て一字一句を完璧にやるとか人間業とは思えない作業もMIFESを使えばストレスなく出来ました。
希望を入れると、よそのプログラム作成総合環境のエディターなどでやられている。編集作業をするエディターの指定などが出来たらば、かなり使いやすくなる思う。それは私の使っていたアクセスのバージョンでは無理だったので、ひたすらカットアンドペーストを繰り返していたのを思い出します。
やろうと思えば、エディターの動くメモリーなどのスペースを余分に空けといて、そこで使うデータの共有化をはかるだけの話なので、MSのやる気だけの問題なんだが。
その辺りも汎用化されると、アクセスを好きになる人も出てくると思う。
うかうかしていると、総合環境のデータベース作成機能がアクセスの汎用性を追い越してしまって、使う人が激減するのでは？って門外漢ながらちょっと心配してます。プログラムを専門職でやられるなら、MSのVisual Studioなど使われているだろうけど、私はそこまで専門でもないので、総合環境については良いなぁーてぐらいでまだ使いこなしていないのであしからず。年々、機能が豊富になっていて使いやすくなる総合環境、PCを買い換えたらすぐに試してみたいと思う今日この頃。
アクセスで作ったプログラムの具体的な使い方・作り方は、私の勤務する会社でアクセスのバージョンアップをするタイミングを見て、思い出しながら最新バージョンに合わせてカスタマイズしつつ使い方・作り方を載せる事になると思います。それまでは、このブログの内容に近い物を公開するぐらいになると予定しています。今の所バージョンアップの予定は聞いていないので、いつになるか不明です。
Excelピボットテーブル大事典
調べていたら、良さそうな本も出ていた。
第2版で、去年出ていた。
良くまとまっている様なので、読もうかなぁと思っている。
ピボットテーブルについては、自分なりにバッチリだし会社での使用率ではPC自体を最近意識して使わず、使う時には普通に使いこなしているという状態だ。
周りからは、普段は家でしか使っていない割に上手く使えているなぁーとか思われていることだろう。
自分なりに、PCは極めているので既に道具か体の一部になっているからそんなに意識しなくても使えている。
時々、「そこまで使えるなら仕事を変えたら？」と言ったちょっと羨ましがるような嫌味などを言われることもあるが、私にしたら普段の食事で使っている箸やボールペンなどと大して変わらないぐらいの道具の一つだ。
箸使いが上手いから、グルメレポータになるって人もそういないだろうし、字が上手いからってそれだけで食べていくには、よっぽど上手くないと難しいと思う。
それらと同じような考えで私のPC使いのレベルなら仕事を変えるところまでは行っていないと考えている。
人より余分にＰＣに触って、いろいろと経験つんでとやってきた結果だと思う。
本を読むと、その著者の考えが分かったりするので使えているソフトのマニュアルなどでも進んで読むようにしている。
一昔前なら、各ソフトのマニュアルでも3冊ぐらいは読んでその中の誤植やエッセンスは全て理解するようにしていたが、最近の本は誤植もかなり減っていて、1冊読むだけでも十分理解できたりするので、こちらも著者の方々の上手なPC利用のお陰かなぁーなどと考えたりしている。