すべてのカテゴリ

面倒なCSS!？Web プログラミングには基本的に HTML/CSS/Javascript が必要です。この中でも意外に面倒なのが CSS です。この記事ではなぜ CSS が面倒なのか考えてみました。HTML と Javascript は意外にシンプルHTML と Javascript の方が、学習することは多いのはあきらかで。 しかし、HTML の場合は、記述が誤っていると目で見てわかりまし、間違いの箇所は比較的簡単に特定できます。Javascript の場合は、少し事情が変わってきます。 Javascript の問題は、大きく二つあります。＊　Javascript の記述上の誤り（文法のエラー）＊　プログラムの論理的な誤り（バグ）　Javascript の記述上の誤りは、その箇所を実行した場合はエラーメッセージがコンソールに表示されるので間違いの場所の特定は簡単です。 プログラムの論理的な誤り（バグ）の場合は、場所の特定は少し難しくなります。しかし、デバッガーなどを使って、データの中身を見たりして工夫することで、バグを見つけることができます。いずれにしても、プログラミング言語でプログラミングをする場合、バグを見つけて修正するのはプログラミング開発の一部です。CSS は何が違う？CSS が特別というわけではありませんが、CSS の場合、問題の箇所を見つけるのが意外に難しいという事情があります。 HTML と同様に目に見えるという点では、想定通りに動作しない場合は、思ったような表示になりません。そいう点では簡単に問題が見つかりそうです。しかし、実際は表示が思うようにされないけれ

見えない物は難しい！Web プログラミングは大きく二つの部分に分かれます。一つは、UI の為のプログラム、もう一つはデータ処理のためのプログラムがあります。UI は目に見えるので、上達も早いのですが、データ処理は時間がかかります。２種類のプログラミングWeb プログラミングは、Web ブラウザ上の UI を担当する部分と、入力したデータなどを処理する部分に分かれます。UI の部分は、動作が目に見えやすいので何が起きているかもわかりやすいので、比較的習得もしやすく、デバッグも基本的には楽です。 加えて、React や Vue などのフレームワークも利用できますし、ある程度パターンも固定されているので参考にできるサンプルコードも多く初心者でも、コツを掴むのが簡単です。一方で、データ処理の方は、動作が見えにくく、アプリケーションによって扱うデータも異なるので UI に比べると難易度が高くなります。見えないと難しい理由は？見えないと難しい理由は、何が起きているか外側からはなかなかわからないからです。 わからないものは、何か問題が合った場合には、まずは何が起きているかを見極めないと対策が取れません。 いうならば、推理小説で言うところの密室殺人事件のようなもので、密室の中でないが起こっているのかを見つける必要があります。プログラミングの場合は、密室というわけではなく、中に入れば何が起きているのかを見ることができる点が違います。 これを助けてくれるのが、デバッガーです。デバッガはデータの様子、データがどのように変わって行くのかを覗く事ができるツールです。これを利用すると、見えないデータの動き

見やすく管理しやすいコーディングのコツプログラムが小さい場合はあまり問題になりませんが、プログラムが複雑になって大きくなってくると、コーディングのやり方によっては、管理が大変になる場合が多くなります。この記事では、「見やすく」「管理しやすい」コーディングのコツを紹介します。誰がプログラムを読むか？最初にプログラムを書いた人以外が、プログラムを見る（読む）ことは、現実的にかなりあります。 一人で開発を行っていても、依頼されてプログラムの開発を行う場合、納品後の管理は依頼者側で行う場合が多くなります。また、会社などでは、最初にプログラムを書いた人が退職したり、別の仕事に就いたりして、その後の管理は別の人が行う場合もたくさんあります。また、プログラムを書いた本人でも、時間が経つと細かい部分は忘れてしまう場合が多く、開発してしばらくして何かの問題が出て、プログラムのコードを見直す場合には意外に時間がかかってしまうものです。こうした事態に備えるため、業務でプログラムを開発する場合はドキュメント（設計仕様書）を作成するのが普通です。 しかし、ドキュメントがあっても、プログラムのソースコードはいずれにしても読む必要があります。 つまり、ソースコードが見やすく、管理しやすいよう書いてあるかどうかで、そうした管理のために費やす時間は大きく変わってきます。ハードコーディングの問題管理が面倒なプログラムに「ハードコーディング」が多いプログラムがあります。 「ハードコーディング」とは、プログラムの中に「具体的な値」を直接書く書き方です。例えば、最近の投稿で紹介している、Vue と Firebase に

『プログラミングで切り開く、新しい未来♪』こんにちは！塾講師のdainarです。まもなく待ちに待った『黄金週間』G.W.がやって来ますが新型コロナウィルス（さらに進化している💧）の感染拡大が止まりませんね。今年のG.W.も何も”思い出づくり”ができずに過ぎていくのだろうか・・・「いやいや贅沢な悩みやな」(￣◇￣;)さて、気を取り直して今回も前回の”プログラミングで横断幕をつくる”の続きです。目次 1. 大きく表示する2. デバッグする3. forループを使って大きく表示する前回の復習。下の画像のように「はじめてのPDF」という文字列をファイルにしました。今回は１ページに１文字ずつ大きく表示するプログラムを考えて、横断幕を作ります。まずは実際のプログラムを見てみましょう！ここでは簡単に「お」という文字をA4サイズいっぱいに表示してみます。（プログラムの実行からファイルの開き方までは大丈夫ですね？）A4サイズは、横幅が210mm、高さが297mmという規格になっています。なのでフォントのサイズを横幅と同じ210mmに指定すると、文字が横幅いっぱいの大きさになるはずですが・・・お！？実際はこのようにはみ出してしまいました💦　なぜ？？？デバッグする参考図書に書いてあるプログラムとの記述ミスがないか”目を皿のようにして”見比べます。特に今回修正をした箇所を中心にmoji = ” お “フォントの大きさは用紙横幅と同じ210mmとするpdf.setFont(“HeiseiKakuGo-W5”, 210 * unit.mm) —— フォントの大きさを210mmにする高さh = (297 –

正しいバグの治し方！プログラムには殆どの場合、「バグ」があるものです。余程規模の小さなプログラムを除けば、小さなバグはどうしても残ってしまう場合も多くなります。プログラムを作ったら、まずは動作確認やテスト（検証）をして、意図しない動作の修正を行います。この記事では、正しいバグの治し方について考えてみました。バグとは何か？プログラムで意図しない動作をする場合がありますが、これをバグと呼んでいます。少なくても検証をきちんとしていないプログラムには基本的にバグは存在する場合が殆どです。テストをしながらこうしたバグを修正する作業をデバッグと呼んでいますが、プログラム開発では重要な作業になります。ところで、バグを修正する際はどのように修正しますか？シンプルに言えば悪いところを見つけて、それを直すという作業になりますが、実は意外に簡単ではありません。バグの原因はいろいろ考えられますが、よくあるケースを例に挙げると：＊　変数などの書き間違い＊　処理の条件の間違い　（プログラムの論理の間違い）＊　想定外の条件の発生＊　タイミングに関連した不具合などがあります。バグの原因はこれ以外にもたくさんありますが、この辺りが良くあるバグの原因です。プログラムを書く人や書き方にもよりますが、書き間違いはよくあるミスです。最近は、プログラムを入力するエディタの機能が向上しているので、ある程度のミスはプログラムを入力する段階で気づく機会も増えているので比較的少なくなってきています。ところが、プログラムの論理的なミスは発見するのが少し難しくなります。 プログラムの書き方自体には問題がなくても、処理の条件や想定外の

バグの少ないプログラムの作り方プログラムが想定通りに動かない原因を「バグ」と呼んでいます。現状では、バグを完全になくすことは難しいとされています。対策としては十分なテストをして、可能な限りのバグを修正してからリリースすると言う方法が取られています。しかし、プログラムを書く人によって、プログラムに潜んでいるバグの数の差はかなり大きな開きがあるのも現実です。この記事では、バグの少ないプログラムを作成するコツを紹介しています。バグの分類一言に「バグ」といってもいろいろなタイプ（種類）のバグがあります。まずは、バグのことを理解するために大まかに分類していみます。コンパイルや実行時の文法エラーなどはここでは除外して考えます。そうすると、大まかに以下のようなバグを想定することができます。＊　入力のミス＊　プログラムの論理的なミス＊　想定外の動作　あたりがバグの大きな分類です。入力のミスは、例えばループのカウントで使っている変数、「i」が正しい変数であるのに、実際は「j」と入力されている場合です。あるいは、Python などのように変数を宣言しないで利用できるプログラミング言語の場合、本来「abc」と言う変数を使う場面で、「dbc」などと入力するような場合です。 いずれの場合も本来使うべき変数と別の変数を使うことになるので、殆どの場合は、プログラムは正しく動作しません。この種類のバグは、プログラムを入力する際に発生するバグです。プログラムを動かす前に注意深くチェックすれば見つけることは可能です。しかし、多くの場合、気づかずにプログラムを実行して運が良ければ見つかる種類のバグになります。最近は

ココナラでPICマイコンのプログラムを作成するサービスを提供しています。作成するプログラムの中にはPIC への入力信号を元に信号を出力するものがあります。入力信号はレベル信号の場合が多いのですが、中にはパルス信号だったり入力信号が比較的短時間で変化するものや複雑なものがあります。ゆっくり動くレベル信号はタクトスイッチの手動操作で入力してデバッグしますが、パルス信号等の場合はファンクションジェネレータ等が使えると思います。複雑な入力信号が必要な場合は模擬信号を作って入力する必要に迫られることがあります。そのような時にRaspberry Pi Pico を使って模擬信号を作ってデバッグすることがあります。MPLAB X でPICを動かしながら、Thonny でPico を動かしてデバッグしています。MicroPython で作る模擬信号はスクリプト言語故に、パラメーターを変えながら試す際に手軽で便利だと感じています。Pico の信号電圧が3.3Vなので５Vで駆動しているPIC の場合は信号極性（High/Low）反転に注意しながらトランジスタで信号電圧を合わせて使います。PIC の場合、組み込み系のご相談が多いのですが、このような模擬信号を使うことで在宅でも対応可能な範囲が広がるように思います。今後とも宜しくお願い致します。

　何種類かのデータベースを扱う技術者にとって、専用ツールを使用したクエリテストは避けられないものです。　　私がストレスを感じるのは、データベースエンジンごとに、ユーザーインターフェースの使い勝手が全然違って、「ただクエリをテストしたいだけ」なのに、クエリに集中できないことです。　そこで私が愛用しているツールが「WinSQL」です。　　　www.synametrics.com/SynametricsWebApp/Download.do?ProgName=WinSQL　これは様々な種類のデータベースに対して、一つの共通したインターフェースからクエリを発行することが出来るツールです。　これを使用すると、データベースにアクセスするプログラムを開発する、一般的な手順の中で(１) 画面設計／作成(２) DB接続※場合により、トランザクション処理を開始。(３) SELECTクエリでテーブルデータを読込み。(４) (３)項の結果に応じて、INSERT, UPDATE, DELETEなどのクエリを発行。(５) SELECTクエリで、データの不整合がないか確認。※場合により、トランザクション処理を終了。といった流れの (３)(４)項を 効率的に進めることができます。非常におすすめのツールです。

Javascript と TypescriptWeb 開発では、Javascript は欠かせませんが、最近では Typescript も注目されています。Typescript を勉強しておいた方が良いのか迷う場合も多いと思います。どちらが良いのかを考えてみました！Javascript は必須Web 開発をする場合、バックエンドは別にしてもフロントエンドの Web ブラウザで動作するプログラムは Javascript になります。したがって、フロントエンドに関わる開発では Javascript は必須のプログラミング言語という事になります。そうした、理由もあって Javascript を学習する人はたくさんいますが、最近では企業のある程度の規模の開発では Typescript が使われるケースも増えています。そうなってくると、Typescript を学習しておいても損はなさそうな状況になりつつあります。ところで、Web 開発者を目指してプログラミングを学習する人の場合はどうでしょうか？この連載で既に書いてきたように、「今必要な事に絞って学習する」ことで、学習を効率よく進めて短期間で成果を出すという考え方で言えば、Javascript でプログラミングを書ければ、Typescript はなくても良い事になります。そう考えると、Typescript を初心者が学習するのは後でも良いという事になりそうです。Typescript の正体とは？ところで、Typescript の正体をご存知ですか？ 一言で言うならば、Typescript は Javascript をベースに、変数の型や初

エラーの原因特定プログラムの実行中にエラーが発生した場合やプログラムに問題がある場合、その原因を特定する事が重要です。 一つのプログラムの場合には殆どの場合、そのプログラムの中に問題があると考えるのが一般的です。 しかし、Web サービスなどの場合は、フロントエンドとバックエンドで別々のプログラムを動かす場合も多いので原因の特定が難しくなる場合が殆どです。この記事では、Web サービスでの問題の見つけ方を簡単に紹介します。プログラムを取り巻く環境プログラムを作成して実行して問題が発生した場合、その原因の殆どはプログラムその物にある事が多くなります。 しかし、実際にプログラムが動く仕組みを考えると問題の発生は、そのプログラム事態以外にも要因があることがあります。例えば、ある PC 上で実行できるプログラムを作った場合でも、作成したプログラムは、実行している「システム」という観点から考えると極一部です。どういう事かというと、作成したプログラムを動かすために必要になる要素にはいろいろな物が含まれています。＊　実行するコンピュータ（スマホや PC）＊　プログラムを実行する OS(オペレーティングシステム)＊　プログラムが利用しているライブラリや外部のモジュール＊　作成したプログラム　実際にプログラムを実行するには、これらの要素が必要になるので、どの部分にも問題がある可能性があります。さらに、一般的な Web サービスのプログラムになるとさらに別の要素が増えるのはこれまで紹介してきた通りです。＊　Web サーバー（ホスティングをする、サーバーから、OS、HTTP のサービスなど）＊　ネッ

「え、またバグ！？」「クエストが進まない…」「せっかくガチャ引いたのに、アイテムが消えた！」ソシャゲをプレイしていると、 予期しないバグ に遭遇することがありますよね。でも、 バグが起きたとき、適当に運営に報告しても対応してもらえないことがある んです。「問い合わせしたのに無視された…」「他の人は補填もらってるのに、自分だけダメ？」そんな経験、ありませんか？実は、 運営が動きやすい「正しいバグ報告の方法」 があるんです！これを知っているだけで、 修正が早まったり、お詫びアイテムがもらえる可能性が上がる んです。過去には、「ガチャが正常に動作しなかった」と 明確に報告した人には補填があった のに、「ガチャがバグってる！」と 曖昧な報告をした人には対応なし という事例もありました。例えば、 「○○のステージでフリーズする」 ではなく、「2025年3月22日 18:30、iPhone13（iOS17.1）、イベントクエスト○○のボス戦後にフリーズ」と詳しく伝えることで、運営の対応がスムーズになります！この記事では、 「運営が動くバグ報告の方法」 を テンプレート付き で詳しく解説します！読めば、 スムーズな修正・補填・対処法がわかる ので、最後までしっかりチェックしてくださいね！はじめに｜バグ発生！どうすればいい？バグ発生時、最初にすべきことは？ソシャゲを遊んでいると、 「バグ」や「不具合」 に遭遇することがあります。例えば…ゲームが突然フリーズして進まないクエスト報酬が受け取れないガチャで当たったはずのキャラが消えた課金アイテムが反映されないランキングが更新されないこうしたバグに直

「あれ？これって、ダレが買ったの？」・・・「TEMU」・・・「テム」って、あの最近、めっちゃ「ネット」等で宣伝しているヤツじゃろ～？！「テレビ」や「新聞」でもやっていたよ～な気がするけど～、確か「アメリカ」の「スーパーボール」でも「CM」やってたのとちゃうのん？！そういえば、ボクの「メルアド」にも「メール」がめっちゃ入っていたぞ～。ボクも前に「WISH」とかいう「激安サイト」で買い物したことあるけど、まぁ、あれは、一応「問題」って、それほど無かったような気がするけど・・・今は、全然利用してないけどね。何か「安いけど、それほどイイ品質でもナイかも」って思ったからじゃ。でも～、この「TEMU」って、ちょっと「ヤバ」くないかい？！中国の「激安サイト」じゃけど、何か「問題」がけっこうアルとのウワサじゃ。＾＾；でも、我が家でもダレが「TEMU」なんて利用したのじゃ？・・・「ママ」かな？・・・いや、はて？・・・ヤツか？・・・「ダーリン」か？・・・う～ん。やっぱ「ダーリン」じゃ！・・・でも「梱包（こんぽう）」も雑（ざつ）じゃね～、「茶色の包み紙で商品をグルグル巻きにして、ポンって送っているだけ」じゃん。でも、もし「箱」とかに入っている商品じゃと、箱がつぶれてしまうじゃろ～し、もしもの「商品が壊れるなんて普通にアルじゃん」って思ったのじゃ。ま、でも、買った本人は「大満足～♪」らし～。「ナニ考えてんネン！」でも、買った商品は、「下着」とか「デバッグ」とか、少々チカラが加わっても「大丈夫？」な商品ばっかだから、イイけど～、ちょっと「機械製品」とか「電子・電気関連商品」じゃと、かなり心配じゃ。でも、

QAに関するサービスをご提供してまいります！上村と申します。少しずつ、サービス開始に向けてコツコツと進めているところです。。よろしくお願いします♪第一弾のサービスは「自主制作物のHPやアプリ作品の体験レポートのご提出」としております！いつでもリリースはできる状況だけど、、実際にお客様に触れていただくまで、反響がわからないのはちょっともったいない気もします。リリース前にお客様目線での「操作しづらいところ」「わかりづらい部分になってしまっているところ」などを把握しておき、よりよい作品に改善できたら、今よりもっともーっといい作品になる！よりベストな状況でお客様に提供できるよう、お客様を幸せにしたいな。。という想いを込めて、サービスを作成しているところです。私の経験をフル活用します！ご興味のある方はＤＭをいただけますと幸いです。お気軽にどうぞ♪

はじめに「ちょっとお願いしたいんだけど…このプロダクト、テストお願いできますか？」そう言われて見せられたのは、完成間近の画面と、簡単な概要だけ。「仕様書…は、まだなくて。とりあえず触ってみて、バグがないか見てほしいです！」──実はこれ、QAとしてご相談いただく中でも、とてもよくあるシチュエーションなんです。個人開発や小規模チームでは、「正式な仕様書を用意する余裕がない」なんてこと、めずらしくありません。でも、そんなときでも、テストを始める方法はちゃんとあります。今回は、私がこれまでに実際やってきた「仕様がない状態からのQA」について、お話してみます。「仕様がない」ってどういうこと？まず、「仕様がない」というのは、本当に“何も決まっていない”という意味ではないんですよね。たとえば…・開発者さんの頭の中にある・Slackのメッセージでざっくり話した・FigmaやNotionにUIだけはある・以前のバージョンがなんとなくベースになってるこんなふうに、言語化・明文化されてないだけで、実は“期待される動き”は存在していることが多いんです。なので、QAとして最初にやるのは、「仕様があるかないか」じゃなくて、どこに“仕様のヒント”が隠れているか？を探すというアプローチだったりします。私が実際にやっていることでは、そんなときにQAとしてどう動くか？いくつか、私の定番パターンをご紹介しますね。● まずはユーザー視点で触ってみるいわゆる“アドホックテスト”のように、ざっくり触ってみて違和感や気づきを拾います。「これってこう動くと思ったけど、実際は違う？」といったポイントは、仕様を考えるうえでのヒン

EXCEL、ACCESSなどで使うVBAですが、ネットでコードがあるのでよく転用させて有効活用してます。 でも、コードそのままだとうまく動かないことが多いです。そこで、VBデバッグの方法をご紹介します。 Visual　Basicデバッグ方法 今回は、ACCESSで紹介します。 確認したいコードを見て、エラーがでる手前の左側をクリックするとデバッグで一時停止します。この状態でACCESSに戻って実行します。実行すると一時停止します。そこで、値も入ってくるので確認できます。 まとめ 簡単な操作でデバッグできますね。VB6全盛のころに、PC制御設計部の後輩に指導を受けた内容です。何事も真摯にお話をきくといいことありますね。部署が違うから関係ないってことはないと思います。

Django の便利な外部モジュール　 dj-database-urlDjango で利用できる便利なモジュールに「dj-database-url」があります。機能をちょっと見ただけだと余りメリットがないように見えますが、便利な外部モジュールです。特に、開発に「SQLite」を利用する場合は、インターネットに公開する際は別の SQL データベースに置き換えるケースが殆どです。こうした切り替えを上手く管理できるモジュールです。公開の際はデータベースを入れ替える場合が殆どです！前回も触れましたが、Django の開発時とインターネットに公開時では設定が違うのが普通です。 特にデータベースは、Web アプリや Web サービスの性能に影響する部分なので、公開時には MySQL や PostgreSQL など本格的な SQL データベースを使うのが普通です。 SQLite はデータベースと行っても一つのファイルにデータを保村する簡易的なデータベースなので、沢山の人が同時にアクセスするような使用は想定されていません。しかし、開発時は開発者以外のアクセスは基本的にないので、こうしたシンプルなデータベースで開発しても大きな問題ではありません。SQLite の場合、SQLiteBrowser など、データベースの中身をチェックできる便利なツールもあるので、開発時には便利です。先日紹介した、「django-configurations」で環境変数を使えばこの問題にも対処できますが、データベースの指定には、「dj-database-url」も便利です。dj-database-url を利用するには

こんにちは。大藏(大蔵)陽平と申します。フリーランスとして10年システム開発に携わるなかでバグ調査ほど「やり方次第で時間が大きく変わる作業」はないと感じています。闇雲にコードを追いかけていた時期と比べると、今は同じ調査を半分以下の時間で終えられることが増えました。その違いは、優先順位のつけ方にあります。①まず「再現条件」を徹底的に絞り込むバグの調査を始める前に、「どんな操作をしたときに、何が起きるか」を可能な限り具体的に整理します。再現条件が曖昧なまま調査を始めると関係のない場所を延々と掘ることになる。「特定のユーザーだけ起きる」「特定の時間帯だけ起きる」といった条件が絞れると、調査範囲が一気に狭まります。②「最後に変更した場所」から疑うバグは突然発生しているように見えて、多くの場合は直前の変更が引き金になっています。デプロイ履歴、コミット履歴、設定変更のログ。「何かが変わったタイミング」を最初に確認することで無関係な場所を調べる時間を大幅に省けます。③ログを読む順番を決めておくエラーログ、アクセスログ、アプリケーションログ。闇雲に全部読もうとするのではなく、「このバグならまずここ」という自分なりの順番を持っておくことが重要です。経験を積むほど、この判断が速くなります。デバッグは感覚ではなく、再現性のある手順で進めるもの。その考え方が定着してから、調査時間が安定して短くなりました。ご相談はお気軽にどうぞ。

“見落とし防止”のためのヒント「テスト項目、作ったけど…なんか不安」「チェックリストはあるけど、これで十分なのかな？」そんなふうに感じたこと、ありませんか？この記事では、“テスト観点”ってそもそも何？というところから、観点を考えるためのヒントまで、やさしくお話ししていきます。観点って、なに？テスト観点とは、「何をチェックすべきか」という視点や切り口のことです。・たとえばこんなものがあります：・機能が正しく動くか（正しいデータ入力、エラー処理 など）・操作しやすいか（UIの使いやすさ、ナビゲーション など）・セキュリティ的に問題がないか（認証やアクセス制限）・パフォーマンスが落ちないか（読み込み時間、同時アクセス など）つまり、「何を、どんなふうにチェックすべきか？」を考えるための“地図”のようなものなんです。観点が抜けやすい理由経験上、観点が抜けてしまうのには、こんなパターンがあります：・ユーザーの使い方を想像していない→「どんな人が、どんな状況で使う？」が抜けている・画面単位でしか考えていない→全体の流れ（登録→確認→保存→戻る…など）が見えていない・過去の失敗から学べていない→以前あったトラブルを参考にしていない「項目をひたすら並べて終わり」だと、どうしても見落としが出てしまうんですね。観点を考えるヒントでは、どうすれば観点をうまく出せるのでしょうか？私が現場でよく使っている方法をご紹介します。✅ ユーザーのストーリーを想像する「どんな人が、何をしたくてこの機能を使うんだろう？」と考えてみます。たとえば：・忙しい主婦がスマホで買い物をしているかも？・通信状況が悪い中でログイ

「QAまで手が回らない…でも、ちょっと不安」「バグが残ってないか心配だけど、自分ひとりでは確認しきれない」「テストって何から手をつけたらいいの？」「お願いするほどでもないけど、誰かに一度見てほしい…」そんなふうに感じること、ありませんか？実はこのお悩み、個人開発者さんや小さな開発チームの方からよく聞く声なんです。今日はそんな方に向けて、「テストや品質保証（QA）って、ちょっとだけ頼ってもいいんですよ」というお話をしたいと思います。QA支援は「ちょっとだけ」でも、大歓迎です「QAって、全部任せるもの」「準備が整ってから依頼するもの」そんなふうに思っていたら、どうか気軽に考えてみてください。こんな“部分的なご依頼”もよくあります：・作ったテスト項目のレビューだけ・今の仕様で、バグの観点が足りているかだけ見てほしい・「このアプリ、大丈夫そう？」って感覚的に見てもらいたい・テストを始めるにあたって、どう進めたらいいか相談したい実は、こうした“小さな依頼”こそ、開発初期や少人数体制ではとても効果的なんです。ひとつの気づきや、ちょっとしたアドバイスで、大きなトラブルを防げることもあります。実際に、こんな支援をしてきましたたとえば過去にはこんな事例があります：・治験管理アプリのテストケース作成＋テスト実施開発者さんの「一通りテストしたいけど時間が足りない」という声にお応えして、チェックリストの作成と、テストの実施をお手伝いしました。・カードゲームアプリの観点出し＋チェック項目作成仕様に沿ったテスト項目だけでなく、ユーザー視点の気づきも加えたことで、初期リリース前の不安がグッと軽減されたとのご

はじめに：テスト観点って、なんとなく難しそう？「観点って、どうやって考えるの？」「なんかセンスが要りそう…」そう思ったこと、ありませんか？実際、私も新人の頃は「この仕様、どこをテストすればいいの？」と悩んでばかりでした。でも今は、「観点はセンスではなく“考え方”で出せるもの」と思っています。今回はそのコツを、やさしく解説していきます。「テスト観点」って、そもそも何？テスト観点とは、かんたんに言うと「どこを注目して確認するか」という“着眼点”のことです。たとえば、ユーザー登録機能をテストするなら──入力値に間違いがあったらどうなる？メールアドレスは正しく保存される？パスワードは安全に扱われてる？といった「確認したいポイント」が、まさに観点です。観点を考えるための3ステップ「どうやって観点を出せばいいの？」という方へ、私が普段使っている3ステップを紹介します。ステップ①：目的をはっきりさせるまずは、「何のためにテストするのか」を考えます。安心して使えるようにしたい？不正利用を防ぎたい？ユーザーが迷わないようにしたい？目的がはっきりすると、「それなら、こういう点が気になるよね」という観点が浮かびやすくなります。ステップ②：対象をざっくり把握する仕様書があれば軽く読んで、どんな動きになるのかをイメージします。画面だけでもOK。「何ができるのか」がわかれば、観点のヒントになります。ステップ③：「もし◯◯だったら？」と仮説を立ててみる観点は、「もしも」に注目すると出しやすくなります。もし入力が空だったら？もし通信が不安定だったら？もし同じアカウントで2人がログインしたら？いろんな“もしも”

コードが動かない？デバッグ力を鍛えるためのステップバイステッププログラミングをしていると必ず訪れる「コードが動かない！」という瞬間。初心者だけでなく、経験豊富なエンジニアでも避けられないものです。でも、デバッグ力を身につければ、この「動かない時間」を大幅に短縮できます。今回は、デバッグ力を鍛えるための具体的なステップを解説します。ステップ1: エラーメッセージをしっかり読むコードが動かない原因の多くは、エラーメッセージにヒントが隠されています。内容が英語でも怖がらずに、何が問題なのかを冷静に読み解きましょう。エラーメッセージを理解することで、解決の第一歩を踏み出せます。ステップ2: 変更点を振り返るコードが動かなくなった場合、最後に変更した箇所を思い出してみましょう。エラーの多くは、新しく書いた部分や編集した部分に原因があります。必要であれば、その変更を一時的に元に戻して、どこに問題があるのかを絞り込みます。ステップ3: プロセスを分解する動かないコードをいきなり全体で確認しようとすると、問題が見えにくくなります。プログラムを小さなパーツに分けて、1つずつ動作を確認してみましょう。「どこまでは正しく動いているか」を特定することが重要です。ステップ4: 他人の視点を取り入れるデバッグが行き詰まったら、同僚や仲間に見てもらうのも有効です。他人の視点を借りることで、意外と簡単に解決できることがあります。また、オンラインのフォーラムやコミュニティで質問するのも一つの方法です。ステップ5: 検索エンジンをフル活用するエラーの内容をそのまま検索エンジンに入力することで、解決策にたどり着ける

こんばんは🌸柿ピーって最高ですよね… どうでもいい情報なんですけどBBQ味って…知ってます？最近見ないんですよね！！おそらく期間限定で出してやがるんですけどなんというかチリソースみたいな味がしてとても美味しいんですよ♡ 柿ピーって柿の種よりピーナッツの量が少ないからいかに効率よく柿の種とピーナッツを一緒に食べれるかの勝負なんですよ！私は最初に柿の種を減らして途中からピーナッツと一緒に食べてます。 また余計なことを… さて本題です！！ そんなこんなで第二のサービスを出品いたしました！Next merchandise！！！ デンッ！ 【ゲームのテストプレイ・デバッグ】 元々小さい会社でゲームデバッグをしていたこともあり、私でも役に立てるならやってみようかな…と。 色んな人に「何の仕事してるの〜？」と聞かれて「ゲームのデバッグしてるよ〜」って言うと面白いほど皆首を傾げるんですよ！そりゃそうだ！私もこの仕事を始めた時はデバッグ…？なにそれ言いづら…って思いました。 なので「ゲームのバグを見つけるお仕事だよ」っていつも教えるんです！ 稀に「えぇ〜！？デバッグしてるんだ〜！！」って返されるとおぉぉぉ！と感動して手を握りたくなるんです。 実はむちゃんこ機械音痴なんですよね！最初はPCすら使えませんでした。なのでプログラミングとか難しいことは全くわかりません！基本的な操作のみの最低限でなんとかやってきました。なのでその分どれだけ分かりやすく丁寧に報告できるかを心がけています！ 文章って本当に理解してもらえなかったり違う解釈されてしまったりするんですよね…どうしたら理解してもらえるかを常に考えて

[👦質問者] WordPress開発で直面する問題を効率的に診断し解決するには、どのようなデバッグ技術やツールを推奨しますか？ [😺阿修羅ワークス] WordPress開発中に直面する問題を効率的に診断し、解決するためには、いくつかのデバッグ技術やツールを利用することが推奨されます。 WordPressでは、wp-config.phpファイルにあるWP_DEBUG定数をtrueに設定することで、警告や通知、エラーメッセージを画面に表示させることができます。 これにより、問題の原因を速やかに特定できます。 さらに、WP_DEBUG_LOGをtrueに設定すると、エラーメッセージがwp-content/debug.logファイルに記録され、WP_DEBUG_DISPLAYをfalseに設定することで、画面上にエラーメッセージを表示させずにログファイルにのみ記録することも可能です。 Query Monitorは、データベースクエリ、PHPエラー、フックとアクション、HTTP APIコールなど、WordPressサイトのさまざまなデバッグ情報を記録する強力なプラグインです。 このプラグインを使用することで、パフォーマンスのボトルネックやエラーの原因を簡単に特定できます。 ブラウザの開発者ツール（特にChrome Developer ToolsやFirebug）は、HTML、CSS、JavaScriptの問題を診断し、リアルタイムでコードを編集して結果を確認するのに非常に役立ちます。 ネットワークパフォーマンスの分析や、DOM要素の検査も行えます。 XdebugはPHPのデバッグを行うた

Docker Compose を使ってみる！Docker の利用例として、Django で作成したアプリを docker 上で動かす際には、「Docker Compose」を利用しました。この記事では、Docker Compose について簡単にまとめてみました。Docker Composer はどんな時に必要か？最初に、知りたいのは「いつ」Docker Composer を使うかだと思います。 一言で言えば、複数のコンテナ（Container）を利用する場合に使います。例えば、Web サーバーのコンテナとデータベースのコンテナを別々に動かして一つのサービスやアプリケーシんを作る場合です。前回の Django の例では、データベースや、HTTP のリクエストを管理する NGINX や、Django のアプリケーションサーバーなどを利用するために利用しています。Docker Composer を利用する場合、その設定は「xxx.yml」という設定ファイルに記述します。 このファイルで、どのようにイメージを作成（build）して、利用する Docker コンテナをどのようにインターフェースして、どのようにサービスやアプリを起動するかをまとめて設定します。少し、規模の大きなサービスやアプリの場合、複数のコンテナを組み合わせて利用する場合が殆どなので、Docker Composer は、そうした少し複雑で大きなサービスやアプリを Docker で動かす場合に必要になってきます。Docker Compose の基本設定Docker Compose を利用する場合でも、Docker を使う

Web アプリ開発の「見えない時間」とは？仕事として、Web アプリを開発する場合、納期は重要です。 納期までに仕事が終わらないと発注元にも迷惑をかけてしまうので、予定をしっかり立てて納期に間に合うように開発を進める事が求められます。仕事を受ける場合、基本的には「自分に出来ると思う」仕事を受けるのが普通なので、大まかにはどれくらいでプログラムが書けるかは感覚的に分かる場合が多いと思います。ところが、納期や品質はトラブルが多い部分でもあります。大きな理由は「見えない時間」が存在するからです。見えない時間の正体見えない時間とは、予め計画されていない時間の事です。Web アプリの仕事の場合、プログラムの作成にかかる時間は見落とされる事はほぼありません。誰でも、考える時間だからです。しかし、テスト（検証）とデバッグの時間は見落とされたり、予想以上に時間がかかる場合があります。それが原因で、納期が遅れたり、納品した Web アプリがきちんと動作しないというトラブルに繋がる事がよく起きます。テスト（検証）は軽視されがち！特にテスト（検証）は、実際のプログラムを各作業（コーディング）に比べると軽視されがちな傾向があります。これは、テストをしないという意味ではなく、テストを行う「ケース」が限られている事が原因になる場合が多くなります。Web アプリに限らず、プログラムを開発する場合、思った通りに動作するかをチェックすることは誰でも重要だと認識しています。したがって、殆どの場合、テストがされないという事はほとんどありません。仕事で開発したプログラムでなくてもテストはされています。問題は、テストを

こんにちは、Ruaです。ふだんはゲームやアプリ、WebサービスなどのQA（品質保証）に長く関わっていて、今はメガベンチャー系企業でQAリードをしています。今回は、「開発初期の段階からQAって必要？」というテーマでお話ししたいと思います。「まず動くものを作ってから考えたい」という個人開発や小規模チームの気持ち、すごくよく分かります。でも…あとから直すのって、すごく大変なんですよね。QAってテストだけの話じゃないんですQAというと、「リリース前にバグを見つける役割」と思われがちなのですが、じつはもっと広い視点でプロダクトに関わる立場でもあります。たとえば、・仕様の“抜け漏れ”に気づく・ユーザー視点で「これ、わかりづらいかも…」と指摘する・優先順位の整理を手伝うといったように、“作る前”や“作っている途中”にこそ価値が発揮できる場面がたくさんあるんです。“後戻り”はコストが跳ね上がる「とりあえず作ってみて、あとで直せばいいでしょ？」……それ、本当に直せますか？プロダクト開発って、一歩進むごとに周辺の仕様やコードが複雑になっていきます。つまり、あとから直すには「つながっている他のところ」も直す必要があるんです。結果として、・修正範囲が広がる・スケジュールが押す・テストし直しになる・モチベーションが下がるなんて悪循環に…。QAは「リリース直前に慌てて呼ぶ存在」ではなく、もっと前から一緒に走る仲間としていると、こうした手戻りを未然に防げるんです。初期から取り入れられる“軽いQA”とはいえ、いきなり「がっつりQAを入れよう」となると、ハードルが高いですよね。そこでおすすめしたいのが、“軽めの

「テストって、何をすればいいの？」「バグが出てこないか、ちょっと不安…」そんなとき、QA（品質保証）の力を借りられるって知っていましたか？一人でがんばっている開発者さんや、少人数チームで走っている方にとって、品質のことまで手が回らないのは自然なこと。でも、だからこそ“ちょっとだけ”QAを頼ってもらえるとうれしいのです。今回は、「QAに何が頼めるのか？」をわかりやすくまとめてみました。1. QAは“テストだけ”じゃないんです「QAって、バグを見つける人でしょ？」実は、それだけではありません。QAは、開発の前・途中・終わった後、いろんなタイミングで「見落とし」を防いだり、「これで大丈夫？」を一緒に考えたりできる存在です。例えるなら、道に落ちている石を拾っておいたり、「この先に坂道があるよ」と声をかけたりする“伴走者”のようなイメージです。2. こんなタイミングで頼れますQAに相談していただけるタイミングは、思っているよりたくさんあります。たとえば…開発初期：「テストのこと、まだ何も考えてない…」実装途中：「ざっくり動くようにはなったけど、ちゃんとチェックできてない」リリース前：「動作確認したけど、誰かに見てほしい」運用中：「不具合があったとき、どう対処すべきかわからない」どの段階でも、QAは「いま必要な品質の視点」でサポートできます。3. QAにできる具体的なことたとえば、私がお手伝いできるのはこんなことです。・テストの 計画づくり（何を、どう確認するか）・テストケース・チェックリストの 作成・探索的テスト／アドホックテスト でのバグの洗い出し・「この仕様で大丈夫？」という 壁打ち

「品質保証（QA）」って、どんなイメージがありますか？マニュアルやルールに厳しくて、手順どおりにチェックしていくような…ちょっと堅苦しくて、近寄りがたい印象を持っている方もいるかもしれません。でも実際は、もっと柔らかくて、チームに寄り添う仕事なんです。実は“気づき”の積み重ねが大事な仕事品質保証の仕事って、よく「間違いを見つける人」って思われがちです。もちろん、バグを見つけるのも大事な役割のひとつ。でもそれ以上に大事なのが、「違和感」や「不安」に気づけることなんです。たとえば…「この動き、ユーザーにとって分かりづらくないかな？」「仕様がふわっとしてるけど、これはこのままでOK？」「この機能、他の操作とのつながりがちょっと不自然かも？」…といった“なんとなく引っかかる感覚”を言葉にして、開発チームと一緒に、どうしたらより良くなるかを考える。それが、品質保証という仕事の一番の役割だと私は思っています。QAって、プロダクトの相談役です小さな開発チームや個人開発では、「仕様を誰かに見てもらいたいけど、エンジニア同士で忙しくて相談できない」「品質のことを気にしたいけど、どこから手をつけていいかわからない」…そんな声をよく聞きます。そんなときこそ、QAはチームの“相談役”になれる存在です。仕様の確認からテストの進め方、開発効率と品質のバランスの取り方まで、「ちょっと聞いてほしい」ことに寄り添えるのが、QAの強みです。Ruaのご紹介私はこれまで、ゲーム・アプリ・Webサービスなど、さまざまなプロダクトのQAに関わってきました。現在はメガベンチャー系企業でQAリードを務める一方、副業として様々

Django のテストやデバッグに便利なツールバーDjango のフレームワーク自体に必要な基本機能が含まれていますが、利用すると便利な外部のモジュールもいろいろあります。その中でも便利なモジュールの一つがデバッグ用のツールバーです。この記事では、デバッグ用のツールバーの導入のやり方を紹介します。デバッグ用のツールバーのインストールこのモジュールは「django-debug-toolbar」と呼ばれるパッケージです。 Django のフレームワークに組み込みできるデバッグ用の「アプリ」です。利用する場合は、「pip」でインストールします$ pip3 install django-debug-toolbar django-debug-toolbar の基本設定Django のアプリの扱いなので、プロジェクトフォルダの「settings.py」の中の「INSTALLED_APPS」に登録します。INSTALLED_APPS = [    'django.contrib.admin',    'django.contrib.auth',    'django.contrib.contenttypes',    'django.contrib.sessions',    'django.contrib.messages',    'django.contrib.staticfiles',    'rest_framework',    'app',    'debug_toolbar'] さらに、「settings.py」の「MIDDLEWARE」にも追加します。MIDDLEWARE

システム工房Matsuが提供する。オンラインプログラミングスクール

※ブログ初投稿です。これから精進していきます※ゲーム業界で働くことは、多くの人にとって夢のような仕事です。私もその一人で、プログラマーとしてQA（品質保証）、デバッグ、リメイクなど、主に開発の最終工程に携わってきました。特に「ゲームの完成形を見る瞬間」や「自分が手がけた作品が世に出る瞬間」に感じる達成感は、それまでの苦労を吹き飛ばすほどの喜びがあります。私の仕事の中で、特に印象深かったのはデバッグ作業です。ゲーム開発が進む中で、バグを見つけて修正する作業は、非常に地道で時間がかかります。しかし、この作業こそがゲームの品質を保つために欠かせない部分であり、開発の最終段階ではその重要性が一層増します。バグを見つけた時の緊張感や責任感が大きくなる一方で、修正が完了した瞬間の喜びは言葉にできません。【描画不具合との戦い】開発の途中で多くのバグが報告されますが、特に「描画不具合」に関わる問題は私にとって大きな挑戦でした。リメイク作業では、元々のコードを対応機種用に書き換えることが多く、その過程で画面に何も映らないという問題が発生したことがあります。修正作業に1ヶ月以上かかり、その間、何度も試行錯誤を繰り返しました。その結果、ついに問題を特定し解決できた時の達成感は何物にも代えがたいものでした。画面に再び映像が表示された瞬間、心から喜びを感じました…（その間は精神的に非常にきつかったことも、今では良い思い出です（笑））【バグ修正の達成感】バグを修正した際の達成感は、ゲーム開発者として最も大きな喜びの一つです。開発中に直面する問題をひとつずつ解決することで、ゲームはどんどん完成に近づいていき