Atomic Design における Atom, Molecule, Organism の見極め方 - assertInstanceOf('Engineer', $a_suenami)
最近フロントエンド書いてて、コンポーネントの設計とかデザイナーとのコミュニケーションには Atomic Design を採用しているのだけど、まあよくある話として「この要素が atoms / molecules / organisms のどれにあたるかわからん！」となる（なった、特に molecules）ので、チーム内に雑にテキストで書いて共有した。で、せっかくならそれを公開して優秀なデザイナーおよびフロントエンドエンジニア諸氏に意見を募りたいと思ったのでブログ書いてみることにする。 ちなみに、現状は実装対象として Web アプリケーションを想定しているけど、ネイティブアプリも視野に入ってるので「HTML ではそうかもしれないけどネイティブアプリだと云々」みたいな意見も歓迎する。 チームに共有したテキストがこちら。 Atom, Molecule, Organismの見極め方 Atomic
エンジニアのための情報設計入門
20240530_IBMTechXchangeDojo_いまからでも遅くない_OpenShiftでアプリをHTTPSで公開してみる
エラーメッセージは 2W1H がいいんじゃないか
良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か
論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
API設計のポイント - ワザノバ | wazanova
Living Socialが7回に渡りSOA (Service-oriented architecture) についてのブログを書いてますが、今回はAPI設計についてのエントリーです。 「APIはRESTful」と言うだけでなく、社内でガイドラインがオーソライズされるように調整すること。設計にあたっての選択肢及び自由度をしっかり考慮すること。そして一番大事なのは、決めた原則とおりにブレなくインプリすること。 どのHTTPステータス（success/error）をどのシチュエーションで採用するか。 204もしくは200をPOSTで使うか？PUTで使うか？ 4xx番台のコードの一貫性。 bodyにエラーメッセージを追加するのか。 認証はどこで？ ヘッダー？もしくはURLパラメータ？ リソースの階層はどうするか。 忠実にRESTfulとするのか、RPCのようなエンドポイント（/inventory
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
