システム運用アンチパターン
上層部がDevOpsに理解のない組織で働き、組織構造を変える権限を持っていない開発者であっても、チームにDevOpsを導入するための現実的な方法を紹介します。 重厚な承認プロセス、可視化されていない運用、プロセスの最後でのみ行われるソフトウェアテスト、ノイズだらけのアラート、インシデントから学習しない習慣、時間外のデプロイ、情報のため込みなどを取り上げ、ソフトウェアシステムの開発運用が滞るチームや組織に共通してみられる陥りがちな状況や犯しがちな間違いをアンチパターンとして紹介します。そして管理職やマネージャでなく、エンジニアが実行し、繰り返すことで改善できる具体的な行動を解説します。 組織で必要とされる変化を、エンジニアが行動することで実現する本書は、ソフトウェアシステムをよりよく開発運用したいエンジニア必携の一冊です。 目 次 序文 本書について 1章 DevOpsを構成するもの 1.1
.dockerignore アンチパターン - Qiita
.dockerignoreとは Dockerfileからイメージをビルドする場合、Dockerfileの存在するディレクトリの中身はtarで固められdaemonへと送られます。 $ ls -la total 2097168 drwxr-xr-x 5 muni staff 170 3 7 12:40 . drwxr-xr-x 8 muni staff 272 3 10 15:19 .. -rw-r--r-- 1 muni staff 76 2 16 17:04 Dockerfile -rw-r--r-- 1 muni staff 18 2 16 10:10 docker-compose.yml -rw-r--r-- 1 muni staff 1073741824 2 16 10:04 dummy.file $ cat Dockerfile FROM debian:jessie $ time
Index as a key is an anti-pattern
So many times I have seen developers use the index of an item as its key when they render a list. { todos.map((todo, index) => <Todo {...todo} key={index} />); } It looks elegant and it does get rid of the warning (which was the ‘real’ issue, right?). What is the danger here? It may break your application and display wrong data! Let me explain, a key is the only thing React uses to identify DOM el
ポケモンを題材に「SQLアンチパターン」を実践してみる - kanayamaのブログ
@tkanayama_です。「SQLアンチパターン *1」 という本を読みました。「ポケモンを題材に因果推論を実践してみる」のように、仮想的なストーリ上で実際に使ってみた感を出すことにより、自分の記憶に定着させることを狙います。 前提として、何をアンチパターンとするかは状況（ベンダーフリーである必要があるかどうか、どの程度の頻度で更新されるか・・・など）によって大きく異なるので、下記で紹介するアンチパターンは実は状況によっては問題にならないケースもあるかと思います。この投稿はあくまで「SQLアンチパターン」に忠実に従うことが目的です。 www.oreilly.co.jp 追記 登場人物 ストーリー フシギダネへの対応 ヤミカラスへの対応 ディグダへの対応 誤登録でポケモントレーナーになってしまったユーザーの削除 最後に 謝辞 追記 このブログを公開後、「外部キー制約はレコードロック周りのト
やってはいけないUIアニメーション
ここの画面ではメインボタンの「START」を目立たせたいのですが、右上のボタンに目がいってしまいます。 右上に目がいってしまうのは、最後に動く箇所に視線が移動するので不必要に右上に視線が誘導されます。 他にもコントラストや動き量がメインボタンよりも大きく変化しているため、いやでも目についてしまいます。 不必要に待たせている 最後に動かすところに視線が行きますが、視線をメインボタンに向けさせようと最後のアニメーションを長くしてしまった結果、ユーザーがアニメーションによって待たされている状態になってしまいました。 メインボタンはすぐに押してゲームを遊べることが大切になるので、最後にボタンを大きく動かして目立たせてもユーザーは早く押させて欲しいと思ってしまうので、アニメーションは短くサッと出して上げてユーザーが気持ちよく行動できるといいですね。 動き過ぎ、優先順位が曖昧 全てが動き過ぎてしまい、
やめてほしいUIアニメーション
最近はクオリティの高いアプリも増え、UIの見せ方も工夫されて昔より質の高いアプリが増えましたが、低コストで開発していくとUIアニメーションは後回しにされがちですよね。 開発時間や人員の問題、UIアニメーションをやる人がいないから自分がやった人など、UIアニメーションの優先順位が低いため、手探りでやっている方も多いと思います。 今回の記事では今出ているアプリに対してあれはダメだ！と言いたいわけではなく、リリースされているアプリを触って、自分が作るときはここは気をつけようと思ったり、これはアニメーションいいなとか、実際体感して勉強していけるため、その経験が業界全体を徐々にクオリティアップしていくため、結果は惜しいアニメーションだとしても挑戦した結果でもあると思うため大事なことだと思っています。 前置きはここまでにして、今回はアニメーションの中で、あれ？と思ってしまう、そんな「これはやめてほしい
治安の良いCSSを目指して 〜 平和な世界のために僕たちができること 〜 - Qiita
はじめに 業務でCSSを書くようになってから、いくつかの月日が流れました。 CSSを学び始めた当初は、要素をキレイに横並びにすることすら手こずっていましたが、最近は随分スムーズにデザイン通りのスタイルを書くことができるようになりました。 今日に至るまで、過去の自分が書いたCSSへの後悔の念で眠れない日々や、原因のよくわからない表示崩れの悪夢にうなされる夜もありました。1 これからCSSを学ぶ人、CSSにはあまり詳しくないけどたまに書くよという人にそんな思いをして欲しくない。できたらCSSのことを好きになって欲しい。 そんな思いで自分がスタイルを書く時・レビューをする時に気をつけていることを（自戒も込めて）まとめまてみました。 🤔 良いスタイルってなんだろう？ スタイルを書く時に大切だと考えていることは3点あります。 開発効率 デザイン再現性 パフォーマンス 開発効率 色々な記事や本でも引
「SQLアンチパターン」を避けるためのチェックリスト③（SQLクエリ設計編） - log4ketancho
引き続き「SQLアンチパターン」について、自分なりのチェックポイントを言語化していきたいと思います。 「SQLアンチパターン」を避けるためのチェックリスト①（DB論理設計編） - log4ketancho 「SQLアンチパターン」を避けるためのチェックリスト②（DB物理設計編） - log4ketancho 「SQLアンチパターン」を避けるためのチェックリスト③（SQLクエリ設計編） - log4ketancho 【本記事】 「SQLアンチパターン」を避けるためのチェックリスト④（アプリケーション設計編） - log4ketancho この記事では、SQL クエリを作成するときに抑えておきたい勘所について整理します。 SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入:
「SQLアンチパターン」を避けるためのチェックリスト②（DB物理設計編） - log4ketancho
引き続き「SQLアンチパターン」について、自分なりのチェックポイントを言語化していきたいと思います。下記の記事の続きです。 www.ketancho.net 本題に入る前に、ふたつ。嬉しかったこととお詫び（？）を。 t_wada さんからコメントを頂けた😂 素晴らしいエントリをありがとうございます。『SQLアンチパターン』は名著であると胸を張って言えます。ご興味をお持ちの方はこの機会にぜひ。 / “「SQLアンチパターン」を避けるためのチェックリスト①（DB論理設計編） - log…” https://t.co/Vjj0Yh2cqU— Takuto Wada (@t_wada) 2018年3月8日 スーパーなエンジニアの方からコメントをいただけるなんてと、帰り道ニヤニヤしてましたｗ 色々拙い部分があると思いますが、自分の理解のために拙くてもいいので言語化を続けていこうと思っています。引き
「SQLアンチパターン」を避けるためのチェックリスト①（DB論理設計編） - log4ketancho
ずっと前から積ん読状態だった「SQLアンチパターン」を読みました。 何年積んでたか分からないSQLアンチパターン読み終わったー。噂に違わずいい本ですねー。もっと早く読むべきだった。— @ketancho (@ketancho) 2018年3月6日 噂通りとても良い本で、まさに「エンジニアとしての血肉本」と言えます。1, 2年目の頃に読んでおくべきだったなーと少し後悔しています。 SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る 読んで終わりだと身につかないと思うので、自分なりのチェックポイントを言語化しておこうと思います。長くなってしまったので、章ごとに4つに分けたいと思います。この記事はその第一弾と
コードレビューにおけるレビュアー側のアンチパターン
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
idやclassを使ってテストを書くのは、もはやアンチパターンである - Qiita
いきなり結論を書くと、idやclassはスタイルのためのものなので、テストでそれを使うのはやめましょう。そして、カスタムデータ属性を使いましょう。(idやclassはスタイルのためだけではないという意見はごもっともです！しかし、主にとしてスタイルに使われるということでご了承頂いて以下の駄文に付き合って頂けると幸いです🙇) 先に断っておくと主にreactについての話で、JSXを前提とします。(手法はReactに限りませんが理由は後述) 2020/03/23 追記 この記事は1年以上前に書かれた記事なのでテストフレームワークとしてenzymeを使っていますが、現時点ではTesting Libraryの使用をオススメします。data-testid に対応するクエリを備えています。 React Testing Library · Testing Library はじめに ご存知の通り、ロジックと
Lobiスピンオフ！トーナメント開催サービスをDocker+CircleCIで開発したはなし - KAYAC Engineers' Blog
はじめまして（？）。taiyohと申します。 幾つか事業部を渡り歩いた後、現在はLobiにて新規機能の開発などを行っております。 皆様は3/3発売のNintendo Switchの予約はお済みでしょうか。僕は早速1/21の午前中に近所の電器店に駆け込んで予約をしました。ゼルダ、Splatoon2、ゼノブレイド2と、既にやりたいソフトがいくつかあるので大変楽しみです。2017年も何とか生きていけそうです。どうぞ宜しくお願いします。 さて、昨年の2016年末ですが、Lobiアカウントを利用したトーナメントサイトというものをリリースしましたので、そのちょっと技術っぽい観点についてお話させていただきます。なお、技術っぽいと書きながら実装やインフラ成分は低めです。その点予めご了承ください。 Lobiトーナメントはゲーム大会をより簡単に開催・参加できるようにしたサービスです。大会のエントリーから大会終
最も割高なアンチパターン : 構造化されたデータを文字列関数で操作する「printfアンチパターン」について | POSTD
本記事では、私の知る最も割高なアンチパターンとなるプログラミングについて述べます。 それは、 構造化されたデータフォーマットを文字列関数を使って操作すること です。 以後これを” printfアンチパターン “と称します。 コスト 私がこれを”最も割高な”アンチパターンと呼ぶのは、根拠のない主張ではありません。 cve.miter.org のデータを使って 脆弱性をタイプ別にカウントし 、下記のように、上位を占める脆弱性のタイプ別リストを作りました。 rexec: 19268 DoS: 14849 xss: 9236 memory: 8212 sqlinj: 6230 privilege: 3321 dirtraversal: 2762 arith: 1260 csrf: 1117 私の方法に対する批判や良いご提案があれば遠慮なくどうぞ。 上位を見ると、XSSとSQLインジェクションの数が
ダメなプログラミング入門書の特徴 - 望月いちろうのREADME.md
2016 - 12 - 07 ダメなプログラミング入門書の特徴 list Tweet Share on Tumblr 環境構築について書いていない 僕が見てきた限りではプログラミングに挫折する理由はプログラミングそれ自体の難しさより、プログラミングをするための環境構築がうまく行かないことに起因することが多い。特にWindowsでは（最近ではPower-Shellに統一され、マシになったそうだが）、オープンソース系の言語を動かすための環境作りに苦労した記憶がある。僕自身もPythonをWindowsで動かそうとしたときになかなかうまく行かずに苦しんだ記憶がある。 実際に初心者向けを謳う非常に初歩的な入門書であっても、環境構築については、さらっと流す程度で済ませてある本が殆どだ。これでは本当の初心者は挫折することが必至だろう。 一般に、プログラミング言語を習得する最初の一歩は、Hello Wo
Reduxのパターンとアンチパターン | POSTD
Redux は、 Flux のようなアーキテクチャを使用してアプリケーションの状態を管理できる非常にシンプルなライブラリです。私たち Affirm では今、 Reduxのタイムトラベル機能 に注目しています。Affirmの主要事業は、透明性の高い消費者ローンを提供することなので、ローン申し込み時の全過程をユーザ視点で再現できると非常に有用なのです。 Reduxはフレームワークというよりも、パターンの適用に役立つ関数セットです。よって、適切なパターンを慎重に適用しないと、Reduxを使ったことを後悔する結果になりかねません。この記事では、Affirmで確立したReduxのベストプラクティスや、ミスを犯しやすいポイントについて説明します。 ImmutableJS ImmutableJS は、不変の永続データ構造を扱うためのライブラリです。私たちがこのライブラリを好んで使う理由は2つあります。
Scalaアンチパターン：変更可能コレクションをvarとして宣言する - kmizuの日記
Scalaは最初から関数型プログラミングのスタイルで書くことを意識して設計されたという意味で関数型プログラミング言語と言えますが、一方で、「Better Java」な手続き型スタイルで書くことも基本的には否定されるべきではないと思います。たとえば、ビッグデータ関係のソフトウェアとして有名なApache SparkはScalaで書かれていますが、（おそらく）パフォーマンス上の理由のため、手続き型のスタイルで書かれている部分がかなり多いです。 さて、それはいいのですが、そういう「Better Java」なScalaコードによく見られるパターンに、変更可能コレクションを使っているのに、そのコレクションを格納する変数をvarとして宣言しているものが（割と有名なソフトウェアでさえ）あります。ですが、そういうコードは 書いてはいけません（かなり例外的な場合を除いて）。 「書いてはいけません」というのは
ドキュメント作成時のあるあるアンチパターン20 - Qiita
業務でドキュメントを作成するケースは多々ある 例：仕様書・設計書・提案書・メール・障害票．．． ここでは各ドキュメント共通してありがちなアンチパターンをまとめてみました。 1. 表記がバイト表示・マイクロ秒表示 プログラムが出した数値をありのままに表示するパターン ファイルサイズが100MB, 1GBあろうと、バイト表示にする 桁数が多い数値に、桁区切り（,）を入れない 時間を何でもマイクロ秒・ミリ秒にする（1/100万秒までの精度が必要？体感で分かる？） 桁数が多い＝精度が高い＝良い文書、ではなく、見る人が必要とする精度に切り上げることが重要（売上で１円単位まで出すことが無いのと同様） 悪い例 No ファイル名 ファイルサイズ(byte) 処理時間(秒)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
インフラしくじり先生 / Failure story for infrastructure
RDBアンチパターン // Speaker Deck
