日本語学校様向けの クラウド教務システム(jimmi)に出席不良(5割未満)者報告書の印刷機能が追加されました。
日本語教育機関の告示基準に基づく各種報告について の 「2告示基準第1条第1項第39号(出席率が5割を下回った生徒について)」に関する報告書を簡単に出力して頂けるようになりました。
詳細につきましては是非お問い合わせください。
日本語学校様向けの クラウド教務システム(jimmi)に出席不良(5割未満)者報告書の印刷機能が追加されました。
日本語教育機関の告示基準に基づく各種報告について の 「2告示基準第1条第1項第39号(出席率が5割を下回った生徒について)」に関する報告書を簡単に出力して頂けるようになりました。
詳細につきましては是非お問い合わせください。
日本語学校様向けクラウド教務システム jimmi に「中長期在留者の受入れに関する届出」出力機能が追加されました。
もちろん届出事由「受入れ開始」「受入れ終了」「5月1日における受入れ状況」「11月1日における受入れ状況」による対象者抽出、対象者人数による様式切替にも対応しています。
jimmiでは法務省指定様式書類への対応はもちろん、入管ごとの特定様式にも順次対応しています。
オンラインでのデモも対応いたしますので、日本語学校様向けシステムをお探しの場合は是非一度お問い合わせください。
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 になるかといった問題も発生しました。これについては弊社ではプログラム側で対応しました。
会社の前にモスバーガーがあるのですが、今朝何気なく見たらのぼりが新しくなっていました。
ライスバーガー 海老天ぷら。
それもはや「天むすび」では、と思いながらモスバーガーのサイトを見に行くと、天丼がモチーフらしいですね。でも海苔もついており、結んでないけど天むすびでした。
まぁどちらにしてもアレルギーで海老は食べられないのですが。
今日、佐賀に行った方にお土産として小城羊羹をねだってみるという会話のなかで
くろがね堅パン、くろがね羊羹を食べたことがない社員がいることが発覚。
自宅に常備している私は驚愕しました。
北九州の会社としては由々しき問題です。
オフィスグリコの横に並べておくべきかもしれません。
体組成計により、筋肉量が少ない等うれしくないことがわかったワケですが、他にも気になることがあります。
体組成計で計測した結果をスマートフォンに取り込んでアプリで見るわけですが、この「ヘルスプラネット」、使う際に自分の身長や年齢といったプロフィールを登録する必要があります。
で、その中に「身体活動レベル」という項目があり、選択肢が「高い」「普通」「低い」なんですね。そしてこの「身体活動レベル」の選択によって「体重キープの目安」カロリーが表示が変わります。
ほぼ一日机に向かってますから「高い」はない。ので「普通」か「低い」なワケですがここが問題で「体重キープの目安」カロリーが330kcalほど違ってきます。食後のデザートにロールケーキを一切れ食べても安心できるかどうか。
仕事は座りっぱなしとはいえ、毎日飼い犬の散歩でそこそこの速度で数km歩くしそんなに低くもないのでは。と思いつつ下手に安心して余分なカロリーを摂るようになっても困ります。
そんなわけで活動量計「カロリズム AM161」も買ってしまいました。メーカーの思うつぼです。
1週間ほど身につけた結果。活動量、というか消費カロリー非常に低かったです。話になりません。仕事の合間におやつ食べている場合ではないです。
北九州マラソンも近いし、私もランニングでも始めるべきでしょうか。
体組成計を買った結果、体重その他もろもろが数値で突きつけられるようになったわけですが、ある程度わかっていた事とはいえ、どうにも痩せすぎ感が。
体脂肪率が低めな点は良いとしても、筋肉、骨量も少なめと表示されると良い気がしません。そして本当に少ないのか気になります。
というわけで、どうにか他の方法で確認したいと思って考えついたのが握力計です。筋力が十分なら筋肉量が少なめに計測されても言い訳が立ちそうな気がしたわけです。
背筋力計の方がより大きな筋肉の筋力を計ることができそうですが、そこそこ良いお値段がします。その点握力計はピンキリで比較的お安い。
早速注文して計ってみました。
結果。利き手はかろうじて平均値、反対は平均値よりも10kg近く低い結果に。どうやら体組成計は正しいようです…
長く使っていた体重計のパネルが割れてしまい、体重計を買い換えることになりました。
ちょうどポイントが貯まっていたので少し高機能なモノを買ってみました。
計測結果をスマートフォンに転送でき、アプリでグラフ表示できます。
で、体重、体脂肪率はもちろん、筋肉量や基礎代謝、骨量まで判定されるんですね。体重、体脂肪率はこれまでと変化もなく気にならなかったのですが、筋肉量や骨量が「少なめ」表示され少しばかり凹みました。
釣りに行ってへばらないよう、筋力維持程度の運動はしているつもりだったのですが。
それでも数値で判定されると改善しようという気になるので悪くはないですね。