ITコーディネータの
9月にJava SE 11がリリースされました。
これ以降は業務や商用で使用するには
有償のライセンス契約が必要になりました。
今回はこの問題を取り上げたいと思います。
ITコーディネータの
9月にJava SE 11がリリースされました。
これ以降は業務や商用で使用するには
有償のライセンス契約が必要になりました。
今回はこの問題を取り上げたいと思います。
ITコーディネータの吉田聖書です。
近年、IT人材を増やそうということで
小学校、中学校、高等学校でのプログラミングの授業が
必修になることはすでに皆さんご存じのことと思いますが、
小学校は2020年から必修科目になります。
ITコーディネータの吉田聖書です。
先日，IoT＋AIのもくもく会に参加してきました。
「もくもく会」というのは耳馴染みのない言葉ですよね。
勉強会というと主催者がテーマを提示するケースをイメージしますが，
もくもく会の場合は，大きなテーマ、分野は決まっていますが
その時その場で具体的に何をやるかは決められていません。
自分の興味のあるテーマについて調査したり試作したりといった作業を
持ち寄って，ただ黙々と行うというだけの会です。
ドイツの大手自動車メーカーであるフォルクスワーゲン社（VW社）の排ガス不正問題はまだ真相究明に至っておりませんが、最初にニュースを聞いた時には正直驚きました。それは「あのVW社が」というポイントであって規制逃れの手法そのものに驚いたわけではないのですが、そうこうしているうちに、今度は横浜市のマンションの傾きの発覚により施工データの偽装が明らかになりました。いずれもまだ問題の全容が見えていない段階ですので詳しい言及は避けますが、なんとなく似たような臭いを感じます。
特にVW社による不正の類は、IT業界では大なり小なり割とある話なのではないかなと思います。VW社の場合は市場に出してしまったのでかなり大きな問題になっていますが、リリースまでには直す前提で、例えば工程完了判定をパスするために不具合があっても検査に合格したことにするということは、実際にやるかどうかは別として簡単に出来そうなものです。ですので、テスト結果を鵜呑みにするのではなく、あるいはテスト結果だけを評価するのではなく、どのようにテストしたのかというテストのプロセスを評価するような仕組みが必要になってきます。
あるシステム開発でテストの自動化を導入した時のことです。開発チームではメンバー間で生産性や品質にばらつきがあるのは普通のことですが、全体として短納期で高品質を求められた結果、あるメンバーはそれがプレッシャーになったのか自動テストのコードはスカスカで、本体のプログラムは全くダメという状況に陥ったことがありました。この時、自動化したのは単体テストのみで、結合テストは通常通り手動で行うことにしていたのですが、単体テストの時はテスト結果が毎日OKとなっていたので問題ないように思われたのですが、結合テストになって初めてその品質の悪さが露呈したのです。この時はその人の書いたプログラムはほぼ作り直しで、納期には何とか間に合ったものの、当人以外のリカバリーを担当したメンバーは大変な思いをしました。
テスト駆動開発という開発手法も存在しますが、いずれにせよ合否の基準が最初から決まっている場合、エンジニアはその基準に合わせて開発を行う傾向があります。これは何もシステム開発だけではありません。会社の人事評価も同様です。会社が良かれ悪しかれ定めた基準によって、社員はその行動パターンを決定します。例えば、基本給は横並びだけど持っている資格に応じた手当を継続的に出すよということにしたとしたら、多くの社員は本業はそこそこに就業時間中に資格取得のための勉強に励むでしょう。
話を戻してソフトウェアの場合、予めテストの合否基準が決められていることで、効率的に開発を進めることができる部分があるのかもしれませんが、それで全てがうまく行くわけではないという至極まっとうな教訓が得られました。チーム全体が意欲的な場合にはうまく行くが、そうでない場合は特に、人には失敗を隠そう、ごまかそうとする性質があります。VW社の不正も環境負荷の少ないエンジンが供給できず、それを隠すために不正なソフトウェアを組み込んで試験を通そうとしたようですし、施工データの偽装も担当者が失敗を隠すためにデータを偽装したとの報道がなされました。今後全てのことが明らかにされた時、また新たな教訓が得られることと思います。
—-
拙作ソフトが書籍で紹介されました！
先日12/13に学研パブリッシングより発売された「エクセルパーフェクトテクニック350+α完全保存版」という書籍に「クロスラボラトリー」ブランドのソフトウェアが紹介されましたのでお知らせいたします。私にとってはちょっとしたクリスマスプレゼントになりました。
今回掲載されたソフトは、以前の「JPEG Image Filer」ではなく、Microsoft® Excel® のブックファイルの全シートの表示形式と表示倍率を揃え、かつ、全シートのA1セルを選択した状態にし、更にはブック中の先頭シートを選択した状態にする「Xls/xlsx File Unifier」というソフトウェアです。
「JPEG Image Filer」とは異なり、プライベートユースではほとんど使う局面はないと思うのですが、逆にビジネスユースではそれなりに使う局面があるのではないかと思っています。というのも、Microsoft® Excel® ブック形式のファイルを納品物や情報資産として利用する場合、ファイルを開いた時に不適切な位置が表示されてしまうと格好悪いので、ドキュメントの最後の仕上げとして体裁を整える作業を行うということがあると思います。そういった利用の仕方をする場合、対象のブックファイルが1つや2つではないので、それらを1つずつ開いて確認しながら直していくのは大変です。このアプリを使うことでその作業を軽減することができます。
「JPEG Image Filer」の場合は、いくつかのサイトが取り上げて使い方を紹介してくださっていますが（ありがとうございます）、「Xls/xlsx File Unifier」はそういったサイトは今のところ見当たりません。にもかかわらず、こうして書籍に掲載してくださったことはとても嬉しいことだと思っています。
この書籍は、データ分析やピボットテーブルなど、私もExcel®についてまだそれほど使いこなしていない機能についての解説も豊富で、せっかくなので私も本書を使って勉強してみようと思いました。Excel®は道具として使いこなせればビジネスでもかなり役に立ちますので、このような参考書をお持ちでない方は是非1冊手元に置いてはいかがでしょうか。
—-
書名：エクセルパーフェクトテクニック350+α完全保存版
発行：学研パブリッシング／2014年12月13日
ISBN：978-4056107302
以前このブログでも書いた「クロスラボラトリー」ブランドのソフトウェアですが、本日10/24発売の日経PC21・2014年12月号にて紹介されましたのでお知らせいたします。
今回掲載されたソフトは、JPEG画像のExif情報に含まれる撮影年月日を利用して日付ごとのフォルダに振り分ける「JPEG Image Filer」というソフトです。最近のデジカメだとそのように撮影日ごとにフォルダわけしてくれるユーティリティが付属していると思いますが、古いデジカメに付属していたソフトではそのようなことが出来ず、カメラからPCに取り込んだ日付でしかフォルダを作ってくれなかったため、整理するのに困って作ったものです。普通のWindowsアプリではありますが、「クラウドで写真管理」という記事で紹介されています。
ところで、このソフトは特にこれといった宣伝活動はしていないのですが、気付いてみたら知らないうちにいくつかのフリーソフトの紹介サイトで取り上げられていて、しかも弊社で提示している説明よりも詳しく、かつ分かりやすく使い方や特徴を掲載していただいており、マイナーながら少しずつ利用者が増えてきているようです。それに伴い、サポートサイトやメールにて感想や要望を頂戴することが増え、徐々にではありますがリクエストに応える形で改良を重ねてきました。
必ずしも全てのリクエストにお答えできているわけではありませんが、
今後とも一層のご愛顧を賜りますようお願い申し上げます。
久しぶりにプログラミングの話を書いてみようと思います。プログラミングの割と初歩的な話なのですが、プログラムを作っていく工程には「デバッグ」というものがあります。
要はプログラミング作業のミスによって生じるエラーをバグ（＝虫）に見立て、プログラムを修正することによってエラーを解消することをデバッグと表現するのですが、スキルがあるレベルに達するまではこれが非常にきつい。何故かというと修正しても修正してもなかなか自分が思ったとおりに動いてくれず、時間ばかりが過ぎていくということが起こり得るからです。それに加え、プログラムをコンパイルした時や実行した時のエラー表示が、まるで自分を否定されたような気持ちにさせるという側面もあるでしょう。（こんなのは慣れればどうということはありませんが）
そのデバッグ作業なのですが、そのエラーを早く直せる人となかなか直せない人がいます。もちろんその差は知識や経験の差ではあるのですが、具体的にどういうところに現れるのでしょうか。
私がデバッグ作業の進まない人の仕事を見ていて気付いたことがあります。その中の一つが「エラーメッセージを読まない」ということです。つまりコンパイラやインタプリタやミドルウェアが出すエラーメッセージから「エラーを解消するために手掛かりに成り得る情報」を取ろうとしないということです。
その人は「実行したらエラーになった」「直して実行してもまたエラーになった」という程度の情報しか取りませんでした。でも私が見ていたところ、2回目に実行した時にはエラーメッセージが変わっていたのです。そこで「今、エラーメッセージが変わったことに気付きましたか？」と質問したところ「え、そうでした？」というような返事が返ってきました。
もちろん某ミドルウェアのように、非常にわかりにくい不親切なメッセージしか表示されないということもあるでしょう。でも、たとえ分かりにくくても「ある個所を直したらエラーメッセージが変わった」というのはエラーには違いありませんがデバッグを行う上では重要な手がかりです。その上でメッセージの内容を読めば、比較的容易にエラー解消に近づいていくでしょう。
このように、プログラミングのスキルというのは一朝一夕に向上するものではなく、こういった緻密な心配りの積み重ねで伸びていくのかなと思っています。
また久しぶりにデータベースの話をしたいと思います。前回は「論理削除か物理削除か」というテーマで記事を書いたらそこそこ反響がありました。こういったテーマは実際にDB設計に関わっている方でないと刺さらないのだと思いますが、そのうち入門者向けの話題も提供したいと考えています。
さて本題ですが、今回はIDの採番において私が実際に遭遇したトラブルについての話です。そもそも採番という言葉が一般的ではないのかなと思っていますが。というのも普通にPCで「さいばん」と打っても変換されないので、新しい現場へ行ってPCが貸与されると大抵この単語を辞書登録するからです。英語で言うと numbering が近いのでしょうか。別の言い方をすると発番あるいは番号の払出しといったところでしょうか。
利用するDBMS製品によってはIDの列に自動採番の属性を付与することで済ませるケースもありますが、多少癖もあるので緻密な運用を行いたい場合は自前で実装することになります。実装と言ってもそんなに難しいことはなく、IDが連番であることを利用してその最大値に1を足したものを新しいIDとするだけなのですが、その方式によっては注意が必要です。
これは設計者の好みの問題もあるのですが、テーブルの行数を見積もった時に、まあ普通に取り扱える規模であれば毎回最大値を計算して1を加算しても大した負荷にならないので私はその方式を良く使っています。一方で最大値を計算するのが負荷となるほどの行数が見込まれる場合は、本テーブルの他に最大値を管理する採番用テーブルを作ってそこで管理するケースがあります。
ある現場でデータの移行を実施した時のことです。ファイルに用意したデータ件数と、実際に取り込まれたデータの件数が1件だけ異なるという事故が起きました。あまり細かい話をしてもしょうがないのでざっくり書くと、そのシステムはWEBアプリケーションで、移行はバッチアプリケーションでしたが、両社でIDの採番方式が異なっていたためにWEBアプリで作られたデータを1件バッチで上書きしてしまっていたということが判明しました。
具体的には、WEB側では、採番用テーブルのIDに1足した番号を新しいIDとして本テーブルのレコードを作成し、その番号で採番用テーブルのIDを更新していたのですが、一方のバッチ側では、採番用テーブルのIDを使って本テーブルのレコードを作成し、そのID＋1の番号で採番用テーブルのIDを更新していたのです。つまり採番用テーブルの番号が「使っている値の最大」なのか「次に使うべき値」なのかという解釈において相違があったわけです。
例えば、WEB側でIDが1～5までのデータが作成されていたとします。そこへ移行バッチでデータを追加すると本当は次のレコードのIDは6番でなければいけないのですが、採番用テーブルのIDが5番であるために追加するレコードのIDを5番としてしまい、すると結果的に既にある5番のデータが上書きされてしまうという事象が発生してしまいました。
この話の留意点は、どっちの方式が正しいかという議論ではないというところです。よくありがちなコミュニケーション不足、検討不足の症例です。要はどちらかのやり方にもう一方が合わせていれば全く問題の無かった話です。
また、これが実際に起こった時には、移行の作業等に起因してもっと状況がややこしく、原因を突き止めるのに苦労したのですが、その移行作業の問題点というのは本題を外れるので、いずれ機会があれば書きたいと思います。データベースの話と言いながらマネジメントの話っぽくなってしまいましたね。
「クロスラボラトリー」ブランドの実績第一弾として、Windowsの.NET framework上で動作するアプリケーションを作成し、フリーソフトとして公開していましたが、この度、日本で最大級のソフトウェアライブラリであるVectorでも公開を始めましたのでお知らせいたします。
クロスラボラトリーというのは弊社の前身である個人事業主時代の屋号です。ソフトウェアの会社を離れ個人事業主として独立して10年目となりますが、古くからお付き合いのある方にとってはお馴染みかもしれません。やはり過去の屋号とはいえ愛着があるもので、クロスイデアとしてはコンサルティングやIT人材の育成をメインに据えたということもあり、弊社の「研究開発部門」のブランドとしてクロスラボラトリーの名称を今後も使っていこうと考えたのです。
一方、Vectorは大学生時代から15年以上利用させていただいているサイトで、今でもお世話になっております。そこで出会ったソフトウェアは数知れませんが、今回その仲間に加えさせていただくことが出来て大変光栄に思っております。とは言ってもやっていることはそんなにすごいことではないのですが、個人的には感慨深いものがあります。大学の研究室であるミニゲームをVectorからダウンロードして息抜きに遊んでいたのですが、社会に出てからあるプロジェクトで一緒に仕事をしているメンバーがそのゲームの作者だった、ということもありました（笑）
今回登録されたアプリケーションは以下の5個です。ちょっとしたツールなので全ての方に使っていただけるようなものではありませんが、お使いになれる方は是非一度お試しください。