Got the error "Failed to decode downloaded font OTS parsing error: invalid version tag" and looks like the font can be read/decoded by the browser as the font can be previewed in the browser:
Making it seems that the reason why TinyMCE is not loading the fonts correctly..
..is due to incorrect mime type of text/html:
Although the font can be previewed by the browser, it looks like it is from previous successfully loaded font. Meaning, the browser aggressively caches the fonts, making it look like there is a very serious error, e.g., incorrect mime type of text/html when it should be application/woff, when in reality it is just a 404 that resulted to a 404 page(seemingly), yet without the status code of 404. A page is text/html.
The docker built just don't have font files in it.
Suggestions like nginx has missing mime types for the fonts, made the error looks complex than it really is.
404s are mostly a page, so that might be reason for the content type of text/html being reported by the browser. The browser might be returning a page, but it's hard to actually know since what the browser previews is the actual font, not a page. As for why the app is not returning status code of 404, would have to find out.
Happy Coding!
Tuesday, January 17, 2017
nginx proxy https node express
server { listen 443 ssl; server_name domain.name.here.com; ssl_certificate /usr/local/etc/nginx/cert.crt; ssl_certificate_key /usr/local/etc/nginx/cert.key; location / { proxy_pass https://127.0.0.1:3000; proxy_set_header host $host; # proxy_connect_timeout 600; # proxy_send_timeout 600; # proxy_read_timeout 600; # send_timeout 600; } }
To create a certificate in homebrew'd nginx:
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /usr/local/etc/nginx/cert.key -out /usr/local/etc/nginx/cert.crt
Friday, January 13, 2017
Protobufjs unresolvable field type
If you got this error, one cause is there are many roots. Even if ecommerce.proto below imports the common.proto, protobufjs won't be able to resolve the message type if they are in different roots.
Instead of:
One solution:
Another solution:
Happy Coding!
Instead of:
const common = protobufjs.loadSync('common.proto'); const ecommerce = protobufjs.loadSync('ecommerce.proto'); const hr = protobufjs.loadSync('hr.proto');
One solution:
const common = protobufjs.loadSync('common.proto'); protobufjs.loadSync('ecommerce.proto', common); protobufjs.loadSync('hr.proto', common);
Another solution:
const root = protobufjs.loadSync([ 'common.proto', 'ecommerce.proto', 'hr.proto' ]);
Happy Coding!
Thursday, January 12, 2017
TypeScript + enum + node that works
If you have an internal module in TypeScript and use it on node, and wanted to add an enum on it:
task.ts:
Then the reading the value of enum would result to runtime error: 'com is not defined':
If we try to move the enum Status and make it node-compatible by putting it on separate file without the module namespace and exporting the enum, the task.ts will be interpreted as external module instead, and as such, all dotted names will be interpreted as external modules too and would result to compile-time error if they are not imported, e.g., TypeScript will complain that it has no exported member uuid on com.anicehumble even there is one defined on an internal module, as all names under com.anicehumble will now be interpreted as external modules instead.
When a module become an external one like the code below, all members (e.g., uuid) under the module com.anicehumble should be moved to task.ts and cannot be defined anymore in an internal module on a separate file; or if it will not be inlined in task.ts, uuid should be implemented as external module, and it should be imported like the importing of Enums from the-enums.ts below:
the-enums.ts:
task.ts:
To maintain the internal-ness of a TypeScript module, we will just simulate the enum, and then for the enum-using node, it will just import the external module version of the enum.
So let's define the task's status enum and make it an external module version of an enum instead. You might be wondering why we need to use const instead of enum. Later, the advantage of using const over enum will be apparent.
tasks-status-enum.ts
task.ts:
The internal module version of the enum is the export type Status = 0 | 1 | 2. We will not be directly using the numbers in node, as it will look like magic numbers, we just add that to constraint the values that can be assigned to Task's status. The code below uses magic number:
For enum-using node, this is how enum will be used:
app.ts:
And this will not work, as the status value is constrained to 0, 1, 2 values only:
This will not compile as type Status and number are not type-compatible:
and so is this, even if the value of 2 of n is in the allowable values of Status:
And now for the interesting part, we can make things more discoverable if we will make the simulated enum have a type of com.anicehumble.Status:
tasks-status-enum.ts
Adding the type to the constant, that external module version of simulated enum is now related to the internal module version of the enum (i.e., export type Status = 0 | 1 | 2)
With real enum, the type cannot be added, the following is invalid:
Update
Had I known TypeScript's const enum from the start, this post will not be written. Use const enum, it's better than what was suggested here.
Happy Coding!
task.ts:
module com.anicehumble { export enum Status { PENDING = 0, IN_PROGRESS = 1, COMPLETED = 2 } export interface Task { uuid: com.anicehumble.uuid; ownedBy: string; title: string; status: Status; } }
Then the reading the value of enum would result to runtime error: 'com is not defined':
console.log(com.anicehumble.Status.IN_PROGRESS);
If we try to move the enum Status and make it node-compatible by putting it on separate file without the module namespace and exporting the enum, the task.ts will be interpreted as external module instead, and as such, all dotted names will be interpreted as external modules too and would result to compile-time error if they are not imported, e.g., TypeScript will complain that it has no exported member uuid on com.anicehumble even there is one defined on an internal module, as all names under com.anicehumble will now be interpreted as external modules instead.
When a module become an external one like the code below, all members (e.g., uuid) under the module com.anicehumble should be moved to task.ts and cannot be defined anymore in an internal module on a separate file; or if it will not be inlined in task.ts, uuid should be implemented as external module, and it should be imported like the importing of Enums from the-enums.ts below:
the-enums.ts:
export enum Status { PENDING = 0, IN_PROGRESS = 1, COMPLETED = 2 }
task.ts:
import * as Enums from './the-enums'; module com.anicehumble { export interface Task { uuid: com.anicehumble.uuid; // TypeScript will complain com.anicehumble 'has no exported member uuid' even it is defined in an internal module on a separate file. ownedBy: string; title: string; status: Enums.Status; } }
To maintain the internal-ness of a TypeScript module, we will just simulate the enum, and then for the enum-using node, it will just import the external module version of the enum.
So let's define the task's status enum and make it an external module version of an enum instead. You might be wondering why we need to use const instead of enum. Later, the advantage of using const over enum will be apparent.
tasks-status-enum.ts
export const PENDING = 0; export const IN_PROGRESS = 1; export const COMPLETED = 2;
task.ts:
module com.anicehumble { export type Status = 0 | 1 | 2; export interface Task { uuid: com.anicehumble.uuid; ownedBy: string; title: string; status: Status; } }
The internal module version of the enum is the export type Status = 0 | 1 | 2. We will not be directly using the numbers in node, as it will look like magic numbers, we just add that to constraint the values that can be assigned to Task's status. The code below uses magic number:
const t : com.anicehumble.Task = <any>{}; t.status = 2; // http://stackoverflow.com/questions/47882/what-is-a-magic-number-and-why-is-it-bad
For enum-using node, this is how enum will be used:
app.ts:
import * as TaskStatus from './task-status-enum'; const t : com.anicehumble.Task = <any>{}; t.status = TaskStatus.IN_PROGRESS; console.log(TaskStatus.IN_PROGRESS); // no more undefined error
And this will not work, as the status value is constrained to 0, 1, 2 values only:
t.status = 42; // compile error: 42 is not assignable to type Status
This will not compile as type Status and number are not type-compatible:
const n: number = 42; t.status = n; // compile error: number is not assignable to type Status
and so is this, even if the value of 2 of n is in the allowable values of Status:
const n: number = 2; t.status = n; // compile error: number is not assignable to type Status
And now for the interesting part, we can make things more discoverable if we will make the simulated enum have a type of com.anicehumble.Status:
tasks-status-enum.ts
export const PENDING : com.anicehumble.Status = 0; export const IN_PROGRESS: com.anicehumble.Status = 1; export const COMPLETED: com.anicehumble.Status = 2;
Adding the type to the constant, that external module version of simulated enum is now related to the internal module version of the enum (i.e., export type Status = 0 | 1 | 2)
With real enum, the type cannot be added, the following is invalid:
export enum Status { PENDING : com.anicehumble.Status = 0, IN_PROGRESS: com.anicehumble.Status = 1, COMPLETED: com.anicehumble.Status = 2 }
Update
Had I known TypeScript's const enum from the start, this post will not be written. Use const enum, it's better than what was suggested here.
Happy Coding!
Sunday, January 1, 2017
Error: request entity too large
return this.$http.post( '/great/api/-core/file/jpg', formData, { transformRequest: angular.identity // , headers: { 'Content-Type': undefined } // uncomment this to remove the error: Request Entity Too Large });
Happy Coding!
Subscribe to:
Posts (Atom)