rambulance Rails 4.2時代の簡単404/500エラー対応最近作っているRailsアプリケーションで、404/500エラーの対応をしている時に知ったgem『yuki24/rambulance』 の紹介です。 一言でいうと、ものすごく簡単にRailsのエラーハンドリングを行ってくれつつ、エラーページを構築できるgemです。
FTH - Fault Torelant Heap の無効化やリストのクリア方法など | ゲームプログラマの生態: ゲームプログラマの小ネタ 0x0003
2011年7月31日日曜日 ゲームプログラマの小ネタ 0x0003 Windows 7環境下でVisual Studioを用いてプログラムをデバッグ開始すると、 「出力」ウィンドウに FTH: (nnn): *** Fault tolerant heap shim applied to current process. This is usually due to previous crashes. *** と表示されることがある。 これの意味と対処法とか。 ■FTHとは FTHは、"Fault Torelant Heap"の頭文字をとっている。 Windows 7から実装された機能で、メモリ破壊を起こしたプロセスを覚えておいて 次の実行時からは、壊される領域を織り込んでメモリ確保するという仕組み。 開発者視点では、バグの再現が難しくなるだけであって、迷惑極まりない機能。 ユーザー的には、
ActiveRecord::RecordNotFoundエラーを防ぐ - komagataのブログ
こちらの記事の解決編です。 ActiveRecord::RecordNotFoundのエラーは放置すべきか？ - komagata @hiroshi3110さんからズバリな答えをいただきました。 @komagata ... とかやってました。 ActiveRecord::Notfound がでるときはバグというのがすぐわかるように — hiroshi (@hiroshi3110) 2015, 1月 6 怖話で実装 # lib/record_not_found_by_trustless_param.rb: class RecordNotFoundByTrustlessParam < StandardError; end # app/controllers/comics_controller.rb: class ComicsController < ApplicationController
Web APIを作るときに考えること。 - パルカワ2
この記事はPepabo Advent Calendar 2014の11日目の記事です。 前日は、tnmtさんのVagrantのshell provisionerでApacheのビルド済tarボールをOSバージョン毎に作る術でした。 はじめに 今回は、Web APIを作るときに考えることをまとめました。 本当は、社内向けに資料を作っていて、社内の勉強会とかで話せればいいか〜って考えていたんですが、アドベントカレンダーのネタが本当になくて困っていたのでこれを使います。 対象者 APIを作る時、と書いてますが、クライアント側の人にとっても知っておく必要があることなので、サーバ側の人・クライアント側の人両方が対象者です。 APIを作るときに考えること 「APIを作るとき」と言っても、色んな状況があります。 まずはそれを絞ります。 APIの種類 プライベートAPI アプリのAPIなど使う人が限定され
Errbit
The open source, self-hosted error catcher Errbit is a tool for collecting and managing errors from other applications. It is Airbrake API compliant, so if you are already using Airbrake, you can just point the airbrake gem to your Errbit server. Documentation is available for all released versions of Errbit and master. It is built directly from whatever documentation was available in the ./docs f
Application Performance Monitoring (APM) with Elastic Observability
Search and analytics, data ingestion, and visualization – all at your fingertips.
続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi
三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン２：エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数（
リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
または私は如何にして例外するのを止めて golang を愛するようになったか — KaoriYa
Java の finally よりも golang の defer のほうが筋が良さそうだ、 ということから考え始めた結果、 どうして私が golang を気に入ったのかがわかった気がしたので書いておきます。 ファイルをオープンし読み込みな処理で何かして終わったら閉じる、という関数を Java と golang で書き比べてみましょう。 Java で書くとこんな感じですね。 public static void readFile(String fname) throws IOException { InputStream s = null; try { s = FileInputStream(fname); // // Do something with "s". // } finally { if (s != null) { s.close(); } } }
Big Sky :: golang で複数のエラーをハンドリングする方法
golangいまどき例外ないの頭おかしいって思ってたけどようするにgoroutineと例外がうまくいかないからgoroutineのほう取って例外捨てたってことかねえ。 — Urabe, Shyouhei (@shyouhei) April 15, 2014 FAQ に書いてあります。 Why does Go not have exceptions? - Frequently Asked Questions (FAQ) - The Go Programming Language We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programme
異常検知の世界へようこそ - Preferred Networks Research & Development
比戸です。 先週Jubatusの最新0.4.0がリリースされましたが、外れ値検知機能の追加が目玉の一つとなっています（jubaanomaly）。昨年PFIへ入社して初めて手がけた仕事が公開されたということで感慨ひとしおですが、便乗してあまり語られることのない異常検知の世界について書きたいと思います。以下の資料は昨年のFIT2012で使ったものです。 異常検知とは簡単にいえば、「他に比べて変なデータを見つけ出す」タスクです。お正月にテレビで繰り返し流れた、おすぎとピーコのCM(*1)がわかりやすいイメージですね。機械学習の枠組みで言えば”教師無し学習”に属します。分類や回帰、クラスタリングなど応用も多く人気も研究熱も高いタスクに比べると、マイナーです。SVMとか、Random Forestとか、Boostingとか、最近だとDeep Neural Networkとか、有名な必殺技アルゴリズム
scala.util.Tryが使いづらい？
Kenji Yoshida @xuwei_k 「scala.util.Tryが嫌いな理由」という感じでブログ書こうとして、そういえばtwitterから来たわけだし「改めてTryが使われてるコードを見なおしてから記事書こう！」と、(おそらく一番多く使われているであろう)finagleのコード見たら、複雑で理解できなくて死・・・ 2013-05-26 12:04:20 Kenji Yoshida @xuwei_k scala.util.Tryについて言えるのは「失敗をThrowable型でしか持てない」のが大きな特徴で、Throwable以外のもっと扱いやすいオブジェクトにその場で変換できるならTryいらない(?)とか、じゃあThrowableってそもそも何？とか考える必要がある気がして 2013-05-26 12:10:01
例外処理 - Wikipedia
例外処理（れいがいしょり、英語: exception handling）とは、IT業界で用いられる専門用語で、ある抽象レベルにおけるシステムの設計で想定されておらず、ユーザー操作によって解決できない問題に対処するための処理である。例外処理の結果として問題が解決されないとシステム障害になる。システム停止やデータ破損の原因になり、ユーザーに損害を与える可能性があるため、システム開発で例外処理は重要視されている[1][2][3]。 システムの設計で想定されておらず、継続不能や継続すると問題になる様な状態としては、次のようなものが挙げられる。 ハードウェアの故障 オペレーティングシステム等、システムの設定ミス ライブラリの欠損 ユーザーの入力間違い 数値入力を要求している場合での、英単語の入力 存在しないデータベースのテーブル／カラムやファイルの指定 必要な他システムとの疎通が取れない 許されない
Error handling in Erlang and Scala
こんにちは。 よろしくお願いします。 弩.netといいます。 AngularとElixirの新しい関係について提案します。 私は、名古屋でプログラマーをしています。 家ではDartを、会社ではGoとTypeScriptを書いています。 今日切実に訴えたいのは最近のフロントエンドがまじで面倒くさいので Elixirで何とかしたいということです。 たしかに、部分的には便利になりました。 AnguarやReactを使えば手続きではなく変数でViewを管理できるようになりました。 例えば、bool値でメニューバーが開いているかtrue/falseで宣言すれば、 間違いなく画面でメニューバーが閉じたり開いたりします。 ** 1分 ** また、DartやTypeScriptなど型安全な言語で開発できるようにもなりました。 僕は名古屋出身だで、型安全な言語で開発しりんよとおばあちゃんに言われて育ちました
Scala Tips / Scala 2.10味見(10) - Try(2)
TryとEitherは2つの状態による計算文脈を表現するという意味ではよく似たオブジェクトですが、Tryはファンクタ(Functor)かつモナド(Monad)であるのに対してEitherはそうではないという点が異なります。 Eitherは直和の性質を表現するために2つの状態を同じ比重で扱いますが、この点を徹底するためにファンクタやモナドにはしていないと思われます。EitherではLeftProjectionやRightProjectionと組み合わせることによって、ファンクタ的、モナド的な使い方も可能ですが使い勝手がよいとはいえません。 正常状態と異常状態の2つの状態を扱う場合、(1)出現頻度は正常状態の方が多い、(2)正常状態に対するロジックは複雑/異常状態に対するロジックは単純、(3)一度異常状態になると以降は異常状態を保持、となるケースが多いと思います。このようなケースでは、正常状態
Scala 2.10.0 Try ＆ NonFatal - CLOVER🍀
なんか、情報だけチラチラ見かけていて気になっていたので。まあ、半分くらいFutureの時に使っているのですが。 Try Futureの結果として使っていた、SuccessとFailureの親クラスです。Successが成功、Failureが失敗を表すわけですが、Failureは例外を情報として持ちます。それ以外はSuccessですと。 Futureの時は、計算結果がSuccessまたはFailureとして得られましたが、これを単独で使う場合にはTryコンパニオンオブジェクトのapplyメソッドを使用します。 println(Try { 10 }) // => Success(10) println(Try { throw new Exception("Oops!") }) // => Failure(java.lang.Exception: Oops!) Try.applyのシグネチャは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Golang Cafe版あなたがGoについてたぶん知らない10のこと。
CPUに適度に間違わせることで節電する技術
GitHub - yuskesh/jsdojo: This repo includes additional material on JSDojo#1
Scala Global - 2.1.0