ゲームの勝敗でかんしゃくを起こす子どもにできることは大人げない大人になること｜フィンランドワークショップomena
「ずるい！！ なんで勝てないの！？」 コントローラーを床に投げつけ ソファの上で大暴れしながら 小学１年生の男の子は 目に涙を溜めながらそう言った 私は月に数日 友達の子どものお世話をしている 親の代わりに学童に迎えに行って 親が用意しておいた 夕食を温めて食べさせる その後は一緒に遊びながら 友人が帰ってくるのを待っている 最初はおもちゃや トランプで遊んでいたが 最近はニンテンドースイッチの マリオパーティーという ゲームにハマっている その家にはゲームはあるものの その子はほとんど遊んだことがないと言う 私の友人は元々 ゲームはあまりやらないし 友人のパートナーつまり 子どもの父親がゲーム好きだが 「すぐに怒るから一緒にゲームはしない」 と子どもに言っていたそうだ そこへやってきた ゲームOKの大人に 彼は毎回 「ご飯食べたらゲームしよう！」と 目を輝かせているのだ。 最初の頃は 彼
ブルシットプロダクトからチームを守れ! ｢顧客が本当に必要だったもの｣を追求するプロダクトマネジメントを実現するぞ
ユーザーから見て、ただひどいだけでなく、開発したり販売する人たち自身がプロダクトに価値がないと感じており、また買ってもらうことに罪悪感を感じるようなプロダクトやサービスをブルシットプロダクトと呼びましょう。 ブルシットプロダクトとは何か、どのようにして生まれるのか、なにをすれば解消されるのか、顧客…
ユースケースに応じたユニークなIDの生成 - Carpe Diem
概要 ユニークなID生成をしたい場面は多々ありますが、ユニークIDにはユースケースによって以下のような要件が出てきます。 ユニーク 短い（＝データ量が少ない） 推測困難 分散性（ランダム性） 順序性（Lexicographical） 生成速度 それぞれの観点について説明し、最後にGoでオススメの選択肢を提示します。 ユニーク ユニークIDというのでそのまんまではありますが、一番満たさなければいけない要件です。 特に現代におけるサービスでは高トラフィックをさばくためにスケール性を重視し、分散システムであっても衝突しないIDを求められます。 例えばMySQLのようなDBのauto_incrementを使う場合、そのDBがスケールしにくい＆SPoFといった課題があります。 Twitterで開発されたsnowflakeは以下のフォーマットになっており、 ※instance = machine id
シーケンスの代わりにuuidをIDとして使う
stop using numbers as IDs. just use UUIDs. seriously — Postgres: The Bits You Haven’t Found by pvh UUID の違い v1 Generate a UUID from a host ID, sequence number, and the current time. v3 Generate a UUID from the MD5 hash of a namespace UUID and a name. v4 Generate a random UUID v5 Generate a UUID from the SHA-1 hash of a namespace UUID and a name. この内、ID として利用できるのは v1 と v4 の2つ。v1 は最後 48 ビットがハード固有のノー
PostgreSQL DDL文でtable,view等を作成する | ITSakura
※シノニムはありません。 データベースの一覧 \l psqlのコマンドでは、円マークとエルでデータベースの一覧が表示されます。 SELECT * FROM pg_database; 上記SQLでも取得できます。 データベースを作成 CREATE DATABASE test1; CREATE DATABASEの後にデータベース名を指定します。 データベースを削除 DROP DATABASE test1; DROP DATABASEの後にデータベース名を指定します。 テーブルの一覧 ¥dt psqlのコマンドでは、円マークとdtでテーブルの一覧が表示されます。 select * from pg_tables where schemaname not in('pg_catalog','information_schema') 上記SQLでも取得できます。 テーブルを作成 CREATE TABLE
git で --diff-filter に D 以外指定して削除されたファイルを除外する | mersy note
納品用の差分データをまとめていて、なんかエラーでうまくできないなぁということがあり。 gitで差分ファイルを抽出してzipにまとめる方法 - HAM MEDIA MEMO https://h2ham.net/git-diff-fil… （そもそも差分データまとめるとかではなくGitからデータを取ってもらえるといいのだけど） とりあえず、出てるエラーはこんな感じで fatal: pathspec 'hogehoge/fugafuga.gif' did not match any files そのファイルはみつからないってことで $ git archive --format=zip --prefix=archive/ HEAD `git diff --name-only --diff-filter=d [commit] HEAD` -o archive.zip みたいに —diff-filte
Retrying HTTP Requests
Network Working Group M. Nottingham Internet-Draft February 1, 2017 Intended status: Informational Expires: August 5, 2017 Retrying HTTP Requests draft-nottingham-httpbis-retry-01 Abstract HTTP allows requests to be automatically retried under certain circumstances. This draft explores how this is implemented, requirements for similar functionality from other parts of the stack, and potential futu
mswとgraphql codegenでGraphQLをモックし、効果的で効率的なReactのテストを書く
はじめに：テスト戦略の話 そもそもフロントエンドのテストって何をどんな粒度で書けばいいの？という疑問はよくあると思います。これについては以前Qiitaの記事: フロントエンドでTDDを実践する（理論編）で書いているので詳細は省きますが、Testing Trophyの戦略に則り、integration testを中心とし、unitテストは本当に有効なものに絞って書くというのがフロントエンドにおいては有効です。 APIモック フロントエンドのintegration testにおいて課題になるのがAPIのモックです。urqlやapollo clientのようなGraphql Clientでもqueryをモックする仕組みはありますが、どちらもclient自体をモックするような書き方になります。一見問題ないようですが、client側でキャッシュの挙動を制御したりできることもあり、本番コードと異なるコ
mswjs/data で広がるテスト戦略
本稿は MSW（Mock Service Worker）エコシステムのうちの一つ mswjs/data を試してみた記事です。記事中のサンプルコードは以下で公開しています。 mswjs/data とは 仮想 DB をブラウザ（インメモリ）に展開する、データモデリング・リレーションライブラリです。MSW 単体ではハードコードされたフィクスチャのみの定義となりますが、mswjs/data を併用することで、データ駆動型 API モックを作成することが可能になります。使い始めは簡単で、以下の様にスキーマを定義しfactory関数で DB インスタンスを生成します。 import { factory, primaryKey } from '@mswjs/data' const db = factory({ user: { id: primaryKey(String), firstName: Str
SansanのR&D、すごいらしいよ。｜nishiba
ざっくりまとめると話を聞いてみたい人(学生・社会人問わず)は気軽にMeetyでカジュアル面談しましょう！ 半年前(2021年7月)に入社するまで、「SansanのR&Dって名刺のOCRをしている組織でしょ？」と思っていたのですが、色々とやるべきこととやれることがたくさんあり、非常に面白いフェーズです。「それ、早く言ってよ〜」と思いました(元ネタの動画を見てください) 自己紹介SansanでR&Dの部長をしています。経歴は、メガバンク → 大手医療系IT企業 → 現職のSansanといった感じです。これまで、クオンツ、MLエンジニア、エンジニアリングマネジャー、採用人事、プロダクトマネジャー、事業責任者などを経験し、今は組織マネジメントに専念しています。 参考記事です。
useRefでステートを管理するのはReact18でアンチパターンになるからやめよう - Qiita
こんにちは。最近、Reactでのステート管理において「useStateの中にステートを置くのではなく、useRefで得たrefオブジェクトの中にステートを置いてuseState（またはuseReducer）をコンポーネントの再レンダリングを発生させるためだけに使う」というやり方を複数の記事で見かけました。このパターンは、今（React 17以前）は動くけどReact 18でアンチパターンに変貌するやり方なので、啓蒙するためにこの記事を用意しました。 ステート（コンポーネントのレンダリングに使用される値）は、useRefではなくuseState（またはuseReducer）をちゃんと使って管理するようにすれば、React 18以降も安泰です。 useRefをステート管理に使うパターンとは こういうやつです。 // 普通のやり方 const Counter1: React.VFC = () =
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Tutorial gomock
テスト自動化研究会 - テスト自動化の8原則
A Complete Guide to UUIDs in Postgres
日付/時刻データ型
Improving Nonparametric Classification via Local Radial Regression with an Application to Stock Prediction
Structure and Interpretation of Computer Programs