応募前に見て聞いて欲しいことチーム別詳細🔗募集中求人
応募前に見て聞いて欲しいことチーム別詳細🔗募集中求人

灘脇 裕一 / yuichi nadawaki

タグ
Backend
写真
5e1af35c-99e3-42f5-a8b2-deb5ee064393_vuK%253B.jpg
Twitter
https://twitter.com/natacoon
Date

自己紹介

主に機能開発チームのリードをしているバックエンドエンジニアです。 最近はスクラムマスターの役割もやったり。 DDDなど、ソフトウェアアーキテクチャ設計関連の話題が好き。 前職はHRTechで設計実装、システムリプレイスのための要求定義（モデリングなど）を担当してきました。

Voicyの好きなところ

常に前しか向いていないメンバーと、刺激し合いながら良いモノを考えて実現できること

好きなVoicyパーソナリティ

私が思う「声で未来をつくる」

カジュアルに話してみる

入社エントリー

ピックアップコンテンツ

設計原則をデザインパターンで考える - voicy tech blog
こちらは Voicy Advent Calendar 2021 13日目の記事です。 はじめまして、株式会社Voicyでバックエンドエンジニアをしている なだまる です。 みなさん、設計してますか？ 「設計」っていうと難しいこと考えがちですが、普遍的に言われていることを組み合わせてみてみると、あ、こんなもんかと思ったりします。 今回はそんなアプリケーションの設計に関するお話をしてみます。 広く知られる設計の原則として、SOLID原則があります。 この原則の目的は主に以下のような性質を持つ中間レベルのソフトウェア構造を作ることです。 変更に強いこと 理解しやすいこと コンポーネントの基盤として、多くのソフトウェア・システムを利用できること SOLID原則は以下の各原則の頭文字をとってSOLIDです。 今回は各原則について詳しくは記述しませんが、軽く紹介までに。 Single Responsibility Principle（単一責任の原則） Open-Closed Principle（オープン・クローズドの原則） Liskov Substitution Principle（リスコフの置換原則） Interface Segregation Principle（インターフェイス分離の原則） Dependency Inversion Principle （依存関係逆転の原則） これらだけ読んでも「ほうほう」くらいはなるんですが、具体イメージは湧きづらいですよね。 ここで言う デザインパターンは GoFの デザインパターンを指します。 デザインパターン は23種あり、よく出会う問題とそれに対処する良い設計としてまとめらた指針のようなものです。 こちらの各パターンの紹介も今回は割愛しますが、前半で紹介した原則と合わせて理解することで、どういったところに肝があるのかを掴みやすくなります。 本記事はこの部分を扱います。 説明にクラスと言う言葉を使いますが、便宜上そうしているだけでモジュール等の一定の実装のかたまりの意味合いで捉えてください。 単一責任の原則はざっくり言うと「モジュールを変更する理由はひとつにすべきだ」というヤツで、 ユースケース のアクターが異なるのであればコードは分割しましょうねということです。 Facadeパターンはモジュールの窓口を担う、システムの外側に対するシンプルな API を提供するパターンで、クラス図にすると以下のようなものです。 Facade パターン - Wikipedia 実装コードを扱うクラスがあったとして、それぞれアクターが異なるメソッドが実装されているとします。（例が雑でごめんなさい） implement()は実装者、review()はレビューする人、release()はシステム管理者が行うとします。 このままだとどういう ユースケース の変更であったとしてもCodeクラスを変更することになります。 アクターが異なることがわかっているので、アクターごとにクラスを分けてます。 分けたら分けたで、利用者側からは3つのクラスを意識して上手に使ってあげないといけなくなります。 それは使いにくいので窓口としてFacadeクラスを配置します。 こうすることにより、実装者にかかわる変更はImplementerのみを変更すれば良くなり他のアクターのケースは影響を受けません（関数の シグネチャ ーが変更される場合などはFacadeも変更対象になります）。 このように、Facadeパターンを通じて、 ユースケース のアクターごとに変更すべきクラスを分けることができ、かつ理解もしやすくすることができます。 依存関係逆転の原則は、 ソースコードの依存関係を抽象だけを参照するようにして、その名の通り依存関係を逆転させるヤツです。抽象クラスや インターフェイス に依存しましょうってことですね。 Abstract Factoryパターンは直訳すると「抽象的な工場」で、これだけだと意味が分かりづらいですが、工場で生産する部品の具体には触れず、 インターフェイスだけを使って部品を組み立て製品にまとめようぜというヤツです。 API を定義するイメージですね。クラス図で表すと以下のようになります。 Abstract Factory パターン - Wikipedia 上側が API になっていて、下側に詳細の実装が配置されています。 ClientはProduct1の インターフェイス経由でConcreteProduct1を使用します。 Product1は AbstractFactoryの インターフェイス経由ででProduct1を生成します。 このとき、 ...
https://tech-blog.voicy.jp/entry/2021/12/13/224641
IntelliJ IDEAのHTTPクライアントが使いやすい話 - voicy tech blog
バックエンドエンジニアの なだまる です。今回は開発環境としてのHTTPクライアントの話をしてみようと思います。 API の開発をしていて、エンドポイントの動作確認を行う際、 もし、お手元でお使いのエディタがJetBrains製品ならなんと！実はHTTPクライアントが付属してます！ 結構使いやすく愛用しているので、紹介してみることにしました。 ちなみに私は以前はPostmanを使っていました。 準備と言っても特段ないんですが、リク エストを記述するためのファイルを作成します。.restか、.httpとして作ればHTTPクライアントがそれと認識してくれます。 なので、自分で適当にファイル名をつけて作成するか、Scratchファイル作成から作ればOKです。 Scratchファイルは Mac なら Shift+Command+N から HTTP Request を選択します。 IDEAのHTTPクライアントは GUIがあって画面のどこに何を書いてという形ではなく、 スクリプト チックです。 基本はこんなかんじ↓ Method Request- URI HTTP-Version Header-field: Header- value Request-Body 上記の文法になぞらえていくつかリク エス トの例を並べてみます。 // 普通のGET GET http://example.com ### // Bodyを指定してPOST POST http://example.com/api/users Content-Type: application/json { "id": 1, "name:
https://tech-blog.voicy.jp/entry/2022/06/29/185733

音声アウトプット

テキストアウトプット