きまぐれ備忘録

多言語対応してます！　って言えるとカッコイイかも？　と思い、 必要ないかもしれませんが、仕組みを組み込んでみました。（笑 手順 1. Stringファイルを追加する ファイル名は「Localizable.string」とします。 2. プロジェクトのプロパティを開く 3. Localizationsで言語を追加 +　ボタンを押して、言語を選択する。 先ほど追加した「Localizable.string」を選択。 4. Stringファイルが言語ごとに用意されていることを確認 Localizable.stringを編集 言語ごとにファイルが用意されているので、言語に合わせてテキストを編集します。 書式は、"任意のID" = "テキスト"; となります。 セミコロン(;)で区切らないと、コンパイルが通りませんので注意です。 Localizable(English) "label-RoundUnit" = "Round Unit"; "label-Rounding" = "Rounding"; "label-TotalAmount" = "Total Amount"; "label-CalcTotal" = "Calc.Total"; "label-CalcResult" = "Calc.Result"; "CalcTypeDIF" = "Difference"; "CalcTypeFIX" = "Fix"; Localizable(Japanese) "label-RoundUnit" = "丸め単位"; "label-Rounding" = "端数処理"; "label-TotalAmount" = "合計金額"; "label-Ca...

私の主観なので、考え方の１つとして参考になればと思います。 ソフトウェア品質って？ システム構築のプロジェクトをやってると、毎回こんなことを言われます。 ・チェックリストの件数と密度は？ ・不良の摘出件数と密度は？ ・どんなバグが出てるの？　品質向上施策はしたの？ まぁ、システム開発に携わった方なら、普通に言われることと思います。 「動作不良がなく、仕様通りに正しく動作する。」 これ自体は正しいことと思います。 ただ、私としては、「これだけでは足りないのでは？」と思うわけですよ。 例えば、 仕様通りに動作するけど、ソースはスパゲッティ状態で、開発した人しか理解できないプログラム 「仕様通りに動いているので、品質は確保できている」と言えるけど、同時に「開発した人にしか理解できないソースは、修正時にデグレを起こす可能性が高く品質が悪い」 とも言える。  結局、品質って良いの？　悪いの？　ってなりますよね。 これは「品質」をどう定義しているか？　の違いによるものと思ってます。 ソフトウェア品質の定義 ソフトウェアの品質には、いくつかの観点があると思います。 私の場合、下記の観点で品質を見るようにしてます。 正確性（仕様通りに機能すること） 安全性（想定外の事象が起きた時、安全な方向に処理が倒れること） 操作性（ミスを起こしにくく使いやすいこと） 保守性（機能拡張、仕様変更に対応しやすいこと） 性能（人がストレスを感じない程度に応答が返ってくること） 1. 正確性 ソフトウェアが正確に動作しないのは致命的ですから、これは必須条件です。 仕様に書かれている通りに動作しないものは、不良として検知され修正をすることになりますので、品質を評価する上で数値化もしやすく、誰もが意識していることだと思います。 2. 安全性 これは、仕様に書かれていないことをどれだけハンドリングができているか？ ということになります。 例えば、仕様で 処理済み件数と総処理件数を引数で受け取り、進捗率を返す。 進捗率は、 （処理済み件数／総処理件数）×100　で算出する と書かれていたとします。 何も考えずにコーディングするとこんな感じだと思います。 public float(int ...

コーディングでUITextFieldの入力可否を制御する Swiftのバージョンにより実装方法が異なるようで、悩みました・・・。 UILabelを使えば、表示専用にはなりますが、状況によって編集/表示を切り替えたい場合には、UITextFieldの属性を切り替えられる方が便利。 StoryBoardだとControlにあるEnabledにチェックを入れると実現できるので、絶対に何かあるはず！ ってことで探しました。 環境 Xcode10 Swift 4.2 編集可否の制御方法 let txtAmount = UITextField() //　編集不可 txtAmount.isEnabled = false isEnabledをtrueにすると、編集可能となります。 感覚的に isXXXX のメソッドって、Get専用と思い込んで見逃してました。。。 スッキリ（笑

StoryBoardの使い方（というか細かい設定）がよく分からず、コーディングで全部作ってやる！　ってことで、画面表示まで作ってみました。（iOS用です） プロジェクト作成 とりあえず、プロジェクトは「Single View App」を選択。 自動で作成されるStoryBoardなど、不要なものは削除しますし、少ない方が良い！ ってことで。 削除したファイル ・Main.storyboard ・LaunchScreen.storyboard そして、プロファイル定義で、StoryBoardを設定している箇所を変更 ファイルを追加 ViewController 自動生成されているViewControllerの名前をBasicSettingViewController変更して、コーディングを追加。 BasicSettingViewController.swift import UIKit class BasicSettingViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() let basicView = BasicSettingView(frame: self.view.bounds) basicView.autoresizingMask = [.flexibleWidth, .flexibleHeight] self.view.addSubview(basicView) } override func viewDidLayoutSubviews() { super.viewDidLayoutSubviews() } } 画面の定義（オブジェクト類）は、viewDidLoad()の中に書いても良かったのだけど、 オブジェクトの数が多くなったり、複雑な画面を作ろうとした場合、外出しにした方が見やすいかな〜 と思い、BasicSettingViewを作成して組み込んでみました。 BasicSettingView.swift im...

StoryBoardを使うと 多分良いところ ・ラベルやボタンなどを配置しながら作っていけるので、直感的にはわかりやすいかも？ ・デバイスを切り替えるとデザインが調整されるので、他の機器での表示イメージも確認できる？ なんかイマイチなところ （私のスキルが不足してるだけかもしれませんが・・・（汗 ・「こうしたい」に対し、どこをどう設定したら実現できるのかがわかりにくい。 ・少し複雑なレイアウトを作ろうとしたらめんどくさい（笑 ・オブジェクトが多くなると、プロパティの変更がめんどくさい。 　色とか、フォントとか・・・ StoryBoardとの格闘 StoryBoardで画面を作ってみてるのですが、AutoLayout関係で警告が出るわ出るわ・・・。 なんでも制約がおかしいらしい。 一応、自動調整してくれる機能があるみたいです。 警告アイコンをクリックすると、ポップアップが表示されるので、Confirmをポチ。 Failed to automatically update constraints んー。　自動調整はできなかったようですね。 警告なので無視しても良いのかもしれませんが、気になる性格でして。 警告無しの綺麗な状態にしたいのですが、いちいち制約をつけていくのも面倒な作業だし、StoryBoardを使わず、コーディングでやった方がわかりやすいのでは？ なんて思ったりした。 コーディングなら、プロパティの設定を変数や定数で定義しておけば、後から変更するのも楽にできそうだし。 結論 私には、StoryBoardは合わないようです。 もしかしたら効率が悪かったり、分かりやすさに欠けるかもしれませんが、 コーディングで作った方が、白黒はっきりして良いかも？

JPAのJPQLはパフォーマンスが良いらしい？ とのことで、使ってみましたが、理解が進んでいないためか、あまり使い勝手が良いように感じなかった。。。 MyBatisも触ってみたが、Eclipseのプラグインを使えば、DBからEntityを自動生成してくれる機能は、両方とも持ってるので それだったら、使い慣れてるSQLを利用できる方が便利では？ という感じがしてます。 JPAの場合 テーブルへのアクセス定義 <named-query name="MProject.findByKey"> <query> SELECT m FROM MProject m WHERE m.projId = :projId </query> </named-query> 実行 EntityManager em = JPACore.getEntityManager("TestManagerJPA"); Query query = em.createNamedQuery("MProject.findByKey"); query.setParameter("projId", "abc"); MProject mProject = (MProject) query.getSingleResult(); System.out.print("Proj Id = " + mProject.getProjId()); MyBatisの場合 テーブルへのアクセス定義 <select id="selectByPrimaryKey" parametertype="String" resultmap="hashMap"> select * from m_Project where projId = #{projId} </select> 実行 try (Reader r = Resources.getResourceAsReader(...

顧客要件に合わせた請負型のシステム導入はこの先も続くの？ ERPパッケージの導入に携わって２０年。 老朽化、バージョンアップ、パッケージ切り替えなどで、案件はまだあるが、この先も継続的に案件が続くのか疑問。 システムのバージョンアップであれば、データ移行が不要（ひどいパッケージだと内部アーキテクチャの変更で、移行が必要なりますが・・・）な分、費用は抑えられるかもしれないが、システムの入れ替えになると、システムの構築費用とデータ移行で多額の費用がかかる。 マスタは移行できるが、過去の業務データはデータ構成の違いから移行できないことが多く、参照用で旧システムを残すことが多い。 最近では、ERPシステムをクラウドサービス化しているところもあり、今後はサービス利用の方向に向かっていくではないかと。 サービス利用のメリット ・自分たちでサーバの維持・運用をする必要がない ・バージョンアップはサービス提供側が実施してくれるので、常に新しいものが使える ・いつでも利用を止めることができる（契約にもよりますが） などが考えられるが、市場の変化により、今のシステムでは機能不足で新しい機能が必要になったとしても、機能改変の融通が利かないことが考えられる。 他に良いサービスが出てきたので、乗り換えたいと思っても、マスタと業務データの移行が問題になる。 それなら！  データと機能を切り離して、やりとりするデータのインタフェースを標準化したら、機能は入れ替え可能だよね？ って単純に思うわけですが、今のところそのような仕組みは聞いたことがない。 想像する理由は ・データを抱え込むことで、他への乗り換えを防ぐ（顧客の抱え込み） ・技術的に難しい？ データが切り離されて、機能部分を入れ替え可能なら、自分たちにあった機能サービスを選択して利用することができる。 より良い機能サービスを提供するところが現れたら、乗り換えればいい。 携帯電話だとSIMを入れ替えれば新しい機種に切り替えることができる。 システムも自由に乗り換えができる仕組みが出来上がれば面白いと思うのですが どうでしょうかね。