2012-02-24

HerokuにLokkaをインストールしてみた

アインシュタインの電話番号を参考に、LokkaをHerokuにインストールしてみました。
たしかに簡単だったので、取り急ぎ記録しておきます。

設置が簡単？

前述のアインシュタインの電話番号では、次のように書いてありました。

Lokka公式サイトの「はじめよう」の「Herokuの場合」に書かれている下記のコマンド、最初見たときには省略してあるのかと思いましたが、ホントにこれだけでブログの設置が完了します。
$ gem install heroku bundler
$ git clone git://github.com/komagata/lokka.git
$ cd lokka
$ heroku create
$ git push heroku master
$ heroku rake db:setup
$ heroku open （ブログをブラウザで開くための1行を追加）
たった7行のコマンド、herokuやbundlerのgemがインストールされているならたった6行でLokkaブログのHerokuへの設置が完了します。2年くらい前にWordPressをレンタルサーバーに設置しようとしたときは、特にデータベースの設定でやたら手こずった記憶がありますが、Lokka＋Herokuならそういう設定も要りません。

ホントにこの通りに事が進むのでしょうか・・・？

インストール

1.gem install heroku bundler
2.git clone git://github.com/komagata/lokka.git
3.cd lokka
4.heroku create
このへんまで、ホントに余裕でした。

いつも悪魔はそこに

で、
5.git push heroku master
これを実行したところ、

じゃんっ

なんかRSAって見たことある・・・いったんキャンセルしました。
GOOGLE先生に聞いてみました。

$ ssh-keygen -C "自分のメアド" -t rsa

を実行すると幸せになれると。
とりあえず実行。
なんか生成されました。

２度目の挑戦

5.git push heroku master　をもう一度実行してみます。

もう一度、RSAキーの作り方をおさらいします。

・・・あれ？
~/.sshでkeygenしろと書いてある！

ではさっそく、
> cd ~/.ssh
> ssh-keygen ...（以下略）

そうすると、こんなメッセージが出てきました。
> Generating public/private rsa key pair.
> Enter file in which to save the key (/Users/○○/.ssh/id_rsa):

このへんまで来て、やっと気が付きました。
これ、Gitでアカウント作る時に生成したやつですね。

その後

さっきのダイアログに、Gitの時に決めたパスフレーズを入力して、
めでたく手順どおりに終了しました。

画面イメージはコレ。

ただし、まったく自分で手を下した感がないので、
gitコマンドを書く練習した、という感じです。
あとで、Lokkaの中身を見ておこうと思います。

参考資料：アインシュタインの電話番号

2012-02-22

MacPorts から Homebrew に移行する

mac

MacPortsからHomeBrewへ

タイトルにちなんでやってみました。
MacPortsからHomeBrewへ引っ越し。

もともとMacPorts使ったのは、Rspecのセミナーを受けた時、HomeBrewでnokogiriが入らなかったので、仕方なくMacPortsを使ったという経緯がある。

その頃のオイラは、まだどっちがいいかなんて知るよしもなかった。
HomeBrewのほうがいいらしいと最近知ったので、えいやっと変えてみた。

やってみた結果

MacPortsでインストール済ライブラリの一覧を見ると、出るわ出るわ。
ファイルにリダイレクトして、それを加工してシェルで回しながらHomeBrewでインストールしていくか・・・

と思ってたけど、手が滑って一括削除しちゃった。

仕方がないので、『必要になるたびにHomeBrewで入れる』という運用にしてみる。
今のところ、全く問題なし。

けっきょくnokogiriも問題なく入ったし、まずはめでたし。

タイトルに、はてブしたページを

ところで、記事を書くとき、タイトルのテキストボックスで↓を押すと、自分がブックマークしたページのタイトルがドロップダウンする。
文字を入力すると、フィルタもかける事ができる。

初めて知った。
内容へのリンクとか張られるんだろうか。

まだ便利なのかそうでないのかは、よく分からず。

追記：特に何かリンクなどが設定される事はないようだ。
誰が得をする機能なんだろう。

2011-11-25

XMLシリアライズ、デシリアライズについて

XML シリアライズとは

あるクラスの内容をXMLに書き出したり、XMLから読み込んだりすること。
クラスの内容をファイルに保存したりできる。
Webサービスにデータを渡す時も、XMLにシリアライズされている。

今回やろうとしたこと

あるフォルダのXMLファイルに書き出された、あるクラスのインスタンスのデータがある。
そのファイルを読んで、中身をクラスとして復元する。

ちょっとハマったとこ

サーバー側で定義したインスタンス（データベースをモデル化したもの）に対して、
プロパティをXMLにシリアライズしたい時は、以下の属性を付けないといけない。

XmlElement: 単一のプロパティに付ける。
XmlArray: 配列のプロパティに付ける。

public partial class MotorCycle{
    [XmlElement]
    public Engine Engine { get; set; }

    [XmlArray]
    public List<Tyre> Tyres { get; set; }
}

参考文献

Stack overflow
http://stackoverflow.com/questions/364253/how-to-deserialize-xml-document

動作するバージョンを上げるよ。XmlElementAttributeラベルとXmlElementを変更した。
理由は、StockNumberとMakeとModelの値は要素であって、属性ではないから。
あと、reader.ReadToEnd()も消した。このメソッドは、テキストを全部読んでファイルの終わりに辿りついてしまって、そこからデシリアライズのために読むことができなくなっちゃうので。
同じく、ネーミングもちょっといじらせてもらったよ:)
これがクラス定義:

[Serializable()]
public class Car
{
    [System.Xml.Serialization.XmlElement("StockNumber")]
    public string StockNumber { get; set; }

    [System.Xml.Serialization.XmlElement("Make")]
    public string Make { get; set; }

    [System.Xml.Serialization.XmlElement("Model")]
    public string Model { get; set; }
}


[Serializable()]
[System.Xml.Serialization.XmlRoot("CarCollection")]
public class CarCollection
{
    [XmlArray("Cars")]
    [XmlArrayItem("Car", typeof(Car))]
    public Car[] Car { get; set; }
}

デシリアライズする部分:

#!
CarCollection cars = null;
string path = "cars.xml";

XmlSerializer serializer = new XmlSerializer(typeof(CarCollection));

StreamReader reader = new StreamReader(path);
cars = (CarCollection)serializer.Deserialize(reader);
reader.Close();

生成されたXML:

<?xml version="1.0" encoding="utf-8"?>
<CarCollection>
<Cars>
  <Car>
    <StockNumber>1020</StockNumber>
    <Make>Nissan</Make>
    <Model>Sentra</Model>
  </Car>
  <Car>
    <StockNumber>1010</StockNumber>
    <Make>Toyota</Make>
    <Model>Corolla</Model>
  </Car>
  <Car>
    <StockNumber>1111</StockNumber>
    <Make>Honda</Make>
    <Model>Accord</Model>
  </Car>
</Cars>
</CarCollection>

2011-11-25

ポモドーロうまくいかないなぁ

どううまくいかないか

タイマーを起動しないで作業を始めがち。
５分休むはずが、１０分とか休んでいる。
切りが悪いタイミングでタイマーが終わる。

なぜか

休憩終了のタイミングが意識できてない。
作業の見積もりを立ててない。
半端なタイミングで始めるのが嫌で、やめてしまう。

対策

とりあえず、休憩の5分間にすることと、休憩終了のタイミングを意識しよう。

2011-05-31

ポモドーロはじめました

考え事

ポモドーロをやるぞ

ポモドーロテクニックというのがあるそうな。
それを始めてみることにした。

ポモドーロとは？

簡単に言うと、『２５分集中して仕事して、５分〜１０分休む』というのを繰り返して、効率を高めようというやりかた。

必要なものは、２５分計れるタイマー。
しかし、仕事場は、セキュリティの関係で、フリーソフトのインストールができない。
申請するのも面倒くさい。

タイマーを作ろう

そこで、WPFの練習を兼ねて、タイマーを自作することにした。

自分しか使わないし、最初はシンプルにウィンドウだけあればいいと思ったのだけど、やっぱりデザインに凝ってしまった。

楕円でボディを描いて、別途Cacooで描いたへたを載せた。

最後に、かわいいフォントの時間表示部分を作り、
影が付くように小細工して終わり。

できた

出来上がりは、こんな感じ。

実行ファイルはここに置いときますね。
Pomodoro Tool

ソースコード

いちおう使い方

アイコンをダブルクリックすると開始。: よーい、ドン！とかなしで、問答無用で数え始めちゃう。

右クリックで設定が出る。: 設定は、『常に手前に表示』の選択だけ。

今のところは、これでいい。
欲しくなったら、機能を追加していけばいいじゃない。

しかし、WPFはまだまだ使いこなせない。
泥臭い書き方でもだんだん書けつつあるので、
上手に使いこなせるようになるといいな。

2011-05-19

悪魔を呼べた日

考え事自分のこと

プログラムを書いて感動した思い出について書いてみる。
今でこそ、データベースからデータを取って来て、
EXCELに貼りつけるなんて朝飯前になったけど、
これを初めてやった日は、禁断の呪法を会得したような
気分になったっけなぁ・・・

あの頃は手で打ってた

あれはまだ、派遣社員をやってた時だったな。

当時オイラがいたチームでは、営業さんからヒアリングした話を、
書類にまとめて会議に提出するのが仕事だったっけ。

ヒアリング内容をAccessに入力して、それを見ながら
EXCELのシートを埋めて・・・

最初はそれが普通だと思ってた。でも、だんだん苦痛になってきて、
『ここに自動でデータが入ったら楽なのになぁ・・・』と思うようになった。

プログラミングとの出会い

折しも、『Access？なにそれ？おいしいの？』状態だったオイラに、
当時のボスはチームのデータベースを任せてくれたのだった。
チームゆうてもオイラとボスとお姉ちゃんの３人だったけど。

で、Accessのボタンとかいじるのに、どうしてもVBAを知る必要に迫られ。
面白いもんだからハマっていた。
『プログラムって面白いなぁ。EXCELもVBAでなんかできるの？』と思っていたところに、
『Accessと連携できたら面白いのに！』というアイデアが湧いて。

これは天啓だと思ったなぁ。

さっそく本屋さんに行って、『ExcelとAccessの連携について書いた本ください』と
言ったら、これが出てきた。

仕事に役立つExcel&Accessデータベース連携テクニック
古川順平 (著)
http://www.amazon.co.jp/dp/4797324635?tag=booking1025-22&camp=243&creative=1615&linkCode=as1&creativeASIN=4797324635&adid=0MT9S9EYCWXYCJ3GPWEC&

これは役に立った。

禁断の呪法・ADO

当時、ADO（ActiveX Data Object）の技術は、とても敷居が高そうに見えた。
技術書やネットで見ると、かなり面倒臭い事が書いてある。
おどろおどろしく書くと、こんな感じ。

【ADOの心得】

これを使う者は、『参照設定』なる契約を行わなくてはならない。

これを使うものは、以下の通り儀式を行わなくてはならない。

依り代を捧げる儀

『dim ADODB.○○』

召喚の儀

『set new ○○』

異界の扉・開門の儀

『Connection Open』

お願いごと

やってほしい事をここに書く

異界の扉・閉門の儀

『Connection Close』

依り代祓いの儀

『Set Nothing』

依り代祓いの儀を行わなかった者は、理由のいかんを問わず、電源を切るまでの間呪われるであろう。

んー、どう見てもコックリさんっぽい。
これを使えた日には、本当に感動したし、興奮したんだよねぇ。
『とうとう奥義に到達したぞ！』って感じ。

だって、開いてもいないAccessからデータを引っ張ってきて、
超高速でコピペしてくれるんだよ？
もう完全に悪魔を使役してる気分。

で、空いた時間をさらに勉強に使って、プログラマーになりましたと。

今ではどうしてるかと言うと

その後、連携の方法はVBAを使わなくてもいろいろあるのを知って、
『なるべく簡単に実装、VBAは奥の手で使う』というふうになったのでした。

で、今は仕事でC#を書いてるけど、
身近に使うちょっとしたツールならEXCELで作る。
だって、入力回りとか全部付いてて楽だもん。

きっと、SEなら誰でも多かれ少なかれ、感動体験ってあるんだろうな。

2011-05-12

例外処理について考えてみた

考え事

例外について

日報に、例外の事を書いたので、ここに引用してみる。

例外処理について、再考しながらの設計となっています。
改めて調べてみると、いろんな考え方があり、人によっても途中で主義を変えたりしています。
http://blogs.msdn.com/b/nakama/archive/2008/12/29/net-part-1.aspx
http://csharper.blog57.fc2.com/blog-entry-99.html
自分の現在の考えは、『業務エラーは例外で表現するべき』ですが、Try-Catch握り潰しを書くと、不正な状態のまま業務を継続してしまうというのがリスクです。
どんな表現方法にもリスクはあるので、万能な手法はないですが・・・
いま自分の中で興味のある分野は、『Tryを書くタイミング』です。

不正な値を持ったまま処理を継続してはならない。

本番環境で、システムが強制終了してはならない。

この２つは、相反する命題です。
Tryを多用すると前者のリスクが高まり、使わないと後者のリスクが高くなります。
その間のちょうどよい処理をどんな順序で書くか、そこが大切ではないでしょうか。

定型的な処理には『お約束の例外』が決めてあり、そこまではあらかじめ対策を検討しておく。

複雑な条件で発生する例外については、『起こるべくして起こった例外』と位置付け、システムテストまででなるべく起こしておく。

あくまで私見ですが、今日のところは上記のように考えました。