成功者がどのようにNew Relicを使用してKubernetesのパフォーマンスを4倍に向上させ、拡張性とスループットを改善したかをご覧ください。
成功者がどのようにNew Relicを使用してKubernetesのパフォーマンスを4倍に向上させ、拡張性とスループットを改善したかをご覧ください。
インプレスR&D 迷わない!困らない!レガシーフロントエンド安全改善ガイド 著者:麦島 一 レガシーコードを理解して、モダンなアーキテクチャーに改善しよう! 本書はレガシーなフロントエンドコードを安全かつ確実にモダンに改善していくためのノウハウをまとめた一冊です。筆者が経験したフロントエンドの改善経験をベースに、実践的で現場で使える内容になっています。また、jQueryで書かれたレガシーコードにVue.js/TypeScript/Jestなどを段階的に導入する流れを各章毎に「実践編」として掲載しており、実際に手を動かしながら学べます。改善のための考え方や手法を知りたい方はもちろん、モダンなアーキテクチャーそのものを学びたい方にも最適の一冊です。
24. 削除 フラグ︖ というかそもそも論理 削除 とか 削除 フラグなんていうか ら話が掴みにくくなる スーパー非表⽰フラグとか表⽰ステータスとかにすればいいんじゃ ね︖ - そうすれば、それはレコードの 属性 の⼀つなので、リレーショナル モデル的に納得がいく 運営のみ閲覧可能フラグとかユーザー非表⽰フラグとかでもいい ステータスならENUM(ʻNOT̲DELETEDʼ, ʻDELETED̲BY̲USERʼ, ʻDELETED̲BECAUSE̲DMCAʼ, ʻDELETED̲BECAUSE̲PORNʼ, ..)とか︖ ただし”display̲status <> ʻNOT̲DELETEDʼ“とかやると死ねる。 とはいえそんなクエリー流すの管理画⾯だけであるべきなので、テーブルスキャンく らいは覚悟しろという気でいる。 - 23/33 26. 削除フラグのインデックス そして全ての(ユーザ
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか?」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
概要 COVID-19の影響でキャンセルとなったEmbulk & Digdag Meetupですが、オンラインで実施することとなりました! Arm Treasure Dataが中心となって開発・提供をしているOSSプロダクトであるEmbulkとDigdagのMeetupを初開催します! Embulk/Digdagのオリジナル開発者である古橋(@frsyuki)や現在のコア開発チームも参加して、EmbulkとDigdagそれぞれの今後のロードマップについて発表します。 さらに、EmbulkとDigdagをプロダクション環境で利用しているZOZO TechnologiesとprimeNumber社の「troccoⓇ」開発チームの2社にも登壇いただき、EmbulkとDigdagの運用やプラグイン開発についてのディープなナレッジを共有します。 Youtube Live経由で配信します。https:
【登壇資料】AWS CDK を使った サーバーレスアプリケーションのデプロイ方法と実装例を紹介しました – Developes.IO 2020 CONNECT #devio2020 Developers.IO 2020 CONNECT の登壇資料です。サーバーレスアプリケーションのデプロイに焦点をあて、AWS CDK が便利に使えそう、という話をしました。 AWS サーバーレスアプリケーションデプロイのハードルを下げたい プロダクションでのアプリケーション構築にサーバーレスを採用することも増えてきました。本セッションではサーバーレスアプリケーションのデプロイを考えます。昨今のクラウドアプリに共通して、デプロイのハードルがかなり上がっています。実際の環境、例えばAWSにあげてみないとわからないことが増えてきたためです。 プロダクションデプロイのハードルを下げるアプローチとして、「デプロイ可能
近年、ドメインの更新手続き忘れにより、大きな損失を被る企業・法人が増えています。ワシントンポスト紙、ユニクロドットコムなどが、更新ミスにより自社のドメインを失効し、Eメール送受信やサイトが終日不通になったケースがあります。 また、ドメインの失効に気づき、再登録を行ったけれど、既に失効したドメインは第三者に取得されていた…というケースが多々あります。 一刻も早くサイトを復活させたい元のドメイン所有者は、第三者から、高額でのドメイン買取りを余儀なくされます。 (A社における2007年度のドメイン平均取引価格:約25万円) また、ドメインの買取りを諦めても、フィッシング詐欺目的のサイトとして、自分が利用していたドメインを悪用されることがあります。 ゴンベエドメインの自動更新を利用していただければ、こうした不安から解消されます。 自動更新のお申し込みに書類を送付したり、別途手続きしたりする必要はあ
この記事は Gunosy Advent Calendar 2017の5日目の記事です。前回の記事はGunosyのパーソナライズを支える技術 -ワークフロー編-でした。 GoでAPIを書くときの問題僕の在籍するGunosyはGoを昔(?)から本番採用しておりまして、ノウハウも潤沢に溜まっている企業だと言えます。 しかし、contextの扱いやベストなパッケージ構成、テスト、net/httpでAPIを書くノウハウなどなど、迷うことは多々あります。 これは弊社特有の事情ではなく、Goのサーバーサイドエンジニア全員にとっての問題です。中でも、パッケージ構成をどうすればいいのか(相互参照せずに快適に開発を進められるパッケージ構成とは)を見つけるのは結構難しく、各々のチームにお任せ、という状況です。 今回は上記の問題のうち、パッケージ構成に踏みこんで見たいとおもいます。会社でもよくパッケージ構成をどう
こんにちは。Finatextでエンジニアのマネジメントをしている河本です。 当社は「金融を“サービス”として再発明する」をミッションとして掲げ、ビジネスの成長とともに技術領域も拡大させてきました。 エンジニアチームは今、私たちが「BaaS (Brokerage as a Service)」と呼んでいる証券サービスのためのシステム基盤と、そのBaaS上のサービス開発に力を注いでいます。 今回は、そんな当社の技術スタックについて紹介したいと思います。 開発環境・CI/CDGitHubSwaggerSonarCloudPostmanTerraformAWS CodeBuildAWS CodePipelineコードはGitHubで管理され、API 仕様管理には Swagger が使われています。SonarCloud を用いてソースコードの健全性やテストカバレッジの可視化を行っています。API開発の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く