ネットワークの基礎⑦

前回、PPPについて触れてきました。さらにPPPについての学習とその他のデータリンクについても学んでいきましょう。

その他(インフラ)

【初心者用】React Nativeについて

Reactは学んでいたのですが、主にWeb系のUI開発にしか使用ができないため、Android開発をしたい場合はできませんでした。ですが、Reactには携帯用のアプリ開発言語があることを知ったので、改めて今回勉強の為にまとめておきたいと思います。

その他(PG/フロントエンド)

【入門】topコマンドの使い方

Linuxシステムのパフォーマンスモニタリングにおいて、topコマンドは非常に重要なツールです。本記事では、topコマンドの基本的な使い方や出力結果の読み方について解説します。

その他(インフラ)

【初心者用】PL/SQLとは

今度の案件で触ることになりそうなので、PL/SQLも触ることになりそうなので今回まとめたいと思います。SQLのクエリ操作などの基礎は全て学びなおしたのですが、PL/SQLの操作はまた別のようなので学んでいきたいと思います。

【初心者用】Goとは

Goという言語自体は聞いたことはあるのですが、特に何に使用されているのかよくわかっていませんでした。ですので、Goという言語が一体どういった強みがあり、どのような現場で使用されているのか学びたいと思います。

Flutterを使ってみよう その３（開発前準備）

前回のサンプル実行の記事の続きです。今回は、サンプルプロジェクトから開発のために何を抑えておけばよいか知識を深めていきましょう。環境　・MacOS Ventura 13.6.3　・Xcode 15.1　・VSCode 1.85.1　・Flutter 3.16.5　・Dart 3.2.3

製造・コーディング(PG/フロントエンド)

Flutterを使ってみよう その６（画像表示 他）

前回の記事の続きです。今回は、今まで触れていない実装方法の知識を深めていきましょう。環境　・MacOS Ventura 13.6.3　・Xcode 15.1　・VSCode 1.85.1　・Flutter 3.16.5　・Dart 3.2.3

製造・コーディング(PG/フロントエンド)

サーバーOSの種類と特徴を徹底解説！選ぶ際のポイントは？

サーバーとは、インターネットやネットワーク上で様々なサービスを提供するコンピューターのことです。サーバーには、ウェブサイトやメール、データベースなどのサービスを提供するために必要なソフトウェアがインストールされていますが、そのソフトウェアを動かすためには、サーバー用のOS（オペレーティングシステム）が必要です。サーバーOSには、主にwindows系、UNIX系、LINUX系の3つの種類がありますが、それぞれにどのような特徴があるのでしょうか？この記事では、サーバーOSの種類と特徴について徹底解説し、選ぶ際のポイントをお伝えします。

開発環境関連(インフラ)

【ソフトウェアテスト】不具合報告のインシデントレポートについて

開発プロジェクトで発生した問題はインシデントとして、管理・分析・対応が必要です。プロジェクト全体を通しての問題となるとかなり範囲は広く、人的トラブルやステークホルダー間での問題など、開発しているプロダクト以外の問題も含んでしまうので、本記事では主にプロダクトのテストに関して検出された動作の不具合(バグ)に焦点を絞って記載します。プロダクトのテストに際して検出した不具合は、報告・対応したあとは蓄積データとして、引き続きプロジェクトで参照・活用されます。実際の開発現場によっては、早期レビューでのやりとりに関するものや、開発とテスターが口頭で連携できるような状況で報告即時対応できる程度の不具合対応など、状況により必ずしも定められたドキュメントの形式で報告されるものとは限りませんが、可能な限り検出対応した不具合は履歴を残しておくことで、プロダクトの品質向上を目指すことができます。ほとんどの場合は不具合管理に別途外部のbug tracking system（BTS）を使用しています。BTSはインシデントレポート1件をチケットという1単位で扱います。チケットの形式や内容が必ずしも同一の形式に沿っているというものではありませんが、不具合の報告管理をするチケットの内容は、管理運用の観点から記載が必要となる項目はある程度決まっています。余談ですが、BTSは不具合報告のみならず、チケット駆動開発 (TiDD) を実施するプロジェクトでは開発作業自体の管理進行目的で使用される場合もあります。

テスト(運用・保守・サポート)

【ソフトウェアテスト】レビューについて

ソフトウェアテスト領域には、動作させることを前提とした対象をテストする動的テストと、動作させることを前提としていない対象をテストする静的テストがあります。単体テストや結合テストなど、作成したものを動作させてテストをするのが動的テストですが、静的テストは動作させる対象がなくてもテストが実施できます。静的テスト活動の種類としてレビューがありますが、開発活動の中で作成された製品やシステム自体以外のものは、レビュー対象としてテストすることが可能です。

テスト(運用・保守・サポート)

【ソフトウェアテスト】シナリオテスト

シナリオテストはユーザー視点で利用場面を想定し、操作フロー、入力値、発生する正常系挙動異常系挙動など、ユーザーが利用する一連の流れを想定したうえで発生しうるストーリーを元にテストを実施する手法です。ブラックボックステスト技法はさまざまあり、あくまで無数に存在しうるテストケースから粒度や対象を整理抽出してより広く浅いテストケースを目指すようなものがほとんどです。しかし、複数機能をもつシステムを実際に利用する際には、複数回の遷移を繰り返したりシステムが何重にも関連したりするので、1つの機能を対象としたテストや、2つ3つの機能間の関連をテストしただけでは、再現し得ないような組み合わせでの不具合が発生する懸念は常にあります。フリーチェックやモンキーチェックなどと呼ばれるものも、結局は「ユーザーなら再現しうる」可能性を想定して実行するものですが、それを数値や手順を明確にしてより詳細にテストし、かつ明示することでその内容をテストの履歴としたり、テストの要件自体もレビューなどで評価対象とできることがこのシナリオテスト手法の利点と考えられます。また、ユーザーのストーリーを元にテストするという点から、よりユーザーサイドでの視点から評価できるため、単純に欠陥を検出するのみならず、UI/UXの評価検討なども実施することができます。

テスト(運用・保守・サポート)

マニュアル作成で心がけることとは

皆さんはシステム開発現場のマニュアルや仕様書などのドキュメントに対して、どのようなイメージをお持ちでしょうか。 実際にシステム開発の現場で整備されていたマニュアルが、めちゃくちゃ役に立ったと考えているかたは、ごく少数なのではないでしょうか。 各プロジェクトで、エンジニアの入れ替わりが当たり前になった昨今では、業務マニュアルやシステムの操作マニュアルがない会社はないと言っても過言ではありません。 ・分厚くて読む気がしない ・どこに何が書いてあるのか分かりにくい ・そもそも読んでも理解できない ・プロセスやトラブルの解決策が抜けがち ・書いてある内容が古い（アップデートされていない） 上記の内容はいずれも、マニュアルが風化する原因の1つです。 裏を返せば、マニュアルを作る側が、上記のような状態にならないように気をつけるべき項目とも考えることが出来ます。 実際、多くのシステム開発の現場で、マニュアルと実際に稼働しているシステムとの情報が乖離しており、マニュアルはストレージを圧迫する邪魔な存在。だと認識されているケースが多いです。 今回の記事では、システムの操作マニュアルに関して、みなさんが実際にマニュアルを作成する場合に、分かりやすく使いやすいマニュアルを作るために心がけるべき5つのポイントについて解説していこうと思います。