昨日のマクロを組み込む時に少し手を加えて汎用性が上がった。

 昨日のバージョンでは絵文字を入れたシートで実行するか、途中でそのシートに移動するかしなければならなかったが、このバージョンでは最初に取り込んでおくので、後でシート間の移動があっても安心。配列を関数の引数にすることを覚えた。

sub main()
Dim numOfer(2) As Integer ‘エラーの数(最終表示のため)
Dim showtxt(2) As String ‘メッセージ内容
Dim sw As Integer ‘メッセージ用
Dim emoji(11, 5) As String ‘メッセージを作る時に使用

‘ どこかでエラーをカウントした結果 numOfer(1) ,numOfer(2) には数字が入っている。
‘ テストのために数字を入れる
numOfer(1) = 3
numOfer(2) = 5

‘絵文字取り込み シートhogeの1,1-11,5 セルに顔文字を入れておく。
Sheets(“hoge”).Select
For i = 1 To 11
For j = 1 To 5
emoji(i, j) = Cells(i, j)
Next j
Next i

  for i = 1 to 2
sw = numOfer(i)
showtxt(i) = getEmoji(sw, emoji())
next i

MsgBox “ERR1:” & numOfer(1) & ” 個 ” & showtxt(1) & vbNewLine & vbNewLine & _
“ERR2:” & numOfer(2) & ” 個 ” & showtxt(2)
end sub

Function getEmoji(sw As Integer, emoji() As String) As String
‘swにはエラーの数が入っている、emoji は配列でメインルーチンの最初にシートから取り込んだもの

Dim mood As Integer ‘どの行を使うかを乱数で決定
Dim retsu As Integer ‘どの列を使うかは残りのエラー数で決める

mood = Rnd * 10 + 1

If sw = 0 Then
retsu = 1
ElseIf sw = 1 Then
retsu = 2
ElseIf sw < 5 Then retsu = 3 ElseIf sw < 9 Then retsu = 4 Else retsu = 5 End If getEmoji = emoji(mood, retsu) End Function

VBA で仕事を楽しく

 引き続きVBAで思いつき。Fanction の使い方マスターしたのでさらにコーディングの生産性が上がった。

 実行の結果、修正すべきエラーが残っていたらダイアログを出すというだけのものだが、それだけでは味気ないのでランダムでメッセージを出すようにしてみた。それ用のワークシートを持っておいて(画面上は非表示)そこからエラー数の大きさによって深刻度を変えるが、同じ数字でも違う顔文字を出すようにしてみた。

 マスタとなるメッセージ(顔文字)の数を増やして種類を増やすことは簡単にできる。ここではセルから直接データをとっているが、見せたくなければ他のファイルから読み込むこともできるだろうし、懐かしのRead data 文でソース内部に持つことも可能だろう(VBAで read data が使えるかは未確認です)。

 これはメインルーチンに組み込むことが前提だが、エラー数によって呼び出されるサブルーチンにすることも可能。そうすれば、エラー数の有無によってメッセージを出すかどうかを振り分ける if は不要。


Sub errMsg()
'
' eswにエラーの数をカウントしておく。
'チェック項目が増えても同じロジックで配列を増やすだけでOK
'
Dim esw(2) As Integer
Dim showtxt(2) As String
Dim sw As Integer

esw(1) = Rnd * 10 + 1 'テスト用
esw(2) = Rnd * 10 + 1 'テスト用

If esw(1) > 0 Or esw(2) > 0 Then
sw = esw(1)
showtxt(1) = getEmoji(sw)

sw = esw(2)
showtxt(2) = getEmoji(sw)

MsgBox "ERR1 " & esw(1) & " 個 " & showtxt(1) & vbNewLine & _
"ERR2 " & esw(2) & " 個 " & showtxt(2)
End If
End Sub

Function getEmoji(sw As Integer) As String
Dim mood As Integer 'どの行を使うかを乱数で決定
Dim retsu As Integer 'どの列を使うかは残りのエラー数で決める

mood = Rnd * 10 + 1

If sw = 0 Then
retsu = 1
ElseIf sw = 1 Then
retsu = 2
ElseIf sw < 5 Then retsu = 3 ElseIf sw < 9 Then retsu = 4 Else retsu = 5 End If getEmoji = Cells(mood, retsu).Value End Function

VBAでサビ残を減らせ!

今週書いたVBAは決定的だった。これまでシステムが作ったプログラムで時間がかかった作業を秒単位にできた。

 そのプログラムは、2年前まで使っていたPCでは10分近くかかり、そのPCの晩年には起動すらできなくなっていた。2年前に更新された i5 モバイルでも5分近くかかった。

 基幹システムのプログラムが5分かかるのはそれほど珍しいことではない。月に一回や決算期毎に一回動かすプログラムが5分かかっても痛くも痒くもない。このプログラムの困った所は、まいつき何回もやらなければならないことだ。このプログラムは更新結果のチェックを行なうもので、元のパラメータを触った結果をチェックする時に必要なのだ。「パラメータ修正>更新>結果のチェック」というサイクルを何回も繰り返さなければならない業務が有った。

 パラメータが分かれば一回でいいが、正しい数値がはっきりしないままに数字を入れ替えて結果を見るという前時代的なことをやらざるを得なかった。そのパラメータは特殊で、その数字を使って計算した結果がそこに影響するというもので、複雑な動きをする。しかも、結果とするものが複数あって、両方の差を同時に収束させなければならない。なので、「そろそろ近づいたから10単位でいくか」という感じで、トライアンドエラーを繰り返さなければならなかったのだ。

 古いPCでやっていた頃には、この作業が長引いて夜中まで残らなければならないことがあった。このプログラムが動かないと結果が分からないので、次の作業が全くできない。これが終わったらパラメータ修正と更新は数分で終わるのにチェックできないので、決算の締め切りというプレッシャーに怯えながらこのプログラムが早く終ることを祈ったものだった。とにかく、ワンサイクルで15分から20分ちかくかかるので、数回試すだけで1時間以上かかった。そして、実際にはこれを延々数十回繰り返したものだった。

 その後、シミュレータをVBAで書いてかなりの時間短縮を達成した。それは、パラメータを正確に出すためのプログラムで、サイクルの回数を激減させることでトータルの時間を大きく減らすことに成功した。相関を数式にして、パラメータをソルバーで割り出すことが可能になった。これによって、試行錯誤の回数はほとんどなくなった。しかし、シミュレーターに読み込んで操作する時間はかからないが、パラメータを手入力し結果を確認するというサイクル自体の時間短縮はできなかった。サイクルの大半がこのプログラムの実行時間だったからだ。(この時点で5〜10時間かかっていた作業が2〜3時間に短縮できた)。

 また、シミュレーターは一回の操作で一つの種類にしか適用できない(複数を同時にやるようにもできるが、表が複雑になりすぎて操作が大変になる)。なので、パラメータ毎に何回もやらなければならなかった。

 そこで、このプログラムのソースを情報システムから入手(社内開発なので)し解析してみた。チェックの条件は簡単で、必要なデータは完結していたのでVBAにしてみた。 i7 + 8GM + SSD + windows7 + office2013 で15秒程度になった。

  8月分の月次で実践投入してトータルの時間がどの程度になるか楽しみだ。おそらく、1時間以内にできるだろう。

Objective-C + Xcode 4 で学ぶ iOS プログラミング入門

 図書館の本は古いので実際のチュートリアルには使えない事がわかったので、Amazon で古本を買ってみた。古本と言っても Xcode 4 なので、今の環境と大きくは違わないだろうと思った。

 iMac に入っていた Xcode は3.2だったので、App store から最新版をダウンロードした。Mountain Lion にしか対応していなかったらという不安があったが、かろうじて Lion でも動いてくれた。Mountain Lion は買ってあるのだが、移行が面倒で放置してあるWWW

 本の内容に沿ってXcodeを動かしてみたが、起動のオプション画面から違う。似たような名前のものを選んでやって進んでいくが、所々で説明と違うところがありタイムロスにつながる。自動で作られるテンプレートが違っているところがある orz…

 しかし、コードを入力してコンパイルした結果が表示されると楽しい。Xcodeには iPhone や iPad のシミュレータがあって、Mac 上で擬似的にコンパイルした結果を実行できる。これも純粋に楽しい。

本:iPhone SDK プログラミング大全

iphoneSDK 図書館で借りてみた。iPhone SDK と Objective-C の解説本。2009 年の本なので、iPad もないしiOS のバージョンも2だから、実際に今の iOS 6 向けのアプリ開発には使えないだろう。が、Objective-C の文法や開発環境については大きくは変わっていないだろうから、イマドキの開発環境をVBA for Excel しか知らない(それも深く使い込んでいるわけではない)元汎用機プログラマには参考になった。

 この本は、CやC++ の経験がある人向けのようだ。C++ の記述との比較で説明される。オブジェクト指向言語についての基礎知識がない人間には少しハードルが高いし、開発できるようにはならないだろう。

 Cobol や BASIC で育った人間には分からない作法が多く戸惑う。cobol の場合は変数の宣言は絶対だ。プログラムの中で一意でなければならない。Data division で宣言したものしか使えない(コンパイルエラー)。だから、サブルーチンの中で変数を宣言したり、ましてそれが異なるサブルーチンで同じ変数名が使われているなどというのは想像できなかった。後、変数の宣言と代入をひとつのステートメントでやるというのも、自分には読みにくかった。自分は、Cobol の癖で、VBA を書くときも、Dim は最初に置いている。途中で宣言することはしないし、いわば全てがグローバル変数みたいな使い方しかしていない。これは、汎用機のように固定長のテキストや数字のデータのやりとりしかしない場合にはいいかもしれないが、ひょっとしたら数百メガのムービーファイルとかを扱わなければならないかもしれないようなアプリには使えない。また、容量を確保できたとしても、データが予想より少ない場合には無駄だろう。動的にメモリを割り当てたり開放したりということが、特にモバイルでは重要だろうから、このような使い方を覚えるしかないのだろう。

 後、この本はオブジェクト指向についての解説はない。オブジェクトの意味やインスタンス、プロトコルの使い方は書いてあるが、「なぜそこで、インスタンスのメソッドなのか、オブジェクトのメソッドなのか」といった疑問には答えてくれない。

 ただ、ソースを見た時に「こういうことが書いてあんねんな」とは思えるようにはなった。買っていたら後悔必至だが、図書館で借りたのでオーライ。

本:iPad プログラミングの作法

ipad_prog iPhone アプリを作るスキルを持った人が iPad に向き合う時に読む本だった。つまり、自分には「猫に小判」だった。

 iPad が発売された当時に書かれた本なので、その後の iOS の変化によって意味がなくなったり変わったりしている部分も多いように見受けられた。

 iPhone の画面は 3 種類(旧 iPhone、iPhone 5、iPad)しか無かった。iPhone 3GS 以前と iPhone 4 は解像度は違うがアスペクト比は一緒でターゲットの大きさも変わらなかったし、iPad と iPad retina も同様の関係。また、iPad mini は iPadやiPad 2 と同じ解像度だ。ところが、iPhone 5 の投入と、恐らく来るであろう iPad mini Retina によって更に異なる解像度が必要になるだろう。

 これは、開発者に新たな負担とチャンスをもたらすだろう。いち早く対応したアプリはユーザを獲得できるかもしれないが、そのためにはその画面に最適化した UI を作らなければならない。

 iPhone SDK プログラミング大全よりは新しいので、同書にはなかった iPad と iPhone アプリの作り分けや iPad にのみある機能(その後 iPhone も対応したと思われるが)などの説明もあって、「ああ、ユニバーサルアプリを作りこむのは大変だ」ということがわかった。

 とにかく、2年前以前のものは使いものにならないことがわかった。それを、図書館で借りて確認できたので助かった。一冊あたりが高価なものが多いので、チョイスのミスは痛いから余計だ。

VBA 懐かしのロジック cobol 的

vba

VBAはオブジェクト指向の言語だが、使い方は Cobol そのものというマクロを組んだ。

 ソートしたリストデータを読み込んでキー項目が同じデータの計をとるというものだ。実に懐かしい。Cobol で作ったプログラムの大半はこのロジックだったと言っても過言ではない。入力・更新・検索プログラムを除くと、企業で使われるプログラムの大半がこのロジックといっても過言ではないだろう。

 Excelならピボットテーブルの方が柔軟性もあって、条件を色々変えられて便利だが、条件がフラットでない表を作ろうとすると急激に面倒になる。そして、物理的な制約やその表を見る人間の好みに合わせる必要が、大人の世界には、ある。

 自分などは「こんな資料をもらうよりデータをくれ」と思うけど、そうでない人間が会社の意思決定をしているのが現実だ。そんな、何な管理職が喜ぶ資料もVBAなら簡単。何の汎用性もなうんこコードでスイスイと小計、中計・・・嗚呼、懐かしい。

 VBAならいちいちコンパイルしなくても文法チェックができるし、変数の内容も同的に分かる。こんな環境が昔あったら開発効率は倍以上だっただろうな・・・

VBA 開発は続くよどこまでも

 「VBA に夢中www Excel から IE を介して情報収集(サンプルコード付)」以降にも引き続きVBAを書いている。

 今日は、特定のフォルダのファイル名を取得し、そのファイルから別のフォルダに一括でファイル名を変更しながらコピーするというマクロを組んだ。ついでに、ファイル名のリストを使って、複数のファイルの任意の指定したセルに任意のデータを書き込むマクロもセットした。

 「そんなもん、何に使うねん?」と思うかもしれないが、企業の事務職なら分かるはずだ。派遣さんの得意技に、「前月(期)に作ったフォルダをコピーしてファイル名だけ変えて翌月(期)の作業ファイルにする」というものがある。過去のファイルを残しながら、数字だけを入れ替えれば今期の資料ができるというメリットが有る。ルーチンワーク主体の業務では合理的ではある(弊害もあるが)。

 で、経理としては決算資料がその典型例となる。そして、作る資料の数も多い。フォルダを複製、一つ一つのファイル名を変更、一つ一つのファイルを開いてヘッダ要素(”2013年度9月” とか “第2四半期” など)を手作業でやっていた。時間もかかるし何より何も価値を生み出さない機械的な作業だ。そう、「機械的な作業」。これこそVBAの最も得意とするところだ。

 さらに、この作業の効率を上げるために、対象となるファイルの年月や期といった要素を全て同じセルから取り出すように作り替えた。定型化されたワークシートならこの作業は不要だが、微妙に異なるフォーマットを使っているので、オフセット化するのだ(このやり方はワークシートのパラメータを扱う際にも有効)。

 これで、1~2時間かかっていた作業が数秒になった。しかも、入力忘れは皆無だ。本当に人間が判断して入力しなければならない箇所に集中できる。

VBA に夢中www Excel から IE を介して情報収集(サンプルコード付)

iPhone や Android の開発は敷居が高い。敷居が高い上に使い道がないからやる気も出ない。かといって、人に使ってもらえるようなものも思いつかない・・・

 そんな、プログラムしたい情熱を叩きつける相手が最近は VBA(Excel)だ。Web にある情報とオンラインヘルプだけでやっているので、簡単なことに躓くことがあるが、基本的なテクニックを使いまわして課題をクリアできると楽しい。今の実行環境(Windows7,8GB,SSD,Core i5 2GHz,Office 2010)でなら1万レコードの集計も1秒もかからない。数万回のループが回っても数秒で終わる。だから、コーディングは分かりやすいことを最優先させる。20年以上前に汎用機でした、実行時の実メモリ使用量域を減らしたり、ロジックのチューニングをしたりといった苦労は全て過去のことだ。

 今回、VBA から IE を操作するという本を kindle store で見かけて、無理やり用途を見つけて作ってみた。オブジェクトから値を引き出す所に苦労したが、それ以外は従来からのプログラム方で対応できた。

 企業秘密もないし、財産価値もないし、完全に個人で作ったものなので公開する。自由にダウンロードして使っていただきたい。ただし、以下をあらかじめご了解頂いた上での利用に限ります。
・ソースを読んで、中身に変なところがないか確認できる人。
・社内で使うことが前提なのでエラー処理とかちゃんとやっていません。こちらの環境では正しく動きましたが、他の環境で同様に動くか分かりません。
・Yahoo! のファイナンス情報をとってきているので、サイトの仕様が変わったら正常に動かなくなります。
・テストしたのは Windows 7 + Excel2010 です。他の組み合わせで動くかわかりません。

 また、26週間移動平均線をとるための履歴データを多く持つのがめんどくさかったので、2013年4月以降にしか対応していません。過去に遡って自動的に26週間移動平均線を作るマクロも考えられますので、改造してはいかがでしょうか。また、スパンについても月固定ですが、任意の期間を選べるようにしても面白いかもしれません。

 なお、こちらの一連の動画にはお世話になった。このサイトがなければ諦めていたかもしれない。

為替レートグラフ 

BASIC に始まり BASIC に戻る

 今時BASICからプログラムを始める人は少ないかもしれない。が、ポケコンや 8bit パソコンがパソコンの原体験というおっさんたちなら 99% BASIC から入っているはずだ。更に先輩のクラスだと「アセンブラしかなかった」という人がいるかもしれないが。

 当時はパソコン=BASIC実行機 だった。結果的にパソコンを使うことはプログラムをすることと同義だった。今時のOSの環境からは想像もつかないだろうが、アプリというものは BASIC で書いたプログラムのこと以外の何物でもなかった。電源を入れて起動した時に表示されるのはプロンプトだけで、それ自体が既に BASIC のプログラミング環境そのものでインタプリタ実行環境でもあった。この当時にパーソナルコンピュータという言葉を知った世代にはパソコンに対して得体のしれないもの、プログラムが理解できないと使えないものといった感覚が残っていて、「パソコンを使えるのはすごい」につながっているようだ。

 しかし、今はパソコンを使うこととプログラムは完全に切り離され、パソコンを使う際にプログラムを組むことは稀になった。というより、一般人が使うパソコンに開発環境は入っていないことが普通だ。

 自分も、Excel for Macintosh がバージョン4まではマクロを作っていたが、5になって(英語版しかなかった)全く異なった環境(VBA)になったこと、Excelの機能が充実してマクロを使わなくても結果が得られるようになったこと、FMPのスクリプトが強力になったこと等から VBA は習得せず、マクロレコーディングの編集程度しかしていなかった。

 自分のチームに全くプログラムが出来ない人物が配属されたことをきっかけに、マクロを自動化する必要性が生まれた。これまでマクロレコーディングしたものを手で修正して対応していたが、それができなさそうだったから。

 セルの中身の取り出しと書き出し、配列に取り込んでの操作を調べたら、後はロジックだ。業務用のマクロだからユーザーインターフェイスを全く書かなくてもいいので、そこからは芋づる式に開発に取り掛かって、ここ数日はずっとプログラムをやっている。決算期の1営業日を費やしていた資料を数分で終わらせられるようになった。

 iPhoneやwebプログラムのような華々しいものはできないが、ロジックを考えてそれが思うような結果を出すようになると楽しい。他に案件がないかなぁww