「子どもの声は騒音ではない」。政府は法律で定めることも視野に検討に入りました。騒音の苦情で廃止された公園もある中、社会の意識は変わるのでしょうか。赤ちゃんを抱えて、総理官邸入りする女性。政府の「こど…

「プロジェクトマネジメントの基本が全部わかる本」を買ったら、注文ミスして2冊頼んでしまったんだけど、結果的にはむしろ2冊買ってよかった、という話を書きます。 「プロジェクトマネジメントの基本が全部わかる本」 （ @paradisemaker 著）が届いたー。 なんか注文ミスって2冊届いたけど、1冊は誰かに読ませるとき用にしようw pic.twitter.com/evnrXtssm8 — フジイユウジ (@fujii_yuji) 2022年11月10日 制作/開発をするメンバーはいるけどプロジェクトマネジメントは得意ではなくて雑になってしまっているという制作/開発会社も多いと思うのですが、僕もそういう会社からどうしたらいいのか相談されたり、PMの育成の話をすることがあります。 (肩書としてPMだったことはないんだけど、僕も20年くらいPdM的な仕事をやってるんで相談されることがそれなりにある

はじめに こんにちは、株式会社 Flatt Security セキュリティエンジニアのぴざきゃっと (@pizzacat83) です。 認証機構を自作せずに導入できる Firebase Authentication は様々なアプリケーションにて利用されていますが、その特性を十分に理解せずに導入すると、実は不具合や脆弱性が生じることがあります。そこで本稿では Firebase Authentication を利用するうえで、注意しなければ不具合や脆弱性に繋がりうる 7 個の「落とし穴」について解説します。 はじめに IDaaS の利点と欠点 落とし穴 1. 自己サインアップ リスク 対策 不十分な対策 落とし穴 2. ユーザーが自身を削除できる 対策 落とし穴 3. 他人のメールアドレスを用いたユーザー登録 リスク リスク 3-1. メールアドレス誤入力によるユーザー乗っ取り リスク 3-2

ちむ子👶4y@おうち英語 @chimwo_chimko コッソリ言わせてください…。 Twitterワーママ界で神扱いされているホットクックをいまいち使いこなせてないんですけど、カレーとかスープ以外に何作ったらいいんでしょうか…。皆さんのヘビロテホットクックメニュー教えてください…🙇‍♀️🙇‍♀️🙇‍♀️ 2022-04-11 22:22:21

今日、内定承諾書にサインした。 9月1日から新しい会社で働くことになるのだけど、転職活動、マジできつかった。エージェント経由の応募では、書類選考で落ちまくった。たぶん30社くらい落ちた気がする。もっとかな。書類で落ちまくっていた数週間はネガティブ思考に陥り「今のキャリアを維持することは諦めたほうがいいのかも」と思いつめていた。 結果として「行きたいな〜」と思った会社へリファラル（中の人から紹介してもらって面接に進む）でお話が進み、これを逃すかと全力で取り組んでいたらトントン拍子で入社が決まった。 でも、今回の転職がなんとかなったのは、30代のうちに種を蒔いておいたことがポツポツとつながったからだなという感じがしたし、実際そうだと思う。 わたしの周りには30代の友人が多く、将来ミドル世代で転職することに不安を感じている人もいるだろうと思うので、率直に備忘します。 40代での転職活動、甘く見て

Alexander Mielke Hellinger--Kantorovich (a.k.a. Wasserstein-Fisher-Rao) Spaces and Gradient Flows

1988年神奈川県生まれ。普通の会社員です。運だけで何とか生きてきました。好きな言葉は「半熟卵はトッピングしますか？」です。もちろんトッピングします。（動画インタビュー） 前の記事：ラーメンを食べるとちょっとやせる ①外でオフィスチェアを使うと眠たそうに見える 外でシャーと移動する前に、果たして屋内でやることを屋外でやったらどう見えるのか。よく首で電話を抑えて仕事をする人をみかける。それをやってみたい。 電話がかかってきたな。 「ちょっと待ってください。今、調べますので」 あれ？ 寝ちゃった？ 日差しのせいか、目を閉じたせいか、寝ているように見える。決して忙しそうに見えない。仕事がいやすぎてふて寝した人だ。こういうことじゃない。 次へ行くぜ。 ②イスに座りながら飲み物を買うとすぐに落ち着いて飲める 何かをやりながら別のことをしている人を見ると忙しそうだなと思う。たまに会社で電話をしながらコ

2018年の初めくらいから、仕事でGraphQL APIを何度も作っている。サーバーサイドもクライアントサイドも実装している。 最近クライアント側にRelayを使ってみている。 GraphQLのクライアントとしてはApolloを使う場合が多いと思うが、Facebook製のRelayもかなりよくできている。以前はTypeScriptに対応していなかったが、今はTypeScriptも使える。最近のバージョンではhooksのAPIがexperimentalではなくなり、ReactのSuspense API（Suspense for Data Fetchingは使わずに）と合わせて使える。 RelayはGraphQLのスキーマに制約を設けることで、クライアント側のAPIがデータの再取得やページネーションなどを抽象化している。換言すると、Relayからデータの再取得やページネーションに必要なスキーマ

こんにちは！LayerXの mosa_siru (榎本) です。 LayerX インボイスでは、もともと github.com/go-swagger/go-swagger を利用してREST APIを開発していましたが、最近開発したワークフロー機能 のコンポーネントではGraphQLを取り入れました。 GraphQLには様々なメリットがあり、RESTとの比較記事は多くありますが、なぜ僕らは移行したのか、その結果どうなったのかを紹介していきます。 GraphQLのメリット GraphQLのメリットは、様々な箇所で語られています。例えばこの記事によれば、 強力に型付けされたスキーマであること アンダーフェッチとオーバーフェッチがないこと（後述） Apollo, Relayなどの、クライアントライブラリにより、フロントエンド開発が迅速になること 複数のGraphQL APIからの統合が可能 強力

Arjhun777 Posted on Jan 2, 2021 • Updated on Jan 11, 2021 • Originally published at arjhun777.blogspot.com To create a video chatting and screen sharing application requires three major setup Basic React setup for handling UI. Needs Backend (Nodejs) for maintaining socket connection. Needs a peer server to maintain create peer-to-peer connection and to maintain it. 1) React basic setup with join b

「Firebase は安いし楽だしマジ最高」という一心で技術選定してしまったプロダクトが成功して見えてきた課題、割高なコスト・権限管理・カスタマイズ性、そして （特性やスキルセット的に）RDB 製品が適していたのに無理やり Firestore を採用したことによるデータ不整合。 その結果チーム内で Firebase を抜ける機運が高まるも、Firebase べっとりなアプリケーションすぎて移行しづらいといった問題に出会うかもしれません。 そのような場合に備え、Firebase の存在を隠蔽して開発することに挑戦してみましょう。 注意: Firebase を剥がしているときに「俺、次は絶対そうするわ」と感じたものを書いているだけであり、まだ実際にはこのパターンでプロダクション導入していません。 あくまで個人開発で試してみていけそうと思ったので、提案しますという体です。 また Firebase

2020年6月26日18:00より開催された Firebase Realtime Meetup に参加したので参加レポートを書きました。 勉強会自体のアーカイブ動画 は以下に掲載されています。 https://www.youtube.com/watch?v=4iS8EySYU14 FJUGの紹介 @k2wanko スライド: - 動画開始位置： https://youtu.be/4iS8EySYU14?t=5 内容メモ： Firebase Japan User Groupの活動内容・Slackの紹介 FJUG Appの紹介・テスター募集 Firebase Japan User Groupの活動紹介と、@k2wankoさんが個人で開発中のFJUG Appの紹介でした。 Firebase Japan User GroupのSlackは私も度々参考にさせてもらっています。日本でFirebaseを

こんにちは, Mackerel 開発チーム アプリケーションエンジニアの id:susisu です. 現在 Mackerel では, Web コンソール画面の開発に使用しているフレームワークを, これまで使用してきた AngularJS から React へ移行することを中心とした, フロントエンド開発の刷新プロジェクトを行っています. このプロジェクトの立ち上げについては以前 Hatena Engineer Seminar で発表しましたが, そこでは時間の都合もあり, 技術的側面についてはあまり深く掘り下げることは出来ませんでした. ということでこの記事では, より技術的な面にフォーカスしてプロジェクトの内容をご紹介できればと思います. "React化" プロジェクトについて Mackerel の開発は 2014 年ごろから始まりましたが, フロントエンドのフレームワークとしては当初か

vivit株式会社でフロントエンドエンジニアをしている関です。 新型コロナウイルス感染症(COVID-19)への対策として発出された緊急事態宣言の影響で、弊社も2ヶ月ほどリモートワークとなり、私も駆け足で自宅に作業環境を構築しました。買っちゃいましたL字デスク。 さて、弊社ではいくつかのプロダクトのフロントエンドに React(Next.js) + TypeScript を採用しており、バックエンドとの通信には GraphQL(Apollo) を採用しています。 今回はその中で、コンポーネント分割をする際の GraphQL Query の定義と取得したデータの受け渡しについて話をします。 ここからは GitHub GraphQL API v4 を使って説明していきます。 developer.github.com アジェンダ pages から components へのデータの受け渡し方法に

今回は、何故ＣＤＮを使う必要があるのか、ＣＤＮ の　仕組み や技術的なことをなるべく分かりやすく解説したいと思います。 ＷＥＢ高速化、負荷分散、オンデマンド・ライブ動画配信、コンテンツ配信、ということを検討もしくはこれから始めようとしている方は、ＣＤＮというキーワードを一度ぐらいは聞いたことがあると思います。CDNってどんな仕組みでどのようなことが出来るかご存じですか？　まずはCDNの簡単な歴史から。 ＣＤＮの歴史ＣＤＮ（コンテンツデリバリーネットワーク）というのは、大手Ａｋａｍａｉさんが１９９０年代に提唱したといわれているコンテンツを配信するためのネットワークのことです。実は、最近できた技術や仕組みではありません。 インターネットが流行りだした時代からありました。 しかし、近年では90年代当初から比べると様々な仕組みや技術が取り入れられた次世代CDNに進化しています。 ＣＤＮとは？CDN

去年の12月まで1年数ヶ月お世話になった業務委託先を離任して、1月から休暇を取っていました。 5月から新しい案件に入ったので今はまたお仕事の日々です。 さて、4ヶ月も休暇を取った理由は、毎回案件が終わる度に休暇を取っているというのもあるのですが、学習や趣味の活動でやりたいことが多すぎて、一度がっつり時間を取ってそちらに全力投球したいと思ったというのがありました。 1月の時点ではどのくらい休暇を取るのかは決めていなかったのですが、最低でも3ヶ月、案件のタイミングによっては半年くらい休暇をとってもいいと思っていました。 結果的には4ヶ月丸々休暇を取った感じになりました。 休暇中にやりたかったこと kirimin.hatenablog.com 以前こういうエントリを書きました。 内容を要約すると30歳になる2020年の9月までに ソフトウェアエンジニアとしてCSや数学の知識をもっと高めて、And

実サービスで GraphQL API をインターネットに公開する際は、悪意あるクエリに対する防衛が欠かせません。この記事における「悪意あるクエリ」とはサービスに意図的に負荷をかけるクエリのことです。GraphQL では 、木構造や再帰的な構造を利用して、一回のクエリで容易に数百万・数千万件のデータを取得することができます。そのようなクエリを実行してしまうと、アプリケーションサーバーや、その後ろにいる別のサービスに甚大な負荷がかかります。これは攻撃者からしてみれば恰好の的で、なんらか対策を講じる必要があります。 幸いこうした問題はよく知られており、クエリを静的に解析するライブラリがいくつか存在します。しかし、そうしたライブラリをどう使うかといったことはあまり議論されておらず、効果的な対策を行うのは依然として難しい状況だと感じます。この記事では、典型的な負荷の高いクエリとその具体的な対策を紹介

SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜JavaScriptRailsJWT認証React SPAのログイン周りについて、「これがベストプラクティスだ！」という情報があまり見当たらないので、様々な可能性を模索してみました。 いろいろな状況が想定され、今回記載する内容に考慮の漏れや不備などがありましたら是非コメントでご指摘いただきたいです！特に「おすすめ度：○」と記載しているものに対しての批判をどしどしお待ちしております！ この記事でおすすめしているものであっても、ご自身の責任で十分な検討・検証の上で選択されてください。 前提 想定しているAPIは、 ログイン外のAPIにはPOST/PUT/DELETEのものがなく、GETのみ GETのAPIにはDBを更新するなどの操作がない とし、そのためログイン外では