並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 10 件 / 10件

新着順 人気順

validの検索結果1 - 10 件 / 10件

  • Web API設計時に使われ方の想定を添えると良い。けどより良いやり方を知りたい - valid,invalid

    先日登壇したイベントにて、仕事で協業したモバイルエンジニアから「Web APIのドキュメントに使われ方の想定が添えられていてありがたかった」とフィードバックをもらった。 具体的にはX post (以下、tweet) に添付した画像のような感じで、Web API (以下、API) が呼び出される画面・タイミングの想定、レスポンスの使われ方の想定などをUIのスクショとともに記述する、というもの。 API設計時にこういう使われ方の想定を添えると認識揃えやすくてありがたい、とモバイルエンジニアに喜ばれました#B43_techtalk pic.twitter.com/XLB3g6fCLZ— ohbarye (@ohbarye) 2023年8月3日 他にもこんなのとか。 APIレスポンスの使われ方の想定を書いているようす このことについて思ったよりもイベント内外で反響があったので書く。 ドキュメントの

      Web API設計時に使われ方の想定を添えると良い。けどより良いやり方を知りたい - valid,invalid
    • 『研鑽Rubyプログラミング』を読んだ - valid,invalid

      『研鑽Rubyプログラミング 実践的なコードのための原則とトレードオフ』を読んだ。ちょっとブームに乗り遅れたけどまぁ、本なんていつ読んでもいいものなので気にせず感想を書く。 研鑽Rubyプログラミング 実践的なコードのための原則とトレードオフ 作者:Jeremy Evans,角谷信太郎ラムダノートAmazon 想定読者層はあらかじめ示されているとおり中級〜上級で、Ruby初学者には厳しめ。RubyやRailsでのアプリケーション開発にそこそこ慣れてきた自称中級者が読むと知識の広がり幅が大きくて良さそう*1。 同じようなレベルの層に対してよく推薦される図書として『メタプログラミングRuby』があると思うのだけど、そちらよりは平易かつ実践的な内容が多いと感じた。 具体的にはDSLやプラグイン機構の作り方など、ふだんのWebアプリケーション開発業務でしょっちゅう書くわけじゃないけど、書き方を知っ

        『研鑽Rubyプログラミング』を読んだ - valid,invalid
      • ZodでAlways-Valid Domain Modelを実現する

        課題意識 特定の商品を数量を指定して購入できるECサービスのドメインモデルを表現とします。TypeScriptで構築する際に、「数量」を単にnumber型で扱うことは可能ですが、よりロバストな設計を目指す上で以下の2つの方法論があります。 Refinements(値の制約を表す): 「数量」は一般的に自然数です。1度の注文で指定できる上限を設けるビジネスルールがあると仮定します。この場合、number型に「自然数」「上限付き」の制約を加えた値として表現します。 Branded Types: (同じ構造の型を区別する): 「価格」などの他のnumber型と混同されないように、これらの数値を型レベルで区別したいです。JavaやC#に見られる公称型の概念をTypeScriptで模倣するBranded Typesのテクニックを用いることで、これらの誤った利用を型システムで防ぐことができます。 Br

          ZodでAlways-Valid Domain Modelを実現する
        • :user-valid & :user-invalid擬似クラスが来た! - What's new in Browsers!

          What's new in Browsers!は、サイボウズのフロントエンドエンジニアがブラウザの最新情報から気になるトピックを紹介するシリーズです。 今回はChrome 119の更新内容から気になるトピックとして、:user-valid擬似クラスと:user-invalid擬似クラスを紹介します。 ユーザーの操作後に検証が行えるようになった :user-validと:user-invalidはどちらもフォームなどの入力要素の検証の状態に対してスタイルの指定などが行える疑似クラスになります。 検証の状態とは、例えば<input type="email" required />な要素では入力されていない場合やemailとして許容されない文字列が入力がされている場合はinvalidな状態になり、emailとして許容される文字列が入力されている場合にはvalidな状態となります。 :validと

            :user-valid & :user-invalid擬似クラスが来た! - What's new in Browsers!
          • :user-validと:user-invalid擬似クラス | フロントエンドBlog | ミツエーリンクス

            入力フォームがあるページの設計をする際はフロントエンドでもバリデーションを実装することが多くあります。代表的なバリデーションは例えば以下のようなものです。 必須の入力欄に値が入力されていなければエラーとする メールアドレス入力欄に入力された値がメールアドレス形式でなければエラーとする パスワードとして使用できない文字が入力されればエラーとする 入力内容が不適切な場合は、入力欄に装飾を施すために:validと:invalidの2つの擬似クラスを利用してきました。 :validと:invalidは、主にフォームコントロール要素に関連する擬似クラスで、以下のような基準にしたがって各要素の状態がマッチするかどうかを判定します。 required属性付きの入力欄が空でなければ:valid、空であれば:invalid type属性がemailである入力欄に入力された値がメールアドレス形式であれば:va

              :user-validと:user-invalid擬似クラス | フロントエンドBlog | ミツエーリンクス
            • :user-valid、:user-invalid 擬似クラスでユーザーの操作の後に検証を行う

              :user-valid、:user-invalid 擬似クラスでユーザーの操作の後に検証を行う 2023.10.13 ユーザーの操作の後にフォームの検証に基づき有効か無効かを示すために使用できる :user-valid、:user-invalid 擬似クラスを紹介します。従来の :valid、:invalid 擬似クラスと異なり、ユーザーがフォームに入力するまではスタイルを適用されません。 :user-valid、:user-invalid 擬似クラスは、ユーザーの操作の後フォームの検証に基づき有効か無効かを示すために使用できます。フォームの検証として、以下のような例があげられます。 required 属性を指定した要素に値が入力されているか pattern 属性を指定した要素に指定した正規表現にマッチしているか min や max 属性を指定した要素に指定した範囲内の値が入力されているか

                :user-valid、:user-invalid 擬似クラスでユーザーの操作の後に検証を行う
              • YAPC::Hiroshima 2024に参加してIdempotency-Key Headerの話をしてきた - valid,invalid

                表題の通りYAPC::Hiroshima 2024にスピーカー、およびスポンサー企業の一員として参加してきました。最近はブログ不精となっていてイベントに参加しても記事を執筆せずにいたものの、YAPC参加者のすさまじい熱量にあてられたので久々に筆をとってみます。 自分とYAPCとbuilderscon YAPC初参加です。が、実はYAPCには思うところがありました。 YAPC::Asiaの後継として開催された(ですよね?)buildersconに2017, 2018, 2019と参加しており、このイベントからは過去にめちゃめちゃ感化されていたのでした。特に初参加のbuilderscon 2017に強く影響を受けてから僕は登壇やOSS活動を始めたので、勝手な思い入れがあるカンファレンスです。 「buildersconにもやがて登壇するぞ」と思っていたものの直近の数年は非開催となってしまったので

                  YAPC::Hiroshima 2024に参加してIdempotency-Key Headerの話をしてきた - valid,invalid
                • SmartBank, Inc.に入社して3年経過した - valid,invalid

                  タイトルの通りSmartBank, Inc.に入社して3年が経過したので記念に整理。 SmartBankに入社して3年が経ちました 良い会社です— ohbarye (@ohbarye) 2023年8月4日 ちなみに前回書いたのは1.5年経過のタイミングで、だいぶ遅まきの入社エントリであった。 ohbarye.hatenablog.jp やってきたこと 半年なり1年なりの区切りをトリガーに書いていれば差分を書きやすいのだけど、その習慣がついていないのでやむなく、今回は3年分まとめて書いてしまおう。3年間でやってきたこと*1のうち公にしているものたち*2を並べるとたくさんあるが、もちろんほとんどはチームでやってきたことである。 カード発行会社かつ銀行のようなサービスで、対ユーザー向けの各種機能の開発 出金 / 送金 / 目的別口座 / ペア口座 / 支出管理 サブスクリプションサービスB/43

                    SmartBank, Inc.に入社して3年経過した - valid,invalid
                  • Ractorを用いたproperty based testingの並列実行についてRubyKaigi 2024で発表しました - valid,invalid

                    表題の通りRactorを用いたproperty based testingの並列実行についてRubyKaigi 2024で発表してきました。かつスピーカーとしての参加は初めてで、いろいろ稀有な体験ができて総合的にはめちゃくちゃ楽しかった。 発表内容について "Unlocking Potential of Property Based Testing with Ractor"という題で、property based testing(以下PBT)において発生する小さくて大量のタスクをRactorで並列実行させるというアイデアと仮説検証の結果を報告しました。 日本語のテキストで概要を知りたい方はTechouse社の記事をご参照ください。登壇者の自分が発信したどのテキストよりも丁寧にわかりやすくまとめてくださってます。この場を借りて感謝いたします! developers.techouse.com

                      Ractorを用いたproperty based testingの並列実行についてRubyKaigi 2024で発表しました - valid,invalid
                    • 毎日やったことをGoogle Calendarに記録してる - valid,invalid

                      今年に入ってから毎日やったことをGoogle Calendarに記録するようにしており、5ヶ月続いているので習慣化できてきた。 やったことを書くと言っても大それたことではなく、生活をちゃんとやっているな〜と自分で認められるようなこと、日記を書くほどでもないことを箇条書きにしているだけ。*1 ランニングや筋トレをした RSSリーダーに溜まっている記事を消化した 行ったことのない店に行った コーヒー豆を買った 楽器を弾いた 他にもクラフトコーラを作ったとか、図書館に寄ってレコードを聞いたとか、なにか新しいことをやったとか ほとんどはやったあとに事後で記入しているが、翌日や週末にやりたいことを前もって書くこともある。 実際のようす。Tasksとして登録している 始めたきっかけは昨年末に読んでいた2つの本で、異なる目的で似たような手法を紹介していて面白そうだと思ったから。 1つ目の本は『不老長寿メ

                        毎日やったことをGoogle Calendarに記録してる - valid,invalid
                      1