docker composeの–profileオプションで必要な時だけserviceを立ち上げる
docker composeって必要なserviceまとめて扱うから重いと思ってた例えば Procfile であれば起動しないプロセスを簡単にコメントアウトできるので、一時的な ON/OFF も容易だ。 しかし docker compose は長大な YAML になっていて簡単に切り替えできないんだよなぁとずっと思っていたんだけど、いつの間にか profile というものができていた。 2021-01-20 の version 1.28.0 で --profile を support して以降、この状況は変わっていたようだ。 Docker Compose release notes | Docker Docs ということは、2023-06 に docker compose v1 が EOL になっている今、利用可能な compose コマンドでは必ず使えるということになる。 Docker
SpringのBean定義(Java Config)で型が重複する場合のインジェクション方法
🗃 {Programming/Java/org/springframework/core} 🏷 Java 🏷 Spring 🗓 Updated at 2016-03-09T01:57:53Z 🗓 Created at 2016-03-09T01:54:01Z 🌎 English Page Spring DIの基本的な話ですが、よくはまっている人を見るので書いておきます。 例として次のJavaConfigがある場合を考えてみましょう。 @Configuration @ComponentScan public class AppConfig { @Bean PasswordEncoder sha256PasswordEncoder() { return new Sha256PasswordEncoder(); } @Bean PasswordEncoder bcryptPas
フルリモートで相手に気持ちよく仕事をしてもらうためのコツあれこれ
社内のプチ発表に使った資料です。 文章のコツ 前置き フルリモートでは、文章でのやり取りがメインになる。 なので、文章がヒドいと「この人と仕事するのキツイ」と思われちゃう😢 そう思われないための色々思ったことを自戒メモ。 なるべく箇条書きにする
GitHubのMerge Queueとは何か？それと、認識しておきたいこと - Mitsuyuki.Shiiba
同僚に「GitHubのMerge Queueってあんまり知らないんだけど、どう思う？」って聞かれて「あー。僕もあれよく分かってないんだよね」って返事をして、ちょうどいい機会なので見てみた 見てみた感想としては、いくつか気をつけておきたい点があるけど、チームの開発の進め方にうまくはまれば便利な機能だな、という感じ（なんでもそうか・・・） Merge Queueって? 2023年の7月にGAになったGitHubの機能 プルリクエストをマージするときに「マージ先のブランチ（ベースブランチ）の最新の変更を取り込んでからChecks（つまりCI）を実行して、それが成功したらマージしといて！」ってお願いできる便利機能。名前のとおりQueueになっているので複数のプルリクエストからenqueueできて前から順番に処理してくれる そうは言われても最初に説明を見た僕は「？？？」状態だった。「なんでこんな機能
モノレポでマージキューと必須ステータスチェックを運用するためのTips - ROUTE06 Tech Blog
ROUTE06 でソフトウェアエンジニアをしている @MH4GF です。 GitHub のマージキュー(Merge Queue)を私のチームでの開発フローに取り入れてから数ヶ月経ちました。マージキューは非常に便利ですが、挙動の理解やセットアップに難しさがあると感じています。いくつかの課題の対処ができ安定した運用ができてきたので、この記事ではセットアップでつまづきがちな点を紹介します。 マージキューとは マージキューは 2023 年 7 月に一般公開された比較的新しい機能で、簡単に説明すると「プルリクエストのマージ前にマージ先ブランチを取り込んだ上で CI を実行し、通ることを確認してからマージする」機能です。 複数人で GitHub を利用した開発をしていると、main ブランチの取り込み漏れにより「プルリクエストでの CI は通るものの、マージ後の main ブランチの CI は失敗する
TypeScriptの型と値とバリデーション
TypeScript は本質的に自分に型が付与されていると思っているだけの JavaScript です。 いくら型を付与しようが、それが実行時に影響を与えることはありません。 コードレビューをしているとここを誤解している人が本当に多いです。何度も解説しているのですが、なかなか浸透しないので、TypeScript におけるバリデーションという視点で記事を書くことにしました。 あと TS でバリデータ使って色々作ろうとしている友人と、プログラミング始めたてで zod と openapi を使っいる友人がいたので、彼らが想定読者です。 型と値の名前空間 TypeScript 上での名前空間(スコープ)は2つに分類できます。 値: 実行時にランタイム上のメモリに存在するもの 型: 静的解析時にのみ参照可能なもの。コンパイル時に完全に消滅する。 TypeScript は基本的に JavaScript
これが「19年目のBtoB SaaS」で実践している要件定義プロセスだ【SaaSビジネス経験談 #10】｜シナマケのプロダクト【Synergy!】｜SynergyMarketing
シナジーマーケティングのプロダクト「Synergy!❐」に関わる様々な職種のメンバーが、自身の経験を元に、ビジネスに役立つ情報をお送りします。 今回の筆者は、Synergy!の「使いやすさ」実現の推進を担っているUXデザイナーです。 ・はじめに私はSynergy!の企画・開発や、プロダクトマネジメントに携わるUXデザイナーの山本です。 リリースから19年目を迎えたSynergy!は、機能の運用・保守、顧客からの要望、新機能の搭載など、やるべきこと・やりたいことがいつも盛りだくさんです。 特に規模の大きい開発ではユースケースが多岐にわたるため、要件も膨らみやすく、判断も複雑になりやすいです。弊社でも気がついたらスケジュールや実現可能性に偏った判断をしていた...ということも少なくありませんでした。 そこで、現在Synergy!の大規模な開発では、顧客の利用状況を調査・分析し、ユーザー理解を深
プレミアムプランの状態管理と決済ハンドリングの難しさ｜tsusowake
はじめにこんにちは、PIVOTでソフトウェアエンジニアをしている裾分です。PIVOTは2024年2月にアプリ・Webを本格始動しました。私はPIVOTにジョインして以降、サブスクリプション機能の開発をしてきたので設計の概要と決済プラットフォームが係る実装の難しさについてまとめてみました。 本題冒頭のリリースの通り、PIVOTはYouTubeからプロダクトに集中するにあたり、サブスクリプション機能をリリースしています。 サブスクリプションを実装するにあたり考慮すべき点として、以下の状態を考慮する必要があります。 自サービスで管理する状態 ユーザーのサブスクリプション ユーザーのプラン 他サービスで管理する状態 ユーザーへの課金を行うプラットフォームに登録されているサブスクリプションの状態 決済状態（成功 | 失敗 | …） PIVOTの場合では、決済プラットフォームとして App Store
”顧客解像度”の上げかた ~事業開発こそ「お客様」を一番理解するべき~ #BtoB事業開発アドカレ｜稲田宙人 / LayerX
■ はじめに こんにちは、LayerX・バクラク事業開発の稲田(@HirotoInada)です！ 今回は事業開発をしていく上で必要になる”顧客解像度”をどのように上げていくのかに関して自身の経験を踏まえてまとめていきます。 この記事は 「BtoB事業開発アドベントカレンダー」 の6日目の記事です！ 前回は Pitta CEO 中村さんによる「toB事業立ち上げ時のBizOpsをどこまで設計すべきか」でした ぜひハッシュタグ「#BtoB事業開発アドカレ」をつけて感想などシェアをお待ちしております！ 全ての記事はこちらから(大人気につき2枠目も増設 計50人が参加してます) ・ BtoB事業開発アドカレ 1/2 ・ BtoB事業開発アドカレ 2/2 時間がない方向けのAIサマリー 時間がない方は、サマリーを読んでもっと詳しく知りたいなとなったら、ぜひ全文読んでみてください！ この記事は、事業開
PPRはアイランドアーキテクチャなのか
先日、Next.jsの新たなレンダリングモデルであるPartial Pre-Rendering(以降PPR)について記事を投稿しました。 この記事を書いてる時は意識してなかったのですが、感想でアイランドアーキテクチャに言及されるケースが散見されました。社内で上記記事の話題になった時も同様に、アイランドアーキテクチャとの違いについて問われました。 結論から言うと、PPRとアイランドアーキテクチャは全く異なるものです。本稿ではPPRとアイランドアーキテクチャの違いについて解説します。 PPR まずはPPRとアイランドアーキテクチャの概要を改めて整理しましょう。 PPRはページをstatic renderingとしつつ、部分的にdynamic renderingにすることが可能なレンダリングモデルです。具体的には、画面をbuild時(もしくはrevalidate後)に静的生成しつつ、リクエスト毎
熟練が必要なUIについて、それがよくない理由と、UIの慣性について
久しぶりに記事を書く。最近マルス端末のUIについてツイートがあった。 この件に関して、UIについてやUXに対して日々やってきている人間は「ダメなUI」という認識の人が多いように思う。一方で、システムの開発者にとってはこれは、その認識でない人間が多いようだ。なので、この辺を私なりに意見を書いておこうと思う。 まぁ、これはいつもなのだが、書いていることが散らかってる。基本的に音声入力のメモなので、読みにくいかもしれないが読んでくれ参考になれば幸いだ。 熟練が必要なUIは基本的によくない まず、基本的に熟練が必要なUIはそもそも良くないって話をしていく。順番に話していこう、まず、熟練が必要なUIが支持される理由を考え、それに対して、批判していき、なぜ熟練が必要なUIはダメかを語ってみよう。 熟練が必要なUIが支持される理由 その前に、こういった熟練のUIが支持される理由についてかいておこう。それ
プログラマ視点での生成AIとの付き合い方
プログラミングについて、最近考えてることについてのポエム。 基本的に、 GPT-4 と Claude-3-Opus を使った経験を念頭に置いて話をする。機械学習エンジニアではないので、あくまで利用者に徹した視点での話。仕事で生成AIを使ったパイプラインを作ったりはしている。 生成AIの進化速度を予測しておく 今大事なことは、今AIがどの程度の性能かという定点の話ではなく、その進化の速度を認識すること。 コード生成というタスクにおいて、生成AIモデルを人間に当てはめると、こんな感じの人物像を自分は持っている。 GPT-4: プログラミング経験2年目の大学2年生 Claude-3-Opus: プログラミング経験3年目の大学3年生 ここでいうn年目は、業務経験ではなく、プログラミングの単位がある大学での、教育課程としての経験年数。今のひたすら学習量を増やす方式だと、単に1年に1年分ぐらい賢くなっ
『みんなで小さく区切ってやる』ガイド｜kawanotron
『みんなで小さく区切ってやる』とは『みんなで小さく区切ってやる』は複雑な問題を解決するためにみんな（チーム）で一緒になって改善していくためのやり方です。 『みんなで小さく区切ってやる』で大事な考え方は『経験から学ぶ』と『ちょっとずつ進める』です。小さく区切ることで、ちょっとやってみて、それから学び、またちょっとやってみる。それを繰り返しながら進みます。 『みんなで小さく区切ってやる』を上手にするには『見える化』『チェック』『改善』の3つが重要です。これにより『経験から学ぶ』効果を高めます。 機会を作る『見える化』『チェック』『改善』を取り入れるために5つの機会を設けましょう。これらの機会は毎回同じ時間に行うことでリズムが生まれいい感じになります。 『区切り』があることで立ち止まれます。立ち止まることで落ち着いて『チェック』し『改善』することができます。この『区切り』は1週間もしくは2週間に
エラーや非同期処理をより安全に扱うための TypeScript ライブラリ Effect-TS
TypeScript の型システムを活用して、本番のアプリケーションにおける実用的な問題を解決することを目指しています。Effect-TS は、以下のような特徴を備えています。 並行性（concurrency）：Fiber ベースの並行モデルにより、高いスケーラビリティと低レイテンシを実現 コンポーザビリティ（composability）：小さく再利用可能なパーツを組み合わせることで、メンテナンス性、可読性、柔軟性の高いソフトウェアを構築する リソースの安全な管理（resource-safety）：処理が失敗したとしても、安全にリソースを開放する 型安全性（type-safety）：TypeScript の型システムを活用した型推論と型安全性に焦点を当てている エラー処理（error handling）：構造化された信頼性の高い方法でエラーを処理する 非同期性（asynchronicity
請求関連テーブルのスキーマ変更をした話 - Feedforce Developer Blog
以前に アプリケーションを停止させずにRDBのスキーマ変更する話 を書きました。 developer.feedforce.jp 今日は、その実践編というか、実例として EC Booster というサービスで請求関連テーブルのスキーマを変更した話をしようと思います。 はじまりのテーブル 元々、 EC Booster の請求を管理するテーブルは、このような形でした。 create_table "monthly_charges", id: :uuid, default: -> { "gen_random_uuid()" }, force: :cascade do |t| t.uuid "shop_id", null: false t.integer "year", null: false t.integer "month", null: false t.datetime "created_at"
はじめてのプロジェクトマネジメントでやりたい放題した結果
株式会社プラハは2022年、株式会社アガルートによるM&Aで子会社となりました。 この変化の一環として、アガルート社長自らがプロダクトオーナーのひとりとして参加する新規プロダクト開発が始まりました。プロダクトの開発はプラハの私たちが担当し、私も「開発チームのリーダー」としてそのチームに加わることになりました。 私はこれまで開発メンバーとしての経験しかありませんでしたが、エクストリームプログラミングとかレガシーコードからの脱却とかめっちゃ好きで、本で学んだプラクティスをリーダーとして実践できる機会が与えられて最高にハッピーでした。しかも、プロダクトオーナーの一人として参加するアガルート社長はこれまで伝統的な開発手法しか経験したことがないとのことで、新たな開発の進め方を経験してもらう絶好の機会でもありました。 やったこと 「欲しい機能一覧」を受け取ったが、いったん白紙に戻した プロジェクトが始
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Go1.21から導入された Go Toolchainの仕組みをまるっと解説
日本人プログラマー向けコーディングフォント「Bizin Gothic」が無償公開／「Ricty」でもお馴染みの「Inconsolata」と読みやすい「BIZ UDゴシック」をかけ合わせ
Magic UI
Cosenseの哲学 - 橋本商会
