CloudNative Days Tokyo 2021の発表資料です。 https://event.cloudnativedays.jp/cndt2021/talks/1207 補足資料 https://git.io/operator-bestpractice

CloudNative Days Tokyo 2021の発表資料です。 https://event.cloudnativedays.jp/cndt2021/talks/1207 補足資料 https://git.io/operator-bestpractice
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか?」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
(Image by Pixabay) 勉強が進まないので、今回は与太記事でも書いてお茶を濁すことにします(笑)。ネタはこちらです。 Why your machine learning project will fail – THE DATA SCIENCE NINJA 9 Reasons why your machine learning project will fail 読んで字の如し、「あなたの機械学習プロジェクトが失敗する9つの理由」というグサグサ刺してくる論評記事です。あまりにもオリジナルの記事が素晴らしかったということか、KDnuggetsに誘われてrepostされた模様です*1。 最近は機械学習の学術・技術的研究開発も極めに極まったところで一息つく感じになってきている印象で、どちらかというとインダストリーサイドではML Opsという考え方が提唱されるようになってきています。そ
SELECT COUNT(*) INTO before_count FROM table1; ... INSERT INTO table1 ...; ... SELECT COUNT(*) - brefore_count INTO registered_count FROM table1; なにかTABLEへの追加処理をしてますが、意図通りにできたかどうか、前後で COUNT(*)をとって、その差分を報告させようとしています。 複数のプロジェクトの複数のオーナーのコードで見かけたので、こんな初級アンチパターンも共有しときます。 なにがまずいの? COUNTは、シーケンシャル・スキャンしないと出てこない値なのです。アンチパターンでは、テーブル全体が対象ですから、主キーインデクスを総なめです。小さいテーブルのうちはいいのですが、運用の1000万行を越えるような巨大テーブルだと、主キーインデック
電子カルテが登場してから随分たつが、残念ながらいまだに素晴らしいものにお目にかかったことはない。特に、日本のメーカーが開発したものは使いやすさまで考慮されているとは言いがたく、UI/UXにも改善の余地がかなりあるように思う。 一般的にPC上でセキュリティのかかったものにログインするためには、利用者IDとパスワードを入力後にエンターすれば開く。電子カルテも同様で、多くのメーカーの場合、利用者IDとパスワードを入力してエンターすればログインできる。 これはF社の電子カルテであるが、利用者IDとパスワードを入力後にエンターするだけではカルテの画面にはならず、利用者氏名が表示されるのを待って、さらに「診療業務開始」をクリック(もしくは再度エンター)しなければならない。 診療業務(電子カルテ)以外の業務も選択できるようにするために、このようにしていると思われるが、多くのユーザーは1回のエンターでログ
SQLアンチパターン 作者:Bill KarwinオライリージャパンAmazon 免責 この本を読んだことがない人が、このノートから本の内容を脳内に展開することはできません。見出し部分は Amazon などで「目次」の内容として公開されている範囲にとどまります。 この本を買うかどうか悩んでいる人は是非購入しましょう。これは価値のある本です。 本の紹介 SQL つまり RDBMS を使ったアプリケーション開発や運用の中で遭遇する「アンチパターン」についてまとめられている本です。出版年を見ると歴史が古いことがわかりますが、Amazon で見ると最近も非常に人気があるロングセラーであることがわかります。読んでみると、それは確かに納得のいくものでした。 アンチパターン、つまり「やらない方がよい手法」を集めたものですが__多くの人が共感してくれると思いますが__よくやってしまう手法でもありました。な
【プレゼント贈呈終了のお知らせ】 転職成功プレゼント、友達紹介プレゼント、カムバックボーナスプレゼントの贈呈を終了いたします。 各プレゼント申請は、対象者の方へ送付している「申請フォームご案内メール」および「申請フォーム」内に記載の申請期限までに申請をお願いいたします。 詳細は **[リリースノート](https://job-draft.jp/release)** をご確認ください。 【サイト停止のお知らせ】 2025年2月10日(月) 22:00 ~ 24:00に、メンテナンスのためサイトを停止いたします。 こんにちは!転職ドラフトスカウト審査チームです。 登録後、審査に通過した人のみが参加できる転職ドラフトスカウトで、私たち審査チームはレジュメのチェックとフィードバックを行っています。 日々、たくさんの方の審査を行っていくなかで、 「実力はありそうなのに書き方がもったいない!」 という
業務でドキュメントを作成するケースは多々ある 例:仕様書・設計書・提案書・メール・障害票... ここでは各ドキュメント共通してありがちなアンチパターンをまとめてみました。 1. 表記がバイト表示・マイクロ秒表示 プログラムが出した数値をありのままに表示するパターン ファイルサイズが100MB, 1GBあろうと、バイト表示にする 桁数が多い数値に、桁区切り(,)を入れない 時間を何でもマイクロ秒・ミリ秒にする(1/100万秒までの精度が必要?体感で分かる?) 桁数が多い=精度が高い=良い文書、ではなく、見る人が必要とする精度に切り上げることが重要(売上で1円単位まで出すことが無いのと同様) 悪い例 No ファイル名 ファイルサイズ(byte) 処理時間(秒)
Go書いててなんとなく見えてきた Goでやっちゃいけないパターン WAF導入してらくらくWebアプリ WAF自体が現在群雄割拠状態。 WAF毎にハンドラインターフェースが違うので既存コードつなぐにはラッパーが必要。 どのWAFもLL言語に比べるとまだまだフィーチャーの網羅範囲が狭い。 なのでもちろんLL言語ほど楽には書けないことが多い。 リフレクション使いまくりでトータル性能はLL言語並みに遅いのもある。 Go1.7のcontextパッケージの導入で標準のHTTPハンドラが復権する可能性があり更に荒れる予想。 追記: 楽できるのを期待してWAFを導入するの「やっちゃいけない」とまでは言い過ぎだったかもしれないけれど例のsqlでPrepareを正しく使えていないで性能出なかった件とか、当面WAFを使うなら自分で概ね中身を理解して使う覚悟が必要。 構造体メソッドにロジックを詰め込む Goの思想
今回は「SQLアンチパターン」の中で紹介されているナイーブツリーというアンチパターンについて見てみることにする。 www.oreilly.co.jp 使った環境は次の通り。 $ sw_vers ProductName: Mac OS X ProductVersion: 10.11.4 BuildVersion: 15E65 $ mysql --version mysql Ver 14.14 Distrib 5.7.12, for osx10.11 (x86_64) using EditLine wrapper $ sqlite3 --version 3.8.10.2 2015-05-20 18:17:19 2ef4f3a5b1d1d0c4338f8243d40a2452cc1f7fe4 ナイーブツリーとは リレーショナル・データベースで再帰的な構造を表現したいときに発生しうるアンチパターン
http://seleniumjp.connpass.com/event/24206/ 第3回日本Seleniumユーザーコミュニティ勉強会の資料です。 Seleniumのアンチパターンについてです。Read less
名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる!! 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる
PostgreSQL 9.2より追加されたJSON型だが、特徴を理解して適切に使わないと色々な副作用に悩まされることになる。その問題点を挙げると共に、どのような場合に使うべきかの指針を示す。 PostgreSQLは、データ型としてjsonをサポートしています。しかし、やりたいことがある時に何でもかんでもjson型を使ってしまうというのはやめるべきです。これは、hstoreや新しく登場したjsonb型にも同じことが言えます。これらの型は必要な時には便利なツールになりますが、PostgreSQLでデータのモデリングを行う際に最初に検討すべきものではありません。 なぜなら、データを呼び出したり操作したりするのが難しくなってしまうためです。 何もかも同じところに入れてしまおうとすることによるアンチパターンをご存知の読者もいるでしょう。EAVアンチパターンは、長らくデータベーススキーマにおける必要悪
This document discusses using Node.js as the foundation for building applications that connect the physical world to enterprise systems through mobile devices and sensors. It describes initial work done to build a proxy and protocol for handling requests and addresses challenges with authentication, scalability, and performance testing. The document shares results from benchmarking the system unde
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く