エンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『@type』のコンテンツです。
はじめに これは Ruby on Rails Advent Calendar 2014 - Qiita の19日目です 18日目 @yancya さんの Rails でシングルじゃないテーブル継承 - Qiita でした 19日目:オレオレRailsアプリを支えるインフラの作り方 最近では Heroku などのPaaS*1 も普及してインフラのことを知らなくても簡単にアプリを公開することができるようになりました。 しかしトラブルシューティングやパフォーマンスチューニングなどを行うにはアプリケーションコードだけで完結することは少なく、全体像を把握する必要があります。Railsアプリケーションの裏でどんな構成で動いているかを知っておくかは重要なのでざっくりと紹介したいと思います。 書かないこと Railsアプリを作る上でのノウハウ 便利なgemや外部サービスの紹介 *2 監視 アラート検知 モ
アメーバ事業本部コミュニティ事業部の大﨑 (@hiroosak)です。 24LOGというサービスの開発を担当しています。 サイバーエージェントでは、コミュニティサービスが多数存在しているのですが、 実は、その中のいくつかのサービスでRailsが使われています。 ですが、社内・社外問わずあまり知られていないようです。 なので、今回は、Railsを使ったプロジェクトでは どのように開発が行われているかを簡単に紹介したいと思います。 基本構成 構成図の概要は上の図の通りです。 (監視サーバなどは上の図から省いています) 静的なファイルは、社内の共通ストレージに置き、検索については 社内のラボチームで用意したシステムと連携しています。 なのでプロジェクトのチームでは、主に app, db, cache, queue を見ています。 ちなみに、rubyのバージョンは主に2.0, railsは3.2で
おそらく多くのソーシャル系アプリにあてはまるRailsのプチ・デザインパターン的な話。 ぼくが今やっているEast Meet Eastには、ユーザごとに数多くのプロフィール属性があります。名前、性別、生年月日、郵便番号、職業などなど、カラム数にしてざっと25個。これを、全部ひとつのusersテーブルに詰め込むのは、コードの見通しという観点からも性能の観点からも、あまりよろしくありません。 なぜならば、ユーザ関連の情報を扱う局面としては主に メールアドレスとパスワードなどを使ってログインする(アカウント情報) プロフィール情報で条件を指定してユーザを検索・推薦する(プロフィール情報) という2つの独立性の高いユースケースにわかれるため、ログイン処理をやってるときにはプロフィール情報はいらないし、プロフィールを検索してるときにはメールアドレスやパスワードをロードするのは無駄です。また、開発やデ
先週日曜日に総額480円、プログラムコード200行、作業時間8時間で「給与明細.net」(http://www.給与明細.net)というWebサービスを作ってリリースをしました。これは給与支払明細書のPDFをWebで簡単に作れるWebサービスです。 シンプルな内容なので開発を開始してから8時間以内の作業でリリースできました。このエントリではサクッとサービスを開発してリリースするまでの僕なりの方法を紹介します。 特長 無料 会員登録不要 Excelから一括作成できる(CSVではない) オープンソース(MITライセンス) 目次 解決したい課題を見つける ドメインを取得する サイトマップとURLを決定する よいツールを集める まずデプロイ(公開)する そこそこのデザインにする 最低の機能をつけたらリリースする 広めるための準備をする おまけ:コードをかく 解決したい課題を見つける これがないとそ
(PgDay2012発表資料) SQLにとって、なぜO/Rマッパーが重要かを説明した資料です。Read less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く