社内SEの徒然なる日記

ノンアルコールのビールって、商品だけは昔からあったような気がしますが、最近は味も悪くないなってきて、各メーカーからも商品が販売されるようになってきました。

スーパーのビールコーナーを見ると、ずいぶんと種類があったので、気になって集めてみました。
近所のスーパーとコンビニを数件廻った結果、これだけ揃いました。


ちょっと巡っただけで、９種類ですか・・・

上の２段がメーカー品で、下の１段はPB商品ですかね。
TopValueのバーリアルは明らかにそうですが、左下のCGCのヤツは分かりません。
世辞には疎いし、そもそもビール好きって訳でもないですしね。


たしか、ノンアルコールビールってのが広まる切っ掛けって、この「キリンフリー」だったと思います。


ノンアルコールビールってカテゴリーで、初めてまともに飲める味で仕上げてきたのはコイツでしたね。
外出先でビールを飲みたいけど、車を運転しないといけないので、諦めるって多かったので有り難かったのを覚えています。


現在の私のお気に入りは、この「サッポロ　プレミアム　アルコールフリー」です。


もともと「プレミアム」なんたらっていう種類のビールが好きだったので、それに近い口当たりのコイツがマイヒットでした。


買っといてなんですが、これは避けたいシリーズです。
TOPVALUの「バーリアル」シリーズのノンアルコール版みたいですが、何も２種類も出さなくても良いと思うんですけどね。


この「バーリアル」の普通のヤツ（ノンアルコールじゃないの）ですが、確かに安いのですが、もう二度と買う気がしません。
味は非常にマズいし、なによりも悪酔いします（他の人がどうかと思うか知りませんが）。

最近のビール情勢で、まさかここまで低品質のビールを出してくる所があるとは、夢にも思いませんでしたよ。


次は、CGCの「Zero Clear」です。


近所の、ラッキーっていうスーパーで見かけたのですが、コイツが何者なのかよくわかりません。
ネットで軽く検索してみたのですが、ブログが数件ひっかかっただけで、それらしい商品紹介までたどり着けませんでした（まぁ、本気で調べたわけじゃないですけど）。

ほかのスーパーで見かけないので、きっとマイナーな商品だとは思いますけどね。
ただ、意外と味は（思った程には）悪くなかったです。



最後が、この「プレミアム　アルコールフリー　ブラック」です。


お気に入りの、プレミアムシリーズですが。どうやら黒のアルコールフリーを出したようです。
飲んでみた所、黒ビール独特のサラッとした感覚が感じられて、悪い出来ではないと思えました。


上で個別紹介を省いたヤツもありますけど、どのメーカーも頑張っているのが、ノンアルコールビール自体の味が、ここ数年で急上昇してくれて嬉しいです。

健康のため、運転の都合、などなどの理由で、アルコールは控えたいけど、それらしい飲み物が飲みたいって時に、非常に重宝します。
個人的には、深夜残業に備えてご飯を食べる時に、このノンアルコールビールを飲むのが大好きです。


スポンサードリンク

マック標準のメールソフト「メール」を、Yahooメール、Gmail、iCloudの３つのフリーメールとリンクさせて使用しています。
これ一つで、複数のメールアカウントを確認できるので、とっても便利です。


何でも、もっと使いやすいメールソフトもあるらしいのですが、私はMacでは可能な限り環境を弄らない方針なので、標準ソフトでOKです。
というか、使い勝手が云々というほど、メール使わないだけなんですけどね。

それはそれで良かったのですが、受信したメールを削除してから「メール」を終了しようとすると、ときどき異常終了するようになりました。


発生原因は不明ですが、受信メールを削除してから、間を置かずに終了しようとすると発生する確率が高くなります。
・・・まぁ、おそらくは、リンク先との同期が終わる前に終了させるとダメってことだとは思いますけどね。


まぁ、ソフトウェアが異常終了するなんて、良くある話なのでこの時点ではまったく焦りはありません。
長年Windowsと戦ってきたのは伊達ではないのですよ。

って訳で、Windowsの作法に習って、まずは再起動を行う事にしました。
メニューから、「システム終了」を選択。


んで、「システム終了」です。


ところが、こんなメッセージが表示されて、マックを終了出来ません。


「メールを終了」って言われても、Dockには肝心の「メール」が見当たらないし、「メール」を起動しようとしても起動しない。

うーん、困った。


私も、10年の経歴を持つ社内SEですので、状態の想定は付きます。
ようするに、「メール」終了時に異常終了したために、「メール」が終わりきらずに不正な状態で残ってしまっているってことですよね。

実際、commandキー ＋ tabキーでアプリの切り替えを表示すると、「メール」が出てくるんでよ。
しかし、この状態でメニューから終了しようとしても。


メニューの一番下の「メールを終了」が灰色になっていて選択出来ません。

これがWindowsなら、タスクマネージャーから該当のアプリを強制終了したり、直接プロセスを殺してやれば済むのですが、マックで強制終了する方法が分かりません。
まぁ、分からないなら、分かるようになれば良い話ですね。ちょっと調べたら、簡単に分かりました。

今までは意識していなかったのですが、アップルメニューの真ん中に「強制終了」って項目があるようです。
下がその画像なのですが、「強制終了」ではなく「メールを強制終了」になってます。


画面をキャプチャする時にShiftキーを押さないといけなかったのですが、どうやら、Shiftキーを押してしまうと選択中のアプリを終了するモードに変わってしまうようです。
まぁ、これで終了させても良かったのですが、ここでは「強制終了」を選択した物として続けます。

「強制終了」を選択すると、アプリケーションの強制終了画面が表示されました。



ここまでくれば、Windowsと同じですね。
一覧から「メール」を選択して「強制終了」を押したら、問題なく「メール」が終了してくれました。

これで、マックも再起動できるようになりましたし、メールも起動出来るようになりました。

余談ですが、上の画像に書いてある通りに、commandキー ＋ Optionキー ＋ Escキーからでもきちんと強制終了画面は表示出来ました。
とは言っても、このショートカットを覚えるほど、強制終了が必要なソフトなど使いたくないですけどね。


それにしても、Windowsの切り札である再起動が使えなかった事にはビビりましたね。
もちろん、安全性を考慮した上で、システム終了をキャンセルさせるようにしているのでしょうけど、かえって危険なような気がします。

私の場合は、強制終了の方法がすぐに分かったので良いのですが、分からなかった人や、時間がない人の場合、パソコン自体の電源を切るという手段にでるような気がします（というか社内SEとしての経験では、大体の人はそうします）。

Windowsのように、終了時に終わらせられないアプリがある場合に、強制的に終了させるようにした方が、トータルで見ると安全な気もするのですが・・・
まぁ、Windowsのように、強制終了が前提みたいなOSってのも考えものですけどね。

私見ですが、Macの場合、「×」でアプリが終了しないって作法と関係あるのではないかと睨んでいます。
「×」では見た目上は終了するけど、実際にはソフトは起動したまま（再起動しても）なので、システム終了時には、アプリ側に対して何らかの退避処理のようなものが実行される。そう想定すると、アプリ側に不整合がある場合にシステム終了を許さないって考え方も、理解できなくはないんですよね。

まぁ、さすがにサポートに問い合わせても答えてくれないでしょうから、真相は分かりませんが。


いやいや、意外と手こずりました。
何よりヤバかったのは、発生したのが夜中で、寝ようとした時だったって事です。

もう寝たいってのに、こんなトラブルが起きて、頭抱えました。
システムトラブルの対応なんて、仕事以外じゃしたくないんですけどね。


スポンサードリンク

ウィスキーの炭酸割り。とっても美味しいですよね。
時々作るのですが、いつも困るのは炭酸が余ってしまう事です。

500mlのペットボトルで売っているのを使用するのですが、それほどお酒に強いわけではないので、炭酸が半分くらい余ります。
そして、翌日には炭酸が抜けて、ただの苦い水になってしまっています。

と言うわけで、炭酸の抜けを防止してくれるキャップを調達しました。


ペットボトルの上の黄色いヤツが、そのキャップです。
ペットボトルのフタの代わりになっていて、黄色い風船みたいなの押す事で、ペットボトル内部の圧力を高めて炭酸の抜けを防止してくれるらしいです。


締める時は、単純にキャップ代わりに締めれば良いのですが、開ける時は、手順があるようです。

こんな感じで、親指で白いプラスチックの部分を押してやります。


ペットボトル内部の圧が解放されて、スパっていう鋭い音を立ててふたが開きます。



んで、肝心の炭酸なのですが、まぁ、ないよりはましって所ですかね？
少なくとも、抜ける量は減ったような気がします。

いずれにせよ、封を開ける前の状態を維持してくれってのは望み過ぎでしょうし、こんなところでしょうね。


スポンサードリンク

前回、仕訳が未確定って話を書いたのですが、通常の発生時と決済時の仕訳についてはブレないようなので、これだけは実装可能ですね。

という訳で、基幹システムで作成する仕訳に新しく発生する科目「電子記録債権」の勘定科目コードが必要になってきます。
私、勘定科目コードって、どっかの機関が定めた共通で使用するコードがあるって思っていたんですけど、そんなことないんですね。

一生懸命調べた（いや、ググっただけですけど）結果、分ったのはそれだけでした。
せめて、会計ソフトの販売元が推奨するコードとかあると楽だったのですが。

そういえば、学生時代に簿記の勉強をしていたのですが、その時の授業でも、コードって概念は教わらなかった気がします（もう10年以上前なので、うろ覚えですが）。


ってことで、発生する科目について、経理担当者に作成をお願いしました。
なんでも、コード自体はなんでも良くても、並びとかの関係があるので、まったく好きにして良いってわけでも無いようです。

少し時間が掛かる（社内の手続きとかもあるらしい）らしいので、とりあえず適当なコードで作成しておいて、確定後に正式の設定することにしますかね。

．．．こうやって余裕を見せてると、本番リリース時に修正を忘れて障害が発生！って事になるんですよね。


うーん、それにしても、コードが無いってシステム屋としては、すごい違和感です。

考えてみると、経理の人ってコード＆名称の表を提供すると、コードを削除して名称だけにするんですよね。彼らの業務内容にとって、ユニークなコードの必要性って非常に薄いのかも知れません。

前回：基幹システムの電子記録債権への対応　Part7　仕訳ってどうなるん？
次回：基幹システムの電子記録債権への対応　Part9　サブシステムの対応範囲
投稿記事の一覧：目次

--- blog end ---


スポンサードリンク

私が子供の頃（1980〜1995位かな？）には、近所のガソリンスタンで給油すると、あめ玉とか、ジュースとかくれるサービスがありました。
ジュースもいくつか選ぶ事が出来て、その中の「つぶつぶオレンジ」が私のお気に入りでした。

あの当時は、つぶつぶオレンジって結構見かけたのですが、最近ではめっきりと姿を見なくなりました（たまに、自動販売機でみるくらい）。


もう見る事はないかとも思ったのですが、やはりつぶつぶの需要はあるらしく、しぶとく販売しているようです。
この前、maxvalueで見かけたのがこれです。


株式会社えひめ飲料の「POM　つぶつぶ愛媛みかん」です。

さっそく飲んでみたのですが、このつぶつぶの感じが何とも言えないですね。
ジュース自体の味もクドくなくスッキリとした味わいになっていて、なかなかグッドです。

この、つぶつぶが何とも懐かしいですね。


こういう懐古趣味って、若い子にはまだわからないでしょうね。
年を取った特権ですね。


普通に飲んでも美味しいのですが、思い立ってシャーベットにしてみました。
・・・いえ、ごめんなさい。シャーベットにしようとしたんじゃなくて、冷やすために冷凍庫に入れて忘れちゃっただけです。

ともあれ、冷凍庫で凍らせます（２時間くらいかな？）。


スプーンでぐちゃぐちゃにしてやります。


大体の場合、こういう風にしても大して美味しくはならないのですが、この「POM　つぶつぶ愛媛みかん」は凍らせても美味しいです。というか、こうやってシャーベットにした方が美味しかったです。味だけなら、市販のアイス（ガリガリ君とか）と良い勝負が出来そうな気もします。


それにしても、ガソリンスタンドの数も減った物ですね。
北海道で言えば、札幌などの大きめの都市には、まだまだ数があるのですが、地方にいくとビックリするくらい無くなってしまいました。

時代の流れと言えばそれだけですが、すこし寂しいような気がしますね。


スポンサードリンク

このシリーズの最初（基幹システムの電子記録債権への対応　Part1　始まり）に、発生するだろう仕訳の想定を書いていたのですが、どうも譲渡時の仕訳が非常に怪しいです。

譲渡した場合、単純に貸方に「電子記録債権」勘定を発生させれば良いと思っていたのですが、やはり手形と同じように、一度、別の科目を挟んだ方が良いのではないかってことですね。


例えば、受取手形を割引した時の仕訳は、現状ではこんなところでしょうか。

　a)　受取手形の発生仕訳
　--------------------------
　受取手形　|　売掛金

　b)　割引した時の仕訳
　--------------------------
　当座預金　|　割引手形

　c)　上記の手形が決済された時の仕訳
　--------------------------
　割引手形　|　受取手形

電子記録債権の場合には、受取手形が電子記録債権、割引手形が電子記録割引？みたいな勘定科目になると考えられます。


こういう経理処理って、社内だけで決定できる事ではないので、経理担当を通して監査法人に確認してみたのですが、現時点では事例がないため、分らないって事だそうです。

いや、これ聞いた瞬間、数秒間フリーズしてしまいました。

いくらなんでも、決まっていないってことは無いと思うんですけどね。


でんさいネットも稼働したばっかりだし、電子記録債権が普及するまでの道のりは長そうですね
（そもそも普及するのかっていう問題もありますが）。

このあたりがハッキリと確認できるまでは、分割や譲渡の機能は実装しない方が無難なようです。
ようは、どう転んでも対応できるように、基盤部分（データの持ち方とか）をしっかり作っておけば問題ないのですよ。

．．．実際には、そんな強気なわけもなく、ただの空元気なんですけどね。

前回：基幹システムの電子記録債権への対応　Part6　テーブル設計
次回：基幹システムの電子記録債権への対応　Part8　勘定科目コード
投稿記事の一覧：目次

--- blog end ---


スポンサードリンク

前回でも書いていますが、要件がきちんと定まっていない中での開発なので、内部設計が重要な意味を持ってきます。

ある程度の仕様変更に耐えられるように、柔軟な受け皿を用意しないといけません。
さて、どうしたものか．．．


基本的なデータの持ち方は、こんな感じですかね。


期日が10/10で、電子記録債権を受け取ったのが1/5。
決済を向かえた後で、10/14に不渡になった事が判明した電子記録債権のデータの持ち方です。

肝になるのが、右端の2項目の開始日と終了日です。
データ上に状態（発生、決済、不渡）を表す区分を用意して、それらが有効な期間を開始日と終了日で表現します。
終了日は、基本的には次の履歴データの開始日の前日になるようにして、最終レコードの終了日は、設定できる最大日を設定します。

帳票などで、特定の時期の状態を出力しなければならない時は、この開始日と終了日から対象となるデータを抽出するって方針です。

例えば、基準日が2013/9/30時点での電債の状態を確認するのであれば、こんな感じでしょうか。

-- 基準日が2013/9/30の場合
select * from ***
where
開始日　<=　基準日　and
終了日　>=　基準日　and
期日　>　基準日

条件には、期日が到来している電子記録債権は弾くように考慮します。
．．．基本的には、これで行けると思うのだが。

ちなみに、PrimaryKeyは、管理番号と履歴として、自動採番してやります。


これが手形であれば、上記の手法だけで問題ないと思うのですが、電子記録債権の場合は分割っていう事が出来てしまうので、その時の方法も考えないと行けませんね。

それを考慮して、こういう持ち方にします。


5/5に1,000円の電債を700円と300円に分割した時のデータの持ち方です。

元になった管理№1の終了日を、分割を実施した前日の5/4としてやります。
そして、分割した700円と300円の２件分のレコードを、開始日5/5として作成してやります。

この時に、元になった電子記録債権が分るように、元管理№という項目に、分割元の親の管理№を設定してやります（元が無い場合は、0とする）。

先ほどの抽出条件を考慮すると、基準日が5/4までは元の電債が、5/5以降は、分割した後の電債のみが抽出対象になります。


上では、単純に電債を分割した想定ですが、でんさいネットの場合は、譲渡を伴わない分割は許されないはずです。
ただ、他に３つ存在する記録機関はどうなのか分らないし、電子記録債権法には、分割だけをしちゃダメって書いてないようなので、譲渡を伴わない分割も出来るように考えました。

では、譲渡を伴う場合はどうするかっていうと。


300円の電債を譲渡した場合のデータです。
このような場合には、履歴を作らずに、状態を上書き更新します。

譲渡だけに限らないのですが、履歴の保持方法が日の単位なので、１日の間に複数回の状態変更が発生する場合には、履歴を作らずに上書更新しようかと。

ただ、ここはもう少し慎重に考えても良いかもですね。
さっきは、終了日は次の履歴の開始日の前日って書き方をしましたけど、状態が変更される場合には同一日でもｏｋにするとか。でないと、制約の多いシステムになってしまいそうです。

あとは、うーん。開始時間と終了時間を持たせるって手もありますかね。


このデータをベースとして、売掛、買掛、経理などの各サブシステムと連携させていくので、連携用のフラグを準備してやります。

決済フラグ、債権フラグ、仕訳フラグってかんじでフラグを用意。
各フラグの値は、未処理、処理済み、対象外って３つの状態で管理して、連携用のプログラムでは、フラグの値が未処理であるデータを対象として処理を行ってやります。


いろいろ考えたんですけど、１件の電子記録債権を１レコードとして考えるって方式では無理があると判断しました。

“今この瞬間だけを考えれば良い”っていう要件であれば、それでも良かったんですけど、“過去の特定の時点の状態”も見たいとなると、これが正解の一つではないかと思います。

．．．もっと良い手段もあるとは思いますけど、私の能力ではここまでですね。

前回：基幹システムの電子記録債権への対応　Part5　開発方法
次回：基幹システムの電子記録債権への対応　Part7　仕訳ってどうなるん？
投稿記事の一覧：目次

--- blog end ---


スポンサードリンク

しばらく前の話ですが、グッピーが亡くなりそうになりました。


お腹を見せて、喘いでいます。

上の写真では分からないでしょうが、腰からしっぽのあたりが微妙に曲がっていて、泳ぎづらそうです。元気な時は真っすぐだったので、何かの病気か、怪我でもしたのかも知れません。
過去にも数回、同じ状態になったグッピーはいたのですが、未だかつて、こうなって助かったヤツはいません。


実を言うと、もうグッピー（というか生き物）の育成は辞めたいと思っているので、亡くなる事自体は別に構わないのです。
とはいえ、生き物を飼育するからには、それ相応の責任があるでしょうから、捨てるような真似はせずに、繁殖を停止して（子供を産んでも隔離しない、子供の逃げ場所も作らない）、全滅するまで待つつもりでした。

こういう事情なので、放置しても良かったのですが、見殺しにするようで気分がよくありません。
ということで、出来る事はやる事にしました。


原因は分かりませんが、このまま水槽に入れていてもエサも食べれずに衰弱死するのが目に見えています。
なので、まずは隔離する事にしました。

エサが食べられそうにないので、出張用に用意していた３日間フードで栄養補給させます。


水面まで上がる元気もないようなので、窒息しないように、おさかなぶくぶくブロック（水中で空気を出す石）も用意します。


予備の水槽なんて無い（以前はあったが処分した）ので、退避用の容器が必要です。
これは、以前に購入したキムチのパックを使用することにしました（もちろん、きちんと洗ってますよ）。

これだけでは不足です。私の住まいは北海道で、今は冬。そして、私は仕事にでるので、家の中の気温は10℃を下回ります。
もちろん、この気温にグッピーが耐えられるわけが無いので、温める必要があります。

一瞬、不在時にもストーブ付けっぱなしにしてやろうかとも考えたのですが、いくらなんでもグッピーのために、そこまでのコストはかけられません。
そこで、キムチのパックを水槽に浮かべる事にしました。


見ての通り、水槽にはヒーターがあるので、これで大丈夫かなと。
後はキムチパックがひっくり返らないように、水量を調節して、水槽のフタを乗っけて固定してやります。


私に出来るのはここまでです。治療薬とかも考えたのですが、そもそも病気なのかも分からないし、調べる程の時間もない（ちょうど仕事が忙しい時期で、毎日深夜残業してたりします）ので、野生の生命力にかける事にしました。

正直、まったく期待してなかったのですが、数日後、なぜか元気になりました。


腹を見せて喘いでいたのが、元気に泳ぎ回れるまでに回復しました。
ただ、しっぽの部分が曲がったのは、流石に治らなかったようです。


これなら、エサも自力で調達出来るでしょうから、元の水槽に戻してやりました。


実は、回復したと思ったグッピーですが、結局は亡くなりました。
しばらくの間は生きていたのですが、徐々に衰弱して、最後には天に召されてしまいました。

私に出来たのは、亡くなるまでの時間を、ちょっとだけ延ばして上げただけ。なんだか、苦しむ時間を長引かせただけのような気もしています。
いっその事、そのまま楽にして上げた方が良かったんでしょうかね。


スポンサードリンク

必要な情報は（現状で可能な範囲で）揃ったので、設計を行います。

本音では、しっかりと要件を煮詰めて、必要な機能（画面・帳票など）を完全に洗い出したいのですが、今回はそれは無しとします。
というか、開発者が私一人なので、設計→製造→テスト・・・なんて工程を生真面目にやろうとすると、納期に間に合わないのが目に見えてるんですよね。


実は、必要な画面や帳票については、依頼してきた人（部署）もはっきり分っていないようなんです。
例えば、「電子記録債権の管理帳票は欲しいが、表示する項目や、データの並び順とかは、分らない」って感じです。
まぁ、ありがちですけど、なーんか嫌な感じですよね。

こうなると、ウォーターフォール型の開発手法をとっても、膨大な手戻りが発生するのが目に見えています。
なので、私はアジャイル型とプロトタイプ型を組み合わせたような手法をとる事にしました。

各機能を分割可能な単位に分解して、その単位で必要な画面、帳票を洗い出して、試作品（プロトタイプ）を作成。
それを、レビューしてもらって問題点や疑問点を引き出して、問題が解決するまでそれを繰り返します。

これで、一つの分解要素が完了すると、必要な項目の洗い出しが終了．．．するんじゃないかなぁと考えてます。


今回使用する手法は、実は私が普段から行っているモノだったりします。

ユーザーって、実際に動作する画面や帳票を見せないと、何も意見を言ってくれないんですよね。
ちゃんと要件定義してるのに、出来上がった画面を見せると「イメージと違う」とか騒がれることが結構あったんです。

そこで、いろいろと試行錯誤をした結果、一番手戻りが少なくなったのが、今回の開発手法です。
概要は「まず適当に試作品を作って、レビューしてから、本気で設計・製造する」ですね。
まぁ、物珍しいものではないですけど、自分（組織）に合わせた最適解を見つけ出すまでに結構苦労したものです。

前回：基幹システムの電子記録債権への対応　Part4　要件定義
次回：基幹システムの電子記録債権への対応　Part6　テーブル設計
投稿記事の一覧：目次

--- blog end ---


スポンサードリンク

先日、近所のスーパーで変わった日本酒を見つけました。
純米吟醸「祝」（いわい）っていうらしいです。



容器からして、なにやらおめでたい雰囲気を醸し出していますね。

なんでも、京都の方の「祝」っていう米を使用したお酒だそうです。
容器の裏面には、何やらいろいろと書いていますね。


Google先生によると、この「祝」って米は、酒造好適米として有名だそうですが、正直、美味しければどうでも良いです。
そして、美味しかったです。

どちらかと言えば、甘口になるんでしょうか？
非常に口当たりがよく、スパスパと飲めるお酒でした。

私は冷やで飲んだのですが、熱燗でのんでも美味しそうです。
機会があったら、試してみたいところですね。


スポンサードリンク

勤め先の方が、出張のお土産かなにかで持ってきてくれました。


何やら、こってり風味のラーメンのようです。
最初は、スープを別に作るタイプの麺だとおもったのですが、どうやら只のインスタントラーメンのようです。

手間がかからないようなので、朝ご飯に作ってみました。


・・・具材を何も用意しなかったので、麺だけです。
いや、その、何と言うか、ごめんなさい。

こうして見ると分かりますが、ラーメンの主役は、間違いなく麺とスープですけど、脇役がいない締まらないですね。
インスタントラーメン程度で言う事ではないですが、何やら、いろんな事象の真理を見てしまった気がします。


味は、中々美味しかったです。
豚骨ラーメンのイメージなんですが、こちら（北海道）で食べる物とは、なんか微妙に違います。
美食家ではないので、上手く説明できないんですけどね。

はい、今回はどうということのない日々の風景でした。


スポンサードリンク

デジカメで撮った写真をブログに掲載しようしたところ、個人情報などの貼ってはマズい物があって諦めてしまうことが数回ありました。
画像編集ソフトとかを使えば、どうとでもなるのでしょうけど、この用途のためだけにそんな高価なソフトを買っても勿体ないですよね。

んで、ふと気づいたのですが、iPhotoって画像管理ソフトですよね。ってことは、簡単な画像編集くらいなら出来そうな気がしてきました。
・・・アルバムの電子版程度にしか考えていなかったので、思いつかなかったのですよ。


iPhotoを起動して、編集したい写真を表示します。
この時点で、画面の右下にこんなツールが出てくると思います。


ここで「編集」を選びます。


すると、画面の右側にこんなメニューが表示されました。


どうやら、ここから色々な編集が出来そうです。


上の方にある「エフェクト」や「調整」を使うと、かなり細かい事が出来そうなんですけど、さっぱり分かりません。というか、そこまでの編集機能は求めていません。
というわけで、使用するのは「クイック修正」に表示されているものだけです。

まず「補正」というのを試してみます。
こちらが、補正前の状態です。


そして、「補正」を選択した後の状態がこれです。


おぉ！何やら奇麗になりました。
上の写真は、データ容量の関係上、かなり解像度を落としているので分かりにくいかも知れませんが、実際にはぱっと見で分かるほど奇麗に（というよりは色合いがくっきりする）なりました。


今度は「レタッチ」で写ってはいけないものを隠してみます。

右のメニューから「レタッチ」を選択すると、サイズを変更するバーが表示されます。


画面のキャプチャが出来なくて見せられないのですが、レタッチを選択した状態でマウスカーソルと画像の上に移動すると、丸い輪っかが表示されます。
この輪っかを、ぼかしたい場所の上でクリックしてやれば良いようです。輪っかが大きい、小さいって時は、サイズってバーで大きさを調整するようです。

では、先ほど補正した写真から、看板をぼかしてみます。


どうやら、ぼかしたい場所の周辺の色彩の情報を使用して、できるだけ違和感のないようにしているようですね。
もちろん、よく見ると変なのは一目瞭然なんですけど、ぱっと見では気付かれないかも知れません。

・・・これで、人間の足の部分を隠してやれば、立派な心○写真の出来上がり、ですね。


いろいろ遊んだあげく、編集失敗！元に戻したい！ってのは、ありがちなパターンですよね。
そんな時は、画面右側のメニューの一番下の「オリジナルに戻す」「取り消す」ボタンを使用します。


「オリジナルに戻す」は、文字通り編集前の最初の状態に戻します。
「取り消す」は複数回の編集をしていた時に、直前の状態に戻します。


相変わらず、アップルの商品はスマートなものが多いですね。
実はWindowsでも、標準で編集ソフトが付いてきた気がするのですが、あっちの場合、最初からサードパーティのソフトだの大量のソフトがくっ付いてきて何が何やら分からず、何とかたどり着けても、操作方法が分からんってパターンが多いから、機能があっても使わないんですよね。
・・・バージョンアップのたびに、操作方法がガラッと変わったりして、覚えるのが虚しくなるってのもありますし。

しかし、今回の補正、ぼかす、編集前に戻すって一連の機能ですが、エンジニアの目線から見ると、非常に興味深いです。補正時やぼかす時、編集状態を保持するための情報保持のロジックってどうなってるんだろ？

まぁ、知ったところで業務に役立つとは思えませんが、何かのヒントになるかも知れませんからね。

スポンサードリンク

先日、ウィスキーを物色していたのですが、こんなのを見つけました。


札幌ウィスキー？いや、そもそも地ウィスキーなんて存在していたのか？地ビールなら聞いた事があるけど・・・
って感じだったのですが、面白そうなので買うことにしました。

うん、所詮は嗜好品。楽しめれば良いのですよ。

とりあえず、瓶の裏を見てみました。


非常にスッキリしたラベルですね。
アルコール度数が４３％は、私にはややキツめ、製造元は札幌酒精工業株式会社。

札幌酒精工業？あれ？焼酎作ってる会社じゃなかったけ？
気になって、ホームページを覘いてみたのですが、少しだけウィスキーも作っているようです。


地何たらってつくお酒って、物珍しくて買う事はあるのですが、妙なクセがあって、味は今ひとつってパターンが多いんですよね。
こいつも、その類いと思って味に期待はしていなかったのですが、意外や意外、美味しかったです。

特に気になるクセもなく、安心して飲めるウィスキーでした。
これは、いけますね。


本当は、角瓶を買うつもりだったのですが、値段的にもそんなに違わないので、こちらにしてみました。
良い意味で期待を裏切られた感じで、楽しかったです。


スポンサードリンク

先日、近所のスーパーで白酒（しろざけ）を見つけました。
白酒っていえば、ひな祭りですよね。ですよねって言いながら、ひな祭りに飲んだ事は無いんですけどね。


お祝いに使うだけあって、可愛いですね。

買ったのは、ひな祭りが終わってから一週間後くらいだったでしょうか？
なんだか、投げ捨てるように積み上げられていて、見かねて手に取ってしまいました。


さっきは、ひな祭りに飲んだ事がないって書きましたけど、よく考えると、白酒自体を飲んだ経験がありません。
ってわけで、飲み方が分からなかったのですが、箱の裏に書いていました。


ふむふむ、ストレート、牛乳割り、インスタント甘酒、・・・・・・甘酒！？

あぁ、そういう飲み物なんですか。
せっかくなので、全部試してみました。


とりあえず、牛乳割りで飲んでみました。
何と言うか、ようするにアルコール度数が高い甘酒って感じですね。

これはこれで面白いのですが、晩酌用としては合わないです。
・・・結構残っちゃったこれ、どうしようかな。


最初の写真の箱の中央がぼやっとしてるのは、半額のシールが貼ってあって見栄えが悪いので編集したためです。


スポンサードリンク

最近、野菜不足のせいか、水分補給が足りないのか分かりませんが、お通じがよろしくなかったりします。
ってことで、整腸作用があると聞くコンニャクを食べて、胃腸を整える事にしました。

刺身コンニャクとか、煮物とか、いろいろ手はあるのですが、ここは簡単なおでんを選択します。
・・・おでんをツマミに日本酒飲みたいって訳じゃないですよ。


ってことで、近所のスーパーで紀文のおでん汁の素を調達しました。


後は具なのですが、特に考えるまでもなく、おでん汁の横に、おでんセットが用意されていました。
練り物、コンニャク詰め合わせ、汁付きのパックに詰まったタケノコや牛すじ、大根。

・・・ここまで揃ってると、もう料理とは言えないですね。

とりあえず、コンニャクを下ゆでします（説明書にやれって書いていた）。
時間の目安が分からないので、沸騰してから２〜３分で終了。

んで、そのお湯を使って、練り物に湯通しします（お湯をかけるだけ）。

後は、お湯、おでん汁の素、具材を突っ込んで２０分程煮込むだけです。


はい、日本酒といっしょに美味しく頂きました。


おでんを茹でたのは、鍋ではなくフライパンです。
人に教えてもらったのですが、フライパンを使った方が、鍋よりも煮こぼれとかしないで、料理しやすいんですよ。

個人的には、ラーメンを茹でるのに使うのが最適！
ラーメン専用鍋とか使っても、なお煮こぼれして困っていたのですが、フライパンで茹でると煮こぼれしないで茹で上げる事が出来るようになりました（もちろん限度はありますが）。


スポンサードリンク

普通預金にある程度まとまったお金が貯まったら、そのまま置いておくのは勿体ないですよね。
というわけで、何らかの金融商品（って言い方でいいのかな？）を購入することにしています。

選択肢としては、定期預金、国債、地方債、社債、FX、株、後は金とか先物取引も含むかな？

博打なしで資産を殖やしたいので、前提条件は、元本割れをしない、不渡りみたいな事にならないってことです。とすると、定期預金と国債、地方債くらいしか選択肢がなくなります。まぁ、元本保証型のFXとかもあるようですけど、今回は却下です。

さて、定期預金が一番安定しそうなんですけど、ここ数年は、利率があまりにも低いので、よっぽどの大金を預けない限りは、普通預金に置いておくのと大して利息が変わらないって言う寂しい状況になっています。

であれば、国債か地方債なんですが、こいつらも、ここ最近は募集のたびに利率が下がっています。
うーん、嫌な時代ですね。

結局、ちょうど募集が始まった、札幌市債を購入する事にしました。


私のメインバンクは北海道銀行でして、そこから札幌市債を購入しました。


利回りが、0.113%ですか・・・
定期よりはましですけどねぇ。

手続きが結構面倒で、いろいろな書類を記入する事になります。年収、総資産とかのアンケートやいろいろな承諾書などですね。
まぁ、担当してくれたお姉さんの指示通りに書くだけなので、難しい事はないです。

当然、準備する物は、身分証明書、印鑑、普通預金から購入するので通帳も用意します。
ほかの金融機関はどうか分かりませんが、北海道銀行の場合は債権を購入すると、債権専用の通帳をくれるので、以前に購入したことがあるのなら、それも必要ですね。

ってことで、手続きに約１時間くらい掛かりました。
なんか、最後に担当のお姉さんと、そこの責任者？らしき人に、お待たせして申し訳ありません、みたいな事を言われましたけど、この手の手続きをするのに１時間くらいなら想定内ですよ。


帰り際に、プレゼントを頂きました。


紙の包みの中は、タオルです。


定期や債権とか購入するたびに、こういうプレゼント（粗品って言うんですかね）を頂いています。
ちなみに、以前に購入した時は、サランラップだかクッキングシートだかの台所周りのものでした。

せっかくですので、ありがたく使わせて頂きます。


以前は、定期預金を活用していたのですが、利率が下がりすぎて実利が無い事と、期日がきた時に、放っておくと勝手に更新されるっていう仕組みがなんとなく嫌でした。
その点、債権の場合は期日がきたら、現金化されて普通預金に戻ってくるので、こっちの方が良いかなって思い、最近はもっぱら国債、地方債を購入しています。

ハイリスク＆ハイリターンを狙うか、安定した資産運用を目指すか、いっその事、何もしないか。
この辺りは、各人の考え方だと思いますので、一概にどれが良いとは言えないですよね。


スポンサードリンク

SELECT文でデータを抽出して、COBOL側で値を編集、その結果を書き戻すっていう単純なプログラムを作ってみました。

SELECT文を発行します。FOR UPDATEでロックしておきます。

EXEC  SQL  DECLARE  CU1  CURSOR  FOR
SELECT
       ABCD.NUMMGR ,   -- 管理番号
       ABCD.NUMRCD     -- 記録番号
  FROM
       ABCD
 WHERE
       ABCD.NUMMGR = 123456
FOR UPDATE
END-EXEC.

*> カーソルオープン
EXEC  SQL
      OPEN  CU1
END-EXEC.

フェッチします。

EXEC  SQL
    FETCH  CU1
    INTO
          :H-NUMMGR    ,   -- 管理番号
          :H-NUMRCD        -- 記録番号
END-EXEC.

COBOL側で値を書き換えます。

IF H-NUMRCD = "1"
    MOVE  "5" TO H-NUMRCD
END-IF.

んで、更新します。

UPDATE  ABCD
   SET
       ABCD.NUMMGR =  NVL(ABCD.NUMMGR, 0) ,      -- 管理番号
       ABCD.NUMRCD =  RTRIM(ABCD.NUMRCD)         -- 記録番号
 WHERE
       ABCD.NUMMGR = 123456

ABCD.NUMMGRは、PrimaryKeyなので、別にこれでも問題は無いのですが、なんとなーく気持ち悪いです。


という訳で、こうしてみました。

UPDATE  ABCD
   SET
       ABCD.NUMMGR =  NVL(ABCD.NUMMGR, 0) ,      -- 管理番号
       ABCD.NUMRCD =  RTRIM(ABCD.NUMRCD)         -- 記録番号
 WHERE
       CURRENT OF CU1                          -- カーソルで指定（フェッチ）している行

WHERE条件に、CURRENT OF [カーソル名] とだけ指定します。
これで、現在カーソルで指定している行を更新の対象にすることが出来ます。

スポンサードリンク

javaScriptでラベルの値を変更する方法（真）


少し前に、javaScriptでラベルの値を変更する（ように見せかける）方法という記事（javaScriptでラベルの値を変更する方法）を書いたのですが、親切な方が、ラベルの値を変更する正しい方法を教えてくれました。

という訳で、試して見ました。


どうやら、innerTextというプロパティを使用することで、タグ内の内容を取得、変更することが出来るらしいです。

まず、HTMLを準備します。

<br>
<INPUT id="labelCode1ID" tabindex="-1" value="000" Style="width:30px;">
<LABEL id="labelName1ID">テスト</LABEL>
<br><br>
<INPUT type="button" value="変更" Style="width: 80px;" onClick="JavaScript:testSelect();">

前回との変更点は、INPUTタグをLABELタグに変更、name属性を削除、id属性を追加です。
まぁ、nameを削除してidで書き直す必要はなかったんですけどね。

んで、javaScriptはこうします。

function testSelect() {

	if (document.getElementById("labelCode1ID").value == '999') {
		document.getElementById("labelCode1ID").value = '000';
		document.getElementById("labelName1ID").innerText = 'テスト';
	} else {
		document.getElementById("labelCode1ID").value = '999';
		document.getElementById("labelName1ID").innerText = '変えました';
	}

	return true;
}

getElementByIdで対象とする要素を取得して、innerTextプロパティの値を書き換えてあげればＯＫです。

なーるほど、こうすれば良かったんですね。
IE8とChromeで試したところ、問題なく動作してくれました。


いろいろ調べたんですが、innerTextプロパティってFireFoxでは対応してないらしいんですよね。
FireFoxの場合は、innerTextの代わりにtextContentを使用しないといけないようです。

javaScriptを下記の通りに修正します。

function testSelect() {

	if (document.getElementById("labelCode1ID").value == '999') {
		document.getElementById("labelCode1ID").value = '000';
		document.getElementById("labelName1ID").textContent = 'テスト';
	} else {
		document.getElementById("labelCode1ID").value = '999';
		document.getElementById("labelName1ID").textContent = '変えました';
	}

	return true;
}

修正と言っても、innerTextをtextContentに書き換えるだけです。

一瞬、こっちの方がいいかとも思ったのですが、IE8では動作してくれなかったんで却下しました。
Chromeでは動作したので、textContent自体は使えるようなんですが．．．。

少し調べてみると、innerTextは（Microsoftお得意の）IEの独自仕様で、textContentはW3Cで標準化されたプロパティらしいです（出典を調べきれなかったので、嘘かもしれませんが）。

．．．IE8って標準仕様に従うとか言ってなかったでしたっけねぇ。
流石はMicrosoftです。


本題とずれるので書かなかったのですが、getElementsByTagNameっていうものも教えて頂きました。

document.getElementsByTagName("LABEL")[0].innerText="変えました"

なんでも、引数で指定したタグ名の要素を配列として取得するメソッドだそうです。
うーむ、javaScriptもいろいろと出来るものなんですね。

前回：javaScriptでラベルの値を変更する方法
投稿記事の一覧：目次

--- blog end ---


スポンサードリンク

javaScriptを使用して、HTMLのラベルの値を変更したかったのですが、どうしてもやり方が分らなかったので、疑似的に実現することにしました。
はい、タイトルの「ラベルの値を変更」ってのは嘘で、正しくは、「ラベルの値を変更しているように見せかける」ですね。

やりたいのは、こういう事です。

まず、こんな画面があったとします。


んで、「変更」ボタンを押すと、下記のように値を変更させるって事です。



htmlは、こんな感じでした。

<br>
<INPUT tabindex="-1" value="000" name="testCode" Style="width:30px;">
<LABEL>テスト</LABEL>
<br><br>
<INPUT type="button" value="変更" Style="width: 80px;" onClick="JavaScript:testSelect();">

繰り返しになりますが、変更ボタン押下時に実行しているjavaScriptでは、LABELタグの値を変更することが、出来なかったんですよね。
もしかしたら、技があるのかもしれませんが、私には発見できませんでした。

そこで、スパッとLABELタグを使用することを諦めました。


LABELタグをINPUTタグで書き直しました。

<br>
<INPUT tabindex="-1" value="000" name="testCode" Style="width:30px;">
<INPUT value="テスト" name="testName" readOnly="readOnly"
Style="width:190px;border-style:none;background-color:transparent;">
<br><br>
<INPUT type="button" value="変更" Style="width: 80px;" onClick="JavaScript:testSelect();">

問題は、入力が出来てしまう、枠線が見える、背景色が異なるってことです。
という訳で、これら問題の機能を封印していきます。

まず、readOnly="readOnly"で、入力不可にします。

今度は、Style属性で枠線を消してやります。
border-styleは、枠線の書式を一括設定できます。こいつにnone を指定してあげると、枠線が表示されなくなります。

最後に、背景色を透明にします。こいつもStyle属性で設定します。
背景色を設定するbackground-colorに、transparentを設定することで透明になります。

これで、一見ラベルに見える、テキストの完成です。

※　ここでは省略しましたが、実際にはタブも当らないように、tabIndex="-1"も必要ですかね。


この手のスタイルを直接指定するのは、あんまりよくない気がするので、スタイルシートで定義することにしました。

まず、スタイルシートにこんなのを追加します。

.inputLabel {border-style:none;background-color:transparent;}

htmlは、こんな感じに修正します。

<br>
<INPUT tabindex="-1" value="000" name="testCode" Style="width:30px;">
<INPUT class="inputLabel" value="テスト" name="testName" readOnly="readOnly"
Style="width:190px;">
<br><br>
<INPUT type="button" value="変更" Style="width: 80px;" onClick="JavaScript:testSelect();">

readOnlyは、スタイルじゃないのでそのまま残します。


余談ですが、変更ボタン押下時のjavaScriptは、こんな感じです。

function testSelect() {

	if (document.all.testCode.value == '999') {
		document.all.testCode.value = '000';
		document.all.testName.value = 'テスト';
	} else {
		document.all.testCode.value = '999';
		document.all.testName.value = '変えました！';
	}

	return true;
}

まぁ、特に説明も必要ないですよね？


スポンサードリンク

先日、ちょっと変わった濁り酒を見つけました。


ピンクっぽい瓶で、名前通りふわっとした感じです。
とりあえず、注いでみました。


濁り酒に対する私のイメージは、「甘酒から甘みを抜いたもの」って感じなんですけど、コイツにはこってりした酒粕がありません。
色のイメージとしては、カルピスが最も近いと思います。

名前通り、ふわっとした飲みやすい味で、なかなか面白かったです。
最近、こういう口当たりの柔らかい日本酒が多くなってきた気がします。個人的には好きなんで良いんですけど、時代の流れなんですかね。


お酒は好きなんですけど、量を飲むのは嫌いなタイプです。
お酒を飲んで、ふわっとした感じを味わったらそれで満足、それ以上は翌日の二日酔いとかが怖くて飲みたくありません。

ついでに言うと、外で飲むのも嫌で、もっぱら自宅で一人で飲んでいます。
外で飲むと、酔っぱらった状態で自宅まで帰りのが手間で嫌。それに、人と騒ぐより、ひとり静かに楽しみたいんですよ。


スポンサードリンク

先日、久しぶりにNetCOBOLで新規にプログラムを作成したのですが、見事にエラーが発生しました。

SQLCAの中身を確認したところ、下記の状態になっていました。

  SQLCODE    : -000001405
  SQLERRM    : ORA-01405: フェッチした列の値がNULLです

  SQLERRD(3) : +000000001
  SQLWARN0   :  
  SQLWARN1   :  
  SQLWARN2   :  
  SQLWARN3   :  
  SQLWARN4   :  
  SQLWARN5   :  
  SQLWARN6   :  
  SQLWARN7   :  

あぁ、NetCOBOLってNULL値を受け取れないんだったよ。


実行したSQLは、こんな感じ。
NUMMGRがNUMBER型、NUMRCDがVARCHAR2型です。

SELECT
       ABCD.NUMMGR ,   -- 管理番号
       ABCD.NUMRCD     -- 記録番号
  FROM
       ABCD
 WHERE
       ABCD.NUMMGR = 123456

フェッチでする変数はこんなのです。
H-NUMMGRがS9タイプ、H-NUMRCDがXタイプです。

EXEC  SQL
    FETCH  CU1
    INTO
          :H-NUMMGR    ,   -- 管理番号
          :H-NUMRCD        -- 記録番号
END-EXEC.

この条件下で、ABCD.NUMRCDがNull値の時にフェッチを行うと、エラーが発生しました。


まぁ、Nullを受けられないのであれば、別の値の変更すれば良いだけの話です。
という訳で、こんな感じにSQLを修正します。

SELECT
       NVL(ABCD.NUMMGR, 0)          ,    -- 管理番号
       NVL(RTRIM(ABCD.NUMRCD), ' ')     -- 記録番号
  FROM
       ABCD
 WHERE
       ABCD.NUMMGR = 123456

NVL関数で、Null値の時に違う値に置き換えています。
ABCD.NUMMGRは数値型なので、単純に0に置き換えています。
ABCD.NUMRCDは文字型なので、RTRIM関数で右側空白を除去した上で、NVL関数で半角スペースに置き換えています。

RTRIM関数は無くても良さそうですけど、こいつをDML文で使用する時には意味が出てきます。


問題があるとすれば、フェッチした値を更新で使用する場合です。
ABCD.NUMRCDの値がNull値だったとした時に、下記のUPDATE文が実行されたとします。

UPDATE  ABCD
   SET
       ABCD.NUMMGR =  :H-NUMMGR,         -- 管理番号
       ABCD.NUMRCD =  :H-NUMRCD          -- 記録番号
 WHERE
       ABCD.NUMMGR = 123456

ホスト変数「H-NUMRCD」には半角スペースが入っているので、このまま更新を行うと値がNullからスペースに置き換わってしまいます。

※　置き換わるはず。試してないけど、たしか変わったはず．．．

なので、さらにRTRIM関数をかぶせて、スペースをNull値に変換して、Null値のままで更新されるようにします。

UPDATE  ABCD
   SET
       ABCD.NUMMGR =  NVL(:H-NUMMGR,) + 1 ,      -- 管理番号
       ABCD.NUMRCD =  RTRIM(:H-NUMRCD)           -- 記録番号
 WHERE
       ABCD.NUMMGR = 123456

これで、問題なく動作します。

まぁ、元のデータが固定長で、後方にスペースがある事が前提とかなってくると、RTRIM関数を使うのはまずいですよね。その時は、COBOL側で工夫するしかないでしょうね。


今回はNVL関数を使用する方法を使いましたが、Oracleのマニュアルでは「標識変数」という変数を使用してNull値の発生を記録うんぬんって書いています。

これは、フェッチした値がNull値かそうじゃないかを表すフラグを項目別に用意、フェッチした時にNull値であった場合には、そのフラグに-1が設定されるので、それでNullの判断をしてねっていうものです。

言葉だけ聞くと使えそうな気もするのですが、実際に使った感想としては、変数の準備とか、判定用のIF文とかで無駄にソースが長くなるだけで使いにくいと思いました。

Null値の判定がどうしても必要な処理でない限り、無理に使う事もないでしょうね。
ということで、使い方の説明もしません。必要な方は、頑張ってNetCOBOLとかのマニュアルを開いて下さい。

スポンサードリンク

文字列の日付っていうのは、日付が文字型（VARCHAR2）で"20130405"って感じで格納されているってことです。
こいつに対して、日付の加減算をしたいわけですよ。

ちなみに、環境はOracle11gです。


Oracleの場合、日付型への加減算は特殊な式を使う必要がなく、単純に日数を加えてやればＯＫです。
なので、TO_DATE関数を使用して、文字型から日付型に変換してやれば、簡単に日数計算ができます。

-- 2009年4月5日の135日後を求める。
TO_DATE('20090405', 'YYYYMMDD' ) + 135

-- 2013年3月4日の前日を求める。
TO_DATE('20130304', 'YYYYMMDD' ) - 1

ただ、これだと結果が日付型になってしまいます。
テーブルの格納値が文字型ってことは、周辺環境（更新する時や、アプリ側の共通部品など）でも、それを前提にしていると思われます。なので、TO_CHAR関数で８桁の文字型の日付に戻してやります。

TO_CHAR(TO_DATE('20090405' , 'YYYYMMDD' ) + 135, 'YYYYMMDD')

月の加減算を行う場合は、ADD_MONTHS関数を使用します。
この関数も、引数は日付型を前提としているので、TO_DATE関数を使用して、文字型から日付型に変換してから使用します。

-- 2012年1月31日の１ヶ月後を求める。
ADD_MONTHS(TO_DATE('20120131', 'YYYYMMDD'), 1)

第一引数が元の日付で、第二引数が加算する値ですね。

上の結果は、「2012/02/29」になります。きちんと、うるう年まで判定してくれるようです。
まぁ、そうでなければ使い物になりませんけどね。

そして、こちらも８桁の文字型日付で取得する場合は、TO_CHAR関数を使用します。

-- 1980年5月20日の３ヶ月前を求める。
TO_CHAR(ADD_MONTHS(TO_DATE('19800520', 'YYYYMMDD'), -3), 'YYYYMMDD')

同じことをやってもしかたないので、過去月を取得してみました。


この調子で、年の加減算もしたいのですが、どうやらOracleには年の加減算をする関数が存在しないようです。
なので、ADD_MONTHS関数を使用することになります。

-- 2012年2月29日の１年後を求める。
ADD_MONTHS(TO_DATE('20120229', 'YYYYMMDD'), 12)

こんな感じで、加算する月数に12を指定してやればＯＫです。
１年前って場合は、-12としてやれば良いです。


勤め先の基幹システムの日付の格納方式ってのが、ほとんどVARCHAR2の８桁文字なんですよね。まぁ、一部ではDATE型も使用してますけど。

入力画面の書式が、年・月・日でそれぞれフィールドを分ける作りにしているので、無理にDATE型を使うよりも、VARCHAR2型を使った方がやり易いのは確かなんでしょうけど。

ずっと社内SEとしてやってきているので、他社さんのシステムの内部構造ってあんまり見たことがないんですけど、一般的にはどうやってるんでしょうかね？


スポンサードリンク

札幌が本拠地の「さんぱち」というラーメン屋さんがあります。私、結構お気に入りでして、月に一度くらいは顔をだしています。

おすすめは、味噌ラーメン。札幌と言えばこれですよね。
ラーメンの上に、モヤシを中心にした野菜がたっぷり乗っていて、こいつに汁の味がしみ込んでいて美味しいんです。
んで、もっと野菜を食べたい時には、野菜ラーメン（味噌味）を頼む手もあります。

これが、その野菜ラーメンです。上に乗っているのは、全部野菜（ほとんどモヤシ）です。


妙なクセの無い、食べやすい味なんですけど、問題点は非常に味が濃いってことです。濃い味の好きな私には良いのですが、薄味好きの人にはちとキツいかもしれません。
そのせいで、人によってはお勧め出来なかったりもしますが。


先ほどの写真の横にも写っていましたが、なにやらハシが付いてきました。


つい先日まで、普通の割り箸だったと思うのですが・・・

他のラーメン屋で、こういう箸が出てきた記憶がないので、ちとビックリしました。
一瞬、普通の箸だと麺が滑って食べにくいのでは、という懸念を持ったのですが、特に問題なく食べられました。

しかし、今さら何でしょうか？洗い物の手間が増えて、現場は大変だと思うのですが、コスト的なメリットでもあるんですかね。
エコだ何だと騒ぐ人が居ますけど、結局のところ企業にとっては利益第一。払う費用に見合う効果が無いと、まともに取り組んだりしないはずなんですがね。

数年前に、マイ箸とかがブームになった記憶がありますが、実はその類いの話が現在でも続いているんでしょうか。


先日、回転寿しのとっぴーに行ったのですが、そこでも箸が再利用できるハシになっていました。
とっぴーに行くのは数年ぶりだったので、前がどうだったのか覚えていないのですが、もしかして、最近はこういうお店が増えてるんですかね。


スポンサードリンク

半年くらい前の話ですが、基幹システムに対する、修正要望が上がってきました。
何でも、商流が変わるので新しい伝票入力方式が必要になるって話だったんですけど、私の所まで話が回ってきたときには、あと一ヶ月位しか時間が無い状態でした。

ザックと工数を出して見ると、60人月超（開発人員は私一人）。
．．．要望上げてきた人（部署）は、軽い気持ちで言ってきたのでしょうけど、作るのは大変なんですがね。

まぁ、愚痴ってもしょうがありません。
私が二人分働いて（つまり残業して）、何とかするとしますかね（給料も二人分出るのなら喜んで働くんだけどなぁ）。

※　注意
愚痴ってもしょうがないと書いておいてなんですけど、この先は愚痴です。
そんなの、聞きたくない（読みたくない）という方は、そっと別のサイトに移動をお願いします。


要件を整理すると、新規画面は不要で、既存の画面に対する修正だけで何とかなりそう。

まず、仕様書を直そうと思ったのですが、何か記述が変。
．．．はい、仕様と実装が食い違っているという、よくあるパターンです。

本当は、実装を解析して仕様書を直したかったのですが、何しろ時間が無い。しかも、プログラムが非常に汚くて、解析していると納期に間に合わなくなることが明白。

という訳で、仕様書は私の頭の中（+殴り書き）で作成して、プログラムを先に直すことにしました。
本当は、いけないんでしょうけど、どうせ開発者が私一人ですからね。


というわけで、必死こいて何とか動くところまでプログラムは直しました。ユーザーへのレビューも、概ね好評でなかなか順調だったのです。

．．．まぁ、代償に私の体はボロボロになりましたけどね。

この時点で、納期まで数日。
実は、この時はまだ詳細なテストが出来ていなかったりして、内心かなり焦っていました。
見た目上はレビューが出来る程度まで動くのですが、他システムとのデータの整合性とかといった、内部的な部分の検証が出来ていなかったんですよ。

やるべきテストは大きく２つ。
一つは、先ほど言った内部連動とかの基盤部分のテスト（これが重要）。もう一つは、修正した画面の動作の検証です。

結構な機能追加で、画面制御ロジックとかもかなり（元の70％以上）書き直したので、追加した部分以外にも障害が出る可能性が高い（というか、間違いなくバグがある）ので、そちらも潰さないと不味いです。

残日数を考えると、私一人で両方を片付けるのは無理（というか無謀）と判断して、既存機能の動作を把握しているシステム運用部署の課長（Ａさん）にテストの協力を依頼しました。

ちなみに、この修正案件をユーザーから直接受けたのは、このＡ課長で、修正画面の動作を把握しているのも、この人だけです。

その条件下で、依頼した結果がこんな感じです。

私：ということで、画面周りの動作テストを手伝って貰えませんか。
Ａ：．．．（嫌そうに顔をしかめて、顔を横に向ける）
私：．．．

いや、このＡ課長が忙しいっていうなら分るんですけど、見るからに余裕がある（というか満ち溢れている）のに、この態度ってどうなんだろ。


なんというか、やる気のない人間に期待しても無駄と判断して、自力で何とかすることにしたのですが、現実的に間に合う訳がありません。

なので、システム全体に影響を与える部分を中心にテストして、画面制御あたりについては、通り一遍等のテストだけにしました。というか、時間切れになりました。

結局そのままリリースしたのですが、案の定、リリースした途端に障害が頻発。もぐら叩きのようにバグを潰して、安定するまでに約１週間ほどかかりました。

ただし、私がしっかりテストした内部連動の部分についてはバグが無く、画面制御系のバグだけでした。うん、まったく想定通りです。

結構な数のバグが出たのですが、これ、私だけが悪いとは思えなかったんですよね。
バグといっても、修正前の動作との食い違いといった軽微なものが殆どで、Ａ課長がテストを手伝ってくれていれば、間違いなくバグの発生件数は半分以下に抑えられたと思うのですよ。

最終的には、「たくさんバグだしてすみません」って私、頭下げましたけど、これ、頭下げる人違いませんかね。


このＡ課長。自分に都合の悪いことは逃げ回るくせに、自分は仕事をしていると思っているっていうタイプなので、あんまり期待してなかったんですけど、流石に今回くらいは手伝ってくれると思っていたんですね。

がっかりです。

ちなみに、リリース後にはユーザーの所に積極的に顔を出して、操作指導とかやってました。
これも、好意的にみれば、運用担当の責任を自覚した行動って見えますけど、私の立場からみると、別の見方もできるんですよね。


スポンサードリンク

しばらく前に記事にしましたが、国家試験のプロジェクトマネージャーに挑戦します（プロジェクトマネージャーに挑戦します！）。

初めての論述式の試験と言う事もあって、勉強も熱心にやっているのですが、腕が痛くなってきました。
うーん、仕事が忙しいせいで、朝から晩までキーボードを打ち続け、勉強のためにノートを書き続ける毎日でして、考えてみると、一日中腕を動かし続けてるんですよね。そりゃ、腕も痛くなりますよ。

とりあえず、腕に湿布を貼って凌いでいるのですが、腕の負担を減らさない事にはどうにもなりません。
最悪、試験については自分だけの問題なので切り捨てるとしても、仕事の方に悪影響が出ては、周りの人に迷惑かけちゃいますしね。


実は、キーボードについては、既に人間工学云々って言うお高いキーボードを使っているので、これ以上はどうしようもありません。
ちなみに、キータッチも無駄な力を入れて、腕に負担がかからないように気を配っています。

問題は筆記の方ですね。

私、字を書くのはヘタで、どうやら無駄に力を込めて書いているようです。どうやら、最大の問題はここにありそうです。
とりあえず、普段から意識して力を抜くようにして、腕への負担を減らしつつ、良いシャープペンシルを用意することにしました。

とは言え、すっごい高級品が欲しいわけでもないので、人間工学云々っていうシャープペンシルを探して見ます。たしか、以前にそんな商品があるのを見た気がするんですよ。
しかし、近所の文具店を除いても、それらしい物が見当たりません。うーん、街中のデパートとかに行かないとダメなんだろうか。

目当ての物は無かったのですが、緊急を要しているので、売り場にあった一番高価なヤツ（まぁ、５００円程度ですけど）を買っておきました。
ダメなら、時間がある時に探しに行くってことで。

GRAPHGEAR500って商品のようです。グラフギアって読むらしいです。


この記事を書く時に、ググってみて知ったのですが、これ、製図用のシャープペンシルらしいです。


妥協の末に購入したわけですけど、その割には悪くはないです。

軽量でバランスが良く、ペンの先が長いので、書いてる最中の文字が読みやすいです。
デザインは、非常にシンプルで、他の色もありません。この辺りは賛否両論あるでしょうけど、私はこういうシンプルなデザインが好きなので、問題ありませんね。

難点があるとすれば、握る部分の滑り止め？の部分がゴツゴツしてることですかね。
書いている内にペンだこが出来そうです。まぁ、無駄に力を込めると指が痛くなるので、却ってよかったと前向きに考えますか。

求めていた物とは若干違いますが、これはこれでアリですね。


実は、腕だけでなく肩も結構な負担なのですが、そちらは以前に購入した肩かけしきのマッサージ器（トントンお肩をたたきましょう）で何とかしています。

これ、買った時には「無駄な買物だったのでは」と危惧していたのですが、意外に大活躍です。


スポンサードリンク

Excel2007辺りから、何やらセキュリティの仕組みがいろいろ追加されて、非常にウザいです。
バックグラウンドであれこれやるなら良いんですけど、何か動作させるたびにメッセージボックスとか表示されると、もう迷惑以外の何物でもありません。

しっかし、何なんでしょうね？
そんなに、過去のバージョンで悪用されたりしたんでしょうかね。


マクロ有効ブックにした時にも、メッセージが表示されるようになりました。

再現手順として、まず適当にExcelファイルを作成して、名前を付けて保存から、「Excelマクロ有効ブック（*.xlsm）」で保存します。


開発タグのコードグループから、Visual Basicをクリックしてエディタ画面を開きます。
挿入メニューから、標準モジュールを選択します。


すると、それ以降、Excelブックを保存するたびに、変なメッセージが表示されるようになりました。


表示されたメッセージは下記の通り。

「プライバシーに関する注意：このドキュメントには、マクロ、ActiveXコントロール、XML 拡張パックの情報、またはWebコンポーネントが含まれています。これらにはドキュメント検査機能で削除することができない個人情報が含まれる場合があります」

フツーのユーザー相手に、こんなメッセージ出したところで何の役にも立たない（理解できないでしょ）だろうし、無駄にしか感じません。
さらに、メッセージが改行されていないのも、地味にイラつきます。


実にウザいので、下記の方法で出ないようにします。

ファイルから、オプションを選択します。


セキュリティセンターからセキュリティセンターの設定ボタンをクリックします。


プライバシーオプションを表示して、ドキュメント固有の設定にある「ファイルを保存するときにファイルのプロパティから個人情報を削除する」のチェックをＯＦＦにします。


これで、表示されなくなりました。


最近の流れから考えて、セキュリティ面の強化は理解できるのですが、もう少しやりようがある気がしますね。
例えば、表示したメッセージボックスに「このファイルではこれ以降表示しない」とかのオプションを用意するのではだめなのだろうか？

「保存する時だけだろ、我慢しろよ」って声が聞こえてきそうですが、私はWindows95とかの時代からの使用者で、Excel長時間作業　→　Excel異常終了　→　全作業結果喪失　という一連の流れを何度も経験しているんで、短時間（10分程度かな？）に一度の割合で、保存（Ctrl + S）をする習慣があるんですよ。

そのたびに、メッセージが表示されると、邪魔で仕方ありません。


スポンサードリンク

エビスビールといえば、金の缶に、ちとお高い、味の濃い本格派ビールって印象なんですけど、ここ数年は試行錯誤を繰り返しているのか、白いのとか緑のとか黒いのとか、いろいろ苦心しているようです。

そして、ついに赤いのまで出てきたようです。
注いでみたところ、見た目は普通のビールと同じようです。


味は、普通のエビスに比べて、スッキリ感があって飲みやすい味になっていました。
最近は、その他雑種とかのビールもどきが流行っているのですが、折角飲むのだから、美味しいものを飲みたいですね。

まぁ、毎日晩酌をする方にはコスト的に厳しいのでしょうけど。


この赤いヤツ、どうやら限定商品らしいです。ということは、時期を逃したらもう飲めないってことですね。
まぁ、値段もお高めで、私自身、ビール派ではないので特に惜しいとは思いませんが。


スポンサードリンク

Excelのマクロで、ファイルを保存する処理を実装しているものがあるのですが、ある日、ユーザーから「保存できなくなった」という問合せを受けました。

実際に画面を見せてもらうと、GetSaveAsFilenameメソッドの動作が何やら変です。
ファイル名をシステム側で自動設定させているのですが、なぜかファイル名が空白になっています。

ソースはこんな感じです。

    'ワーク変数
    Dim myFile
    Dim myName As String
    
    '適当に名前を付ける
    myName = "金剛.csv"

    'GetSaveAsFilenameメソッドを実行
    myFile = Application.GetSaveAsFilename(myName, "ＣＳＶファイル,*.CSV", 0)

結構、多くのユーザーが使用しているExcelマクロなのですが、こんな事象は初めてです。
ためしに、私のパソコン（WindowsXP ＆ Excel2010）で同じ処理を動かしたら、問題なく動作しました。


実は、心当たりはありました。
ちょうど、OSがWindowsXPからWindows7に切り替えている時期でして、もしかして、その絡みかと想定してみます。

同じ時期に、Excelのバージョンも2000から2010に切替中でもあったのですが、私のXP＆2010で問題が再現しないので、Windows7の問題と判断しました。

．．．まぁ、7＆2010の組合せで発生するって可能性もあるのですが、それは手詰まりになってから考えるってことで。


Application.GetSaveAsFilenameってメソッドは、ファイルの保存画面を表示するのですが、どう考えても、Excelではなく、OS側の機能を呼出しているとしか思えません。

実際に、XPと7では表示される画面も違いますしね。

もしかして、7で仕様が変わったのか？


いろいろ、試行錯誤したのですが、最終的にはこれで解決しました。

修正前

myFile = Application.GetSaveAsFilename(myName, "ＣＳＶファイル,*.CSV", 0)

修正後

myFile = Application.GetSaveAsFilename(myName, "ＣＳＶファイル,*.csv", 0)

第二引数のFileFilterで指定している拡張子を、大文字から小文字に変えただけです。
どうやら、7では拡張子の判定が厳しくなったようですね。

他にもいろいろ試したので紹介します。

まず、第一引数のファイル名の規定値で拡張子を除くこと。拡張子の設定は、第二引数「FileFilter」で設定した拡張子が自動的に追加されるので、そちらを使用する。
拡張子を指定したい場合は、FileFilterに合致する拡張子にする。拡張子は大文字と小文字も一致させること。

こんな感じのルールで運用したところ、きちんと動作するようになりました。


私の会社は、ユーザーの利便性を高めるためにEUCの活用は、結構積極的に行っています。
私たちも、基幹システムと連動するためのExcelとかを提供していたりします。

そんな中で、OSのバージョンアップ（XP→7）と、Officeのバージョンアップ（2000→2010）が行われたものですから、結構ビビっていたのですが、思ったほどの問題にはなりませんでした。

もちろん、ユーザーからかなりの問い合わせがあったのですが、大体は使用方法の確認であって、今回のような問題に発展するケースは少数、案ずるより産むがやすしですね。

まぁ、その少数の中にはOfficeベースのソフトを購入していて、バージョンアップが必要（つまり買い直し）とか言うのもあったりして、大変は大変だったんですけどね。

スポンサードリンク

以前に、ロードヒーティングを削ったお話を書いたのですが（ロードヒーティングは良いのだが・・・）、どうやらもう一度やらないといけないようです。

予想通り、今年度の雪は量が多いですよ。


装備は、前回と同じツルハシと、削った雪を捨てるためのスコップです。
しかし、前回とはやり方が違います。

前回は、時間をかけてユックリと削って行ったのですが、今回はスピードアップを目指します。といっても腕に頼るわけではなく、足腰を使います。
ツルハシが攻撃目標点にあたる瞬間に、下半身を沈めるようにして、下半身からツルハシまで力が伝達されるようにします。
上半身はこれまで通り、すっぽ抜けない程度に力を入れておくだけで、無理に力をかけないようにします。

と言う方法で30分ほど励んだ結果がこれです。
まずは、作業前。


そして、作業後です。


※　上の方がぐにょぐにょしてるのは、個人のお宅が映ってしまったので編集した結果です。

横方向は、車１台分で妥協しました。というか、途中から面倒になりまして・・・
実際の削った量はこんな感じです。


捨てる場所がないので、ロードヒーティングの上に捨てておきました。
右上の方に、使ったスコップが見えていますね。


下半身を有効に使用する方法を取った結果、単位時間あたりの効率は向上したのですが、代償として翌日に太ももが筋肉痛になりました。
よく考えたら、座り仕事の私には、普段、下半身から力を伝達してって行為が発生しない。そりゃ、筋肉痛にもなりますよね。

そして、頑張って削った数日後に大雪がふり、除雪車が元通りに雪を置いて行って下さいました。

・・・ちくしょう。

いいですよ、どうせもう３月です。
放っといても、解けるでしょ。


それにしても、今年は雪が多すぎて困りますね。
ロードヒーティングのあるマンションに住んでいるしおかげで、日々の除雪が必要ないので、実は私はそれほど困らないんですけど、職場の同僚などは四苦八苦しているようです。月に数回、実家に戻って除雪をしている孝行息子もいますしね。私にはとても真似できませんよ。

最後に、作業中の心が和む光景を張っておきます。


近所に野良猫がいるらしく、ニャーニャーと走り回っています。
私、ちっちゃな生き物は好きなんで、なんか嬉しいです。


スポンサードリンク

ユーザーから、とある処理が異常終了するという連絡を受けて、原因を調べていたのですが、障害の原因となったソースが非常に読みにくくて、無駄に手間取ってしまいました。

悪いことに、他システムと連携するための処理で、１時間以内に何とかしないと大変な問題だってことで、ユーザーが後ろに立って急かしてくる状態だったので、私自身が焦ってた事もありますけどね。

大声上げて私を責めても、問題は解決しないよ．．．


頭を抱えたのは、こんな書き方をされたからです。

private boolean smart(String a, String b) {

	// １．引数a、bの共に1であればTrue
	boolean chkFlag = a.equals("1") && b.equals("1");

	// ２．引数aが2ならばTrue
	boolean aFlag = a.equals("2");

	// ３．日付作成
	String day = chkFlag || aFlag?"30":"31";

	// ４．作成された日付が"30"ならTrue
	return day.equals("30");
}

実際のソースは見せられないので、適当に書いてみたのが上記のソースです。
なんというか、非常に気に入らないです。

１．と２．で、判定用フラグへの設定値に、別の処理の結果を直接突っ込んでいる。

３．で三項演算子を使っている

４．で関数の戻値に、別の処理の結果を直接突っ込んでいる。

こういうソースを書く人って「スマートでしょ」とか思ってるのかなぁ。


もちろん、追えますよ。実際に追い切って、対応策まで出してますしね。
しかし、多少冗長であったとしてもif文を使ってくれていれば、もっと手早く対応できたわけですよ。


気に入らないと書いておいてなんですけど、別に私は上記のような書き方を、一概に否定してる訳ではありません。
システムの特性や、チームの技術レベルなどによっては、使ってもいいとは思っています。

例えば、「多少のバグがあっても許される」「寿命が数ヶ月から数年」「開発速度が最優先で今後の改修予定もない」なんて条件であれば、効率優先ってことで、書きやすい手法をとればよいと思います。

反対に、社会インフラを支えるような、止まる事が許されない類のシステムの場合、求められるのは安定性ですので、あえて冗長だが読みやすい書き方をするべきだと思います。
まぁ、常に優秀な技術者が確保できるっていうのなら、難しく書いても良いでしょうけどね。

他には、立場上、口に出来ないとかですかね？IT系でシステム開発が本業っていう会社の技術者が「三項演算子は分りずらいので使いません」とか言い出したら、「その程度で難しいと思う程度の技術力しかないのか？」とか思っちゃいますし。


ちなみに、障害の原因自体は、日付計算を行うメソッドのパラメータに、存在しない日付を渡したという、実に馬鹿らしいものでした。

パラメータとして渡す日付は、年月は画面から入力、日をマスタから持ってきて作成するのですが、作成された日付が「****/11/31」のように月末日を超えた場合は「****/11/30」のように補正する処理が実装されています。

はい、ここまでは良いんですよ。
問題はこのソースを書いた人が、マスタから取得した「日」が"30"以下の場合は、補正処理を実行しなくても良いなんてアホな考えを持っていた事です。

・・・はい、この障害は２月に発生しました。

もうね！三項演算子がどうとか、スマートな書き方が云々とか、それ以前の問題ですよね。

スポンサードリンク