先に疑問を考えてから本を読む - $shibayu36->blog;
久々に昔のエントリを読み返していたら、以下の様な記事があった。 最近の本の読み方 - $shibayu36->blog; どんな本を読むかの部分と、読んだ後ブログに書くというのはずっと変えてないが、最近は読む時どうするかという部分についてちょっと調整を加えている。この部分について書いてみる。 ちなみに今回説明する本の読み方は、特定の事柄を学習したい場合に読む本に限定している。ざっくり興味関心で読む本はここまでしっかり読まず適当に流し読みしてる。 読むときの流れ 読むときは以下の様な流れで読む。 目次を見ながら学びたいことを疑問形式で書く 読みながら印象に残った部分をメモ書きする 最初に書いた疑問に答える 読書ノートテンプレ(自作)に従ってまとめる ブログに書く ここから以前会議の前に決めることは何か - 「感動の会議！」読んだ - $shibayu36->blog;で書いた「感動の会議」を
「シバソン」という名の何も準備しないイベント - $shibayu36->blog;
最近、シバソンという名のほぼ身内でやっているイベントを開催している。シバソンとはシバハッカソンの略で、なぜか適当にハッカソンしますと会社で呼びかけたら自然とシバソンという名前になっていた。今日は勉強会について簡単に書きたいと思う。 Kyoto.pm 以前自分はKyoto.pmというperl界隈のイベントの主催をしていた。このイベントは最初もっといろいろな人にアウトプットする場を提供したいという気持ちで始めたイベントだった。有名な東京のperl hackerを呼べたり、東京からはるばる来てくれる人が何人かいて、けっこう面白いイベントに出来たと思ってる。 ただ問題点がいくつかあった。 一つ目は主催者が開催のために前準備(スピーカー集めとか)をするコストが非常に高かったこと。発表会形式にすると、特に関西ということもあって、全然スピーカーが集まらないということがよくあった。そのたびにいろんな人に声
Harrietを使ってprove単位でmysqldを作ってみた話 - $shibayu36->blog;
tokuhirom blog を見て、これ便利だなーと思ったので、試しにこれを使ってprove単位でTest::mysqldを起動するやつを作ってみた。 harriet用設定を作る まずt/harriet/mysqld.plみたいなのを作る。この中でmysqldの起動とschema流し込みまでしてしまう。複数のdsnを保存しておきたければ、jsonで入れておくと良さそう。 # t/harriet/mysqld.pl use JSON::XS; use Path::Class; $ENV{TEST_EPIC_DSNS} ||= do { require Test::mysqld; my $mysqld = Test::mysqld->new( my_cnf => { 'skip-networking' => '', # no TCP socket 'default-storage-engin
設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog;
以前開発のドキュメントをどこに置くか問題 - $shibayu36->blog;という記事を書いた。まだよい方法はちゃんと考えられてないが、少しずつケースバイケースでいろいろな手法を試してみている。今回は設定項目の仕様のドキュメントという観点で考えたときに、テストを作ることで解決できないか、ということについて書く。 設定項目の仕様 例えば以下の様な設定があったとする*1。 [ { "blog_url" : "http://shibayu36.hatenablog.com/", "permission" : "public", "can_be_edited_by" : [ "shiba_yu36" ] }, { "blog_url" : "http://shibayu36-private.hatenablog.com/", "permission" : "private", "can_be_
Server::Starterから学ぶhot deployの仕組み - $shibayu36->blog;
以前http://tech.naver.jp/blog/?p=1369の記事を読んだのだけれど、それまでにprocessの知識が無かったりして、まったく理解できませんでした。そこでWorking with UNIX ProcessesやServer::Starterの中身を呼んでようやくhot deployの仕組みを理解できた(気になっている)ので、Server::Starterの実装を追いながら、それをまとめてみます。 hot deployとは hot deployとは「再起動の時にリクエストの処理を続けながら、変更の内容を反映するための手段」です。 通常serverをrestartさせるときは、stop -> startの流れになると思いますが、この場合stopしてから、start出来るまでの期間にリクエストを処理できない期間が発生します。その期間なしにdeployする仕組みがhot
goインストールから、emacsにgo-mode, go-autocompleteを導入するまで - $shibayu36->blog;
最近社内でgo勉強会をしているので、goのインストールとemacsの基本的な設定を行った。 goのインストール とりあえず適当にbrewで入れた。 $ brew install goあと http://golang.org/doc/code.html を参考に適当にGOPATHとPATHを設定した。 .zshrc # Go PATH export GOPATH=$HOME/go export PATH=$PATH:$GOPATH/bin go-modeのインストール とりあえずgo-modeはMELPAにあったのでそれを入れる。 M-x package-install go-mode設定書く。 (require 'go-mode-load) これでsyntaxハイライトやインデントなどはうまくいくようになった。 go-autocompleteのインストール あと補完をいいかんじに効かせたか
コードレビューを円滑に行いたい (#cross2014 のお話) - $shibayu36->blog;
id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
自分流の .emacs管理 - $shibayu36->blog;
この記事は.emacs Advent Calendar 2013の三日目です。.emacs Advent Calendarということなので、今回は僕自身がどうやって.emacsを管理しているかということについて書こうかなと思います。 .emacsの管理ってなかなか難しくて、init.elにずっと書き続けていたりするとあっという間に管理不能になったりします。そこで今回は僕自身がどういう構成で、どういう考え方で管理しているかについて、参考程度に紹介したいと思います*1。僕の.emacsはhttps://github.com/shibayu36/emacs に公開しています。 大雑把な構成 基本的に以下の様な感じです。 外部elispの管理はpackage.el + el-getを利用 MELPAにあるものはpackage.el それ以外はel-getを利用 自分の設定の管理・分割はinit-l
自分が入れたEmacs便利拡張・設定集 (2013年版) - $shibayu36->blog;
年末emacs設定大掃除をして、これは捨てられないと思った設定書いてく - $shibayu36->blog; 昨年に引き続き、2013年の自分のemacs.dを振り返るのをやろうと思います。 今年はemacsでいろいろできるようにする、という方向よりも、emacsでの基本操作をどれだけ使いやすく出来るかということを中心にやって来ました。例えば .emacs.dの管理をどうするか コードリーディングや編集を速くするにはどうするか gitとの連携をどうやって簡単にするか この辺りについて１つずつまとめて行きたいと思います。 .emacs.dを管理する .emacs.dの管理って難しいですよね。僕も関西Emacsに参加してから自分が最新のやり方についていけてないなと感じたので、今年はいろいろと見なおしてみました。 基本的なやり方としてはこんなかんじです。 外部elispはpackage.elと
ペアプログラミングをしていたら、開発環境が良くなった話 - $shibayu36->blog;
最近、仕事で一週間に一度はペアプロをするということをしているのですが、これによって思ってもみなかった効果が出たので紹介します。 ペアプロというとプログラムを書いている人の後ろでもう一人が見ていて、逐次指摘などしながらプログラミングすることによって、生産性の向上やバグ発生率を抑えるみたいなことが言われています。僕自身もそう思いながらペアプロに望んでいたのですが、違うところで効果が出始めました。それは自身の開発環境がだんだん良くなっているということです。 ペアプロによって開発環境が良くなる 今回開発環境といっているのは、emacsなどのエディタや、ターミナルなど、ローカルマシンの設定などのことです。 なぜ開発環境がよくなっていっているというと、見ている時と見られている時のそれぞれにおいて、次のようなことが起こるからです。 見ている時 後ろから見ていると突然プログラムを書いている人が、自分の知ら
MySQLをさらに理解するために読んだ記事まとめ - $shibayu36->blog;
最近MySQLの勉強をしていました。実践ハイパフォーマンスMySQLを読むべきという話を聞いていたのですが、かなり網羅的に書かれていて、今の知識ではどれが重要なのかわからない状態でした。そこで色々調べてみて、参考になる記事をいくつか見つけたので、少しまとめてみようと思います。 今回まとめた記事を読んで、大体以下のことが理解できました。 インデックスの使われ方とその構造(MyISAMとInnoDB) EXPLAINの詳しい使い方、見方 InnoDBの特性 ALTER TABLEの特性 レプリ遅延 まず最初に Webエンジニアのための データベース技術[実践]入門 (Software Design plus)posted with amazlet at 12.06.02松信 嘉範 技術評論社 売り上げランキング: 9767 Amazon.co.jp で詳細を見る 松信さんの書いた「Webエンジ
チームで開発する際に自分が心がけていること - $shibayu36->blog;
最近結構大きめなチームで開発しているのだけれど、そこで気をつけていることをちょっと書いてみる。 チームを開発していると 自分がメインで開発している機能 自分以外がメインで開発している機能 の二つが必然的にできてくる。チームがある程度大きくなってくると、自分がメインで開発している機能は自分が一番詳しくなるし、自分以外がメインで開発している機能に関しては自分がいちばん詳しいわけではなくなる。 そこでこの二つについて自分が心がけていることを書いてみる。 自分がメインで開発している機能 この時考えているのは、 自分一人だけの知見では見逃すことも多いので、出来るだけ早めに意見を集める 他の人の意見に左右され過ぎない 動くものが必要な場合は最小工数で作る それは全て捨てる気持ちで作る これらを考えて、僕は自身では以下の様なプロセスで機能開発をしていっている。 その開発に関する調査をする その機能に関す
Kyoto.pmを初開催 & 発表しました - $shibayu36->blog;
Kyoto.pm初開催 & 発表をしました。 初開催 ようやくKyoto.pmを初開催まで持っていくことが出来ました！今回は初開催にも関わらず、JPA様に講師派遣支援をしてもらい、id:yappoさんを呼ぶことが出来ました。ありがとうございます。 今回は全部で45人ほどの参加があり、発表も通常トークが7つ、LTが10くらいあって非常に盛り上がったように感じます。また関東の方からid:yappoさんや、id:nekokakさんなど7人ほどの方が来ていただきました。ほんとうにありがとうございます。 さらにustreamを見ていたid:xaicronさんが20:00くらいに新幹線に乗ってやってきて驚きました。この行動力...すごい！ まぁ何はともあれ、無事に第一回を開催することが出来てほっとしました。一般の人も呼ぶようなイベントとかは開催したことがなかったので、とりあえずは成功と呼べる程度の規模
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
