フロントエンドのコードからの情報漏洩を防ぐための工夫 - BASEプロダクトチームブログ
基盤チームの右京です。 昨今はフロントエンドのアプリケーションもリッチになり、ブラウザ上で実行されるコードが行うことの範囲も増えてきました。一方で多くのことを実装できてしまうのはリスクでもあり、BASE でも問題となることがあります。 その中でも「開発環境の URL」や「デバッグ機能の存在」ような環境毎に異なる情報は、特に意図せずに漏れやすいものだと考えています。これらはコードを記述する際に、実装方法を知識として知っていればその多くが回避可能です。この記事ではその実装例を解説しています。 コードから漏れる情報 例えば、次のようなコードがあるとします。 function debug() { // 開発環境の host であればデバッグ機能を有効にする return location.host === 'dev.example.com'; } なんの変哲もないようなコードに見えますが、ブラウザ
TDDという名の幻想... - Qiita
TDDは死んだ。テスティングよ栄えよ。 by DHH http://d.hatena.ne.jp/yach/20140424#p1 【翻訳】TDD is Fun http://diskogs.hatenablog.com/entry/2014/04/25/085112 を読んで思ったことをつらつらと書いてみます。 TDDはできれば、やったほうが良いのは確か？です。 しかし、実際の開発現場で全面的に採用するのは ミドルウェア等の画面の存在しないソフトの開発以外では ほとんどの場合、無益です。 なぜなら、TDDを採用すると開発時間が膨らむ、すなわち、開発コストが 膨らむからです。そして、ソフト開発では細かな仕様は変化していきます、 するとTDDではそれに合わせ、テストを修正していかなくてはなりません。 また、TDDで書かれたテストが全てのケースを抜けなく網羅できていること は稀です、抜けは必ず
リファクタリングは事前準備が９割 - freee Developers Hub
会計チームで債権周りの開発をしている hachi (@hachiblog)です。会計チームが開発している freee 会計は freee の中で一番歴史が長いプロダクトです。加えて会計というドメインは複雑かつバグを生むと顧客の業務を大きく阻害するという点で一度作ったものを変更しづらいという特徴があります。 そのような環境で今回、債権のチームでは freee会計の初期からある「自動で経理」という機能の一部リファクタリングを行いました。リファクタリングのしづらい環境下でうまくリファクタリングをすすめるための tips は多くの人に役立つのではと思い、このエントリを書くに至りました。 今回「自動で経理」でリファクタリングしたときに事前に以下のことを行いました。 課題の発見 課題の具体化 設計とスケジュール見積もり テストコード実装 それぞれについて今回意識したことを書いていきます。 課題の発見
Googleでもやっている障害対応訓練の「Wheel of Misfortune」をやってみた。 - MonotaRO Tech Blog
序文 こんにちは。MonotaROの伊藤です。 弊社では障害対応訓練の実施手法の一つであるWheel of Misfortune(略称:WoM)を実践しています。WoMの導入で、障害対応体制の強化を行うことができましたので、実施までの経緯や得られた学びなどを中心に紹介したいと思います 序文 運用担当者の負荷が高まり続ける問題 運用担当者=社歴が長いベテランエンジニア 運用のスケールアウト 障害対応訓練をやってみよう 訓練環境の準備の問題 訓練シナリオの問題 外部からの助け Wheel of Misfortuneとは 実施時の様子 シナリオ開始時の様子 モニタリング画面の表示 WoMとDiRT(Disaster in Recovery Training) 障害対応訓練をやってみた結果 準備時点で感じたメリット 手順書の不備を発見できたこと 障害が起こりかねない場所を考えるきっかけになったこと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
