CubicLouve

conf	説明
aws_key_id	Access Key Id
aws_sec_key	Secret Access Key
from	fromアドレス(SESでverifiedされているアドレス)
to	送信先(少なくとも一つは指定、カンマ区切りで複数指定できます)
cc	ccのアドレス(オプションカンマ区切りで複数指定できます)
bcc	bccのアドレス(オプションカンマ区切りで複数指定できます)
reply_to_addresses	返信先のアドレス(オプションカンマ区切りで複数指定できます)
subject	メールのタイトル

メールの本文は、plaintextformatterで整形されたログがそのまま貼り付けてあります。

その他

AWSのモック欲しい。。。。
テスト書く時いつも悩ましい。

Posted 1ヶ月前

Comments

fluentd, ruby, aws, ses,

とある大学生の話を聞いて

テクニカルなネタをここには書いてきたけど、今回は違う感じで。

とある大学生と話してたら、”頭下げてまで日本の企業に就職したくない”と言ったので(ちょっと誇張したかな。。。)大分イラっとした。

日本ナメんなよ

海外の企業でちゃんと利益を出している企業がどれだけあるのだろうか。
(もちろんAmazonとかGoogleとかあるけれど、総体としてってことで)
まあ、まだ就活前の人だしあんまり深くは突っ込まなかったけど、何でこんなに日本の企業を低く見てしまうのか。。。

あと、”海外に行ってみたい”って言ってた。
海外に行って何が得られるのだろう。。。
少なくとも日本の大学で”学ぶ”ということをするべきではないのだろうか。
(良い成績を取るってことではなく)
英語を勉強したいってのはわかるけど、大学生活を費やしてまでやることなのかな。。。
大学ではもっと自分から学ぶことを学ぶのが必要なのではないか。
(自分が卒業した大学は少なくともそういうことを教えてくれた。)

折角、義務教育から開放され、自分の学びたいことを学びに行っているのになぜそれをしないのか。

まあ、日本の大学の限界って言われればそれまでなんだけど。。。

海外ってそんなにいいとこなんですかね？

勢いにまかせて書いたけど、まあちょっと気になったので。

Posted 1ヶ月前

Comments

Tatsuhiko Miyagawa's Podcast: ep6 ゲスト: Naoya Ito

bulknews:

bulknews-podcast:

収録時間 41:20 | Download MP3 (23.5MB)

第６回は伊藤直也さん (@naoya_ito) をゲストに迎えて、Kindle 出版、GitHub、Google Reader などについて話しました。

第１回に続き、naoyaさんに出てもらいました。

「非公式なAPI」

後半で出てくる Google Reader APIの話で、「野良API」って言葉を使ってますが、紛らわしい表現だったかもなので、ちょっと補足。

「野良API」というと第三者が無断でつくったAPI、のように聞こえるかもですが、そうではなく、「非公式なプライベートAPI」という方が正しいかも。

ここでいう非公式なAPI、というのは、Google Reader のウェブサイトが Ajax で使っているエンドポイントや、Google公式の Reader アプリが使っているプライベートAPIをリバースエンジニアリングしたAPI、という意味で使っています。仕様についても Google は一度も公開したことはなく、有志がリバースエンジニアリングした仕様をGoogle Code上で公開してるもので、これを feedly などは使っていた、という話です。

ゲストの人選

naoyaさんが２回めということもあって、「もう２周目」？とかTwitter で意見をもらったりしてます。

もともと、ゲストを週替りにしてインタビューする、という発想ではなくて、その時話したい「ネタ」があって、それに最適な人をキャスティングする、という発想をベースにしていました。MessagePack のissueの話、Ruby 2.0 のリリースの話、その開発者に聞くのが一番いいですよね :)

とはいえ、ネタにとらわれずに「いいとも」あるいは「徹子の部屋」的に人にフォーカスした回もあってもいいかなと思っていますし、ep4の高林さんの回なんかはそういう感じですね。

その辺もいろいろバランスをとってやって行きたいと思いますが、まだまだいろいろ試行錯誤ですので、フィードバックもらえるとうれしいです！

Reblogged 2ヶ月前 from bulknews

Comments

21 リアクション

TDDBC Tokyoに参加して来ました

2013/03/16に開催されたTDDBC Tokyoに参加してきました。

主催の@katzchangさん、会場を提供してくださったVOYAGE GROUPさん本当にありがとうございました！

作業

お題はこちら

tddbc_tokyo_20130316

当日自分が書いたソースはgithubにあげてあります。

tddbc_tokyo_20130316

ruby2.0+rspecで書いています。
一応travisにも対応しています。

振り返り

今回の課題はLtsvを扱うモジュールの実装でした。

この課題では”テストが、実装するメソッドに依存してもいいのか”ということに悩みました。
メソッドAのテストを書くためにはメソッドBを使うと簡単に書ける、逆も同様。
自分はテストは実装する他のメソッドに依存しないようにテストを書くようにしているのですが、今回はペアプロしていてそこを突っ込まれてどうしたものか悩みました。。。

今回は、テストするメソッドがインスタンス変数へアクセスするメソッドだったので、インスタンス変数を直接確認する方法を取りました(instance_variable_getとinstance_variable_setを使いました)
でも、結局はっきりとこうしたほうがいいって自信がないまま終了してしまったので、後で相談したところ、

テストが実装する他のメソッドに依存するのは大丈夫
テストのために一時的にメソッドはやしたり、アクセッサを定義する方法もある(あとでちゃんと消すのが前提)

と教わったので、今回であれば実装順はこうしてもよかったなあと反省しています。

インスタンス変数のアクセッサーを作っちゃう
get(or set)のテストを記述
getが実装完了したらset書く
setのテストはgetに依存してもOK
setのテストが完了したらアクセサ消す
getのテストが落ちるのでgetのテストを書きなおし

まあでも、なるべく依存したくはないですね。

その他

TODOを作る時間に前半の時間のほとんどを割いてしまった。。。
適度に考えて適度に手を動かすことが重要ですね！

あと色々な人のテストの経過が見えるのは良かったです。
大抵ライブラリとかみても綺麗な状態になって出てくるので、TDDBCではテストを書く経過が色々見れて参考になりました。

普段テストは書いているのですが、もっとテストを効率よく書くためにテストについてもうちょっと勉強しないとなあって痛感しました。(テスト駆動開発入門とかリファクタリングとか読まないと。。。)

TDDBC Fukuoka

TDDBC Fukuokaを6月中旬頃に開催する予定です。
まだ、詳細を詰めている段階ですが、2日間でガッツリ行う予定です。
詳細が決まりお知らせします。

あと、TDDBC Fukuokaを開催する前に、github workshopをする予定です。
TDDBCではペアプロをするのですが、その際一台のマシンを使ってるとキーバインドやエディターの違いでペアプロしにくいだけでなく戦争が起こる可能性があるので、githubでソースを共有して自分のマシンでソースが書けると効率が上がりそうだからです。
特にIDEがそこまで浸透していない言語(rubyとか)でよく起こるのでTDDBCに参加する前に一度githubの使い方workshopを開催してgithubを使ったコードのシェアに慣れてもらおうと思います。
(もちろんTDDBC参加しない人でも参加できるようにします！)

TDDBC Fukuokaの情報は下記FBグループにも流します。
興味が有る方は是非ご参加ください(公開グループなので参加しなくても閲覧できます)。

TDDBC Fukuoka

最期に

2013/5/13にTDDBC 長岡が開催されます！
詳細はこちらから

TDDBC長岡1.0

リンク

Posted 2ヶ月前

Comments

tddbc, rspec,

Fluentd meetup in Fukuokaに参加 & 発表してきました

先日福岡で行われたFluentd meetup in Fukuokaに参加してきました！
(エントリが大分遅くなってしまった。。。)
@tagomorisさんや@repeatedlyさんなど東京からモヒカン達が福岡に来襲して大分盛り上がりました!

Fluentd in Co-Work

Fluentd in Co-Workというお題で発表させて頂きました。
スライドはこちら

Fluentd in Co-Work from Makoto Haruyama

ちょっと頑張って英語で書いてみました(誤植が大分あると思います。。。)
最近、Co-Workというサービスをリリースしたのですが、その中でFluetndをどのように使っているかを紹介しました。
Co-Workでは、ログ収集だけではなく、Queueingで使っているのですが、バッファリングがしっかりしているFluentdはログ収集だけではもったいないのでQueueing以外にも活用出来る部分があればどんどん活用して行きたいですね。

あと、自分が作ったfluentd-resque_statはこちらにあります。

ダウンロード数はkanicounterを超えていて少し安心しましたwwww

他の発表

他の方のスライドは下記リンクにまとまってます。

@tagomorisさんのプラグインの類別は参考になりました。
今後pluginを作る上で意識したいです。

最期に

東京から来ていただいた方たちには大層福岡を気に入って頂けたので、今後も福岡で色々勉強会が開催されると思います。

福岡まとめ

Posted 2ヶ月前

Comments

fluentd,

ruby 2.0とそれ以前でのconst_getの挙動の違い

ちょっとハマったのでメモ。

ruby 1.9.3 p327

ruby 2.0

ruby 2.0から const_get A::B みたいなことが可能になっている。

object.c L 1872付近にコードconst_getのコードがある。

Posted 2ヶ月前

Comments

MySQL Casual Talks in Fukuoka Vol.3を開催しました！

大分エントリー書くのが遅くなりました。。。
2013/02/24にMySQL Casual Talks in Fukuoka Vol.3を開催しました。
今回は東京からMySQL Casual Talksの元締めである、@myfinderさんが参加してくださいました！
今回もMySQL5.6の話題が満載でした。