Some random notes on the pangs of ember. Will be expanding as they are uncovered.
Say you have a form that maps to a model, something like:
<form>
<fieldset>
<legend>Who are you?</legend>| /** | |
| * jQuery.support.checkboxIndeterminate | |
| * https://github.com/RupW | |
| * Tests for HTML 5 checkbox 'indeterminate' property | |
| * http://www.w3.org/TR/html5/the-input-element.html#dom-input-indeterminate | |
| * http://www.w3.org/TR/html5/number-state.html#checkbox-state | |
| * | |
| * Released under the same license as jQuery | |
| * http://docs.jquery.com/License | |
| * |
Article by Faruk Ateş
One of the most commonly overlooked and under-refined elements of a website is its pagination controls. In many cases, these are treated as an afterthought. I rarely come across a website that has decent pagination, and it always makes me wonder why so few manage to get it right. After all, I'd say that pagination is pretty easy to get right. Alas, that doesn't seem the case, so after encouragement from Chris Messina on Flickr I decided to write my Pagination 101, hopefully it'll give you some clues as to what makes good pagination.
Before going into analyzing good and bad pagination, I want to explain just what I consider to be pagination: Pagination is any kind of control system that lets the user browse through pages of search results, archives, or any other kind of continued content. Search results are the obvious example, but it's good to realize that paginat
L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs
| # -*- encoding: utf-8 -*- | |
| Gem::Specification.new do |s| | |
| s.name = 'parallel_assets_compiler' | |
| s.version = '0.2.0' | |
| s.platform = Gem::Platform::RUBY | |
| s.author = 'Jørgen Orehøj Erichsen' | |
| s.email = '[email protected]' | |
| s.summary = 'Compile assets in parallel' | |
| s.description = 'Compile assets in parallel to speed up deployment' |
| # Nginx+Unicorn best-practices congifuration guide. Heartbleed fixed. | |
| # We use latest stable nginx with fresh **openssl**, **zlib** and **pcre** dependencies. | |
| # Some extra handy modules to use: --with-http_stub_status_module --with-http_gzip_static_module | |
| # | |
| # Deployment structure | |
| # | |
| # SERVER: | |
| # /etc/init.d/nginx (1. nginx) | |
| # /home/app/public_html/app_production/current (Capistrano directory) | |
| # |
| require 'parallel' # gem install parallel (https://github.com/grosser/parallel) | |
| # Monkey patch to Sprockets::StaticCompiler, a class provided by actionpack | |
| # that's used by the assets:precompile task. This patch uses the Parallel gem | |
| # to parallelize asset compilation in the simplest way possible. | |
| # | |
| # Parallel wraps Process.fork to handle things like inter-process communication | |
| # via pipes and determining the maximum number of processes to run based on | |
| # your system's total logical processors. So far only tested on MRI 1.9.3 on OS X. | |
| module Sprockets |
| # SSL self signed localhost for rails start to finish, no red warnings. | |
| # 1) Create your private key (any password will do, we remove it below) | |
| $ openssl genrsa -des3 -out server.orig.key 2048 | |
| # 2) Remove the password | |
| $ openssl rsa -in server.orig.key -out server.key |
Web application frameworks have been developing fast in the past few years, and as the technologies that they're built on top of get more advanced, each of these frameworks is able to provide newer features to help developers build more complex applications. This year, we've seen the release of a new class of application frameworks that takes advantage of JavaScript's ability to be both on the client and the server. What this allows these frameworks to do is provide both a new level of abstraction by sharing code between client and server, as well as embrace the benefits of both client-side rendering and server-side rendering.
For the end user, they get smooth, desktop-like responsiveness from client-side rendering, while still being able to maintain the SEO and accessbility benefits of server-side rendering. For developers, that means writing less boilerplate code, and being able to focus more on writing the application logic.
Today, there are three main framew
| /* ---------------------------------------------------------- */ | |
| /* */ | |
| /* A media query that captures: */ | |
| /* */ | |
| /* - Retina iOS devices */ | |
| /* - Retina Macs running Safari */ | |
| /* - High DPI Windows PCs running IE 8 and above */ | |
| /* - Low DPI Windows PCs running IE, zoomed in */ | |
| /* - Low DPI Windows PCs and Macs running Firefox, zoomed in */ | |
| /* - Android hdpi devices and above */ |