All posts by admin

TIL : Capybara and AJAX


# spec/support/wait_for_ajax.rb 
module WaitForAjax 
  def wait_for_ajax 
    Timeout.timeout(Capybara.default_max_wait_time) do
      loop until finished_all_ajax_requests? 

  def finished_all_ajax_requests?

RSpec.configure do |config| 
  config.include WaitForAjax, type: :feature 


click_link "Check validity"
click_link "Create" # if this is a button that depends on "Check validity" to be disabled/enabled, it will have the correct status before the test is executed


TIL : New Structural Elements Added To HTML5

Element Description
<header>  Introduction of “sectioning elements”: an article, a section, the entire document (header page). Typically the header of a Web site that appears on top of each page, or a header of a long <article> or of a long <section>
<footer>  Contains the footer of a site, a long <article>, or a long <section>
<nav>  Section that contains the main navigation links (within the document or to other pages).
<article>  Independent content, which can be individually extracted from the document and syndicated (RSS or equivalent) without penalizing its understanding. Typically a blog post.
<section>  Generic section used to group different articles for different purposes or subjects or to define the different sections of a single article. Generally used with a header.
<time>  Used for marking up times and dates.
<aside>  Section whose content is not necessarily directly related to the main content that surrounds it, but can provide additional information.
<figure>  and <figcaption>  Used to encapsulate a figure as a single item, and contains a caption for the figure, respectively.
<main>  The main element represents the main content of the body of a document or application. The main content area consists of content that is directly related to or expands upon the central topic of a document or central functionality of an application. There can be only one <main> element in a document.


Source : edX Course “HTML5 Part 1: HTML5 Coding Essentials and Best Practices

Avoid Over-engineering!

  • Never build beyond the application requirements at the time you are writing the code.
  • If you do not have concrete requirements, don’t write any code.
  • Don’t jump to a model prematurely; there are often simple ways, such as using Booleans and denormalization, to avoid using adding additional models.
  • If there is no user interface for adding, removing, or managing data, there is no need for a model. A denormalized column populated by a hash or array of possi- ble values is fine.

source : Rails AntiPatterns : Best Practice Ruby On Rails Refactoring – by Chad Pytel and Tamer Saleh