第103回 Yokohama.rbにてみんなで問題を解いてみた

月次で開催しているYokohama.rbにて@Nabetaniさんに用意して頂いた問題をみんなで解いてみるということをやってみました。

yokohamarb.doorkeeper.jp

用意して頂いた問題は以下のもの。

nabetani.sakura.ne.jp

問題としては単純なものです。ですが素朴に問題を解くと計算量が多くなるので、問題を速く解くためにはなんらかの工夫が必要という良問と思いました。

以下、回答編。問題を解きたい方はスクロールはしないでください。

.

..

...

.

..

...

.

..

...

.

..

...

.

..

...

.

..

...

.

..

...

さて、回答編です。

私が解いたのは以下のもの。愚直な実装です。

http://nabetani.sakura.ne.jp/yokohamarb/103mask/ の ...

会場では愚直な実装で解かれた方が多かったのですが、早々に@hamaknさんが高速な実装を行い参加者が皆驚いてました。

gist.github.com

@Nabetaniさんの実装例は以下の通り。

qiita.com

正直、一度読んだだけではよく理解できなかったので、手元で動かしながら理解していこうと思います。

こういう問題を解いたりすることをこれからもやりたいと思っています。ご興味ありましたらYokohama.rbにご参加いただけますと嬉しいです。

yokohamarb.doorkeeper.jp

「Docker for Rails Developers Build, Ship, and Run Your Applications Everywhere」を読み終わった

「Docker for Rails Developers Build, Ship, and Run Your Applications Everywhere」を読み終わりました。

Docker for Rails Developers: Build, Ship, and Run Your Applications Everywhere

Docker for Rails Developers: Build, Ship, and Run Your Applications Everywhere

The Pragmatic Bookshelfにある本書のページには本書をBeginnerレベルに位置づけられています。その位置づけ通りはじめてDockerを使ってRailsアプリを構築する人でもサクサク読み進められる本であると感じました。Rails Tutorialを一通りこなしたぐらいの経験は必要かと思いますが、Dockerに関する前提知識はいらないかなと思います。

洋書なので、当然英語を読む必要があります。ですが、本書の前半はチュートリアル形式で読み進めることができるので、コマンドやソースコードを写経していけば本書を進めることができます。わからないコマンドやオプションは適宜検索して母語の情報を漁ればいいかなと思います。

一方、本書の後半にある「Toward Production」からは英語を読むところが増えてくるので、英語を読み進める必要があります。頑張りましょう。

個人的には、Dockerfileの書き方の説明がかなり丁寧に書かれていたり、テストの部分もしっかり書いているので好感を覚えました。

Azure App ServiceでRailsアプリを動かしてみる

概要

Azure App ServiceのLinux版にてFree版が提供されました。

blogs.technet.microsoft.com

物は試しと先日のYokohama.rbにてRailsアプリを動かしてみました。

yokohamarb.doorkeeper.jp

ただ、SQLite3がロックされた状態になり、データの書き込みができない状態でしたので完全に動いたとは言えない状態です。

環境を作る

Azure PortalからApp Serviceを選択します。Rubyが2.3か2.4しかないのが寂しいところ。

f:id:miyohide:20190519100215p:plain

Free版はJapan Eastには無いみたいでApp Serviceを作成しようとするとエラーが発生して作成できませんでした。場所をEast Asiaにすると作成できました。

準備

ローカルのGitからApp Serviceにpushすることでアプリケーションのデプロイができます。「デプロイセンター」の画面から画面に従い操作をするとクローン先や認証情報が取得することができます(スクリーンショット取り忘れた...)

また、簡単のために環境変数RAILS_ENVdeploymentにします。「構成」の場所にて設定する場所があるので環境変数を設定します。

f:id:miyohide:20190519100740p:plain

他のページは日本語化されているのに、このページが英語なのはなんでなんだろう...

Railsアプリの作成

App Serviceで動いているRubyは2019年5月18日現在、2.4.5なので、それに合わせてRailsアプリを作ります。また、bundlerのバージョンも2.0.1ではなく、1.x系を使っています。このため、何も考えずに最新のRuby・bundlerでRailsアプリを作るとRubyやbundlerのバージョン不一致でgit pushしたときに異常終了してしまいます。rbenvを使っているのなら、

$ rbenv install 2.4.5
$ rbenv local 2.4.5
$ gem install bundler -v 1.17.3
$ gem install rails
$ rails new azure-app

といった感じでRailsアプリを作るのが良いでしょう。

また、アプリのルートにpackage.jsonがあるとRailsアプリとは認識されず、node.jsアプリとして認識されます。これを解決できなかったので、package.jsonファイルを消すことで対処しました。

App Serviceにpush

あとは

$ git remote add azure デプロイセンターで提示されたクローン先
$ git push azure master

とすると、App ServiceにRailsアプリがpushされ、自動的にbundle installが行われ、Railsアプリが起動します。App ServiceのURLにアクセスするとRailsの初期画面が表示されます。

f:id:miyohide:20190519101922p:plain

RDBMSへのCRUD操作

Railsscaffoldを使ってRDBMSへのCRUD操作をするアプリを自動生成させ、App Service上で動かしてみます。

$ rails g scaffold post title:string body:text
$ rails db:migrate

App ServiceにRailsアプリをpushしたとき自動的にdb:migrateは走らないのでとりあえずローカルでできたSQLite3ファイルをApp Serviceにpushするようにします。.gitignoreファイルを編集して/db/*.sqlite3ファイルをGitの管理対象外からGit管理対象とし、git pushします。

ただこの方法では、テーブルに値を書き込む際にロックが掛かってしまって書き込みができない問題が発生します。

f:id:miyohide:20190519102822p:plain

そもそもローカルで作ったSQLite3ファイルを無理やりApp Serviceに送っているのでこれは無理も無いことでしょう。

考察

ざっくりとAzure App ServiceでRailsアプリを動かすことをやってみました。短い間でのトライでしたが、とりあえず動かすことまでにたどり着けたのは一つの成果と思います。

あとで調べると、Azure App ServiceにRailsアプリをpushしたときに動く処理は以下のGitHubリポジトリに説明が書かれていました。

github.com

例えばpush時にdb:migrateをさせるには環境変数APP_COMMAND_LINEを独自に設定すれば良さそうです。

ただ、Rubyのバージョンが古いことやpackage.jsonと同居できないことから実際にはRailsアプリをDockerイメージ化して動かすのがよいのでは?とちょっと思っています。

JavaScriptコードレシピ集を読んだ

技術評論社から出ている『JavaScriptコードレシピ集』を読み終わりました。

gihyo.jp

紙版は600ページを超える厚さなので、電子書籍版で。

jQueryを使ったWebアプリはそれなりに書けるけど、thisの扱いがよくわからなかったり、最近の脱jQuery化の流れやES2015などの最近のJavaScriptについてはよく分からないなあと思っていたのですが、なかなか勉強するため のモチベーションが上がらず。そこで小難しい文法書よりもすぐ実践に結びつきそうなレシピ集で学んでみようと思い本書を手に取りました。

レシピ集なのでまずはパラパラとどのページに何が書かれているかを大雑把に把握。その後は必要に応じて写経するという読み方を取りました。

具体的にはWebアプリでのJavaScriptの利用が多いので、

  • 「Chapter 8 HTML要素の操作方法」
  • 「Chapter 9 フォーム要素の操作方法」
  • 「Chapter 14 さまざまなデータの送受信方法」

を中心に写経。

文法的な箇所としては、

  • 「223 非同期処理を行えるPromiseを使いたい」
  • 「267 thisが参照するものを固定したい(アロー関数)」
  • 「Chapter 19 JavaScriptをより深く知る」

が断片的な情報でしか把握してなかったので大変勉強になりました。

個人的には「JavaScriptのテスト」みたいな章が欲しかったところ。

しかしながら、当初の目的である最近のJavaScriptについてはなんとなく分かってきた感じ。手元において日々の開発に役立ちそうです。

File.openを使っているメソッドのテストを書く

軽めのネタ。例えば、次のようなread_dataというメソッドがあるとします。

class MyTest
  def read_data
    File.open("hoge.txt").read
  end
end

このread_dataのテストをRSpecで書くかというお話。なんとなくhoge.txtというものは用意したくない。

StringIOを使って次のように書きました。

require "rspec"
require_relative "my_test"

describe MyTest do
  context "read_data" do
    it "return test data" do
      file = StringIO.new("aaa")
      allow(File).to receive(:open).and_return(file)
      expect(MyTest.new.read_data).to eq("aaa")
    end
  end
end

環境は

で確認。

Yokohama.rbの開催回数が100回となった

ここ数年、運営しているYokohama.rb。昨日の開催が第100回目となりました。

yokohamarb.doorkeeper.jp

お祝いに@publichtmlさんがケーキを用意してくれました。ありがとうございます。

f:id:miyohide:20190316190729j:plain
yokohamarb 100回記念ケーキ

@dan5yaさんが始められて、色々あって私が運営しだして数年。主催者自身が特にコンテンツを用意することない中続けることができたのは、参加者の皆様のおかげです。

Rubyレシピブックを読み進めてくれた@igrepさんや@nabetaniさん。

Rubyレシピブック 第3版 303の技

Rubyレシピブック 第3版 303の技

今は「RubyでつくるRuby ゼロから学び直すプログラミング言語入門」を読み進めています。

RubyでつくるRuby ゼロから学びなおすプログラミング言語入門

RubyでつくるRuby ゼロから学びなおすプログラミング言語入門

場を盛り上げようと色々と話題を振ったり、運営の分散化を提案・実践してくれた@hamaknさん。今回ケーキを用意してくれたり、運営にご協力いただいている@publichtmlさん。などなど、多くの人々の協力があってこそ今回の100回目の開催を迎えることができ、感謝しています。

Yokohama.rbの参加者の多くは、会に参加されると近いうちに転職を経験される場でもあります。Rubyをはじめに様々なプログラミング言語に関する話題や今のIT業界に関する深い話が行われることもあり、そのような話から参加者が違う道に進むいいきっかけになっているのではないかなと思っています。

Yokohama.rbは会場や主催者の都合にもよりますが、基本毎月第3土曜日の17:30から開催しています。4月以降も毎月開催していきますので、ご興味ある方はぜひとも参加してみてください。

yokohamarb.doorkeeper.jp


これからもYokohama.rbをよろしくお願いします。

『人事の超プロが明かす評価基準』を読んで自分の強みを考えてみた

@hsbtさんの日記に感化され『人事の超プロが明かす評価基準』を読みました。

人事の超プロが明かす評価基準 (単行本)

人事の超プロが明かす評価基準 (単行本)

書籍の冒頭部で

「会社」というゲームのルール、つまり「評価基準」を知ることは、多くの人が気づいていない、最も大事な原理原則なのです。

と記されていています。会社のルールとして行われている評価制度を知るのではなく、どのように評価されてそれに向けてPRしていくのかを知るということを深掘りしており、大変面白かった。

@hsbtさんが書かれている「影響力」の件については、くり返し読んでみてなるほどと納得。どうしても目が行きやすい技術力というワードに考えが行くんだけれども、スカウターみたいなもので「技術力、1,080か...」って測れるもんじゃないですし技術力という概念から離れて自分の強みを分析・PRする必要性を感じました。

じゃ、技術力という概念から離れた自分の強みは何か。

  • 行動が早い
  • 既存のスキルセットにとらわれずになんでも面白がってやってみるチャレンジ精神
  • 長期的なメリットをもとに長い時間の改善活動に尽力する。

なんかがすっと思い当たるけれども、もうひと押し何かがほしいところ。