タグ

fushimatsuのブックマーク (3,822)

  • ウェブサイト制作では、游ゴシックはおすすめしない理由

    ウェブサイト制作では、游ゴシックはおすすめしない理由こんにちは、こんばんは!せきゆおう です。 游ゴシックは好きですか?僕も印刷物では使いますが、ウェブサイトでは「游ゴシックを使ってください」と指示されるまでは使いません。 また、そう指示された場合もデメリットは必ずお伝えするようにしています。 「游ゴシックってMacでもWindowsでも標準でインストールされているし、デバイスフォントとして使う際に最有力候補では?」という方も多いです。それでも僕は推奨しません。 その理由は4つあります。 ・游ゴシックはWindowsでかすれて見える ・スマホ端末に游ゴシックは搭載されていない ・実はMacOSで游ゴシックは標準では搭載されていない ・今後、システムフォントとして使えないブラウザが増える それら4つの理由を参考資料を交えつつ解説したいと思います。 その前に...游ゴシックの採用率は非常に高い

    ウェブサイト制作では、游ゴシックはおすすめしない理由
  • RDBの主キー、UUID使った方がいいの?(DDD, CleanArchitecture対応)

    結論 お手軽モノリスならAutoIncrementが効率的だしこれでいいよ アプリケーション側で主キーを生成したい場合はLUIDを作る必要があるよ。GUIDで大は小を兼ねよう 主キーでGUIDを使うならULIDよりもUUIDv7がおすすめだよ ただし分散されているエンジンによってはUUIDv4の方が効率的になる場合もあるよ 主キーは原則公開しない方がいいよ UUIDv7やULIDはユニーク性を持ったInstant(timestamp)としても使えるよ 分散されたシステムでは厳密な時系列性を担保することはできないよ、あきらめてロックをかけつつ連番を一か所で生成しよう RDBのPrimary Key(主キー)とは? MySQL、PostgresQLなどのRDBでは各レコードを識別するために一意な値を必要とします。これをPrimary Key(主キー)と呼びます。別のカラムにUNIQUEなInd

    RDBの主キー、UUID使った方がいいの?(DDD, CleanArchitecture対応)
  • デジタル署名と(デジタル)証明書の関係

    angel (as ㌵㌤の) @angel_p_57 @AGAINST_sa9sa9 先にデジタル署名からおさらいです。 が、その前にまず「暗号化」「復号」という用語は忘れてください。 暗号技術の一部としてまとめられていますが、「暗号化」「復号」とは機能が全然異なる技術なので、混同すると誤解の元です。 2021-11-15 20:10:26 angel (as ㌵㌤の) @angel_p_57 @AGAINST_sa9sa9 デジタル署名は「特定の人だけが作れて、誰でも物と確認できるデータ『署名』」を実現する技術です。 作る(署名する)時に必要なデータを署名鍵 or 秘密鍵、確認する(検証する)時に必要なデータを検証鍵 or 公開鍵と呼びます。 2021-11-15 20:10:51 angel (as ㌵㌤の) @angel_p_57 @AGAINST_sa9sa9 繰り返します

    デジタル署名と(デジタル)証明書の関係
  • 存在するはなぜ二階の述語なのか|ミック

    拙著『達人に学ぶ SQL徹底指南書』の中で、EXISTS述語の使い方を解説している章があるのだが、そこでEXISTS述語だけが唯一SQLの中で二階の述語である、ということを説明している。これはEXISTS述語だけが行の集合を引数にとる述語だからである。それは分かるのだが、なぜ述語論理を考えた人(具体的にはゴットロープ・フレーゲ。タイトル画像のおじさんである)はこんな着想を得たのか、そこが分かりにくいという質問をしばしば受けることがある。確かに、数ある述語の中でなぜ「存在する」だけが二階の述語であるのか、というは直観的にすこし分かりにくい。なぜフレーゲはこんなことを考えたのだろう? この点について、述語論理の創始者でもあるフレーゲの議論を参照しながらかみ砕いて見ていきたいと思う。かなり理論的かつ哲学的な話になるので、興味ない方は読み飛ばしてもらってかまわない。とくにSQLの理解に支障のある話

    存在するはなぜ二階の述語なのか|ミック
  • データベースでユニークキーにUUIDを使うメリットは何ですか?連番やタイムスタンプまたは複合などではいけないのでしょうか?どうも視認性が悪く使いにくく感じますし連番でも衝突しない気もします。

    回答 (7件中の1件目) まずはUUID及びその対案として用いられる連番(自動採番)のメリット・デメリットを整理します。 (タイムスタンプキーや複合キーなどもその効率性から設計上有用なシーンはありますが、比較から除外します。) * UUIDを使うことのメリット * * データベースにSQLを送信する前からアプリケーションレイヤーでIDを生成できる。 * * トランザクション処理を実装しやすい場合がある。 * IDを推測しにくい。リソースが列挙可能ではない。 * UUIDを使うことのデメリット * * レコード・インデックスサイズが増加する。 * * ...

    データベースでユニークキーにUUIDを使うメリットは何ですか?連番やタイムスタンプまたは複合などではいけないのでしょうか?どうも視認性が悪く使いにくく感じますし連番でも衝突しない気もします。
  • ジャック・ドーシーがBlueskyを辞めた理由をもうちょい詳しくエスパーする|KingYoSun

    インタビュー記事はこちら https://www.piratewires.com/p/interview-with-jack-dorsey-mike-solana GIGAZINEBlueskyのかなり初期から分散SNSを追っていて他のメディアより比較的コンテキストがわかっていると思いますが、今回は是非元になったインタビュー記事を読んでほしいです。SNSと言論の自由、検閲について興味があるなら特に 私とBlueskyそれでお前は誰やねんって話なので、ちょっと自己紹介します 多分bsky.appの日人だと一番古いか、三番目くらいに古いユーザーで、多分世界初のBlueskyのサードパーティサーバー(PDS)のboobee.blueを運営しています。 その時の記事はこれ https://note.com/kingyosun/n/n45d3b1ff89bf 上の記事のときは「プロトコルはマジで

    ジャック・ドーシーがBlueskyを辞めた理由をもうちょい詳しくエスパーする|KingYoSun
  • WebAssembly所感

    WebAssemblyをちょっといじってみて思ったところをまとめてみます。 設計思想 WebAssembly/designに設計文書がまとまっています。特にHighLevelGoals.mdから読み取れるポイントは以下の4点です。 サンドボックス化された環境であること。 移植性があること。つまり、特定の実CPUアーキテクチャ等に依存しないこと。 少なくともC/C++の(十分に高速な)コンパイルターゲットとして機能すること。 安定した仕様を持つこと。 サンドボックスという観点からは、先行技術として以下のようなものが特筆に値します。 Webサンドボックス JavaScript および asm.js Javaアプレット Flash (ActionScript) NaCl, PNaCl Web以外のサンドボックス OSのユーザーランド、特にLinux userland これらのサンドボックスとの比

    WebAssembly所感
  • OSS 観光名所を貼るスレ - ぽ靴な缶

    これは はてなエンジニアアドベントカレンダー2023 2日目の記事です。 はてなエンジニア Advent Calendar 2023 - Hatena Developer Blog はてなエンジニアのカレンダー | Advent Calendar 2023 - Qiita トップバッターは緊張するけど、順番が回ってくるまで長い間ソワソワするのも嫌、という理由で例年2日目を狙うようにしている id:pokutuna です。今年も成功しました。 観光名所とは 目を閉じれば思い出す、あのコード... あの Issue... あなたが Web 系のエンジニアであれ、趣味で開発している方であれ、必要に応じてライブラリやフレームワークのコードを読むのはよくあることでしょう。公開の場で開発されているソフトウェアは、ソースコードだけでなく、開発コミュニティでの議論やバグ報告なども見ることができます。 リポ

    OSS 観光名所を貼るスレ - ぽ靴な缶
  • 見よ、これがHonoのRPCだ

    僕が開発しているWebフレームワークHonoは、同じJavaScriptのフレームワーク、Expressと比べられることが多いです。どちらもやれることはほぼ同じですが、HonoのアドバンテージはファーストクラスでTypeScriptをサポートしていることです。特に「RPC」機能は他のフレームワークにはなかった「TypeScriptの型でサーバーとクライアントの仕様を共有する」ことを可能にしています。今回はそのHonoのRPCについて紹介します。 どんなものか まず、どんなものかを箇条書きで共有します。 Web APIの仕様、特にインプット・アウトプットをサーバーとクライアント間で共有するためのもの OpenAPIgRPCを使ってやりたかったことを叶えるかもしれない サーバーとクライアントをどちらもTypeScriptで書くことが大前提である 同種のものにtRPCがあるが、Honoの場合、

    見よ、これがHonoのRPCだ
  • 【特集】 電源の仕組みはこうだ!理解できれば良し悪しも分かる。これで目指せ電源マイスター

    【特集】 電源の仕組みはこうだ!理解できれば良し悪しも分かる。これで目指せ電源マイスター
  • Referrer-Policy の制限を強めると安全になるという誤解 | blog.jxck.io

    Intro Referrer-Policy は、送信される Referer の値を制御することが可能だ。 このヘッダの副次的な効果をよく理解していないと、「no-referrer にして送らないのが最も安全だ」という誤解を生むことになる。 では、複数あるポリシーの中でどのような観点で、どのディレクティブを採用するのが良いのだろうか? 前提として前回の記事の「リクエストの出自をチェックすることは現代の実装のベースプラクティスである」という点を踏まえて考えてみる。 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io https://blog.jxck.io/entries/2024-04-26/csrf.html Referer とアナリティクス Referer は、リクエストに対してその前のページの URL を送るところから始まった。 GET / H

    Referrer-Policy の制限を強めると安全になるという誤解 | blog.jxck.io
  • えっ!?まだ色の指定でrgba()関数を使っているの!? – TAKLOG

    最近次のようなポストをしましたが、主に不透明度を伴う色の指定に現在でもrgba()関数を使用している方が多い印象です。 ポストを別枠で表示する 今年に投稿されているCSS技術記事でもrgba()関数を使用したサンプルコードが散見されますが、現在rgba()関数はレガシーな指定とされています。 rgba()関数使っている人、全員時代に取り残されています過去のCSSでは色を指定する方法の一つとしてrgba()関数が使用されてきました。この関数はRGB値とアルファ値(不透明度)を組み合わせて色を表現するために用いられます。

    えっ!?まだ色の指定でrgba()関数を使っているの!? – TAKLOG
  • SQLは滅ぶべきか|ミック

    でかい釣り針が来たので釣られてみる。とりあえず以下の資料を読んでいただきたい。そんなに長くないのでサクッと読める。 SQLの記述順序と思考の順序が違うので書きにくいし、エディタの補完機能の恩恵が受けられないのが嫌だ、という意見はもう大昔からある。何度も何度も何度も繰り返されてきた議論である。以下の2011年のスレッドでも「SQLはFROM句が最初に来るべきではないか?」という問いが提起されている。すぐに出てこないが、筆者はこれより古い文書も見た記憶がある。

    SQLは滅ぶべきか|ミック
  • なぜ管理職は罰ゲームなのか。 - Qiita

    はじめに タイトルでお察しかと思いますが、今回は「罰ゲーム化する管理職」の著者である小林祐児さんがPIVOTのYoutubeチャンネルに出演されており、そちらの内容が非常に素晴らしかったので、管理職の課題や対策について、記事にまとめたいと思います。 また、途中で出す資料はパーソル総合研究所の中間管理職の就業負担に関する定量調査からお借りしています。 中間管理職の課題 部下育成が不十分、後継者不足 働き方改革が進んでいるもの、現在の管理職は人手不足・ダイバーシティ・ハラスメント対応・人手不足などによって業務量が増加。 管理職人の負担が増えている他、部下育成と後任者の不在という課題も抱えている。 昨今の働き方改革やハラスメント対応などにより、管理職の業務量は増加傾向にあります。 小林さんに言わせれば、「働き方改革は一般層の働き方改革」であって、それによって管理職の首を絞めていると。 業務量増

    なぜ管理職は罰ゲームなのか。 - Qiita
  • https://www.reddit.com/r/rust/comments/pjri4c/module_source_filenames_srcfoors_srcfoofoors_or/

  • 【Rust】健全なmacro_rules!にはパスに曖昧さが無い

    Rustの宣言的マクロ(macro_rules!)は、Cのマクロに比べて健全なマクロ(hygienic macros 衛生的なマクロとも訳される)が書きやすいようにできています。macro_rules!では、Rustの文法に違反するようなマクロは記述できないようになっています。しかし、コンパイルできたマクロ=健全なマクロかというと、そのような保証はありません。そこで、「健全なマクロ」にするためにどのような点に気をつければよいか?という記事です。ちなみに、この記事では宣言的マクロに限定して書いていますが、手続き的マクロ(proc_macro)でも同様です。 ※この記事のRustのバージョンは1.70.0です。 要約 クレート内の識別子のパスは$crate::(Crate Rootを指す)から始める。 クレート外の識別子のパスは、マクロを公開しない場合は::(Extern Preludeを指す

    【Rust】健全なmacro_rules!にはパスに曖昧さが無い
  • はじめに - Rustで独自のスライス型を定義する本

    Rust でプログラムを書くうえで、用途や制約に応じた適切な型の定義は大変重要である。 たとえば Rust ではバイト列は [u8]、 UTF-8 文字列は str、OS ネイティブのエンコーディングの文字列は std::ffi::OsStr、パス文字列は std::path::Path といったように、横着すればひとつの型で済むような様々なデータに対してそれぞれの特徴に応じた型を標準で用意している。 ときに標準ライブラリで用意された型ばかりでなく、自分で専用の型を用意したいこともある。 たとえば「相対パスのみを保持できる型」のようなものを実装したくなるかもしれない。 もちろん Rust でこれは可能なのだが、 str のような (値として利用するときは &str のように参照を使う) 可変長のスライスのような型は、定義したり十分な利便性を確保するのに多少のコツが必要となる。 書では、独

  • 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io

    Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、当にプラットフォームに足りていなかったものと、それを補っていった経緯、当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp

    令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
  • 不用意に font-feature-settings を使うと日本語表示がおかしくなる - 果樹園

    CSSでOpenTypeフォントの機能を制御できるようになった結果、欧文ページで font-feature-settings: "dlig"; が指定してあると、日語に機械翻訳して読もうとした時に合字になって欲しくないところまで合字になってしまう。 「〜になります。」が「〜になり〼。」になる。— りんご🍏夜明けのリモートワーカー (@mstssk) April 17, 2024 日は晴天なり <div style="font-feature-settings: 'nalt';"> 日は晴天なり </div> 環境にインストールされているフォント次第だと思うので、手元のスクショも。 ※mac上のChrome。 記事を書いたきっかけのツイート https://twitter.com/yodare_inu_/status/1780431031218343978 参考 font-featu

    不用意に font-feature-settings を使うと日本語表示がおかしくなる - 果樹園
  • さようなら、全てのエヴァーノート - 本しゃぶり

    2011年6月10日、Evernoteを使用開始。 2014年9月19日、有料プランに加入。 2024年3月23日、クソみたいなメールが届く。 プラン、廃止 いつも Evernote をご利用いただき、ありがとうございます。このたびは今後の Evernote 登録プランに関する変更についてご案内させていただきます。 お使いの Evernote アカウントは Plus から Personal に移行されました。Evernote Plus など、一般のお客様に数年間ご利用いただけなかった従来の登録プランが廃止となったためです。この変更により、Personal プランで利用可能な機能すべてをご利用いただけます。 今後はAnnualの登録プランが現在の Evernote Personal プランの料金 129.99 USD/Yearに合うように更新されます。この料金は次の更新日である2024/4/

    さようなら、全てのエヴァーノート - 本しゃぶり