タグ

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

  • 2024年版のDockerfileの考え方&書き方 | フューチャー技術ブログ

    最近はお客さんとの勉強会でDockerのドキュメントをつまみいして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事Pythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整

    2024年版のDockerfileの考え方&書き方 | フューチャー技術ブログ
    kimihito
    kimihito 2024/07/27
  • 2024年Gitワークフロー再考 | フューチャー技術ブログ

    春の入門祭り2024の2記事目です。 Gitは、出自としては1週間で作られたLinuxカーネルのための分散バージョン管理システムでした。当時のワークフローに合わせてパッチをテキスト化してメールに添付できるような機能だったりが備わっています。 一方で、現代のGitは、デファクトスタンダードなバージョン管理システムになりLinuxカーネル以外のアプリケーション開発で利用されています。分散バージョン管理ではあるものの、サーバー・クライアント型の使われ方をしていて、GitHubGitLabを核にして、ローカルで作ったブランチをpushして、Pull Requestの形にして管理しています。少なくとも周りで見る限りでは、それ以外の使われ方の方が少なくなってきてます。そんなこんなで求められている使われ方が変わってきていて、それに合わせた機能がぼちぼち増えています。それを活用することで、ウェブ画面上で

    kimihito
    kimihito 2024/04/10
  • 管理画面等でNext.jsをBetter Reactとして使う | フューチャー技術ブログ

    最近、Next.jsが複雑になりすぎて、単なるウェブ画面を作る用途にはNext.jsは重すぎるので別のものが良いとか、Vercel統合のための機能が多いんでしょ、みたいな感想を見かけることが増えた気がします。特に管理画面とか社内システムとかですね。B2Cでも設定画面系とかは当てはまるかもしれません。 ホンダ時代に、タイプRを買っても実際にサーキットとかに走らせに行く人は1/10ぐらい、という話を聞いた気がしますが、必ずしも、そのすべてのパフォーマンスを引き出さないのはダメとかなくて、単にかっこいいからとか、一部のメリットでも自分にあえば良いのです。 Next.jsも、たくさん機能がありますが、ミニマムな使い方もできます。 ほぼNext.jsの機能をオフにした使い方たぶんNext.jsを最低限で使うライン・メリットはここかな、と思います。 基的に全部CSR(Client Side Rend

    kimihito
    kimihito 2023/06/01
    “Next.jsはeasyであるがsimpleではないというのを地でいく発展をしています。”"機能追加も活発にされているように見えるのですが、ずっと追いかけてきた立場から見ると、「よりeasyであろう」としているように思えます。"
  • Goのテストに入門してみよう! | フューチャー技術ブログ

    2020/08/15更新: 「テストの失敗をレポートしたい」と「サブテストの一部のみ実施したい」の章を追加 はじめにTIG の辻です。今回は春の入門祭りということで Go のテストに入門してみよう! という記事です。 書いた背景ですが Go の標準ライブラリのコードリーディング会で testing パッケージにチャレンジしてみましたが、難しすぎてわからん。そもそも Go のテストって何ができるんだっけ? という話になり、基的な内容をなるべく具体例をまじえながらまとめました。 ざっとどんなことができるんだろう、という index になれば幸いです。 TipsGo に組み込まれているテストの仕組みの中に、ベンチマークに関するテストと Example テストというサンプルコード用のテストも含まれているのですが、この 2 つは対象外にします。基礎的と思われる内容から順に並べてみました。 はじめに

    Goのテストに入門してみよう! | フューチャー技術ブログ
    kimihito
    kimihito 2022/11/12
  • Go入門の軌跡 | フューチャー技術ブログ

    Gopher wan designed by Renee Frenc. はじめにこんにちは。TIG DXユニットの今泉です。 秋のブログ週間の2目です。 業務ではJavaを使用する機会が多かったのですが、今年に入ってからGo言語を扱うようになりました。 これまでプライベートではエディタに叱られながらGoを雰囲気で書いていたりはしたのですが、これを機にしっかりと学ぶことにしました。 記事ではキャッチアップのため自分が参考にさせていただいたリソースを紹介させていただきます。 一通り学んだ結果、コードが読み解けなかったりWebAPI開発で困るような場面はかなり減ったと思います(コードレビューGoっぽくないよね、みたいな指摘は受けるのでまだまだ精進は必要です)。 言語仕様を学ぶ A Tour of Go Goの言語仕様をブラウザ上で学ぶことができる公式のチュートリアルです。 実際にコードを実

    Go入門の軌跡 | フューチャー技術ブログ
    kimihito
    kimihito 2022/11/12
  • AGPLを理解する: もっとも誤解されたライセンス | フューチャー技術ブログ

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

    AGPLを理解する: もっとも誤解されたライセンス | フューチャー技術ブログ
    kimihito
    kimihito 2022/09/23
  • Goのフラットパッケージについて登壇しました | フューチャー技術ブログ

    はじめにTIG真野です。 2021/3/19(金)にFuture Tech Night #7 〜フューチャーの開発事例と共に学べるGo勉強会〜 を開催しました。 トップバッターでGoの開発構成・アプリアーキテクチャについて話したので報告します。 なお、その他の登壇者の資料はこちら に公開済み。他の登壇者のレポートはこちらです。 GoDockerAPIを叩いてみる GoにおけるAPIドキュメントベースのWeb API開発について登壇しました 発表内容:Goでフラットパッケージを導入してみて良かったこと、これから フューチャー技術ブログで、GoのWebアプリ開発でフラットパッケージにした話 という記事を公開した内容の改定版になります。なぜフラットパッケージに至ったかの経緯についてなるべく自分がたどった経路を細かに説明することを意識しました。 かなり挑戦的で大胆な設計だったとおもいますが、一

    Goのフラットパッケージについて登壇しました | フューチャー技術ブログ
    kimihito
    kimihito 2022/09/14
  • GoのWebアプリ開発でフラットパッケージにした話 | フューチャー技術ブログ

    2023.10.5追記: Goチームからプロジェクトの目的に応じたディレクトリ構造についてのドキュメントが公式に公開されています。 https://go.dev/doc/modules/layout 2020/11/13 「やってみてよかったことまとめ」「やってみて困ったこと」「外部モックサービスを使ったユニットテストの未来」の章を追記 2020/11/18 「やってみてよかったことまとめ」にSNSでもらったフィードバック内容を追記 はじめにこんにちは、TIG 真野です。秋のブログ週間連載の第9弾です。 1年弱ほどGo言語でWeb APIアプリケーション開発を行っていますが、かなり割り切った構成・テスト方針を採用しました。そろそろ1年弱になり機能開発も比較的落ち着き、保守運用フェーズの割合も徐々に増えてきた頃合いなので、やったこと・学び・反省といった振り返りを共有します。 Goのパッケージ

    GoのWebアプリ開発でフラットパッケージにした話 | フューチャー技術ブログ
    kimihito
    kimihito 2022/09/14
  • 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編 | フューチャー技術ブログ

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

    仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編 | フューチャー技術ブログ
    kimihito
    kimihito 2022/07/13
  • Mypy と Pyright の解析手法と型情報の比較 | フューチャー技術ブログ

    はじめにMypy や Pyright は Python の静的解析ツールとして有名ですが、これら二つに解析情報でどのような違いがあるのかわからなかったので、実験することにしました。Pyright は Mypy に比べて後発のプロジェクトですが、性能面で優れているなどとして徐々に注目を集めています。 https://github.com/python/mypy https://github.com/microsoft/pyright 解析以外での比較はこちらが参考になります。 https://qiita.com/simonritchie/items/7492d1c1a3c13b2f27aa#%E4%BA%8B%E5%89%8D%E3%81%AEpyright%E3%81%AE%E8%BF%BD%E5%8A%A0 実験概要Mypy、Pyright はともに reveal_type(expr)

    Mypy と Pyright の解析手法と型情報の比較 | フューチャー技術ブログ
    kimihito
    kimihito 2022/07/12
  • JavaプログラマーのためのGo言語入門 | フューチャー技術ブログ

    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のゼロ値はすぐに使用できる空のス

    JavaプログラマーのためのGo言語入門 | フューチャー技術ブログ
    kimihito
    kimihito 2022/03/21
  • JSレスBootstrapなdaisyUIの秘密 | フューチャー技術ブログ

    使い方は、CSSのクラスにちょっと書き足すだけで動きます。使い勝手はBootstrapみたいですね。ドキュメントが検索しやすくて、サンプルが豊富で、シンプルに書かれているので、フロントエンドが苦手でCopy And Paste from Stack Overflowな人にも使いやすいと思います。 <button class="btn">neutral</button> <button class="btn btn-primary">primary</button> <button class="btn btn-secondary">secondary</button> <button class="btn btn-accent">accent</button> <button class="btn btn-ghost">ghost</button> <button class="btn b

    kimihito
    kimihito 2021/11/26
  • 「リアクティブコントローラ」導入がもたらすかもしれないウェブフロントエンド設計の変化 | フューチャー技術ブログ

    フロントエンド連載2日目のエントリーです。 あまり話題になっていないような気がしますが、Web Componentsを実装するためのフレームワークのLit-Element v3がバージョンアップして、ついでにリブランディングしてLit v2.0となりました。ロゴも変わり、ウェブサイトも新しくなりました。 Introducing “Lit” for Web Components 当はこのLitの紹介をこの連載でしようとしたのですが、上記のウェブサイトがすごく詳しいので、単に紹介するだけの記事だとあまり価値がないので、この中のコントローラ機能のみをとりあげようと思いますが、まずはWeb Componentsとは、というところを説明します。 n回目のWeb Components元年以前次のような記事を書きました。最初のPolymerというフレームワークが推進していたころよりも、ブラウザ対応も進

    kimihito
    kimihito 2021/09/27
  • SQLBoiler(とoapi-codegen)でつくるREST APIサーバ | フューチャー技術ブログ

    ライブリッツの筒井です。 GoのORマッパー連載、折り返して5日目です。 SQLBoilerを使用したDBスキーマ駆動なREST APIサーバの開発ワークフローを紹介します。 なぜSQLBoilerを選ぶのか?自分たちのチームでは、REST APIサーバを開発する際にはまずデータベースのテーブル設計から始めることが多いです。その次にAPI定義の設計へ入るのですが、既にテーブル定義は出来上がっているため、なんとなくSQL文が頭に思い浮かんだ状態でAPIのRequest / Responseを考えることになります。 ゆえにO/Rマッパに一番に求めるのは、「いかにストレスなく思い描いていたSQL文を実行し、Goの文脈に持ち込めるか」ということです。 この基準を元に、次のような観点からSQLBoilerを選定しています。 複雑なSELECT文でDSLに苦悩したくない前述の通り、我々の頭の中にはなん

    SQLBoiler(とoapi-codegen)でつくるREST APIサーバ | フューチャー技術ブログ
    kimihito
    kimihito 2021/08/01
  • GoのORマッパー連載を始めます | フューチャー技術ブログ

    (2021.09.18追記)おまけとして、筒井さんがさらに寄稿してくれました。 lib/pq から jackc/pgx への移行 O/RマッパとクエリビルダーO/Rマッパは Object Relational Mapperの略で、通常はGoの構造体とRDBのレコードを紐付ける処理のことを指します。O/Rマッパーと呼ぶことが多いですが、略してORMとも呼びます。名前から見るとSQL検索結果を構造体にマッピングすること(Goだとsqlx相当の処理)かなと思いますが、実際はSQLを組み立てるDSLを提供するライブラリが多いです。 クエリビルダーは、広い意味のO/Rマッパ機能のうち、SQLクエリを組み立てるライブラリのことです。調べると goquとかがまさにそれにあたります。 細かくはgoquを連載テーマにした伊藤真彦さんに譲るとして、簡単ではありますがここでサンプルコードも出しちゃいます。 ds

    GoのORマッパー連載を始めます | フューチャー技術ブログ
    kimihito
    kimihito 2021/07/29
  • Goのおすすめのフレームワークはnet/http | フューチャー技術ブログ

    僕としてはGoのおすすめのフレームワークを聞かれたら、標準ライブラリのnet/httpと答えるようにしています。というよりも、Goの他のフレームワークと呼ばれているものは、このnet/httpのラッパーでしかないからです。 Goでアプリケーションを作成する場合のイメージは次の通り。battery includedなアプローチは他の言語でもたまにありますが、ついてくる機能が今時のものが多くて、標準ライブラリで済むことが多いです。ウェブ開発についてもそんな感じです。 PythonとかRubyとかもそうですが、言語組み込みのウェブサーバー機能はテスト用で番運用には機能が足りない、性能が足りない、ということから「プロダクションに耐えうるフレームワークを別に入れないと」と思う人も多いんじゃないかな、と思いますが、Goの場合は組み込みのサーバーで問題なかったりします。Node.jsに近いかも? 世間

    Goのおすすめのフレームワークはnet/http | フューチャー技術ブログ
    kimihito
    kimihito 2021/07/15
  • サーバーアプリ開発環境(Python/FastAPI) | フューチャー技術ブログ

    Pythonでお仕事する前提で、現在のところで自分が最適と考えるチーム開発のための環境整備についてまとめてみました。今までももろもろ散発的に記事に書いたりしていたのですが、Poetryで環境を作ってみたのと、過去のもろもろの情報がまとまったものが個人的にも欲しかったのでまとめました。前提としては次の通りです。 パッケージ管理や開発環境整備でPoetryを使う 今時はコードフォーマッター、静的チェックは当たり前ですよね? コマンドでテスト実行、コードチェックとか実行とかができる(CI/CD等を考えて) VSCodeでもコマンドで実行しているのと同じコードチェックが可能(ここコンフリクトすると困る) デプロイはDockerイメージ コンテナのデプロイ環境でコンテナに割り当てられたCPU能力を比較的引き出せて、スケールさせたら線形にパフォーマンスアップできるようなasyncioを前提とした環境構

    サーバーアプリ開発環境(Python/FastAPI) | フューチャー技術ブログ
    kimihito
    kimihito 2021/06/12
  • 仕事ですぐに使えるTypeScript — 仕事ですぐに使えるTypeScript ドキュメント

    注釈 ドキュメントは、まだ未完成ですが、ウェブフロントエンドの開発を学ぶときに、JavaScriptを経由せずに、最初からTypeScriptで学んでいく社内向けコンテンツとして作成されはじめました。基の文法部分以外はまだ執筆されていない章もいくつもあります。書かれている章もまだまだ内容が追加される可能性がありますし、環境の変化で内容の変更が入る可能性もあります。 書籍の原稿はGitHub上で管理しております。もしTypoを見つけてくださった方がいらっしゃいましたら、 GitHub上で連絡 をお願いします 1 。reSTファイルだけ修正してもらえれば、HTML/PDFの生成までは不要です。フィードバックなども歓迎しております。 1 https://github.com/future-architect/typescript-guide/pulls

    kimihito
    kimihito 2021/01/06
  • GoでWebアプリ開発時にあるあるだったレビューコメント | フューチャー技術ブログ

    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言語

    GoでWebアプリ開発時にあるあるだったレビューコメント | フューチャー技術ブログ
    kimihito
    kimihito 2020/07/10
  • あなたのGoアプリ/ライブラリのパッケージ構成もっとシンプルでよくない? | フューチャー技術ブログ

    2023.10.5追記: Goチームからプロジェクトの目的に応じたディレクトリ構造についてのドキュメントが公式に公開されています。 https://go.dev/doc/modules/layout Goプロジェクトのフォルダ構成どうしよう、とググると見つかるStandard Go Project Layout。とはいえ、これはかなりコード量を増やしてしまう恐れがありますので、導入する場合のデメリットも考えておく方が良いです。 特に、プログラマーは、最初にみたプログラミング言語のフォルダ構成を親だと思う特性があり、Javaや.NETに影響されるとかなり細かくフォルダを切りたくなったり、package privateなど細かく可視性を制御しようとしたりして、なおかつ「privateのテストってどうすべきなんですか?」とか議論を始めたりもしますが、Go先生によればこれぐらいは1パッケージにフ

    あなたのGoアプリ/ライブラリのパッケージ構成もっとシンプルでよくない? | フューチャー技術ブログ
    kimihito
    kimihito 2020/05/28