java.util.loggingの闇 - nekop's blog
Javaの1.4からjava.util.logging(以下JULと表記)というロギングパッケージが標準で使えるようになって、ログ出力のためにlog4jなどのサードパーティライブラリをいちいち導入したりする必要がなくなりみんな幸せになりました。 と言いたいところですこいつが超不便なAPIをしていてとてもとてもとっっっても使い辛い。ふざけんな。 まずさらっと使ってみましょう。Java 7です。 Logger.getGlobal().info("log") Logger.getLogger("foo").info("log") 出力はこうなります。 Jan 15, 2015 5:11:41 PM JUL main INFO: log Jan 15, 2015 5:11:41 PM JUL main INFO: log はい、キモイですね。軽くつっこむと なんで2行なんだよ 日時AM/PM表記か
モバイルアプリのログ収集ライブラリ「Puree」をリリースしました - クックパッド開発者ブログ
モバイルファースト室の @rejasupotaro です。 クックパッドでは、サービスをリリースしてログを収集して分析して改善してまたリリースして、というサイクルを素早く回すことでより良いものを作るということをウェブではやってきました。 クックパッドのサービス開発のフレームワークをモバイルアプリでも適用したいのですが、モバイルアプリにはウェブアプリと違ったロギングの難しさがあります。 今回はモバイルアプリのロギングの問題点とPureeというログ収集ライブラリについて話します。 モバイルアプリのロギングの難しさ ウェブアプリでは、基本的にはサーバー側でログを収集することができますが、モバイルアプリの場合は画面の制御はアプリ側で行われ、APIを介してデータを受け取るため、クライアント側でログを収集して送信する必要があります。 アプリのログを収集するのに、画面遷移をしたりタップするたびにサーバー
Web アプリケーションにおいては Python 3 への移行は簡単だという話 - methaneのブログ
Python 2 / 3 両対応のライブラリをメンテナンスしている人にとって、 Python 3 の メリットは享受できずメンテナンスコストだけが上がるつらい状況がずっと続いています。 しかし、「Python 3 への移行が大変」というのは、Python 2 を捨てるのが大変、 Python 2/3 両対応の ライブラリをメンテナンスするのが面倒という意味です。 アプリケーションであれば、 Python 2 対応のプロジェクトを Python 3 に対応させると同時に Python 2 への対応を切れるのでずっと楽ですし、さらに新規プロジェクトを Python 3 で始めるのは もっと楽です。 特に Web 系では、 (Google App Engine などの例外はあるものの)自分で Python のバージョンを 選べることが多いし、主要なライブラリも Python 3 対応ができている
Fluentdのお勧めシステム構成パターンについて発表しました - Y-Ken Studio
2014年9月9日開催の『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！にて発表してきました。 今回は「Fluentdのお勧めシステム構成パターン」というタイトルで、ユースケース毎にどのようなシステム構成をすると運用しやすいかのノウハウをお話しさせていただきました。 また、パネルディスカッションではラジオ番組のようなスタイルで、モデレータに @naoya_ito（伊藤直也氏）をお招きして行い、Kibana以前の可視化はどうしていたの？など、ざっくばらんなトークが出来てとても楽しい経験でした。 発表資料 今回は書籍に書かれた内容をざっとおさらいしつつ、システム構成パターンについて解説しました。 発表資料はSlideshareにアップしております。 Fluentdのお勧めシステム構成パターン 書籍 本書はWEB+DB Pressを取り扱う書店のほか、
Fluentdとログ収集のパターン - Go ahead!
「ログを集めて保存する」と言うのは簡単だけど，ログ収集の構成にはいくつか方法があり，勉強会などでちょくちょく聞かれるので，いくつかのパターンについて書く． 「俺はもうバリバリログ収集やってるぜ！」という人は多分すでに知っていることが書かれているので，タブを閉じて良い． ここではログコレクタにFluentdを想定しているが，他のログ収集プロダクトにも適用出来るはず． ただ，Fluentdはタグベースのルーティングを持ち，単体でもキューのように動作させることが可能で，既存のものより複雑な問題を解決しようとしているので，少し工夫が必要かもしれない． Fluentdそのものについては公式ドキュメントや，Fluentdとはどのようなソフトウェアなのかを参考に． クライアントから直接保存する いきなりFluentdを使わないパターン．JavaScript SDKを提供している解析サービスやモバイル端末
Javaライブラリを配布する際のログ周りにおける配慮と実践 - Kengo's blog
2020-07-22更新: 以下の投稿で情報をアップデートしています。 https://blog.kengo-toda.jp/entry/2020/07/21/223136 いつも購読させていただいている id:teppeis さんのブックマークに以下のエントリが流れてきて、なるほどこいつはたしかに厄介だと思いました。 javaのロガーが多すぎて訳が解らないので整理してみました - 文系プログラマによるTIPSブログ ただSLF4Jが最も先進的かつ著名なインタフェースである以上、配布側としてはSLF4Jを使いつつ問題を解決したいところです。他のインタフェースを使ったりオレオレ実装を使ったりしてしまうと、それこそユーザの自由度を奪ってしまう形になります。 実際、SLF4Jを配布パッケージに含めないという簡単な解決法がありますので、簡単に紹介します。悲劇を繰り返さないためにライブラリ開発者がす
javaのロガーが多すぎて訳が解らないので整理してみました - 文系プログラマによるTIPSブログ
最初は誰しもがファッ！？となるんですよねロガーって。 いずれtree-tipsで公開しようと思っている、solrのプロジェクトを今作っています。mavenでjarを管理している訳ですが・・ なんだこのロガーの数は！！ commons-logging、log4j、slf4j-api、jcl-over-slf4j、logback-classic・・・・、こいつら一体何が違うんだ！どう使い分けるんだ！そもそも必要なのか！？となりました。 昔はcommons-logging＋log4jというのがトレンドだった訳ですが、今はslf4j＋logbackがトレンドになり、jdkも1.4から1.7になり、これらトレンドが推移する過程で、いろいろなjarが旧式に依存してしまい、旧式依存を解決するためにアダプタが登場し始め、mavenでjarを収集すると大抵両方入ってしまい、カオスになっているのです。 特にs
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
