こんにちは mtj です。
AIの活用についてですが
現在AIは社会の色々な部分に活用されています
普通の人が目にする機会があるとすればエンターテイメント向けが多いでしょうか
最近ではChatGPT等のAIチャットが流行っているかと思います。
AIは正確性があまり必要の無いところで使うとよく言われます。
正確性の高い所で使用する場合は使用者に知識が求められます
プログラムの生成もAIで生成できますが、それの成否、バグの有無、コード使用箇所のリソース等を元に
正しいか判断し使用する必要があります。
上記の通り判断する必要があるのでAIが生成するコードを理解、改造できるぐらいの知識は当たり前に必要になると思います。
仮にそういった判断に疎い人が作成し何かが発生した場合は何も対処ができない、改造、改善もできない可能性がでるかもしれません。
AI絵の問題でもそうですが そういった専門家以外の人、もしくは疎い人がAIを活用し始めるのがちょっと怖くもありますね
スマートフォンは今の私たちの生活に欠かせないものとなっています。
反面、スマートフォンにはインターネットやゲーム、動画サイト、SNSなどの楽しくて依存しやすいコンテンツがたくさんあり、スマートフォンを長時間使ってしまい、学業や仕事がおろそかになることが起こり得ます。
また、スマートフォンを使うのをなかなかやめられない、
いつもスマートフォンに関することを考えてしまい、つい触ってしまうなど、「スマホ依存」の状態になることも起こり得ます。[1]
今や誰もが当たり前のようにスマートフォンを持つ時代であり、スマホ依存症は誰にでも起こり得るものなので、十分注意していきたいものですね。
私もついついスマホを触りすぎてしまうので気をつけたいものです。
[1]「大森病院 メンタルヘルスセンター(イルボスコ) スマホ依存について」https://www.lab.toho-.ac.jp/med/omori/mentalhealth/mental/smartphone_dependence/index.html
最近ソフトウェアのある1機能の開発を行ったのですが、想定よりも工数が多くかかってしまいました。
工数がオーバーした原因を考えると、
全体の設計がぼんやりとした甘い状態からコードを書き始めてしまったために、
実装時の迷いや構造の見直しによる手戻りが生じたりしてしまったからではないかと思われます。
プログラムもそれ以外のものでも、
何かを作る際に全体が曖昧なまま個々の詳細から作り込むと、
最終的にそれらを整合性を保ちながら結合させるのは難しく、
結果として辻褄を合わせるはめになり、時間がかかったり構造が歪になってしまう気がしています。
そうならないためにも、全体を曖昧に設計した後、
まずは徐々に全体設計の詳細を詰めて行き（抽象度を下げて行き）、
中盤以降に詳細を作り込み始める（プログラムだとコードを書き始める）のが良いのだと思います。
今回の場合だと、設計は処理の流れと曖昧なクラス設計のみだったのですが、
社内メンバーからの助言を盛り込むと、
データの流れも考えた上で、クラス設計の最低限上位の部分まではしっかり設計してから、
コードを書き始めるべきだったのかと思います。
手を動かさないと何も進めていないように感じたり思われたりするかもしれませんが、
その時間をかけることで結果的に工数を削減できるのではないかと思われるので、
時間に上限は設けた上でしっかり設計を行うようにしたいです。
bingのチャット検索(ChatGPT)が流行っているので試してみました。
■C#でSQLiteを使用するコードを依頼
コードだけではなく、必要なライブラリやコネクション文字列の例も教えてくれました。
■上記の質問のあとに、他のコード例を依頼
ちゃんと続きの会話と理解してSQLiteのコード例を教えてくれました。
■上記コードをVB.netに変換
コード変換を行うWEBサイトを使用して変換してくれました。
■結果
今回のチャット内容は簡単なものなので実際にはどれほど役に立つかはまだわかりませんが、ちょっとした調べ物などをお願いして開発の労力を減らせそうに思います。
良い開発パートナーになりそうです。
こんにちはmtjです。
最近mocopiという簡易的なトラッキングデバイスが発売されました
今までは正面から赤外グリッドで距離、画像でボーン判定を行いトラッキング、
もしくはトラッキング用のスーツ等をつけ人の動きをトラッキングするのが普通だった気がします。
しかしどちらもそれ用の設備を整えたり、全身じゃなく顔トラッキングだけ等限界がありました。
mocopiは時計のような大きさのデバイスでbluetooth接続で簡易にトラッキングができるという物
用途としては今のところVチューバー向けになると思いますが従来のトラッキングデバイスと併用すれば安くモーションキャプチャ等活かす方法はある気がします
kinectもそうでしたがやはりトラッキングというとアミューズメント、娯楽向きになるのではないかなと思います。
自分はデバイスを持っていませんが、友達が持っているのでどこかでSDKでも触れたらなと思います。
業務で調査をしているときに、インターネットのサイトを調べることがあるのですが、日本語で書かれてはいるものの、いかにも海外のサイトを日本語に機械翻訳したようなサイトが出てくることがあります。
私が最近見た例ですが、
「[] に戻ります。クイックツアーメニューまたは、直進してこのクイックツアーの終了。」
(英語の原文はGo back to the quick-tour menu or go straight to the end of this quick tour.)
というように、翻訳後に日本語の文として成り立っていない文になることがよくあります。（なお、これはwebサイト内にある言語を切り替えるプルダウンを用いて機械翻訳したものです。）
このように日本語の文として成り立っていない文が多いと、サイトが読みづらいです。英語で文書を読むのに慣れていない私としては、日本語で書かれていた方が有難いですが、英文の原典を読むのに慣れなければならないな、と思います。
余談ですが、とあるAPIのマニュアルの日本語版(機械翻訳されたもの)で「お前」という単語が出てきたときは思わず苦笑いしてしまいました。
ここ最近は他社のソフトを作り直す案件に携わっています。
自分の担当はPyhonで書かれた部分をC#で書き直す作業です。
書き直すコードはざっくり言うと画像に写っている人間を検出するコードで、
以下のような処理を行っています。
1. 推論エンジンに入力画像を投げる
2. 推論出力結果から検出された物体の情報を切り出す
3. 切り出した物体情報を元の入力画像上の値に変換する
物体の情報をどのようにデータ構造に格納しているかなどがわかって、書き直していて面白いです。
書き直していて思った所感は他に以下の2点です。
1. Pythonの方が多次元配列を扱いやすい
Pythonには数値計算ライブラリのnumpyがある関係で多次元配列が扱いやすいです。
機械学習を行う際の主流になるのも納得です。
C#で書き直しているコードでは1次元配列で保持し、
多次元配列のインデックスを1次元配列のものに変換してアクセスするようにしたのですが、
インデックスの計算などにミスしてしまい、修正に少し手間取ってしまいました。
…とここまで書いて、ふと調べてみましたがC#でもnumpyのライブラリがあるようでした。
書き直したコードのパフォーマンスなどに問題あれば、使用を検討しようと思います。
2. コードのコピペをする際は中身を極力解読すべき
既存Pythonのコードを調査していたところ、コアの部分がネットからコピペされていました。
ライセンスなどないコードだったのでそれ自体は問題ないかとは思いますが、
よく解読せずにコピペしたために生じたのではないかと思われる実装ミスがありました。
（コピペ内で行われている処理をコピペ外で重複して行っており、
設定次第では正常に動作しなくなっていました）
マジックナンバーなど解読できないこともあるかと思いますが、
不精せずに可能な限り解読を試みてコメントを付与して、
保守しやすい状態にする必要があると感じました。
以上です。
WPFでBindingを使用した時にインテリセンスで候補は出て来ないし、定義元に移動も出来ないし、使いにくいと思っていたのですが、最近見たサイトでd:DataContextにデータモデルを設定すれば解決することが分かりました。
通常は、WindowタグやUserControlタグにd:DataContextを追加し、データモデルクラスを設定すればOK。
ControlTemplateタグを使用している場合は、その下のコントロールにもd:DataContextしないといけないです。
これにより改善するのは、
・XAMLにインテリセンスで候補が表示されるようになる。
・XAMLから定義元に移動できるようになる。
・定義されていないメンバを使用した場合にXAMLにエラーの赤線が表示される。
これでも改善しないのは、
・C#コードからXAMLのBinding参照先を検索できない。
・定義されていないメンバを使用した場合にコンパイルエラーが発生しない。
改善しない点もあるが、それでも今までより楽になりました。
こんにちは mtjです。
失敗から学ぶとのことで 自分は成功から学ぶ事は事前に知識が必要と思っています。
成功例では当たり前のように失敗しないように対策していたり、初動自体も正解を選んでいる可能性があるため
その成功を導くための情報が知識が無いと不可能と思っています。
失敗であれば そのまま失敗したままにしないはずなので調査等を行い成功させるように修正を行うので
成功するための知識、調査方法を得ることができ 何故失敗したかを知るための知識も得られます。
なので自分は事例等も失敗からの成功の事例が結構好きです
自分が同じ状態になった場合の解決手段の蓄積にもなりますし、そもそも同じ状況になりにくくなると思います。
事例集を読む場合に上記も含めて自分が行う場合の時に置き換えたりすると知識が深まるかもしれませんね
新年あけましておめでとうございます。
2023年も何卒よろしくお願い致します。
私の今年の抱負は「話す力」の向上です。
本を用いて話し方の勉強をする、
週の初めの朝礼で1分間スピーチをするなどして、
話すことに少しづつ慣れていきたいと思います。