第2回GemJam：Kaminari編を行いました

前回やったのが、2014年12月なのでだいぶ久しぶりな感じになったけど、2回目を昨日実施しました。

ちなみに、GemJamは

GemJamについて

何気なく使ってるgemについて各自のレベルに応じて今よりもちょっと深く理解する インプットだけではなくアウトプットもセットで行うことでアウトプットするという習慣を得るきっかけ作り を目的にしたもくもく会形式の勉強会です。

という感じの勉強会です。

ちょっと長いので目次つけておきます

当日のおおまかな流れ

• 会場に来た順番でこんな↑感じで今日やることをザックリ書いてもらって後はもくもくと作業
• 時間になったら振り返りをしてもらう

という感じで運営しました。

イベントページでそれぞれのレベルに応じて勉強してもらうようにガイドラインとなるものを書いておいたのですが、Kaminariはそれなりに使ったことがあるのでコードを読む （Kaminariのキモとなるようなページネーション処理の実装がどうなってるのか調べる）を行いました

当日の作業振り返り

コールドリーディングをした時にメモを取りながら作業をしていたので、以下にその記録まとめておきます

ページネーション処理がどうやって実現されてるのかとっかかりとなる箇所を調べる

最初は、spec/配下のファイルをじっくり読もうと思ったのですが、結構な分量だったので、ちょっと方針変換して、2016年4月6日時点でのGitHub上のコミットのページで一番最後のページを見つけて、そこから最初にページネーションの実装をしたと思われるものを履歴から見つけようと思いました。

それで、the first implementation of pagination helperといういかにもそれっぽいのを見つけて、そこの変更履歴で

module Kaminari
  module Helpers
    def paginate(scope, options = {}, &block)
      prev_label, next_label, left, window, right, truncate, style = (options[:prev] || '« Prev'.html_safe), (options[:next] || 'Next »'.html_safe), (options[:left] || 2), (options[:window] || 5), (options[:right] || 2), (options[:truncate] || '...'), (options[:style] || 'page')
      current_page, num_pages = scope.current_page, scope.num_pages
      content_tag :div, :class => 'pagination' do

とあったので、どうも個々の処理が関連ありそうと判断。

上記とは別に手元のRailsのアプリで導入したKaminariのソースコードに対して、ターミナル上でfindで以下のように調べることも行ってみました

find ./vendor/bundle/ruby/2.2.0/gems/kaminari-0.16.3 -type f -name "*.*" | xargs grep 'paginate' -n | more

すると

./vendor/bundle/ruby/2.2.0/gems/kaminari-0.16.3/lib/kaminari/helpers/action_view_extension.rb:17:    def paginate(scope, options = {}, &block)
./vendor/bundle/ruby/2.2.0/gems/kaminari-0.16.3/lib/kaminari/helpers/action_view_extension.rb:75:    # Ported from mislav/will_paginate

という情報があって、action_viewという単語が気になったのでこれがそもそも何かを知らなかったのでそれを調べることにした

ActionViewについて調べた記録

ActionView を単体で使ってみるがとてもわかりやすい情報があったのと、幸いにそこの記事で紹介してた内容のサンプルコードが あったのでそのコードを写経しながら理解を深めることにしました

サンプルコードをベースにして、以下の様なコードを書いてみました

require 'bundler/setup'
Bundler.require(:default)
lookup_context = ActionView::LookupContext.new('./views')
lookup_context.cache = false
view_context = ActionView::Base.new(lookup_context)
view_context.assign(first_name: 'xx')
view_context.assign(last_name: 'xxxxx')
result = view_context.render(template: 'main', 
                             prefixes: 'prefix', 
                             layout: 'layouts/appliation')
puts result

上記はmain.rbとしたので、こんな風にして実行

bundle exec ruby ./main.rb

/Path/to/ruby/use-actionview/vendor/bundle/ruby/2.1.0/gems/actionview-4.1.4/lib/action_view/path_set.rb:46:in `find': Missing template layouts/appliation with {:locale=>[:en], :formats=>[:html], :variants=>[], :handlers=>[:erb, :builder, :raw, :ruby, :slim]}. Searched in: (ActionView::MissingTemplate)

あー、Railsのアプリ作ってよく見かけMissing Templateのエラーにここで出くわすとは思わなかった^^;

require 'bundler/setup'
Bundler.require(:default)
lookup_context = ActionView::LookupContext.new('./views')
lookup_context.cache = false
view_context = ActionView::Base.new(lookup_context)
view_context.assign(first_name: 'xxx')
view_context.assign(last_name: 'xxxxx')
view_context.assign(name: 'xxxxxx')
result = view_context.render(template: 'hoge',
                          prefixes: 'prefix',
                          layout: 'layouts/application')
puts result

としたら以下のように問題なく表示されました

--
Hello, xxxxxxxxx
--

で、よくよく見ると、タイプミスをしてました・・

正しくない：layout: 'layouts/appliation' 正しい： layout: 'layouts/application'

ここまででActionViewについてわかったこと

• ActionViewというgemがあった
• そこで行われてるのは、インスタンス変数をセットすることが出来る
• render()メソッドを通じてテンプレートファイルを呼び出すことが出来る
  • テンプレートとなるファイルを探すのはActionView::LookupContextを通じてディレクトリを指定
  • テンプレート自体の参照は、ActionView::Baseのrenderのオプションを指定することで行える感じ
    • template: xxx
    • prefix: これを指定しないとテンプレートが見つけられないらしい

ActionView::Base.new
view_context = ActionView::Base.new(lookup_context)
view_context.assign(first_name: 'ファーストネーム') => @first_name というインスタンス変数にファーストネームという値が格納される

ActionViewがわかった上で、Kaminariのページネーションについて改めて調べる

ここまででおおまかにActionViewの位置づけとか仕組みがわかったので改めてページネーション処理の実装がどこでされてるのか調べることにしました。

spec/controllers/application_helper_spec.rbで

equire File.expand_path(File.dirname(__FILE__) + '/../spec_helper')
class ApplicationController < ActionController::Base; end
class UsersController < ApplicationController
  def index
    @users = User.page params[:page]
    render :inline => '<%= paginate @users %>'
  end
end

というのがあったけど、

:inline => '<%= paginate @users %>'

というコードがありました。

作業してる時に参考にさせてもらったActionViewのサンプルコードに

# 02_assign.rb
ret = view_context.render(inline: '<%= @last_name %> <%= @first_name %>')

という感じで、inline: xxxx という似た感じの処理になっていることに気づきました。

Kaminariのpaginate()はどこで定義されてるかthe first implementation of pagination helperのコードを調べてみたところ、lib/kaminari/railtie.rbで

module Kaminari
    class Railtie < ::Rails::Railtie
    initializer 'paginatablize' do |app|
      ::ActionView::Base.send :include, Kaminari::Helpers

というのをした上で

module Kaminari
  module Helpers
    def paginate(scope, options = {}, &block)

が定義されてるので、この↑paginateが鍵になりそうな感じがしたのでここを深掘りしてみることにしました

実際のpaginateを読む

初期の頃の実装を順番に読んでいきました

scope.num_pagesまでの処理

ここは引数のscope, optionsのオブジェクトの値をチェックしつつ、値が存在してたらそれを変数に代入して、値が存在しない場合には、デフォルト値を設定する処理のようでした。

※Rubyの多重代入についてよく理解してなかったので、以下コードを読んでて、すぐにわからずかなりの時間を費やしたのはここだけの話

def paginate(scope, options = {}, &block)
  prev_label, next_label, left, window, right, truncate, style = (options[:prev] || '« Prev'.html_safe), (options[:next] || 'Next »'.html_safe), (options[:left] || 2), (options[:window] || 5), (options[:right] || 2), (options[:truncate] || '...'), (options[:style] || 'page')
  current_page, num_pages = scope.current_page, scope.num_pages

content_tagの処理

content_tagはしっかり調べたことがなかったけど、2009年08月29日22:28に書かれた Railsのcontent_tagメソッドが便利で使い方も簡単を読みつつ、content_tagの使い方が紹介されていたので、Pry上で試してみた

include ActionView::Helpers
=> Object
[11] pry(main)> content_tag(:h1, 'ふー', :style => 'color:red')
=> "<h1 style=\"color:red\">ふー</h1>"

ここまで理解できた上でさらに読み進めようと思ったのですが、時間になったので今回の作業はここまででした

コールドリーディングをしてみて

Kaminariは普段何気なく利用していたのですが、今回コードを読んでみて、その下ではActionViewという仕組みを利用してる→そもそもActionViewという存在を知らなかったのでそれだけでも自分にとってはプラスでした。

また、他の人の振り返りを聞いてて、知らない機能とかがちょっと出てきたりして改めてRailsの奥深さを実感したのと、1つのgemに絞って、各自のレベルに応じてもくもく勉強してアウトプットしてもらうというスタイルにしたことの良さを実感できた勉強会かなと思ってます

今度はDevise あたりをとりあげてやろうかなと何となく考えてます

Matcher経由で就活相談してFAQになりそうなことをまとめた

Matcherというサービスがあるのですが

Matcher(マッチャー)は、社会人の「就活相談にのるので、○○してくれませんか？」というお願いを叶えることで、大学の先輩以外の人にも気軽にOB/OG訪問ができるソーシャルマッチングサービスです。

という感じで、自分と接点が無い人と出会える意味では 昔良く使っていたCoffeeMeetingに通じる所がありそうで、少し前に登録をしてました。

おかげさまでエンジニア希望の2名の学生さんとお会いして就活相談をしました。

Matcherのコメント欄で、こういう補足の情報が登録できたら嬉しかったけどそういう機能がないことに文章を書いてから気づいて折角まとめた情報なので今後申し込みがまたあった場合に、おそらく似たようなことを今後も聞かれる気がしたので、自分の考えをちょっとまとめておこうと思います。

エンジニアとして大事なこと

エンジニアとしての技術スキルを、これから社会人になろうとする人に対して過度に期待は出来ないと思うので私個人的には、以下３つが大事かと思ってます。

• 相手の話をしっかりと「聴く」
• 自分自身を「内省するチカラ」がありそうか
• 抽象化するチカラを持っているか

１つ目ですが、「聞く」ではなく「聴く」の方です。前者は、受け身というか、聞き流す感覚になると思うので、そういう形ではなく、相手がどういう意図を持って話をしてるのかという姿勢で聴くという意味です。（聴くを真剣にやると精神的にはとても大変だったりするので、インタビューがしっかり出来る人は個人的にとても尊敬してます）

２つ目の内省するは小難しいですが、色々な角度からその人のエピソードを聞いて、挫折した経験とかあると、そういう経験から教訓として何を得てるのかという感じで自分自身で振り返るような意識づけをちょっとでも持っていたらエンジニアとしての素養はあるかなと思ってます。 エンジニアの世界観では、「KPT」というのが１つキーワードになるので「KPT エンジニア」とかで、ググッてみてください

３つ目ですが以前まとめた記事で抽象化についてちょっと触れていてそれがヒントになるかなと思ってます。

勉強方法

エンジニアとしてやっていくには常に勉強するのが必要になるのですが、理想的な状態としては

インプット ↓ アウトプット ↓ フィードバック ↓ インプット （以下繰り返し）

というのが常にあるのが望ましいいかなと思ってます。

この形を目指しつ、勉強方法というインプットの手段としては書籍で学ぶ、ネット上の情報を頼りに学ぶ、オンライン・リアルのスクールで学ぶ、etc・・・と色々あると思います。

大事なことしては、読んだだけとか、聞いただけにせず、自分で手を動かす（エンジニア的にはコードを写経するという言い方をしてます）が大事かと思ってます。

インプット以外の所も補足しておきます

アウトプットの手段

アウトプットするためには、理解が曖昧だと、文章書いたり発表したりというのはとても難しいので、理解度を試す意味でとても良いかと思ってます

手段としてはブログを書く、勉強会で自分のノウハウを発表する（LTをするという）、etc・・・というのがあるかと思いますが、アウトプットはある程度の場数を踏むのが大事かと思うので、その人にとって気軽にアウトプット出来る手段を見つけて、継続的に実施していくのが良いのかなと思ってます

フィードバックについて

自分がアウトプットしたことに対して、コメントを貰ったり、アドバイスをもらったりすることで自分と違う視点を得られることで、これまでと違う分野について学んだほうが良いと感じられることが出てきます。

こういうフィードバックというのはとても大事で、特に最近のエンジニア界隈では、コードレビューという他人が書いたプログラムのソースコードを読んで、それについて疑問点とか改善点をフィードバックして、それをベースに必要に応じてソースコードを書き換える習慣を仕事の仕組みとして上手に取り入れてる会社・チームはレベルの高い人が集まってる印象を個人的に思ってます。

これから社会人になるような人にとって完全には理解できないかもしれませんが、Wantedlyに勤めてるエンジニアの方がQiitaでとても良いことを書いてるので紹介しておきます

その他おまけ

Matherで就活相談の対応をする時に、プランというのを作るのですが、差し障りの無さそうな美味しい珈琲を教えてと書いたら、ある人はわざわざ豆を買ってきてくれた。しかも私が豆を挽く器具を持ってないかもしれないと思って、挽いた状態の方をチョイスするという細かい気遣いをしれくれていて、そういうのが自然にできるのは凄いなぁー

実は最初このエントリ書いてる時にMatcher通じてエンジニア希望の人の就活相談をしたので今後聞かれそうなことをまとめましたというタイトルにしていたのですが、記事タイトルは32文字以内に収めるのがSEO的には良いらしいということを最近しって、今自分が作ってるプロダクトの↓機能を実装してるのでそっち使って試行錯誤してこのタイトルに落ち着きました

なぜポジションレスな働き方が求められてるのかをテーマにしたキャリアトークイベントをやりました

なぜポジションレスな働き方が求められてるのか？というテーマで昨日キャリアトークイベントを1年半振りにやりました。

しばらくやらなかった理由として

収支的に赤字にならないようなイベントでない限り、当面活動ストップしようかなと思ってます。

スタートアップのWebエンジニアとチームの文化の作り方考えませんか？というテーマでトークイベント実施しましたより

ということを1年以上前に書いて、実際今回もイベント単体の収益だけを見ると、まぁちょっと赤字^^; になってしまってるのですが、

• 受託ではない自分の仕事を作るための営業機会
• 年間での収支考えるとここでの持ち出しは実はそんなに大きな影響がない

を考えると、トータルで見て損なことではないかなということがわかってきたので今回実施しました。

簡単に昨日のイベントを振り返る

昨日のイベントの内容はもう@azumi0812さんに描いてもらったこの↓グラフィックレコーディングを見てもらうと、おおよその内容が伝わるかなと思うので、ひとまず貼っておきます。

グラフィックレコーディングしてくれた@azumi0812さん自身も、今回のテーマにとても興味持ってくれていたみたいで、その場での対話を可視化してくれながら、適宜対話に参加してくれたので、可視化されたものを見つつまた違った対話が産まれ、それがまた可視化されて・・・というのは、とっても新鮮な場だったので、今回企画して良かったなぁと思ってます。

イベント開始前から本編までの雰囲気

参加される人が仕事帰りで予定通りに来れるかどうかわからない＋その場の雰囲気を温めるということを狙って、いつも通り、最初に会場に来た人を順番に交えながら交流会→本編のトークイベント→任意でまた懇親会という流れで行いました。

最初の交流タイム

本編のトークイベント

振り返りで何も書かないと手抜きっぽいので「評価」というテーマでちょっとだけ深掘り

従来の役割に固執しない働き方をしてる人をどう評価するのかが気になっていたテーマだったのでそこについてちょっと触れておこうと思います。

あるレベルになってくると、客観的な評価は無理。

すべての状況に当てはまらないと思うのですが、少なくとも新しい領域にチャレンジしてる事業・会社の中で仕事をしてると、数値化して、みんなにとって納得の行くような客観的な評価を作るのが難しいのかなというのが、登壇した2人＋参加していた人との対話で気付かされました。

互いの信頼関係が構築できてるのが重要

客観的な評価は無理だから、「えいや」で評価を決めざるを得ないという状況だと、互いの信頼関係が構築できてるのがとても大事というような話が出ました。

この話を聞いた時にふと、Googleについてのこの記事のことが頭をよぎりました

社員一人ひとりが会社で本来の自分を曝け出すことができること、そして、それを受け入れるための「心理的安全性」、つまり他者への心遣いや共感、理解力を醸成することが、間接的にではあるが、チームの生産性を高めることにつながる。

グーグルが突きとめた！社員の「生産性」を高める唯一の方法はこうだプロジェクト・アリストテレスの全貌より

評価をする上で、他者への心遣いや共感、理解力を醸成できていれば、その空気が相手に伝わり、そういう人が所属するチームに入れば、「えいや」で決まる評価であっても互いに納得感がある形になるのかなと気付かされた感じがします。

イベント告知文で触れたNBAのウォリアーズの凄さ

今回のイベントの告知文で、アメリカのプロバスケットボールリーグのNBAに所属してるウォリアーズというチームの話をこんな感じ↓で書いてました。

ウォリアーズは昨季優勝してある種の目標を達成してしまってモチベーションを保ちづらそうな上に

• ヘッドコーチが腰の手術を受けた影響で、開幕から不在
• ヘッドコーチ不在の間、NBAコーチになってわずか２年目のアシスタントコーチが引き継いでいる

という状況みたいなのですが、現在どうなってるのかというと、【NBA】まだ６敗のウォリアーズ。ブルズ超えの史上最高勝率なるかという凄い状況になってるみたいで、しかも

そして、みんな役割を受け入れてる。NBAはビジネスです。評価はあくまで個人。それなのにそこを度外視してチームとしてまとまってます。

NBAのウォリアーズが、あんなに強い理由が

というのを考えると、ウォリアーズというチームが醸し出してる空気ってどんなものなのか、個人的にとても興味が湧いてきて、NBAとは言わないので、バスケットボールのヘッドコーチやサッカーの監督とかが普段どんなことを考えてるのかをうかがい知る機会とかを作れたらいいなぁと思っているので、遠い先のことかもしれないけど、いつか実現したいなぁとちょっと妄想してます^^;

これまでと違ったステージに進めそうな感触をつかめた

2年半ほどまえに第一回目をやったのですが、その時からずっとどうせやるなら、みんなにとってWin-Win-Winになるようにするということを心がけてて、これまでもその場にいた人達の表情だったり交流具合などを見てて

• 登壇してもらった人
• 参加した人

が満足いただけてるのかなと思っていました。

今回はグラフィックレコーディングをその場にいた人達が体験できて、トークイベントとしてもこれまでと違ったスタイルの体験が生み出せたのかなと思ってます。

また、グラフィックレコーディングをしれくれたご本人も、対話終わったあともだれかの対話を新たに生み出せてるということを実感されていたようで、ご本人の言葉を借りると

グラフィックレコーダー冥利につきる

ということを書かれていて、みんなにとってのWin-Win-Winというものが、これまでよりも、ちょっとアップした形のトークイベントに出来つつある手応えを得た夜だったかなと思います

最後になりましたが、毎回会場利用させてもらってるCo-Edo＆登壇いただいた小林さん＆高柳さん＆グラフィックレコーディングしてくださった@azumi0812さんありがとうございました〜

クローラー開発勉強会を行いました

昨日ですが、いつもお世話になってるCo-Edoで第1回クローラー開発勉強会を行いました。

クローラー開発というニッチなテーマのものをなぜ開催しようと思ったのかというと

• モバイラーズオアシスの中の人であるもぎゃさんから、モバイラーズオアシスで使っていたスクレイピングライブラリについてちょっと意見を聞かせて欲しいっていう話をメッセでもらった
• 実際にCo-Edoで会ってもぎゃさんと色々とクローラーの話をしてたら、互いにあるあるネタが結構満載で、きっと似たような経験ある人が他にもいるんじゃね？っていう感じになり、それなら何かイベントしましょう

っていうのがきっかけでした。

発表資料など

• もぎゃさんの発表資料はこちら
  • 昨日は時間の都合で技術的な深いところは触れなかったので、そちらについて深く知りたい方むけのスライドとして実践スクレイピングを紹介されてました
• 自分はこちら
  • 昨日気づいたけどSlideShareの日本語フォントの表示がおかしいので、ブログの埋め込みのために、SpeakerDeckにもアップしました

当日のおおまなな流れ

昨日の勉強会ですが告知文で記載したタイムテーブルに基本的に沿って以下のように実施しました。

• 自己紹介しつつ簡単な交流時間
• もぎゃさんと私が発表
• フリータイム

良かった点と改善点

• 良かった点
  • 過去のトークイベントの経験を活かして、参加者を巻き込んだコミュニケーションが自分のイメージとおりに出来た。
  • 勉強会でもやっぱりアイスブレイクのようなものを設けたほうがいいと思ったので、今後自分がやるものは今回みたいなスタイルを継続しようかと思ってます
• 改善点
  • フリータイムの位置づけをあまりはっきりさせなかったから、なんとなくグタグタした感じになってしまって、申し訳なかった。もくもくタイムとか明確に宣言＆ひとまずの終了時間を明確にするべきだったなぁ・・

開催して気づいたこと

昨日自分で勉強会をやってみて、以下の3つについて気づきがあったので順番に触れていこうと思います

• 意外と仕事で開発してる人が多い
• ターゲットのサイトタイプが意外と多い
• 技術的に下から上までそれなりのものが求められる

意外と仕事で開発してる人が多い

たまにクラウドワークスとかで、クローラー・スクレイピング開発の案件は見るのですが、世の中の一般的な求人情報でクローラー開発に関連する内容は見たことがないので、仕事でそういうのをやることって基本的にはないのかなとなんとなく思っていました。

そのため、自分の想定参加者イメージとしては趣味でサービス開発しててその一環でクローラー開発をしてるのかなと予想してたのですが、現在仕事で開発してる（あるいはこれから着手予定）という人が、想定以上にいたのが気づきというか、ちょっと興味深いなぁと思いました。

ターゲットのサイトタイプが意外と多い

初対面の人同士の話のネタとして適切かなと思って、参加されてる人達が普段対象にしてるサイトがどんな感じなのかをちょっと聞いていたのですが

• もぎゃさんが発表した飲食店関連
• ECサイト
  • Amazon（co.jpドメインだけではなく、.comの商品情報も対象にするケース）
• 不動産関連の情報
• ニュースサイト

あたりは、想定内だったのですが

• （しっかりとした許可を得た上で）国会図書館の情報
• こういうサイトがあってそこで無料で使用できる楽譜の情報
• ヘア・ネイルサロン

とかは全然イメージ出来ませんでした。

国会図書館の方は、許可を得るまでにメールなどで何度かやり取りして、話がなかなか進まずに、実際に足を運んで、依頼をして、許可を得るための色々な手続をしたみたいだし、楽譜の情報はサイトを見てもらうとわかるのですが、URLの規則性が全然ないから、どっから攻めるのがいいのか検討つかないし、ヘア・ネイルサロンはそもそもポータル的なサイトがないので、個別にそういうサロンを運営してるところを見つけて、かつ、スクレイピングってなると結構大変そうですね・・・

技術的に下から上までそれなりのものが求められる

最初に2人1組のペアーを作ってもらって、互いに自己紹介してもらった後に、今回の勉強会で聞きたいことや相談してもらいたいことを話し合ってもらい、ホワイトボードに書きだしてもらったのですが、そこで

• Ajaxなサイトの場合の対処方法
• HTMLの構文エラー対応
• インフラの構成
  • AWS上での構成
• クローラー開発アンチパターン
  • ブロックされた場合
• 法的な課題

というような内容が書かれていました。

法的な話題を除くと、スクレイピング、クローラー開発それぞれで期待されるスキルって

• スクレイピングを行う時に必要となるスキル
  • HTML内から特定の要素を抽出するためのXPathやCSSセレクターについての理解
  • 慣れ親しんでるプログラミング言語でのスクレイピングライブラリの使い方
  • 文字列操作
  • 対象サイトがJavaScriptを多用してるケースがあるため、一般的によく利用されるJavaScriptライブラリ・フレームワークについての理解
  • WebAPIの概念についての理解
• クローラー開発を行う時に必要となるスキル
  • 何らかのツールを組み合わせてジョブキューシステムを構築できる
  • 並列での処理

という感じで、技術的には、インフラ寄りの所〜アプリケーションレイヤーの所まで割りと広い知識が求められるのかなと思いました。

最後に

昨日の勉強会の最後にも喋ったのですが、第二回目をやりたい気持ちがある反面そもそもみんな使ってるプログラミング言語が異なるため、今回の話を踏まえて、ちょっと詳しく解説となると、どうしてもそのプログラミング言語を利用した時の固有の話が出てきてしまうのかなという懸念があります。 実際、私ともぎゃさんはRubyなのですが、他の方でPython+Scrapy/Beautiful Soupという組み合わせの人もいたし、Node.jsでやろうとしてる人もいたので、そういう人達に共通のテーマで2回目というのはなかなか難しいかなと。

違うネタとして、ハンズオン的なやつをやってもいいかなと思ったのですが、参加者のパソコンを見てたらWindowsマシンの人も半分くらいいた気がするので、当然みんな開発環境がバラバラになるので、その状態でのハンズオンはちょっと厳しいのかなぁと。

もしやるとすると、比較的スクレイピングしやすいサイトを見つけて、

• Ruby
• Python
• Node.js
• 他の言語（個人的にはGo言語あたりを想定）

でどういう形でスクレイピングを行うのかを発表してもらうみたいなスタイルなら、ネタとしては継続的に出来そうだし、これからチャレンジしてみようかなと思ってる人向けの参考情報になって、将来的にそういう人が実際にチャレンジ＆発表してもらうというスタイルが確立できると継続した開催ができるのかなと何となく思ってるのでそういう形での実現可能性をちょっとだけ探ってみようかなと、これを書いててなんとなく思いました。

最後になりましたが、会場利用させてもらったCo-Edo＆発表されたもぎゃさん、協力ありがとうございました！

43歳になりました

タイトル通りですが、今日で43歳になりました。

年齢的にはだいぶオジサンですが、昨年から今に至るまで仕事で新しいことを色々学び、最近はコンディショニングを意識して週3日ほど水泳してて、人生初めての背泳ぎに何となくトライしようと思いつきで始めたら意外と出来たり・・という感じで、淡々とした時間の流れの中にはいるのですが、年齢重ねることに興味・関心が増えてような気もしてます^^

誕生日とは直接関係ないことですが、最近色々考えていたことがあったので、それをちょっとまとめておこうと思います。

収益源の分散をもう少し違った角度で考え直す

あきお(@akio0911)さんブログの2016年の年間目標を立ててみました！というエントリで

うまくいっている仕事に一点集中するのもいいですが、それは強さでもあり、弱さでもあります。

様々な考え方があるとは思いますが、個人的には収入源に関してリスク分散をしていきたいと思っています。

というわけで、今年も継続して収入源の分散を心がけていきたいです。

ということを書かれててます。

収入源に関しては、これまでも、週2日の仕事と週3日の仕事という形で、分散はしてきてるのですが、それぞれの仕事は、自分の時間を売切りして収益を得ているという意味では、厳密には分散できてるという感じがしないなぁと前から悶々としていました。

今月末で1年弱ほどお手伝いしていた仕事が終了になるので、当面はもう１つの仕事で最低限の収益を得つつ自分の時間を売切りしない形で売上をたてることが出来ないかをじっくり考えようかと思ってます。

規模は小さくてもいいので、つながりが生まれそうなイベントは開催する

先月にこれからのエンジニアの働き方についてのトークイベントに登壇して、今月の上旬には、【肉を食す】イベントに参加してきたのですが、こういう場を通じておもいがけない出会い(＊1）があったりしました。

前職で、人と人をつなぐような事をしていた職業病なのかもしれないのですが、こういうイベントを通じて新しい人と出会うと

「あ、この人の話を聞いてると、きっと◯◯さんと話が通じそうかな」

という感情がなんとなく自然と出てくる変なクセがあるのですが、目先の損得とか考えずに、こういう活動を繰り返しおこなっておくことで、中長期的に、お仕事につながっていく気もしてます。

そもそもそういう活動・行動が全然嫌ではないので、小規模でいいのでつながりが生まれそうなトークイベント/勉強会というのを定期的には開催していこうかなぁーと改めて思ってます

＊1：自分の子供って言っても不思議じゃない20代の学生さんとか。

【2/9に】Co-Edoでエンジニア・webデザイナー飲み会【肉を食す】イベントに参加しました

タイトルで全て言い尽くしてますが、昨日このイベントに参加＆こんな↓内容でLTしてきました

2016 02-09-co-edo lt from Hiroshi Oyamada

2月9日（ニクの日）に肉を食べる・・という感じのイベントだし、イベント告知文の中で肉を食べましょう・お酒を飲みましょうってあったから、ネタっぽいLTをみんなするのかと思っていたら、そうでもなかったりしてどうせだったら最近作っていたやつのデモでもすればよかったかなと思いつつも、その後の懇親会でビールネタで交流出来たので結果的にはこれで良かったのかも。

てっきりみんなCo-Edoの常連さんかと思っていたら意外とそうでもなく、参加者同士が初対面みたいな割合が多かったけど、みなさんあちこちで交流されていて、Co−Edoで開催されるイベントらしい雰囲気でした

印象に残ったLTを振り返る

自分の中では印象に残ったLTが２つあったので簡単に振り返ろうかと思います

Site Reliability Engineer（SRE）という仕事

最近、一緒にコワーキングスペースで仕事してるすろっくさんがSite Reliability Engineer（SRE）という仕事についてLTされてました。

メルカリさんのブログの以下内容見るとどんな記事なのかがわかるかと思います

SREには、サイトの信頼性の向上のためにインフラストラクチャの自動化、障害対応、システムの維持などの運用業務、サーバ管理者的な役割に加えて、ソースコードに手を加えることでサイトのパフォーマンスを改善し、可用性、スケーラビリティを向上させるソフトウェアエンジニアとして役割の２つが求められます

ポジション・レス

ちょっと話が飛びますが、Number 894号の記事の中で、アメリカのプロバスケットボールリーグのNBAに所属してるウォリアーズというチームについての記事がありました。

記事の中では、以前だと個々のポジションの役割が割りと明確なものがあったのが、現在のウォリアーズというチームにいる選手がかならずしも、そのポジションにふさわしい体格ではなかったりするそうです。

ちょっとググッて２年ほど前の記事ですが世界が、日本がW杯に熱狂している裏で。《スタッフ石坂の視点》という記事で、ポジション・レスという言葉で説明されてました

バスケットボールは全員で攻め、全員で守るという点でサッカーとは異なりますが、当然各ポジションにはおおまかな役割があります

〜中略〜

このようにそれぞれに大まかな役割があるのがバスケットボールですが、マイアミ・ヒートの「ポジション・レス」という概念はこれをぶっ壊します。 そんなレブロンを中心としたマイアミ・ヒートは、プレイヤー全員がオールラウンダーと呼べるような人材が揃います。そしてヒートはこの「ポジション・レス」という概念が通用することを証明してみせました。過去2シーズンはマイアミ・ヒートが優勝しているのです。そう、2連覇。2000〜2002年のレイカーズ以来となる3連覇を目指します。

エンジニアの役割もちょっとづつポジション・レスになってる気がする

イベント参加前にNumberを読んでいたのと、SREの話を聞いたことで、ポジションとか役割とかが、従来イメージされていたそれとは異なりつつあるのかなとふと思いました。

SREとかは、インフラエンジニアっていうと半分はその素養が必要だけどそれだけでは務まるようなポジションでもないし、かといってアプリケーションレイヤーに強い人がやろうとすると、今度は運用部分についての知見とかが足りずにうまくマッチしないみたいなことが生じたりするのかなと。

最近のNBAのポジション・レスな発想で、目の前の問題解決のためにチームとしてどのように振る舞うのかをみんなで考えるという流れがエンジニアな世界だけではなく、他の分野でもあるのかなとなんとなくですが思ったりしました。

どうでもいいけどNumber 894号のサッカーの中村俊輔選手とラグビーの五郎丸選手の対談記事がそれぞれ違う分野のスポーツしてるけど見てる絵というか発想が近い所がある印象で読んでて凄く面白かったです

Number(ナンバー)894号 〝エディー後〟のジャパン。特集 日本ラグビー「再生」 (Sports Graphic Number(スポーツ・グラフィック ナンバー))

posted with amazlet at 16.02.10

Number編集部
文藝春秋 (2016-01-21)

Amazon.co.jpで詳細を見る

中年エンジニアがエンジニアを続けられるように気をつける健康とココロのこと

東洋経済オンラインでエンジニア夫婦のあるある日記という連載記事を書いてるぼへぼへさんが、健康とココロのことについてLTされました。

私もあともう少しで43歳になるのですが、日々の体調管理というかコンディショニングみたいなことを意識して定期的に運動したり、食事や睡眠なんかも気をつけて、病気にならないような予防を心がけているので、似たような考えを持ってる方のお話が聞けてとても興味深かったのと、その後の懇親会でお話し聞いたら、割りと今に至るキャリアの作り方も面白くって、どこかで一度これまでのキャリアを掘り下げるようなお話をしてもらいたいなぁーとふと思いました。

最後になりましたが、美味しいお肉＆懇親会でとてもお話を聞かせてもらった株式会社サイクスの門松さん＆他のイベントスポンサーの皆様＆Co-Edoの運営スタッフさん、ありがとうございました！

英語もくもく会を実施しました。

Web系な人の英語勉強会というコミュニティをDoorkeeperに作りつつ、昨日第一回目のもくもく会を行いました。

なぜ、実施したのか？

昨年の年末に、だいたい課税対象額がどの程度になるのかを計算してて、もうちょっと経費として計上したいと思った時にふとSafari Books Onlineという英語版ですがO’Reilly本＋αや、O’Reilly主催のカンファレンスの動画閲覧し放題なサービスのことを思い出して年額契約しました。

ちなみに、メジャーな技術についての書籍はもちろんなのですが、例えば、最近お仕事でちょっと使ってるBackbone.jsベースのMarionette.jsの情報もSafari Books Onlineで検索するとBetter Backbone Applications with MarionetteJSという本が見つけることが出来たりとかなり有益な情報が得られたりします。

せっかく年額契約したSafari Books Onlineをもっと使い倒したい気持ちがあるので、そのために定期的に英語を勉強する機会/場を作らないとダメかなと思ってWeb系な人の英語勉強会という形で、２週間に１度くらいのペースで実施しようかと思って、今回実施しました。

何を勉強するか

最初はSafari Books Onlineで興味ある本を探してそれを読む・・・とかを一瞬考えました。

ただ、Ruby / Ruby on Rails ビギナーズ勉強会 第９回に参加した時に、安川さんがお話された英語学習から海外発表までの流れという内容のショートセッションの中で

• 英語のイメージ化
• 理論・構成を把握

ということをお話されていた事がが今でも特に印象に残っていて、どうせ勉強するのなら手応えがあってみんなが手を付けないような領域にチャレンジしたほうが、結果的に得られるものが多いと思って、ひとまずSafari Books Onlineの本を読むのはもう少し後にしようと決めました

また、英語のイメージ化や、英語の理論・構成を把握するみたいな話は、大学受験の予備校時代に教わって、それが要因で英語の偏差値飛躍的に上がった経験もしていたのでその辺りの体験も振り返って改めて勉強することにしました。

実際勉強した内容

安川さんのスライドで紹介されてる一億人の英文法を本屋さんで探し、立ち読みした感じで良さそうだったのでこれを買って勉強することにしました

一億人の英文法 ――すべての日本人に贈る「話すため」の英文法（東進ブックス）

posted with amazlet at 16.02.04

大西 泰斗 ポール・マクベイ
ナガセ
売り上げランキング: 40

Amazon.co.jpで詳細を見る

実際の勉強内容を振り返る

１時間弱ですが本を読んだ内容で印象的だったことがいくつかあります。

英語は配置のことば

日本語の場合には、語尾の変化、（たとえば赤、赤く、赤いみたいな感じ）で文中の機能を表してるのに対して、英語の場合には、配置によって行ってるということが書かれてました。

どういうことかというと、redという単語が単独であってもそれが赤、赤く、赤いのどれかというのはわからないですが

• Red is the color of passion
• I love red.
• That dress is red

というそれぞれの文章の中でredがどこに配置されてるのかで役割が決まるみたいなことが書かれてて、この説明は自分にはとてもわかりやすいと思ってこれを知れただけでも、昨日勉強したかいがあったかなと思ってます

前置詞onのイメージ

前置詞onは、「〜の上に」という和訳がされがちですが、実際にネイティブの人がonという単語で想起されるイメージは他にもあるということが書かれていて、これは、安川さんのスライドの33枚めあたりでも紹介されてます。

私が以前、外資系で仕事をしてた時に、メールの文章の中で利用される単語それ自体は簡単なものが多いのに、イマイチ理解が進まないケースがあったのですが、それなんかも、その単語の本来イメージされる概念が何かを正確に掴んでなかったからなのかなぁと気付かされました。

終わりに

システム開発でもそうだと思うのですが、その根底にある概念を知ってることで多少知らない機能が出てきても、ある程度の推測が効くかと思いますが、英語においても、その根底にある概念をしっかりと理解しておくのが大事なのかなと勉強をしててふと感じたので、今後もちょっとづつ勉強していこうと思ってます。