The end of the year is rolling around and it’s time to remind everyone about that yyyy works the way you think it does and YYYY does not. Here’s a quick example to start: Just because you test a format quickly with the current date and get back the result you expect, does not mean you’ve constructed your date format correctly. Speaking of which, BJ Homer points out that you can just use “y”, as “y
結論 まず最初に急いでる人向けに結論を先に書いておきます。2つの違いは以下の様に成っています。 yyyy 年(西暦)を出力 YYYY ある年における「最初の木曜日を含む週が、その年の第1週である」というルールで年(西暦)を出力。 例えば 2015/1/1 は木曜日なのでその週の日は日曜日〜土曜日まで全て2015年の第1週という解釈になります。この場合には2014年で有る、 2014/12/28(日曜)〜2014/12/31(水曜) の時でも YYYY では 2015 を返します。 きっかけ Podcast で Rebuild の第73回を聴いていたら日付フォーマットで yyyy ではなく、YYYY を使った為に Twitter の Android クライアントで不具合が出たという話が出てきました。 ※根本的な原因はこのルールでサーバ側が実装されていた為、 Android クライアントで正し
ログの出力内容は意外と設計時に考慮不足で、コーディング時にプログラマのスキルに依存する事が良くあります。 何も問題がなければそれでもよいのですが、エラーメッセージが表示された場合に、どこで何が起きているのか？探すのにログが適切出ないと時間がかかり、利用者への迷惑だけではなく、担当者の作業時間も大きく関係してきます。 そんな背景もあり「６Ｗ２Ｈ」の観点で、設計段階で考えるログ設計の考慮事項を整理してみました。 Index ６Ｗの項目 ２Ｈ＋１Ｗの項目 まとめ ６Ｗの項目 出力日時 – [When] ・年月日時分 ・秒やミリ秒の出力は必要か検討 ・出力時間はUTCかそれとも日本時間か検討 補足: 年月日時分はログとして当たり前の項目ですね。秒・ミリ行はシステムの性質から必要可否を選ぶと思いますが、基本は出しても良いと自分は思います。 意外と見落としなのは基準時間をUTCにするのか、それとも日本
LZ4 explained
At popular request, this post tries to explain the LZ4 inner workings, in order to allow any programmer to develop its own version, potentially using another language than the one provided on Google Code (which is C). The most important design principle behind LZ4 has been simplicity. It allows for an easy code, and fast execution. Let's start with the compressed data format. The compressed block
Constant Database, known as cdb, is an elegant data structure proposed by D. J. Bernstein. It is suitable for looking up static data which is associated with arbitrary byte sequences (usually strings). Although DJB already explained this in his cdb page, it is not easy to implement this because his document lacks some important information such as the number of each subtable. Here I tried to illus
BER(Basic Encoding Rules) ＢＥＲは元々はＡＳＮ．１で定義された唯一のコード化方法でした。 １９８５年の仕様からＡＳＮ．１はデータ型の記述言語とコード化の定義が分離され、 他のコード化も可能とされ、実際に１９９４年にＰＥＲが定義されました。 現在でのＢＥＲおよびＢＥＲから派生したＣＥＲとＤＥＲがＡＳＮ．１のコード化方法の主流です。 1. ＴＬＶ符号化 ＢＥＲはＴＬＶ符号化とよばれる基本技術を用いています。 ＴＬＶ符号化は情報の符号化を情報タイプ（Type）、長さ（Length）、値（Value）の３つで構成します。 符号化データを解釈する場合、情報タイプにより情報の種別を特定でき、長さにより情報の終端を検知します。 タグフィールド：ＡＳＮ．１データ型を示す。 長さフィールド：符号化された情報オブジェクトの値の長さを示す。 内容フィールド：符号化された情報オブジェクト
パソコンで最もよく利用されているエンコーディングの一つがシフトJISなのだが、その誕生については、なかなかまとまった資料がない。当時の関係者の証言を断片的にまとめたものしかない。 まづ小形さんの以下のBLOGとコメントを読む。当時の当事者が証言をしている。 http://d.hatena.ne.jp/ogwata/20051228/p1 シフトJISを発明したのは誰か？ http://d.hatena.ne.jp/ogwata/20051229/p1 シフトJISを発明したのは誰か？(2) http://d.hatena.ne.jp/ogwata/20051230/p1 「BASIC80を漢字化した経理専用マシン」のこと http://d.hatena.ne.jp/ogwata/20060102/p1 たくさんのコメント、ありがとうございます 安岡さんの日記も参考になる。 http://s
Introduction numfmt is a new command released with coreutils 8.21 in Feb 2013. In its most basic usage, it can be used to generate a "human readable" number like: $ numfmt --to=si 4576881213 4.6G $ numfmt --to=iec-i 4576881213 4.3Gi There have been a few requests for a general utility that could convert values to/from human-readable formats. Pádraig Brady planned the original interface. Assaf Gord
LTSV が行指向な Key-Value フォーマットで捗る話 - naoyaのはてなダイアリー で試作した LTSV のフォーマッタが思いの他捗ったので ltsview という名前でもう少し機能を整えてみました。 Text::LTSV に同梱する形で先ほど CPAN に shipit したので、CPAN で取得可能になったら cpanm Text::LTSV で ltsview ごとインストールされるはずです。なお github は https://github.com/naoya/perl-Text-LTSV です。 $ cat example/example_log.ltsv time:05/Feb/2013:15:34:47 +0000 host:192.168.50.1 req:GET / HTTP/1.1 status:304 size:0 referer:- ua:Mozil
ここ数年のデータ解析の重要性の高まりから、ログに関するソリューションが方々で活発に探求されている昨今でございます。ウェブサーバーの単純なアクセスログをそのまま保存するではなく追加情報を添加してみたり、あるいはアプリケーションから直接ログを吐いてそれらをデータウェアに投げ込んで･･･というのも当然のように行うようになりましたね。 しかしあまり自由度のない access_log の combined フォーマット。さてどうしたもんか･･･ ここで id:stanaka の登場です。 Labeled Tab Separated Valueというのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからflue
追記(2/8 11:30) id:naoyaによる一連のまとめが【今北産業】3分で分かるLTSV業界のまとめ【LTSV】 - naoyaのはてなダイアリーにあります。 また、仕様などをまとめるために http://ltsv.org/ を立ち上げました。 追記ここまで Labeled Tab Separated Values (LTSV) というのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからfluentd、Apache Hiveまで幅広く便利に使えています。 ログフォーマットに期待されることは、 フォーマットが統一されている → 共通のツールで集計し易い 新しいフィールドの追加が容易 → サー
こんにちは、combinedログ撲滅委員会のひろせです。 ApacheのcombinedやNginxのデフォルトのlog_formatは、機械処理(日付でのソートやパース)がしづらい上に、人の目にもあまり見やすいフォーマットとはいえないと思っています。 なので自宅のサーバーでは、 日付は ISO8601 にする sortコマンドとかで簡単にそぉーっとソートできるようになる 日付、レスポンスコード、所要時間とか固定長的なフィールドは左に寄せる URLとかUAとか可変長で長いのは右に寄せる リクエスト(%r)も右に寄せた方ががいいような気がしてきた。。。 数値だけだとわかりづらいのでなんとなくわかるようにフィールド名も添える フィールド名を長くするとわかりやすくなる反面、ログサイズが大きくなるので注意 という観点で次のようなログフォーマットにしています、 # Apache LogFormat
ISO 8601 is an international standard covering the worldwide exchange and communication of date and time-related data. It is maintained by the International Organization for Standardization (ISO) and was first published in 1988, with updates in 1991, 2000, 2004, and 2019, and an amendment in 2022.[1] The standard provides a well-defined, unambiguous method of representing calendar dates and times
日付の表記方法は、文化的な背景の違い、また用途の違いによって様々なフォーマットがあります。多くの場合、特に断り無く使っても問題なく正しい日時を伝えることができますが、文脈や利用者の環境によっては、意外な落とし穴にはまることもあります。誤解なく、かつ効率的に処理しやすい日時表記方法としては、2001-08-02T10:35Zというスタイルの、ISO/W3Cフォーマットがあります。 文化と日付表記 日時表記の国際標準とW3Cノート W3Cの日時フォーマット XML Schemaの日時データ型 タイムスタンプのインターネット標準 そのほか広く用いられる日時の書式 ピリオド区切りによる日付 電子メール、HTTPヘッダなどの日時表記 継続期間の表記 ISO 8601の期間表記 Dublin Coreの期間表記 読みやすさと処理しやすさのバランス 参照文献 文化と日付表記 よく見かける日付の表記法とし
We couldn’t find the page you are looking for. Perhaps you can try searching:
Java言語のコードの書式のひとつとして、fluent interface（流れるような*1インターフェース）という書き方が知られています。 http://capsctrl.que.jp/kdmsnr/wiki/bliki/?FluentInterface 構文的にはSmalltalkのようにメソッドの戻り値にメッセージ送信対象のオブジェクトを返却することで、一文で複数のメソッド呼び出しを行うという書き方です。以前、多くの日本人がオブジェクト指向プログラミングを苦手とするのは英語アレルギーだからか？ - 達人プログラマーを目指してで書いたように、英語脳になってないと必ずしもうれしくないこともありますが、英語の得意な外国人にとっては自然言語のように分かりやすく簡潔に記述できることもあり、最近のAPIでは結構流行しているようです。厳密にはFluentではないかもしれませんが、形式上チェーンで呼
はじめに CSVファイルは最も普及したデータ交換用フォーマットですが、さまざまな方言があります。 本稿ではCSVファイルフォーマットの仕様とデータ交換時のポイントを説明します。 対象読者 CSVファイルを扱うDB管理者、開発者。 CSVとは？ CSVとはComma-Separated Valuesの略で、カンマ区切りで並べた値という意味です。 CSVファイルの例として、一般的なアドレス帳データを示します。 "姓","名","生年月日","郵便番号","住所","電話番号" "山田","太郎","2001/1/1","100-0002","東京都千代田区皇居外苑","03-1234-5678" "山田","次郎","2001/1/2","251-0036","神奈川県藤沢市江の島１丁目","03-9999-9999" カンマで区切られたデータの横一列を"行"（英：Row）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
