弥生開発者ブログスマートフォン用の表示で見る弥生開発者ブログ2019-12-19情シスを保守的だと誤解していた話こんにちは!弥生のいっしーです。カレンダーも終盤ですね!年末なので、ふりかえりも兼ねて、2月から所属している情報システム部での気付きなどを書いていこうと思います。New!2013年に新卒で入社し、途中まではプロジェクトマネージャー志望でした。自分で手を動かしたくなり、クラウドサービスの開発へ。さらなる修行を、ということで、これまであまり経験のなかった社内運用までを含めた開発を行う新課金チーム(情シス)に至っています。新課金チームでは、弥生のサービスの契約販売管理システムを旧システムから移行するべく、新しい画面を作ったり、バッチ処理を組んだり、契約まわりの問い合わせ対応を主に行っています。社内のIT関連で困ったときの一次受けあんまり開発してなさそうくらいの認識で、お世話になっているけれども、正直なところ何をやっているのかよく分かっていませんでした。新しいことに取り組み始めている雰囲気も感じていました。配属されてからは「開発:運用=7:3」くらいの割合で業務を行っています。開発もできる社内業務の効率化を継続して提案・実現していければ、最強の弥生を作り上げられるのではと考えています。財務経理部へ毎月の売上状況の資料提供を行ったりするなど、ビジネス施策や社内の重要業務に対応する必要があります。自分の業務がその役に立っていることをタイムリーかつダイレクトに知ることができます。相手の顔が見えた方が頑張れる人は、意外と情シスが向いているかもしれません。~過去に自分が関わった機能をいまは呼び出す側~新課金システムはマイポータルWebやMisocaとも連携するため、過去に自分が開発した機能やテストをした機能を呼び出すことがあります。そんなとき、自分の中で点と点がつながる感じがして面白く、また感慨深いです。~本番環境、めっちゃこわい~リリース等で本番稼働中のサーバーを操作したり、依頼などでデータをメンテナンスしたりするのですが、関連するシステムが多いため、他に影響が出ないかビクビクしています。1契約まわりはセンシティブな部分なので、手順書と実際に実行するSQL等は有識者レビューを行い、指さし確認しながら実施するなど、細心の注意を払っています。関連システムとの関係性を理解し、旧システムからの移行を最後までやり遂げたいです。情シスはいいぞ、という普及活動をして仲間を増やせれば、と考えています。本日19日は2019年最後のもくテク2があります!mokuteku.connpass.com課金システムの話や軽減税率の話など、盛りだくさんの内容となっています。明日は我が身...!と思いながら読んでいます。弥生が開催しているIT勉強会。木曜日にテクノロジーを語ろう、の略。Qiitaの17日目のエントリーになります。こんにちは、弥生のつじのです。普段は弥生のインフラチームで商用環境の構築・運用などを主に担当しています。Azure(以下Azure)に触れる機会が比較的多いので、Azureに絡めた話題としてAzureのOCRサービスについて紹介したいと思います。Readerの略です。画像データ内の文字を認識してtxt、csvなど文字列データへ変換する装置のことです。今回Azureで使用する主なリソースについてです。Azure内部の操作を自動実施したり、外部からのトリガーで特定の操作が可能なリソースです。GUI上からある程度直感的に処理の作成が可能です。Azureが提供しているOCRサービスです。Azure上に以下の様な環境を構築します。次はAzureのOCRの精度検証です。アップロードする画像はアドベントカレンダーなので、冬らしい和歌を調べて画像にしました。...これは...元々24文字ある和歌ですが、OCR結果内に和歌に含まれる文字は15文字しか無いですね。『朝ぼらけ』の行に関しては欠落している。この結果からAzureのOCRサービスは精度出ませんでしたで終わってはなんとも味気ない...そこで多少頭を捻り何が悪かったのか考えてみました。予測1:このOCRサービスは左から読み込み、その結果を最終的に左から横書きで出力しているように見えるので元画像も横書きがよいのでは?予測2:また選んだ書体には文字の見え方を意識した線や太さの強弱が発生してる、機械に読み込ませるならゴシックのような書体が良いのではないか?このような予測を立てた上で、一つずつ修正して結果を確認しました。書体を行書体からゴシックに変更してみます。文字単位で見れば正しく変換されていますね!しかし、行単の順番が入れ替わっており、これでは読めない。縦横を入れ替えてみるだけだとどうでしょう。『朝ぼらけ』の行は出てきましたが、文字単位では正解率では書体の変更ほど変わらないですね。最後に書体、縦横両方の変更を加えた結果を確認します。雪!?読める!間違いもなく正確に画像データから文字列データに変換されています。※今回の検証では画像の空白は考慮せず、文字サイズのみ統一しています。今回の簡単な検証の結果、文字の変換精度という観点で見ると『書体の変更>縦書き横書きの変更』、行順序の変換精度という観点では『書体の変更<縦書き横書きの変更』でした。AzureのOCRサービスに画像データを取り込む際にはゴシックのような書体で横書きが良いようです。(書いてみると当たり前ですが...)しかし文字精度に書体が影響するのはわかるのですが行順序については、OCRサービス側でどのようなロジックとなっているのかもう少し検証してみたいと思います。OCRサービス側で前後の行と意味のつながりを意識していたりするのかなど。Igniteにて機械学習に力を入れていくという発表があり触れてみたいと思っていましたが、このアドベントカレンダーが良いきっかけとなりました。Azureには引き続き新しいリソース機能がGAされてゆくと思いますので、置いて行かれないようこまめに新しい情報に触れていきたいと思います。去年のアドベントカレンダーも12/17に記事を書いたので、それから色々あったな―と思い返して楽しく記事を書いてました。18日目は、mugi_unoさんです。16日目エントリーです。初めまして、弥生のエンジニア、肥後です。給与チームのエンジニアをしております。弊社のデスクトップアプリケーションはC++ネイティブとC#のコード双方を利用して開発を行っています。このうち、C++ネイティブのコードからC#のコードを呼び出す際、ちょっとハマった点についてここで記載させていただきます。そもそもやろうとしていたこと弊社の某アプリケーションでコードクローンが見つかったため、『その解消できそうかとりあえずやってみてくれ』とのお達しがありました。モジュール構成は以下の通りです。実際開発に苦労してた時期だったからしゃあないなぁ、とか思いながら、クローン元を確認しつつ、該当箇所をDLL呼び出しに変えて動かしみました。クローンの置き換えだけだから問題ないよね~、ポチッとな。Studioコンソールを確認したところ、EEFileLoadExceptionが出ているとのこと。どこで落ちてるのかをステップで確認したところ、以下の『暗号化ユーティリティ』が見つからない模様。マネージド(C#)さて、どうする?MSDNなどで明確には記載されていないけど、どうやらマネージドのモジュールはそのままでは常に実行モジュールとサイドバイサイドでなくてはならない模様です。stackoverflow.comこれを回避するためにはリフレクションを使用して動的に処理を呼び出す必要がありますが、ここに記載された内容を見ると、それを使わなくても回避できそうな方法がある様なので試してみました。NGorzさて、どうする?(その2)マネージドコードでフォルダまたぎでどうにかアクセスさせるとなれば、後はリフレクションを使用する方法が考えられます。処理を実行する毎にDLLの読み込みが発生する訳でして、当然ながらパフォーマンスの劣化は避けられません。暗号化ユーティリティはテーブル内の文字列項目へのアクセス毎に呼ばれるので、その影響は、大げさな話ではなく計り知れないものとなります。以下、簡単なプログラムで実例を示します。この例ではプロパティの情報しかAssemblyLoaderUtilで取得していませんが、メソッドの情報を取得する様に使用を拡充することでもう少しやりたいことの幅は広がります。※動作確認は行っていますが、コードの内容を試す場合は自己責任でお願いします。コメントでも少し触れていますが、C++ネイティブに対して公開するヘッダファイルにはC++/CLI固有の定義やヘッダファイルのインクルードは記載しない様にしてください(コンパイルできなくなります)。<para>ロード対象のDLLとこの処理が所属するDLLが同階層に配置されている場合を想定している。<para>ロード対象のDLLの階層が異なる場合、DLLのパスを何らかの方法で取得してAssembly::LoadFromの引数とすること。<para>今回のサンプルは呼び出すプロパティが決まっているので名前の一覧を外部から受け取っている。<para>実際の処理に組み込む場合はpublicのプロパティをすべて取得しておいた方がいいかもしれない。<para>本クラスが所属するDLLはC#のモジュールと同階層となることを想定している。<para>C#のDLLば別階層となる場合は該当モジュールのパスをこのクラスからAssemblyLoaderUtilに渡す必要あり。<para>また、このクラスヘッダはネイティブコードに公開されるため、C++/CLIのクラス定義等は記載できないことに注意。FizzBuzzAdapter::Impl(num);}まとめにかえて.NETに限らず、MS系の技術に関する細かい情報は以外と日本語で出ていないことが多いです。英語で調べて対応することはもちろんできますが、その時の知見をプロジェクト内に閉じ込めるのももったいない。同じ箇所で躓く技術者さんは他にも必ずいますので。いう意味で、こういうのちゃんと公開することには意義があるのかもと思います。17日目は、kentaro_tsujinoさんです。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。