全体がいい感じになるために、私たちRailsをホームにするWeb技術者ができること/let-our-whole-system-growRailsDM 2019 での発表資料です
Ruby on Rails の魅力と思想 - ボクココ
ども、@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 の最新版をプロダクトに反映され続けて
The Rails Doctrine
Ruby on Rails’ phenomenal rise to prominence owed much of its lift-off to novel technology and timing. But technological advantages erode over time, and good timing doesn’t sustain movements alone over the long term. So a broader explanation of how Rails has continued to not only stay relevant but to grow its impact and community is needed. I propose that the enduring enabler has been and remains
tumblrみたいなやつのRoutingパターン
tumblrみたいなやつのRoutingパターンtumblrみたいなやつ (そろそろ適当な名前を決めたくなってきた) をRuby on Railsを利用して実装するにあたって、主にRoutingの周りで考えたことについてまとめておく。他の人がWebアプリ書くときの参考になれば。 機能 tumblrみたいなやつには以下のような機能がある。 ログイン・ログアウト・サインアップ 記事の一覧・詳細・投稿・編集・削除 あるタグの付いた記事一覧 あるユーザの投稿した記事一覧 記事にスターを付ける・外す 記事にタグを付ける・外す 通知一覧 画像投稿 config/routes.rb Routingのコードはコピペするとこうなってる。 Rails.application.routes.draw do root to: "posts#index" get "/@:user_id" => "users#sho
「それでもRailsを選択する3つの理由」を読んだ - ローファイ日記
http://ppworks.hatenablog.jp/entry/2015/02/19/223552 ほぼほぼ同意なのですが、フームと思って（ppworksさんプロダクトだから、ということでもないが）ポエムをしたためた。 でもなんかこれをあえてポエムにとどめないで書いたらどういう反応があるかな〜と思ったのでブログにも転載してみよう。 規約縛りの哲学 これは文句なくその通りだと思っていて、Rails以外のフレームワークではこれらの実現が非常に中途半端であると言う印象を持っている。 サービス作りにおいて技術選定やら何やらからの議論をしていてはリリースは当然遅くなるし、あまりしたくないということである。議論するならもっとユーザに近い、正体のよく分からない不安点（このアプリほんとにユーザに受けるの？ とか）に関してすべき。 議論は一般的に良いことのように思われているが凄い体力を使うし、本当に必
リソースの一部更新におけるURL設計 - Qiita
概要 Webアプリケーションにて、リソースの一部更新を行う際、どのようにURL設計を行うとシンプルで美しいか（本当はそこまで考えていなかったけど）悩んでいたところ、 @t_wada さんから素敵な設計指針をご教示いただきました。 本記事はその内容に加えて、実際に自分で行ったこと、調べたこと、思った事など、まとめております。 あらすじ 数週間前にSIピラミッドからヒモなしバンジーを決めてWebの世界に飛び込んだ私は、小さな小さなWebアプリケーションをrails newから手探りで作っていました。 そんなとき、簡単なリソースの一部更新機能をどう実装したもんかなーと悩んでました。以下、当時（といっても先週）の超雑なぼやき。 リンクをクリックしてモデルの一部を変更するのはどうしたらいいんだろう。 例）不参加をクリック -> 某カラムをtrueからfalseへ リクエストオブジェクトに対象カラムの
開発環境と本番環境の違いを埋めるHeroku、Engine Yardの新機能：Rails Hub情報局：エンジニアライフ
「でも、ステージング環境ではちゃんと動いています！」 こう言われてブチ切れた経験があります。業務アプリのバギーな動作を社内のエンジニアに指摘したところ、テスト用の環境では動いているというのです。「いや、ぼくら本番環境のアプリを使っていて現に困っているので、それを直してほしいだけなんですけど」というと、「でも、ちゃんとステージング環境では動いています。お使いになっているのがChromeのようですが、Chromeでの動作検証はしていません（キリッ」というようなやり取りに絶望しました。原因はブラウザではなく、バージョンアップしたアプリ自体にあったのですが、ステージング環境では問題が発現しなかったんですね。 というように、開発環境、ステージング環境、プロダクション環境（本番環境）の3つは、大小いろいろな違いがあって、完全に一致させることは難しいものです。手元の環境で動いているアプリが、プロダクショ
Sprockets再考 モダンなJSのエコシステムとRailsのより良い関係を探す - Qiita
すいません。締切守れませんでした…。 やっぱ、java-jaの忘年会の翌日は辛い…。 はじめに Webシステムを開発していると切っても切れないのがJavaScriptです。 Railsはかなり早い時期からalt-JSや結合、minify等を組み込めるようにフレームワークにそれを取り入れてきました。 それを支えているのがRails3.1から導入されたsprocketsです。 それに伴なってJSのライブラリをどうやって管理するかという点について、独自の路線を取ることになりました。 JSのライブラリを同梱したgemパッケージにラップしてrubygemsとして管理する方法です。 ある程度は上手くいっていたし、今もその流れは続いているんですが、時々問題になることもあります。 例えばメンテナの対応時期がズレてて古いバージョンのままだったり、似たようなgemが乱立してややこしくなったり。(backbon
Resource Routingつらくね？ - Qiita
Rails Guidesでは「Resource Routing: the Rails Default」として namespace, resource, resources といったメソッドを利用する方法が紹介されている。これまでとりあえずこの機能を使って開発してきたが、これは果たして本当に積極的に利用した方が良い機能なのか。 あるとき 試しにTwitterのAPIのようなルーティングを定義しながら、Resource Routingを利用する場合としない場合とを比較してみることにする。ここでは (Resource Routingを利用するメリットを出すためにも)、API用のPrefixとして各パスの先頭に /api/v1 を付けることにする。このAPIはアクセストークンの発行や、tweetの取得、投稿、ユーザやフォロワー情報の取得などの機能を提供する。また、/api/v1 以下のどのパターン
Railsアプリつくった - ✘╹◡╹✘
最近APIサーバ用途でRailsアプリを1個つくったので振り返る。 概要 接続元はiOSやAndroidアプリとか、Webブラウザとか、別のWebアプリケーションとか。1ホストあたり秒間数百リクエスト、平均応答時間10msぐらい。Rails 4.1.0.rc2、Unicorn、Nginxを使ってる。正直Railsは全部入りで重いイメージがあったので何となく平均50ms以内程度であれば良いところだろうと思ってたけど、意外と速い。多分そもそもサーバの性能が良いんだと思う。実装時に気を付けたことは普段の開発と特に変わりない。いつもは大勢でワイワイ開発するものに少し手を加えるということが多いんだけど、今回は珍しく自分一人でつくったから目が行き届いてたのかもしれない。DBへの問合せの効率に気を配るとか、Rubyでの処理の無駄を省くとか、アプリケーションのプロセスに無駄なコードを読み込ませないとか、計
RailsでInteractorをうまく利用する - ワザノバ | wazanova
http://eng.joingrouper.com/blog/2014/03/03/rails-the-missing-parts-interactors 3 comments | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 飲み会アレンジサイトGrouperが、同社のエンジニアブログで、規模の大きなRailsアプリをパフォーマンスよくつくるときの工夫を提案をしてますが、それに対してRailsのクリエーターのDHH (Basecamp / 37 Signals) が厳しいコメントを残しています。 1) Grouperの提案 問題意識 Railsは、コードベースが千行を超えると、テストスイートが遅くなりがちで、フレームワークのロードタイムが増える。 よくあるのは、ビジネスロジックのほとんどがActiveRecord /m
Node.js を選ぶとき 選ばないとき
4. @tricknotes I am a software developer who love JavaScript and Ruby. http://tricknotes.hateblo.jp/
RailsのStrong Parametersで弾かれたときにすぐに気付けるようにしてみる - (ﾟ∀ﾟ)o彡 sasata299's blog
2013年08月12日11:25 Ruby RailsのStrong Parametersで弾かれたときにすぐに気付けるようにしてみる Rails4 を使ってると Strong Parameters で特定のパラメーターが弾かれていてハマることがあります。セキュリティ的に安全になったので素晴らしいんですが、いかんせん慣れていないせいか特定のパラメーターが弾かれていても気付かないことが多くて。。そこで、すぐに気付けるように色付けしてくれる colorize_unpermitted_parameters っていう gem を作ってみました。 使い方はこんな感じ。以下を Gemfile に追加して bundle install するだけ。 gem 'colorize_unpermitted_parameters' Strong Parameters で弾かれると Unpermitted para
「壊れてねぇなら直すな」という発想はRailsにはないのかも - QA@IT公式ブログ
QA@ITはRuby on Railsで構築・運用しています。で、そろそろRailsの新メジャーバージョン、Rails4のリリースが近づいているようです（と、聞くようになってずいぶん経ちますが）。いろいろと新機能がありますが、GitHubを見ていて1つ驚いたことがあります。Ruby on Railsの生みの親のDHH（David Heinemeier Hanssonさん）が、メジャーバージョンアップとなるRails4に向けて行ったこのコミットに唐突感があったのです。よく使われるAPIの名前を、こんなに簡単に変えちゃうんだという軽い驚きです。 「壊れてねぇなら直すな」（If it ain’t broken, don’t fix it.）という有名な言葉があります。米国のジミー・カーター大統領時代の行政管理予算庁長官だったトーマス・バートラム・ランス氏の1977年の発言が人口に膾炙したもののよ
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
全Railsエンジニアが毎日始業時に正座して見るべき動画 - komagataのブログ
Thomas on Rails。楽しげなメロディーと共に大惨事連発してます。Railsエンジニアのお父さんはお子さんとうっかり見たら心を深くえぐられそうです。 日本語版 Original Version 歌詞（日本語版） 「じこはおこるさ」 スリルなんてちょっとなら楽しみさ でもイライラすると事故が起きる へっちゃらさ なんて知らん顔して 走っているとそんな時 事故がほら起きるよ いきなり来る 調子乗ってやってるとバチがあたる 事故がほら 起きるよ いい気になってると そうさ、よそ見してるその時に 事故は 起きるものさ 思いつきでやると きっと 失敗するよ 幸運の女神は気まぐれだから ウキウキしてるとまっさかさま 忘れないで気をつけてね いつだって 事故がほら起きるよ 突然さ 運が無い時はしょうがない なんとかしよう 事故がもし起きたら 落ち込まないで うまくやれるようにがんばろうよ 事故
ジモティーを支える技術 | 株式会社ジモティー
Hashです。ミームの人と呼ばれていた時期が俺にもありました。現在、株式会社ジモティーでエンジニアをやってます。公私ともにidで呼ばれ、本名を忘れがちなのが最近の悩みですが、別に悩んでいません。 ジモティーのエンジニアは5人で、基本的にまんべんなく仕事をやるもののある程度得意不得意があって、僕はインフラというかサーバの世話をすることが多いです（諸般の事情により名刺にはインターフェイスエンジニアと記載されているのですが…）。 そこで今回は「ジモティーを支える技術」と題して、ジモティーの使っている技術をざっくり紹介したいと思います。まぁタイトル使いたかっただけじゃね感あります。 Rails3 Ruby on Rails 3でWebアプリケーションを開発しています。 ウェブサービスとして見たときジモティーはいわば今風の「掲示板」で、トリッキーな作りは少ないためRailsとの相性は良いのではない
ベターJavaScript!? CoffeeScriptが注目されるワケ：Rails Hub情報局：エンジニアライフ
JavaScriptへコンパイルして実行することを前提としたスクリプト言語「CoffeeScript」がちょっとした注目を集めています。CoffeeScript自体は2009年末に登場し、その1年後の2010年12月にバージョン1.0がリリースされていますが、注目を集めたのは、数日前（2011年4月13日）にRuby on Railsの生みの親であるDHHが、次期バージョンのRails3.1でjQueryやSCSSと合わせて、CoffeeScriptをデフォルトとして採用するとTwitter上で発言して議論が巻き起こったからです。 Yes, it's true, Rails 3.1 is going to ship with CoffeeScript and SCSS in the box for use with the new asset pipeline. It's bad ass.
RailsDevCon2010で話してきました
RailsDevCon2010、お疲れ様でした。主催かつ発表のお声をくれた@ysakakiさん、スタッフの方々、スピーカー、発表を聞いてくれたみなさま、どうもありがとうございました。 今回、「Railsプロジェクトを成功させるために現場ができること」というタイトルで話したけどびっくりするぐらいRailsに関係のない話。オマケ程度にちょこっと。以下、資料です。 テーマとしては、@ysakakiさんから声をかけて頂いた時に、[Railsの現場でまだまだバージョン管理すらしてないところあるよね。そういう基本的なところを改めて赤松さんの方から話して欲しい」と言うことだったので、個人的に基本的な所と言うと「TDD」と「バージョン管理」(できれば継続インテグレーションもいれたい)だったので、その変も踏まえて技術的負債というトピックを扱った。 具体的な話をしても、スクリーン上じゃコード読みづらいし、わか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hypermedia: The Missing Element to Building Adaptable Web APIs in Rails
