key_ambのブックマーク - はてなブックマーク

「世界でもっとも強力な9のアルゴリズム」読んだ - $shibayu36->blog;

なんとなくアルゴリズム系の読み物読んでみたかったので読んだ。世界でもっとも強力な9のアルゴリズム作者:ジョン・マコーミック日経BPAmazon この本は、著者が3つの基準で選んだ「偉大なアルゴリズム」について、エンジニアでなくても分かるような簡単な言葉を使って紹介してくれる本である。以下のようなアルゴリズムについて紹介している。検索エンジンのインデクシングページランク公開鍵暗号法誤り訂正符号パターン認識データ圧縮データベースデジタル署名話題がかなり身近なものであり、説明が本当にわかりやすいため、とりあえずアルゴリズムを学ぶ前の読み物として非常におすすめ。個人的には検索エンジンやページランク、パターン認識あたりが興味深かった。この本を読んで、興味を持った部分について、さらに深く学習をしていくと良いかもと思った。読書メモ ## 検索エンジンのインデクシング - 検索エン

key_amb 2017/01/08

面白そう

リンク

今日のElasticsearch学び Vol.5 - Avoiding Type Gotchas - $shibayu36->blog;

今日はElasticsearch: The Definitive Guideを読んでいて怖いと思ったところについて書く。学びがあったのはAvoiding Type Gotchasという部分。これによると、同一のindexを使っていて別のtypeで定義していたとしても、Luceneからはindex単位でフラットに定義があるように見えるらしい。なので、別々のtypeだけれど、同じfield名で定義していて、かつそのfield名のデータ型がそれぞれのtypeで異なっているとき、コンフリクトが起こってしまうみたい。直感的には、typeが名前空間となり、field名は完全に独立しているというふうに思いがち。変にハマる可能性があるので覚えておく。ちなみにParent-Childなどを利用しないなら、1 index 1 typeがオススメのようだった。 Avoiding Type Gotchasっ

key_amb 2016/08/10

リンク

仕様や実装方針の相談をPullRequestで行う取り組み - $shibayu36->blog;

これまで少し大きめな機能であれば、コードを書く前にまず仕様や実装の方針をissueのdescriptionにまとめ、それを先にレビューしてもらってから実装にとりかかるということをしていた。最近、その方針をそもそもrepositoryのファイルとして書いて、PullRequestしてレビューしてもらうようにしたら便利だったのでご紹介。なぜコードを書く前に仕様や実装の方針をレビューするのか前提としてなぜコードを書く前に仕様や実装の方針をレビューして欲しいのかについて書いておく。これはとにかく手戻りの量を少なくしたいという要求のためである。実装に取り掛かろうとすると、実装の方針はいくつか思いつくが、どれが一番よいか迷うことはよくある。その場合に誰にも相談せず自分だけで判断し、コードを書いてからPullRequestを送った場合、もしその選択に重大なミスがあった場合全て書きなおさないといけな

key_amb 2016/08/06

なるほど。ラインコメントできるのいいな

リンク

いつ突然会社をやめても問題ないという基準でコードやドキュメントを書く - $shibayu36->blog;

先に前提を話しておくと、会社は全く辞めるつもりはないし、むしろどんどん会社を良くしていこうと思っている。今回はそういう基準で自分がコードやドキュメントを書いていますよという話。コードやドキュメントを書く時に、どのくらいきれいにしておくかとか、どのくらいわかりやすくしておくかとかを考えることがある。こんなとき僕は、いつ突然自分が会社をやめて連絡がつかなくなったとしても他の人がある程度理解できるか、を基準にしている。そのためにはあまりいい方法が思いつかなくて仕方なく書いている部分にはちゃんと経緯のコメントを書く。他にも例えば作ったサービスであるイベントを開催する方法のドキュメントを書くなら、全く何もやったことがない人がそのドキュメントを読んだらとりあえず開催できるよう、ドキュメントを書く。当然コードもかっこよさよりも、説明しなくても分かりやすくなるようなシンプルさを追求する。また、このよう

key_amb 2016/08/05

+1 あと「半年後の自分が読んでも理解できるか」とか考えてる。

リンク

プロジェクト単位でElasticsearchのローカル開発環境を作成する - $shibayu36->blog;

最近Elasticsearchを触っていて、まずはローカル開発環境を作ることになった。ただ、Elasticsearchはバージョンがかなり変わり、別プロジェクトと利用したいバージョンが異なっていたので、プロジェクト単位で使い分けるにはどうすればよいかを考えた。やりたいことプロジェクトごとにElasticsearchのバージョンを切り替えられるようにしたい MySQLだったら同じようなものにmysqlenvなどがあるまた、他の人が一瞬で環境を整えられるようにしておきたい利用するプラグインなども含めて一瞬でバージョンを上げる時もローカル環境なら簡単にあげたい作戦 Elasticsearchはここからダウンロードして、特定のディレクトリに展開するだけでも利用できるそこでプロジェクトルートのelasticsearch/ディレクトリ以下に展開し、ここに展開したバイナリを利用するように

key_amb 2016/07/26

リンク

horensoを使ってcronの実行時間を自動でmackerelに記録する - $shibayu36->blog;

最近cronの実行にはhorenso というツールを使って、実行エラーがあればSlackに通知するなどといったことをしている。今回はcronの実行時間をmackerelのサービスメトリックに自動で記録するということをやったのでメモ。やりたいこと crontabに以下の形式でスクリプトを登録すれば、自動でサービスメトリックに記録される horenso --tag (tag名) --reporter=elapsed-time-to-mackerel-reporter.pl -- (実行したいコマンド) 記録は秒数で、小数3桁まで記録する horensoの動き horensoではreporterとして適当なスクリプトを指定することが出来て、そのスクリプトには標準入力に実行のログ等が渡ってくるようになってくる。例えば $ horenso --reporter=test-reporter.pl -

key_amb 2016/07/25

horenso 便利そう

リンク

コードレビューを段階的に行ってもらう話 - $shibayu36->blog;

最近コードレビューをどのように回していくかについて考えたことがあったのでブログに書いておく。コードレビューの目的コードレビューには誤りの発見以外にいろいろな目的がある。自分の中ではid:hisaichi5518が昔プレゼンでまとめていた目的が結構しっくり来ている。 https://speakerdeck.com/hisaichi5518/kodorebiyufalsehua?slide=8 http://hisaichi5518.hatena blog.jp/entry/2014/10/29/165721 機械的に発見できない誤りの発見技術力の向上属人性の排除コードレビューの目的としては誤りの発見と同様に、技術力の向上や属人性の排除といった教育的側面も重要である。コードレビューで課題に思っていたこと自分のチームでは基本的に一人がコードレビューをして、OKだったらmergeをして

key_amb 2016/07/01

レビュアーふやしていきたい

リンク

最近コード中のTODOコメントの書き方を工夫している - $shibayu36->blog;

コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは # TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ... みたいなやつです。コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。 TODOコメントの問題点問題点として次のものがあると考えました。 (1) 書く人によって形式がバラバラ TODO, XXX, FIXMEなどバラバラだったりする (2) TODOコメントの

key_amb 2016/05/09

なるほど。

リンク

自分流Elasticsearch入門 - $shibayu36->blog;

【2016/09/10追記】勉強しなおして、Elasticsearchの知識についてさらにまとめた記事を書いたので、そちらを参照してもらうと良さそうです。 blog.shibayu36.org 最近Elasticsearchの勉強をした。ただ、入門のためどのような資料が適しているかを知るのが大変だった。そこでどのように勉強したかについてメモをしておく。少しまとめエントリー的なノリになりそう。 Elasticsearchの概念を知る全文検索技術の基本を知る Elasticsearchのドキュメントのたどり方を知るの順に学習を進めていった。 Elasticsearchの概念を知る Elasticsearchの学習を始めようとした時に、まずは基本からということで以下の本を読んでいた。高速スケーラブル検索エンジン　ElasticSearch Server (アスキー書籍) 作者:Ｒａｆａｌ

key_amb 2015/07/08

リンク

[perl]DateTimeのtimezoneについてのメモ - $shibayu36->blog;

DateTimeでtimezoneの設定をしたりしたときに、うまく整理できなくてはまったのでメモ。今回はDateTimeでset_timezoneを利用したときにどのような仕様で時間をずらすのかという部分とDateTime::Format::MySQLの仕様を理解できていなかったために、MySQLからデータを取ってきたときにはまってしまった。仕様(?) DateTimeオブジェクトはtimezoneを設定したときに以下の規則で時間をずらしている。 DateTimeのtimezoneがfloatingの時にtimezoneをセットしても、時間は変換されない。つまりその時のfloatingにおける時間を設定したtimezoneの時間とみなす。 DateTimeのtimezoneがfloating以外の時にtimezoneをセットすると、時間はそれらの差分の分変化する。例えばtimezone