Installing pgsql as a aservice on Windows

Get the latest pgsql from here and if you need postgis from here.

Unpack the pgsql zip to a desired destination.

Create a directory for the db files.

Navigate to the bin folder of pgsql and run the following command: 

initdb -U postgres -E UTF-8 -A md5 -D <path to data directory> -W

When prompted, provide the master pass. Your console should look like this:

Now it's time to adjust the db cfg. You may find it in the db files folder, it is called "postgresql.conf". Make sure you adjust the port the db listens on and also that it is available for localhost:


# - Connection Settings -

listen_addresses = 'localhost'		# what IP address(es) to listen on;
					# comma-separated list of addresses;
					# defaults to 'localhost'; use '*' for all
					# (change requires restart)
#port = 5432				# (change requires restart)

By default pgsql listens on 5432. If you already have another pgsql live or need to change it for whatever reason, simply adjust the port value.

Once this is ready, it's time to create a service for our db (you may need to run the console as an admin though):

pg_ctl register -N ServiceName -U postgres -P <password> -D <path to data directory> -w

The console should look like this:

And the service should be visible in the service manager:

If you wish to rename the service then simply delete it and register again:

sc delete ServiceName

The final step is to adjust the service properties, such as a user that runs the service (by default it runs as NetworkService) or the startup mode:

Now, if you also need postgis, simply use the exe installer and you're good to go.

OGC xml schemas to c# classes using xsd.exe

The process of generating c# classes off the xsd is usually rather simple. One needs the xsd.exe utility (for example located here: C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools) and then a simple command to get things done:

xsd schema.xsd /c

Sometimes there may be some problems though with missing refs, namespaces and such.

In this example, I will generate classes for WMS 1.3.0 based on the OGC schemas - it is possible to grab them one by one, or all the goodies wrapped as a zip archive.

I have extracted WMS 1.3.0 schemas to f:\wms\schemas, so my command should look like this when in f:\wms (I have copied xsd.exe there too):

xsd schemas\capabilities_1_3_0.xsd /c

Unfortunately there are some problems and classes do not get generated:

The problem here is caused by unresolved references. Xsd was not able to find xlink.xsd. Although there is a xlink schema in OGC repo, this is not the one we're after. The one in question is the mentioned, and its schema definition is, pretty much as defined in the very beginning of the capabilities_1_3_0.xsd I am trying to process:

<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="" xmlns:xlink="" xmlns:wms="" xmlns="" elementFormDefault="qualified" version="">
		WMS is an OGC Standard.
		Copyright (c) 2004,2010 Open Geospatial Consortium.
		To obtain additional rights of use, visit .

	<import namespace="" schemaLocation=""/>

Unfortunately xsd.exe does not resolve the import automatically, so in order to make it work I just copied the xlinx.xsd to my schemas folder and specified it in the command:

xsd schemas\xlink.xsd schemas\capabilities_1_3_0.xsd /c

Looks like this did the trick and the classes got generated as expected. The complete set of files is here: (51.1KB)

PhantomJS test runner for ExtJs Jasmine test runner

Having borrowed some stuff from here I have extended my ExtJs Jasmine test runner so it can be used with PhantomJs.

The ExtJs Jasmine test runner as well as its new PhantomJs test runner have made it to a separate library called gm (see here how to use it); both test runners are actually the very first utils available ;)

So once you have PhantomJs installed and your tests created they can be executed in PhantomJs like this:

ExtJs source control package strategy for a utility library

So, after (re)reading the sencha docs and forums a couple of times I have come up with an alternate strategy for maintaining a utility library as a package... Not sure if it will not change at some point but so far it seems to be ok-ish...

Anyway, the requirements were:

  • it should be possible to share the lib between apps / projects (obviously)
  • the lib should have its own source control storage without having to use workspaces and such
  • in should be possible to pack it and deliver as a package in the future (not sure it it will ever be the case though ;)
  • It should be ready for the ExtJs 6 universal app usage
So what i did was:
  • I created a package within one of my apps and moved it to a separate repo
  • I created 3 subfolders under the src folder: core, classic, and modern; they will hold the core code as well as the ui for both modes
  • in the app's packages folder I created a Junction to the new source controlled package folder
  • in the app.json I added my app in the requires array - at this stage it is ok to reference the classes through the PackageName (in my case gm) namespace

So far it looks like the package buids-in nicely into the consumer app and at the same time it is independently source controlled which were my primary concerns.
There are some problems building the package itself as it is not a part of an app or a workspace. I guess it can be simply copied over to a temp app and then built as required. Not too fancy indeed, though at this stage I have no drive to investigate it further.

  1. As of ExtJs 6, i leaned towards using universal apps. therefore the code organisation changes a bit and the code goes to src, modern and classic folders respectively
  2. When requiring a package class in the generic code (not toolkit specific) then there must be package equivalents for a required class for both toolkits - otherewise building will fail for the code not implemented for a particular toolkit
  3. And finally, made the package build as expected - instead of simply drilling down to the packages/local/packageName and running sencha package build (that throws errors related to missing Ext classes), the command should include the sdk param, so the cmd knows where ExtJs stuff actually is (obviously not in the default location in my case ;)