評価制度の目的とは何か考えてみる - $shibayu36->blog;
最近どのような人事評価制度が良いものなのか考えている。どういうシステムが良いかを考えるためには、まずは人事評価制度はどういう目的で行われるのかを考える必要があると思い、まずは人事評価制度は何なのかについて自分なりに考えてみたいと思う。 今のところいくつかの本を読んで、自分の意見をまとめているという段階なので、中身の正確さは保証できない。間違っているところなどあれば指摘してもらえると。 人事評価制度の目的は何か 「そうか、君は課長になったのか。」「マネジメントとは何か」「1分間マネジャーシリーズ」など、いくつかの書籍を読んだ所、人事評価制度はマネジメントという文脈で非常に重要なポジションであることが見てとれた。 これらの書籍を見る限り、以下の様なものが人事評価制度の目的となるのではないかと考えている。 報酬による外的モチベーションの管理 社員教育の促進 会社の方向性を社員に伝搬させる 報酬に
見学のときに不動産屋に質問して得た有益情報 - $shibayu36->blog;
良い物件ではなく良い不動産屋を探した - $shibayu36->blog; 先日の物件探しの見学のときに、不動産屋のこと全く知らないし質問チャンスと思っていろいろ聞いたのだけれど、いろいろと内容が面白かったので公開します。ちなみに京都で、かつその不動産屋で、ということなので、一般的ではないかもしれません。 その部屋が隣の音漏れがあるかとか運ですよね 雑談してて、部屋の間取りとか条件とかは情報で得られるけど、壁の音漏れとか、条件に入ってこないところとかもあったりして、そういう部分を含めると引っ越しは運ですよねーって話をしてたら、有益情報を得られた。 正確さは保証できないが、実は壁の音漏れなどの情報を得ることも出来る そういう条件に入ってこない悪い部分があると、住人が管理会社に何度もクレームを送って、対応されないから退去ということが起こる可能性がある なので、退去理由やクレームの量・内容を、
良い物件ではなく良い不動産屋を探した - $shibayu36->blog;
いろいろあって今の家から引っ越すことになった。 良い物件どうやって探したらいいか分からなかったので、適当にググって http://nanapi.jp/286/ を実践してみたら、結果的にうまく行ったので経験をメモ。 結論 良い物件を探すのではなく、良い不動産屋を探すという方法にしたところ、僕の性格としては上手く行った 今回の流れ suumoやhomesで住みたい場所の物件を眺める 希望条件をまとめる 不動産屋を選んでメールしまくる 良さげなところを数社に絞って、さらに送られた物件見ながら返信してみる 一番いい感じに返答してくれた雰囲気の店に行って相談 suumoやhomesで住みたい場所の物件を眺める http://nanapi.jp/286/ とやってることは一緒なので割愛 希望条件をまとめる http://nanapi.jp/286/ とやってることは一緒なので割愛 不動産屋を選んでメ
挫折しないための英語勉強 - $shibayu36->blog;
最近また英語の勉強をしている。僕自身は全く英語の勉強が続いたためしがなくて、毎回はじめてから1~2ヶ月くらいたつと英語の勉強に飽き、挫折してしまう。けれど今回は何とかして続けたいと思って、いつもとは全く違うアプローチで英語の勉強を続けたところ、今のところ6ヶ月くらい英語を続けられている。 今日はどんな感じで英語勉強してきたか軽く書いてみたい。 挫折しないために決めた方針 これまでは毎回英単語を勉強したり、英語の本を読んだり、英語のニュースを聞いてリスニングの勉強をしたり、といういわゆる英語の勉強をやってきた。でもこれだと自分は挫折するということが分かった。 今回は海外の人と友だちになれればモチベーション維持できるのではと考えて 海外の人と友だちになってチャットしたり会話したりを勉強の中心にする チャットや会話を円滑にするための勉強をする という方向性でやってみた。 効果的だったもの 効果的
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと
仕事の仕方が悪かった - $shibayu36->blog;
ここ最近全く仕事に対してモチベーションが湧かなくて困ったと思っていたけど、仕事のやり方が悪かったせいと気づいた。IRCを見すぎていた。 仕事するときに基本的に集中力を落とすようなものは出来るだけ見ないようにしていた。例えばtwitterを見ないようにクライアントは立ちあげないとか、あえてクライアントを立ち上げるショートカットキーを設定しないとか。 とは言えIRCとかは仕事でコミュニケーションするときに使っていて、それを落としてしまうとコミュニケーションが困難になる。なのでIRCは立ちあげないことはせず、気にならないようにTotalSpacesみたいなものを使って別windowに押し込めるとかしていた。 IRCを別windowにしたといっても、実際にはショートカットとかで簡単に見れてしまっていて、慣れてしまうと結局IRCを見てしまっていた。結果として、集中力を欠き、仕事の進み方が遅くなり、い
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 でのホス
いろいろなツールをplenvに移行した - $shibayu36->blog;
最近はplenvを使うべきって感じだったんだけど、promptとかemacsとかを対応させるのがちょっと面倒でサボっていた。そろそろやばいと思ったので全部plenvに移行した。 インストール macだったらbrewで提供されているので入れる。https://github.com/tokuhirom/plenv を参考に。 $ brew update $ brew install plenv $ brew install perl-build $ plenv install 5.14.2 # お好みのperl入れる $ plenv shell 5.14.2 $ plenv install-cpanm promptに現在利用しているperlのversionを出力する 以下のように、promptにperlのversion出てるとうれしいのでそういう感じにする。 plenv version-nam
「電書はてなブログ 準備号」読んだ - $shibayu36->blog;
[asin:B00DW3FDE0:detail] 身内びいきかもしれないけど、面白かった。 寝る前にちょっと読んでみるかとか思ってiphoneで読み始めたら、そのままさくさく最後まで読んでしまった。なんとなく一気に全部読みきれるこのくらいの分量的がちょうど良いのかもしれないと思った。 内容的にも意外と読んでないものが多かった。 印象に残ったのは二つ。 マクドナルド苦戦の理由を「てりたまバーガーセット」を食べながら考えた 愚妻 てりたまのやつはファストフード店に関する考察がなかなか面白いと思った。マクドナルド行かないから実感はないけれど。 maymaoさんの「愚妻」はブログの時点でも読んでいたのだけれど、電子書籍になってみてもう一度書籍として読むと、更に心を打つものがあった。温かい気持ちになれる。 自分の関わるサービスからこのような良いコンテンツが生まれるのはなかなか感慨深い。今後も良いコン
nekokakさんを呼んで、7/13(土)にKyoto.pm 05 Tech Talkを開催します！！！！！ - $shibayu36->blog;
前回からしばらく経ったので、そろそろKyoto.pm 05 Tech Talkを開催しようと思います。 Kyoto.pm 05 Tech Talkに参加する 今回はJPAの講師派遣プログラムを利用して、DBix::SkinnyやTengの作者である@nekokakさんに来てもらうことになりました！@nekokakさんに話していただきたいことを、参加フォームのアンケートで募集しています。この機会に是非リクエストしてみてください イベントの詳細は以下の通りです。 日時 : 7/13(土) 15:00- 場所 : 株式会社はてな 8F(http://www.hatena.ne.jp/company/location) 参加費 : 500-1000円 懇親会 : その場でかどこかに行きます(2000円-4000円) 参加は以下のボタンからZusaarで登録をお願いします。また発表者も募集しています
Cinnamon now supports concurrency execution of task - $shibayu36->blog;
Cinnamonのタスク並列実行を正式にリリースしました。インストールするとデフォルトでは全ホスト同時に実行されるようになります。 参考 http://shibayu36.hatenablog.com/entry/2013/04/14/013325 またconcurrencyという項目でタスクごとに最大並列ホスト数を制限することが出来ます。例えば以下のように設定すると、 use Cinnamon::DSL; set concurrency => { restart => 1, 'server:setup' => 2, }; role production => [qw(server1 server2 server3)]; task update => sub { my ($host, @args) = @_; # ... }; task restart => sub { my ($host
ペパボとカヤックに遊びに行ってきました & Cinnamonの検証について発表しました - $shibayu36->blog;
金曜日にペパボとカヤックに遊びに行って来ました。 ペパボ 昼ごろにペパボに遊びに行ってantipopさんに案内してもらいました。食堂みたいなのがあってそこで昼食を食べた後、オフィスに少しだけお邪魔しました。ちょうど開発の方々がお話をしていたので、少しだけお話して来ました。 あとペパボの入ったところの黒板に絵が書いてあってかっこ良かった。 すごいぶれてた。。。 カヤック そのあとカヤックに3時くらいに行ったら、社内isuconが開催されていました。実際には7時前にお邪魔するつもりがすごく早くに着いてしまったのですが、isucon会場でぼーっと作業を眺めていました。 見てるとすごく楽しそうで、DBIがとかRedisがとかいろいろ話しててとにかくやりたすぎるけど参加できなくてもどかしい感じでした。そのあと今回のisuconの解説があったのですが、それが面白くて参考になりました。社内isucon非
perlでforkしたプロセスとの通信を簡単に行う方法が知りたい - $shibayu36->blog;
今作っているもので、「forkした後、子プロセスの実行の結果を最後に親プロセスに通知し、親プロセスは子プロセス群の状態をまとめて取得する」、ということがやりたいのですが、モダンかつ簡単な方法って何があるんでしょうか？ 具体的には use Parallel::ForkManager; $pm = Parallel::ForkManager->new(5); foreach $data (@all_data) { # Forks and returns the pid for the child: my $pid = $pm->start and next; # ... do some work with $data in the child process ... # 実行結果のサマリーを親プロセスに投げておく $pm->finish; # Terminates the child proc
vagrantで使ったコマンド - $shibayu36->blog;
最近vagrantを使ってみてるのだけど、いくつか使ったコマンドがあったので、メモがてらブログに書いてみる。 vagrant init vagrant initでそのディレクトリにおけるvagrantを設定できる。具体的に言うとそのディレクトリ以下にVagrantfileというものが出来る。例えば以下のように使う。 $ vagrant init vagrant box vagrant boxはどこかのURLにあるboxファイルを名前付きで手元に持ってくるもの。vagrant box addつかえば持ってこれるし、vagrant box listを使えば手元に何があるか分かる。あとはremoveとかrepackageとかある。 boxをlocalに持ってきておけばいろいろなprojectで毎回boxファイルをdownloadせずに同じ物を使うことが出来るので便利。 $ vagrant box
職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;
Code Completeの上下巻を読んだ。 CODE COMPLETE 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCODE COMPLETE 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 読んだ感想としては、職業プログラマーなら必ず読むべき本だなと感じた。 この本ではソフトウェアコンストラクションに関する話題を扱っている。この本の中でソフトウェアコンストラクションとは、詳細設計、コーディングやデバッグ、単体テストなどなど、要求定義が終わった後、ソフトウェア製作に必要なプロセス全般のことを指している。 主なテーマとして、どうやってソフトウェアにおける複雑さを減らすことが出来るのか、について書かれている。そのテーマをいろいろな観点から説明されている。例えば以下の様な観点がある。 上流工程の欠陥による
チームで開発する際に自分が心がけていること - $shibayu36->blog;
最近結構大きめなチームで開発しているのだけれど、そこで気をつけていることをちょっと書いてみる。 チームを開発していると 自分がメインで開発している機能 自分以外がメインで開発している機能 の二つが必然的にできてくる。チームがある程度大きくなってくると、自分がメインで開発している機能は自分が一番詳しくなるし、自分以外がメインで開発している機能に関しては自分がいちばん詳しいわけではなくなる。 そこでこの二つについて自分が心がけていることを書いてみる。 自分がメインで開発している機能 この時考えているのは、 自分一人だけの知見では見逃すことも多いので、出来るだけ早めに意見を集める 他の人の意見に左右され過ぎない 動くものが必要な場合は最小工数で作る それは全て捨てる気持ちで作る これらを考えて、僕は自身では以下の様なプロセスで機能開発をしていっている。 その開発に関する調査をする その機能に関す
Kansai.pmに行ってCinnamonというデプロイツールについて発表しました - $shibayu36->blog;
http://www.zusaar.com/event/476003 に参加して来て、前作ったデプロイツールであるCinnamonについて発表して来ました。 発表したこと 以前capistranoの奥深さに毎回ハマっているのを怒りを覚えて、もっとシンプルなデプロイツールであるCinnamonをantipopさんと一緒に作ったのでその発表をしてきました。それなりに好印象っぽかったので、発表してよかったです。 スライド Cinnamon - simple deploy tool from Yuki Shibazaki デモで使ったサンプルコード https://github.com/shibayu36/cinnamon-deploy-sample 簡単に紹介すると CinnamonはMinimumというのと、Role x Taskというのを思想として持っている Minimum : デプロイの方
プログラマの数学を読んで、数学の初心を思い出した - $shibayu36->blog;
プログラマの数学を読んだ。 プログラマの数学 作者:結城 浩ソフトバンククリエイティブAmazon この本ではプログラミングに関わる数学について(例えば論理や再帰的な構造など)、わかりやすく説明がされている。 内容についてはある程度知っていたことが多かったが、それより文章の進め方を見て、高校時代に数学が楽しいと思っていた自分を思い出した。 最近は数学勉強するのすごくだるくて、それは大学時代にわけわからない数式を突然見せられて、全く解けないみたいなのを繰り返してたからだった。でも今思い出すと高校のときは、数学の勉強するのすごく楽しくて、自分で数式作って遊んでたりしてた。 プログラマの数学は、基本的に小さいところから初めて、その規則性を見つけ、それを一般的な数式に変えるというのが、一章ごとで行われていた。例えば、100個の中から20個選ぶ組み合わせの問題を、最初は5個から3個選ぶという小さい問
ペアプログラミングをしていたら、開発環境が良くなった話 - $shibayu36->blog;
最近、仕事で一週間に一度はペアプロをするということをしているのですが、これによって思ってもみなかった効果が出たので紹介します。 ペアプロというとプログラムを書いている人の後ろでもう一人が見ていて、逐次指摘などしながらプログラミングすることによって、生産性の向上やバグ発生率を抑えるみたいなことが言われています。僕自身もそう思いながらペアプロに望んでいたのですが、違うところで効果が出始めました。それは自身の開発環境がだんだん良くなっているということです。 ペアプロによって開発環境が良くなる 今回開発環境といっているのは、emacsなどのエディタや、ターミナルなど、ローカルマシンの設定などのことです。 なぜ開発環境がよくなっていっているというと、見ている時と見られている時のそれぞれにおいて、次のようなことが起こるからです。 見ている時 後ろから見ていると突然プログラムを書いている人が、自分の知ら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
敦賀でフグを食べてきた - $shibayu36->blog;
