Are you working with social media influencers? Wondering how to vet and recruit influencers? In this article, you’ll discover four tools to manage your influencer relationships. #1: Identify and Vet Influencers With Influence.co and Social Blade Influence.co is a tool that helps you easily find and connect with influencers who want to work with brands. [...]
The post 4 Tools to Find and Manage Influencers appeared first on .
SelectListActions is a jQuery plugin that allows you to perform several actions with HTML Select lists.
‘Vanilla’ is a free Landing Page HTML template by UIdeck built using the Bootstrap framework. Features include all the elements you’ll need for a standard Landing Page including clear intro CTA button, services, team, testimonial, pricing table, Google Maps and enquiry form.
As programming languages go, JavaScript’s development has been positively frantic in the last few years. With each year now seeing a new release of the ECMAScript specification, it’s easy to get confused about JavaScript versioning, which version supports what, and how you can future-proof your code.
To better understand the how and why behind this seemingly constant stream of new features, let’s take a brief look at the history of the JavaScript and JavaScript versioning, and find out why the standardization process is so important.
The prototype of JavaScript was written in just ten days in May 1995 by Brendan Eich. He was initially recruited to implement a Scheme runtime for Netscape Navigator, but the management team pushed for a C-style language that would complement the then recently released Java.
JavaScript made its debut in version 2 of Netscape Navigator in December 1995. The following year, Microsoft reverse-engineered JavaScript to create their own version, calling it JScript. JScript shipped with version 3 of the Internet Explorer browser, and was almost identical to JavaScript — even including all the same bugs and quirks — but it did have some extra Internet Explorer-only features.
The necessity of ensuring that JScript (and any other variants) remained compatible with JavaScript motivated Netscape and Sun Microsystems to standardize the language. They did this with the help of the European Computer Manufacturers Association, who would host the standard. The standardized language was called ECMAScript to avoid infringing on Sun’s Java trademark — a move that caused a fair deal of confusion. Eventually ECMAScript was used to refer to the specification, and JavaScript was (and still is) used to refer to the language itself.
The working group in charge of JavaScript versioning and maintaining ECMAScript is known as Technical Committee 39, or TC39. It’s made up of representatives from all the major browser vendors such as Apple, Google, Microsoft and Mozilla, as well as invited experts and delegates from other companies with an interest in the development of the Web. They have regular meetings to decide on how the language will develop.
When JavaScript was standardized by TC39 in 1997, the specification was known as ECMAScript version 1. Subsequent versions of ECMAScript were initially released on an annual basis, but ultimately became sporadic due to the lack of consensus and the unmanageably large feature set surrounding ECMAScript 4. This version was thus terminated and downsized into 3.1, but wasn’t finalized under that moniker, instead eventually evolving into ECMAScript 5. This was released in December 2009, 10 years after ECMAScript 3, and introduced a JSON serialization API, Function.prototype.bind, and strict mode, amongst other capabilities. A maintenance release to clarify some of the ambiguity of the latest iteration, 5.1, was released two years later.
Do you want to dive deeper into the history of JavaScript? Then check out chapter one of JavaScript: Novice to Ninja, 2nd Edition.
With the resolution of TC39’s disagreement resulting from ECMAScript 4, Brendan Eich stressed the need for nearer-term, smaller releases. The first of these new specifications was ES2015 (originally named ECMAScript 6, or ES6). This edition was a large but necessary foundation to support the future, annual JavaScript versioning. It includes many features that are well-loved by many developers today, such as:
ES2015 was the first offering to follow the TC39 process, a proposal-based model for discussing and adopting elements.
Continue reading %ES6 (ES2015) and Beyond: Understanding JavaScript Versioning%
Sails.js is a Node.js MVC (model–view–controller) framework that follows the “convention over configuration” principle. It’s inspired by the popular Ruby on Rails web framework, and allows you to quickly build REST APIs, single-page apps and real-time (WebSockets-based) apps. It makes extensive use of code generators that allow you to build your application with less writing of code—particularly of common code that can be otherwise scaffolded.
The framework is built on top of Express.js, one of the most popular Node.js libraries, and Socket.io, a JavaScript library/engine for adding real-time, bidirectional, event-based communication to applications. At the time of writing, the official stable version of Sails.js is 0.12.14, which is available from npm. Sails.js version 1.0 has not officially been released, but according to Sails.js creators, version 1.0 is already used in some production applications, and they even recommend using it when starting new projects.
Sails.js has many great features:
There are currently a few important cons, such as:
Software development is all about building abstractions. Sails.js is a high-level abstraction layer on top of Express.js (which itself is an abstraction over Node’s HTTP modules) that provides routing, middleware, file serving and so on. It also adds a powerful ORM/ODM, the MVC architectural pattern, and a powerful generator CLI (among other features).
You can build web applications using Node’s low-level HTTP service and other utility modules (such as the filesystem module) but it’s not recommended except for the sake of learning the Node.js platform. You can also take a step up and use Express.js, which is a popular, lightweight framework for building web apps.
You’ll have routing and other useful constructs for web apps, but you’ll need to take care of pretty much everything from configuration, file structure and code organization to working with databases.
Express doesn’t offer any built-in tool to help you with database access, so you’ll need to bring together the required technologies to build a complete web application. This is what’s called a stack. Web developers, using JavaScript, mostly use the popular MEAN stack, which stands for MongoDB, ExpressJS, AngularJS and Node.js.
MongoDB is the preferred database system among Node/Express developers, but you can use any database you want. The most important point here is that Express doesn’t provide any built-in APIs when it comes to databases.
One key feature of Sails.js is Waterline, a powerful ORM (object relational mapper) for SQL-based databases and ODM (object document mapper) for NoSQL document-based databases. Waterline abstracts away all the complexities when working with databases and, most importantly, with Waterline you don’t have to make the decision of choosing a database system when you’re just starting development. It also doesn’t intimidate you when your client hasn’t yet decided on the database technology to use.
You can start building you application without a single line of configuration. In fact, you don’t have to install a database system at all initially. Thanks to the built-in sails-disk NeDB-based file database, you can transparently use the file system to store and retrieve data for testing your application functionality.
Once you’re ready and you have decided on the convenient database system you want to use for your project, you can then simply switch the database by installing the relevant adapter for your database system. Waterline has official adapters for popular relational database systems such as MySQL and PostgreSQL and the NoSQL databases, such as MongoDB and Redis, and the community has also built numerous adapters for the other popular database systems such as Oracle, MSSQL, DB2, SQLite, CouchDB and neo4j. In case when you can’t find an adapter for the database system you want to use, you can develop your own custom adapter.
Waterline abstracts away the differences between different database systems and allows you to have a normalized interface for your application to communicate with any supported database system. You don’t have to work with SQL or any low-level API (for NoSQL databases) but that doesn’t mean you can’t (at least for SQL-based databases and MongoDB).
There are situations when you need to write custom SQL, for example, for performance reasons, for working with complex database requirements, or for accessing database-specific features. In this case, you can use the .query() method available only on the Waterline models that are configured to use SQL systems (you can find more information about query() from the docs).
Since different database systems have common and database-specific features, the Waterline ORM/ODM can only be good for you as long as you only constrain yourself to use the common features. Also, if you use raw SQL or native MongoDB APIs, you’ll lose many of the features of Waterline, including the ability to switch between different databases.
Now that we’ve covered the basic concepts and features of Sails.js, let’s see how you can quickly get started using Sails.js to create new projects and lift them.
Before you can use Sails.js, you need to have a development environment with Node.js (and npm) installed. You can install both of them by heading to the official Node.js website and downloading the right installer for your operating system.
Make sure, also, to install whatever database management system you want to use with Sails.js (either a relational or a NoSQL database). If you’re not interested by using a full-fledged database system, at this point, you can still work with Sails.js thanks to sails-disk, which allows you to have a file-based database out of the box.
After satisfying the working development requirements, you can head over to your terminal (Linux and macOS) or command prompt (Windows) and install the Sails.js Command Line Utility, globally, from npm:
sudo npm install sails -g
If you want to install the latest 1.0 version to try the new features, you need to use the beta version:
npm install sails@beta -g
You may or may not need sudo to install packages globally depending on your npm configuration.
After installing the Sails.js CLI, you can go ahead and scaffold a new project with one command:
sails new sailsdemo
This will create a new folder for your project named sailsdemo on your current directory. You can also scaffold your project files inside an existing folder with this:
sails new .
You can scaffold a new Sails.js project without a front end with this:
sails new sailsdemo --no-frontend
Find more information about the features of the CLI from the docs.
Here’s a screenshot of a project generated using the Sails.js CLI:
A Sails.js project is a Node.js module with a package.json and a node_modules folder. You may also notice the presence of Gruntfile.js. Sails.js uses Grunt as a build tool for building front-end assets.
If you’re building an app for the browser, you’re in luck. Sails ships with Grunt — which means your entire front-end asset workflow is completely customizable, and comes with support for all of the great Grunt modules which are already out there. That includes support for Less, Sass, Stylus, CoffeeScript, JST, Jade, Handlebars, Dust, and many more. When you’re ready to go into production, your assets are minified and gzipped automatically. You can even compile your static assets and push them out to a CDN like CloudFront to make your app load even faster. (You can read more about these points on the Sails.js website.)
You can also use Gulp or Webpack as your build system instead of Grunt, with custom generators. See the sails-generate-new-gulp and sails-webpack projects on GitHub.
For more community generators, see this documentation page on the Sails.js site.
The project contains many configuration files and folders. Most of them are self explanatory, but let’s go over the ones you’ll be working with most of the time:
api/controllers: this is the folder where controllers live. Controllers correspond to the C part in MVC. It’s where the business logic for your application exists.api/models: the folder where models exist. Models correspond to the M part of MVC architecture. This is where you need to put classes or objects that map to your SQL/NoSQL data.api/policies: this is the folder where you need to put policies for your applicationapi/responses: this folder contains server response logic such as functions to handle the 404 and 500 responses, etc.api/services: this where your app-wide services live. A service is a global class encapsulating common logic that can be used throughout many controllers../views: this folder contains templates used for displaying views. By default, this folder contains the ejs engine templates, but you can configure any Express-supported engine such as EJS, Jade, Handlebars, Mustache and Underscore etc../config: this folder contains many configuration files that enable you to configure every detail of your application, such as CORS, CSRF protection, i18n, http, settings for models, views, logging and policies etc. One important file that you’ll frequently use is config/routes.js, where you can create your application routes and map them to actual actions in the controllers or to views directly../assets: this is the folder where you can place any static files (CSS, JavaScript and images etc.) for your application.Continue reading %An Introduction to Sails.js%
Hapi.js is described as “a rich framework for building applications and services”. Hapi’s smart defaults make it a breeze to create JSON APIs, and its modular design and plugin system allow you to easily extend or modify its behavior.
The recent release of version 17.0 has fully embraced async and await, so you’ll be writing code that appears synchronous but is non-blocking and avoids callback hell. Win-win.
In this article, we’ll be building the following API for a typical blog from scratch:
# RESTful actions for fetching, creating, updating and deleting articles
GET /articles articles#index
GET /articles/:id articles#show
POST /articles articles#create
PUT /articles/:id articles#update
DELETE /articles/:id articles#destroy
# Nested routes for creating and deleting comments
POST /articles/:id/comments comments#create
DELETE /articles/:id/comments comments#destroy
# Authentication with JSON Web Tokens (JWT)
POST /authentications authentications#create
The article will cover:
/.Make sure you’ve got a recent version of Node.js installed; node -v should return 8.9.0 or higher.
Download the starting code from here with git:
git clone https://github.com/markbrown4/hapi-api.git
cd hapi-api
npm install
Open up package.json and you’ll see that the “start” script runs server.js with nodemon. This will take care of restarting the server for us when we change a file.
Run npm start and open http://localhost:3000/:
[{ "so": "hapi!" }]
Let’s look at the source:
// server.js
const Hapi = require('hapi')
// Configure the server instance
const server = Hapi.server({
host: 'localhost',
port: 3000
})
// Add routes
server.route({
method: 'GET',
path: '/',
handler: () => {
return [{ so: 'hapi!' }]
}
})
// Go!
server.start().then(() => {
console.log('Server running at:', server.info.uri)
}).catch(err => {
console.log(err)
process.exit(1)
})
The route handler is the most interesting part of this code. Replace it with the code below, comment out the return lines one by one, and test the response in your browser.
server.route({
method: 'GET',
path: '/',
handler: () => {
// return [{ so: 'hapi!' }]
return 123
return `<h1><marquee>HTML <em>rules!</em></marquee></h1>`
return null
return new Error('Boom')
return Promise.resolve({ whoa: true })
return require('fs').createReadStream('index.html')
}
})
To send a response, you simply return a value and Hapi will send the appropriate body and headers.
Object will respond with stringified JSON and Content-Type: application/jsonString values will be Content-Type: text/htmlPromise or Stream.The handler function is often made async for cleaner control flow with Promises:
server.route({
method: 'GET',
path: '/',
handler: async () => {
let html = await Promise.resolve(`<h1>Google<h1>`)
html = html.replace('Google', 'Hapi')
return html
}
})
It’s not always cleaner with async though. Sometimes returning a Promise is simpler:
handler: () => {
return Promise.resolve(`<h1>Google<h1>`)
.then(html => html.replace('Google', 'Hapi'))
}
We’ll see better examples of how async helps us out when we start interacting with the database.
Like the popular Express.js framework, Hapi is a minimal framework that doesn’t provide any recommendations for the Model layer or persistence. You can choose any database and ORM that you’d like, or none — it’s up to you. We’ll be using SQLite and the Sequelize ORM in this tutorial to provide a clean API for interacting with the database.
SQLite comes pre-installed on macOS and most Linux distributions. You can check if it’s installed with sqlite -v. If not, you can find installation instructions at the SQLite website.
Sequelize works with many popular relational databases like Postgres or MySQL, so you’ll need to install both sequelize and the sqlite3 adapter:
npm install --save sequelize sqlite3
Let’s connect to our database and write our first table definition for articles:
// models.js
const path = require('path')
const Sequelize = require('sequelize')
// configure connection to db host, user, pass - not required for SQLite
const sequelize = new Sequelize(null, null, null, {
dialect: 'sqlite',
storage: path.join('tmp', 'db.sqlite') // SQLite persists its data directly to file
})
// Here we define our Article model with a title attribute of type string, and a body attribute of type text. By default, all tables get columns for id, createdAt, updatedAt as well.
const Article = sequelize.define('article', {
title: Sequelize.STRING,
body: Sequelize.TEXT
})
// Create table
Article.sync()
module.exports = {
Article
}
Let’s test out our new model by importing it and replacing our route handler with the following:
// server.js
const { Article } = require('./models')
server.route({
method: 'GET',
path: '/',
handler: () => {
// try commenting these lines out one at a time
return Article.findAll()
return Article.create({ title: 'Welcome to my blog', body: 'The happiest place on earth' })
return Article.findById(1)
return Article.update({ title: 'Learning Hapi', body: `JSON API's a breeze.` }, { where: { id: 1 } })
return Article.findAll()
return Article.destroy({ where: { id: 1 } })
return Article.findAll()
}
})
If you’re familiar with SQL or other ORM’s, the Sequelize API should be self explanatory, It’s built with Promises so it works great with Hapi’s async handlers too.
Note: using Article.sync() to create the tables or Article.sync({ force: true }) to drop and create are fine for the purposes of this demo. If you’re wanting to use this in production you should check out sequelize-cli and write Migrations for any schema changes.
Let’s build the following routes:
GET /articles fetch all articles
GET /articles/:id fetch article by id
POST /articles create article with `{ title, body }` params
PUT /articles/:id update article with `{ title, body }` params
DELETE /articles/:id delete article by id
Add a new file, routes.js, to separate the server config from the application logic:
// routes.js
const { Article } = require('./models')
exports.configureRoutes = (server) => {
// server.route accepts an object or an array
return server.route([{
method: 'GET',
path: '/articles',
handler: () => {
return Article.findAll()
}
}, {
method: 'GET',
// The curly braces are how we define params (variable path segments in the URL)
path: '/articles/{id}',
handler: (request) => {
return Article.findById(request.params.id)
}
}, {
method: 'POST',
path: '/articles',
handler: (request) => {
const article = Article.build(request.payload.article)
return article.save()
}
}, {
// method can be an array
method: ['PUT', 'PATCH'],
path: '/articles/{id}',
handler: async (request) => {
const article = await Article.findById(request.params.id)
article.update(request.payload.article)
return article.save()
}
}, {
method: 'DELETE',
path: '/articles/{id}',
handler: async (request) => {
const article = await Article.findById(request.params.id)
return article.destroy()
}
}])
}
Import and configure our routes before we start the server:
// server.js
const Hapi = require('hapi')
const { configureRoutes } = require('./routes')
const server = Hapi.server({
host: 'localhost',
port: 3000
})
// This function will allow us to easily extend it later
const main = async () => {
await configureRoutes(server)
await server.start()
return server
}
main().then(server => {
console.log('Server running at:', server.info.uri)
}).catch(err => {
console.log(err)
process.exit(1)
})
Continue reading %Building Apps and Services with the Hapi.js Framework%