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

締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;

これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。前提となるプロジェクト今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。細かい仕様は決まっていないが、作るものの要件はある程度明確であるアジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。プロジェクト初期にやっておきたいことは何か上記のようなプロジェクトの

n314 2020/07/28

最初は100の仕事を100の期間でやる予定だったのに、締め切り間際だと完了済み100プラス追加修正100あるんだよね。

リンク

知識ゼロからElasticsearchを実践で使えるようになろう！ - $shibayu36->blog;

以前少しだけElasticsearchを触った時に、自分流Elasticsearch入門 - $shibayu36->blog; というElasticsearchに入門した時のメモをまとめていた。しかし、その頃はElasticsearchを使って完全に一人で一つの機能を作るというところまではいけなかった。最近になってまたElasticsearchを一から導入する仕事をすることになった。この時以前自分がまとめた記事を読みながらやっていたのだが、実践で一から導入するためにはこの記事だけでは知識が足りなかった。そこで、前の記事の知識をベースに、一から導入するために少しずつ学んでいき、自分のブログにまとめるなどのことをしてきたので、今回はその締めくくりとして、知識ゼロからElasticsearchを使えるようになるために学習したことについて書いておきたいと思う。今回書くこと・書かないこと今

n314 2018/10/09

elasticsearch

リンク

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

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

n314 2018/10/09

elasticsearch

リンク

PostgreSQLでSQLチューニングや障害状況調査に使ったクエリ達まとめ - $shibayu36->blog;

最近PostgreSQLでSQLチューニングや、DBが詰まった時の状況調査をいろいろやった。その時に便利だったクエリ達をまとめていく。PostgreSQLのバージョンは9.6系です。 SQLチューニングなどに便利だったクエリ達それ以降に実行するSQLの実行時間を表示する。参考 https://morumoru00.wordpress.com/2011/05/08/postgresql-sql%E5%87%A6%E7%90%86%E6%99%82%E9%96%93%E3%82%92%E8%AA%BF%E3%81%B9%E3%82%8B%EF%BC%88timing/ \timing 実際にクエリを実行して実行計画や実行時間を表示する。クエリが実行されるので破壊的な操作も実行されてしまうことに注意。トランザクション張って最後にROLLBACKしましょう。参考 https://www.post

n314 2018/04/10

postgresql

リンク

ioドメイン障害を理解するため、DNSの仕組みについて勉強した - $shibayu36->blog;

先日、ioドメインの障害があったのだけど、自分がDNSの仕組みをよく分かっていないせいで、いまいちどういうことが起こっていたのか把握できなかった。そこで、DNSの仕組みについて軽く勉強したので、そのメモを残しておく。内容は間違っているかもしれないので、その場合は指摘してください。 DNSについて学んだこと Software Design 2015/4のDNSの教科書が非常に勉強になった。また、インターネット10分講座‥DNSキャッシュ - JPNICも参考になる。権威サーバとフルリゾルバまず、DNSサーバには権威サーバとフルリゾルバの二つの種類が存在する。権威サーバドメインの情報を管理し、自分の管理しているゾーンの情報を提供するだけのサーバ問い合わせたドメインが自分のゾーンの管理下ではない場合、別の権威サーバへ委任するという情報を返すコンテンツサーバとも言われる?例) co

n314 2017/10/04

digだけ打つとルートサーバー一覧が出るので、そこから dig www.hatena.ne.jp ns @a.root-servers.net みたいにして自力traceすることが多い。

リンク

関数の仕様を正しく実装していることをどう保証するのか - $shibayu36->blog;

静的型チェックがあったらテストはあまり書かなくて良いのか - $shibayu36->blog; で静的型チェックがあったとしても、テストをあまり書かなくて良いわけではないという話を書いた。するとブコメでいろいろ意見をもらえた。これらの意見から、関数の仕様を正しく実装していることをどう保証するのかについてもう少し深く考えてみようと思い、その考えがまとまってきたので、ブログに書いておく。一応前提として、今回の話は自分の経験とこれまでの本を読んだ知識を元に自分で考えたものであり、何かの理論に則って話しているわけではない。この部分が違うなどあれば突っ込みを受けたい。今回考える仕様このようなことを考える時、非常にシンプルに考えたほうが理解がしやすいので、以下の様な仕様を持つ関数addNaturalIntを考える。関数addNaturalIntは正の整数を二つ受け取り、足しあわせて正の整数を

n314 2016/10/19

“非常にシンプルに考えたほうが理解がしやすい”そうなのかな。複雑になればなるのど効果を発揮する印象がある。

リンク

静的型チェックがあったらテストはあまり書かなくて良いのか - $shibayu36->blog;

昔に動的言語だとひたすらテストを書かないといけないけど、静的型チェックの仕組みがあればそんなにテストを書かなくてもいいよねみたいな話があった記憶がある。昔は結局どうなんだろうと思ってたのだけど、最近もそういう話を耳にして、やっぱりそんなことないだろうという気持ちになったのでメモ。ふと思いついただけなので正当性は分からない。まずなぜそのような話になるのか考えたのだけど、「静的言語ならコンパイル時に型チェックをすることができるため安全性を高められる」という点からこういう話が上がってきているように思う。しかしよく考えてみると、静的型チェックという仕組みは、プログラムテキストとして正当であるかという点しか保証していない。つまり、特定の変数が必ずその型であるとか、特定のエンティティからのメソッド呼び出しが正しいか(メソッド名や引数など)とか、関数が返す型がかならず指定した型になるかとか、そのような

n314 2016/07/16

動的 vs 静的のはずが Java vs Haskell のような話に発散した記憶がぼんやりある。違うところ見てたかもわからんが。

リンク

つかまらない上司にならないために - 1分間マネジャーの時間管理を読んだ - $shibayu36->blog;

1分間マネジャーの時間管理パンローリング株式会社Amazon ﹁1分間マネジャーの時間管理﹂を読んだ。非常に面白く、勉強になることが多かった。この本は、マネジャーが時間に追われている状況をどう解決するかについて教えてくれる。この本においてプロジェクトにおける﹁次の対応﹂はサルと表現され、マネジャーが時間を作るためにはこのサルの管理をうまくしなければならないというような話で、時間に追われている状況の改善方法について説明している。書き方自体も時間に追われたマネジャーを主人公として物語風に進んでいくので、非常に読みやすく面白かった。上に書いた通りの話なので、マネジャーになってなぜか忙しくなったと思う人は是非読んでみると良さそう。確かにそれで忙しくなってるわーみたいなことがいろいろ書かれているので参考になると思う。この本の中でメインとなるポイントはオンケン流サル管理の心得三つの時間をや

n314 2014/09/25

リンク

なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;

最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、﹁アジャイルな見積りと計画づくり﹂を読んだ。アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイクコーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと

n314 2014/03/25

リンク

自分が入れたEmacs便利拡張・設定集 (2013年版) - $shibayu36->blog;

年末emacs設定大掃除をして、これは捨てられないと思った設定書いてく - $shibayu36->blog; 昨年に引き続き、2013年の自分のemacs.dを振り返るのをやろうと思います。今年はemacsでいろいろできるようにする、という方向よりも、emacsでの基本操作をどれだけ使いやすく出来るかということを中心にやって来ました。例えば .emacs.dの管理をどうするかコードリーディングや編集を速くするにはどうするかgitとの連携をどうやって簡単にするかこの辺りについて1つずつまとめて行きたいと思います。 .emacs.dを管理する .emacs.dの管理って難しいですよね。僕も関西Emacsに参加してから自分が最新のやり方についていけてないなと感じたので、今年はいろいろと見なおしてみました。基本的なやり方としてはこんなかんじです。外部elispはpackage.elと