Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
会社勤めのエンジニアが開発したサービスを買い取って独立した話 - Qiita
なぜかミクシィ社でエンジニアだった人々がアドベントカレンダーを書くことになってしまったex-mixi Advent Calendar 2017、12月11日担当の @tnj です。 一般的に、会社を退職することになったら退職届というものを会社に提出することになります。その退職理由には「一身上の都合」と書くのが通例だと思いますが、私はちょっと変わった退職の経緯を持っているので、今回はそれについて共有してみたいと思います。思いのほか長くなってしまいましたが、社会人歴10年目のソフトウェアエンジニアのキャリアの変遷の一例としてお楽しみください。 TL;DR Android開発者としての自分の経験を基に新規事業を立ち上げることになり、エンジニアとして参画したつもりが気がつくと事業責任者になり、果ては事業を買い取って経営者になった 好きでやってる話だしまあなんだかんだ乗り越えていけるよねと思ってたら
CTOのやるべきことは何なのか？（翻訳と考察） - Qiita
【背景】 この記事はQuoraの「What does a CTO do?」という質問に対するAmr-Awadallah氏のよくまとまった回答の翻訳です（本人から許可取得済）。 私はMAMORIO株式会社でCTOをしているのですが、最近自分の仕事が何なのかよく分からなくなってきたことがこの記事を書こうと思ったきっかけです。 私はこの記事でいう所の「雑草CTO」であり、たまたま会社の初期に私以外に適任者がいなかったので成り行きで就任し現在に至ります。 そして、人数もプレッシャーも少ない総初期は来た玉は打つの姿勢でコーディングから渉外まで何でもこなしていましたが、メンバーが増え、それよりも早いペースでユーザーと仕事が増えてくると、自分の職務を定義しやることとやらないことをはっきり分ける必要が出てきます。 この翻訳が同じような状況にあるCTOの助けになればと思いますし、誤訳等があったら指摘してくだ
個人プロダクト開発で、困った時にどうするか - Qiita
Introduction Webエンジニアであれば、「自分達の手で0から作ったプロダクトで世の中を変えられたらな、それで食べてけたらなー」と夢見ることがあるのではないでしょうか。 私たちは、夫婦2人で、プライベートの時間でアプリ開発と運営をしています。その過程でぶつかった壁がとてもたくさんありました。 全てのプロダクトで当てはまることではなく、あくまでも特定のケースなのでなかなか一般的な手法として展開しずらい事例が多いですが、これらの困った体験が何かのお役に立てればと思い書きました。 実際に起こったこともあれば、起こってはないが、経験から推測するとこのケースはこう対処すればいいのかもしれないと思ったこと、の両者を記載しています。本やブログなどで得た知識をそのまま紹介するというよりは、実体験に基づいた内容になっています。 人が集まるまで 作る時間が無い 困った たくさん機能開発したいが、普段
JSONスキーマはじめの一歩 - Qiita
JSONスキーマと、RubyでJSONスキーマつかってvalidationするやり方を解説します。 全てがJSONになる - ✘╹◡╹✘ を読んでJSON schema良さ気だと思ったけど、まだ使ったことない人向けの記事です。 JSONスキーマって？ 本屋のJSONデータを返すAPIがあったとします。 { "name": "おしゃれな本屋", "place": { "large_area": "おしゃれな地域", "small_area": "おしゃれな街", "address": "おしゃれな街のおしゃれな建物", "latitude": 33.333, "longitude": 33.333 } } これに対して、JSONスキーマを用意しておけば、１つ１つの値の有無や型をチェックできます。生成したJSONが意図したものになっているかテストするのに便利です。 JSONスキーマといいつつJ
RailsでAPI開発する前に知っておくべき４つのこと - Qiita
$ bin/rails g scaffold user name:string mail:string password:string invoke active_record create db/migrate/20151214145437_create_users.rb create app/models/user.rb invoke test_unit create test/models/user_test.rb create test/fixtures/users.yml invoke api_resource_route route resources :users, except: [:new, :edit] invoke scaffold_controller create app/controllers/users_controller.rb invoke test_un
「WebAPI 設計のベストプラクティス」に対する所感 - Qiita
「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図
Awesome Ruby : 素晴しい Ruby のライブラリ・ツール・フレームワーク・ソフトウェアの数々
元記事: Awesome Ruby Ruby 以外の言語, ソフトウェアについては を参照してください. Awesome List in Qiita Awesome Java Awesome JavaScript Awesome Node.js Awesome Python Awesome Go Awesome Selenium Awesome Appium 抽象化 ActiveInteraction - アプリケーション固有のビジネスロジックを管理します. Cells - Rails のコンポーネントを表示します. Decent Exposure - コントローラに宣言的インタフェースを提供するヘルパー. dry-rb - 共通のタスクをカプセル化するための, 次世代 Ruby ライブラリコレクションです. Interactor - 1回のリクエストで複雑なインタラクションを実行するため
FormオブジェクトのURLの渡し方について - Qiita
Rails Advent Calendarの2日目の記事である Rails4でFormオブジェクトを作る際に気をつける3つのポイント｜江の島エンジニアBlog を読んだんですが、ちょっと気になる所があったんで突っ込みを入れてみる。 モデル層であるFormオブジェクトにURLを返すためのメソッド定義するのは、あんまりよろしく無いんじゃないかと思う。 そもそもurl_helperをちゃんと動かすためにはホスト名やポート等のリクエスト情報が必要で、この例の様に相対パスを出力するだけなら使えなくもないけどモデル層から呼ばれることは、余り想定されていない。 デコレーター層に生やすか、そもそも組込みのヘルパーを使うべきではないかと思う。 ちなみにform_forヘルパーが中で使っているのはpolymorphic_pathというヘルパーで、地味だし自分も良く忘れるのだが、この例ではこれがそのまま使えるは
Rails のサービスクラスでのマイルールとちょっとしたコツ - Qiita
動機 Railsにおけるサービスクラスのオリジナルルール という記事をたまたま見つけ、「自分ならこう書くかな」と感じたことがいくつかあったので、記事にしてみました。 なお の参考記事の中でさらに参考にされている 肥大化したActiveRecordモデルをリファクタリングする7つの方法(翻訳) という記事のコードを、この記事でも説明のために用いようと思います。そこで、以下は 2 つの記事をこのように呼称します。 参考記事 1: Railsにおけるサービスクラスのオリジナルルール 参考記事 2: 肥大化したActiveRecordモデルをリファクタリングする7つの方法(翻訳) さらに翻訳元の記事: 7 Patterns to Refactor Fat ActiveRecord Models ルール 1. クラス名は「動詞 (+ 目的語)」にする 参考記事 1 のものとほぼ同じルールです。末尾に
先人達から学ぶRailsのテーブル設計 - Qiita
はじめに Ruby on Rails Advent Calendar 2017 - Qiita の4日目の記事です。 背景 Railsのテーブル設計について、社内で議論することは多いのですが、サービスの要となる部分であるが故、社外にER図を公開するケースは少なく、自分達のサービス開発時以外にテーブル設計を学ぶ機会が少ないです。 目的 OSSで公開されているRailsアプリケーションのソースコードから、テーブル設計に関するデータをまとめることで、テーブル設計時の議論に活かすことを目的とします。 具体的には、「1テーブルが持つ情報量として、どれくらいのカラム数が妥当なんだろう…？」や「テーブル名やカラム名を命名する時にどちらの単語の方が一般的に使われているんだろう…？」といった疑問点の解消を目指します。 方法 OSSで公開されているRailsアプリケーションの見つけ方 AwesomeRails
DBのint枯渇を目の前にした僕らは - Qiita
MySQLのint型は符号付きで -2147483647〜2147483647 の範囲をサポートし、レコードを記録する際にこの範囲を超えて記録しようとするともちろんエラーとなります。 これは、長い運用の末にデータが膨大になり、ついにintのサポート範囲が枯渇寸前となった話です。 方針 DBはAWS Auroraを使用しており、アプリケーションはRailsで構築されています。RailsのMigrationはデフォルトでidカラムをAUTO INCREMENTのint型で作成します1。サービスの特徴としては他のサービスと比較すると高トラフィックに晒されるもので、DBに大量のログを記録する必要がありテーブルによっては1ヶ月で1億レコード以上記録されるものもあります。対処方法を検討し始めた時にはidは既に18億を超えており、やるべきことは対象のテーブルのidカラム、及びそのidを関連として保持して
悪しきRailsプロジェクトの特徴 - Qiita
0. 背景 職場その他でいくつかのRailsプロジェクトを見て来て、同じ組織であってもリポジトリが違えば雰囲気が全然違うなと思い、その中でもこれはダメだろうと思ったことがありましたので、自分の備忘録も兼ねて記述します。 ここ２年ぐらいで出会ったRailsプロジェクトを見て感じた例ですので、他にも挙げようと思えば挙げられると思いますが、出会った中での記述ということでご理解ください。 また、技術的、より個別的な事象についてはRails AntiPatternsを読むといいかもしれません。 1. rubocopを導入していない rubocopはRuby Style Guideをベースにしたrubyの静的解析ツールです。Rubyを使ったことのある人で知らない人はいないでしょう。また、Ruby Style Guideについても、Rubyを勉強する初期に一読しておかなければいけないと言われる代物です。
そろそろポリモーフィック関連について一言いっとくか - Qiita
class Notification < ActiveRecord::Base belongs_to :notifiable, polymorphic: true end class Message < ActiveRecord::Base has_one :notification, as: :notifiable end class Like < ActiveRecord::Base has_one :notification, as: :notifiable end 一行で色んなクラスに対する関連が指定できて便利感がある。 だからって、これを安易に使う前にちゃんと考えよう。 ポリモーフィック関連は単に関連の定義を省力化するためのものじゃない。 ポリモーフィックという名前が示す様に、これは多態性を持ったものに対する関連を定義する事であって、インターフェースに対する関連の定義だということ
Railsのポリモーフィック関連とはなんなのか - Qiita
はじめに Railsのポリモーフィック（polymorphic、多態性）関連について、実装方法を説明している記事は見かけるのですが、実際これがどんなものでどんな時に便利なのかを説明している記事があまりなく、よくわからないで使っている人もいるようなので本記事を書きました。 実装方法そのものについては詳細には説明しませんので、Railsのポリモーフィック関連をどう書くのかを知らない方はまずは公式ドキュメントを読んでいただけると理解が早いかと思います。 ボリュームは少ないので、2分もかからないかと思います。 Rails Guides: 2.9 ポリモーフィック関連付け "どんなものか"について、先に結論 ポリモーフィックとはダックタイピングの一種であり、 別の言い方をするとGoFのデザインパターンで言うところの「プログラムは実装に対してではなく、インターフェースに対して行う（Program to
マイクロサービス時代に捧ぐ、Railsでの中規模APIサーバ開発のための技術構成 - Qiita
初めまして、qsona (tw) と申します。Ruby on Rails Advent Calendar 2016 6日目の記事になります。 Rails歴は10ヶ月で、もちろんAdvent Calendarへの参戦も初です。 全体的に生意気な内容と思いますが、 じゃんじゃんマサカリ投げてください お手柔らかにお願いします。 はじめに 環境 JSONを返すAPIで、データベースはRDBを想定してます。 あんまり関係ないですが一応、Rails5 (api mode) + MySQLを想定しています。 マイクロサービスとしてのバックエンドに使う技術スタックの必要な要件 マイクロサービスの良いところは、サービスごとに合った別々の技術が使えるということです。 とはいえ、一般的な組織であれば、学習コストの面などから、ファーストチョイスとなる言語があり、普通の要件に対してはその言語を使う、ということにな
独断と偏見で選ぶ、新人Rubyプログラマの為の技術書21選 - Qiita
株式会社LITALICOでWebエンジニア（Rails）を担当しています、@YudaiTsukamotoです。 この記事は『LITALICO Advent Calendar 2016』21日目の記事です。 はじめに 業務なり趣味なりでプログラミングを学習していくと、技術書を読む機会が誰しも有るのではないでしょうか？ 初心者や、新人プログラマの時は、対象となる無数の技術書の中から自分にとって良い技術書を探す事は中々難しいのかなと思います。 技術書を選定する基準はいくつか有ると思いますが 「他人がオススメしている」 という選定軸はそれなりに有効であるという事を私は初心者から頑張って勉強した過程の中で学びました。 そこでLITALICO Advent Calendar 2016の21日目の本日、 不詳ながら私が新卒1年目の時に読んだ技術書(サイトも含む)の中から21個をピックアップしてみようかと
Rails Viewの表示のためにDecoratorを用意してHelperとModelを助ける - Qiita
def publication_status(article) if article.published_at? "Published at #{article.published_at.strftime('%A, %B %e')}" else "Unpublished" end end ただし、これだと違和感があって、BookというモデルもArticleモデルと同じようなメソッドを作ろうとしたときに、少しだけしかフォーマットの仕方を変えないのに同じようなメソッドを作る必要が出てきます。 book_publication_status や article_publication_status のような2つのメソッドになるかと思いますが、グローバルな空間にこのように同じようなメソッドを作り続けるのは嫌ですね。 だったらModelで定義してしまえ！とModelで定義して下記のように呼び出すこと
Rails：Service層を運用して良かったところ、悪かったところ - Qiita
1年前くらいにRailsの設計にDDD(ドメイン駆動設計)のService層を導入し、Modelの肥大化対策をしました。 この記事では、まずどのようなルールでService層が組み込まれているかと、1年間運用してみて良かったところ、悪かったところの感想を書きます。 [2018/05追記] 最近ではサービス層の導入は賛否両論あるようなので、導入する際は自分のプロジェクトに合っているかどうかを十分にご検討ください！ Service層を導入するきっかけになった問題点 Modelの肥大化 Model間の複雑な依存関係 多数のミドルウェアの導入による複雑さの倍増 これらにより.. メンテナンスやテストがしにくい コードが整理されていないのでとにかく読みづらい Model複雑化の例 <ユーザがECサイトの商品をお気に入り(like)にするメソッドを書く場合> 処理に関連するテーブル my_itemsテ
サービスクラスについては僕も悪かったと思っているけど、それでもCQSは実現したいんだ - Qiita
このエントリは Ruby on Rails Advent Calendar 15 日目です。（遅くなってすいません） 同時に 14 日目のじょーかーさんのエントリへのアンサーエントリでもあります。 （まあ、じょーかーさんがこの Advent Calendar に登録したときに、タイトルから内容を推察してこれを書くことを決めましたが、実際のところ、あまりアンサーにもカウンターにもなってないし、全然関係ない内容と言えないこともないので、まあサービスクラスについては僕も推奨したことがあるし、僕も反省してるんですよ程度に読んでもらえると幸いです。） まずはじめにごめんなさい 3 年くらい前に僕は Rails にサービスクラスというものを導入するといいことがあるよと書いたのだけど、それからいくつもの Rails アプリケーションを見たり、実際に自分で開発したりして、うーんって思うことも増えてきたので
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
