$ rails new . -n ActiveAdminDemo -c tailwind -a propshaft --skip-test --skip-system-test
$ rails g active_admin:install --skip-users
$ rails tailwindcss:install
$ rails generate active_admin:assets
$ cat tailwind-active_admin.config.js | sed 's/require(`@activeadmin\/activeadmin\/plugin`)/require(`${activeAdminPath}\/plugin.js`)/g' > config/tailwind-active_admin.config.js
$ rm tailwind-active_admin.config.js
$ bundle binstub tailwindcss-rails
$ rails generate active_admin:views
Latency Comparison Numbers (~2012) | |
---------------------------------- | |
L1 cache reference 0.5 ns | |
Branch mispredict 5 ns | |
L2 cache reference 7 ns 14x L1 cache | |
Mutex lock/unlock 25 ns | |
Main memory reference 100 ns 20x L2 cache, 200x L1 cache | |
Compress 1K bytes with Zippy 3,000 ns 3 us | |
Send 1K bytes over 1 Gbps network 10,000 ns 10 us | |
Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD |
# Author: Pieter Noordhuis | |
# Description: Simple demo to showcase Redis PubSub with EventMachine | |
# | |
# Update 7 Oct 2010: | |
# - This example does *not* appear to work with Chrome >=6.0. Apparently, | |
# the WebSocket protocol implementation in the cramp gem does not work | |
# well with Chrome's (newer) WebSocket implementation. | |
# | |
# Requirements: | |
# - rubygems: eventmachine, thin, cramp, sinatra, yajl-ruby |
Note: Before diving into this implementation, consider that there are more popular and potentially easier-to-use solutions for implementing Sign in with Apple in Ruby on Rails, such as Omniauth. If you prefer a more out-of-the-box approach, explore those alternatives.
This implementation of the Sign in with Apple service in Ruby on Rails is suitable for APIs, eliminating the need for views.
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.
I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.
Chrome 51 has some pretty wild behaviour related to console.log
in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft
,elem.offsetTop
,elem.offsetWidth
,elem.offsetHeight
,elem.offsetParent
Made this example to show how to use Next.js router for a 100% SPA (no JS server) app.
You use Next.js router like normally, but don't define getStaticProps
and such. Instead you do client-only fetching with swr
, react-query
, or similar methods.
You can generate HTML fallback for the page if there's something meaningful to show before you "know" the params. (Remember, HTML is static, so it can't respond to dynamic query. But it can be different per route.)
Don't like Next? Here's how to do the same in Gatsby.
In August 2007 a hacker found a way to expose the PHP source code on facebook.com. He retrieved two files and then emailed them to me, and I wrote about the issue:
http://techcrunch.com/2007/08/11/facebook-source-code-leaked/
It became a big deal:
http://www.techmeme.com/070812/p1#a070812p1
The two files are index.php (the homepage) and search.php (the search page)