Some of the naming conventions we use at Sails for nouns like variables, parameters, property names, config settings, database attributes/columns/fields, and so on.
Naming is hard. And naming conventions usually end up being wrong, or incomplete at best.
This may be an unpopular opinion, but in my experience, coming up with new methodologies for variables and such doesn't usually create a lot of value for an individual developer. So why bother?
I’m looking for any tips or tricks for making chrome headless mode less detectable. Here is what I’ve done so far:
Set my args as follows:
const run = (async () => {
const args = [
'--no-sandbox',
'--disable-setuid-sandbox',
'--disable-infobars',
After hearing great points from the community, and experiencing the need for this in some of our projects, all but the bare bones Sails core is going to be pulled into plugins. The basic plugins will all be installed by default in new projects, but now it's possible to disable the things you don't want. It also makes it much easier to customize Sails for your needs, and probably enables all sorts of cool things none of us have even considered yet. ** More on this to come **
- REST blueprints will now be applied using the
controllershook, and configurable-- on by default.- Automatic controller routing (add a middleware method to a controller and you can hit it at
/controller/middleware) will also be applied via thecontrollershook, on by default, and is now considered part of the blueprints (the other blueprints just happen only to work if you have a model, since they need something to get allllll RESTful on.)
| # Install Node.js and friends | |
| # (From https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager) | |
| sudo apt-get install python-software-properties python g++ make | |
| sudo add-apt-repository ppa:chris-lea/node.js | |
| sudo apt-get update | |
| sudo apt-get install nodejs npm nodejs-dev | |
| # Install other tools we like | |
| sudo apt-get install git emacs |
The following is our development style guide. We put this together as a handy reference on how we write our code. We work on lots of projects, and using conventions offers advantages to everyone working with the code base. Writing new code is faster, maintaining old code is easier, and iterative feature development happens faster with consistent development styles used by everyone.
Even after agreeing on this guide, we've all been guilty of delighting in a bit of forbidden fruit. It's out of habit. It's not a big deal, let's just try to move towards standards as quickly as we can. In the mean time, if we see code that doesn't match up, and we have time, let's fix it.
As usual, feel free to pipe up with ideas and errata. That said, let's avoid religious wars and subjective rules-- everything below is here for a reason, and we want everybody on board with the why. Following rules without knowing why they exist is stupid. The goal is to make our code cleaner, our developm
| // *Usage* | |
| // Include the following as a bookmark: | |
| // javascript: var gistSrc = "https://raw.github.com/gist/4022488/d8b31cf4fb663ce2b1afee89f3bd6bf72479c10c/quick-veil.js";console.log("Toggling veil, please wait...");function loadScript(src, optionalCallback) { var s = document.createElement("script"); s.type = "text/javascript"; s.src = src; var context = document.getElementsByTagName('script')[0]; context.parentNode.insertBefore(s, context); s.async = true; s.addEventListener('load', optionalCallback);}if(typeof veil_liev !== "undefined" && veil_liev) { jQuery("#veil-liev").stop().fadeTo(250, 0, function() { console.log("Veil lifted."); veil_liev = false; jQuery("#veil-liev").remove(); });} else { function afterLoadScript() { drawVeil(0.65, function(v) { veil = v; console.log("Veil dropped."); veil_liev = true; }); } if(typeof veil_liev !== "undefined") { afterLoadScript(); } else { loadScript(gistSrc, afterLoadScript); }} | |
| // Source: | |
| var gistSrc = "https://raw.github.com/gist/4022488/d8b31cf |
| _.mixin({ | |
| // ### _.objMap | |
| // _.map for objects, keeps key/value associations | |
| objMap: function (input, mapper, context) { | |
| return _.reduce(input, function (obj, v, k) { | |
| obj[k] = mapper.call(context, v, k, input); | |
| return obj; | |
| }, {}, context); | |
| }, | |
| // ### _.objFilter |
| <!DOCTYPE html> | |
| <html> | |
| <head> | |
| <title>Test Swift CORS</title> | |
| <!-- Only using jQuery for jQuery.parseJSON --> | |
| <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script> | |
| </head> | |
| <body> | |
| <div style="border: thin solid grey; padding-left: 10px; width: 50%; margin-left: auto; margin-right: auto"> |
| require 'octokit' | |
| require 'csv' | |
| require 'date' | |
| # Github credentials to access your private project | |
| USERNAME="USER_NAME" | |
| PASSWORD="SEKRIT" | |
| # Project you want to export issues from | |
| USER="REPO_OWNER" | |
| PROJECT="REPO_NAME" |