コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

『Rails Developers Meetup 2018 Day 3 Extreme』に行ってきたよメモ

Rails Ruby 行ってきたメモ

Rails Developers Meetup 2018 Day 3 Extreme］に行ってきたので見たセッションに関してのメモ。メッチャ多いのでひとつひとつの感想に雑味があるのは許してほしい…。

各発表の感想

※資料スライドは見つけたら貼ります。

曖昧さを受け入れて開発をしていく方法

感想

  • 仕様がしっかり固まって降りてこないウォーターフォールではない開発に関しての構えの話
  • 前に違うところでも語られていたが、足回り見たい部分が結構重要になるなという気持ち
  • GraphQLを使うことで画面の仕様変更に強くするというのは知見だった

関連リンク

Octocatは技術的負債の夢を見るか?

感想

  • 実際にあった怖いコードの話を交えながらの技術負債の話
  • 地図があればそれに従い、地図がなければ布教するというのはとても共感できた
  • 設計レビューやってます、みたいな話があったので質問したら丁寧に答えていただけた…ありがたい…（無断転載するのもアレなのでこちら）

ちゃんとやっている…非常に参考になる話だった

関連リンク

pixiv Sketch Live: WebRTC配信サービスの裏側

スライドは公開された貼ります

感想

  • リアルタイムチャットとWebRTCを使った配信ノウハウの話
  • 結構門外漢なので、はーそうなのかーみたいな感じの知見が多かった
  • あとここでも時雨堂さんの名前を聴くとは思わなんだ…

関連リンク

Ruby でつくるデータ分析基盤 - Rails アプリケーションにおけるデータ処理の変遷

感想

  • データ分析基盤をどう作っているかという話
  • 「WebUI上に用意してしまうと間違いに来づけない」というのは確かにそうだし、BigQueryをカジュアルに触れると普通に起こりうる問題だなと思った。
  • BigQueryのクエリ組み立てが独自DSLっぽいのつくると管理がツラミなのでバランス大事かもなっていう所感

GCPをフル活用したゲームログ収集基盤の構築

感想

  • イベントログデータとかをどう扱うかという観点の話
  • fluentdだと欠損が…みたいな話があったので使ってないのかと思いきやRailsからの吸い上げは普通に使っているんだという気持ち
  • 技術比較の部分は普通に参考になった

関連リンク

IKUSEI on Rails

感想

  • みんなのウェディングのRuby人材を育てるという意気込み毎度すごいなと思う。
  • 新人教育しっかりしてるけど中途はどうなんだろうとかは思ったりした
  • エッセンスとは見習いたい部分多分にあるので参考にしたい

関連リンク

esmメンバーの関心事〜開発手法と開発環境編

感想

  • アジャイルとは何か…みたいな気持ちにさせられたので原典をちゃんと読もうと思った気持ち
  • dotsファイルは結構人によって色出るよね、とは思った。

関連リンク

技術顧問という働き方

感想

  • 外部の人が入って技術を牽引していくトライアンドエラーの話
  • レビューとかはやっぱドメイン要素が入ってきちゃうのでバランス間隔難しそうだなと思った
  • 読書会は結構実りが多いとのことだったので、輪読形式でやってみようかなという心持ち

関連リンク

enzaプラットフォームのアーキテクチャ

感想

  • 技術選定の背景から、パフォーマンス、運用周りまで結構実りの多い資料（話が途中だったのすごく残念）
  • Elixirの事例や定常的な負荷試験など普通のサイトとは切り口が違うところが学び

関連リンク

Rails経験者が万葉の新人研修を受けて得られたこと

感想

  • 中途でもちゃんとランディング期間を設けてるとてもいい会社の話
  • 新人研修のカリキュラム非常に良さそうなので読みたい

関連リンク

Rails + TypeScript + React + Hypernovaで始めるSSRライフ

感想

  • GoogleBotがちゃんと来てるかをメトリクスする、というのはなんかなるほどというか、ギリギリを活きてるサービスなんだなという感想
  • それとは別にhypernova結構いいなという気持ちになったのでちょっと業務で導入検討したくなった
  • あとBulmaは癖がなくて使いやすいと思う

関連リンク

Railsと考えるデータベースのインデックス戦略

感想

  • カーディナリティに注目したパフォーマンスの話
  • こういう部分って大切だと思うし、そもそも我々実行計画の読み方を覚えてちゃんと見るべきだよねという気持ちになる…（割とAcitiveRecordにおんぶにだっこになってしまっているので改めたい）

関連リンク

リフォーム Rails app

感想

  • おかしなコードを事例を交えて紹介
  • ガード節を一個間違って消すだけでおかしくなるようなコードを書いてはいけない場面もあるよね、みたいのはもうちょっと掘り下げて聞きたかった
  • スライド公開されると思ってメモがあまり取れてなかったのが残念… 公開された、やったー！
  • デカいコードを切り出すときに利用していない変数が生まれるとかはちゃんとテスト書こうねみたいな事案ですね…

関連リンク

RSpecでBDDをしよう

speakerdeck.com

感想

  • TDDとはBDDとはみたいな付録C的な話
  • テスト技法じゃなくて、開発技法なんだよ！という叫びを伝えていきたい

関連リンク

RailsWayの再考

感想

関連リンク

Wantedlyにおけるプロダクト、技術、組織、7年間の進化

感想

  • 歴史資料。
  • モノリシックなアプリと増えていく新機能とどう向き合うかの一例
  • ある程度で方向性を見極めていくべきところ多いのかなーと思うなど

関連リンク

Attributes API実践

感想

  • ActiveRecordに型を意識させたり、オブジェクトを初期値として仕込む事例などの話
  • 機能的には便利そうだなーと思う半面、しっかり理解するさせないと沼になりそうな機能

関連リンク

GraphQL on Rails 2018

感想

  • 実際に導入した感想としての資料
  • 使い手のメリットが見えないが、やっぱりデータを検索する系は使ってみたいなと思ったりした。

関連リンク

RuboCop Headqurters 2018

感想

  • rubocopの現状ってこういう感じなんだ、というのが体感できた
  • 1.0に向けて整備されてきているので、そのタイミングが襟を正すよいタイミングかなと思ったり。

関連リンク

Rails 6 に向けた ActiveRecord の改善

kamipoさんによるフリートークセッション

感想

  • ActiveRecord闇多いなという感想。
  • 新機能がパフォーマンス検証されてないので遅くなっているという話もあったりして、この話って普通の開発にも当てはまるので怖いなと。
  • ARを過信せず、ちゃんとテストケースは書かねばと思ったり…

全体を通しての感想

  • コード・全体設計、チーム運用、Rails的な話、いろいろ聞けて楽しい1日でした。
  • 広く浅くマンの私としてはRailsの強みみたいな部分を活かしつつも技術選択の幅を増やしていきたいなとLaravelの話を聞きながら思いました。
  • ActionCableに関しては、各々使い方が微妙に違う話なのに、全員難色を示す/示さざるを得ない結果を得てる感じがあった。
  • あとみんなわりとカジュアルに「ドメインが〜」みたいな話をするので、それらの用語って割とRails開発者間では一般化してきたのだろうかと思ったりした。

時刻を文字列からParseするときはTime.zone.parseが一番オススメ

Ruby Tips Rails

ローカルマシンでは露見せず、アップすると露見する系なので、思わぬ事故を防ぐために。

環境

rails (5.2.0)

何故オススメなのか

原理としては Time.zone.now と同じなのですが、 Time.parse を使うとRailsに設定されているタイムゾーンは配慮されないので、Time.zone.parse を使ったほうが間違いがないよねという話。

例

# タイムゾーンの確認
Time.zone.name
#=> "Tokyo"

# 設定したい時間をセット
set_time = "2017-10-01 12:30:45"
#=> "2017-10-01 12:30:45"

Time.parse(set_time)
#=> 2017-10-01 12:30:45 +0000
Time.zone.parse(set_time)
#=> Sun, 01 Oct 2017 12:30:45 JST +09:00

関連リンク

負荷試験をやりたいけどやれてないという思い

雑記

実はソフトウェアエンジニア歴約8年ですが、まっとうな負荷試験というのを経験したことがない。

というのも、サーバーサイドエンジニアマンやってた時間よりもネイティブアプリとかフロントアプリとか書いていた時間が長かったりするのと…

  • 自社サービスばかりで、納品するような話もなかったので非機能要件としてそれを満たす課題が設定させるような案件をやってこなかった
  • 負荷試験を行うほどの予算がない or そんなのが必要のないアクセスのもの
  • Jmeter とか gatling 使いたい！とか思ったけど、他の実装が大変でそれどころではないというところで見送り
  • 負荷試験的なことをしたがマクロを組んでただただgetリクエストをするだけとかのもの

などなどいろいろな要因があり、負荷試験に長けている人や経験者とも出会うことがあまりかなった。

といはいえ大切なモノという認識はあるので…

これを読んでみたいなと思った。

関連リンク

MySQL5.7のTEXT型とBLOB型にはデフォルト値を設定できない

Tips

基本的にはdefaultを設定したい衝動に駆られるができないというただのメモ

環境

$ mysql --version
mysql  Ver 14.14 Distrib 5.7.17, for osx10.12 (x86_64) using  EditLine wrapper

どういうことか

何故かぐらいは調べようと思ったのだが短い時間では特段それっぽいものは見つからないので、ドキュメントに書かれている

BLOB および TEXT カラムにはデフォルト値を割り当てられません。

が全てなのかもしれない…

参考リンク

Railsのrequest.domainはデフォルトの場合、セカンドレベルドメイン相当まで

Rails Ruby Tips

domainって書かれているのでサブドメインもまるっとひっくるめてもってくるのかと思いきやそうではなかったのでメモ

環境

rails (5.2.0)
  actionpack (= 5.2.0)

実装

request.domainを深掘りすると以下のコードに突き当たる

# /actionpack-5.2.0/lib/action_dispatch/http/url.rb
def extract_domain_from(host, tld_length)
  host.split(".").last(1 + tld_length).join(".")
end

ホスト名に対してトップレベルドメイン長さ（tld_length)分だけ取得して抽出する。

で引数に使われている数値は同ファイル内で定義されていて

#  /actionpack-5.2.0/lib/action_dispatch/http/url.rb
mattr_accessor :tld_length, default: 1

ってことなので基本はセカンドレベルドメイン相当しか取得ができない。

ちなみに host は以下の内容で抽出される

def raw_host_with_port
  if forwarded = x_forwarded_host.presence
    forwarded.split(/,\s?/).last
  else
    get_header("HTTP_HOST") || "#{server_name || server_addr}:#{get_header('SERVER_PORT')}"
  end
end

参考URL

シンプルにするということ

雑記 日記

こんなツイートがあった

超絶機械翻訳で見た感じ、不必要な機能を削る、みたいな話ですね。

きのこ本にもあるんですけど、「間違って使うことを困難に」という話があって、間違えようのないインターフェイスを作れば、誤った使い方はされなくなるという話で、これはつきつめると、シンプルに一つのやりたいことに対して一つの機能を実装するということだなと思っています。

これは設計、コーディング等々いろいろつかえる思考法で、できるだけシンプルにするとモジュール化されまくるので使い勝手がとてもよろしくなるので大事にしていきたい考え方だと思って雑記として。

関連リンク

フルスタックと枯れた知識の水平思考

日記 雑記

ただの日記です。

忙殺されていた仕事も落ち着きの様相を見せ、そろそろRuby以外のカテゴリのこともちゃんと取り組んで行きたいなと思いながら身体を通常生活に戻すことにパワーを割いてしまっている日々です。（なのでちょっと更新時間の次元が歪んでいます…）

コードを書き、仕様書も作り、誰かの話を噛み砕いて形にする、しかもフルスタックエンジニアの振る舞いを要求されることがおおいので、携わる知識のアップデートは結構アンテナ高くいないとすぐに取り残されてしまいます。

そんな感じなので一番大切にしているのは、どの事柄にでもつかえるコアな部分の考え方だと思っています。

具体的には設計論や、使われている技術がどう意図で培われてきたのかというバックグラウウンド、どういう仕組で動いているかなどです。

車輪の再発明をして無駄に時間を過ごしたくないというのもありますが

  • 車輪はいかにして生まれたか
  • 車輪はどういう仕組で動いているか

みたいなことを知ることにより車輪とはまた違うものを開発するときにスライドしてつかえるものがあるのではないかと思っています。

なので枯れた知識の水平思考という考え方を（原典とはちょっと違う確度ですが）大事にしています。

もっとジャンル問わずいろいろと知識を付けていって、ここにアウトプットできればと思う今日このごろでした。

関連リンク