Rubyちゃんこんにちわ

子育てエンジニアが綴る

2014 振り返り

GitHub 見れば大体一年何してたか分かるかなーと思ったけど、10月に入るまでほとんど草が生えてないので全然だった。 Qiita, blog も合わせてみてみたけど、とりあえず RubyKaigi 初参加したなーってくらいからの記憶しかない。 たぶん家作ってたりであんまり時間取れてなかったんだと思う。それが落ち着いてきたころの9月くらいからアウトプットが少しずつ増えてる感じですね。 RubyKaigi、m3hackathon、24pullrequests、Elixir Advent calendar 2014 ってのがアウトプットにつながる大きなイベントだったかな。 あと書籍書くのを目標にしたけど、まぁ全然でしたね。。。Qiita とかもう少し継続的にアウトプットできるようにするのが先決かなと。

GitHub

後半継続的な活動ができた。m3hackathon があったのと、24pullrequests のおかげですね。

m3hackathon でよかったのは細切れの時間でも、hackathon のようにアウトプットできることに気づけたことかな。何となく1日集まって、ガーっとやらないとモノができないイメージがあったのですが、その概念を壊してくれてかつ子育て中の自分にそれがあっていることが分かったのは大きな収穫だったかなと。

24pullrequests は今年は本気で 24 回目指そうと思って色々考えたので、結構カジュアルに PR できるようになってきた感じはある。それもあって自分で手伝えることがあれば積極的にしていきたいなと思えたのは良いことでした。その分ちょっと雑な感じの PR になっているかもですが。。

いくつか PR と個人的な project を取り上げてみる。

山の日対応ですね。ですがまだ新しいバージョンの 0.3.2 がリリースされていない。。 作者の方も忙しそうなので気長に待つかなー。まだ困るほど急いでいるわけじゃないので。

phoenix で作ったアプリを heroku に上げるときに色々失敗していたついでに見つけたバグの修正をした件。新しいこと挑戦していると色々躓いて、PR の機会も増えますね。

phoenix へ parameter filtering 機能を追加した件。比較的簡単そうに思えたので、ちょっとチャレンジしてみました。結果バグとかいくつかあって、私の知らない間に chris さんとかが修正入れてくれていた。たぶん v0.6.2 とかはバグのせいでリリースされているんじゃないかな。。。すみません。

Elixir のライブラリを hex.pm へ公開。Ruby 側で gem の公開とかしていない分、こちらで色々公開してました。

Rails 4.2.0.rc2 で migration_comments 動かなくなってたので、それを直した。たまたま Rails 4.2.0.beta4 から触ってたので見つけたという感じ。

mix hex.publish にも mix hex.docs と同じような気の利いたメッセージを出すようにした件。Elixir 周りは hex にも contribute できてよかった。

octoparts の ruby 向け client を作ろうと思って今作ってる途中のライブラリ。正月中に書ききりたい。

rubygems.org

何もリリースしてなかった。まだまだ a4nt が一番ダウンロードされているけど、breadcrumble が追いつきつつある。

Qiita

Qiita Organization に入れてもらえたのと、Qiita に書くと blog に書くより読まれるのが理由で、結構 Qiita に記事を書くようになった気がします。一方で英語によるアウトプットも大事なんじゃないかと思っている今日この頃です。。

何となくまとめてみると、Rails 関係がまぁ人気で top 5 までは全部 Rails、かつ以下の2つは特にストックされました。200 contribution に行ったのは、この2つのおかげですね。 Rails の rescue_from で拾えない例外を exceptions_app で処理する Rails 4 で assets に font を追加する方法

一方で個人的には以下の記事が一番オススメだったのですが、そんなに必要な情報ではなかった様子。Rails update するときに便利だと思うんだけどなぁ。 rake rails:update の diff を vim で見る方法

Elixir 周りだと以下が最高ストック数ですが、Go などに比べてしまうとまだまだ Elixir は始まった感じがないですねー。Go の一人勝ちも面白くないので、Elixir 続けると思いますけど。 Elixir 実装の Qiita API v2 Client を公開しました

Job

少し落ち着いてみれるようになった感じはあって、その分新しいことへのチャレンジもできていて嬉しい。一方で忙しさは増えていて、それが雑さに繋がっているかなという懸念もある。新しい方が入ってくれると嬉しいなぁ。 あと年末大掃除で一個アプリ減らせたのはよかった。Rails update する対象を減らせるだけでも助かる。

まとめ

今年はプライベートが忙し目だったのもあり、あまりアウトプットできなかった印象。でも後半結構取り戻せた感じはあり、それはよかったので継続していきたい。 来年は Elixir を production で使えたらなぁと朧げに考えている。使うことが目的になっても仕方ないけど、チャンスがあれば。

積ん読リスト 2014-09-25

全然消化していないのに、本だけ増えてしまっているので、一旦リストアップしておく。

RubyKaigi でも2冊本が増えてしまった。直前にこのリストを見ていれば。。。いや、買ったかもしれないけど。

RubyKaigi 2014 SEP 20 Day 3 日記

Ohayō Rails (おはよう Rails)

結婚式の準備でドタバタしてしまったので途中参加。

Speeding up Rails 4.2

初 RubyKaigi でアーロンさんの発表を生で見れて大満足。

Rack 2.0 の話とか、Rails の速度上げるためにどうしているかの話。あと話が上手。ちょいちょい笑いを挟んでくるし、日本人の文化も理解している。

https://github.com/tenderlove/the_metal

https://github.com/ko1/allocation_tracer

Practical meta-programming in Application

slide

メタプログラミングのお作法の話。どこかで似たような slide 見ていたのでしっかりと理解できた。

用事がありここで終わり

この日は初日に話しかけた人が偶然近くに居たのでその人としゃべったきり。やっぱりスーツで来ると話しかけたりされづらいですねー。

3日通してのまとめ

  • RubyKaigi に参加して輪が広がった。色んな人に話しかけてたので多少増えたかなと。

  • RubyKaigi に参加すると GitHub の星が増える。25% も増えたので凄い。実体は 8 -> 10 になっただけ。

  • ノベルティのデザインすごく好き。カッコいいのでネックストラップは普段使いすることにしました。

  • RubyKaigi 楽しい。また参加したい。

  • 次回は写真をもう少し撮れたらいいな、今回はこれだけだった

gacha

RubyKaigi 2014 SEP 19 Day 2 日記

Comming soon…

Ruby 3.0 ということで燃料投下。performance, 型あたりは最近確かに気になるところ。

Soft typing というのは初めて聞いた、必要なところだけでっていうのは確かに良さそう。仮にそれが便利であれば、型のない世界が淘汰されるだろうし、いまいちであれば元に戻れるしということで。それと誰かも書いていたけど、人間が苦労するのではなく機械側に任せるという方向性はやっぱりいいですね。

Extreme Makeover: Rubygems Edition

bundler, rubygems の速度改善するぞって話。だったと思う(予想以上に英語が聞き取れなく)。

bundler 凄くお世話になっているので、お礼を伝えにいくために顔、服装を必死に覚えてた。

お礼を言うだけじゃつまらないので、ジョーク gem の bundle-star 作ったよって話もしてみた。星が2つ増えた、またお礼をいいにいかないと(笑)

ジョーク gem でも作っておくと話のネタになるのでオススメ。

とてもいい人だったので、もっと何かしら話したかったが、残念ながら英語で話す力、アドリブ力が足りなすぎた。。。

Deep down fixtures

fixtures について詳しく知らなかったので聞きにきた。slide 構成とか練られていて、説明の次にコードが出てくるようになってて、英語でも結構理解できた。

色々知らないことあるのに、勧められたまま FactoryGirl 使ってる自分を発見できた。。。

Rails stack に居るべきというのは確かにその通りで、なるべく余計なものを覚えるようなことはしたくないですよね。

Going the Distance

git のように、typo したときに推測して、類似すると思われるコマンドを実行する仕組みについての話。

レーベンシュタイン距離について何となく学んだ。

英語は割と聞き取れるのだけど、内容が少し難しくて、rails migratoon の話が出てくるまでほとんど理解してなかった。逆にそこで一気にそれまでが理解できたけど。

MRuby as Development Platform for Payments

集中力がなくなってしまい、ちゃんと聞けなかった。。。せっかくかなり面白い話だったぽいのに。

The Twelve-factor Ruby 「Ruby を良くするための12のポイント」

柴田さん私の観測範囲で、すごく活躍されていて尊敬していたのだけど、発表内容を聞いたところ、それ以上にもっと活躍されていてほんと素晴らしかった。

が、引き続き集中力が途切れているのか 12 ポイントメモったつもりが、11個だったりで何だかなという。。。

今まで個人的に色んな箇所で教わってきたバグレポートの良い作法がまとまっていた感じの発表でした。

Scalable deployments - How we deploy Rails app to 100+ hosts in a minute

ssh 遅いので、mamiya という独自ツール作ったという話。100 台超えるホストに対して数十秒でデプロイ完了するのは、圧倒的な感じだった。

だからといって私の環境で導入するかというと、そこまで必要なくて capistrano でいいんですよね。試してみたい気持ちもありつつ、悩ましい。

Resource Control Architecture scripting with mruby for a Web Server Separating Computer Resources Virtually at Each HTTP Request

mruby 関連で有名な方の発表ということで来てみた。インフラ周り詳しくないけれど、apache 経由でも動的に処理変更したりおもしろそうだった。mod_mruby/ngx_mruby がホスティング大手さんで数社使われているってのも説得力あって導入障壁下がりそうだ。

ServerEngine: a framework for multiprocess servers in Ruby

slide

Elixir, Erlang とかで聞いたことのある内容が多くあった。Supervisor はまさに Erlang OTP な感じだったし、Erlang とかでやると実装楽なのかなとも思ったり。Erlang 書いたことないけど。

ServerEngine がこれからどうやって使われていくかは興味があって、というのも Elixir 適用する領域ってたぶん似ているから。Elixir 何に導入するといいのかなってのは最近いつも考えてる。

https://github.com/fluent/serverengine

あと sigdump 便利そう。

https://github.com/frsyuki/sigdump

Power Assert in Ruby

参加できなかった。。。orz

LT

途中の記憶がない。。。寝てないはずだが。。。

[JA] Practical factory_girl

slide

内容が良かった。後で slide みる。

[EN] Native Libs and Gems on Heroku with Hammer

英語力が足りなかった。。

[JA] ofruby - Ruby running on the iPhone

ofruby すげー

[JA] Keep Freedom on Ruby - A magical world, ‘Diversity’

バランスって難しい。行き過ぎると ruby でも詰まらなくなるし、かといって色々自由過ぎるとツラいという。

[JA] 10th anniversary of Rubyist Magazine

コント。笹田さんコメントがじわじわ来る。

[EN] Invitation for v1.0.0

version 1.0.0 のススメ的な内容。自分のやつもアップデートしなきゃー、と思ってたら、 大体なってた。。。何か自分でも似たようなことを考えていたのかも。

[JA] How the RSpec team and I built the smooth upgrade process for RSpec 3

Transpec は私の中で今年一番の gem なので、LT 後に感謝をお伝えしにいきました。発表内容も論理的で頭にすっと入ってくる感じがよかった。

https://github.com/yujinakayama/transpec

まとめ

2日目もそこそこ知らない方と話すことができた。何故か私の話した人の中には SNS ゲーム系の人が多かった。あと名古屋で仕事している方も多かった。

海外から来ている人に話かけることができたのも個人的にはよかった。というのも、RubyKaigi のためだけではないけど、通勤とかの時間を使って英語の speaking を何度も繰り返し聞いていてそれの効果を知りたかったから。結果としてリスニングには多少効果があることは分かったけど、会話したりというレベルになるにはもう一歩進める必要がありそう。とはいえもっと場数踏まないとものにはならないから、このレベルでもいいかなとも思った。

それと話かけるとき Can i talk to you? さえ覚えておけば良さそう。そっからはどうにかなる(しなければならない。。。)。

RubyKaigi 2014 SEP 18 Day 1 日記

はじめに

初めての RubyKaigi で、今まで行きたいと思いつつずっと行けてなかったのでとても楽しみにしていました。

Rubyist の誰かが人に話かけた方がよいと言ってのを覚えていたので、知り合いの方はなるべく話かけず(今思うと失礼だったかも。。。)、偶然近くに座った人、発表者の方、ライブラリなどでお世話になっている方に声をかけてみました。

急に話し下手に話しかけられて困った人もいるかもしれないですが、色んな世界あるなと知れたので声かけてみて正解でした。

それと最初は個人で行こうと考えていたのですが、会社の方で業務として参加可能ということだったので、業務日として参加させていただきました。特にレポートの強制もなしで、金銭的な補助もそこそこ出るので、制度としては結構良いのではないでしょうか?興味があればお声がけください。

以下自分の参加したセッションの自分用メモ。何かもうすでに色々忘れているので、当日書くってのは結構大事ですね。。。

CRuby Committers Who’s Who in 2014

Ruby comitter の紹介セッション。登壇する人をセレクトしてくれたので、どのセッションを見に行くかとても参考になりました。

Build-up Ruby interepreter - What is easy and what is difficult? -

trade off の話はソフトウェア開発では多くありますが、trade off を超えるという言葉はインパクト大きかったです。

performance について(特に parallel かな)、C Extension の話があったりして中々難しそうでした。

lunch

SNS Game 開発している方、アルバイトでコード書いている学生の方と軽く話しました。

Controller Testing: You’re Doing It Wrong

命令的でなく、宣言的にコントローラを書こうという話。

テストはどうするのかというと shared examples を上手く使って、宣言っぽく書けるという感じだった。 納得したつもりだったのだけど、今忘れているのでスライドを後で見たい。

個人的な感想で言えば、Growing rails application と思想が似ているかなと思った。あまりコントローラで命令的なことをしないという意味で。

Eliminating Giant VM Lock in Ruby through Hardware Transactional Memory

最近 STM(Software Transactional Memory) というワードを Haskell 業務で使っている人に聞いていたので、Transactional Memory 関係のセッションということで行ってみた。

CPU のキャッシュサイズ考慮が必要だったり性能出すためには結構難しそうに感じた。

あとセッション聞いていて思ったけど、発表者の方は確実に Ruby をより良くできる実力のある人だと感じた。

Cores unleashed Part II: Introduction to GobiesVM (and Software Transactional Memory)

Golang で書かれた ruby vm 実装とのこと。一つ前のセッションと違って、CRuby とは完全に別実装なので比較は難しい。

https://github.com/brucehsu/GobiesVM

Coffee break

無限コーヒーうまー

Non-Linear Pattern Matching against Unfree Data Types in Ruby (Egison Pattern Matching in Ruby)

Egison 言語のパターンマッチを Ruby に持ってきた話。

https://github.com/egison/egison-ruby

そして途中から Egison の紹介(笑)。Egison 自体は昔に Lightweight Language 系イベントの LT で見たことがあり、そこから続けていることが素晴らしい。Rakuten さん Egison の仕事もできるとか凄いわ。

Hypermedia: the Missing Element to Building Adaptable Web APIs in Rails

slide

プレゼンが上手い。上手すぎる。

Hypermedia な API を作る方法の紹介。途中に何故 microdata なんか出てくるのかなーと思っていたら、そこに自作 gem hypermicrodata です。どーん!って感じで紹介して、そっから API とし て必要なもの取ってくるのねーという感じでした。

https://github.com/tkawa/hypermicrodata

この日は Cookpad も garage をリリースしていたり、Hypermedia な感じが来てますね。

https://github.com/cookpad/garage

“Gem of this Week” - building culture and making gem

Drecom さんの話。geminabox 使っているとのこと。うちは GitLab です。

間違って rubygems にリリースしないように、独自の gem 作成ツール作ってて良さそうだった。

他にも小さなことでも gem 化して、共通化しているのが印象的でした。どれくらいのサイズなら作るか迷うところだけど、プロジェクト多いと十分ペイしそう。

Ruby committers vs the World

少しグダグダ感あったけど、色々有意義な話が聞けた。

Party!!!

偶然近くにいた方と話したり、Elixir 仲間の方を見つけて Elixir どこに使うといいんですかねーみたいな話をしてました。

最後に

初 RubyKaigi 充実してました!!一参加者であっても結構疲れたので運営の人は想像つかないくらい疲れているだろうなと思いました。本当にお疲れさまです。おかげさまで楽しく参加することが できました。

Growing Rails Applications in Practice を読んだメモ

よりよい Rails の書き方ってどんなのかなーというのはいつも模索していて、比較的安かったのと、ページ数が少なかったので読み切れそうという判断で買った。 “Gems increase the cost of upgrades” なんていう章があったのも購入の決め手。

Growing Rails Applications in Practice

精読はできていない。他に読みたいのもあるので、早く読み終えるためにも、細かいところは飛ばし読み。

本の概要

本の主張としては大きなアプリになっても複雑度を上げないために、コードをどうしていくべきかということが書いてある。コードは Rails の既存資産を生かした方法。すなわち Rails を知っている人が新たな知識必要なしに理解できるコードにしていこうという方針。

こんな gem を使えば楽になるとか良く聞いたりするけど、そういったものはその gem のための新しいルールを覚える必要があったりなので、そういった方針は取らない。 と思ったら active_type なんてのが出てきた。。。でも出てくるのはこれくらいだし、必ず使ってという訳ではない。

コードはなるべく model に寄せて、太ってしまった model からは、継承、service object に切り出してダイエットしましょうというのが大まかな流れ。

個人的に気になった/参考になった点

コードの理解を容易にするため統一した方法にする

Rails の scaffold で出力されるようなコードになるべく寄せましょうという感じ(本書の中では scaffold で生成されるコードをもう少しカスタムしていました)。そうすることで後からプロジェクト入った人も既存の Rails 知識で何となく分かる。

そのため例えば Form オブジェクト(table なしのモデル)でも、以下のように save メソッドを controller で使う。

1
2
3
4
5
6
7
def create
  if @sign_in.save # @sign_in が Form オブジェクト
    # success
  else
    # fail
  end
end

Form オブジェクトが#saveって凄い違和感なのですが、まー大規模なアプリで統一させるとなるとこれくらいやる方がいいかもですね。 個人的にはそこまで大規模なアプリ書いてないのと、違和感あるのでこれは参考程度だなと思う反面、現場のアプリは実装時期や人によって controller の書き方が異なっていたりで、上手いこと中間点見つけたい気はしている。

BEM

CSS の設計手法に BEM(Block, Element, Modifier) というのがあって、それについて章という単位では一番多くのページを割いて説明されていました。 BEM について、どういうものか理解したのはこの本が初めてだったので参考になった。 ただ、CSS も副作用で色々壊れるってのは分かるのだけど、あえてこの本に載せなくてもいいんじゃないかなーという気がしないでもない。

いまどきのCSS – OOCSSとかBEMとかSMACSSとか

BEM 以外にも何かあるんですね。

役割の列挙と分割

どの章か忘れてしまったのだけど、複雑な処理をしている model(controller だったかな?) の役割を列挙していて、基本に立ち返るのは重要だなと思った。

この本を買った目的の一つでもあるのだけど、今複雑になってしまっているアプリを改善したいなという思いがある。でもそれって自分が無意識に銀の弾丸探しちゃってるんじゃないのって、その章を読んでふと気づいた。そんなものを探すよりは、複雑になっている処理を理解して、役割を列挙していって分割すればいいだけなんじゃないかと。

ということで次は隙を見て役割列挙と分割をしてみることにする。

その他

Rails のアップグレード、gem の選定方法、test の章とかは大体そーだねーという感想。

所感

今書いているアプリのコードを良くさせるヒントは得れたかなという感想。 本自体はもう少しコードあるといいかな。最近だと書籍内のコードを github で公開している本なんてのも多いので。

全体的に読みやすい感じだし、ページ数短いのでサラッと読むのにいいかなと。 はー、ページ数多い本どうやって消化していこうかな。

2014 年の抱負

いつもはぼんやりと考えるだけで忘れるだけなので今年は書いてみる。 今ぼんやり考えているのは、OSS 活動の継続、新しく学ぶ言語は Elixir 、本を書くの3本です。 前者2つは想像つくので、最後の本を書くことについて少しだけ書きます。

本を書いてみる

去年は個人的に電子書籍元年で、消化のために iPad mini を購入してからは、ほとんどの書籍を電子で読んでいました。電子書籍の面白い点として、個人出版物のようなものを購入しやすいです。そういった書籍って結構マイナー層に向けて書かれているので、ちょうどよくその層にヒットしてたりすると普通に面白いんですね。しかもページ数も比較的少ないので、割と読み切れる。

そういった読書体験をしていて、少しだけ気づいたことがあるのですが、これって blog とかの延長、それもちょっとした延長なのかなーって。例えば blog だったりで特定の技術について日々書いていって、それをまとめればマイナー層向けの本が完成しちゃうんじゃないか?と。実際購入してみた本を読んでみると、特定技術によったものとか普通にあって、Web のまとめ記事を読んでいるような感覚になることも多かったです。それに更新されることも多いので、ますます Web っぽい。

ということで、自分にももしかしたら1ミリくらいは可能性あるかも?と思ったので、本を書いてみるという少しアグレッシブな目標にした次第です。あと知り合いの方が昨年に本を執筆していたり、その影響もありますかね。もともと本を書いてみたいという夢もありました(実現するとなると、想像してたよりかなり早いですが)。

ちなみに上のような気付きを得ることになった本達をリストアップしておきますね。これらの素晴らしい書籍を取り上げて自分でもできそうっていうのはおこがましいですが、そもそも blog すら続いてない(^^;

最後に

子育ても忙しくなるかもしれないですし、MH の新しいのが出ればそれをやらなければならないので、未知数な感じではあるのですが、出来たら面白そうなので達成したい。

2013年これ買って本当によかったものベスト3

今年買ってよかったものベスト3を紹介します。

第3位 iPad mini

初代の方を買いましたが、電子書籍用なので普通に便利です。電子書籍読むのがかなり捗ります。32GB を買ったのですが、今のところ 16GB で全然十分ですね。

第2位 MG シナンジュ

格好良すぎです。説明書みるだけでも買いですね。まだ作っていないです。

第1位 ランボルギーニ・アヴェンタドール

カッコいいですね。子供受けも抜群ですし、大人もハマりますよ。最高です。

来年もいいものが買えるといいですね。ネタにお付き合いくださりありがとうございました。

See Also

http://oreno-memo.hatenablog.com/entry/2013/12/10/165706

2013 年自分まとめ

2013年は結構アウトプットを意識したので、せっかくだから自分用にまとめて整理する。

GitHub

Pull Request(PR)することで OSS 活動したいという目標。これは自分が持っているものでも何かしら役に立ったら面白いなーという思いと、自分の貢献したプロジェクト使ってくれてたら嬉しいっていう自己満足のため。

Rails に最低10個くらい PR するという目標もあったのですが、これは結局4つでした(merged は3つ)。10個の根拠は月1で Rails のあら探しすればいけるだろってのと、2ヶ月くらいはグダグダする月もあるだろっていう目算から。Rails へ10個は無理でしたが、PR に慣れたおかげで、色々なプロジェクトに PR できたので、OSS 活動したいという目標としてはそこそこ達成したかなという感じです。

PR したプロジェクト: Rails, Elixir, rspec-kickstarter, ruby-style-guide

https://github.com/ma2gedev

Rubygems

OSS 活動したいということで、gem も色々と公開しました。 目標とかは特になくて、作りたいから作るでした。breadcrumble 以外は今年作ったらしい。

リストを見た感じでは、仕事で楽したい、何でもいいから作りたい、OSS 貢献したいという分類に分かれてます。

OSS 貢献したいっていう目的で作ったのは bundle-star です。GitHub でお世話になっているプロジェクトにスターが増えるといいなという理由で作ってみました。よければ使ってみてください。使わなくてもスターつけるのだけは忘れないでください。

っていうか一個知らない gem が公開されている。酔って帰って寝て起きたら公開されていた感じがある。。。何これひどい。。。

もう一つ余談ですが a4nt は何故か一番DLされているのですが、これ多分嘘です。実際のところそんなに使い道ないはずなので。なんか自動DL系のスクリプト作った人が間違えたのかなと、名前順だとかなり上の方に位置するので。。。

https://rubygems.org/profiles/ma2ge

Speaker Deck

Speaker Deck のプロフィールページの9マスを埋めるのが目標でした。最初から空欄で9個並べられていたので、じゃこれを埋めようという何となくな理由です。で、これは何とか達成。 最初の動機は Rubyist な方々の Cool なスライドをみて、そういうの作りたいなーという不純な感じだったと思う。こういうのとかこういうの

達成するためには発表する場もないといけないので、そういう意味で自社の M3 Tech Talk が頻繁に開催されていたのは助けられたなーという感じ。 後半は単に目標達成したいがために質の悪いスライドもあるので、来年は少し質を意識したい(意識しすぎて公開しないとならない程度に)。

https://speakerdeck.com/ma2gedev

Blog & Qiita

本当は willnet さんのように、OSS 関連の情報をブログ公開することをしたかったのだけど、あまりマメじゃない自分にはできなかったですね。ということで、いつもお世話になりっぱなしですよ。ググるとき「rails willnet 調べたいワード」みたいになってるし。

一方で発表したりはできたので、話したりするの苦手なわりに意外と発表好きなのかもしれないという発見も。 それと Blog 更新できないといいつつ、Elixir Advent Calendar に参加して Qiita を積極的に使ってみたら意外と書けたという発見もありました。 Web 上ですぐに Markdown でプレビュー見つつ書けるってのは楽でいいですね。ブログは Octopress 使っているので、なんだかんだ手間が多いです。

話は少しそれますが Advent Calendar は来年も何かしら参加したいですね。記事追加しなければならないという制約もあって色々学べました。新しい言語を比較的しっかりやるのは Haskell 以来でしたが、新しく学ぶのはやっぱ楽しいです。しばらく Elixir ブームは続きそうな感じです。

しばらくは Qiita でアウトプットするかなー。

Job

振り返ってみると色々なことやらせてもらってました。Rails アプリをいくつも作ったり、Web API Client 作ったりと昔だったら考えられないなーという気がしなくもない。でも作るだけってのは簡単なことで、結局はメンテだったり機能追加だったりが大変です。レガシーアプリメンテとかツラいですよね。あとレガシーほどじゃないけど、Rails アプリのバージョンアップとか。まぁ、人生普通に生きてたらツラくないことなんてないので、それくらい平気ですよ。 ということでメンテなどの運用を楽にするとかっていう視点をもっと意識して開発したいですね。例えばアプリ減らすとかね。

それと弊社でも人材募集中のようなので、こちらなどみて興味がありましたら是非。 結構尖った人が多いです。SEO マスターな人がいたり、Ansible Tutorial 書いている人がいたり、Web Application Framework 作ってる人がいたりで個人的には結構面白いなーと思いますし、いつもお世話になってばかりです。なんか広告っぽくなってしまった。。。

まとめ

この他にも GitHub の Your Contribution をせめて1週間に1つ緑色にするという目標もあったのですが、MH4 が出てしまったので仕方ないですね。正直なところ子供育てながらだとかなり難しいです。同僚の @seratch さんとか寝てないとしか思えない。

とりあえず書いてみたけど、あまり次の目標につながりそうなものが出てこない。もう少し大きな目標とか立てたいと思っているんだけど、その場その場でやっていく方が自分にあっているのかもしれない。 引き続きトライしたいことは、アウトプット重視。それと人生結構あっという間なので、色々気にしてやらないよりは、とりあえずやってみるということですかね。

子育てエンジニアのための時間確保術-夜泣き編

今日は普段と趣向を変えて、子育て中の時間確保について。

子育て中は本当に時間ないです。今実感しているので、これは本当です。

エンジニアって新しい技術に挑戦したり、学んだりってことをしたいじゃないですか?でも、それも中々できない状況になるのでツラいものがありますよね。

さらにキツいのは夜泣き。一人目の子が夜泣きが激しくて、時間確保どころか削られる毎日だったのを思い出します。

夜泣き対策

夜泣きをそのままにしないこと。

自分の場合ですが、夜泣きって自然と治まるとか良く言われていたので、対処療法でごまかしながら日々我慢してきました。

ですが、よくよく考えたらもう少し対策なりするように動けたのではないかなと今は思っています。

というか偶然この本を読んでそう思わされました。

本の中身は夜泣きへの対処方法が、理論、実践それぞれ書いてあります。結構なるほどと思うことが多く、早速実践しています。

本の中で夜泣きごとという言葉が出てくるのですが、大人でいうところの寝言代わりに、赤ちゃんは泣いてしまうこともあるそうです。それを赤ちゃんが何か要求してると勘違いして抱っこして、逆に覚醒させてしまったりという話も出てくるのですが、まぁ心当たりのあることあること。

もう少しこの本に早く会っていれば、我慢せずに上手くできて、よい時間の使い方もできたのかなと思っているところです。

普段技術のことではすぐ本を買ったりして解決しようとするのに、何故子育てにそれを適用しなかったのかと後悔してもいるのですが。。。単にその余裕すらなかったような気もします。

まだ本に書いてあることが効果があったっていう話ではないのですが、解決しようという姿勢を持てたのは良かったなと思ったので記事にしてみました。

終わり

夜泣き編とか書きましたが、それ以外に特にxx編は考えてないですし、そもそも時間確保術?って感じになっちゃったし、続かない予定です。