Future Tech Blog
フューチャー技術ブログ

設計 タグの記事

  • 27
    投稿
  • 15
    著者数
  • 5370
    総シェア数
  • 1513
    Twitter
  • 44
    Facebook
  • 2386
    はてブ
  • 1427
    Pocket

フューチャーのSwagger（OpenAPI 2.0）規約の紹介

フューチャーの有志メンバーでSwagger（OpenAPI Specification Version 2.0）のコーディング規約を作りました。

リアクティブプログラミングについて考える

前回のエントリーで、コンポーネント単位のステートをがちゃがちゃ更新していくという、オブジェクト指向型（オブジェクトの境界がコンポーネント）の考え方から、より小さな状態のインタラクションになっていくよ、という話を紹介しました。ビジネスロジックのアーキテクチャとしては、DDD本には以下の2つが書かれています。

ソフトウェア設計のトレードオフと誤りを出版しました

オライリージャパンから「ソフトウェア設計のトレードオフと誤り」の翻訳をフューチャーのメンバーと一緒に出版いたしました。好評なようで、発売一カ月ほどで増刷も決定いたしました。

データライフサイクルとトレードオフ

ソフトウェアの中身を大きく2つに分解すると、プログラムとデータに分かれます。データの表現にもいくつもの方針があって、それによるトレードオフがあるな、というのはもやもやと考えていたので、その考えをまとめて文章にしてみました

データベースと向き合う決意

「中間層を増やして柔軟性を高めるのがソフトウェアの歴史」これは大学時代に2つ上の先輩が言っていた言葉です。例えばマシン語を直接書くのではなく、アセンブラで書けば、変換（コンパイル）の手間はかかりますが、他のCPUへの移植はしやすくなります。

DynamoDB利用時の書き込みスキュー（Write Skew）の回避

一般的に複数のトランザクションが並行して同じオブジェクトに対してアクセスを行う場合には、トランザクションの分離レベル（SERIALIZABLE/REPEATABLE READ/READ COMMITTED/READ UNCOMMITTED）によって様々な問題が発生します。DynamoDBは2018年にトランザクションがサポートされましたが、本記事ではファントムリードによる書き込みスキューの問題とその対応について取り上げたいと思います。

ソフトウェアのバージョンと開発スタイルの関係について

バージョンという言葉を身近に聞いたり、体感することは多いのではないでしょうか？ソフトウェア開発においてもバージョンは決して避けて通ることはできません。しかし、プログラムにバージョンをつける側に立ってみると、そもそもバージョンとは何なのでしょうか？ふわっと考え出すとわりときりがないと思います。

Class Widgets vs Functional Widgets

FlutterでWidgetを開発するとき、Stateless WidgetやStateful Widgetを継承したクラスを作成することが一般的だと思います。一方でクラスを定義せずとも、Widgetを返却するFunctionを定義することで同様のことが実現できるのでは？と考えたことはないでしょうか。

Project Haystackに関する備忘録

IoTに関するデータモデル標準化に用いられるProject Haystackについて調べる機会があり、日本語でまとめられている文献が少なくて理解するのに若干苦労したため、備忘録も兼ねて調査した内容を簡単にまとめておきます。Project Haystack は、ファシリティ・機器などの IoT に関するデータモデルを標準化する取り組みです。ビルシステムとそれに関連するデバイスのモデルを様々なツールで解釈できるようにするため...

A5:SQL Mk-2に回帰した話

みなさま、ER図を作成するとき、どんなツールを使っていますか？タイトル通りの出オチですが、数度の輪廻転生を経て私はA5:SQL Mk-2（以下A5M2）を使用しています。ツールをお勧めする記事は多数ありますが、意外と現場のリアルな事情を踏まえた投稿は見当たらなかったので、経験を踏まえてER図作成ツールの比較検討していきたいと思います。

PlantUMLのテーマ（思わぬ展開）

PlantUMLで使えるテーマについてのご紹介です。以前、チームで機能設計するためのPlantUML標準化の記事でも書かせていただきましたが、PlantUMLのデフォルトカラーって少しドライですよね。色の好みは人それぞれで、あれはあれでカッコよさはありますが、複雑な図は少しでも可愛く描きたい・楽しく見たいものです。

マルチクラウドを考えてみた

私は、企業へのクラウドのアーキテクチャ方針を考えたり、デザイン、構築などの仕事を主にしています。その際によくマルチクラウドの導入をしたい！という要望を最近受けることが多くなった気がします

Terraformerとしてコードを書いて思うこと

ここ最近はほぼ1からコード設計をして運用まで持っていくこともあり、「より腐りにくい、より息の長いコード」というものを考えるようになりました。Terraformだからこその「定期メンテを簡易にするためには」「より簡単に変更するためには」をひたすら突き詰めていった結果、アツい気持ちが生まれ、今回は筆を取っています。

OpenAPIにおけるundefinedとnullの設計

OpenAPI仕様に則ってREST APIの設計をする際に、値が存在しないという状態をどのように表現するかというお話です。まずはじめに、ここで`undefined`と言っているのは、OpenAPIの仕様において、リクエスト/レスポンスのデータ型を定義するSchema Objectのプロパティの1つである`required`が指定されていない状態を指します。

「リアクティブコントローラ」導入がもたらすかもしれないウェブフロントエンド設計の変化

フロントエンド連載2日目のエントリーです。あまり話題になっていないような気がしますが、Web Componentsを実装するためのフレームワークのLit-Element v3がバージョンアップして、ついでにリブランディングしてLit v2.0となりました。ロゴも変わり、ウェブサイトも新しくなりました。

Goの構造体の使われ方の設計

Goで構造体を設計する場合、オブジェクト指向的な「型ごとの責務の分担」以外に、「どのように使われるものか」を考える必要があります。 ポインタで扱うのか？値として扱うのか？両方許可するのか？値として扱える場合にimmutable（変更不可能）なオブジェクトとするのか...

HTTP検索条件、GETにするか？POSTにするか？

RESTfullとかRESTishな方針でWebAPIの横断検索を設計する際にチーム内で方針について議論したやり取りの備忘記事です。

Goのフラットパッケージについて登壇しました

TIG真野です。2021/3/19に「Future Tech Night #7 〜フューチャーの開発事例と共に学べるGo勉強会〜」を開催しました。トップバッターでGoの開発構成・アプリアーキテクチャについて話したので報告します。

GCPで構築するサーバーレスデータレイク①

GCPで構築するサーバーレスデータレイクの連載第1弾の記事となります。GCPでデータレイクを構築する場合のポイントについて連載形式でご紹介していければと思います。

Go 1.16のsignal.NotifyContext()

Go 1.16リリース記念連載の最終回はsignal.NotifyContextです。ご存知のように、Go 1.7でcontext.Contextが入ってから、少しずついろいろなAPIがContext対応になりました。

GoのWebアプリ開発でフラットパッケージにした話

1年弱ほどGo言語でWebAPIアプリケーション開発を行っていますが、かなり割り切った構成・テスト方針を採用しました。そろそろ1年弱になり機能開発も比較的落ち着き、保守運用フェーズの割合も徐々に増えてきた頃合いなので、やったこと・学び・反省といった振り返りを共有します。

デスクトップWebアプリのモバイル化における考え方・Tips

こんにちは、2019年入社、TIGメディアユニット所属の中村立基です。今回はメディア業界向けクラウドサービスGlyphFeedsCMSのモバイル化を例に、Webアプリケーションをモバイル化する際の考え方や手法について書きます。Webアプリケーションをモバイル化する際の参考になれば幸いです。昨今「モバイルファースト」という言葉が広まる中、スマートフォンを始めとするモバイル端末利用の風潮は強まっています。それに伴いWebアプリケーションもモバイル端末での利用シーンが拡大しています。

あなたのGoアプリ/ライブラリのパッケージ構成もっとシンプルでよくない？

Goでプロジェクトのフォルダ構成どうしよう、とググると見つかるStandard Go Project Layout(https://github.com/golang-standards/project-layout)。とはいえ、これはかなりコード量を増やしてしまう恐れがありますので、導入する場合のデメリットも考えておく方が良いです。

Go Tips 連載5: エラーコードベースの例外ハンドリングの実装＋morikuni/failureサンプル

今回は、errors package を一部利用して、エラーコードベースのエラーハンドリング処理を実装しました。また、morikuni/failure を利用した実装への書き換えも試してみています。

スキーマファースト開発のためのOpenAPI（Swagger）設計規約

みなさん、Swagger使ってますか？本記事では実際にSwaggerのスキーマ定義を設計していく上で取り決めた規約について書いてみたいと思います。