no_picture

FlowとTypeScriptを同時に使う話を大正GeekNight Vol.2でしました

大正GeekNight Vol.2 で「静的型なきJS界を救う英雄たちの話」というタイトルでLTをしました。 実は会場に行ってなくて、LTしてる動画を録画して送りつけるという参加方式をとりました。 なぜ、会場に行かなかったかというと、私は介護者と共に行動する必要があり、イベントの時間は子供を寝かせる時間帯で、子供も連れてくるという選択肢以外には、録画かリモートで発表する必要がありるためです。 連れて行くという選択肢はありえないし、寝かせるタイミンで配信なんてできるわけがないのでがんばって録画しました。録画するタイミングもあんまりなくて大変だった。動画は倉庫に封印しています。 中身がないので、公開する予定は今のところないですが、希望があれば検討するかもしれません。(もしくはリベンジ) サンプルプロジェクトはこの辺に投げてあります。 https://github.com/eiel-sample-code/flow-with-typescript さて、本題ですが、身近なエンジニアがTypeScriptを始めた的な発言をしていたらFlowもどうですか?と聞いてみる遊びをしていたところ、同時に使ったらどうなるんだろうと気になったので、やってみたらできたというのが発端です。 といっても、TypeScriptはちょっとしかつかったことがなかったので、どんなことができそうか判断するために、FlowのドキュメントにあるコードをひたすらTypeScriptのPlaygroundで試すという遊びをしてみました。 その結果、ファイル分割していくとimportがつらそうだなとわかったので、importをつかいつつ両方でエラーできないコードと、FlowとTypeScriptでエラーがでるのが違うところになるようなサンプルコードをかいて、簡単に解説するという話になりました。 紹介した内容は、 MaybeがないのでHoge | nullというnullをくっつけたUnion TypeをつかってMaybeの代用してみた Object Typeの挙動の違い になります。 ところで、このサンプルコード大失敗があって、noImplicitAnyぐらいしかtrueにしていないというミスがありました。 https://github.com/eiel-sample-code/flow-with-typescript/blob/master/tsconfig.json#L4 スライド上にあるFlowだけエラーになるコードはTypeScriptでもstrictNullCheckをつけるとエラーになります。 TypeScriptの評判を落とすような誤解を招く可能性が多いにあり大変申し訳ないです。 蛇足ですが、個人的にはObject Typeの挙動が結構好きなので、Flowを使うのが楽しいです。 というわけで、あまり詳しくないものを活用して、思いつきでLTする場合は、有識者のレビューをいれるとより良いものになると思いました。 その他のFlowとTypeScriptの違いに興味があれば、FlowのドキュメントにあるコードをひたすらTypeScriptのPlaygroundで試すなど参考にしてみたりしてください。

no_picture

Hiroshima.rbから見たRubyKaigi 2017という奇跡

こんにちは。 「俺がHiroshima.rbだ」といっても過言ではない@eielhです。 そういえば、@jmettrauxが引き継いでしまったので、「俺が元Hiroshima.rbだ」が正しいかもしれません。 最初に書いておきますが、この記事はただのポエムである。 RubyKaigiが広島で行われたということは、PHPカンファレンス(本体)やPyCon JP(本体)、ScalaMatsuri(本体)などなどその他諸々が広島で行われる可能性だってある。もしかしたら広島以外でも開催されるかもしれない。 そういうことに繋がることを信じて、私の心境とか、心境に至る経緯を書き記しておく。 先日、我が師でもあり、弟子でもあり、ライバルでもある@NeXTSTEP2OSXがRubyKaigi (本体) が広島に来ることがいかに貴重なことかを語った。 それを踏まえて、Hiroshima.rbを始めた私にとってRubyKaigi 2017がどんなものであるのかを書きたいと思う。 私は何者なのか 2009年12月にHiroshima.rbを立ち上げ、2010年より広島でRubyに関するイベントを開催してきた人です。 2017年4月に病気の治療として補助人工心臓というものが植え込まれてしまい、大阪の病院の近くに住まないといけない状態になっています。詳細は最後に記載の別記事を参照ください。 「RubyKaigi 2017の開催を広島で」という話が出てきた頃はまだ広島に住んでいて、広島の最初のオーガナイザーとして参加しています。 しかし、3月より4ヶ月入院していたため、ほとんど名前だけのオーガナイザーです。 参考1 RubyKaigi 2017 Team 参考2 4ヶ月ほど入院してプログラマとして感じたこととか せっかくなので集客につながる活動ができればいいなと思いつつこんな記事をかいています。 Hiroshima.rbのはじまり ところで、さきほどの補助人工心臓を植え込むに至る病気が診断された頃の話をする。 それは2009年の7月でHiroshima.rbが立ち上がる数ヶ月前である。 私は25歳でした。 地方のIT事情に物足りなさを感じており、東京へ行ってみたいと思っていたりした頃です。 東京には技術的に楽しそうな勉強会がたくさん行われており、地方で生活する人間としてはとても羨ましく思うものです。 実際、多くの地方の優秀なエンジニアはどんどん東京へ行ってしまいました。 そんな頃に健康診断で心臓の機能が弱っているということを知ることになりました。 そこまで大げさ状況ではなかったのですが、なんとなくやる気は消失もして、仕事にも行かなくなっていました。 体力的にも独りで東京へ行くのも難しいです。 がんばる意味なんてあるだろうか。 その瞬間にはは特になかったのは間違いないです。 (最終的には一人で東京に遊びにいくぐらいには病気にはなれてしまうのですが) そうは言っても生きていかなければいけない。 どうせ生きていくならもっと楽しく生きていきたいと考えました。 私は少しづつ、少しづつさまざまな活動をはじめていきました。 その活動目的は「自分にとって楽しい場所」を作ることでした。 東京まで行かずとしても、自分にとって楽しい勉強会がもっとあれば良いと思ったわけです。 そこで、自分の興味があることで、最も人が集まりやすいだろうと思う「Ruby」をメインとした勉強会をするためにはじめたのがHiroshima.rbだったのです。 RubyKaigi 2017が広島で開催されるという奇跡 そんなわけでHiroshima.rbはちょっと変わっていて有名なRubyistと繋がりがあるわけでなくスタートしました。 Rubyコミュニティとしては完全に孤立していたのです。 あれから9年。そんなRuby的に孤立した広島で、今回RubyKaigiが行われるわけです。 私からすると奇跡にしか思えない出来事です。 それもそうで、広島開催に至る理由は 広島国際会議場に、たまたま僕らの希望の日程で空きがあったから 日本中探しても、そこ以外に僕らが探している条件にマッチした会場が見つからなかったから と記されています。 Hiroshima.rbの活動による影響は微塵もありません。 しかし、Hiroshima.rbが目的としたことが大きく達成できてしまいます。 オーガナイザー広島チームにすらRubyKaigi体験者はいません。 たくさんのrubyistとオフラインの繋がりもできるでしょう。 会ってみたい人もたくさんいます。 新たな出会いもあるでしょう。 そんな私の中から出てくる言葉は「うん、わけがわからない」でした。 こんな奇跡はなかなかない。 しかし、私は当日参加することはできそうにありません。なんてこった。 この奇跡をもっと活かそうぜ RubyKaigiを広島で成功させることは、今後RubyKaigiのようなテクニカルなイベントが広島で行われる可能性が高くなります。 これは広島がたいへん楽しい場所になります。 私にとってはたいへんお得です。 もし、同じようにたいへんお得だと思うのであれば、さりげなく宣伝してみたり、参加してみて国際会議の空気感を掴んでみたり、運営のノウハウを盗んだりしてみると良いと思います。 東京に行くことに比べるとたいへん低いコストで参加することができます。 素晴らしい経験になると思います。

no_picture

広島人によるRubyKaigi 2017のためのグルメ情報

広島が誇るスーパーエンジニアそーだい(@soudai1025)がRubyKaigiのための昼飯情報を提供している。 Rubyistが今すぐ知るべき大切なこと それに対抗するわけではないが、私が県外のイベントに参加したときに困った経験を参考に記事をかいてみることにする。 中立的に書きつつも、個人の主観を大量にいれているのでご注意ください。 また、個人で出てくるネタにも限界があるので、後に続く人がでてくると嬉しい。 RubyKaigiは1000人規模のイベントであり、1000人が一斉に昼ごはんに向かう事を考えるとおすすめの店を紹介するだけでは、役に立たない。 だから、会場の国際会議場周辺の事情中心に最初は書いていく。 どの方向にいけばどんなものがあり、キャパがどのくらいあると想像できるかも記していく。 つまり、近辺は広島グルメかどうか問わずかいていく。 また、遠くになるとさまざまな飲食店があるのでおすすめのみに留める。 広島グルメの復習 お好み焼き - 定番。派生もので府中地方の府中焼きもちらほら。地元の人は肉玉そば・肉玉うどんをたべるが観光客向けに牡蠣をトッピングしたものなどがある。量を食べたい場合は、麺ダブルというトッピングが定番。麺が増加すると焼き加減がいまいちな店がまれにあるので注意。 広島つけ麺 - 唐辛子のたくさんのったつけ汁でいただくつけ麺。野菜がたくさんのってることがおおい。お店にもよるが辛めを挑戦することをおすすめします。 広島ラーメン - 豚骨醤油の中華そば。 汁なし担々麺 - 現在広島B級グルメの王者。辛いものが苦手ならやめておくほうが良い。つけ麺よりリーズナブルですが、野菜などはあまりついていません。 あなごめし - A級グルメになってしまうのでお高い。広島市内ではそんなにお店はない。宮島口のうえのが有名。市内では弁当が購入できる。弁当もとてもおいしい。 牡蠣 - 定番。当たっても自己責任の世界。生ガキを食べたいなら、最終日や帰る前にどうぞ。 タコ - 居酒屋にいくと三原のタコがおいてあることがある。 ウニホーレン - 居酒屋にいくとあるけど、グルメとして名物なだけでウニがとれるわけではない。 小イワシ - 居酒屋で食せることがおおい。 ホルモン天ぷら - あまり知らない。誰かフォローたのむ。 番外 呉冷麺 - 食べれるところは少ないが広島市でもたべれる。ゴマダレの冷やし中華に近い。(あんまり詳しくない) 尾道ラーメン - 食べれるところはあるが、とりたてておすすめを知らない。 周辺状況 RubyKaigiは広島国際会議場で行われる。国際会議場は平和公園の南側に位置する。 周辺は公園なので、そこそこ移動しなければ、飲食店はない。 適当にぶらつきたいなら、大手町(南側)や紙屋町がおすすめ。 北方面はしばらく平和公園でやがて川にぶつかってしまうので、平和公園を散策したい、原爆ドームが見たい場合はかまわない。その場合、結局紙屋町方面にすすむのと同じになる。広島市民球場跡地でイベントをやってることがある。今回にかぎるとオクトーバフェストをやってる。 西方面は僕はあまり詳しくないが、いくつか飲食店がある。なんとなくいってみるのは有りです。 国際会議場は西方面が近いので、試しにいってみるのもよいでしょう。 南方面はお好み焼き屋、つけ麺屋、セブンイレブン、寿司屋などがあるがほとんど店舗はない。目的がない限りはおすすめしません。 間違いなく100席分も飲食店はありません。 (グーグルマップから引用したが、コピーライトがきれてしまっています) 東方向の南側 大手町(南) 東方向にすすんで、橋をわたって右手に位置する。 汁なし担々麺のお店が多く存在するので、辛いものが苦手なければ、第1候補となる区域。 更に東にすすむと小町区域。南に進むと鷹野橋というところへ行ける。 汁なし担々麺のお店が本当に多く、はずれはない。 キング軒 マップ 万人におすすめ。 花山椒 マップ 本物を追求したい人へ。

no_picture

4ヶ月ほど入院してプログラマとして感じたこととか

毎月スライドが公開されてたブログが突然と更新されなくなって驚かれたかもしれませんが、3月20日から4ヶ月ほど病院に入院していました。 せっかくなので、入院している中で感じたことを書き下しておきたいと思います。 (しかし、この記事は書き始めて1ヶ月後に公開されたため、ある程度日常生活をした上で書かれている) 本記事を結論を述べておくと「プログラマはこんな体でも世の中に貢献できる可能性がある」と感じた。 座っていて作業できて、リモートワークできる。努力しだいでは、世界で活躍するのも可能だ。 (世界で活躍はできていないけど) ざっくり目次 一体なにがあったのか 入院中に感じたこと 入院生活で改善したいこと 今後のこと まとめ 一体何があったか 心臓の血液を全身に流すチカラが弱くなってしまった。 もともと弱くなっていることはわかっていたが、これが悪化してしまい日常生活ができなくなりました。 そこで、補助人工心臓装置を体に植え込み、装置とうまく付き合うことで日常生活が送れるようになりました。 「安静にしとけ」って言われた同じような病気がある人は本当に無理をしないことをおすすめしたい。 無理をすることは自らに大きな制約を課すのと同等だ。 (そうは言われてもどこからが無理のある範囲なのかわからへんのや) より詳しいこと 広島の病院に入院していましたが、状況が改善しないため、より高度な治療が可能な大阪の病院に転院した。 治療法としては心臓移植をしかないが、現在の移植待機中の人達が大勢いるため、移植ができるのは3年以上先の見込みである。 移植する心臓は全く足りていないようだ。 代わりに、植え込み式の補助人工心臓装置を装着することで、退院可能な状態になる。 私は4月末に人工心臓装着し、7月末にさまざまな訓練を終えて退院した。 補助人工心臓を扱える病院は広島にはないため、現在は大阪の病院の近くに住んでいます。 大阪に移動するときヘリだったんだけど、ずっと寝たままで怖かった。 ヘリで移動後は、3週間ぐらい電波禁止の病室にいて、インターネットがつかえなくてさまざまな人と連絡とれなくてつらかった。 そういえば、脳梗塞とかもおきて、片目が動かなくなった。 さすがに仕事ができなるかとおもったけど、なおった。よかった。 人工心臓装置装着後のリハビリはたいへんって脅されたけど、中学生がやっているような炎天下の部活に比べたら大したことはなかった。パソコンが使えないため、退院するためにも、リハビリに対するモチベーションはかなり高かった。 結果、リハビリでは、補助人工心臓装置装着者の中では、最速の歩行速度という称号を得ることができた。 現在の状況 いくつか制限があったり、面倒なこともありますが、ほぼ普通に生活しています。 プログラミングもしたり、でかけることもできます。 最近は4時間ぐらい継続して作業することもできるようになってきました。 より詳しいこと イベントの準備を手伝ったり、Flowで遊んだり、Rustで遊んだり、Swiftで遊んだり、Scalaで遊んだりしています。 ETAとElixir、Kotlinあたりも遊びたいですが、作るものが浮かびません。 話がそれましたが、二人暮らしで妻が妊婦なため、買い物は重いものを持つ必要があったりするのが、他の装着者には無さそうな苦労です。(車ももってないし、この辺は坂が多い) 補助人工心臓は胃の上あたりに植え込まれていて、電力供給するためのケーブルがお腹から出ています。 また、お腹から出ているケーブルには、コントローラとバッテリーが接続されていて、このコントローラとバッテリーを入れた2.5kgの鞄を常に持ち歩いています。 コントローラとバッテリーの予備も常に持つ必要があり、出かける場合は5kgほど追加で持つ必要があります。 他の装着者は介護者が持つと思いますが、なるべく自分で持つようにしたいと思っていますし、そこそこ持っています。 ケーブルが出ている部分にチカラがかからないように活動する必要があるため、しゃがんだりすることが禁止されていたり、行動が制限されています。 また、週2回ほど消毒作業をしていて1時間弱かかっています。 お風呂は入ることができず、シャワーになります。 お腹まわりをラップのようなもので保護をして、コントローラとバッテリーは保護用のカバンに入れ替えて、カバンを持ち込んでシャワーを浴びることになります。 あとは補助人工装置を扱える介護者がアラームの聞こえる範囲に必要があります。 どちらかが外に用事がある場合は、二人で必ず出かける必要があります。 お腹から鞄までのケーブルがむき出しなので、出かける際は引っ掛けないように気を付けないといけません。 人の多い場所はたいへん危険です。 残りはほとんど普通の日常かと思います。 入院中に感じたこと 看護師プロ意識 患者の命を預かってるという意識をもって仕事しているのを日々感じた。 僕らはシステム利用者のビジネスを背負って仕事できていただろうか。 気がつくと目の前のものを完成させるのに精一杯になってしまってないだろうか。 その前に大半の人が補修が少なすぎるという話はあるかもしれないけれども、そもそも独学で始めたような人達も多いし、作ることしか考えれていない場面はよくみかける。 プロ意識みたいなのは欠けていないかときどき自問自答したい。 医学すごい 医者は数値としては曖昧な反応をみて対処をしていく。 プログラムは書いたとおりにうごくので、ずっと扱いやすく発展しやすいけど、こんな曖昧な数値しかとれないものが発展しているのは本当にすごい。 曖昧ではなく、成否のはっきりするコンピュータを扱っているので、もっとうまく扱っていきたいと感じました。 入院生活で改善したいこと、改善して欲しいこと テレビカードいらないからインターネットカードが欲しい テレビとかいらないんで、インターネットさせてください。 暇なのでセミナーの動画とか見たかったです。 パソコン使わせてください パソコン使えれば、開発できるのに。

no_picture

広島フロントエンド勉強会で、カスタムエレメントの話をして、divタグの代わりにはつかえるんじゃないか?というLTをした

広島フロントエンド勉強会 Vol.7でライトニングトークをした。案の定早すぎると言われた。いつものことである。(結構削ったんだけどな) 「すごい広島」でA-FRAME触ってる人がいて、A-FRAMEをみていたらカスタムエレメントをつかってるみたいだったので、調べたついでに思ったことを述べた。 「カスタムエレメントは独自のタグが使える」ぐらいの理解で充分かなっとおもってます。 Angular2にしても、Reactにしても、Riotにしても、Vueにしても独自タグのようなものがでてくるので、独自タグを定義できるという感覚は慣れておいて損はないと思い話を考えました。 本題ですが、カスタムエレメントは要素が定義するまでは未解決の要素となり、正当なエレメントになるらしい。 要素は定義の通りにアップグレードされるまでの間、 未解決の要素 と呼ばれます。これらの HTML 要素は正当な Custom Element 名を持ちますが、まだ登録されていないものです。 https://www.html5rocks.com/ja/tutorials/webcomponents/customelements/ ということは、エレメントを登録しなくてもつかえそうだし、特に中身を実装しなくても、使うことで可読性の高いマークアップができるような気がしました。 というわけで、特に何も実装してないカスタムエレメントでマークアップをすることは、カスタムエレメントの入門としてありなのではないかと思ったわけです。 div だらけでモダンと言えるでしょうか?そして現状では、これが我々のウェブアプリの作り方なのです。悲しいですね。 我々はウェブプラットフォームからの恩恵をもっと受けるべきだとは思いませんか? https://www.html5rocks.com/ja/tutorials/webcomponents/customelements/ カスタムエレメントの誕生の意義からも全く外れていません。 独自タグの要素にCSSも問題なく使えます。定義しておかなくてもバッチリスタイルもあたります。 カスタムエレメントのAPIはv0とv1があるようです。 v1のほうが対応ブラウザが多いですが、v0はPolyFillもありますし、class構文が必要ないので、v0 APIのほうが実質対応ブラウザが多い気がします。class構文無しでもv1 APIは使えるみたいですが、結局未対応ブラウザはAPIが足りなくてつかえなさそうでした。(調べたメモがどっかいったのでソースは省略) あとカスタムエレメントに対して知っておきたいことは、 独自タグの名前にはハイフンを含む必要がある カスタムエレメントを定義する前に利用しても良い まだAPIが変わる可能性がある かなとおもいました。 「独自タグの名前にはハイフンを含む必要がある」というルールをみてA-FRAMEはいい名前をとってるなと感じました。a-で始まるタグはA-FRAMEのタグになるので、完全に一等地ですね。 Z-FRAMEはどんなライブラリがとるのかとても見ものです。 カスタムエレメントをマスターしたら次のステップはShadow DOMなんですかなー。 ためしにかいたコード <my-app> <my-contact> <my-header>連絡帳</my-header> <my-user>hoge@example.com</my-user> </my-contact> <my-inbox> <my-header>受信箱</my-header> <my-mail>2016-01-02 hogehoge</my-mail> <my-mail>2016-01-03 hogehoge</my-mail> </my-inbox> </my-app> body { display: flex; justify-content: center; align-items: center; } my-app { display: block; background-color: #eee; width: 300px; } my-contact {

no_picture

オープンセミナー2017@広島の申し込みが少ないので、興味を持つ人が増えるように内容について個人の見解を述べる

2017年2月25日(土)にオープンセミナー2017@広島があります。 いまいち申し込みが少ないので、テコ入れにすらなるかどうかわからないですが、スタッフの個人の意見を述べることで、オープンセミナー2017@広島がどんなイベントが理解してもらい、参加者を増やすのが目的です。 この記事にかいてあること 広島のITエンジニアが集まって交流するイベントが一つはほしい 今回のオープンセミナー広島の内容の個人的な推測 テーマはいままで参加してくれていない人たちへのアプローチするのが主な目的 懇親会の申込みは20日(月)まで 懇親会LTはありません 広島のITエンジニアが集まって交流するイベントが一つは欲しい 私は、地域ごとに毎年ジャンル問わない大きなITエンジニア向けのイベントがあると良いと思ってます。 その地域にいく機会が欲しいからです。 自分が追っている特定の技術を扱うイベントは県外でもいくことはありますが、地方ではなかなか難しいです。 自分の住む地域より人の少ないところへ行くことは少なく、より人の多い 都会へ出かけていく事が多いと思います。(例外はある) そんな、県外に住むエンジニアが「広島に行ってみよう」と考えたときにちょうどいいイベントがあると嬉しいかなと思うわけです。 こちらも誘いやすいです。 私も山陰や四国に行く機会があれば行きたいとおもいますが、どうせ行くならその地方にいる優秀なエンジニアが集まっているイベントが良いかなっておもいます。 個人的にも、お誘いはそこそこお待ちしています。 正直な話、広島に行くのにちょうどいいイベントがオープンセミナー広島である必要もないわけです。 比較的そういう位置に育てやすいのがオープンセミナー広島という感じです。 ぶっちゃけ、OSC広島は昨年は学生もたくさんいて、むしろOSCのほうがいい線をいってるかもしれません。 私はオープンセミナーのお手伝いを2013年ぐらいからしています。 特定の企業が運営しておらず現場で働くITエンジニアがボランティアで運営するイベントの中では広島で一番大きいと思います。 しかも、突然運営に参加した人がこれまで培ってきた下地を掌握しやすいです。 特に、広島で起業するエンジニアがうまく活用して欲しいと思っています。 今回のテーマについて テーマは「エンジニアがより良い社会を作れる!!」です。 テーマはキャッチーですが、個人的にはセッション内容がピンとこない印象です。 エンジニアが参加して何が得られるのでしょうか? 背景としては、今回の実行委員長である石崎さんがCode for Japanが行っている鯖江市でのコーポレートフェローシップの経験を活かした構成になっています。 「SIとして働いてきたエンジニアがすこし違う世界にいってみたら、目の前に困っている人を助けられる経験ができて日々が楽しく変化したいから共有したい」と、推測しています。(推測です) 参考 鯖江市でのコーポレートフェローシップが始まりました #codeforjapan そこで、実行委員長の石崎さんが鯖江で出会った「利用者に最も近いソフトウェアを提供し、より豊かな社会を実現する」ために活動する福野さんが講師として登場することになったわけです。 福野さんの最近の活躍で私が知ってるものは3月に結果が発表されるRESASのプログラミングコンテストの審査員を務められていますね。(応募締め切りは今週末2月19日なのでまだ間に合いますね) まとめると、石崎さんが出会った、外の世界、身近な世界にあった驚きや、発見を得られるのではないかと思います。(推測です) その他の講師について myThings使ったIoTによる地域課題解決 山本 学 今回どんな話をしてくれるのか僕もよくしりません。 昨年も広島にこられていて、myThings X HMCN#3で講師を務められています。 蛇足ですが、HMCNとうまく連携しようという私の目論見もありましたが、まったく交渉していません。 SIerは企業のシステムを構築することで社会に貢献してきたとおもいます。 近年登場してきた IoTというキーワードは、企業をアシストするのではなくて、エンジニアが直接社会に貢献できるチカラともいえると思っています。 そんなIoTをどのように活用しているのかを聞けるのではないかと思います。 Engineer is Hero !! マイクロサービスの開発手法や IoT を採用し感情や表情を解析しより良い社会を作ろう 寺田 佳央 もはや語るまでもない #てらだよしおがんばれ の寺田さんです。 福山市出身らしいです。蛇足ですが、福山市出身のそーだいさんはエンジニア界でもホットですね。ちなみに、そーだいさんは先週末中国地方を旅されてたので、今回は来られないのではないかと思います。(ってかいておいたら来てくれるかもしれない) 昨年末開催された広島Javaユーザグループのイベントで寺田さんが登壇されましたが、参加者が少なかったので、もっとたくさんの人に効いてもらいたいのと今回のテーマと相性がよさそうということでお招きすることになりました。 技術的な話もしっかり聞けると思います。 子どもプログラミングとドリームマップ 花谷 美香 身近な社会を変化させるという点においては教育はとても重要です。 未来の社会を担うのは子どもたちです。 子どもたちが、プログラミングの価値を理解する機会が増えています。 プログラミングが得意な人たちは、プログラミングに無限の可能性を感じるはどんな人たちに映るでしょうか?

no_picture

Firebase Hostingの紹介をした - WEB TOUCH MEETING #96

WEB TOUCH MEETING #96でFirebaseの紹介をしました。対象者としては、「レンタルサーバを借りたことがあって、独自ドメインの設定をしたことがある」ぐらいに設定してお話をしました。 Firebaseを試した時に感じたのは、「Googleが用意したWebアプリケーションを作る手軽な場所」でした。 今まではその役割をGoogle App Engineが持っていたようにおもいます。 しかし、次世代のGoogle App Engineとなる Flexible Environmentは無料では始められないようになっています。 この部分にFirebaseが登場したから役目を終えたのではないかと感じました。 次に、気になったのはが独自ドメインのTLS/SSLが無料だったことです。 独自ドメインでなければHTTPSがつかえるサービスは確実に増えていて、困ること減っているとおもいます。 また、VPSなどあれば無料で証明書は発行して、HTTPSに対応できるようになってきましたが、ブログサービスなどの活用をしようとした場合、なかなか無料で独自ドメイン使えるものはありませんでした。 そうしているうちに状況は変化してきて、 2017年1月からGoogle ChormeがHTTPのサイトは警告を出すようになるそうです。 HTTPSでないサイトではiOSの一部の機能が使えないそうです。 先日Jimdoが独自ドメインのHTTPSの対応を発表したりなどありました。 HTTPS everywhereを現実に迎える直前で、良いタイミングだと思ってFirebase Hostingを紹介しました。 アプリケーションに満たないちょっとしたWebサイトを公開する際の一つ 他の話はおまけ程度のつもりで以下の話もしました。 FTPは使えなくてコマンドを使う必要があるよ でも簡単に前の状態に戻せるよ Firebase Hostingにドメインを割り当てると、サブドメインを別のFirebaseプロジェクトに割当ができないよ Firebaseの他の機能を使うとこんなことができるよ FTPでファイルを手動でアップロードしてる人たちの考え方が変わると良いなと少し思いました。 デモサイトの話 https://eiel.info/をリニューアルついでにデモとして使いました。 サインインをすると挨拶ができるという機能が実装されています。 リアルタイムに反映されるのをみていただきました。 ソースコードは以下に公開しています。 eiel/eiel.info Tag wtm96 React.js + material-ui を利用もしていますが、その話は一切しませんでした。 最近はウェブサイト作る必要がある際にmaterial-uiを試しています。 Firebaseに関するコードだけ抜粋します。 JavaScriptですがBabelを利用して、ES2017が使える状態にしてあります。 firebaseの利用準備 import firebase from 'firebase/app' import {} from 'firebase/auth' import {} from 'firebase/database' const config = { apiKey: "xxxxxxxxxxx", authDomain: "xxxxxxxxxxxxxx", databaseURL:

no_picture

広島から岡山への距離 - 大都会岡山 Advent Calendar 2016

大都会岡山 Advent Calendar 2016の4日目の記事です。 書くことがないのに枠が余ってたので滑り込みました。 昨日は、razonさんの大都会が誇る「ゴールデンハンマー」というエナジードリンクについて - SHI-Zoneでした。ゴールデンハンマーとやら味わってみたいものです。 さて、書くことがないのに筆をとることにしました。 もしかすると中国地方に来たことがない方がいるかもしれないので、広島と岡山の距離感の話でもすればいい気がしてきました。 私は岡山に年に2,3回行くことがあります。 岡山に行く目的はだいたい交流目的です。 ITエンジニアとして人生を生きているため、他県のエンジニアと仲良くなることは、自分にない視点からの考えを得ることができとても参考になります。 地方だと都会にくらべて、いろんな考え方が入って来にくいと思います。 のんびりできて良いことでもあります。 岡山へ行こう 僕が広島から岡山へ行く手段は3つあります。 電車 - 片道 170分 3020円 新幹線 - 片道 40分 5500円 高速バス - 片道 150分 2900円 大体の場合が新幹線で節約したいときは高速バスで、倉敷に行くときは各駅電車なことが多いです。 ただし、高速バスは予約が必要だったり、本数もすくないので、最近は各駅の電車を選ぶこともあります。 正直、電話してまで予約したいレベルで電話が嫌いです。 新幹線を使うと3倍上早くつくのに、値段は2倍未満なのでとてもお買い得です。 旅客鉄道株式会社旅客運賃減額「第1種」が使えるとその優位性は少しおちてしまいます。 電車 - 片道 170分 1510円 新幹線 - 片道 40分 3990円 高速バス - 片道 150分 1450円 それでもやはり新幹線がお買い得でしょう。 広島と岡山の距離 広島と岡山の距離はJRで160kmあるそうです。 ちなみに、大阪から京都は40km、横浜から東京は39km程度です。 広島から大阪の間が340km程度なので、半分よりは近いため、広島に遊びにいくぐらいなら大阪方面にいくほうがよさそうな気がしてしまいます。 見方をかえれば、広島の人が関西の人と交流するのであればとてもちょうどいい場所にあります。 そういえば、広島と岡山の人が交流する目的で広島・岡山Ruby交流会01などが開催されました。 四国との位置関係も相まって、交流という観点では、人が集まりやすい地域です。 岡山で会おう 結局、何が言いたいかというと、せっかく岡山にいく予定があるので、関西や四国、山陰の人はぜひ岡山で会いたいなって思ってます。 県外ゲスト枠でセッション申し込んでしまったけど、まだ未定です。 あ、広島の人も岡山であってみたいですね。 まとめ 広島は良いところですが、広島まで来いとはいいません。 岡山もいいところです。 他県の人にも来るようにアピールしたので、広島の人も岡山にいってみてはどうでしょうか。 あんまりまとまらなかった。 明日はarisonjpさんです。もう、ギガフロート玉野しか書けないらしいです。

no_picture

とある広島のスタンプラリー - たまに広島Advent Calendar 2016

たまに広島 Advent Calendar 2016の1日目の記事です。 このAdovent Calendarは広島のことを書くようですが、「たまに」書いてあればいいらしいです。 他の人の記事のいずれかに広島のことが書いてあればいいんでしょうか。 広島の人は赤いものが好きなようで、最近よく赤いものを見かける事が増えました。 唐辛子をつかったつけ汁でいただくつけ麺。 唐辛子と山椒をつかったタレでいただく汁なし担々麺。 調子にのって辛くしすぎてお腹を痛めることもあります。 お腹を壊してしまうことを考慮すると、広島の食べ物を本格的に極めるためには、広島に住んでおく必要があるでしょう。 だって、旅先でお腹の調子が悪くなるのは嫌ですからね。 我馬のスタンプラリーを制覇しました 広島には我馬というラーメン屋があります。 広島にしかないラーメン屋の一つです。 食べられるのは「博多ラーメン」です。 広島ラーメンではありません。 傍目からみて、広島に観光に来た際に立ち寄るようなところではないように見えます。 そんな我馬ですが、昨日までスタンプラリーが行われていました。 我馬は9店舗あり、2ヶ月間ですべての店舗をまわるとホノルル往復航空券が当たるというイベントです。 1週間に一つの店舗を回らなければならないので、達成するにはなかなかハードルの高いイベントですね。 そんな、「博多ラーメン」のお店を毎週のようにわざわざ違う店舗に出向く価値があるのでしょうか? 限定麺のスタンプラリー 実は、スタンプラリーの期間中、各店舗でそれぞれ別のラーメンを食べることができます。 限定ラーメンです。 限定ラーメンは過去に提供されてきたものです。 我馬では四季のラーメンと称して、年に4回程度、限定ラーメンが提供されてきました。 限定ラーメンでは四季のラーメン以外にもあるので注意してください。 過去の限定ラーメンの一覧をみてみると38種類もあるようです。 - 歴代 限定絵ラーメン 我馬 私は第10弾の博多ごぼ天 バイ煎つけ麺あたりから存じております。 第11弾 「新派 とろ馬」は衝撃的で、ラーメンという領域を超えていたと思います。 となりにパンがあることから想像できるでしょうか? これらの限定麺はとても完成度が高いです。 そもそも手札としてある「博多ラーメン」という看板ラーメンで行列を作れているラーメン屋が、既存のアレンジで攻めてくるわけではないというのがポイントが高いです。 本来はポイントが下がりかねないですが、おかげで値段がお高くなっています。 そう、このスタンプラリーは過去の限定麺が2ヶ月だけ復活するお祭りなのです。 スタンプラリーの思い出 得にないです。 おいしかったです。 せっかくなので限定麺ふりかえる 個人的には冬の限定麺に好きなものが多い気がします。 冬は味噌ベースのラーメンが多いです。 第20弾 ベジミソ麺や第25弾 みそ菜麺はかなりハマりました。 事前に復活するラーメンのアンケートがありましたが、優勝したのは第31弾 香るウマ辛 芳辛 みそラーメンでした。 今年の冬が楽しみです。 夏はつけ麺が登場することが多いです。 カリーつけ麺は私のまわりでは傑作だと評判です。 太めの麺も毎回試行錯誤されているのではないかと思われます。 そういえば、春系のラーメンはありますが、秋っぽいラーメンってあまりないですね。 いつか松茸ラーメンとかでてくるのでしょうか? 難しそうです。 まとめてきなもの 広島には赤い名物が多いです。 我馬は「赤うま」というのが定番ラーメンです。 やっぱり赤かったです。 ぜひ一度お越しください。 たまに広島

no_picture

広島とPythonということで広島のプログラマがPythonのイベントでプログラミング言語の話をした - PyCon mini Hiroshima 2016

PyCon mini Hiroshima 2016というイベントに参加した。 参加をしたことには違いはないが、基調講演をするという立場だったようだ。 本人はあまり自覚をしていなかったわけではないが、本人的には準備不足と感じていたようである。 たぶん、もうひとつ本当の基調講演があると思っていたから油断をしていたに違いない。 実はそんなものはなかった。 (むしろ、イベントの代表である西本さんの発表が基調講演だった感じもする気がしなくもない) いろいろ話すネタを求めてPythonのことをいろいろ調べたけど、結局調べたことはあまり使わなかった。 ただ、話す際の礎になっているし、近年のPythonの状況も少しわかったと思う。 勉強会駆動ってやつはまったく本当に勉強になるな。ただし、喋る立場であれば。 「プログラミングを使い分ける理由」という依頼内容に最終的に沿うような話にしたけど、自分の中にあったものが出し切れていないきがして、個人的には準備不足であると感じているが、作品というのはどこかで妥協すべきなので仕方ない。 あまり一般的なことを話しても調べればわかることなので、自分の色が出せることを意識しつつも、知らない人には知っていて欲しいを散りばめたつもりである。 伝わったかどうかは定かではない。 技術的な話も個人的にしたかったので、時間があまったときようにもスライドを用意した。 正確には、言語の比較ネタとして用意しておいたネタなのだけど、実際につくってみたら、時間がたりないことがわかったので別のスライドにしたというのが本音である。 実際、時間はほとんど余らなかったが、無理矢理ねじこんでしまった。 口頭での説明に頼った部分もあるので、別途、解説記事をちゃんと書くつもりである。 プログラミングというのはたいていの人にとっては手段である。 言語がどうこうより目的を見失うべきでない。 とはいえ、プログラミング言語はたくさんある。 ゆえにプログラミング言語について何か語ることはできる。 プログラミング言語にはプログラムする上で楽することができる機能がいくつかあって、便利機能であって必須機能でないものも結構ある。 アセンブラは大変だけど、がんばれば高級言語で実現できることはできるよね。 プログラム自身が合成可能な性質があるため、小さなプログラムを組み合わせて大きなプログラムを構築することができる。 高級な言語ははじめから大きなプログラムを部品としてもっていると考えることができる。 すごく強力な機能、たとえば goto とかあるけど乱用するとコードを追いづらくなる。 もっと制約となる代わりになる、用途に特化した機能がループ、continue, breakとみなすことができる。 高級な言語は強すぎるチカラに制約をあたえて、秩序を与えていると考えることができる。 あとはトレードオフも重要な要素である。あちらを立てればこちらが立たない。 読みやすさを重視すると、実行速度が遅くなることがる。 (とっさに例がでてこない) それよりも、どのプログラミング言語を使うかという選択は、プラットフォームによるのが一番の現実かなとおもう。 正直な感想をのべると、プログラミング言語の学習コストより、プラットフォームの学習コストのほうが高い。 Webブラウザ、スマートフォン、Flashというフロントエンドのプラットフォームを考えてもいい。 それぞれの都合がある。 その上でマジョリティである言語がたいていの場合において最良である。 駄文 発表することについて とてもありがたいことに、以下のような評をいただいた。本当に感謝である。 めっちゃ発表慣れされてるなー,テーマが明確で聞きやすい #pyconhiro #iotlt広島 — Shinichi Nakagawa (@shinyorke) 2016年11月12日 基調講演らしい基調講演で面白かった! #pyconhiro #iotlt広島 — Shinichi Nakagawa (@shinyorke) 2016年11月12日 発表することについては、比較的慣れていることは否定できない。 しかし、私は発表するのは大変苦手である。 苦手な人間でも、回数をこなすとどうにかなるということも伝えたいが、それだけではない。 話す立場に一度でもなると、話す立場を考えて他の人の話が聞けるようになる。 やったことがないことをたくさんやればやるほど、いろんな立場で物事を考えることができる。 1を聞いて10を聞くことができるようになる。 プログラミングに限らずすべてのことに言えるが、経験できることは速いうちにたくさんの経験を積んでおくほうがお得なんじゃないと思う。 若者はぜひいろんなことに挑戦して欲しい。 ああ、どうやら僕はまだ若者のようだ。いろんなことにチャレンジしなければならない。

no_picture

Akka StreamのDelayで学ぶback-pressure という話をした - #LT駆動

LT駆動開発28でLTをした。 Scala関西Summit 2016でAkka Stream系の話をしようとおもっていたけど、結局応募に間に合わせることができなくて、ストックされていたネタを開放しはじめました。 とういうことで、ちょいちょいAkkaやPlay Frameworkの話をその辺でするかもしれません。 本題です。Akka Streamしはじめたときに、Delayでの動作がback-pressureされてることがわかりやすかったので、今回はその話をしました。 スライド内にあるコードの詳細はGistにアップしています。 https://gist.github.com/eiel/a8edc165ad316868c75766a447d57237

no_picture

各クラウドサービスのIoTソリューションをしらべたことを IoTLT広島 Vol.2ではなした

IoTLT広島 vol.2でLTしました。LTすると参加費が無料になるので。(代わりに参加費分の寄付をしました) <- 意味がない 特にネタができてなかったので、クラウドサービスを比較してみました。 AWSは王者たる風格を感じ、Azureはトータルで支援してAWSに追いつこうという意志を感じました。 IBMはWatson推しで、Googleはマイペースだなともおもいました。

no_picture

続・プリエンプティブルVMをずっと起動させてみる - #LT駆動

GAE/GoでGCEのAPIたたいて、プリエンプティブルVMをずっと起動させてみました。割りとうまくいきました。 ただ実験中に予約していたIPアドレスでそこそこお金をつかってしまいました。 そういう話をLT駆動開発27でしました。 残念ながらコードは整理していません。 ずっと起動することにモチベーションがすでに切れているので公開するのは別の機会になりそう。 いや、大したことはしてないし、必要になってしらべたことはちょいちょい記事化しているはずです。 関連リンク Go言語でGCEのインスタンス一覧を取得する - Qita GCEのインスタンス内からインスタンスのzoneを取得。ついでにメタデータの処理

no_picture

IO (Maybe a)というタイトルでモナド変換子について学んだことを話した - #LT駆動

LT駆動27に参加しました。 「IO (Maybe a)」という話をした。 自分なりにモナド変換子について整理した。 一度文章にしてからスライドにした。 そっちはざっくりQiitaにアップしておいた。 IO (Maybe String)を触ってみる - Qiita サンプルコード 個人的には先入観で誤解していた部分が整理できたので、満足している。 特になにか図にしてみるという行為は面白いとおもっている。 勉強会で発表するという行為はとても勉強になる。(自戒) LT駆動開発は毎月開催されているので、みなさまの参加を楽しみにしています。

no_picture

「プリエンプティブルVMをずっと起動してみた」という話をした #LT駆動 26

LT駆動 26でLTをしました。 最近Google Compute EngineのプリエンプティブルVMで節約しつつ使えるリソースを増やしていこうと遊んでいます。そんなに増やしてもやることはまだみつけていないけど。 Google Compute Engineには70%OFFで使えるプリエンプティブルVMというのがあるみたいです。 しかし、24時間しか使えないみたいです。 Google Compute EngineはMetadataのkeyでstartup-scriptにいれておくと起動時に実行してくれるそうです。 shutdown-scriptもあるようです。 また、インスタンスグループは指定した数のインスタンスを維持するようにインスタンスを起動してくれるみたいです。 あとは正常に終了処理ができれば、最低1日1回5分程度落ちていることがあるけど、とても安くつかえそうです。 というわけで、最近つけっぱなしにして様子をみて遊んでいます。 1台じゃ回しきれなくなったらクラスタを組んでロードバランサーも使っていくことで、1台落ちても大丈夫な状態はつくれるんじゃないかと思っていたりもします。 落ちる前提でサーバーを管理するのも結構楽しそうです。

no_picture

Scala福岡2016に遊びにいって「Scalaで関数」というLTをした

Scala福岡2016に遊びにいきました。 会場はnulabさんのオフィスで、BacklogやCaccooというナイスなサービスを展開されています。 広島にもWebサービスをやってるナイスな会社が増えて欲しいなとおもいました。 僕はScalaあまり詳しくない初心者なので、最新のネタがズバズバ跳んでるScala Matsuriとはちょっと違って、Scalaやってるなら知っていたほうがよい基礎っぽい話がたくさん聞けて、とてもよかったです。(もちろんScala Matsuriも楽しい) せっかく広島からイベントに参加したので、ライトニングトークもしてきました。 特にネタをもってなかったので、Scalaの気になっている部分のtupledやcurriedというメソッドについて整理したので、その発表をしました。 基本形の関数から、カリー化された関数、タプル化された関数の3種類があることがわかって、カリー化された関数をタプル化された関数に変換するには、一旦基本形にしないといけないことがわかりました。 ショートカットするメソッドがどこかにあってもよさそうな気もしましたが、あったらあったでカオスになりそうな気もします。(スライドの34ページ目に記してます。) Haskellとの対応を考えると、Haskellには「カリー化された関数」と「タプル化された関数」しかないと考えることもできそうで、いろいろすっきりさせることができました。 県外のコミュニティのイベントにでかけると知らない人もたくさんいるし、新たな繋がりや新しい文化を仕入れることもできて、とても楽しいです。 ぜひ広島のイベントにも遊びに来て、いろんな風を入れて欲しいと思いました。

no_picture

#LT駆動 25で並行プログラミングについて話した

LT駆動 25に参加しました。 でGoで書かれた並行処理をHaskellで書いた並行処理を比べてみました。 いろいろしらべていく過程で、最近の並行プログラミングはメッセージパッシングという手法をとっていることがわかりました。 書いたコードなどはQiitaにまとめてます。 Haskellで並行化する方法: 6秒かかる処理を3秒にしよう - Qiita 他には、ナノsimになるようにsimをカットする話や、Cloud9をつかってみた話や、流行りのセキュリティの攻撃方法や、Dockerの話やDeepLearningの話や吹奏楽の話や、資格の話などを聞くことができました。 いろんな人が最近やってることを聞くことでちょっとだけ少ない努力でトレンドを知ることができて楽しかったです。 LT駆動開発は最近勉強した内容をさくっと発表することで自分が勉強するための勉強会です。 毎月第1土曜日か日曜日に開催されています。

no_picture

bluemixで遊ぶならメモリの使用料が少ない言語つかいたいよね、という話をした - #LT駆動 24

LT駆動開発 24に参加しました。 bluemixはメモリ使用量で、課金されるので、メモリ消費の少ない言語が有利なんじゃないかと思いて、さまざまな言語で使用メモリを確認をした話をした。 全部はみていないがbluemixで提供されているものでは、Goが良さそうである。 GoならGAE/Goもあるし、Goは幅広くつかえますね。 個人的には、haskellやrustが気になるところである。リッチだし、特にRustはローカルで動作させてみたところ使用メモリがすくなかった。デプロイするにはbinary-buildpackを使うのが楽そうだけど動かすところまでやってない。 普通にbuildpackをつかってやるとbuild時間がなかなかつらそうです。(heroku-buildpack-rustは見事に失敗してまった) メモリ使用量のところを抜粋しときます。 go7MB swift14MB python40MB php57MB nodejs74MB ruby75MB .net152MB java177MB

no_picture

Hiroshima Ruby Conference 2016でしかもオープンデータデイなのでRDFの話をした

Hiroshima.rbとRuby Associationの共催でHiroshima Ruby Conferenceが開催されました。 この日はインターナショナルオープンデータデイでもありオープンデータに関する話をすることにした。 ということで、「Hiroshima.rbの情報をRDFでオープンでリンクなデータにしたんよ」という話をした。 プログラマとしての視点で、RDFについて知りたかったことはQiitaにまとめておきました。 RDFに関する雑な説明 - Qiita つづいて、RubyでRDFを作る方法をQiitaにまとめておきました。 RubyでRDFを構築してみる - Qiita そして、今回はHiroshima.rbのサイトにJSON-LDでエンコーディングして、埋め込みしました。 scriptタグを利用して埋め込みをしています。(詳細はHTMLをみてください) schemaには https://schema.org/ を利用してるのでGoogleが認識することができます。 RDFのライブラリを使えばウェブページを読み込みして、データを取り出すことが単にできるとおもいます。 RDFにするとデータをつなぐことができて分散データベースをつくることができるというわけです。 RDFはとても柔軟なフォーマットでRDFからいろんな形式をデータを生成できます。 ただし、柔軟性をを得たトレードオフとして処理効率が犠牲になります。 RDFのデータはクエリをつかって、表データのようにデータをとりだせるので、うまく使えばネットで情報を収集して、扱いやすい形式に落として別のシステムへ渡したりもできるとおもいます。 とまあ、今回はRDFについて調べて疑問点だったことを自分が知りたかったことベースにまとめたついでに実践してみたという話でした。 具体例として参考になると幸いです。

no_picture

プログラミングできなくても積極的にITと関わろう的な話をした - Code for DOGO 「CIVIC TECHって?」

Code for DOGOが主催するイベントである「CIVIC TECHって?」というイベントにお招き頂いた。 5374.jpをつくる上での工夫点や考え方を話して欲しいという依頼で60分枠だったが、とてもじゃないけど、60分もネタがない。聴衆は経済経営系の情報学部で、工学や情報学部ではないという話だったので、少し話を広げてITの意義から考えてみた。 ざっくりまとめると、 ITは人間の頭脳を拡張する ITが疎い人はもちろん・高齢者は積極的利用することで生活を便利にする プログラマと一緒につくれば、広がりもできて、コミュニティも形成できて、IT機器の使い方も効率よく学べる だから、プログラマと一緒に活動しよう ITの効果が増大すればプログラマ一人あたりの価値もあがる 的な論理の話をした。 第9次 国民生活審議会 総合政策部会報告 情報社会と国民生活という資料をかなり参考にさせていただいた。30年前の資料なのにも関わらず、色褪せない良い資料だと思いました。 スライド自体にはあまり話をいれていないが5374.jpあたりなど具体例の話は踏み込んだ話をした。 実は四国に行ったのは初めてだったので、道後温泉にもいった。 松山という街は、街の中心街から大学は近いし、松山城からの眺めもすごいし、温泉街は近いし、食べ物もおいしかったし、「ことば」がいろんなのところに散らばっていて良い所だった。 中途半端に大きい、広島よりもコンパクトで生活はしやすいかもしれない。 やはり、行ってみてわかることというのはいろいろあると思った。 そういう意味でも、積極的に行動をするというのは重要だと思う。 広島からは、船で2時間ちょっとなので、リーズナブルに旅行に行くには良い所でした。 勉強会駆動旅行も良いと思います。(準備がしんどいけど) あえて言うならば、港から伊予電鉄までがバスが走っているが、歩いても10分なので、駅の場所をもっと港に近づけて欲しいとおもいました。 最後になりましたが、スライドはこちらになります。

no_picture

ユーザーストーリーマッピングのここが面白いという話をした - #LT駆動 23

LT駆動開発23に参加した。 いっぱいいっぱいだったので雑なLTをした。 ユーザーストーリーマッピングがオープンセミナー2016@広島のテーマである「みんなでつくろうモダンな開発現場」にぴったりだとおもったので紹介しました。 あ、LT駆動開発23はオープンセミナー2016@広島の懇親会で行われました。 グラフィックレコーディングは記憶に残りやすい記録方法だとおもいますが、ユーザーストーリーマッピングもそういった手法な気がします。 実際の現場で大切なことは、チームメンバーの共通認識が重要です。この本ではそのことがとかれています。 ぐるぐるDDDは繰り返しの重要さを説いています。 強い共通認識をつくれます。 ユーザーストーリーマッピングではアトラシアンの現場の話がでてきます。 アトラシアンの現場の話がでてきます というわけで、今回のオープンセミナーととてもリンクした内容だったとおもいます。 あと感じたのはUXもアジャイルも同じところにむかってるのを感じました。

no_picture

関数型を現場に持ち込むことはモダンなのか? - オープンセミナー2016@広島でLTした

オープンセミナー広島@2016でLTさせていただきました。 「関数型を現場に持ち込むことはモダンなのか?」ということについて、現場の状況によるんじゃないですかね。関数型自体はモダンな機能いっぱいもってるけど、すごい特別なものじゃない気がする。 関数型に求めようとしていることは本当は、並行とか分散なんじゃないだろうか?という話をしつつ関数型の関数が値として扱える楽しさについてざっくりと話ました。 学習コストの高さとか考慮すると純関数型は浪漫だよね。僕はもっと学びたいけど。 ただ確実に大きなチカラであるのは確かではあるとおもっています。 ただ、しばらくは、それよりはAkkaかerlangといったあたりにリソースを使いたいなあ、と思っています。

no_picture

ScalaMatsuri 2016にあそびにいった

ScalaMatsuri2016に遊びにいきました。 そういえば、スポンサーになりました。忍者スポンサーです。にんにん。 本イベントの参加チケットは5000円でしたが、5000円分の価値のあるイベントだったとおもいます。 昼ごはんついてるし、朝ご飯ついてるし、翻訳ついてるし。 イベント自体はリアクティブやマイクロサービスを中心にまわりました。 本当は関数型系にいきたかったですが、今必要な技術はそっちのほうだとおもったのでそちらを優先しました。 Refactoring in Scala Isoがなんとくわかりました。Lensもなんとなくわかりそうです。 圏のチカラを感じる なぜリアクティブは重要か リアクティブとはなにかふりかえり、それぞれのリアクティブについて深掘りできました。 リアクティブ・マイクロサービス Play + Akkaをつかった実際のりアクティブなシステムの話でした。席がとおすぎてコードがあまりみえませんでした。 バッチを Akka Streams で再実装したら100倍速くなった話 元の仕組みからすごくはやくなったようですが、Akka Streamsがどれくらいのチカラがあるのか気になります。 アジアから Scala OSS に貢献するということ スピーカーの瀬良さんが広島出身だと知りました。 英語よんだりかいたりしないといけないと思いました。 みんなの関数型プログラミング 入門な内容でした レジリエンスが無ければ、他は無いも同じ レジリエンスがなければなにもないんです。 ささります。 The Zen of Akka Akkaの大事なことがいっぱいきけました。 Domain Specific Language(NASA, Guardianの話題) DSLについて理解を深められました。 かなり細かく説明をきけました。 コミュニティLTセッション いろんなコミュニティがいました。「広島でScalaのイベントをやりたい?」という質問には、やりたいと聞いたので企画したいです。 SBT人間 SBTの歴史的経緯をいろいろきけました。 IntelliJ IDEA で Scala をマスターする intelliJをつかいこなしたい。動画はやくみたい。 DDD+CQRS+EventSourcing実装する会 すごくもりあがっていました。 パネルディスカッション:Scala社内教育 環境はパクろうとおもっております。 純粋関数型という幻想。

no_picture

「強いチームの作り方」を読み直した - そうだOSH2016へ行こう - #LT駆動22

LT駆動開発22に参加しました WEB+DB Vol.83の特集のひとつである「強いチームの作り方」について紹介しました。 2014年10月24日の発売したものですが、とても良い印象をもっていてまた読み直したいと思ってました。 今回2016年2月6日(土)に行われるオープンセミナー2016@広島に著者の一人である原田 騎郎さんがいらっしゃるので自分のなかで咀嚼したことを話しました。 チームにおいて多様性が重要であることが書かれていて、我が道をゆくことも大切だと感じています。 一人でやるよりもコミュニケーションコストが高くなり、個々の生産性が落ちてしまうチーム開発ですが、代りに多様性というチカラを手にいれられます。この多様性を活用できるかどうかがチームの面白さになるんじゃないだろうかと思います。 オープンセミナー2016@広島は「みんなでつくろうモダン開発」というテーマですが、まさにチームの活かし方を考える機会になるんじゃないかと思いました。 そんな話を懇親会なんかで講師陣を混じえてしたいと思ってます。 オープンセミナー2016@広島

no_picture

2015年のスライドをふりかえった - LT駆動開発22

LT駆動開発22に参加しました。 2015年はたくさんスライドをつくったので、スライドをみなおすだけで結構ふりかえることができました。どうやら28個ぐらいスライドを公開したみたいです。 eiel - Speaker Deck 昨年はよく、「未来を視るために、過去をふりかえる」なんてことをちょいちょい言ってまわりました。 去年は可視化を目標にしていましたが、あんまり可視化っぽいことして遊べてないので引続きやっていこうかと思ってます。 そんなわけで年末に、JavaScriptによるデータビジュアライズ入門を購入してちまちま読んでいます。 関数型を学ぶことが仕事に直結してきているので関数型やスケールできるアプリケーションについて考えていることも多かったと思います。 そんなわけで2016年はいまさら流行りにのってマイクロサービスとかリアクティブなシステムとか分散環境っぽいものを学んでみたいなぁ、と思っております。 シングルコアでのCPUの性能は伸びなくなってきているので、並行/並列処理にも着目していきたいですが、同様のアプローチが使えている部分もあるみたいなので気になっております。 リアクティブ宣言 昨年読んだ本の中でよかったもの Web APIをつくっている場合は必読だと思いました。 最初のほうは思想的な面が強くよみにくいかもしれませんが、技術的にも役に立ちますし、いろんなことに気がつくことができました。 それでは2016年もよろしくお願いします。

no_picture

アプリケーションの起動ショートカットにBetter Touch ToolからKarabinerで行うようにした

Better Touch Toolが有料化の運びになったため、会社PCでは申請しないと使えないだろうし、私にとってMUSTのアプリケーションではない。 しかし、別のツールでもできる機能なのだけど、私にとってMUSTな機能として、ショートカットキーでアプリケーションを起動する機能がある。 これまではQuickSilverやAlfledのpower packなどでやってきたことだ。 参考 Macアプリをショートカットキーに登録して、一発起動させるアプリ「BetterTouchTool」 | iDEA CLOUD/dev 今回、これを気に別の方法を模索した結果Karabinerで同様のことを行うことにした。 メリット 右Cmdと左Cmdを区別したショートカット設定ができる テキストベースでの設定 左CmdはOSXのショートカットキーは右Cmdは独自ショートカットとかにできて便利。 テキストベースの設定なのでGit管理ができてよい。 デメリット 設定するのがめんどくさい xmlを書くことになるのでやっぱり設定は格段にめんどくさい。 設定例 Cmd+eでemacsを起動する例 <?xml version="1.0"?> <root> <vkopenurldef> <name>KeyCode::VK_OPEN_URL_APP_Emacs</name> <url type="file">/Applications/Emacs.app</url> </vkopenurldef> <item> <name>Open Emacs</name> <identifier>private.command_e</identifier> <autogen> __KeyToKey__ KeyCode::E, ModifierFlag::COMMAND_R, KeyCode::VK_OPEN_URL_APP_Emacs, </autogen> </item> </root> 詳しくはKarabinerのprivate.xml設定方法を。 関連 eiel/KarabinerConfig - GitHub

no_picture

swiftで書いたProtocolをObj-Cで使うなら@objcをつけろ

Swiftで書いたProtocolをObjective-Cで使う予定があるなら、@objcをつけなければいけない。 つけなければ、Obj-C側で使えない。 @objc protocol Hoge { func get() -> Int } というHogeプロトコルがあったとき class HogeService : NSObject { let hoge: Hoge } としたとき、HogeServiceのhogeをィールド利用しようとするとコンパイルエラーになる。 そもそもヘッダファイルに書き出されない。 単にちゃんとドキュメントを読んでいなくてハマっただけといえばそれだけである。 類似したもので、Swiftで書いたクラスはNSObjectを継承していないとObjective-Cで使えないなどある。 参考文献 SwiftとObjective-Cで相互に連携する - Qiita

no_picture

広島ITエンジニア合同忘年会 2015

広島ITエンジニア合同忘年会 2015が開催されました。 広島のITコミュニティがあつまって忘年会をしようという企画です。 参加コミュニティ(サンクス @csc_kamera25 LTができる会場だったので、LTをしておきました。 そんなわえで、広島のすごいエンジニア大賞をしました。 今年広島で活躍したエンジニアを表彰しようという作戦です。 さまざまな思惑があり、いろいろ悩んだのですが5人の方を表彰することにしました。 他にも選びたい人はいたのだけど、予算不足なので断念しました。 個人的には表彰したいので来年もぜひ活躍してください。 この5人をすごい広島大賞2015の候補として、大賞の行く手は会場におまかせしました。 ただ、決めるのが難しいということを予想して、Haskellでランダムに選出するプログラムを用意しておきました。 厳正なる審査のうえで、今年の大賞は akira345 さんになりました。 みなさん、広島を盛り上げていただいて、ありがとうございました。 大賞の方には1500円分のamazonギフト券を進呈しました。 また、候補者の方々にはそれぞれ違うぬいぐるみを進呈いたしました。 来年も表彰したいし、もっと公正に行いたいので、のんびり協力者を集めたいと思います。

no_picture

アウトプットしていたら結婚できた

この記事は「アウトプットしていたら Advent Calendar 2015」14日目の記事です。前の記事は特にありません。 というか、アウトプットしていたら仕事がたくさんやってきた! | noconoをパクってリスペクトしています。 自己紹介 広島でフリーランスエンジニアしてます。フリーランスAdvent Calendarはまだ参加していません。 今日のテーマ 特にネタもないです。タイトルどおりです。 結果的にみると、「積極的に勉強会を開催・登壇(=アウトプット)するようにしていてよかったな」と思ったのでそのことを書きます。 アウトプットAdvent Calendarだし。 今年1年やった仕事 iOSアプリケーションの改修 定期的にとあるiOSアプリケーションのバグ修正や機能追加を行なっています。 こういった仕事の金額は高くはありませんが、継続的なので安定した収入が得られてとても助かっています。 元々iOSアプリケーションをはじめたのは、iPhoneを購入してしまいLinuxデスクトップでは扱いにくかったためメインマシンをMacに変えたのが起因すると思います。 そんなわけで普段使う道具をよりよく使うためCocoaアプリケーションのちまちま勉強していたところ、勉強会でお会いした人たちに書籍をいただいたり、iOS勉強会に混ぜていただいていたりで、気がついたらiOSアプリケーションを作る仕事がやってくるようになっていました。 Railsアプリケーションの改修 Ruby on Rails で開発されたウェブアプリケーションのバグ修正やメンテナンスを行う仕事もしています。 元々Rubyをはじめたのは、前職の仕事を自動化するのにひっそり使っていました。JavaやC++、Perlより扱いやすく、関数型の思想を受け継いでいてとても気に入っていました。 また、Rubyに関しては勉強会を主催したりしていました。 こういった経緯もありWeb APIを作成する仕事や、Railsを扱う仕事させていただく機会がたくさんありました。 こういった仕事は、勉強会を主催したり、登壇したりすることをしていたことから繋りができたのを強く感じています。 また今年からScalaを扱うようになりしたがRubyで学んだことはとても役に立っています。 Scalaによる開発案件 勉強会の繋りから、Scalaによる開発に興味はないかと声をかけられ、特にScalaでも関数型積極的に扱っていくとのことでした。 Haskellを趣味で勉強していたので、関数型に興味がありました。 これもさまざまな勉強会に参加したり、ブログを書いたり、登壇したりしていなければ声をかけていただくこともなかったと思います。 いままで本格的なチーム開発はしていなく、とても貴重な経験をしています。(継続中) Javaの新人研修の講師 あまり大きなものでハイレベルなものではありませんが、さまざまなプログラミングを扱っている部分を買われて、「様々な言語とも比較しながらJavaを説明して欲しい」といった依頼もありました。 関数型の話もちらほらしながら講師をしました。 まとめ アウトプットしていたら自分のスキルが伸びているのをふりかえり実感することもできるし、なにより収入が安定してきました。 また、いろんな人と出会うことができ、普通にエンジニアをしているだけだったころに比べて、毎日がとても楽しくなりました。 僕の場合は、 Emacsに出会い 関数型に出会い Lisp勉強会などで勉強会をしり Lispより一般的なRuby勉強会を主催し 関数型を勉強して学んだことを発表したり Webの勉強会に参加したりすることで出会いがあり 関数型の仕事ができるようになり 結婚しても大丈夫な収入を得ることができるように なったと思います。 Scalaにしろ講師業にしろ、こういった実績のない仕事を頂けると自分のスキル幅が大きく広げることができ、本当にありがたいです。 こいつに任せて大丈夫だろうかという不安がある中、それでも任せていただけて感謝しております。 いい経験ができて本当によかったです。関係者のみなさまありがとうございました。(引用) やはり関数型は重要だったのだ。(知らんけど) おまけ 私は元々はあがり症で、昔は人前で話す時めちゃくちゃ緊張して失敗することも多かったのですが、勉強会で登壇を重ねるうちに緊張することも減りました。トークスキルも上がっているようです。嬉しい。 「登壇なんて自分には無理」と思う人もいるかもしれませんが、何事も経験なので機会があれば手を挙げてやってみるといいと思うよ!(引用) (でも正直いまだに人前で話すのは苦手なのであんまりしたくない) 質問の回答 このアドベントカレンダーには質問が用意されていますので、そのうち何個かに答えてみます。 Q. 机やイスにこだわりありますか? 特にはないですが、オカモトのシルフィーをつかっています。 バロンが人気ですが、実際にすわってみてシルフィーにしました。 関連: オフィスチェアを買いました。- LT駆動開発04 | そんなこと覚えてない Q.

no_picture

HMCN Vol.2 でその他の広島のコミュニティについて話をした。

HMCN(Hiroshima MotionControl Network)でライトニングトークをしました。 タイトルは「「Code for Hiroshima」「HMCN」「その他大勢」というタイトルです。 うたわれるものです。 タイトルのとおりCode for Hiroshimaを紹介する話とみせかけて、広島のITコミュニティはもっと横連携をしたい、という話をしました。 例に岡山をとっていますが、岡山はとても横の繋りが強いですね。岡山県を飛び越えての集客ができてるのがなによりもすごいところです。 さて、モーションコントロールのITコミュニティなので、それっぽい話もしなきゃいけないと思って、iPhoneのセンサーをつかって遊びでつくったプロダクトがあったので、これも紹介しておきました。 まずは、去年つくったデジタル万華鏡です。 これはこれで、進化させてみようかなとちょっとおもってたりもします。 今年つくったやつもありますが、これはまた別に紹介したいと思います。 とりあえず、オープンセミナー広島と広島の合同忘年会をよろしくお願いします。 そういえば、スライド内でつかったてきとうな広島のITコミュニティの関連図も別途アップしてみました。

no_picture

GAE/GoでChatWorkボットつくって遊んだ話 - #LT駆動 21

LT駆動開発21でLTしてきました。 タイトル「GAE/GoでChatWorkボットつくって遊んだ話」です。 最近ちょっとしたアプリで頻繁に起動するものはGAE/Goで走らせています。 そうでないものはHaskellやScalaでherokuにおくことが多いです。 今回はgo-chatworkで遊びました。 正確にはChatWorkで動く、チャットボットをつくって遊びました。 LT駆動はゆるふわに個々が学んだことを発表していてとても楽しいです。気軽に参加してみてください。

no_picture

内包表記とPythonと… - #LT駆動 21

LT駆動開発21でLTしてきました。 タイトル「内包表記とPythonと…Option」です。 PyCon Mini Hiroshima用に用意してたネタですが、参加できなかったので放出しました。 Pythonの内包表記でScalaのOptionのようなものをつくってみました。 Pythonの内包表記はScalaではfor式で表現ができます。 Scalaではリスト以外のものでもfor式が使えます。 代表格としてOptionが上げられます。 ということで、PythonにもOptionクラスをつくり内包表記で利用できるようにしてみました。 スライドに登場するように内包表記に対応するために、__iter__とnextメソッドを実装をしています。 class Option: def __init__(self, value): self.value = value def __iter__(self): return self def next(self): if self.value == None: raise StopIteration else: ret = self.value self.value = None return ret def __str__(self): if self.value == None: return "Nothing" else: return "Some(%d)" % self.value def add(x, y): return [ x_+ y_ for x_ in x for y_ in y ] add(Option(1),

no_picture

普通の右上をゆこう - ふつうの広島 Advent Calendar 2015

本記事はふつうの広島 Advent Calendar 2015の1日目の記事です。 ふつうの広島 Advent Calendarは広島の「ふつう」なところとこを書いたりするらしいです。 自分にとってあたりまえなことは、意外と誰かにとって「すごい」かもしれません。 この記事では広島はさておいて、そんな、「ふつう」について考えてみます。 私が言う「ふつう」とは「普通の積み重ね」による当たり前や、習慣から生み出されるチカラと考えています。 「ふつう」はある種の理想や、最強の自分自身かもしれません。もしかすると、当たり前すぎて気づかない空気のようなものかもしれません。 そんなわけで、「普通の右上をゆくのがふつう」です。ちょっとだけ普通よりすごい「ふつう」になりましょう。 「ふつう」とはなんだろう 楽しい方向へずれてみよう ふつうとはなんだろう まず「ふつう」とは、なんなのかを考えてみましょう。 「ふつう」とは、青木峰郎の著書のシリーズである「ふつうシリーズ」をリスペクトしたものです。 「ふつうシリーズ」は ふつうのLinuxプログラミング ふつうのHaskellプログラミング ふつうのコンパイラをつくろう の3つが刊行されています。 どれも良書で、ふつうのLinuxプログラミングは駆け出しのプログラマの頃に読んでとても勉強になりました。 ふつうのHaskellプログラミングはHaskellの入門書としては、今はあまりおすすめしませんが、関数型の入門としては出版当時は数少ない良書だったと思います。 プログラマにしかわからない説明になりますが、ふつうのプログラマはLinuxのプログラミングをするし、Haskellのプログラミングをするし、コンパイルをつくるのです。 普通というにはちょっとすごく思えるはずです。 だから、そんな普通を目指す人を「ふつう」と呼びたいと思います。 「ふつう ≧ 普通」なのです。ふつうは普通よりちょっとすごいです。 そんなわけで、僕は普通よりちょっとだけすごい「ふつうのプログラマ」を目指す旅の途中です そんな思いを基に2015年5月に行われた岡山のイベントで「ふつうのプログラマ」についてお話しました。 楽しい方向へずれてみよう さて、「ふつう」を目指すことにしました。なにをすればいいでしょうか。 なりたい自分を想像して、なりたい自分になれるような習慣をつくりましょう。 2週間など短いタイムボックスを設定して、効果を計測するのがイマドキらしいです。 良い習慣が思いつかないときは、すごい人たちの習慣を真似することが良いです。 すごい人たちの習慣には、すごい理由が隠されているはずです。 しかし、毎日続けるのは難しいかもしれません。というか、だいたい難しいです。 自分ができるようにアレンジしていきましょう。 アレンジしていく時に大切なことは、「自分が楽しい方向」であることです。 習慣なので、続けられなければ意味がありません。 続けられるように、目標を誤らないように、変化できてこそのイマドキです。 楽しいなら続けられますよね。 上を目指すのも疲れるので、すごいを目指すわけでない、「普通」の私達なので右(楽しい方向)にずれるのです。 そのズレがやがて、あなただけの色になることでしょう。(たぶん) ちなみに、私は毎日GitHubを更新するという継続や、毎月1回みんなの前で何かをするという継続をしています。 たいしたことではないですが、ふりかえると大きな成果がのこるのを感じています。 まとめ 「すごい」になるのは大変なので「ふつう」をめざします。 普通なんだけど、ちょっとすごい。 そんな「ふつう」をめざすときに、毎日が楽しくなるようにアレンジすると毎日が楽しくなります。 楽しく続けることができれば「ふつう」がやがて誰かの「すごい」になると思います。 ふつうの広島AdventCalendar1日目でした。明日はtsuchimさんのふつうの人生をおくりたいです。

no_picture

WebアプリをつくるならGAEは勉強になる気がするという話をした - #LT駆動 20

LT駆動開発20でWebアプリをつくるならGAEは勉強になる気がするという話をした。 このスライドはすごく雑につくった。 中身の整理とかほとんどしていない。 ただ、Google App Engineに載せるアプリケーションを無料枠内でという制限を設けて作るのは、スケールアウトできるウェブアプリをつくる上で学べることがたくさんあると感じている。 それをだらだらかいたスライドを使いながら話した。 GAEにある制限の多くはスケールアウトするための制限なはずで、GAEがもってる様々な機能をうまく使うことで制限内でがんばることができる。 また、早い段階で制限にひっかかるため、学べることも多いと感じた。 なので、ある程度ウェブアプリの作り方になれたらGAEで遊んでみることをちょっとおすすめしたい。

no_picture

HaskellのWebApplicationFrameworkを試してみるという話をした - #LT駆動 20

LT駆動開発20で「HaskellのWeb Application Frameworkを試してみる」という話をした。 試したのはいわゆるController的な部分になる。最近Webというのはヘキサゴナルアーキテクチャのアダプタにみえてしまう病にかかっています。 話しが逸れました。 前々からHaskellでWeb APIをかきたかったのですが、小噺マスターさんと小噺をしている際に「Haskellのフレームワークってなんですかねー?」という話が出たのを機会にちょっと調べた。 気軽にデプロイできることもわかったし、これを機会にざくっと試してみたという感じです。 scottyに改良を加えたのがSpockって感じの印象をうけました。ふたつとも手軽に使えました。 Yesodは別格で難しく感じましたが、機能的にはすごいなーって思いました。 3つともコードはシンプル。 しばらくは、Spockで遊びつつYesodを勉強しようかと思っております。 ソースコード 関連 stackを使ってhaskellで最小のWeb Applicationしてみる - Qiita herokuにhaskellのウェブアプリをdocker:releaseをつかってデプロイしてみる - Qiita

no_picture

Dockerコンテナの中からDockerコンテナを動かす話をした - LT駆動19

LT駆動開発19で「Docker >>= Docker」という話した。 「どっかーばいんどどっかー」と読む。 cronの中でDockerコマンドがつかいたかった。そのcrondはDockerホストでは当然動かしたくない。Dockerコンテナ内におきたい。 Remote APIでたたいてもいいけど、ちょっとしたものならコマンドが楽でよい。 dockerが使えるイメージはdockerがある。docker run サブコマンドは $ docker run イメージ コマンド なので、イメージを節約して、dockerイメージをつかいまわすと、 $ docker run docker docker run docker ls` という不思議な呪文になった。 実際はDockerfileでRUNで指定したりするので、 $ docker run docker docker run hoge とかですんだり、そもそもdocker run hogeで済むようにつくることになるだろう。 ちなみに $ docker run docker "docker run docker ls"` だとうまくうごかない。 $ docker run docker bin/sh -c "docker run docker ls" とすると良い。 sh -c の中でdockerコマンドで複数のプログラムをうごかしてパイプで処理をつないだりもできる。 そういう話をしました。 あと一番大事なことだけど、Docker Hostが動いているコンピュータ上のdockerコマンドは/var/run/docker.sockをつかって通信しているようなので、-v /var/run/docker.sock:/var/run/docker.sockを共有してやると、コンテナ内からHostと簡単に通信できる。 これって安全なのかはよくしらない。 Dockerの中でDockerを起動すると Docker Docker A になりそうだけど、Docker

no_picture

haskellとpython - #LT駆動 開発19

LT駆動開発19で「HaskellとPython」というLTをしました。 2015年11月22日(日)にPycon mini Hiroshimaが開催されますが、参加できないのが濃厚なので、お詫びために告知をすることにしました。 Pycon miniのテーマが「○○とPython」なので、「HaskellとPython」というアプローチにしました。 Pythonが影響を受けた言語の中にHaskellがあり、Haskellを書いてるとPythonとHaskellは結構近いという印象をもっていて、思いついた似てるところを書きだしました。 本当は11月のLT駆動のネタにするつもりだった1ヶ月じっくり考えようとおもっていたのですが、ほどよいネタにしやすい@mrtc0ツイートがあったので、今月にまわしました。 Haskell自体を学ぶことはいろんなプログラミング言語を使う上で活きると僕は感じているので、興味があれば勉強してみてください。 最近のLT駆動は、僕が関数型系の話をして、@tsuda_ahrさんがMS系の話をして、@nemumupoyoがネットワークノ話をして、@mrtc0氏がネットワーク便利ツールを照会してくれて、@akira345さんがハードウェア系の話をしてくれて、@k2worksさんがソフトウェア開発のノウハウを生活に活かす話をするのが定番になってます。とても楽しいです。 今月は大学生が二人、初LT駆動で、若いのにナイスなLTをしていました。 毎月第一土曜日に開催されるので気軽に参加してみてください。 関連リンク PyCon mini Hiroshima Python - Wikipedia Functional Programming HOWTO — Python 2.7.10 documentation Haskellで生産性を高める-Pythonからの移行 | プログラミング | POSTD チャットワークScala化プロジェクトの一年 / Scala Kansai Summit 2015 // Speaker Deck

no_picture

OSC2015 HiroshimaでLT駆動のふりかえりの発表をした

OSC2015 Hiroshimaがありました。LT駆動開発のセミナーがあり、そこで合作LTをしました。 僕がスライドをつくって、@kakenaviさんがスピーカを担当したらしいです。 らしいというのは、僕が風邪で休んだからです。 技術ネタとしては、qコマンドを使いました。CSVをSQLでごにょれます。便利です。 https://github.com/harelba/q 勉強会で発表しなきゃいけない…っておいこむと勉強できるので、毎月追い込みをかけるのがLT駆動開発です。(やや誇張あり) これまでLT駆動開発は18回行われていてトータルで180個以上のLTが行われています。壮絶です。 一回あたり10回のLTがあるようです。 現在、ユニーク参加者は31名います。1回しか発表者していない人は3人しかいません。90%近くのリピート率です。高いです。 蛇足ですが、よく調べるとトータルで31回LTしている人がいますね。頭がおかしいですね。 発表者内容は技術ポエムを除くと開発に関したものが多かったです。 ついで、プログラミング言語、セキュリティの話題でした。 これは開発している人が参加している多いのと、セキュリティに興味のある学生が多いため、この傾向になっています。ポエムは気軽に話せますから必然的に増えます。というかジャンルがうまくわけられなかったものは全部ポエムに分類させてしまっからなのもあります。 関連するプログラミング言語も調査してみました。 Ruby JavaScript Python Haskell という順序でした。Haskellが広島で高い人気があることがうかがえます。 Rubyが多いのは、LT駆動の前進がRubyの勉強会だった影響です。JavaScriptは今いけいけなので必然的におおくなってきている気がします。 発表者のスライドも結構ネットで拡散しており、はてなブックマークが800を越えているものがありました。すごいです。(僕のものではありません) というわけで、LT駆動したことの世の中の影響は微々たるものですが、あるような気がします。 LTをすると世界の真実に近づけますよ。たぶん。 あと、ロマシング佐賀はスクウェア、エニックスの著作物です。 http://romasaga.jp

no_picture

モナドがくれたものという話をした - #LT駆動

LT駆動開発18 - 秋(not 安芸)の宮島で「モナドがくれたもの」というタイトルでLTしてきました。雑なLTです。 モナドの利点を問われたので、似ているパティーン(パターン)が除去できるんだぜ。みじかくかけるんだぜ。 「裏で毎回同じことやってくれてるんすよ。これはコンピュータの得意なことだよな。だけど、その内容はモナドの種類によって違うんだぜ」 的な話をしておきました。 動作確認につかったコードはここに投げておきます。

no_picture

HaskellでGitHub APIライブラリをつかってみた - #LT駆動

LT駆動開発17でHaskellのgithubライブラリをつかった話をした。 ついでにstackを試したので、その話をした。 Haskellは簡単な具体例がすくないってことで、ちょっとしたコードもどんどんかいていこう。 正直、雑なLTだった。 Haskellでコードかくの楽だなぁ。 関連 ソースコード 突然Scalaプロジェクトに参加することになったことを話した - #scala_ks

no_picture

突然Scalaプロジェクトに参加することになったことを話した - #scala_ks

Scala関西Summit 2015でLTをした。 上からの重圧を感じて申し込みしておいた。 関西のイベントだし、たくさん申し込みがあるだろう。 概要からして期待値が低いから落ちるはずだ。 そんなことを思っていたら発表することになった。 最近、Scalaなプロジェクトで仕事をしている。 完全にScala初心者だけど、なんとかやれているし、とても楽しい。 「Scala初心者だけどScalaな仕事をしたいと思う人の背中を押したい」とおもって準備をしたが、Haskellを勉強してるが故のすんなり入れた疑惑があるので説得力が低い。 Haskellという視点はなるべく捨てて話をしたつもりだ。 先にあだちさんにネタバレをかるくされた…つらくはない。 Scala初心者であることをアピールするためにGitHubにおいてるリポジトリの言語を集計した。 これをScalaで書いてネタにしようとおもったらScalaが難しくて失敗におわった。 しかし、APIを自分で叩いてやれば、なんとかなったとも思うが、Haskellでかいてみたらすんなりかけてしまった。 その話は#LT駆動17で使うことにした。 プロジェクトのチームメンバーは面白い人たちばかりでテレワークという奴なのに日々楽しく過ごさせていただいている。 とても感謝している。 Scalaについてだけど、最初はたくさんの焦りを感じたけど4日目ぐらいから、しばらくはやれそうな感じはした。 知識不足はあきらかだけど、なんとなくのコードをかいてプルリクエストをすれば手厚いフォローがいただけて、とても勉強になった。 「こんなの書ける気がしない」から「書いたらこんなのになった」って感じの数日間だった。 Scalaのコードになれるのに、Scala逆引きレシピには大変お世話になった。 通勤時間でプロジェクトに参加するまでに3回流すことができたが、コードは1行も書く時間は確保できなかった。 ちなみにゴールデンウィークは熱を出してそれどころではなかった。 IntelliJ IDEAも実質、プロジェクト参加してから使い方を学ぶことになってしまった。 Scalaを積極的に採用しようとしている人たちは、技術的に挑戦している人たちが多くて「大変楽しい」と思うことを最後に伝えたいと残しておきます。 というわけで、HaskellもScalaも楽しいです。

no_picture

自治体との対話を考えていきたい - ヒロハタ中間発表会を終えて

この記事はヒロハタというプロジェクトに関わった人がみんなが「参加してよかった」って思えるようになって欲しいから書いている。 そして、広島県に限らず市民が自治体に振り回されないようになって欲しい。 ひろしま発人材集積促進プロジェクトというプロジェクトが広島県によって実施されている。 現在、「ウェブ分野」と「デザイン分野」が実施されており、ウェブ分野の通称が「ヒロハタ」である。(たぶん) 脱線するが、デザイン分野はあまりウェブに情報がない。ウェブ分野はウェブ分野だけあって、ウェブにそこそこ情報がある。素晴らしい。 話を戻す。ヒロハタがスタートして1年経過した。そこで今回、中間発表が行なわれた。 中間発表の肝は中間にも関わらず、現時点で優秀なプランがあれば奨励金として100万円が提供されるそうです。 その中で感じたのは、ヒロハタの現場と県の審査基準のズレである。 この記事では、その話と私が発表した内容についての話をする。 本記事の概要は次の通り。 ヒロハタは「広島の鷹野雅弘」を育てるのが目的ではないのか スタートアップに必要なのはウェブデザイナーではなくてエンジニアだよね そんなわけで私が話したこと ヒロハタはどう進むが良いのだろうか ヒロハタは「広島の鷹野雅弘」を育てるのが目的ではないのか このウェブ分野は、「Web等の活用による事業化を目指す!」というのがテーマである。 なので、中間発表の審査基準は、 新規性・独創性 市場性・成長性 実現性・収益性 熱意・表現力 なるほど。スタートアップを評価する基準としては一般的だ。 ところで、このヒロハタの指導者をみてみよう。 鷹野 雅弘(たかの・まさひろ) プロフィールをみてみよう。 株式会社スイッチを1996年から経営(現在、19期目)。コアスキルは、グラフィックデザイン、DTP(プリントメディア)やWebの制作。 デザインだけでなく、ビジネスドキュメントの制作などにも精通。これらに関して講演や教室でのトレーニング業務などを20年以上にわたり行っている。 Web制作者向けのセミナーイベントCSS Niteを主宰。400回を超える関連イベントを通して、参加者はのべ50,000人弱。 都内での開催を中心に、全国23の都道府県、および韓国にて展開。 年間200万ビューのDTPに関するブログ「DTP Transit」を運営。 テクニカルライターとして20冊以上の著書を持つ。1万部を超えるヒット作を連発し、総販売数は14万部超。 そのほか、書籍の企画編集、スクールのカリキュラム開発などを企画する。 審査基準は良いスタートアップかどうかである。指導者のコアスキルはグラフィックデザイン、ウェブ制作である。 さて、指導者の指示に従って行動することで、素晴しいビジネスプランできるのだろうか。とても疑問である。実際、指導者が進む方向と、審査基準がズレていたと思う。 その結果、今回の審査結果は、ビジネスプランとしてはどれも弱いため、「優秀なプランはない」という結果になったようだ。 当たり前だ。はじめからわかってたよ! ここで知事の記者会見を見てみよう。 一定の分野で人を惹きつけるチカラのある人材を核として、磁石にくっつくような形で人材を集積を拡大してくれぇ、というのがいろんなところで見られまして(中略)この人材集積の効果を狙って、人を惹きつけられる人を来てもらって、いろんな活動をすることによって高度人材の定着を狙ってすすめるものであります。 本来の目的を考えると、「広島の鷹野雅弘」を育てるのが目的だと思うのだけど、違うのだろうか。 指導者の立場。カタリスト。 指導者として設定された、鷹野さんは事業化を目指すという観点では自身が指導者としては的確でないのは理解されている。 この記事をみればわかる。 ヒロハタ(ひろしま発人材集積促進プロジェクト)について - 鷹野雅弘(スイッチ) 最初にかいてある。 ヒロハタ(ひろしま発人材集積促進プロジェクト)は、創業支援ではありません。 現実のカタリストと広島県の思う指導者のズレをまず解消して欲しいところである。 言わば、これはちゃぶ台返しである。 スタートアップに必要なのはウェブデザイナーよりもまずエンジニアだよね このヒロハタはリーンスタートアップで進めるという方針が打ち出されている。 さて、みなさんはリーンスタートアップやRunning Leanを読まれただろうか。 これらを読んでみると、明らかにエンジニア向けの本である。 しかし、ヒロハタが募集したのは、アイディアをもった人である。 Running leanを読めば、エンジニアでなくても取り組めることがあることはわかる。 しかし、アイディアを実現するためにエンジニアをマッチングしてあげるべきなのではないだろうか。 全く無視である。 カタリスト、アシスタント、自治体の人はまずみんな読んでおくべきなのではないのでしょうか。 スタートアップができるのはIT技術の発展でITエンジニアがひとりでもサービスが提供できるようになったことや、3Dプリンタでプロトタイプが簡単に作れるようになったからだと最近思ってるんだけど違うんだろうか。 実際、こういうことがしたいのであればスタートアップウィークエンドやハッカソンをやるべきだろう。 広島県はすでにハッカソンをやっているじゃないか。 第2回 レッドハッカソンひろしま そっちの優秀賞に奨励金を出せばいいと思う。 これは「広島県商工労働局

no_picture

AtlasでPackerが実行できるようになってて感動した

すごい広島113で遊んでたこと。 テスト環境を提供しないといけなくて、Dockerつかいたかったけど、今回はVagrantのBoxでベースを提供することにした。 Packerつかうと時間がかかるのでvagrant packageでつくって、Vagrant Cloudにおいたりしてました。 ちょっと久しぶりにPackerでboxをつくるかーってAtlasにいってみたら、Web上に表示されたチュートリアルにそってコマンドラインで作業するだけでBoxがつくれるようになってました。 しかも、Packerの実行をAtlasがやってくれます。しかも、VirtualboxとVMwareのイメージ両方つくってくれます。 しかも、勝手にBoxesに登録されます。 素敵です。 Atlasにサインインする Build Vagrant Boxes with Packer and Atlasというメニューがあってクリックする packerのバージョンの確認をさせられる。0.8.0より最新かどうか。 PackeのTemplaterをもってるかきかれます。もってなかったら atlas-packer-vagrant-tutorialが使えると教えてくれます。 API TOKENが生成されるので、環境変数に登録します packer push をつかって template.jsonとscriptをAtlasに送信します 進行状況をAtlasで閲覧できます。だいたい30分ぐらいかかります。 そうすると、boxができて、Atlasから取得できるようになります。 ここから配布していると vagrant box update でboxが更新できたりとなかなか嬉しいです。 他に遊んだこと tutorialのものはUbuntu12.04だったので14.04にかえたりしました。 railsが実行できる環境つくって遊びました。 mysqlとrubyをいれてるだけです。2.1.6なのは大人の事情です。 公開するboxは一度公開したバージョンの場合、最終的なPackerの実行が失敗します。 成果物が登録できないからです。 メタデータを修正して、新しいバージョンに変えるようにしてください。 具体的にはこの辺を参考にしてください。versionを0.0.4にしています。 実際につくったVagarantのBoxはこちらにあります。 vagrant init eiel/rails-ymqsl とかすると使えます。 Vagrantのboxをつくるのに、Packerをつかうとローカルマシンが占有されてつらかったのですが、Atlas上でビルドできるようになってたいへん幸せです。 継続的デリバリー感がします。とても楽しいので一度遊んでみてください。

no_picture

「Material Designなサイトをつくってみる」という話をした - #LT駆動 16

LT駆動開発16で「Material Designなサイトをつくってみる」をというLTをした。 ちょっと前にPolymer Starter Kitに遊んだので紹介した。 戯言 ライブコーディングでカバー画像の設定とボタンの設置をやった。 エレメントを使うのにimportをしないといけないことに気づかないでハマったのでその話をした。 Starter Kitで使われているエレメントはapp/elements/elements.htmlでインポートされてる。インポートされてないものはインポートする必要がある。paper-buttonやiron-imageやら。 それだけわかれば結構楽しめるPolymerさん。 カスタムエレメントのHTMLも眺めてみるとどんなことができるのかも結構想像できるんじゃないかと思う。 あまり情報がないので、どんどんみんな試して欲しい。 関連 icon-iconで使えるアイコン Polymer Catalog

no_picture

「戻り値の型によって処理を変える」という話をした。 - #LT駆動 16

LT駆動開発16で「戻り値の型によって処理を変える」をというLTをした。 要するに自分の中で型クラスのことがそこそこすっきりしたので喋ってみた。 完全な準備不足でもっと丁寧につくりたい部分があったけど雑に説明してしまってるところがある。 戯言 いまだにアドホックという言葉がよくわかっておらず、つらい。 型クラスを使うとアドホック多相というのが実現できるらしい。 アドホック多相というのは、分岐処理の自動生成ができる機能とも言えさうだ。 また、クラスがメソッドをグルーピングする機能と見なした場合、型クラスをつかうとより柔軟にグルーピングできる機能とも言えそうだ。 その辺の話をうまく図示したいけど、考える時間が足りなかったので、また今度考えてみたい。 型推論や型を指定することで関数の戻り値の型が決定すると実行される関数が決まる。 戻り値だけでなく、引数の型なんかでも決めることができる。 オプジェクト指向では、レシーバで決まったり、オーバロードで呼び出しする処理を変えたりできる。 オブジェクト指向だとか、関数型だとかではなく、言語がもってる機能の違いなんだよなぁ、と思ったりしなくもないけど真面目に考えてない。 LT中に登場した言語がHaskell, Ruby, Python, Perl, ScalaだったけどOCamlのことをあまり知らないので、もっと勉強しようと思った。 スライド中のコードはGistにアップしておきます。(実行例かきわすれてる…)

no_picture

プログラマは地域のヒーローになれるんだろうか - Code for Japan Brigadeに関わることについて少し考えた

Code for Hiroshimaというコミュニティができたらしい。 広島の市民や自治体と連携して、テクノロジーを活用することで地域課題を解決することを目指す団体だ。広島以外にもこのような団体はあって「Code for なにがし」がいろんな地域にある。 このような活動は普段の生活ににおいてIT業界にいるプログラマやデザイナの価値を高めるんじゃないかと思っていたりする。 少し前までは、コンピュータのチカラを有効に使えるという能力は地域課題の課題解決には役に立たなかったんじゃないかと思う。 市民の多くの人がテクノロジーを活用できるデジタルデバイスを所有するようになった プログラマが活用できるコンピュータ資源が豊富になった という背景ができて、身近なまわりの人の問題にプログラマの活躍できるようになったんじゃないかと思う。 IT関係のスタートアップが豊富なのもきっと同じ理由だろう。 今や僕らプログラマは大きなチカラをもっているのかもしれない。 プログラマは地域のヒーローになれるのか プログラマといえば、少し前までは、一部の物好きが使うおもちゃみたいなものだったみたいです。 黒い画面に向かい、指だけを動かしている人たちです。 とても不健康そうです。オタクなんて言われていたりした気がする。 コンピュータは軍事活用のために研究は進められたかもしれません。 ビジネスの世界では効率化のために活用されていったかもしれません。 しかし、今は誰でも持ち歩けるところまで発展しました。 プログラミングができるというのは、車を運転ができるような生活に役に立つようなものではなかったのですが、誰もが持ちあるくものになることで状況は変わってきているのです。 これまでもパソコンが普及したことで、パソコンで困ったことがあれば、質問されるようなこともありました。 大抵の質問はプログラマとしてのスキルが活かせるようなものはなく、特定のソフトウェアの利用方法に関するものでした。 でも、状況は変わってきたのです。 地域課題を解決するオープンソースプロジェクトやオープンデータが登場することで、プログラマは地域課題に活躍できる立場になったのです。 ソースコードが公開されていれば、他の地域の問題を解決するサービスを自分達の地域でも使えるように修正ができるのです。 ソフトウェアの根本的な問題を追うことができるのです。 データがないのであれば、データをつくる場所を提供することができるのです。 さらに、公開されている情報を組み合わせたり、情報を公開する場を提供したりできるのです。 そして実際に問題を解決していくことで、プログラマはよくわからない不健康そうな人たちから、「もしかしたらなんとかしてくれる」という、子供たちの憧れになっていくのではないかと思うのです。 Code for Hiroshimaについてもう少し Code for HiroshimaはCode for Japanが提供する支援プログラムに参加するCode for Japan Brigade(ブリゲード)という立場になります。 個々のブリゲードは独立して活動しているようですがCode for Japanを通して関節的に連携することになります。繋りをつかってお互いにサポートしあうことができます。 コミュニティを構成するメンバーはテクノロジーの提供するプログラマやデザイナだけでなく、地域課題を抱えている市民も対象となります。 市民のためのコミュニティであるため、非プログラマの市民のメンバーがいることは重要なことです。 活用をするのは市民だからです。活用されないテクノロジーに価値はありません。 そのため、市民が本当に必要なものを提供するために開発段階から一緒に活動し、問題の共有とテクノロジーの活用する能力を一緒に向上していくことになります。 l そんなわけでCode for Hiroshimaのオープンなミーティングが7月からはじまるそうです。 7月5日 日曜日 10時 Code for Hiroshima 井戸端会議 Code for Hiroshimaは「被爆70年の広島・長崎での平和イベントを可視化するサービス」の開発や、いつ、どのゴミが収集されているのか?をわかるサービスのメンテナンスをしていたり、広島の駐車場の料金を調べることのできるサービスの開発を支援していたりするそうです。 作成中のサービスに意見をしたかったり、自分の困っている問題をテクノロジーで解決してみたかったりするような人をみかけたら紹介してあげてください。 もちろんテクロノジーを提供する能力をもった人はヒーローになるために参加してみてもいいと思います。 まとめ Code for Hiroshimaができた。 プログラマはみんなの憧れになれるかもしれない。わからない。 参加自体はオープンだ。気軽に参加してみよう。

no_picture

Scalaをはじめる α & β - #LT駆動 15

LT駆動開発15に参加してきました。 最近、Scalaを触っているので、仕事していると放置しがちな基本的な使い方を調べたりしています。 今回はα世界線とβ世界線の二本でお送りいたします。 αはsbtを使わずにJARを使う方法を調べました βはAppトレイトについて調べました なんのJARを使うのか非常に悩んだのですがScalazにしておきました。 Scalazを選ぶまでは早かったのですが、Scalazをつかった良いサンプルがつくれずに苦戦しました。 Appトレイトのほうは、Scala関西 Summit 2015のLTに応募しようかと一瞬思ったのですが、まだ2ヶ月あるので止めておきました。 まあ、一番苦戦したのは scala HogeZ -cp ‘*.jar:.’ とかいて、動かなかったことである。 まとめ1 JARを使うときは classpath を指定すればよい。 sbt使うと楽チン。 まとめ2 object Hoge { //コード def hoge() = //コード } みたいなのはJavaでいうと class Hoge { static { // コード } public staic void hoge() { /* コード */ } } みたいな感じになるらしい。 https://github.com/scala/scala/blob/540b18fb68a0210b187e595622c31f20b2c6f581/src/compiler/scala/tools/nsc/transform/Constructors.scala#L474 こういった特殊なものがあるならもっとしりたい 参考文献 はじめての関数型プログラミング教室 // Speaker Deck sbtで、プロジェクト内のライブラリ依存関係を調べる - CLOVER App - Scala Standard Library 2.11.6 DelayedInit - Scala

no_picture

セルフブランディングがテーマのオープンセミナー岡山でセッションをした - とあるふつうの命令書

オープンセミナー岡山という大きな技術者向けの無料のイベントで講師参加をした。 テーマが「IT業界におけるセルフブランディング」だったので、自分はセルフブランディングはしていないけど、セルフブランディングみたいになっているだろうことについて話すことにした。 とても有名なライトノベル「とある魔術の禁書目録」を文字ったタイトルをつけた。 せかっくなので何かにルビを振りたくなったので、「みんな」というキーワードを「モナド」と読むことにした。 そういえばちょうど5月にモナドの話をしていて、うまく伏線が貼れている。 偶然というのは恐しい。 平たくいうと、わたしの目の前でおきた「拡散される仕組み」の話をした気がする。 結果、迫ってくる未来が期待に近いほうへと進んでいるような気がする。 全体でみると、どこかにもうちょっとしぼった話をしたほうがよかった気もする。 独りの「ちから」はわずかなので、みんなの力をわずかに借りられるようにしておきたいと思う日々です。 変えられない未来はない = 自分のちから x みんなのちから そうか、モナドか。(ゼノブレイド的な意味で) 利用したラーメン画像は我馬というラーメン屋のものです。 なんかセッションがお互いに相補していた気がしていて、とても良い一日だった。 関連 当日のツイートまとめ モナド則だけ見つめていたい - LT駆動開発14 Newニンテンドー3DS専用 Xenoblade ゼノブレイド Github Pages について整理しておきます ふつうのシリーズの著者である 青木 峰郎:作品一覧、著者略歴 かずー氏さん ぐらばくさん ⑨④①さん 岡山のオープンセミナーで「行ってきたの裏側」を話してきた #oso2015 - 941::blog 狩猟女子 わたしのつくりかた オピヨさん そーだいなるらくがき帳: オープンセミナー岡山@2015に今年も参加してきた #oso2015

no_picture

ScalaのMapの使い方がよくわからないので遊んだときのメモ

すごい広島 #104で遊んだときのメモ。 最近Scala勉強している。 Mapを使いなれていなかったので少し遊んだ。 参考になりそうなのは下記のサイト Scala Standard Library 2.11.5 Scala Mapメモ(Hishidama’s Scala Map Memo) さて遊ぶ Mapを作ってみる。emptyでも作れるけど。 Map("hoge" -> 1) // scala.collection.immutable.Map[String,Int] = Map(hoge -> 1) 値を取り出してみる。 Map("hoge" -> 1).get("hoge") // Option[Int] = Some(1) ImmutableなMapに要素をつけたしてみる。新しいMapができる。 Map("hoge" -> 1) + ("mogu" -> 2) // scala.collection.immutable.Map[String,Int] = Map(hoge -> 1, mogu -> 2) +でくっつけることができた。("mogu" -> 2)ってなんだろう。 ("mogu" -> 2) // (String, Int) = (mogu,2) どうやらタプルらしい。 Map(("hoge", 1)) // scala.collection.immutable.Map[String,Int] = Map(hoge -> 1)

no_picture

モナド則だけ見つめていたい - LT駆動開発14

LT駆動開発14に参加した。 ゼノブレイドクロス発売記念でモナドの話をしといた。 Stateモナドを簡約して、Stateモナドを説明しようとおもったけどうまくいかなくてボツになりました。 Haskell - Stateモナドを手で簡約してみたりしていた - Qiita そんなわけでHaskell/圏論 - Wikibooksを元ネタにモナド則を辿ってみました。 a -> M bって型の関数を並べるにはfmapしてjoinしてを間にはさむことがポイントな気がしたことがあったのでその話です。 a -> M bな関数を組み合わせると M b -> M (M c) になって M (M c) -> M (M (M d)) とどんどんMが増えていってしまうのですが、モナドであればM dにできるわけです。 a -> M bってなんなんだって話になってきますがM a -> M bでも良いけど、a -> M b のほうがあつかいやすいよね。だってMは外せないんだから外れているものが受け取れたら便利じゃないですか。 結果的に残ったものは 何度も同じことをしないといけない部分を隠すことができます。 その内容を自由に取り替えできちゃうのがモナドの魅力なのだと思う。 そしてMに関する操作は裏でひそかに行われて、命令書を構築したり、失敗していたら何もしなかったり、可能性すべてを記録したり、単に設定した値をおけるだけだったり、するだけだと思われます。 関連 Haskell - Stateモナドを手で簡約してみたりしていた - Qiita

no_picture

AppleWatchを1日使ってみての所感

AppleWatchを購入した。ちょうどでかける日だったので、1日外で使った感想。 率直に述べると、便利になるとは思うけど、値段が高いので費用に対する効果はなんとも言えない、と思った。 購入したのは38mmステンレススチールケースとミラネーゼループ。 アプリ開発する際にどんなものか知らないと提案できないので、購入した。 箱から取り出してちょっとさわった感想 思ったより重い すぐには使い方がわからなかった 起動めっちゃ長い 省電力モードからの戻り方がわからない 通知ばんばん飛ぶので見せと言われても見せづらい 磁石強くて付けるの難しい 1日つけてみて感想 重さは気にならなかった 歩いてても通知に気づけて良い 1日で電池は50%程度なくなった つけ心地は良いと思う 心拍数を測定してくれるの楽しい iPhoneの操作が少しできるちょっと嬉しい force touch 楽しい 腕を回すと自動でディスプレイがオンになるの使いこなせないのでオフにした 付けたままPC作業は難しい あんまりかっこよくない 2万以内なら悩まず買うと思う。 重量について 重量についてはかなり気にしてモデルを選んだ。 とにかくつけてて疲れるのは防ぎたかった。 スポーツの黒が有力候補だったけど、ミラネーゼループを選んだ。 スポーツバンドは色によって重さが違うので注意。 実機に触ってないのに選ぶ必要があったので下記の記事はとても参考になった。 Apple Watchのケースとバンドの重さを比較!モデルによって2倍の重量差! | IT Strike つけ心地 腕時計は普段していません。つけ心地は良いと思う。毎日つけていられると思います。 PC作業はちょっとしづらいですが。つける位置を調整しています。 通知 iPhoneをズボンのポケットにいれて歩いてると通知にまったく気づかない。 Apple Watchを装備することによって、通知に気づかないことがすごく防げるようになりそう。 といっても、メールすべて通知しているので、たいへんめんどくさくなることもあります。 そろそろ通知を細かく調整しようと思いました。 心拍数 定期的に自動で計ってくれてHealthアプリで確認できる。 とても楽しい。不整脈を検知するのは難しそうである。 ついでにアクティビティですが、運動時間30分の設定を変えたい。 30分も運動できない人だっているんです。 電池 半分なくなってました。 毎日充電する必要がありそうな気配が漂っています。 音楽 iPhoneの音楽アプリを制御できるのは地味に嬉しい。 曲名の確認が地味に嬉しい。シャッフルで流してると曲名が覚えられないんだ。 force touch 強く押すと、押した感じがする。違和感はあるけど楽しい。 まとめ Apple Watchを持つか、持たないでは、ライフスタイルが変わる可能性は非常に高い。 しかし、金額に見合ったリターンがあるかどうかは保証できない。 iPhoneの拡張パーツなのにiPhoneと同等のお値段…。 現在すでにお気に入りの腕時計がある人は購入しづらいと思うし、いままで腕時計している人には新しく腕になにかつけるのは抵抗がある気がする。 なかなか誰にでもおすすめはできないけど、おもしろいと思います。

no_picture

私の強み - ストレングスファインダをしたのでメモ

少し前にストリングスファインダってのをした。 自分がふりかえりをするためだけにつくった記事である。 着想 学習欲 最上志向 内省 収集心 参考 ストレングスファインダーまとめサイト 特徴 【着想】複雑に見える物事の裏側に存在する、的確で簡潔な表現方法を発見すると嬉しくなる 【着想】見た目には共通点の存在しない現象に、なんらかの共通点を見出すと創造力をかき立てられる 【着想】多くの人が中々解決出来ない日常的な問題に対し、新たな視点をもたらす人物である 【着想】世の中の既知の事実をひっくり返すことに無上の喜びを感じる 【着想】目新しい考えや、逆説的な考え、奇抜な考えを好む傾向にある 【着想】新しい着想が生まれるたびに、エネルギーが電流のように身体を駆け巡る体験をすることが多い 【着想】他の人たちからは、「創造的」「独創的」などと評される傾向にある 【着想】着想のある人生にスリルを感じ、そんな生活を送れていると幸福を感じる 【学習欲】あなたの才能に突き動かされ、更なる知識を獲得することや新しいスキルを得ることに重きを置く 【学習欲】「教育」を常に進行中の活動として捉えている 【学習欲】他人とアイデアや概念、理論について話す過程で、あなたはより容易く知識を獲得することができる 【学習欲】あなたの思考は、何らかの質問が提示され、それに対する回答の中で生じるものである 【学習欲】あなたは、考えていることがそのまま口から出たり、知的な人々が彼らの考えを述べるのを聞く時間を素晴らしいと感じる 【学習欲】あなたは議論した内容の一部を自然と書類化したり記憶したりする 【学習欲】機会が提示されたときにはいつでも、あなたは洞察や事実に差し戻しをしたいと感じる 【学習欲】生まれつき、仕事によって発奮させられたいと感じている 【学習欲】あなたはあなたの仕事や学習から情熱を感じることを必要とする 【学習欲】あなたは常に知識やスキルを獲得する 【学習欲】事実を学び、概念について思案し、理論を試し、スキルを磨いているときはいつでもあなたは最も「生きている」と感じる 【学習欲】あなたはあなたの精神の拡大を妨げる人や状況を避けたいと感じる 【学習欲】恐らくあなたは継続的に知識やスキルを獲得することに意欲づけられる 【学習欲】あなたの才能を使うための新たな方法を発見すると、あなたは精力を得る 【学習欲】「どうやったら上手く出来るのか」をすでに知っていることをやり続けさせるような人々や状況をあなたは避けようとする 【学習欲】あなたは、知性を「現状維持」することを受け入れがたいと感じる 【学習欲】本能的に、あなたは一つの事柄に対して長時間集中力を保つことができる 【学習欲】恐らく、あなたが獲得した知識によって、あなたはなぜ特定の事象が正確に動くのか、もしくは動かないのかを理解することができる 【最上志向】自身の”強み”を活用した場合の成長と利益の大きさを本能的に理解している。 【最上志向】あなたの才能を評価してくれる人々を常に探している。 【最上志向】身体的、精神的なエネルギーを「自分がより上手くやるための方法を知ること」に使う。 【最上志向】正しい取捨選択が成功の鍵となることが多い。 【最上志向】明確な労働観をもつことで、目的を達成に近づく。 【最上志向】他人があなたの強みを認めてくれた場合に、最大の力を発揮する。 【最上志向】生まれながらの才能や獲得したスキル・知識を人に賞賛されたいと感じる。 【最上志向】自身の才能をパーソナリティや専門性の更なる向上に使う傾向がある。 【最上志向】すでに高いレベルに達した事柄を更に向上させることを好む。 【最上志向】繰り返し「より上手くできないか?これが自身のマックスか?」と自問する傾向がある。 【最上志向】過去の成果や生まれながらの才能に満足してしまうことを「平凡に流れること」だと感じ、危機感を覚え、そうならないために一生懸命になる。 【最上志向】モチベーションの在処を見つけることに長け、それを伝えることで他人を鼓舞できる。 【最上志向】個人個人のユニークさを認め、賞賛する。 【最上志向】あなたの知識や賛辞は、とりわけ他人に活力を与える。 【内省】頭脳活動が好きで、考えることを好む。 【内省】問題を解くにせよ、アイデアを出すにせよ、他人の感情を理解するにせよ、脳を刺激して縦横無尽に働かせる活動をやりたいと感じる。 【内省】何に思考を集中するかは、あなたの自身の「ほかの強み」によることが多い。 【内省】一人での時間を大切にし、楽しむ傾向がある。 【内省】内省という資質により、実際の行動と頭の中で検討したこととのギャップに不満を感じることがあるかもしれない。 【収集】生来の性質として、あなたは【収集】それ自体に純粋に楽しみを見出す。 【収集】おそらく、あなたは本や新聞や雑誌等を行列に並んだときのため、一人で食事をするときのため、見知らぬ人の隣に座ったときのために持ち歩いているだろう。 【収集】多くの場合、活字があなたの精神に対して栄養を与える。その結果、あなたは、他の人にとって独創的だと感じるような特定の種類の計画やプログラムやデザインや活動を生み出しうる。 【収集】あなたは時折、大きな戦争について学ぶ傾向がある。何人かの人がこのようなトピックに対して退屈さやイライラを感じる一方で、あなたはそれを魅力的に感じることがあるだろう。 【収集】もしあなたが特定の地球的な争いについて学んだならば、多分あなたはそれについて更なる情報を集めたいという衝動に駆られるだろう。 【収集】一つの本や記事が、あなたを別の本や記事へといざなうことが多い。 【収集】あなたは、時々、あなたの目の前の印刷されたページ上で展開される人間の物語を疑似体験することがある。 【収集】本能的に、あなたはあなたに対して「達成したいこと」を話してくれるような特定のタイプの人々と友達になりやすいと感じるだろう。また、その人たちをより良く知るために、あなたはいくつかの本や、雑誌や、新聞や書状や、インターネットのサイトを彼らの関心ごとに関する知識を広めるために読むかもしれない。 【収集】人々をゴールに近づくのを補助するような知識を分け与えることができるようになったとき、あなたはお互いをよりよく理解出来るようになるだろう。 【収集】あなたの強みにより、あなたは示唆に富む刺激的な会話の中心に入り込める。 【収集】あなたは理論的に話す。それは、あなたがまだ発明や証明、製造や実行の前段階にある事柄について話すことができることを意味する。 【収集】あなたの語彙は、あなたの思考と同じくらい複雑なものである。このことは、あなたがずらりと並んだ洞察や概念、哲学について詳細に考えられることを説明する。 【収集】あなたは、即座にあなたの洗練された言葉の意味を把握出来る人と会話をすることを好む。 【収集】あなたの才能に突き動かされ、あなたは時にグループでの集会で議論されるべきトピックスについて読み、多くの情報を収集する。 【収集】あなたが、準備的な読書やリサーチなどの宿題を全てやってくれるだろうと頼る人たちが居るだろう。そのお陰で、その人達はそれについて全く心配する必要がない。

no_picture

リーントーク駆動開発 - LT駆動開発13

LT駆動開発13でLTをした。 ちょっと前にリーンスタートアップ系の本を読んだので、それを元にリーントーク駆動開発ってなんだろうと考えていたので、それを垂れ流した。 しかし、実際には内容が発散しすぎて収集がつかなかった。 なんにおいてもバランスは大切だというのが結論。 無駄なものに力を注ぎすぎないように全体を見ながらバランスよく攻める。 そして、効果があるところをみつけるところから始めたほうが良いと思う。 このスライドが誰かの役に立てば嬉しいなぁ。 関連 JSXとReactとDOMと。 - LT駆動開発13

no_picture

JSXとReactとDOMと。 - LT駆動開発13

LT駆動開発13でLTをしてきた。 最近JavaScriptを他の人に教える機会があって、Reactへの導入を踏まえながらコードをかいた。 JSXのないReactはDOM地道にJavaScriptで構築するわけだけど、これに比べて生のDOMを構築はすごく大変だなとおもった。 こうなってくるとReactのVirtualDOMって部分って割と気軽に感じたのでそういった話をした。 あんまり下調べをちゃんとしてないのでてきとうなことを喋ったかもしれない。 LT駆動開発は毎月やってるので喋る人へのフィードバックをする人が増えたら嬉しいので、参加してどんどんまさかりを投げあって欲しいです。 関連 リーントーク駆動開発 - LT駆動開発13

no_picture

記事のタイトルを大切にするように内容も大切にして欲しい

みんな記事のタイトルの付け方がうまくなった。 思わずクリックしたくなるタイトルが増えた。 でも、見慣れてしまって、なんだか見る気がしないものが増えた。 たぶん、タイトルに対して内容が伴わないな記事が増えたんだと思う。 タイトルを付けるのに時間を使うように、内容が「読者のことを考えて書かれている」かを考えたら良いと思う。 メールにしろ、ブログ記事にしろ忙しい人はタイトルしかみない。 だからこそ、タイトルで目を引くのが大切だ。 そういった目を引くタイトルは本来見るべき人にすばやく届いて、SNSでの拡散力だって高まる。 でも、内容の良いブログは検索エンジン経由でどちらにしろアクセスがくる。 インターネットで調べものをしているとどうしても見つからない情報がある。 あなたがそれを記事にすれば、たくさんのアクセスがくるだろう。 思わずクリックしたくなるよりも記事の内容を適切に表現するタイトルをつけよう。 誰かがWeb上書いているような記事に時間をかけるのはやめよう。 なにか付加価値をつけよう。 対象読者を変えてみるのも付加価値だろう。 もっと知りたい人のために、参考にした記事へリンクを貼ろう。 あなたのリンクが情報源の価値を高める。 結果、あなたの記事の信頼性も高まり、あなた自身の信頼も高まるだろう。 「〇〇するときに大切なN個のこと」そんなタイトルの記事の大切なことを合わせるといったい何個あるんだろう。 「あなたが書いた」という価値がその大切さを伝えるようになるときが来るだろう。 そんな時に使って欲しい。 あなたが記事を書いて本当にしたいことはなんだろう。 アクセスアップだろうか。きっと、それは目の前の目的だと思う。 本当は、世の中を良くしたり、経済を回すことなんじゃないかと思う。 本当にアクセスアップがしたいのなら何が大切なのか考えてバランスよく時間を使うことだ。 時間を無駄に使ったり、誰かの時間を無駄にさせたりはしたくない。 もっと読者のことを考えて文章を書けるようになりたい。 関連記事 「数学文章作法 基礎編」 が心に残り過ぎて、しばらく持ち歩きたい。

no_picture

リーンキャンバスは仮説検証をすることができる製品

実践リーンスタートアップを読んだ。 リーンキャンバスは仮説検証をすることができる製品です。 しかも、作りなれていると5分で作成することができます 製品 製品は、顧客に提供することができてフィードバックを得ることができます。 リーンスタートアップでは、アイディアをなるべくコストをかけずに製品を構築して、顧客に提供して、顧客のことを学習して、本当に必要なものをつくっていきます。 その最初につくる製品として、候補のひとつとして上がるのがリーンキャンバスになるようです。 他に製品になりえるものは スライド ランディングページ A4サイズ1枚程度の説明書 などなどがありそうです。 ランディングページをつくったりするのは大変です。 スライドもリーンキャンバスをつくるよりは大変です。 A4サイズ1枚程度の説明書はスニペットがあれば、比較的簡単につくれそうです。 まとめ ということで、アジャイルサムライで紹介されていた、エレベータビッチみたいなもののようです。 リーンキャンバスは重要なものほど広い面積がとってあるため、重要な場所がわかりやすいということみたいです。 顧客が欲しいものやビジネスがうまくいきそうなものがわかったら、リーンキャンバスより大きな製品をつくって検証をしていけばよさそうです。 次に学べばよさそうなこと 製品をつかって顧客から学習する方法 関連 アイディアを思いついたらリーンキャンバスを書くと良いらしい | そんなこと覚えてない Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

no_picture

もっと地域を活性化したいのでセミナーイベントの後の交流会を盛り上げたい - WEB TOUCH MEETING 76に参加した

広島のWeb系のハブになるイベントであるWEB TOUCH MEETING の76回目に参加した。 セミナー内容はとてもおもしろかったですが、割愛します。 おもしろいかったのですが、イベント後にある「カフェベローチェで井戸端会議(自由参加)」の参加者が固定化されていて、参加者が少なくてもったいないと思った。 セミナーを聞く目的で参加するのも良いのですが、情報の交換が一番のおいしいところだと思う。 Webというキーワードでいろんな人たちが集まっているから。 人が集り、交流するといろんな楽しいことが起きる。 だから、もっとイベント後の交流会に参加者を誘導できたら良いのにと思っている。 感じたこと たぶん、はじめましての人がたくさんいた。 だからこそもっと交流したい。 良いとおもったこと デザイナーよりのセッションが多めだったにも関わらず、 そこそこプログラム系の人がいた。 より期待すること プログラマよりのときはもっとデザイナが来ると良いと思う。 デザイナよりのときはもっとプログラマが来ると良いと思う。 WEB TOUCH MEETINGの主旨に立ち返ってみる。 WEB TOUCH MEETINGとは主に広島県、中国地方の方を対象にウェブ周りの技術や知識に関して自分は知ってる当たり前のことをまずはさわりの部分からでもお互いにしあいましょうという会です。 さわりの部分を共有したいから、興味がないかなぁって思う時こそ参加すると良いと思う。 問題点 さわりを共有したからこそ、交流したいのに、交流会の参加者が固定化されている なぜ交流会に参加者が少ないのか 仮説を立ててみる。 イベントの時間が遅いため交流会に参加できない 交流会への誘導に失敗している 交流会があることを知らない 交流会にメリットが感じていない イベントの時間が遅いため交流会に参加できない イベントが19時から22時。 土曜日なのでバスの最終が22時50分だったりで充分な時間がないのではないか。 解決案 主催者に終了が22時になりそうなときは21時終了にできないか交渉してみる 交流会への誘導に失敗している イベントが終了後、運営は片付けているので、いきましょうって引っ張る人がいない。 行くか迷っている人をしっかり引っ張る。 解決案 自分が誘導係をやる イベントの終わりに充分な交流時間を入れてもらう 交流会があることを知らない アピールが足りず、存在に気付いていない。 解決案 自分がピエロになって終了後にしっかりアピールする 交流会にメリットが少ない 交流会にメリットを感じていない人が多い可能性。 そもそもイベント自体の参加がはじめてで参加しづらい可能性。 解決案 メリットを強調する 講師にはなるべく参加してもらう 次回挑戦したいこと みんなにもっと参加して欲しいということを伝えるような行動してみる。 名刺交換を積極的にしにいく 誘導係をする 交流会の告知係をする まとめ 交流会のメリットは固定化メンバーがいることから推測すると、 勉強会のメリットをよく知っている人たちであり、そこそこ忙しくない人のような気がする。 (注: みんな忙しい中で参加していると思います) 交流が増えると新しいコラボが生まれて、盛り上がるし、講師をする人も増える気がする。 そういえば最初のころは「興味がなくても参加する」ことを大切にしていた気がする。 一緒に仕事する可能性も高い人たちだし、何より喋るのが苦手だからだ。 喋ることが苦手なら何度も顔をみせることで話すきかっけをつくればいい。 そんなことを思い出した。

no_picture

「ふりかえり」の仕方をときどき振り返りしたほうが良いと思った - すくすくスクラム広島第10回 スタッフによる「ふりかえり」

『「ふりかえり」の仕方をちゃんとおさらいしたい』と思う出来事があった。 「ふりかえり」に限らず、よく行うことはときどきやり方の見直しが必要だと思った。 いきさつ すくすくスクラム広島第10回 スタッフによる「ふりかえり」に参加しました。 すくすくスクラム広島では3回に1回「ふりかえり」を行います。前回やりわすれたらしくて、約1年ぶりのふりかえりをしました。 どのようなふりかえりをしたか 去年のふりかえり時にしたKPTを確認して、Tryに着目して、継続するかどうか検討した。 ふりかえり スクラムのふりかえりのことで、英語ではsprint retrospective(スプリントレトロスペクティブ)と言うらしい。 振り返り スプリントゴールの達成具合や、スプリントで発生した問題とその改善について話し合う。次回のスプリントゴール目標についての取りまとめも含まれる場合がある スクラム (ソフトウェア開発) - Wikipedia KPT Keep(続けたいこと) Problem(問題点) Try(挑戦したいこと) 3つにわけてふりかえります。 参考: 今日からできる!全員参加型の建設的フィードバック「ふりかえり」~実践編(KPT・タイムライン) (1⁄3):テクノロジーでビジネスを加速するための実践Webメディア EnterpriseZine (EZ) 起きた問題点 ふりかえりのやり方はあれでよかったのか どんなことをしたか 前回出たTryができたかどうかを判断した 続けるべきだどうかを考えた 何が問題か 前回のトライにしか着目していない 新たなトライがあまり登場してない そもそも正しいKPTはどうするのだろう。 よくよく考えると私はしらない。 ふたたびKPT さきほど参考にはった記事のやり方をみてみる 参考: 今日からできる!全員参加型の建設的フィードバック「ふりかえり」~実践編(KPT・タイムライン) (1⁄3):テクノロジーでビジネスを加速するための実践Webメディア EnterpriseZine (EZ) Try実施確認 Keep/Problem抽出 Keep/Problem確認 Problem深掘り Try項目抽出 Who、When決定 クロージング 今回、2の「Keep/Problem抽出」がとても弱く、6の「Who、When決定」は自然とやっていたけど、強制力が弱かった気がする。 2については 今回のKeep/Problemについての項目を書き出します。時間を決めて全員で一斉に書き出します。 と書かれています。 今回のKeepとProblemに着目する時間がとれていなかったと思います。 改善案 ちゃんと各イベントごとふりかえる 時間ととって付箋で個別にKPTをする時間をとるべきだった やはり付箋をつかったKeepとProblemの抽出をやるべきだと思いました。 その他 ふりかえりの手法としてYWTという手法の紹介がありました。 参考 ビジョンを叶えるために。個人でも出来る戦略を考える第1歩 〜 YWTを使った戦略の立てかたとは | Social Change! やったこと(Y)

no_picture

「GeoJSONをGistに貼る」という話をLT駆動開発12でした

LT駆動開発12で「GeoJSONをGistに貼る」という話をした。 遊びでつくってたAPIのJSON形式をGeoJSONにしたので、GeoJSONの話をした。 仕様の日本語訳もある。 位置情報系は疎いので、積極的にアウトプットして、情報を集めていきたい所存。 オープンストリートマップのことももうちょっと調べておくべきな気がしつつ全く調べてない。 D3.jsもだけど。 他にも最近地理系はなにかあった気がする。 LT駆動を1年やった結果いろいろな資産(スライド)が蓄積された。 はてぶもされた。 2年目も毎月LTできるだろうか。

no_picture

OctopressからHugoに移行した マルチコアをもっと使いTai - LT駆動開発12

LT駆動開発12の発表者資料です。テーマ 「祝一周年&ハーレム」です。 ブログをOctopressからHugoに移行したのでその再に感じたことを発表しました。 Goはバランスがとれているなぁ、と最近感じていたりはします。 どちらにしろ、最近CPUは速くなってはいるだろうけど体感できないのは感じていたりしてました。 バッテリーの持ちはよくなってるけど。 前置きはさておき、普段ローカルで実行してるようなプログラムがマルチコアは生かせてないというのは非常に体感する出来事でした。 とはいえ、ウェブサービスをつくっていたりすると並列化なんてする必要はないだろうし、スマホアプリなら複雑な処理はAPIサーバにやらせればいいだろうし、 並列化が必要な場面は特定分野にはなるんだろうとは思います。 Hugo移行の歳にしたこと 移行の際にしたことを記録しておきます。 日付のフォーマットの修正。 find . -type f -exec sed -i "" -e 's/date: \([0-9]\{4\}-[0-9]\{2\}-[0-9]\{2\}\) \([0-9]\{2\}:[0-9]\{2\}\).*$/date: \1T\2:00+09:00/g' {} \; layoutパラメータは指定しないので削除。 find . -type f -exec sed -i "" -e 's/layout: .*//g' {} \; カテゴリではなくてタグに変更 find . -type f -exec sed -i "" -e 's/categories/tags/g' {} \; あとは、パーマリンクがずれないようにパーマリンクを指定しています。 permalinks: post: /blog/:year/:month/:day/:filename/ ただし、ファイル名にも日付を含んでたので、あきらめて削除しました。 日付でソートできなくてつらい。 あとは rss が atom.xml だったのが index.xmlになってしまったので、デプロイする前にcpして対処しました。 https://github.com/eiel/blog.eiel.info/commit/baeea3fca8ee6a4cf987c42e4ab29da6831cb6b1 Werckerをつかってデプロイしていますが、ステップがすでにあってとても楽チンでした。 https://github.com/eiel/blog.eiel.info/blob/baeea3fca8ee6a4cf987c42e4ab29da6831cb6b1/wercker.yml box:

no_picture

アイディアを思いついたらリーンキャンバスを書くと良いらしい

アイディアを思いついたらリーンキャンバスを書くと良いらしい。 リーンキャンバス的なものを書く必要があったので、LT駆動開発1周年ということで、リーンスタートアップの段階的にしている@k2works先生のスライドを見直しながら自分なりに整理しただけである。 Q. アイディアを思いついたらどうするか。 A. 実現させる アイディアを実現するための、おすすめの方法論がリーンスタートアップらしい。 個人的なざっくりなイメージ 「仮説検証を繰り返して方向を修正しながら、顧客と製品を育てる」 その最初のステップがリーンキャンバスの書きながら検証する。 書きながら、専門家に相談したり、潜在顧客にインタビューする。 リーンスタートアップ リーン ムダがなく効率的という意味。 スタートアップ 不確実な状態で新しい製品やサービスを創り出さなければならない組織のこと。 「アイディアを実現するためのチーム」と言える。 リーンスタートアップとは 新しい製品やサービスを開発する際に、顧客にとって価値のないものを作ってしまうことを防ぎつつ、より早くサービスを生みだしつづける方法論。 どうやってやるか。 構築-計測-学習を繰り返して行い最適なプランをみつける。 仮説をたてて、検証して、学んだことを反映させて、次の仮説を立てる。そして、検証する。 「プロトタイプを提供して、顧客にフィードバックをもらう」はコストが高い。 プロトタイプの作成はコストが高い。 そもそも顧客がまだいない。 リーンキャンバスを作成して、潜在顧客にフィードバックをもらう。 リーンキャンバス リーンキャンバスを書いていくことそれ自体が、アイディアを実現するための整理でこれからのプランの構築をすることになる。 リーンキャンバスでやることを並べると以下のようになる。 対象とする顧客が明確にする 何を課題としているのか明確にする 顧客に伝えるコンセプトを明確にする どうやって解決するかを明確にする このサービスをどうやって宣伝するか決める 収益源を想像する かかるコストを計算する 成長していることを計測するための指標を決める 他者より優れている点を整理する アイディアを思いついたらすべきことが整理されている。 ここからリスクを洗い出して、プランを検証していくことになり、 配置に意味があるので、わかりやすくなることらしい。(たぶん) まとめ アイディアを思いついたらリーンキャンバスを作成する リーンキャンバスをつかって検証して、プランの固める ここからどうするのか リーンキャンバスの書き方を学ぶ リーンキャンバスを使った検証方法を学ぶ リーンキャンバスに書いたソリューションのプロトタイプを作成する リーンスタートアップのことを学ぶ とりあえず、ウェブ上の情報では表面的なことしかわからないので実践リーンスタートアップを注文した。 追記 ウェブ上でリーンキャンバスを作成できる TinyCanvas 参考文献 実践リーンスタートアップ…その前に 実践リーンスタートアップ NPO / ソーシャルビジネスのためのリーン・スタートアップ入門 【Running Lean入門】リーンキャンバス作成ワークショップ(簡易版) はじめてのリーンスタートアップ

no_picture

ChefDKハンズオンをして思ったこと

ChefDKハンズオンをしました。 すごい広島93の脇で行いました。 ハンズオンをするととても勉強になります。自分が。 当日のトラブルを避けるための入念な準備をしたり、それでも想定しないことが起きたり、自分では簡単だと思っていることが他の人には意外と難しかったり、なんとなく理解の部分を発見したりできました。 参加者にとってハンズオンの良いところは、本来一人で新しいことをはじめるとつまづいた時に一人で解決しないといけませんが、講師がいて一緒に解決できるところがとても大きいと思いました。 そんなわけで、ChefDKハンズオン with すごい広島の資料はここにあるので、気が向いたら遊んでみてください。 反省点なんかを反映したいですが、間に合っていません。 作るのもそれなりに大変だったので、しっかり直したいです。 今度から月1回程度、他の人の作成したハンズオン資料でハンズオンしたり、ときどき自作したりしてもいいかなと思いはじめています。 そういえば、Boot2dockerの準備の仕方を書いてなかったらみんなハマってました。 使ったことなければ、それはそうですね、本当にすみません。 再演希望とかあれば言ってください。研修に使いたい場合、講師で呼んでくれても良いです。 生活費稼がなきゃ。 もっとみんなに使って欲しいと思った技術をみつけたら、新しいハンズオンを考えてみたいです。

no_picture

「外資系エリートのシンプルな伝え方」を読んだ

読んだというか、ジャンケン大会で勝った。 あれはたしか1月31日に行われた「2015 MVP Community Camp~広島~」だった。 「澤 円さんという世界に何人か存在するプレゼンの神の一人がいらっしゃる」ということで足を運んだ。 でも、たぶん澤円かさんが来なくても足を運んだと思う。 なんだか珍しくジャンケン大会で勝つことができた。 そこで得たのは 澤円さん著 「外資系エリートのシンプルな伝え方」 である。 当然だがサインをいただいた。(ありがとうございます) ひっそり、りんごマークが映るように撮るべきだった。(やめろ) 本書は意外と厚いのだけど、文字が大きめなので、そんなに内容は多くない。 そこら辺にいっぱいある自己啓発に書かれていることばかり書かれているかもしれない。 だけど、冒頭で説明したように、神と評される人がどんなことを実践しているかと思って読んでみると驚くべき本である。 以前どこかにかいたけど、すごいと思う人の習慣を真似することはとても効果がある。 もし澤さんのように、心を動かす伝え方をしたいのであれば、この本はシンプルでとても良い本だ。 本書は、自己啓発から始まり、コミュニケーション術を経由して、本題の澤さんがプレゼンで大切していることに向かう。 最後のプレゼンで大切にしていることはたくさん刺さる。 「相手の未来を拓く核を持て」とあるが、これができている人のプレゼンは終わった後はワクワクする。実践してみたいものです。 自分が得意なことを誰かに伝えたい人は、一度澤さんのプレゼンを見て、本書を読んでみると良い。 一度以上人前でプレゼンをしたことがあるとなお良い。 とても心動かされることだろう。 僕は誰かの心を動かすような話をすることが今後できるだろうか。 勝手に宣伝しておくと、今週も広島に澤円かさんが広島にやってくるらしい。 ヒーロー島 バレンタイン スペシャル 2015 with Windows女子部 宣伝する間もなく定員いっぱいみたいですが。 ところで、ロン毛おじさんでググると澤 円さんがヒットするらしい。

no_picture

GitHubに馴れると何ができるのか

コンピュータに疎い人にGitHubに馴れると何ができるのか聞かれたので、その時に書いた文章を残しておく。 GitHubに馴れると何ができるのか GitHubの操作になれると、他の人の協力して「ものづくり」しやすくなります。 「ものづくり」と書きましたが、なんにでも使えるわけではないです。 基本的にはコンピュータ上で動くものを作るときでであり、作るものは、文字で表現できるものが主となります。 文字で表現できるものは、例えば、コンピュータ言語を記述して作るものがあります。 コンピュータ言語を使って作成できるものは、アプリケーションやウェブページなどなどがあります。 コンピュータに疎いということであれば、GitHubに慣れることよりもまず、コンピュータを使って何かを作ることになれる必要があるかもしれません。 もし、コンピュータを使って、アプリケーションやウェブページを作成しているのであれば、GitHubに馴れることで、他の人と協力しやすくなります。 HTMLというものやCSS、JavaScriptなどを利用して、なにかを作成している場合、今の時代であれば、どこかでGitHubというものに出会うと思います。 蛇足 書いてて、思い出したのは「ものづくりにっぽん: Gitとかわかんなくても死なないです」だけど、Gitとかわかんなくても死なないのは事実だな、と思いながら書いた記憶があります。 ただ協力して作業する場合に、便利なサービスとしてGitHubをたくさんの人が使うようになると、Gitが使えない人は協力して作業するのが難しくなると思います。 そのコストを誰かが払ってでも一緒にものをつくれるのであれば、Gitとかわかんなくても生きていけると思うのでした。 何を学ぶかは、誰と作りたいのか、何を作りたいのか、それをどうやって作るのか。 僕はGitがないと仕事できないので、一緒につくりたい人のためにはGitの使い方なんていくらでも教える。 マイノリティーが生きるのはどこへいっても辛いものです。

no_picture

「プログラマのためのGulp入門」というLTをするはずだった

LT駆動開発11で「プログラマのためのGulp入門」というLTをするはずだったんだけど、 思っていたより発表者がいたためお蔵入りしました。 次回に回してもよかったんだけど、正直まとまっていないし、そもそもLTに収まらないのが明らかだったので、今回はさっさとスライドを公開することにした。 そして内容をいそいそと現在Qiitaに書き下しております。 プログラマのためのGulp入門 - Qiita 今回、用意したLTがDockerとGulpって僕はいったいどこへ向かっているのかさっぱりわからない。

no_picture

LT駆動開発11で「 dockerをどこかで使う」という話をした

LT駆動開発11でライトニングトークをしました。 LT駆動開発11はオープンセミナー2015@広島の懇親会内で行われました。 そういえば、「タイトルがつまらないと」言われましたが、Dockerなんていますごく盛り上がってるのにキャッチーなタイトルつけたら死んでしまいます。 まさかり怖い。 Dockerいろいろつかってますが、すごく楽しいです。 Dockerつかってやりたいことも結構あります。 Docker自体はまだ使わないだろうとおもってたんですが、ちょっとDocker使いたくなってどっぷり使っています。 「Railsのアプリを開発するのにRubyをインストールする必要がなかったり、production環境でRailsアプリを動かすのにRubyやnodejsをインストールする必要がなかったり」 その辺すごく良いとおもったので、そのあたりを強調した話をしました。 CI環境で使えないミドルウェアがあっても安心っすね。Werckerがあるけど。 僕自身そんなに頭は良くないので、シンプルに考えることができるようになるプロダクトは好きです。 そのひとつはDockerでしょう。「Gitのコミットしてブランチが切っていれば良い」みたいな安心感があります。 そういえば、このスライドの内容は遊びでつくってるサービスでもやってるのでご自由に閲覧ください。 Github Parkmap-h/parkmap そういえば、時間があまらなかったので、もう一個スライドがあまってるのでどう消化するか悩み中です。(どうでもいい)

no_picture

再・オープンセミナー広島は広島のITエンジニアが集う場所

昨年のオープンセミナー広島の実行委員長です。今年は雑務担当です。こんにちは。 2015年2月14日(土)オープンセミナー2015@広島が開催されます。 そういえば前振りとして LT駆動開発10でTest KitchenではじめるChef入門という話をした。OSH2015のステマかもしれない。 - そんなこと覚えてない という記事も書いていた。 しかーし、イベントを来週に控えた2015年2月6日現在の申し込み人数は28名だ。 ちなみに去年の参加者は93名だったらしい。 ついでに、懇親会は41名の参加があったらしい。 それはさておいて、去年こんなタイトルの記事を書いていた。 オープンセミナー広島は広島のITエンジニアが集う場所 - そんなこと覚えてない すこしだけ抜粋しよう。 テーマに興味なくても参加しようぜ 本番は懇親会らしい 将来の委員長が会いたい人を呼べるイベントになればいいのに 同じことを書いても仕方ないので少し遊ぶ。 テーマに興味なくても参加しようぜ テーマってコミュニティに参加している人の好みへ流れるので、参加して「俺好みにしようぜ」という話を書いた。 特に大きいイベントに。 結果、自分が好むテーマのイベントが増えていくと思う。 それ以前にコミュニティの人たちが興味をもってることだから何かしら役には立つとは思いたい。 どうやらイベントがバレンタインデーなのがまずくて、参加したくても参加ができないのではないかと思う。 > ITエンジニアはなんてリア充なんだ!! < 本番は懇親会らしい セミナーで講師の話を聞くのが目的にしないで、刺激をうけた上で情報交換しようってのが裏の理由だろう。 そんなことはおいておいて面白いライトニングトークをして欲しいのが建前だ。 面白ければどうでもいいのが本音である。(?) ということで、懇親会でLT駆動開発を行うことになった。 > テーマは「打倒オープンセミナー」< LT駆動開発 11 - 打倒オープンセミナー - LT駆動開発 | Doorkeeper DockerかGulpの話をする予定だけど、時間が足りなくて別の話をするかもしれない。 将来の委員長が会いたい人を呼べるイベントになればいいのに スタッフもボランティアなのでなにかメリットがあって欲しい。 そういう話である。 しかし、参加者が少ないイベントに協賛してもらうのも心苦しいので、そういった意味ではたくさん人が来て欲しい。 > ボランティアメリットにはまずは協賛メリットとかつらい! < まとめ 別に島根から来てもいいんだぜ(ちらちら 岡山の人は何も言わなくても来るだろう。 もちろん鳥取、山口、福岡、香川、徳島、高知、愛媛もね。 私もちょろちょろ遊びにいきます。 仕事が楽しいセミナー旅行で、ITエンジニアは魔法使いで、子供の憧れるような職業になればいいと思う。 打倒デスマ。 この想いはどの辺りまで届くんだろうか。えいやっ! > オチが同じ!! < オープンセミナー2015@広島 - オープンセミナー広島 | Doorkeeper

no_picture

DockerでCMSの会 Vol.2に挑む - 準備編

CMSの会 Vol.2というイベントが2月7日(土)に広島で行われるらしい。 a-blog CMS,concrete5,Wordpressの3つのCMSを使って、同一のウェブサイトを作成して、個々の長所短所を学べるらしい。 こっちも確認しておくとよいだろう。 川谷制作所 » CMSの会Vol.2をやります さて、参加するかどうかは不明だが、参加条件に環境を準備をしてくる必要がある。 どうやって環境を用意するかと考えた結果。「ここはDockerしかない」と思い、環境を整えてみた。 実際に参加してみるとどんな問題にぶつかるかわからないので、参加する場合に参考にする場合は注意しておいたほうが良いでしょう。 事前にテキスト的なものがいただけたら確認はできるかもしれないが。 さて本題。 dockerがインストールされていれば以下のコマンドで環境を構築できる。 Windowsは想定していない。(そろそろOSが欲しいが空いてる64bitマシンもない) docker run -d --name my-mysql -e MYSQL_ROOT_PASSWORD="secret" eiel/mysql:concrete5 docker run -d --name my-wordpress --link my-mysql:mysql -p 8001:80 -v `pwd`/wordpress:/var/www/html eiel/wordpress docker run -d --name my-concrete5 --link my-mysql:mysql -p 8002:80 -v `pwd`/concrete5:/var/www/html eiel/concrete5 docker run -d --name my-acms --link my-mysql:mysql -p 8003:80 -v `pwd`/acms:/var/www/html eiel/acms イメージをダウンロードするので時間がかかります。 二度目からはダウンロードの必要がないのでだいぶはやくなります。 wordpress concrete5 acms の3つのディレクトリが作成されます。 それぞれのCMSの作業ディレクトリとなっていて必要なものが準備されています。 CMSの動作を見るにはdockerの動いているホストのそれぞれのポートにアクセスすればOKです。 boot2dockerを使っている場合はまずIPを確認します。 $ boot2docker

no_picture

LT駆動開発10で「Rubyistからみたnpm」という話をした。

LT駆動開発10で「Rubyistからみたnpm」という話をした。 このスライドは10月につくったのだけど、使う場面がなかったけど、今日は時間が余ってたので取り出しました。 なんか微妙だった。まあ。いいや。 使ってみた上での認識です。 参考になれば幸いです。 関連 LT駆動開発10でTest KitchenではじめるChef入門という話をした。OSH2015のステマかもしれない。

no_picture

LT駆動開発で「GitHubのリポジトリで先月のコミット一覧を見たい」という話をした

LT駆動開発10で最近つくったGemを紹介した。 作業しているGitリポジトリの先月の作業内容を閲覧するためにつくった。 GitHubのcompareのページをブラウザで開いてくれるGemだ。 $ git month-commits open で使える。 openをけずると git log を実行します。 インストールは下記の通りである。 gem install git_month_commits 毎月やる作業を楽にするどうでも良いスクリプトである。 コミットを探す簡単なスクリプトを用意してたのだけど、折角なのでrubyで書き直した。 エコシステムが整備されてこういうのが気軽にインターネットにおけるようになったのは利点なのが問題点なのかわからないけど、楽しいので良いことにしよう。 ちょっと改造すれば先週とか月指定とかにもできるけど要望があったら考えることにしよう。 関連 eiel/git_month_commits · GitHub LT駆動開発10でTest KitchenではじめるChef入門という話をした。OSH2015のステマかもしれない。

no_picture

LT駆動開発10でTest KitchenではじめるChef入門という話をした。OSH2015のステマかもしれない。

LT駆動開発10で「Test KitchenではじめるChef入門」という話をした。 ちなみにこの記事はオープンセミナー2015@広島のステマ記事でもある。 また、「Test KitchenではじめるChef入門」はQiitaに投稿した記事である。 Chefはちょいちょい使っていて、使いこなせてはいません。 Cookbookを作成するときの環境で、Vagrantfileでやるのがよいのか、knife-zeroを使うのがいいのかいろいろ悩んでいた。 やっぱりテストコードを書きたいし、ますはTest Kitchenをいじっておこうと至るのは自然な道だと思う。 Test Kitchenをいじっていると、そのままの環境でCookbookを書くのが良さそうだということに気づいた。 ならば、はじめからTest Kitchenを使いつつChefを学ぶのも良さそうだということで「Test KitchenではじめるChef入門」というネタを考えた。 詳細はQiitaの記事を参照して欲しい。 広島のみんなはオープンセミナー2014@広島で@t_wadaさんに来てもらったことだし、何をはじめるにしてもテストコードをかく環境から導入したいはずだ。 きっと、Chefのテスト環境にみんな興味があるはずだ。(確信)(そんなわけはない) そういえば、オープンセミナー2015@広島は2月14日が行なわれる。 事前申し込みはこちらからできる。 そして、みんなすごいChefを試していると思うんだけど、Chefの調べものをしていると、きっと@sawanobolyさんを何度もみかけるはずだ。 代表的な記事をピックアップしてみよう。 Ruby - Chefのローカルモードチュートリアル + knife-zero + knife-sakura - Qiita test-kitchenのつかいかた - Qiita Chefのローカルモードだけでリモートサーバを運用してみようと、Knife-Zeroを作った。Nodeの構成情報もとれるよ。 - Qiita ところで、オープンセミナー2015@広島の講師に@sawanobolyさんがいるように見えるのは僕の気のせいだろか。 Chefに限らず構成管理ツールの利用箇所は幅が広がりつつある。 Packerをつかって各仮想環境のbox作成 Vagrantのプロビション Dockerなどコンテナのプロビジョン WerkerのBox作成 GitLabのインストーラ あまり知らないけど、僕が知る限りでも、そこそこある。 もっとあるんじゃないかと思う。 構成管理ツールは運用する人たちののツールから開発をする人たちでも使われていくツールなるだろう。 せっかく@sawanobolyさんがいらいしゃるので、いまのうちにChefをしっかりいじっておきたいよね。 他にも広島でChefをいじっている人いえば、@akira345さんとか、@k2worksさんとか、@ogatomoさんとか、@moobay9さんとか、@pecosantoyobeさんとかがいる。 Ansibleなら@soudaiさんとか@24motzさんとか、@yukilabさんとか、@NeXTSTEP2OSXさんとかがいじっていると聞いている。 たぶんTwitter IDを上げた人はほとんど参加するはずだ。間違いない。 名前を上げなかった人でもきっと何かしらの構成管理ツールを使っている人がたくさんいて遊びに来るはずだ。 @sawanobolyさんが来るんだし、きっと間違いない。(自信なし) さあ、みんなでオープンセミナー2015@広島に集まって情報交換しよう。 構成管理に入門するタイミングとしては、この上はないはずだ。 そういえば以前こんな記事を書いている人がいましたね。 オープンセミナー広島は広島のITエンジニアが集う場所 - そんなこと覚えてない くりかえす。 オープンセミナー2015@広島は2月14日だ。 事前申し込みはこちらからできるぞい。 全く関係ないし、公式に受理されていないが、オープンセミナー2015@広島の懇親会の裏の名前はLT駆動開発11なる予定だ。 関連 JunkBox~主に個人的防備録~: オープンセミナー2015@広島を開催します!

no_picture

2014年を振り返る - まとめ編

2014年をふりかえりしようと思っていたら31日なっていた。 今年は去年に引続きアウトプットは意識してやっているので分量が多い。 というわけで、分割しながらすすめた。 2014年を振り返る - スライド編 - そんなこと覚えてない 2014年を振り返る - GitHub編 - そんなこと覚えてない 2014年を振り返る - ブログ編 - そんなこと覚えてない 他にも軸を絞ってふりかえりしたいところである。 2014年はコミュニティ活動が忙しかった印象が強いです。 来年は実を結んでいきたいところです。 以下はじっくり1月からふりかえってみる 1月 オープンセミナーの準備を進めながらiOSアプリの作成をがんばってた気がする。 忙しいから仕事を控えめにしようと思ったのに3つが同時進行する悪夢だった。 見積りしたら負けなんです。 大学生にiOSアプリを教える会を見にいった。 そういったところにもうちょっとノウハウを提供したいとは思うけどなかなかうまくいかない。 2月 実行委員長を務めたオープンセミナー2014@広島が行なわれた。 期待した程度に参加者が集まってよかった。本当によかった。 来年も同じぐらい人が来ると素敵である。 オープンセミナー2015@広島 オープンセミナーがうまくいったので、ちょっとがんばろうと思ったことを思い出した。 3月 LT駆動開発がスタートした。 カレンダーにはIT勉強会駆動と書いてあるのは秘密である。 5374(ゴミナシ).jp for Hiroshimaを作った。 Twilio API 勉強会 @広島なんかのサポートもしていたようだ。 月末はとにかく仕事をしていたくせに、広島・岡山Ruby勉強会に参加したりしてとにかくバタバタしていた。 4月 前半は土日も仕事していて納期が多重に重なる罠にはまる。 CSS Nite in Hiroshima Vol.8の準備なんかがはじまる。 5月 割と楽しくのんびり過ごした。 オープンセミナー2014@岡山に参加したり、すくすくスクラム広島で長めのイベントがあったり、JSer’s Cafe ZEROがスタートしたりした。 6月 Rubotyですごい広島BOTをつくった。 仕事がくるくると聞いていたので空けていたのだけど、こなくてswiftで遊んでいた気がする。 Sketch 3勉強会とか手伝ったりした。 DevLOVE広島 第一回(夏の陣)が開催されて登壇したりもした。 7月 とある我馬の非公式(ファンサイト)を作成した。 dockerで遊んでいた時期でもある。 Atom Editoへの引っ越しを検討したが失敗に終わった。 8月

no_picture

2014年を振り返る - ブログ編

2014年をふりかえりしようと思っていたら31日なっていた。 今年は去年に引続きアウトプットは意識してやっているので分量が多い。 というわけで、分割しながらいきます。 というわけで本ブログをふりかえる。 記事数 84 2013のほうが多い気がする。 年間PV 12万 去年は8万PVで大きくは伸びてない。増加率としては落ちている。 PVランキング せっかくなのでPVランキングをつくっておこう。 10位 Cucumber のフィーチャの文法 - Gherkin - そんなこと覚えてない 2013年の記事。個人的にはがんばった記憶がある。 これをかいてCucumberはだいぶ怖くなくなった。 9位 コミットメッセージの先頭に絵文字いれるのが流行ってんだろうか 結局覚えられないのであんまりつかってない。 8位 GitHub に課金した 課金するだけの話なのに…英語だと怖い人がたくさんいるのかな。 7位 今後のiOSアプリケーションのために Auto Layout を学んだ - 内容編 2013年の記事。AutoLayoutはまだまだ勉強不足です。 6位 Git がわからなくても Github を利用しよう 2013年の1位の記事。まだまだ見てくれる人がいる模様。 5位 Rails の自動読み込みの話 2013年の記事。結構リンクしてもらったりしているので伸びている。 4位 GnuPG で遊ぶ - 暗号化してみる GnuPGはもっとみんな使えばいいのにって思う。これも2013年の記事。 3位 Ruby on Rails で NOT IN な SQL をかく。 最近Rails4に以降した人が多いのかそこそこ伸びている。これも2013年だと…。 2位 Github の楽しみ方 2013年の2位記事。まだまだいける。 1位 Github Pages

no_picture

2014年を振り返る - GitHub編

2014年をふりかえりしようと思っていたら31日なっていた。 今年は去年に引続きアウトプットは意識してやっているので分量が多い。 というわけで、分割しながらいきます。 今回はGitHubのリポジトリを辿ってみた。 いっぱいしょうもないリポジトリをつくっていた。 40個近く新しいリポジトリを作成していたようです。 CppHiroshima-1 https://github.com/eiel/CppHiroshima-1 C++勉強会in広島でスライドをつくるのに試したコードを置いている。 CppUTestというのを試した。 cookbook-munin-example https://github.com/eiel/cookbook-munin-example Chefを試すのにまずはリソースチェックかなということでmuninをインストールしてみて遊んでみたやつだ。 iOS-CameraSample https://github.com/eiel/iOS-CameraSample iOSプログラミングを大学生に教えるイベントに参加して、その時に学生と一緒につくったプログラムのソースコード ActionTemplate https://github.com/eiel/ActionTemplate RailsのAbstractControllerを単体で使ってみたくて試した時のソースコードです。 5374-csv-generator-in-hiroshima https://github.com/great-h/5374-csv-generator-in-hiroshima hiroshima.5374.jpをつくるのにHTMLをスクレイピングしてCSVをつくるのに使ったスクリプトです。 chef-porxy https://github.com/eiel/chef-proxy squidの動作確認をするのにつかったchefのcookbookです。 keynotes-eiel https://github.com/eiel/keynotes-eiel http://keynotes.eiel.info/ のindex.htmlを作成してS3にアップロードするスクリプトです。 Haskellでかきました。 jekyll-ention-test https://github.com/eiel/jekyll-mention-test GitHub Pages で jekyll-mentionが使えるようになっていたので動作確認に使ったものです。 UIDynamicsSample https://github.com/eiel/UIDynamicsSample iOS6あたりで追加されたUIDynamicsをつかったサンプルコードです。 my-hubot https://github.com/eiel/my-hubot idobataにつかってるhubotのソースコードです。 wpho-30-typescript https://github.com/eiel/wpho-30-typescript WindowsPhoneハンズオンでtypescriptのハンズオンをしたときのソースコードです。 great-bot https://github.com/great-h/great-bot すごい広島のTwitterアカウントの中の人です。 Rubotyでつくっています。 vagrant-up-with-wordpress https://github.com/eiel/vagrant-up-with-wordpress vagrant up したら wordpressの環境が整って欲しかったのでつくったVagrantfileです。 kaleidoscope https://github.com/Augment8/kaleidoscope Swiftがベータの時につくった万華鏡です。 A8D:2というイベントのために作りました。 docker https://github.com/eiel/docker-bannar dockerがはやっていたのでdockerで遊んだときのサンプルです。 docker-development_environment https://github.com/eiel/docker-development_environment dockerで開発環境が作れないか試行錯誤した時のものです。 docker-portage https://github.com/eiel/docker-portage 最新のportageをいれたdocckerイメージがつくれるようにしたdockerfileです。 use-actionview https://github.com/eiel/use-actionview 勉強のためにRailsのActionViewを単体でつかってみたくて試したときのサンプルコードです。 gaba https://github.com/eiel/gaba ラーメン屋我馬の公式サイトの更新情報を取得できるgabaコマンドを提供するgaba-gemの中身です。 gaba.eiel.info https://github.com/eiel/gaba.eiel.info とある我馬の非公式のソースコードです。 wpho-31-typescript2 https://github.com/eiel/wpho-31-typescript2 WindowsPhoneハンズオン31回でかいたサンプルコードです。 今回もtypescriptでした。 rails_template-eiel https://github.com/eiel/rails_template-eiel 自分がつかっているRails Application Templateです。 eiel.info https://github.com/eiel/eiel.info eiel.infoの中身です。 自分のウェブサイトです。 itunes_information_slack https://github.com/eiel/itunes_information_slack 現在itunesで再生している曲をslackにおくりつけるスクリプトです。 hirohata-reporter https://github.com/great-h/hirohata-reporter ヒロハタの参加者の情報を収集するためのスクリプトです。 hirohata https://github.com/great-h/hirohata hirohata-reporterをつかって収集した情報を公開しているヒロハタを勝手に応援するサイトの中身です。 wercker-box-review https://github.com/eiel/wercker-box-review WerckerでRe:viewをつかった電子書籍をコンパイルするのにつくったboxです。 github_scouter https://github.com/eiel/github_scouter GitHub戦闘力を計測できるスクリプトです。 ltdd_shuffler https://github.com/LTDD/ltdd_shuffler LT駆動で喋る順番を決めるのがめんどくさくなってシャッフルするために書いたスクリプトです。 modified-update-rails-sample https://github.com/eiel/modified-update-rails-sample 友人にActiveRecord(ActiveModel)のbefore_updateについて説明するのに書いたサンプルコードです。 quim https://github.com/eiel/quim Eメールを管理するためのウェブアプリケーション。タグをつけて、特定の人にだけメールを送れたりする。 絞り込みをウェブインターフェースとして提供できなくてrails cをつかって調整して使っているのは秘密だ。 eiel-logo https://github.com/eiel/eiel-logo 自分の名刺につかっているロゴです。 作ってもらった。感謝感激。 circleci_notify https://github.com/eiel/circleci_notify CircleCIから通知しやすくすろに書いたGemなんだけど、アダプターがチャットワークしかつくってない。 browserify-sample https://github.com/eiel/browserify-sample browserifyというクライアントサイドでnodeモジュールが使えるようになるライブラリを試した時のサンプルコード。 gulp-assemble-abc https://github.com/eiel/gulp-assemble-abc gulp で静的サイトジェネレータするのにassembleをつかってみたというサンプルコード。 gulp-assemble-template https://github.com/eiel/gulp-assemble-template gulp で静的サイトジェレートするためのGulpfileがおいてある。 color-schemes https://github.com/eiel/color-schemes 自分のつかっている配色データをおいておこうかとおもってつくったリポジトリ。 great-mile https://github.com/great-h/great-mile すごい広島のやること宣言を俯瞰するためにつくっているサービス。 まとめ みんなGitHubはゴミ箱じゃないぞ!

no_picture

2014年を振り返る - スライド編

2014年をふりかえりしようと思っていたら31日なっていた。 今年は去年に引続きアウトプットは意識してやっているので分量が多い。 というわけで、分割しながらいきます。 まずは公開したスライドから。 今年はspeakerdeckにしかスライドをアップロードしていない。 https://speakerdeck.com/eiel ざっと確認したところ34個のスライドを公開したようです。 途中からkeynoteのファイルも以下で全て公開しています。 http://keynotes.eiel.info/ ざっくり 主に2014年3月からはじまったLT駆動開発のせいで毎月スライドを二つ作ったりしたせいで30越えになった。 分割したのに、とても振り返ることのできる分量ではない気がする。 仕事が忙しかった4月が一番少なく、一番仕事を避けていた9月が一番多い結果になった。 9月だけで8個あってわけがわからない。そういえば9月なんも仕事をした記憶がなかったのはこのせいだろう。 いくつか紹介する オープンセミナー2014@広島の実行委員長になったので…完全版 主に2013年のふりかえりの結果を整理したスライド。 2013年はスライドを23個つくっていたことがわかった。 そいや今回のオープンセミナーの申し込みに事前アンケートをつくり忘れていることにも気づいた。 今回は私はただの下っ端ですが、目標は120人ぐらいなので、みんな申し込みしてください。 オープンセミナー2015@広島 - オープンセミナー広島 | Doorkeeper CIのある生活 第1回のLT駆動開発用に対象者をウェブをやっている人まで引き下げたつもりでつくったスライド。 しかし、イベントの時間があまらなかったので大幅縮小で実質お蔵入りである。 今みなおすと、長い。長いよ…。 LT駆動開発で「CI のある生活」という話をするはずだった - そんなこと覚えてない ActionDispatch ってなんだろう? 広島岡山Ruby交流会 01のためにつくったスライド。 RailsのActionDispatchがどういうものが自分でイメージできるようになっていたので整理した。 Railsのアーキテクチャは無駄にがんばったがあっているか謎だ。 コアにはrackがいて、小さなラックアプリケーションへ橋渡しをする大きなラックアプリケーションがActionDIspatchである。 ルーティングをしているだけともいえる。 ActionDispatch ってなんだろう? // Speaker Deck S3にスライドを保存することにした スライドって一度つくったらなおすことないしS3に保存するかーってことではじめてAWSのAPIを叩いて感動したので、HaskellでS3のAPIを叩いて遊んだ話である。 PVはあまり伸びなかった。(あたり前) LT駆動開発03で「S3にスライドを保存することにした」という発表者をしてきた。 - そんなこと覚えてない 継続は力になるのか 結構反響があったスライドだけど、当日はあんまみんな話を聞いてなかった気がする記憶。 日々続けることで身につく力はすごいと思う。 途中にいれたツイートがおもったより伸びない。(仕方ない) オープンセミナー2014@岡山に参加した。ついでに懇親会で継続することについてLTした。 - そんなこと覚えてない 愛無双 - エンジニアリングの楽しさ DevLOVE広島 第一回でエンジニアリングの楽しさを語るという使命の元に作成したもの。 実はかなり悩んだので作るのにつかった時間はかなりかかっている。 しかし、全然伸びなかった子なので見てない人はみて欲しいところ。 We’re so Happyをめざしたい。 DevLOVE広島

no_picture

Oiitaと技術系ブログを書き分けることにした理由

Qiitaをどのように使うのか迷っていたのだけど、答えが出たのでQiitaも使うことにした。 結論から書くと「読者のことを考えた上で書き分ける」ことにした。 そんなわけで、昨日はじめてQiitaに投稿した。 oh-my-fishではじめるfish - Qiita 読者にとって、書いた内容がQiitaのほうが読みやすいのであればQiitaに書くことにした。 そうではなく、そこから漏れてしまったことはこのブログに書くことにする。 「読者のことを考える」は文章を書く上でとても大切なことです。 数学文書作法で、結城先生がとても大切なこととして説明されています。 この記事の目次。 Qiitaに書いたほうが良いこと Qiitaに書いても広告収入は増えないけど その他雑多なこと Qiitaに書いたほうが良いこと Qiitaに書いたほうが良いものはなんだろうか。 Oiitaはプログラミングに関する知識を記録、共有するサービスです。 ということは、プログラミングに関する知識を閲覧するのに、私が何もしなくても、日々読みやすくなっていくと考えることができます。 自分のブログをもっと読みやすくしていくこともできますが、この労力を捻出することはなかなか難しいです。 しかし、このブログにいつも書いていたことが、Qiitaでも書けるかというと、そうでもない記事もいくつかあることに気づきました。 本記事もそうだし、どこそこでLTしたなんかもそうだし、あれを作った、というのもQiitaには書ける気がしない。 書きたいことが浮かんだ時に、何を伝えたいのか明確だったらQiita書くと思う。 Qiitaでタグをフォロしている人はどんな情報を読みたいだろうか。 そのタグに関する有益な情報を読みたいはずです。 少し話はずれるけど、noteに文章を投稿する場合も同様で、何か伝えたいことがあってすごく強い時でジャンルが技術系ではない場合に使っています。 書く場所を変えることで、文章を書く時の気持ちを切り換えもできます。 Qiitaに書いても広告収入は増えないけど そもそもなぜQiitaに書かないのかを考えると、どっちでもいいならこのブログに書けば広告収入が増える可能性があるからだろう。 これからQiitaに書くだろう記事をこのブログに書けば、このブログからの広告収入は増えるだろう。 しかし、技術系の広告収入なんて雀の涙で、せいぜいサーバの運用費ぐらいにしかならない。 あまり気にすることではない。 読者のことを考えて良いと思う選択をするほうが、いつかもっと大きな利益になって還元されるんじゃないだろうか。 目先のメリットに囚われるな。 そもそも広告収入で生活したいならもっと別のことをすべきだし、そっちのほうが効率が良いはずだ。 その他雑多なこと 過去に書いた記事を整理してQiitaに書きなおしたりすることもあると思う。 その際には自分のブログから引用にしたり参考文献にはったりすることもできる。 ハイパーメディアの特徴を生かせたら良いと思う。 Qiitaだけでなくて他のサービスも使い方にも悩む。 スタックオーバーフローを今から調べたいことを質問しておいて、作業をすすめるとアドバイスしてくれる人がいて捗りそうな気がしている。 「アドバイスがくる前に解決したら自分で回答する」みたいな使い方もありなのか検討していたりする。 ますますブログにかくことがなくなりそうではある。 まとめ 整理されたドキュメントや何か伝えたいことがあればQiitaも使っていこうと思う。 そこから漏れてしまう書いておきたい技術メモはこのブログにかいていく。 現時点でQiitaに書かないこと。 どこかのイベントでセッションをしたこと バグをみつけた、一時的な回避方法 ライブラリやウェブサービスやウェブアプリケーションを作成した ちょっと確認しただけの書き捨てたメモ ということで、Qiitaさんには読み手も書き手も便利なサービスになっていくことを期待したいと思います。 何をするにしても「読者のことを考える」ことを大切にしたいですね。 もちろん文章を書く以外では「相手のことを考える」ことを大切にしたい。

no_picture

gitで公開されてるクックブックに依存している時のmetadata

ふつうに書くしかない。 利用する際にはcookbooksディレクトリにあればよい。 test-kitchenをする際には、Berksfileにかいとけばよい。 以下のようになる。例はrbenv。 metadata cookbook 'rbenv', git: 'git://github.com/fnichol/chef-rbenv.git', branch: 'v0.7.2' このクックブックに依存したクックブックを書くとつらい目にあうような気がするので、READMEにしっかりかいておいたほうが良さそう。 どうしてこんな話が出てくるかというと、rbenvは系統が違うものがふたつある。 chef-rbenv rbenv-cookbook chef-rbenvのほうはsupermacketにあるのだけどrbenv-cookbookのほうはない。お互いに関連はなさそう。 「VagrantにRuby/Rails開発環境を整えるChef+Berkshelf構築メモ - Qiita」ではgitで指定していたのでそんな話がでてきただけである。

no_picture

黒背景に青文字はやめろという話を合同勉強会in大都会で話をした。

合同勉強会 in 大都会岡山 -2014 Winter-に参加して、「黒背景に青文字はやめろ」という話をした。 その様子をみたいならTogetterがある なんか色の勉強する機会が欲しいと思って出オチなタイトルを設定してみた。 しかし、あんまり調べたことがそんなに反映されていない。 ちゃんと咀嚼できなかったのとそんなに時間をとれなかったのが原因である。 終わる終わる詐欺です。どうもありがとうございます。 後半は完全に「エディタの文字色に悩む日々 - CIELCH」の使いまわしではあるが、書いてないことも喋ったりしたし、気にしないことにしよう。 まあ、HSBの明度は人間の感覚には合わされてないので、感覚で調整するには使えるけどプログラムで処理するにはあまりつかいやすくない。 知っていると若干色づくりに役に立つかもしれない。 そういえばPCメガネは青色をカットするけど、青色が文字の読みやすさには影響を与えずに光を弱くできるという機能があるのかと言えるのかもしれないと思ったけど、根拠がないので言わなかった。 そのあたりはディスプレイの設定でカバーできる気もしなくもない。 しかし、画面ってだいたい白いしな。まぶしいぜ。 というわけで、中身があったのかなかったのか自分ではよくわからない始末である。 まとめると、黒と青の組み合わせ、白と黄の組み合わせが読みにくいという話でした。 そういえば、今回作成したiTermのカラースキームはeiel/color-schemes · GitHubにおいている。 ハイライト色を暗めにとっていて、場合によっては使いにくいかもしれない。 世の中にはいろんなカラースキームが公開されているので、そっちを使うほうがいいかもしれない。 今年はたくさんセッションをしたけど、これが最後だと思われる。 来年も考えたことはてきとうにまとめていこう。 参考文献 X 8341-3:2004 「高齢者・障害者等配慮設計指針-情報通信における機器,ソフトウェア及びサービス- 第3部:ウェブコンテンツ」技術解説 第1.1版 委員会ワーキングドラフト(7月22日版) ウェブコンテンツ・アクセシビリティ・ガイドライン 1.0 色の組み合わせチェック - 読みやすい前景色と背景色 カラーコミュニケーションガイド 色を正しく伝えるために 色色雑学-楽しく学べる知恵袋 | コニカミノルタ 情報科学講義資料 - グラフィックス colour: A model for human colour/color perception | Hackage エディタの文字色に悩む日々 - CIELCH - そんなこと覚えてない

no_picture

PostGIS関連でRailsの本番環境でエラー

PostGIS 開発環境ではおきないのだけど、pointを作ろうとしてエラーが起きる。 NoMethodError (undefined method `point' for #<Proc:0x000000038dde90>) 見事に下記の通りだった。 https://github.com/rgeo/activerecord-postgis-adapter/issues/63 self.lonlat = Pin.rgeo_factory_for_column(:latlon).point(self.longitude, self.latitude) だったのを self.lonlat = Pin.rgeo_factory_for_column(:latlon, {}).point(self.longitude, self.latitude) に書き換え。rgeo_factory_for_columnの第2引数に {}を加えた。

no_picture

PostGISを試してみる

緯度経度って奴をDBにいれる。 PostgresならPostGISって奴があるらしい。 とりあえずローカルで試す。 brew install postgresql brew install postgis データベースを作る createdb postgis_sample psql -d postgis_sample -c "CREATE EXTENSION postgis;" CREATE EXTENSION postgis; すれば postgis が使えるらしい。 八丁堀から510ビルまでの距離を求めてみる。 $ psql -d postgis_sample -c "SELECT ST_Distance(ST_GeographyFromText('Point(132.463495 34.393817)'), ST_GeographyFromText('Point(132.468527 34.393366)'));" st_distance --------------- 465.421862299 ST_Distanceで距離を算出できる。 テーブルをつくってみる。 CREATE table places ( name VARCHAR(255),geog GEOGRAPHY(Point)); INSERT INTO places VALUES ('ShakeHands', 'POINT(132.458767 34.394010)'); INSERT INTO places VALUES ('MOVIN''ON', 'POINT(132.465314 34.393052)'); シャレオ中央からの距離を求めてみる。 > SELECT name, ST_Distance(geog, ST_GeographyFromText('POINT(132.457589 34.395300)')) FROM

no_picture

VagrantでX転送

以下をかいておけばよい。 config.ssh.forward_x11 = true あとは普通にvagrant sshして、Xクライアントを動かせばよい。 サーバ側にある程度必要なライブラリがない場合はディスプレイがないと言われてしまう。 CentOSなら以下をいれとくとよい。 yum -y groupinstall "X Window System" vlgothic-fonts

no_picture

広島で使われるゆるい言葉 - ゆるい広島 Advent Calendar 2014

この記事はゆるい広島 Advent Calendar 2014の7日目の記事です。昨日はToro_kunさんのLT駆動開発というゆるい勉強会でCreative Commons LicenseについてゆるくLTしてきた – ゆるい広島 Advent Calendar 2014 8日目でした。 広島とか言いつつ、僕のまわりで使われているだけど、ゆるい言葉を紹介する。 これらの言葉を知っていると広島の人とのコミュニケーションはとてもスムーズになるかもしれません。 完全にネタ記事です。 期待して読まないでください。 ごろごろ ごろごろは、だらだらごろごろしている状態を示す言葉です。 疲れたときや暇なときによく使われます。ごろごろ…。 とりあえず、困ったらごろごろしましょう。ごろごろー。 別にお腹の調子が悪いわけではないです。(ごろ 実際に言葉にする用途よりもチャットで使われていることが多いです。 GitHubのコメント欄などで使用しましょう。 またあした 「またあした」は別れの挨拶としてよく使われます。 「またあしたも会えたらいいね」の略で使用されています。 非常によく使われているゆる語です。 実際に明日も会う可能性がある場合は派生系の「またきょう」や「また来年」などが使用されます。 GitHubを使うための集まりの別れの挨拶としては定番化しています。 もっと流行らせましょう。 また、あした。 - よく使う言葉 しらんけど 困っている人がいるときに、ちゃんと調べていないがなんとなく知ることを相手に伝える場合に、ちゃんと調べずに回答していることを伝えるための魔法の言葉です。 ちゃんと調べていると反応が遅くなってしますので、この言葉を使えばショートカットすることができます。 使われ方が非常にゆるいです。 人間はあまり間違ったことを言いたくないらしく、困っている人を助けられないシーンが見られるために登場した非常に便利な言葉です。 あまり使いするぎると、オフラインで喋ることすべての語尾に勝手につけられて、あなたの発言の信憑性が著しく下がる場合があります。 気をつけましょう。 ぎっとはぶ 広島だけでなく日本全国…いや、世界で利用されているゆるい言葉です。 知らないと非常に困ることになります。 派生語としては「おくときゃっと」とかがあります。 そうです。広島のみんなはソーシャルコーディングをしているんです。 オチはない。

no_picture

Lispインタープリタ勉強会に参加したので - LT駆動開発09

LT駆動開発09でLTをした。 Lispインタープリタ勉強会に参加したのでLispを実装しなければいけない気がしたので、勉強したことを参考に作成しはじめてみた。 インタプリタと書くか、インタープリターと書くか、インタープリタと書くかブレまくっていたのは秘密である。 書いたコードはGistにあるんだ。 Gist - Lisp インタープリタ勉強で学んだことを試した。 勉強会でlesson0として、用意してあったJavaScriptのコードを参考にした。 これは四則演算がすることができて、 JavaScriptの配列リテラルを使ってLISPのコードをかく。 この配列を評価できる評価機をつくる。 配列リテラルを評価したものが、それ自身がASTなので割と簡単にLISPの評価機が作れる。 ASTなんだけどLispのプログラムのように見えるからLispをつくった気分になる。 そのスタート部分を作成しただけである。 といいつつも、和しか実装していない。 しかし、Haskellのリストは同じ型の値しかリストには入れなれないので実際リストで書いてみると、値をつくる必要があり、LISP感は下がる。やはりパーサを書かねばならないのである。 やることはそんなに難しくないし、手を動かしてみると学ぶことはたくさんある。 勉強会に参加したかどうかはおいておいて、自分だけのLISPを作るべきである。 HaskellでLISPを作るなら良さ気な文献があるのでそちらをやるのもよい。 48時間でSchemeを書こう - Wikibooks

no_picture

LT駆動開発09で「Vagrantを使ったa-blog CMSの環境で思ったことを話した

LT駆動開発09でLTをした。 ちょっと前にa-blog CMSの作業環境をVagrantで作成したのでその時に思ったことを話しただけである。 おまけでVagrantについての解説をしたがきっと必要のない情報だろう。中身がない。 Vagrantは簡単に開発環境を作成するツールらしいです。 Vagrantfileがあれば環境が何度でも構築できるのがポイントだろう。 あと設定が楽チンである。 a-blog CMSをchefでインストールするにはogom/cookbook-acmsをいじったものを使用している。 いじったものは公開していなくてさーせん。 どんな問題があったかというとローカルで編集したファイルが全然反映されない問題がおきてつらかった。 あとは他の人がプロジェクトをクローンしてvagrant upしても実行できない問題がおきた。 それについて説明しただけである。 というわけで、作業用のコードとCMSのコードは分離して配置できるといい気がするという話をしただけである。 a-blog CMS だと config.server.php でテーマディレクトリ位置は変えられるようなのでうまく使うと良さそうだと気づいが次に使う機会がない限りにそのままである。 中身がない。 ついでにVagrantのBOXはVagrant Cloudのものを使いたいけど、bentoで作成されているBOXを使いたいという話をした。

no_picture

ぶらりと飲み物を買いにいくついでに写真をとってきた - ゆるい広島 Advent Calendar 2014

ゆるい広島 Advent Calendar 2014の6日目の記事です。 昨日はあかぎたかしさん の a-blog cms DAY Hiroshima というゆるい勉強会を紹介するでした。 このアドベントカレンダーは広島をテーマに好きなことを書いていいらしいです。 というわけで、広島の写真を撮影してきました。広島っぽさは全くありません。 使用したカメラはRICOH GRさんです。 16時を過ぎていたので、なるべく場所が特定されないように露出を高めにして、逆光で撮影した写真が多いです。 ちなみにカメラは1ヶ月前ぐらいからはじめた初心者です。 Flickrで見る あらためてみるとピントが残念なのがいくつかある…。 明日は誰なのか知らない。 また意味のない記事を書いてしまった。

no_picture

すごい広島 x IBM - クラウド交流会でゆるくすごい広島の紹介した。 - ゆるい広島 Advent Calendar 2014

一応、ゆるい広島 Advent Calendar 2014の三日目の記事になります。 12月1日のお昼にIBM Cloud Exchange 2014の広島が開催されておりましたが、その夜にひっそりとすごい広島 x IBM - クラウド座談会が開催されました。 すごい広島という弱小コミュニティがIBMさまといったいどんな交流をしたらいいのかよくわかりませんが、ここは弱小なことは気にせず、対等な振りをして対等なつもりでいつもどおりすごい広島の紹介をしてきました。 なるべくゆるくいこうとはじめからおもっていたので、「すごい広島っていうのはー」という、すごいゆるいタイトルをつけてみました。 まとめると、すごい広島は、すごい人を集めるのが目的のようです。 すごい広島の話はもう何度もしていますが、IBMの方たちを対象にしたとき、なにをしたいコミュニティなのか改めてブレストをして臨みました。 そうすると普段のすごい広島の参加者から、「そんな目的が!」なんて声が聞こえました。 なんとなく新しいスライドをつくった甲斐がありました。 あとあと、SoftLayerユーザ会 広島支部を作りたいそうです。 支部長希望者探しているようです。主に女性。 少し脱線しますが、今回挑戦したことは自分が撮影した写真を使うというところでした。 ちなみに、使用しているカメラはRICOH GRです。 たぶん高級コンパクトデジタルカメラに分類されるカメラで、起動がはやく気軽に撮影できて、ミラーレスと同等のセンサーサイズを備えるなかなか素敵なカメラです。 このカメラの素晴しいのはレンズ沼にはまらないということがあります。 低価格帯のミラーレスの少し触らせてもらっいましたが、良いカメラを買ったと感じております。 でも、フルサイズの一眼レフ欲しくなるので、沼には確実に近づいていますね。 閑話休題。 コミュニティを運営することに関しては、わりと無欲におこなって継続できるペースで続けるのがいいかなとなんとく改めて思いました。 継続することから産まれるリターンが計ることができないように思います。 「だからこそ、企業との対話、連携に価値が産まれるのかな」なんて思いました。 お互いにとって価値のあることがもっとできるようになるといいですね。

no_picture

LT駆動開発というゆるいIT勉強会を紹介する - ゆるい広島 Advent Calendar 2014

この記事はゆるい広島 Advent Calendar 2014の1日目の記事です。このアドベントカレンダーは広島をテーマに好きなことを書いていいらしいアドベントカレンダーです。 広島にはLT駆動開発というゆるめのIT勉強会があります。 IT勉強会の形式には セミナー形式 ハンズオン形式 アンカンファレンス形式 などなどがありますが、LT駆動開発はセミナー形式になります。 LT駆動開発はライトニングトークと呼ばれる5分から10分程度の短いセッションで構成され、10人程度の発表があります。 LTはライトニングトークの略で、「LTを毎月やるつもりで普段の開発(仕事)をしよう」という勉強会になります。 セミナー形式は普通は参加対象者をしっかり定めて、スピーカーが参加者に価値のある情報を提供するのが一般的ですが、このLT駆動開発では、スピーカーになることに重点を置いています。 そのため、参加対象者は曖昧となっています。 セミナー形式の勉強会で、聴衆はたいていの場合、内容のすべてを理解することはできません。 そして、聞いたことを実践できる人はほとんどいないと思われます。 しかし、スピーカーは喋ることを理解した上で伝える方法を準備してきているのです。 スピーカーになるということは喋る内容をより理解できるということなのです。 これを利用して、喋ることで学んだことをより理解を深めるのがLT駆動開発なのです。 スピーカーは参加対象者は自由に決めることができるし、喋る内容も自由に決めることができるし、発表者する時間ほ長くなければ自由に決めることができるというとてもゆるいIT勉強会なのです。 ライトニングトークを行うイベントはたいてい時間制限がきっちりしていて、ドラが鳴らされて発表が打ち切りになりますが、このLT駆動開発ではぐだぐだに継続することができます。 やはりゆるいですね。 これまでのLT駆動開発の8回行われています。 その中からいくつか公開されているスライドをゆるく紹介したいと思います。 これまでのLT駆動開発 これまでのLT駆動開発のはWikiに整理されています。ここで紹介しないものはそっちからみてください。 ワイヤレスディスプレイをつかってみよう! ワイヤレスディスプレイをつかってみよう! from Yoshitake Takata 無線で画面を飛ばせる。最近はおもしろいものがありますね。 #### コーチングから学んだこと コーチングから学んだこと from Yuri Kamimori おれたちのLT駆動はまだはじまったばかりだ。 自分がどんなタイプなのか、一緒に仕事する人はどんなタイプなのか。 #### LT駆動開発03 Web制作をカレー作りで例えてみる LT駆動開発03 Web制作をカレー作りで例えてみる from Kawakami Hiroko すべてはカレー作りに通ずる。 #### 原典にあたったら英語も勉強できた話 〜 Git編 〜 原典にあたったら英語も勉強できた話 〜 Git編 〜 from Yukinori Kitadai 名作スライド #とは。 #### Twitterのスパムアカウントを考察する Twitterのスパムアカウントを考察する [LTDD 01] from nemumu

no_picture

内包表記について、すごい合同勉強会で話した

すごい合同勉強会2014 in 広島でセッションしたので内容を公開しておく。 今回は「私がモナドの内包表記という名前を知った時の感覚を伝えよう」というのが目的でした。 さりげなく「私がモナドに感じている効能を伝える」というのもしているのですが、そこは本当にさりげなく。 内包表記。その意味を知らずに5年前ぐらいにpythonで利用していて、forやif文字通りにうけとっており、その動作を正しく理解できてないときがありました。 現在とその間にHaskellを学び、その5年前の自分に内包表記を伝えるにはという観点で話を進めました。 まず、リストの内包表記ですが、リストを生成を簡単にしてくれる機能です。 内包表記は、どうやら数学の集合の記法である内包的記法に由来するそうで、「関数プログラミング入門 ―Haskellで学ぶ原理と技法―」か何かで読んだ記憶があります。 その対になる記法として外延的記法があります。 これは具体的な中身を列挙する方法で、普段のリテラル表記ともみなすことができます。 リテラルで地道にかくのではなく、てプログラミングで自動生成しようというのが内包表記と言えそうです。 Haskellの内包表記は ジェネレータとガードと呼ばれる真偽値を並べることで作成します。 x <- [1..9] の部分がジェネレータです。あと真偽値を返す式がガードになります。 参考 3 Expressions - Haskell 2010 pythonではジェネレータとガードが for と if で表現されています。 直感的だし、キーワードの使いまわしとも言えそうです。 (関係ないけど、C++はキーワードの使いまわしたいへんそうだなぁって思った) あとはジェネレータを並べた際にどうなるか、というのがわかればリストの内包表記はうまく使えるのではないかと思います。 直積をとる。つまり、全部のパターンをつくる。 あとはフィルタで、致しているものを求めるだけですね。 そういえば、リストモナドでできることですね。複数答えがある場合にリストモナドを使うとすべての回答が得られます。 よく内包表記がmapやfilterと比較されることがありますが、そもそも同一に扱っても面白いことは特にない気がします。 目的しだいではmapやfilterを使うより便利だと考えてよいと思います。 蛇足ですが、モナドの有効性として、コードが斜めに述びる性質がある際に真っ直ぐに伸ばすことができるみたいなイメージを持っています。 それをさりげなく言っていたのですが、後ではなださんのセッションで実例がでてきました。 さて、ここまでくると内包表記とSQLの類似性が簡単に説明できるし、具体例にしやすいので、SQLと絡めた話をしました。 あとはモナドの内包表記へと一般化する話です。具体例のリストから、Maybeへと繋ぎ一般化して終わりです。 Rubyの例でflattenしている部分がありますが、あの辺はリストモナドがいつも勝手にやってくれてるところで、さりげなく強調していたりしますね。 モナドはなんか怖いとか言われますが、それはさておいて内包表記は便利なので知っておいて損はないと思います。 会場はわりとポカーンとしていましたが「誰かの何かに役に立てばいいなぁ」ということでスライドと簡単な解説を残しておきます。 登場したコード コピペしやすいように置いておきます。 主に対話環境用に。 Haskell [(x,y) | x <- [1..9], y <- [1..9], x * y == 24] [(x,y,z) | x <- [1..9], y <- [1..9], z <- [1..9], x * y * z == 24] :set -XTransformListComp [ (x,y) | x <- [1..9], y <- [1..9], x * y == 24, then take 2] :set -XTransformListComp :m GHC.Exts [ (x,y) | x <- [1..9], y <- [1..9], x * y == 24, then sortWith by y] :set -XMonadComprehensions [ (x,y) | x <- Just 3, y <- Just 8, x * y == 24] Python [(x,y) for x in range(1,10) for y in range(1,10) if x * y == 24] Ruby [*1..9].map do |x| [*1..9].map do |y| [x,y] end end.flatten(1).select do |x,y| x * y == 24 end [*1..9].map do |x| [*1..9].map do |y| [*1..9].map do |z| [x,y,z] end end end.flatten(2).select do |x,y,z| x * y * z == 24 end [*1..9].product([*1..9],[*1..9]).select do |x,y,z| x * y * z == 24 end SQL SELECT x,y FROM generate_series(1,9) AS X, generate_series(1,9) AS Y WHERE x * y = 24; SELECT x,y,z FROM generate_series(1,9) AS X, generate_series(1,9) AS Y, generate_series(1,9) AS Z WHERE x * y * z = 24; 参考文献 内包と外延 - Wikipedia 内包的記法の出展 - 集合 - Wikipedia 5.

no_picture

すごい合同勉強会2014 in 広島を開催した

すごい合同勉強会2014 in 広島を開催しました。 開催したといっていいのだろうか? この勉強会は広島市立大学の大学祭にあたる市大祭の出し物として行われました。 主催は広島市立大学 プログラミング同好会です。 といっても、広島で毎月行われているLT駆動開発の年に一度の大型バージョンという側面もあります。 でっかいLT駆動開発です。 いつもより大きいだけあって、いつもの参加者も少しだけ長い時間を喋っていてボリュームのあるものになったと思います。 学生や学校と交流できたこともよかったと思います。 学祭と被っているため懇親会に参加できる学生が少ないのはとても残念でした。 しかも、プログラミング同好会を巻き込んだだけのLT駆動開発ではなくて、江添さんとはなださんがいらっしゃっいました。 イベントのメンバーは固定化がおきていて、今回は特に県外から別の文化が届くのはとても大切だと感じました。 とても大きな刺激になりました。 お二人が参加されるきっかけができたことには本当に感謝しています。 この規模だと、県外からの参加もあったりするのもとてもよいです。 県外は岡山や山口にいく程度ですが、九州や関西にも足を運ぶようにしたいと改めて思いました。 「これだけは行っとけ」というイベントがあれば教えて欲しいです。 Ruby World Cunference にいければいいんだけど日程的に無理である。 イベントを行うのは、参加者の貴重な時間を使うことになります。 イベントが大きいものになればなるほど不安も大きくなります。 そんな中で思ったのは、参加者が受け身にならないように自発的に動いていきたくなるような空気感をつくるのが、参加者も運営者もメリットになるものになるのではないかとさっき考えたりもしました。 結局はみんなが協力していて、さりげなく支えてくれてる人がいて成立しているものだと思いました。 本当にありがとう。 発表することのメリットを私自身がしっかり享受して、広島がITエンジニアにとってもっと楽しい街になると良いと思っています。 ただし、私の定義する広島は広いぞ。#知らんけど それでは、また来年(あした) 関連リンク 内包表記についてすごい合同勉強会で話した

no_picture

nodejsのモジュールをブラウザで使えるようにするbrowserifyでちょっと遊んだ

Browserifyで少し遊んだ。 npmにあるライブラリをクライアントサイドで使いたいなぁ、という時に便利な子がBrowserifyさんです。 HTML側に複数のscriptタグを書かなくてよくなり、<script src="bundle.js"></script>のみ記述しておけば良いので管理が楽です。 (当然bundle.js以外の名前にすることもできます) requirejsの代わりに使うこともできるし、gulpやらを組み合わせてminifyなどもできるでしょう。 とりあえず試すには QUERY_STRINGをクライアントサイドで処理するのを試した。 ライブラリにはqsを利用。 nodejsをインストール npm install -g browserify npm install qs qsを使うコードをかく browserfyを実行 生成されたjsを使う nodejsのインストールは省略。 browserifyコマンドを利用するためにnpm intsall -g browseriyする。 今回はqsを使うのでnpm install qs をする。 以下のコードはmain.jsに書いた。 var qs = require('qs'); console.log(qs.parse('aaa=bbb&ccc=ddd')); 出力は以下のようになった。 { aaa: 'bbb', ccc: 'ddd' } これをブラウザ上でもうごくようにするためにbrowserifyを使う。 以下のコマンドでbundle.jsを作成する。 $ browserify main.js -o bundle.js qsの中身をbundle.jsの中に加えてrequireを使える状態にもなってるらしいけど確認してない。 index.htmlを作成してブラウザで開くとコンソールで開いてみると同じ出力がでている。 <html> <head> </head> <body> <script src="bundle.js"></script> </body> </html> もうちょっとちゃんとQUERY_STRINGを解析してみる さっきのは固定値だったので、ちゃんとURLから取得する。 location.searchの値を使った。 main.js を以下のようにして、HTML上にも表示した。 var qs = require('qs'); var queryString

no_picture

Macで open . が失敗する

open .をしようとしたら LSOpenURLsWithRole() failedが発生した。 $ open . LSOpenURLsWithRole() failed with error -600 for the file tmux のペインを全部消して開きなおしたら治った。 参考文献 osx - open Safari and Finder failed in tmux - Super User

no_picture

最近のMacでRubyのビルドに失敗するなら brew unlink apple-gcc42とかしたらいいかもしれない

友人のMacでRubyのインストールに失敗するらしいということでログとかいろいろみせてもらった。 結果だけいうと $ brew unlink apple-gcc42 を実行してもらったらなおった。 もっと詳しく rbenv と ruby-build をつかっているっぽくてログファイルを渡してもらった。 ログは失敗したときにここにあるよ。的なのが端末にでているはずだ。 たぶん、/var/folders/XXXXXXXXXXXXXXXXXX/ruby-build.20141014143529.76588.logみたいな感じになっている。 それを詳しい人に渡してきくようにするといいと思う。 中身をみたら ./configure で失敗していたので config.log をみせてもらった。 そしたら configure:3064: result: x86_64-apple-darwin13.4.0 configure:3335: checking for gcc-4.2 configure:3351: found /usr/local/bin/gcc-4.2 configure:3362: result: gcc-4.2 となってて Target: i686-apple-darwin11 となってて ld: library not found for -lcrt1.10.6.o collect2: ld returned 1 exit status なってた。 ターゲットが x86_64-apple-darwin13 になってないのがなんか嫌だなと思いつつ、事例が「rbenvで ruby インストールエラー (OS X mavericks) - QA@IT」に似ているので、 sudo ln -sf /usr/bin/llvm-gcc-4.2 /usr/bin/gcc-4.2 で解決すること的なことが書いてあるけどなんか嫌だなぁってことで、そもそもなんで/usr/local/binにgcc-4.2があるねん、ということで ls -l /usr/local/bin

no_picture

LT駆動開発08でHiroshima.rbをふりかえった

LT駆動開発08で活動が不定期になるHiroshima.rbについてふりかえった。 Hiroshima.rbがリアルでのイベントを中止するらしいので、Hiroshima.rbについてふりかえることにした。 結局、Hiroshima.rbなんて毎日楽しく生きられるようにするためにはじめたものらしい。 そもそも、広島Ruby勉強会からRubyっていうテーマを外しただけのものがLT駆動開発で、Hiroshima.rbの活動がなくなる。 それもどうなのかって思ったので、月に二回集まる時間をつくっただけである。 集まるだけのイベントはすごい広島があるのであり、負担になってるなら休止するだけなのである。 あと、およそ5年間の思い出を何か話したはずだが記憶にない。 まあ、なにかRubyのイベントときどきしたらいい。 私がしてもよいし、誰か別の人でもよい。 それでは、また、あした。 読む必要ないネタの解説 ネタに解説はいらない。 「生きているよりマシさ」ここ最近よく聞いている曲で、タイトルほどネガティブじゃなくて、「生きているほうがマシさ」なんじゃないかと勘違いするという話をした。実にどうでもいい。 この曲が好きな人たぶんこのフレーズが好きな人が多いでないかと思う。 君と居られたのが嬉しい 間違いだったけど嬉しい 会えないのはちょっと寂しい 誰かの君になってもいい嬉しい 解釈の仕方は自由だけど、人によっては、「君」をどんな人に当て入めても合うんじゃないだろうかなぁ。 もう絶対会えない人がいて、その人にすごく感謝していたら、自分がしてもらったことを誰かにしたい。 そんな風に感じている。 間違いだと思うのは、だいたいその人の主観による勘違いなのだけど、自覚しているのもやっぱり好きである。 何が言いたいかと言うと、「嬉しいとおもったことは連鎖したら良いな」と思う。 Hiroshima.rbに感謝している人がいるのであれば、似たようなことをする人が出てくるんじゃないかと思う。 関係はないが、「死んでいる方がマシさ」とは歌うが、「死んだ方がマシさ」なんて一言も言ってない。 そんな曖昧さに「生きたい」と思うかどうかは人それぞれなのであるような気がしているが、なんか、「だけど、生きようかな」って次の句を繋ぎたくなるのである。 まあ、目立たないように生きたいのは正直な気持ちである。(ておくれ)

no_picture

LT駆動開発08でWerckerのBOXの作り方の流れを軽く説明した

LT駆動開発08でWerckerのBOXの作り方を本当に軽く説明した。 本当は図を用意したかった。 何が話したかったかというとWerckerはboxなりstepなり自分でつくれるけど、それはGitHubなどに公開してWerckerでCIするとWerckerづ使えるようになるという循環している話がしたかった。 一言で言うと、CIで使うためにCIをする。 BOXをつくっていて容量制限にひっかかったの懐しい思い出です。 BOXやSTEPを作ること自体はシンプルなものでいいので一度やってみると面白いと思います。

no_picture

ChatworkをOperaで使うのはやめといたほうがいい。

ずっとOperaでChatworkをつかっていた。 通知が微妙だなぁって思ってた。 Chromeで開いてみてみた。 不満に思うことがおきなかった。 Chromeでひらくべきだとおもった。 そもそも僕はひらきっぱなしにしたいサイトはOperaで開いている。 デフォでタブが固定できるのが主な理由で、あとは開きっぱなしのものは閲覧用のブラウザと分離したいからだ。 なので、Operaでちゃっと動いてくれると実はすごく嬉しい。 Operaで開いていてよく困るのが通知音がしないことが多いことだ。 特に開いているチャットは通知音がならない。 フォーカス管理まわりの挙動が違うんじゃないかと思う。 こんなことしてる人はあまりいないと思うけど、記録に残すことにした。

no_picture

hiroshima.rbを休止することに決めた話

Hiroshima.rbの活動を休止しようと思います。 すでに立ててしまっているHiroshima.rb #055を区切りにしたいと思いますが、 すごい合同勉強会があるのでそこが最後の活動になると思います。 理由は僕自身ががんばるための、根本的なモチベーションを失なってしまったからです。 すごい広島の縮小も検討しています。 オフラインのすごい広島は月1ぐらいにしようかなと思っています。 エア参加オンリー化とか。 一応、Hiroshima.rbを引き継ぎをしたい人は募集したいと思います。 気軽にご連絡ください。 さまざまな権限をお渡しします。 そもそも現在、僕が主体となり、運営したり、主催しているものは すごい広島 LT駆動開発 Hiroshima.rb CSS Nite in HIROSHIMA, Vol.8 すごい合同勉強会 があります。 お手伝いしているものとしては オープンセミナー2015@広島 - 会計 日本Androidの会 中国支部 - ウェブ担当? WEB TOUCH MEETING - サポート 中国地方DB勉強会 - 開催地が広島の場合のサポート&ウェブ などがあります。 正直にいうと一番つらいのはCSS Niteで、参加者からお金を集めるイベントなので、委員長からの引き継ぎもなく、いままで見てきた知識で指揮を取っていてつらいです。 このイベントを7回も行なった藤本さんは本当に素晴しいと思います。 しかも、WEB TOUCH MEETINGを継続している。 マジ半端ない。 つまり、僕自身が完全にキャパシティオーバーなのです。 心臓の病気で、身体障がい者3級なのだけど、体力が他の人よりなくてもこれぐらいはがんばれるというのは示せたと思います。 ただし、実質無職のようなフリーランスで、時間を自由に使えたからでもあると思います。 オープンセミナー2015が終わるまでは一息つけそうにないですが、なんとかやっていきたいと思います。 もしこれから勉強会をやってみようと思う人がいたら積極的にサポートしていきたいと思います。 もっと詳しく 以下は読みたい人だけどうぞ。 きっかけの根本を辿ると恋人ができたことです。 恋人を充分に大切にしつつ、コミュニティ活動するには僕は手を広げすぎました。 そもそも前提として「恋人ができることを諦めた」ということではじめることができたのが「すごい広島」や「LT駆動開発」でした。 だから、3ヶ月ほど前からコミュニティ活動を縮小することを考えていました。 家族がいて、子供がいて、勉強会に参加する人は本当にすごいなと学ぶことができました。主催する人は本当に半端ない。@soudai1025とかマジすごい。 ただ、付き合いはじめて、コミュニティ活動を縮小するのは止めて欲しいという要望があったので、どこまでがんばれるか試してからにしようと考えていました。 結果、がんばることで生じた無理はどこかに存在してしまっていて、今回いろいろ諦めようと思いました。 継続するためには無理しないことが大切です。そして、継続できるように維持することが大切です。 僕自身は人前に出るのはとてもとても苦手で、大人数の前で話した後は自己嫌悪がすごいです。 人前で話すのは、だいぶ馴れたと思ってたのですが、オープンソースカンファレンスからのWEB TOUCH MEETINGの後はとてもつらかったです。 オープンソースカンファレンス2014広島 - LT駆動開発 ベストセッションズ 凪のライトニングトーク

no_picture

RubyでFacebookのコメントに写真を投稿する

FacebookのGraph APIをさわった。コメントを自動でしたかったからだ。 RubyでFacebook Graph APIをたたくにはサードパーティなgemを使うのでいろいろい種類がある。今回はkoalaを使用した。 コメントに関するAPIの仕様はここに書いてある require 'kola' object_id = "OBJECT_ID" file_path = "FILE_PATH" oauth_access_token = "ACCESS_TOKEN" file = Koala::UploadableIO.new(file_path) graph = Koala::Facebook::API.new(oauth_access_token) graph.put_object(object_id,"comments", source: file) で、投稿できる。graph.put_comment というメソッドがあるが、ファイルがわたせない。コメントしたいだけならこれで充分。 object_id が必要になる。 てっとり早い方法はブラウザでコメントしたいポストを開いたらURLに書いてある数字がobject_idである。 画像はsourceに指定するが Koala::UploadableIOで開いておく。 またoauth_tokenが必要になる。 Graph API Explorer(アクセスにはログインしている必要がありそう)``から作成できる。たぶん1、2時間しかつかえないはず。(ちゃんと調べてない) 権限は user_photos publish_actions が最低必要で、書き込みする場所によって対応したものが必要。 user_status user_groups などなど。必要に応じて追加する。 user_photosをつけてなくて3時間ぐらい悩んだのはただの愚痴。 ついでにRestClientで送りつける場合の方法 require 'rest_client' url = "https://graph.facebook.com/v2.1/#{object_id}/comments?oauth_token=" + oauth_access_token RestClient.post(url, "source" => open("/Users/eiel/Desktop/hoge.png")) 参考文献 Ruby: How to post a file via HTTP as multipart/form-data? - Stack

no_picture

re: Rails update時に値を変更して更新したい

友人のブログ記事へのレスです。 JunkBox~主に個人的防備録~: Rails update時に値を変更して更新したい。について。 さすがにやってることがまわりくどい。コメント欄だと返信がつらいのでここにかく。 まず、元の内容を引用します。 たとえば、保存時10円単位で四捨五入して保存したい場合。 ついでに登録日を1日ずらす。 日付型の項目は、年、月、日、時、分、秒と別れてパラメタに入ってくるので、扱いづらい。ので、一旦モデルに突っ込んで処理し、その後ハッシュに変換する。 def update # パラメタを一旦モデルに突っ込む tmp = Syohin.new(syohin_params) # 金額を10円単位で丸める tmp.kingaku = tmp.kingaku.round(-1) # 日付型の登録日を1日ずらす。 tmp.record_datetime = tmp.record_datetime + (60 * 60 * 24) # モデルをハッシュに変換する。 tmp2 = tmp.attributes # 不要なキーを削除 ["id","created_at","updated_at"].each do |key| tmp2.delete(key) end #updateに突っ込む respond_to do |format| if @syohin.update(tmp2) format.html { redirect_to @syohin, notice: '更新完了' } else format.html { render :edit } end end end わざわざ一時的な新しいモデルをつくっているけど、updateメソッドのsaveしなバージョンのメソッドがある。assign_attributesメソッドである。 def update @syohin.assign_attributes(syohin_params)

no_picture

すごいHirohsimaの本について、OSC2014とWTM71で紹介した

すごい広島を紹介するための書籍(通称、薄い本)である、すごいHiroshimaの本というものを作成しました。 作成した主の目的はオープンソースカンファレンスで展示をするためです。 作成した電子書籍はすごいHiroshimaの本置場というところに置いています。 ePubとPDFを提供しています。 OSC2014広島編 せっかく電子書籍を作ったので、興味をもってもらうために、オープンソースカンファレンス2014広島のLT駆動開発 ベストセッションズ – 凪のライトニングトークの中でライトニングトークをしました。 題して、すごいHirohsimaの本のここがヒドいです。 少し、補足。 しつこいですが、我馬は広島のラーメン屋です。博多ラーメンを提供します。 私とすごい広島の章は実際には4人しか書いていません。 一人で5役している人がいます。誰やねん。あ、でも一役は入れ替わる可能性も。 第71回 WEB TOUCH MEETING OSC2014広島と同日に行なわれたWEB TOUCH MEETING 71で、Web製作者向けにこの書籍をつくるのに利用技術がどんなものなのか、すごい速さでざっくりと紹介しました。 対象者をWebの初心者にすればよかったと少し反省しております。 速さ自体はやや意図的にやった部分はあるのですが、いろんな参加者がいて真ん中あたりの人を対象にしてしまった感じがあります。 よくわからないけど、キーワードをひろってもらったりしてもらえた良いかなぁ。という感じでつくりました。 それよりも図はもっとがんばらなければ。 スライドは前半のすごいHiroshimaの本のここがヒドいの部分はカットしてアップロードしています。 そして補足。 電子書籍をつくるためにはRe:VIEWを利用しました。はじめて挑戦する場合はクイックスタートガイドを読めば良いと思います。 Re:VIEWは電子書籍をつくりたい場合でも、技術書を書きたい人向けのものっぽいです。プログラミングなどをしてない人には少し扱うのが難しいかもしれません。 ただ、環境さえ用意できれば、使うこと自体はは難しくはないと思います。 書くだけとかなら。 本の中でグラフをかくのに今回gnuplotを利用しました。 gnuplotは理系の学生であれば利用したことが多いと思われるグラフ作成ツールです。コマンドラインから利用します。 Re:VIEWではgnuplotのコマンドを書く方法が用意されていて、PDFに変換する時はPDF用の画像をつくってくれて、ePubに変換する時はePub用に画像をつくってくれます。 ありがたい。 この本をつくるにあたって、最初にしたことは、ePubとPDFに変換する部分を自動化したことです。 もし途中で執筆に誰かが参加しようと思った時に作成されるものをわかりやすくしたり、本が生成されてるところを見せて、興味をもってもらおうと思ったというのが主な目的です。 他にも執筆に集中してしまって、いざePubやPDFに変換する際にトラブルで間に合わないという自体を避けるなどの理由もあります。 実際に文字化けとかグラフが生成されなかったり、予期していなかったエラーを事前に発見することができました。 Octokitは付録の「すごい広島の統計情報」「すごい広島の参加者」を作成するために、利用しています。すごい広島のサイトの情報がおいてあるGitHubのリポジトリgreat-h.github.ioから情報を取得して、gnuplot用のCSVを作成したり、Re:VIEWの.reファイル内に挿入する文字列を作成しています。 Octokitを使った例として、GitHub戦闘力があります。(GitHub戦闘力が完全にこれを作るときの副産物である) 蛇足ですが、この電子書籍には他にも最新の情報を取得して、更新している部分がいくつかあります。 コミットの数なんかは随時変化していくので、ePubやPDFを作成する際に最新情報を使うようにしています。 対象読者に対して説明不足になってしまうのですが、この電子書籍はgit pushしたら自動生成するようにしています。 これを実現しているのがCIサーバで今回利用したサービスがWercerです。 CIサーバでできることは結局は自分のコンピュータできることと基本的に同じです。 しかし、CIサーバを使うと基本的にクリーンな状態でePubやPDFを作成することができます。 これがどんな時に嬉しいかというと、執筆者が増えた時に、ePubやPDFをつくるのに、自分が追加し忘れたファイルがないことを保証できます。 (一部のファイルがキャッシュされたりはじますが…) また、ePubやPDFを生成するための手順をコードに落とす必要がでるため、作成方法が明確なります。 こういったことを早めにやっておくと、本を作成するための全体像を把握しやすくなります。 Werckerを使う際にRe:VIEWを使うための仮想マシン(box)も作成しました。 この詳しい話は今回割愛しますが、リポジトリは晒しておきます。 eiel/wercker-box-review Werckerで作成したePubやPDFはAmazon S3へアップロードしています。 作成したファイルはtmp/great-h-book-[バージョン番号]というファイル名にして保存しています。 これらのファイルは1週間たつと削除されるようにしています。こちらはAmazon S3の機能です。 ただ、masterブランチものをCIサーバに動かした場合は、great-h-bookというファイル名にして、消えないようにしてあります。 (厳密にはファイル名はオブジェクト名ですが…) Amazon S3はとても安価で信頼性も高いので、最近、成果物はなるべくS3におくようにしています。特に変更がもうないものを置くのが良いと思います。 最後に、ePubやPDFが生成されたことがみんなに伝わらないと意味がないので、Twitterに流すようにしています。この時にユニークなハッシュタグをつけるようにしています。 夜フクロウは特定のキーワードを含むツイートを音声つきで通知する機能があるので、これも使ってます。 とても便利です。 継続的デリバリなんて言葉を使いましたが、みんなで一緒になって何かをつくるときはみんが嬉しくなるようにやるのが大切だと思います。 書く人も、確認する人も、作りたい人も、読む人もみんなチームだよね。

no_picture

オープンソースカンファレンス2014広島 - LT駆動開発 ベストセッションズ 凪のライトニングトーク

オープンソースカンファレンス2014広島のLT駆動開発 ベストセッションズ – 凪のライトニングトークの中でライトニングトークをしてきました。 今回はLT駆動開発の説明を担当させていただきました。 LT駆動開発の説明もしましたが、LT駆動開発の中でよくあることを紹介しました。 以下補足 LT駆動の説明をする人を毎回変えるようにしているのは、参加主旨をみんなに考えて欲しいからです。 我馬は広島のラーメン屋です。博多ラーメンを提供しています。 その他のLTについても随時公開される予定です。 詳しくはこちら また、来月のLT駆動開発の申し込みはこちらになります。 テーマは「おれたちのLT駆動はまだはじまったばかりだ」ということでLT駆動2期のスタートです。 関連 すごいHirohsimaの本について、OSC2014とWTM71で紹介した

no_picture

GitHub戦闘力を提案してみた - 座駆動LT大会

座駆動LT大会で「戦闘力」というLTをしてきました。 座駆動LT大会とは、岡山にはRyouteiという素晴しいお店があり、そこの座スタジアムという部屋は非常にLTに適した場所です。 大都会岡山が誇る最強の懇親会会場「Ryoutei 座・スタジアム」でLT大会を開催します! というわけで、今回参加してきた時のスライドを紹介します。 戦闘力といえば、Vim戦闘力やEmacs戦闘力がありますが、GitHub戦闘力を適当に定義してみました。 スターの数がGitHub戦闘力と言われているのもみかけましたが、折角なのでいろいろ考えてみました。 実はオープンソースカンフェレンス2014広島のために制作しているものの中でGitHub APIを使用してつくっていたものがあり、そのノウハウで、そのついでに作成したのが今回のgithub_scouterです。 eiel/github_scouter · GitHub オープンソースカンファレンスは今週末の土曜日、2014年9月20日に予定されています。 予約数があまり多くないらしいので、今後も継続して欲しいと考えている方は参加や告知を協力していただけると助かります。 ちなみに私はLT駆動開発ベストセッションズでLTをする予定です。 閑話休題。 今回はGitHub戦闘力を攻撃力、知力、すばやさの3種類に分けて戦闘力を定義しました。 攻撃力は所有リポジトリを元に算出しました。 知力はさまざまな言語を利用していると高くなるようにしました。 すばやさはOrganizationの情報を元にチーム力の高さとして算出しました。 と、非常にどうでもいい戦闘力ですが、みなさんも御自分の戦闘力を算出してみてはいかがでしょうか。 また、APIの利用しすぎにご注意ください。 .@eielh 「わたしの戦闘力は168Gです」 #zadrvnlt — (っ’ヮ’c) < 君のほうがかわいいよ (@ryosms) 2014, 9月 13 かけ算バージョンは表計算で出したので、コマンドを用意していません。 0にならないように1を加えてからかけ算しています。 今後、計算式を定義しなおしてVersion2も検討したいと考えているのはまた別の話です。 追記 Gem化して欲しいって要望があったのでしておきました。 $ gem install github_scouter $ github_scouter [GitHub ID] で利用できます。

no_picture

LT駆動開発で hubot をつかったオフィスに誰がいるかわかるコマンドを作成した話をした

LT駆動開発07 でLTしてきた。 今回は hubot をつかってオフィスに誰がいるのかわかるようにした。 どうしてそんなことをしようとするのか、そして簡単に仕組みを紹介しました。 みんなが積極的に関わろうとするにはどうするのか。 おもしろかったり便利だと思うことをやること。 興味をもってもらうことだ。 オフィスには人がいたりいなかったりで、「誰かいたらいこうかなー」とか思うこともあるので完全に俺得である。 スライド内のデモ動画はこちらにあります。 結構みんなつかっていて、コンボも流行っている。 そのコマンドは突然のおるんかとかですね。 デモにいれておけばよかった。 仕組みはMACアドレスをつかっていて、みんなノートPCなのでなかなかうまくいっている。 最初はデーモンをつくろうかと思っていたけど、なくても解決できそうなのでこうなった。 おまけで、他につくったコマンドを紹介しとく。 アリア社長とアリシアさんの画像はこちらから拝借しております。 ありがとうございます。 非常に癒される。 おまけ LT駆動では予備のスライドを用意しておくことが大事らしい。

no_picture

Haskell のフィールドラベルをもつデータ型について

Haskellのレコード構文というかフィールドラベルをもつデータ型についてなんだけど、苦手意識というか更新の方法を最近までよくしらなくてうまく使えてなかった。 わかったことを含めて書いておく。 フィールドラベルをもつデータ型はざっくりいえば、構造体のようなものである。名前と年齢をもつ「人」を表現する型をつくってみよう。 data Person = Person { name :: String, age :: Int } deriving Show 上記はフィールラベルがないデータ型にいろいろおまけがついてくるだけなので data Perosn = Person String Int とした場合と同じような使い方ができる。 ghci> data Person = Person { name :: String, age :: Int } deriving Show ghci> Person "eiel" 30 Person {name = "eiel", age = 30} せっかくラベルがあるので、生かした使い方をしてみる。 ghci> data Person = Person { name :: String, age :: Int } deriving Show ghci> Person {

no_picture

Git で現在チェックアウトしているコミットのID

稀に今チェックアウトしてるところのコミットIDを知りたいときがある。 ぐぐったら下記のページがあったけど、grep やら awk やらつかっててずるい気がした。 gitリポジトリのリビジョン(コミットID)を取得するワンライナー | tomotaka-itoの日記 git log |grep '^commit' |head -1|awk '{print $2}' git コマンドだけで完結できる気がするので help を読んだりした。 以下に落ちついた。 git show -s --format=%H git log -n 1 --format=%H 関連 このコード書いた誰だよ! そんな時の git log -S でもしてみよう - そんなこと覚えてない Git で特定のコミットがどのタグに含まれているか確認する - そんなこと覚えてない

no_picture

Redis に保存されてる値を見ようと思った時に覚えておきたい redis コマンド

redis なんか使ったことないけど redis を使うアプリケーションを使う場合に、デバッグや動作確認をするのに、データベースの中身が知りたい場合がある。 そんな時に覚えておきたいことを整理してみた。 自分が hubot や sensu の動きを確認するのに必要だったことを書いてるだけで、 redis のことはよく知らない。 コマンドラインで redis にアクセスするには redis-cli コマンドを使用する。 redis-cli を実行して、対話環境を利用してもいいし、引数を追加して実行することもできる。 最初に紹介する keys コマンドを例にすると $ redis-cli > keys * $ redis-cli keys "*" といったアクセス方法がある。 ここで紹介するコマンドの一覧 コマンド説明 keys *redisに登録されているキーの一覧を取得する key のパターンを指定する type [key]value の種類を返す。 get [key]type が string だった場合の値をみる方法 lrange [key] 0 -1type が list だった場合の値をみる方法 smembers [key]type が set だった場合の値をみる方法 zrange [key] 0 -1type が zsetだった場合の値をみる方法 hgetall [key]type が hash だった場合の値をみる方法 hkeys

no_picture

Haskell で Selenium

たまには Haskell が書きたかったので、コマンドラインからあるウェブサービスに書き込みできるようにしたが失敗した。 失敗したというか画面を進めていくと止まってしまう。 なにやらアラートがでて処理ができていない感じなのだろうか。 Rubyでやっても停止するので、Haskellの問題ではない。 一応、最低限の使い方がわかったのでメモしとく。 利用したのは、hs-webdriver と phantomJS。 phantomJS は –webdriver オプションを使用することで、SeleniumのServerとして使えるようになる。 Haskellでは Selenium と対話するための webdriverというライブラリがあって制御することが可能。 Google にアクセスしてスクリーンショットを作成するプログラムをかいてみた。 {-# LANGUAGE OverloadedStrings #-} import Test.WebDriver import Control.Monad.IO.Class import qualified Data.ByteString.Lazy.Char8 as B main :: IO () main = runSession defaultConfig $ do openPage "http://google.co.jp/" screenshotWriteFile "google.png" screenshotWriteFile:: FilePath -> WD () screenshotWriteFile name = do string <- screenshot liftIO . B.writeFile name $ string 事前に $ phantomjs --webdriver=4444 としてから実行する。

no_picture

Rails 4.2.0 beta1 ちょっとだけ見たのでメモしとく。

Rails 4.2.0.beta1 が出てるよね。 Riding Rails: Rails 4.2.0 beta1: Active Job, Deliver Later, Adequate Record, Web Console betaが出ると試したくなるのでアップデートしても問題ないものをアップデートして遊ぶ。 先に結論 詳細とかあとで述べる。 Gemfile に追加とか変更とか。 gem 'rails', '4.2.0.beta1' gem 'sass-rails', '~> 5.0.0.beta1' gem 'web-console', '~> 2.0.0.beta2' group :development, :test do gem 'byebug' gem 'web-console', '~> 2.0.0.beta2' end gem 'rails-html-sanitizer', '~> 1.0' config/application.rb に追加 config.active_record.raise_in_transactional_callbacks = true config/environments/development.rb に追加。 config.assets.digest = true rails new したときの違い rails new してときの生成されるファイルの違い下記の方法で確認した。 $ rails _4.2.0.beta1_ new --no-rc hoge $ mv hoge 4.2.0.beta1 $ rails _4.1.5_ new --no-rc hoge $ mv hoge 4.1.5 $ diff -ur 4.1.5 4.2.0.beta1/ 全文はGistに貼った。 まず gem 関連 web-console と byebug と rails-html-sanitizer が追加されてる。 その他は、バージョン調整されてるだけ。 debugger はたぶん ruby 2.1 だと動いてないし、web-console を使うようになったので、byebug も追加された感じがする。よくしらん。 rails-html-sanitaizer は sanitize ヘルパーが追加できるらしい。HTMLタグがとりのぞけて独自のルールはScrubberを作ることで調整ができる模様。 以下、それ意外の抜粋。 onfig/application.rb + # For not swallow errors in after_commit/after_rollback callbacks.

no_picture

LT駆動開発で UIDynamics を利用した万華鏡アプリを紹介した

A8D:2 というイベントが2014年8月3日に行なわれます。明日じゃねーか。 そんなことはさておいて、Augment8というグループがあります。 このグループは年に1回、普段作っているものをみんなに体験してもらう場をつくろうというイベントがあるらしく、Augment8 Day を省略して A8D というイベントをしているそうです。 デジタルなガジェットを一般の人に体験していただくイベントだ。 そのイベントに参加することになったので、このために作成したアプリを告知を兼ねてLT駆動開発06で紹介をしました。 というわけでまずスライド。 つづいて、スライド内で利用している動画。 万華鏡のサンプル1 万華鏡のサンプル2 UIDynamicsのサンプル iOS7 からUIKitで物理エンジンが搭載されていて気軽に使えるようになったらしい。 まだ試してなかったのだけど、普通の人にも楽しめそうなものとして万華鏡をつくってみた。 iOSのCoreMotionを使いiOS端末を操作して画面に映る万華鏡が変化するという寸法です。 普段、iOSアプリをつくってるわけではないのでそんなに凝ったことはしていません。 万華鏡といえば三角なのですが四角のものもあるそうで、手抜きで四角の万華鏡になっています。 Apple Swift で作成しているためアプリとして申請するのもできないし、体験できるようにソースコードを公開しておきますね。まだ勉強中でソースコードが汚いですね、わかります。 Augment8/kaleidoscope · GitHub サブディスプレイに対応しているので、プロジェクタに写したり Apple TV で画面に写したりできます。 当日は丸いものにプロジェクトションマップもどきをしたりする予定です。 操作用のiOS端末のために拡張パーツを用意しています。デザイン担当のあきさんが作成しています。これを装着すると…つづきは当日のA8D:2にて体験してください。 デジタルならではなところは動的に反射している数が増えたり、中身が変化したり、マスクが変化したりと用意してみました。 それなりに面白くなったでしょうか。 魅せるためのスキル不足なため、本当に楽しめるものになったのかよくわからないので、みんなの反応が気になります。 今回のLT駆動における初挑戦は「動画をつかってみる」でした。 スライドを公開する際に動画は別のところにアップロードしないといけないのがすこしつらい。 Swiftのコードを書いていて思ったことは、 ブロック構文がなかなか書きなれない 変数宣言で型から書きそうになる なぜか[を入力してしまう なるべつ let で済ませたい病 selector 補完効かない。つらい。(文字列で渡すから当たり前) ヘッダファイルいらないヒャッハー CGFloat が絡む数値計算なんかよくわからない(すぐ型エラーに阻まれる) などなどでしょうか。(咄嗟に思いついたものだけ書いた) UIDynamics で ビヘイビアのインスタンスを節約しようとするとランタイムエラーではまったりしたのも良い思い出です。アニメータごとにインスタンスをつくりましょう。 Viewを触れるようにしてみたけど、移動したViewは元の位置にもどるという残念な結果にもなりました。 最後になりますが、調整するのにBAUHAUSの上原さんやファナフェクトの方々にアドバイスをちょろっともらったりしました。さんきゅーです。

no_picture

LT駆動開発で とある我馬の非公式というLTをした

LT駆動開発06 でライトニングトークをした。 我馬というラーメン屋のウェブサイトが更新情報のフィード配信してないので、勝手に応援しているという話をしました。 とある我馬の非公式(ファンサイト) 折角なのでフィードの存在を知らない人もいるかもしれないので、簡単に説明しつつ、どうやってフィードをつくったのか説明しました。 とりあえず、季節のラーメンはアツいので広島には3ヶ月に一度程度いらっしゃると良いと思います。 関連 とある我馬の非公式(ファンサイト) 我馬 eiel/gaba · GitHub eiel/gaba.eiel.info · GitHub


no_picture

iOSアプリでスリープしないようにしても、ホーム画面にもどったらスリープするよね

「iOS スリープしないように」で検索した結果、上位のいくつかの記事に [UIApplication sharedApplication].idleTimerDisabled = YES; とあり、これでうまく動作する。 注意事項として以下のこともかいてある。 上記の処理をするとアプリが終了してもスリープが起こらなくなってしまうため,アプリの終了時には必ず戻すようにします. 逆引きObjective-C for iPhoneアプリ - スリープモード(自動ロック)に移行しないようにする ただし、このまま放っておくとアプリを終わらせてもスリープが起こらなくなるので、アプリの終了時には必ず戻すこと! iPhoneSDKでスリープさせない方法 - 電子ガジェットいろいろ 開発メモ などなど書かれていて、事実なのか気になった。 UIApplication のインスタンスの設定を変えているのに OS の設定が変わるとは思えない。 というわけで、実際に試した。 普通にスリープしました。 記事自体も古いのでOSのバージョンによって違うのかもしれません。

no_picture

ヒロハタ 第1回レギュラー・ミーティング に潜入してきた

ひろしま発人材集積促進プロジェクトというのが行われていて、通称「ヒロハタ」というらしいのですが、その第1回 レギュラー・ミーティングがあったのですごい広島 をネタに潜入してきました。 「ヒロハタ」というのは一言からいうと、広島にクリエイティブな人材を集めようというプロジェクトだと思われます。 第1回のミーティングはプロジェクトに応募したアイディアのプレゼンテーションをするというもので一部のプレゼンが Ustream で配信されていました。 もうすでに動いているプロジェクトでさらなるブラッシュアップを計る人たちや、準備中で動いてはいるけど表に出るようなアウトプットはない人たちだったり、構想だけのものだったり、いろんな立場の人たちがいました。 参加してみると、こういった人たちがつながり相互に良い影響を与えようというのがプロジェクトの目的のように感じました。 「すごい広島」の立ち位置自体は協力できそうなプロジェクトをみつけて、Webアプリケーションのプロトタイプを作成してみたり、良いと感じたものを広めるお手伝いをしようという目論みです。 「すごい広島」は結果的にすごいエンジニアをみつけることができればメリットになります。または、作成したプロトタイプのつづきの作成するエンジニアをみつけることができればメリットになるかなぁ、というそんな感じです。 個人的には、参加者同士が交流する方法が少ないので、他の参加者の現状を見える化やコミュニケーションをとる何かがあるといいなぁ、と思っているところです。 関連 ヒロハタ~Web・ITを活用してアイデアの事業化を目指そう~

no_picture

ActionView 単体で slim を使ってみる

「ActionView を単体で使ってみる」というのを書いたので、ついでにいろいろ試してみる。その1。 誰が得するのか謎だけど ActionView だけで slim を使うことを試みてみました。 action_viewを require して、 action_pack を require して、 slim を require すれば使えます。 用意したファイル views/prefix/slim.html.slim p | Hello, #{@name} views/layout/appliacation.html.erb -- <%= yield %> -- require 'action_view' require 'action_pack' require 'slim' lookup_context = ActionView::LookupContext.new('./views') lookup_context.cache = false # ActionPachk を読まなくて済む魔法 view_context = ActionView::Base.new(lookup_context) view_context.assign(name: 'eiel') ret = view_context.render(template: 'slim', prefixes: 'prefix', puts ret =begin -- <p>Hello, eiel</p> -- =end slim は temple という gem を使ってRailsに対応してました。 ActionPack はバージョン確認に利用しているだけなので、ちょっといじればなんとかなりそうですけど。 Temple::Templates::Rails もう少し詳しく 誰得感がひどいのでもうちょっと書いてみる。 Railsとの連携の処理の部分は Temple::Templates::Rails(Slim::Engine, :register_as => :slim, # Use rails-specific generator.

no_picture

ActionView を単体で使ってみる

誰が興味があるのか謎ですが、ActionView を単体で使ってみようと思います。 意外にも Rails の仕組みとか見えてくるかもしれません。 Rails 4.1 ぐらいから ActionPack から独立した記憶があります。どうでしたっけ。 テンプレートを使いたい時には erb, haml, slim などを単体で利用すればいいのであまり使う機会はないかもしれません。 雑感では、 layout 機能を使いたい インスタンス変数で値にアクセスしたい Rails が提供するビューヘルパーを使いたい あたりがメリットかと思います。 この記事のために作成したコードはこちらにおいておきます。 補足の部分は読み飛ばせるように書いているつもりです。 利用したRailsのバージョンは 4.1.4 です。 1 Hello, world まずは使ってみます。 ActionView::Base.new.render(inline: 'Hello, World!') # => Hello, world ActionView::Base のインスタンスを作成し、renderメソッドを呼びだします。 コントローラでの render メソッドはどうやらこの render メソッドのようです。 (viewで使う render もこの render ですが…) 1の補足 ActionView::Base Rails を使ってる際に erb ファイルの中で self.class を確認したことはあるでしょうか? ちょっと確認してみましょう。 <%= self.class %> <%= self.class.superclass %> #<Class:0x007f82891092e0> ActionView::Base self は無名のクラスになっていますが、そのスーパークラスは ActiovView::Base です。 ビューは ActionView::Base のインスタンスのコンテキストで実行されるわけです。ビューコンテキストと呼んでいるようです。 また、このクラスにヘルパーをミックスインすることでヘルパーとして利用できるようになります。 デフォルトのHelperはすでに include されています。 > ActionView::Base.ancestors.map(&:to_s).grep(/Helper/) => ["ActionView::Helpers", "ActionView::Helpers::TranslationHelper", "ActionView::Helpers::RenderingHelper", "ActionView::Helpers::RecordTagHelper", "ActionView::Helpers::OutputSafetyHelper", "ActionView::Helpers::NumberHelper", "ActionView::Helpers::JavaScriptHelper", "ActionView::Helpers::FormOptionsHelper", "ActionView::Helpers::FormHelper", "ActionView::Helpers::FormTagHelper", "ActionView::Helpers::TextHelper", "ActionView::Helpers::DebugHelper", "ActionView::Helpers::DateHelper", "ActionView::Helpers::CsrfHelper", "ActionView::Helpers::ControllerHelper", "ActionView::Helpers::CacheHelper", "ActionView::Helpers::AtomFeedHelper", "ActionView::Helpers::AssetTagHelper", "ActionView::Helpers::AssetTagHelper::StylesheetTagHelpers", "ActionView::Helpers::AssetTagHelper::JavascriptTagHelpers", "ActionView::Helpers::SanitizeHelper", "ActionView::Helpers::ActiveModelHelper", "ActionView::Helpers::UrlHelper", "ActionView::Helpers::TagHelper", "ActionView::Helpers::CaptureHelper"] 2 インスタンス変数を使う Rails ではコントローラのインスタンス変数がビューの中で使えます。 普段はRailsが自動でやってくれていますが、自分でインスタンス変数を設定するには assign メソッドを使います。 view_context = ActionView::Base.new view_context.assign(name: 'eiel') view_context.render(inline: 'Hello, <%= @name %>') # => Hello, eiel @name が eiel に展開されています。 ActionView::Base のコンストラクタの第2引数に渡しても設定できます。 2の補足 ActionView::Rendering コントローラがビューコンテキストに対して assign メソッドを利用して、設定します。 これは ActionView::Rendering で行われます。 この ActionView::Rendering には ActionController::Base にミックスインされていて、コントローラがビューを設定する処理などが記述されているようです。 > ActionController::Base.ancestors.map(&:to_s).grep(/ActionView/) => ["ActionView::Layouts", "ActionView::Rendering", "ActionView::ViewPaths"] ActionController::Base には ActionView::Rendering がミックスインされています。 ちなみに assign するのに使う Hash は AbstractController::Rendering#view_assign で作成されています。 def view_assigns protected_vars = _protected_ivars variables = instance_variables variables.reject!

no_picture

Mac で docker 起動できない時。具体的にはDOCKER_HOSTを指定してない時

DOCKER_HOST を指定しとけって話。 個人的には Docker を外部マシンで起動して使えないか検討したいが、ここでは関係ない。 Macだと VirtuaBox 上で docker が動くので DOCKR_HOST を設定してないといけない。 その状態で使おうとすると下記のようになる。 http:///var/run/docker.sock/v1.13/containers/create: dial unix /var/run/docker.sock: no such file or directory boot2docker up を実行すると設定すべき値を確認できる。 $ boot2docker up Waiting for VM to be started... Started. To connect the Docker client to the Docker daemon, please set: export DOCKER_HOST=tcp://xx.xx.xx.xx:2375 表示された export DOCKER_HOST=tcp://xx.xx.xx.xx:2375 をコピペしとけばいい。 設定ファイルで export しとけって。

no_picture

Docker Hub を少し試してきた

Docker 初心者です。 難しいことはよくわかりません。 いまさら Docker Hub で遊んだ。 ちなみに #すごい広島 60 で遊んでたことらしいです。 今回は何をしたのか docker さえインストールされていれば、以下のコマンドを実行できます。 $ docker run eiel/banner ###### ####### ##### # # ####### ###### # # # # # # # # # # # # # # # # # # # # # # # # # # ### ##### ###### # # # # # # # # # # # # # # # # # # # # # ###### ####### ##### # # ####### # # $ docker run -e BANNER_ENV="happy hacking" eiel/banner # # # ###### ###### # # # # # # # # # # # # # # # # # # # # # # ####### # # ###### ###### # # # ####### # # # # # # # # # # # # # # # # # # # # ##### # # ### # # ##### # # # # # # # # # ## # # # # # # # # # # # # # # # ####### # # # ### # # # # # #### # # ####### # # # # # # # # # # # # # # # # # # # ## # # # # # # ##### # # ### # # ##### BANNER_ENV を設定すると出力を変えられます。 これの何が嬉しいかというと、banner コマンドの実行環境が簡単に用意できることだと思います。 redmine を実行するのに、 GitLab を実行するのに、Wordpressを実行するのに docker run でリポジトリ名を指定するだけでできるとしたらとても嬉しいと思います。 (実際にはDbのデータどうすんの?とかある気がするけど、どうするのがいいのかよく知らないけど) 定時実行するスクリプトが Docker さえインストールしていれば実行できたりするわけですね。 Docke Hub はどこで使ってるのか eiel/banner というイメージが Docker Hub にあいてあるので、docker run eiel/banner を実行すると、まだローカルにイメージがなければ取得して実行できます。 それだけ。 このイメージはここにあります イメージを作成するのに Dockerfile をつかっており、コードは GitHub に up してあります。 FROM eiel/gentoo-sample:banner MAINTAINER Tomohiko Himura <eiel.hal@gmail.com> ENV BANNER_ENV docker CMD banner $BANNER_ENV このファイルをカレントディレクトリに置いて docker build -t banner .

no_picture

LT駆動開発で ruboty の使い方っぽいことを適当に紹介した

LT駆動開発 05 でライトニングトークをした。 6月はすごい広島のBOTを作って遊ぶことをしていた気がしたのでこれを紹介することにした。これは Ruboty で作成した。 何か毎回やってないネタを挟みたいということで、ふたつスライドを用意して相互参照するというネタをした。 まずは、BOTの具体例である「すごい広島 BOT」を紹介することでなにがしたいのかをBOTを知らない人に理解してもらう。 そこから、どうやってそれを作るのか。というところに焦点をおいたというライトニングトークするという流れである。 しかし、実際、ふたつもライトニングトークをする時間があるかどうかわからないので「Rubotyの使い方」はかなり適当につくってしまった。 類似性を持たせるために、前半は同じ構成になっている。 最終的にしたいことは、「すごい広島のTwitterアカウントを誰か運用してくれ」ということかもしれない。 すごい広島のBOTは今後もプロキシーBOTとして活躍していただきたいところである。 ruboty-twitter の fork をみてみると、デバッグ用のコード仕込んでみたりとかしているところがあって、うまくメンションが返ってこなかったからかと思い、その辺を補足してみたという経緯があったりなかったりもします。 関連 Rackup で Ruboty すごい広島 一周年 LT駆動開発という勉強会をはじめるよ

no_picture

コミットメッセージの先頭に絵文字いれるのが流行ってんだろうか

Atom Editor の Contributringをみてみると、「コミットメッセージの先頭に関係ある絵文字をいれろ」的なことが書いてある。 Git Commit Message - contributing - Atom :lipstick: when improving the format/structure of the code :racehorse: when improving performance :non-potable_water: when plugging memory leaks :memo: when writing docs :penguin: when fixing something on Linux :apple: when fixing something on Mac OS :checkered_flag: when fixing something on Windows :bug: when fixing a bug :fire: when removing code or files :green_heart: when fixing the CI build :white_check_mark: when

no_picture

Atom で キーバインディングを使うには key-binding-resolver を使えばいいらしい

キーに割り当ててるコマンドを探す場合、emacs だと Ctrl-h k を使うけど、Atom なら Key Binding Resolver を使えばいいらしい。 Macならデフォルトでは cmd+. にバインディングされてる。 helm-describe-bindings に比べると不便だけどないよりましだと思う。 わがままをいうとコマンド名をコピーできるようにして欲しい。

no_picture

Atom Editor で markdownモードのスニペットの追加

Atom Editorをときどき試している。 markdownモードにスニペットを追加する方法がなかなかわからなくて困ったのでメモ。 最初に指定する文法名がわからなかった。.source.gfmを指定すれば良かった。 この .source.gfm の簡単な調べ方がよくわからない。 gfm は GitHub Flaver Markdown の略だと思われる。 参考例をあげておきます。 '.source.gfm': 'Sample Snippet Hoge': 'prefix': 'hoge' 'body': 'hogehoge' atom.syntax.grammarsByScopeName にいろんな名前がとれたけど、全然効率よくない。

no_picture

シェルの if を1行でかく

すごい広島 59 のメモ sensu の実験をしていて実行する command に if を含むスクリプトをかいていたのだけど、ちょっとはまったのでメモしとく。 以下のようなスクリプトを1行で書きたいとする。 HTTP_STATUS=`curl -w '%{http_code}' -s http://blog.eiel.info/ -o /dev/null` if [ $HTTP_STATUS -eq 200 ] then echo -n $STATUS else echo -n $STATUS; exit 1 fi 1行で書くとこうなる。 HTTP_STATUS=`curl -w '%{http_code}' -s http://blog.eiel.info/ -o /dev/null`; if [ $HTTP_STATUS -eq 200 ]; then echo -n $STATUS; else echo -n $STATUS; exit 1; fi then と else のすぐ後ろにはセミコロンがあってはいけないらしい。 整理すると if [test]; then command1; else command2;

no_picture

さくらVPSでGentoo をインストールした時のはまったことのメモ

つかってた VPS がサービス終了してしまったので、さくら VPS に移行してみた。 折角なので OS は Gentoo Linux を選択した。 前の VPS では Debian をつかってた。 なんか、ウェブサーバの応答がよくなった気がする。 一応はまったことを書いておくけど大したことは書いていない。 iso アップロードして、普通にインストールした。 デバイス eth0 がみつからない なんか enp0s3 として認識してた。 おかげで、ネットワークつながらなくて苦労した。 参考 さくらのVPS(2G)でのハマリポイント(enp0s3) - /dev/curiosity ディスク が vda だった 「ディスクがねぇぇええ」って、デフォのCentOS起動してよくみたら sda じゃなくて vda だった。 GPT に挑戦したら GRUB が入らなかった 最近Linuxインストールしてなかった。GPTとやらにしてみることにした。 なにも考えずにデフォのCentOSのパーティションをそのまま利用して構築していた。 さあ、GRUBをインスールするぞ。というところで気づいたのだけど、BIOS boot partitionとやらなく、GRUBのインストールに失敗するので、対処を迫られた。 すでにカーネル配置済みの /boot の中身を一旦退避して、パーティションを書き換えてごまかした。 ブートCD がある方法で、ディスクブートする方法がわからない 15秒放置するだけでした。 virtio いれわすれてディスクがみつけられない とりあえず、 genkernel したからなにもいらないかとおもったけどダメだったらしい。 $ genkernel --virtio all とか genkernel にいろいろオプションがあるのを学んだ。 まとめ Gentoo力上がってるので、あんまりハマってない。 最初のネットワークが繋がらないで挫折しそうだったのは秘密である。

no_picture

DevLOVE広島 第一回(夏の陣) でエンジニアリングの楽しさについて喋らされた

いや、別に無理矢理だったとかわけではなく。 依頼されて喋ることになったからこういうタイトルになった。 ということで、 DevLOVE広島 第一回(夏の陣) に参加して「愛無双 - エンジニアリングの楽しさ」というタイトルでセッションをしてきた。 エンジニアリングの楽しさを語れということだったので、自由にはっちゃけてきた。 中身のないあるひどいセッションだったと思うけど、みんなが楽しめるようにがんばったつもりである。 何度か会場に笑いとれていた気がするのでよかったことにしよう。 会場に電波がなかったせいであまり Twitterにも感想が流れていない のでみんな感想ブログを垂れ流してもらえると自分が勉強になる。 タイトルはご存知 jubeat knitのボス曲 I’m so Happyです。 解禁にお財布が Broken するアレです。 多くの人が Happy になれないアレです。 ちょうど言いたいことにマッチしていたのでこのタイトルにしておきました。(他意はない) ちなみに、わしはぶち楽しいけぇ。 エンジニアリングの楽しさ 技術的なネタがないし、30分もネタが浮かびそうになかったので、前半は「エンジリアリングの楽しさ」というのはなんだろうかと自分なりに考えた話をした。 DevLoveには参加してないようなエンジニアリングというのがよくわからな人に届けばいいな、と思いながらつくった気がする。 あとは「友人のツイート」が使いやすかったからこうしたという説もある。 楽しくある必要性 二番目は「楽しくある必要性」として、さてどうして僕がそんなにいろいろがんばれるか。という根本原理について話してみようと試みたがたぶんあまりうまくいってなく自分でも消化不良である。 ここで登場しているダチョウさんは、グーグルの画像検索で再利用可能なものを指定して検索した場合、一番使いたくなる画像らしいです。 普段から撮影した写真を感情ごとに分類しておけばいいなと、今回とても感じた。 よーするにさ、こうしたいってのみつけと、どーしたらいいか考えてるだけだ。 あと、できるだけ楽しいほうがいい。 僕の楽しい 正直、楽しいものはよくわからない。わからないけど、出てきたものは楽しいものだ。 そういう気持ちで、目的の被らないネタを選択して適当に紹介した。 「変態は褒め言葉」ということで蝶の写真を選択したけど、ネタが通じた気がしない。よーするにエンジニアはものをつくるため、ものの仕組みに詳しくなり、人によっては自分が自由に使いやすいようにしたりするのも楽しむよね。 だから、エンジニアリングとはあまり関係ない例になってしまったが、わかりやすいのでキーボードの話をした。 Aの左横が Cotrol の人がかなりいました。delete の人はいませんでした。 あとよくみればわかりますが Dvorak 仕様になっています。 GitHubですが、もっと整理しとけばよかったなと思いますが、今回の参加者は大きい企業にお勤めの方が多そうだったので話しておこうと思ったところです。 それ以外に深い意味はありません。 あと勉強会をすることについてですが、この辺はスライドがあまり面白くないので、背景に我馬 というラーメン屋のラーメンの写真を利用しました。 狙ってやってるのはカリーつけ麺だけです。 みそ菜麺はかなり好きだったのでまとめに使いました。 我馬は広島に店舗を構える博多の有名なラーメン店に似ているラーメン屋です。 レギュラーメニューもとてもおいしいのですが、毎回新作が登場する季節のラーメンのこだわりがすごすぎて、よくいくラーメン屋です。 広島へお越しの際は、一度行ってみてください。 まとめ スライドを作成するにあたりキーボード書いたり、写真選んだり、ツイート探したりと、それなりに時間をつかったのは久しぶりでした。 楽しんでもらえたのでしょうか。 そんなことは #知らんけど、そんなことはさておいて、わしらはぶち楽しいけぇ。 スペシャルサンクスとか @shuuheyhey @Toro_kun @kakenavi @eielh ファナフェクト株式会社

no_picture

rackup で ruboty

ruboty を heroku で動かすついでに web アプリケーションとして扱いたい。 その場しのぎで書いたコードを紹介する。 config.ru の中で別スレッドを起動して Ruboty#run を走らせた。 # Rackアプリになるように call メソッドを実装 module Ruboty::Web def call(env) [200, {'Content-type' => 'text/html'}, ['hello, world']] end end Ruboty::Robot.include(Ruboty::Web) Thread.new do robot.run # bot起動 end run robot # rack アプリを構築 heroku では 1X dynos でもスレッドが 256 個ぐらい起動できるっぽいしきっと大丈夫だろう。いや、わからんけど。 参考: Limits | Heroku Dev Center シグナル処理も追加したほうが良い気がするけど、とりあえず気にしない。 そのうちウェブアプリを構築しやすくする方法を考えたい。 関連 hubot で起動しているウェブサーバを経由して idobata へ投稿してみる

no_picture

オフィスチェアを買いました。- LT駆動開発04

LT駆動開発04で椅子を買った自慢をしといた。 これからは真面目に仕事をがんばろうと思う。(しかし、僕はもう結構限界だ) というわけで、椅子を買いました。 ほぼオカムラ一択で決めていた。 というか、あまり椅子の情報ってネットにない。 バロンもすわったけど、座った感触がシルフィーがよかったので、金額的にもシルフィーにした。 シルフィーはバックカーブアジャスト機構のレバーを上げた状態がすごくフィットしてて、そこが気にいっています。別に小柄ではないはずだけど。(大柄でもないけどさ) 感想としては、コンピュータルームによくある椅子のさらにちょっと良い奴。という印象です。 本当はシフトが気になってて、非常にだらだらした体制で作業したい。 というか、ほとんどが後傾姿勢で作業してることが多いので、「そうそうその体制で作業したいんだ!」という思いがありました。 しかし、購入ルートがわかんなくて、レビューも全然なくて高い買い物なので。諦めました。 というわけで、椅子のレビューはあんまりないのでみんなすればPVが稼げるんではないかと思います。 体験はご自由にしていただいて構わないので気軽に遊びにきてください。(どこに) ちゃんとしたレビューは使い込んでからしたい。

no_picture

通知環境としてidobataを試した話をLT駆動開発04でした

今月もLT駆動開発04でライトニングトークしてきました。 結構今回雑…。喋りもグダってた。見直しとか、リハっぽいこともしてないから…。 CircleCIの通知をしたいなーってことで idobata のクライアント使えばできそうなので、 hubot をつかって idobata に情報を送信してみたよ!という話をしました。 なんか開発で BOT を使うの良さってのがやっとわかってきたので、その話もちらっとした気がします。しかし、中身がないな…。 気になってるのは CircleCI の Web Hook から飛んでくるJSONの情報が整理されてなくて調べるのがめんどくさいなーって思ってたりします。なんかライブラリはないのだろうか。 関連 hubot で起動しているウェブサーバを経由して idobata へ投稿してみる

no_picture

ツイートを埋め込みするためのボタンが行方不明なので、JavaScriptでなんとかする

ブログにツイートを埋め込みしたい…。 なぜか「その他」ボタンがみつからない…なぜだ…。 解析したら要素は存在している模様。ブックマークレットをつくってごまかす。 javascript: $('.permalink-tweet .embed-link button')[0].click() ちなみに、ログインしてない状態だと「その他」ボタンが出ることに後で気づいた。

no_picture

Git で特定のコミットがどのタグに含まれているか確認する

バグなどをみつけて原因のコミットをみつけたけど、バグというか自分が依存してるライブラリが古いせいだったりして、いつからじゃないと使えないですよーって伝えたい時に、どのタグに含まれてるコミットなのか調べたかった。 git tag コマンドの --contaions オプションが使える。 $ git tag -l --contains [コミットID] フィルターしたい場合は 引数にパターンが渡せる。 v4.0 系をみたいとかであれば $ git tag -l --contians [コミットID] `v4.0.*` みたいな感じ。 クオートしないとシェルに食われる。 パイプで grep してもいいけどね。 ブランチにも同様のオプションがある。 branch には似たようなものとして、ブランチにマージされてるかどうか調べる --merged とか --no-merged とかある。

no_picture

hubot で起動しているウェブサーバを経由して idobata へ投稿してみる

hubot をつかって idobata 用のBOTを作っていた。 heroku にホスティングして HTTPアクセスをすると idobata へメッセージが流れるようにしたい。 最終目的は CircleCI から WebHooks に登録しておいて、ビルドが終了したら通知したい、だったりするけど今回はそこはおいておく。 チャットへメッセージを送るには robot#send を呼べばよくて、第1引数が envelope で 第2引数以降が文字列。 idobata-adapter の場合は第1引数の message.data.room_id に投稿する ROOM_ID が必要になる。 参考 - hubot-idobata robot.send_room 'hogehoge' みたいな感じに投稿できるようにメソッドを加えるならこんな感じになった。 ROOM_ID = process.env.HUBOT_IDOBATA_DEFAULT_ROOM_ID module.exports = (robot) -> robot.send_room = (msg) -> envelope = { message: { data: {room_id: ROOM_ID } } } @send envelope, msg ROOM_ID を取得しないといけないので、登録したBOTに room_id を返すような機能を追加しました。 robot.respond /ROOM_ID/i, (msg) -> room_id = msg.message.data.room_id robot.logger.debug room_id msg.send room_id ROOM_ID がわかったら 環境変数 HUBOT_IDOBATA_DEFAULT_ROOM_ID を設定しておく。 あとは robot.router.get とか robot.router.post をつかって処理を作成すればいよい。 robot.router.post "/hubot/ping", (req, res) -> robot.send_room 'pong' ローカルで実行する場合は 8080 ポート。 heroku へは push するだけで使える。 /hubot/ping にアクセスするとチャットに pong と書き込みがされます。 hubot 自体のソースコードはそんなに長くないので、いじりながらソースよめばなんとか使えるようになりそうでした。 補足 robot.respond とか、使った場合は コールバック引数 msg があるのでこいつの send を利用するだけでチャットにかきこみができる。 msg は Response クラスのインスタンスでサーバからうけとった情報を message プロパティに保存されてて、この情報で envelope.message から取り出せる。 Response#send は以下のように実装されていて、 send: (strings...) -> @robot.adapter.send @envelope, strings...

no_picture

すごい広島 一周年

すごい広島って勉強会というかミートアップが一年間、毎週休まず活動したらしい。「すごい」というか、めでたい。 概要 すごい広島とは何か 一年間活動してみて すごい広島とは何か すごい広島は、「ITエンジニアとか、情報系の学生とか、Web系デザイナが毎週どこかに集まっていればそれだけで面白いことになるはずだ」 と考えた @Toro_kun と @CentBoss と @eielh がはじめたミートアップらしいです。(他人事) 「すごい広島」は、もともとすごいHaskell を楽しく学ぼう という書籍の読書会を広島でやろうとした際に考えた名前だそうです。 しかし、Haskell の需要が少ない関係で、参加者が見込めないため、読書会はお蔵入りしてしまいました。 せっかく考えた名前は面白いし、どこかで使いたい。 そこで、流用したのが「すごい広島」となりました。 しかし、ただ集まるだけでは目的を見失う恐れがあります。 「広島のエンジニア」のアウトプットの総量を増やすことによって広島が盛り上ってるように錯覚させることができないか考えることにしました。 結果、参加ルールを設けることにしました。 その場で何をするつもりなのか GitHub の Issue に書く すごい広島内でブログを書く GitHub に Pull Request をする というルールです。 GitHubに慣れてもらうために、開発でない部分にGitHubをつかおうとする試みです。 最初に Pull Request した時の楽しさを伝えたいというのもありますし、GitHubを使える人と仕事をしたいという裏の目的です。 結果、GitHubを練習するための場として定着するようになりました。 しかし、ブログをかくのは少し負担が大きいということになり最近では「何かしらのやったことをウェブに残すこと」というルールに緩和されました。 ところで、広島でもIT勉強会は土日にそこそこの数あります。 自分がいろんなすごい人たちの話を聞きたいのもありますが、土日以外なら参加できる人もいるかもしれない。 毎週やっていれば、月に1回ぐらいは来られるかもしれない。 そんな気持ちでやっています。 気がつけば、すごい広島はほぼ毎週参加されている人は3,4人います。 いつもいる人を中心に、輪が広がり、相乗効果が起きるといいと思っています。 一年間活動してみて つづけたいこと 毎週活動する 学生など若い人を優遇する 学生が来る場合は、社会人がひとりいるだけでも学生にとっては参考になる話も聞けると思うので、それだけでやってる価値がでて良いと思います。 問題点とか直したい点 人数が多いと喫茶店だと迷惑がかかる 参加者の固定化 名前からやってることが想像をしづらい。なにしてるか不明。 よく参加する人はステップアップして欲しいが、その道を示してない。 はじめての参加者に優しく、参加しやいように メンバーの固定化はちょっと深刻な気もします。 なるべくはじめてきた人が入りにくくならないように気をつけたい。 挑戦したいこと みんなが勝手に準備して、勝手にまわるように 協賛。活動することにメリットがある企業をみつけて支援してもらいたい。 企業に協力してもらいたいところはちょっとある。 その他感じてること 大人がんばれ 参加者に学生がわりと多く、どうやら大学の同好会の活動の一部になってきているらしいです。 それこそ学生が参加して価値を提供できるように社会人ががんばるようになるとすてきだと思います。 2ヶ月に一度ぐらい来る人とかが数人いるとちょっと雰囲気が変わるかなとも思います。

no_picture

オープンセミナー2014@岡山に参加した。ついでに懇親会で継続することについてLTした。

オープンセミナー2014@岡山に参加しました。大盛況でした。 中四国地方では最強の無料セミナーなんじゃないかと思えてしまいます。(他を知らないだけ) 実行委員長の @mako_wis おつかれさまです。 本編の話はおいておいて、ライトニングトークをしたので資料をはりつけておきます。 一日で何回テンプレートが azusa の資料をみたことでしょう。僕は配色は変えてありますが…。 本資料はもともと#LT駆動 の余った時間用につくったスライドでした。 前回、時間がなく利用するタイミングがなかったので、ほぼそのまま使いました。 このスライドは GitHub の Longest streak が 365日を越えた記念で作ろうかなーっと思ひてつくったものです。 Longest Streak は GitHub で活動した日数が最大で何日続いているかというものです。 毎日続けてみたいなーって思い、続けてみたのですが、ときどきふつうの人と比べてみると、怖いレベルになってる気がしてきています。 今も継続しています。この記事を書いてる時点では394日でした。 つづけるための秘訣は、なるべくがんばりすぎないことと、ちゃんと通知する仕組みを用意することだと思います。 他にもいろいろ毎日やってることがありますが、 心臓病と診断される前は腕立腹筋とかもしてましたが、最近は医者に怒られるのでやってません。その頃はorg-modeで管理していましたが、今は Mac のリマインダーを使って管理をしています。 自分がやりたいことに近づいていけるように、毎日何かをしたいし、癖にしてしまいなにもしない日があったしても、少なくともなんらかの基礎力は付けたいです。 その上で継続したからこそ起きたことをゆっくり話したかったですが、グダグダでした。 物事の成長は線型じゃないことを覚えていたほうがいいと思うので、Beatmania IIDX の段位認定を元に成長速度の話をするつもりでしたが、全部カットしました。THE SAFARI は例外的に山が高いです。がおー。 最後にいつもツイートを使わせていただいている、友人のえいるさんの努力に関する心に残ったツイートを引用していたのですが、そこにいくための前振りでタイムアップでした。 あの人すげーって思ったら、その人がしてる努力や日常に目を向ける。どういうことを継続すればあんな風になれるかわかる。 — えいる (@eielh) 2013, 6月 15 みんなでオープンセミナーを盛り上げて、ITエンジニアをこどもたちが憧れるような職業に変えていけたらいいのに。 関連記事 LT駆動開発という勉強会をはじめるよ 本当に障がい者でもオープンセミナー広島の実行委員長ができるのか? - 答え: できた。 .オープンセミナー広島は広島のITエンジニアが集う場所

no_picture

rails console でルーティングが生成した helper を使う

Railsで config/routes.rb に resources :users とかくと users_path users_url user_path user_url new_user_path などなどのViewで利用できるヘルパーが生成される。 このヘルパーを rails console で使うには、app オブジェクトを経由する。 例 app.users_path # => "/users" app.users_url # => "http://www.example.com/records/3.html" app.user_path(User.first) # => "/users/1" app.user_path(User.first, :html) # => "/users/1.html" なんとなく関係ない例を混ぜた。 routing helper というらしいのに helper からアクセスできない。 関連リンク ActionDispatch ってなんだろう? - 広島・岡山Ruby交流会01 - そんなこと覚えてない

no_picture

GitHub Pages で jekyll を使うなら safe: false で開発したほうが良いかもしれない

3月ぐらいから GitHub Pages でも使える Jekyll のプラグインが一部使えるようになりました。 最新の github-pages gem の v18 だと jemoji - GitHubの絵文字が使える jekyll-mentions - @github-id と、書くと自動でユーザへのリンクになる jekyll-redirect-from - 別のページからこのページに飛ばせる jekyll-sitemap - sitemap.xml が自動生成される が使えます。 ローカルで開発する場合、_config.yml に safe: true と記述してしまうと、これらのプラグインが動作しません。 GitHubに push すると動作してました。 ただし、GitHub上では safe: true の状態で動いてるはずなので、注意が必要です。(実際に確認はしてないけど) github-pages v19 で Jekyll が 2.0.2 になるのでこれはこれでまた違ってくるかもしれませんが、確認していません。(まだリリースされてない) そういえば、SASS とか CoffeeScript が使えるようになりそうなので非常に期待したい v19 です。 ローカルやTravisで生成すればだいたいのことができますが GitHub で生成できるとGitHub 入門として使いやすいですし、どんどん機能拡張されると良いですねー。 補足 プラグインを利用するには _config.yml に gems: - jekyll-mentions - jekyll-redirect-from - jemoji - jekyll-sitemap の記載が必要です。

no_picture

LT駆動開発03で「S3にスライドを保存することにした」という発表者をしてきた。

LT駆動開発03 でLTをしてきました。 最近、本当にSSDの容量不足が深刻で仮想マシンなんて作った日にはさっさと用事を済ませて消さないとやばい状態が続いています。 そんなわけで、滅多に使うことのないけど、残しておいたら役に立ちそうなファイルはS3に保存してみることにしました。 それだけだとつまらないので、ついでに一般公開しました。 index.html を作るのに手動で作るのはめんどくさいので、 S3のバケットに保存しているオブジェクトの一覧をAPI経由で取得して、この情報を元に index.html を作成して、アップロードして、静的サイトとして公開しています。 一覧の取得 index.html の作成 index.html のアップロード を自動化しています。 実際のページとソースコードはこちらに。 http://keynotes.eiel.info/ GitHub - eiel/keynotes-eiel S3を使った静的サイトの運用もちょっと試してみたかったので良い機会でした。まだ、調査が必要そうですけども。 自動化はしていない部分であるスライドのアップロードには s3cmd を利用しています。 後半はHaskellの話です。 HaskellのAWSのAPIを叩くには aws ライブラリを使用しました。他にも aws-sdk というライブラリもあるようですが、対応しているサービスが違っているようでした。 元々 Ruby を使ってつくってたのですが、なんとなく理由もなく Haskell でやりたくなってHaskellでやってみましたが、意外と簡単にできました。 Haskell 良いですね。 あとレコード型が実に使いこなせてないことに気づいたので勉強してこようと思いました。 まだ、 keynotes.eiel.info に特化しているのでそのうち汎用性を上げたいと思います。 スライドですが、azusa テンプレートをかなり参考にさせていただきました。 というか、色は少し自分好みに変えただけですね。 赤はもうちょっと明るい色を使うほうがいいなって思う反省点がありました。 そんなわけで、今日はこの辺で。 関連リンク LT駆動開発という勉強会をはじめるよ - そんなこと覚えてない

no_picture

CucumberとTurnipとSpinachと。

最近 spinach というライブラリがあることを知って Cucumber や Turnip と同じようなものだということはわかっていたのですが、ちゃんと調べてみることにした。 Cucumber Turnip Spinach 「きゅうり」と「かぶ」と「ほうれん草」ですね。 一応ざっくり解説しておくと ビヘイビア駆動開発 を実践するためのテスティングフレームワークです。 Gherkin という書式を利用して自然言語をならべて記述した文書を使い、自動テストとの結びつけができます。 動くことを確認することができる仕様書として使えます。 今回登場している3つのソフトウェアは Gherkin を使っている Cucumber がら派生したライブラリです。 Turnip は Cucumber から派生して、使いやすく改良したものです。 Spinach は Cucumber から機能を削減して見通しをよくしています。 Turnip Cucumber から派生して、Cucumber のイケてないところが修正されており、最近徐々に人気が出ているようです。 るびまで取り上げられているので知っている方も多いと思います。 また rspec コマンドから実行することになります。 Spinach Spinach は GitLab で利用されています。 Cucumber から強い機能が外されてます。 ステップから引数をうけとったり、シナリオテンプレートが廃止されていたり。 「重複を排除するための機能は Ruby のレイヤーでやらせてしまおう」という感じがしました また、Gherkin は独自のものが再実装されていて国際化がされてないので、Cucumberだとできることが一部できません。 When や Given などは、日本語で「前提」や「もし」とかけましたが、Spinach 日本語が使えません。 もうちょっと詳しく 例として Feature をひとつ作成してみました Feature: Cucumber と Turnip と Spinach ちょっと遊んでみる Scenario: 配列の作成 Given

no_picture

hiroshima.5374.jpをつくった話を LT駆動開発 02 でしてきた

LT駆動開発 02に参加してきました。 そもそも主催者らしい。 LT駆動開発は普段の開発する際に「毎月ライトニングトークすることを考えながらやろう」という主旨の勉強会で、「勉強会では発表者が一番勉強になる」という法則を軸にした勉強会です。 今回は3月頭に 5374.jp の広島市バージョンを作成したのでその話をしました。 世の中には「誰かがやれば便利になるだろう」と思うものがあると思います。 でも、「誰かがやるだろう」って思う人がたくさんいます。 だからこそ、積極的に誰かがやるだろうと思うことをやることで、良い流れを作れる人になれるのではないかと最近思ってたりします。 でもでも、独りのキャパシティには限界にあるので、どうやって周りをまきこむかも大事だと思っています。 こういう想いを書いたブログ記事を書いたりとかも巻き込もうという意図があるかもしれません。 以前どこかで書きましたが、私は一般の人より体力が少ないみたいなのです。 最近はどうやったらそれを補えるか、どうやったら生かせるか、を考えていたりしています。 その一つの答えは「大きな流れをつくるきっかけを作る」ことかと思っているのですが、その想いは特に語りませんでした。 みんなが楽しくなる場所とか、みんなが便利暮らせる社会とか、そういう風に考える人が少しでもたくさんいて欲しい。 あ、でも、まずは、自分のことを大切にしてくださいね。 自己犠牲なんか誰も喜ばないからね。 話が逸れた。 Code For Japan とか Code For X のこと自体、私自身がよくわかってはいないですが簡単に話したりもしました。 そもそもの目的は GitHub を普通の人に使ってもらえる機会が作れるんじゃないかと思ったのですが、結局自分ひとりでCSVをつくってしまったという話も少ししました。 そんなわけで、LT駆動開発はなるべく毎月やっていきたいと思います。

no_picture

ActionDispatch ってなんだろう? - 広島・岡山Ruby交流会01

ちわっす。絶賛、仕事が遅れまくっていてこんなことをしている場合じゃない状態です。こんにちは。 広島岡山Ruby交流会01 に参加してきました。 一応セッションをしたので、ブログに残しておきたいと思います。 Rails のコードリーディングをしているので、自分の中に構築できたイメージをアウトプットをしようというシリーズです。4ヶ月ぶりぐらいですね。 今回は ActionDispatch です。 ActionDispatch ってなにすんだよ?って正直思っていたので、「ActionDispatchってなんだろう?」というタイトルにしました。 Rails は MVC フレームワークということで MVC のどこかにはまるものであればイメージが湧きやすいのですが、それ意外の部分になると途端に想像できなくなります。 ようやく想像できるようになったので簡単に図示しつつ、それと気になる部分をざっくりと紹介しました。 スライド中のコードは Gist にアップロードしました。 https://gist.github.com/eiel/b4c6e39bf9b694022b17 最後に言い訳をしておくと、時間を使ってる場合ではないので図が雑です。 Rails の勉強をしている人に参考になれば幸いです。

no_picture

Twilio を使って、着信でモールス信号してみた。

Twilio API 勉強会に遊びにいった。 勉強会では基本的なことを学んだ。 電話をかけたときの動作を登録したり、電話をかけたりしました。 せっかくなので、なにか作ってみることにした。 以下、完全にネタです。実用性皆無です。 あとサービスにどれくらい負荷がかかるのかよくわからないので、試す場合はほどほどにしましょう。 たぶん、もう二度と試さない。 着信する長さが一応調整できるのでモールス信号してみました。 コードは以下の感じ。 require 'twilio-ruby' require 'morse' account_sid = 'account_sid を設定する' auth_token = 'auth_tokenを設定する' @client ||= Twilio::REST::Client.new account_sid, auth_token TWILIO_NUMBER = 'Twilio で作成した電話番号を登録する' MY_NUMBER = '自分の電話番号を設定する' def call(n) call = @client.account.calls.create( from: TWILIO_NUMBER, to: MY_NUMBER, url: 'http://example.com/', timeout: n, ) puts "create call #{call.sid}" loop do call = @client.account.calls.get(call.sid) puts "call status #{call.status}" case call.status when 'no-answer', 'completed' sleep(1) break when 'failed','canceled'

no_picture

Sensu を少しだけ触ってみた

ちょっと前に Sensu を試した。 大したことは試してないのですが、日本語の情報もあまりないので試したことを記録しておこうと思う。 Sensu って? Nagios という統合監視ツールの置き換えを狙ったプロダクトのようで、Nagios のプラグインがそのまま使えます。 そもそも Nagios のプロトコルをそのまま使ってるようです。 同様のツールとして Zabbix などありますが、結構毛色が違うツールだということを今回わかりました。(Zabbix は試したことがありますが、Nagios は試したことがないです) Zabbix は全部入りみたいな感じで、これだけでなんでもできたりして、入門するには難しい感じです。 Nagios を利用する際にはグラフを書きたい場合は munin などを併用する人も多いようです。 munin は個人的に設定が楽なので、ちょろっとした時に利用します。 そんなわけで、「いまどきの Nagios」 である Sensu を試してみようという流れです。 まずインストールしてみる どんなものかピンと来ない場合はまず動かしてみるほうがいいです。 Sensu をインストールするのに chef や puppet が使えるように公式から sensu-chef や chef-puppet があり割と簡単にインストールできるようです。 手動でもそんなに難しいわけではなく ドキュメントを見ながらやればできると思います。 というわけで、今回は sensu-chef を試しました。 私が chef の初心者なので、その辺のメモも書いています。 sensu-chef の README.md をみるとやり方が書いてあります。 Vagrant をつかって動かすサンプルがあります。 $ git clone git@github.com:sensu/sensu-chef.git $ cd sensu-chef/examples $ gem install bundler $ bundle install

no_picture

S3を使って静的サイトの公開する奴をしてみた。自動化できるみたいで幸せだった。

AWS 楽しいですね。プログラミングできる領域が増加する楽しさがありますね。 なかなかAWSのマネージメントコンソールとお別れできない、AWS初心者です、こんばんは。 Amazon S3 の売り文句に静的サイトにするという話がよくあります。 ちょっとやってみたのですが、マネージメントコンソールでのポリシーの設定とかめんどくさい。 具体的にいうと、S3を使って静的サイトを公開する手順に記載されてる1番と2番と3番がめんどくさい。 Webサイト用にS3のバケットを設定する。 バケット内のファイルがアップロードした際、自動的に公開されるようバケットポリシーを追加する。 HTMLファイルをアップロードする。 S3のwebsite endpointにアクセスし、ウェブサイト が表示されることを確認する。 という手順を踏む。 1番はデフォルト設定だとそんなにめんどくさくない。 2番はコピペして修正しなきゃいけなくて少しめんどくさい。これはやらないと毎回アップしたオブジェクトを公開しないといけない。上書きしたとしても。 3番はいろんなツールがありそうな気がする。今回は気にしない。 4番はしゃーない。 というわけで、1番と2番を ruby の aws-sdk をつかってやってみた。 require 'aws-sdk' def s3_static_site(bucket_name) @hostname = bucket_name set_policy set_website end def set_policy bucket.policy = AWS::S3::Policy.from_json(policy_json) end def set_website bucket.configure_website do |cfg| cfg.index_document_suffix = 'index.html' cfg.error_document_key = 'error.html' end end def s3 region = ENV['AWS_REGION'] end_point = "s3-#{region}.amazonaws.com" @s3 ||= AWS::S3.new(s3_endpoint: end_point) end def bucket @bucket ||=

no_picture

LT駆動開発で「CI のある生活」という話をするはずだった

LT駆動開発 01で「CI のある生活 すごい広島の例」という話をするはずでしたが、時間の都合で「すごい広島の例」だけになりました。 LT駆動開発の参加者には、継続インテグレーション(以下、CI)の知らない普通の人もいるだろうという想定で CI の説明をしてみようという試みでしたが、時間がなかったので30枚ぐらいスライドを省略しました。 下記のスライドは省いたスライドも追加してあります。 本スライドは「CI を普通の人に有用性を知ってもらうには」や「Web制作の人にも使いどころを考えてもらうにはどうすればいいか」を考えつつ、ウェブで見つかる CI の説明は開発者よりのものばかりなので、他の説明方法はできないかと考えてみたものです。 すごい広島の中に Travis-CI というサービスが登場するようになりました。 すごい広島の目的の一つに、プログラマではないITの仕事をしてる人に「GitHubの使い方を学んでもらう」というのがあるというのが発端です。 CI って、とりあえずテストを自動実行するところから入る使い方から入るパターンが多くて、自動テストかいてなくて使いどころがなくって使ってないなんて話や「何に使うの?」って話が周りでは多い気がします。 そんな中、「CIサーバってなんだろうなー」と半日考えた結果の答えは「作ることに集中したい」ってことと「継続的デリバリーをするためのツール」ってことだと考えました。 そこで、そこへ至る道を論理的に進めてみたつもりです。 ちなみに継続的デリバリーは読んでいない。 スライドつくってて困ったのは、最初 CI って言葉しか使ってなくて、文脈によっては CIサーバという意味に変化してることがあって、それをどうやってごまかさないのか苦労しました。 気がついたら CI が継続的デリバリーって意味になっていることに気がついて、「これ CI じゃないじゃん」「CI ってなんなんだ」とか、ぐるぐるしました。 あと、統合って説明しにくい。 LT 仕様なのでスライドの枚数の割に内容がないですね。 そんなわけでLT駆動開発なのですが、私はLTをするために、いろいろ考えたので、当日参加した時点で勉強する目的を達成した感があったりします。 参加しなくても勉強になったかもしれない。 他のLTは分野が多岐にわたり、自分が追えてない情報がまとまっていたり、自分にはない発想があったりと、当日は当日で勉強になりました。 LT駆動開発の主旨を説明するために用意したスライドもアップロードしておいたので興味があれば、確認してみてください。 ついでに、スライドの .key ファイルをどっかに残しておきたいと思いつつ GitHub だとローカルディスクにコピーがいるし、悩んだ結果 S3 に置いてみたりしました。 来月にはこのあたりを自動化したりして、この話を整理して話そうかなぁ、と考えていたりします。3月は忙しそうで怖い。 keynotes.eiel.info index.html を自動生成したい。 関連 LT駆動開発という勉強会をはじめるよ - そんなこと覚えてない Travis-CI でコミットして GitHub にプッシュする - 公開鍵認証を利用してみる - そんなこと覚えてない すごい広島のサイトを sitespec に変えてみた - そんなこと覚えてない

no_picture

Devise で登録時にConfirmation Token が不正な値というエラー

Devise で確認メールで確認してから有効にする機能 Confirmable の機能をつかってたのだけど、トークンが不正というエラーがおきた。 この問題は devise 3.1.0 より前で、確認のために送信されるメールの内容をカスタマイズしていれば起きてるんじゃないかと思う。 DBに格納される Token の値が HMAC されるようになったらしい。 Use HMAC on tokens stored in the DB · 143794d · plataformatec/devise · GitHub そのため、画面をカスタマイズしている場合、token の取得方法が変えないといけないっぽい。 -<p><%= link_to 'Confirm my account', confirmation_url(@resource, :confirmation_token => @resource.confirmation_token) %></p> +<p><%= link_to 'Confirm my account', confirmation_url(@resource, :confirmation_token => @token) %></p> 確認メールだけでなく app/views/devise/mailer 内のファイル全部変えないといけない気がする。 confirmation_instructions.html.erb reset_password_instructions.html.erb unlock_instructions.html.erb あたりですね。 蛇足 v3.1.0 ってリリースされたの9月なんだが…さっき気づいたということは…。とおもって Gemfie.lock を git log –patch Gemfile.lock して devise 検索したら、デプロイされたのは最近だった。 参考 直してから探したやつだけど。

no_picture

LT駆動開発という勉強会をはじめるよ

LT駆動開発という勉強会がはじまります。広島で。 「LT駆動開発」というのは、「毎月ライトニングトークすることを前提に普段の開発をしようぜ」という意味らしいです。命名した人が言ってました。私だけど。 「勉強会で最も勉強になっている人は発表している人なのではないか?」ということで、「発表することで勉強をしよう」、という目的の勉強会です。 第1回は3月1日に行われます。 まだ1週間以上あるので準備はまだ間に合いますね。(?) この記事の概要 発表して勉強する 発表しなくても参加しても良いよ 「なんとなく」で、できることを増やそう 発表して勉強する 発表するという行動は人に考えを伝えることです。 何かを伝えるために自分がまず理解している必要があります。 発表の準備をしているとまだちゃんと理解していない点を見つけることができます。 とても勉強になりますね。 人にわかりやすく伝えるには情報を整理する必要があります。 なんとなく理解しているだけではうまく伝えられません。 伝えようとすることでより情報が整理できます。 とても勉強になりますね。 整理された発表資料を残しておくと、説明する手間が省けますね。 他の人が勉強になりますね。 蛇足なのですが、地方の勉強会では発表者が不足がちで、喋り手に困ることがあります。 そういう理由で、広島Ruby勉強会では、クオリティはさておいて、「みんな発表しよう。練習で良いので」という感じでここ1年ぐらい進んでました。 最近は、5、6人の発表者がでるようになりました。 しかし、Rubyというテーマに絞るのはもったいないよね。 そんなわけで、そこから派生したのがのがこのLT駆動開発になります。 もちろん、地方に発表できる人を増やすという裏の目的はもちろんありますが。 発表しなくても参加して良いよ。 見学歓迎です。 発表するというのはハードルが高いし、無理してする必要はないです。 ただし、一番勉強になるのは発表者らしいです。 というわけで、ふらっと来れるように参加費は無料に設定しています。 スポンサーが裏でひっそり会場費を全額払うそうです。6000円ぐらいだっと思います。 誰かの発表を聞いてモチベーションを上げにくるのもOKです。 会場費を払うスポンサーですが、緩やかに募集します。 そんなことよりも、代わりに別の勉強会を開催したり、地域活性化になりそうなこととか、情報リテラシーが向上しそうなことに使ってもらえたら嬉しいなー。 と、私自身は思ってます。 そこで誰かが何かイベントとかはじめて同じような流れになって、どんどんいろいろやる人が増えたらいいなー。 そういう良さげな循環ができるといいなー。 「悪い循環は止めて、良い循環は作りたいな」というのが最近の私の考えのようです。 実はふらっと来てもらう場合、参加費って設定しづらくて、「どこまでを参加者とするの?」というのがあるというのもあります。 会場の ShakeHands さんも面白いところなので、ついでに体験してもらう機会になればと思います。 どんな人を対象に発表すればいいのか? とくに今は設定してません。 参加者しだいなところで、どんな人が参加するかによってちょっとづつ変わっていくと思います。 勉強会を作るのは参加者なのです。 どうするか良いかは参加してる人たちの考えていきたいですね。 なんとなくで、できることを増やそう はじめてやることって、どうしても準備に時間がかかります。 なんとなくやっても人に見せられることを増やせると気楽にアウトプットできるようになります。 たぶん、ブログも最初は一つの記事にたくさんの時間をかけてしまうでしょう。 時間かかると認識しちゃうとだんだん書かなくなってしまいます。 手軽に良い感じの記事がすぐ書けるようになった人はたくさん書いてます。 たぶん、回数とか慣れとか、効率よく書くにはどうすればいいのかちゃんと考えているのだと思います。 発表をすると スライドの作り方を学ばないといけない 人に説明する方法を学ばないといけない 考えを整理すること学ばないといけない (場合によっては)図を書くツールの使い方を学ばないといけない などなど、レイヤーがブレてる箇条書きになってしまってますが、たくさん学ぶことがあります。 いまの段階でなんとなくでどれくらいできるでしょうか。 私はまだまだ全然ダメで苦手なところがちらほらあります。 毎回、新しいことにチャレンジしていろんなことをなんとなくできるようにしたいです。 最近の開発方法ってまずデプロイすることを大事にしますよね。デプロイしてみてはじめてわかることがたくさんあるからですよね。 まずは発表してみて、どんなことをしないといけないか学んでみましょう。 発表になれていても、「どんな人を対象に話をするのか」とか、「もっとわかりやすく伝えるにはどうしたらいいか」などなど発展課題も出てきます。 慣れてる人は次のステップを考えながらやると効果的だと思います。 説明するのが上手い人が増えたら私自身も効率よく勉強できるような気がするんだ。(幻想だったらどうしよう) IT業界の進化は速いので、みんなが効率よく勉強できると良い気がしませんか?

no_picture

すごい広島のサイトを sitespec に変えてみた

すごい広島 #40 で書いてる。 すごい広島には GitHub に馴れるというサブの目的が存在します。 参加者は 「GitHub にプルリクエストをしなければならない」というルールがあって、参加するだけでプルリクエストの練習することができます。 プルリクエストを体験することで、GitHubがどういうものなのか理解してもらおうという魂胆です。 どんなプルリクエストを行うかというと、すごい広島のサイトに情報を追加してもらいます。 すごい広島で何をしているのか GitHubのIssue に書いてもらっているので、そこへのリンクを貼るのが一番簡単な変更となります。 さて本題です。 40回を迎えたことだし、もっと実際の GitHub の作業フローに合わせるためにすごい広島のプロセスの中に CI サーバを登場させることを考えてみました。 すごい広島のサイトは GitHub に生成させていましたが、Travis-CI でサイトを生成するようにしました。 プルリクエストすると Travis-CI でサイトが生成できるかどうか確認します。 これで、プルリクエストを本流にマージする際にサイトが生成できることを確認してからマージすることができるようになりました。 これで少しだけですが、より実際の開発の流れに近づけることができたはずです。たぶん。 下図はTravi-CI でサイトが生成できるかどうか確認中の時のプルリクエストのマージボタンです。 ついでに静的サイトジェネレータを変更する せっかくなので、静的サイトジェネレータもJekyllから別ものに変えることにしました。 GitHub 上でビルドしなくなるので Jekyll でもいろいろできるようになりますが、どうせ機能面で優れたものに変えたいですよね。 候補は middleman か sitespec だったのですが、sitespec を試してみたかったので sitespec にしてみました。 Sitespec sitespec は rspecをつかってサイトを生成します。 Sitespec を使ってみて良い点は、普段のテスト駆動開発っぽいプロセスで開発できて、思考を変えなくてよかったところです。 作成したいページの spec を書いて、 rspec を実行するとそのページが生成できないことが確認できます。 そこからは好きな方法で Rack アプリケーションを用意してあげればよいのです。 あとは通常のウェブ開発と同じやり方になりそうだと、sitespec を使いはじめてすぐにわかりました。 Rails や Sinatra に馴れているのであればそれを使えばよくて、拡張機能もそれぞれのフレームワークのものが使えるし、足りないものがあれば同じ要領で開発すればよさそうです。 新しいことを覚えなくていいし、かゆいところに手が届きます。 また、なにか拡張機能を作れば普段の開発にも生かせそうなのも良いです。 sitespec は柔軟性がありますが、その代わりにやることがちょっと増えたりします。 気軽に作りたい場合は

no_picture

Travis-CI でコミットして GitHub にプッシュする - 公開鍵認証を利用してみる

静的サイトジェネレータとGitHub Pagesを使っていると、Travis-CIでHTMLを生成してコミットを行い、masterを自動で更新して欲しいですね。 普通なら下記の記事の方法で充分でした。 Middleman で作った web サイトを Travis + GitHub pages でお手軽に運用する - tricknotesのぼうけんのしょ しかし、 Organization のリポジトリに対してこの方法を使うとメンバーが私個人のリポジトリを操作ができる気がする。 仕方ないので別の方法を模索してみた。 GitHub には、リポジトリごとに公開鍵を追加する機能があったのでこれを使ってみました。 考えないといけないことは、秘密鍵をどうやってTarvisへもっていくかです。 秘密鍵を共通鍵で暗号化して、リポジトリに追加する方法を選んでみました。 共通鍵を .travis.yml の中に暗号化してに保存しておきます。 この共通鍵の復号は Travis 側で自動的にされます。この共通鍵を使い Travis 側でリポジトリに含まれる秘密鍵を復号します。 秘密鍵さえ手に入れば GitHub に push できます。 やることを整理します。 Travis-CI の設定 秘密鍵と公開鍵の作成 秘密鍵を暗号化するための共通鍵の生成 秘密鍵の暗号化してリポジトリに追加 GitHub のリポジトリに公開鍵を追加 .travis.yml へ暗号化した共通鍵を設定 .travis.yml にGitHubへ pushする処理などを記述 Travis-CIの設定 割愛します。 ログインして、設定したいリポジトリをONにします。 秘密鍵と公開鍵の作成 ssh-gen コマンドを使います。 作る鍵を deploy_key として進めます。 $ ssh-keygen -f deploy_key deploy_key と deploy_key.pub が生成されます。 秘密鍵を暗号化するための共通鍵の生成 適当につくります。shell変数 password に保存しておく例を書いておきます。 $ password=`cat /dev/urandom | head -c 10000 | openssl sha1` 秘密鍵の暗号化してリポジトリに追加 さっき作成した共通鍵で deploy_key を暗号化して deploy_key.encを作成します。 $ openssl aes-256-cbc -k "$password" -in deploy_key -out deploy_key.enc -a あとは適当にコミットします。 deploy_key をコミットしないように気をつけてください。 $ git add deploy_key.enc $ git commit -m 'Add deploy key' GitHub のリポジトリに公開鍵を追加 deploy_key.pub をGitHubに登録します。 GitHubのリポジトリのページを表示して、設定 > Deploy keys > Add deploy key で登録できます。区別がつくように名前は好きにつけましょう。 .travis.yml へ暗号化した共通鍵を設定 travis gem をインストールしていない場合はインストールしましょう。 $ gem install travis travis encrypt コマンドを使用します。 $ travis encrypt -r [ユーザ名や組織名]/[リポジトリ名] "SERVER_KEY=$password" -a .travis.yml の env.global へ情報が記録されます。 すごい広島を例にすると、こんな感じになります。 $ travis encrypt -r great-h/great-h.github.io "SERVER_KEY=$password" -a .travis.yml にGitHubへ pushする処理などを記述 .tarvis.yml の after_success にやりたいことを書きましょう。 鍵の設定の部分はこんな感じ。 after_success: - echo -e "Host github.com\n\tStrictHostKeyChecking no\nIdentityFile ~/.ssh/deploy.key\n" >> ~/.ssh/config - openssl aes-256-cbc -k "$SERVER_KEY" -in .travis/deploy_key.enc -d -a -out deploy.key - cp deploy.key ~/.ssh/ - chmod 600 ~/.ssh/deploy.key あとは煮るなり焼くなり。 すごい広島での例を上げておきます。 _site にファイルが生成されているので、それを master ブランチにコミットしてプッシュしています。 language: ruby rvm: - 2.1.0 after_success: - echo -e "Host github.com\n\tStrictHostKeyChecking no\nIdentityFile ~/.ssh/deploy.key\n" >> ~/.ssh/config - openssl aes-256-cbc -k "$secret" -in .travis/deploy_key.enc -d -a -out deploy.key - cp deploy.key ~/.ssh/ - chmod 600 ~/.ssh/deploy.key - git clone git@github.com:great-h/great-h.github.io.git -b master - cd great-h.github.io - cp -a ../_site/ .

no_picture

手軽にHaskell できる hawk が楽しい

コマンドラインで Haskell のワンライナーっぽいものが使える hawk ってのがあるらしくて、awk に似ているから hawk っていうらしい。 気軽に Haskell の練習できて楽しい。 インストールは $ cabal install haskell-awk らしい。 hoge:goro:mogu goro:mogu:hoge という入力があって 2列目だけ取り出したーいとかなら $ echo "hoge:goro:mogu\ngoro:mogu:hoge" | hawk -d: -m '!!2' mogu hoge という感じらしい。-m を使うと行ごとの処理がかけて -d を使うとデリミタを認識してあらかじめリストしておいてくれる。 それ意外にも情報源にできる。 奇数のリストを作って10個とりだしてみる。 $ hawk 'take 10 [1,3..]' 1 3 5 7 9 11 13 15 17 19 もちろん無限リストだって作れる。 $ hawk '[1,3..]' | head -n 10 1 3 5 7 9 11 13 15 17 19 ~/.hawk/prelude.hs をいじれば、他のモジュールもインポートできる。 Data.Ix でも追加して遊んでみる。 {-# LANGUAGE ExtendedDefaultRules, OverloadedStrings #-} import Prelude import qualified Data.ByteString.Lazy.Char8 as B import qualified Data.List as L import Data.Ix $ hawk 'range ((0,0,0),(2,2,2))' | head -n 20 0 0 0 0 0 1 0 0 2 0 1 0 0 1 1 0 1 2 0 2 0 0 2 1 0 2 2 1 0 0 1 0 1 1 0 2 1 1 0 1 1 1 1 1 2 1 2 0 1 2 1 1 2 2 2 0 0 2 0 1 ひっくくりかえして、 3つとるとかを愚直にかくと、 $ seq 10 | hawk -a 'take 3 .

no_picture

Route 53 の特定の Hosted Zone を IAM ユーザで設定できるようにしてみた

AWSの無料枠のうちにいろいろ遊ぼうと思っていたのに半年ぐらいなにもできてないユーザがこちらになります。こんにちは。 そんなわけでAWS入門者です。がんばります。 AWSへの入門するなら Route 53 や S3 あたりが良いと思います。EC2 とか SNS とかなかなかハードル高いです。あれ、そういえば9月ぐらいに試してる形跡が…。 先日、eiel.info の管理を Route 53 に移してみたら、気持ち表示が速くなった気がします。たぶん、気のせいです。 他にも代わりに管理してる zone があったので、移行してみました。 いままでレコードを追加するのは私がしてたのですが、「本人にも自由に編集できるといいなぁ」と試してみたらできました。IAM を使いました。まー、お金を払うのは自分ですが。+0.5$ 程度なので大したことではないです。 管理コンソールで操作してもらうことを前提にした場合のやることは、 管理する Hosted Zone を作成する(Route 53) 操作者のためのユーザを作成する(IAM) ユーザに作成した Hosted Zone への編集をできるようにする。(IAM ポリシー設定) ログインページとログイン情報を伝える パスワードを変更して貰う 編集ページのURLを伝える といった感じのようです。 管理する Hosted Zone を作成する(Route 53) 管理する Hosted Zone がないとはじまらないので、作成します。 Route 53 の管理コンソールで行えます。 脱線しますが、Bind の zone ファイルからそのままインポートできるようになっていて、移行はとても簡単でした。 作成した Zone Hosted Zone ID を控えておきましょう。後で使います。 操作者のためのユーザを作成する(IAM) ログインしてもらうためのユーザが必要です。 IAMで作りましょう。 管理コンソールへのログインはパスワードが必要になります。 デフォルトでは設定されてないので、パスワードを設定したいユーザを選択して、Security Credentials で Password の設定をしましょう。 パスワードはあとで使用者に変更してもらえばよいです。 忘れたら作りなしましょう。 ユーザに作成した Hosted Zone への編集をできるようにする。 作成したユーザは基本的には何もできない状態です。 特定の zone だけ編集できるようにしてみます。 zone の編集をする行動を許可する作業をします。 IAM でユーザを選択して permission > Attach User Policy で設定できます。 JSONで指定できるのですが、ジェネレータがあるとでポチポチすれば作成できます。 Policy Generator を選択して Select をするとフォームがでてきます。 Effect - Allow AWS Service - Route 53 Actions - All Actions Amazon Resource Name (ARN) - 後述 と指定しました。 ARN には Hosted Zone Id を使用して arn:aws:route53:::hostedzone/[Hosted Zone ID] となります。 このへんの情報は Using IAM to Control Access to Amazon Route 53 Resources - Amazon Route 53 に記載されてます。Policy のサンプル JSON なんかものっています。 ログインページとログイン情報を伝える 準備ができたら相手にユーザ情報を伝えましょう。 ログインするための URL を伝える必要もあります。 ログインするための URL は IAM の Dashboard に IAM User sign-in URL が記載されてます。 https://[Account ID].signin.aws.amazon.com/console 少々長く覚えにくいAccount ID が使用されています。 Alias を作成すると短いものを利用できます。 パスワードを変更して貰う ログインしてもらったらパスワードを変えてもらいましょう。 暗号化された通信路を使用したのであれば気にしなくていいかもしれません。 編集ページのURLを伝える 早速、ログインして Route 53 のページにいっても何も表示されません。 Hosted Zone の一覧を取得する権限がないからです。 直接アクセスすれば表示できるので気にしなくてもいいでしょう。 Hosted Zone ID を使用して https://console.aws.amazon.com/route53/home#resource-record-sets:[Hosted Zone ID] にアクセスすれば編集できました。 その他雑多なこと Hosted Zone の一覧が表示されて構わないのであれば、 ListHostedZones Action に Resource * でポリシーを追加してやれば表示できます。 ListHostedZones には個別のリソースを許可することで表示内容を制限する機能はないようです。 Zoneの設定するのに便利そうな Roadworker などなど使う場合も設定しなきゃいけないんだろうか?

no_picture

iOS でmtimeを設定する

iOS で ファイルの mtime を設定したい事態が発生した。 utimes(2) を利用してもよいのだけど、なるべく Cocoa の領域でコードは書いておきたい。 書き込む前に取得。取得したいファイルパスはわかっているとします。 NSString* path = @"hoge.txt"; NSFileManager* filemngr = [NSFileManager defaultManager]; NSDictionary* attributes = [filemngr attributesOfItemAtPath:path error:nil]; if (attributes) { NSDate *date = [attributes fileModificationDate] } NSFileManager-attributesOfItemAtPath:error で 辞書型でファイルの情報を取得できます。 NSDictionary-fileModificationDate は NSFileManager.h で拡張されたメソッドです。これを使えば取得できます。 書き込みする際は拡張メソッドはないですが、取得した辞書型に値を設定してに書き込みすればできました。 NSString* path = @"hoge.txt"; NSFileManager* filemngr = [NSFileManager defaultManager]; NSDictionary* attributes = [filemngr attributesOfItemAtPath:path error:nil]; if (attributes) { NSMutableDictionary* mattributes = [NSMutableDictionary dictionaryWithDictionary:attributes]; NSDate *date = [NSDate new];

no_picture

そういえば彼氏募集というネタリポジトリがありましたね。真似するならこんな感じかなぁ。

最近、C++界や、ひろし魔界で暴れているらしいまさかず氏が彼氏募集のリポジトリを真似して彼女募集のリポジトリを作成してました。 条件さえ揃えば真似してもよかったのですが、条件が揃ってなかったので真似してませんでした。 気がついたら条件が揃ってたので真似してみることにしてみました。 eiel/need_a_girlfriend - GitHub やったこと fork したけど 空のブランチつくって、fork元とはコード的には関係をなくした Haskell で DSL したかった。結局、Writer モナドの上に構築した。 source ブランチを push すると travis で README.md を生成して master ブランチに自動で push する リポジトリの名前を変更した fork したけど 空のブランチつくって、fork元とはコード的には関係をなくした fork したので、その上から上書きしてもよかったのですが、だいぶ違うし、ゼロからつくりたいけど fork したことは残したいよね。 ということで空のブランチをつくってから作りました。 git checkout --orphan <branch名> で空のブランチが作れます。 Haskell で DSL したかった。 README.md は手書きせずにプログラムから生成するようにしてみました。 まさかず氏を真似ただけである。 Haskell で DSL 作るのにはどうしたらいいんだろうなぁ。たぶんモナド作ればいいんだろうと、コード書きはじめたけど、途中でよくわからなくなった。 それはそれで別に勉強すればいいやということから途中から Writer モナドでつくりました。 background = do h1 '背景' p 'ほげほげごろごろ' みたいに書きたかった。というか、このように書いてから h1 や p 関数を実装しました。 Writer モナド は

no_picture

本当に障がい者でもオープンセミナー広島の実行委員長ができるのか? - 答え: できた。

本記事のタイトルは尊敬できる人生の先輩のブログ名からインスパイアされました。 どうしてこういうタイトルの記事を書こうかと思ったかというと、 オープンセミナー終わったし、「次の目標は?」とか「次のステップは?」と、問われた時に出た答えが 「いままでやってきたことをいままでどおりやりつつも、少しだけ特殊な状況下にある自分を生かせることをしていきたいなぁ」 だっただけです。 このタイトルを見て、「だから、どうした」という感想を抱くのが普通であって欲しくて、 もし「裏切られた」という気分になった方がいたら、本当にごめんなさい。いないとは思っている。 これからはそういう風に扱えという話でもない。 仕切り直します。 「ブログ書くまでが勉強会らしい」ので、私自身のオープンセミナー2014@広島に対する振り返り記事です。 懇親会でLTしました オープンセミナー2014@広島の目標と達成具合 これからの目標とかまとめとか という構成です。 懇親会でLTしました 「オープンセミナー2014@広島の実行委員長になったので…完全版」というタイトルでLTしました。 基本的には忘年会議2013の際につかったスライドを修正しているだけです。 変更点は 前半の告知を削除して、オープンセミナーをやる上でやりたかったことを追加 ブログなどのPV情報を 2013年1月1日 から 2013年12月31日 までのデータへ修正 事前アンケートに差し込んだネタについての話を加筆 です。 何をやるにもマネタイズを考えないと続かないという人もいらっしゃいますが、お客さんがいないと、どうしようもありません。 「広島でセミナーをやることが有用である」というのを示す必要があると思います。 実際に、「広島では人が集まらないから」という理由でいろんなイベントが広島を素通りされているという話を何度か耳にしています。 そういう意味では無料のセミナーを盛り上げるで、「広島は素通りできない」という状態に戻せるはずです。わからんけど。 そういったことを考えながら普段はイベントをしているのですが、 それに加えてオープンセミナーをやる上で、運営のボランティアスタッフにメリットが出るようになったり、実行委員長をやることにメリットがあったり、企業とコミュニティの繋りがより良いものになったりするには、どういったことができればいいのかと考えて、その中で自分でできることをやってみました。 あと、人を集めるには告知をしないといけないのだけど、現状ではもともと届いていた範囲にしか声が届かないのは他のイベントを手伝う上で感じていました。 だから、今まで自分が行かなかったところに顔を出したり、情報発信する際に意識するようにした2013年でした。 あと、オープンセミナーが終わったからといってやめるつもりはなく、同じようにやっていけたら良いと思っています。 あとは完全版にするためにネタを削ってしまったので、事前アンケートは完全に趣味で作った質問があって、そこの紹介もしました。 Emacsは環境だと認識されていて、Vimはエディタだと認識されてる傾向があることがわかったことが成果です。(根拠不充分) オープンセミナー2014@広島の目標と達成具合 オープンセミナーをやる上で立てた目標は表向きには、「参加者90名」です。 事前参加希望者100名、参加者93名という結果になり、目標達成できました。 「本当に達成できるとは思わなかった」という声もあったり、スタッフや講師の協力のおかげであることは言うまでもないです。 ありがとうございます。 話が逸れますが、こんなにたくさん「ありがとうございます」って言った日は他にないんじゃないかな、と思います。 「結婚式をした人もそんな感じなんだろうか?」とぼんやり思いました。 話を戻します。 スタッフ内で共有してた目標としては 懇親会は面白いLTするところ、という空気を作る 企業に協賛をお願いする のふたつがありました。 懇親会は期待以上に盛り上がったと思います。 ドリンクの注文や配るのをみんなに手伝ってもらったり、ちょっと狭かったり、私がドリンクをこぼしたり(ごめんなさい、ごめんなさい)がありましたが、来年もこんな感じになればいいと思います。 LTもみんなにしてもらえるかどうかわからなかったので、私も立候補していましたが、しなくてよかった気がしますね。(逃げたいだけ) 協賛に関しては、できているように見えますが、本当はスタッフとなんの関係もないところから協賛をひとつでも取りたかったです。ちょっとだけ達成できませんでした。 個人協賛枠も用意していましたが、最低限の赤字は防げることがわかったので、お断りしました。 「エンジニアにメリットがあるイベントだからエンジニアが協賛をする」だと、限界があるような気がしていて、輪の外に見えている人たちに協賛してもらって、輪の外にいる人にお返しをする意識を持ちたかったのです。 参加できないから個人協賛したいとかであれば、今思えばありだったかと思います。 今は時間に余裕があったりして、コミュニティに参加して、盛り上げたりできている人もいますが、そうでなくなる人も必ず出てきます。 そのためにも、参加しなくてもできるコミュニティへの貢献方法も探していきたいですね。 自分がそうできるようにしておくためにも、探しておきたい。 でも、協賛の最終形は地元企業からの協賛だと思っていて、コミュニティに協賛することへのメリットをそれぞれが見つけて欲しい、とも考えています。 「人事の点でメリットがある」とか、「情報拡散に効果がある」とか。 その程度しか思いつかないけど、それってこっちから提案するのはちょっと変な気がしていて、アイディアだしするのはできますが、企業側に受け身になられるのは少し嫌だなぁ。 話は変わり、セミナーの内容ですが、全体の統制は全然調整できていなかったのですが、講師のみなさんがその場で臨機応変に対応していただいたみたいで、思ってた以上に綺麗にまとまってしまってビビってしまったのは秘密です。 みなさんすごい。 あとかなりわがままいって司会業をしつつ受付サポートもしてました。 前日に「受付したい」っていったら。 @Toro_kun 司会メインで受け付けサポで。 — えいる (@eielh) 2014, 1月 31 だって、参加者の名前と顔を一致させたいじゃん。個々に挨拶したいじゃん。というか、司会はやりたくない。(結局してたけど) そんなわけでトータルでみて、だいたい目標が達成できてよかったです。 参加してくれたみんな、拡散してくれたみんな、講師のみなさん、スタッフのみなさん、ありがとうございます。 やったぜ!

no_picture

Rubyのオプション変数というグローバル変数

Rails のソースコードを読んでいたら before = $-w $-w = false require 'action_dispatch/journey/parser' $-w = before https://github.com/rails/rails/blob/v4.0.2/actionpack/lib/action_dispatch/journey/router.rb#L6-L9 というのがあって $-w なんだろうと思って調べたら オプション変数というグローバル変数があるそうな。 どうやら -w が指定されているかどうかの判断に利用できる模様。 つまり、このコードは -w がついていたかどうかを保存しておいて requireをして -w をもとの状態にもどす ということをしているようです。 -w は verbose レベルを設定する機能ですが、 ActiveSupportに一時的に変更する機能があったような気がしつつも、調べてない。 もう少し詳しく こういうのは実際に試すのが大事だよね。 指定しない場合 $ ruby -e 'p $-w' false 指定する場合 $ ruby -w -e 'p $-w' true ちなみに -w は -W2 と等価らしいので、これも確認してみよう。 $ ruby -e 'p $-W' 1 $ ruby -w -e 'p $-W' 2

no_picture

Jekyll 使うときは exclude: vendor しとけって話らしい。

素のJekyll なんて使う人はあまりいないと思うけど一応書いておこう。 以前から jekyll build が失敗するっていう話をしてる人がいて自分の環境じゃ、おきてなかったんだけど、bundle install --path vendor/bundle してるのが原因だったらしい。 _config.yml に exclude: ['vendor'] するのがよいでしょう。 ついでに以下のような感じにした。 exclude: ['Gemfile','Gemfile.lock','Rakefile','vendor'] 具体的なコミットはこちら 素のJekyllから拡張してる場合は注意。 middleman などなどを使うことをおすすめしとこう。 自分が発見したネタじゃないけど記録しておいた。

no_picture

UIImage#initWithCGImage:scale:orientation で回転させる話

iOS な作業をしていた。 UImage な画像をてっとり早く回転する方法として、 image = [[UIImage alloc] initWithCGImage:image.CGImage scale:image.scale orientation:UIImageOrientationRight]; というのがある。 みたいなのがあるのですが、2度回転させようとして、下記のように2度呼んで回転しないなぁ、というハマり方をした。 image = [[UIImage alloc] initWithCGImage:image.CGImage scale:image.scale orientation:UIImageOrientationRight]; image = [[UIImage alloc] initWithCGImage:image.CGImage scale:image.scale orientation:UIImageOrientationRight]; 実際に並んでいれば気づくのだけど、違う場所で呼んでる場合は注意。 CIImage の使う向きを変えてCGImageは使いまわしてるだけなので、右に回転させたものを使うだけになる。「右に方向にして使う」という機能なので当たり前なのだけど。 どう対処したかというと、1回目の回転はちゃんと新しい画像をつくって対処した。 CGContextRef context = UIGraphicsGetCurrentContext(); CGContextRotateCTM(context,M_PI); CGContextTranslateCTM(context, -image.size.width, -image.size.height); [image.layer renderInContext:context]; image = UIGraphicsGetImageFromCurrentImageContext(); ちょっと無理矢理感。 移動させてるのは、(0,0) を中心に回転するので、画像が実際にかきこまれる位置が負の領域にいってしまってるから。

no_picture

CodeClimate のカバレッジは SimpleCovの設定がしてあるところだとうまくいかない

CodeClimate で、課金して利用しているとカバレッジを取得する機能がある。 設定方法はここに書かれてる 中身は SimpleCov らしく SimpleCov の設定より先に書いていたらうまくうごかなかった。 仕方ないので削除してみたら、うまくうごきました。 SimpleCov のフォーマッタを差し替えているらしく、両方使いたい場合は、MultiFormatter を使えばよいらしい。 SimpleCov.formatter = SimpleCov::Formatter::MultiFormatter[ SimpleCov::Formatter::HTMLFormatter, CodeClimate::TestReporter::Formatter ] しかし、CodeClimate ではカバー率を表示するだけっぽいのであまり使いどころがない感じでした。

no_picture

C++勉強会in広島でオープンセミナー2014@広島の告知を兼ねたLTしてきた

C++勉強会in広島に参加してLTしてきました。 テスト駆動開発がオープンセミナー2014@広島のテーマのひとつなので、C++ のテスティングフレームワークである CppUTest を試しすことで告知するという手法をとりました。 C++は大学生のころ勉強していたようなそうでもないような、More Effective C++ ぐらいは読んだかなぁ。 そういえば丸善出版で再販されるそうですね。よかったよかった。 冷静に考えると C++ で書いたプログラムをビルドするのに Makefile を書いたのは、はじめてな気がしたり、clang++ をコマンドから使うのがはじめてだったり、LT をしようとすることでいろいろ勉強になるなぁ、と感じました。 勉強会があるので、そのために勉強するのも良い方法だと思います。 「まとめ」が「まとめ」じゃないって言われたので、今度から「いろいろ試した結果、最終的な結論」とかにしたいと思います。 実際に動作確認するのに使用したソースコードは GitHub に置いています。 src/test_runner.cpp がテストを実行する部分です。 src/factorial_test.cpp がテストコードです。 src/factorial.hpp が階乗求めるプログラムの実装部分です。 make を実行するとビルドしてテストを実行するようにしています。 そういえば test というディレクトリを最初つくっていて、 make test した時に test ディレクトリがあるせいでうまく動かなかったりしました。 一般的にはどうするんだろうか。 その他の発表 南山まさかず氏 の Template Meta Programming なんかは全く知らない世界でした。 シンタックスを気にしなきゃ、純粋関数型プログラミングと見なせるようだったので、がんばれば使えそうな気がしてきております。 ちょっとぐらいサンプルコードを書いてみたいと思いますが、コンパイルエラーの解読がきっとつらいんだろうなぁ、と想像してます。 スライドはここにあるらしい uchan_nosさんのC++でできる!OSの自作入門は、知ってる範囲のこともあったりそうでないところもあったりでおもしろかったです。 プログラム書いてたらOSの仕組みやらブートシーケンスはやっぱり知りたくなりますよね。 「フリースタンディング環境」という言葉は初めて知ったので、いろんな言語のそのあたりの状況もちょっと気になっております。 スライドはここにあるらしい その他、全体の雰囲気はTogetterのまとめをみるほうがわかりやすいかもしれない。

no_picture

ActiveRecord のスコープを書くときは proc を使えよって話

ActiveRecord で scope を定義する時は、普通は以下のように書きますよね。 scope :hoge, -> { where(name: 'hoge' } 歴史的背景で、 scope :hoge, where(hname: 'hoge') とか、書いてることがあるかもしれません。 この場合、一応、問題なく動きますが、コンテキストに応じて値が変化するようなものを利用してる場合には問題が起きることがあるので、早めに修正したほうが良いかもしれません。(というか問題が起きた) 前者で書きましょう。 具体例 特に日付などを利用してると問題になりやすいかもしれません。 例えば、 scope :this_month, where(month: Date.today.month) というのは、月を跨ぐと問題になる可能性が高いです。 常にデプロイした月の結果を返すことになります。 クラスをファイルを読み込みした際に Date.today.month が評価されてしまうので、そこの値が固定されてしまいます。 scope :this_month, -> { where(month: Date.today.month) } という風に書き換えておいたほうが良いです。 年とか使ってると気づかない可能性高そうですね。怖い怖い。

no_picture

cmigemoがインストールできない - openlab.ring.gr.jp が死んでるっぽい

Twitter に書いてもあまり反応がないので、blogにでも書いとくとなんとかなるかもしれないのでかいておくことにする。 http://openlab.ring.gr.jp/ が死んでるっぽくて $ brew install cmigemo が失敗してしまう。 もしかして ddskk とかも一部インストールできない状態なんだろうか…。ミラーとかないんだろうか。 詳細 $ brew install cmigemo ==> Downloading http://cmigemo.googlecode.com/files/cmigemo-default-src-20110227 Already downloaded: /Library/Caches/Homebrew/cmigemo-20110227.zip ==> Patching patching file src/wordbuf.c ==> chmod +x ./configure ==> ./configure --prefix=/usr/local/Cellar/cmigemo/20110227 ==> make osx ==> make osx-dict 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (56) Recv failure: Connection reset by peer make[2]: *** [SKK-JISYO.L] Error 56 make[1]: *** [dictionary] Error

no_picture

pandocのインストールに失敗する

hakyll のアップデートしてたら pandoc のビルドにこけた。 エラーの内容は下記のとおり。 src/Text/Pandoc/Readers/Haddock/Lex.x:149:46: Couldn't match type `(AlexPosn, Char, String)' with `(AlexPosn, t0, t1, [Char])' Expected type: (AlexPosn, t0, t1, [Char]) Actual type: AlexInput In the first argument of `go', namely inp' In the expression: go inp' sc In a case alternative: AlexSkip inp' len -> go inp' sc ぐぐったら以下が出てきた https://github.com/jgm/pandoc/issues/815 というわけで下記を実行してみた。 cabal install alex 再度 install してみたら成功した。 失敗したファイルが *.x なファイルだけどコンパイル前に alex で処理されるんだろうか…よくわからない。そのうち調べたい。

no_picture

オープンセミナー広島は広島のITエンジニアが集う場所

オープンセミナー2014@広島の実行委員長です。こんにちは。 2014年2月1日(土)にオープンセミナー2014@広島という参加費が無料のセミナーがあります。 この記事の目的を平たく言うと、公式サイトとは違うアプローチでイベントの告知をすることです。 ここに書いてあることは私個人の考えで、他のスタッフがどう考えているかも別ですし、イベントの主旨とも関係ない部分もあります。 そんなわけで、アジェンダです。 テーマに興味なくても参加しようぜ やっぱり企業に協賛して欲しい 行くのが怖いなら小さなイベントからどうだろう 本番は懇親会らしい 将来の委員長が会いたい人を呼べるイベントになればいいのに ほんの少しだけ主観での講師紹介 どんなイベントなのかをもっと知りたい場合はウェブサイトのほうをご覧ください。 そちらのほうが効率が良いでしょう。 サイトのダメだし助かります。 Pull Request だともっと助かります。(まて テーマに興味なくても参加しようぜ もし、参加しない理由が「行ってもいいんだけどテーマとかセッションに興味がないんだよなぁ」という人に伝えたいことを書きます。 イベントに参加して周りに影響与えることが自分の興味のあるイベントを作ることになると思うのだけど、どうだろうか。 興味のあることに需要があることがわからないと大きなイベントで扱われるのは難しいです。 知られてないものであればあるほど、知ってもらわなければ興味を持つ人は増えないです。 ぜひ、参加者と話をしたり、懇親会でライトニングトークをしたりして興味のある人を増やしたり、詳しい人をみつけに来てください。 参加者の多いイベントで目立ってください。小さなことがはじめてよう。 今回はTDDやアジャイルというテーマですが、それとは別にたくさんの興味をもった人が来ることで「面白い出会いがあるといいな」と期待して来る人が多いと嬉しいです。 テーマはセミナーを作る骨組みですが、この先オープンセミナーで継続していくだろうことを考えてみると大事な部分は出会いだと思います。 これは、懇親会が本番という話にも繋ると思います。 「投票に行くか行かないか」みたいな話に似ている気がする。 もちろんセッションも楽しめるほうが良いと思うので、その辺はがんばりたいです。事前アンケートも講師にも見てもらってできる範囲で内容を調整してもらったりしています。 やっぱり企業に協賛して欲しい 赤字になりそうであれば、個人協賛枠も考えているのだけど、私自身は企業協賛だけでなんとかしたい。 無料のセミナーという性質上、予算がありません。 スポンサーを募ることになります。 スポンサーにとって価値のあるイベントにしなければなりません。 そうすると、自分達のやりたいことから妥協せざるを得ない点が出てきます。 スポンサーのメリットの中心は広告効果です。 集客効果がある選択をせざるを得ないのです。 イベントの参加予定の人が個人協賛をしたいという声はいくつかあるのですが、なるべく企業協賛のみでなんとか黒字になるのが個人的には理想的です。 個人協賛をやりたくない理由は、参加者がいろいろ学んだり、学ぶことを効率化することによってメリットを得るのが最終的には企業であって欲しいからです。 企業が技術者に投資することに価値があるようになって欲しいのです。 技術者がお金を出して、技術者がメリットを得るような世界に先が見えないのです。 だって、お金を産み出しているのは経営者なのですから。 どんどん広島のIT企業を巻き込んでいきたい。 経営者にとって技術者が自ら進んで学ぶことが価値あることにしたいんだ。 技術者が昇進していくために、技術者を辞めてくのも嫌なんだよなぁ。 そういうわけで、「広島のIT技術者を盛り上げる手伝いをしたいなぁ」って経営者さんからの連絡お待ちしてます! 現時点での協賛を決めてくださったオレンジシステムさんやまほろば工房さんは本当に感謝しきれません。 この時点でもっとたくさんの企業を紹介したかった。ぐぬぬぬ。 行くのが怖いなら小さなイベントからどうだろう 知らない人ばかりのところに行くのは怖くないですか? 怖くない人もいるでしょう。 ちなみに、私は怖いし、知り合いが少ないところへいくとたいていポツーンとしてます。 自慢ですが、ぼっちスキル高いです。かなりの孤立率です。 話が逸れた。 行ってみたいけど、ちょっと怖いなぁ、という方は、まずは小さなイベントから行ってみるのはどうでしょうか。 参加者が少ないイベントではお互い名前を覚えやすいですし、よくいろんなイベントへ顔を出す人が多かったりでアットホームです。 ゆるいです。 広島界隈では、すごい広島が毎週やっていて、人数も少なくて気軽です。 事前に Twitter なんかで絡んでおくと少し楽だと思います。 これで準備体操もしたので怖いものはないですね。 オープンセミナー2014@広島に行きましょう。(ちょっと無理矢理感ある) 本番は懇親会らしい あれ?勉強会って懇親会が本番じゃないの? つくばに来てから,何度か勉強会に参加することがありました. そこでカルチャーショックだったのが「懇親会が地味」ということです. 時羽金也の技術帳: 岡山から離れて9ヶ月 〜岡山を離れて変わったこと,変わらなかったこと,etc〜 岡山の勉強会は懇親会が本番らしいです。 「ライトニングトークは5分間にどれだけ笑いをとるのかが大事」と言う人もいました。 小さい勉強会は懇親会が本番じゃなくてもいいのですが、年に数回ある大きいイベントは懇親会も本番だといいな、と思います。 ちゃんと技術ネタで笑いを取れるLTをする人が何人もいるととても楽しいです。 楽しいと仲良くなるきっかけにも増えます。 秘蔵のネタをひっさげて遊びにきてください。 ヤジるだけでもきっと良いでしょう。 今回の懇親会は40名までとなってますが、参加したい人が多い場合は立食に変更して増員も可能です。 開催ギリギリなると変更は難しいと思うので早めに登録お願いします。 将来的には懇親会の中でもいろんな企画を用意できたらいいのにな。 将来の委員長が会いたい人を呼べるイベントになればいいのに 委員長は毎年交代するのがオープンセミナーの伝統となってるみたいです。 あまりその辺の伝統を私自身理解してないし、やりたいようにやってみていますが、 将来、委員長になった人がその時に広島で輝いてるエンジニアになってるといいと思います。 それだけじゃなくて「輝いたご褒美みたいになるといいな」って思っています。 そのひとつが、「会ってみたいけどなかなか会えない人を呼ぶ機会を作れる」かなと思います。 他にもメリットを作れたらいいのですが、まずはここから。 ほんの少しだけ主観での講師紹介 少しだけ私の主観で講師を紹介したいと思います。 今回の目玉講師とも言える和田さんです。 私が和田さんのことを知る機会となったのは以下の記事です。 RSpec の入門とその一歩先へ - t-wadaの日記 RSpec というテスト駆動開発を行うために利用されるテスティングフレームワークを試している時に上記の記事に出会い、たいへん参考になりました。 基本的な使い方は抑えていましたが、実際の流れが見えて感動した記憶があります。 はてなブックマークが647もついてるだけでのこの記事の素晴しさを物語っていると思います。 テスト駆動開発という手動自体まだ模索する部分もたくさんあります。 ぜひそのエッセンスに触れてください。 あと折角なので、この方も紹介しておきたいと思います。 @kakenavi’s (かけなび) Best Tweets 最高 1582 fav とか想像を絶する数字ですね。 ハードルあげてマジごめんなさい。 まとめ 年の一度のお祭りみたいになって、内容問わずITエンジニアが集まる場所になれば良いと思っています。 そのために、2014年度は2015年、2016年に繋るような下地づくりに挑戦してみたつもりです。 次年度の規模が小さくならないように下記の二つが達成できたらいいなぁ。 イベントの参加者を90人以上を達成したい 懇親会を盛り上がる 勉強会という観点でみると都会のほうがいろんな人がいて楽しいと思います。 (not 大都会) でも、さまざまな理由で地方でがんばっている人たちがいます。 地方には地方で良いところがあり、距離があることによって違う文化が育って、都会の人たちが「遊びにいこうかなー」と思うようにしていきたいですね。異文化交流すてき。 「都会に負けたくないなー、地方に負けたくないなー」って競争心がもっともっと楽しい世の中をつくることになると思います。 たぶん。いや知らんけど。でも、そう信じとく。 この想いはどの辺りまで届くんだろうか。えいやっ!

no_picture

2013年のふりかえりをする

2013年も残り1週間なのでふりかえっておいて来年の目標を考える準備をする。 1月 WTM-summaryを作るustをした気がする。そういえば放置されている。はよ完成させたい。 オンラインで Auto Layout の勉強会をした 関数プログラミング入門 Haskellで学ぶ原理と技法の読書メモを残したりしてみた。一章で終わってるので続きをしたい。 GitHub スパム判定される事故がおきた 2月 広島Ruby勉強会 #027 で Fiber について簡単に紹介した。 Git がわからなくても Github を使おう という記事を書いたらアクセスがいっぱいきた。 Cucumber のフィーチャの文法 - Gherkin とか書いてじわじわアクセスがある。 Github Pages について整理しておきます もそこそこアクセスがきてる 3月 広島Ruby勉強会 #030 で Liquid について喋った。 4月 広島Ruby勉強会 #031で、Hakyllの紹介をした gherkinに出した pull request が取り込まれた railsdoc.eiel.infoの毎日更新をはじめた。最近ちょっとサボり気味。 Web Touch Meeting #56で軽量マークアップ言語について喋った Ruby on Rails にいくつか Pull Request 出したりしてみた。 広島マックユーザーグループ|4月28日(日曜日)の勉強会 で「黒い画面入門 と その応用例」という話をした。 「数学文章作法 基礎編」に感動していた。まだ持ち歩いている。 5月 Githubの楽しみ方という記事を書いたら390はてぶついた。 OA@ITで遊んでたみたい ForKanjiをつくってた形跡があるけどこれも完成してない気がする すごい広島はじめた。 6月 広島Git勉強会 201306で「やりなおせるGit入門」というセッションをして、スライドを公開したら440はてぶとかいった

no_picture

Wisper 試した

Wisper を試した。 Rails のプラグインで、依存性の管理や分離ができる。 ActiveRecord の callback だと依存の記述がモデル上になって、 Observer は本家から外れたような気がするし(うる覚え)、 ActiveSupport::Notification じゃ依存性がゆるすぎる。 でも、コントローラでかくにはちょっと処理が多すぎるし…って時に探してたらみつけたプラグイン。 やってることはどれも大差ない気がするんだけど、とりあえず、公式のサンプルコードをみてみる。 class BidsController < ApplicationController def new @bid = Bid.new end def create @bid = Bid.new(params[:bid]) @bid.subscribe(PusherListener.new) @bid.subscribe(ActivityListener.new) @bid.subscribe(StatisticsListener.new) @bid.on(:create_bid_successful) { |bid| redirect_to bid } @bid.on(:create_bid_failed) { |bid| render :action => :new } @bid.commit end end create_bid_successful が発生したときはリダイレクトして、create_bid_failed が発生した時は new を render するというのをアクションでかける。 ifの分岐がなくて、縦にコードが並んで複雑な分岐をする場合は読みやすい。 また、Listener を登録することで機能追加ができる。 create_bid_successful イベントがおきたときは、PusherLister#create_bid_successful や ActivityListener#create_bid_successful、StatisticsListener#create_bid_successful なんかも呼ばれる。 Set で保存されてるようなので順番は保証されない メインの処理をモデルで集中できて少し脇道に逸れるようなものは Listener を書いて subscribe

no_picture

設定画面で表示する値をアプリ側で設定する - iOS Second Stage Advent Calendar 2013

この記事はiOS Second Stage Advent Calendar 2013の19日目の記事です。 Advent Calendar に参加したのはギャングであるaguuu の中の人に脅されたわけではありません。 iOS のアプリケーションを iOS自体の設定画面で設定を行えるアプリケーション があります。その画面内に稀にバージョン番号が表示されているようなものがあると思います。 これを行うには方法として紹介されているのはビルドする際に値を差し替える方法があります。 ググるとこればっかりでてきます。 参考: アプリのバージョン、ビルドを「設定」の初期値として設定する 今回はそれをせずに、アプリ内で設定できたので紹介しておこうと思います。 動的設定とでも言えばいいのでしょうか。 この設定画面を用意する方法は Settings.bundle を追加し Root.plist を作成することで作ることができます。 今回のゴール バージョンってタイトルには書いてますが、最終起動時刻のほうがわかりやすいので、最終起動時刻に焦点を当てます。 、設定画面に値を表示するには、Setting Bundle を追加します。 root.plist に type を table のアイテムを追加し、DefaultValue を設定します。 DefaultValue を設定します。 大事なことなので強調しておきます。 あとは [NSUserDefaults standardUserDefaults] に値を書き込めばよいです。 NSUserDefaults* userDefaults = [NSUserDefaults standardUserDefaults]; NSDate* now = [[NSDate alloc] initWithTimeIntervalSinceNow:0]; [userDefaults setObject:[now descriptionWithLocale:[NSLocale currentLocale]] forKey:@"lastLaunched"]; とっても簡単ですね。 プロジェクトファイルはこちらにおいておきます たまたま最初に思いつく方法を試したらうまくいきました。(最初は Documents や Cache ディレクトリの中身を確認して plist を直接書き換えたなんて言えない…。しかも、何か勘違いをして UserDefaults

no_picture

knife のログレベルの設定

knife solo でエラーがでるけど、どこで起きてるかわからねぇ。 というわけで、pry を差し込みして調べた。ぐぐってトップのほうにあるのは 「やり方がわからない!」って、なっていた。悲しい。 結論としては、knifeの設定ファイルである .chef/knife.rb や ~/.chef/knife.rb に以下を追記すればいい verbosity :debug :debug としてるのは分かりやすくかいただけで、 nil や 0 、1 で ない値であればいい。 参考: https://github.com/opscode/chef/blob/11.8.2/lib/chef/knife.rb#L373-L380 case Chef::Config[:verbosity] when 0, nil Chef::Config[:log_level] = :error when 1 Chef::Config[:log_level] = :info else Chef::Config[:log_level] = :debug end これぐらいならドキュメントにかいてありそうだけどソースをみてしまった。 追記 -V でログレベルが変わる模様 -VV で、さらに変化する。 -V で出力がかわんなかったから油断した。(いいわけ) 関連 やっと Chef Solo はじめた

no_picture

忘年会議2013 に参加して LT したり、表彰されたりした

合同勉強会の懇親会ともいえる、忘年会議2013に参加しました。 その中で告知メインの LT してきました。 オープンセミナー2014@広島の告知がメインで、その後に今年のアウトプットのふりかえりをしようと思ったのですが、余裕で時間が足りませんでした。 そもそも「8分ぐらい喋ってもいいよね」なんて甘い考えがよくありませんでした。 スライドは喋ったところまで公開したいと思います。 完全版をオープンセミナー2014@広島 懇親会でやろうかと考えています。 ほとんど告知なので大したことは書かれていません。 数値は12月10日時点のものです。 この後は、アクセスの多かった記事の具体的なPVなどを紹介して、「量が質に転化したかなぁ」という話をするつもりでした。 他にはざっくりとした広告収入の話とか。 あと、20枚ぐらいありました。 大都会アワードの授与式 忘年会議では他には、「大都会アワードの授与式」なるものがあって10人以上表彰されていました。 そういえば、私も表彰状頂きました。 本当にありがとうございます。 人生で表彰状なんてもらった記憶が他にない!! ピントを合わせるところを間違えた気がする。 表彰するのは良いことだと思いました。どこかで真似していこう。 まとめ こんなにたくさんの IT 技術者が集まり LT のある懇親会は広島にはないので、オープンセミナー2014@広島の懇親会で実現できたらいいなぁ。 といっても座れる定員の40が限界そうではあるのですが…。 もし、いっぱいになるようであれば、立食形式も検討したいと思います。 関連 流れるようにプログラミングしたい - 合同勉強会 in 大都会岡山 2013 Winter

no_picture

流れるようにプログラミングしたい - 合同勉強会 in 大都会岡山 2013 Winter

合同勉強会 in 大都会岡山 -2013 Winter- でライトニングトークをしました。 合同勉強会という名前からわかるように各勉強会からいろんなスピーカーがやってきて、セッションをします。 私はHiroshima.rb・すごい広島・WEB TOUCH MEETING からやってきたという形でライトニングトークをしました。 「流れるようにプログラミングしたい」というタイトルです。 Ruby で読み書きしやすいプログラミングをしたときの問題点を紹介しつつ、Haskell の良いところを紹介するといった内容です。 内容も多かったのでかなりの早口で喋りました。 コードはこちらら Ruby で関数型の思考でプログラミングをすると自然と流れるようなコードになりますが、問題があり、データをすべて読み終えないとプログラムが実行されないという状態になります。 その例が flow.rb のプログラムです。 puts ARGF.each_line .map(&:to_i) # 数値に .map { |n| n * 5} # 5倍する .select { |n| n > 10 } # 10より大きいものだけに .first(5) # 最初の5つ Haskell を使用した場合は、そのまま書いてもこの問題はおきず、現時点で処理できる時点まで処理してくれています。 main = do getContents >>= ( return . take 5 . -- 最初の5個 filter (>10) . -- 10より大きいものだけに map (*5) . -- 5倍する map read .

no_picture

UIWebView の UserAgent を変更した時に気をつけたいたった1つのこと

iOS SDK のUIWebView は UserAgent を変更することができます。 [XCODE] UIWebViewを用いる際にUserAgentを独自に設定する方法 UserAgent を変更したときに気をつけておきたいことを書きたいと思います。 UserAgent によって条件分岐する JavaScript ライブラリがあることを忘れないようにしましょう。 3時間以上たたかって、Google検索しても、なんにも情報ないし、「もうわからんわー」って投げ出したくなったところ JavaScript のライブラリのソースコード読み始めて、ようやく気付きました。 なるべくもとの UserAgent を尊重するほうが生きやすい世の中かもしれません。

no_picture

近畿大学のIT交流勉強会 2013 に参加してきた

近畿大学 工学部 情報学科の IT 交流勉強会に参加してきました。 2013年版。残念ながら固定リンクがない。 オープンメディアラボ開設記念ということで学生に自分から学ぶきっかけをつくるための施設づくりをしているようです。 というわけで、その中で稲妻トークを一本してきました。 稲妻トークというのはライトニングという言葉から連想した、近畿大学オリジナルの名前です。10分のライトニングトーク風になるように挑戦してみました。 裏テーマは「ライトニングトークがどんなものか体感してもらう。へたくそでも大丈夫」というのでやりました。 速すぎると言われたので、「リハーサルをちゃんとやらないといけないなあ」と、思いました。あと事前にイメージトレーニングが足りなくて話そうとした内容をいくつか飛ばしてしまいました。 反省点が毎回あるのは良いことです。 私より前の発表者でアウトプットの利点が説明されていて、その部分はちょうど省いていて、アウトプットの利点の部分はネタにしていたので、個人的にはラッキーでした。 Speaker Deck 応援週間ということで Speaker Deck にアップしました。 Slide Share は PV とかわかって良いのですが、Ruby製を応援したくなる病。 ちゃんと解説 募集が「稲妻トークの募集」だったので、タイトルを「ライトニングトークをしよう」にすると非常に危険そうになって良さそう、ということでこれに決めました。 それだとストレートすぎるので、ターゲットは学生なので音ゲーネタから「お米の美味しい炊き方、そしてお米を食べることによるその効果。」を参考にタイトルをつけました。 しかし、知ってる人が誰もいませんでした。 セッションの目的は「地方の勉強会は発表者が足りてないので、ライトニングトークの練習をして発表者になれる練習をして欲しい」というのが主なところです。 そこで、発表者になることのメリット。もっと一般的にしてアウトプットすることのメリットについて前述のとおりざっくりと喋りました。 「アウトプットすると情報が集まる」のは実際によくあって、アウトプットする人は自分の必要な情報をうまく集めます。そんな話はしわすれたけど。 うまく使うと効率よく勉強できます。 あとは、これからライトニングトークができそうな勉強会を駆け足で紹介しました。 そこが速かったのかもしれませんが、スライドをアップロードしてるのでそっちを見て欲しいということでおまけをつけています。学生さんは見てくれるでしょうか。 自己紹介の定番であるベストツイートが省略されたのは現地でネットが使えなかったからです。 今回、自分の中で挑戦したことは10分というのはライトニングトークとしては長めなので、中盤に大きなネタを突っ込んだことです。 自分をネタにすると他人の誹謗中傷にならなくて使いやすいですが、自分で直視できない問題があります。 ソーシャルの力を使うで、ガッチャマン クラウズ の話を入れたかったりしたのですが、時間の都合で入れませんでした。 最近は「一人でできることには限りがあるなぁ」と感じているので、みんなの力を借りれるようになりたいです。 そのためには、やることを「社会的価値あることにしたりしないといけない」というのを感じてます。 まー、実際みんな、そんなにがんばる必要はないと思う。 直近の勉強会リンク WEB TOUCH MEETING (12⁄14 土) Web界隈の勉強会。ジャンルが幅広く毎月。 発表に挑戦してみたい勉強会。 岡山 合同勉強会 (12⁄14 土) 年に一度の岡山周辺のIT勉強会が集う。エンジニア向け。 岡山 忘年会議2013 (12⁄14 土) 合同勉強会の後のお祭。本当の戦いはここから。一度いってみるべき。 C++勉強会in広島 (01/11 土) 大学生主催。もう定員いっぱい。部屋がひろくなったりしないんだろうか。 オープンセミナー2014@広島 (2⁄1 土) 年に1度の大きな勉強会。懇親会LT可能!岡山に負けてられない Hiroshima.rb

no_picture

今すぐフォローしたい!?広島のすごいTwitterユーザを紹介

本記事はすごい広島 Advent Calendar 2013の1日目の記事となります。 タイトルは釣りです。 個人的に紹介したい広島の人を紹介したいと思います。 紹介したい人はいっぱいいるのですが Twitter ユーザに限らせていただきます。 基本的にITエンジニアの人ですが、一部例外があります。 また、すごい人なんだけど、ツイートがあまりない方も対象外にしてます。 明確な基準はありません。 といっても、フォローしている人を上から順に眺めて選んだだけという説もあります。 そして、すごい人なのにうっかり漏れた人もいるかもしれないですが、そこは本当にごめんなさい。(ガクガクブルブル) 順番は意味がありそうで適当です。 kakenavi 外したくても外せない。 伝説の「デスマ神」と言われているがその真相は不明。 Twitter界でも普通に有名人。 リアルでは「おもったほどおもしろくないですね」と、言われることがあるそうな。 しかし、彼の本質はそこではない。 でも、これ以上語ると私がデスマになってしまうので、これ以上語ることができない。 噂によると彼のツイートのまとめたサイトがあるらしい。 その破壊力はあまり知られていない。 NeXTSTEP2OSX ITエンジニアではない。 どちらかというと広島弁で有名。 しかし、プログラミングスキルを有し、その辺のプログラマよりプログラムが書けるかもしれない。 Emacsユーザ。 あまり知られてないがキーボードも変態度もなかなか高い。 Cocoaの勉強会の主催もしている。 24motz NVDAというスクリーンリーダの日本語版の開発者。 私の中で有識者という立ち位置を確立している。 いつも自分にない視点からの素敵なアドバイスが飛んでくる。 Git ネタをよくふぁぼられる。 バージョン管理システムに思い入れを感じる。 moobay9 今、広島でもっとも売り出し中のインフラエンジニア。 広島の救世主として知られている。 ちょっと持ち上げすぎると怒られる。 すばらしいほどの広島愛を「広島のアニキ」といえばこの人!になるように仕向けているがあんまりうまくいってない。 pecosantoyobe 次期エースと勝手に言ってて、いつも迷惑をかけている。 ネタ力が高い。 しかし、ネタ力が高すぎる故に理解されていない感がある。 たぶん、先を行きすぎているのだとおもう。 私より GitHub の Star がアクティブで参考になる。 keiso 広島のコミュニティを支えている人達の中でひとり。 かなりの存在感。 広島MacUGやAUGM広島の代表者。 「調べれば keiso」という異名があって、ブログの更新量が多く、質も高い。 それだけ引き出しもすごく多い。勉強になる。 akira345 今回紹介している人の中で明らかに違う方向に Geek。 ハードに強いのに、ハードっぽい仕事あまりしていない。 自分とは違う方向に知識の幅が広いので、参考になる話をたくさん聞ける。 soudai1025 「#た」 の人と言うと伝わるから不思議。 紹介してる人の中でも県外でもなかなか知名度が高いイメージ。(実際はよくわからない) 広島に入れていいのか謎の福山在中。

no_picture

Dart で遊んだ

Dart の 1.0 がリリースされたらしい。 ということで、2013年11月の広島Webシステム開発で遊びました。 基本的には Try Dart を写経しました。 ウェブサイトから「Dart Editor」や「dart VMを組み込んだ chromium」や「JavaScriptに変換する dart2js」などなど一式含んだファイルをダウンロードできます。 Dart Editor を使えばすぐに Dart をはじめることができます。 ウェブアプリケーションも作成できますし、コンソールアプリケーションも作成できます。 コンソールアプリケーションは dart という実行ファイルが添付されているのでここから実行できます。 また、添付されている chromium も Dart VM を組み込みした特別なものみたいなので、Dartがいろんなブラウザで動くようになるのもまだまだ先になりそうです。 JavaScript に変換できるので、Dartで作成したアプリケーション自体は動かすことができるようですが、試していません。 あとは Try Dart を試していて気づいたこと書いていきたいと思います。 セミコロンは必須 セミコロンかくのめんどくさい。 Dart Editor 括弧とか「閉じ括弧」が補完されるようなものは入力が終わったときに TAB を押すと良い感じになるのを知った。 たぶん、eclipse はだいたいこのような挙動なのだろう。 添付chromium でも bootstrap に JavaScript が必要 Dartでつくったウェブアプリケーションは HTML に packages/browser/dart.js という JavaScript を読み込んでいて JavaScript から Dart エントリポイントが呼び出されるようです。「なんだって!」って気分でした。 他の Google 技術との親和性 例えば Polymer がすでに Polymer.dart としてポーティングされてたりする。 Polymer はチュートリアルにも登場する勢い。 Angularもすでに利用できるみたい。 ..

no_picture

RubyKaja 2013 に選ばれたんだ

そういえば RubyKaja 2013 に選ばれました。 RubyKaja はコミュニティごとに選出されます。 選出したコミュニティはHiroshima.rbさんです。 「なぜ選ばれたのかわからない!!」なんてことはなく、コミュニティの会場準備係(言いだしっぺ)だからでしょう。 そんなわけで選出の際にあえて自分が選ばれにくい方法考えたのですが、見事に失敗しました。 ということで、2014年も RubyKaja の選出があるはずです。 私がやるべきことは、** RubyKaja に選ばれたい人を増やすということでしょう。** 盛り上げていこう。 2013年の Ruby Kaja はなんと RubyKaigi2013 で授賞式が行われました。 たくさんの Rubylist がいるなかで祝われます。(行けなかったので雰囲気はよく知らないし、岡山を除くと県外にほとんど知り合いがいないので私の紹介の時は静かだったという噂もありますが。) ちなみに、RubyKaigi 2013 は5月末にありました。なぜ今頃、私は記事を書いているのでしょうか。 答えはノベルティが届いたからです。 いやだってなんかないと実感湧かないし、記事だって書けないじゃん 刮目せよ。このカッコイイ扇子とカッコイイステッカーを! 扇子のほうのRubyKaja という文字が見えづらい…。 まあいいや、MacBook に貼りつけてみよう。 読みかけの「プログラマのためのSQL」が眩しいですね。 どうでしょうか、皆様。たぶん13枚しかないRubyKaja2013とかけなびシールです。 そう、今ここに「私だけの Mac子さんが今誕生した」 しばらくは扇子の自慢をすることで RubyKaja 2014 を盛り上げていきたいと思います。 あと RubyKaigi に行く方法も考えたい。 まとめ Ruby 盛り上げようぜ。 ちなみにわかると思いますが、ステッカーは乗せてるだけで、まだ貼ってない。

no_picture

GitHub からの通知が迷惑メールになった - 見ないリポジトリは unwatch しよう

すごい広島での出来事である。 いつかなる気がしていた。 GitHub からの通知のメールが迷惑メールとして判定された。 多数のユーザが同様のメッセージを迷惑メールとして報告しています。 迷惑ならそもそも通知が来ないようにするか、単に自動でアーカイブするようにして欲しいですね。迷惑メール報告すること自体が迷惑になります。 私が知る限りの通知の設定方法を紹介しておきます。 GitHub は常に進化しているので、動作や画面はいずれ変わってしまうかもしれません。 そもそもの通知設定 「GitHub からメールに通知して欲しくないよ!」という人は基本的な設定を見直しましょう。 Noticification Centerにアクセスをします。 設定 > Notification Center でアクセスすることができます。 自分が参加しているグループがだだ漏れですが、特に隠しません。 How you receive notifications に注目してください。 「通知をどのように受信するか」を設定します。 Participating Watching の二種類があります。 Participating のほうは @自分のGitHub ID が付いているような「自分が参加しているところに変化があった時」にどこに通知するかを設定できます。 Watching のほうは GitHub にリポジトリを watchする機能があり、「watch してるものに変化があった時」にどこに通知するかを設定できます。 Email のチェックを外せばメールは届かなくなるでしょう。そうではなくて、一部のリポジトリが活発すぎてついていけない場合もあります。 そのリポジトリを unwatch することで調整できます。これについては後述します。 Email という項目の他にも Web という項目があります。Web での通知は画面左上にあります。 クリックすれば通知内容を確認できます。 リポジトリのウォッチ リポジトリが活発すぎて、そのリポジトリの通知はちょっと見てる余裕がない場合はリポジトリを unwatch しましょう。 あるチームにいつの間にか入れらたしまった場合、自動的に watch されてしますので、こういうことがあります。 これは watch している状態です。 外す場合は、Unwatch を選択して Not watching を選びます。 自分のGitHub IDが登場しない限りは通知がこなくなります。 自分が呼ばれていれば通知がきます。 Not

no_picture

やっと Chef Solo はじめた

すごい広島 #26 にて、書いている。 すこし前に chef-solo で遊んだので、その時思ったことを書いておく。 自分が考えたことが書いてあるだけなので、不正確な内容も含むかもしれません。 主な参考文献は以下。 入門 Chef Solo - Infrastructure as Code 今っぽい Vagrant + Chef Solo チュートリアル - Qiita - taiki45 「今っぽい Vagrant + Chef Solo チュートリアル」は「入門 Chef Solo」の内容を踏まえた上で、最近の動向も押えてて参考になりました。 目的 chef-solo を試す上で、 一番の目的は「リモートサーバの設定反映をコマンドを一つ実行すれば済むようにしたい」ということでした。 $ knife solo cook ホスト名 このコマンドをローカルマシンで実行すると、「ホスト名」が示すサーバの設定をできるようにしました。 また、「入門 Chef Solo」では、ローカルマシンでテストするにも knife solo を利用していた点が気になっていました。そこは別にしたかったので、vagrant の機能を利用して、 $ vagrant provision で、済むようにしました。 成果物 GitHub の eiel/cookbook-munin-example に置いています。 使い方も README.md に書いています。 なぜ munin かというと、munin のインストールが必要だったからです。 上記のリポジトリは必要なツールがそろっていれば git clone して

no_picture

GitHub で SSH 接続できなくなった。SSH をつかった場合に高速化する設定が原因だった。

さっき、GitHub に push しようとしたら下記のエラーが発生した。 no matching cipher found: client arcfour256 server aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc 「arcfour256 に対応してねーよ」ってことが書かれている。 ~/.ssh/config を確認したら Host github.com Compression yes Ciphers arcfour256 思いっきり自分で指定しています。 設定した記憶もないし、arcfour256 ってなんだっけなとググると「GitHub で ssh をつかっていると遅くなるから、こういう設定したら速くなるよ」という記事がでてきた。 GitHub で clone するときは SSH じゃなく HTTP を使ったほうが高速 - てっく煮ブログ 「なるほど、設定をコピペしたから記憶に残ってないんだ」と、思った。 コピペした設定は、ちゃんと勉強した上で使わないとダメですね。 そんな感想を抱いた。

no_picture

広島Ruby勉強会 #035 に参加したり、喋ったりした。

広島Ruby勉強会 #035に参加してきました。 リンク貼っておいてあれですがGitHubのWikiのほうが情報が多いです。 さて、今回は3つスライドを作るという暴挙に出ました。ひとつひとつに時間を割けられないので、たくさん作るのはよくないと思いました。 Hiroshima.rb について Hiroshima.rb の説明もだんだん何をしていいのか忘れてきそうなので、誰か作れよ。ということで作りました。 現在の広島Ruby勉強会が大事にしていることも付け足しておきました。 Hiroshimarbについて from Tomohiko Himura 数学文章作法を取り上げていますが、情報発信をする上で **数学の文章でなくても** 参考になる部分があると思います。 または、「数学ガールの誕生」という本があって、これは結城浩さんの講演を本にしたものです。これもたくさん大事なことが書かれていておすすめです。 その場で結城浩さんがセッションしているかのように感じてしまう丁寧な作りの本です。 ちなみに、スライドにする前の原稿がGistにあります。 コンピュータをもっと使おう これは広島Ruby勉強会はやや難しいという意見が多いので、プログラミング初心者が気軽に聞ける話をしようと試みてみました。 何をやろうか悩んでるうちにどんどん対象者のレベルが下がってこんな形になりました。 コンピュータをもっと使おう from Tomohiko Himura 個人的には、「どんな人でも簡単なプログラミングをするような世界になると良いなぁ」と、思ってたので、その辺りを伝えてみました。 Ver 0.1 なのはブラッシュアップしてもうちょっとちゃんとした形にしたいという考えです。毎月バージョンアップしていきたい。 あまり時間をかけていないので、聞き手のことをしっかりと考えられてない感がまだまだあります。 もっと修行します。 つながりをゆるふわにしよう ActiveSupprt::Nnotifications Rails のソースコードをちょっとづつ読んでいるので、その成果発表を毎月やっています。 今回は AcitveSupport::Notifications を取り上げました。 つながりをゆるふわにしよう Active supprt notifications from Tomohiko Himura これもスライドにした原稿をGistに公開しています。スライドではかなり修正しているし、typoも結構あってなおさないといけないですが、まだなおしていない。 喋らなかったこともあるし、そもそもかなり早口で喋ったのでも再確認したい場合にどうぞ。 その他のセッション 今回はいつもより参加者が多くて19人でいつもより盛り上がりを見せていたと思います。 僕のテンションは暴走しないように低めでした。むしろ、低すぎた感。 RailsとAWSで業務システムを構築してみた Rails, AWS, CI モダンな開発手法を試しつつ、毎月どのような感じになっているか報告されてます。ナイスジョブ。 リリースが近いということで実務的な問題への対処が出てきていました。 capistrano ではまる人が多いのはそれだけドキュメントがそろってないってことだと、これを書いてる時に思いました。 気になった点はスライドのどこ部分を話してるか強調すると良いな、と思いました。 時代はMiddleman Jekyll や Octopress を試してそこから Middleman に移行したらすごくよかった。という話でした。 しかし、あえて厳しいことをいうと、どのあたりが他よりよかったのかよくわからなかった。ちゃんと聞いてなかっただけかもしれないけど。 jekyll と比べると

no_picture

Rubyで次の水曜日の18時を取得する

日付処理って意外と面倒である。次の水曜日の18時を取りたい。 ActiveSupport を使っていいのであれば、このように書けた。 require 'active_support/core_ext' Date.today.beginning_of_week(:wednesday) + 1.week + 18.hours 3.0.0 だと beginning_of_week は引数が取れないので注意。3.0 と 4.0 でしか確認してない。

no_picture

Circle CI を試した

2013年10月の広島Webシステム開発勉強会内でCicle CI を試していた。 最安値が19ドルで、この場合プライベートリポジトリがひとつ使える。 Rails プロジェクトで試しました。設定した内容はわずかで、.ruby-version の指定をしただけで、テストの実行することができました。 これはこのプロジェクトが ruby 2.0 以上である必要があるからです。 リポジトリの選択も Github から一覧が取得されているので、一覧から選択するだけでした。 config/database.yml は自動で生成されました。 デフォルトでは並列ビルドされず、20分ぐらい実行にかかりました Edit settings から 6つに分けて並列に実行できました。4分ぐらいで終了するようになりました GitHub に Pull Request があれば merge するときにビルド実行結果がわかります 現在、タイムゾーンの影響で失敗してテストがあるので修正方法を模索しているところです。 並列ビルドは rspec、 cucumber それぞれ、自動で6分割して実行されていました。 一部のcucumberがかなり素早く終了したのでファイル単位で分割しているのだと思います。 その辺のカスタマイズ方法はここに書いてある 結局 circle.yml は、これだけしか書いていない状態。 machine: ruby: version: 2.0.0-p247 timezone: Asia/Tokyo 導入がとても簡単で維持費が EC2 のマイクロを立ち上げっぱなし程度です。 コンテナの数ではなくて、プライベートリポジトリの数での課金なのでアクティブなプロジェクトでのみ使用する使い方になりそうです。 そんな使い方が可能なのかはまだよくわからない。

no_picture

config/database.yml の情報にアクセスする。

Rails の config/database.yml の情報にアクセスしたかった。 別に open して read して YAML.parse するだけなのですが、 もしかすると、 config/database.yml じゃないところを読むように設定を変えてる場合もありますからね。(ねーよ) ということで適当にリポジトリを検索したら、 Rails.application.config.database_configuration で、取り出せました。 この辺りはバージョンよって違うかもしれないので、GitHub で検索するのが良いかもしれないです。

no_picture

ruby-end マイナーモード - emacs

ruby-end モードをいれました。 ruby で end を自動挿入してくれるマイナーモードです。 似たようなマイナーモードとしては ruby-elecric-mode があります。 この子は他にもいろいろ機能をもっています。end の補完も機能のひとつです。 個人的にはかなか挙動が使いづらく end の補完の処理だけ利用していました。 また、emacs24 では微妙な挙動をしたりするそうです。 - [参考: Emacs24 で ruby-electric的なruby-modeを実現するには - メモとか] ruby-end は end が挿入されるタイミングが心地良いので試してみています。 インストール epel でインストールできるので M-x package-install で ruby-end で入力でインストールできます。 参考: package.el - EmacsJP 普通は package.el で充分かと思いますが、私は el-get を利用してるので (el-get 'sync 'ruby-end) を設定ファイルに書いて評価しました。 関連 自分の el-get のワークフローについて整理する

no_picture

コミュニティに GitHub に使ってみて - すごい広島

すごい広島 も20回を越えて、そろそろ半年経とうとしています。 すごいですね。 #知らんけど そんなわけでコミュニティのとして GitHub を使ってみた感想を自分の中でまとめてみようと思います。 簡単に「すごい広島」について書いておくと、毎週やっている勉強会もどきでミートアップです。ITエンジニアが集まって雑談してたり作業していたりします。 思ってたより人が集まってる みんな GitHub になれてきた? マージされない Pull Request もっと Issue が作成されてもいいんじゃないか 思ってたより人が集まってる 自分が想像していたよりも人が集まっています。 みなさんありがとうございます。 どうせ「すぐ一人二人でもくもくーってなる」と、思ってたのですが、3人以下になったのは1回ぐらいしかないように思います。 参加条件は徐々に緩くしているのもあるかもしれません。 未参加の人からよくあった意見は、 行ってみたい ブログを書くのは無理 敷居が高そう 目的がよくわからない です。 「行ってみたい」の人は来れない場合の話がありますが、来れる人が言ってる場合はお世辞なんですかね。(煽り ブログを書くのは必須ではなくしたので、代わりに GitHub を思う存分試してみて欲しいです。 最近は Issue に作業をメモをとったりしています。 参考にしてください。 敷居が高くみえてしまうのは、変態扱いされない人のアウトプットが鍵になる気がしています。 期待したい。 「目的がよくわからない」の一番の理由は名称のせいかな。 やっぱり情報が読まれるかどうかはタイトル次第というのを改めて感じました。 それでも 「Web を見て参加しました!」が登場したので個人的には満足です。 目的のひとつが達成されました。 改めて「広島 勉強会」で Google で検索しましたが、ちょっと SEO 的にはまだまだです。その辺の工夫が必要そうでした。 みんな GitHub に馴れてきた? 参加者のほとんどが GitHub に馴れてない人です。 それだけ GitHub を使う環境がまだまだないのだと思います。 説明せずに Pull Request した人は僅かです。 そういう意味では効果があったと思います。 また、「非プログラマでも Pull Request はできているので難しくないよ」と言いたいのですが、なかなか良い方法がないです。(チラリ ちなみに、半分以上の人が

no_picture

OSC 2013 HIROSHIMA に参加した。

OSC 2013 HIROSHIMA に参加しました。 200名以上の参加があったらしいです。正確な情報が待ちどおしいです。 私も実行委員会に所属したり(あんまり手伝えてなくてごめんなさい)、Hiroshima.rb の枠でライトリングトークをしたり、すごい広島 と Hiroshima.rb の展示ブースで説明をしたりしました。あと、ライトニングトーク&じゃんけん大会 でライトニングトークをしてきました。前日の DB 勉強会 を含めると計3セッションをするという状況になりました。 Hiroshima.rb 広島でRubyが流行らないのはどう考えても俺たちが悪い Hiroshima.rbの発表については wiki に整理してあります。 というわけで、僕は毎年前座を務めているので、「Hiroshima.rb の紹介」と「広島でRubyが流行しているか調べた」のでその話をしました。 本当は僕も成果発表したかったのですが、時間が足りそうにないので諦めました。 その他のHiroshima.rb の活動は wiki にもまとめています。興味があれば覗いてみてください。 スライドは以下の感じなのですが、実際に使ったものとは違う完全版になっています。 広島で Ruby が流行らないのはどう考えても俺たちが悪い from Tomohiko Himura セッションを見にきてくれた方は20人以上いたと思うのですが数えてないのでわかりません。 セッションの元ネタは私がモテないのはどう考えてもお前らが悪い!でした。 セッションにはどこにもこのネタは入れてないので注意してください。 勝手にみんなのセッションをざっくり感想書いてしまいます。 岡山のRuby勉強会 岡山勢 まこぴー の LT です。 僕が「広島」と「岡山」の比較をしたので岡山の状況について喋ってくれました。 本人はもっとネタをいれればよかったといってましたが、もちろんいれるとよかったですが、岡山勢の牽制としては充分なトークだったと思います。 YouTube動画の再生回数がわし…気になります!! (きゅふぃーん うちの OSC でしか使えない秘密兵器 にょほう(にょ砲) の LT です。 4分超過の打ち切り御免のLTなら死んでいた。 息子さんの支援により笑いだけでなく、癒しも追加されたため、圧倒的に一番人気な LT になりました。 しかし、一番アニメ色があるセッションになっていた気がするのは言ってはいけない。 PaaSで簡単 Railsアプリを公開しよう! ~もあぐれっしぶ~ & Rubyを体験しよう! 広島の基盤 たかた さんの LT です。 タイトル的にはもっともアニメ色の強いセッションですが、去年にひきつづきPaaSの紹介になりました。

no_picture

第2回 中国地方DB勉強会に参加したり、喋ったり。

第2回 中国地方DB勉強会 に参加しました。 O/R Mapping の話をするよ。特にActiveRecordの話をしたかった。 セッションしました。準備不足はいいわけにはできないけど、ぶっちゃけ準備不足で、対象者が詰め切れていませんでした。 とはいえ、スライドはアップロードしておきます。 O/R Mapping の話をするよ。ActiveRecord の話をしたかった。 from Tomohiko Himura よろしい、ならばMicro-ORMだ ORM の利点を長所もわかったんだけど、 ORM が使えない場面で ORM がもつ機能の一部を使いたい。そんなときに Micro-ORM が便利だよ。という話がつづきました。 特にデータのマッピングを操作する部分の機能を持っているようでした。 たしかに、普段のプログラミング生活では表現力の高いクエリビルダと値のマッピングができれば充分な感じは最近していたりもします。 スライド MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報 MySQL と MySQL Cluster 異なる製品で、MySQLのストレージとして MySQL Clusterを利用したりできるようです。 単体でも使えるっぽいですが、よくわかっていません。 安価なマシンを並べて性能を出しつつ、高い可用性を実現します。 使われてる箇所としては、「艦コレ」で使われていたのが最近の話題っぽいです。 MySQLのストレージとして使えるので、InnoDBの互換性向上とかもやってるそうです。 スライド AWSで始めるPostgreSQL/MySQL AWS で MySQL や PostgreSQL をいれる話でした。 Wiki に内容がまとめられてます。 さくらインターネットにおけるデータベース提供の実際 特にレンタルサーバの話が印象的でした。 データベース不慣れな人が多く、そういった一部の人が共用サーバに不可をかけてしまったりするということは予想通り多いみたいです。 コントロールパネルが書籍との違いが出てしまうので、なかなかUIを変更できなっかたりもするそうです。 DBはIOがボトルネックになるので仮想化は向いてないのかなあ。なんて話もしてでていました。

no_picture

そうだ OSC2013 Hiroshima へ行こう

2013年10月6日 (日) に オープンソースカンファレンス 2013 Hiroshima が開催されます。 私はここでひとつお願いをしておきたい。 広島の人でほんの少しでも興味があれば足を運んで欲しいということである。 10分ぐらい顔を出すぐらいで構わない。 今から書くことは「懇親会の受付が終わる前」に書きかったけど、間に合わなかったのです。 これは僕の怠惰が原因で言い訳にしかならないのだけど、 もしかしたら当日に空きが出るかもしれないので、興味があれば早めに参加してスタッフの方に聞いてみるのも良いと思う。 さて、オープンソースカンファレンスとは、なんだろうか。 正直、私も県外のオープンソースカンファレンスには一度も参加したことがなくてよくわからないのです。 しかし、今年で3度目となる広島のオープンソースカンファレンスについては毎年参加しています。 そこで感じていることを言葉にしてみようと思う。 オープンソースカンファレンスの参加者の目的には、いろいろあると思う。 「企業の展示に興味があったり」「県外からの講師のセミナーの話を聞きたかったり」である。ここは表向きにもわかりやすい部分だと思う。 実際、すでに参加登録している人の多くはこちらかなと思う。 もうひとつ参加者の層は、県外のオープンソースカンファレンスの常連者だと思う。 この人たちの多くは、IT系のコミュニティの人だ。 参加者として増えて欲しいのは IT系コミュニティの人とIT系コミュニティの人になる可能性のある潜在者だ。 県外に足を運ぶには億劫だけど、「地元なら参加しようかな」と思う人たちなのです。 私の感じているオープンソースカンファレンスはIT系コミュニティのお祭りなので、 ひとつのコミュニティでは作れない大きなイベントを一緒に作る機会で、合同勉強会みたいなものだと思う。 お互いに協力して何かを作れる人達が集る機会なのである。 横の繋りを育む唯一無二とは言えないけでも、貴重な機会なのである。 そこに「オープンソースじゃないんだけど…」はたぶん関係ない。 そこに「最近活動してないんだけど…」はたぶん関係ない。 そこに「Webデザイナなんだけど…」はたぶん関係ない。 大事なのはコミュティの活性化のはずだ。 「オープンソース」はとりあえず今は置いておいていいはずだ。 #知らんけど そこに「面白いものがない」のであれば、どうすれば面白くなるか考えるところなのだ。 他にもIT系のイベントはありますが、ちょっとの努力で大きなリターンが得られ可能性を秘めているイベントなのだ。たぶん。 そんなイベントなのだけど、開催するたびに参加者が減るのが最も怖いことである。 負の連鎖がはじまる。 「人がこない」といって出展を止める企業や遠方のコミュニティ。 「大したことない」といって出展を止める地元コミュニティ。 だから、ちょっと興味がある人が足を運ぶことは、運営側にとってはとても嬉しい行動で、 セミナーに興味があればセミナーに参加して、 そうでないなら展示に集る人達と雑談していくと良いと思う。 ついでに酷評していくと良いと思う。 来年には、他のコミュニティよりクールで馬鹿なことをする人達が登場するのを期待している。負けるつもりはたぶんない。 「言い出しっぺの法則」というものがあって、言葉にしたもの勝ちで、早いもの勝ちなのである。決して、口は災いの元ではない。 #知らんけど ついでに 私の今週末の予定です。 第二回 中国地方DB勉強会 一番目にセッション 第二回 中国地方DB勉強会 懇親会 OSCのスタッフも来られます。少人数であれば飛び入りできるはず。 OSC 2013 Hiroshima - 10:00 - 広島でRubyが流行らないのはどう考えても俺たちが悪い - 一番目にLT予定 OSC 2013 Hiroshima -

no_picture

GitHub に課金した

GitHub に課金した。月7ドル。 課金した理由は「プライベートリポジトリが欲しくなった」で充分だろうか。 いや、充分ではない。 「プライベートリポジトリが欲しいならBitbBucketを使えばいいじゃない」と、言われてしまうのである。 BitBucket は日本語化されているし、プライベートリポジトリは制限なく作れる。 しかし、チームの人数は5人という制限がある。 というわけで、「チーム人数が5人越えそうだ」 というわけでもあるけど、本当の理由は別のところにある。 Github と BitBucket 両方使っていますが、どちらを使いたいかと言われると GitHub なのである。 GitHub も BitBucket も、日々変化している。 変化に対応するためにも毎日利用したい。 というわけで、毎日使いたい GitHub に課金したのである。 しかし、主な利用法が Wiki になりそうというのは秘密である。 最近 iPhone のパケットプランをフラットプランに変更したので、Macローカルにある固有のデータをなるべく減らして情報はどの端末からも参照したくなってきた。 Wikiのデータは Gitリポジトリアクセスできるので、好きなエディタでも編集しやすい。 Dropbox となるとハイパーリンクの利用は HTML となりそうだし、HTML の編集はしたくない。 話は戻るけど、もちろん、チームメンバー5人を越えそうなプライベートリポジトリが必要になりそうなところであった。 しかし、プライベートなリポジトリが欲しいのであれば自分で作ればよく、いままでそうしてきた。今回は GitHub のサービスを利用したいのである。 コードレビューするための Pull Request 機能、課題を管理のための Issues機能である。 BitBucket は自分に書き込み権限があるリポジトリへのプルリクエストができませんでした。 また、Issues で画像をつかいたい場合、自分でどこかにアップロードしないといけないみたいでした。 そのあたりが、「コードレビューのする際の不便さを感じそうだった」というのもあります。 そんなわけで、お世話になりっぱなしの GitHub さんに課金を決めたという話でした。 課金までの流れ 折角なので、課金までの流れを紹介しておきます。 まず、GitHub にサインインした状態で http://github.com/ へアクセスします。 そこから、設定画面に移動します。(下記画像参照) つづいて、左のメニューから Billingを選択します。 次にお好みのプランをクリックします。Micro を選択しました。 するとクレジットカードの入力を要求されます。適当に入力します。 これで終わりです。こんな表示になりました。 料金を考えると1リポジトリあたり月100円だと思うことにしております。

no_picture

Raphaelで遊んでみた。

すごい広島 #17 でやったこと。 Raphael.js で遊んでみました。 Raphael.js は JavaScript で SVG を作成できるライブラリ。 今日作成したサンプルコードはGitHubにup してます。stepごとに タグを作成しているので、STEP1 のコードがみたい時は git checkout step-1 としてください。 step-5 まであります。 checkout したタグで rake server を実行すると、ローカルサーバが起動します。 http://localhost.com:8000 にアクセスしてみてください。 STEP1 とりあえず試す。 Raphael オブジェクトを作成すると自動的にSVGオブジェクトが挿入される。 絶対座標で挿入されるので、DOMの構築を待つ必要はなかった。 まずは円を描いてみる。 var paper = Raphael(10, 50, 320, 200); // 円を書く at x = 50, y = 40, 半径 10 var circle = paper.circle(50, 40, 10); // 赤色でぬりつぶす circle.attr("fill", "#e00"); // 黒で境界線をかく circle.attr("stroke", "#000"); STEP2 SVG を二つ作成してみる。 Rahael

no_picture

Rails の自動読み込みの話

広島Ruby勉強会 #034で使用したネタの文に書きなおしました。 「Rails の自動読み込み規約を支える技術」と若干煽っておりますが 以下の内容はソースコードを読んで判断したことですべて正しいとは保証できないので参考にする程度にお願いします。 というわけで、Rails の自動読み込みの話をしたいと思います。 Rails の自動読み込みを支える技術 from Tomohiko Himura ### Rails のファイル読み込みの規約 Rails には[設定より規約](http://ja.wikipedia.org/wiki/%E8%A8%AD%E5%AE%9A%E3%82%88%E3%82%8A%E8%A6%8F%E7%B4%84) という設計パラダイムが採用されています。 ファイルの自動読み込みの規約は 読み込みされていないクラス/モジュールがあった場合、名前から読み込みするファイルを判断できる というような規約があります。 例えば ``` Hoge - 'hoge.rb' を読み込む Hoge::Mogu - 'hoge/mogu.rb' を読み込む HogeMogu - 'hoge_mogu.rb' を読み込む ``` といった感じになっています。 この時、クラス名からファイル名の変換は `ActiveSupport::Inflector.underscore` が利用されます。 Rails では、自動読み込みは `RAILS_ROOT/app/models` のような `RAILS_ROOT/app/` の中のディレクトリに対し行われます。 `RAILS_ROOT/lib` とかに配置しても自動読み込みされません。 これを実現しているモジュールは [ActiveSupport::Dependencies](https://github.com/rails/rails/blob/master/activesupport/lib/active_support/dependencies.rb) になります。 ### ActiveSupport::Dependencies Rails を使わない場合の使い方を紹介します。 ```ruby require 'active_support/dependencies.rb' ActiveSupport::Dependencies.autoload_paths LoadError: cannot load such file -- hoge/mogu ``` #### eager_autoload と auto_load!

no_picture

AbstractController を継承して遊ぶ

すごい広島 #16 で遊んだこと Rails で AbstractContrller::Base を継承して オレオレ コントローラ を作りたいと思います。 どうしてこれをしたいかというと View です。 コントローラ名とアクションに対応した View がレンダリングできるのが魅力的です。 状況としてはメールを送るわけではないので ActionMailer 使えないし、すぐに画面に表示するわけではないので ActionController はちょっと…という感じなわけです。 どんな状況かというとDBに保存する長文を作成したい時です。 書いたビューはこんな感じ。 こんにちは <%= @user %>さん <%= goodbye_helper @user %> ヘルパーも使えるようにしてみます。 ファイル名は app/views/hoge_template/goro.text.erb でコントローラ名が hoge_template アクション名 goro テンプレートエンジンは erb です。 利用には以下のように使います。 rails c の中でやったり、モデルの中で使えます。 もちろんコントローラ上でも。 template = HogeTemplate.new template.process(:goro) template.render renderの戻り値がテンプレートの出力結果になります。 最終的な出力目標は こんにちは おなまえさん おなまえさん、おやすみ を目指します。 @uesr には おなまえ が入っています。 goobye_helper はお別れのあいさつをしてくれるように実装します。 作成するコントローラ的な役割をする HogeTemplate はこのように書きたいはずです。 class HogeTemplate < ActionTemplate

no_picture

Cucumber-js を試した。

広島Webシステム開発勉強会 で Cucumber-js を試してました。 先に雑感をかきます。 まだ完成度が高くない感じです。 アサーションが用意されてないので、使いやすくするには自分でなんとかしないといけないような感じでした。 step_definision が Ruby版より難しそうでした。 日本語への対応がまだできていませんでした。 色がまだつきません コマンドラインオプションをまちがえるとコールスタックが表示されます。 インストール npm install -g cucumber cucumber.js というコマンドがインストールされます。 試してみる Feature: hogehoge Scenario: hogehoge Given hoge Then goro 試しにこんな feature を書いてみました。 他に作成したのは features/step_defnition/myStepDefinitions.js と features/support/world.js です。 world.js で step で使える DSL を強化できますが今回は特になにもしていません。 Stepの定義は以下のように書きました。 var myStepDefinitionsWrapper = function () { this.World = require("../support/world.js").World; this.Given(/^hoge$/, function(callback) { // express the regexp above with the code you wish you had callback(); });

no_picture

pygements を利用してると jekyll serve --watch のファイル生成が遅いらしい

以下の質問を受けた。 反映されるのに、なんでこんなに時間がかかるのじゃ。 Jekyll on Vimeo https://t.co/RrU2ABliHw — Terasawa Shuuhei (@shuuheyhey) August 30, 2013 --watch を使うと jekyll build の部分が異常に遅くなるらしい。 初回は遅くないのですが、ファイル変更を検知した時が遅い。 @shuuheyhey pygments: falseにすると速いんですけど、それだとシンタックスハイライトが効かないという…。 — Hideki Abe (@_hideki_a) August 30, 2013 pygments を有効にしていると遅くなるらしい。 --watch を使うとファイルの生成する部分がメインスレッドでないのがあやしい。pygements は popen とかつかって実行されるっぽいし。 とはいえ、原因を特定するまではいけなかった。 仕方ないので無理矢理ごまかす方法を考えた。 以下のような Rakefile を用意してみた。 require 'directory_watcher' require 'jekyll' desc 'preview' task preview: [:watch] do sh 'bundle exec jekyll serve' end task :watch do options = Jekyll.configuration({}) source = options['source'] destination = options['destination'] dw = DirectoryWatcher.new(source,

no_picture

ローカルサーバ起動と同時にブラウザで開く。 - Jekyll とかで。

この記事は すごい広島 #015 で書いております。 GitHub Pages などを使っていて、プッシュする前に ローカルサーバで確認すると思います。以前、Github Page で公開する サイトを ローカルで Preview するのに使ってる方法 で、その方法を紹介しました。 $ rake preview で、ローカルサーバを起動するようにしています。 今回は、この rake preview コマンドを実行した時に自動的にブラウザを起動して http://localhost:4000/ へアクセスするようにしてみました。 Rakefile をこんな風に書きました。 require 'bundler/setup' require 'thread' require 'launchy' desc 'preview' task :preview do Thread.new do sleep 1 Launchy.open 'http://localhost:4000/' end sh 'bundle exec jekyll serve --watch' end 別のスレッドで Launchy を使って起動しているだけです。 ちなみに Gemfile はこんな感じ。 source 'https://rubygems.org' gem 'github-pages' gem 'launchy' 関連 Github Page で公開する サイトを ローカルで

no_picture

最近やった Ruby でのミス - rspec の expect で 空白に括弧

Ruby かいてて些細なミスでハマったことを書いておきます。その2。 describe 'Hoge' do it do expect ('hoge').to eq('hoge') end end expect ('hoge') のところの括弧の前にスペースが入っているのが問題です。 正しくは describe 'Hoge' do it do expect('hoge').to eq('hoge') end end 'hoge'にto というメソッドがない、というエラーが出るので気づくのですが + がないというエラーになっててハマった。 解説 expect('hoge').to eq('hoge') は expect('hoge').to(eq('hoge')) と等価です。 expect ('hoge').to eq('hoge') は expect('hoge'.to(eq('hoge'))) と等価です。 to は expect の戻り値に対して使うメソッドです。 空白をいれてしまうと、expect ではなく ‘hoge’ に対し to を呼んでしまいます。 関連記事 最近やった Ruby でのミス - カンマで改行

no_picture

scalaz に入門する

Scalaz をおすすめされた。 ひむひむはScalazでいいと思うの — 航空母艦 (@razon) August 23, 2013 とりあえず、入門してみよう。 scalaz って何 Scala がより関数型言語の力を得るらしい。よくわからん。 モナドとか使える。 https://github.com/scalaz/scalaz sbt を入れる sbt ってのを使っていれば…、て記述がたくさんある。 ruby でいうと bundler に近いものなのでしょうか。ちょっと違うけど。 makefile みたいなもんだろうか。これもちょっと違うよーな。 インストールですが、Gentoo Prefix で入れたい。 Gentoo なら Overlay がある。 https://github.com/whiter4bbit/overlays layman します。 layman -f --overlays https://github.com/whiter4bbit/overlays/raw/master/layman.xml --add gentoo-scala-tools 設定できたら、 emerge sbt-bin でいけた。 sbt をつかって scalaz プロジェクトフォルダを用意して build.sbt を作成する。 Hello, World - はじめる sbt を参考にした。 name := "scalaz-helloworld" version := "1.0" scalaVersion := "2.9.2" libraryDependencies += "org.scalaz"

no_picture

gitolite で tag への権限付与

gitolite でリポジトリを管理しております。 git の使い方わかってない子もいるのでわりと push できるブランチを制限してるリポジトリがあります。 タグを push しようとしたら拒否された。 というわけで許可を与える方法を調べた。 RW+ refs/tags/ = eiel refs/tags/ にたいして行えばよいみたいです。 補足しとくと形式は [許可属性] [ブランチなど正規表現] = [ユーザまたはグループ] という感じです。 参考 gitolite - GitHub

no_picture

Scala 入門しとく

Scala はじめるはじめる詐欺をしていたので、はじめることにしました。 インストール Gentoo Prefix で emerge dev-lang/scala と、しましたが、ビルドに失敗しました。 ドキュメントまわりでエラーのようなのでちょっと工夫すればビルドできそうですが、諦めてバイナリインストールを試みました。 $EPREFIX/etc/partoge/pacakeg.use に以下を加えました。 =dev-lang/scala-2.9.2 binary はじめてみる Getting Started - Scala を参考にはじめてみました。 基本のハローワールドです。ようこそ Scala の世界へ。 scala コマンドで対話環境が起動できます。 $ scala そこに以下のコードを打ち込んでみました。 object HelloWorld { def main(args: Array[String]) { println("Hello, world!") } } 僕の Ruby 的な感覚では HelloWorld というオブジェクトを作り特異メソッド main を定義している感じに見えます。 このあたりは、Java のエントリポイントが static な main メソッドになるのを知っていれば、納得感はあります。 対話環境には defined module HelloWorld と表示されているのが気になります。 「オブジェクトは別にメソッドが集めるところが用意されてるのかな?」という印象を受けました。 その後、追加で、 HelloWorld.main(null) と入力しますと、Hello, World と出力されました。 Haskell を学習してる感覚からいくと 第1引数は null より空のリストを渡したいですね。 「null が渡せて気持ち悪い。」的な感じがしました。

no_picture

ReVIEW を試してみる

毎週のアレ、すごい広島 #013で試したこと。 ReVIEW という軽量マークアップ言語に属すると思われる電子書籍を作成するのを主眼に置いてるものみたいです。先週TLでやたらみかけました。 というわけで、QuicqStart を参考に試してみました。 インストール まずは、gem でインストールしました。 gem install review Ruby使いにはとても簡単。 とりあえず epub をつくってみる epub 作るのに作成したファイルは以下の通り。 sample.re sample.yaml CHAPS 最後に review-epubmaker sample.yaml で、epub が作成されました。 それぞれのファイルの中身ですが、sample.re が、 = はじめてのReVIEW //lead{ 「Hello, ReVIEW.」 //} sample.yml は https://raw.github.com/kmuto/review/master/doc/sample.yaml からダウンロードしました。 最後に CHAPS が、 sample.re です。 そして、iPhone で動作確認してみました。 iPhone に送るには iTuens からの同期するのが良さそうですが、メールで送信しました。 Message で送るとなぜだか認識しませんでした。Dropbox もありだと思います。 PDF作成するためには TeX環境がいるのでまた別の機会にします。 reファイル 内容を書くファイルみたいです。RDに近い文法です。 詳しい文法は ReVIEW フォーット を参考にしてください。 ちらっとみてみるると、コラム専用のものがあって、書籍用って感じがして良いですね。RDに近いと書きましたが、むしろ LaTeX に近いようにも思います。 CHAPS CHAPS ファイルは章を記述するファイルで、1章につき1ファイルになるようです。似たようなファイルPREDEF、 POSTDEF があってこれは、本文ではない前書きの部分や後書きの部分を定義するようです。 前付け、後付けというものに該当するようですが、専門家でないのでよくわかりません。 sample.yml

no_picture

github-pages Gem というのが用意された - Github Page で使う gem のバージョンをあわせてくれる

Github Page は Jekyll プロジェクトを push すれば HTML に変換してくれます。 これを使う場合、Github 側とローカルで確認するときの Gem のバージョンを揃えておきたいです。 そのために Gemfile を記述しますが、github-pages という gem が用意されました。 というわけで、試してみた。 source 'https://rubygems.org' gem 'github-pages' bundle install とか実行せばあ必要な gem が手に入ります。 以前は、 source 'https://rubygems.org' ruby '1.9.3' gem 'jekyll', '=1.1.2' gem 'liquid', '=2.5.1' gem 'redcarpet', '=2.2.2' gem 'maruku', '=0.6.1' gem 'rdiscount', '=1.6.8' gem 'RedCloth', '=4.2.9' gem 'kramdown', '=1.0.2' のように書く必要ありました。 とてもすっきりしています。 利用する gem が更新されても bundle update ですむので、とても嬉しいですね。 もっと具体的に 依存している Gem の情報は gemspec にあります。 github-pages

no_picture

ssh でポートフォワーディングしてブラウザで開くだけの gemを作った

flaun という gem つくって公開してみた。 インストールするには $ gem install flaun でできます。 何をするgemかというと ssh example.jp -L 8000:localhost:80 open http://localhost:8000/ のようなことをするだけの gem です。 ~/.flaun ファイルに設定を書いておくと flaun [target名] で該当サイトが開けます。 [target名] は ID みたいなものでどれを開くか指定するためのものです。 設定はRubyで作った DSL でかけます。 sample という target名の設定は以下のようになります。 port 8000 target :target do host 'example.jp' end はじめから http://localhost:8000/foobarr のようにディレクトリなどpathを指定したい場合は port 8000 target :target do host 'example.jp' path 'foobar' end のように書けます。 どんな時に使うの アクセス制限かけたいけど固定IPがない。BASIC認証はちょっと…。 そんな時は localhost からのみアクセスしたいサーバがあることがあります。 Apache だと以下のように書いてるページですね。 Order allow,deny Allow from localhost こうなるとサーバからアクセスしないと表示することができません。

no_picture

自分の el-get のワークフローについて整理する

この記事は すごい広島 #12 で書きました。 Emacs のパッケージ管理に el-get を利用しています。 他にもいろいろありますが、どれもしっかりと使いこなせないまま el-get におちついています。 ぶっちゃけ、el-get 使いこなせていません。 使いこなせてないので不安な箇所があったので確認してまとめました。 el-get を使いこなせてないのに、これに落ち着いている理由はDistributed Setup という機能を利用しているからです。 これを使うと インストールしているパッケージがない場合自動でインストールしてくれます。 例えば、helm というパッケージを利用していて、emacsの設定ファイルを git などで共有しているとします。普段利用していない別のマシンで設定ファイルをコピーしてきます。 これで Emacs を起動すると、起動時にエラーが出てしまいます。 もし el-get の Distributed Setup の機能を利用していればインストールしていないパッケージをダウンロードしてくれます。 ドロップボックスで共有している場合は不要なのですが、そういった使い方をしていない場合は有効です。 この方法を使っている場合の設定方法とパッケージの更新方法について書いておきます。 設定方法 その設定方法は (el-get 'sync 'helm) と、書いておきます。 基本的にはこれでOKです。 一緒に yasnippet をインストールしたいのであれば リストにすればよいです。 (el-get 'sync '(helm yasnippet)) たぶんリストにしなくても大丈夫。 (el-get 'sync 'helm 'yasnippet) 別々にやっても大丈夫。 (el-get 'sync 'yasnippet) (el-get 'sync 'helm) すでにインストールしてしまっていて、動作を確認したい場合は el-get-removeコマンドで削除して、再評価することで動作確認できます。 rm コマンドなどで削除してしまった場合は el-get から見ると削除したことになっていないので注意してください。 その場合でも el-get-remove

no_picture

参考にならないモチベーション維持方法

ネタです。 #夜だからRTされた数だけ本音言う — えいる (@eielh) August 5, 2013 この記事を書き始めた時点では5RTされていました。 ということで、私のモチベーション維持の方法を適当に書いてみる。 きっと、なんの参考にならないことを書いてしまいそうです。 死ぬのは最後の楽しみ 楽しいと感じる心を信じる 楽しいと思い込む 小さな幸せを楽しめ 死ぬのは最後の楽しみ どんなつらいことがあったとしても人間はいつか死にます。 つらいこと、嫌なことがあれば死んでしまえば終わりです。 とても楽チンな道が用意されています。 ただし、これは最終秘密兵器なのは言うまでもありません。 しかし、救いとしては充分です。 必ず楽になれるのです。 世の中的には「自分で死を選択する」は良いことではないのはご存知の通りです。 ならば、他人に殺して欲しいかもしれません。 これも同様に大変悪いことで、「他人」の人生がぐちゃぐちゃになってしまいます。 これが認められる世の中はあまり想像したくありません。 ならばどうするのか。 生きないといけません。 どんなつらいことがあっても生きないのいけません。 ならばどうするのか。 生きるのを楽しむしかないのです。 いつかやってくる死を楽しみにして生きるしかないのです。 はい、生きることになってしまいました。 どうせならつらいより楽しいほうがいいです。 毎日が楽しくなるように考えましょう。 ほら楽しく生きられそうな気がしてきました。 モチベーションが維持できました。 最近の好きな言葉は 「老衰で死ね」です。 楽しいと感じる心を信じる 楽しい、嬉しい、楽しくなりそう。 そういうものにはマークをつけておきましょう。 tumblr にまとめるもよし、Twitter でふぁぼるのもよいでしょう。 すかさずネタにしたり、わざと盛り上げてみましょう。 たぶん、楽しくなります。 ぼっちでも、「この空気が楽しい/楽しくなりそう」と思うところが居座ってみましょう。 気がついたら仲間がいるかもしれません。 気がついたら常連かもしれません。 半年ROMれとはたぶんそういうことです。 居場所ができてるかもしれません。 世の中に楽しいことがあることに気づけばモチベーションは上がります。 この場所にずっといたいと思うなら、いるための努力ができます。モチベーションが上がります。 楽しいと思い込む 最終手段です。 仕事へ行くのはつらいです。 仕方ないので仕事へ行くのは楽しいと思い込みましょう。 そういえば社会人一年目、なかなか起きれない朝は以下のことを考えていたように思います。 仕事へ行けば いつか幸せで楽しい未来作れる。(と信じます) あの子と共同生活ができる。(と信じます) 帰ってくると我が子のかわいい寝顔が見れる。(と信じます) イメージは具体的であればあるほど有効です。 ただし、現実からは目を背けましょう。 妄想と現実をごちゃまぜにするのは危険です。 現実には起きないことを認識しつつ現実から目を背けましょう。 慣れてるくると部屋にムカデがいても眠れるようになります。 良い子は真似をせず、つかまえてから眠りましょう。 ムカデに噛まれたことがきっかけで就職活動が開始できたというレアケースもありますが、ここでは話しません。

no_picture

広島Ruby勉強会 #033 でやったこと - ActiveSupport CoreExt & Rails Template

広島Ruby勉強会 #033 に参加しました。 前回に引き続き ActiveSupport のCoreExt のソースコードを読んだので、面白そうなところをざっくりと紹介しました。 資料 - Rails のソースコード読んだので面白そうなところを紹介する – ActiveSupport CoreExt編 その2 あと LT しました。 rails new には --template という引数があるのでこれについて調べました。 まずはスライド。 Rails プロジェクトでスタートダッシュを決める from Tomohiko Himura このスライドを作る前に調べものした時のメモは前回の記事を Rails New した時の追加処理をかく 参加者の もりしー こと @CentBoss が 「広島Ruby勉強会 #033に遊びに行ってrails newでのtemplateを作った」 早速試してみてくれました。 rails new する時のデフォルトの引数を指定できる ~/.railsrc というものがありますが、そのなかで –template が使えるのを試してくれています。 上手くいったようです。 ここでテンプレートファイルを指定しておくと、とても楽ができます。 次回の 広島Ruby勉強会は 9月7日を予定しているそうです。 発表の練習したい方募集中だそうです。

no_picture

rails new した時の追加処理をかく

この記事はメモです。 広島Ruby勉強会 #33 で LT するのに下調べしたことを書いてるだけです。 rails new した時に --template file_or_url というオプションがあります。省略形は -m。 これを使うと、rails new した時に追加処理ができます。 「テンプレート機能」と呼びたいと思います。 何がしたいかというと rails new した時点で pry とか rspec とか cucumber とかいつも使うのを設定した状態にしたいのです。 ウェブサービスが思いついたら直ちに開発をしたいのです。 このテンプレート機能を使うものとしては Rails Composer というものがあります。 これを使うと、どのライブラリを利用するか質問されるので、回答していくと、雛形ができます。 これを自分でカスタマイズしたいので、いろいろ調べました。 役に立つかもしれないウェブページ Rails Application Templates - Rails Guide Creating and Customizing Rails Generators & Templates - Rails Guide RailsのApplication templateを使って開発の初速をあげよう! ひとつめの「Rails Application Templates」は Rails Guide ですが、Rails Guide のトップにリンクがありません。 だいぶ調べた後に気づきました。泣きたい。 ふたつめも Rails Guide ですが、機能的には Generator と同じなので参考になります。 みっつめは日本語記事。面白くまとめてあります。このメモを書いてLTをつくった後にみつけた。 つづいて、関係してきそうなクラスやモジュールを整理します。 Rails::AppBuilder Rails::Generators::AppGenerator Rails::Generators::AppBase Rails::Generators::Base Rails::Generators::Actions Thor::Actions Thor::Group Thor::Shell Thor::Invocation Thor::Base --template に指定したファイルは Rails::Generators::AppGenerator インスタンスのコンテキストで実行されます。 Rails::Generators::AppGenerator が継承してるクラスやミックスインしているモジュールのメソッドが使えると考えてください。 「instance_eval される」と書いたほうがわかりやすい人もいるとかもしれません。 rails new や rails generator には、Thor というライブリが使用されています。 bundler や Vagrant でも利用されているそうです。 もっと詳しいことを知りたいのであれば、 Github のリボジトリやWikiをみるとよさそうです。 Thor についてはまだ勉強中でまだよくわかりませんが、コマンドラインから実行するプログラムを作成するのを支援するようです。 継承関係は、 Rails::Generators::AppGenerator < Rails::Generators::AppBase < Rails::Generators::Base - [Thor::Actions, Rails::Generators::Actions] < Thor::Group - [Thor::Base, Thor::Shell, Thor::Invocation] となっていて、 < は継承しているところで - はミックスインしているところです。 Rails::AppBuilder には Rails::Generators::AppGenerator で使用するレシピが書いてある感じになっています。 Rails::Generators::AppGeneratorに定義されているメソッドは Thor::Group の規約により、定義された順番に実行されるようになっています。 --templateに指定したファイルが実行されるのは最後から二番目になります。 最後はrun_bundle が実行されます。これは bundle install が実行されます。 rails generator に対応したクラスのを多くは Rails::Generators::NamedBase を継承しています。 継承関係は Rails::Generators::NamedBase < Rails::Generators::Base となっているので、両者に共通するものが Rails::Generators::Base になることがわかりました。 rails new する時の処理をまるまる変更したいのであれば Rails::AppBuilder を継承して::AppBuilder を作成すればできそうな感じでした。 ベースになるクラスは railties/lib/rails/generators にあります。 generatorとして利用できるものは、ここに配置されているディレクトリに配置されています。 ないものもありますが、rails g --help に表示されるものと概ね対応しています。 find -maxdepth 2 -type d .

no_picture

GnuPG で遊ぶ - 暗号化してみる

GnuPG 使う機会が無い。無さすぎるよ。使わないと忘れそうなので、たまには遊ぶ。ついでに広まればいいな。ということで、整理しながら試す。 そうそう、これは すごい広島 #011 で遊んだことです。 GPGとは GNU Privacy Guard という暗号化ソフト。ざっくりとは Wikipedia の GPGとかみてみると良いかも。 PGPの実装のひとつです。 これを使うと暗号化とか署名とかできる。 暗号化すると特定の人しか解読できないファイルが作成できる 署名すると特定の人が作成したことを示せる メールの暗号化にも使える。しかし、私は暗号化されたメールを受信したことがない。 GnuPGの使い方 あたりを見ながら復習。 GPG がインストールされているか確認する $ gpg --version gpg (GnuPG) 2.0.20 libgcrypt 1.5.3 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: xxxx サポートしているアルゴリズム: 公開鍵: RSA, ELG, DSA 暗号方式: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 ハッシュ: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 圧縮: 無圧縮, ZIP, ZLIB 入ってるとこんな感じ。 暗号化してみる 暗号化する場合 暗号化するための鍵を取得する 暗号化する 読みたい人に送りつける 読む人が自分の鍵で複合する 暗号化するための鍵が必要になります。 暗号化してメールを送って欲しい人は「公開鍵」という種類の鍵を鍵を公開しています。なので、これを取得すれば暗号化できます。 復号化するほうは「公開鍵」とペアになっている「秘密鍵」を使います。 これは復号化する人しか持っていないので、メールの暗号化が成立するわけです。 実際にやってみる 実際にやってみたいと思います。 メインのコンピュータで自分の鍵を作成する 自分の公開鍵を公開する 別のコンピュータで、公開鍵を取得する 別のコンピュータで暗号化したファイルを作成する メインのコンピュータにファイルを送る メインのコンピュータで復号する というシナリオでやります。 メインのコンピュータでの実行は main $ をつけて、別のマシンの場合は sub $ をつけて明示しておきます。 サブのコンピュータを用意する簡単な方法は仮想マシンでしょうか。 メインのコンピュータで自分の鍵を作成する 鍵がないことには始まらないので作成します。--key-gen オプションを使用します。 すでに作成しているので、実際には使用しない鍵で例をあげます。 main $ gpg --gen-key ご希望の鍵の種類を選択してください: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (署名のみ) (4) RSA (署名のみ) 選択?

no_picture

Mac で WMA ファイル MP3 に変換するのに wavePad を利用した

Mac で WMA ファイル編集して MP3 に変換するのに wavePad を利用しました。 営利目的でなければ無料で利用できます。 QuickTime で WMV を再生可能にする Flik4Mac だと Flip4Macを使用している旨が音声に追加されてしまいますので、これを使いました。 トリミングなど編集もできて出力形式も指定できるのでとても助かりました。

no_picture

Github の Feed が溜りすぎてやばい。ついでに気になるのをメモっとく - すごい広島 010

この記事は すごい広島 #010 でやったこと。 GitHub の News Feed が読めてない、ヤバイ。6月17日から溜まってる! この時間を使って眺めて気になったのを簡単にまとめる。 ようするに、頭の中を垂れ流すだけの記事です。 One Hundred Ideas for Computing One Hundred Ideas for Computing 「クラウドコンピューティングでやりたい100のこと」といったころなのでしょうか。本当に100個あってびびった。ネタがないときのインプットにしたい。 あと、すでに存在しているものや、似ているものにリンクが貼られていて面白いです。100個あるとタイトルを読むだけで精一杯でした。 http_configuration http_configuration ruby の gem。Rails の plugin としても利用可能らしい。 NET::HTTP のグローバル設定が可能らしい。タイムアウトする時間やプロキシを登録しておけば、自動で引き継ぐ感じなのでしょうか。試してないから知らない。 config = Net::HTTP::Configuration.new(:proxy => :environment, :read_timeout => 10, :open_timeout => 5) config.apply(:read_timeout => 5) do Net::HTTP.get('http://example.com/') end pjaxメモ pjaxメモ ブラウザの履歴操作のメモのようだ。整然としていてナイスである。 まだまだ充実していくんだろうか。 glim GRUB2 Live ISO Multiboot - glim いろんなOS Live CD をブートできる USB メモリや CD を作成できるみたい。 CDイメージを用意する必要があるのか気になったけど、そこまでは見ませんでした。

no_picture

Exception Notification の 4.x 系へのアップグレード

Rails のプラグインである Exception Notification を gem upgrade したらエラーが起きた。 例外が発生したらメールを送信してくれるやつです。 最近は Errbit とかが流行りらしいです。 ブルジョワ層は Airbrake とか使うらしいです。 話が剃れた。起きたエラーは以下の通り。 undefined method `new' for ExceptionNotifier:Module 対処方法は公式に書いてある。 Upgrading to 4.x version - Exception Notification ミドルウェアの名前が ExceptionNotification::Rack に変更された 第2引数に :email という上位にキーが必要になった production モードじゃないと発生しないので、Jenkins などで rake assets:precompile して置かないと発見が deploy するまで遅れそうです。

no_picture

Mac で jenkins

Mac で ローカルに「すごい cron」的に使うために Jenkins を入れて遊んでいます。 その辺の理由は 広島Ruby勉強会 #32 でも話しました。 特に動作に関連する点で気になった部分をメモしておきます。 アップデートの方法 再起動する方法 Jenkins を止める方法 日本語が化けるのを直す 127.0.0.1 でのみアクセス可能にする 実行ユーザの変更 インストールには Native Package を利用しました。 http://jenkins-ci.org/ アップデートの方法 /Applacations/Jenkins/jenkins.war を差し替えて、再起動すればOK。 最新版がある場合は「Jenkinsの管理」の画面にリンクがあるので簡単にダウンロードできます。 Jenkins を再起動する プラグインのインストールした時に再起動するを選択できるけど再起動しない。これは私の環境なのかもしれませんが、よくわかりません。 仕方ないのでシャットダウンの準備ができてる状態にして、プロセスを kill しています。 あとは launchd が自動的に起動してくれます。 「Activity Moniter」で java を検索して kill するのが一般的でしょうか。 launchd をunload して loadしてもよいです。 その場合は以下のようにします。 sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist sudo launchctl load /Library/LaunchDaemons/org.jenkins-ci.plist Jenkins を止める方法 Native Package でインストールすると launchd に登録され、起動時に自動的に起動するようになります。 これを止めるには以下のコマンドを使います。 sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist アンインストールしようとして /Applications/Jenkins

no_picture

Ruby on Rails で NOT IN な SQL をかく。

Rails 4 で NOT な条件をもつ WHERE 句 が非常に書きやすくなりました。 Rails 4 なら NOT IN な SQL も簡単に書けます。 User.where.not( name: ["hoge","goro"] ) 条件にリストを渡せばよいです。SQLは以下のようになります。 SELECT "users".* FROM "users" WHERE ("users"."name" NOT IN ('hoge', 'goro')) サブクエリも使えます。これが便利すぎて困る。 query = User.select(:name) User.where.not name: query SELECT "users".* FROM "users" WHERE ("users"."name" NOT IN (SELECT name FROM "users")) Rails 3 の話 そうはいっても、Rails 4 にすぐには更新できないプロジェクトがあるので、これに慣れてしまうと非常につらい。折角なのでメモしておく。 where に文字列を渡す 格好悪いけど、とりあえずごまかす場合はこれを使う。 User.where("name NOT IN ('hoge', 'goro')") 文字列で渡す。 ? を使うとエスケープで泣きたくなるので、手軽には使えない。右辺も文字列で逃げます。 サブクエリを使うときは、こんな感じ。 query = User.select(:name) User.where("name NOT IN (#{query.to_sql})") SQLを直接書くしかない。複雑な query だとつらいので to_sql メソッドで逃げます。 squeel を使う Rails 3 だと NOT なSQL を書きづらいので、 squeel をよく使っています。 squeel を使っていればこんな風に書けます。 User.where { name << ["hoge","mogu"] } where に ブロックで引数が渡せるようになって << という演算子を使うと NOT IN になります。name はシンボルではないのも ポイントです。 ブロックで渡すので、スコープ内で name に値が束縛されているとそちらを参照してしまうので注意。 サブクエリも使える。素晴らしい。 query = User.select(:name) User.where { name << query } squeel を使うと LIKE やら OUTER JOIN やらもできます。便利。 arel の世界へ行く arel で構築した sql を where に渡す方法がある。 squeel をインストールしたくない時に。 users = User.arel_table User.where( users[:name].not_in(['hoge','mogu']) ) arel 自体あまり解説してる人がいないのでなかなか勉強しにくいのが欠点。 わかってくるとなんとなくでも書けます。 サブクエリもいけます。 query = User.select(:name) users = User.arel_table User.where( users[:name].not_in(query.arel) ) ActiveRecord::Relation はそのまま渡せませんが arel メソッドで変換可能です。 まとめ Rails 4 の not 便利です。 squeel も良いです.

no_picture

シンプルなプロンプトを提供する zsh pure を試してみた

この記事は すごい広島 #9 で行なったことです。 Pure という シンプルなプロンプトを提供する zshスクリプト を導入してみました。 機能としては バージョン管理システムのブランチを表示 git の管理下で、ワークツリーに変更がある場合は * が表示される 実行の長いコマンドを実行した時に実行時間が表示される デフォルトのユーザと違う場合は ユーザ名@ホスト名 といった機能があります。 カレントパス と ブランチ名を表示している部分は print を使い出力していて、PROMPT は > だけの表示となってます。 そのため Ctrl+l を入力すると非常にすっきりした画面になります。 設定方法 私は ~/zsh.d/ に zsh のスクリプトを集めていますので、それを前提に書きます。 wget https://raw.github.com/sindresorhus/pure/master/prompt.zsh -O ~/.zsh.d/prompt.zsh そして ~/.zshrc を編集します。 # wget https://raw.github.com/sindresorhus/pure/master/prompt.zsh -O ~/.zsh.d/prompt.zsh local username='' DEFAULT_USERNAME='eiel' [ $USER != $DEFAULT_USERNAME ] && local username='%n@%m ' ダウンロードした prompt.zsh をいじらなくて済むように、少しだけ細工しています。 DEFAULT_USERNAME には自分の ユーザ名を入れます。 導入するとこんな感じになりました。 まとめ バージョン管理の情報は PROMPT3

no_picture

Funtoo から Gentoo に戻してみた

この記事は すごい広島 #008 に参加中に書きました。 この間、我が家の Funtoo を Gentoo に戻してみた。 戻した理由 OpenRC のバージョン違いで munin が新しいのにできなかったから。 Gentooからの乖離が大きくなってきてるみたいですね。 #知らんけど 折角なので、戻す際に新規インストールせずに、そのまま移行できないか試みてみた。バックアップとるのがめんどくさかったとかでは決してない。たぶん。 Gentoo に関しては勉強不足なので、ここに書いてあることは鵜呑みにせず参考にするぐらいにしてください。 そういうこともできるだろうということでやってみたかった。 手順を考える 最初どうすればいいのかなぁ。考えてみた結果。 以下のとおりになりました。 portage tree を Gentoo のものに変える emerge -e @system を実行する meerge -e @world を実行する 結論からいうと概ね予定通りできましたが、それなりにはトラブルがありました。 portage tree を Gentoo のものに変える 一番苦戦したところです。 Funtoo は git を利用して portage tree を更新するので、参照先の Gentoo の rsync のものするだけでは emerge --sync がエラーになってしまいました。具体的には /etc/make.conf の SYNC です。 Gentoo の portage tree も Git を使う という手もあるのですが、これ最近 コミットされてないように見えます。

no_picture

Mac で使える git mergetool をいろいろ試してみる - Araxis

Mac で使える git mergetool をいろいろ試してみる - 準備編 の続きです。 Araxis Merge を紹介します。 Cocoaアプリで表現も操作性も良いです。 だけど、値段を考えるとすこし残念な感じでした。 値段は 120ドルと Kaleidscopeの2倍近い値段です。 ちょっと高い。 マージモードなのに3カラムではなく、2カラムでどのようにマージされるのかわかりにくかったり、キーボードショートカット が fn + ↓ とかになっていて効かなかったりと、そのあたりが残念でした。 設定方法ですが、git にあらかじめ設定がもりこまれているため、インストールして、環境変数PATHを設定してやれば利用できます。 export PATH=/Applications/Araxis\ Merge.app/Contents/Utilities:$PATH ここもまた残念で、compare というコマンドで起動するようですが、 他にもcompareというコマンドがあると、これより先にコマンドがみつかるように PATH を設定する必要があります。 公式の設定だと PATH=$PATH:/Applications/Araxis\ Merge.app/Contents/Utilitiesとかかれていてハマりました。 あとは git mergetool -t araxis と、実行すると起動することができます。 常に Araxis を利用したい場合は git config --global merge.tool araxis としておくと -t araxis を省略できます。 画面左が現在のファイル内容で、画面右がマージしようとするブランチのファイルの内容になります。保存して画面を閉じれば左側の内容に決定したことになります。 左側がデフォルトで選択されていて、右側を採用したい場合は選んでいくという使い方になります。 TimeMachine との連携などもでき多機能で優秀なのですが、git mergetoolとして使うにはちょっと悩む感じでした。 有料だけあって、無料ツールよりはずっと使いやすいです。 関連 Mac で使える git mergetool をいろいろ試してみる - 準備編

no_picture

広島Ruby勉強会 #32 で 発表したこと - ActiveSupport, jenkins

広島Ruby勉強会 #032 で、紹介したこととか、喋ったこととかまとめときます。 広島Ruby勉強会の各発表は Github の Wiki に整理されてます。 Rails のソースコード読んでるので面白そうなメソッドを紹介する - ActiveSupport Core Ext すごい cron - Jenkins を試した 勉強会自体の感想は別のところに書きました。 Rails のソースコード読んでるので面白そうなメソッドを紹介する - ActiveSupport ここ最近はほぼ毎日 Rails のソースコードを読んで簡単にメモをとっています。います。 概ね毎日サボらずやれております。 この内容は railsdoc.eiel.info で垂れ流しています。 まずは、ActiveSupport から攻めています。特に Core Ext の部分を読んでいます。ということで、4月から6月の間に読んだものの中で、適当に抜粋して紹介しました。 内容はこちら その他には読んでいて気がついたことを残しています。 すごい cron - Jenkins を試した ローカルに Jenkins インストールして、これ cron の代わりに使えることに気づいたので、使用してみました。 その中で気づいたことや問題点についてお話をしました。 おまけで ruby 関連の Jenkins の Plugin についてわかったことを話しました。 すごい cron ? - Jenkins 試した from Tomohiko Himura 具体的な設定方法は まだ公開してないです。ごめんなさい。 また時間をとって書きたいと思います。 しかし、cron として使うにはメモリを食いすぎるので、Local

no_picture

Mac で使える git mergetool をいろいろ試してみる - xxdiff

Mac で使える git mergetool をいろいろ試してみる - 準備編 の続きです。 つづいて xxdiff を紹介したいと思います。 Ot で実装されているっぽいです。 マージ結果が常に表示されないため扱いにくいです。 また、Retina に対応していないみたいで、文字が読めませんでした。 あと、日本語が文字化けしました。 設定は不要で、 git mergetool -t xxdiff とすると起動できます。 また、常に xxdiff を利用したい場合は git config --global merge.tool xxdiff としておけばよいです。 画面左に現在のブランチのファイル、画面右にマージするブランチのファイルの内容が表示されます。 キーボードショーットカットは充実しているようですが、マージ結果をみる方法がわかりませんでした。 日本語はでないし、マージ結果の出し方がわからないということで利用は難しそうでした。 関連 Mac で使える git mergetool をいろいろ試してみる - 準備編

no_picture

Mac で使える git mergetool をいろいろ試してみる - tkdiff

Mac で使える git mergetool をいろいろ試してみる - 準備編 の続きです。 tkdiff を紹介します。 名前のとおりツールキットは tk なのでマルチプラットフォームのアプリケーションです。 マージ結果が同時に表示されないので非常に使いにくいです。 最近は Mac で tk のアプリケーションの起動速度が早くなってるのに少し残念です。 ツールキットの都合、表示も他に比べると綺麗ではありません。 設定は不要で、 git mergetool -t tkdiff とすると起動できます。 また、常に tkdiff を利用したい場合は git config --global merge.tool tkdiff としておけばよいです。 画面左に現在のブランチのファイル、画面右にマージするブランチのファイルの内容が表示されます。 マージされる内容を表示するには、画面上部の緑の部分をクリックするとみることができます。 左や右やじるしをクリックすることで、変更を選択できます。 ツールキットの都合、使いにくいです。常用には耐えそうにありまんでした。 関連 Mac で使える git mergetool をいろいろ試してみる - 準備編

no_picture

Mac で使える git mergetool をいろいろ試してみる - Vimdiff2

Mac で使える git mergetool をいろいろ試してみる - 準備編 の続きです。 Vimdiff2を紹介してみます。 emacs使いですが、 vimさえ入っていれば、設定不要で、「気軽に使えるかなぁ。」という目論見です。 vimdiff2 とかいてみましたか、vim の起動方法が違うだけのような感じでした。 よくわかりません。 vimdiff でも起動できます。 設定は不要で、 git mergetool -t vimdiff2 とすると起動できます。 また、常に vimdiff2 を利用したい場合は git config --global --global merge.tool vimdiff2 としておけばよいです。 ヘルプを見るには vim を起動した状態で ` :h vimdiff で help が出せました。 pecosantoyobeに教えてもらいました。 ありがとうございます。 画面左が現在のブランチのファイルの内容で、画面右がマージするブランチのファイル内容です。 中央にはコンフリクトしたファイルの内容がでており、修正することができます。 次のコンフリクト場所に移動するには ]c で移動することができます。 前のコンフリクト場所に移動するには [c で移動することができます。 コンフリクト場所に移動して、:diffget L と入力すると 左の内容を取り込むことができ、:diffget R と入力すると右の内容を取り込むことができます。 移動も含めてショートカットを用意すると、とても便利そうです。 終了の仕方がよくわかりませんでした。 ZZZZZZ として終了しました。 もっとよい方法があるような気がします。 終了すると次のファイルが自動的に開きました。 とても便利でした。 なんとなく emacs に渡せないときに使いたいと思います。 関連 Mac

no_picture

Mac で使える git mergetool をいろいろ試してみる - DeltaWalker

Mac で使える git mergetool をいろいろ試してみる - 準備編 の続きです。 DeltaWalker を紹介します。 DeltaWalker 49ドル の有料アプリケーションで、見た感じ Eclipse と同じツールキットのようで、マルチプラットフォームを実現しているようです。 しかし、購入する際はOSを指定するので、OSごとにライセンスがいるのでしょうか。試用ができるので試してみました。 有料ツールの中では値段が安く、日本語を使用していても問題はおきてないです。 設定するには /Applications にインストールした場合は git config --global --add mergetool.dw.cmd '"/Applications/DeltaWalker.app/Contents/MacOS/git-merge" "$LOCAL" "$REMOTE" "$BASE" "$MERGED"' で設定できます。 起動するには git mergetool -t dw とするとできます。 デフォルトで起動するツールに設定したい場合は git config --global merge.tool dw で、設定することができます。 画面左にもとのブランチのファイル、画面右にマージするブランチのファイルが表示されます。中央にマージ結果が表示されています。 マージ方式は emacs の ediffと同じように、先にベースしたいほうを選びます。 そうすると細かいコンフリクト箇所が表示されるので、どちらを選択するか選ぶことができます 。 左を選ぶか、右を選ぶかを選択するための状態にもっていくのが少し扱いづらかったです。 なぜだかわからないですが、左しか選べない状態になったりしました。マウスクリックですることで直りました。 コンフリクトの修正後は、ウィンドウ閉じれば次へ勧みます。 他にコンフリクトするファイルがあれば続けて表示されます。 修正が終了するとコンフリクトしたときのファイルは .orig が末尾について保存されます。 気になる点は Java で実行するため、起動が少し遅いです。 関連 Mac で使える git mergetool をいろいろ試してみる - 準備編

no_picture

Mac で使える git mergetool をいろいろ試してみる - kaleidoscope

Mac で使える git mergetool をいろいろ試してみる - 準備編 の続きです。 Kaleidoscope を紹介します。 Cocoaアプリということで、万人にに勧めたいという理由で一番注目しております。 Mac App Store で開く 有料アプリで金額は App Store では 6100円 です。 画面は圧倒的に綺麗でMacとの親和性が非常に高いです。 画像の差分も見れたりするので difftool としても気になります。 ただし、私の環境のせいなのか、トライアルバージョンで試しているのかわかりませんがgit mergetool から上手く扱えない。 製品版なら上手いこといくのか確認したいのです。 追記: 2013-07-10 tmux 上で実行していたら発生することがわかりました。 値段的にも、インターフェイス的にも一番デザイナーさんに勧められるツールです。 追記終了 設定はとても簡単です。 ダウンロードして、起動後に メニューから integration… を選択して設定します。 install と configure をクリックすれば完了です。 ここからが問題なのですが、git mergetool で起動しても画面が出ません。 起動はするのですが、起動していた状態でないと画面がでませんでした。 起動をすれば下記のような画面が出ます。 画面も3種類あり自由に切り替えたりすることができます。 左側がマージ前のファイルのもので、中央がマージ結果で、右がマージに指定したブランチのファイルの内容になります。 下部の右下のボタンで 競合場所を移動でき、下部中央のボタンでどちらを採用するか選択できます。 これらはキーボードショートカットで、コマンド + ↓、コマンド + ↑、で、コンフリクト箇所を移動することができ、コマンド + ←、コマンド→ でどちらを採用するか選択できます。 カーソルキーを普段使う人であれば使いやすいと思います。 修正を終了するには終了すれば、プロンプトが書いてきますが、失敗しているような挙動をしていてちょっと困っております。トライアルだからなるのか、バグなのか。 タブになっているのでコンフリクトしているファイルをまとめて開いて欲しいところです。 使い勝手はよさそうなので、購入してみて、バグレポートするか悩んでいるところです。 一番期待できるだけにちょっと残念です。 追記。直せたので再度試しました。 コンフリクト修正後は保存して、ウィンドウを閉じれば次に進めます。 見た目、操作性を考えると、さすが有料アプリといったクオリティだと思いました。周りに薦めていけるツールでした。 関連

no_picture

Mac で使える git mergetool をいろいろ試してみる - ediff

Mac で使える git mergetool をいろいろ試してみる - 準備編 の続きです。 ediff は Emacs に添付されているマージツールです。 いつから添付されているのか調べてないですが最近のEmacsであれば標準で使えるはずです。 個人的には一番使いやすいと感じています。 git mergetool から ediff を起動するのはややめんどくさいです。 magitを使用していれば、コンフリクトしているファイルにカーソルを合わせて e を押すと起動できます。こちらのほうは設定いらずで楽ちんでした。 どうしても git mergetool から使いたい場合は git mergetoolでEmacsのediff-merge-files-with-ancestorを呼び出す - 工夫と趣向と分別と。 を参考にするとできました。 具体的には上記の記事で紹介されてる emacsc をclone してきて設定しました。 個人的な使い方の問題で emacsclient への引数を付加したかったので少しいじりました。 ediff を起動するとこのような画面になります。 配色設定を細かくやってないのでみづらいのは気にしないでください。 左が現在のブランチのファイルで、右がマージしようとするブランチのファイルになります。 下部がマージ結果になります。下部は直接編集することもできます。 a を入力すると 左側を選択できて、 b を入力すると右側を選択できて、下部に反映されます。 差分は2行あるのに、まとまってしまって不便に感じますが、どちらをベースするかという選択だと考えると良いことがわかりました。 その後 ! を入力すると細かく差分が表示され n や p で競合箇所を移動して a や b で選ぶことができます。 編集が終了したら q で終了できます。 magit から起動した場合は ステージングされないので注意してください。 再度 e を入力するとやりなおすこともできます。 emacs

no_picture

Mac で使える git mergetool をいろいろ試してみる - p4merge

Mac で使える git mergetool をいろいろ試してみる - 準備編 の続きです。 p4Merge を紹介します。 先に問題点などを書いておくと、日本語が利用されていると表示がずれてしまいます。 Qt が利用されているので Cocoa アプリに比べると動きは悪いですが、インターフェイスは使いやすいです。 インストールには、サイト下部の Download now をクリック後にOSなどを選択してダウンロードします。 ダウンロード後は/Application に配置します。 設定は以下のコマンドでできます。 git config --global mergetool.p4merge.path /Applications/p4merge.app/Contents/MacOS/p4merge git config --global mergetool.p4merge.keepTemporaries false git config --global mergetool.p4merge.trustExitCode false あとはコンフリクトした際に git mergetool -t p4merge と入力すると利用できます。 git mergetool だけで起動できるようにしたい場合は git config --global merge.tool p4merge としておくとよいです。 起動すると下記のような画面です。 画面中部に 左から マージしたいブランチのファイルの内容 枝わかれした時のファイルの内容 現在のファイルの内容 になってます。他とは左右が逆なので注意が必要です。 画面下部にはマージ結果の情報が出ています。 下部の右側のボタンを押すことでどちらの変更を使うか選択できます。 両方を選ぶことはできませんでした。 また、選択後に編集することもでき、アンドゥもすることができます。 ツールバー一番端で最初からやりなおすこともできて、良いと思いました。 編集後は p4merge を終了することで、次のファイルへ移行として同じ作業を繰返します。 マージする前のファイルが .ファイル名に .orig

no_picture

Mac で使える git mergetool をいろいろ試してみる - OpenDiff

Mac で使える git mergetool をいろいろ試してみる - 準備編 の続きです。 Xcode に標準添付されていた opendiff を紹介します。 Source Tree にもついてきていましたが、挙動が微妙に違いました。 設定は不要で git mergetool -t opendiff と入力すると利用できます。 git mergetool だけで起動できるようにしたい場合は git config --global merge.tool opendiff としておくとよいです。 日本語がまざっていると、 file are not ascii と メッセージ がでますが、 proceed anyway をクリックすると問題なく動きます。 opendiff で起動しますが FileMerge というアプリケーションのようです。 左側に checkout しているブランチのファイル、 右側に merge しようとするブランチのファイルが表示されます。 下側に マージ結果が表示されます。 デフォルトで 右側のものが選択されていました。 競合箇所をクリックして、画面右下の actions から選択することで、どちらの変更を使うか、両方を使うかなどが選べます。 競合箇所は真ん中の矢印がでている部分ではないと機能しないようでした。 キーボードで移動したい場合は command + d で次へ進み、 command + shift + d で前へ戻ります。 下部の部分は 編集可能で、修正を加えることもできます。 修正が修正したら、閉じてコマンラインに Was the merge successful?

no_picture

Mac で使える git mergetool をいろいろ試してみる - 準備編

この記事は すごい広島 #6 での活動の一部です。 Git で branch をマージしたときにコンフリクトが起きると、これを解消する必要があります。テキストエディタでがんばるのはつらいこともありますよね。 そんなとき、マージするためのツールを使いたい場合もあります。 Git に git mergetool というコマンドがあって、設定しておいたツールを起動することができます。 同様に 差分を見るのにGUIツールを使いたい場合などには git difftoolというコマンドもあります。 基本的には Mac で使えるものを紹介しますが、マルチプラットフォームのもあるので、別の環境でも使えるものもあります。 試したツール opendiff - 無料 Xcode に添付されている p4merge - 無料 Qt ediff(emacs) - 無料 Kaleidoscope - 有料 - Cocoa アプリ (Mac Only) deltawalker - 有料 マルチプラットフォーム vimdiff2(vim) - 無料 tkdiff - 無料 マルチプラットフォーム xxdiff - 無料 マルチプラットフォーム Araxis Merge - 有料 (Winあり) いろいろ試すために用意したもの いろいろ試すのになるべく楽をしたいので以下のリポジトリを用意しました。 Github eiel/git-merge-sandbox このリポジトリを clone して $

no_picture

最近やった Ruby でのミス - カンマで改行

Ruby かいてて些細なミスでハマったことを書いておきます。 goro = "gorogoro", hoge = "hogehoge" 1行目の最後に カンマ が入っているのがポイントです。 期待した結果は goro # => "gorogoro" hoge # => "hogehoge" です。 実際には goro # => ["gorogoro", "hogehoge"] hoge # => "hogehoge" となりました。 1行目の最後にある カンマ を削除すれば期待した結果になります。 このミスは hash で値を渡していたところを 代入に書き換えたときに発生しました。異常はテストコードのおかげで直ちに検知できました。(ちらちら) 解説 カンマのあとの改行なので、 式が完結していないので以下と等価です。 goro = "gorogoro", hoge = "hogehoge" 括弧をつけてわかりやすくします。 goro = ("gorogoro", (hoge = "hogehoge")) もうちょっとわかりやすくします。 hoge = "hogehoge" goro = "gorogoro", hoge hoge が上にきているのに注意してください。 もう必要ないと思いますが、以下と等価です。 hoge = "hogehoge" goro

no_picture

Microdata を使ってイベント情報をページに埋め込む。

この記事は すごい広島 #005 で調べたこととかです。その2。 すごい広島 は個人的な思惑として、「広島にいる表に出てこないエンジニアを発掘する。」という裏の目的があったりなかったりします。 そのためには、SEOとして効果のありそうな技術もいろいろ試してみよう。 ということで、Microformatsを使ってウェブページにイベント情報を付与してみようと思いました。 以前、ブラウザの拡張を使えば、「カレンダーアプリケーションへイベント登録が簡単にできる。」という噂を聞いたことがあったからです。 調べてみると、HTML5 には Microdata というものがあるみたいなので、Microdataを試すことにしました。 しかし、結局カレンダーに簡単に登録する方法はわかっておりません。 Microdata コーディングとSEOの概念が変わるかもしれない、Microdataについての概要 - Web Design KOJIKA17 より引用 Microdataとは何か? マークアップ言語であるHTMLは「見出し(h1,h2,h3… )」「段落(p)」「リスト(ul,ol,li)」などの文章構造を示すことができても、「人の名前」「肩書き」「地域」などを示すことができません。 それらをHTMLでメタデータとして追加する方法のひとつとして、HTML5の仕様からMicrodataというものができました。 類似の技術には、MicroformatsやRDFaなどがあります。 これらMicrodata,Microformats, RDFaを指す言葉として「Semantic HTML」などと呼ばれています。 一応自分の理解で説明してみます。 人間はページを読んでこれは「イベント情報だ」とか、「会社の情報だ」とか認識する能力がありますが、コンピュータにはわかりません。 なので、コンピュータがわかるようにするためのルールを用意しました。 このルールに従ってHTMLを書いてください。 というものだと思います。 仕様とかは下記をみてください。 Microdata Working Draft Microdata と Microformats せっかく Microfrmats の話もしたので、比較ページとしては下記のものが面白っかたです。 マイクロフォーマット(microformats) vs. マイクロデータ(microdata) - 檜山正幸のキマイラ飼育記 実際に使ってみた すごい広島のイベントページに使ってみました。 イベントの情報として、場所や日時、名前を設定しています。 Google ウェブマスターツールの構造化データ テストツールを使うと内容や、Google検索での結果を確認することができます。 赤枠の部分に日付や場所が表示されています。 具体的な読取した結果も確認できます。 この部分のHTMLは下記のようにしました。 <div itemscope itemtype="http://schema.org/Event"> <h1>日時</h1> <span itemprop="startDate" content="2013-06-26T19:00">2013年06月26日 19:00</span> <h1>開催場所</h1> <div itemprop="location" itemscope

no_picture

Jekyll を使ったGithub Pages で関数呼び出し的なことをする

この記事は すごい広島 #005 で試したことです。 Github Pages で Jekyll を使う場合は機能拡張などすることが基本的にできません。 関数のように汎用のHTMLを作成して、引数で動作を変えるようなことがしたい。 本来ではあれば Liquid のカスタムタグなどが使えるのですが、jekyll が safe モードで動いているので、カスタムタグを作成することができません。 しかし、 liquid の includeタグ を利用することでそれっぽいことができます。 流れは あらかじめ変数をセットしておく include を使う セットしておいた変数で分岐したり、表示内容として利用する となります。 変数 変数をセットするには FrontFormatter を利用するか、liquidの assignタグ か caputerタグを利用することになります。 FrontFormatterを使う FrontFormatter は ページの先頭に書く yaml の部分です。 例: title: "すごい広島 #5" date: 2013-06-19 19:00:00 place: tullys page.place という変数を追加して tullys という文字列をセットできます。 assign を使う Liquid の assign タグを利用して { % assign place = tullys % } place という変数を追加して tullys

no_picture

「Github をつかったコミュニティ すごい広島」というタイトルでLTしてきた

WEB TOUCH MEETING #58 の LT 枠ですごい広島について LT をしました。 Githubの話はほとんどしていない。最近、隔週で何か喋ってる気がする。 主な目的は みんな広島を盛り上げようぜ です。 表面的には みんなもっとアウトプットしましょう 楽しいことをしよう というのをメインに話しました。 裏の目的は 自分のツイートだってコンテンツになりえるか です。 世の中には勉強会の存在を知らなくて一人でがんばってる人がいたり、 勉強会で何をやってるのかわからなかったり、 そういう人たちに地元の勉強会の存在を知る可能性を高くする。 あと LT できる人、したがる人を増やす。 LTやる人がいないと LTをやろうと思う人も増えない。 僕は人前で喋りたくない派なので、できるのはきっかけ作りをしたい。 そういう目的のセッションをしたつもりです。 すごい広島 from Tomohiko Himura というわけで、セッション補足。 up したスライドは削ったものを追懐しています。 Github ここを見ている人に書く必要はないと思いますが、オープンソースプロジェクトをしていく上で重要なWebサービスです。 言葉慣れをしてもらうということで解説は全くしませんでした。 気軽にアウトプット 気合いれてアウトプットするにはエネルギーが必要です。大作を毎週書くのは大変です。 「気軽に書きましょう」という話をしたかったですが、時間の都合上、削除しました。 LTも気軽にアウトプットできて、影響も大きいです。気軽に作れるように練習したほうが良いと思います。 なので、気軽にLTするには 広島Ruby勉強会を使うといいですよ。 という話をあらかじめ休憩時間の告知で伏線を貼ることで、省略しました。 アウトプットをすると勉強になる、かつ、そこに情報が集まる。 アウトプットをするにはそれなりのエネルギーが必要ですが、インプットするのはアウトプットに比べるとずっと少ないです。 気軽にコメントをしてくれたり、詳しい情報を聞こうと人が集まってきたり、強力なマサカリが飛んでくることで自分の理解を促進してくれます。 また、伝えようとすることで考えを整理することができます。 そういう話をざっくりしました。 また、ツイートも立派なコンテンツになるんじゃないかと、自分のツイートをスライドに使ってみたりもしました。 これは自爆気味なのでライフポイントがガンガン減ります。 県外のほうが楽しく見える 隣の芝生は本当に青いのか。 青くないのかもしれませんが、青く見えたら人はそちらに流れていく可能性があります。 そうです。潜在的に面白い人たちが都会へと流れてしまいます。 こういった勉強会に興味を持つ人が「地元には面白いものがないから」 と、都会へと行ってしまう。 特にいまから高い可能性を持つ学生が都会へ流れずに、地元へ残る選択肢を提示していきたい。 また、面白ければ「県外から広島は楽しそうだから」と、やってくる可能性もあります。 僕だって楽しいところに行きたいもの。 じゃあ、楽しくするしかないじゃないか。 楽しければいいの? ここは削った部分です。 「楽しいだけの勉強会は人は集まらないし、本格化しない。人が集まらないので継続は難しい」そんなマサカリを受けたことがあります。 ビジネスにならないとメリットを感じることが難しいので人がこないという話ですね。 実際、Ruby勉強会の参加者のほとんどがRuby初心者です。 でもね、エンジニアはビジネスをする人じゃない。

no_picture

Rails で AngularJs を使おうとしてみた

<htmlday> 2013でやったことプラスアルファ。 足りなかった部分はすごい広島 #4内で調査しました。 <htmlday> では AngularJS で遊びました 前にAngularJSを利用したときの復習 AngularJS を rails で使うのに使えそうな gemの調査 <html ng-app> と書けないの時の対処方法 AngularJS を rails で使うのに使えそうな gemの調査 とりあえず、Ruby Toolboxで angularを検索してみました。 候補としては angular-rails anglurajs-rails angular-gem angular-rails-engine と、乱立状態でした。他にもありましたけど、見る元気はありませんでした。 結論をまとめておくと 素の AngularJs でいいのなら angularjs-rails generatorなど、もしかすると便利になるものがあるかもしれないのが angular-gem という感じでした。 まずは、angular-rails を試しました。generator などついていますが、AngularJSの本体が更新されていない状態でした。 また、添付されている angle.js を読み込みすると動作しなかったりと問題もちらほらありました。 次にみたのは angularjs-rails です。これは Javascriptが添付されているだけのシンプルなものでした。添付されているものも最新で、unstable な最新バージョンも添付されていました。読み込みたいだけならこれで良さそうです。x unstableなバージョンをよみこむ場合は application.js に //= require_tree ./angular/unstable と、かけば良さそうです。 3番目に angular-gem です。前述の angularjs をフォークして複数のversion のAngularJSを取りこんでいたりと、なかなか意欲的です。 4つ目は angular-rails-engin です。angular_include_tag というヘルパーを提供してくれて、必要に応じて読込みして使う感じになるようです。 とりあえず、 angular-gem を試していこうかなと思います。

no_picture

Gitリポジトリを直接動かして変更を検知 - QA@ITで遊んでる

朝早く起きることができたら、QA@ITで、遊んでいます。 ざっと未解決の質問を見て、すぐわかりそうなものを試して解答をします。 今日は 「rails new project -d postgresql を指定した時に変更される部位」というのがあって、「試せばいいやーん」と思ったので、すぐに手を動かしてみました。 rails new project と rails new project -d postgresql の違いについて。 だいたい以下の操作をすれば違いはわかります。 rails new project mv project project_sqlite3 rails new project -d postgresql diff -ru project_sqlite3 project とすれば違いは簡単にわかります。 new の引数は同じ名前にしないと、余計な差分ができてしまうので、作成した後に リネームしています。 折角なので Git を絡めてみた Git のリポジトリって直接移動してもそのまま使えるんだぜ! rails new project mv project project_sqlite3 cd project_sqlite3 git init git add . git commit -m 'initial' cd .. rails new project -d postgresql mv project_sqlite3/.git project cd project git diff という、感じの解答をしてみました。 .git を移動をしてるのが味噌です。 リポジトリに対する物理的なワークツリーが変わっても簡単に認識してくれます。 このようにGitの理解が深まってくると応用力がついてきて、「subversion より Git 楽しいなぁ」と、個人的にはなります。 別解 git には リポジトリを指定するオプション --git-dir があります。 なので以下のような方法もあります。 rails new project mv project project_sqlite3 cd project_sqlite3 git init git add .

no_picture

このコード書いた誰だよ! そんな時の git log -S でもしてみよう

広島Git勉強会 で @pecosantoyobe が git log の使えるオプションについて語るというナイスなセッションがありました。 その中で git log -S の紹介がありましたが、説明が難しそうなので、さらっと流れてしました。 折角なので実例を紹介します。 複数人でプログラムを書いてると、「このコード書いたの誰だよwww」 的なことが稀にあります。 例えばこんなコードがあるとします。 class Sample def hoge hogehoge_gorogoro.to_sym.to_s end def hogehoge_gorogoro "hogehoge_gorogoro" end end 「hogehoge_gorogoro.to_sym.to_s ってなんだよ!! 意味あるのかよ!」 みたいなことがあると思います。 そんな時はすかさず git blame を利用します。 みやすさの都合上、emacs の magit-blame を利用します。 e92db224 で変更されていることがわかります。 ちょっとこの時のコミットを見てみましょう。 git show e92db224 インデントの修正されているだけで、大した情報が得られません。 こんなときに git log -S を使います。 git log -S 'hogehoge_gorogoro' --patch 変更内容が見たいので、 --patch をつけました。 「なんだよ。initial commit ではじめからそーなのかよ!!」 なんて展開でした。 ちょっと例が凝れてなくて便利さが伝わりにくいかもしれません。 diff の内容から更に git log -S で追ってみたりできます。 もし良いコミットログがあれば、コードの意図がわかったり チケットID などが記載されていれば、そちらを参照することになります。 「なんだよ。書いたのオレじゃねーか!!

no_picture

広島Git勉強会 - 番外編 Github Flow してみる

書きわすれたことがあった。 ひとつ前のエントリはそれはそれで完結してるので、追記せず、別にしてみる。 そういえば、ひとつ前のエントリーうっかり Ruby勉強会って書いてました。見なかったことにしてください。 広島Git勉強会 の終了後に懇親会の代わりに、別の教室で Github Flow体験をしました。 やることの手順ははGistにかいてます そしてその成果物がこの辺です もし、やってみたい方がいれば気軽に挑戦してみてください。Issueにそれっぽいことを書いてもらえたら大丈夫です。 先に空のブログ記事をつくって pull request して、あとからブログに感想を書くなどでも大丈夫です。もっと面白いことが思いついたらそれでもOKです。 やってみて思ったことですが、Git普段使ってない人であれば、これだけでも結構難しいようでした。 次回やるときはもっと準備しておこうと思います。 関連リンク 広島Git勉強会 - 番外編 Github Flow してみる Github Pages について整理しておきます Github で Jekyll を使う時に調べたこと Git がわからなくても Github を利用しよう Github の楽しみ方

no_picture

広島Git勉強会 201306 - やりなおせるGit入門

広島Git勉強会 に参加しました。 1セッション喋りました。 はじめからgit reset と git checkoutあたりを説明しようと思ってたのですが、「元に戻せること」を主眼においていろいろ考えました。 結果として、「危険」「少し危険」なコマンドを定義して、よくわからない時どうすればいいのか伝えられるか試みてみました。 「危険」なコマンドはワークツリーにした変更が消えてしまう恐れがあるもの。 「少し危険」なコマンドはgit reflogなどを利用しないと追えなくなるコミットができてしまうもの。 と定義して、そこを強調しながら説明してみました。 スライドはこちらに。 やりなおせる Git 入門 from Tomohiko Himura 結局、難しかったのか簡単だったのか、周りの空気を読む余裕が僕にはまだまだ足りなくて、「経験値を積まないといけないなぁ」と、思うのでした。 追記 ブクマのコメントなどなどに返信 「git commit の -m はそろそろ卒業しましょう」というのはどういうことなのかな? -m って解説のために、そう書いてることが多いじゃないかと思う。スライド上でも -mを利用していますが、こ の場合はコミットログをタイトルしか書かない場合が予想できる。なので、「概要も書きましょう。」という話をするために書いています。 良いまとめ。だけど rm -rf .git ってそんなにカジュアルでいいのかなw すごく危険な操作なので、カジュアルにやるのはよくないですが、初回のコミットまでなら。という感じで口頭では伝えております。スライドにも入れればよかった。 関連リンク 広島Git勉強会 - 番外編 Github Flow してみる 岡山Git勉強会 - 20130223 - Git 仕組み入門 という話をしてきた Git がわからなくても Github を利用しよう Github の楽しみ方

no_picture

Polymer という Web Componets のラッパーを試した

Google I/O で紹介されていた Polymer という JavaScript で少し遊びました。 Web Components という Web の UI を コンポーネント化するための仕組みがあります。 これをラップして 使いやすくしてくれる Polymer です。 遊んだ結果はこの辺 rake preview でウェブサーバが起動するので http://localhost:4000 でアクセスできるようにしています。 ポイントは カスタムタグが作れる 属性でコンポーネントに情報を渡せる コンポーネントは独立した HTML ファイル linkタグ で読み込む コンポーネントを指定できる Web Components に比べて記述良が少ない といっところでしょうか。 index.html は下記のようになっています。 <!DOCTYPE html> <html> <head> <script src="polymer.min.js"></script> <link rel="import" href="my-element.html"> </head> <body> <my-element hoge="goro"></my-element> <my-element hoge="mogu"></my-element> </body> </html> Polymer を読み込んで my-element という コンポーネントを読み込んで my-element タグ で利用している という流れです。 hoge属性で my-element コンポーネントのボタンのラベルを変更しています。 my-element.html は下記のようになっています。 <element name="my-element" attributes="hoge"> <template> <div> <span>I'm <b>tk-element</b>.

no_picture

cleditor の内容を javascirptで変更する in Cucumber

Cucumber の @javascript で実行しているシナリオに ]cleditor](https://github.com/cleditor/cleditor/blob/master/jquery.cleditor.js) という WYGSYG が利用されていて 普通に値を代入しただけだと反映されない問題に直面した。 caybara のドライバーには poltergeist を使用しています。 バリデーションをかけていて、入力しないと進めないので、javascriptを使って入力することにした。 $(selector).data('cleditor').$area.html( content ); .data(‘cleditor’).$area というところに情報が保存されていることがわかったので、そこのHTMLをさしかえます。 Safari で実行した場合は画面表示は変更されないので注意です。 これを cucumber の step で実行したいので、 description = "hogehoge" code = <<"JAVASCRIPT" $('#hogehoge').data('cleditor').$area.html('#{description}'); JAVASCRIPT evaluate_script(code) として、 evalute_script を利用して実行しました。 data属性にデータを保存しておくのは一般的なのかな?この辺の事情はよくしりません。

no_picture

Github Page で公開する サイトを ローカルで preview するのに使ってる方法

すごい広島 #2 でしたことを書きます。 日記のほうはこちら 2013年8月23日追記。下記の方法を改良したものがあります。 ローカルサーバ起動と同時にブラウザで開く。 - Jekyll とかで。 以上、追記終了。 私は、Jekyllを使用したサイトをプレビューする際に、jekyll のインターフェイスが変化しても、または、jekyll 以外のものを使用しているときのことも考えて、 rake preview でサイトのプレビューをできるようにしています。 「Octopressでも、Hakyll でも Jekyll でも rake preview にしたいんだ!!」 具体的には以下のような、Rakefile を作成しました。 desc 'preview する。 http://localhost:4000/' task :preview do sh 'bundle exec jekyll serve --watch' end Jekyll は v1.0.0 で preview するためのコマンド名が変わりました。 あとは、他の人が gem のインストールのを軽減するために、Gemfile も書きました。 source 'https://rubygems.org' gem 'jekyll', '=1.0.2' gem 'liquid', '=2.5.0' gem 'redcarpet', '=2.2.2' これで、ruby と bundler さえ入っている人は bundle instnall というコマンドを実行すれば、サイトのプレビューができるようになります。 bundler は gem

no_picture

セキュリティもみじで空気読めてないLTをしたんだ - すごい Hiroshima で楽しく学ぼう

先週の土曜日にセキュリティもみじで 5分の LT をしました。 セキュリティの勉強会なのに、セキュリティと全く関係なかったり、5分を超過してたり、痛いツイート引用していたりと、恥ずかしい限りです。 しかも、ターゲットに設定していた広島の若い人が……参加してない! という、致命的な問題が発生しました。 仕方ないので、ネタにしておきました。 すごい Hiroshima で楽しく学ぼう from Tomohiko Himura タイトルの元ネタは言わずとしれた、「すごいH本」で知られる [すごいHaskell 楽しく]http://www.amazon.co.jp/gp/product/4274068854?ie=UTF8&camp=1207&creative=8411&creativeASIN=4274068854&linkCode=shr&tag=eiel-22() です。 良本なので、まだ読んでない方は、ぜひ。Haskell を使う機会がなくて新しい視点を得るヒントになるかもしれません。 LTは Haskell ともなんにも関係ないし、説明する時間もありませんでした。 話を戻します。 つまり、広島は盛り上がってるのか、盛り上がってないのか。 どちらでも構わないから、もっと盛り上げたらいいよね。 そういう気持ちの話しをしてきました。 人前で話すのは本当に苦手です。 だからといって、何もしないのでは期待するような結果にはならないです。 ならば、まずは自分にできそうなことをやる。それだけです。 「地元がよいけど、やっぱ都会のほうが楽しいよー」って、人たちが「地元楽しいな!」になると良いですよね。 このセッションに便乗したわけではないのですが、すごい広島 という Meetup 的なものをはじめてみたりしました。 毎週水曜日にやってみようと思います。 おしい広島にもなんとなく音が近いですね。 Asakura.rb 的なものがやってみたかった。 実は参加したことがないのでどんなやり方なのか実はさっぱりわかっていません。 岡山でも Okayama.rb というのを毎週やっていて、対抗したい意識があったり、なかったりです。 やり方がよくわからないので自己流で裏テーマとして Github の使う ブログを書く週間をつける というのも兼ねてみてます。 「これは意識高すぎるんじゃね?」という意見もちょっと出てて、ちょっと迷い気味。 敷居もなるべく下げたい。 盛り上がりというのは、正のスパイラルで、そこからはずれてしまうと、負のスパイラルに落ちいってしまう印象があります。 良い方向へ進めばどんどん良い方向に進むと思います。 悪い方向へ進んだら、ゼロからやりなおせばいいです。 とりあえず、まずは周りから。

no_picture

cucumber で PhantomJS を使う

Cucumber で使うブラウザを PhantomJS にしたい。 Cucumber -> Capybara -> Poltergeist -> PhantomJS という感じに利用します。 PhantomJS は画面のないブラウザと言うと、伝わりやすいでしょうか。 統合的なテストを行う場合、Rails プロジェクトでは Cucumber がよく使われています。 Cucumberのシナリオに @javascript というタグをつけると Selenium を利用して Firefox を制御してテストを行うことができます。 非常に便利なのですが、処理が長かったり、また、X11の起動してない Linux などで動かそうとするとちょっと問題がおきます。 そこで、画面の表示をしないブラウザでテストしたくなります。 また、実際によく使うわれるのはレンダリングエンジンは Webkit です。 そのためのブラウザとしての有力候補が PhantomJS です。 PhantomJS のレンダリングエンジンは Webkit で、必要であればスクリーンショットがとれます。 Travis CI でも利用できるようです。(未確認) 利用までの手順としては PhantomJS のインストール Rails プロジェクトに Poltergeistを追加 featrue/support/env.rb を設定 となります。 PhantomJS のインストール http://phantomjs.org/download.html から ダウンロードできます。 Mac であれば Homebrew や Macport でインストール可能なようです。ダウンロードしても bin/phantomjs を 環境変数PATH に入っているところに配置するだけです。 Rails プロジェクトに Poltergeist を追加 Gemfile に group :test do gem 'poltergeist' end と追記すれば良いです。 feature/support/env.rb を設定 設定しないと使えません。 feature/support/env.rb に以下を追記すればよいでしょう。 require 'capybara/poltergeist' Capybara.javascript_driver = :poltergeist @javascript つけるのがめんどくさい!

no_picture

AutoLayout TIPS - 真ん中に固定幅のスペース

AutoLayout になかなか慣れません。 そうは言っても使わなければ、身につかない。 というか久しぶにりiOSのコード書いてるだけな気がする 今回挑戦したのはふたつのViewの間に固定幅をスペースをつくりたい。 具体的には以下の感じ。 書いた VisualFormatLanguage はこんな感じ。 |-[_leftView]-40-[_rightView]-| [_leftView(==_rightView)] V:|-[_leftView]-| V:|-[_rightView]-| 以下のように書いてもよい。 |-[_leftView(==_rightView)]-40-[_rightView]-| V:|-[_leftView]-| V:|-[_rightView]-| やってみると簡単。 プログラムで気軽にレイアウトできる。 具体的なソースコードは Github に アップしています。 主な処理はこの辺にあります。 簡単に解説 頭に V: がついているのは 縦方向に対する設定です。 |- の部分は OS 標準の幅になります。ぴったりつけたいなら、|-0- とします。 縦方向の左側 だけやってみます。 V:|-0-[_leftView]-0-| まとめ なれるまで発想のセンスがいる気がします。 論理的な手順で、作りたいレイアウトをするのはまだまだまだ説明できそうにないです。

no_picture

Github の楽しみ方

みなさん Github を楽しんでいますか? まだ利用してない場合は、利用しましょう。 「利用しはじめたけど、もう一歩進みたい…」という人のために、私なりの楽しみ方を紹介しておきたいと思います。 今回は以下の遊び方について書きます。 友人のリポジトリにちょっかいを出す 有名なリポジトリに名前を残す 毎日活動して Longest Streak の記録を更新する 友人のリポジトリにちょっかいを出す Github は 「SNS」 です。 SNS なのでは人とコミュニケーションをとって遊びましょう。 なので、コミュニケーションをしましょう。 Github ではユーザ同士がコミュニケーションを取る主な方法は コミットへのコメント Issues Pull Request があります。 こういったものはまずは友人に対して行うのが気軽で、オススメです。 しかし、リポジトリを作成したことや、コミットされたことに気づかなければ、コミュニケーションを取る機会がありません。 友人がリポジトリを作成したことに気がつくためには、友人をフォローしておくことです。 以前紹介しているので、ここを読んでいる方はフォローしていると思います。 これで News Feed を見る癖がついていれば、友人がリポジトリを作成したことに気がつくようになると思います。 しかし、コミットされ、プッシュした情報は流れてきません。プッシュされたことを知りたいなら、watch をしましょう。 Watch する watch をするには リポジトリのページへ移動し、以下の画像の示す部分を Watching にします。 watch するとそのリポジトリへの push や Issuesの作成、 Pull Request の作成などの情報が流れるようになります。 ここまで来れば日々チェックして、相手の隙を伺いアタックをしていきます。 コミットへのコメント Github ではコミットに対してコメントをすることができます。 また、コミットに関連しているファイルの特定の行にもコメントを付けることができます。 まずは、Github で コミットを見てみましょう。 参考用に利用するリポジトリは eiel/hiroshima_hall にしました。 コミットを見るにはコミットを見つける必要があります。 一般的な方法としては 「コミットの一覧」 > 「コミット」と進めばコミットのページへいけます。 コミットの一覧を見るには以下の画像を参考にしてください。 そこからコミットを見るには、見たいコミットの`コミットIDをクリックします。

no_picture

rails4 で Asset の生成したいファイルの追加がうまいこといかなかった。

Rails4 を試していた。 1ページだけ全く違うデザインがあって js とか css を application.js とか application.css とは別に生成したかった。 ということで `config/environments/production.rb’ に config.assets.precompile += %w( hoge.js ) と書きました。 なぜか生成されない。Rails3 では間違いなく生成される。 調べてみたところ config/application.rb に書けば動くことがわかった。 それだけ。

no_picture

rails4 rc1 がリリースされたことだし beta1 からアップグレードしてみた

Rails 4.0 rc1 がリリースされてますね。軽いノリでアップグレードしてみたら余裕で起動しませんでした。 アップグレードするには Gemfile を以下の編集をしました。 -gem 'rails', '4.0.0.beta1' +gem 'rails', '4.0.0.rc1' gem 'pg' # Gems used only for assets and not required # in production environments by default. group :assets do - gem 'sass-rails', '~> 4.0.0.beta1' - gem 'coffee-rails', '~> 4.0.0.beta1' + gem 'sass-rails', '~> 4.0.0.rc1' + gem 'coffee-rails', '~> 4.0.0.rc1' あとは bundle update そんでもって起動すると下記のエラー。 gems/railties-4.0.0.rc1/lib/rails/application/configuration.rb:144:in `const_get': uninitialized consta nt ActionDispatch::Session::EncryptedCookieStore (NameError) CHANGELOG.mdには Automatically configure cookie-based sessions to be encrypted if secret_key_base is set, falling back to signed if only secret_token is set.

no_picture

i18n で ActiveModelを使ったモデルの日本語化

ActiveModel を利用したモデルで i18n を利用しようとして以下のようなyamlを書いたら日本語にならなかった。 activerecord: models: page: "ページ" ソースコードを読んでみた結果、 activemodel: models: page: "ページ" と、書けばいいことがわかりました。 「それはそうですね。」という結果でなんとも言い難いです。

no_picture

広島マックユーザグループで 黒い画面入門 + パッケージ管理画面の話をした

広島マックユーザーグループ の勉強会 で「黒い画面入門 + パッケージ管理紹介 + Macの使い方とか」と称して稚拙なセッションを担当しました。 黒い画面入門 広島マックユーザグループは開発者ではない方が多く参加されるので、パッケージ管理システムの話をする前に UNIX 的な話をしてみました。 正直な話、何を話すか自分の答えが出ず、迷走した感があります。 結局ですが、「リダイレクトとパイプの話を20分でする。」という裏目的のスライドになりました。 ちなみに20分どころか 30分使いました。それでも速かった。 そもそも大学の授業で2コマぐらい使いそうな内容な気がするので、「がんばって必要最低限の知識を詰め込みをしました。」という仕上りになっているんじゃないだろうかと思います。 Macの使い方の部分はやりたかったことはあるのですが、時間も準備もなかったのでサラッと流した感じになりました。また別の機会に。 黒い画面入門 + パッケージ管理紹介 + Macの使い方とか from Tomohiko Himura パッケージ管理ツールの紹介 どちらかというと今日のメインです。 がんばって普段使わないものと基本的な比較をしてみました。 どれもマサカリが飛んできそうなところで非常に怖いところです。 Mac OS X のパッケージ管理紹介/比較 from Tomohiko Himura いろいろ使ってみての感想ですが、Macports が良い感じでした。 Finkは日本語が化けたという話をし忘れました。 ウェブサイトも日本語化されていますが、更新がだいぶ遅れているようなので注意してください。 ちなみに資料とかメモとか Github に丸投げしております。

no_picture

「数学文章作法 基礎編」 が心に残り過ぎて、しばらく持ち歩きたい。

数学文章作法 基礎編 読みました。 どこを読んでいても、すごく読者を大切にしてることが伝わってきます。 文章を書いてるすべての人に、「読者のことを考えて欲しい」と伝えたい。 文章だけでなくて、何かを伝えたいことがある人に、「相手のことを考えて欲しい」と伝えたい。 Booklog にも拙い感想を書きましたが、とても素晴しい一冊でした。 しばらく持ち歩いて、「読者のことを考える」ことを癖にしたいです。 この本のタイトルと著者を見た瞬間に迷わず、予約しました。 数式の混ざるような文章は書くことは当面ないとわかっていて理解していました。 それだけ、著者の結城浩さんの伝わる文章、わかりやすい文章を身をもって何度も体感していたからです。そのノウハウが詰まっていると期待して迷わず購入しました。 その期待は全く裏切られることはありませんでした。 私たちは様々な場所で文章を書きます。 特にメールを書く人は多いと思います。 メールは伝えるために書く文章です。 誰が書くメールであっても、相手に何か伝えたいことがあります。 メールを読む相手のことを考えて書きたい。そう思いました。 私はブログを書いていますが、自分のために書いてるものが多いです。 細部を気にしたり、読者のことを考える必要はあまりありません。 それでも、人の目に触れる場所に書いています。 どうせならば少しでも伝わるように書きたい。そう思いました。 Facebook に友達に伝えたいことがあって書くことがあります。 伝わるように書けば、「いいね!」もたくさん付くと思います。 伝えることがもっと楽しくなると思いました。 気がつくと文章の書き方の書籍から、いつのまにか「相手を大切にする」こと考えていました。 人に伝えることをはじめたいです。

no_picture

Windows8 を触ってみての感想

お仕事で Windows8 を触る機会がありました。ちょろちょろいじっております。 大概作業は Emacs と ターミナルで行う僕の感想を書きます。。 クラシックデスクトップで生活する人からみると、かっこ悪くなったんじゃないだろうか。 クラシックデスクトップとModern UIとの相性がいまいち。 Modern UI の中で大半の生活するなら素敵な世界だと思う。かゆくなったらデスクトップへ。 フラットデザインということで、影とかつやつや感がなくなってしまいました。 なんだか寂しい。退化した感じがします。 クラシックデスクトップをModern UIと同じ世界感においてしまった故の状況ですが、別世界として扱う手法もあったんじゃないかという感想を抱きました。 Google chrome をインストールしてみたら Modern UI なアプリでした。クラシックデスクトップで使用するように切り替えることもできます。 別に悪くない。 ただ、Modern UI の状態で使用してダウンロードして実行すると、通知がなにもこない。クラシックデスクトップにもどって始めてきづく。 ただ、最大化して使うことが多くなった最近のアプリケーションが多くて、いつのまにか埋もれしまうことが多発。 しかし、タッチデバイスの操作感の統一性はよくて、慣れと目的さえ見えていれば、直感的です。パーソナルコンピュータとしてはより人にやさしくなった。 開発マシンとしては…いままでどおりいけばいいのか。 デスクトップはリッチに見せて欲しいのは、Macユーザのエゴなのでしょうか。

no_picture

rbenv install したときに 一緒に bundler をインストールする

rbenv install したときに bundler ぐらい自動で入って欲しいですよね。 たぶん。今日、そういうツイートを見ました。 rbenv には hook という機能が用意されているのでこれを利用するとできます。 hook したときに呼ばれるスクリプトは以下の場所に配置できます。 ${RBENV_ROOT}/rbenv.d /usr/local/etc/rbenv.d /etc/rbenv.d /usr/lib/rbenv/hooks 環境変数 RBENV_HOOK_PATH を設定すると好きな場所に配置できます。 私はホームディレクトリにおきたいので指定しました。 export RBENV_HOOK_PATH="$HOME/.rbenv.d" 必要に応じて .zshenv や .bash_profile などに書き込みましょう。 以下、 .rbenv.d に設定したと仮定して話をします。 rbenv install 時 にhook するスクリプトは .rbenv.d/install におきます。 拡張子を bash にする必要があります。 .rbenv.d/install/install_bundler.bash というファイルを作成して、 #/bin/sh after_install 'RBENV_VERSION="$VERSION_NAME" gem install bundler' とかいておけばOKです。 $ rbenv hooks install で rbenv install で hook される script を確認することができます。 rbenv-hooksというリポジトリをつくったので、作るのがめんどくさい人は環境変数を設定して、clone してください。 $ git clone git://github.com/eiel/rbenv-hooks.git ~/.rbenv.d READMEかかなきゃ…。 もうちょっと詳しく after_install というのは ruby-buildの rbenv-install で定義されてる関数です。 同様の関数として before_install があります。 このへんは ruby-buildの独自機能のようです。 rbenv hooks 自体は rbenv の機能です。 rbenv の各コマンド実行後に実行したいスクリプトがあれば、同じ手法が使えます。 ただ、対応してないコマンドもあるようなので、使いたくなったら、適当に追記して pull request すればよいと思います。(たぶん) # Load plugin hooks.

no_picture

rbenv で Ruby の version を一時的に切り替え

rbenv で ruby の version を一時的に切り替えたい場合があります。 rbenv は名前のとおり環境変数で挙動を変更することができます。 RBENV_VERSION を設定しておけばそのRubyを実行をすることができます。 $ ruby -v ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-darwin12.2.1] $ RBENV_VERSION=1.9.3-p0 ruby -v ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-darwin12.3.0] ruby だけでなく gem や gem で installしたコマンドにも有効です。 おまけ rbenv local でそのプロジェクトで使用するRubyを設定できますが、.rbenv-versionというファイルを生成します。 まれに、生成したくない場合があります。 例えばホームディレクトリにいるときです。 広い範囲で影響がでます。 rbenv global を使えばいいという説もありますが、バックグラウンドで ruby の script が動いていると必要な gem がないということが起きることがあります。 そんなときは rbenv shellが使えます。 一時的に ruby の version を固定できます。 $ ruby -v ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-darwin12.2.1] $

no_picture

cucumber で シナリオを Ruby のバージョンによって実行しなかったり

どんなにがんばっても ruby 1.8.7 では動かすことができない cucumber のシナリオがあって、これを対応した時のメモ。 結論から書いておきます。 @fails_on_1_8_7 というタグを使って、失敗するシナリオをタグづけ cucumber の profile に ruby_1_8_7 をつくり --tags ~@failds_on_1_8_7 を設定 rake 実行時に RUBY_VERSION をみて profile を ruby_1_8_7 になるように設定 です。 テストは Travis CI で実行します。Travis では rake が実行されるので、rake 実行時にprofile を切り替えるようにしました。 もともとそのプロジェクトには ruby_1_9 というのと ruby_2_0 というのがあったのでそれらに合わせました。 具体的には cucumber/cucumber に出したpull request です。 ちょっと掘り下げておく。 cucumber には profile という機能があって、あらかじめ設定しておいたオプションを切り替える機能があります。 cucumber --profile ruby_1_8_7 みたいに使います。 これを rake task に割り当てるには Cucumber::Rake::Task のインスタンスのprofile に渡してやればいいです。 new したときのブロックの第1引数が Cucumber::Rake::Task そのものです。 例: Cucumber::Rake::Task.new do |t|

no_picture

Rails で外部キー制約

外部キー制約は好きですか? O/RマッパーしててもなるべくDBの力は借りたいです。 ということで、Ruby Toolboxで foreign を検索して、ちらちら見て一番人気のforeignerを選びました。基本的にはデータベースに丸投げなので Rails4 でもいまのとこ問題なく使えております。 インストールは Gemfile に: gem 'foreigner' と追加して bundle install あとはマイグレーションで: create_table :comments do |t| t.references :post, null: false, index: true t.foreign_key :posts, dependent: :delete end としておきました。 ついでに確認。 存在しない 外部キーを指定すると保存を失敗する確認。postgresの例: Comment.create(post_id: 1) # => PG::Error: ERROR: insert or update on table "comments" violates foreign key constraint "comments_post_id_fk" キーを指定して、親になるオブジェクトを削除すると消える確認: Comment.create(post_id: Post.create) Comment.count # => 1 Post.count # => 1 Post.first.destroy Post.count # => 0 Comment.count

no_picture

広島Ruby勉強会 #031 で 「Hakyllで遊んだ」のでざくっと紹介した。

広島Ruby勉強会 #031 で かるくLT しました。 内容は Hakyll についてです。 なのですが、Rubyのリファレンスからメソッドの紹介をしているのですが、今回は ActiveSupport で追加される メソッド。Array 編をしました。 その資料はこちらに。 この資料をどこにどうやって置こうかな?と思っていたので、ついでにHakyllを試してみました。そこで学んだこととかを紹介しました。 Hakyllで遊んでみた。 from Tomohiko Himura このサイトのソースコードは Github に丸投げしていたりします。 このスライドに書いてないことでは、コンパイルを毎回するのがめんどくさかったので、ghci から 引数付きで main 関数を実行する方法を調べました。 System.Environment に定義されてる withArgs を使えばできました。 withArgs :: [String] -> IO a -> IO a 利用例: withArgs ["build"] main 第1引数にコマンド引数をリストで渡してしまえば、良いようです。

no_picture

Ruby で モナドを書いてみた。

ちょっと気分転換したかっただけで、反省している。(2015年4月11加筆修正) 記事を書く目的があったわけでも、何か確認したかったわけでもないけど、自分的に得るものがあったので、それを書いておきます。 Rubyでモナドをつくってみました。 ソースコード モナドってモノイドに名前が似ていることからわかるようにモノイド的な特性があるらしいです。 Wikipedia:モノイド 今回の話は、モナドだと簡単にモノイドが作れるという話のような気がする。 結合律 モノイドであれば結合律が成立します。 結合律をプログラミングに当てはめてみると func1(); func2(); func3(); という命令列があった場合 func1(); func2(); func3(); と func1(); func2(); func3(); は等価と言えるという話にできます。 違いがよくわからないので、別名をつけてまとめてみます。 funcX(); // funcX () { func1(); func2(); } func3(); func1(); funcY(); // funcY () { func2(); func3(); } どちらも同じように動きますよね。 セミコロンを演算子とみたててみます func1 ; func2 ; func3 最後のセミコロンはみにくいので削除しました。 (func1 ; func2) ; func3 == func1 ; (func2; func3) 単位元 単位元の存在 - 演算してもコンテキストが変化しない値が存在する プログラムでいえばセミコロンだけでかこまれていればそんな感じになりそうです。 func1; ; // あってもなくても変わらない func2; かけ算で考える

no_picture

Rails で ajax をちょっと実験するときに `render text:` すると コールバックしてこない。

サンプルコードがなくて申し訳ないです。 rails で ajax を使用とすると 一般的には jquery-ujs を利用します。 あるリンクをクリックする時に非同期に読込みたい場合は <%= link_to 'hoge', @user, class: user-link %> に対して、 remote: true を追加します。 <%= link_to 'hoge', @user, remote: ture, class: user-link %> といった感じになります。 あとはサーバからのレスポンスが返ってきた時の処理を書きましょう。 $(function () { $(document).on('ajax:success', '.user-link', function (ujs, content, status, xhr) { $('#user-info').html(content); }); }); 少し説明不足ですが、気にせず。 さて、ここで リンク先が未実装で手抜きして: class UsersController def show render text: 'hoge' end end と、さくっと実装しちゃうと さきほど実装した javascript の コールバックが呼ばれません。 めんどくさがらずに、 app/views/users/show.htmle.rb などを作成してあげましょう。 そんなこと滅多にないか…。

no_picture

Ruby の とあるクラスの実装がどこにあるかわからない時の方法 - コードリーディング

広島Ruby勉強会 のネタ探しをしていて、「実装見てなにか面白いネタないかなー。」 って時に使ったコマンドを紹介。 例は Method クラスの実装を探す。 まずは git でソースコードをとってきている場合。 $ git grep 'rb_define_class("Method"' proc.c: rb_cMethod = rb_define_class("Method", rb_cObject); git grep を使います。git grep はサクサクなのでメインの探索方法です。 Emacs上から使うとジャンプも楽チン。 「git リポジトリじゃねーよ」って時は ag を使います。 $ ag 'rb_define_class\("Method"' proc.c 2331: rb_cMethod = rb_define_class("Method", rb_cObject); こちらは行番号とかでます。 ( のエスケープがいります。 ag というのは the silver searcher のことです。こちらも emacs から使う helm-ag というのがあるのでオススメします。 使える正規表現も違うような気がするので凝ったことがしたいならこちらを。 rb_define_class というのは Ruby の C API で クラスオブジェクトを作成します。このあたりに メソッドをクラスに紐づける処理なんかがあったりします。 それでは Happy な ソースコードリーディングを。

no_picture

libv8 が コンパイルしたり、バイナリで入ったりで、気になったので少し調べた。

気になったというか、環境によって失敗すると言われてしまった。 libv8 は the ruby racecer のバックエンドです。 調べてみると、「libv8 はバイナリバージョンの gem」 と「ビルドするバージョンの gem」があるのですね。 バイナリバージョンは当然のようにアーキテクチャごとあるようです。 libv8のバージョン一覧 3.16.14.1 March 28, 2013 x86_64-darwin-10 3.16.14.1 March 28, 2013 3.16.14.1 March 28, 2013 x86_64-linux yanked 3.16.14.1 March 28, 2013 x86-linux yanked 3.16.14.0 March 28, 2013 3.15.11.1 January 8, 2013 yanked 3.15.11.0 January 8, 2013 x86_64-linux yanked 3.15.11.0 January 8, 2013 yanked 3.11.8.17 March 22, 2013 x86_64-linux 3.11.8.17 March 22, 2013 x86_64-darwin-12 3.11.8.17 March 22, 2013 x86-linux

no_picture

ActiveModelを利用してフォームを作成した時の型変換

対応するレコードがないフォームを使う場合、ActiveModelを使用することで、シンプルなビューを構築しつつ、処理はモデルにかけます。 しかし、ActiveModelのノウハウってあんまり落ちていません。 それなりに ActiveRecord に対する理解も必要で、難しいですね。 ハマったことなど共有していきたいと思います。 フォームからのデータは文字列ですが、ActiveRecord にはコラム自体には型があるため、型変換を自動的に行ってくれます。 これを無意識に使用していると ActiveModelではまります。 具体的には以下のテーブルがあったとします。 class CreateUsers < ActiveRecord::Migration def change create_table :users do |t| t.string :name t.integer :age t.boolean :is_person t.timestamps end end end 利用例を見てみましょう。 user = User.new(age: '20') user.age # => 20 user.age.class # => Fixnum user = User.new(is_person: "1") user.is_person # => true user.is_person.class # => TrueClass 文字列から作成しているけども、自動的に数値や、真偽値へと変換されています。 ActiveModel を使用する場合は以下のように実装しておくとよさそうです。 class User2 attr_reader :age, :is_person include ActiveRecord::ConnectionAdapters def initialize(attributes = {}) attributes.each do |key, value| send("#{key}=",value) end end def age=(age) @age = age.to_i end def is_person=(is_person) @is_person = Column.value_to_boolean(is_person) end end 代入する時に値を修正するのが インスタンス変数に直接アクセスした場合にも型が保証できて良いです。 「別に文字列でもいいよ。」なんてこともあると思いますが、 数値だとおもってうっかり使うと '20' * 3 -> '202020' となって欲しい 40とは大きく違います。 チェックボックスを利用すると "1" などなど、値として降ってきます。 特に 真偽値への変換ですが、とりあえずわからなかったので、自前でごまかしていたのですが、調べました。 ActiveRecord::ConnectionAdapters::Column にさままな型変換のメソッドが実装されています。 https://github.com/rails/rails/blob/v3.2.13/activerecord/lib/active_record/connection_adapters/column.rb その中の value_to_boolean を使用しました。 def value_to_boolean(value) if value.is_a?(String) && value.blank?

no_picture

iOS で Digest認証してみる。 - AFNetworking

iOS で Digest認証するコードを書きました。 サンプルコードの作成は頼まれて作成しただけです。 折角なので、簡単な説明を 記事にしておきます。 サンプルコードはこちら テストサーバ構築 まずは動作確認をできるようにしないといけないので Digest認証 をするためのウェブサーバがないと困ります。Ruby の rack を使いました。 Digest認証をするには Rack のミドルウェア Rack::Auth::Digest::MD5 を使用しました。 Digest認証は ハッシュ化アルゴリズムの選択できるようになっているので、ミドルウェアはこのような名前になっているようです。 Rackのソースコードみにいったら、最初気づかなくて困りました。 config.ru は以下のように書きました。 use Rack::Auth::Digest::MD5, "auth", '' do |username| "password" end run proc { [200, {'Content-Type' => 'text/html'}, ['hoge']] } use の第三引数は opaque となります。デフォルトでは nil で、設定しないと動きません。はまりました。 蛇足ですが、 use の仕組みをよくしらなかったのでソースコードをちら見しました。 lib/builder.rb に実装があります。 def use(middleware, *args, &block) if @map mapping, @map = @map, nil @use << proc { |app| generate_map app, mapping } end @use << proc { |app| middleware.new(app, *args, &block) } end @map が nil の場合は middleware.new する処理が割り込むだけですね。引数はまるまる渡しています。 use する時の引数は 使用するミドルウェア の initialize メソッドをみればよいことがわかります。 Digest認証の場合は (ソースコード) def initialize(app, realm=nil, opaque=nil, &authenticator) @passwords_hashed = nil if opaque.nil?

no_picture

エディタの文字色に悩む日々 - CIELCH

色について少し話しをしたいと思う。 プログラマたるものエディタの配色はこだわりたいものです。 目が疲れにくく、かつ、文字が読みやすい配色が欲しいのです。 特に私は視力がそんなによくないので、この点を気にしています。 既存のテーマのもので文字が読めなかったりして、色を変えたりしても上手いこと調和が取れない。 上手いこといかないので過去に何度か模索して、いまも模索しています。 そんなわけで今回は CIELAB について調べていたのですが、その変種な CIELCH について紹介したいと思います。 先にまとめておくと CIELCH を利用して配色を行います。 背景色と文字色で L(明度) がある程度の差をもつようにすると文字の読みやすさを確保することができます。 明度の差が大きいとチカチカするので差をつけすぎないのも大事です。 あとは C(彩度) や H(色相) のパラメータを調整しています。 CIELAB CIELAB は L a b というパラメータで色を指定します。CIEというのは 国際照明委員会だそうで、Lab とかいても通じそうです。 L は明度を示し 0だと黒で 100だと黒です。 a は正の値が大きいと マゼンダ(赤紫)っぽい色になり、負の値が大きいと緑っぽい色になります。 b は正の値が大きいと 黄色っぽい色になり、負の値が大きいと青っぽい色になります。 a と b がなんでそんな色なのかっていうと、色相を考えたとき、それぞれの正負が補色関係にあり、かつ a と b 直交するからでしょう。 この色空間の良いところは L です。 Lの明度は HSV の明度と違う明度で、人間の視覚に比較的近いのです。 HSV は 色相、彩度、明度を色で決める方法で、よくみかけると思います。この明度には人間の視覚においては非常にあてになりません。 例を出します。 黒が明るさ 0 なんだから 明るさ 100% の色を使えばうまくいくような勘違いを一度はしたことはないでしょうか。 rgb (0, 0, 255) の青を考えます。HSVでいうと 色相 240° 明度 100% 彩度 100% になります。 明度 100% です。 明度 100% です。 大事なことなので3回言いました。3回目は読みにくいですね。 HSV の明度は人間の視覚に対応していません。 同じ明度の黄色でやってみましょう。 明度 100% です。 青のときに比べて文字がはっきりしますね。 というわけで、ほかの色空間が欲しくなります。 他に使えるものとしてはマンセルカラーとかありますが、RGB値が厳密には定義されてないようです。 色見本から測定して変換しているものはあるようです。 実世界の色とモニターの色を比較する場合、モニター自体の明るさを変更できてしまうし、一致させることができない。と、認識しました。 Haskell で CIELAB から RGB に変換する場合 ホワイトバランス というパラメータが必要でしたし。 いろんな文献をあたると RGB をマンセルカラーに変換する場合は XYZ という色空間を経由して、CIELAB にもっていくことがわかりました。 そこで CIELAB を利用するのですが、HSV のように 色相 明度 彩度で指定できると都合がよいので aとb を極座標にして 色相、彩度にしたのが CIELCH になります。 ようやく本題ですが、CIELCH の色立体が見たかったのです。 Y 方向に明度 X 方向に彩度 で 色相を18°づつずらしてみました。 また、RGB値に変換するときに どんな値でも変換できるのですが、負の値になるものやら,255を越えてしまうものやらでてしまいます。 若干丸めて、そのような色の場合は表示しないようにしました。 マンセルカラーと比べてみても似たような雰囲気はでてますね。 明い色になると青色がでてないのがわかります。 今度は彩度200 まで。 異常と判断した値も表示してみます。 彩度をあげると徐々に明るくなっちゃってますね。 もっと起きてることをわかりやすくするには彩度をもっと引っ張ります。 彩度500 とかいってみましょう。 ほんとは三次元に出したかった。 使用したコード 作成したコードも貼っておきます。Haskell のサンプルコードとしてお使いください。 import Data.Colour.CIE import Data.Colour.SRGB import Data.Colour.CIE.Illuminant import Data.Colour.SRGB.Linear cieLCH :: (Ord a, Floating a) => Chromaticity a -> a -> a -> a -> Colour a cieLCH white_ch l c h = cieLAB white_ch l a b where radius = pi * h / 180 a = cos radius * c b = sin radius * c validRGB :: (Fractional a, Ord a) => RGB a -> Bool validRGB (RGB r g b) = if sum >= 0 && sum <= 3.1 && r > low && r < high && g > low && g < high && b > low && b < high then True else True where sum = r + g + b low = -0.1 high = 1.2 toRGBColor :: (Fractional a, Ord a) => Colour a -> Maybe (Colour a) toRGBColor colour = if validRGB rgb then Just colour else Nothing where rgb = Data.Colour.SRGB.Linear.toRGB colour type ColorName = (Maybe (Colour Double), Double, Double) type ColorTable = [[ColorName]] colorTabletoHTML :: ColorTable -> String colorTabletoHTML table = "<table style=\"display: inline;\">" ++ (unlines $ map makeRow table) ++ "</table>" where makeRow :: [ColorName] -> String makeRow cols = "<tr>" ++ (unlines $ map makeCol cols) ++ "</tr>" makeCol :: ColorName -> String makeCol (color, l, c) = "<td style=\"background-color: " ++ rgbString color ++ "; \">&nbsp;</td>" rgbString Nothing = "" rgbString (Just color) = sRGB24show color colorTable lightnesses chromas h = [[(makeColor l c h, l,c) | c <- chromas] | l <- lightnesses] where makeColor l c h = Main.toRGBColor $ cieLCH d65 l c h hues = [0,18..342] chromas = [200,160..0] lightnesses = [100,80..0] main = do putStrLn "<body style=\"background-color: #2c2c2c\">" mapM_ putStrLn $ map (colorTabletoHTML .

no_picture

Wikiやメモをかくときに考えてること

私がメモをとるときに意識してることを書いておきたいと思います。 といっても、大したことではないです。 Wiki を書くときのポリシーについて、書こうと思ったのですが、こういう形に落ちつきました。 最初に一言でまとめておきます。 ログを書いているのか まとめを書いているのか を意識する 物事を整理するには、 情報収集 まとめる という2段階のプロセスを踏みます。 情報収集のアウトプットがログで、まとめることのアウトプットがまとめです。 なんのためにメモをとるんだっけ? 忘れても大丈夫なようにするためです。 決めたことの証拠にもなります。 ログ とは 時系列順に並んだメモです。 時系列に並んでいなくてもいいですが、時系列に並んでるほうが扱いやすいです。 ログは基本的に一度書いたものは、変更しません。忘れても大丈夫でないと困るからです。変更されてしまうと、変更前の情報がわかりません。 人の話を聞いたり、読書メモをとったりするのに、マインドマップのようなものを使っていたこともあるのですが、正直間に合いません。スペースが足りません。 なので、時系列順というのは書きやすいです。 また、時系列順であれば見直す場合も読みやすいです。 紙にメモをしている場合であれば、矢印をつけたり、色をつけたりをしても良いかもしれませんが、迷うようであればあとまわしにしています。 一時期、メモをとるのに工夫をしすぎていて、 メモの最中にあとでわかりやすいよに文章の位置を入れかえたり、などなど していてとメモが取れる量が減ってしまったりしました。 そうすると、必然的に重要なことだけメモろうとなります。 でも、なにが重要なのかその場で判断できないことのほうが多く、真っ白なままのノートができたりします。 もともと何かのまとめであったものが、ログになる場合もあります。 まとめ とは まとめは必要な情報が必要な時にすぐに取り出せるようにしている情報です。使いやすくなるように工夫したりしましょう。 忘れた事を思い出すためのショートカットです。大事なことだけ伝えるためのショートカットにもなります。 一度書いたあとも何度も何度も修正していくこともあります。 ログさえあればまとめを再構築できるはずなのでどんどん修正できます。 書式は様々です。Wikiであったり、blogであったり、マインドマップだったり適材適所です。 修正されなくなったまとめはログとして再利用される場合があると思います。 ログとまとめ 頻繁に閲覧することになるのは まとめ です。 利便性のためにまとめはあるため、時折、修正を行い利便性を維持する必要があります。 結果、修正をしていくうちに、その結論にいたった理由や情報が失われる恐れがあります。これを補完するためにログが必要になります。 ログは情報が失われていませんので、ログがあればすべてがわかります。 時系列に並んでいればどうしてそういう結論になったのか追いやすいです。 しかし、ログ は情報量が まとめ に比べて多いです。ノイズも多いです。 ログをすべて追うには時間がかかります。 必要な情報が分散していれば、いったりきたりしたりすることにもなります。 このためにまとめが必要になります。 まとめは過程が欠落してしまい、ログは長すぎるのです。 ということで、覚えておかなければならないことがあるのであれば。 ログがあるならまとめをかいて、より便利に。 ログがないのであればログを作る。でないとまとめが書けない、なおせない。 ということになります。 Wikiをかくときのこと Wiki はどちらかというと まとめを書くのに適したツールです。 リンクを貼ることもできるので、ログへのリンクを用意しておくと良いです。 必要な情報が取り出しやすいようにメンテナンスもしましょう。 また、ログがない情報もあるかもしれません。 ログなのか、そうでないかでページをわけていきましょう。 同じ情報でも、別々に記述する場合があります。 まとめのほうは更新するのでなくなる可能性がありますし、 ログのほうはそのまま残ります。

no_picture

Gentoo Prefix で python3.2 がないって言われてインストールできない

いつのまにやら Gentoo Prefix が python 3.2 を入れようとするのだけど、 python 3.2 の ebuild はありません。 emerge -uDNt world とかで更新しようとしたとき python 関連のものがあると実行できない。以下のようなメッセージがでます。 emerge: there are no ebuilds to satisfy "dev-lang/python:3.2". python 3.3 はいってるし、別にいらないよね。 ということで USE フラグに -python_targets_python3_2 を追加したらうまくいった。 TARGET_PYTHONを調整したくなるのですが、これは 上記の USE フラグに展開される。

no_picture

広島Ruby勉強会 #30で Liquidの簡単な説明をした

広島Ruby勉強会 #030で Jekyl の中で使用されている テンプレートエンジン Liquid のざっくりとした説明をする LT しました。 大したネタもないし、そんなに凝ったこともしてないですが、公開しておきます。

no_picture

Rails4 beta1 がリリースされたのでアップグレードしてみた

Rails4 beta1がリリースされてます。 というわけで、アップグレードしてもよさそうなプロジェクトをアップグレードしてみました。(リリースしてないし) config以下の書き換えなどは自己責任で。 やったこと bundler 1.3 が必要になるので、まだいれていない場合アップデートします。 $ gem install bundler Gemfileを修正します。 gem 'rails', '4.0.0.beta1' group :assets do gem 'sass-rails', '~> 4.0.0.beta1' gem 'coffee-rails', '~> 4.0.0.beta1' # See https://github.com/sstephenson/execjs#readme for more supported runtimes # gem 'therubyracer', :platforms => :ruby gem 'uglifier', '>= 1.0.3' end 必要に応じてgemの設定 protected_attributes strong_parameters に移行してない場合 gem 'protected_attributes' devise devise がまだ対応 gem がないので gem 'devise', github: 'plataformatec/devise', branch: 'rails4' githubから直接。 simple_form gem 'simple_form', '3.0.0.beta1' simple_form が rails4

no_picture

ruby-build の プルリクエスト バトル

ネタです。 最近もろもろな事情で Ruby がリリースされることが多かったですが、ruby-build の更新を待っていた人はどれくらいいるでしょうか。 みんな待ちきれなくて自分で ruby-build のレシピを書いたんではないでしょうか? そして「俺がと プル リクエストをおくるんだ!!」と燃えたのではないでしょうか? これを Ruby のリリースがあるたびに発生する ruby-bulild プルリクエストバトルだと勝手に想像して楽しんでいます。こんばんは。 僕の場合はだいたいなぜか rbenv のほうをみにいって、「まだ更新がないないなー」っておもってレシピをかくんですが、書いたあとに ruby-build だったと気づく馬鹿なことをしているだけだったりしますが 今日も Ruby 2.0 のリリース がありましたが、このプルリクエスト バトル の行方はどうなったのでしょうか。 https://github.com/sstephenson/ruby-build/pull/299 https://github.com/sstephenson/ruby-build/pull/301 同じ Issue を立てないように気をつけたいですね。 それと Ruby 20周年おめでとうございます。 ついでにレシピの書き方 ネタだけで終わるのもあれなので。 ~/.rbenv にインストールしている場合は ~/.rbenv/plugins/ruby-build/share/ruby-build/ にレシピが配置されています。 今回の 2.0 の場合は install_package "openssl-1.0.1e" "https://www.openssl.org/source/openssl-1.0.1e.tar.gz#66bf6f10f060d561929de96f9dfe5b8c" mac_openssl --if has_broken_mac_openssl install_package "ruby-2.0.0-p0" "ftp://ftp.ruby-lang.org/pub/ruby/2.0/ruby-2.0.0-p0.tar.gz#50d307c4dc9297ae59952527be4e755d" とか前のバージョンを参考にして書けばよいです。簡単ですね。 なんでこんなことかいたのか なんで push してないんだー。って怒られたので Ruby 2.0 リリース & 20 周年 おめでとー。とかそういう記事書きたいじゃないですか

no_picture

岡山Git勉強会 - 20130223 - Git 仕組み入門 という話をしてきた

岡山Git勉強会 20130223 で Git 仕組み 入門という話をしてきました。 トゥギャッター セキココ もっと簡単な内容にできるかな?っと思ってやってみたのですが、やっぱり難しめだったみたいです。 スライドだけでもある程度理解できるように細かめにつくってみました。 やりすぎた感が漂います。 Git 仕組み 入門 from Tomohiko Himura スライドをつくる際のメモなどもupしています。 この辺りの話を聞いたことがない方は手を動かしてみてはどうでしょうか。 話し忘れたこと 日頃使うツールはしっかり理解したほうがいいと思う tree オブジェクトに登場した mode は 666 とかよくパーミッションがどうこう言われるアレです。 このあたりの仕組みが入門書に出てくるあたりも Git の魅力なだと思います。 内容にあまり関係ないこと keynote の機能をいろいろためした もっとはやく勉強しておけばよかった。マスタースライドでスライドのテンプレートをつくっていじると、スライドのデザインをまとめていじれる。 背景色をうっすら変えてみた。 お洒落感が出るのか試してみたかった。結果はよくわからない。 ディスプレイでみるとわかる違いはプロジェクターでわかるかどうか怪しい。 keynote で アウトラインからスライドを作ると効率よさげ 前述のマスタースライドの機能がわかっていれば、わりといけます。 まとめ 話をするのは苦手で、相変わらず、反省点の多いセッションですが、話を聞いていただいてありがとうございました。良い経験になりました。

no_picture

Github で Jekyll を使う時に調べたこと

Github で Jekyll を使うときにできることとか調べたので整理しておきます。 今日の成果物。 この記事をいきなりポーンと書いても仕方ない気がして前の記事を書きました。 Github Pages について整理しておきます Jekyll を利用するかしないかの判断材料などに利用してください。 利用できる マークアップ HTML Markdown Textile 関連する gem liquid- テンプレートエンジン redcarpet - 高機能高速動作な Markdown maruku - 高機能な Markdown rdiscount - 高速動作な Markdown RedCloth - Textile Pygemnts.rb - シンタックスハイライト できること Layoutの利用 - ネスト可能 includeの利用 - Jekyll Boostrap がかなり利用してる様子 記事の作成 atom.xmlや記事一覧の作成 - site.posts 変数から参照可能 シンタックスハイライト できなかったこと Rubyのコードを書いて改造 pluginの利用 対応するファイルのないものを自動生成 拡張タグ 利用できるタグの追加 gem を読み込んで情報源などにする Scss, Sass, Less などメタCSSの利用 CoffeeScript などの利用 Jekyll Bootstrap がしてること

no_picture

Github Pages について整理しておきます

Git の練習を兼ねて Github できることといえばひとつとして Github Pages があります。 ウェブサイトを Git で管理して、Github へ プッシュすれば公開できるというものです。 使い方などは 公式のヘルプに書かれていますが自分が Github Pages を使おうとした時に知りたかったことを整理しておきます。 細かいことについてはあまり書きません。 Github Pages の特徴 Github Pages の種類 ユーザぺージ または グループページ プロジェクトページ Github Pages の構築方法 Jekyll 静的ファイル 独自ドメインの利用 Github Pages の特徴 公開リポジトリで作れば無料。容量制限もないと言ってよいです。 CGI,PHPなどで動的ページは生成できません。 代わりに Jekyll というアプリケーションを使い github にページを生成させることができる Github Pages の種類 Github Pages には 2種類あります。 ユーザページ または グループページ プロジェクトページ ユーザページ グループページ ユーザページ と グループページは同じ機能と言えるので同じものと考えてください。 ユーザページはアカウントにひとつだけ作れる Github Pages になります。 グルーページは Github には Organization という グループを作る機能があります。

no_picture

tmux で copy-mode でのキーバインドについて

tmuxのコピーモードでのキーバインドはデフォルトで emacs like になっています。 なぜか、一部のマシンでのみ vi like になってたので、man tmux をみてみた。 > the default is emacs, unless VISUAL or EDITOR contains ‘vi’. デフォルトは emacs だけど環境変数 VISUAL か EDITOR に ‘vi’ を含んでいれば vi like になるそうです。 環境変数に影響されずに固定したい場合は set-window-option -g mode-keys emacs とか set-window-option -g mode-keys vi とか、書いておきましょう。

no_picture

よりよい開発者になるために CodeKata

github の News Feed みてたら codekata というのがあって、なんだっけと思いつつ調べたら 情熱プログラマという本 ( http://amzn.to/d6zjDE ) を読んでいる。 そこにこんなことが書いてあった。 プログラマはしばしば実務の中でスキルを訓練する。 これがミュージシャンだったらどうだろう? 彼らがステージ上で変な音を出しながら練習していたら、観客はどう思う? 練習は、観客のいない密室で、自分の時間を使ってするべきだ。プログラマもそれと同じだ。 なるほど、それはその通りだ。で、この本にプログラミングの訓練の手がかりが紹介されている。 それが「Code Kata ( http://codekata.pragprog.com/ )」 だ。 “Kata”とは、空手の型のこと。 空手の練習は、定められた型を繰り返し反復することで技術を習得していく。 それと同様のコンセプトで、型を訓練し、ソフトウェア開発のスキルを磨きましょう、というものだそうな。 – 言葉をポッケに持ち歩こう なるほど。日々の基礎練習が大切なんですね。 ということで forkして codekata for haskell はじめました。

no_picture

読書メモ 関数プログラミング入門 Haskellで学ぶ原理と技法 1.7 仕様

関数プログラミング入門 Haskell で学ぶ原理と技法 の読書メモです。引用もしていますし、感想なども混ぜています。 本節は仕様についてです。 仕様と実装の関係について、語られます。 仕様はやりたいこと、実装は実現方法。 そんな感じのことがかかれています。 関数の仕様を表明し、そのやりかたとして引数と戻り値の組を用意する。 単純な実装を行い、よりよい実装にしていく方法が良いとされてます。 すごくBDD感漂うRspec的な手法が勧められていますね。 この手法の難しい点は、 仕様が利用者の要求とずれてしまうかも。 仕様を満たすための検証が膨大になりすぎて証明が大変 ということです。非常に身に覚えがあります。 練習問題 あまりおもしろくない解答をかきました。うーん。面白いの考えたい。 ついでに1章のまとめ。 一度、読書メモを本気でやってみようと思っていたのではじめてみましたが、思うよりもずっとずっと大変でしたが、関数プログラミングに対する基礎知識がグッと固いものになったと感じてます。 通し読みせずにやっているので、読み終わるのはいつになるのでしょうか。 これからもがんばってできる限り続けていきたいです。 関連 メモ用のリポジトリ 1章 1.6の練習問題

no_picture

Cucumber のフィーチャの文法 - Gherkin

Cucumber 利用していますか? 基本的な使い方はわかるんだけど、なんだかもっと上手く使えるんじゃないだろうか?と、もやもやしながら使っています。 少くとも私の周りには Cucumber について情報交換できる人がいないです。 それでも、SlideShare や Speaker Deck なんかに公開されたスライドでよくみかけるので、使い込んでるところでは使い込まれているのだと思います。 Cucumber は Rails プロジェクト以外でも利用されているようで、範囲が広いです。もうちょっといろんな情報がWeb上に流れていても良い気がします。 私が知る限りでは Cucumber についてもっと詳しく書かれているのは The Rspec Book です。 前置きはさておき、 Cucumber の *.feature は Gherkin という 言語で書きます。 その文法について調べたのでそのメモを整理しておきます。 ちなみにこの内容はソース読んだり、Wikiに書かれているものを参考したもので、仕様として記述されてない情報もあるので未来のバージョンでは予告なく変更される部分があるかもしれません。 こんな長くて不正確な記事読みたくないよ!という人は BNF を読むのが手っ取りです。 というか、BNFが読める人は読みましょう。 むしろ、もっとはやく読めばよかった。 具体例 Gherukinのという言語で書いた文書の例を上げておきます。 内容はシステムに関するものにしませんでした。 # language: ja @blog フィーチャ: ブログを書く ブログを書くには本人のやる気と書く時間が必要です。 アウトプットは次のインプットに繋がるので積極的に行なうべきです。 # これはコメントでタグの後にはかけない # @ではじまるのはタグ @good シナリオ: ブログが書ける ブログが書ける場合はやる気と時間があるのです。 # ネタがないとかけないです。 前提 ネタがある # 時間がないとかけないです かつ 納期に終われていない # 先輩とかいないですけど もし 先輩にブログを書けと言われた # オチがない ならば ブログが書けている @bad シナリオ: デスマ中はブログが書けない デスマ中ダトソレドコロジャナインダ!!

no_picture

読書メモ 関数プログラミング入門 Haskellで学ぶ原理と技法 1.6 仕様

関数プログラミング入門 Haskell で学ぶ原理と技法 の読書メモです。引用もしていますし、感想なども混ぜています。 本節は型についてです。強い型付けがよくわからなくて悩みました。 内容は 型の基本と強い型付け 多相型 型クラス といった感じです 型の基本と強い型付け 値は型という集まりに分類することができて、様々な型があります。 Int, Float, Integer,リスト…などなど。 既存の型を組合せて新しい型も作れます。 (Int, Int), Int -> Int 型固有に演算があり、違う型に利用することは無意味です。意味がないので不当な式となります。 式であれば、必ず型があり、その型は式を構成する要素から推論できます。構成要素から型が決定できるので強い型付けになるようです。(ここがはっきりしなくて悩んだ) 弱い型つけの場合は暗黙のキャストなどにより実行してみないとわからない部分があるようです。 強い型付けの利点は つづりミスや混乱した定義をコンパイル時点で発見できる プログラムを書く際のルールになる だそうです。 引数や結果の型を考えることで型レベルの整合性を保ち、その中で値をやりくりするので、型の枠から外れることも防ぐことができて、明瞭なプログラム設計ができるようです。 多相型 式の型は 構成要素から決定できますが、関数合成や和や積などは複数の型に対して利用できているように見えます。これは型変数を利用することでこのような定義ができます。 「それって強い型付けなの?」という疑問に教われるのですが、型変数を含んでいても型なので問題がないようです。 曖昧であれば不正な式になるのだと思います。その場合は推論に任せず型指定をすることになります。 このように型変数を含む型を多相型と呼びます。 おまけで (->) は 型演算子 だそうで、右結合だそうです。Int -> Int は -> で演算して新しい型を作るとも言えます。 型式というものがありそうですが説明されてません。 型クラス 和や積をするつあめの (+), (*) がありますがこれを型変数で定義するには一般的すぎます。数値であるようなものであれば扱えて欲しい。 そのような似た型をまとめる型クラスという機能があります。型変数に制約をつけることができます。数値であるような型は Num クラスのインスタンスとなります。 Num a => a -> a -> a とかいたとき a がNumクラスのインスタンスであるという制約のもとで、 a -> a -> a

no_picture

「状態管理用の変数をインスタンスに持たせるなこのタコって話」という記事のStateパターンを適用したときのリファクタリングのステップが気になって。

内容の批判とかではなくて、自分が気になったことで、記事にするのもどうかなって思ってたのですが、サンプルコードを書いちゃったので、折角なので書きおきします。 状態管理用の変数をインスタンスに持たせるなこのタコって話 - life.should be_happy # => 1 examples, ? failures という記事がホットエントリに出ていて、すごく面白いです。 その中で 「Stateパターンを使おう」というところでリファクタリングのステップが大きいなーって感じて、30分ぐらい考えてしまったんです。 Stateパターンってのをよく知っていれば、書き換えることは難しくないのですが、丁寧にコミットすることを考えたとき、どういうリファクタリングのステップにすればいいのかな、と。 リファクタリングは極力小さなステップで行うほうが良いです。いきなりがっつりやるためにはテストコードがほぼ必須になります。 あったとしても小さいほうがうごかなくなって悩む時間が減ります。 ということで、「リファクタリング飛躍」 に該当する部分は、player_02.rb から player_03.rb への変化する部分になります。 リファクタリングのステップが大きすぎることを「リファクタリング飛躍」と個人的に呼びたいです。 例 1 クラスごとに分かれる処理を case でまとめておく https://gist.github.com/eiel/4748209 ポイントだけ、抜粋します。 元のコードは: def move(direction) case @moving_mode when MOVING_MODE::NORMAL x_speed = 10 # かにモードとの整合性のために y_speed = 10 # 無駄な変更が加えられている when MOVING_MODE::FAST x_speed = 20 # FASTモードにも! y_speed = 20 when MOVING_MODE::KANI x_speed = 40 y_speed = 5 end case direction when :up

no_picture

今さらながら turbolinksを試した。- 感想

今さらながら Rails4 の新機能の一つである turbolinks を試してみました。 解説なんかは僕がするよりも様々な記事がもうあるので、あまり必要ないと思います。 Rails 4.0 に入る予定の turbolinks について調べた Rails4 Turbolinksのメモ #mtsmhack Rails4でデフォルトで入るturbolinksがオープンリダイレクタと合わさると何でもできてかなり危険 どれも良い記事でした。 ということで、個人的感想とか production環境より development環境での効果が高い気がした 体感ほんとに早い - development環境 だいたいそのままで動く。動かなくなる Javascriptはやっぱりある。 fancyboxとか、でも、そういうのはそもそもRailsで扱いずらいものばかり。 CSSやJavaScriptが切り変わるリンクには HTMLタグに data-no-turbolink属性をいれればよい。いれないと悲しいことになります。 インストール 一緒に jquery.turbolinks も入れておきました。 これは簡単に言うと、”なにもしなかったら動かなくなってしまうもの”を減らすように工夫したものだと思います。 なんとなくで具体的に書くと、readyイベントでやってることをページロードするときにも実行するようにするんじゃないかと思います。(たぶん) jquery.turbolinks は turbolinks に依存してないのでそれぞれGemfileに入れる必要がありました。 gem 'turbolinks` gem 'jquery-turbolinks' //= require turbolinks //= require jquery.turbolinks といった感じです。 感想をもうちょっと 体感ほんとに早い Rails3 でも試せるので、体感しておくのは良いと思います。設定はとても簡単なので、どういうものかは知っておいたほうが今後の方針に役立ちます。 個人的には、規模が大きいプロジェクトでは develpoment 環境でだけでも使いたいです。 動かなくなったプラグイン 試したプロジェクトは fancybox という jQueryプラグインが使用されてる箇所がありましたが、ここが動かなくなりました。 そもそも、Railsではこれはすごく扱いにくくて置き換えてやろうしてる部分で放置してるうちに次々と使われてしまってる問題児です。 修正するにはちょうどよい機会。 まとめ Rails的じゃないところほど問題がでやすい機能という点ですごく面白いなー。と、思いました。

no_picture

Active Supportの日付演算ってなかなか不思議。

昨日の記事がかなり反響がありまして、みなさまありがとうございます。 関連のある記事を書きたくなりますが、とりあえず、変わらず淡々とメモも残していきたいと思います。ゆるりとGithub入門記事も書きたいです。 ActiveSupportが拡張する日付操作はとても便利です。よく使います。でも、ちょっと黒魔術だなぁって思ったことがあったので紹介します。 Rubyでは日付や時刻クラスのインスタンスと数値が演算できます。 今から1ヶ月後の日付が知りたいのであれば、以下のように書けます。 1.month.since # => 2013-03-07 12:51:18 +0900 1.months.since # => 2013-03-07 12:51:18 +0900 複数形でも単数形でも。 特定の日付からでも同様のことがしたい場合は以下のようになります。 DateTime.new(2013).months_since 1 # => Fri, 01 Feb 2013 00:00:00 +0000 DateTime.new(2013) + 1.month # => Fri, 01 Feb 2013 00:00:00 +0000 有名な機能なので、ご存知の方も多いと思います。 別に、一日単位なら month メソッドとか使わなくてもできます。 DateTime.new(2013) + 1 # => Wed, 02 Jan 2013 00:00:00 +0000 DateTime.new(2013) + 1.day # => Wed, 02 Jan 2013 00:00:00 +0000 さて、本題。 monthだけでなくhourやday,secondなどもありますが、戻り値の型はすべてFixnumになっています。 1 などの数値もFixnumです。 Rubyで日付や時刻を表わすクラスは DateTime, Date, Time などありますが、演算をした場合は、レシーバによって変化します。 でも、monthやsecond メソッドを利用してから演算すると引数によって動作が変化します。どれも足すのはFixnumなのに。 というわけで、サンプルコード。 require 'active_support/all' datetime = DateTime.new 2013, 2, 7 date = Date.new 2013, 2, 7 time = Time.new 2013, 2, 7 datetime # => Thu, 07 Feb 2013 00:00:00 +0000 date # => Thu, 07 Feb 2013 time # => 2013-02-07 00:00:00 +0900 # レシーバによって動作が変わる (1) # 1日先に datetime + 1 # => Fri, 08 Feb 2013 00:00:00 +0000 # 1日先に date + 1 # => Fri, 08 Feb 2013 # 1秒先に time + 1 # => 2013-02-07 00:00:01 +0900 # これを防ぐには和をとるものを明示する (2) datetime + 1.days # => Fri, 08 Feb 2013 00:00:00 +0000 date + 1.days # => Fri, 08 Feb 2013 time + 1.days # => 2013-02-08 00:00:00 +0900 # 秒の場合 (3) datetime + 1.second # => Thu, 07 Feb 2013 00:00:01 +0000 date + 1.second # => 2013-02-07 00:00:01 +0900 time + 1.second # => 2013-02-07 00:00:01 +0900 # Class は どれも Fixnum なのです 1 # => 1 1.class # => Fixnum 1.days # => 1 day 1.days.class # => Fixnum 1.second # => 1 second 1.second.class # => Fixnum # (1) の場合のみレシーバによって動作が変化。動作的には自然だと思う。 # (2), (3) の場合は 引数に応じた動作に。 Dateは演算の結果、型が変化する。 # 使う分には使いやすい。 いいたいことはソースコードにもかいた!

no_picture

Git がわからなくても Github を利用しよう

みなさん Github を利用していますか? 「Git がわからないから…」と、そんな理由で使わないのはもったいないです。 Webや開発に携わる人間であれば、例えプログラムを書かなくても、Github へアクセスする機会は増えているのではないでしょうか。 Webの人であれば jQueryのプラグインを探したり、サンプルコードが Github においてあったりすると思います。 しかし、いきなり使いこなすのは難しいので、まずは以下のことをはじめてみることをおすすめします。 アカウントを作る 知り合いや気になる人をフォローする 自分が利用しているリポジトリや気になるリポジトリにスターを付ける News Feed を読む 日本人がやってるネタリポジトリの Issues やPull Requestsに絡む Gitを利用しなければいけない機能はとりたててありません。(Pull Requestには突っ込まないで) アカウントを作る まず、アカウントがないと何もできません。作りましょう。 Githubのトップページに “Sign up for free” というボタンから作成することができます。 知り合いや気になる人をフォローする 友達や気になる人をフォローしましょう。相手がフォロー返しをしてこなくても気にすることはないです。News Feed を読む ための布石にすぎません。 フォローすると News Feed にフォローした人の活動が表示されるようになります。これを見るのが目的なので、自分が興味のある活動をしている人がおすすめです。 あまり活動的な人をフォローするとフィードがどんどん流れてしまうので、初心者にはおすすめできません。 フォローする相手がいない場合は、あまり活発でない リポジトリをウォッチするという手もあります。 フォローするには https//github.com/ユーザ名 にアクセスして、画面右上のほうに Followというボタンがあるのでそれをクリックします。 例えば、私をフォローしたい場合は、http://github.com/eiel にアクセスします。 自分が利用しているリポジトリや気になるリポジトリにスターを付ける スターというのは、お気に入り、ブックマーク、いいね!のような機能です。ソーシャルブックマークの効果を感じていれば、説明は不要だと思います。 スターをつけると、自分の活動に このリポジトリにスターをつけました と流れるので、あなたをフォローしている人が目にすることになります。 そうすると、そのリポジトリを見にいく人が増えますので、そのリポジトリがより活発になる可能性が高くなります。 応援したい!! と思えば、すかさず押してしまっても良いでしょう。 News Feed を読む ここが本記事の主旨です。 News Feed を読みましょう。 News Feed はログインした状態で、Githubのトップにアクセスすると閲覧できます。 友人もフォローしたし、スターをつけることを学びました。 友人がスターを付けたことがわかるはずです。

no_picture

Rubyの拡張ライブラリをデバッグしてみた。

結論から言うと解決していないんだけど、学んだことをメモしておきます。 あらまし ruby-2.0.0-rc1 で debugger を動かしたかった。 ruby-2.0.0-rc1 だとコンパイルすらできない! 結果: コンパイルはできるようになったしとりあえず、うごくけどすぐ落ちる。テスト通らない。 https://github.com/eiel/debugger/tree/ruby-2.0/doc 拡張モジュールをコンパイルする方法 手順としては rake compile するだけでした。 手動でやりたい場合は * Makefileを生成する * make する Makefileするには ruby extconf.rb とします。カレントディレクトリに Makefile ができるので make します。 拡張モジュールはextディレクトリにソースコードがあり、rake compile すると libに共有ライブラリ(.so, .bundle, .dll)ができます。 gem にして installする方法 gem build *.gemspec して gemを作ってもいいけど、だいたい rake gem で作成できます。 pkg/ にファイルが生成されるので、gem intall pkg/*.gem でインストールします。 やったこととか make してエラーが出る部分を rubyのソースコードで git log -S して変更内容を確認してひたすら直す。 APIとか拡張されてると思いますが、その辺はわからないので無理。 gdb を使ってデバッグする方法 ruby hoge.rbなどでセグメンテーション違反などで落ちる場合は以下の方法でデバッグできます。 $ gdb rubyのバイナリを指定[~/.rbenv/versions/ruby-2.0.0-rc1/bin/ruby gdb> run hoge.rb 書いてて気づいたんだけど、lldb でデバッグするべきだった?

no_picture

@soudai1025 がFizzBuzzのエントリで再帰についてかいてた。なんか違和感を感じた。

@soudai1025 が書いたブログ記事にPythonでFizzBuzzとかしてみたというエントリーがあって、まーいろいろ、あって突っ込みをいれました。 この中で再帰に関する記述があります。 で最後はみんな大好き再帰。 折角なのでループ文を使わずに与えられたintまでの1からの和を出してみました。 def sum(num, answer = 0): answer = answer + num num -= 1 if num == 0: return answer return sum(num, answer) 「この再帰なんかおかしくね?」って直感的に思った。 おかしいというのはなんか複雑すぎないだろうか?ということである。answerって引数なくても実装できるよね。引き継ぎたい値がひとつしかないから戻り値で対応できる。 def sum(num): if num == 1: return 1 return num + sum(num-1) うん。これだ。これが正しい。 再帰を使う場合は、まず終了条件を考えます。この場合、num から 1へおりていくので、1で終了です。 次にのこったそれ以外のときのことを考えます。num と n-1 の和を足せば求める値がもとめられることに気づくことができればあとはそのままかくだけです。 再帰を使うと今作成している関数が動いている前提で考えることができます。そのあたりに慣れるとさくさくかけます。 再帰というのは スタック付きのループと見なせます。なのでループでできることはなんでも出きます。外のスコープの変数を引き継ぎたいときは、引数を増やせば伝搬できます。ただし、戻り値があるので、ひとつだけであれば伝搬可能です。この戻り値をリストにすることで複数の値を返すこともできます。 ちなみに、普通の関数プログラマの場合、こういうときは reduce を使います。 再帰より読みやすいですからね。 たぶん。

no_picture

Cucumber の Capybara で 複数の同じ名前のリンクに対応するステップ

Cucumber のステップで もし /^"(.+)"をクリック$/ do |name| click_on name end というステップを書いていますが、name に複数マッチしてしまうとエラーが発生しています。同じ名前にならないようにすればいいのですが、そうもいかない場合もあります。結局、以下の方法を用意しました。 もし /^(\d+)番目の"(.*?)"をクリック_$/ do |n, name| n = n.to_i - 1 all(:link_or_button, name)[n].click end 何番目のリンクか指定することで回避しました。 もうちょっと詳しく click_buttonと同じことをやろうとすると find(name) や all(name) ではうまくいきません。調べてみると XPath::HTML.link_or_button というメソッドを使用して、findに渡すXPathを生成してることがわかりました。。 これをどうやって使うというと all の第一引数に使えばいいことがわかりました。 さらに詳しく page.class # => Capybara::Session click_onメソッドやallメソッドのレシーバである page オブジェクトは Capybara::Session でした。pry で調べました。 Capybara::Session NODE_METHODS = [ :all, :first, :attach_file, :text, :check, :choose, :click_link_or_button, :click_button, :click_link, :field_labeled, :fill_in, :find, :find_button, :find_by_id, :find_field, :find_link, :has_content?, :has_text?, :has_css?, :has_no_content?, :has_no_text?, :has_no_css?, :has_no_xpath?, :resolve, :has_xpath?, :select, :uncheck, :has_link?, :has_no_link?, :has_button?, :has_no_button?, :has_field?, :has_no_field?, :has_checked_field?, :has_unchecked_field?, :has_no_table?, :has_table?, :unselect, :has_select?, :has_no_select?, :has_selector?, :has_no_selector?, :click_on, :has_no_checked_field?, :has_no_unchecked_field?, :query, :assert_selector, :assert_no_selector NODE_METHODS.each do |method| define_method method do |*args, &block| @touched = true current_node.send(method, *args, &block) end end https://github.com/jnicklas/capybara/blob/2.0.2/lib/capybara/session.rb#L338-L343 これらの メソッドは動的に生成されるようです。 def current_node scopes.last end def scopes @scopes ||= [document] end https://github.com/jnicklas/capybara/blob/2.0.2/lib/capybara/session.rb#L351-L358 current_node は document という変数に格納されたオブジェクトのようです。 def document @document ||= Capybara::Node::Document.new(self, driver) end https://github.com/jnicklas/capybara/blob/2.0.2/lib/capybara/session.rb#L334-L336 documentは Capybara::Node::Document クラスのインスタンスだとわかりました。 class Document < Base https://github.com/jnicklas/capybara/blob/2.0.2/lib/capybara/node/document.rb#L11 ここには all メソッドがなく Capbyra::Node::Base を継承しているようです。 include Capybara::Node::Finders https://github.com/jnicklas/capybara/blob/2.0.2/lib/capybara/node/base.rb#L27 この辺にありそうですね。 def click_link_or_button(locator) find(:link_or_button, locator).click end alias_method :click_on, :click_link_or_button https://github.com/jnicklas/capybara/blob/2.0.2/lib/capybara/node/actions.rb#L12-L15 cloick_on みつけました。このあたりを grep でみつけた時点で all :link_or_button でいけそうなのはわかります。 def all(*args) query = Capybara::Query.new(*args) elements = synchronize do base.find(query.xpath).map do |node| Capybara::Node::Element.new(session, node, self, query) end end Capybara::Result.new(elements, query) end https://github.com/jnicklas/capybara/blob/2.0.2/lib/capybara/node/finders.rb#L110-L118 all みつけたー!

no_picture

@souda1025 に PythonでFizzBuzzとかしてみた に対抗しろって煽られたので。

@soudai1025 が書いたブログ記事にPythonでFizzBuzzとかしてみたというエントリーがあるのですが、Facebookでこういうコメントをみた。 多分、ひむひむが対抗してくるはず。 全力でお答えしましょう。 とりあえず、普通 FizzBuzz かくならこうかくだろう。 def fizzbuzz(number): if number % 15 == 0: # number % 5 == 0 and number % 3 == 0 return "FizzBuzz" elif number % 5 == 0: return "Buzz" elif number % 3 == 0: return "Fizz" else: return str(number) if __name__ == '__main__': number = int(raw_input("Please enter an integer: ")) print fizzbuzz(number) 数値を入れると 数値の文字列 か “Fizz” か “Buzz” か “FizzBuzz” を返す関数を用意するほうが柔軟性があり、わかりやすいです。 さて、もとのコードを確認していきましょう。 int = int(raw_input("Please enter an integer: ")) def do_fizz(int): if (int % 3) == 0: return 1 return 0 def do_buzz(int): if (int % 5) == 0: return 2 return 0 def do_answer(fizz, buzz): flag = fizz + buzz if flag == 0: print int #引数に居なくても外のintを参照出来る elif flag == 1: print "Fizz" elif flag == 2: print "Buzz" elif flag == 3: print "FizzBuzz" do_answer(do_fizz(int), do_buzz(int)) さて、気になる点をあげていこう。 do_answer 関数が外のスコープにアクセスしている。 よくわからないフラグ処理がされている。 do_answer の引数が意味不明。 関数が外のスコープにアクセスしている 関数が外のスコープにアクセスしてしまうとその関数だけみたときに他の部分を確認しないといけないのでよくない。 それぐらいなら引数を追加しましょう。 よくわからないフラグ処理がされている do_fizz と do_buzz が関数名から何をするのかさっぱりわからない。 do_fizz は 3で割り切れる場合 1 を返し、それ以外の場合は 0 を返す関数である do_buzz は 5で割り切れる場合 2 を返し、それ以外の場合は 0 を返す関数である ということはコードをよまなければわからない。ならば、関数の頭にコメントをかくか、そのような名前の関数にすべきだと思う。 do_ という接頭辞が着いている以上何かする関数だと想像するので、ここで print されているのであれば、まだ良いと思うけど, iPhoneで閲覧していたらこの命名のせいで混乱しました。 do_answer の引数が意味不明 fizz って何?

no_picture

ActiveRecord の has_many で生成されるメソッドってActiveRecord::Relationに変換できる配列なんですね。

タイトルのとおりなんですが、ArticleとComment とかあったりして、ちゃんと設定をしておくと article.comments とやると あるArticleに紐づいているCommentがとってこれる機能です。 まず、結論からいうと article.comments.to_sql とか article.comments.scoped とか article.comments.joinsとかできる!! ということです。 article.comments.create ってかける時点でうすうす思ってたんですが、これがわかっていると小回りがききます。返しているものが ActiveRecord::Relationのようなものです。classを確認すると Arrayって言われちゃいますが。 もうちょい深く 以下のクラスがあることを想定してみます。 class Article < ActiveRecord::Base has_many :comments end class Comment < ActiveRecord::Base belongs_to :artcile belongs_to :user end class User has_many :comment end さきほど紹介した技を紹介すると User.first かつ Article.first な Commentを探す場合、以下のように書けます a = Article.first u = User.first a.comments.merge(u.comments.scoped) すると、こんな SQLができます。 SELECT "comments".* FROM "comments" WHERE "comments"."article_id" = 1 AND "comments"."user_id" = 1 aとかuとかを引数な関数を用意するとウハウハな気がしてこないでしょうか。 joinだってできます。 a =

no_picture

読書メモ 関数プログラミング入門 Haskellで学ぶ原理と技法 1.5 定義

関数プログラミング入門 Haskell で学ぶ原理と技法 の読書メモです。 本節は定義についてですが、前節につづき関数ともいえそうです。 内容は * ガード付等式 * 再帰定義 * 局所定義 です。 ガード式の前に関数だけじゃなく、他の値も定義できるという話がでてきますが、それ以上でもそれ以下でもないです。一般的なプログラミング言語なら定数ともいえそうです。 つづいて、ガード付等式です。ガード 付等式 か ガード付 等式悩みましたがたぶん後者でしょう。 まだ、登場していませんが、パターンマッチよりも細かいところで分岐させるのによく使います。数学のノートみたいに見えてよいです。一応例をだしておきます。 compare x y | x > y = LEFT | x == y = EQUAL | x < y = RIGHT LEFT、EQUAL RIGHTの定義をしていませんが、比較して大きいほうを返す関数です。よみやすいです。このように3パターン以上に分岐する場合は if を使用するよりもよみやすくなります。 ifを使うと compare x y = if x > y then LEFT else if x == y then EQUAL else RIGHT みたいな感じでしょう。 再帰定義 あまり文章での説明がなかったです。関数の中で自分の名前が使用できます。実際に手を動かして簡約してみると、再帰というものが存在して良いことが確認できると思います。 ただし、終了条件がなければ収束することなくどんどん大きくなります。 局所定義

no_picture

読書メモ 関数プログラミング入門 Haskellで学ぶ原理と技法 1.4 関数

関数プログラミング入門 Haskell で学ぶ原理と技法 の読書メモです。 本節は 関数 について。 要点は 外延性 カリー化 演算子と関数 優先順位 結合順序 関数合成 です まず関数は値として扱えますが、表示することはできません。引数を適用することで表示できる場合があります。 また、関数は 引数の値 を戻り値 の型に変換する(対応をつける)役目をもちます。関数の型を示すには -> 演算子を使い 型A を受取り 型B を返す場合 A -> B とかきます。 関数 と 関数に値を適用したものを混同しないように気をつけたほうがよいそうです。 外延性 関数が等しい場合は任意のxに対し以下が成立します。 f x = g x この方法は関数に値を適用した結果が一致するので 適用的証明 というそうです。また ポイントワイズスタイル ともいうそうです。このように f や g はブラックボックスですが、引数と結果で確認できるので外延性の原理 逆に定義から f = g を示す場合はポイントフリースタイルというそうです。ただし、効率が違う場合があり、これは内包的性質というそうです。 カリー化 単一の引数の関数の複数の引数に分解できます。こうすると関数に引数をひとつだけ適用すると新しい関数を作成することができます。結果が変わらないので括弧が減ったり、引数を変えるだけで様々な効果をもつ関数がつくれる利点があります。Arrow を使う場合は逆に アンカリー化をする場合もあります。 演算子と関数 演算子も実質的には2引数の関数ですが中置することができます。Haskellでは 括弧で演算子を囲むことで通常の関数にもできますし、関数をバッククォートで囲むことで演算子のように利用できます。また、括弧で演算子を囲む場合は (+1) のようにして あらかじめ引数を適用したりもできます。これをセクションというそうです。 優先順位 結合順序 これらのおかげで 括弧を省略することができます。 これらの把握しておかないとHaskellのコードを読む際によくわからなくなるのでしっかりと慣れておいたほうが良いです。 関数は最優先で左結合です。 f x y + z であれば ((f x) y) + z と等価です。 右結合か左結合か は演算子によって違いますが、どちらでも同じ結果になるものもあります。これを結合性というそうです。+ や * は結合性があります。 関数合成 関数合成は関数と関数を演算できます。結合性です。 ある関数の結果を別の関数の引数にできる場合に利用できます。 f (g x) が正しい場合 (f .

no_picture

Github pages が反映されない?と思ったらスパム扱いされてるかも

ここ最近 github に push しても Github pages が反映されない現象に悩まされておりましたが、スパム判定されていたらしいです。私のgithubのprofileページが私以外の人がみれなくてスパム判定されていることが発覚しました。同じようなことに悩まれることがあれば、運営に確認してみてはどうでしょうか。

no_picture

Rails の rake notes というタスクをいまさらしった。

Rails Guide 読んでたら notes というタスクがあるのを知りました。 コードのコメントに TODO とか FIXME, OPTIMIZE といったコメントをみつけて表示してくれます。 grep すればいいやとか思いますが、それなりの便利そうです。jenkins なんかで回してレポートに出すのもよいかもしれません。 $ roke notes app/controllers/admin/users_controller.rb: * [ 20] [TODO] any other way to do this? * [132] [FIXME] high priority for next deploy app/model/school.rb: * [ 13] [OPTIMIZE] refactor this code to make it faster * [ 17] [FIXME] notes:custom というタスクもあるようです。 もう少しつっこんでみよう タスクのソースコードがここになります。 notes:custom では 環境変数 ANNOTATION で表示するキーワードを決められるようです。 notesの場合は “OPTIMIZE”, “FIXME”, “TODO” の3つか使用されていますね。 あと 動的にタスクを生成しているようなのでnotes:todo optimize fixme

no_picture

読書メモ 関数プログラミング入門 Haskellで学ぶ原理と技法 1.3 値

関数プログラミング入門 Haskell で学ぶ原理と技法 の読書メモです。 本節は 値 について。 値と式の関係。値と正格関数、非正格関数。がメインです。 値は 式を用いて表現できます。値を表現する式はひとつだけではなく、複数存在し、評価機が出力する表現は 標準表現 が利用されます。基本的には評価可能な式が表示されるということのようです。Rubyでいうと pメソッドの出力結果に近そうです。 また、値を表示しようとすると停止しない可能性が存在します。このような状態になる関数を正格関数と呼びます。具体的にシンプルに定義されてるのでわかりやすいです。正格でない関数は非正格なりますが、これは遅延評価でないと定義できないそうです。 練習問題は正格と非正格について考える問題でした。 関連 メモ用のリポジトリ 1章 1.3の練習問題

no_picture

Gentoo Prefix 環境で git がビルドできないので bug報告してみた

結構前からわかっていたんだけども、Gentoo Prefix on Mac OSX で USE=“subversion” していると gitのビルドに失敗していた。 なので、ビルドできるようにして、パッチを書いて Gentoo Bugzila へバグ報告してみた。 Gentoo Prefix というのは Gentoo Linuxのパッケージ管理である portage を /以外のところにインストールしていろんな環境で利用できるようにしているものです。役割的には MacPorts や Homebrew と同じように Mac で Unixツールをインストールするのに利用しています。 どんなエラーがでていたか USE=“subversion” emerge gitすると LINK svn-fe Undefined symbols for architecture x86_64: "_libintl_ngettext", referenced from: _show_date_relative in libgit.a(date.o) "_libintl_gettext", referenced from: _show_date_relative in libgit.a(date.o) _warn_on_inaccessible in libgit.a(wrapper.o) _xgetpwuid_self in libgit.a(wrapper.o) ld: symbol(s) not found for architecture x86_64 svn-fe をビルドに失敗していました。 いろいろ調べてみると OSX 上では -lintl をつければビルドできることがわかりました。git をビルドするための Makefile はかなり凝ったものが使われてるのですが、その判定が svn-fe の Makefile にないため -lintl が自動でついていませんでした。 どんなパッチをかいたか CHOST で darwin がある場合 contrib/svn-fe/Makefile をかきかえるようなその場しのぎでかいてみました。 diff --git a/dev-vcs/git/git-1.8.1.ebuild b/dev-vcs/git/git-1.8.1.ebuild index 1bfa55a..3338847 100644 --- a/dev-vcs/git/git-1.8.1.ebuild +++ b/dev-vcs/git/git-1.8.1.ebuild @@ -241,6 +241,12 @@ src_prepare() { -e '/$(INSTALL)/s/ $(libexecdir)/ $(DESTDIR)$(libexecdir)/g' \ -e '/$(INSTALL)/s/ $(man1dir)/ $(DESTDIR)$(man1dir)/g' \ contrib/subtree/Makefile + + if [[ $CHOST == *-darwin* ]]; then + sed -i \ + -e 's:EXTLIBS =:EXTLIBS = -lintl:' \ + contrib/svn-fe/Makefile + fi } git_emake() { いろいろみていると sed -i で改行を入れてから sed の命令をかいていくスタイルが多いのでそれに従いました。 どこに投稿したか https://bugs.gentoo.org/show_bug.cgi?id=452044#c0 に登録されています。 登録方法は アカウントを作成 new をクリック Gentoo/Alt をクリック 類似バグがないか検索 component は Prefix Support を選択 Opereting System は OS X を選択 summaryとdescription を記述 登録 パッチを追加 という感じでした。 component には Mac OSX という項目がありますが、DEAD.

no_picture

読書メモ 関数プログラミング入門 Haskellで学ぶ原理と技法 1.2 評価

関数プログラミング入門 Haskell で学ぶ原理と技法 の読書メモです。 本節は評価を中心に式の簡約化についての説明です。 正規形という形を目指して式を簡略化していきますが、関数プログラミングにおいては、どのような手順で簡約しても最終結果が一致するのが特徴です。 代入のような破壊的な操作が存在する世界では、順序が影響します。 そこが命令型のプログラミングと違うところでしょう。そのため並列処理させるたべ順序に影響しないため、関数プログラミングが評価されてる部分だと思います。 話が脱線しましたが、簡約の手順には 1つだけでなく複数存在する可能性があります。そのためプログラミング言語によっては簡約の評価戦略が違うようです。 あと、簡約の手順が違う場合、停止しない場合が存在することもあります。 練習問題は評価の順序、停止性について考えるような問題でした。 関連 メモ用のリポジトリ 1章 1.2の練習問題

no_picture

読書メモ 関数プログラミング入門 Haskellで学ぶ原理と技法 1.1 セッションとスクリプト

関数プログラミング入門 Haskell で学ぶ原理と技法 の読書メモです。 本書は 2002年に出版されたIntroduction to Functional Programming using Haskell の2版の翻訳です。 いまになって日本語に訳されたということはそれなりの名著なのかなー。ということで、Haskellネタを書く機会があまりなかったので、読書メモを書いていこうと思います。 問題を解いてくのに最強の環境をつくろうぜ。と、意訳できる文章ではじまります。本節は Hugs を使用することを想定して セッション、スクリプトといった対話環境だからこそしっくりくる用語を中心に基本用語が解説されています。 スクリプトによって定義を追加していき環境を構築した上で 式を評価 するというのが主軸なのかなあ、と思います。環境/文脈は束縛の集りであるというのは非常にシンプルで実際の文脈の小ささは関数プログラミングの特徴と言えるのではないかな、と思いました。 あとは、定義には関数の定義がかかれ、関数には 型シグネチャ をかけることぐらいかな。 練習問題が関数定義の練習と束縛済みの関数を再利用するのが目的な感じでした。 関連 メモ用のリポジトリ 1章 1.1の練習問題

no_picture

今後のiOSアプリケーションのために Auto Layout を学んだ - 内容編

今後のiOSアプリケーションのために Auto Layout を学んだ - 準備編 につづき勉強した内容をまとめていきたいと思います。 まずは Auto Layoutについて。概ね WWDC 2012 の session 202 のまとめだったり、使ってみた感じでのまとめです。仮説もいっぱい混ざってるので注意してください。 Auto Layout は制約ベースのレイアウトシステム Auto Layout は ふたつのViewの関係を設定していくことでレイアウトを構築します。 例えば ある特定のViewは親のView左から 自分の左端を 20pt あける のような制約をつくります。これらの制約を追加していくことで期待するレイアウトを構築します。 制約が無い場合はそれぞれデフォルトの振舞いがあります。 動きをみつつ上書きしていくような形になります。 制約のでViewのサイズなのが自動的に決定していくのでコードで記述する場合は frame の設定が不要になる書き方ができます。 Auto Resizing Maskの機能を再現することもできる Auto Layout は 以前のレイアウトシステム(?)である Auto Resizing Mask の表現範囲より大きなもので、エミュレートすることができます。Auto Resizing Mask でできることはすべてできますし、コードから利用する場合は今までどおりの挙動をします。 また、デフォルトでは Auto Resizing Mask をエミュレートしています。エミュレートさせたくない場合は translatesAutoresizingMaskIntoConstraints プロパティを NO に設定します。 作成できる制約 制約はふたつのviewに対して item1.attribute1 = multiplier x item2.attribute2 + constant という式を満たすように attribute1 を設定するようです。(たぶん) 等号の部分は不等号を指定することができます。制約はNSLayoutConstraint

no_picture

今後のiOSアプリケーションのために Auto Layout を学んだ - 方法編

12月29日に @mako_wis と @NeXtSTTEP2OSX の中の人の Auto Layoutの勉強会をした。 そこでのメモをここに記す。まずは勉強会のやり方について書いておきます。 どんなやりかたで勉強したの? 参加者が 岡山 広島北部 広島西部と集まるのがめんどくさい Skype と 画面共有を駆使した 事前に WWDC の動画をみてくることにした 動画の内容を手を動かして挑戦する そこからやってみたいことをやってみる 気をつけた点 操作する人を交代するようにした 同じような内容のちょい難しいバージョンを交代してやることで理解の共有を図った 操作する場合は、先に見てる側の意見を中心に作業するようにした 自薦予習することだけはあらかじめ念をした 前日に skype、 画面共有の動作確認をした 気になる点 聞いてるだけの人はグダグダになりそう。 わからないことで詰まるともくもくタイムになりそう みんながまとめを記事にしてない 画面共有の方法 画面共有には Mikogo というツールを使用した。 フリーだと3人までは共有可能。人数を増やす場合、もっと良いツールがないか検討したい。 あまり問題は起きなかったのですが、 MBP Retina の人が画面を共有できずにはまりました。外部ディスプレイをつけて、外部をメインディスプレイにすることで強制的に Retina モードから脱出するという無理矢理な方法で解決。(今回は関係ないけど, ユーストするときにも応用できました) まとめ オンラインで勉強会を行うと集まるコストを低減できてよいです。相手のPCを操作することが難しいので、ある程度PCの操作になれている人たちであれば、IT勉強会以外にも応用できるかもしれません。 当日の最初に様々なトラブルが起きる可能性が高いので、前日に動作確認してグダグダになるのを防ぐことができました。 参加者との画面の切り替えがオフラインより楽なので、ペアプロっぽいことを複数人で行うことができてよいです。 また新な高い壁があるときにやりたいです。

no_picture

UITabBarControllerのMoreに表示される edit を消したいなー。

「UITabBarControllerのMoreに表示される edit を消したいなー。」と思いながら、なんてググればいいんだろーと思いつつも、ヘッダファイルをみていたら customizableViewControllers ってプロパティがあった。 迷わずに nil に設定した。うまくいった。 もし、UITabBarControllerを継承してるクラスがあるなら -viewDidLoad で処理してしまうのが早いです。 self.customizableViewControllers = nil; ない場合、用意しましょう。といってもいいんですが、タブ内の UIViewController の viedDidLoadで self.tabBarController.customizableViewControllers = nil; でも、いけました。 「継承してるコントローラあるのにわざわざ試したんだからねっ!」 ちなみに、 このプロパティは nil じゃない場合 "Edit" で表示されるコントローラをカスタマイズできてデフォルトはすべてのコントローラだよ。 的なことが書かれていました。なので空の配列を渡してもOKです。

no_picture

Devise で email 変更する。

Railsの plugin で 認証を行なう devise という gem があります。 このユーザ認証で 実際にユーザにメールを送信して、登録を完了するという機能を提供するのに confirmable という機能があります。 このConfirmableという機能を使用していると管理者が ユーザのメールアドレスを変更してあげる必要がある場合、代えるときもメールがユーザに送信されます。これが便利なときもあったりテスト時にこまったりすることがあります。 devise :confirmable した モデルには skip_confirmation! skip_reconfirmation! というメソッドが追加されてるので、これらを呼び出すことで回避することができます。 ちなみに、これらのメソッドの中身をみると def skip_confirmation! self.confirmed_at = Time.now.utc end def skip_reconfirmation! @bypass_postpone = true end となってます。 confirmed_at に値がはいっていれば有効で、@bypass_postpone が true で メールの送信が回避できそうですね。このあたりの実装はversionによって変更される恐れがあるので直接利用するには注意が必要です。

no_picture

Rubyの 1.8 スタイルの Hash を 1.9 に書き換える

syntax_fix を使うと一瞬でした。 (defun query-replace-ruby-18-to-19-stayle-hash (&optional delimited start end) "Rubyの 1.8 スタイルの Hash を 1.9 から導入されたスタイルへ確認しながら変更する ネストした hashには対応していない" (interactive) (query-replace-regexp ":\\([^ ]+\\) => \\([^ ]+\\)" "\\1: \\2" delimited start end)) という正規表現を指定しただけの Emacs Lisp も書いたけどみなかったことにしてください。

no_picture

ActiveRecordで関連レコードの自動保存

ActiveRecordで has_one なんかで関連づけしている場合、関連モデルを保存しわすれる。 そもそも、関連してることをドメインロジック上からは隠蔽したい。そんなときは autosave オプションが使えます。 関連するモデルが Information の場合、 has_one :information, autosave: true となります。 informationで親のモデル IDを validate presence かけてたらはまったことも一応メモしておきます。

no_picture

zeus test で スペックを実行すると 2度実行されてしまう

zeus test で spec を走らせるとなぜかスペックが2度実行されるようになっていた。 spec/spec_helper.rb 内の require 'rspec/autorun' を削除すると治るようです。 spork で実行してみたり、 rake spec したりもしてみたけど、消したから起きている問題は今のところないです。 追記 zeus rake spec したときに DB がリセットされてなくて上手く動いてないことがわかった。全件まわしたい場合は rake spec を使用してたので気がつかなかった。 参考 https://github.com/burke/zeus/issues/180

no_picture

Macで M-x gdbするとうまく動かない…

まず要点から。 新しめの emacs でMac上で M-x gdb がうまくうごきません。 M-x gud-gdb は動くことがわかりました。 gud-gdbを使う場合はgdb --fullname commandで動かすと良いです。 原因ですが、Macの gdb が古い模様。最近の Emacsに添付されてる gdb は gdb/mi インターフェイス(よくわかってない)でやりとりするようで、一応うごくけどわけのわからぬ動作をするみたいです。 gdbmi Gentoo-Prefix をつかって gdb いれてみたものの run ができませんでした。ツールチェーンまわりはよくわからないのでなんとも言えません。 gud-gdb ですが、これは gdb よりも機能が弱いものの模様です。古いeamcsがこれと同等のもので動いてるのかもしれませんが、調べていません。gdbに比べたら便利な機能は減るかもしれませんが、十分使えそうです。 LLDB/MI みたいなものがあれば良いのでしょうが、よくわかりません。 このあたりはMac使ってて不便なところですね。

no_picture

Gitのソースコードでも読もうかな。準備編 - デバッガ

ソースコードよみたいなー。よみたいなーってことで、環境を整えていきたいと思います。ひらメソッドにも挑戦したい。 静的によむのも良いのですが、答え合わせができないと遠まわりです。デバッガを使って答え合わせできると効率がよいです。なので、ソースコードをDLして、動作確認するところまで試してみましょう。 Gitのソースコードは https://github.com/git/git とかにあります。 cloneしてみましょう。 $ git clone git://github.com/gitster/git.git $ cd git 別にどのバージョンにしてもいいのですが、自分が使っているバージョンでコードリーディングしていきたいと思います。 $ git --version git version 1.8.0.2 $ git checkout v1.8.0.2 これで v1.8.0.2 のソースコードになっています。デバッグ情報をもった状態でビルドしてみましょう。 $ make -d -d をつけることでOKです。 しばらく待つとバイナリが生成されますので、gdb をつかってみましょう。 $ gdb git (gdb) これで gdb が起動できます。プロンプトに (gdb)と表示されます。 この状態で r を入力すると実行ができます。 (gdb) r usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path] [-p|--paginate|--no-pager] [--no-replace-objects] [--bare] [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>] [-c name=value] [--help] <command> [<args>] The most commonly used git commands are: add Add file contents to the index bisect Find by binary search the change that introduced a bug branch List, create, or delete branches checkout Checkout a branch or paths to the working tree clone Clone a repository into a new directory commit Record changes to the repository diff Show changes between commits, commit and working tree, etc fetch Download objects and refs from another repository grep Print lines matching a pattern init Create an empty git repository or reinitialize an existing one log Show commit logs merge Join two or more development histories together mv Move or rename a file, a directory, or a symlink pull Fetch from and merge with another repository or a local branch push Update remote refs along with associated objects rebase Forward-port local commits to the updated upstream head reset Reset current HEAD to the specified state rm Remove files from the working tree and from the index show Show various types of objects status Show the working tree status tag Create, list, delete or verify a tag object signed with GPG See 'git help <command>' for more information on a specific command.

no_picture

read_attributeの存在を知らなかった、死にたい - rails

Railsの ActiveRecordで レコードの属性にアクセスする際は動的に生成されたメソッドを使いますが、そのようなメソッドを上書きしている場合、値に直接アクセスする必要があります。このような属性情報は @attributes に保存されています。 /lib/active_record/attribute_methods.rbに定義されてる attributes メソッドを経由してアクセスしていましたが、なんとなく @attributes へ直接アクセスするだけかとおもってたのですが、違ったようです。 def attributes attrs = {} attribute_names.each { |name| attrs[name] = read_attribute(name) } attrs end という定義になってました。 attribute_names は文字列で属性の一覧を返すので @attributesは 普通のHashでキーが文字列です。 もし email というの属性にアクセスしたい場合は attributes["email"] になります。 attributes[:email] ではアクセスすることができません。 しかし、 read_attributeは シンボルでも文字列でも使用することができて、 read_attribute :email でも read_attribute "email" のどちらでも良いみたいです。 ちなみにエイリアスがあって [] メソッドになります。なので self[:email] などでアクセスできます。pubilcメソッドです。 read_attribute があるということはも write_attribute もあります。 ついでにもう少し深追い read_attributeの実装もついでにおってみると def read_attribute(attr_name) self.class.type_cast_attribute(attr_name, @attributes, @attributes_cache) end となってました。クラスメソッドを経由するようです こいつも中身を追うと def type_cast_attribute(attr_name, attributes, cache = {}) #:nodoc: return unless attr_name attr_name = attr_name.to_s if generated_external_attribute_methods.method_defined?(attr_name) if attributes.has_key?(attr_name) || attr_name == 'id' generated_external_attribute_methods.send(attr_name, attributes[attr_name], attributes, cache, attr_name) end elsif !attribute_methods_generated?

no_picture

ViewSourceMap が地味に役に立つ

ViewSourceMapというのが地味に役に立ちそうなので導入してみた。 部分テンプレートを render して出力された前後にどの view をレンダーしたのかHTMLのコメントを挿入してくれる。 <!-- BEGIN app/views/users/_form.html.haml --> <form /> <!-- END app/views/users/_form.html.haml --> ついでに、partial以外のレイアウトとかメインのビューとかもついでに出力してみるのもありかなと思ったりもするけど、その辺は明確だし、時間ができたら fork してみよう ソースコードも短いしRails の plugin 的なものを作ってみたいときにも参考になりそうでした。 https://github.com/r7kamura/view_source_map

no_picture

ruby 2.0.0-preview2 をいれて rails起動してみた

ruby 2.0.0-preview2 が出てるのでビルドして rails を起動してみた。 $ uname -v Darwin Kernel Version 12.2.1: Thu Oct 18 16:32:48 PDT 2012; root:xnu-2050.20.9~2/RELEASE_X86_64 preview1のときと同様にopenSSLがついてこないので、OpenSSLを一緒にビルドするようにrbenvを修正しました。[https://github.com/eiel/ruby-build/tree/2.0.0-preview2-with_openssl] bundle instalの実行で ~/.rbenv/versions/2.0.0-preview2/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require’: cannot load such file – rubygems/format (LoadError) と出てしまいますが rubygemsのライブラリ構成が変わっててbundlerが動かないだけみたいなので、 $ gem install bundler --version ">= 1.3.0.pre2" として 1.3 系の gem をいれました。 あとは普通に rails が起動できました。

no_picture

raptureXML でXMLのparse

XMLのパースしなきゃいけなくて、libxmlで処理するのめんどくさいなー。ということで、CocoaPodを探った結果、RaptureXMLを試してみることにしました。 URLから直接XMLを取得するイニシャライザがついていて、とても簡単に利用することができました。 CocoaPodsを使わない場合は libz と libxml2 をリンクしてやるようにして、RXMLElement.hとRXMLElement.mをプロジェクトに追加するだけで使えます。 だいたい以下のように利用してます。 NSURL* url = [NSURL URLWithString:@"http://eiel.info/hoge.xml"]; RXMLElement* root = [RXMLElement elementFromURL:url]; NSMutableArray* schedule = [NSMutableArray array]; [root iterate:@"item" usingBlock: ^(RXMLElement *item) { [schedule addObject:[[ALScheduleItem alloc] initWithRXMLElement:item]]; }]; i_schedule = [NSArray arrayWithArray:schedule]; RXMLElementオブジェクトを配列に格納しておいて利用しようとしたら、失敗したのでモデルオブジェクトを用意してやりました。 値を取り出すには [element child:@"day"].text; とやって取り出せます。DOMのインターフェイスになってますね。XPathも利用できるようです。 ソースコードも500行程度でコンパクトでした。

no_picture

MacでWMAやWMVの再生c

Macで WMA や WMV といったWindows Media ファイルを再生するには Flip4Macというツールを利用するのが定番みたいなのですが、再生中に 「This is a demonstration of Flip4Mac」という音声が定期的に流れるようです。とりあえず、聞いてる分には問題ないのですが、サウンドレコーダで録音したい音声を編集したいだけなので、ちょっと困りものです。 $24 払えば出なくなるみたいですが、それだけのために $24 は高すぎやしないだろうか。 WMAは圧縮率も高く非常に優れた形式ですが、最終的な利用形式としては今回採用しませんし、サウンドレコーダの形式がそうだったに過ぎないので、Switch というフリーツールで別の形式に変換させていただくことにしました。 参考文献 Apple サポートコミュニティ WMAファイルとMP3ファイルを一緒にして音楽CD作成はできますか

no_picture

もっと楽ができた。bundle init で作成したプロジェクトの rake task

以前 勢いでhiroshimarbというgemを作った。反省する気なんてあんまりない。という記事で gem の リリースをする方法を書いたのですが、 bundle gem で作られた rake タスクも見てあげると良いかもしれません(rake releaseだと push しつつ tag も切ってくれたりする)。(via @sugamasao) https://twitter.com/sugamasao/status/268286597110312960 というコメントを頂いてました。 なので、調べました。 $ rake -T rake build # Build hiroshimarb-0.1.4.gem into the pkg directory rake install # Build and install hiroshimarb-0.1.4.gem into system gems rake release # Create tag v0.1.4 and build and push hiroshimarb-0.1.4.gem to Rubygems rake release で git でタグをつくりつつ、rubygems.org に uploadしてくれました。 生成したgemは pkg ディレクトリ内に保存されます。対した作業ではないですが、バージョンを入力する手間が省けて素敵ですね。 taskの中身は Rakefileが $ cat Rakefile (gi#!/usr/bin/env rake require "bundler/gem_tasks" ということで gem_task.rb をみてみましょう。 require 'bundler/gem_helper' Bundler::GemHelper.install_tasks Bundler::GemHelper.install_tasksが呼ばれてます。 def install_tasks(opts = {}) new(opts[:dir], opts[:name]).install end install_tasksはインスタンスを生成して installすることがわかります。 つづいて インスタンスを生成するので、initilaizeです。 Bundle::GemHelper#initializeでは gemspecを読み込んでいるようです。なんとなくしかみてません。 def initialize(base = nil, name = nil) Bundler.ui = UI::Shell.new @base = (base ||= Dir.pwd) gemspecs = name ?

no_picture

Mac で rbenv 使って ruby-2.0.0-preview1 インストールすると OpenSSLがうごかないのでなんとかしてみた

以前書いたruby-2.0.0をビルドしてみた on Rbenvの方法で build できるのですが Mac OSX でやると OpenSSLのバージョンが古いようで、 bundle install などが失敗してしまいます。 なので OpenSSLを一緒にインストールするようにパッチを書いてみました。 githubにupしてます。 上記の記事と同じ状況であれば以下の操作でインストールできます。 $ cd ~/.rbenv/plungin/ruby-build $ git remote add eiel git@github.com:eiel/ruby-build.git $ git remote update $ git checkout eiel/master -b eiel $ rbenv install 2.0.0-preview1 patchの内容ですが share/ruby-build/ にビルド時のルールを定義するファイルがあるのでそこに OpenSSL を追加しました。でもそのままだと失敗したので、configure のoptionを追加したり make のオプションを潰したりしてます。 homebrewを使った場合の情報はおちてるんですが Gentoo Prefix を使う身としては使わずになんとかしたかった。 参考文献 http://blog.takuyan.com/blog/2012/11/21/rbenv-install-2-0-0-preview1-and-openssl/ https://github.com/mxcl/homebrew/blob/master/Library/Formula/openssl.rb

no_picture

部分一致 - Bash

シェルスクリプトで部分一致を確認したい場合どうするんだろーっと思って考えた結果 grep の終了ステータスで確認すればいいんじゃないかということで。以下のように書いた。 search_term="openssl" target="openssl-1.0.0" if echo $target | grep "$search_Term" > /dev/null; then echo "goro" fi せっかくなので簡単に解説 shellの if は終了ステータスに応じて分岐します。 終了ステータスは $? に代入されています。 echo $target | grep "$search_Term" > /dev/null; echo $? とすればどんなステータスを返すのか確認できます。 grep は match しなければ 終了ステータス 1 を返すので 確認したい文字を流し込んでチェックして、余計な内容を表示しないように /dev/nullにリダイレクトしてます。 もっと良い方法があれば教えていただきたい。

no_picture

TagHelperっていうのがあるんだけど、周りの人が使ってない - Rails

Railsのhelperに TagHelper っていうのが text_area_tag のようなフォームを作成するような Helper がありますが、その内部で使用するようなメソッドが定義されています。 主に tag, content_tag になるのですが、自分でHTMLのタグを生成するようなヘルパーを生成したときこれを使うと便利です。 例えば hoge的なものを表現するタグを生成するhoge_tagという抽象化をしたいときにざっくりな実装をすると以下のようになります。 def hoge_tag(content) %Q{<div class="hoge">#{content}</div>}.html_safe end hoge_tag "hogehoge" # => "<div class=\"hoge goro\">hogehoge</div>" しかし、つかっていくと個別に class属性を追加したくなる場合が多々ありますし、content の escape などもしないといけないです。 def hoge_tag(content, *classes) classes = ["hoge"] + classes class_string = classes.join(" ") %Q{<div class="#{class_string}">#{content}</div>}.html_safe end hoge_tag "hogehoge", "goro" # => "<div class=\"hoge goro\">hogehoge</div>" もちろん、class属性だけじゃなくていろいろ指定したくなります。 text_area_tag なんかと同じようにoptionsで受けるようにしたい。こうなっとときに 「ソースを読もう!!」 という発想が出るようになると良いと思います。 def hoge_tag(content, options = nil) classes = options[:class] classes = [classes] unless

no_picture

HTMLを印刷時 表の途中で改ページを防ぐ

印刷用のページってどうやって作るのがいいんだろう? PDF? HTMLでもいいの? ってことで HTML でかきはじめてました。 キャプションと表をひとくくりにしたかったのですが、そのままだと表の途中で改ページされてしまうのは具合が悪くてなんとしたい。 ひとつの表はページを跨いで欲しくない。 CSSで改ページを制御するには page-break-inside を avoid にしてやればよいらしいです。 なので以下のようなHTMLを用意して、 <div class="block"> <h1>表の説明</h1> <table> <tr> ... </tr> </table> </div> CSSを以下のように用意すると期待したとおりになりました。 .block { page-break-inside: avoid; }

no_picture

git push 時に発生する update hookを起動するワンナイナー

git の hooks の update hook の動作確認するのに使ってたワンナイナー。 update というのは リモートリポジトリに push したときに リモートで起動するスクリプト。 $ git commit --amend --no-edit; git push --force git commit --amend を使用してコミットの日付を変更しておけば新しい commit として認識してくれるので、–force オプションで無理矢理 push してやる。 コミットが新しくなるので hook が起動してくれます。 git push の部分は適宜好みに合わせて。

no_picture

認証必須環境におけるJenkinsのスクリプトトリガーによるビルドの実行

Jenkinsは便利に使わせていただいているのですが、git push をhookしてビルドの開始をできるようにしていないまま運用していて、重い腰をあげてやっと設定することにしました。 公開しているサーバやイントラにあるサーバであれば http://YOURHOST/jenkins/job/PROJECTNAME/build ヘ wget してしまえば良いので簡単です。インターネット上に置いているとそうもいかないので、認証を必須にします。 認証を必須にしている場合は ユーザID (USER) API Token (APITOKEN) Project Token (PROJECTTOKEN) が必要になります。 API Tokenと Project の Tokenが別のものだと気がつかずに無駄にはまりました。 $ wget --auth-no-challenge --http-user=USER --http-password=APITOKEN 'http://jenkins.yourcompany.com/job/your_job/build?token=PROJECTTOKEN' とすることで上手くいきました。 最終的には $ wget -q --auth-no-challenge --http-user=USER --http-password=APITOKEN 'http://jenkins.yourcompany.com/job/your_job/build?token=PROJECTTOKEN' -O - > /dev/null で回してます。 USER はユーザのIDをそのまま使えばよいです。 APITOKEN はユーザの設定画面にあります。 PROJECTTOKEN はプロジェクトの設定画面で自分で設定します。 参考文献 https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+clients

no_picture

ActiveSupport::Concern - Railsのソースとか読みはじめた 2

ActiveSupport::Concern - Railsのソースとか読みはじめたの続きになるのですが、 @netwillnet さんに。 ActiveSupport::Concernはモジュールが少しだけ書きやすくなるというメリットよりも、複数のモジュール同士に依存関係があったときにモジュール内でその依存関係をうまく解消させられるところに真価があるのでは https://twitter.com/netwillnet/status/270150759335723008 と素敵な突っ込みを頂いたので、rdocとソースコードと睨めっこしてきました。 睨めっこした結果の結論を書きたいと思います。 というわけで A -> B -> C という依存性があるモジュールを考えます。A には B が必要で。 B には C が必要という意味です。 module C def c "c" end end module B include C def b "b" + c end end class A include B def a "a" + b end end A.new.a と実行すると "abc" と出力されます。 これと同じことをクラスメソッドで実現しようとしてみます。 module C2 def c "c" end end module B2 def b "b" +

no_picture

Rails 3.2.9 で default_scopeに設定してる条件が属性の初期値になるらしい

あるプロジェクトでrails 3.2.9 にアップデートしたら テストが失敗しまくる。そのひとつに ActiveRecordの default_scope を使ってる部分に問題があるとわかった。 どんなエラーかと言いますと。 NoMethodError: undefined method `to_i' for [1, 2, 3]:Array from activerecord-3.2.9/lib/active_record/connection_adapters/column.rb:178:in `value_to_integer' [1, 2, 3] とか即値すぎて わけがわからないよ という感じだったんですが、いろいろ調べると class User < ActiveRecord::Base default_scope proc { where(state_id: [1, 2, 3]]) } end というコードがあったときに User.new すると発生することがわかりました。 仕方ないので、 class User < ActiveRecord::Base scope :valid, proc { where(state_id: [1, 2, 3]]) } end として、ひたすら置換しまくりでした。 僕はdefault_scope使わない派なのであまり気にしない方向で。 ちなみに class User < ActiveRecord::Base default_scope proc { where(state_id: 1,name: "hoge") }

no_picture

Capybaraでtitleタグの内容が取得できなくなってしまった。

Capybaraを2.0にしたら動かなくなった Cucumber の step がありました。titleタグ のtextをとる部分。visible でない要素のtextは取得できなくなったんでしょうか。 コードを追う余裕がなかったので、Nokogiriで対処した。 target = find("title").text expect(target).to eq(title) を target = Nokogiri::HTML.parse(page.source).css("title").text expect(target).to eq(title) に書き換えました。 ちょっと無理矢理。 Cucumberについてやりとりする仲間がいないので、titleタグのテキストの中身なんて確認しなくていいよ!とか、そういうい話ができないのが寂しいですね。

no_picture

ActiveSupport::Concern - Railsのソースとか読みはじめた

Railsのソースをちょろちょろ読むようにしている。読んで学んだことをメモしておきたい。だいたい読んだ当時の最新リリースを参考にします。 ActiveSupport::Concern を読みました。 このモジュールはモジュールの定義を手助けします。 クラスメソッドの定義場所をルール決めして include するだけで済むようにしたり、クラスのコンテキストで実行したい処理を書く場所を用意してくれます。 具体的にいきます。 以下のコードがあったとします。 class ConcernSample attr_accessor :hoge def self.mogu "mogu" end def goro "goro" end end これを以下のようにするだけで同じ機能を提供できるようにしたいと思います。 class ConcernSample include Sample end 処理を Sample モジュールにまとめたいということです。 これができると class ConcernSample include Sample end class ConcernSample2 include Sample end class ConcernSample3 include Sample end と、似たような機能をもつクラスを量産できます。 クラスに機能を追加するのが簡単になるという視点を持つとよいでしょう。 さて、Sample はどのように書くかということです。 ここで ActiveSupport::Concern を利用します。 require 'active_support' module Sample extend ActiveSupport::Concern included do attr_accessor :hoge end module ClassMethods def mogu "mogu"

no_picture

debugger-ruby_core_source に Ruby 1.9.3-p327 のヘッダ追加してみた

2012/11/17 追記 1.1.5がリリースされて基本的に以下の作業は不要です。 以下の記事は興味がある方だけどうぞ。 昨日になりますが、 Ruby 1.9.3-p327 のリリースがありました。早速インストールして開発環境で試してみてます。 前回のリリースのときもそうだったのですが、rbenv と ruby-build を使用していると、 debugger-linecache のインストールにこけてしまいます。この子をインストールするには ruby の ヘッダが必要になります。(他の環境でもなるかもしれませんけども) この gem は debbuger を利用している場合必要になります。 そのヘッダを提供する debbuger-ruby_core_source というgemがあるので、この子を git clone で取得してごにょごにょすればごまかせます。 前回はごにょごにょしたものがすでにあったので git clone して gem build gem install のコンボで済んだのですが、自分でやってみました。Pull Request も出してるのでそのうち gem が更新されるのでそんなに気にする必要はないかもしれません。 すぐにインストールしたい人向け とにかく、動かしたい人で debugger-ruby_core_source.gem が欲しい人むけ $ git@github.com:eiel/debugger-ruby_core_source.git $ gem build debugger-ruby_core_source.gemspec $ gem instll debugger-ruby_core_source-1.1.5.gem あとは bundle install などやりなおしましょう。 どうやって更新するか知りたい人向け READMEみればわかるのですが簡単に更新できます。 $ gem install archive-tar-minitar $ rake add_source VERSION=1.9.3-p327 add_source という rake task が用意されてるので簡単です。 この実行には archive-tar-minitar が必要になります。 bundler に対応されてないので直接いれました。 ネットワークみてみると対応されてるのがありましたが取り込まれてないようです。 あとは commit を作ればOKです。 最近の gem は gem を生成する際に git ls-tree の情報が使用されるので commit しないとハマります。 では happy programming !

no_picture

コード補完に便りにし過ぎてはいけない。

ふと思っただけなのですが、コード補完に便りにし過ぎるのはダメなんではないだろうか。しかし、まず前提条件を付けたい。 コード補完はしまくれ!! コード補完などの補完機能を利用していない人はいますぐ使いましょう。 Emacs なら M-/ vim なら C-p, C-n Sublime Text 2 なら C-Space TextMate 2 なら ESC などなどでデフォルトでもある程度できます。メソッド補完などをしたくなればカスタマイズしていきましょう。 コード補完はとても便利なのですが便りすぎるといくつかの問題が出てきます。 つづりがわからなくて補完がないと文章やコードが書けない。 補完のおかげで生産性は上がり、効率も上がるのですが、地力が落ちてしまいます。どちらかというと地力を高めつつも生産性を上げるほうが最終的な作業効率も伸びてくるはずです。 楽をするというのは、“日々の作業は楽をする。しかし、脳の力もついでに鍛える。”というのを大事にしたい。

no_picture

cucumber で表示した画面がXMLを出力しているか確認する

rspec でマッチャーがあればよいのですが、とりあえず心当たりがなかったので、適当にごまかしました。良いgemがあれば紹介して欲しいです。 page.source が サーバからの出力を返してくださるので、これを Nokogiri で parse させてエラーがないかどうかで確認しました。 ならば /XMLを出力する/ do errros = Nokogiri::XML(page.source).errors expect(errors).to be_empty end どうせなら下記のように書きたいですね。 ならば /XMLを出力する/ do should render_xml end マッチャーを書いてみます。 RSpec::Matchers.define :render_xml do match do |actual| Nokogiri::XML(actual.source).errors.empty? end end ほとんどそのままです。matcher つくるのは難しくないので気軽に作りたいです。 少しだけ解説。 y cucumberの中では subject を省略した場合は page になります。なので、 ならば /XMLを出力する/ do page.should render_xml end と書いたのと等しいです。なので、acutual には page オブジェクトがバインドされていますので、そこから source を取り出してチェックします。page オブジェクトには html というメソッドが存在しますが、ブラウザが解釈したあとのDOMをdumpしたような感じになってるので期待通りの動きをしませんでした。

no_picture

ruby-2.0.0をビルドしてみた on rbenv

Ruby 2.0.0 preview1 の話題をちらほら見かけますし、 heroku さんが対応したらしいので遊びのプロジェクトで使おうと思いまして、buildしてみました。 私は rbenv を git clone でインストールしていて、ruby-buildも git clone しています。 この場合以下の操作でビルドできます。 $ cd ~/.rbenv $ git pull $ cd ~/.rbenv/plugins/ruby-build $ git pull $ rbenv install 2.0.0-preview1 $ rbenv global 2.0.0-preview1 $ ruby -v ruby 2.0.0dev (2012-11-01 trunk 37411) [x86_64-darwin12.2.0] git だと更新も楽チンですね。rails プロジェクトでも試してみたり、新機能を試してみたりしたいと思います。 新機能については 下記のサイトとかにちょろちょろあるみたいです。 http://el.jibun.atmarkit.co.jp/rails/2012/11/ruby-20-8256.html https://speakerdeck.com/a_matsuda/ruby-2-dot-0-on-rails 自分で試したら記事にしたいと思います。

no_picture

Railsによる開発にはzeusが新たな定番になりそう。

rails c や rake spec ってすごく時間がかかる。それをできるだけ早くするプロダクトはいままでにもいろいろありました。rails-shとかsporkとか。 そんな中zeusというのが最近登場したみたいです。gem install zeusu でインストール。Gemfileに書いてもいいそうですが、かかなくて良いようです。 あとは RAILS_ROOTで zeus init して zeus start しておけば、あとは別の端末で zeus c や zeusu sとして使うだけです。ファイルを変更すると認識して再読込します。zeus initした際にzeus.jsonが生成されます。 変更箇所に応じて必要なところからforkしなおすような挙動をしているように見えます(よくわかっていません) cucumberやrspecも認識して zeusu cucumber や zeusu spec というものも用意してくれます。 まだ使い込んでいませんが、イノベーションを感じるのでしばらく使ってみようと思います。

no_picture

Mac でPostgreSQL

railsアプリの一部を heroku にもっていこうとおもったので、「開発環境もPostgreSQLにすべきよね」と、思ったので 最初は Gentoo Prefix でインストールしたのですが起動方法がわからず。時間をかけたくなかったので、One Click Installerを使用したら Mac が起動できなくなりました。 というわけで、困っていたらPostgres.appというのがありました。9.1.3ですが heroku が提供してるものなので、herokuにデプロイする目的には最適なような気がしております。 はい、それだけです。

no_picture

travisを利用してみる

githubで公開してるリポジトリを継続的インテグレーションを行えるサービスとして travis というのがあるので、hiroshimarb-gemで利用してみることにした githubのアカウントがあればログインができるのでアカウントの作成は手軽でした。 リポジトリの指定 リポジトリを指定するにはプロフィールからいけばよいです。 いろいろでるので利用するリポジトリをONにすればよいみたいです。 travisの設定 .travis.yml用意する必要があります。 参考文献 Travis CI Getting started

no_picture

CentOSにJenkinsを入れてみた

ちょっと前に(だいぶ前?)にCentOSに Jenkins をインストールしてみた。その方法のメモ。 Jenkinsは継続的インテグレーションを行うためのツールで、 ビルドやテストの自動実行を行い、カバレッジなどの統計データを生成したりするツールです。大規模なプロジェクトになってくるとローカル環境ですべてのテストを実行するのが難しくなってきたりすると便利です。 具体的なインストール方法ですが sudo yum install java-1.6.0-openjdk sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key sudo yum install jenkins sudo cp -p /etc/sysconfig/jenkins /etc/sysconfig/jenkins.orig sudo /sbin/chkconfig jenkins on sudo /etc/init.d/jenkins start といった感じです。JREを何使えばよいのか迷いましたが openJDKにしてみました。 あとは デフォルトーでは ポート 8080 で動作するので、 http://localhost:8080 へアクセスしたりすればよいです。 /etc/sysconfig/jenkins をいじりたい場合(ポートを変えたいなど)に備えてコピーもしてあります。 Jenkinsに関連するデータは /var/lib/jenkins/ に配置されます。

no_picture

勢いでhiroshimarbというgemを作った。反省する気なんてあんまりない。

あらまし 広島Ruby勉強会で Hiroshima.rbでなにか gem を作りたいですよね。という話を前からちょくちょくしてたので、勢いで作成してみた。実際は反省している。 gemを公開するといっても、何か機能がないと寂しいので、 $ hiroshimarb open とすることで、Hiroshima.rbのウェブサイト を表示するようにしてみました。 インストール方法は $ gem install hiroshimarb リポジトリはgithubにあります。 gemの作成方法 せっかくなので gem の作成方法というか 本gemを作るにあたって作業内容を書いておきます。 プログラムの作成 まずはプログラムをかくためにプロジェクトの雛形を作ります。 gemを作りやすい構成になっていると都合がよいです。 Bundlerの機能を使うと良い感じの雛形がつくれます。 $ bundle gem hiroshimarb そうするると hiroshimarb ディレクトリができますので、READMEや hirosihmarb.gemspec をかきかえます。gemspecの情報をもとにgemが作成されます。summaryやhomepage、 descriptionを書きかえたりしましょう。もちろん hiroshimarb の部分は自分の都合の良い名前にします。 あとは適当にプログラムを作成します。 binディレクトリにコマンドを作っておけばコマンドとしてインストールされます。 ローカルでためす。 *.gemspecをもとにgem を作成するには $ gem build hiroshimarb.gemspec とします。そうすると hiroshimarb-0.0.1.gemのようなファイルが作成されます。 あとは $ gem install ./hiroshimarb-*.gem とすればインストールできます。 rubygems.orgで公開する。 $ gem install hiroshimarb で、インストール可能にするために rubygems.orgにgemを登録します。 まずは、sign upをしてアカウントを作成します。作成がおわったら $ gem push ./hiroshimarb.*.gem で送信することできます。 メールアドレスとパスワードを入力して終了です。

no_picture

database.ymlが.gitignoreに入っている環境でのcapistranoを使ったデプロイ

[2012-09-20日追記] 以下の記事の内容ですが、gemが用意されてました。 https://github.com/amfranz/capistrano_database_yml Railsプロジェクトで、ひとりで開発している場合は除いて、.gitignoreにconfig/database.ymlを追加することがよくよくあります。この場合、config/database.ymlをどこかのタイミングで作ってやらなければなりません。この対処法はこの記事で説明されてます。 概略 英語だったりするので簡単に説明をかいておきます。 前述の記事の作業を行うとcapコマンドにふたつのタスクが追加されます。 cap db:setup cap db:symlink db:setupはshared_pathにconfig/database.ymlに生成してくれます。すでにあると上書きされるので注意が必要です。 db:symlinkは db:setupで生成したconfig/database.ymlへsymlinkを貼ります。なので、#{shared_path}/config/database.yml手で編集しておけば良いということになります。 試したときに困ったことなど 記載されているコードをコピーして、capistrano_database.rbを作成するのですが、このファイルをどこに作成すべきなのか記述されていないので、lib上に作成しました。 libはLOAD_PATHが通ってないのに気付かなくて迷惑をかけました。 config/deploy.rbに require "capistrano_database"とするところをrequire "./lib/capistrano_database"として回避しました。 ところが、cucumberの実行時のオプションに--require libをつけているせいだと思いますが、cucumberの実行時に読み込まれてしまい不具合がでてしまったので、 Capistrano::Configuration.instance.load do .... end の部分を if instance = Capistrano::Configuration.instance instance.load do ... end end のように変更して回避しました。

no_picture

「私はRSpecでテストをこんな感じで書いてる」に少し便乗してみる

私はRSpecでテストをこんな感じで書いてるという良エントリがあったので少し便乗してみます。 まずは上記の記事を。 最終的なrspecについてですが、私の場合は以下のような感じにしてます。 といっても、前回もかいたように試行錯誤の毎日です。 # -*- coding: utf-8 -*- require_relative 'user' describe User do describe "#admin?" do subject { user.admin? } let(:user) { User.new(role: role) } context "管理者の場合" do let(:role) { 'admin' } it { should be_true } end context "一般ユーザの場合" do let(:role) { nil } it { should_not be_true } end end describe "#runnable_system?" do subject { user.runnable_system? } let(:user) { User.new(name: name) } context "管理者がリンディさんの場合" do let(:name) { 'Lindi' } before do user.stub!(admin?: true) end it { should be_true } end end end diffもつけておきます。 @@ -3,30 +3,34 @@ describe User do describe "#admin?" do + subject { user.admin?

no_picture

Railsでコントローラのスペックを試行錯誤中

Rspec書いてますか?最近なかなか荒れ気味ですが、僕はなんだかんだで嫌いじゃないです。 コントローラのテストは何をすべきかなかなか難しいです。 こんな感じでどうかなーというのを一応紹介しておきます。 何をテストするか 基本的には rspec を走られせるとこのコントローラが何をするのかわかるようにすることです。 どのアクションがどのHTTPメソッドを受けるのか どんな変数をビューに渡すのか リダイレクトするのか、しないのか どんなflashが設定されるのか 前提とする状況はなにか といったあたりがわかるようにしています。 どのアクションがどのHTTPメソッドを受けるのか これは単純にdescribeにかくだけですが、コード上ではlet式を利用して request という変数にバインドしてちょっとだけ目立つようにしています。 どんな変数をビューに渡すのか ビューに渡す値はインスタンス変数に入れますが、どの変数にどんな型の値が入るのかテストしています。 ビューを先にかくことが多いのでその際にpendingにして追加していくとコントローラかくときにビューの確認をする必要がありません。 あと、before_filterのようなものを利用しているの、その中で勝手にバインドするものがあるのでこれを明確にしてやったりします。 リダイレクトするのか、しないのか 対応するビューがあるのかないのか、うまくいくのどこの画面にいくのかが明確になるのでかいておきます。 どんなflashが設定されるのか これは変数の場合とだいたい一緒です。ビューではなく cucumber でのテストとの橋渡しな感じもあります。私はcucumberでは成功したらこの値が出てるのか確認してます。 前提とする状況はなにか ログインしている場合なのか、とかです。contextのブロックが増えるだけです。 それらを踏まえて上での雛形 コメントは解説のために。 describe HogeController do subject { request } describe "GET 'index'" do let(:request) { get :index, params } let(:params) { { hoge: "mogumogu"} } context "ログインしている時" do include_context "ログイン" # リダイレクトなどしない場合 it { should be_success } context "リクエストした時" do #

no_picture

Pryでエイリアスを作成する

pry便利ですね。 edit-methodをよくつかいます。 ファイル開くためだけに使うときもあります。 だんだん、edit-methodってかくのがめんどくさくなってきたので、em あたりで利用したくなってきたので、やりかたを調べました。 Pry.config.commands.alias_command "em", "edit-method" こんな感じらしいです。第1引数が作成するエイリアス。第2引数が元のコマンドです。 pryの起動時の読み込みファイルは~/.pryrcなので、そこにかいてやればOKです。

no_picture

ActiveRecordで今のスコープをそのまま返したい

あるオプションパラメータがあるかどうかで、条件が変わるような処理を書いてると、オプションがない場合、ActiveRecord::Relationが欲しくなるような場面があります。 例えば @articles = Article @articles = @articles.where(valid: true) if params[:valid] みたいな感じになっちゃって@articles = Articleって何?な状態になります。 メソッド化しようとするとさらに困るのですが、scopedを使うと以下のように書けるようです。 @articels = Article.scoped @articles = @articles.where(valid: true) if params[:valid] なんか異臭がしなくなりましたね。 だから、どうした?って思う方もいるかもしれませんがメソッド化すると、 def self.valid(is_valid = nil) scoped.where(valid: true) if is_valid scoped end となります。scopedなしで書かこうとするとちょっと困ります。 そんだけ。

no_picture

AngularJSで遊んだときのメモ

広島ウェブシステム開発勉強会で、AngularJSで遊んだのでそのメモ。 AngularJSってなんぞ Googleとコミュニティによって開発されているWebアプリケーション作成のためのフレームワークらしいです。Googleという名がでてくるように、保守性の高そうな設計がしてある印象を受けました。非常に使いやすかったです。 DOM操作が必要にならない工夫もしてある印象。 特徴としては、 規約をもちいた、ViewとModelの自動化と knockoutJSのようにモデルの変更を検知して自動的に画面が更新される mix-inのようにコントローラへ機能を追加でき、引数からオブジェクトをうけとることで、スコープの制限をしていること htmlに埋め込まれる式は Javascriptではなく、AngularJSのDSLでシェルのパイプのような流れるようなコードが記述できる コンポーネント化しやすい構造 なのかなぁ。印象ですが。スコープをうまく設計してあると思いました。 Angular 日本語の意味は角度っぽいです。由来が全然検討がつきません。 チュートリアルをひととおりやってみました。 http://docs.angularjs.org/tutorial/ github で公開されてるサンプルコードを追っていきます。 node.js は必須ではないです。Mac では pkg が用意されていて簡単にインストールできるのでいれてしまったほうが楽だと思います。 以下、 各章のメモです。 step ごとの diff をみながらすすめぬのがよさそうです。 見ている step を checkout してgit show などなど。 step0 bootstrap $ git checkout -f step-0 して $ scripts/web-server.js でサーバが起動する http://localhost:8000/app/index.html にアクセスすると Nothing here yet! と表示される。 ng-app 命令 <html ng-app> Angular Application のルート要素を指定する 二重の波括弧内に式がかける {{'hoge'}} かける式は Angular Expression であって JavaScriptではないらしい ng-appの指定したモジュールを DOMContentLoaded イベント時に自動で読込む

no_picture

Ruyb on Railsにて render を before_filterとかafter_filterで読んだら酷い目にあった

コントローラ内デいろんなところで同じrenderを書いてたのでリファクタリングしようと思った。 そんなわけで after_filter を利用して render を呼んでみましたが、actionの処理がすでに終了してるようで、 renderは一度呼んでるよ! って怒られました。 仕方なく before_filter で呼んだら、action内に入る前にレンダリングしてしまって、@hogehoge がnilやねーんって怒らました。 とりあえず、あきらめることにしました。

no_picture

nginxの最新版を Debian squeezeで

nginxはいままでソースからビルドしてたんですが、公式でパッケージ配布されてるのでいい加減aptでインストールできるようにしました。特に特殊なこともしてなかったですし。 gpgのキーが必要なので登録します。 wget http://nginx.org/keys/nginx_signing.key sudo apt-key add nginx_signing.key sources.listにsourceを追加します。 ``` bash /etc/apt/sources.list.d/nginx.list deb http://nginx.org/packages/debian/ squeeze nginx deb-src http://nginx.org/packages/debian/ squeeze nginx `/etc/apt/sources.list.d/`で設定する場合ファイル名の接尾語が.listである必要があります。 あとはupdateしてsafe-upgrade $ sudo aptitude update $ sudo aptitude safe-upgrade /etc/nginx/conf.d/に設定を移動して $ sudo /etc/init.d/nginx configtest でOKがでれば $ sudo /etc/init.d/nginx start ```

no_picture

ruby-debugからpryを起動する

Pry便利です。 スクリプト上で debugger をかいておくとそこでデバッガ(rdb)を起動できますが、debugger-pryをインストールしておくとpryコマンドが追加されてpryを起動できます。 Gemfileに書く場合は gem "debugger-pry", :require => "debugger/pry" 最近のRailsのGemfile {% gist 3051612 %}

no_picture

Rspecマッチャー rspec-html-matchersを試してみてる

Ruby on Railsで ViewやHelperの Specを書く際に利用するマッチャーに良いのがないか探してます。現在のRspecはcontainぐらいしかないので、細かくチェックしたい場合は若干使いづらいです。というわけで、rspec-html-matchersを試しています。 以前は rspec-tag_matchers を使用していたのですが、出力がちょっとイマイチでした。 Ruby Toolsでざらざらと探した結果、rspec-html-matchersを試してみることにしました。 Form用のマッチャーがいろいろあったり、内部に存在するタグをチェックしたりできるのが嬉しいですね。capybaraのhave_cssはsubject側で find(selector)しておく必要があるので、ややめんどくさいです。 いまのところの不満点は Hashで渡していくのがちょっと格好悪い 正規表現での属性チェックができなかった 暗黙的なsubjectを使用する場合、ブロックがあると不具合がでる 3番目なんですが、have_tag マッチャーにブロックを渡し場合 shouldメソッドのレシーバをかかないと、ブロック内へと処理が流れないようです。 subject { render } it do should have_tag("a") do # このブロック処理が走らない with_tag("b") end end のように書いてしまうと with_tag("b") の部分が動作しません。3行目を明示的に subject.shouldとすると動いてくれました。rspecの問題なのか、rspec-html-matchersの問題なのか切りわけが難しいのでとりあえず、我慢することにしました。 ブロックを渡さない場合は大丈夫です。 他は良好に使えています。 View Specの良い例が欲しいです。

no_picture

Xcodeのテンプレート

Xcodeが genarate する templateですが、 いつもかきかえる部分があるのでなんとかしたいなーっておもっててしらべたら http://akisute.com/2009/06/xcode.html にかかれているんですが、 /Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/ というディレクトリはすでにありません。 現在は /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/ あたりにあるようです。

no_picture

iOS24h Vol.1でCocoaPodsの紹介をした

iOS24hという ustream番組で午前3時にCocoaPodsについてしゃべりました。 CocoaPodsはObjective-C用のBunlderみたいなものです。 スライドを下記にあります。 http://eiel.github.com/iOS24h-vol1 impress.jsを使用してみたけどたいへん時間をつかったので次も使うか悩む…。 気合をいれて臨んだ割に人がいなかったかなー。 その他の資料は https://github.com/eiel/iOS24h-vol1

no_picture

gitx --all

skypeでgitの説明していたときに gitxa って何?と問われた。単なるgitx --all のエイリアスです。 alias gitxa="gitx -all" Gitx Mac用のgitクライアントツールにGitxというものがあるのですが、コミットの機能なども備えていますが、私はgitkコマンドの代替として利用しています。 ただし、Gitxをインストールしただけでは gitx コマンドは使用できません。Gitxのメニュー内のEnabble Terminal Usaeg… をクリックすることで利用できるようになります。 gitxを引数になにもなしで、呼びだした場合、checkout している branchを表示します。--allを使用するとall branchesを選択した状態になります。 他にもときどき便利なのは gitx ブランチ名 や gitx -- ファイル名 などがあります。gitkを使う場合はさらにいろいろできます。詳細は man gitk にて。

no_picture

funtooメモ grubの設定

funtooのメモ grubの設定は /etc/boot.conf を雛形に作成される。 変更後はboot-updateで /boot/grub.cfg を生成してくれます。 新しいkernelを /boot に配置したときも自動的に生成された印象があるんだけど、あれはどうなってんだろう。

no_picture

プログラムミングにおけるモナドと圏論との対応。

説明するわけではないです。メモです。 Kleisli圏 をキーワードに調べると気になるということがわかったのでメモしておきます。 その中で気になったもの tnomuraのブログのブログ - モナドのKleisli圏 関数型プログラマのためのモナド理論 はじめての圏論 その第1歩 単にHaskellをするのに圏論の理解は不要です。使うだけなら馴れるだけで十分だと思います。モナドの表現力がどのようなところまであるのか、そのあたりを知りたいのです。

no_picture

magit-brame-modeの表示がみやすかった件

共同作業ないし、自分が書いたコードでもここ変更したのいつだっけってことあるとgit blameを利用するんですが、emacs の magit についてる magit-brame-mode がみやすくて感動しました。 git blameがどのようなことをしてくれるのかは github でも特定のファイルを選択したときにもみることができます。 押すとこんな感じ。 すっきりみやすい。 端末で $ git blame conf/50-ruby.el するとこんな感じ。 文字ばっかり。 git-emacsの M-x git-blame-mode だとこんな感じ カラフル。細かい情報はミニバファにでます。そのまま編集できるのはナイスなのかもしれない。(重いですけど magitの M-x magit-blame-mode だとこんな感じ あれ、なんかみやすさが伝わない…。 80列におさまるのは嬉しいですね。 ゆっくりみる分には github が一番いんじゃないかということいわれてしまいそうです。

no_picture

iOSでFacebookAPIへのアクセス

最小限のサンプルを作成してみました。 FacebookのSDKいたれりつくせりでそれなりに簡単。 https://github.com/eiel/iOS-FacebookAPISapmle

no_picture

redmine-1.4系に更新してruby1.9で動かそうとしてはまったこと

mysqlがよめないっていわれた。 cannot load such file – mysql (MissingSourceFile) bundle installすると mysql2がはいるのであたりまえなんだけど、なんでかなー。 と考えた結果 config/database.ymlでadapterをmysqlにしてるからだ!と気づいてmysql2にかきかえました。

no_picture

gmailで未読メールの探し方

gmailで未読メールをさがすには、検索ボックスで、 is:unread と入力すれば未読メールだけを検索できます。 ラベルにずっと未読マークの(1)がついてて邪魔だなーっておもってたんですが、消すことができました。 検索ボックスの仕様ももうちょっと把握したいですね。

no_picture

Helmをインストールしてみた

anythingのフォークであるhelmを試してみた。 試した環境は GNU Emacs 24.0.94.1 (x86_64-apple-darwin11.3.0, NS apple-appkit-1138.32) of 2012-03-25 具合がわるくなってしまう設定 (set-file-name-coding-system 'utf-8-hfs) (setq local-coding-system 'utf-8-hfs) utf-8-hfsを設定してるとhelmのロードがおわらなくなった。何かを収集中に無限ループに落ちいる模様。anythingにできて、helmにできないことはまだまだたくさんあるので、しばらくanythingと共存させてみます。