展示会等に行った場合に思うことは何事も見栄えが大事だと感じました。

もちろん展示会は展示目的でもあるので見た目が重要で、デザインが良ければ聞いてくれる人も多くなります。
自分も興味のある分野以外はだいたい見た目でフィルタしていたりします。

業務用ソフト等は見た目よりも機能だったりしますがその場合もデザインで使いやすさが変わると感じました。
UIデザインにもなりますがメニュー等についてもよく使う機能等、アイコン等がついていたほうが分かりやすくなります
ちょうどEXCELのリボンのように分かれていると初めて使う人でもどの辺りにあるのか探しやすくなると思われます。

コーディングだけでなくUIデザインについても頑張りたいと感じました。

こんにちはmtjです。

展示会を見ましてソフト系の展示会はAI、IOT、遠隔操作等が流行っていると感じました。

世の中が省力化に動いているような気がします。

ARを使い技術者が遠隔から作業者に指示を出す、ロボットにAIを組み込み配置等が変化しても柔軟に適応できる
IOT、遠隔通信技術により遠隔からでも保守、状態の確認が可能になる等です。

まだまだAIと言っても展示会用に特化していて、実際にはプログラムで状態判定をしているかAIかわからないもの等もありますがあと数年後には
単純作業はAIを導入したロボットが行うのではと感じました。

AIの保守、導入コスト等が解決されればすぐに広まるのではないかと感じました。

１０年後が楽しみになりました。

こんにちはmtjです。

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

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

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

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

こんにちはmtjです。

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

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

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

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

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

mtjです。

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

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

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

こんにちはmtjです

現在のプログラムはWEB系のアプリがメインになりつつあります。

デスクトップアプリに比べて様々なOSで動くことがメインだと思われます。
一時期に比べてWindows一強状態ではなくアンドロイド、IOSのタブレット等が流行っているので当然の流れだと思われます。

IT関連技術者もこれからWEB系についていける人が残っていくのではないのでしょうか。
WEB系は様々な要素技術の集まりなので役割分担がしやすく作りやすくなると思います、その分根幹部分の技術者の需要も上がっていくと思うので自分はそういうところを詰めて行けるといいかなと感じます。

こんにちはmtjです。

kotlinでUIの作成等に手を出していますがVSの出来の良さを改めて感じます。
特にUI、イベント関連の出来がよく何も入れなくてもダブルクリックでボタンのクリックイベントを実装可能です。
イベントもdelegateの注入処理もなくデザイナーが勝手にしてくれます

開発者は用意されたメソッド内に処理を書くのみでUIアプリを作成可能です。

kotlinの方はライブラリ等を模索しながら作りやすいように調整中です。
調べるほうが面白くなり全然進んではいませんが。

こんにちはmtjです

最近アンドロイドアプリの勉強しようと思いkotlinをしております。
開発環境が日本語でないので既に敷居は高いのですがなかなか新鮮であり、JAVAを元にしている事もあり懐かしくも思います。

こういった新しい言語の考え方、作り方を覚えるのも良い技術のトレーニングになると思いました。
自分たちの業界には大切なことと思います。

こんにちはmtjです。

最近無線の進化はすごいと感じています。

それも家でヘッドセットを使用しているのですが断線で以前の有線ヘッドセットがダメになり今回無線にしてみようと考えたためです。

あまり遅延があっても音は問題がないので無線にしました、steelseriesの無線ヘッドセットです。
送受信機とヘッドセットという構成で送受信機は独自規格ですが音ゲーをしていても遅延を感じないくらい高速通信をしています。
今までと比べて充電をしないといけない欠点はありますがケーブルの取り回し等を考えるとかなり楽になり遅延も少ないのでかなり良い買い物をしたなと感じています。

無線のイメージといえば遅延が大きくそういった速度が要求されているものでは使えないと思っておりましたが考えを改めました。

今使っているマウス、キーボード等も余裕があれば無線にしてすっきりさせたいですね。
よく考えないと結局充電ケーブルでごちゃごちゃしそうですが。

こんにちはmtjです。

ソフトでは内部のソースまではわかりません

普通に動いていれば何も問題ないのでソースが汚かろうが、綺麗だろうがお客さんには関係ありません。
ではどんな時にソースの汚さで問題になるかというと基本は異常時と変更時です。

異常時の場合はソースが複雑な方が修正が長引き修正による不具合も起きやすくなります。
変更時は変更箇所が多くなったり多い分テスト、手戻りも多くなり費用が必要になります。

では汚いソースで行う利点は何かというと考える時間がいらない分速度が速い＝安いということです。
もちろん上手く行けばの話ですが設計、共通化の検討等もしないため手戻りがなければかなり早くなると思います。

もちろんですが上記は小さいソフトならばの話です、大きくなればなるほど共通化による同じようなコードがなくなっていくので基本は設計もコードも綺麗なほうがはやくなります。

只お客さんから見ると金額と仕様書のみなのでそういった後々の部分については頼む側からすれば全くわからないのが現状です。
頼むときの指標にするためにソフト開発のレベルを測るための指標が何かあるといいのかもしれません。