mamori017.logスマートフォン用の表示で見るmamori017.log歴史的クソブログこの広告は、90日以上更新していないブログに表示しています。GitHubClickOnceアプリケーションの配布はHTTPで更新ファイルを参照できさえすれば動作するはず。それならGitHubのリポジトリ上でも実現できるのではないかと思ったのでやってみました。いっても既にGitHubでの運用を検討されている方はおられるわけで。リポジトリにプッシュしたファイルを参照する場合、応答ヘッダが異なるため上手くいかないようです。Pages上に配布ファイルを配置した場合の動作はどうなのか。Pages用のgh-pagesブランチを切ったうえでHTMLファイルなりを配置する必要がありました。Pagesも管理できるようになっています。branchを選択し、リポジトリルートにdocsディレクトリを作成します。Pagesが表示されるようになります。ビルドとClickOnceのアプリケーション発行後にリポジトリにプッシュすれば大した手間もかからずアプリケーションの配布環境が構築できるはずです。Pages用ディレクトリ(ClickOnceアプリケーションの配布環境)を含んだmasterブランチの構成を以下の状態にしてmasterブランチへプッシュしてみます。Files|┝ClickOnceApp.application|┗setup.exe┝.gitattributes┝.gitignore┝ClickOnceApp.sln┝LICENSE┗README.mdGitHubから警告メールが届く上記の構成でリポジトリにプッシュしたところ、ClickOnceでのアプリケーションアップデートを実施することができました。リポジトリへのプッシュ直後にGitHubから警告のメールが届いていました。Pagesでバイナリファイル公開しているならRelease機能を使いなさいとのこと。その通りなので何とも言えません。ちなみに、リポジトリ内にバイナリファイルがあるとプッシュするたびに警告メールが届きつづけるみたいです。email.結論ClickOnceのアプリケーション配布自体は可能だったのですが、GitHubが推奨する使用方法ではないのでやるべきではないです。配布するアプリケーションバージョン管理が必要になったら、CodeCommitからS3にデプロイするのが現実的に考えて楽なのかなと思っています。dev.classmethod.jp警告でアカウントがBANされても困るのでGitHubのサポートにメールで謝っておきました。見る*1:rawgitというサービスを使えばReleaseにアップしたデータを参照できるらしい。BindingSourceクラスのFilterプロパティが使用できる。(System.Windows.Forms)手順DataGridViewにバインドしたDataSourceをDataTableとして取得する。DataTableをBindingSource.DataSourceプロパティにセットする。BindingSource.Filterプロパティに絞り込み条件を設定する。Filterに設定した条件で絞り込みされた結果がDataGridViewに表示される。TextChangedイベントが発生するたびにフィルター処理を呼ぶようにハンドラを追加する。見かけ上分かりやすかったのでTextChangedをイベントに指定しているが、このイベント自体は別に何でも良い。絞り込み条件の記述を整形し、BindingSourceにデータと絞り込み条件を設定する。'%Pink%'となる。あとはこの条件式をBindingSourceにセットすることでDataGridViewの表示状態は以下のように変更される。Pink記述した内容だと入力の都度TextChangedイベントが発生してしまう。Pink、Pink、Purpleの3件が表示される。このあたりの振る舞いは別のイベントで制御するほうがスマートかもしれない。*1この記事は今度書き直す。*1:とはいえEnterキーとか検索ボタンをトリガーにしたくないという要望があってこのまま実装した。LogstashヤマハRTX1200のsyslogにURLフィルターのログを出力するようにしています。このURLフィルターのログをLogstashを使用してelasticsearchに登録し、kibanaで可視化してみました。使用するログsyslog全体から以下のログを抜き出しテストで使用しました。http://hatenablog.com/?via=201002Grokフィルターパターンの作成このログをGrokフィルターで項目ごとにパースします。[URL_FILTER]...からはじまるデータのみ対象になるようフィルターパターンを作成します。Grokのパターンは以下を参照しました。Debuggerを使用しながら作成しました。Debuggerは入力したいログとパターンを入力することでテストしながら作成ができて便利です。Debugger今回は以下のようなフィルターパターンを作成しました。作成したフィルターパターンをlogstash/conf.d/pipeline.confに記述します。/etc/logstash/conf.d/pipeline.confログファイルは先頭から読み込みます。テストなのでインデックスも特に指定していません。}}Logstashを起動しelasticsearchにデータを登録します。startelasticsearchの確認elasticsearchにデータが登録されているか見てみます。localhost:9200/_cat/indices?vテストで使用したログ17行が取り込まれています。インデックスは指定しなかったのでlogstash-2018.02.17で作成されています。57.5kbkibanaで可視化kibanaで取り込んだデータを見てみます。Discoverでelasticsearchにデータを取り込んだ時間ごとの件数と生のデータを見ることができます。取り込んだデータを選択するとGrokフィルターに記述した通りにデータがパースされている事が確認できます。Grokフィルターでパース出来なかったデータについては、tagsに_grokparsefailureと記述されています。取り込んだテストデータの1行目、6~9行目、12、13行目が該当していました。取り込んだデータが想定通りにパースされていたのでVisualizeで可視化してみます。Pieチャートでデータを見てみたところ、初期状態では取り込んだ全17件がCountで表示されています。Slicesを選択し、AggregationでTerms、Fieldでurlhost.keywordを選択します。Changes(▷ボタン)をクリックするとチャートが分割されます。ここでチャート内にカーソルを当てると各データのカウントを見ることが出来ます。このとき、テストで使用したデータの17件のうち7件はGrokフィルターに当てはまらなかったデータになるのでチャートの対象は10件になります。逆にTermsでtags.keywordを選択すると、10件のデータにはtagsに値が無いので_grokparsefailureの7件が結果として表示されます。Tableを選択します。RowsでAggregationでTerms、Fieldでurlhost.keywordを選択すると各データの件数が表示されます。Visualizeは画面右上のSaveから設定を保存することができます。データを取り込んだ結果Grokフィルターでデータをパースできることを確認できたので、とりあえず手元にあるデータ150000件を登録してみました。見た感じやはりというか広告、CDNと思われる場所とのアクセス数が多い気がします。Barで日ごとのアクセス先が可視化できるようにしました。Kibanaの運用は当面これでやっていこうと思います。見る*1:syslogで対象としたいログはこれだけではないので、フィルターはGistで更新していく。Chartでログ出力日、出力月ごとに、URIでグラフを分割するようにしています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。