You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
#1: 統計を調べる(本記事) #2: Railsの長所と向いている用途 #3: Railsの短所と不向きな用途、他の選択肢など 追記(2019/04/26) 特に他の言語やフレームワークの方には、Rails Developers Meetup 2019で発表された以下のスライドもご覧になることをおすすめいたします。 概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Who gives a F*** about Rails in 2019? 原文公開日: 2019/01/15 著者: Wojciech Miśta 原文が長いため3分割してあります。 日本語タイトルは原文タイトルではなく内容に即したものにしました。 画像は元記事からの引用です。 Railsは2019年も「あり」か?(翻訳) もう認めようではありませんか、Ruby on Railsが年を取ったことを。いや本当に長生き
Forem is open source software for building communities. Communities for your peers, customers, fanbases, families, friends, and any other time and space where people need to come together to be part of a collective. See our announcement post for a high-level overview of what Forem is. dev.to (or just DEV) is hosted by Forem. It is a community of software developers who write articles, take part in
INSANELY FAST Qiitaを読んでる人なら https://dev.to をほとんどの人が見たはず。見てない人は見てきてください、速すぎて驚くはず。またmizchiさんがdev.toに書いた なぜ dev.to がこんなにも速く、こんなにも自分にとって感動的なのか - dev.to を見た人も多いと思う。個人的にHeroku, Railsを採用してここまで爆速なサイトを構築出来ていることは今までの常識を覆す衝撃な出来事だった。こんな新しい発見をもたらしてくれたdev.toには本当に感謝してる。自分もこんなサイト作ってみたいなと思ってdev.toのことを色々調べてて少し知見がたまったので共有してみます。 この記事はOkinawa.rb Advent Calendar 2017 7日目の記事です。 Twitterやってるのでよかったらフォローしてください🙋♀️ @saboyut
ISUCON7本戦に「railsへの執着はもはや煩悩の域であり、開発者一同は瞑想したほうがいいと思います。」チーム (@cnosuke, @rkmathi, @k0kubun) で参加し、4位でした。 本戦の概要 予選より参加者は少ないと思うので軽く解説しておくと、クッキークリッカーを模したトラフィックのほとんどがWebSocketのアプリで、1万桁とかのスコアを計算する都合ほとんどのチームのボトルネックが最後までBigintの演算になるような問題でした。 僕らは15:00くらいに1位になり、その後はスコアをそれほど改善できず終わってしまいました。 方針 「@k0kubun 氏のチューニングした3倍速いRubyで優勝したらまじかっけーっす!」って話をした。 #isucon— FUJI Goro (@__gfx__) 2017年11月25日 最近Ruby向けのJITコンパイラを開発している
はじめに 業務で使っているわけではないのですが、個人的にコツコツVue.jsの勉強をしています。 今回は今まで勉強したことを整理する意味合いも兼ねて、チュートリアルのようなものを作成したいと思います。 見ていただいた方の参考になれば嬉しいです。 また、JavaScriptに関しては書き慣れていないので、もしもっと良い書き方などありましたらご意見いただけると幸いです。 なお、テストコードはまだ書けておりません。。。 次回の記事で各コンポーネントのユニットテストを書きたいと思っています。 2017/09/20 追記 試しに書いたテストコードの差分を、記事の最後に追記しました。 作るもの 簡単なTODOアプリです。 (どっかのサービスに似ていると言わないでください。。。) TODOの管理はRailsのAPIで実施します。 前提条件及び環境 Ruby、Rails、Node.jsの環境をご用意くださ
日報一覧画面最近、プライベートな時間をつかってRepostというオープンソースの日報共有アプリケーションを開発しています。 投稿した日報に対して、コメントや絵文字でリアクションすることでチームでのコミュニケーションを活性化させることを目的としています。日報版Slackのようなイメージです。 まだ開発着手から1ヶ月ということもあり、バージョン0.0.1でまともに稼働できる段階ではないですが、開発のモチベーションを高めるためにも記事を書いてみました。 技術スタック チャンネル作成画面RepostはフロントエンドにReduxを採用し、SPAとして構築しています。APIサーバとしてのバックエンドはRuby on Railsで開発しています。また、エディタ部分はDraft.jsを用いてMarkdownエディタを実装しているところです。 Draft.jsについては、過去にとあるプロダクトに採用した経験
はじめに こんにちは。KitchHikeエンジニアの小川です。KitchHikeでは主にサーバーサイドを担当しています。 少し前のものですが、「DHHはどのようにRailsのコントローラを書くのか (原文)」というすばらしい記事があります。Railsのコントローラ分割の(DHH流)ベストプラクティスについて解説した記事なのですが、私はこの記事に大変感銘を受け、KitchHikeのルーティング定義にもこのプラクティスを取り入れるようになりました。 本日はこのDHH流ルーティングを取り入れることで得られるメリット、実際の routes.rb でのルーティング定義のしかたについて紹介したいと思います。 DHH流ルーティングとは?何がうれしいの? 詳しくは元記事を是非とも読んで下さい・・・なのですが、かいつまむと、ここで示されているのはたったひとつの単純明快なルールです。 コントローラはデフォルト
(訳注: 2016/3/2、頂いたフィードバックをもとに記事を修正いたしました。) Ruby on Railsは最近、急激に注目を集めていますが、その原因はほとんど、この言語が斬新なテクノロジーとしてもてはやされたことと、タイミングにあります。技術的な優位性は時間の経過とともに失われますから、タイミングがよかっただけでは、一過性のブームに終わり、このムーブメントの隆盛は長続きしません。従って、「Railsがいかにして、適切な技術としての位置を維持し続けるるだけでなく、影響力とコミュニティを拡大し続けてきたのか」をより多くの人に説明していく必要があります。そして、その維持・拡大を可能にした/していく要因は、物議を醸すことさえあるRailsの基本原則にあると考えています。 この基本原則はここ10年ほどの間に進化を続けてきましたが、最も強固な柱となっているルールはやはり、公開当初から制定されてい
Webアプリを作っていてよく出くわすのがファイルアップロードですね。単純にアップロードするだけなら実装自体はたいしたことないものですが、より良くしようと思うと想像以上に奥が深く…悩ましい沼感があります🤔 今回は今までファイルアップロードを実装していく中で手に入れた改善ポイントを紹介していきます。これで最速・最高のファイルアップロードに1歩でも近づけられればと思います。 なお、僕が普段開発をしているアーキテクチャの都合上、 nginx Rails の話が出てきますが一部を除きWebアプリなら普遍的に使える話だと思います。 2つの側面から紹介します。 UI編 と パフォーマンス編 です。 UI編は、HTML5を中心に使い勝手を向上させるためのポイントを紹介します。パフォーマンス編ではRailsのファイルアップロードを約10倍高速化⚡️した事例を紹介します。それでは長いですが、よろしくお願いし
この記事は Akatsuki Advent Calendar 2016 の1日目です。 はじめに アカツキで、ソーシャルゲームのバックエンドやサーバーアプリ、その他つらみなどを担当している@the40sanです。 この記事では、実際に開発/運用されているソーシャルゲームインフラのアーキテクチャや、Ruby on Railsで構築された中〜大規模なAPIサーバーに関するtipsを紹介したいと思います。 インフラ構成 アカツキのソーシャルゲームは、バックエンドにAWSを利用しています。 構成例(全体) 弊社プロダクトの構成の例です。全体でみるとこんな感じになります。 APIサーバー ゲームのロジックなどが実装されたサーバーアプリが動いているサーバーです。 WebAPIによってアクセスします。 アカツキでは、Ruby on Rails + Unicorn + nginxの構成がほとんどです。 A
はじめに Railsでアプリケーションを開発していると、E2Eの試験としてfeature specを書くことはよくあると思いますが、JavaScriptで実装したフロントエンドのモジュールやライブラリのユニットテストは「feature specがあるから大丈夫」とおざなりになっていませんか?E2Eテストですべて網羅的に検証できていれば良いという意見には一理あるのですが、UIやUXをはじめとして、フロントエンドの要件が大きく複雑になる傾向にある最近のWEBアプリケーションにおいては、フロントエンドのユニットテストがあることのメリットは大きいと考えています。またfeature specはえてして実行時間が長く、ユーザーの操作パターンをすべて網羅的に検証するのは現実的ではありません。 今回の記事では、バックエンドのフレームワークとしてRails、フロントエンドのフレームワークとしてVue.jsを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く