ブックマーク / future-architect.github.io (101)

  • 初めてのセキュリティ情報収集(mjckeck4) | フューチャー技術ブログ

    こんにちわ。Cyber Security Innovation Group(CSIG)の井上です。 部門名の通り、サイバーセキュリティに関する部署で、セキュリティコンサルティングやFutureVuls( https://vuls.biz )という脆弱性対策サービスのコンサルティングやサポートをしています。 初めに春の入門祭り2023 という事で、初めて脆弱性対応をする方に向けた記事を書いてみようと思います。 この時期になると、部門移動等で情報システム部に移動し「何をやっていいのか分からない…」という話も時々聞きます。 今回は、IPAの「mjcheck4」( https://jvndb.jvn.jp/apis/myjvn/mjcheck4.html )というツールを使った、セキュリティ情報の収集についてお話しようと思います。 セキュリティ情報収集とは世の中にはセキュリティ情報はいろいろありま

    初めてのセキュリティ情報収集(mjckeck4) | フューチャー技術ブログ
  • CDN 入門とエッジでのアプリケーション実行 | フューチャー技術ブログ

    のようなイメージです。 ※192.0.2.0/24、198.51.100.0/24、203.0.113.0/24 は例示に利用できる IP アドレスブロックです。 実在する IP アドレスではありません。 以上のように、CDN では オリジンサーバーのドメインと CDN 用ドメインの紐づけ CDN 用ドメインに対応する IP アドレスの動的な名前解決 を用いて、オリジンサーバーへのリクエストを地理的に近いエッジロケーションへのリクエストに振り替るのが一般的です。 CDN サービスの例ここでは、CDN サービスの例を各クラウドベンダーごとに簡単に紹介します。 AWS - Amazon CloudFrontAWS の提供する CDN サービスは Amazon CloudFront です。 Amazon CloudFront では、CDN のオリジンサーバーとして EC2 や S3、ELB など

  • markdownlintで設計書の品質を高める | フューチャー技術ブログ

    はじめにフューチャー技術ブログのリレー形式の連載である、春の入門祭り2023の1日目です。TIG真野です。 ここ数年、Markdown設計書をチームで書き、GitHubGitLab)上でレビューするフローを採用しています。なるべくテキストベースで設計開発フローを統一するため、私の所属するチームでは以下のようなツールを採用しています。 シーケンス図、業務フロー図 Markdown中にPlantUMLで記載 参照はGitHub上からも見れるように、pegmatite を利用 システム構成図など画像系 Diagrams.netdraw.io)で作成し、.drawio.png の拡張子でMarkdownから参照 これだけは目視で差分チェックとなる Web API定義 OpenAPI SpecのYAMLファイル 参照はGitHub上からも見れるように、swagger-viewer を利用 ER

    markdownlintで設計書の品質を高める | フューチャー技術ブログ
  • データライフサイクルとトレードオフ | フューチャー技術ブログ

    ソフトウェアの中身を大きく2つに分解すると、プログラムとデータに分かれます。コードコンプリートやA Philosophy of Software Designなど、評判の良いソフトウェア設計のはいくつかありますが、それらはどれもプログラムの説明がメインでデータのライフサイクルについての説明はなかったと思います。しかし、データの表現にもいくつもの方針があって、それによるトレードオフがあるな、というのはもやもやと考えていたので、その考えをまとめて文章にしてみました。 データといっても、処理中の短期間の間では変わらない、いわゆるマスターデータ的なデータです。ジャーナルというか、トランザクション的なデータはここでは触れません。 この記事では、それぞれのトレードオフについて考えていきます。 即値(リテラル) 定数 コマンドライン引数 環境変数 設定ファイル ダウンロードコンテンツ オンラインデータ

    データライフサイクルとトレードオフ | フューチャー技術ブログ
  • 「リーダブルコード」を読んでTerraformの可読性について考える | フューチャー技術ブログ

    こんにちは。TIGの伊藤太斉です。 この記事は、読書感想連載の6日目です。 今回取り上げる書籍は、多くのエンジニアが通過するであろう、「リーダブルコード」についてです。 最近、「もし「リーダブルコード」を弁護士が読んだら?」という記事をたまたま見かけて読んでみました。記事としては契約書にも同じことが言える、と自分が知らない世界でも使える部分はあるのだと読んでいました。そして、ふと考えてみると、「うちにもがあったじゃないか。しかも積読している。」と思い出し、今回積読解消の機会としてこの連載に参加しました。 リーダブルコード書評や感想については既に多くの方が書いている内容があるので、今回はTerraformと絡めて書いていければと思います。私は、俗にいうプログラミング言語に対しては明るくない方なので、自分が理解できうるTerraformにおいて考えたらどうなるか、について地震の頭の整理、理

    「リーダブルコード」を読んでTerraformの可読性について考える | フューチャー技術ブログ
  • 「実践Redis入門」所感 ~「E.G.コンバット」の観点から語る~ | フューチャー技術ブログ

    積読を消化しようというテーマの、読書感想文連載 の2冊目です。 導入『自分たちは、クラウドネイティブじゃなくてマネージドネイティブなんだよ…』 TIGの原木です。 最近、冒頭のような開発者の嘆きを人づてに聞く機会があり、今も脳裏に残り続けています。 昨今のITシステムにおいて、クラウドサービスは欠かせないものとなっています。しかしユーザー、そして開発者として大きな利便性を享受する裏で、クラウドサービスによって巧妙に隠蔽された裏のソフトウェアを意識する機会は減り続けているのではないでしょうか? Webサービスにおいて、RedisやMemcachedに代表されるキャッシュサーバーもそのようなソフトウェアの1つです。 キャッシュサーバーは、Webアプリケーションなどデータの読み込みや保存を効率化するために欠かせない存在ですが、同じデータストアであるRDBMSなどと比較していま一歩隠れた存在だと思

    「実践Redis入門」所感 ~「E.G.コンバット」の観点から語る~ | フューチャー技術ブログ
  • 単体テストの考え方/使い方 の感想文 | フューチャー技術ブログ

    はじめにTIG EXU真野です。 積読を消化しようというテーマの、読書感想文連載 の1冊目は、単体テストの考え方/使い方 です。 書籍の基礎情報です 2022年12月28日発売 Unit Testing Principles, Practices, and Patterns の翻訳書。原著は2020年1月14日に発売 テーマ 質の高いテストを行い、ソフトウェアに価値をもたらそう!単体(unit)テストの原則・実践とそのパターン プロジェクトの持続可能な成長を実現するための戦略 単体テストの原則・実践とそのパターン コード例は C# であるものの、どの言語でも適用できる汎用的な内容とのこと 中を見ると、微妙にC#特有ぽいところに1箇所悩みましたが、それ以外はその通り 翻訳者の須田さんは、他にもセキュア・バイ・デザイン: 安全なソフトウェア設計 やOAuth徹底入門 セキュアな認可システムを適

    単体テストの考え方/使い方 の感想文 | フューチャー技術ブログ
  • プログラマーのためのCPU入門 | フューチャー技術ブログ

    まあ後半のインテルのモデルになると同じCPUでも熱設計で性能が大きく変わったり、ブースト時の性能だったり、いろいろあるのであくまでも数字は目安ですが、無視できないほど大きくなっているのがわかります。特に、Ryzenが元気なここ5-6年の競争による進化がすごいです。 なぜ5-6倍も性能が上がったのか、というのをすぐに言葉できちんと説明できる人はあまりいないと思います。最近、更新がなくなってしまい、Facebook(なぜか友達にしていただいた)上でも活動がみられなくて、悲しいのですが、後藤弘茂のWeekly海外ニュースの連載をずっと読んでいた人であれば、「命令デコーダーが増えたのね」とかなんとなく強くなった部分のイメージがつくとは思いますが、そのなぜ、というのに、実験付きで数値の根拠も含めてわかりやすく説明してくれているのが書です。 CPU実験がおもしろい書は、豊富な図で(LambdaNo

    プログラマーのためのCPU入門 | フューチャー技術ブログ
  • チームの開発生産性を高めるための心がけ | フューチャー技術ブログ

    はじめにTechnology Innovation Group 辻です。 秋のブログ週間の 4 目です。 最近はアーキテクトとしてチームにジョインすることも増えてきました。より素早く、継続的にビジネス上の価値を提供するためにチームの開発生産性は重要です。チームの生産性を高めるために私が心がけているいくつかの内容を紹介します。 心がけ 開発上のボトルネックを取り除く コードべースの品質を保つ コードを読みやすくする 素早くレビューに取り組む、質問/相談にレスポンスする 体裁の一貫性を保つ 1.開発上のボトルネックを取り除く開発上のボトルネックになっているポイントを発見し、原因を特定し、対応する、ということです。一例をあげると以下のようなことです。 コードの責務がはっきりしておらず、改修時の影響が大きくなる。意図しない挙動になる そもそもテストコードがなく、機能仕様が満たされているのかわから

    チームの開発生産性を高めるための心がけ | フューチャー技術ブログ
  • 業務システム開発でsqlcを導入して良かった点とハマった点 | フューチャー技術ブログ

    はじめにTechnogoly Innovation Group 辻です。Go には Gorm や SQLBoiler をはじめとして様々な ORM があります。2021 年には当社のブログで OR マッパーの連載を行ったこともありました。絶対的な ORM があるわけではなく、業務システムの特性やチーム構成などに合わせて ORM を選択することになるでしょう。 今回、私たちのチームでは、バッチ処理が中心的な業務システム開発において GoORMsqlc を採用しました。素の SQL を書いていくチームの開発方針1とマッチし、開発体験は非常に良かったです。一方、枯れきってはいない ORM ではあります。いくつか想定外の挙動が発生し GitHub の Issue を見ながら問題を切り分けることもありました。 これから sqlc を導入してみようかな、と考えている方々の参考になればと思い

    業務システム開発でsqlcを導入して良かった点とハマった点 | フューチャー技術ブログ
  • CSV処理における共通処理をDecoratorパターンで実現する | フューチャー技術ブログ

    はじめにTechnogoly Innovation Group 辻です。 システム間のデータ連携として、他システムが出力した CSV ファイルを Go で読み込んでリレーショナルデータベースにファイルのデータを保存する、という処理がありました。CSV の値をデコードしたあとに共通的な処理を差し込みたいユースケースで Decorator パターンを使って実装をしました。コードベースをシンプルに保ちつつ共通処理をフックできます。実用的なユースケースで Decorator パターンを紹介する記事は少ないと思ったので、記事を書きました。 まず Decorator パターンが必要になった背景を説明したあとに具体的な Go の実装を見ていきます。 背景他システムが出力した CSV ファイルを Go でデコードして、PostgreSQL にデータを投入するような処理がありました。簡略化したイメージは以

    CSV処理における共通処理をDecoratorパターンで実現する | フューチャー技術ブログ
  • Goで作ったロジックにWebUIをつけてGitHubページに公開する | フューチャー技術ブログ

    ちょっとしたツールをGoで作ってみたのですが、わざわざインストールしなくてもいいようにWebのUIをつけてブラウザで使えるようにしてみました。作ってみたのは以下のツールで、Markdownのリスト形式でざっと下書きしたテーブルの設計をSQLとか、PlantUMLとかMermaid.js形式のERDの図にします。 https://shibukawa.github.io/md2sql/ ウェブフロントエンド部分はNext.jsの静的サイトで、GoWASMにしてロードして実行しています。WASMを使うのは初めてなのであえて選んでみました。 GoWASM化するもともとCLIツールは作っておりました。CLIのメインはcmd/md2sql/main.goで作っていました。この中でやっていることは kingpin.v2のオプションパース 指定されたファイルを読み込み(あるいは標準入力) パース 指定

  • AGPLが適する場所、適さない場所 | フューチャー技術ブログ

    前回翻訳したAGPLを理解する: もっとも誤解されたライセンスでは、実体以上に強いライセンスであると思われているケースについての紹介がありました。 もちろん、使い方次第ではアプリケーションコードの開示が必要になってしまうケースもあるかと思います。前回のエントリーはわかりやすい切り口で書いてくれていますが、いくつか、やはりプロダクトコード側へ制約が出るケースが考えられるので、その点についてまとめてみます。 AGPLの特徴を2行でまとめると以下の通りかと思います ネットワーク越しに利用することも配布とみなし、AGPLで書かれたアプリケーションのソースにアクセスする権利が伝わる ネットワーク越しの利用することはリンクではないため、ネットワークで通信するアプリケーションのライセンスをAGPLにする必要はない 配布とリンクがごっちゃにされるのが、よくされる誤解の原因かと思います。もしネットワークアク

    AGPLが適する場所、適さない場所 | フューチャー技術ブログ
  • 東京Node学園40時限目で話をしてきました | フューチャー技術ブログ

    オンライン開催された東京Node学園40時限目で発表してきました。スライドはこちらです。 内容としてはこのブログに書いた、gRPCフロントエンド通信の第一の選択肢になる時代がやってきたかも?という記事をベースにして、gRPCとは何かとか、Connectプロトコルの存在や、今までの公式実装ととどのように開発のスタイルが変わるか、みたいな話を絵つきで説明したりしました。 あとは、streamを使って受信する部分のTypeScriptコードがどうなるかの紹介とかも追加しました。 // 単発実行 return await client.greet({name}); // ストリームからの受信 for await(const res of client.conversation({name})) { setMessage(res.message); } あるいは最近追加されたconnect-web

    東京Node学園40時限目で話をしてきました | フューチャー技術ブログ
  • React + Goで簡素な掲示板アプリを作ってみた | フューチャー技術ブログ

    はじめにこんにちは。金融グループ所属、新人の藤戸四恩です。 記事は夏の自由研究ブログ連載2022 5日目の記事です。 今回は勉強中のReactTypeScriptGoを使って掲示板アプリを作りました。 夏の自由研究ということで、以前から気になっていたviteを使って開発しました。 いままでフロントエンドの開発環境を作成する際には、create-react-app を使っていましたが、少しもっさり感を感じていました。そこで従来のビルドツールよりも高速に動作すると噂のviteを使ってみました。 また、掲示板アプリを開発する上で勉強になったパスワードをハッシュ化してDBに保存するところが勉強なったところをピックアップしました。 作ったアプリ今回の掲示板アプリでは、投稿ができて、投稿されたものが一覧で表示されます。 また、一覧表示されている投稿のうちログインしているユーザー人が投稿したもの

    React + Goで簡素な掲示板アプリを作ってみた | フューチャー技術ブログ
  • Go 1.19のメモリ周りの更新 | フューチャー技術ブログ

    Go 1.19リリース連載の6目です。 Go 1.19では、いくつかメモリ周りの更新がありました。1つはガベージコレクタ周りのお話と、あとはメモリモデルの更新です。 ライブラリではsync/atomic.Int64など、いくつか型が追加されました。 ガベージコレクタガベージコレクタの詳細と調整の仕方についてのドキュメント が追加されました。このドキュメントはスライダーで動作の変化がみられるインタラクティブなドキュメントになっているので、ぜひご覧ください。 「GoJavaと違って、GCの調整ポイントがほとんどなく、最初からトップスピード(オプションの選択の中で相対的に)だよ」みたいに説明されることもありましたが、そういうわけにも行かなくなったというか、ある程度知っておく必要はあるかもしれません。とはいえ、デフォルトでも十分うまくやってくれますし、そもそも即座に終了するユーティリティでは頑

    Go 1.19のメモリ周りの更新 | フューチャー技術ブログ
  • Flutter でプッシュ通知するときに知っておきたいこと | フューチャー技術ブログ

    はじめにこんにちは。TIGの越島です。 Dart/Flutter連載 の5日目のお題はFlutterプッシュ通知です。 Flutter製のスマホアプリにプッシュ通知機能をつけるとなったときに「最初に教えてもらってたら楽だったな〜」という情報をまとめてみました。また、最後に具体例としてFlutter x Firebase Cloud Messaging x Amazon Pinpointを組み合わせた場合の実現方法も簡単にご紹介します。 プッシュ通知の基礎知識まずはプッシュ通知について、基からおさらいをしていきましょう。 ローカル通知とリモート通知プッシュ通知には大きく分けて以下の2種類があります。 ローカル通知 リモート通知 ローカル通知は、デバイスの内部で完結するプッシュ通知で、インターネット接続を必要としないものになります。リマインダーアプリで決まった日時に通知を飛ばす等、外部のサ

    Flutter でプッシュ通知するときに知っておきたいこと | フューチャー技術ブログ
  • スキーマのバージョン管理と互換性の話 | フューチャー技術ブログ

    はじめにはじめまして、TIGの原木です。サービス間通信とIDL(インタフェース記述言語)連載の4目です。 気が付けば、バージョンの話0ばかりしています。 この記事ではスキーマのバージョン管理と互換性について話します。 “スキーマ”が指し示す言葉と課題一般的にスキーマのバージョン管理という話が出た場合、次のどちらかを想像する人が多いのではないでしょうか。 データベースのスキーマ(DB内のデータ構造)の変更をどうやってバージョン管理していくか サービス間通信で使用するデータフォーマット(ex. gRPCのprotobuf)をどうやってバージョン管理していくか データ構造が変わったことによりソフトウェアの改修が発生するとわかった瞬間、この問題に直面して「どうしよう…」と悩まれた経験を持つ方は数知れずいらっしゃるかなと思います。 両者において、スキーマのバージョン管理が課題だと意識するタイミング

    スキーマのバージョン管理と互換性の話 | フューチャー技術ブログ
  • Go言語で定数として扱いたいmapを毎回アロケートさせて性能劣化した話 | フューチャー技術ブログ

    はじめに失敗談をテーマにした連載の3目です。 TIG DXユニットの原です。21年度4月に新卒で入社し、2年目となります。 参加しているプロジェクトで、数百万件のデータを処理する機能を担当したことがありました。 記事はその際の失敗と、その失敗から得た経験を共有するため、執筆しました。 内容のサマリ 来フィールドで宣言すべき定数的に扱いたい変数を、関数内で毎回生成しreturnしてしまったので呼び出す度に毎回アロケートが発生し性能劣化してしまった Benchmark Test、Profiling、Escape Analysisでどういう挙動になってしまっていたか調べてみた 内容記事では、まずどのような状況であったかを説明し、どのような順番で問題を解決したかの順で説明します。 主にGoのテストとProfilingに関した内容です。 Goのテストについての関連記事として、Goのテストに入

    Go言語で定数として扱いたいmapを毎回アロケートさせて性能劣化した話 | フューチャー技術ブログ
  • ドメイン駆動設計の源流のPofEAAを読んでみる | フューチャー技術ブログ

    最近、ドメイン駆動設計(以下DDD)とかそのあたりを読みこんでいる人から、DDDの読み方を教えてもらいました。ここではDDDはエリック・エヴァンスのドメイン駆動設計の方を参照しました。 @katzchang さんから教わったのは「DDDはパターンランゲージの形式を意識してるよ」ということでした。ただし、きちんとしたパターンランゲージの形式になっておらず、記述が著者のものになってるので、読者は注意して読む必要があるのかもとのことです。 @ryoaitaさんから教わったのは「DDDはエンタープライズアプリケーションアーキテクチャパターン(以下PofEAA)を下敷きにしているだよ」ということでした。 DDDももう時代的にはかなり古いです。自分で読んだ限りは全然好きになれなくて、でもきっと何かあるはずだと3-4冊読んでみましたが感想は変わらずでした。ユビキタス言語も「当たり前のものを先頭に