Rails Developers Meetup 2018 https://railsdm.github.io/
![コードレビュー自動化の最前線から](https://cdn-ak-scissors.b.st-hatena.com/image/square/c6d437d3d19d4feae6ea9ef2082244acb745869a/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F2c5c5026f9cf4590a2e633316b1a9f7e%2Fslide_0.jpg%3F9704301)
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Rails' CurrentAttributes considered harmful 公開日: 2017/06/22 著者: Ryan Bigg: Ryan Bigg氏はRailsのcontributorであると同時にCulture Amp社のメンバーであり、RubyやElixirでの開発を行っています。RailsガイドのドキュメントやMultitenancy with Rails など多くの執筆実績があり、現在はDeep Dive Railsという書籍を執筆中です(現時点で45%↓)。 leanpub.com/ddrより 2017/08/01: 初版公開 2023/04/26: 更新 2024/01/25: 更新 更新情報(2024/01/25) CurrentAttributesについては、Kaigi on Rails 20
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。最近は子育てに忙しくしています 👶 先日、メドピアで利用しているcapybaraのjavascript driverをpoltergeistからheadless chrome(selenium-webdriver)に移行しました。driverを変更するにあたって既存のテストコードをいくつか修正する必要があったので、そこで得た学びを共有したいと思います。 なぜ移行したのか ここ数年、Railsでエンドツーエンドのテストを書くときにはpoltergeistを使う、というのがデファクトスタンダードだったはずです。それ以前はみんなcapybara-webkitを使っていましたが、poltergeistはバックエンドにPhantomJSを使っており、Qtに依存しているcapybara-webkitと比べてビルドが
はじめに こんにちは。ゆうすけです。 僕はRailsエンジニアとして内定後、勤務が始まるまでの1ヶ月で技術書13冊(金額にして3.4万円(汗))を読んできました。 内定先のマネージャーにおすすめされた本も多く、Railsエンジニアに転職を検討されている方、実務レベルの知識を習得したいという方の参考になればと思い、1ヶ月で読んできた本を紹介します。 無料でPDFが公開されているものもあるので、是非参考にしてみてください。 当然ですが1ヶ月で全てを理解出来た訳ではなく、今後繰り返し読んでいこうと思っているので、自分の現状の備忘も含めて書きました。 はじめに 読んだ本 基礎知識 Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus) プログラミング一般 プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則 オブジェ
はじめに コードリーディングの重要性はそこらじゅうで語り尽くされてる感があります。 僕も地道にコードリーディングをしているのですが、いざやろうとするとハードルが高いことがままあります。そこで、個人的にコードリーディングがはかどったと感じたテクニックをまとめておこうと思います。 筆者環境の前提 ソースコードのバージョン管理は Git を使っている 開発 PC は Mac を使っている エディタは Vim を使っている ghq + peco で読みたいリポジトリに気軽にたどり着く 読みたいソースコードのリポジトリが増えてくると、ローカル環境でのリポジトリをどのディレクトリに置くか、またいざ読もうとするときにディレクトリを辿っていくのが煩雑になってきます。 そんな時、読みたいリポジトリに気軽にたどり着くことができれば、読むハードルが下がります。 僕は peco と ghq の組み合わせを使ってい
ども、@kimihom です。 私は Web フレームワークは Ruby on Rails を利用している。かれこれバージョン2.2 の頃から使い続けているので 7年以上になる。そこまでして私が Ruby on Rails を使い続ける魅力について個人的な想いを記していく。 Rails の作者 DHH と彼の環境 Rails の作者として有名な DHH(David Heinemeier Hansson) という名前は、 Ruby on Rails を触ったことがあるなら必ずや聞いたことがあるだろう。しかし、彼のいる会社 Basecamp がどんな想いでどんなことをしているかを知っている人は案外少ない。 Basecamp はプロジェクト管理の SaaS である。今や世界中に顧客を抱える超有名サービスであり、Basecamp は Ruby on Rails の最新版をプロダクトに反映され続けて
こんにちは、hachi8833です。Aaron Pattersonインタビューの続きをお送りいたします。インタビューを音声で聞いてみると、原文でカットされている細かなやりとりやくすぐりもわかって面白いと思います。 (前編): GitHubとRails、日本語学習、バーベキュー 概要 原著者の許諾を得て翻訳・公開いたします。 元記事: INTERVIEW: Aaron Patterson, Rack, Github and BBQ 著者: Vera Rabkina 元サイト: RubyroidLabs Blog: 有用な記事が多く、おすすめです。 写真はすべて元記事からの引用です。 6. Rack 2とHTTP/2 技術の話題に戻りましょう。Rack 2がリリースされるので私たちも備えておきたいのですが、何か役に立ちそうなことをご存知でしたら 了解です。まずはHTTP/2についてお話しましょ
2017.06.26 [インタビュー] Aaron Patterson(前編): GitHubとRails、日本語学習、バーベキュー(翻訳) こんにちは、hachi8833です。RubyとRailsのコアコミッターとして著名なAaron Patterson氏(GitHub名: tenderlove)の30分にわたるロングインタビューを今週と来週の2回に分けてお送りいたします。HTTP/2、Rack、WebAssemblyといった技術的な話題や、GitHubやRailsセキュリティチームでの仕事、趣味や日本語学習、若手開発者へのアドバイスなど、多岐にわたった内容です。 概要 原著者の許諾を得て翻訳・公開いたします。 元記事: INTERVIEW: Aaron Patterson, Rack, Github and BBQ 著者: Vera Rabkina 元サイト: RubyroidLabs
The document discusses an error encountered with ActiveRecord in a Ruby on Rails application when trying to execute a SQL statement. It received an ORA-01795 error code from the database indicating that a maximum identifier length was exceeded. Some debugging steps are mentioned to investigate further like checking the SQL statement and database object names for length compliance. It concludes by
ピクスタ開発部で毎日ヒィヒィ言いながらエンジニアをやっております @muramurasan です。 今回はPIXTAのとあるリポジトリにおいて、未使用のメソッドを削除しようとした際、gemを組み合わせることで、効率的かつ安全に削除することができたという話をしたいと思います。 よくやる方式 外部の勉強会などで、「未使用のメソッドを削除する際にどうしているか?」ということを聞いた際、よく聞くのが「未使用らしきコードを見つけ次第、ロギングを行うメソッド呼び出しを挟み込んでいく」というものでした。 この方式は、動的なメソッド呼び出しにも当然対応できますし、お手軽なので、一般的に好まれているようです。 問題点 ただし、この方式では以下の問題点があると私は考えています。 そもそも、未使用らしいメソッドを見つけるのが大変 プロダクションコードを汚してしまう これらの問題を解決するために、PIXTAでは
All slide content and descriptions are owned by their creators.
僕と共同創業者のSuinは2013年に起業してShouldBeeというプロダクトをPHPで作りはじめた。 起業する前にプロトタイプをPHPで1〜2週間程で開発し簡単なセールスを行ない1件の受注を獲得した。これはよい感触だと感じSuin氏を誘い起業に乗り出した。 その後もプロダクト開発はPHPで行っていたが当時はPHPに不満を感じていた。そのころの僕達は顧客数が伸び悩む原因をプロダクトの機能不足や開発速度が遅いからだと考えてしまった。後にこれはまったく検討違いな判断だったと気がつく。 本格的に顧客がつき、たくさんの利用がはじまるとPHPで作られたこのプロトタイプではフィードバックにすばやく対応できないことや、自分達のモチベーションのためにならないと考えScalaでの全面的なフルスクラッチを実施することを決定してしまった。バックエンドはScalaで記述し、フロントエンドはReact+Redux
Ruby/Railsと直接関係ありませんが、かつてRubyコミュニティで愛された_why氏の名言を紹介したいと思います。 when you don’t create things, you become defined by your tastes rather than ability. your tastes only narrow & exclude people. so create. – Why the lucky stiff (何も作っていないとき、人は自分の能力よりも好みによって特徴付けられることになる。好みは世界は狭め、他人を排除するばかりだ。だから、作れ) これは2005年頃から2009年にかけてRubyコミュニティで「Why the lucky stiff(_why)」のペンネームで活躍していた、ある多才なRubyistのツイートです。 発言の文脈が分からないので、もし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く