List of helpful shortcuts for faster coding
If you have any other helpful shortcuts, feel free to add in the comments of this gist :)
What is the right programming language for you? Traditionally programming languages are created to concisely model a specific problem, or to maximize expression while solving a broad range of problems. Psychoanalysts have noted that many decisions we make as humans are not based on rational premises
In object-oriented development, we are all familiar with design patterns such as the Strategy pattern and Decorator pattern, and design principles such as SOLID. The functional programming community has design patterns and principles as well. This talk will provide an overview of some of these, and
FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.
window.onclick = () => { | |
// You MUST create the window on the same event | |
// tick/stack as the user-initiated event (e.g. click callback) | |
const googleWindow = window.open(); | |
// Do your async work | |
fakeAjax(response => { | |
// Change the URL of the window you created once you | |
// know what the full URL is! | |
googleWindow.location.replace(`https://google.com?q=${response}`); |
(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.
Many agree that the newly proposed srcset
attribute is much less syntactically intuitive than the widely appreciated picture
element. I hope that the WHATWG and W3C review all of the efforts that the web dev community have put into the picture
element proposal in their own community group and go back on this recent addition.
Syntax aside... if srcset
was here to stay regardless of what we want, is there any way we could make it work in existing browsers without introducing unnecessary overhead or potentially buggy markup? At a glance, it looks shaky to me.
The main problem is request overhead, and attempting to work around that.
Given the following markup, existing browsers will prefetch/fetch the image referenced in the src
attribute, and JavaScript can not prevent that request from going out. This means larger screen devices will request an unnecessary image for every imgset
on a page - not good.
<head> | |
<style type="text/css"> | |
picture source { | |
src: image-set(url({filename}@2x.{ext} 2x high-bandwidth)); | |
} | |
@media screen and (min-width:321px){ | |
picture source { | |
src: image-set(url({filename}-m.{ext}), url({filename}-m@2x.{ext} 2x high-bandwidth)); | |
} | |
} |
/* | |
* Normalized hide address bar for iOS & Android | |
* (c) Scott Jehl, scottjehl.com | |
* MIT License | |
*/ | |
(function( win ){ | |
var doc = win.document; | |
// If there's a hash, or addEventListener is undefined, stop here | |
if( !location.hash && win.addEventListener ){ |
// Source: http://www.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/platform/ColorData.gperf&exact_package=chromium&type=cs | |
// There's also an RGB one defined here: http://www.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/inspector/front-end/Color.js&exact_package=chromium&q=indianred&l=393 | |
var CSS_NAMED_COLORS = { | |
aliceblue: "#f0f8ff", | |
antiquewhite: "#faebd7", | |
aqua: "#00ffff", | |
aquamarine: "#7fffd4", | |
azure: "#f0ffff", | |
beige: "#f5f5dc", |