今年の4月からインフォテック株式会社に入社しましたmasugiでございます。
これからよろしくお願い致します。
現在私は研修として、C#を用いたソフトウェアの開発の練習を行っています。
その際、要求仕様に関する不明点を質問しなかったり、要求仕様を(実際には正しく理解していないのに)正しく理解していると思いこんで実装を進めた結果、実装したソフトウェアの機能が要求仕様と違う、ということがありました。
練習だから良かったものの、これが実務だとお客様からお叱りを受ける、ということになりかねません。
このことから、要求仕様を正しく理解するために、どんなに些細なことでも不明点の質問や確認事項の確認を怠らないようにすることが大事だと感じました。
また、開発に関して悩んでいることがあったら、最適解が思いつくまで自分で悩み続けるよりも上司や先輩に相談した方が早いことがあることも学びました。
最後になりますが、研修で開発ツールの使い方やコーディングの仕方をしっかりと習得して実務に臨みたいと思います。
若手育成の目的で、先月からペアプログラミングを始めました。
本来は常にペアプログラミングを行なうのが良いのでしょうか、まずは週に数回行ってみて様子を見ています。
それでも、余裕が無くてなかなか時間が取れていないです。
こんにちは mtj です。
ゲームをよくする手前 購入した人にダメージをあたえる いわゆるクソゲーとなるものを購入する頻度は高い
購入したお金はもうどうしようもないが そこから友達と何故これが産まれたかを話し合うのはとても面白い
またプロジェクトで自分がこういう物を作らないようにするためのトレーニングにもなります。
ゲームは様々な要素が組み合わさってできています
・コントローラーでの操作性
・UI等のデザイン（配置等も含む）
・ゲームとして面白さ
・シナリオとして面白さ
・3D等グラフィック
それ以外にもジャンルによっては様々ありますが ゲームの内容によって何が足りないか
何故足りなくなったがだいたい想像できます
そういった要素ごとに色々考えながらマネージメントの本を読むとマネージメント力が上がると思います
また、ここからどうやったら面白くなる、改善案等も考えることでそのような製品開発のトレーニングにもなります。
是非マネージメントをやったことが無い人はクソゲーをクリアしてトレーニングしてみてください。
いい勉強代になると思います。
先日、USBカメラを接続するためにドライバのインストールを行ったのですが、
その際に以下のエラーが発生し、インストールに失敗しました。
「このハードウェアのデバイスドライバーを読み込むことができません。
ドライバーが壊れているか、ドライバーがない可能性があります。（コード39）」
結論から言うとWindowsセキュリティ設定が原因で、
Windowsセキュリティ->デバイスセキュリティ->コア分離->メモリ整合性をオフに変更
により解決しました。
以下、解決までの過程です。
1. 試行錯誤
次のようなことを試したのですが、解決も原因特定もできませんでした。
・カメラやケーブル、接続ポートを変更
・メーカーHPにてドライバの対応OS, CPUの確認
・ドライバを最新のものに更新
2. PC初期化
社内の他のいくつかのPCでは問題なく成功しており、
PC自体に原因がありそうだったのでPCの初期化も行いましたが、
それでもインストールは成功しませんでした。
3. メーカー問い合わせ・解決
にっちもさっちも行かなくなり、メーカーさんに問い合わせたところ、
次の手順でWindowsのセキュリティの設定を緩めれば良いと教えていただき、
無事解決しました。
スタート->設定->更新とセキュリティ
->Windowsセキュリティ->デバイスセキュリティ
->コア分離->コア分離の詳細
->メモリ整合性をオフに変更
原因となったメモリ整合性、PCによっては出荷段階で既にオンになっているようなので、
ドライバのインストールに失敗した際には確認してみると良いかもしれません。
その後、本件について補足情報などないか検索していたところ、
エラーメッセージ+エラーコードがタイトルの記事に解決策が掲載されているのを発見しました。
プログラミングの際はエラー発生の初期段階でエラーメッセージの検索をするのですが、
今回は失念していました。今後は気を付けたいです。
弊社で開発している、ある案件のVisualStudioソリューションを開くのが異常に遅い問題があり、
てっきりプロジェクト数が100個くらいあるのでしかたがないと諦めていたのですが、
原因がわかり速くなりました。
問題は「Microsoft Visual Studio Installer Projects」で作成したインストーラプロジェクトでした。
インストーラプロジェクトを含んでいるとVisualStudioソリューションを開いていからマウス操作がまともに行えるようになるまで1分くらいかかっていたのですが、
インストーラプロジェクトを省くとマウス操作が数秒で行えるようになりました。
今は、ソリューションに空のダミーインストーラプロジェクトを含むようにし、インストーラを作成するときだけソリューションファイルを置換してダミーインストーラプロジェクトから本番インストーラプロジェクトに切り替えるようにしました。
もっと早くに気づけばよかった。
こんにちは mtj です。
PGの作りが良いか悪いかこれがわかるようになるかは勉強するだけではわからないことが多いと思います。
実際に良い作りがわかるのはそのソフトを改造、保守する、別の誰かが改造するときにわかりやすいものです。
改造、保守等がしやすいなら基本良いプログラムだと思われます。
コードを書くだけであれば現状のコードをコピペしたり、メソッド等に分けずに書いた方が早い場合があります。
メソッドに分けるために頭を使わないのでその時は速くなります。
コピペも現状の動作が繰り返されるならそれで問題もなくなります。
しかし上記のコピペ等にバグ、変更等を行った場合 コピペした箇所を全部探したり
メソッド分けもされていないような長いコードを読んで影響範囲を調査したり不都合な事が多く発生します。
PGは本を読んでの座学だけでなくアウトプットが必要という話がよくあるのは作らないとわかないことが多いためだと思います。
新しい事を学んだら頭の中でも仮想でもいいのでアウトプットすることを心がけるとPGのレベルアップが早くなるかもしれませんね。
先日、クラスの持つプロパティ名をExcelファイルに列挙すると言った作業を行うことになりました。
対象となる複数のクラスから特定の条件を満たすプロパティの名前のみを列挙する必要があり、
始めは手作業で地道にコピーしていたのですが、途中でReflectionを用いれば自動で列挙可能だと気付きました。
プロパティには列挙条件を示す属性が付与されていたのですが、
属性を取得できることを失念していました。
取得には以下のようなコードを使用しました。
※正確に再現したコードではないのでミスなどあるかもしれません
private static List<string> GetHogeIsHugaPropertyNames(Type type) {
return type.GetProperties()
.Select(p => (p, Attribute.GetCustomAttribute(p, typeof(HogeAttribute)) as HogeAttribute))
.Where(x => x.Item2 != null && x.Item2.IsHuga)
.Select(x => x.p.Name)
.ToList();
}
これに気付かなかったため時間を少し溶かしてしまいました。
何か作業する際は開始前に作業手順を確認し、
繰り返し手作業を行う必要があるようならどうにか自動化できないかを考えるようにしたいと思います。
先日作成したアプリで、結果演算をプログラム風に定義できる機能を実装しました。
こういう機能は実装していて楽しいですね。
実装自体は結構シンプルなのですが、利用者側の自由度が高いので、他のアプリでも需要がありそうです。
こんにちは mtjです。
色々とSwitchのゲームを見ていると割とプログラム系のゲームが多い
”つくってわかる はじめてゲームプログラミング”とかを見てもよくできていると思うし
こういうものからPGに入ったほうがプログラミングの楽しさがわかると思う。
自分はPGの教材を最近は読みませんが、昔に読んだ記憶では ループをさせて 標準出力に1,2等を表示するような例が多かったと思う
正直上の例ではPGはわかるがPGの楽しさは全く無いと感じる。
そういう意味ではSwitchのプログラミング系のゲームは動きを見ながら調整でき 自分で作り変えている感がすごい出ていると思う。
正直コンソールでの勉強はもう古いように感じる、せめてフォーム、画面を出しての動作か Webブラウザ上で勉強する系のプログラムのほうが覚えやすく、楽しいんじゃないかと感じた。
2週間ほど前に業務で使用するディスプレイを新調していただけました。
23.5インチほど（解像度1920*1200）から31.5インチ（解像度2560*1440）になったのですが、
コーディングがやりやすくなって大変ありがたいです。
コードの表示領域が大きくなるとこれだけ変わるのかと驚いています。
特にコードの読みやすさが格段に上がりました。
今までは横に長いコードに読み辛さを感じていたのですが、
視野内中心部に余白有りでコードが表示できるようになり問題がなくなりました。
適宜改行を挿入して読みやすく整形しておくに越したことはないと思いますが、
開発者全員が大きなモニタを使用することが確かなプロジェクトであれば、
多少横に長いコードを書いても支障はないのかもしれませんね。