Hatena::ブログ(Diary)

プログラミングお勉強記録 RSSフィード Twitter

2016-12-02

わたしとRails Girls

これはRails Girls Japan Advent Calendar 2016 の2日目の記事です。
1日目はattsumiさんでした
Tokyo 7th 開催予告がされていましたね!すごく楽しみです。

思い出話をします

こんにちは、katorie といいます。
私は Rails Girls Tokyo 2nd の卒業生です。
Tokyo 2nd は 2013年3月1・2日に開催されたので、もう3年と9ヶ月も前の話です。
#railsgirlstokyo RailsGirlsTokyo 2nd に参加しました - プログラミングお勉強記録

私の人生は、Rails Girls に参加したことで大きく方向転換しました。
この話は、たまにどこかで話していたことなのでご存知の方もいらっしゃいますが、あらためてブログに残しておきたいと思います。
(Advent Calendar の2日目にふさわしい内容なのかはさておき)

現在の話をすると、2015年1月より株式会社ユビレジソフトウェアエンジニアとして所属しています。(正確には出産を控えており、休職中)
その前は6年9ヶ月ほど、医療機器メーカーで事務をしていました。

それでは、私の思い出話におつきあいください。

参加する前

上述のとおり、私は医療機器メーカーで外回りをしている営業さんたちのサポート業務をしていました。
10名くらいいた本社の営業さんたちのスケジュールを把握したり、電話連絡を取り次いだり、展示会や勉強会という名の営業活動の準備(資料やお弁当など)をしたり、まぁ、何でも屋さんでした。
使用するツールは電話と、メールと、Microsoft Office。
属人的な仕事が多かったことに不満をもっていました。

あるとき、毎朝手作業で行っていたスケジュール表の作成や営業さんへ送信するメール作成に嫌気が差し、どうにかならんものかと思っていたところ、
自分でプログラムを組んで自動化するという魔法のような解決策があることを知りました。

いろいろググってプログラミング言語が複数存在することを知りましたが、最初に読んだ本がこれだったので、はじめて書いた言語は Ruby でした。

初めてのプログラミング 第2版

初めてのプログラミング 第2版



やがて Ruby を書くことをお仕事にしている方々がいることを知り、Twitter で生態研究をしているうちに、Rails Girls の存在を知りました。
ひとりで書籍と格闘していた私は、仲間ができることを期待して、参加することにしました。
たしか応募動機とかに「さみしいので仲間がほしい」とか書いた気がします。

当日の出会い

Rails Girls の内容としては(各回それぞれ若干違いはあるかもしれませんが)、
初日の夜にインストール・デイがあって環境構築をして、翌日はグループに分かれてチュートリアルに挑戦します。
このグループ分けは事前にオーガナイザーが済ませていて、事前アンケートから知り得るだいたいの経験値や当日使用するOSなどで分かれていたようです。

初めて触れる「プログラマの世界」にドキドキしながら、指定されたグループの席に着きました。
私の参加したグループは、Girls 4人に対し、コーチが2人ついていて、「無料のイベントなのに手厚いなー」と思ったのを覚えています。
その時のコーチが @a_matsuda さん 、そして一緒のグループに @Yuryu さん がいました。

他のグループのコーチたちもそうそうたるメンバーだし、途中、@_ko1 さん による解説(たしかローカル変数とインスタンス変数についてだった気がする)もあったりして、すごい豪華な一日だったのですが、正直言うと当時はそこまで凄さがわかっていなく、「皆さんやさしくわかるまで教えてくれるとても優しい人たち」くらいの認識でした。すみません。
あるいはそれまで生態研究をしていたアカウントの皆様の実在確認をしていたというか…すみません、すみません。

その後

そんな豪華な出会いがあったわけですが、私としては当時この Rails Girls で実在確認をしたアカウントの皆様だけが「私の知っている Rubyist」でしたので、
皆様の発信する情報だけを頼りに、大江戸Ruby会議や RubyKaigi などに参加していました。

少しずつ慣れてきて、いろんな勉強会やmeetupに参加できるようになり、いくつか大変お世話になったコミュニティがあります。
そのひとつが、Rails Girls, more! という卒業生(と本編に参加できなかった方)のための勉強会
右も左もわからない、けど作りたいものはある、みたいな私のような困った人を、毎回コーチが一人ついて丁寧に教えてくださいました。
(現在の活動については Facebook グループで確認いただくとよさそう)

それから、同じく Rails Girls Tokyo 2nd の卒業生 @yucao24hours さんオーガナイザーのよちよち.rb。
そして「実際にプロダクションとして動いているコードを見てみたい!」という動機で参加させていただいた、合同会社フィヨルドさんインターンシップ

他にもたくさんの方々にお世話になりながらプログラミングを続けていくうちに、現在所属しているユビレジを知りました。
@Yuryu さんに誘われて参加した GitHub Drinkup で、 @a_matsuda さんが @soutaro さんを紹介してくださったのです。
(実際にユビレジに入社することになったのは、この Drinkup のずーっと後でしたが)

どうしてプログラマになりたいと思ったのか

プログラミングを始めたきっかけは、「めんどくさいことを一瞬で終わらせてくれる魔法をもっと使えるようになりたい」という気持ちでした。
営業事務の仕事を楽にしたい、それだけだったのですが、そのためにいろんな勉強会に参加しているうちに、すっかり Rubyコミュニティ のとりこになった私は、いつの間にか「Rubyist と仕事したい」「Rubyist として仕事したい」と思うようになったのでした。
実務経験が全くないのにユビレジに入社することが決まった時には夢を見ているのかと思いました。

これからのこと

私は Rails Girls をきっかけにプログラマという道がひらけましたが、他にもこの素晴らしいイベントが何かのきっかけとなった方々はたくさんいらしゃると思います。
そんな方々の想いがつながって、今後もこの素敵な機会が続いていくことを願います。
5th でコーチも経験したのですが、またコーチ、スタッフとしても関わっていきたいと思います。

2016-03-22

よちよち.rb 第111回 #yochiyochirb

ちょっと間があいてしまったのですが、思い出しながら参加記録をつけます。

最近のよちよち.rbは、Railsをつかったチーム開発をしています。
2年前くらいに有志で作成したアプリ「Kajaeru」の開発です。

ミートアップではissueからひとつ選んで、エクストリームフィッシュボール形式で開発を進める、という流れ。
この日はこちらのissueに取り組みました。

bootstrapをいれたことでヘッダーにサインイン状態などが表示されるようになったのですが、
依然としてbodyにサインイン名(サインインしていればサインアウトへのリンク)やそれに関連するメッセージが表示されたままでした。
というわけで重複している項目を削除していく、というのが主な作業となります。

実装しはじめたとき、視点が「サインアウトへのリンク」にいってしまったため、
ブランチ名が delete-signout-link となっていたのですが、よくよく見るとサインアウトへのリンク以外にも削除するべきところはありそう。
なのでブランチ名はひとまず置いておいて、「このissueに対応するブランチ」として作業をすすめて、
ひとつのプルリクエストとして完了させたほうがいいということになりました。

こういうことっておそらく実際の業務の中でもあって(少なくとも私は)
ひとつの問題を修正するときに、いきなり思いつくところから作業にはいると、
途中で「あーもっとこうするべきだったー」と思い直して手戻りしたりするので、
ゴールとそこにたどり着くまでの道筋を立ててから作業に入ると、
ブランチ名のつけ方やコミットの粒度などに困らないのだろうなぁと思います。

いい勉強になりました。

2016-03-01

よちよち.hs 第3回 #yochiyochihs

いつからか気になっていたHaskell、なかなか手を出せずにいたのですが、
よちよち.rb 主催者の @yucao24hours さんがHaskellに挑戦しているということで、便乗させてもらいました。

すごいHaskellたのしく学ぼう!

すごいHaskellたのしく学ぼう!



こちらの本を読み進めていきます。

実は、ミートアップに参加できるかどうか直前まで悩んでいて、結局当日の朝になって慌てて準備をした…という体たらく。
どうにか実行環境を作って本をざーっと読んで行きましたが、当然ついていくのが大変でした。反省。

プログラミング言語でいえば、Rubyしかやったことない(あとちょっとだけJavaScriptとかVBA)人がHaskellをやるとどうなるのでしょうか。

遅延評価」とは


Haskell は怠け者です。特にそうしろと言われた場合を除いては、結果が必要になるまで関数を実行しないのです。この振る舞いは、専門用語では遅延評価といいます。


と本にありますが、なんだか抽象的でよくわかりません。
これは、こういうことのようです。

def func(x, y)
  if x > 0
    x + 1
  else
    y + 1
  end
end

a = 10
func(1, a + 3)  #=> 2

上記のようなとき、funcの第二引数にあるような ( a + 3 ) の部分は、本当に必要になるまで評価されないということのようです。
ふむ。

「型クラス」とは

関数を定義するときに型も書くんですね。
型を意識して書くというのが新鮮。
そういえばVBAでも変数を宣言するときに型も一緒に書いていたっけ。。
しかしまだまだイメージできません。理解できていない。
型、あるらしい。くらい。

本では「型クラス初級講座」(27ページ)ということで、いろんな型の紹介がはじまったところです。

Hello World したかった

この日ほんとにはじめてHaskellを触ったので、ひとまずHello Worldをしたいなって思ったのですが、
この本でHello Worldできるのは第8章のようです。

そこでHaskell先生から教わったExampleから写経してHello Worldしてみました!

ひとまず初日はここまで!

2016-02-16

よちよち.rb 第107回 #yochiyochirb

今週は、よちよちで「どう書く?」をやりました。
お題は「ケブンッリジ関数」!
40分くらい各自実装する時間を設けて、最後みんなのを眺めたりしました。

私はお題の内容を勘違いしていて、なんか単語をひとつ、中だけシャッフルすればいいと思ってしまっていて、文章に対応していませんでした。。
標準出力から単語を受け取って、ケブンッリジして標準出力するというのを書きました。

# 単語ひとつにしか対応していません!

puts '単語をひとつ、どうぞ↓'
word = gets.chomp

if word.size >= 4
  splited = word.split('')
  completed = splited[0] + splited[1...-1].shuffle.join + splited[-1]
  puts completed
else
  puts '4文字以上じゃないと!'
end

splitのところとか、shuffleのところは他の書き方も試しながら、なんとなく読みやすいコードを心がけてみた。

で、文章に対応した。

def text(sentence)
  words = sentence.split(' ')
  cambridge = words.map do |word|
    if word.size >= 4
      splited = word.split('')
      splited[0] + splited[1...-1].shuffle.join + splited[-1]
    else
      word
    end
  end
  p cambridge.join(' ')
end

はい。

ゆかおさんとかとみーとか、テストから書いてて勉強になった。
(ランダムであることをテストするのむずかしい!!)
おがさわらさんはシャレがきいてた。
わかすぎ先生はかっこよすぎた。

コード書くミートアップは楽しいですね!

2016-02-09

Sendagaya.rb #136 #sendagayarb

今週、ちょっと浮気をしてSendagaya.rbに参加しました。
メタプログラミングRuby 第2版」を読んでいるということで気になっていたのです。



読んで追いついてから参加しようかなと思っていたのですが、いつになるかわからないので、とりあえず参加してみました。

15分くらい各自で読んで、15分たったらみんなでわいわい内容を確認するというスタイル。
「2.5 クイズ:絡み合ったモジュール」からでした。

includeのこと

クイズのサンプルコードを実行していくときにモジュールをincludeする場所のことで話がひろがりました。

module Printable
  def print
     p 'printable_print'
  end

  def prepare_cover
    p 'prepare_cover'
  end
end

module Document
  def print_to_screen
    prepare_cover
    format_for_screen
    print
  end

  def format_for_screen
    p 'format_for_screen'
  end

  def print
    p 'document_print'
  end
end

class Book
  include Printable
  include Document
end

p Book.new.print_to_screen    #=>"prepare_cover", "format_for_screen", "document_print"
p Book.ancestors    #=> [Book, Document, Printable, Object, Kernel, BasicObject]

サンプルコードではBookクラスのなかでincludeしています。
ancestorsを見るとわかりますが、PrintableをincludeしたあとにDocumentをincludeしているので、
Bookのすぐうえの親はDocumentとなり、呼ばれるprintメソッドはDocumentのほうになります。
これをプログラムのトップレベルでincludeすると、どうなるのか。

module Printable
  def print
     p 'printable_print'
  end

  def prepare_cover
    p 'prepare_cover'
  end
end

module Document
  def print_to_screen
    prepare_cover
    format_for_screen
    print
  end

  def format_for_screen
    p 'format_for_screen'
  end

  def print
    p 'document_print'
  end
end

include Printable
include Document

class Book
end

p Book.new.print_to_screen   #=> うえと同じ
p Book.ancestors    #=>[Book, Object, Document, Printable, Kernel, BasicObject]
p self    #=> main
p self.class    #=>Object

Objectクラスの位置が変わりました。
こうなると、moduleのなかで定義しているメソッドたちは、mainで直接定義されているのと変わらなくなる、けど、
同じ名前のメソッド(ここではprint)は、includeされる順番にしたがって呼ばれる。
ようです。(間違っているところはご指摘いただけると助かります)

あんまりこういうことは起こらないと思いますが。。

Classクラスのこと

話が進んでいくうちに(ちょっと発端がうろ覚えですが)、「Objectクラスの親クラスはなにか」という話になりました。
ancestors(あるいはsuperclass)で知ることができるのは、継承している親クラスの系図であって、それとはまたちょっと話のベクトルが違って、
すべてのクラスの親クラスはClassクラスであり、すべてのクラスはClassクラスのインスタンスであるということです。

すでに読み終わったページにそのことが書いてあるということなので、読み返しながら話しました。
「2.3.1 クイズの答え」のところにあるような図がとてもわかりやすかったです。

去年Effective Rubyを読んだときはこの辺がさっぱりわかっていなかったんですが、
今回だいぶ整理されました。。図って大事。

Electronでアプリを作った話

最後に主催の @fukajun さんがElectronでつくったアプリの話をしてくださいました。
詳しくはElectron + react.js + gulp でメニューバーアプリを作ってみた - fukajun - 僕はvimで行きます -

おもしろそう!!

<< 2016/12 >>
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31


記事検索


過去記事一覧
2011 11 12
2012 01 02 03 05 06 07 09 10 11 12
2013 01 02 03 04 05 06 07 09 10 11 12
2014 01 02 03 04 05 06 07 08 09 10 11 12
2015 01 02 05 09
2016 01 02 03 12






-->