CsvHelper を使って CSV 文字列を生成

公式のサンプルにも似たようなのあるんだけどうまくいかなかったので。

JoshClose/CsvHelper

CsvHelper は

普通に StreamReader/StreamWriter を受け取って動作するので、その辺りが分かっている人にはなんてことはないと思います。

コード

using (var memoryStream = new MemoryStream())
using (var streamWriter = new StreamWriter(memoryStream))
using (var streamReader = new StreamReader(memoryStream))
using (var writer = new CsvWriter(streamWriter))
{
    writer.Configuration.RegisterClassMap<Hoge>();

    writer.WriteRecords(hogeList);

    streamWriter.Flash();

    // Position = 0 でも大丈夫ぽい
    memoryStream.Seek(0, SeekOrigin.Begin);

    var csvStr = streamReader.ReadToEnd();
}

公式のサンプルコードには Flash の記述がなくてウンウン唸っていたというお話でした。。

第六回 tokushima.rb に参加してきた

第六回tokushima.rb＆新年会 | Facebook

参加したいしたいと思いながら、予定が合わず参加できていなかったが、第六回にしてついに参加できた。（飲み会は日曜ということもあり参加できず。。）

当日の参加者は 10 人いなかったぐらいでしたが、大きめのテーブルを全員で囲みながら、基本はもくもく会スタイルでした。

IntelliJ Ruby plugin 使いとの遭遇

もくもく中に Twitter を眺めていると以下のツイートが流れてくる

IntelliJ と rbenv の組み合わせで Bundler が使えない時 on @Qiita http://t.co/Dh4erwoUND

— 4ヶ月間自転車禁止 (@sunny4381) 2015, 1月 25

「あれ、この人、目の前に座ってる人じゃないか？？」と声をかけてみるとやっぱりそうでした。

自分の職場では RubyMine 使いは自分だけで、後は Vim, Emacs, Sublime, Atom と様々。初めて（ほぼ）同じエディタ使いの人に合えて嬉しい。

割りとコンソールを行き来している自分とは違って、RSpec もデバッグも、Git までも IDE 上で完結させてて、かなり良い感じでした。真似したい。

地域のコミュニティに貢献する人達

参加している人達のコンテキストまでは分からなかったけれど、他の勉強会の企画を進めようとしていたり、Code for Tokushima の話しをしていたりとコミュニティ活動に積極的な人が多かった。周りの人も「あの人声かけてみようか」「場所はあそこが使えるかも」とか協力的な人が多かった。

講義型の勉強会では無いため、そういうコミュニティの中心に近い人達が集まっているんだなと思う。横で聞いてて感心しきりだった。

地域のコミュニティと地域の仕事

私は東京の会社の仕事をリモートワーカーという形でやっている訳ですが、最近はもう少し地元の仕事をしたいとも考えてる。というか、地元の人たちと仕事がしたいのかもしれないとも思う。 東京に居ると感じなかったが、「地元」というコンテキストの中で、そこに居る人と仕事をするのは楽しそうに感じた。

一方で、それはリモートワークに多少行き詰まりを感じていたのかもしれないとも気づいた。性格的にも経験上もどうやら自分には小さなチームが性に合っているようで（大きな声だすの苦手だし、承認フローみたいな筋を通してやるのがすごい苦手。。）、現在中規模のチームでたった一人のリモートワーカーをやる事に多少しんどさを感じているような気がする。 チームにはすごく協力的な人もいるし、上司も理解があるので、環境がどうこうとかではないので、たぶんこれは自分の性質への気付きでしかないのかなとも思う。

かと言って、東京で仕事をするというイメージはもう無いし、地元に何か貢献できればと思ったりする。神山町は農業支援にも力を入れているし、他にもいろんな仕事はあると思うし、全部 IT じゃなくて、一部 IT みたいな仕事ができればなーと思ったりする。（IoT とか流行ってますし）

今日の場に出ててみて、例えば、仕事で「コード書いたー」みたいな環境に無くとも、コミュニティやプライベートのプロジェクトでプログラミング欲は満たせればみたいな希望を持てた気がするし、地元の技術コミュニテイの素敵さを感じることができた。

ホントにもくもくと集中する中でも、いろいろと気付きにもなった良い会でした。またお邪魔します！

/dumped

土壌の基礎知識 第一章 を読んだ

図解 土壌の基礎知識

特にこれを選んだ理由も知識もない。私が世話してる畑なんて、畳３枚分ぐらいしかない。

ここ半年ぐらいであった生産者の方々は以下のような方が多かった。

1. 畑をキレイに保って、石灰や肥料等で土のバランスを整える人
2. 自然農法（？）で、雑草や土は比較的自然なままにしている人

1 の人たちは「肥料をやらないから作物が病気になる」といい、2 の人たちは「自然じゃないものをやるから作物が病気になる」という。正直良くわからないけれど、どちらの人も自分たちが正しいと思っているから、結構強く言われたりすることもある訳です。

実際自分が本格的に農業をするかどうかはさておき、ちゃんと土について理解して、見聞きする事を少しぐらいは理解したいなと思い読んでみる事にしました。

第一章 土と土壌

考えた事も無いが、「土」と「土壌」は異なるものらしい。

「土」となると、単に岩石が風化したようなものも土と呼べる。よって、月面上にも土があると言えるらしい。

一方で「土壌」となると、生物によって作られ、生物の生育を支える事ができるというものになるらしい。

土と土壌のライフサイクル

これは結構驚きで、土・土壌のそれぞれにライフサイクルがある。

土は前述の通りで岩石が風化したり削られてできる。その前に岩石自体はマグマが地表で冷えてできたり、火山噴火したものが堆積してできたりするらしい。また、地震等で地殻変動し、隆起してくるケースもある。

地表に現れた岩石は崩落や雨水で削られたりで「土」になる。土はその後、雨や風で流されて低地に蓄積して後述するが「土壌」に変化する。

さらにその土壌もいずれ流亡したり老化し、再び堆積し岩石となって土ではなくなる。この周期が実に数百万年から数億年周期で起こっているらしい。なんというか途方も無い。。

土壌は土のなかに微生物が活動してくる事で植物生育に適する環境に変化していくことで土壌化していくようです。

土壌はそこに生育する植物や微生物によって、徐々に肥沃になっていくものの、数千年単位でその肥沃度は低下し老化していくらしい。

老化と一口にいっても、土壌の階層化、上層のミネラルの溶脱、鉄やアルミニウムの下層での蓄積と成分レベルでの変化のことを指すようです。

興味深かったのは、農耕地は化学肥料の施用で土壌が酸性化することで土地の荒廃が進みやすいとのこと。

酸性化すると、アルミニウムが活性化して作物の根の生育を害するとか、リン酸を作物に吸収されない形で固定化するとか、難しい事も書いてあった。。徐々に理解していきたい。

感想

自然土壌と畑や水田の土壌での土壌の変化は、「連作はダメ」とか「石灰をまいて中性にしないと」といった事の理解に繋がった。

「農業機械踏圧での土に耕盤が作られる」とか何言ってるのか分からないが、土壌は実に多くの要因で成立していて難しいという事がわかった。。先は長いぽいです。。

FabLife 対談1 と 2章の②まで

対談1

アムステルダムとボストンのファブラボの話しがメイン。

一章の内容以上にファブラボのコミュニティの側面が伝わってくる。アムステルダムでの世界ファブラボ会議での、いきなりレシピと材料を渡されてみんなでディナーを作る様子やコンペでボートを作ったり、なんでもありの会議の様子はすごく楽しそう。

その他だと、

• 世界のファブラボのネットワークの繋がりの重要性
• ファブラボは個性があるが、振り返ってみると運営している人の顔や人柄が思い出される
• ファブラボは、個性、自発性、多様性に支えられたネットワークであることが魅力

とかが気になりました。

スペースや道具、直接の知識の共有は１つのファブラボでできるけど、それだけじゃなくて、世界中のファブラボと共有できる仕組みを思案しているらしい。

会社という組織にいても暗黙知だらけになるのに、世界の会ったことも無い人達との情報の共有に情熱を燃やせる事はすごいなーとか。もしかすると、ある程度距離感があった方がちゃんと共有とかするんだろうかとかリモートワーカーは思ったりする。

２章①②

MIT のなんでも作れるようになる授業は前から知っていて詳細知りたいなーと思ってたので読めて嬉しい。

• 30 名のスキルも人種も年齢も違う人が集められ
• とにかく How （どう作るか）を叩きこまれ
• アイデアが新鮮なうちにとことん作らされる

ラピッドプロトタイピング

本には IDEO の例も乗っているが、最近は何かを作るにしても LEAN がなんだ、仮説検証のサイクルがなんだ、学びがなんだ、ピボットがなんだと、なんかちょっと個人的についていけてない。たぶん、（スタートアップにしろ違うにしろQCD を考える）経営者としての観点では、理にかなっているんだろうけど、個人的に性に合わない感じがずっとあったりした。

なんとなく、面白い事を思いついたら週末で荒くても全部作ってしまいたいのが昔からの性分なのだと思う。（だからコード汚いのだと思う）

アイデアが新鮮な間に、その期待感とともに「もの」に外化できることが重要だ というのは、すごくいいなーと感じた。

もちろんお仕事でもスパイクして見積もってーみたいなプロセスを踏む事もあるから似てるかもだけど、まあ、それが自分にとって期待感のあるアイデアかどうかだけみたいなものか。

でも最近ホント、わーと作る力が衰えてきて辛い。本にも書いてあるけどただただ勉強不足なのだ。

/dumped

FabLife 一章だけ読んだ

最後まで読んでからと思うと、だいたい時間空きすぎて忘れてるのでとりあえず一章で。。

一章はファブラボの歴史みたいなものと、世界各地のファブラボやそこでどういう事が行われているかが説明されています。

私のファブラボのイメージは、書籍にも出てきますが、鎌倉や渋谷にあるファブラボのイメージで（最近だと秋葉原の DMM のもそう呼べるのかな？）コワーキングスペースの延長みたいなもんかと思ってました。

でも、読んでみると全然違って、工房であり、学校であり、カルチャーセンターであり、遊び場でもある、そんな感じでした。ソフトウェアの話に置き換えるとハッカソンを年中やってるスペースがあるような感覚なんだろうか？

Make 系のイベントや場は（まだ東京に居た頃の） 2 年前の MAKER Fair Tokyo に行ったことしか無くて、あれはカンファレンスな感じだったので、たぶん全然空気感みたいなものを分かっていなかったんだと思うけど、それでも、そこで話している人や聞いている人もすごく楽しそうで羨ましさを感じたのを覚えている。（もちろん、ソフトウェア業界がそうではないとかではないけど、なんとなくです）

残ったキーワード

パーソナル・ファブリケーションとは、大量生産に向かう前の時代の精神を現代の眼でとらえ返し、いまの技術環境の上にアップデートしていくことでもあるのだ。この技術がときに「新しいようで懐かしい」といわれる理由は、おそらくそこにあるのだろう。過去を捨てて未来へ突き進んでいくのではなく、過去を未来へ繋げる手段なのだ

なんとなく「ラダック 懐かしい未来」を思い出した。

僕は山村に住んでいても、テクノロジーに頼って生きているし、ヒッピーのような生活がしたい訳でもない。それでも、手作りのものが好きだし、テクノロジーも自分たちに寄り添ってくれるレベルのものでなんとかできないかと思ったりする。 そういう事をいうと、「前時代的」「技術者なのに何を言ってるんだ」と言われそうだけども、少なくともパーソナル・ファブリケーションは技術を自分たちに取り戻そうとしている点ですごく共感できる。（とはいえ、MIT Media Lab でやっているような、未来ぽい取り組みはすごく好きなので激しく矛盾はしておりますが。）

「世界の周縁の人こそ、先端技術を真に必要としているのだ」（ニール・ガーシェンフェルド教授）

一昨年まで東京に住んでいて、今も東京と山村を行き来していたり、東京の仕事をしていたり、テクノロジーのニュースを見ていると、東京にコレ以上何が必要なんだろうと思うことがあったりなかったり。

とまあ、都会は都会ゆえに不便になる部分があったり、生活が過密になったりするので、そこを解消したり効率化したりというのはあるのは分かるので必要は必要なんだと思います。（実際、私も住んでてそう思いましたし）

私の住んでる山村なんて世界の周縁とは言えないですが、少なくとも日本の周縁ではあると思う。田舎はホント良くも悪くもいろんな前提が通じなくて、驚く程に 人 が有効に機能している。（逆に人が機能しないところは、かなり辛い）

また、いろんなものがコンパクトであるがゆえに、大型の機械や自動化がされていない部分がたくさんある。（人でやった方がコストが安いから） 加えて、土地によって条件が異なるため、カスタマイズ無しにしては辛いものがあったりする。

たまに地方の課題解決系のハッカソンみたいのを見かける。素晴らしい取り組みだと思うし、現地の人の話まで聞いて出てくるソリューションは有用なものになるかもしれないと思う。 ただ、最終的には、ファブラボのようなものが地域に根付き、高度にローカライズされて、最終的にはパーソナライズされる事で、役立つものが仕上がるのではないかと思ったりする。（そんな事はないかもしれない）

そして、そういう場所で利用されるのは実は東京から遅れたものではなく、先端技術なのではないかというのは、なんとなく感じる。

「ファブラボのクリエイティブな雰囲気をつくるのにいちばん大事なのは、いい音楽（Good Music）とおいしい料理（Free Food）だよ」（ファブラボ・アムステルダム アレックス）

まあ、均一に机が並べられたオフィスではないってことだけは分かる。

とは別に、ポートランドに旅行に行った時も、いろいろお店回ったり、現地のガイドの人にスタートアップの話を聞いて思ったのも似たようなことだった。（ポートランドはビールだったけど）

なんか自分も、せっかく山村の一戸建てをオフィスにして働いてるんだから、いい音楽と美味い飯の中で仕事すれば、もすこし楽しめるかなと思ったりした。（クリエイティビティが求められる仕事ではないけど。）

/dumped

Yosemite にした後に出た Ruby と Homebrew の問題の対処

たぶん Yosemite だけじゃなくて、他のセキュリティアップデートとかも絡んでたり自分のやり方の問題もあったと思う。

bundler が動かない

Ruby は 2.1.2 を rbenv 経由で使っていたのですが、急に Symbol not found: _SSLv2_client_method (LoadError) を含むエラーが出るようになりました。

事象、解決策ともに以下と同様で、インストールしなおしたら大丈夫でした。

• Yosemiteにした時にSymbol not found: _SSLv2_client_method (LoadError)が出たら

ついでに恒例の therubyracer でハマる。。

なんか以前もこのサイトにお世話になった気がします。

• どう頑張ってもtherubyracerがインストールできなかったあなたに贈る僕がインストールできた時の方法 - 俺のタコメータは常にレッドゾーンを指してる

置き換えまでしなくても、一時的に参照する先を変える方法も見たよという同僚情報があったことも付け加えておきます。

Homebrew が動かない

明らかに何の関係も無い気がしますが、なぜかついでに brew update で失敗してgit の変更が残ってる的なメッセージで絶望感を与えてくれました。

とりあえず、brew のディレクトリに移動して、変更を無しにしようとし git stash とか打ってみたら権限無いと怒られる始末。。

• homebrew の update でエラー発生 - [Takuya71]の日記
• HomebrewのUpdateで失敗したときの対処 - Scribble

brew doctor 大事。。

結局は以下で大丈夫でした。

• brew のディレクトリのパーミッションの問題を解消
• 変更点を無しにする

$ cd `brew --prefix`
$ sudo chgrp staff .
$ sudo chmod 775 .
$ git fetch origin
$ git reset origin/master --hard
# 上記の git の操作は git stash && git clean -f でもいいのかも

ぶつかった問題の記録を残してくれている先人に今日も感謝です。

Homebrew と dotfiles 周りの設定見直し

滅多にやらないのだけど、いつぞやから brew bundle がなくなっていたのをついにスルーできなくなってしまったので。（仕方ないから brewfile 使ってるのに普通に brew install するというダメさ。）

Brew-file

• rcmdnk/homebrew-file
• brew-file: Brewfileを扱うbrewallを改名した - rcmdnk’s blog

前準備

• brewfile から || true の記述をざくっと取り除く。開いたのが Vim だったので:%s/|| true//g とかした。
• brewfile から tap homebrew/versions || true の記述を取り除く。なんで入ってたのかは覚えていない。
• dotfiles を管理するリポジトリに既存の brewfile を追加する。ちゃんと push しておこう。

Brew-file を使うようにする

$ brew install rcmdnk/file/brew-file
$ brew file set_repo -R dany1468/dotfiles # https の URI 入れたら結局 <user>/<repo> で聞き直されたので、最初からこれでいい気がする
$ brew file edit # 既存の brewfile が開く
$ brew file push # これで Github のリポジトリに push 完了

この後は、新しく brew install hogehoge した後に brew file update するか、直接 brew file brew install hogehoge していくのかと思う。

既存の brewfile が無い場合は brew file init してから使いはじめるのかな。もろもろ参考リンク参照で。

homesick

dotfiles の運用は前から homesick 使ってたのだけど、いつからかコマンド忘れてちゃんと更新しなくなってたので改めて。

• technicalpickles/homesick

場所

$ ~/.homesick/repos/dotfiles/
$ ls
home brewfile
$ homesick cd dotfiles # これでも移動できる

dotfiles はそういう名前のリポジトリだから。homesick 的には CASTLE と呼ばれます。

直接編集したい場合は homesick edit dotfiles でも大丈夫。（$EDITOR の設定が必要）

変更する、追加する

$ homesick diff # 変更してたら変更点が見えるよ
$ homosick track 変更したファイル dotfiles # 最後は CASTLE 名
$ homesick commit
$ homesick push

track で git add、commit, push はそのまま git commit, push が行われているイメージ。

他にも機能ありそうだけど、とりあえず直近困らないここまでで。