| { | |
| "auto_complete_commit_on_tab": true, | |
| "color_scheme": "Packages/Oceanic Next Color Scheme/Oceanic Next.tmTheme", | |
| "draw_white_space": "all", | |
| "font_face": "Fira Mono", | |
| "font_size": 20, | |
| "tab_size": 2, | |
| "theme": "Brogrammer.sublime-theme", | |
| "translate_tabs_to_spaces": true, | |
| "trim_automatic_white_space": true, |
The Goal of this gist is to help understand service worker. It's not for diving deep in the core, but to understand the concepts, benefits and trade offs.
I have listed three resources which helped me greatly to unfurl the curtains:
| const sql = require("mssql"); | |
| require("msnodesqlv8"); | |
| const conn = new sql.Connection({ | |
| database: "db_name", | |
| server: "server_name", | |
| driver: "msnodesqlv8", | |
| options: { | |
| trustedConnection: true | |
| } | |
| }; |
Redis is Database whereas RabbitMQ was designed as a message router or message-orientated-middleware (mom), so I'm sure if you look for benchmarks, you'll find that RabbitMQ will outperform Redis when it comes to message routing.
RabbitMQ is written in Erlang which was specifically designed by the telecom industry to route messages, you get clustering out of the box due to it being written in Erlang which means in a clustered environment, RabbitMQ will outperform Redis even further.
Furthermore, you get guaranteed delivery of messages due to the AMQP protocol, in other words, if the network drops while consuming the message, the consumer won't be able to say thanks for the message, so the consumer will drop the message and Rabbit will requeue the message, if you publish a message and the queue didn't say thanks to the publisher due to network problems or timeouts, Rabbit will drop the message and the publisher will keep on trying to publish the message. You can have publish retries with backoff policies, so
Issue: Automattic/kue#130
Here's the rough set of steps we typically follow to repair various kue issues we see regularly: (note that some of these apply only to our fork - that has the ability to do "locks" so jobs for - in our case - a single user are serialized (users are differentiated based on their email address).
Failed Jobs Not Showing When there are failed jobs (the sidebar says non-zero), but none show in the list, use the follow this procedure to repair them:
| /** | |
| * GET /api/scraping | |
| * Web scraping example using Cheerio library. | |
| */ | |
| exports.getScraping = function(req, res, next) { | |
| cheerio = require('cheerio'); | |
| request = require('request'); | |
| request.get('https://news.ycombinator.com/', function(err, request, body) { | |
| if (err) return next(err); |
Though we're focused more on server setup procedure in this document, I will still give a very brief explanation in laymen terms for ELK. To those who are starting new in this stack, must have already heard of MVC (Model View Controller), so take it like this:
=> Elasticsearch (for Storage, Indexing & Search)=> Kibana (for DataViz & G-Man, yeah the one in half life 😏)=> Logstash (For Logs & Filtering)
| const server = restify.createServer(); | |
| const https_server = restify.createServer({ | |
| certificate: fs.readFileSync('certs/ca.crt'), | |
| key: fs.readFileSync('certs/key.pem'), | |
| name: 'Sellnews-Trends', | |
| }, err => { | |
| console.log(err, err.stack); | |
| }); | |
| const setup_server = function(server) { |