フィーチャーフラグの標準規格 OpenFeature の React SDK を試してみる 2024.08.31 OpenFeature はフィーチャーフラグのオープンな規格です。特定のベンダーに依存しない API や SDK が提供されています。フィーチャーフラグの API の標準化により、ベンダーロックインを回避し、フィーチャーフラグのツールを自由に選択できるようになります。この記事では OpenFeature の React SDK を使ってフィーチャーフラグを評価する方法を紹介します。

「街づくり」はとても複雑なものです。 そこに住む住民はもちろん、商いを営んでいる人、デベロッパー、行政……などさまざまな主体による活動の上に成り立っています。各々の活動はお互いに何らかの影響を与え、結果的にまちという姿で現れます。そう考えると、それらの主体が街づくりを意識することから、本当の街づくりがはじまるのではないでしょうか。 漫画－近年、日本が世界から最も注目を浴びる文化。背景にあるまちの緻密で繊細、圧倒的な描き込みと描写力が、作品の大きな魅力である現実と空想が混在する世界観をつくっている漫画家panpanyaさんに『足摺り水族館』という作品ではじめて出会い、注目していました。 panpanyaさんはまちの断片を継ぎ接ぎしたような世界を巡る漫画を多く描いています。商業デビューから10年、「見たことがないのにどこか懐かしい」と感じられる架空のまちを描いてきたpanpanyaさんの作品は

サービスの開発をしていてPMから施策案が出てきた時、ソフトウェアエンジニアとして施策案が本当にユーザーのためになりサービスの成長につながるか納得できないことがある。 このような時にただ文句や愚痴を言っても何も始まらない。エンジニアからも何らかのアクションを起こし施策を前に進める必要がある。 そこでエンジニアができるアクションについて、自分が思っていることを書いてみる。 納得できないケースは大まかにどのようなものがあるか 納得できないケースでは大まかに2つのケースがあるのかなと思っている。 (1) 施策をしたい目的や仮説自体に納得できていない (2) 施策の目的や仮説は良いが、それを達成する手段に納得できていない 1つ目は、たとえば「ターゲットとしているようなユーザーって本当にいるか？」「ユーザーにこういう課題があると言っているが本当にそういう課題があるか？」「この指標に繋がると言っているが

私の職場のADHDのAさん（私の後輩）が辞めてから職場が明るくなった。 スムーズに仕事が回るようになって、みんなイライラしなくなった。 なぜ私がAさんがADHDかということを知ってるのかというと、Aさんが飲み会で突然カミングアウトしたからだ。 Aさん「実は自分、ADHDで…」 静まる周り。 Aさん「あ〜、一般人の方は知らないですよね。ADHDというのは…」 その後AさんはADHDについてとても詳細に説明してくれた。 しかしその場の人の反応がイマイチだったのADHDについて知らなかったからではなく、他の人が話している最中に話し始めたからという理由が大きいことに気づいていないだろう。 みんな先ほどの話が気になっていたはず。少なくとも私はそうだった。 Aさんのカミングアウトを受けて私は正直そうだろうなと思った。思い当たるフシしかなかった。 Aさんはとんでもなく視野が狭く、ありえないほどミスが多く

2024年7月8日月曜12時、ポッドキャストラジオ番組「エンジニアの楽園vim-jpラジオ」がAuDee（TOKYO FM）公式番組として配信開始されました。 ほかにも以下のプラットフォームから配信されていて、毎週月曜更新となっています。 Apple Podcast Spotify Amazon Music まだお聞きになっていない方は、冒頭から圧倒的なクオリティを感じられますので、騙されたと思ってぜひ一度だけでもお聞きになってみてください。 今回は、こちらのラジオ番組を作った経緯や、どのようにして作ったのかを記録しておきます。 構想5年、実働2ヶ月半で配信開始 # きっかけは、vim-jpでつぶやいたこちらの一言でした。 何気なくつぶやいた「そういえば、vim-jp ラジオ立ち上げたい」という、この発言をきっかけにして、パーソナリティとしてありすえさんが手を上げてくださり、ほかにもたくさ

こんにちは。yebis0942です。GoとTypeScriptを書いています。夏祭りのおみくじで「待ち人来る」を引いたので、最近のちょっとした待ち事例についてご紹介します。 Goでタイムアウト時間を指定する関数を呼び出したとき、待機時間を0秒にすると何が起きるのか？という点が社内のレビューで少し話題になりました。 気になって調べてみたところ、同じ0秒のタイムアウト処理でも、内部の実装によって振る舞いが異なるケースがあることが分かりました。 よく見るタイムアウト処理 Go言語では、一定時間だけあるchannelを待つというタイムアウト処理は以下のように time.After() を使って書くことができます。 func timeAfter(c chan int, duration time.Duration) { select { case <-time.After(duration): //

Slides and videos explaining a functional approach to error handling This page contains links to the slides and code from my talk “Railway Oriented Programming”. Here’s the blurb for the talk: Many examples in functional programming assume that you are always on the “happy path”. But to create a robust real world application you must deal with validation, logging, network and service errors, and o

Web 技術解体新書 第一章 Origin 解体新書 Same Origin Policy とは Web において非常に重要なセキュリティモデルの 1 つだ fetch や XHR でリクエストを送信したときに、 CORS 違反で失敗したり、 Preflight という謎のリクエストが送信されたりして悩んだ経験があるかもしれない。これらは全て、ユーザを保護するために設けられた Same Origin Policy という制限を、ブラウザが遵守した結果なのだ。 本書はこの重要な Origin という概念について、そもそもなぜそんなものが必要なのかという背景や、それがユーザを保護するメカニズム、 JSONP はなぜ危険なのか、 Preflight が飛ぶ理由、 Service Worker など新しい API との連携、 Spectre によって発覚した脆弱性と CORP,COOP,COEP,

技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 今回発表された研究では、技術的負債を抱えたレガシーコードのリファクタリングで取り除かれた問題の90％以上が、メソッド名と実際の関数の動作が一致していない、あるいは関数名とコメントが矛盾しているなどの「命名的問題」、もしくは複雑で読みにくい多数の条件分岐や深いネストなどを抱えた「構造的問題」のいずれかであるという先行研究があることを踏まえ、どちらを優先してリファクタリングすると保守性や可読性が高くなるかを調査しています。 具体的には、命

はじめに ファーストクラスコレクションの出典を知らなかったので、調べて、結果とメリデメをまとめました。サンプルコードはGoで書いています。 ファーストクラスコレクションの定義 ファーストクラスコレクションとは、ThoughtWorksアンソロジーで登場するデザインパターンです。以下のように定義されています。 プログラミング言語で提供されているリストやマップなどのコレクションをプリミティブと見なして、それをラップしたクラスをファーストクラスコレクションと呼んでいる そして、次のように書かれています。 コレクションを持つクラスには、他のメンバ変数を持たせないようにしてください。各コレクションをそれぞれ独自のクラスにラップすることで、コレクションに関する振る舞いをそのクラスに置くことができるようになります。 注意してほしいことですが、ファーストクラスコレクションでは、配列やコレクションをイミュー

ソフトウェアエンジニアは、どのように事業に貢献すべきか？ 宿泊施設やレストランの予約サービスを提供する株式会社一休で執行役員CTOを務める伊藤直也さんは、2016年に入社しておよそ2年間、心の奥に抱えた悩みを解消できないまま仕事をしてきました。 伊藤さんは、2000年代から複数のWeb系テックカンパニーで技術部門のリーダーとして活躍し、現在でも利用される個人向けWebサービスのローンチをいくつか手掛けています。一休には入社以前からフリーランスで技術顧問を務めており、会社がヤフーグループ（当時）に入って経営陣が一新されるタイミングで、代表取締役CEOとなった榊淳さんの要請を受けて入社しました。 当時は全て.NETだったというサービス基盤の刷新や技術的負債の解消、開発組織の整備といったエンジニアリングにおいて重要な改善を進めてきましたが、あるとき自身が「事業に貢献していない」ことを明確に意識す

Introduction​ This guide should help you to make sure you are following our best practices and writing tests that are more resilient. Testing philosophy​ Test user-visible behavior​ Automated tests should verify that the application code works for the end users, and avoid relying on implementation details such as things which users will not typically use, see, or even know about such as the name o

7月にEMをやめたのだけれど、実は最近マネジメントロールに戻った。 1on1などで自分や組織の至らないところについてメンバーから率直なフィードバックをもらうことが多く、そのたびに本当にありがたいと思っている。ちなみに最近もらってよかったフィードバックは、「ハレーションを恐れすぎ」です。 メンバーからのフィードバックは受け手のスタンスや振る舞い次第で何も言ってもらえなくなったり信用をなくしたりすることもあるので、「メンバーからのフィードバックに向き合うとはどういうことか」を雑にまとめておきたい。 フィードバックをもらうまで フィードバックを受け付けていることを伝える 言いにくい話も多いので、スタンスを明確に伝えておかないとフィードバックはもらえない 予定が詰まっていると遠慮されてしまうので「予定は調整するのでいつでも声をかけてほしい」と伝えるとか 意見を持ってそうな人には直接声をかけるのもよ

先達エンジニアに学ぶ 思考の現在地 Online Conference https://findy.connpass.com/event/313119/

2024年4月25日紙版発売 2024年4月25日電子版発売 市原創，板倉広明　著 A5判／456ページ 定価3,740円（本体3,400円＋税10%） ISBN 978-4-297-14178-3 Gihyo Direct Amazon 楽天ブックス 丸善ジュンク堂書店 ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo honto 本書のサポートページサンプルファイルのダウンロードや正誤表など この本の概要 SSL/TLSは，通信の秘密を守るために利用されている通信プロトコルです。HTTPSやHTTP/3にも利用されており，今日のWebでは利用が一般的になっています。本書では，その最新バージョンであるTLS 1.3のしくみと，その使い方を解説します。SSL/TLSは公開されている実装例などを真似すれば基本的

はじめに 開発生産性をテーマとした技術イベントに出まくった結果、ある程度体系化された知識のおすそわけ記事です。 この記事を読めばわかること 開発生産性のトピックでよく語られている前提の部分 開発生産性を語るうえで大事なざっくりとした体系的な知識 開発生産性を測るためによく使われるメトリクス 雑に言えば、数字とってデータ駆動でPDCA回そうという話です。 この記事を読んだ後に、「開発生産性の議論 ﾅﾝﾓﾜｶﾗﾝ ...。」という人でも「まずはこの辺調べてみよう」ができる状態になればいいなと思って書いてます。 この記事を読んでもわからないこと 開発生産性の文脈におけるビジネスサイドとのコミュニケーションらへん 開発生産性の文脈における経営層とのコミュニケーションらへん 目次 開発生産性についての前提 開発生産性と言うクソデカワードの認識をそろえる 開発生産性には３つのレベルがあることを知る な

意思決定の場にいない人に対して決定事項を共有する際、いくつか気をつけておくといいなぁと考えていたことを雑にまとめておきたい。 決定する前から進捗をちょっとずつ共有しておく 決定前の話なので後の祭りかもしれないが、いきなり結果をドーンだと相手を戸惑わせることがあるので事前に議事録を共有したり中間で説明する機会を作ったりするとよい 背景と前提条件を伝える なぜやるのかわからないまま結果だけ共有すると納得してもらいにくい。決定する上での前提条件を知らないと余計な反発をうむこともあるので注意が必要。それまでずっと考えてきた当事者は気づきにくいが、びっくりするくらい前提知識が違うことがある。相手は何も知らないものとして、イチから説明した方がよい 決定までの経緯を伝える 結論より経緯の伝え方が重要。どのような議論があってそんな決定になったか、完結に伝えましょう 捨ててきた選択肢も伝える 結果に至るまで