$ brew install irssi gmp | |
$ cpan install Crypt::OpenSSL::Bignum Crypt::Blowfish Crypt::DH::GMP | |
$ echo '[[ $SHLVL -eq 1 ]] && eval "$(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib)"' >> ~/.bashrc | |
$ mkdir -p ~/.irssi/scripts/autorun | |
$ (cd ~/.irssi/scripts/; wget https://freenode.net/sasl/cap_sasl.pl; ln -s ../cap_sasl.pl autorun/) | |
$ irssi | |
/sasl set <network> <nick> <password> DH-BLOWFISH | |
/sasl save |
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.
lib/
is intended for code that can run as-issrc/
is intended for code that needs to be manipulated before it can be used
""" pipelines.py """ | |
import collections | |
import scrapy | |
import scrapy.contrib.exporter | |
import myproject | |
class SitemapPipeline(object): | |
""" | |
Sitemap builder |
We will compare ASP.NET and Node.js for backend programming.
Source codes from examples.
This document was published on 21.09.2015 for a freelance employer. Some changes since then (14.02.2016):
- Koa.js no longer uses co-routines, it has switched to Babel's
async/await
.yield
andawait
are used almost in the same way, so I see no point to rewrite the examples.
- Close Android File Transfer
- Open Activity Monitor and kill “Android File Transfer Agent”
- Go to where you installed “Android File Transfer.app” (I have it under /Applications)
- Ctrl+click –> “Show package contents”
- Go to Contents/Resources
- Rename “Android File Transfer Agent” to e.g. “Android File Transfer Agent_DISABLED”
- Then go to “/Users/username/Library/Application Support/Google/Android File Transfer” and again rename the Agent app.
#!/bin/bash | |
if [ -z "$1" ] | |
then | |
echo "Please specify a folder" | |
exit | |
fi | |
if [ -z "$2" ] | |
then |
Method | Side effects1 | State updates2 | Example uses |
---|---|---|---|
Mounting | |||
componentWillMount |
✓ | Constructor equivalent for createClass |
|
render |
Create and return element(s) | ||
componentDidMount |
✓ | ✓ | DOM manipulations, network requests, etc. |
Updating | |||
componentWillReceiveProps |
✓ | Update state based on changed props |
CertSimple just wrote a blog post arguing ES2017's async/await was the best thing to happen with JavaScript. I wholeheartedly agree.
In short, one of the (few?) good things about JavaScript used to be how well it handled asynchronous requests. This was mostly thanks to its Scheme-inherited implementation of functions and closures. That, though, was also one of its worst faults, because it led to the "callback hell", an seemingly unavoidable pattern that made highly asynchronous JS code almost unreadable. Many solutions attempted to solve that, but most failed. Promises almost did it, but failed too. Finally, async/await is here and, combined with Promises, it solves the problem for good. On this post, I'll explain why that is the case and trace a link between promises, async/await, the do-notation and monads.
First, let's illustrate the 3 styles by implementing