You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Instantly share code, notes, and snippets.
Mariusz Nowak
medikoo
Engineering modern web applications
JavaScript/Node.js/HTML/Serverless
This section describes the conventions used here to describe type signatures.
A [T] is an array-like value (only ever used read-only in this API), i.e., one with an integer length and whose indexed properties from 0 to length - 1 are of type T.
A type T? should be read as T | undefined -- that is, an optional value that may be undefined.
Bootstrap for static websites with Grunt and Webmake (featuring Stylus, cssmin, htmlmin, jshint...)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Today I had a brief debate on twitter about AMD vs CommonJS, https://twitter.com/TechWraith/status/441387541778808832. It's a debate worth having for sure. But I had to bail out of this one. The thing that annoyed me is that the first argument that people bring up to disquality AMD is "the syntax is too complex". I disagree with this. There are lots of reasons to prefer CommonJS over AMD, but the module authoring syntax is not a very good one. There was also a related statement that AMD authoring introduces more "cognitive overhead". This is absolutely true. But I don't consider this to be synonymous with "complexity" by any means.
So I thought I'd explore some comparable examples. Here's a simple one that was offered up by someone else in the thread. This was on twitter so I can forgive erring on the side of brevity.
From Imperium by Ryszard Kapuściński, first published in Poland in 1993:
Page 277
It is not surprising that the Ukrainian Language Society was among those groups attacked and oppressed. The revolution in the Ukraine, like everywhere else, was waged at least partly over language. Half of the fifty-two million inhabitants of the Ukraine either do not speak Ukrainian, or they speak it poorly. Three hundred and fifty years of Russification have inevitably produced such a result. The ban against printing book in Ukrainian was in force for decades. As early as 1876, Alexander II ordered that instruction in Ukrainian schools take place only in Russian. Several months ago I visited the third-largest city in the Ukraine — Donetsk. The battle to open at least one elementary school teaching Ukrainian was by then already in its second year. Teachers assembled children in the park and there instructed them in Ukrainian. Teaching Ukrainian? Why, that was counterrevolution, an imperialist conspiracy!
Front-Trends 2014 extended review with links and stuff
DISCLAIMER:
The whole content comes "as is".
All commentaries refer to author's impression.
Some inconsistency possible as well.
The few details (mainly useful links) were added while transcribing notes.
While the following structure is not an absolute requirement or enforced by the tools, it is a recommendation based on what the JavaScript and in particular Node community at large have been following by convention.
Beyond a suggested structure, no tooling recommendations, or sub-module structure is outlined here.
Directories
lib/ is intended for code that can run as-is
src/ is intended for code that needs to be manipulated before it can be used
There are certain files created by particular editors, IDEs, operating systems, etc., that do not belong in a repository. But adding system-specific files to the repo's .gitignore is considered a poor practice. This file should only exclude files and directories that are a part of the package that should not be versioned (such as the node_modules directory) as well as files that are generated (and regenerated) as artifacts of a build process.
All other files should be in your own global gitignore file:
Create a file called .gitignore in your home directory and add any filepath patterns you want to ignore.
Tell git where your global gitignore file is.
Note: The specific name and path you choose aren't important as long as you configure git to find it, as shown below.
You could substitute .config/git/ignore for .gitignore in your home directory, if you prefer.
I've been looking for the best Linux backup system, and also reading lots of HN comments.
Instead of putting pros and cons of every backup system I'll just list some deal-breakers which would disqualify them.
Also I would like that you, the HN community, would add more deal breakers for these or other backup systems if you know some more and at the same time, if you have data to disprove some of the deal-breakers listed here (benchmarks, info about something being true for older releases but is fixed on newer releases), please share it so that I can edit this list accordingly.
Do zespołu konsultantów pracujących bezpośrednio dla UNCTAD (organ ONZ) poszukujemy programisty/programistki JavaScript (HTML5 + Node.js)
Zajmujemy się tworzeniem aplikacji, których długofalowym celem jest zmniejszenie szarej strefy w krajach rozwijających się, a konkretniej umożliwienie obywatelom rejestracji różnego rodzaju działalności przez internet.
Realizujemy projekty z wykorzystaniem najnowszych otwartych technologii (full-stack JavaScript, bazowany na ECMAScript 5 oraz implementowalnych w ES5 funkcjonalnościach z najnowszego standardu ES). Pracujemy na in house'owym, modularnym stack’u, bazującym na dziesiątkach niezależnych, stale rozwijanych modułach, w większości opublikowanych na npm’ie. Dajemy możliwość upubliczniania generycznej części pracy na Github'ie lub podobnych serwisach.
Jeżeli lubisz JavaScript, lubisz dyskutować o rozwoju języka, omawiać ciekawe algorytmiczne problemy, i przede wszystkim chcesz się rozwijać jako programista JavaScript, to