プロダクトマネージャーという仕事はビジネス・デザイン・エンジニアすべてのスキルが求められる総合格闘技のような仕事です。その分、やることも多く忙しくなりがち。 しかし、再現性の高いプロセスというのは仕事が変わってもそのまま活用できます。その代表例がフレームワークです。 今回は世の中に数あるフレームワークのうち、プロダクトマネージャー・事業開発者が絶対知っておいた方が良いと判断したものを厳選してみました。 プロダクトマネージャー向けフレームワーク4選1. Product Prioritization Frameworkhttps://www.product-frameworks.com/Gusto-Product-Prioritization.htmlこちらはもうプロダクトマネージャーであれば無意識に考えていてほしいくらいシンプル、かつ大事なフレームワークです。 expected：期待値の大き

ウィスキー、シガー、パイプをこよなく愛する大栗です。 先程のアップデートで CloudFront の IP アドレスが Managed Prefix List でサポートされました。これにより CloudFront を経由しない不正なアクセスを簡単に弾くことが可能になります。CMS など CloudFront を使う機会が多いサービスではぜひご利用ください。また CloudFront で AWS WAF を使ってセキュリティを向上している場合の迂回路を塞ぐことができます。 Amazon CloudFront now supports a managed prefix list CloudFront を経由しないアクセス 今まで AWS で CloudFront を経由したアクセスだけ強制させる場合は、CloudFront ではカスタムヘッダを付与して、その値を ALB や Web サーバで

Amazon Web Services ブログ AWS Amplify 入門ハンズオンを公開しました！ – AWS Hands-on for Beginners Update こんにちは！テクニカルソリューションアーキテクトの瀬高(@stktky)です。最近は気温の低い日が続き、布団が恋しく寝起きが悪くなるような日が多いのですが、起きる際にアラームではなくスマートウォッチの振動機能を試したところ、相性が良かったのかスムーズに起きられることが判明しました。加えて周囲の人を起こさなくて済む、睡眠データも取れる、ということでこのあたりに課題感のある方、ぜひお試しください。 さて、AWS Hands-on for Beginners シリーズの新コンテンツとして、 AWS Amplify 入門ハンズオンを追加しました。このハンズオンでは、 AWS を用いたアプリケーション開発を加速させるサービスで

ここでは主導する方が知っておくべきものをまとめています。 なおこの記事での 1on1 とは、バスケのハーフコートにおける 1 対 1 の攻防ではなく、職場における 1 対 1 の定期的な話し合いのことです。 1on1 で話すべきこと 業務以外の課題解決 なにか課題を抱えていると他のどの話題にも身が入らないため、まず話せる環境を作りましょう。同様に課題は業務効率を落とします。 ここでの課題は次を指しています。 健康上の課題 業務が原因で病院受診が難しい場合の業務量の調整など お互いの健康テクニックの共有なども Good 家族との課題 お子さんが夜泣きで寝不足などの場合は就業時間の調整など 親族と折り合いが悪いなどの場合、第三者としての意見や、自分の経験を共有する 社会上の課題 コロナ禍によるつらみの共有など 業務に連動するわけではないため、前回課題がなかったからといって今回もないと仮定しては

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

Red Hatの須江です。 本記事は赤帽エンジニアAdvent Calendar 2018の6日目です。 (子供の寝かしつけで一緒に寝落ちして日付が変わってしまいましたが12/6分です。。。) Debeziumとは? DebeziumはDBに対するデータ操作をキャプチャしてイベントストリームに変換してくれる分散プラットフォームです。Apache Kafkaをベースに実装されており、Kafka Connectベースのコネクタを利用してDBをモニターすることができます。 既存DBに対するデータ操作をKafkaのメッセージに変換することができますので、レガシーシステムなどでアプリケーションに手を入れたくないけどデータだけ抜き出してリアルタイム処理したいとか、別システムにデータを流用したいという場合に便利なソフトウェアです。 また、イベントログはKafkaが保持してくれているので、データを利用する

Reactで開発をしていく上でみなさんがいつかお世話になるだろうと思った記事たちです。 （僕はお世話になりました。これからもお世話になります。） これも良かったよっていう記事があればコメントで教えてください！ 🌟 = 特におすすめ Reactを最初から学ぶ・入門 React Docs BETA 🌟 りあクト！ TypeScriptで始めるつらくないReact開発 第4版【① 言語・環境編】 - くるみ割り書房 ft. React - BOOTH 🌟 Reactハンズオンラーニング 第2版 ―Webアプリケーション開発のベストプラクティス RailsエンジニアのためのNext.js入門 - hokaccha memo React Glossary + Explain Like I'm Five 🌟 React Server Components 総まとめ Reactのレンダリングに関

WebページやUIコンポーネントのレイアウトの崩れ、おかしな挙動にあらかじめ対応しておくためのCSSのテクニックを紹介します。 FlexboxやCSS Gridによるレイアウトの崩れ、テキストが長いコンテンツ、固定の幅・固定の高さによるレイアウトの崩れ、子アイテムが増えすぎたり減りすぎたりで崩れたりなど、起こりがちな問題を解決する実践的なテクニックが満載です。 Defensive CSS by Ahmad Shadeed 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに Flexboxでの折り返し スペースの確保 テキストが長いコンテンツ 画像の伸縮を防止する スクロールが連鎖するのを回避 CSS変数のフォールバック 固定の幅・固定の高さによるレイアウトの崩れ 忘れがちな背景の繰り返し 垂直のメディアクエリ justif

こんにちは。スターフェスティバル株式会社の ikkitang です。 さて、皆様 GitHub Actions 使ってますか？ 弊社では大半のプロジェクトで GitHub Actions が活用されていて、 月 1 回の WinSession で知見が共有されたりしています。 GitHub Actions の素敵な所はイベントの柔軟さだと感じています。それによって GUI での操作が想起できて、直感的にイベントをフックさせて Workflow を作っていくことができます。とはいえ、Workflow が増えてくると別の Workflow をコピペで持ってきて必要な Step を書き換えるなんてことをすることがないでしょうか。 そこで、今回は Workflow の保守性を上げるために Step の共通化について調べてみました。 ちなみに今回説明にあたって GitHub にサンプルを用意してみま

gzip圧縮だとあまり圧縮できていなく、スライディングウィンドウが小さいせいかなと思ったのですが、実際に大きさがかなり違うみたいなので、それが原因としてありえそうです。 Gzip uses a fixed size, 32KB window, and Brotli can use any window size from 1KB to 16MB, in powers of 2 (minus 16 bytes). This means that the Brotli window can be up to 512 times larger window than the deflate window. Results of experimenting with Brotli for dynamic web content - The Cloudflare Blog AudioContextの

2022年に注目しておきたいCSSの新機能を紹介します。いくつかの機能はすでに1つ以上のブラウザでサポートされており、他のブラウザもそれに続く予定です。 ビューポートではなく親コンテナに応じてスタイルを定義できる「コンテナクエリ」、詳細度とスタイルの順序を明示できる「カスケードレイヤー」、相対色構文が追加された「カラー関数」、Safariの100vhを解決する新しいビューポート単位「svh」など、今すぐにでも使用したい機能ばかりです。 Photo by Jr Korpa on Unsplash CSS in 2022 by Bramus 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに 注目の新機能（クロスブラウザでサポート） まだ先の新機能（実験的/シングルブラウザでサポート） 停滞している新機能 Safariは「新し

どうも、まさとらん（@0310lan）です！ 今回は、フロントエンド開発者およびこれから学習をしようと考えている人に最適な無料リソースを厳選してご紹介します。 学習コンテンツばかりでなく、開発に便利なサービスやツールなども紹介しつつ、初心者から中級者くらいまで役に立つドキュメントもまとめています。すべて無料なのでWeb開発にご興味ある方はぜひ参考にしてみてください！ ■何を学習したらいいのかをロードマップで確認する 【 Developer Roadmaps 】 フロントエンドの学習といっても意外に広範囲なので、まずは何から勉強をすればいいのか迷う人も少なくありません。この「Developer Roadmaps」はWeb開発者が勉強するための学習内容をロードマップとして無償公開しています。 さまざまな種類が用意されていますが、例えばフロントエンドの場合は以下のような感じです。 有名なロードマ

この投稿では、「TypeScriptの文法や用語がよく分からない」という問題を解消してくれそうなツールを紹介します。 勉強しながらの見切り発車 最近はTypeScript未経験でも、TypeScript案件にアサインされることが増えてきているように思います。 運がいいと着手前にTypeScriptをじっくり学習する時間を与えられることがあります。しかし、多くのケースでは、見切り発車で開発に参加するのではないでしょうか。 コードリーディングから始まる TypeScript案件は、理解すべき既存のTypeScript/JavaScriptコードがあるケースが多いです。 そのため、 読んで理解すべき既存のTypeScriptコードがある しかし、TypeScriptの知識が乏しい状態でスタート といった事態がよく起きます。 新規プロジェクトでは既存コードがありませんが、ググって出てきたサンプルコ

新人育成用に自分が知っている知識を棚卸するための記事です。なお、解釈が誤っている可能性は十分にあります。 キーワード ポートアンドアダプター ヘキサゴナルアーキテクチャ ミュータブル/イミュータブル 腐敗防止層 ポートアンドアダプター(ヘキサゴナルアーキテクチャ)とは 私がアーキテクチャで意識しているのは、次の点です。 アプリケーションの「内側」と「外側」の区別をつける 「外側」の知識を「内側」に侵入させない 「内側」の知識を「外側」に流出させない アプリケーションの「内側」と「外側」の区別をつける 私は「内側」「外側」を次の定義で表現しています。 内側 アプリケーションのビジネスロジック 外側 アプリケーションで完結できない、実行時例外が発生しやすいロジック HTTPを受信するController、DBと接続するRepository、他システムとRESTやSOAPで連携、ファイル操作 こ

これまでいろんな現場でWebフロントエンド開発をしてきて、メンテナンスしやすく効率の高いWebフロントエンド開発をする上で重要になる考えが自分なりにまとまってきたので記事にしてみます。 Worse is Betterという考え方 自分が見てきた中でWebフロントエンドの開発効率が落ちてしまう一番の要因は、きれいで理論的には優れているアーキテクチャを構築しようとしてそれ自体がもたらす複雑性を支えきれないというパターンです。 少し前にフロントエンドにClean Architecture（以下CA、あの同心円の図を指すのは誤用に近いですがここではそれに乗ります）を導入する記事が流行ったと思いますがあんな感じです。ああいったクラスベースでDIが重要となる設計手法はサーバーサイドのJavaでSpringを使うのとは違ってReactがサポートしているものではないため、CAの実現自体に高い設計スキルが必

技術本部 データ戦略部 Newsグループの木田です。 最近、初めて自作キーボードに挑戦しました。ちょうど２枚目のモニターも買ったので、モニター２台と自作キーボードで快適に記事を書いています。 予めお断りしておきますが、この記事は元々、社内向けに設計方針や規約・ツールなどについて共有するために書いたものでした。最近、他チームの参考資料として役立ったこともあり、社外向けに手を加えて公開する運びとなりました。 はじめに 機構改革・人事異動情報(β) とは ⚛️ Atomic Design に従う ⚛️ Atomic Design とは ⚛️ Molecules と Organisms の分け方 ⚛️ コンポーネントの設計方法 📝 規約 📝 Component と Container を分ける 📝 データの繋ぎ込みは Organisms 以上で行う 💡 Tips 💡 Atoms はタグ本

上の画像に意味はありません、なんか強そうだからはりました。 さて、こういうエントリを普段私は書かないっぽいのだが、なんか書かないとすべて忘れるので書くことにする。 今年は振り返ってみると夏頃までは「コロナだしなあ」といって引きこもりつつ、受託開発や有償OSS活動をし、カートにハマるなど晴運雨読、悠々自適な生活をし、 夏が終わる頃、某現場に入ったあたりから色々スラッシングが始まり、ハチャメチャにLoad Aveが上がり、ダイエットの結果体重が20kg落ちる。という感じだった。 なにか「買ってよかったもの！」とか書けば良いのだろうが、全部をそれでうまくまとまる気分でもないので乱文のママとする。 なお、以下は嘘である。 サポートの重要さを改めて知る 今年は色々なものを買ったり、修理したりなんだりしたのだが、とにかくサポートというものは重要だなと思った。そしてそれを支えるロジがしっかりしている必要

判断と決断の話の違いはこのツイートの通り。 判断の話で言うとぼくはそーだいさんがしてくれた「判断と決断は違う」という話がだいぶ実になっていて、「情報を集めれば理屈で答えが出せるのが判断、今は情報を集めることができない中で答えを出さないといけないのが決断、リーダーがやらなければならないのは決断」という話をかなり大事にしている— しんぺいくんさん (@shinpei0213) 2021年12月10日 決断のコツ 結論から言えば、決断のコツは失敗できるようにすることだ。 失敗できる状態なら決断することができる。 そして素早くアクションして、失敗のフィードバックを受け取ることで新しい決断をすることができる。 そーだいさんがぼくに教えてくれた二大大事なこと「判断と決断は違う」と「ロールバック可能なことはどんどん試せばいい、ロールバックが難しいことは慎重に」です— しんぺいくんさん (@shinpei