Just connect; Done;
I thought so… The internet is not that easy of a place huh?! They told everybody would be connected, and promised again with IPv6, but I’m disgressing.
# Rails developers have long had bad experiences with fixtures for | |
# several reasons, including misuse. | |
# | |
# Misuse of fixtures is characterized by having a huge number of them, | |
# requiring the developer to maintain a lot of data and creating dependencies | |
# between tests. In my experience working (and rescuing) many applications, 80% | |
# of fixtures are only used by 20% of tests. | |
# | |
# An example of such tests is one assuring that a given SQL query with | |
# GROUP BY and ORDER BY conditions returns the correct result set. As expected, |
if Rails.env.production? | |
require 'fileutils' | |
FileUtils.mkdir_p(Rails.root.join("tmp", "stylesheets", "admin")) | |
template_path_one = "#{Gem.loaded_specs['activeadmin'].full_gem_path}/app/assets/stylesheets" | |
template_path_two = "#{Gem.loaded_specs['activeadmin'].full_gem_path}/lib/active_admin/sass" | |
old_compile_path = "#{Rails.root}/public/stylesheets/admin" | |
new_compile_path = "#{Rails.root}/tmp/stylesheets/admin" | |
Sass::Plugin::remove_template_location template_path_one |
(function (originalOpen) { | |
XMLHttpRequest.prototype.open = function (method, url, async, user, password) { | |
if (url.match(/limits/)) url = "REJECTED"; | |
originalOpen.call(this, method, url, async, user, password); | |
}; | |
})(XMLHttpRequest.prototype.open); |
package str | |
func Reverse(input string) string { | |
return "" | |
} |
const React = require("react"); | |
const ReactDOM = require("react-dom"); | |
const reducer = (state, action) => { | |
switch (action) { | |
case "INCREMENT": | |
return state + 1; | |
case "DECREMENT": | |
return state - 1; | |
default: |
Real world application with a lot of pages (or "screens") have to deal with problem managing the pages' DOM and memory efficiently and at the same provide a nice smooth transition effect between pages. This is not a real problem when you do it in native apps since Android or iOS already handle the hard work for you, but when come to JavaScript, HTML, and CSS, running on mobile browsers, this is the real challenge.
There are 2 common approaches to solve this problem:
display
) to transit between pages.# Start by stopping the built-in Apache, if it's running, and prevent it from starting on boot.
# This is one of very few times you'll need to use sudo:
sudo launchctl unload /System/Library/LaunchDaemons/org.apache.httpd.plist 2>/dev/null
# We need to tap homebrew-dupes because "homebrew-apache/httpd22" relies on "homebrew-dupes/zlib"
//If you need to spy or stub the global require function in node.js, don't try to spy on the require function itself..you aren't going //to be successful. | |
//Instead, spy on the require.extensions object like so: | |
var spies = {}; | |
spies.require = sinon.spy(require.extensions, '.js'); | |
//Then when you need to assert you can do stuff like: | |
spies.require.firstCall.args[1].should.include("path/to/some/module"); |
I'm a fan of MiniTest::Spec. It strikes a nice balance between the simplicity of TestUnit and the readable syntax of RSpec. When I first switched from RSpec to MiniTest::Spec, one thing I was worried I would miss was the ability to add matchers. (A note in terminology: "matchers" in MiniTest::Spec refer to something completely different than "matchers" in RSpec. I won't get into it, but from now on, let's use the proper term: "expectations").
Let's take a look in the code (I'm specifically referring to the gem, not the standard library that's built into Ruby 1.9):
# minitest/spec.rb
module MiniTest::Expectations