はてなブックマーク

{ "posts": [ { "id": 1, "title": "json-server", "author": "typicode" } ], "comments": [ { "id": 1, "body": "some comment", "postId": 1 } ], "profile": { "name": "typicode" } } また、CRUD処理やソート、ページングなどもjson-serverの仕組みに乗ることで利用が可能です。 クライアント開発では、事前にjsonの定義でサーバ相当の機能を実現、開発し、サーバ開発が完了した時点で本物のサーバを利用するようにします。 gRPCのモックサーバ gRPCの開発スタイル gRPCにおける開発では概ね以下のフローで行います。 クライアント/サーバ間のインターフェイス定義 protocにより、クライアント/サーバの自動生成 サー

2021.4.14 追記 proto3で削除されたoptionalですがv3.15(experimentalオプションを利用する場合はv3.12)から正式に実装されたため、それ以降のバージョンを利用する場合は素直にoptionalを利用してもらうのがいいと思います！ https://github.com/protocolbuffers/protobuf/releases/tag/v3.15.0 Protocol Buffersはproto3でrequiredとoptionalが削除されました。 そもそも削除された経緯に関しては、@qsonaさんのエントリーにて、分かりやすくまとめて下さっています。 そこで課題になるのが、proto3において各フィールドは全てデフォルト値を持つため、デフォルト値が設定されたフィールドが利用側から 1. 意図的にセットされたデフォルト値と同様の値 2. 存在し

gRPCとは gRPCの概要については、こちらのエントリで記載しています。 このエントリでは、gRPCの運用で気になるポイントや、Javaで実装する場合を中心にまとめていこうと思います。 開発フロー 現代的なシステムではシステム間をAPIを通じて通信することが多くなってきています。 この場合、各システムのインターフェイスは以下のいずれかのパターンで開発が進む場合が多いです。 パターン1: 手動でインターフェイスのドキュメント(仕様書等)を記述し、サーバ、クライアントの開発者でその要件を満たす実装を行う パターン2: サーバ側のコードから、インターフェイスドキュメントを自動生成し、クライアントがその要件を満たす実装を行う パターン3: 手動でインターフェイスドキュメントを記述し、各システム用にサーバとクライアントのコードを自動生成する gRPCを用いた開発では上記の3のパターンで行います。

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Javaでもラムダ式やStream APIなど比較的モダンな機能が取り入れられ、処理結果を2つ以上の値として返したい場合が増えてきています。 その方法として一つとして思いつくのが、他言語ではよく用意されているTupleです。 ところが、Javaには標準APIとしてTupleが用意されているないため、ちょっと調べたときのメモです。 Tupleとは タプル(tuple) タプルとは、順序付けられた複数の要素で構成される組。もとは数学の概念だが、いくつかのプログラミング言語にはタプルという名称のデータ型が用意されている。 タプル型の仕様は言語

目次 はじめに Collectorを作る Collectorを楽に使う Collectorをまとめる Collectorから生成する はじめに Java 8以降Stream APIはfor文に代わり広く使われる Streamには終端処理がセットになり、その代表がcollectメソッド collectメソッドの引数がjava.util.stream.Collector Collectorを作る // ArrayListに変換するCollector Collector<T, ?, List<T>> toArrayList = Collector.of( ArrayList::new, List::add, (l1, l2) -> { l1.addAll(l2); return l1; }, Characteristics.IDENTITY_FINISH); // 実行 .stream().co

REST APIによる設計 最近のシステムは様々なデバイスやスケーラビリティを重視するため、各システムを分割し軽量なAPIで連携するマイクロサービス的なアーキテクチャスタイルが増えてきています。 そして、そのAPI連携で広く採用されているのが、REST APIです。 しかし、こうした設計を行っていくには、適切に考慮、選択しなければならないことも多くあります。 URL、パラメータ、エラーなどの設計 各言語ごとのライブラリや、サーバ、クライアントの選定、設計 認証、認可 ドキュメント管理 ユニットテスト、インテグレーションテスト、モック、Consumer-Driven Contracts 開発用ツール 絶対的スタンダードがない状況下で、こういった問題はシステムやメンバーが増えるにつれ複雑化していき、設計や管理、その仕組み作りに時間を取られ、本来の目的となるべき機能開発の時間を失っていくことにな

背景 最近は変化し続ける要件に対応するために、システムも柔軟であることが求められています。 そのため、部分的に変更やスケールの可能なシステムを構築し、API経由で連携するマイクロサービス的アーキテクチャが増えてきています。 そういった設計の中で問題になっていくのが、従来のモノリシックなアプリケーションではIDEやコンパイラなどで行っていた、機能間のインターフェイスをどう管理するかという部分です。 Swaggerとは? SwaggerとはRESTful APIのドキュメントや、サーバ、クライアントコード、エディタ、またそれらを扱うための仕様などを提供するフレームワークです。 公式サイトでは、The World's Most Popular Framework for APIsと謳っています。 その理由は、マイクロソフト、Google、IBM、SmartBearなどを大手の企業を含む「Open

import org.jsoup.Jsoup; import org.jsoup.nodes.Element; import java.io.IOException; import java.util.Arrays; import java.util.List; import java.util.Map; import java.util.function.Function; import java.util.stream.IntStream; import static java.util.function.Function.identity; import static java.util.stream.Collectors.*; public class Ranking { public static void main(String[] args) { Stream.<Triple

public class HamcrestTest { List<String> list = Arrays.asList("hoge", "fuga", "piyo"); @Test public void test() { assertThat(true, is(true)); assertThat("hoge", is("hoge")); assertThat(list, is(not(empty()))); assertThat(list, is(contains("hoge", "fuga", "piyo"))); } } 見た目はHamcrestとあまり変わらないように感じますが、大きなメリットはFluent APIのため、チェック対象の型情報からIDE補完で使用可能なメソッド一覧を選択できることです。 このため、Hamcrestのように事前にAPIを把握していなくても、型安全

なぜRxJava? RxJavaは様々な特性を併せ持ったライブラリですが、簡単にまとめると以下のような機能に分類されます。 List処理の抽象化・ストリーム化 Optional Future/Promise Data Binding Event Bus Android開発でRxJavaをチームに導入した話 Java 8ではStream APIやOptionalが導入されていますが、Androidや業務要件などそのAPIを使えない環境も存在します。 また、非同期や並列などそもそもJavaで扱いにくい処理を、統一されたインターフェイスで簡潔に記述できるなどのメリットも多く、その基本的な機能を試してみたので紹介します。 なお、ここに記載する内容はRxJavaの使い方が中心で、RxJava自体の概念やFRPなどについては、他にも多くの方々紹介してくださっていますので、そちらをご覧いただければと思い

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Builderパターン 個人的にBuilderパターンはオブジェクトの生成制御や、ものによっては可読性が高くて好きなパターンなんですが、その実装には用途によっていくつかパターンがあるので、まとめてみました。 生成するオブジェクトの条件 クラス名:People フィールド:String name(必須), Integer age(必須), String hobby(オプション) 必須要素はnullを禁止 PeopleクラスはStringを返り値とするhelloメソッドを持つ 今回はBuilderパターンの比較のため、パターン上必要でない限りgetterなどのメソッドは省略 Native Builder Builderパターンではなく、ただのコンストラクタ。Builderパターンを使いたくなるのはこれをやりたくないからだけど、比較のために記載。 class People { private S

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Javaの開発と言っても、各種ミドルウェアやフレームワーク、ライブラリ、ツールなどが豊富にあり選択に悩むことは少なくないと思います。 そこで関連技術のインデックスになればと作成しました。 あくまで知っている範囲で記述しているので、コメントしてもらえれば随時追加します！ すべてを書くと膨大な量になるため、現状採用が減ってきているものや、そもそもあまり採用されていないもの、後継があったり、類似のものと比較した場合に明らかに劣っているものは省いています。 ちなみにライブラリには高機能なものも多いので、分類は参考程度にご覧下さい。 サーバ系 A

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #はじめに JUnit実践入門を読んだのでそのまとめ #Part1 JUnit入門 ##なぜ、ユニットテストを行うのか? どんなプログラマであっても人間であるかぎり間違いをおかす→正しく動くか不安→不安を安心に変える ユニットテスト ##JUnitとは? Javaのテスティングフレームワーク。 テストの実行フレームワーク テストの期待値と実測値の検証API テストケースのフォーマット ##日本語のメソッド名を使うメリット 英語で格好よくテスト内容を記述でき、それを英語表記でき、読み取れれば英語の方が望ましい。 日本語でのソフト開発なら、

はじめに Effective Java関連の記事をまとめ。 他にも見つけたら追加していこうと思います。 また、内容に誤り、問題がありましたら訂正しますので、コメントまたはプルリクエストをお願いします！ Effective Javaって？ JavaでプログラミングをするすべてのSE必読の書籍です。 Effective Java 第2版 Effective Javaは全Javaプログラマ必帯と言って良い名著.. Effective Java 第2版 が今月発売されるようです Java中級者以上なら読むことがマナーであると言われるJavaの必読書。 [書評]Effective Java 第2版 Javaを使う上で知っておいたほうが良い知識・注意した方がいいテクニックを紹介した本 Effective Java 第2版 数々のブログやサイトで評価されAmazonのレビューやランキングでも常に上位に存

public class FourPhaseTest { @Test public void testCase() throws Exception{ // 1.初期化 Calc sut = new Calc(); int expected = 7; // 2.テスト実行 int actual = sut.add(3.4); //3.アサーション assertThat(actual, is(expected)); //4.終了処理(必要な場合) sut.shutdown(); } }

経験ゼロでもできるプログラミング現場の単体テストを読んだので、そのまとめ はじめに 著者曰く、 初めて導入する単体テストの指南書 を目指した一冊。 単体テストを書いたことが無かったり、書いたことがあっても書き方の方針が定まっていない人にはおすすめの本。 逆に既にバリバリテストコードを書いてる人に、再確認的な内容になるかも。 単体テストについて基礎知識 アプリケーション開発では設計に時間がかかりすぎて、テストに時間をかけられないことがある。 致命的な障害発生する可能性がある。 とはいえすべてを想定してテストを実施することはできない。 テストケースを絞る必要がある 各テストフェーズの礎となる単体テストが重要になる 高品質なシステム ユーザーを満足させ、不安や不満をいだかせないこと システムエラー：データの破損などの心配が生まれる 応答が遅い：いらいら・二度と使わなくなる まとめてテストはダメ

EC2でテスト環境とかまだ公開したくないアプリケーションを作成した時に、簡単な認証をかけたくなることがよくある。 ってことで AWS EC2 Amazon Linux + Apache 環境でBasic認証のかけ方 認証ユーザの作成、追加 認証に使用したいユーザのログイン名とパスワードを.htpasswdファイルに設定する

What's Google Guava? Googleが開発しているOSSのjava core libraryで、Googleの多くのJavaベースのプロジェクトで使用されており、 Java 1.5 以上で使用できる。 昔、Google Collectionとして開発されていた。 Apache Commons の Lang、Collectionsなどに替わる機能を提供していて、パッケージ名を見れば大体の機能について想像がつくと思います。 com.google.common.annotations com.google.common.base com.google.common.cache com.google.common.collect com.google.common.escape com.google.common.eventbus com.google.common.hash c

#テストの必要性 以前のシステム開発と言えば、ウォーターフォールのような要件から設計、実装、テストのような徐々に作業を細分化し最後にテストを行う手法が主流、というかSierとかでは基本今でもこの手法が多いはず。 しかし、現在はアジャイル開発の普及にともない、TDD、BDDに代表されるようなテスト重視の開発スタイルが増加している。 その中で実際テストコードを書いてみようとすると、Javaではテストフレームワークやツール、ライブラリ等が多数あり、どれを選択すべきか悩みどころになってくる。 ここではそれらを整理するため、Javaのテストコードを書くときに必要な情報をまとめておきます。 #どれを使うか・・・ 個人的には、どれを使いうかと考えた時に以下に注意している。 簡単、シンプル テストコードをするために、時間がかかり過ぎたり、可読性が低下したり、ロジックがあまり複雑になるようなものは避ける。

start Start SCRIPT as a daemon stop Stop the daemon SCRIPT stopall Stop all running forever scripts restart Restart the daemon SCRIPT list List all running forever scripts config Lists all forever user configuration set <key> <val> Sets the specified forever config <key> clear <key> Clears the specified forever config <key> logs Lists log files for all forever processes logs <script|index> Tails t

現場で使えるソフトウェアテスト Java編を読んだので要点をまとめ。 Step1 テストとは ソフトウェア開発では、様々な問題が発生するが、そのなかでよくあるのが動かない、誤動作、パフォーマンス問題人が作る上でミスは起こるのでテストが必要 テストの流れ 品質目標を立てる テスト密度（目標、上限、下限値）、バク密度（目標、上限、下限値） テスト計画 ソフトウェアテストの全体計画作成 実施スケジュール、予算、体制、環境構築手順、必要ツール利用手順、成果物の様式、バージョン管理、設計書の準備 テスト作成 期待動作、パターンの洗い出し、テスト環境構築、テストデータの作成、テストケース作成、レビュー テスト実施 作成したテストケースの実行 テスト検証 結果の確認、テスト関係者以外の利害関係者との調整（設計書管理、仕様管理、修正管理）、テスト実施者の作業管理、テスト報告のとりまとめ、テスト全体報告、再

Spring Rooとは Springのサブプロジェクトで「コマンドラインからソースファイルを生成するRAD（Rapid Application Development）ツール。 Rooは標準で、いままで使用されてきた実績のあるフレームワークやライブラリを使用（Spring Framework、Hibernate、JPA、AspectJなど） 実行は、コマンドライン、あるいはSTSのRooシェル上で行う。 生成されたソースにはRooに関連するアノテーションが付いているが、Rooはランタイムライブラリではなく、使用を中止する場合、コマンドを実行するだけでRooの依存性を簡単に削除できる。 Spring Rooで出来るとこ Eclipse用プロジェクトとして設定ファイル生成 CRUD機能を持ったscaffold生成 DBやO/Rマッピングのセットアップ データベーススキーマからのEntity自