フィーチャーフラグの標準規格 OpenFeature の React SDK を試してみるフィーチャーフラグの標準規格 OpenFeature の React SDK を試してみる 2024.08.31 OpenFeature はフィーチャーフラグのオープンな規格です。特定のベンダーに依存しない API や SDK が提供されています。フィーチャーフラグの API の標準化により、ベンダーロックインを回避し、フィーチャーフラグのツールを自由に選択できるようになります。この記事では OpenFeature の React SDK を使ってフィーチャーフラグを評価する方法を紹介します。
コードレビュー開発者ガイド
コードレビュー開発者ガイド はじめに コードレビューとは、コードの作成者以外の人がコードを調べるプロセスです。 Google ではコードとプロダクトの品質を維持するためにコードレビューを実施しています。 このドキュメントは Google のコードレビューのプロセスとポリシーに関する正規の解説です。 このページでは私達のコードレビュープロセスを概観します。このガイドはさらに二つのドキュメントに分けられます。 コードレビューの仕方: コードレビュアーのための詳細なガイド CL 作成者のガイド: CL をレビューしてもらう開発者のための詳細なガイド コードレビュアーはどんな観点でレビューすべきか？ コードレビューは次の観点で見るべきです。 設計: コードはうまく設計され、そのシステムにとって適切か？ 機能性: コードは作成者の意図通りに動作するか？ユーザーにとってコードの挙動は適切か？ 複雑さ:
二大企業大激突Ⅱ！！ スクウェアvs任天堂 前編｜初心カイ
0．はじめに 日本の国産二大RPG、といえば「ドラゴンクエスト」と「ファイナルファンタジー」であることに異論がある人は少ないだろう。これは両方ともスクウェア・エニックス社のIPであるが、スクウェア・エニックス社は元々スクウェアとエニックスの二社が合併してできたものだ（若い人はピンとこないかもしれない）。 ファイナルファンタジーはスクウェア社側のIPであったが、元々任天堂のファミリーコンピュータ（以下ファミコン）で誕生し、育ったIPだった。任天堂とスクウェアは初めのうちこそ蜜月といって良かったのだが、そこから関係をこじらせ、一時は出禁状態であったことが有名だ。 本記事はスクウェアがどのように歴史を紡ぎ、任天堂と近づき、そして破綻させ、そして再度関係を修復させたかを解説するものである。 1．誕生 スクウェア まず、スクウェアの創業から解説しよう。徳島県に株式会社電友社という、電気工事会社があっ
やらないと後悔するUdemy８選 - Qiita
はじめに みなさんは何か新しいスキルを得るときにどのように学習するでしょうか？ 私はプログラミングコーチングJISOUで多くのジュニアエンジニアとカウンセリングをする中で8割以上の人がUdemyで学習すると言っていることに気づきました。 そこで今回は私がいままでやってきた35個の講座の中でこれはやってよかったと今でも思えるものを紹介していきます。Udemyはその人が学習している技術や興味のある技術でないと参考にはしづらいと思いますが、おすすめを学習することは時間の観点でものすごい価値があると考えているので参考にしてみてください！ Udemyの怖いところ Udemyはとても恐ろしいサービスです 以前にも以下の記事を投稿して話題になりました。 ぜひ読んでほしいのですが、ざっくり解説すると 「Udemyは1本終わらせるのに数十時間単位で時間を使うので、その使い方を間違えると時間の損失が大きい」
いまどきの分析設計パターン10選
JJUG CCC 2024 Spring 複雑な業務ロジックに立ち向かうための実践技法 【初級編】 ①値の種類 ②範囲型 ③階段型 【中級編】 ④状態遷移 ⑤入出金履歴と残高 ⑥未来在庫 【上級編】 ⑦セット演算 ⑧割合と端数 ⑨決定表 ⑩経路探索
網羅的なPRDやDesign Docを書かなくなった - kosui
2024/06/12 16:16 結論を追記 2024/06/12 20:29 より記事の内容を分かりやすく理解頂くため、タイトルを「PRDやDesign Docを書かなくなった」から変更 2024/06/13 20:39 結論にフロー情報・ストック情報に関する意見を追記 結論 この記事では、「様々な観点を考慮して網羅的にドキュメントを書いて、それを関係者にレビューしてもらう」のではなく、関係者と同期的に対話しながら、観点や選択肢やそのトレードオフを洗い出すことで、少ない手数でより良い答えが見つけられると主張する。 ただし、対話のために必要なドキュメントは事前に書いておくべきだし、対話した結果はドキュメントに残すことが望ましい。そして、そのドキュメントのフォーマットはPRDやDesign Doc以外でも良い。例えば、ADRはアーキテクチャに関する議論の過程と結果を述べる上で必要十分なフォー
大公開！バッチアプリケーションの品質を高めるZOZOの『バッチ開発ガイドライン』 - ZOZO TECH BLOG
こんにちは。MA部の田島です。 弊社では開発ガイドラインというものを用いて、システムの品質を担保しています。今回私がテックリードを務めているということもあり、バッチアプリケーションを開発するためのガイドラインを作成しました。本記事では「開発ガイドライン」と「バッチ開発ガイドライン」を紹介します。 バッチアプリケーション開発に限定したTipsはまとまっているものが多くないため参考にしていただければと思います。 開発ガイドラインについての紹介 冒頭でも紹介した通り弊社では、開発ガイドラインというものを用いてシステムの品質を担保しています。バッチ開発ガイドラインを紹介する前に、まず開発ガイドラインを紹介します。 開発ガイドラインの種類 開発ガイドラインは現在、以下の種類が存在します。 共通 Android iOS Frontend Backend Infra API Batch DB(Datab
Git不慣れ勢を束ねて安全なチーム開発をするメモ - Qiita
本稿は当初チーム開発時のメンバー向けにまとめたものです。 ある程度、端折っていた背景などを記載しました。 git初心者同士でのチーム開発において、git操作を詳しく知らないメンバーも含め安全に行う必要がありました。しかし、開発期間はごくわずか...この状況を回避するために、下記の対応をとりました。 Gitコマンドの基礎的な内容を理解する（私） 各種操作をGUI上で完結させる拡張機能を色々と導入する シンプルな開発フロー(Github flow)を採用し、コマンド実行に相当する操作を限定する 各操作をGUI上での操作に置き換え、チームメンバーに教える 本稿はその際の、コマンドやGUI操作に関するメモをまとめたものになります。 こういった取り組みのおかげか、チームの開発をすんなりフローに乗せることができました。 ■ 前提条件 対象とする動き Github flowを回すうえで、 cloneする
グロブ - Wikipedia
グロブ（英: glob）とは主にUnix系環境において、ワイルドカードでファイル名のセットを指定するパターンのことである。例えば、UNIXのコマンド「mv *.xlsx 営業実績/」はカレントディレクトリから営業実績/ディレクトリへと.xlsxで終わる全てのファイルを移動する。ここで、*は「任意の文字列」を表すワイルドカードであり、*.xlsxはグロブである。*以外に一般的なワイルドカードは疑問符 (?) であり、これは任意の1文字を表す。 UNIXの初期バージョン（1969年の「1st」版から1975年の「6th」版まで）におけるコマンドインタプリタでは、コマンドへの引用符で囲まれていない引数内に含まれるワイルドカードの展開は、インタプリタとは独立した /etc/glob というプログラムに依存していた[1]。このプログラムが展開を行い、実行するコマンドへ展開されたファイルパスリストを提
坂口博信 FF7をNINTENDO64ではなくPlayStationで出した理由を語る
坂口博信さんが2024年1月29日放送のJ-WAVE『ゆう坊とマシリトのkosokoso放送局』に出演。ファイナルファンタジー7をNINTENDO64ではなくPlayStationでリリースすることを決めた理由について話していました。 （鳥嶋和彦）でも、スクウェアはやっぱり大きな分岐点だったよね。そっちのPSの方に踏み込んだあたりから。 （松野泰己）業界全体が大きかったんじゃないですか。 （鳥嶋和彦）うん。流れが変わったからね。 （松野泰己）申し訳ないと思ってるんですけど。 （鳥嶋和彦）そうか。あの時、PSか、NINTENDO64か。 （坂口博信）結局、CD-ROMか、ロムカートリッジかなんですよ。で、CD-ROMじゃないと作れなかったので。CGベースのものが。「任天堂か、ソニーか」じゃないんだよね。開発者からすると。もうどうしようもなかったっていう。 （鳥嶋和彦）選択の余地がなかった。
ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編）
ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編） アジャイル開発の代表的な方法論であるスクラムをテーマに、都内で1月に開催されたイベント「Regional Scrum Gathering Tokyo 2024」で、経験豊富なアジャイル開発のエキスパートとしてウクライナを拠点にアジャイルコンサルタントをしていたドミトロ・ヤーマク（Dmytro Yarmak）氏が、ロシア軍の侵攻後にウクライナ軍に入隊し、中隊長としてリーダーシップを発揮するためにさまざまなメソッドを駆使して軍隊の組織を変革していった経験を語ったセッション「A True Story of Agile Coaching in Ukrainian Armed Forces」が行われました。 軍隊という、企業とは異なる構造や目的を備えた組織で、しかも多くの民間人が入
ソフトウェアに関わる人が知っておくといいかもしれない法則10個
「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション）」という興味深いポストをX（旧Twitter）で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション） コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物
0063 号 巻頭言
DDD を理解したいあなたのための DDD 入門以前 Rubyist Magazine 63 号をお届けする。 突然のお知らせで恐縮だが、日本 Ruby の会の主たる事務所が東京から北海道に移転した。それもあってあまりまとまった時間がとれず、11 月のうちに書くはずだったのが気がつくと 12 月も半ばを過ぎていたので、今回は以前書きかけていた文章を発掘してお茶を濁したい。 Ruby とは直接関係がなくて恐縮だが、Ruby に限らずソフトウェア開発では現在でもちょくちょく話題になることがある、DDD についての話である。 ドメイン駆動設計こと DDD は 2020 年代のソフトウェア開発でもよく話題にされるが、率直に言うとストレートにポジティブな評価が行われているとは言い難い。 どちらかというと、ある種マニアックで、対象分野が制限されており、また初心者にはとっつきにくいところがある手法と思わ
クリーンアーキテクチャの功罪
クリーンアーキテクチャというと設計における銀の弾丸のように扱われていて、クリーンアーキテクチャを導入するという記事をよく見ます。しかし自分の経験だとクリーンアーキテクチャで書かれているのにもかかわらず開発効率が落ちているという事が多く、いつでも使っておけばいいというものではないと思っています。 最近目にしたクリーンアーキテクチャに対する批判 本筋ではないので詳細は省きますが、あるとき[1][2]にUncle Bobの著書であるCleanシリーズへの批判をXで見ました。 ここで一番載せたかったものが今見つけられないのですが、以下のようなポストがありました。 書籍クリーンアーキテクチャに書いてある内容を抜きにして起こった現象だけを見るとマイナスの方が多い このポストが自分の感じていることを端的に表現できているように感じました。書籍クリーンアーキテクチャの内容を悪いと思いませんが、その影響により
タスクに「〜対応」という名前をつけるのを避けたい理由 - kymmt
先日同僚と雑談的に話してたことを書いておく。ソフトウェア開発のバックログにおける話です。 「〜対応」とは 主に差し込みで入ったタスクやなにか早めに単一の解決したい事象のためのタスクに名付けられやすい名前。 あくまでも例としてだが 「マーケから割引データ表示依頼対応」 「監視アラート対応」 みたいなやつ。「〜対応」というのは日本語としてはかなり便利なので、とりあえずバックログに入れておきたいときに使いがち。 なぜ避けたいか 完了基準があいまいになる タスクを流していく際の問題。 バックログ上のタスクは完了基準を定めておかないと、作業スコープがどんどん広がったり、完了したかどうかを確認する人から見ると完了していないということが作業後にわかったりして不便。「〜対応」という名前をつけるタスクは、そもそもの作業スコープがはっきりしていないことが多く、結果として、作業を始める前に関係者との認識合わせが
課金術
有償ソフトウェアを売る方法分かんなすぎるから、気軽に相談できる人欲しくなってきた...。 ・寄付募集型か、有料で一部の機能を解放する型か ・価格設定 ・有料で一部の機能を解放するなら、どこまで有料にするか ・買い切り型か、月額サブスクリプション型か とかとか、考えること無限にある。。 — Cside (@Cside_) October 2, 2023 個人開発ではないが、課金については仕事で結構やってきてまぁまぁの知見を得た。かつて自分も情報を得ようとネットで探してみたが、極めて情報が少なかった。ソフトウェア開発についてのノウハウは結構ネットに転がってるが、値付けなどについての情報は少ない。エンジニアとマーケッターでは文化が違うのかもしれないが、そもそも値付けに関しては商材（ソフトウェア）によって様々なので定石がなく、結局のところ自分で試してみないと正解がわからないのではないかと思う。そう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コーディングの練習方法 - 備忘録
ChatGPT for Developer - Promptのチカラ
OpenAI がまたやった！OpenAI DevDay 総まとめ｜ChatGPT研究所
ある個人開発者が「安いほうが良いと思ったけどアプリのサブスクの値段を1.5倍にしたら契約率が2.5倍になったはなぜ？」と困惑している
