令和元年８月２日
お客様各位
バリアントソフト株式会社
拝啓 盛夏の候、ますますご盛栄のこととお慶び申し上げます。
平素は格別のお引き立てを賜り、厚くお礼申し上げます。
さて、弊社では下記期間を夏季休業日とさせていただいております。
休業期間中は、何かとご迷惑をお掛けすることと存じますが何卒ご理解とご了承いただきますようお願い申し上げます。
敬具
記
【夏季休業期間】
令和元年８月１３日（火）～令和元年８月１５日（木）
※８月１６日（金）からは通常どおり営業いたします。
あるアプリで二段階認証を行わなかったために現在も問題となっています、今回は二段階認証について記事を書きます。
二段階認証とは、新規登録の場合とパスワードなどの変更の時に、登録した電話番号にSMSを通じて暗証番号を送信して、入力させるなどの方法によって認証を行うシステムです。
ID・パスワードが一段目の認証システム、SMSを使った暗証番号による認証が2段目の認証システムと、二段構えでセキュリティを確保するということで二段階認証と呼ばれます。
例え、二段階認証が行われていたとしても安心は出来ません、様々なケースで悪意のあるアクセスがあります、そしてパスワード等が流出した場合は大きな被害になります。
どうかID・パスワードは流出しないように、また複雑なパスワードを設定して頂ければと思います。
サービス等生産性向上IT導入支援事業費補助金審査委員会による
２０１９年 ＩＴ導入支援事業者に採択されました。
https://www.it-hojo.jp/
WEBアプリケーションやホームページでデータを更新してアップロードしたのに画面をみたら前と何も変わっていない事があります。
その場合はキャッシュを削除してみると良いです。
一番簡単なキャッシュの削除方法はCtrlキーを押しながらF5キーを押ことです。（※ブラウザ毎に操作が異なります。）
他にもChomeとかならページ右端の設定から閲覧履歴の削除でキャッシュを削除する項目あるので探してみてください。
高校でeポートフォリオを導入している学校が
増えているという記事を読みました。
今後も増えていくことが予想されますが、
生徒が積極的に入力するかが問題でしょうね。
小学校の「プログラミング教育の必修化」この言葉をつい最近まで勘違いしていました。
ネットやパソコン教室のチラシでもプログラミング方法について
いろいろな内容のものは目にしてましたので、てっきり新しく科目が
できるものだと思っていました。
実際には算数や理科等、今の教科科目の中にプログラミング（考え方）を取り入れていこうという
趣旨のもので単純に「プログラムを書く」というものではなさそうです。
既に授業での活用も行っている学校もある様で、レゴの振り子ロボットを理科の授業で
使用し、プログラミングをしてロボットの動作を実験結果としてグループ発表するという
事を行ったそうです。
実験の計画を立て、プログラミングを使用した実験を行い、その結果を発表し合う
ということでアクティブラーニング中にプログラミングを組み込むという事を実施したそうです。
各教科の授業計画の中にアクティブラーニングの活用を考えかつ、更にはプログラミングの
組み込みも考慮しないといけないとは！・・・・・小学校の先生って大変ですね。
我が娘も小学２年生ですが、担任の先生には頭が下がる思いです。
Microsoft 製品のOS(Windows Server 2008)のサポート期限が
2020年1月14日と迫っており、最近は各学校様から新しいサーバー
に関するお問い合わせが多くなっております。
そしてサーバーの他にも、各部署やご家庭でよくご使用されている
「Windows 7」もサポート期限が2020年1月14日となっております。
既に新しいサーバー等への移行がお済みの学校様も増えてきておりますので、
もし、新しいサーバー等への移行等をご検討されていらっしゃるようでしたら、
いつでもお気軽にご一報を頂ければと思います。
OracleからPostgreSQLへのデータ移行 – 1.型指定 であらかたデータ移行はできましたが、次に問題になったのがバイナリデータでした。
最初にORA-24345エラーが発生。これについては ORA-24345 が発生するならこのディレクティブを1にしろ、と書かれているLONGTRUNCOK 1を設定することで解消しました。オンラインドキュメントではLONGTRUNKOK になっていますが、configファイルでは LONGTRUNCOK です。
そしてblobカラムに格納されていたデータが、一見移行できているように見えて途中で途切れているなどの問題が発生しました。
LONGREADLENに十分なサイズを指定することで解消しますが、余り大きくすると今度はOutOfMemoryが発生してしまいます。
OutOfMemoryを防ぐにはDATA_LIMITを小さくすれば良いのですが、そうするとデータ移行に時間がかかるようになります。
これらを踏まえて、1レコードあたりのデータサイズが大きなテーブルとそれ以外のテーブルについて出力を分けることにしました。
1レコードあたりのデータサイズの大きなテーブルをカンマ区切りでリストアップ。configファイルを二つ作り、一方には先のテーブル名をEXCLUDE に指定。もう一方には ALLOW に指定します。
ALLOW に指定した方のconfigではLONGREADLENを大きくとり、DATA_LIMITを小さくします。
これで通常のデータについては移行を手早く、サイズの大きなデータについてもエラーを回避し確実に移行できるようになりました。
弊社でもOracleからPostgreSQLへの移行作業を行うことがあり、データ移行には定番でしょうが ora2pg を使用しています。
基本的にドキュメントのとおりに実行知ればデータ移行が完了してしまう優れものですが、いくつかハマったポイントもあるので書いてみたいと思います。
ちなみにLinuxで動作させる方が多いかと思いますが、ActivePerl をインストールすればWindowsでも問題もなく動作します。
ActivePerlのインストール後にパッケージマネージャでdmakeをインストールし、ora2pgのソースコードを適当なフォルダに展開、コマンドプロンプトからperl .\Makefile.pl して dmake installで終わりでした。
Oracleクライアントのインストールの手間を考えるとWindows環境で実行する方が簡単かもしれません。
さてora2pgでのデータ移行ですが、とりあえず接続先情報以外はconfigをそのまま使用して移行してみたのですが自動で行われた型指定とプログラムの動作に問題が生じました。
例えば、NUMBER(4,0)等がsmallintで移行されてしまいます。これが.NET Framework2の頃に作成された、SELECT結果を DataTable に格納、そのまま DataGridView にバインドしているようなプログラムで問題になりました。intを想定していたものが PostgreSQL+smallintだとshortになっており、DataErrorイベントが発生することに。
これをデータベース側で回避するとした場合、ora2pgのコンフィグファイルで変換する型を指定することになります。DATA_TYPE項目ですね。
Oracleの型:PostgreSQLの型, Oracleの型2:PostgreSQLの型2… のように指定するだけですが2つほどポイントが。
一つは、精度指定のカンマをバックスラッシュでエスケープすることです。これは公式ドキュメントのDATA_TYPEの項目にもしっかり書かれているのですが、読み飛ばしていたため、スクリプトで型変換リストを作成した際にハマってしまいました。
二つ目は、精度指定で小数点以下桁数が0の場合にはカンマ以降が不要という点です。公式ドキュメントの例に DATA_TYPE NUMBER(*\,0):bigint という記述があり、これを参考に NUMBER(4\, 0):integer と書いたのですが numeric(4) に変換されてしまいました。
最初、指定が反映されない理由分からず悩みましたが、実はNUMBER(4):integer のようにカンマ以降が不要でした。
数値データの取得後、プログラム上での扱いについては他にも小数点以下が全て0の場合に10 になるか 10.00 になるかといった問題も発生しました。これについては弊社ではプログラム側で対応しました。
友人がFaceBookで記事にしていた内容をシェアします。( S.Sさんありがとう。)
本文の文言はオリジナルのappleからのメールをそのまま使っているので、文章が怪しい日本語ではないので一見普通ですが、本文中のURLにマウスカーソルを重ねると、リンク先がapple.comではありません。また、apple.comのサーバーから送られていないので、Message IDという各メール個々に付けられる一意な文字列が全然違うドメイン(bestgroup.jp)になっています。
パソコンでメールのヘッダーまで見られる場合は、Receivedヘッダー、DKIM-Signature、Return-pathなんかも判断基準になります。この例は正しいメールのもので、昨日届いた詐欺メールにはDKIM-Signatureは無く、Receivedヘッダーには、bestgroup.jpのサーバーから送られたものだということが記録されていました。
あと、結構見落とされがちなのは、本文中に埋め込まれた画像を表示するしないですかね。画像って、メールに添付されてくるものと、インターネット上にあるものを埋め込んで表示するパターンがありますけど、本文中のURLをクリックしなければ画像を表示するくらいは無害だろうと思うのも危険ですよ。本文に埋め込まれた画像はWebビーコンといって、画像のURLに「誰に送ったメールを経由して開かれたか」がわかる細工がしてあります。つまり、サーバー側でログを見ると誰がメールを開いたかがわかってしまうので、騙せる可能性がある宛先としてキープされて、今後もことあるごとに色んな詐欺メールが届くことにつながります。Webビーコンは1ドットだけの画像の場合も多くて、目に見えるとは限らないので、メール本文の画像は表示しないに越したことはありません。
