スキル差の存在を前提としたJava開発の私の理想 - Kengo's blog
スキルの低い人が生産性における問題ならその人を何とかするのが根本解決だよねと話したら、人に強要することなんてできないじゃないですかーという反応をいただいた。 これはすごく的を射たもので、チームを引っ張ってモノづくりをするうえで・チームを引っ張らせてモノづくりをするうえで重要な着眼点になると思っている。 個人の尊厳や主体性は最大限尊重すべきだし、様々な発想を持ち込めること（多様性）こそがチーム結成の価値の1つでもある。もしも開発プロセスやそのツールをガチガチに固めてしまうことで自由なチャレンジができなくなるのだとしたら、それは価値ある生産物を主体的・継続的に提供する能力の低下につながるだろう。そもそも変わりゆく環境の中で、1つのプロセスがずっと最適である保証も無いのだ。 では、どうするべきなのか。基本的には以下の原則を守ることだと思っている。 チーム全員が同じ方向を向こうとすること 気づきの
コピペで始めるSLF4J & Logback | DevelopersIO
SLF4J & Logback JavaのLoggerといえばlog4jで十分なのでlog4jを使ってる場合も多いと思います。 ログの出力性能は最終的にはディスクの速度で決まり、ログ出力の要件は案件が変わってもそれほど変化することもないのでlog4jの定義ファイルもコピペして再利用すればいいですし、新たなLoggerを使うのは手間でしかありません。 今回紹介するSLF4J & Logbackは既存のソースコードに手を入れること無く、しかも他のLoggingライブラリのログ出力も統合できます。 SLF4J SLF4Jはロギング実装を持たず、出力先毎のライブラリを入れ替えることで色々なLoggingライブラリに対応しているFacadeです。 SLF4Jには標準でplaceholderを使えるAPIもあるのでlog4jなどでよく書いてたlog出力前に不要な文字列結合を避けるためのif文は必要なく
Javaライブラリを配布する際のログ周りにおける配慮と実践 - Kengo's blog
2020-07-22更新: 以下の投稿で情報をアップデートしています。 https://blog.kengo-toda.jp/entry/2020/07/21/223136 いつも購読させていただいている id:teppeis さんのブックマークに以下のエントリが流れてきて、なるほどこいつはたしかに厄介だと思いました。 javaのロガーが多すぎて訳が解らないので整理してみました - 文系プログラマによるTIPSブログ ただSLF4Jが最も先進的かつ著名なインタフェースである以上、配布側としてはSLF4Jを使いつつ問題を解決したいところです。他のインタフェースを使ったりオレオレ実装を使ったりしてしまうと、それこそユーザの自由度を奪ってしまう形になります。 実際、SLF4Jを配布パッケージに含めないという簡単な解決法がありますので、簡単に紹介します。悲劇を繰り返さないためにライブラリ開発者がす
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Java好き
Java好き
