The Way to Nowhere

あるITエンジニアの雑文。

Dell XPS M1530 にSSDを換装

Dell XPS M1530はWindows Vistaの頃のモデルなので、それなりに古いノートPCなのですが、なぜかメモリは一応4GB積んでいて、もったいないなと思っていました。
CPUも多少古い感じもするのだけれでも、とりあえずボトルネックになっていると思われるハードディスクをSSDに交換してみました。

SSDの512GBの中では、これが安かった。



で、換装の手順ですが、PCを裏返すとネジのところにディスクのマークが書いてあるので、とてもわかりやすい。
そのネジを4つとも外すと、横からディスクが引き抜けるようになる。

DellXps2














HDDについているカバーもネジを外して、新しいSSDを取り付けてからPCに挿しこむ。
ただし、元のHDDよりだいぶ薄いのでなんとなく挿しこむだけだと、しっかりと接続されず当たり前のように認識されない。

PC裏返しの状態で、筐体の内側の手前をなぞるような感じで差し込んだら、なんとか接続された。
ディスクを留めるPC中心側のネジが普通に締まるかどうかも目安になるかも。
しっかりと接続されていない時は、端側のネジは留まるけど、中心側ネジは手応えなくスカスカな感じ。
私はそんな状態でもSSDに附属していた長めのネジに替えるなどして半ば無理やり留めてしまい、後からちゃんと接続されていない事に気づくという情けない感じだった。。。

そんなこともありながらも、全般的には簡単にできた、と思う。
ノートPCの中をいじるのは、かなり久々でしたが、昔に比べるとずいぶんと楽でやりやるくなったなぁ、などと思います。

それから、OSはWindows8.1に入れ替えました。Vistaのままのわけはありません。



というわけで、ディスクが速くなれば、まだまだ使えます。

ビデオテープのデジタル化 - The KMPlayer

先日のビデオテープのデジタル化の件、試行錯誤録。

これはまあタイトルにはある意味で偽りありで、うまくできませんでした、という話です。
なので、この記事に何かのソリューションがあるわけではないと思うので、悪しからず。

最初に試してみたのがThe KMPlayerなるツールでした。

が、映像と音声両方を再生するまではできたのだけれども、キャプチャーを試みると、音声だけで映像は取れないというよくわからない感じでした。
アプリ内で再生までできているわけなので、うまく設定すればなんとかできそうな気はするものの、設定項目とかそれぞれの選択肢とか多岐に渡り過ぎてて、なんかよくわからないままうまくできないので諦めました。

まあ、印象だけの話ですが、映像とかをデジタルで扱うのに詳しい人には良いのかもしれないけど、「多機能」過ぎて、私のニーズには合わないな、と思いました。

あと、インストーラなどで何の確認もなく、様々なメディア系ファイルの拡張子を自分に関連付けしてしまうので、イラっとする。
で、アンインストールしてもその関連付けは元に戻らないので、またイラッとするとか。
拡張子の関連付けを修正するのは、 昔に比べるとかなり楽になっているので、それほど実害はなかったですけどね。

というわけで、早々に諦めて別のソフトウェアを、試すことにしました。

昔のビデオテープのデジタル化

世間的には今さらな話なんでしょうが、昔のVHSのビデオテープをデジタル化してPCなどに保管すべく、「ビデオキャプチャー」を使ってみた。家にある古いビデオデッキはもはやテレビにつなぐこともなく放置されていて、このまま壊れて使えなくなりそうで、そろそろやばいかなと思いまして。

まずはキャプチャーのデバイスとしてBuffaloのを買ってみた。理由は特にない。私の用途からすれば、画質とか性能を求める気もなく、とりあえずなんとかしてできればよいので、安いのでいいかな、という程度の事です。



次にキャプチャーのソフトウェアですが、とりあえずbuffaloのに付属しているVHS to DVD 2.5 でやってみる。
面倒な設定もほとんどいらないので、一般的にはこれで十分なのだろうとは思いました。

しかし、調子に乗って比較的長い時間のビデオの取り込みをしてみたところ、ファイルサイズが4GB弱くらいになったところで、ファイル分割されて、別のファイルに保存されてしまった。VHS to DVDの画面をよく見ると確かにファイルサイズが「3.99GB」みたいな設定があるんだが、なんとこれが変更できない!

名前の通りDVDに焼くのが前提なんですかね。

あらためてAmazonのページとか見ると「DVDに焼けるサイズに自動的に分割できる」っていう事をむしろアピールしていたりするんだが、それしかできないというのはちと違うよなーと思った。
だいたいハードディスクがTBクラスの今時でわざわざDVDに焼く事なんてそうそうないだろうって思うけどな。

ググってみると、やっぱり評判悪いみたいですねぇ。。。

キャプチャーのハードとしては別に問題なくて、ソフトウェアの問題だよな、と思ったので、別のを探して試してみることにした。

今現在も試行錯誤中なので、その辺りの話はまたあらためて。

DBのキャラクタセット違いでSJISからUTF8への移行 - Oracle -

最近はOracleのデータベースもUTF8で構築することが当たり前な感じになっていますが、何年も使っているレガシーのシステムだとやっぱりSJISとかだったりすると思います。

そんなSJISとかのデータベースから新しく構築するUTF8のデータベースにデータを持ってくる時には、文字コードの変換とかはだいたいミドルなところがやってくれるので、気にしなければいけないのはマルチバイト文字に必要なバイト数が増える事を考慮してデータを格納する領域を確保するってことくらいかな、と普通は思うわけです。

データの中身に関する事はその程度の事でさほど問題はないのだろうけど、古いシステムの中にはテーブルとかのDBオブジェクトの名前にもマルチバイト文字が使われていたりする。
テーブルとかDBオブジェクトを作る際には、その名前に漢字とかひらがなとかのいわゆるマルチバイト文字は使わずに、半角英数字と若干の記号のみを使うべきとは昔から言われているよね、というのが私の印象ではあるのですが、実際のところ物理名にもマルチバイト文字を使っているレガシーシステムはまあまああります。
そのようなシステムからDBリンクで接続してデータを持ってこようとした時に問題が起きる可能性がある。

OracleはSQLの構文としてDBオブジェクト名は30バイト以内という制限がある。
SJISだと漢字やカナなど2バイトで済むのでテーブル名などにマルチバイト文字を使った場合15文字まで使えるということになる。
しかし、UTF8では漢字とかカナは3バイトが必要になるので、SJISの旧システムと同じ名前ではDBオブジェクトが作れない、ということになってしまう。
新しく構築するんだから物理名にマルチバイト文字なんか使わなければよいのですが、データを移行する為に新しいUTF8のDBからDBリンク経由でSJISのDBに接続してデータを持ってこようとした時に、UTF8のDB上でアットマークをつけてDBリンク先のSJISのDBのテーブルにアクセスしようとすると、UTF8としての30バイトの制限に引っ掛かってSQLが構文エラーになってしまいます。
「DBリンク先の文字コードがSJISだからUTF8としては長い名前だけどもOK」みたいな気は使ってはくれないわけです。

対応策としてはテーブル名やカラム名、その他DBオブジェクト名のバイト数がUTF8にしても30バイト以下になるように、SJIS側のDBにビューとかを作るって事になると思います。
内容や元々の名前がわかるように短縮した名前をつけるとかって、対象のボリュームにもよりますが、結構地味にダルい話だと思います。
まあ、パフォーマンスとか考えて許容されるのであれば、DBリンクを使わないでファイル渡しする、とかでもよいのかもしれませんけどね。

個人的には最近こんなのばっかりで慣れてしまった。
物理名に漢字とかひらがなで日本語を使われていると、ブラックボックスなシステムの中を調査する上ではとっつきやすいのですけどね。

やっぱりそういうDBの物理名にも漢字とか使っているシステムって、COBOLの影響なんのかな?さらにもっと昔にはCOBOLとかでシステム構築していた人たちが90年代のオープン化の流れで技術領域をシフトさせつつ作ったのかな?とかとか思ってしまいます。すごい偏見だけど。


経費で落とせるとか、落とせないとか

別にあえてこういう本を読もうと探したわけではないんだけど、ちょうど独立して経費処理の自分なりのルールを確立しようと色々と考えていたところに、なぜかAmazonのレコメンドに出てきたので勢いでポチッとしてしまった。
この手の本がたくさんある中で、なぜあえてこの2冊かとか、特に意味はありません。なんとなくで。

経費で落ちるレシート・落ちないレシート
梅田 泰宏
日本実業出版社
2013-12-21






それぞれ、『経費で落ちるレシート・落ちないレシート』は税理士、『あらゆる領収書は経費で落とせる』は元国税調査官と、それぞれの立場や経験に基づいて事業における経費処理の考え方を説いていて、タイトルから想像できる通り個人事業主とか中小企業向けの節税対策本。
元国税調査官の方はタイトルが明らかに釣りですが、どちらも基本的な考え方は概ね同じで、要するに「事業に関係のある支払であることが説明できれば経費にできる。」という当たり前のことであったりする。
で、それぞれに具体的な事例を提示しながら個々のケースを説明しているという感じ。

各論では正反対の事を言っている所もありますが、福利厚生費の扱いとか。
なので、実際のところはやはり自分の実態を踏まえた個々のケースについて税理士に相談するのがよいのだと思います。

それから『あらゆる領収書は~』の方は初版が2011年ということで若干情報が古い所があるな、という事があるのと、「税金払うくらいなら経費として使っちまえ!」的な発想が散見されるのが、なんだかなぁ、と思ったりもした。

一応、この数ヶ月で私が自分自身の経費処理をやりながら色々と見聞き考えてきた事の答え合わせになった感じでもあります。
合計金額と但し書きだけの領収書って、むしろ詳細を隠す効果があって、ある意味で「経費処理しやすい」とか思っていたんですが、税務署的にはそういう領収書よりも、いわゆるレシートの方が何を買ったか明細がわかってむしろいい、とかいう話が確認できたりとか。
サラリーマンとして経費精算している時は「常識」と思っていた事が、税務的には実はそうでもないということがいろいろあるとか。もちろん、税務署的にOKでも、会社の社内規程的にNGなケースも多々あるとは思いますが。

こんな感じで法人税とか所得税とかグレーゾーンがいっぱいな状況を見ると、より明確で公正に課税・徴収できそうな消費税とかにシフトさせた方がよいんじゃないかな、とか思ったりする。ちょうどこの4月から消費税の税率アップしたところで、それはそれとして別の問題はあるとは思うけど。
あえてグレーゾーンがそれなりにある事で、官僚の裁量でどうにでもできる部分を確保しているという面もあるのかな、という気もするけど。

だからなのか、『経費で落ちるレシート~』の方では細かいテクニック以前に税務署に対する「心象」を悪くしないようにしよう、という主旨の話だとか、税務官によっても対応が違うという話とかもあったりする。

ともかく、一応の指針とか慣例も含めてのルールはあるわけなので、それを自分自身の実態に即したルールに落としこんでルーチン化していくだけの事だと思います。
ちゃんとやらないと相当な金額にハネてくるからやりますけど、そもそも本当はこんな事には時間かけたくないですからね。

賃貸住宅の家具転倒防止対策

2011年の震災以来、地震対策の一つとして、タンスとか本棚とか背の高い家具の転倒防止対策を考える人が増えたんではないかと思います。

普通に考えれば、壁にビス留めすればよいのだと思いますが、壁に穴をあける事になるので、賃貸だとちょっとね…と気にする方も多いようです。
そこで粘着式なら壁に穴をあけなくてよいので「賃貸でも大丈夫」みたいな話もあります。
まあ、何にもしないよりはマシなんでしょうけど、あれは壁紙に貼り付けている事になるので、実はあんまり意味がないみたいです。
実際に旧宅で使っていて先日の引越でわかったのですが、普通に人の力でべりっと周辺の壁紙ごとはがれてました。
退去に立ち会ったメンテ会社の方も同様の主旨の事をおっしゃってました。
で、そこはもちろん原状回復の補修対象で壁紙貼り替えになるわけですが…

そんなわけなので、「賃貸だから」と変な気を使う事なく、穴あけてビス留めしてしまうのがよいと思います。もちろん、原状回復で自己負担する前提で。
先日の引越し後の私の家ではコンクリートの壁が結構あって、さすがに自分では無理だわ、ということで、管理会社及びメンテ会社に相談したところ、工事費と原状回復費用を自己負担するならいいよ、って反応だったんで、一式やってもらいました。

原状回復といっても、たぶん壁紙貼り替えとプラスアルファくらいだと思います。
壁紙の貼り替えだったら最近は賃貸住宅の紛争防止条例とかなんとかで、通常使用による損耗分は家主の負担になります。
通常使用による損耗分ってどうやってわかるのか?ってのがよくわからないかもしれませんが、これはもう決めの問題として割り切りでしかなくて、所定の想定使用年数から実際の使用年数の割合で計算するってだけのことです。
減価償却とかと似たような考え方だと言えばわかる人もいるでしょう。壁紙自体は減価償却とかしないので、厳密には違うんだけど。

で、要するに長く住むほど、家主の負担分が増えていく、ということです。
そして、たいていは敷金払っているだろうから、その範囲で問題なく賄えるでしょう。
まあ管理会社とかオーナーによっても色々とあるとは思いますし、また条例自体は東京の事ではありますが、一般的にも何もかも借主負担にはできなくなっているのはもう何年も前からの事と思います。

ともかく、地震対策ということなので管理会社に相談すれば、むげにダメとは言わないと思うので、必要と思うののなら勝手に悩まずに聞いてみればいいのだと思います。


e-taxで確定申告(2013年度)

ようやく今回の確定申告を一通り終えました。
今回は年末ギリギリのところで、退職と個人事業の開業などがあって、一応は青色申告をすることになっていた事もあり、さらに法人化を進めている関係で何をいつどこに計上するのかとか、申告前に事前に整理するのがいろいろ大変というか面倒くさかったです。

国税庁の確定申告書等作成コーナーは結構色々変わってた気がする。
一応はユーザビリティを向上させるとか、入力ミスや勘違い入力よる誤入力を減らす為にいろいろ考えた結果なんだろうなというのは、なんとなくは伝わってきました。
だからといって、特に使いやすくなったとも思いませんが。。。

医療費明細をExcelでアップロードできる機能が昨年から追加されていましたが、そのフォーマットが微妙に変わっていて、日付の年と月と日を分けて入力するようになっていた。
たぶん日付の入力書式の事だと思うけど、「分かりにくい」という意見が多かったから、とのことですが、私個人的には「余計なお世話」という感じでむしろ使いづらくなった感がありました。
そもそも病院等の名前より所在地が先に(左側に)あるとか、項目の並びがあんまり自然じゃない気がするんだけどな。
何考えてるんだろ?何か理由があるんですかね?まあ、いいか。

そう言えば12月に開業届けを出す際に、わざわざ税務署まで行って「相談」という形で色々質問したんですが、暇な時期だからなのか、結構丁寧に対応してくれたな、という印象はありました。
ちょうどその時期に引越関連の手続きを含めて、様々な「お役所」を回っていた事もあって、他との比較もあって印象的でした。
まあ、回答内容はあくまでグレーな感じが多いのですが。

ここにきて会社の税務とか含めて、色々と見聞きするようになって、今まで見えていなかった「しくみ」がまたちょっとわかってきた気がします。

本ブログPVが激減しております

もともと大したアクセスのないブログではありますが、それでも平日には過去のORACLE関連の記事を中心にポツポツとアクセスがある感じだったのが、ここ最近はそれもなくなって、全くPVがない日も珍しくない感じになっています。

なのでGoogleさんでエゴサーチしてみると、このブログは全くと言っていいほど検索結果に出てこない。
まさかこれってあの「グーグル八分」とかいうやつか?なんかまずいことしたのか?とか一瞬思いました。
URLそのもので検索してみた時だけ、とりあえずトップページ自体はかろうじて出てくる感じで。

で、たぶんですが、そもそも先日URLを独自ドメインに変えたせいかではないかと思いました。
元々それなりに特定のキーワードでは検索上位に出ていてそれなりに「実績」のあった記事でも、そのURLはそもそもネット上に存在しないURLになってしまっているわけですからね。
一応、古いURLでもlivedoorが転送してくれているので、アクセスはできるはずではあるのですが。
それはあくまで固定で古いURLにリンクが貼られていてもOKという事なのかな、と。

なんかBingの方は新しいドメインのURLで個別記事も検索結果に出てくるようです。なので、また時間がたてば解決するかもしれません。

別にアフィリエイトで稼ごうとかしているわけでもないので、まあどうってことない話ではあります。
ただ、PV実質ゼロが何日も続くとさすがにちょっと寂しかったですが。

プレ幼稚園の申込で早朝から並んだ件

子どもが今年3歳で、5月から週1回のプレ幼稚園に行くということで、その申し込みが先日ありました。
実際にやってみていろいろわかったけど、これが何かに活かされることはないのだろうなぁと思いますので、今後同じような状況で何かの拍子にこの記事読んだ人の参考にでもなればと思います。

朝10時から先着順受付ということらしいんだけど、妻が事前の説明会に行ったりとか、いろいろと情報収集した結果として、希望の曜日を確保するために申込の日は朝5時に並ぼう、ということになりました。あ、もちろん並ぶのは私一人で。

当日はちょっと起きる時間を間違って5時に家を出るくらいの時間になってしまいましたが、ともかく自転車で現地に向かいました。前日の夜に地図で道を調べていたのだが、まだ暗い時間だし確実に迷わない道でと考えて、一番近道というわけでもなかったので、現地には5時半くらいに着いた。
既に幼稚園の門の外側に10台くらい自転車が駐めてあって、あぁ本当にやっているんだって思った。
私も同じように並べて自転車を駐めて、門の端の通用口っぽい所を開けて中に入る。
後で気付いたんだけど、日中でも門は普通は閉まっていて自転車はその通用口で出入りしているようなので、最初から自転車も中に入れればよかったらしい。

受付手続きを行う事になっている建物の方に向かうと、灯りが点いてる部屋があるのでそこに近づいて行ってみる。そしたら「中でお待ちください」という旨が書いてある!なので中に入ると、超暖房が効いててあったかい!で、ドアを開けてすぐの所のテーブルに先着順に名前を書くボードが置いてある。どうやらこのボードは整理券をもらうための順番らしく、整理券が配られる時間にいないと無効らしい。で、整理券がいつ配られるのかはよくわからないので、そのままその部屋で待つ事に。
とりあえず、「並ぶ」と言っても真冬の寒い中、外で待つわけではないという事がわかって安堵。よかったー。

ボードに書いた順番は20番目だった。部屋の中を見ると、そういう状況になるのがわかっていたらしい感じでトランプか何かで遊んでいたり、ひたすらおしゃべりしてるママ友集団が部屋の真ん中辺りのテーブルに陣取り、周辺のテーブルや椅子には私と同様に一人で来たパパ達が座っている感じだった。私も端っこの椅子に座り、まずは用意していたお茶を飲んだりドーナツ食べたりして、後はiPhoneでいろいろ見ながらひたすら待つ。

6時50分を過ぎたくらいかな?幼稚園の人が来て、とりあえず門の外に駐めてある自転車を中へ入れろという。なので、私も含めて自転車の移動に。その後、園長だというおじさんが来て整理券を配るという。
一番の人は前日の夜にとりあえず名前だけ書きに来て帰って朝は6時半過ぎに来たらしい。この流れが事前にわかっていたら、まあそうするよなぁと思ったが、ともかく整理券もらったら一旦解散ということで家に帰る。どうせすぐ帰ることになるなら自転車を中に入れなくてもよかったんではないかという気もするが。

一旦家に帰ったけど、また10時の受付開始に間に合うように行かないといけないということで、ちょっと仮眠を取りつつ9時過ぎくらいに家を出る。
もうちょっと近道がありそうだなと調べておいたら、さっきよりも7、8分早く着いた。で、10時の受付開始を待つ。

こんだけ並んだりしてても、縁故入園(卒園・在園者の兄弟など)の方が優先らしいですが、まあともかく希望の曜日で申込ができました。



「SIガラパゴス」のERP導入における問題点

朝の電車の中で何気なくTwitterでつぶやいたら、記事の筆者ご本人に反応して頂きました。

記者の眼 - 「SIガラパゴス」を育んだIT部門の罪:ITpro

この話はもう何周目かな?と思うくらい、何度もグルグル回っている感もありますが、同じような主旨の話でも繰り返し訴えていくということも必要だと思うし、そういうお立場でもあると思うので、それはそれでいいと思っている。

私はフリーになってこの辺のテーマからは「斜め」方向に行ってしまったわけですが(斜めの上か下かはわからないw)、この記事を読みながらも、記事の論旨とは違う観点で思った事があるので、その辺りをメモ程度に書いておこうかと思います。

記事中で「ERPレガシー」という事に触れらている。
私もその「ERPレガシー」の作り込みに関与してきたと言える。
アドオンたくさん作ってきたな~と。まあ、それが仕事だったし。 

その点に関しては、記事のテーマにある通り、 ユーザ企業側の問題が一番大きいとは思うけど、長年ERP絡みのプロジェクトの現場にいて、それとは別の問題が2つあるなと考えてきた。

1つ目はERPのいわゆる「導入コンサルタント」の問題で、ちゃんとしたスキルとマインドを持った人が圧倒的に不足していると思う。
ERPパッケージの標準機能、業務プロセスを「そのまま使う」といっても、実際にはどこのセットアップ項目をどのようにセットアップして使っていくかということにはいろんな工夫の余地があると思っている。
だけど、できるだけちゃんと標準機能を使うようにしよう、という工夫をしようとするって事がない、そういうふうに考えられる人って少ないよな、と。
まあ、「標準機能じゃできませんね」ってことでアドオン化した方が商売になるっていうSIer側の事情も絡むのだとは思うけど。
そしてどうしてもなんらかのアドオン/カスタマイズは必要だとなったとしても、ただ普通に機能要件を実装するだけじゃない工夫の仕方がパッケージの場合はあると思うんだよね。

もう1つの問題は「スキルのある人材不足」とは裏返しとも言える話で、ERPパッケージをうまく使いこなす為に「コンサルタント」と称する高度なスキルのある人が必要って事は、そもそもERPパッケージ製品自体がまだまだイケていないんだと思っている。
色々と進化はしてきていると思うんだけど、難易度としてはむしろ上がっていると思うんだよね。

「各種セットアップをして標準機能だけで出来ます」とか言っても、実際のプロジェクトの現場でちゃんと動くようにするにはえらい大変だったりする。
ほとんどプログラミングしているみたいなものだと思う事があるけど、普通のプログラムみたいにエディタ上にシーケンシャルにロジックが見えるわけではなく、普通にプログラムを書くよりもむしろ難易度は高いと思える事もある。
それをプログラムを書かない(書けない)「コンサルタント」が対応しようとするものだから、そりゃあ炎上しますわ。。。

そんなわけで、もっと「簡単に」使えるようになる業務アプリケーションパッケージが必要なんだと思うわけです。

繰り返しますが、元記事の論旨とは違う観点の話をあえてしています。
ERPでサポートする業務プロセスがベストかどうかは本質的な問題ではなく、一つの標準プロセスに整流化することで、重複業務のカットなどの効率化を図り、一般管理費を下げることを目指す。
これ自体には基本同意していますので。
今現在あるERPがベストでないにしても、導入すると決めたからには今あるものを受け入れて、その中で工夫すべきだと思います。

時間がないので、この辺の話はまたあらためて考えてまとめてみたいと思います。

記事検索
livedoor プロフィール
Twitter
AdSense
Amazon


  • ライブドアブログ