エラーハンドリング・クロニクル #nds41 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
はじめに プログラミング技術の歴史は、ありとあらゆる歴史がそうであるように、いろんな「史観」で眺めることができます。ならば、プログラミング技術の歴史を、「エラーハンドリングとの戦い」という視点から見ることもできるのではないでしょうか。本日は、エラーハンドリングとの戦いの歴史を俯瞰することで、エラーハンドリングの勘所について考えていこうと思います。 なお、このエントリはNDSという勉強会の第41回で発表した内容と同一です。 Cの時代 Cの時代のエラーハンドリングでは、関数の返り値と、グローバル変数errnoを見ることで処理が成功したか失敗したかを見るのが一般的でした。 例として、文字列をlongに変換するstrtol関数をmanで引いてみましょう。すると、だいたい以下のようなことが書かれています。 変換に失敗すると、0を返す 変換に失敗した場合、グローバルな変数であるerrnoに以下の定数を
ログ設計指針
概要 このドキュメントは、効率的かつ安定した、システム開発/運用をするためのログ設計指針です。 的確かつ無駄のない、ログ出力を目指します。 ログレベル ログの緊急度や用途により、以下のようにログレベルを設定する。 Log4j のログレベルを踏襲しているため、運用の状況によっては Critical などのレベルを適宜追加すると良い。 PHP における PSR-3 では、さらに細分化され emergency, alert, critical, error, warning, notice, info, debug となっている。 「出力先」「運用時の対応」は、各プロジェクトのポリシーに準じてください。 レベル 概要 説明 出力先 運用時の対応
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
UseCaseの再利用性 - yoskhdia’s diary
Clean ArchitectureにはUseCase層が定義されていますが、このUseCaseが一体どういうものなのか度々わからなくなるので、自分の考えをまとめてみるエントリです。 Clean Architectureについてはこちら 8thlight.com 日本語訳：クリーンアーキテクチャ(The Clean Architecture翻訳) 以降、概念を”ユースケース”、実装されるモノを”UseCase”と表記することにします。 （同じっちゃ同じなんですが、指してるものがところどころ変わるので表記分けをしています。） また、Webアプリケーションを想定しています。 ユースケースとは何なのか Clean Architectureから抜粋します。 Use Cases The software in this layer contains application specific busi
Spockのレポート生成はHTML, Markdown, Asciidocできるし、カスタムも出来るんだぜ - うさぎ組
GroovyのテスティングフレームワークであるSpockは標準ではレポート生成機能はありません。 多くはGradleでビルドしたときのxmlやhtmlを利用していると思います。 Spockにはspock-reportという拡張ライブラリがあり、これを依存関係に追加するだけでテスト結果のレポートを独自に追加で生成できます。 しかもなんと、HTMLだけではなくMarkdownやAsciidocとして生成することもできます。 また、最新のspock-reportではテストコードからレポートに文章を追加することも出来るようになりました。 今回はそんなspock-reportの便利機能をいくつか紹介します。 github.com 本ブログで説明しているサンプルコード全部入りのspockおよびspock-reportのプロジェクトテンプレートはこちら。 github.com 本記事はG* Advent
Java 30byte FizzBuzz - プログラマーの脳みそ
なっちゃん（以下な）「なんかさー。タイトルが無理すぎない？」 ぎぃくん（以下ぎ）「まあ流行りだからね」 せっちゃん（以下せ）「流行りって言ってもFizzBuzzを３０バイトで - Togetterが1/24だし、1週間経ってるけど。どちらかと言えばオワコン？」 な「まあまあ」 ぎ「とりあえず、どのぐらい無理っぽいか見てみるかい？」 普通のFizzBuzz せ「じゃぁまあ普通のFizzBuzzをみてみましょ。」 な「FizzBuzz Javaでググって…これかな？ Fizz Buzz - Semicolonless Java」 public class FizzBuzz { public static void main(String[] args) { for (int i : new int[] { 0 }) { while (++i <= 100) { if (i % 15 == 0)
Java で書いた FizzBuzz を短くしながら仕様について学ぶ - Qiita
class FizzBuzz{ public static void main(String[] args){ for(int i = 1; i <= 100; ++i){ if(i % 3 == 0 && i % 5 == 0){ System.out.println("FizzBuzz"); }else if(i % 3 == 0){ System.out.println("Fizz"); }else if(i % 5 == 0){ System.out.println("Buzz"); }else{ System.out.println(i); } } } } 短くしてみる 現在最も短い Java による FizzBuzz のソースコードは 96byteらしいです。 せっかくだから（何が？）短くしてみましょう。 条件演算子を使って短くする class FizzBuzz{ public
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【改訂版】PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016 Revised