PCのフォント

Windows10のシステムフォントは游ゴシックになりました。
また、個別にフォントの種類と大きさを選択する機能が無くなりました。
ノートPCの解像度が2880×1800の場合、Windows10の文字は肉眼では見えません。
「えー!どうすんの?」
Windows10の新機能にディスプレイのカスタムスケーリングがあります。
これを150%に設定すると2880×1800が1920×1200になります。
いつもの感じで少し縦長になりました。(ラダーマンは縦長が好き!)
「あのね、個別にフォントサイズをいじらんと全体の解像度を調整してよ」
という事なのでしょう。
多種多用なディスプレイに対応するための賢い方法だと思います。

ブルーライトカットメガネ

こんにちはmtjです。

最近メガネを買うときはブルーライトカットメガネにしています。
とりあえず付けれるものは付けとこうという考えですが正直あまり効果は実感できません。
昔からPCに向かって作業等をしていたため慣れているのもあって目の疲れを感じにくいのかもしれません。

次買うものは無しを選んでみて効果を確認したく思っています。

レンズは無色のブルーライトカットメガネがいいかもしれません、色付きも度合いがあるのかもしれませんが色付きのメガネで買い物等をすると
肉の色が変色しているように見えたりで正しく色がわからないので古い肉なのか新しい肉なのかよくわかりにくかったり傷んでいるものの見分けがつきにくくなったりしている気がします。

そういう意味でも無色のメガネは買っておかないといけないなと感じました。

コメントもコードの一部

他者の書いた古いソースコードの修正したり、機能追加をしたり、
メンテナンスする機会がありました。
思った以上に時間を費やしてしまったのですが、その主な原因は、
①処理の大きな流れが見えてこない
②なぜその処理を行っているのかが分からない

というものでした。
時間が経ったり、当事者ではない人が読んだりすると、
その開発者がどのような考えでその処理に至ったのか、
なかなか理解できない事を実感しました。

コードのコメントには「なぜそうするのか」など、
コードからは読み取れない情報を記入するべきだとあります。
一方、何でも書けばよいわけではなく、
余計なコメントは可読性を損なってしまいますが、
それでも無いよりはあったほうが助かります。

メソッドやクラスを定義するときと同じように、
使う側の相手の気持ちになって、使いやすいように、
読み手の気持ちになって、処理の理由がわかりやすいように、
適切なコメントを考えたいと思います。

 

ActionデリゲートやFuncデリゲートでタプルを使用

またC#のタプル(ValueTuple)の話です。

ActionデリゲートやFuncデリゲートは、複数個の引数を指定することができます。
例えば以下のようにstring型の引数を2つ受け取るActinデリゲートを受け取るHogeメソッドが定義できます。
(実装内容に意味は無いのであくまで参考の実装です)


void Hoge(Action<string, string> action) {
    action("aaa", "bbb");
}

これで動くのは動きますが、2つのstring引数が何者なのかコードからは全く読み取れないですね。
このメソッドを作った本人で無いと使用できないメソッドになっています。
今までならなせいぜいXMLコメントに引数の意味を記載してメソッド使用者に伝えることになります。
XMLコメントに「第一引数は名前、第2に引数はIDです。」みたいなことが書いてあれば、利用者は以下のように実装が可能でしょう。


Hoge((name, id) => {
    Console.WriteLine(name);
    Console.WriteLine(id);
});

しかし、タプル(ValueTuple)を使用すれば、このような問題は解決します。
先程のHogeメソッドを以下のように変更し、string型2つを保持するタプル変数1つにします。


void Hoge(System.Action<(string Name, string Id)> action) {
    action(("aaa", "bbb"));
}

これならば、2つのstring型に名前が付き、いちいちXMLコメントに記載しなくても最低限の意味は分かるようになりました。(あくまで最低限。XMLコメントが不要ということでは無いです。)
利用者側の実装は以下のようになります。


Hoge(x => {
    Console.WriteLine(x.Name);
    Console.WriteLine(x.Id);
});

60回目の誕生日

とうとう、その日がやって来ました。
いつもと変わらない朝のハズなのに
何故か、ひどくヘコんだ気分でした。
これから、益々、廃人に向かて行く。
決して元気になったりしない。
TVで足腰と意識のしっかりしたご老人を見ると
本気で羨ましいと思う。
自分もそうなりたいと思う。
どうしたらあのようなご老人になれるのだろうかと思う。
足腰が丈夫でもボケたら周りに迷惑。
頭がしっかりしていても車イスなら自分が地獄。
最悪の場合、30年かけて弱っていくわけで。
それでも「生きたい」と思うだろうか?

説明する力と顧客の理解

こんにちはmtjです。

最近は日本でもDevOps等の用語が聞かれるようになってきました。

よくある手法開発の発注側から作成して欲しいシステムの依頼を出し完成品を納品するですが
DevOpsは上記の数ある機能をまとめて納品するというよりは機能1つ1つを作っては公開という作り方になります。

上記の方法は様々な利点があるのですが、開発、発注側(運用側)どちらにも知識が必要なことが難しい事だと思われます。
特に運用側の協力は先に上げた完品の納入に比べてかなりの労力が必要となります。
・次の機能の策定
・優先順位の策定
・必要な機能等の情報収集。

そして自分たち開発側もコスト、期間、難易度等を説明する能力が必要になると思われます。
また完品と比べて頻繁に既存コードの改造が入るのでリファクタリング等の時期を定めないと大変なことになることでしょうか。

上記の労力等を考慮してもなかなか利点の多い開発手法なので自分ももっと流行りを勉強して様々な事に対処できるようになりたいと思っています。

使いやすい携帯端末

電話とメール専用に「Xperia SX」という端末を使っています。
ディスプレイは3.7型で、本体も95gのかなり小さな端末です。
いつか後継機が出たら買い替えようと思いつつ、6年が過ぎてしまいました。

バッテリーも待ち受けだけなら昔のガラケー程度は持つし、
何よりポケットにも無理なく収まるので、お気に入りなのです。
ちなみにその前に使っていたものは「Xperia ray」という端末で、
これも3.3型の小型のものでした。

スマートフォンの機能がどんどん多様化・複雑化する中で、
アドレス帳やスケジュールやメールなどの個人情報、
それに鍵やお財布などの重要な機能は、
その他の雑多なアプリを含む端末とは切り離して所持したいと思っています。

ただ私のような考えはあまり一般的ではないのでしょうか、
小型の端末が発売される気配すらありません。
そろそろ新しいバッテリーの入手が難しくなりそうです…
小型のスマートフォンの発売を切に願っています。

「建設業の足元にも及ばない、IT業界は最も遅れた労働集約型産業だ」について

今朝見た日経XTECHの以下の記事が面白かったです。
「建設業の足元にも及ばない、IT業界は最も遅れた労働集約型産業だ」

我々IT技術者が良く比喩に使う建築業よりも遅れた業界だったとは!

私はこの業界に入ってソフト開発会社2社に勤めましたが、どちらもSIer無しの1次受けで、自社内での受託開発でしたので、この記事に書いているような多重請負でのIT土方な現場には関わったことがなく(関わりたくないですが)、驚くとともに技術者が可哀想になります。

このような現場では、志が高い技術者が入ったとしても、続かないか腐っていきます。結果、知的技術者はいなくなり、労働者だけしか残らいない技術者デフレスパイラルになってしまう。もったいない。

私は、志が高い技術者はベンチャー系会社に入ったほうが幸せだと考えています。
いまの日本のソフトウェア業界では、やりがいがあり・技術力が身につき・成果が収入になるのはベンチャーだけです。

つまり何が言いたいかというと、「インフォテックはベンチャー系なので、やる気のある技術者はぜひ面接に来てください」ということです。

MECHATROLINK-Ⅲ

KV-XH16MLを使いました。
但し、SV2は1台も接続していません。
IAIのPCON(6軸)とORIENTALのAZ(6軸)です。
FBとフローを使用してラダー回路もシンプルになりました。
素晴らしいのは、後に「PCONとAZを別な物に置き換えても
プログラムを変更する必要がない」というところです。
※分解能が変わる場合は電子ギアの設定値が変わります。
Ethernet/IPも初めて使いましたがCC-Linkのような
配線間違いも無く順調にデバッグできました。
いつも時間のシワ寄せがラダーマンに襲い掛かりますが
このようなシステムは大変ありがたいです。

設計は単純なときから

mtjです。

誰かが改造した、自分が改造した問わずにソースの見直しは小さいところから行うべきだと感じました。

小さい時の変なコードもその小さな組み合わせが大量に貯まり全体で見るとかなり保守をしにくい状態になる場合がありました。
小さい内に気にしていれば後に機能改造を行った場合に把握、改造がしやすいと感じました。

自分が作成していたものは気をつけていたのですが、他人のコードになるとチェックが甘いところがあるのでそういった箇所を気をつけ
他人のコードであろうが巻き込んでリファクタリングしたほうがいいと感じました。