3Dグラフィックスを簡単に実装できるライブラリ「Three.js」についてまとめてみた

Three.jsというジャバスクリプトのライブラリを知っていますでしょうか。このライブラリを使用する事で、比較的簡単に3Dグラフィックを実装する事ができ、個人的に興味を抱いているライブラリです。今回は、そのThree.jsについて調べてみましたので、その内容を書いていきます。

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

【初心者目線】Webアプリケーションの開発 第7回

【初心者目線】Webアプリケーションの開発 第7回を書きます。

【まだ現役？】COBOLの現在と将来性

COBOL（Common Business-Oriented Language）は、主にビジネスアプリケーションの開発に使用されるプログラミング言語です。1959年に開発され、それ以来、経済、財務、および行政の分野で幅広く利用されてきました。COBOLは、大規模なデータ処理やトランザクション処理に特化しており、特に企業のバックエンドシステムで使用されることが一般的です。

インフラエンジニアの年収事情とキャリアアップの秘訣

インフラエンジニアの年収事情について、興味はありませんか？IT業界の中でも重要な存在であるインフラエンジニア。彼らの年収にはどのような傾向があるのでしょうか？ネットワークエンジニア、サーバーエンジニア、クラウドエンジニア、セキュリティエンジニアの各分野ごとに年収を探ってみましょう。さらに、インフラエンジニアの年収アップにはどのような方法があるのでしょうか？上流工程への進出やマネジメントスキルの磨き方、幅広い技術習得や有益な資格取得など、具体的なアプローチをご紹介します。インフラエンジニアとしてのキャリアパスを築くために、年収アップへの道を探っていきましょう。

Nuxt.jsについて調べてみた

今回は多くのフロントエンド開発で利用されているNuxt.jsについて調べてみました。

イチから学ぶデータベース・SQL（３）

前回まではデータベースの基本やSQLの基礎について説明してきました。 今回からは、SQLを実務で使うための基本的なことについて学びながら説明していきます。

製造・コーディング(インフラ)

【テストの種類】結合テスト

結合テストとは、システム開発におけるテスト手法の1つです。システム開発では、結合テストの他に単体、機能、システムテストなどがあり、開発工程によって実施するテストが異なります。結合テストは複数のプログラムやモジュールを同時に稼働して行う動作テストで、モジュール同士を結合した際に意図した通りに動作するかの検証を行います。結合テストは、事前にテスト仕様書を作成し、テスト項目を決めてからテストを行います。結合テストの項目は前段階の単体テストが全て完了していることが前提となります。結合テスト前に行う単体テストは、個々の機能やモジュールが単体で動作するかを検証するテストになります。単体テストで行ったテスト項目は結合テストでは殆ど行わないか、簡易的に確認することが一般的です。結合テストでは、ただ動作するかのテストを行うのではなく操作と機能動作の組み合わせが正しいか、仕様書通りに機能しているかについても検証します。単体テストによって個々で正しく動作することが確認された機能やモジュールを対象とし、機能間の連携や一連の機能が仕様書通りに正しく動作するのかを確認します。

【入門編】SQLserverでできることとは？

SQL Server（エスキューエルサーバー）は正式名称「Microsoft SQL Server」と呼ばれます。 Microsoft SQL Server とは、エクセルやワードなどを提供しているマイクロソフトが開発している、リレーショナルデータベース管理システム (RDMS) です。 簡単にいうとマイクロソフトのデータベース製品ということです。 Macでも使えないことはないですが、Microsoft SQL ServerはWindows環境でとても使いやすく、人気が高いデータベースです。 特徴としては「Microsoft SQL Server Management Studio」という管理ツールがあることで、Microsoft SQL Server Management StudioはSQL Server の設定、管理、開発等を行うことが出来ます。 Microsoft SQL Serverでクエリーを書くには、「T-SQL (Transact-SQL)」という SQL 言語を使用します。

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

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

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

【初心者向け】境界値分析について

本記事ではテスト技法の一つの「境界値分析」について解説していきます。

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

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

開発に必要不可欠なテスト設計書について説明！

発プロセスとして欠かすことができない工程として、「テスト工程」があります。テスト工程とは実際に作り上げたシステムが、仕様通りになっているかを確認する工程で、不具合を効率よく検出するために必要な工程となっております。その中で今回はテスト設計書について説明します。なぜテスト設計書が必要であるか、また実際にどのように作成する必要があるかまでご紹介いたします。