僕自身は龍が如くシリーズは、クロヒョウ2、極1、極2、０、3、4、5、6、0とやって、7はRPGだし主人公違うしなぁと思って、買うだけ買って後でやろうと積んでいたところ、CEDECのすごいテストの話を聞いて、（オリジナル版を積んでいたのに)インターナショナル版を買って始めてしまうぐらいインパクトがあり（そして積んでたのを後悔したぐらいよかった）ました。それ以降、維新極、7外伝、8は発売日に買ってプレイしてます。 こちらにその講演の詳細なレポートがこちらにあります。 https://www.famitsu.com/news/202009/11205564.html その8の発売前に龍が如くスタジオの技術責任者の方がXのアカウントを開設して、C++のコードを投稿されていたのですが、それに対してエンプラ開発目線で意見しているようなツイートを見かけて、「いや、システムの特性全然違うから」と思い筆を

秋のブログ週間2023の1日目です。 はじめに※この記事やこの本を読んだからと言って自身で診断を行わず、まずは整形外科などの医療機関にて診断を受けて、医師の方と治療方針を決定しましょう。また既に治療中の方は、取り組む前に一度医師や理学療法士の方と相談しましょう。 腰が痛くて仕事にならない、プログラマーこそが天職なのにこの痛みと一生付き合っていかないといけないのか…と思っている方は結構多いのではないでしょうか？ かく言う自分も腰痛持ちで、20代前半で椎間板ヘルニアと診断されました。当時はヘルニアが神経を圧迫し歩くのもつらい時期もありましたが、通院によってなんとか回復しました。 しかし完全にはよくならず、残りの人生全てを腰を気にしながら生きないといけないのか、、、と絶望しておりました。 そんなこんなで腰痛人生を送ってきたわけですが、ケリー・スターレット式　「座りすぎ」ケア完全マニュアルは自分の

はじめにTIG真野です。育休明けです。 フューチャー社内のタスクランナーはmakeやTaskなど複数の流派があり、チームによって使い分けられています。個人的にはmakeで良いんじゃないかと思っていますが、Taskも良いですよね。 makeは細かい記法をいつも忘れる＋調べるとC言語向けの情報が出てきて脳内変換に手間を感じたため、makeを用いてWebバックエンドアプリをGoで開発するということをテーマに、役立ちそうな情報をまとめます。 なお、今記事におけるmakeは、GNU Makeを指します。バージョンは以下で動かしています。 MakefileのためのEditorConfigMakefileのインデントはハードタブである必要があります。誤りを防ぐためにもEditorConfigを設定しておくと良いでしょう。 makeは通常、Makefileという名称をデフォルトで認識しますが、同一フォルダ

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

アーキテクチャの議論でよく出てくるのが、コンウェイの法則と、逆コンウェイ戦略です。これについては、うっかりIT用語をバズらせてしまう達人のマーチン・ファウラーのブログにも詳しい説明があります。角さん、いつも翻訳ありがとうございます。 「逆コンウェイの法則」が持ち出された議論が苦手なんどけど、なんでなのかな。コンウェイの法則はよく理解できるんだがー。 — Kazunori Otani (@katzchang) February 28, 2023 この@katzchangさんのツイートもそうですが、逆コンウェイ戦略に関しては僕も少しモヤモヤするところが個人的にあり、そのあたりを周りの人（@katzchangさんや@tokoroten、@__garsue__氏）と議論したらいろいろ自分が思っていなかった知見も得られたりしたので、まとめてみます。 コミュニケーションがかえって増える問題コンウェイの

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

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

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

秋のブログ週間の9本目のエントリーになります。この企画もこんなに書く人が出てくるように育っていいですね。 「中間層を増やして柔軟性を高めるのがソフトウェアの歴史」 これは大学時代に2つ上の先輩が言っていた言葉です。例えばマシン語を直接書くのではなく、アセンブラで書けば、変換（コンパイル）の手間はかかりますが、他のCPUへの移植はしやすくなります。高級アセンブラと名高いC言語を使えばさらに移植性は上がります。C言語で書かれたVMを使う言語、例えばJava、Python、Rubyなんかはさらに移植性は上がります。 ストレージもそうです。最終的にストレージはビット列を保存するものですが、それにOSのファイルシステムというレイヤーがあり、そこにスキーマで管理されたデータを入れるDBMSが乗っかり、SQLなどの問い合わせ言語でデータ取得できるようにします。DBMSを挟むことで、レプリケーションでバッ

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

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

このエントリーはSayanさんによるUnderstanding the AGPL: The Most Misunderstood Licenseの日本語訳になります。 オープンソースの出現は、ソフトウェア産業全体を一変させました。しかし、オープンソースのコードを使って誰が何をできるかを管理することは課題でしたし、今も解決していません。オープンソースライセンスはそこに救いの手を差し伸べました。しかし、常に次のことを忘れないでください：石のない土地はなく、骨のない肉はありません。OSI（オープンソースイニシアチブ: オープンソースを促進することを目的とする組織）が承認したライセンスは80以上あり、その数はさらに増加しています。それぞれのライセンスには利点と欠点があるため、オープンソースの開発者は自分のプロジェクトにあったライセンスを選ぶのは簡単ではありません。Affero General Pu

Real World HTTPでも紹介したネタですが、お仕事で受けている技術コンサル中に質問をいただいた時に、微妙に本で紹介した内容では少し足りなかったので、改めて整理のためにブログ記事にしてみました。次回、本が改訂されることがあればこのブログエントリーの内容も入れて加筆したいと思います。 Real World HTTPだとGoを使っていましたが、フロントとサーバーを同時にいじるので、本エントリーではNext.jsをサンプルに使います。Next.jsでプロジェクトを作って（npx create-next-app@latest –ts)、適当なプロジェクト名を入れてアプリケーションの雛形を作っておいてください。 Next.jsでは、1つのスクリプトファイルを作成すると、それがサーバーAPI(/pages/api以下)と、フロントの画面(/pages/以下のapi以外)になります。Next.j

フロントエンド連載の6記事目です。 今年のゴールデンウィーク（STAY HOME週間）に最近話題のSvelteに入門したので紹介を書きます。 Svelteとはなんですか？ 公式のサイトはこちらです。有志の方々が日本語翻訳のサイトを作ってくれています。たいへんありがとうございます！ Svelteは主にブラウザ上で動作するユーザーインタフェースを作るフレームワークで、ReactやVue.jsの対抗馬的な存在です。 特徴とReactやVue.jsなどほかとの違い公式サイトでも、コーディングする際のコード量が少ないという特徴があげられています。 詳しくはこちらのブログに書かれています。コードが多ければ作業時間とバグが増えてしまうため、コードが減らすことはこれらの問題を減らすことができるというようなことが書いてありました。またブログには具体的なコードで量の差について書いていますのでぜひ見てみてくださ

The Gopher character is based on the Go mascot designed by Renée French. はじめにTIG DXユニット 1の真野です。 コードレビューについては3,4年ほど前に、コードレビューにおけるレビュアー側のアンチパターン って記事を書いたりもしました。当時はレビュアーの伝え方って大事だよなって話をしてました。いつしかレビュイーからレビュアーに比重が変わることが増えてきました。相互レビューは当たり前にしていますがが、比較的こうしたらもっと良くなるんじゃないかな？と提案される回数より、自分が提案する回数の方が増えてくるタイミングってありますよね？ そういうわけで、最近Goで主にバックエンドのWebAPIや、AWS Lambdaで動くETLアプリ、たまにCLIツールを開発する時に、2回以上同じ指摘したコメントをまとめてます。Go言語

はじめに現在所属しているプロジェクトではWeb APIやバッチ処理の設計の一環としてPlantUMLを利用しています。効率よく品質高くアウトプットを出すためには、プログラミング言語に対してコーディング規約があるように、UMLに対してもチームで設計するにあたり一定のルールを決める必要があります。 そこでプロジェクト内のPlantUMLを使用するうえでのガイドラインやルールをまとめる機会があり、せっかくなのでそれを記事化します。 記事のゴール シーケンス図設計におけるPlantUMLの標準化 必要最低限のルールだけに絞ってチーム設計の生産性と品質を上げる 記事の前提 ルールの想定の利用シーン： チームで大量生産する業務機能の処理フローを表現するために使う場合を想定。 また、この記事に記載されているルールはRDBを中心的に使用したAPI処理やバッチ処理等を念頭に置き決められたものです。 ルールの

BusterとかStretchという名前が見慣れない方もいるかもしれませんが、これはLinuxディストリビューションとしてシェアの大きなDebianのコードネームです。 Debianバージョンが少し古いStretchの方がちょびっとサイズが小さかったりはしますが、まあ実用的にはサポートが長い方がいいですよね。slimを使ってGCCとかのコンパイラを自前でダウンロードしている記事とかもたまに見かける気がしますが、マルチステージビルドであれば、そんなにケチケチしなくていいのと、パッケージダウンロードは逐次処理なので遅く、処理系が入ったイメージのダウンロードの方が高速です。並列で処理されるし、一度イメージをダウンロードしてしまえば、なんどもビルドして試すときに効率が良いです。また、多くのケースでネイティブのライブラリも最初から入っており、ビルドでトラブルに遭遇することはかなり減るでしょう。 Py

JavaプログラマーのためのGo言語入門こちらはJava to Go in-depth tutorialの日本語訳です 原文の著者に許諾を得て翻訳・公開いたします。 このチュートリアルは、JavaプログラマーがすばやくGo言語にキャッチアップできるようにすることを目的としています。 目次 Hello stack 主な違い シンタックス（文法） 定数 構造体 ポインタ スライス 値の作成 メソッドとインターフェース エラー PanicとRecover ゴルーチンとチャネル Hello server Hello stack 1まずはじめに簡単な例を見ていきましょう。この例ではシンプルな抽象データ型をGoで実装しています。 // collectionパッケージはstring型を格納できるスタックを実装している package collection // Stackのゼロ値はすぐに使用できる空のス

前回のエントリー、一周回って、人間が読み書きする設定ファイルはJSONが良いと思ったの続きです。 設定ファイルをどうするか問題はいろいろ悩ましい問題であります。そんな中、設定ファイル用言語という触れ込みのCUEがリリースされました。 すでに、NSSOLの方が、Linterとして使うという紹介記事をすでに書かれています。これはユースケースの一部（これでも有用ですが）です。まだ使い込んだわけではなく、チュートリアルとドキュメントを一通り読みつつ軽く試した程度ですが、全体的な紹介をしようと思います。 yamlやJsonのチェック(Lint)ができるCUEの紹介 CUEによってできるようになること主な特徴としては次のような感じです。 人が書く設定ファイル(JSON/YAML/TOML/iniあたりがライバル)のための言語 スキーマ定義が書けて、バリデーションが可能 テンプレート機能で一部が違うデー