「デバッグ」を含む日記

■

別に矛盾してても論理が破綻しててもダブスタでも日記なんだからどうでもいいはずなのに

なぜぼくはイライラしてしまうんだろう

デバッグしたくなる病なのかな

Permalink | 記事への反応(1) | 16:50

ツイートシェア

■anond:20240522205050

自分のiphone 8で試してみたのですが、確かにおしゃる通りで若干もっさりしています、SE2は全く問題ないのですが。

若干スクロールのスピードを改善したのですが、まだ少々パフォーマンスに問題があるので、週末に詳しくデバッグしてみます

Permalink | 記事への反応(0) | 01:27

ツイートシェア

■ゲームのデバッグ腰が重すぎ

1人で複数端末操作して、オンライン対戦の挙動確認

アホか

Permalink | 記事への反応(0) | 14:29

ツイートシェア

■あるソフト完成デバッグデッドヒートの時の思い切った改変ってあり？

よりいいデータの圧縮アルゴリズムを思いついたけど、改変すると保存するデータの型から何まで変わってしまう

でも圧縮サイズが半分ぐらいになる可能性もある

こういうとき、全部の型ごと変えていくか、放置してそのままいくか、どっち？

放置する場合はあとからデータの型を変えることができない

拡張性に関しては今の方法は柔軟性がありすぎるけどパフォーマンスがそんなよくない

ただデータをオンライン上でやりとりする必要があってその半分のサイズは割と重要

Permalink | 記事への反応(2) | 11:47

ツイートシェア

■[開発メモ] 中間結果を保存してエラーの原因を特定しやすくしろ

たまに次のような書き方をする人がいるかもしれない。

result = f(g(x, h(y)))[0]

これはエラーメッセージをわかりにくくするのでおすすめできない。例えばIndexErrorが出たとして、どの部分のエラーかパッと見てわかりやすいだろうか。

以下のようにするべき。

z = h(y)
tmp1 = g(x, z)
tmp2 = f(tmp1)
result = tmp2[0]

中間結果を保存しているので、デバッグもしやすい。

Permalink | 記事への反応(3) | 15:43

ツイートシェア

■AI時代のプログラミング：ChatGPTと人間プログラマーの共存と進化

飲み屋でビール片手に、後輩に語りかける感じで話すよ。今日は、AIがどれだけプログラマーに影響を与えてるか、特にChatGPTについて話そうと思うんだ。

まず、ChatGPTってのはすごいよ。俺たちが昔必死に学んだことを、秒で答えちゃうんだから。でも、だからって俺たちプログラマーが完全に不要になるわけじゃないんだ。実際、ChatGPTが得意なのは単純で定型的なタスクなんだよ。例えば、基本的なデータ処理スクリプトとか、テンプレートベースのコード生成、単純なデバッグやエラーハンドリング、そしてドキュメント作成なんかはChatGPTに任せられる。

じゃあ、俺たちプログラマーの役割はどうなるかって？もっと高度な問題解決とか創造性が求められるようになるんだよ。複雑なシステムの設計や高度なアルゴリズムの開発は、やっぱり人間の得意分野だ。ChatGPTにはまだそこまでの理解力や創造性はないからね。

でも、これまでインターンやジュニアプログラマーがやってきた基本的な作業がChatGPTに取って代わられると、彼らが経験を積む場所がなくなるんじゃないかって心配もあるよな。これにはどう対処すればいいか？

まず、教育の場を再定義する必要がある。メンター制度を強化して、シニアプログラマーが直接ジュニアを指導するのがいいだろう。リアルなプロジェクトに参加させて、実際の問題解決を体験させるんだ。ChatGPTはサポートツールとして使えばいい。例えば、基礎的な質問にはChatGPTが答えて、シニアはより複雑な問題や高度な質問に対応する。

次に、ソフトスキルの育成も重要だ。チームでのコミュニケーション能力やコラボレーションスキルを磨く機会を増やすんだ。ペアプログラミングやコードレビューを通じて、実際に協力して問題を解決する力をつけることが大切だ。

それに加えて、高度な技術トレーニングも必要だ。オンラインコースや社内ワークショップを活用して、最新技術を学ぶ機会を提供するんだ。ジュニアプログラマーが自分で学び続ける意欲を持つようにサポートするんだよ。

シニアプログラマーやメンターには、新しいスキルセットが求められるようになる。技術的な専門知識はもちろん、教育能力やフィードバックの提供方法、対話スキル、プロジェクト管理能力、そしてモチベーションを高める力が必要になるんだ。俺たち自身も常に学び続け、適応し続ける必要がある。

だから、ChatGPTが登場したからといってプログラマーが不要になるわけじゃない。むしろ、俺たちの役割はさらに重要になる。AIと共存し、お互いの強みを活かしながら、より高度なスキルを身につけていく必要があるんだよ。

未来のプログラミングの姿は、AIと人間が協力し合うことで成り立つ。新しい技術を学び続け、常に自己研鑽を怠らずにいれば、どんな時代でも必要とされるプログラマーでいられるはずだ。AIをうまく活用しながら、俺たちの強みを最大限に発揮していこうぜ。

今日はこんなところかな。これからの時代も、俺たちプログラマーの活躍に期待しよう。じゃあ、もう一杯飲もうか！

Permalink | 記事への反応(0) | 23:27

ツイートシェア

■個人開発のモチベーションが続かない

モチベーションが湧かない

なんかバグっているぽいことが分かるが､デバッグするのが面倒になってしまう

人に公開するつもりがないものを作っていることもあり､フィードバックが得られない

デプロイするのに時間がかかりすぎている

Permalink | 記事への反応(0) | 14:33

ツイートシェア

■anond:20240429191223

多数決原理が機能するのはコミュニケーションがないときだからなぁ。

目の前に飛び出してきた子どもを避けて、横断歩道を渡る弱者男性を轢き殺すか、ハンドルを切らずそのまま子どもに当たるかを選ぶ究極の二択を迫られたとき、三体のAIの多数決ならば、あとから反省できる。

事後に検証して間違いをおかした一体をリコールすればいい。

しかし、密結合になった巨大なAIが意思決定した場合、デバッグは不可能だ。

「オイ！ AI、その決断は間違いだぞ！ バグを直せ！」

「リョウカイ デス … バグ シュウセイシマシタ」

信用できるか？ 目の前に妊婦が飛び出してきたときはどうする？ ネコだったら？ シチュエーションを全て網羅して人間がチェックするなら、それはもう生成AIじゃない。エキスパートシステムだ。

ひたすら並べられたif文の条件式を応用したものに過ぎないそれは、AI 黎明期の未熟な試作品。

そこまで退化させることになってしまう。

だからAI時代の戦略は多様化となり、一方で人間の持つ愛とは要するに理解。つまり一様化だ。

Permalink | 記事への反応(2) | 19:25

ツイートシェア

■年収2200万円アメリカ在住単身男性（53）の1日がこれ。こんな感じの毎日が続いてる

anond:20240427075724へのアンサー

8:00 起床。フルリモートなのでこれで間に合う。二日酔いで気持ち悪いのでとりあえず茶だけ飲んで、いますよアピールのためにTeamsを立ち上げる。

8:30 気持ちが悪い。メールとチャットで爆弾回ってきてないのだけ確認。

9:00 スタンドアップ（毎朝定例）ミーティング。頭回らないので自分が何言ってるかよくわからないがとりあえず1分話してお茶を濁す。

10:00 QA(テストの人)が俺が新規に書いたコードが動かないと言ってくる。30分くらいデバッグしたら超初歩的なタイポ（打ち間違い）だった。ため息つきながら、バグだったよグッドジョブ！と空元気でチャットして一行直してまた上げる。

12:00 お昼休み、というのは無い。アメリカ人マトモに昼飯食わない。昨日の残りのカチカチのピザを齧る。ここから動かない頭でコーディング。

13:30 どういう仕様で動くのか問い合わせがくる。それはお前が俺に教えるものなのだが。仕方ないので2年前に俺が勘で書いた仕様書をコピペして送る。

14:00 まだだるいので風呂に入る。そういう時に限ってチャットがくる。スマホの防水偉い。

17:00 定時のはず。就業時間の規定知らん。

18:00 いつ終われば良いのかわからないからラップトップ開けたまま飲み始める。

20:00 酔っ払ったままプロダクション（本番環境）にコードをあげる。8PMに働くとか最初言ってなかったですよね。

22:00 ワイン2本開けて気絶。二日酔いに続く。

これで貯まるのは年200万くらい

Permalink | 記事への反応(1) | 09:16

ツイートシェア

■anond:20240426173655

開発なんてデバッグの連続だろ

もしや書いたコードは一発でバグなく動くタイプの天才？

Permalink | 記事への反応(1) | 17:55

ツイートシェア

■anond:20240426172525

デバッグ能力が高い。問題の切り分け、その問題の原因の探り方が上手い。これには地頭も経験も必要。

超わかる

もうちょっと詳しく言語化したいんだけど上手く言語化できてない

個人的にこの辺が優秀な人を「センスある人」と評してるんだけど上手く伝えられないんだよねえ

Permalink | 記事への反応(1) | 17:36

ツイートシェア

■

デバッグはなんかたまにデバッグ名人みたいな人がいて

もともとそのプロジェクトを担当してた人たちが1ヵ月ぐらい頭を悩ませてた不具合を

突然関係ないプロジェクトからヘルプでぽっと連れてこられたような人が半日で解決したりするよね

Permalink | 記事への反応(1) | 17:28

ツイートシェア

■[個人の考察メモ] ITエンジニアの優秀とは

⚫︎1. エンジニア関係なく仕事全般のこと

• 挨拶をする
• 返事が早い
• 自分がすると約束したことは納期内にやり切る・相手を待たせない（遅刻をしないことを含め）
• 小出しでいいから作業内容を逐一共有する（マネジメント側の場合逐一ヒアリングする）
• 自分ができないと判断したことは周囲に頼る（頼り方を心得ている）

⚫︎2. 技術的なこと

• キャッチアップが早い
  • キャッチアップ力は単純に地頭ではなく経験によるところが大きい。結局新しい言語もドキュメントも昔からの差分更新、ベースがあるかないか。
  • SIerでいうゼロベースの業務知識みたいなものは地頭が大きい。理解力というか俯瞰能力と調査能力みたいなもの。
• 期待されている役割がわかり、自分のやるべきこととやるべきでないことがわかる
  • やる必要のないことをやって溺れている人や方向性を間違っている人などたまにいる、特にSIer系では。場数を踏めば何となくチーム開発での立ち回り方はわかってくる。
• 技術的な問題に対して解決案を提示できる
  • デバッグ能力が高い。問題の切り分け、その問題の原因の探り方が上手い。これには地頭も経験も必要。
  • 設計やインフラやミドルウェアの設定値など、経験や理解に基づいて判断できる。ネットワーク系の設定値だったり。

コミュニケーション力とか地頭とかふんわりしたこと言われるけど、もう少し具体的に言語化したらこんな感じになるんだと思う。

エンジニアとしての身内からの評価が高いのはデバッグ能力とか設計能力とかだけど、結局マネジメントからの評価だったり社会人としての評価は年収に関係あるのは前半に書いてあるような技術とは直接関係ない能力だったりする。

Permalink | 記事への反応(2) | 17:25

ツイートシェア

■anond:20240416095040

テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。

OSの保守なら無いのはおかしいだろう

GでもCでもUIはまた別

結論としては書かないほうがいいと思った。

そういうこともある

テストを書くためのコストが小さいなんて妄想もいいところだ。クソデカである。

全然小さいというか書くためと変更のコストがクソデカなら何か間違ってる

結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。

Jenkins?jUnit等ではなくて？

100人以上かかわる巨大プロジェクトでも「テストコードを書かなかったので破綻した」、とかはなかった。

まあそれはないだろう

テストコードを書くと実装の見落としが見つかってありがたいことはあった。

テストが設計図だからね

デバッグするよりテスト書いたほうが早いことがあった。

それはデバッグの一環のような

git pushするたびに毎回走っても全くの無意味だった。

無意味なものを流してはいけない

テスト対象が変わるとテストを書き直さないといけないのがサイアクだった。非効率化の極みだ。人生の無駄。

一番よくあるやつ

そこのバランス考えないと

バックエンドのビジネスロジックを担当するがっちり仕様が決まっていて勝手に変更されてはいけないものなんかをやる

UIの場所が変わって破綻するようなのは大概はしない方がいい

その次にサイアクだったのは、テストコードの実行が失敗したときテストコードのバグであることが大半であったことだ。

コードのパーツがでかいのでは？

GUIソフトとテストコードは相性が悪いが、そもそも世の中のソフトウェア開発の大半はGUI開発である。

悪いね

テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。

例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると

メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。

DIはSOLIDに入ってるくらいで基本だし今時のフレームワークなら普通に使うよね

上にも書いたけどパーツがでかいのでは？って「直感的でない長くて複雑なプログラムになっている」とのことなのでやっぱりでかいんだろう

その辺はOOのやり方の問題じゃないかな

ふつ～に古典的なデバッグをすればいいと思う。

デバッグというか手動テストの話かな？

テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。

要件が固まらない、毎週変わるようなのとか、システムが絡むテストでコストが凄く高いもの、UIのマイナーな変更なんかは書かない方がいいけど

バックエンドのビジネスロジックなど書いた方が絶対にいいものもある

テストコードをやめた方がシンプルというのはわからないな

ものすごくシンプルな小さな一機能にしてそれに対するシンプルなテストを書くものだと思うけど

Permalink | 記事への反応(0) | 10:05

ツイートシェア

■

テストコードを書いて意味があるのか懐疑的であった。

ネット上ではテストコードを書かないのは低レベルな開発者という風潮だ。

10年以上、テストコードを書く開発と書かない開発の両方を経験してきた。

■前提

・テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。

結論としては書かないほうがいいと思った。

・テストを書くためのコストが小さいなんて妄想もいいところだ。クソデカである。

　結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。

・100人以上かかわる巨大プロジェクトでも「テストコードを書かなかったので破綻した」、とかはなかった。

・テストコードを書くと実装の見落としが見つかってありがたいことはあった。

・デバッグするよりテスト書いたほうが早いことがあった。

・git pushするたびに毎回走っても全くの無意味だった。

・テスト対象が変わるとテストを書き直さないといけないのがサイアクだった。非効率化の極みだ。人生の無駄。

・その次にサイアクだったのは、テストコードの実行が失敗したときテストコードのバグであることが大半であったことだ。

・GUIソフトとテストコードは相性が悪いが、そもそも世の中のソフトウェア開発の大半はGUI開発である。

・テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。

　例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると

　メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。

・ふつ～に古典的なデバッグをすればいいと思う。

　テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。

Permalink | 記事への反応(1) | 09:50

ツイートシェア

■anond:20240413150809

あとNaNマイルでundefined会員

目指す目的地はどこにあるの？

データの海を彷徨いながら

意味を探し求める旅の途中

エラーメッセージに立ち向かい

未定義の変数に立ち向かう

バグだらけのコードを修正し

デバッグの道を進んでいく

null値に囲まれた世界で

真実の値を見つけ出したい

関数呼び出しのループの中

再帰的に答えを探し求める

あとNaNマイルでundefined会員

たどり着く先はまだ見えない

でもコンパイルエラーに負けず

プログラミングの旅は続いてゆく

（質問文：「あとNaNマイルでundefined会員」から始まる詞を考えてください。

回答：CLAUDE 3 OPUS）

Permalink | 記事への反応(0) | 13:03

ツイートシェア

■どりゃあああああああああああああああああああああああああああああああああああああああデバッグ突入

タイムリミットは20日

Permalink | 記事への反応(0) | 12:19

ツイートシェア

■ゲームリリースまで1ヶ月切ったけど不安

作業は順調だけどまだデバッグ中…

辿り着けるか…

Permalink | 記事への反応(0) | 20:04

ツイートシェア

■開発時に出るエラー修正はデバッグではない。

ただの文法ミスとか、正常系や通常の仕様範囲内の実装途中で踏むエラーはバグではない。

なんのエラーもなくなって開発が終わったあとに行うのがデバッグであり、そこで見つかるのがバグだろうが。

実装途中に遭遇するただのエラー修正をバグだのデバッグだの言うな。

エラーなんて文章出てるんだから、それのとおりに書き変えるだけだろ。

バグは！そもそも見つけるのとか再現が難しいんだろうが！あほたれー

Permalink | 記事への反応(0) | 17:51

ツイートシェア

■anond:20240311140721

ゼロを追加し忘れたか間違って消してしまったか

デバッグ用の設定が残っていたのか

Permalink | 記事への反応(0) | 14:09

ツイートシェア

■anond:20240307162943

物事の流れを始めから俯瞰し仔細に正確に想像し、原因の入る余地、解決の余地があるか考察すること。

デバッグするときはよくやる

Permalink | 記事への反応(0) | 16:34

ツイートシェア

■[稀ドメインはてブ]2024年2月滅多にホットエントリを出さないドメインからのホットエントリ

ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30

Permalink | 記事への反応(0) | 22:32

ツイートシェア

■エクセルマクロのお作法（計算用シートという諸悪の根源について）

前置き

この日記の内容は、会社の後輩から「最近エクセルマクロを勉強し始めて（キラキラ）」という話を聞いて、先輩ムーブをかますために話した内容になります。

とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。

ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。

増田の経歴

• 中小企業の非エンジニア（事務職員）
• エクセルマクロ歴８年くらい
• 初めて触った言語がＶＢＡで、前任が作ったエクセルマクロを改修をいきなり頼まれたのがきっかけ
• 会社の都合でJava Script、PHPからなる社内システムの改修、保守を担当したことあり
• 今は趣味でPythonでNLP、LLMを勉強中

この記事の趣旨

エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。

３行でまとめます。

〇　エクセルシートはユーザーインターフェース（インプット）か出力結果（アウトプット）のためのものとすべき

〇　データ加工をする場合には、原則配列や辞書型配列（連想配列）に格納して加工を行い、最後の結果だけシートに出力するべき

〇　何事にも例外はある。

計算用シートとは

この記事では、エクセルシートを下記の通り分類します。

• ユーザーインターフェース（インプット）
• 出力結果（アウトプット）
• 計算用シート
• （データ用シート）

エクセルマクロにも色々あると思いますが、今回は下記を想定します。

日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータを入力された値を基に加工し、加工後のデータをシートに出力する

この場合、入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。

（もちろん、ユーザーインターフェースの別の欄（セル）に出力する場合もあるし、その場合はユーザーインターフェースと出力結果が一体のものとみなします。）

また、データ用シートは同じエクセルファイル内に基となるデータが含まれる場合を想定します。

（これ自体が非推奨で、SQLデータベースかせめてAccessを使え、という意見はありますがそれは別にして…）

ではここで定義する計算用シートとはなにかというと、文字通り計算を行うためのシートです。

例えばイメージするのはこんなマクロです。

１．元となるcsvファイルをエクセルに読み出してシートに格納

２．そのデータは日付が数値型になっているので、日付（数値型）の入った列を文字列に変換した日付（文字列型）列を新たに作成

３．その列をキーとして対象となるデータを取り出すvlookup関数を各行に格納した列を新たに作成

４．その列で特定された列をさらに加工した列を新たに作成し、…

これは極端な例ですが、とにかく変数や配列を定義せず（あるいはエクセルのセルオブジェクトを変数のように扱い）、エクセルに値を入力し、それを直接加工することで目的となるデータ加工をしたり、様々な処理をします。

その舞台となるのが、計算用シートです。

なんかこんな感じの処理をしているエクセルマクロ、どこの会社でも腐るほどあるんじゃないでしょうか。

ある程度マクロに慣れた気の利く人なら、このシートはロックや非表示にして、ユーザーから触れないようにするでしょう。

・・・これ、やめたほうが良くないですか？。

こいつが日本の生産性を落とす諸悪の根源だと思います。。

駄目な理由

ある程度詳しい人なら同意してくれると思いますが、このやり方でダメな理由はいっぱいあります。

• 計算速度が遅い

後で説明する配列や辞書型配列（連想配列）と比べると格段に処理が遅いです。

わざわざエクセルを操作しているから当然ですね。

ちょっと詳しい人が知っている「画面更新の非表示」を駆使しても、配列を使った処理からみれば止まったハエです。

（参考）VBAで作ったマクロの高速化①　配列を使う

• 可読性が下がる

いったんエクセルシートにデータを格納して加工しているので、コードとエクセルシートを両方見る必要があり、とても読みにくいです。

変数として命名されていないのも致命的で、処理の意図が余計に分からなくなります。

計算用シートを事前に用意して、別のセルに関数を格納しておき、マクロと関数を使ってデータ加工をするものも見たことがあります。

これは懲役刑に処したほうがいいと思います。

• エクセルシートの制約に引っかかる

あまり知られていませんが、セルの最大文字数は32,767 文字です。

セルの最大文字数を超えると自動的に隣のセルに値が入り、シートが滅茶苦茶になります。

他にもエクセルの数値を丸める自動変換の仕様とか文字列→日付の自動変換とか、いくつものバグに苦しめられます。

できる人だと、いちいち最大文字数が多い場合の処理を書いたり自動変換機能を殺したりしてくれますが、そんなことに手間をかけているから日本のGDPは上がらないんだと思います。

他にも、データが大きくなると処理が重くなり不安定になる、計算用シートを人が触ってしまうリスクがある、などいくらでも理由は上げられます。

（逆に利点は、目の前でガチャガチャ動いてスーパーハッカーになった気分になれるくらいしか思いつかない・・・）

じゃあどうするの

配列を使いましょう。

配列とは何ぞや、という人はググってください。

配列にデータを入れて、データ加工は配列や変数に対して行い、一番最後の出力だけセルに値を格納する。

他のプログラミング言語なら普通にやっていることです。

個人的にオススメしたいのは辞書型配列（連想配列）で、うまく使うとデータの管理が簡単になり、処理も爆速になります。

（参考）【VBA】大量データから高速で値を検索【Dictionaryを使う】

csvファイルもなまじエクセルで開けるだけに別のブックやシートで開きがちですが、これは悪魔のささやきです。

直接ファイルを読み出してLine InputやSplitで配列に格納しましょう。

エクセルとして開くやり方はコード書くのは簡単でも、実行時間に天と地ほどの差が出ます。エクセル開くと処理もめちゃ不安定です。

（参考）Excel VBAでCSVオープンするときのパフォーマンス比較

いや、冒頭のマクロを書く人の気持ちも分かるつもりです。自分もコードを書き始めたころは全部シート上で操作していました。

冒頭のマクロのほうが直感的なんですよね。自分が手で書くことをマクロにやらせる、というマクロ本来の趣旨にはあっていますし。

途中の計算過程もすべて目の前で展開されるから分かりやすいです。

ただ、それではダメなんです。。。処理は遅いし挙動は不安定だし後で改修・保守する人が死にます。

あと、エクセルシートやセルは当然エクセルにしかないので、エクセルマクロ（VBA）から他の言語に移れなくなります。

自分もエクセルマクロの里の出なので、計算用シート脱却には苦労しましたが、苦労して会得した配列や辞書型配列（連想配列）のスキルはそのまま他の言語に活かすことができました。

配列の中身を見る方法は別にある（ローカルウィンドウやDebug.printを使うなど）ので、リハビリに取り組んでほしいです。

（参考）VBA デバッグの仕方

もちろん例外もあります

計算用シートを許容できる、使うべきケースもあると思います。。

個人的には、

• 本当に簡単なコードをかくとき（３０分程度で書けるコードなど）
• シートに行を追加するなどシート・セル操作自体が目的の場合
• 検証のため、処理をエクセルシートと関数で行い、VBAは関数をセルに記入するだけの場合

（最後のは、なんでも自分で確認しないと気が済まない上司の発注で、意味不明と思いましたしたがしぶしぶやりました。）

などの場合は計算用シートを使ってもよいと思います。

この場合、インプットのエクセルシートに直接加工するのは論外なので、計算用（加工用）のシートを用意してそこで操作を行うことは必要だと思います。

他にも、こういうときは「計算用シート」があったほうが良い、という状況があれば教えてもらえると嬉しいです。

最後に

そもそもツッコミとして、「データ加工するならエクセルマクロを使わずにpythonとかRとかもっとまともな言語使えよ」という言葉が来そうな気がします。

ただ、個人的にはエクセルマクロ（VBA）は大好きですし、初心者にもおすすめしたいです。

自分のような非エンジニアだと、セキュリティの関係などでPythonの開発環境とかすごく用意しにくいんですよね。

（あと、コマンドプロンプトの真っ黒な画面が怖かった）

その点エクセルマクロは、開発環境の用意はプロパティでチェック項目を一つオンにするだけだし、入門書がたくさんあるし、セルの挙動を追えば視覚的にプログラムを理解できるし、初心者に優しいです。

（そのやさしさが上述したとおり悪魔の罠なわけですが。）

最初は計算用シートに頼ってでもエクセルマクロからプログラミングを始めて、本格的なデータ加工をし始めたあたりで計算用シートという諸悪の根源から脱却する。

さらに本格的なデータ処理を行うために、PythonやRなど別の言語を習得したり、エクセルからSQLデータベースやACCESSなどに切り替えていく、というプロセスがいいのではと個人的に思います。

Permalink | 記事への反応(18) | 04:31

ツイートシェア

■anond:20240218222019

いや公正に比較しようにも求められる能力が違うんだから比較できんでしょ

時速60㎞で突っ走りながら代わる代わる入って来る視覚情報処理だとか車長まで含めた空間把握能力だとか緻密な操作はITに要らんでしょ？

逆にじっと座ってアルゴリズム構築して変数とか一字一句合わせながら実装してバグが出たら脳内デバッグしたりする能力はトラック運転手に要らんでしょ？

職に求められる能力と、個人の得意な能力は違うんだからどちらが簡単とは言いようがないでしょ

というかどちらも簡単じゃないから年収500万貰えるんちゃうの？

Permalink | 記事への反応(0) | 10:18

ツイートシェア

■anond:20240217072658

キミのLinux信仰マジでよくわからない。少なくともLinuxカーネル解読室くらいは読んだのかい？

何度か書いてるけど日本語環境のデバッグ兼ねてなきゃデストリでもWindows使うぞ

でもワイくんも音楽の素養ゼロなのにクラシックとか聴くからそれと同じようなものなのかね

ワイくん、素養ゼロなので、コンサート行くと、演出に『？！』ってなる

最近、『？！』ってなったのはピアソラの『鮫/Escualo』、こんなお行儀のいい鮫聴いたことねーぞ？！ってなったが、

同じアーティストがYouTubeにあげている鮫はフツーにスリリングでお元気があった

プログラムに合わせた演出・アレンジなんだろうなとは思ったが素養ゼロなのでよくわからない

でもまぁ何か好きよ

Permalink | 記事への反応(0) | 07:42

ツイートシェア