絞り込み条件を変更する
検索条件を絞り込む
有料ブログの投稿方法はこちら

すべてのカテゴリ

24 件中 1 - 24 件表示
カバー画像

ユーザーインターフェースの設計

ユーザーインターフェースの設計前回は、入力フォームを変更して四則演算をできるようにしました。利用しているフォームは数式の穴埋め形式になっています。計算をする場合、一般的な電卓のようなインターフェースの方が一般の方には使いやすい場合が多いと言えます。今回は、ユーザーインターフェースを変更して一般的な電卓のようにする方法について考えてみました。HTML でデザインこれまでの、ユーザーインターフェースは、数式の穴埋め形式のフォームでした。 今回は、一般的な電卓のようなユーザーインターフェースを実現します。 この記事では、プログラムの部分は取り敢えず別にして、まずはユーザーインターフェースを作成することにします。Web アプリの場合、ユーザーインターフェースは基本的に HTML で記述します。 今回の電卓形式のユーザーインターフェースは、電卓の数字を表示する部分(ディスプレイ部分)と数字や演算子を入力する部分(ボタン部分)に分けて考えることができます。 HTML では、「input」のタグでディスプレイ部分を、「button」のタグでボタン部分を記述できます。<!DOCTYPE html><html>  <head>    <title>Calculator</title>  </head>  <body>    <div class="calc">      <div>        <input class="display" type="text" />   
0
カバー画像

足し算以外もできるようにする

足し算以外もできるようにする穴埋め形式の数式のフォームを使って足し算をするプログラムを紹介しましたが、同じ要領で、引き算、掛け算、割り算もサポートできるとさらに便利です。この記事では、足し算のプログラムを拡張して、整数の子息演算をできるようにした例を紹介します。演算子を選べるように変更する足し算のアプリでは、計算できるのは足し算だけだったので、フォームには「+」を固定で表示していました。 この部分に変更を加えて、必要な演算子を選択できるようにすれば、引き算、掛け算、割り算もサポートできるようにできます。これには、HTML の記述を変更してフォームを変更する必要があります。<label>+</label> を以下のように変更します。<select onchange="operatorChanged(event)">  <option>+</option>  <option>-</option>  <option>*</option>  <option>/</option></select> HTML の「select」タグを使って、選択肢は、「option」タグで記述するだけです。演算子の変更を反映するプログラム側でやることは三つです。* 初期状態の演算子を設定する (最初にフォーム上で表示されている演算子をセットする)* 演算子の変更を検出して、現在選択されている選択肢を更新する* 「Calcullate」ボタンがクリックされたら必要な
0
カバー画像

改良版足し算プログラム

改良版足し算プログラム前回は、入力データのチェックを工夫することで、データを処理する前に想定外のデータの入力を制限するユーザーインターフェースの設計について紹介しました。この記事では、そのコンセプトを使って、実際に足し算をするプログラムにしてみました。今回のポイントは、ユーザーインターフェースとデータ処理を分けるという点に注目してみました。プログラムの設計の際には、この二つの境界をきちんと設定する事が大切です。データの処理は?このプログラムは、入力された二つの整数を足して結果を表示するというシンプルなプログラムです。 このプログラムのデータ処理部分は、実は二つの整数の足し算をするだけです。つまり、プログラムのデータ処理部分は以下の関数「add(a, b)」だけです。function add(a, b) {  return a + b;} 処理自体は、二つの整数「a」と「b」を受け取って、この二つの整数を足し算した結果を返すというシンプルなものです。残りのプログラムは?このプログラムのデータ処理部分は、至ってシンプルです。 では、残りのプログラムは何かというと、これがユーザーインターフェースになります。<!DOCTYPE html><html>  <head>    <title>Add Program</title>  </head>  <body>    <div>      <input id="opeland0" type="text" placeholder="Plea
0
カバー画像

誤った入力を防ぐインターフェース

誤った入力を防ぐインターフェースユーザーインターフェースをきちんと設計することで、誤ったデータの入力を防ぐ事が可能です。今回は、整数の値を入力するためのユーザーインターフェースの例を紹介します。ユーザーインターフェースの設計今回は、プログラムに渡すための、整数を入力するユーザーインターフェースを設計します。ユーザーインターフェースの設計の例なので、この例では、計算は行わず、入力された整数の値のみを表示します。* 整数を入力するためのフィールド* 入力された整数の値を表示するためのフィールド の二つを用意します。整数を入力するためのフィールドには、「Input data」というラベルをつけます。また、現在の入力された整数の値を表示するためのフィールには、「Current Value」というラベルをつけます。現在の入力された整数の値を表示するフィールドには、誤って利用者が入力できないように、入力できないように設定します。整数を入力するためのフィールドには、整数の入力を促すため、値が未入力の場合には「Please input integer value!」を、また、現在の入力された整数の値を表示するためのフィールドは、値が未入力の場合には「No input value」を表示します。入力された値が整数でない場合には、「Not an integer value」を表示するような仕様にします。整数を入力するためのフィールは、整数以外の文字を入力できないようにして、整数以外が入力された場合には、表示しないようにして、入力されたデータが整数でない場合には、「Please input inte
0
カバー画像

親切なユーザーインターフェースとは?

親切なユーザーインターフェースとは?前回は、コマンドラインより使いやすい、グラフィックベースのユーザーインターフェースを紹介しました。しかし、前回の例はシンプルなものでした。実は、GUI(Graphical User Interface)を利用すると、もっと利用者に親切なインターフェースを提供する事ができます。今回はその例を紹介します。タイプした文字をチェックするプログラムに必要なデータをタイプして入力する場合には、いずれにしてもプログラムが意図しないデータを入力してしまうことは避けられません。人間がタイプする以上、誤ってデータを入力する可能性をゼロにすることはできないからです。ただし、親切なユーザーインターフェースを設計する事は可能です。今回は、より親切なユーザーインターフェースの例を紹介します。期待しないデータが入力された場合に、それを利用者に伝えるようなエラー処理が必要な事は紹介してきた通りです。何がおかしいのかを利用者に伝えるために、実際に入力された(タイプされた)データをチェックすることで、エラーの詳細を利用者に伝えることが可能です。ポイントは、そのチェックを「いつ」、「どこで」するかで利用者の印象が変わってきます。これまでの例では?これまでに紹介した例では、入力が完了した後にデータをチェックする方法を使っていました。コマンドラインから必要なデータをプログラムに渡す場合には、全てのタイプが終わった時点でプログラムが起動されるので、データの入力完了後以外でのチェックが難しくなります。もちろん、改善する方法はあって、プログラムを起動した後にデータを入力できるようなプログラ
0
カバー画像

モダンなアプリにするには?

モダンなアプリにするには?コマンドラインで足し算をするプログラムができましたが、これは昔のスタイルです。最近のアプリは、GUI(グラフィカル・ユーザー・インターフェース:Graphical User Interface)と呼ばれる、もっと使いやすいです方法で作られています。NodeJS を使った場合には、コマンドラインでの利用になりますが、同じ Javascript のプログラムでも、Web ブラウザを利用するともっと、使いやすいプログラムにする事が可能です。今回は、Web ブラウザ上で足し算をするプログラムにしてみました。Web ブラウザで動くアプリ最近の Web ブラウザは、Javascript を使ったプログラムを実行できるようになっています。 Web ページを作る時に利用される HTML を使って記述すると、Windows パワーシェルのような「特殊」なウインドウを開いて実行しなくても、Web ブラウザ上で必要なデータを入力してボタンの操作で足し算の計算をするようなアプリにする事ができます。この場合、HTML でデータを入力するフォームを作って、その中に Javascript のプログラムを組み込むと Web ブラウザで動くアプリになります。まずは HTML でフォーム作り最初にやることは、HTML でデータを入力するためのフォームを作ります。<!DOCTYPE html><html>  <head>    <title>足し算のプログラム</title>  </head>  <body&gt
0
カバー画像

親切なプログラムを目指そう!

親切なプログラムを目指そう!コマンドラインからデータをプログラミに渡して、色々なデータで足し算ができるようになりました。便利なプログラムに近づいてきました。でも、一つ問題があります。今回は、利用者が期待通りの入力をしない場合について考えてみます。何もデータを入れないとどうなる?まずは、前回のプログラムのソースコードです。const data = process.argv;const a = parseInt(data[2]);const b = parseInt(data[3]);// Display input data A and Bconsole.log(a, b);const result = a + b;// Display the resultconsole.log(result); 前回は、コマンドラインから「1」と「2」を指定して実行しました。PS C:\Users\TH\Documents> node add.js 1 21 23PS C:\Users\TH\Documents> 別のデータ「123」と「456」でも問題なく動作します。PS C:\Users\TH\Documents> node add.js 123 456123 456579PS C:\Users\TH\Documents> 所が、何も入れないとどうでしょうか?PS C:\Users\TH\Documents> node add.jsNaN NaNNaNPS C:\Users\TH\Documents>のようになります。プログラムは正常に動作している!これ
0
カバー画像

足し算の計算「1+2=12」!?

足し算の計算「1+2=12」!?前回はコマンドラインからデータを受け取る仕組みについて紹介しました。今回は、コマンドラインから受け取ったデータを使って足し算をするプログラムに発展させて行きます!コマンドラインから受取ったデータで足し算では、前回のコードを基に足し算をするプログラムを考えてみます。const data = process.argv;const a = data[2];const b = data[3];// Display input data A and Bconsole.log(a, b);const result = a + b;// Display the resultconsole.log(result); このプログラムは、コマンドラインから二つのデータを受取って、それぞれ「a」と「b」と言う定数にセットして、その足し算をして、その結果を表示するプログラムです。これで、プログラムにコマンドラインからデータを渡して、足し算をする処理が可能になります。意外にシンプルですよね!コンピュータも間違える!?では、実行してみます。 プログラムは、「add.js」と言う名前で保存しています。PS C:\Users\TH\Documents> node add.js 1 21 212PS C:\Users\TH\Documents> コマンドラインで入力したデータは、「1」と「2」です。 それを、足し算した結果は「3」になるはずです。ところが、実行結果の二行目に表示されているのは「12」です。明らかに間違いですよね?実際にプログラムを入力して実行された方の
0
カバー画像

足し算をするプログラム

足し算をするプログラム前回はシンプルに、「Hello World」を表示するプログラムを紹介しました。今回は計算をするプログラムを紹介します。とは言っても前回と殆ど同じプログラムなので心配は入りません。今回は、プログラムの書き方よりは、どんなプログラムが便利かを理解することに重点をおきます。足し算をするプログラムも基本は同じ!今回は、足し算をするプログラムを紹介します。 基本的に前回の「Hello World」を表示するプログラムと同じです。 まずは、実際のプログラムを見てください。const result = 1 + 2;console.log(result); これだけです!実行方法は、前回と同じで、このファイルを「add.js」として保存します。 Windows Power Shell を開いて、ファイルを保存したフォルダに移動します。 あとは、以下のコマンドを実行するだけです。PS C:\Users\TH\Documents> node add.js3PS C:\Users\TH\Documents> 「1+2」の計算結果である、「3」が表示されています。今回は、計算結果を定数(const)である、「result」に入れて、この「result」を表示すると言うプログラムです。実際に表示をさせる「console.log(result);」の前に実際に計算を行う数式と、定数に代入するための行が追加されています。別の計算をしたい場合には、プログラムの数式「1 + 2」の部分を書き換えれば好きな計算を行う事ができます。同じ要領で足し算だけではなく、引き算でも、掛け算
0
カバー画像

固まらないプログラム

固まらないプログラムプログラムを利用していて、操作を受け付けなくなったり、何も反応しなくなったりした経験された方も多いかと思います。プログラムを開発する上で、このようにプログラムが反応(応答)しなくなるような事態を避ける事はとても大切です。この記事では、固まらないプログラムを作るのに大切な事を紹介します。基本機能は大抵動く!実は、プログラムの目的の機能(処理)は殆どの場合、「完成」したとされるプログラムの場合動作するのが普通です。これは、プログラムの開発者が基本機能の確認をしないと言うのは通常はないからです。プログラムのコーディングが終わったら、基本的な機能が動作するかは、まず最初に確認するのが常識です。これに問題があれば、問題の原因を見つけて修正して、動作するようにします。従って、「完成」したプログラムの場合、こうした基本的な機能は通常は動作するのが普通です。基本動作が動かない理由は?それでも、予定されたようにプログラムが動作しない場合は存在します。 これには、理由があって、一言で言えば「テストをしていないから」問題が表面化しなかったと言うのがシンプルな理由です。単純な機能の場合、テストで抜けが出る場合は余りありません。しかし、機能が複雑になると、期待されている通りに動作しない場合が増えてきます。現実的には、「全ての可能な動作」をテストするのは、複雑なプログラムの場合は、テストするのが難しいのでどうしても、テストしていないようなケースが発生した場合には、期待通りの動作をしない場合が出てきます。基本機能以外のテストはとても難しい!基本機能でも、テストに抜けが出る場合は現実には結
0
カバー画像

ユーザーインターフェースとデータ処理

ユーザーインターフェースとデータ処理一般的な利用者が使うプログラムの場合、PC やスマホ、タブレットのアプリとして作成する場合が多くなります。その場合、プログラムは大きく、ユーザ=インターフェースとデータの処理を行う二つの部分に分ける事ができます。この記事では、この分類について概要を紹介します。プログラムの基本はデータ処理この連載でも何回も紹介していますが、プログラムの基本は「データ処理」です。プログラムにあるデータを渡して、そのデータを処理した結果を取り出すと言うのがプログラムの基本になっています。ゲームなどのプログラムも基本は、データの処理を複雑にしただけで考え方は同じです。ただし、プログラムにデータを渡したり、処理した結果を取り出す「仕組み」も必要になります。現在のコンピュータの場合は、基本的にデータの処理を「CPU」で行なっています。この CPU が処理するデータは基本的に「二進数」のデータになります。この二進数は人間にはちょっと扱い難い数値で、このデータをやり取りするのはあまり便利な方法ではありません。そうした部分を含めて、実際にコンピュータでデータ処理を行う場合には、利用者である人間とコンピュータの間で上手くデータをやり取りするための仕組みが必要になります。その仕組みを「ユーザーインターフェース」と呼んでいます。プログラムには、この利用者とのやり取りを行うのに必要なユーザーインターフェースのプログラムと実際にデータを処理する、プログラムの本体に相当する部分に分ける必要があります。最近のアプリのユーザーインターフェース最近のスマホやタブレット、PC のアプリは、基本的
0
カバー画像

初心者に向いたテストとは?

初心者に向いたテストとは?プログラムのテストをする事は、初心者がプログラムのやり方を学ぶ上で有効な方法です。しかし、プログラムのテストも色々なテストがあって初心者に向いたテストと余り向いていないテストがあります。この記事では、初心者に向いたテストについて紹介します。色々あるプログラムのテスト一言にプログラムのテストと言っても、色々なタイプのテストがあります。 プログラムの実装を検証するという観点で、広い意味でのテスト(検証方法)を考えると幾つかの分野に分けて考える事ができます。分類のやり方は色々ありますが、一つの分類のやり方として、以下の三つの分野を紹介します。* コードレビュー* 基本機能のテスト* プログラムの実装の詳細のテスト 結論から言ってしまうと、初心者向けのテストは、「基本機能のテスト」です。基本機能、つまり、プログラムの「目的」をチェックするテストです。もう一つは、コードレビューです。コードレビューは完成したプログラムのソースコードを見て、コードの書き方や、プログラムの処理のやり方(論理)に大きな問題がないかをチェックする作業です。実際には、初心者がソースコードを一人で見てもある程度は勉強になりますが、経験者と一緒に見ないと難しい部分も多くなります。理由は、色々ありますが、初心者の場合、ソースコードを見る際にポイントとなる事がよくわからない場合が多いというのが大きな理由の一つです。しかし、実際にどのようにプログラム書くのかという意味で、参考になる部分もあります。データの流れを理解するプログラムの実装方法を学ぶという目的でプログラムのテストをする場合を考えてみます。
0
カバー画像

アプリケーションの品質を保つには CI/CDのCIについて

はじめにプログラム自体は、コーディングしてテストを行えば、はい出来上がりとなります。ただし、実際の現場では一人で開発することは少なく、チーム内の複数名で開発することがほとんどなのですその際、ほかの人が作りこんだ不具合が自分のプログラムに影響を与えるということが多々あります(もちろんその逆も多々ある)古い企業の場合、プログラム修正の翌日以降、チームの中の構成管理者が結合テスト環境のサーバにプログラムを適用する段階になって、コンパイルエラーが出るなどの問題に気づきます。その後は、何が悪い、だれが直したソースだ、と大騒ぎになって対応します。これが本番リリース直前だったとしたら目も当てられません。そこで近年では不具合の検出はできるだけ早く、自動的に行えるような仕組みが多くの企業で取り入れられています。そのような仕組みの一つが CI(継続的インテグレーション) と呼ばれています。CI(継続的インテグレーション)とはプログラムコードに変更があると、そのコンパイルからテストまで自動化する手法です。個々のプログラムからなるソフトウェアは、実際に一つにまとめて(インテグレートして)動かすまで何がおきるかわかりません。 不定期にインテグレートするような運用の場合、コード変更が大量になる傾向があります。その際、結合テストを行って不具合を発見しても、原因究明に多大な時間がかかることがよくあります。CI(継続的インテグレーション)を取り入れることで、コードを変更するたびにビルド・テストが自動で実行できるようになります。 細かい間隔で定期的にテストが実施できるので、即時に問題を発見でき、手戻りを最小限に抑
0
カバー画像

最近のプログラミング言語について(ざっとまとめ版)

仕事で新しい人に最近の業界動向を伝える機会がありまして。そういえばプログラムの言語って何があっただろう、いっぱいあり過ぎて消化不良!ということで私なりにまとめてみました。その方への説明は終わったのですが、たった1回の説明で捨ててしまうのはもったいないなーということで、ここで公開します!ウェブ系言語  フロントエンド… HTML、CSS、JavaScript  バックエンド … PHP、Ruby、Java、Python、Go、Scala など近年で最も多様な言語が出てきた分野のプログラミング言語です。盛衰が激しい。大きくフロントエンド(画面描画用)とバックエンド(内部処理用)の2つに分かれています。フロントエンドは3点セット(HTML、CSS、JavaScript)すべてをすべてを学ぶ必要がありますが、バックエンドはどれか1つ覚えれば十分です。余談ですが、ウェブ系言語の隆盛のなかで一番の進歩だと思うのは、今までJavaやPHPのソースの中で埋もれていた3点セットを フロントエンド と位置付けて独立させたことなのかなと思います。これによって比較的学習しやすい3点セットだけで開発を行えるようになり 開発者が増えたことは good だと思います。 アプリ系言語 Android系 … kotlin、Java  iOS系   … swift、 Objective-C AndroidはKotlin、iOS系はSwiftが主流  KotlinについてはJavaと非常に似通っているため、Javaを触ったことのある人なら取っつきやすいかと思います。ただそれならJavaの方でAndroidアプリ
0
カバー画像

縄張りを作ろう!

縄張りを作ろう!プログラミングでも仕事でも縄張りを持つことはとても大切です。ところで、プログラミングや仕事で言う縄張りとは何でしょうか、この記事ではプログラミングや仕事で大切な縄張りについて考えてみました。縄張りとは何か?いつものように、最初は縄張りについて考えてみます。 一言で言えば、「自分でコントロールできる範囲」のことです。逆にいうと縄張りを出ると、自分ではコントロールできない世界があるという意味です。もの凄くシンプルな事ですが、意外に難しいことでもあります。何故難しいかと言うと、縄張りの外に出ても自分でコントロールしようとする場合がかなりあるからです。簡単な例で言えば、貴方が住んでいる家を考えてみてください。基本的には、自分の家ならば、中に置くものや、中に入って良い人を管理・コントロールできます。しかし、家の外に出て家の前の道路は、殆どの場合は貴方の物ではないと思います。その場合は、その道路に他の人が車を止めても文句は言えませんよね?すなわち、貴方の管理外と言うことです。しかし、管理外にも関わらす、無理にコントロールしようとするとトラブルになります。 そう考えると、どこまでが自分の縄張りなのかをきちんと認識して置く必要があります。縄張りを作るには、一番大切なのは、境目がどこにあるかをきちんと知る必要があります。 境目をきちんと把握していれば、境目の内側はある程度、貴方がコントロールできると言うことです。プログラムでも仕事でも、その境目をきちんと作って取り組むとうまくいきます!プログラミングの縄張りとは?最初はわかりやすいプログラミングの縄張りから考えてみます。 プログラ
0
カバー画像

プログラミングの実績のアピールの仕方

プログラミングの実績のアピールの仕方仕事を受注するに当たって、「実績」は一つの評価基準です。いかに実績をアピールするかで仕事の受注も変わってきます。この記事では、実績をアピールする一つの方法を紹介します。実績とは何か?最初に、実績とは何かを考えてみます。 簡単に言って仕舞えば、実際にやった成果というのが実績という事になります。 ところが、実績をアピールするという事になると、実は結構むずかしいものです。例えば、「経験 5 年」というのが実績かというと、少し疑問ですよね? 大切なのは、5年間で何をやってきたかという事が実は一番大切な事です。従ってこの表現だけだと、アピールされた側でも判断に困るのが普通です。 この実績のアピールは、フリーランスが仕事を受注する時だけではなく、就職活動でも必要な物の一つです。 特に英語のレジュメを書く場合には、このアピールの仕方次第で面接に辿り着けるかの明暗を分ける事の一つです。ポイントは、今までどんなことをやってきたかを出来るだけ具体的に示すのが大切です。具体的とはどういうことか?そこで、今までの実績を具体的に示してくださいと言われた時、あなたならどのように示しますか?よく見かける表現には、「XXX の開発に従事した」とか「OOO のプロジェクトに参画した」と言われる方がたくさんいらっしゃいます。具体的な開発名やプロジェクト名が挙げられているので、「具体的」に説明した様に見えるので、こうした表現を使う場合が非常に多くなっています。実は、「XXX の開発」とか「OOO のプロジェクト」というのは、「場所」を示しています。大切なのは、その中(場所)で「あ
0
カバー画像

ドキュメントをいつかくか?

ドキュメントをいつかくか?プログラム開発でドキュメントが必要なのは既にいくつかの記事で書いてきました。この記事では、いつドキュメントを書くのが良いのかを考えてみました。ドキュメントは後回しになりがち!会社などでの開発は、開発の「プロセス」があるので、ドキュメントを作成するタイミングは基本的に決まっています。 特に、複数の人で開発する場合は、ドキュメントを基にした開発というのが基本なので、ドキュメントは、実際にコーディングに着手する前に作成するのが普通です。ところが、フリーランスでプログラムを開発する場合、一人で開発する場合が殆どなのでドキュメントが無くてもコーディング上はドキュメントが無くても進めることは可能なので、ドキュメントの作成は後回しになる場合が多いようです。仕事の中心がコーディングだと考えている場合も多くドキュメントの作成はどうしても二番目以降になってしまいます。会社では、何故ドキュメントを先に作るのか?では、会社ではなぜ最初にドキュメントを作成するのかを考えてみましょう。 幾つか理由がありますが、ここでは二つの大きな理由をあげてみました。全体の設計と仕事の割り当てをするため各モジュールのインターフェースの明確な定義当たり前ですが、全体の設計をしないと仕事の割り当てができません。会社では多くの人が一つの大きな開発に参加するのが普通です。そのために、まずは全体の設計をして、どのよう仕事の分担を決めます。また、全体の機能が明確になるので、テストの計画の開発もプログラムの開発と同時に進める事ができます。また、各モジュールの設計をするのに必要なインターフェースを明確にして、モ
0
カバー画像

プログラムの詳細のドキュメントは必要か?

プログラムの詳細のドキュメントは必要か?プログラムを開発する場合、ドキュメントが必要なのは言うまでもありません。プログラムの中身をどのように作るかを詳しく書いたドキュメントいわゆる、設計仕様書は必要でしょうか?この記事では設計仕様書の考え方についてまとめてみました。プログラムの設計仕様書とは?最初に、プログラムの設計仕様書とは何かをハッキリさせておきましょう。 これは、プログラムを「どのように作るか(作ったか)」を各ドキュメントです。 プログラムは将来的にも不具合の修正や機能拡張などで、手を入れることも多く、実際にコーディングをした設計者でもその中身の詳細を覚えていることは難しくなります。多くの場合は、最初のコーディングをした人と別の人がプログラムに手を入れる事も多いので、プログラムがどのように作られているかを書いたドキュメントがないと、コードを読みながら理解して修正する事になるので効率が悪くなります。従って、きちんと設計仕様のドキュメントを残すことはとても重要です。操作の説明(取り扱い)のドキュメントは、利用者のためのドキュメントですが、設計仕様書の場合は、プログラマーのためのドキュメントという事になります。従って、内容は専門的で問題ありませんが、プログラムがどのように作られているかを分かりやすく書く必要があります。操作の説明と詳しい設計仕様はどっちが大切?会社などでプログラムを開発する場合は、操作の説明のドキュメントも、設計の仕様書も両方きちんと作ることが求められます。当然と言えば当然ですが、フリーランスの場合は、短期間での開発を求められる場合も多く、時間との兼ね合いで両方
0
カバー画像

プログラムのドキュメントの書き方

プログラムのドキュメントの書き方プログラミングを仕事として行う場合、プログラミングのドキュメントは必須の物の一つです。趣味でプログラムを作るのとは違って、いろいろな人が作成するプログラムに関わってきます。作成するプログラムがどんな物なのかをプログラムを作った人以外の人が理解するのにドキュメントは重要です。どんなドキュメントが必要か?会社などでプログラムを開発する場合、沢山のドキュメントが作成されます。 基本的に、割り当てられた仕事毎に幾つか必要なドキュメントがあります。殆どの仕事には、「入力(インプット)」と「出力(アウトプット)」があります。 その仕事を進めるために必要な情報が「入力(インプット)」で、仕事の結果(成果)が「出力(アウトプット)」になります。プログラムを作る場合の入力は、「どんな機能が必要か」が入力(インプット)になります。この入力の情報に基づいて「どんなプログラム」を作るかが、プログラムを設計する人の出力(アウトプット)になります。多くの場合、仕事と仕事を繋げる役割をするのが、ドキュメントになります。従って、一つのプログラムの開発プロジェクトの場合でも、沢山のドキュメントが必要になります。* 利用者の要望、意見、フィードバックをまとめたもの* 実際のプログラムの要求をまとめた物* 実際のプログラムで実現する機能や方法(やり方)をまとめたもの* プログラムの使い方をまとめた物* プログラムのテストの方針をまとめた物(テストプラン)* プログラムのテスト結果をまとめた物(テストレポート)など基本的なものだけでも結構な数になります。当然ですが、作成するドキュメント
0
カバー画像

プログラムのテストプランの作り方

プログラムのテストプランの作り方プログラムの品質を確保(検証)するのにテストは欠かせません。しかし、フリーランスで開発をする場合は、専門のテストスタップがいない場合も多く、一般的な企業で開発する場合よりテストも限られたものになる場合が多くなります。この記事では、最低限のテストプランをどのように作成したら良いのかをまとめてみました。大切なドキュメント当たり前ですが、どんな場合でもプログラムがサポートする基本機能の確認は必須です。基本機能が動かないというのは、大きな問題です。従って、どんなに時間と人手が限られていても、基本機能の確認のテストは絶対に必要です。ところで、会社などでテストの専門チームがテストの計画を作る場合、どのように作るかご存知ですか?通常は、プログラムのドキュメントを基に作成します。実はこのドキュメントが無いとテストを考えるのは難しくなるのと、テストを行うのも難しくなります。プログラムを開発する場合、求められる機能があるのが普通です。これらの要求事項を満たすようにプログラムを開発します。ところが、その機能を利用する場合、どのような手順でプログラムを使えば良いかは、プログラムをどのように実現するかで変わってきます。プログラムの開発者は、最低でも2種類のドキュメントを作るのが基本です。* プログラムをどのように作ったか(プログラムの仕様書)* プログラムをどのように使うか(操作マニュアル) プログラムをどのように作ったかをきちんとドキュメントに残しておくと、将来の保守やトラブル時にプログラムを見直す場合などに役に立ちます。きちんとドキュメントを残すことが重要です。作成し
0
カバー画像

プログラム開発の終わりはどこか?

プログラム開発の終わりはどこか?プログラム開発をする上で開発の終わりはどこだかご存知ですか?この記事ではプログラム開発の終わりについて考えてみました。 前回の記事で書いた通り、フリーランスには決めることが沢山あると書きましたが、プログラム開発の終わりも決める事のひとつです。会社の場合は?最初に考えるのは会社でプログラム開発をする場合を考えてみます。 もちろん、会社にもよりますが、会社の場合は、プログラム開発の終わりを会社が決めています。 従って、普通は会社の従業員で給料をもらってプログラム開発をしている場合は、開発の終わりは自分で決める必要がありません。開発を終わりにする「基準」を作って開発の終わりを判断しているという場合が多くなっています。 決め方にはいろいろありますが、基本的には以下のような項目です。* プログラムのドキュメントが完成している* プログラムが求められている動作をする* プログラムのテスト(検証)が終了している 他にも細かい事が決められているかと思いますが、簡単に言うならば上の3つの項目を満たしているのを確認した上で終了になります。 その後は、別のプロジェクトを始めるという感じで仕事が続いていきます。会社の場合は、ドキュメントやプログラムの作成、テストを別の人が行う場合も多く、それぞれで更に「終わり」の条件を決めています。基本的に条件を満たせば終わりで、割り当てられた仕事が終わるというイメージです。フリーランスの場合は?ではフリーランスの場合はどうでしょうか?基本的に必要な事は同じなので、同じような基準を作って決めれば良いだけの話です。 例えば、プログラム(ア
0
カバー画像

バグの少ないプログラムの作り方

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

Excel作業自動化の出品をご購入頂きました!

先日以下の出品をご購入頂き、無事納品が完了したので今日はその記事を書いてみたいと思います。以前こちらの記事を書きましたが、当出品でのご購入は2回目、買い切り出品通算では5回目になります。こちらもオーダーメイドの開発なので詳細は明かせませんが、今回も色々と学びのあるお取引をさせて頂きました。今回学んだのは「説明って難しい」ということです。私は毎回サンプルプログラムをお渡しして、意図通りの動きが出来ているかを確認して頂いた後で提案をして実際にご購入頂くというプロセスを経ているのですが、今回は「送付したサンプルプログラムが動かない」というお問い合わせを頂きました。しかし、私の手元にある2台の端末で試しても普通に動く。DMから送付したプログラムをダウンロードして試しても同じ。どうしてだろうと途方に暮れかけましたが、最終的には「プログラムを送る際にzip圧縮しているが、その解凍方式が違った」ために正常に動かなかったということが判明しました。(ココナラではexeファイルが添付できないのでzip圧縮する必要があります)これ、説明書きをもう少し丁寧に書けば避けられたトラブルなんですが「zipで来たら同じフォルダ内に解凍して使ってもらえるだろう」という私の思い込みがそもそもの原因でした。システムの仕事をしているとそういう暗黙の了解みたいなのがたまにあるのですが、ココナラでは様々な方からの依頼があるため、そういうのは取り去ってフラットな目線で自分の説明を見直す必要があるな、ということに改めて気付きました。今後は説明書きをもう少し工夫して誤解の生じない納品を心がけたいと思います。さて、今回の出品物も
0
カバー画像

Word作業自動化の出品をご購入頂きました!

先日以下の出品をご購入頂き、昨日無事納品が完了したので今日はその記事を書いてみたいと思います。以前こちらの記事を書きましたが、買い切り出品をご購入頂いたのはこれで2回目になります。こちらも前回同様、LINE Botの出品とは違いオーダーメイドの開発なので詳細は明かせませんが、色々と学びのあるお取引をさせて頂きました。今回はWordを扱うプログラムだったのですが、実はWordをプログラムから操作するのはほとんど初めてでした^^;それでも何とか形にできたので、今後も同様のご依頼に対応できるという自信をつけることができました。また、作成したプログラムがウイルス対策ソフトに引っ掛かるというトラブルもあり、そちらの回避方法もわかったためこちらも今後のお取引に活かすことができそうです。前回の記事ではテストデータ作成用に作成したプログラムをプレゼントするという企画を思いつきでやってみたのですが、残念ながら応募はゼロ件でしたwできれば今回もやってみたかったのですが今回はついでに作ったプログラムも無いので、リベンジは次の機会にしたいと思います。さて、今回の出品物も「モニター価格」ということで格安で出品しております。3枠限定ということにしていたので、今回のお取引により残り2枠となりました。もしこの出品にご興味のある方は是非お早めにご検討下さい!2021年ももうすぐ終わりということもあり、ココナラでの半年の活動を振り返ってブログを一本書きたいなと思っているのですが、どうにも筆不精でなかなか形になりません。自分らしくゆっくり形にしていきたいと思います。年内には公開できるといいな。
0
24 件中 1 - 24
有料ブログの投稿方法はこちら