| # to generate your dhparam.pem file, run in the terminal | |
| openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048 |
| /* | |
| Utility to analyze bundle chunks over versions. | |
| Assumes: webpack has already created the bundle summary json file -> stats.json | |
| Parameters: | |
| version: (Optional) a string that labels the current bundle with the version | |
| provided and saves the summary in a csv file. | |
| Output: | |
| If run the first time, generates a csv file bundleAnalaysis.csv, which | |
| tracks bundle sizes by version. Adds one row with the current analysis. | |
| If run the next time, analyzes the current stats.json with the last row |
Today’s most web applications probably have these characteristics:
they are complex as such, they depend on many moving pieces (e.g. reverse proxy, cache, db, etc) require secure connections via TLS Here are quick tips I found useful to deploy such applications.
Technologies used:
Docker
| # Reference: https://www.exclamationlabs.com/blog/continuous-deployment-to-npm-using-gitlab-ci/ | |
| # GitLab uses docker in the background, so we need to specify the | |
| # image versions. This is useful because we're freely to use | |
| # multiple node versions to work with it. They come from the docker | |
| # repo. | |
| # Uses NodeJS V 9.4.0 | |
| image: node:9.4.0 | |
| # And to cache them as well. |
| CREATE TABLE IF NOT EXISTS `apps_countries_detailed` ( | |
| `id` int(5) NOT NULL AUTO_INCREMENT, | |
| `countryCode` char(2) NOT NULL DEFAULT '', | |
| `countryName` varchar(45) NOT NULL DEFAULT '', | |
| `currencyCode` char(3) DEFAULT NULL, | |
| `fipsCode` char(2) DEFAULT NULL, | |
| `isoNumeric` char(4) DEFAULT NULL, | |
| `north` varchar(30) DEFAULT NULL, | |
| `south` varchar(30) DEFAULT NULL, | |
| `east` varchar(30) DEFAULT NULL, |
| SELECT CONVERT_TZ(NOW(),'-07:00', city.TimeZone) AS Time, city.Name | |
| FROM city, country | |
| WHERE country.Name='USA' and city.CountryId= country.CountryId; |
| CREATE TABLE IF NOT EXISTS `countries` ( | |
| `id` int(11) NOT NULL AUTO_INCREMENT, | |
| `iso` char(2) NOT NULL, | |
| `name` varchar(80) NOT NULL, | |
| `nicename` varchar(80) NOT NULL, | |
| `iso3` char(3) DEFAULT NULL, | |
| `numcode` smallint(6) DEFAULT NULL, | |
| `phonecode` int(5) NOT NULL, | |
| PRIMARY KEY (`id`) | |
| ) ENGINE=MyISAM DEFAULT CHARSET=latin1; |
| CREATE TABLE `apps_countries` ( | |
| `id` int(11) NOT NULL auto_increment, | |
| `country_code` varchar(2) NOT NULL default '', | |
| `country_name` varchar(100) NOT NULL default '', | |
| PRIMARY KEY (`id`) | |
| ) ENGINE=MyISAM DEFAULT CHARSET=utf8; | |
| -- | |
| -- Dumping data for table `apps_countries` | |
| -- | |
| INSERT INTO `apps_countries` VALUES (null, 'AF', 'Afghanistan'); |
| * | |
| * Migration | |
| */ | |
| 'use strict'; | |
| module.exports = { | |
| up: function(queryInterface, Sequelize) { | |
| return queryInterface.createTable('Users', { | |
| firstName: { | |
| type: Sequelize.STRING | |
| }, |
| Actually - there is no a good answer to your question. Most of the architectures are usually carefully designed and finetuned during many experiments. | |
| I could share with you some of the rules of thumbs one should apply when designing its own architecture: | |
| Avoid a dimension collapse in the first layer. Let's assume that your input filter has a (n, n) spatial shape for RGB image. | |
| In this case, it is a good practice to set the filter numbers to be greater than n * n * 3 as this is the dimensionality of the input of a single filter. | |
| If you set smaller number - you could suffer from the fact that many useful pieces of information about the image are lost due to initialization which dropped informative dimensions. | |
| Of course - this is not a general rule - e.g. for a texture recognition, where image complexity is lower - a small number of filters might actually help. | |
| Think more about volume than filters number - when setting the number of filters it's important to think about the volume change instead of the chang |
