自分流Elasticsearch入門 - $shibayu36->blog;
【2016/09/10追記】 勉強しなおして、Elasticsearchの知識についてさらにまとめた記事を書いたので、そちらを参照してもらうと良さそうです。 blog.shibayu36.org 最近Elasticsearchの勉強をした。ただ、入門のためどのような資料が適しているかを知るのが大変だった。そこでどのように勉強したかについてメモをしておく。少しまとめエントリー的なノリになりそう。 Elasticsearchの概念を知る 全文検索技術の基本を知る Elasticsearchのドキュメントのたどり方を知る の順に学習を進めていった。 Elasticsearchの概念を知る Elasticsearchの学習を始めようとした時に、まずは基本からということで以下の本を読んでいた。 高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍) 作者:Ｒａｆａｌ
elasticsearchにwikipediaのデータをインデックスする - $shibayu36->blog;
elasticsearchの機能を試すように何かしらデータを入れてみたかったので、wikipediaのデータをelasticsearchに適当にインデックスしてみた。 wikipediaのデータセット wikipediaのデータセットは Wikipedia:データベースダウンロード - Wikipedia 辺りからダウンロードできる。いろんなデータがあるが、今回はhttp://dumps.wikimedia.org/jawiki/latest/ の中にあるpages-article1.xml.bz2辺りを利用する。 wikipediaデータのインデックス https://github.com/shibayu36/wikipedia-elasticsearch にサンプルを置いてある。 perlで適当に書いているので、最初にcarton installだけしておいてください。 elastic
第10回elasticsearch勉強会に行ってきました - $shibayu36->blog;
elasticsearch.doorkeeper.jp 最近elasticsearchを触ることがあるので勉強会に行ってきました。 今回のなかで個人的に一番面白かったのは@mats116さんの「AWSで実現するelasticsearchの大規模運用」という話。nodeをmaster/data/searcher/indexerという役割に分けて、インフラを構成しているという話がなるほどという感じ。ある程度大規模になると大体master/data/searcherみたいな構成になりそうに感じる。searcherの部分はhttp.enabledをfalse、node.dataをfalseにするといっていたので、なんかのライブラリを利用してtransport層で通信しているのかなと思った。 またjohtaniさんの紹介していたelasticonの発表の中で、以下の話が面白そうだったので時間がある時
Scala入門してる - 演算子編 - $shibayu36->blog;
コップ本読みながら、Scala入門してる。今は第05章の基本型と演算子を読んでる。 Scalaの演算子はすべてメソッド呼び出しらしい。分かりやすくて良い。 例えば val x = 1 + 1 は val x = (1).+(2) と同じらしい。分かりやすい。 単項演算子みたいなのもあると思うのですが、これはunary_hogeみたいなのにマッピングされるみたい。つまり val x = -1 は val x = (1).unary_-() と同一って感じっぽい。分かりやすい。 ちなみにすべてのメソッドは中置演算子のようにできるみたい。例えばStringのindexOfは単なるメソッドだけど、中置演算子として書ける。 val s = "Hello, world!" s indexOf 'o' これを利用することで、for文で使ってたtoがなぜああいうふうに使えるか分かる。 for (i <-
評価制度の目的とは何か考えてみる - $shibayu36->blog;
最近どのような人事評価制度が良いものなのか考えている。どういうシステムが良いかを考えるためには、まずは人事評価制度はどういう目的で行われるのかを考える必要があると思い、まずは人事評価制度は何なのかについて自分なりに考えてみたいと思う。 今のところいくつかの本を読んで、自分の意見をまとめているという段階なので、中身の正確さは保証できない。間違っているところなどあれば指摘してもらえると。 人事評価制度の目的は何か 「そうか、君は課長になったのか。」「マネジメントとは何か」「1分間マネジャーシリーズ」など、いくつかの書籍を読んだ所、人事評価制度はマネジメントという文脈で非常に重要なポジションであることが見てとれた。 これらの書籍を見る限り、以下の様なものが人事評価制度の目的となるのではないかと考えている。 報酬による外的モチベーションの管理 社員教育の促進 会社の方向性を社員に伝搬させる 報酬に
学習のため書籍を読むときは明確に目的を決める - $shibayu36->blog;
僕は学習をする際には書籍を参考にするのが好きだ。なぜネットとかではなくて書籍を参考にするかというと、書籍のほうが学びたい事柄についてネット情報や人から教わるのと比べて、どちらかというと体系的にまとめられていると思っているためだ。 ただし書籍を参考にしている時によく陥りがちなのが、「学習する」という目的を忘れて、「本を読み切る」という事自体が目的化してしまうことだ。こうならないため、僕はこの書籍を読む目的をはっきり決めるようにしている。その目的が大体3つくらいの種類に分類されてきたので、今回はそれについてまとめてみようと思う。 三つの目的のどれかを選ぶ 僕の中で学習目的で書籍を読むときは以下の三つの目的のどれかに絞っている。 これからの課題を解決する方法を見つけるための読書 これまでうまくいったことの言語化を行うための読書 視野を広げるための読書 この三つのどの目的で本を読むか、自分の中で明
会社は儲けるためにあるのか - $shibayu36->blog;
以前、「会社は儲かればいいのかもしれないけど」というワードを聞いたことがあって、今から考えるとそうではないんじゃないかな―と思ってきたので、適当にメモとして残しておく。 今のところの個人的な意見としては、会社は儲けるために存在するのではなくて、社会的に価値を提供するために存在し、そして社会的に価値を提供した結果、自然と儲かるだけであると考えている。ただし、以下の様なことから少し問題を複雑にしているとは思う。 社会的に価値を提供し続けるためには、儲かっていなければならない 価値というのは、それが人に理解されなければ発生しない このへんの話いろいろ難しいのだけど、会社は儲けるためじゃなくて社会に対して明確な価値を提供するために存在していると僕は考えていたいし、その価値を提供し続けるために儲かっている状態を作り出さないといけないとも思う。ただし、これを逆転させてはならなくて、儲けるために会社の提
2014年に読んだ本の中で、年末年始に読みたいおすすめ本を紹介します - $shibayu36->blog;
年末年始休暇は読書チャンスということで、僕が2014年に読んだ本の中で年末年始に読みたいおすすめ本を紹介します。それ以外の本は http://blog.shibayu36.org/archive/category/bookにていろいろ紹介しています。 マネジメント編 今年はマネジメント関連の本をひたすら読んだので、この辺りのおすすめが多めです。 そうか、君は課長になったのか。 平易な言葉でマネジメントのエッセンスを教えてくれる「そうか、君は課長になったのか。」はマネジャー数ヶ月の人にとっておすすめな本です。200ページくらいでさらった読めます。 そうか、君は課長になったのか。 (ポケット・シリーズ) 作者:佐々木 常夫WAVE出版Amazon 紹介記事 : マネジャーの仕事のエッセンスが学べる「そうか、君は課長になったのか。」を読んだ - $shibayu36->blog; 1分間マネジャ
gojiとgo-xslateを使って、GoでのWebアプリケーション開発入門をした - $shibayu36->blog;
Golangで簡単なwebアプリを作るためにどうしたらいいか調べていたので、試しにGojiというフレームワークと、go-xslateを使ってHello Worldをしてみた。 GitHub - shibayu36/goji-and-go-xslate-sample http://localhost:8000/hello/world にアクセスすると、以下の様なものが出るだけのアプリケーション。 これを作った手順にしたがって簡単に紹介。 作成手順 まずはルーティングを作成 https://goji.io/によると、main関数の中にルーティングを作成してServeすれば良いだけっぽいのでまずはそれを作ってみる。 func main() { goji.Get("/hello/:name", hello) goji.Serve() } これで/hello/{name}でhello関数が使われるよ
「エンジニアマネージャー論と学びを抽出する努力を続けること」を読んで - $shibayu36->blog;
http://wazanova.jp/items/1574を読んで、非常に参考になったのでいつも本を読んで感想書いている時と同様、思うところについて書いてみる。 今回は以下の二つのポイントについて非常に感銘を受けた。 やるべきことを毎日洗い直して、絞り込むことが大切 適切な意思決定プロセスとメンバとの良好な関係が築ければ、95%は大丈夫 やるべきことを毎日洗い直して、絞り込むことが大切 上であげたブログに 真剣にものごとに取組むと、やらなくてはいけないことはそのうち次から次へと気づく and/or 嫌でも湧き出てくるもの。なので、アドバイスを求められれば、やるべきことは最小限、できれば三つ以内に絞って、何をやめることができるかを探す手伝いをするようにしています。やるべきことを毎日洗い直して、絞り込むことが大切。 ということが書いてあり、直近の自分の状況もあいまって非常に納得できる言葉だなと
「イシューからはじめよ」を読んだ - $shibayu36->blog;
最近やることがたくさんあってどうしたら良いか分からなかったので、同僚の薦めもあって「イシューからはじめよ」を読んだ。結構面白かった。 イシューからはじめよ──知的生産の「シンプルな本質」 作者:安宅和人英治出版Amazon この本には、やるべきことがたくさんあった時に、タスクをやる効率をどんどん上げていくという方向にまず走るのではなく、その中で重要なイシューを見極めてそれを重点的に取り組むべきである、というようなことが書かれていた。とにかくやるのではなく、まずやることを見極めよみたいな感じ。確かに忙しい時はとにかくやるとなりがちだけど、とにかくやっててもあんまり成果が上がらないことがあるので、まず見極めないといけないと思った。 この本の中で 悩まずに考える 「これは何に答えを出すものなのか」を明確にしてから問題に取り組む 一次情報を死守 という言葉が印象に残ったので、それについて書く。 悩
実践に繋げるように勉強する - $shibayu36->blog;
遅延評価勉強法だと得られなかったもの - As a Futurist... 漢(オトコ)のコンピュータ道: ヒゲモジャのギークが提案する技術習得戦略 を読んで、なんとなく気分が高まったので、自分の学習のことについて書いてみる。 以下の様なことを書いているつもり。 勉強は実践につなげると知識が定着すると思っている 実践課題を探すのではなくて、実践の目処のあるものを勉強する 一番簡単な実践課題として、自分の言葉でまとめ直すということをしている 実践に繋げる 僕は勉強する時は、いろいろ本を読んだり、情報を調べたりして、まず知識をつけようとすることが多い。ただし、それだけだとだめで、実践しないと知識が定着せず、どんどん忘れていき、結局意味ないということになる。実践大事。 大事なのはわかってるんだけど、実践するのは意外と難しい。本に練習問題あったりすることもあるけどあんまり面白くないし、良い実践課題
挫折しないための英語勉強 - $shibayu36->blog;
最近また英語の勉強をしている。僕自身は全く英語の勉強が続いたためしがなくて、毎回はじめてから1~2ヶ月くらいたつと英語の勉強に飽き、挫折してしまう。けれど今回は何とかして続けたいと思って、いつもとは全く違うアプローチで英語の勉強を続けたところ、今のところ6ヶ月くらい英語を続けられている。 今日はどんな感じで英語勉強してきたか軽く書いてみたい。 挫折しないために決めた方針 これまでは毎回英単語を勉強したり、英語の本を読んだり、英語のニュースを聞いてリスニングの勉強をしたり、といういわゆる英語の勉強をやってきた。でもこれだと自分は挫折するということが分かった。 今回は海外の人と友だちになれればモチベーション維持できるのではと考えて 海外の人と友だちになってチャットしたり会話したりを勉強の中心にする チャットや会話を円滑にするための勉強をする という方向性でやってみた。 効果的だったもの 効果的
開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;
最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。 小さく導入する 短く導入する 振り返る 小さく導入する なんか導入する時は出来るだけ小さく導入してる。 理由は いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。 小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。 小さく導入する方法はいくつかあって スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく
「チーム開発実践入門」を読んだ - $shibayu36->blog;
チーム開発実践入門という本が最近出ていたので、読んだ。 チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus) 作者:池田 尚史,藤倉 和明,井上 史彰技術評論社Amazon この本は良くない開発フローの例をケーススタディとして2章で紹介し、その後の章でそれに対応する形でバージョン管理やチケット管理、テスト、構成管理などの紹介をしている。 なんとなくエンジニアリングの開発フローがうまく行っていないけど、どこから始めていいか分からないという人には非常に面白いと思う。2章のケーススタディの例を読んでみて、その中で確かに自分のチームでもあるあると思えたところを中心につまみ読みしてみると良いと思う。 個人的にはほとんど知っている内容ばかりだったので、どちらかというと事例を含めてもう少し内容があると良かったように思う。 この本を読んでいる中で一番良かったの
レビュータイムの導入・消滅・再導入 - $shibayu36->blog;
今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。 ひさいちレビュー、必ず通すみたいなの良いのか悪いのか— ひさいち (@hisaichi5518) 2014年3月13日 @hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう— 柴崎優季 (@shiba_yu36) 2014年3月13日 @hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。— 柴崎優季 (@shi
「ピープルウェア」を読んだ - $shibayu36->blog;
この前id:hitode909くんからピープルウェアを貰ったので読んだ。非常に面白くて、興味深い話が多かった。 ピープルウエア 第3版 作者:トム デマルコ；ティモシー リスター日経BPAmazon この本はソフトウェアのプロジェクトが失敗する時は、原因が単なる技術的問題だけである場合は少なく、その前段階の人とのコミュニケーションレベルにも問題があるときが多いという話をしている。それでプロジェクトを進める上での人に関する問題をテーマにしている。 最近は個人で作業をするというよりも、チームで仕事を進めるということが多くなりつつあるので、非常に参考になる事が多かった。印象に残った点を書いていく。 早くヤレとせかされると 早くヤレとせかされれば、雑な仕事をするだけで、質の高い仕事はしない 耳が痛い。でも自分自身が言われても直感的にはそうなりそうという感じだと思った。 またこの本の関連する内容に「
レガシーコード改善ガイドを読んだ - $shibayu36->blog;
レガシーコード改善ガイド (Object Oriented SELECTION) 作者:マイケル・C・フェザーズ翔泳社Amazon レガシーコード改善ガイドを読んだ。 この本では、レガシーコードの内部をリファクタリングする際に何を気にする必要があるかとか、非常に長いモンスターメソッドをリファクタリングしていく時にまずどこからやるかとか、そういうことが書いてある。とにかくレガシーコードに直面して何から始めたらいいかわからないという時にはおすすめ。 リファクタリングという本と近い内容だけど、僕の中ではこの本よりはリファクタリングの方がなんとなく肌にあった。また今度再読してみようと思う。 印象に残ったところを書いていく。 依存関係を排除する 「たいていの場合、テストの最大の障害となるのが依存関係です」と書いてあるのだけれど、これは確かにと思った。いつもは無意識にやっているけど、言語化されてよかっ
serfとDockerでクラスタを組んでみる - $shibayu36->blog;
最近Serfというツールも気になっていたので、とりあえずクラスタを組んでイベントハンドラの設定をしてみるところまでやってみました。 Serfとは http://www.serfdom.io/ https://github.com/hashicorp/serf Serf is a decentralized solution for service discovery and orchestration that is lightweight, highly available, and fault tolerant. Orchestrationという層を支援する軽いツールみたいですね。これをうまく使うことで、クラスタにjoinしたweb serverを自動的に配下に加えるHAProxyとかを実装したり出来ます。参考: Serf+HAProxyで作るAutomatic Load Balanc
AWS, chef, Cinnamon等を使った無停止デプロイ(PrePAN carton 1.0化の裏側) - $shibayu36->blog;
最近PrePAN uses carton 1.0 now! - $shibayu36->blog;でも書いたとおり、PrePANのcarton 1.0化を進めていました。 通常であれば変更点をアプリケーションサーバにデプロイし、サーバを再起動すれば良いのですが、cartonを0.9から1.0に上げるというまあまあ大きな変更を加えるため、事前に動作確認を行い、無停止でデプロイしたいと考えました。そこでAWSを使って無停止デプロイを試してみたのでそれについて書こうと思います。 PrePANのサーバ構成やデプロイ手順の検討 無停止デプロイの説明の前にPrePANのサーバ構成を紹介しておきます。 現状はELB 1つに対し、EC2が2台ぶら下がっているという状態で運用しています。そしてEC2に対してはそれぞれapp-1, app-2という名前でタグがついています。 開発メモ#2 : AWS でのホス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
