シリコンバレースーパーウエア

ホーム ブログ Firebase情報 よくあるプログラミングの想定外とは？ 2021年12月30日 よくあるプログラミングの想定外 前回は、仮説を立ててプログラムのテストをすると良いと言う話でしたが、仮説を立てる場合でも、よくあるミスを知っていると効率よく仮説（＝テストケース）を考える事ができます。この記事では、よくある想定外のケースを紹介します。 基本は設計者が余り予期していない操作です 想定外の最も多いのは設計者が予測していない操作です。だから、想定外になるわけですが、良く起きるのも事実です。 例えば、渡すデータがない場合などです。 そんな事あるの？と思うかもしれませんが、例えばファイルを入力データとして指定する場合を考えてください。 入力に使うファイルを指定する方法はいろいろありますが、ファイル名をタイプして入力するようなユーザーインターフェースの場合、タイプミスをする事が考えられます。その場合、本来指定したかったファイル名とは別の名前という事になるので、ファイルが存在しないと言う事が考えられます。ファイルが存在しないので、ファイルからデータの取得はできません。 しかし、存在するファイルのリストを表示して選択するようなユーザーインターフェースにすると、上で挙げたような入力ミスは防げます。そう考えると、存在しないファイルを選択する可能性は低くなります。 いかがでしょう、上の説明だけを見ると、ユーザーインターフェースを工夫すれば、ファイルが存在しないと言う想定外のイベントも防げるように見えませんか？ 実は、これでもファイルが存在しないケースは起こり得ます。 どう言う場合かというと、プログラムがファイルの一覧を表示するためにあるフォルダのファイルのリストを取得した後に、プログラムとは関係ない操作で、そのファイルが削除されたり移動する場合です。確かに可能性は低いと言えますが、起こる可能性はゼロではありません。コンピュータに保存されているファイルは、基本的に他のプログラムや操作の対象となる事は十分に起こり得るケースと言う事になります。 プログラムのテストには、このように重箱の隅を突くよ

ホーム ブログ Firebase情報 プログラムのテストも仮説を作る 2021年12月29日 前回は、一般的な実践の際に仮説を立てるという話を紹介しましたが、もう少し具体的な例としてプログラムのテストのやり方に応用した例を紹介します テストの場合は「期待値」を考える プログラミングに応用する場合は、仮説というより実際は「期待値」を設定するという方が近くなります。 期待値というのは、「こうすれば、こうなる（はず）」という事を考えるという事になります。以前に紹介した事に、プログラミングは基本は「入力」と「出力」で枠組みを作るというのがありました。これが、期待値そのものです。この入力となるデータを渡して、処理した結果（出力）が得られるというのがきちんと決まれば、テストができます。 これはプログラム（関数）の中身を見ないで、入口（入力）と、出口（出力）でテストを行うので、ブラックボックステストと呼ばれるテストのやり方になります。 考えるのはどんなデータを入れるか？ この方法でテストを行う時のポイントは、どんなデータを入れるかです。つまり、どのようなデータを渡してプログラムに処理をさせるかが重要です。 全ての組み合わせのデータでテストするのが理想ですが、殆どの場合全ての組み合わせをテストするのは不可能に近いので、うまくデータを選んで効率良くテストをする事が求められます。 その際に必要なのは、可能性のあるデータを幾つかのグループに分けて、そのグループの中から代表的なデータを使ってテストするようにすると、テストの数を少なくする事ができます。例えば、「整数」を渡す場合には、いくつかの分類が考えられます。 負の数、正の数、０ 数の大きさによる分類 が代表的です。マイナスの数と正の数で処理の仕方が変わる場合は結構ありますし、０の場合も特殊なケースになります。基本的に「０で割る」という計算は避けるようにプログラムを書くのが基本だからです。 また、数の大きさによって処理を分けている場合もあるので、そうした条件の境目（境界）になる数値でテストすることも必要になります。 ここで、大切なのが、プログラムを作った

ホーム ブログ Firebase情報 成功から学べるか？ 2021年12月28日 成功から学べるか？ 「失敗から学ぶ」というのは良く言われる言葉ですが、「成功から学ぶ」というのはどうでしょうか？かなりのケースでは成功から学ぶというのは意外に難しい場合が多くなっています。この記事は、「成功」と「失敗」の大きな違いについて考えてみました。 失敗から学べる大きな理由 皆さんも、自分が失敗した場合について考えて見てください！ 殆どの方は、失敗した時は「悔しい」と思う物です。あの時に、XXX をしなければよかったなどと後悔する場合も多いはずです。 こうした事から分かるように、殆どの人は、失敗する事はは嫌いで、余り良い事だとは思っていません。 なので、同じ失敗を繰り返さないように、「反省」する物です。 具体的には、どうして失敗したのかを考えて、次に同じような事をする際には、同じ過ちを繰り返さない様にする物です。 また、いろいろ試行錯誤してして、何とか失敗の原因を突き止めて対策を講じたりする物です。 こうした努力が、「失敗から学ぶ」につながる場合が多い大きな理由になっています。 成功した場合はどうか？ では、成功した場合はどうでしょうか？ 成功した時は、失敗とは反対に嬉しい物です。また、その結果に満足する場合が殆どかと思います。 殆どの場合は、成功した場合には、成功の真の原因を追求したりするケースは非常に少ないのではないでしょうか？ 一部の研究などでは、うまくいった場合でも、再現性が重要視されるために、上手く行った原因を突き止めるという事を行いますが、ビジネスなどの場合には、上手く行った場合はその時のやり方や方法に固執してしまう場合がどうしても多くなってしまいます。 そうした事が原因で、成功の真の原因というのは余り明確にならない場合が多くなります。 このあたりが、成功から学ぶのは難しいと考える大きな理由です。 どうしたら学ぶ事ができるか？ このように考えると、成功からは学べないように見えます。 しかし、成功からも失敗からも学んで成長するための方法が実はあります。 この方法を使うと、成功しても失敗

ホーム ブログ Firebase情報 プログラムのバグを減らすコツ 2021年12月27日 プログラムのバグを減らすコツ プログラムのバグ（不具合）の原因は色々あります。単純な記述の間違い（typo）から複雑なものまで色々あります。その中で、意識すると効果の高い物の一つを紹介します。 きちんと考えた処理は大抵動く！ プログラムで行なっている処理の中で、プログラムを設計した人がきちんと考えて作られた処理は多くの場合きちんと動作します。 例えば、要求されている機能に関しては殆どの場合動作します。それは、プログラムを書く人の頭の中に処理の流れ（フロー）がきちんとできているのが大きな理由です。 基本的にプログラムはこの流れに従って書かれているからです。処理するデータの変化のイメージもほぼ頭の中にあって、そのイメージを元にプログラムを書くので、そのイメージから逸脱しない限りは基本的に問題なく動くという事になります。 所謂、これが以前から何度かお届けしている「想定内」の動作です。 問題は想定外の状況 上に挙げた理由で「想定内」の処理は多くの場合、きちんと動作します。 一方で、プログラムを書く人が想定していない動作に関してはバグを作り出す可能性が高くなります。当たり前ですが、「想定していない」ものをきちんと書くのは至難の技だからです。結構な場合、その「想定していない」場合の処理は、書かれていない場合が多いのです。 プログラムに書かれていない状況が起きた場合には、その後の処理がどうなるかわからない場合が多く、これが予想外の動作の原因に繋がる場合が非常に多くなっています。 想定外の状況がバグに繋がる理由 実は、想定内の処理でもバグは発生します。 しかし、想定内の処理のバグは、殆どの場合、プログラムを書いた人が行うテストで殆どの場合修正されるので、実際にバグとして残るケースが少ないので問題になりにくくなっています。 理由は簡単で、想定内の動作というのは基本的に求められている基本的な機能に関わる処理になります。こうした機能は、プログラムを書き終えた後で真っ先にテストされる機能になります。当然、プログラム

ホーム ブログ Firebase情報 バグの症状と原因 2021年12月26日 プログラムの基本は入力と出力 プログラムミングの基本は入力と出力を意識することにあります。この記事では、入力と出力のコンセプトについて紹介します。 関数や Method の基本 プログラミングでよく利用する関数や Method の基本は、入力と出力を意識する事にあります。 実際には、プログラム自体が何らかの入力（インプット）を受け取って、それを処理して何らかの出力（アウトプット）をするのが基本です。 その途中の過程で呼び出される関数や Method も、何らかのデータを受け取って、何らかの処理結果を得るという処理の繰り返しで成り立っているのが基本です。 つまり、プログラミングを設計する場合、何が入力で何が出力かを決める事の繰り返しになります。 入力や出力がない場合もあるのか？ ところで、多くのプログラミング言語では、値を返さない関数や Method が存在します。Void 型と呼ばれるケースです。このタイプの関数や Method は値を呼び出しもとに返しません。値を返さないので、出力がないように見えますが、殆どの場合何もしないわけではありません。 一連の処理をして、ある部分のデータを更新したり、出力を画面上にアウトプットしたり、ネットワーク経由でデータを送ったりなど何らかのアウトプットがある場合が殆どです。 入力にしても同じような事が言えます。特に関数に値を渡さない場合でも、何らかの形でデータを処理するケースが殆どです。それが、ネットワークなどからデータを受け取る場合もあれば、利用者がデータを入力する場合もありますし、外部で定義されている変数の場合もあります。 関数や Method の引数や返り値だけで考えると、入力や出力がない様に見える場合もありますが、プログラミングでは、通常は何らかの形でデータを取得して、それを処理して何らかの変化が起きます。その変化が出力でありアウトプットという事になります。 プログラミング以外でも役に立つコンセプト この入力（インプット）と出力（アウトプット）という概念は、プロ

ホーム ブログ Firebase情報 プログラムの基本は入力と出力 2021年12月23日 プログラムの基本は入力と出力 プログラムミングの基本は入力と出力を意識することにあります。この記事では、入力と出力のコンセプトについて紹介します。 関数や Method の基本 プログラミングでよく利用する関数や Method の基本は、入力と出力を意識する事にあります。 実際には、プログラム自体が何らかの入力（インプット）を受け取って、それを処理して何らかの出力（アウトプット）をするのが基本です。 その途中の過程で呼び出される関数や Method も、何らかのデータを受け取って、何らかの処理結果を得るという処理の繰り返しで成り立っているのが基本です。 つまり、プログラミングを設計する場合、何が入力で何が出力かを決める事の繰り返しになります。 入力や出力がない場合もあるのか？ ところで、多くのプログラミング言語では、値を返さない関数や Method が存在します。Void 型と呼ばれるケースです。このタイプの関数や Method は値を呼び出しもとに返しません。値を返さないので、出力がないように見えますが、殆どの場合何もしないわけではありません。 一連の処理をして、ある部分のデータを更新したり、出力を画面上にアウトプットしたり、ネットワーク経由でデータを送ったりなど何らかのアウトプットがある場合が殆どです。 入力にしても同じような事が言えます。特に関数に値を渡さない場合でも、何らかの形でデータを処理するケースが殆どです。それが、ネットワークなどからデータを受け取る場合もあれば、利用者がデータを入力する場合もありますし、外部で定義されている変数の場合もあります。 関数や Method の引数や返り値だけで考えると、入力や出力がない様に見える場合もありますが、プログラミングでは、通常は何らかの形でデータを取得して、それを処理して何らかの変化が起きます。その変化が出力でありアウトプットという事になります。 プログラミング以外でも役に立つコンセプト この入力（インプット）と出力（アウトプット）という

ホーム ブログ Firebase情報 アメリカ型の雇用は大変か？ 2021年12月22日 アメリカ型の雇用は大変か？ アメリカは今日あたりから休日モードです。こちらの連載も今週あたりからお休みを頂こうかと考えています。時間に余裕があれば投稿する予定ですが、内容はアメリカでのエンジニアリングライフなど軽い内容にしようかと思っています。今日は、アメリカでのエンジニアの働き方や雇用の現状などを紹介しようと思います。 日本の終身雇用制度が揺らぎ始めて、アメリカ型の雇用に対する意見や議論を見かけますが、言われている程大変ではありません。この記事ではアメリカで働いて感じた事をまとめてみました。 目次 アメリカの雇用形態 採用プロセス 給与体系 アメリカのエンジニアは大変か？ まとめ アメリカの雇用形態 アメリカの雇用形態と言っても、職種によってかなり違ってきます。この記事では、アメリカでの技術職（エンジニアリング）の話を中心に書いています。 他の職種の場合には、結構事情が変わってくると思いますので、その辺りはあらかじめご理解ください。 大きな違いは、一般的に新卒の一括採用のような仕組みは殆どありません。雇用の基本は、新卒、非新卒に関わらず募集は、空いたポジションや新規に作られたポジションに対して行われます。 当然ですが、採用されると何らかの形で仕事が割り当てられて、仕事をすることが求められます。最近よく見かける日本の記事では「JOB 型雇用」と呼ばれているようですが、基本的に仕事内容を具体的に提示して、必要な知識やスキル、経験を基に選考する仕組みです。 このような仕組みのため、採用の主体は、採用部門、つまり、採用後に配属されて仕事をする部門が中心になって行います。人事部門は、採用のサポートという位置付けになります。そういう事情ですので、基本的な人事権は採用部門のマネージャーにあります。採用枠は、部門ごとに人数が決められているので、辞めた人の穴埋めか、事業の拡張などで増員が必要になった場合などに、部門のマネージャーが新規の枠を申請して認められると採用できるという仕組みです。 このような実態のため

ホーム ブログ Firebase情報 プログラミング学習のバランス 2021年12月21日 プログラミング学習のバランス プログラムの学習には、プログラミングで利用する道具や道具の使い方を学習する部分と、プログラミングの基本や原理を学習する部分に分ける事ができます。プログラミングの学習にあたっては、そのタイミングとバランスが大切です。上級のソフトウエアエンジニアを目指す場合には、プログラミングの基本や原理は重要です！ プログラミングの道具とは？ プログラミングの道具にあたるものは、プログラミング言語や、プログラムの入力に使うエディタなどの開発用のアプリなどがあります。さらに、よく利用する機能を予めプログラムにしたモジュールやラブラリなども道具になります。 まずは、こうした道具を使いこなせないとプログラミングをする事ができないので、道具の使い方を学習するのはとても重要です。 一通り、道具が使えるようになると、簡単なプログラムを作れるようになります。道具の使い方はそういう意味でプログラム学習の第一歩と言えます。 プログラミングにも設計図は必要！ プログラミング言語を習得して、プログラミングに必要なアプリの使い方を覚えると、一通りプログラムを作成できるようになります。上にも書いた通り、プログラミングをする上でこの部分の学習はとても大切ですし、最初に学習する部分でもあります。当然、多くのプログラミングの入門者はこの部分に時間をかける事になります。多くの「わかりやすい」と言われている教材もこの部分をカバーするものが多くなっています。 実際に、プログラミングの上級者に成長していくには、別の部分の学習が必要になってきます。 それは、プログラミングの「設計図」を作るのに必要な知識を身につける事です。 簡単なプログラムの場合には特に設計図がなくてもプログラムを書くことは可能です。しかし、ある程度の大きなプログラムや、複雑な処理が必要なプログラムの場合には、きちんと設計図を作ってからプログラムを書かないと、問題がたくさん発生したり、作り直しや、手直しが頻繁に発生して、結果的に時間がかかったり、管理が面