ciplogic.com
Live with grace. Write superb software.

core-promise

After a bit of fiddling around I managed to convince the core-promise implementation to actually implement the Promise interface from the ES6 typescript definitions itself:

/**
 * Represents the completion of an asynchronous operation
 */
interface Promise<T> {
    /**
    * Attaches callbacks for the resolution and/or rejection of the Promise.
    * @param onfulfilled The callback to execute when the Promise is resolved.
    * @param onrejected The callback to execute when the Promise is rejected.
    * @returns A Promise for the completion of which ever callback is executed.
    */
    then<TResult>(onfulfilled?: (value: T) => TResult | PromiseLike<TResult>, onrejected?: (reason: any) => TResult | PromiseLike<TResult>)" Promise<TResult>;
    then<TResult>(onfulfilled?: (value: T) => TResult | PromiseLike<TResult>, onrejected?: (reason: any) => void): Promise<TResult>; 
    /**
     * Attaches a callback for only the rejection of the Promise.
     * @param onrejected The callback to execute when the Promise is rejected.
     * @returns A Promise for the completion of the callback.
     */
    catch(onrejected?: (reason: any) => T | PromiseLike<T>): Promise<T>;
    catch(onrejected?: (reason: any) => void): Promise<T>;
    [Symbol.toStringTag]: string;
}

Thus not only you have now all the test guarantees, you also get the API guarantees. Neat!

I am writing some unit tests for my TypeScript collection classes (actually migrating some older tests), and I decided in going with Mocha.

How easy it is? Well, as simple as 1, 2, 3 ... 4 :) :

1. Install the typing files

tsd install mocha
tsd install node
tsd install assert

2. Write your test(s)

For this example, I'm presenting you a super simple test, but obviously nothing stops you from adding new ones (check my github core-lang project for details):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/// <reference path="../../../typings/mocha/mocha.d.ts"/>
/// <reference path="../../../typings/node/node.d.ts"/>
/// <reference path="../../../typings/assert/assert.d.ts"/>
 
import { list, XIterable, XIterator } from "../../main/core/Iterable";
import assert = require("assert");
 
describe('ArrayList', function() {
    it('should allow filtering', function() {
        var items : XIterable<number> = list([1, 2, 3, 4]),
            filteredItems: XIterable<number>,
            iterator : XIterator<number>;
 
        filteredItems = items.filter(it => it % 2 == 0);
        iterator = filteredItems.iterator();
        
        assert.equal(iterator.next(), 2);
        assert.equal(iterator.next(), 4);
        assert.notEqual(iterator.hasNext(), true);
    });
});

3. Build your test(s)

I use Grunt, so I have (I deleted all the non test stuff), but is basically easy to see the target that is named "test" across all the plugins in the original full Grunt file:

It brings me great joy to announce the release of version 1.0.0 of core-lang, the collection classes I wrote for JavaScript.

Overview

With an API that is fully compatible with the JavaScript API, keeping the same signatures and behaviors for functions such as forEach, etc, but also inspired from groovy, having methods such as groupBy, chaining support, and full Promise support, allowing to deal with collections that contain promises, or are transformed to promises, using simple chainable calls.

How do you migrate an existing Apache server, to a brand new nginx installation for several websites that use PHP? This is a simple tutorial into changing an Apache installation into a nginx one, without having to change your existing websites.

nginx is a server that scales far better compared to apache running on the same hardware. The tutorial is not super CentOS specific, but all the commands were run on a CentOS.

The Apache server that was migrated, namely this blog, has several virtual hosts, that are all running PHP, some of them Joomla websites. The plan is to take them as they are, and have them available externally the same way as before, using the same virtual host names, the same folder locations, with the same users assigned to them.

The reason is that if we screw up something in the process, we can just revert to our old proven Apache, by just restarting the Apache service and shutting down nginx. Also we can minimize the downtime, since if done right it should be in the end just shutting down apache and starting nginx, but if it doesn't work we can quickly go back to serving the files with Apache until we figure out what is going on.

While it is simple, it is a pretty long read, so grab your coffee, and hack away:

 1. Install nginx

This is as simple as running:

yum install nginx

Make sure the /etc/nginx/conf.d/default.conf has the paths pointing to /var/www/html, or whatever was the default site for your Apache configuration. (In my case it was /var/www/blog).

OK, next

When creating websites performance is one of the main concerns that must be addressed. Fortunately with tools such as Google Page Speed measuring performance, with concrete actual improvement steps that can be taken. So when I've seen that the performance of this website was in the gutter, I know I had to take concrete actions:

1. Compression

The first quick win for a site is to activate compression.

Disqus Comments

comments powered by Disqus

Germanium

The one to rule them all. The browsers that is.

SharpKnight

SharpKnight is an Android chess game.

MagicGroup

MagicGroup is an eclipse plugin.