変更履歴を記録する
Version 1.1.0 # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ### Added - v1.1 Brazilian Portuguese translation. - v1.1 German Translation - v1.1 Spanish translation. - v1.1 Italian
UUID(v4) がぶつかる可能性を考えなくていい理由 - Qiita
お手軽にランダムなIDを取得したい時にUUIDはとても重宝します。 でもたまに、 「このID(UUID)ってぶつかることない？対策しなくて大丈夫？」 と聞かれることがあります。 それに対して、 「ウィキペディア先生がぶつからねえって言ってたから大丈夫だよ！（＃ﾟДﾟ）」 で切り抜けるのもそろそろ限界のような気がするのでちゃんと調べました。 (もちろんウィキペディア先生を頼りました！) 2つの理論 UUIDの衝突確率について考える上で次の2つの理論が重要になります。 鳩の巣原理 誕生日のパラドクス 鳩の巣原理 鳩の巣原理とは、 m個の入れ物にn個のものを入れるとき、n > m ならば少なくとも1個の箱には2個以上のものが入る 9個の巣箱に10羽の鳩が入る場合、必ずどれかの巣箱には2羽以上入ることになるということです！(ウィキペディア先生) 考えれば当たり前のことですが同様にして考えれば、 「
関数型プログラミングと型システムのメンタルモデル
Qiita Conference 2023 Autumun での発表資料です 発表時間の見積もりが下手で後半全然説明できませんでした、すみません！ 実際のプロダクト開発ではどうすればいいのか? というケースは以下のスライドを参照してください。 (本スライドは、こちらのプロダクト開発の経験をベースに基礎を再整理したものになります) https://speakerdeck.com/naoya/typescript-niyoru-graphql-batukuendokai-fa-75b3dab7-90a8-4169-a4dc-d1e7410b9dbd
デバッグが早い人と遅い人の違い
会社にデバッグの早い人と遅い人がいる。 二人を観察していると、色々な違いが見れて勉強になる。 いくつかまとめてみる。 ・デバッグが早い人はコードに着手する前に状況を整理する 期待動作はどのようなものか、現状の動作（バグ）はどんなものか、どんな条件でバグが生じるか、生じないかを整理する 他人からアサインされたタスクの場合、手早くこれらを質問して状況を確認する。 デバッグが遅い人は何も考えずにコードを触り始める。 「何をデバッグしているの？」と聞くと言語化出来ない。 場当たり的、五月雨式に質問する。 ・デバッグが早い人は仮説を持っている。 ざっくりと全体像を把握し、当たりをつけてから作業する。 全ての作業が仮説の検証作業。結果が出た時に次に何をすべきかも把握している。 デバッグが遅い人は自分でも何をやっているか分かっていない。 「よくわからないけど一応2回試してみた」とか言う。 「それは今何を
フロントエンドにおける「単体テストの考え方/使い方」
本稿における「単体テスト」とは自動テストにおける単体テストを指します。手動テストのことではないので、ご了承ください。 単体テストの考え方/使い方という本を読みました。筆者自身、「単体テストはプロダクションコードの付属」という意識がどこかにありました。この本を読んで、単体テストについてあまりに何もわかってなかったことに気付かされ、単体テストの設計はプロダクションコードの設計と同じくらい重要という意識に変わりました。何のために単体テストをやるのか、いいテストとは、「単体」とは、など多くの点で学びを得られ、また、多くのプラクティスとアンチパターンを知ることができました。 本稿はこの本を読んで得られた学びを、フロントエンド開発、特にコンポーネント開発に適用することを試みた際のまとめです。より詳細な解説を求む方には本を手に取ってもらう前提で、できるだけポイントを抑えられるようにまとめることを目指しま
「のどが渇いた」というユーザーに何を出す？ ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
2022年9月13日 株式会社メンバーズ ポップインサイトカンパニーでのウェビナーのスライドです。「ユーザーが欲しいと言った機能をつけたのに使われない！」という経験はありませんか。プロダクトをつくるとき「ユーザーの心理を理解しよう」とよく言われます。しかし、ユーザーに言われたままやることと、ユーザーが本当に望んでいることは異なります。「UXデザイン・UXリサーチ」は、ユーザーを理解するための専門技術です。ユーザーインタビューやユーザビリティテストを用いてファクトを集めることで、ユーザーの表面的な言葉に惑わされない、本当のインサイトにたどりつくことができます。かんたんなワークも交えながら、体系的に解説いたします。Read less
設計の考え方とやり方
#asken_dev「設計の考え方とやり方」勉強会 https://asken.connpass.com/event/254709/ ・良い設計は悪い設計より変更が楽で安全である ・ドメインモデル方式のクラス設計 ・イミュータブル方式のテーブル設計 ・設計スキルの身につけかた ・設計のためのモデリング
カスタマイズをしない
自分の会社ではパッケージ製品、つまりお客様の環境で動かして頂く製品を販売している。 そのため、カスタマイズを希望される事もある。今の機能では簡単に実現するのが難しいというのがほとんどの希望理由だ。 カスタマイズの定義は製品に対して＋アルファの何らかの特別な対応を機能を追加することという事にしておく。 結論から言うと自分の会社では一切のカスタマイズを受けないというスタンスだ。カスタマイズはメリットよりデメリットの方が多いという考え方からだ。 カスタマイズのメリットまちがいなく売り上げを上げやすい事だろう。カスタマイズが必須な場合の顧客はカスタマイズを受け付けない製品を購入しない。 さらにカスタマイズ対応ということで、追加の開発費やサポート費を手にすることができる。これは前職で十分実感できた。 ただメリットはこれしか無い。 カスタマイズのデメリット一番大きいのはコードのフォークが発生してしまう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
レビューの仕方