Trying out – autodeploy to ftp on github push

I just found a tool I like, it’s called and it deploys to ftp on a push to github (or bitbucket). As I have a few sites still on ftp, and I like the git push -> deploy flow this is a service I wanted to try. The service is made by a british company called Cocoon

It was easy to get started, just by log in with my Github account and add an ftp server. The service has been around for a while and they seem to be serious and alert so I dared to add the credentials for a ftp login for their service on my server.

My idea is to push deploy javascripts from one project and razor from another project to a website of mine.

I had a few questions:

  • Can I deploy to a specified folder?
  • From a specified branch?
  • Will it keep files I have in the folder before?
  • Can it delete files I delete from the repository?

I did some experiments and I was happy to find out that the answer to all my questions was yes. I can deploy from a branch to a specified subfolder in the ftp, and it did not touch the files I had in the folder before, nor the ones I added manually in between deploys. But it took care of deletions I made within the repository.

The UI could need a little bit of love. Some minor issues (far from showstoppers). Also I would like to be able to pay with paypal. The service costs 12£ a month for unlimited projects. One proj is free.

I like their roadmap, both for being explicit with their plans and for many of the features they plan to add.

Typescript is simply about programming language evololution

Typescript is not only about getting static types in javascript. It is a lang that can, and promise to, evolve, when javascript cannot because it has to support old browsers.

For wide browser support javascript is still in 1999, as vb, early php or early ruby.

Sure I could still use vb and classic asp (many do), but I don’t need to – I use c# because I think it’s better (and more fun).

Live search for Umbraco frontend – using AngularJs and json content api

Everyone loves instant / live search, where a preview of the contents show up instantly as you write, right?

Update :
I wrote about an approach to create such a search quite a while ago using Examine. Now I like to write about an experimental, but working, approach that is faster than Examine and at the same time use a little bit of AngularJs.

Now – how is it even possible to be faster than Examine? Okay I cheat, I move the search to the client side, and get rid of the server call for each keypress / set of keypresses. Bad choice for sites with a fair amount of content? Well, if we take the Umbraco4 documentation as an example, last time I checked it was about 700kBs of data (in 236 markdown files). When we gzip compress that amount of text we should get about 175kBs. Which is similar in size as an ordinary – decently sized – image, and takes less than a second to download on a slow internet connection. For 236 pages of text. Let’s load that data on the initial page load, and perform the search with simple javascript functions.

For the actual search I’m going to use Umbraco 6 with the MVC CWS Starter kit , a little bit of AngularJs on the front end and a small json content api I call Tapas.

Install the mentioned packages. Then create a partial view called clientSideSearch.cshtml. Add the following code:

@inherits Umbraco.Web.Mvc.UmbracoTemplatePage

<script src=""></script>
<script src="/scripts/clientsearch.js"></script><!-- scripts placed in partialview for simplicity -->

<div ng-app="liveSearchModule" ng-controller="SearchCtrl">

    <h1>Live search</h1>
    <input id="searchText" type="search" placeholder="live search..." ng-model="searchText" />

    <ul ng-if="searchText">
        <li ng-repeat="child in children | filter:searchText | limitTo: 10">
            <a href="{{child.NiceUrl}}">{{child.Name}}</a>
            <div ng-bind-html-unsafe="child.Properties.bodyText"></div>

A few notes about the code. The Angular module and controller sets the scope in our html view. Then we use Angular built in directives ng-if and ng-repeat to filter the search results. Lastly we use Angular templating and the scoped objects to display the content, name, url and bodytext. The ng-bind-html-unsafe directive tells Angular to render the content as is, without encoding the html (as Html.Raw in Razor).

The “children” objects are returned by Tapas with a straight forward format shown in the docs for Tapas.

Add the render instruction inside your search view, “CWS-Search.cshtml” for example:


Next create the /scripts/clientsearch.js script:

angular.module('liveSearchModule', [])
  .controller('SearchCtrl', function ($scope,$http) {
      $scope.children = $http.get('/umbraco/publishedcontent/nodes/getchildren?path=/'); // get all children from the root document

This controller makes an ajax request (similar to $.getJSON / $.ajax) initially to get content from the content api, in this example all immediate children under root (path=”/”). The request returns a “promise” = an async result. Angular handles that automatically, and we do not need to figure out a way to render the content after the async is finished. The controller does not have any other functionality than to get data on initialization, later on the actual search is performed on the data in $scope.children.

And thats it!


Enter one or more letters in the search box to see the articles with bodytext below. If you like to format the document differently simply change the template. Limit number of search items if you wish. If you like to extend this with pager and change to a server side based service it’s fairly easy aswell. Also we might want to search through the entire tree. If there’s interest I’ll write a follow up later on.

Typescript is awesome – but still Alpha


I started using Typescript soon after the public announcement in october 2012. And I honestly thought they would have left Alpha status by now (september 2013). I’m frankly disappointed that they haven’t.

“Alpha software can be unstable and could cause crashes or data loss.” (Wikipedia)

Is the “Alpha” status as bad as it sounds? What does this actually mean?

If you check out the reported issues and the reviews you see that they still have quite a bit of work to do with the compiler before it can be regarded as completely reliable (and production ready).

Do I personally use Typescript “in production”? Yes I do, I have had js code generated by the Typescript compiler, in production since the beginning of 2013. I actually never had problems with the generated javascript. So by my experience, for the code I write, I trust the compiler to give me completely accurate javascript. Of course I had my share of compiler issues, but I was not nearly as badly bitten as others seem to have been.

Of the problems reported in Codeplex, not that many are related to the actual javascript, at least not when it comes to basic usage of the language (javascript with classes and static typing).

However – organisations who trust their compilers to “just work at all times, as with C#” should probably be careful before they start using Typescript until it reaches version 1.

It is very disappointing to hear open source library maintainers, who adopted Typescript for their library, say they strongly consider leaving Typescript because the number of problems they had with it.  In this particular case it is a very large project, written for 0.8 to begin with, and then upgraded to 0.9, where the problems begun (as far as I understood it).

Why use Typescript in the first place?

I jumped on the Typescript ship early mainly for two reasons 1) to get help dealing with the “bad parts” of javascript (as Douglas Crockford and many others talks about) and 2) to get classes and modules with a nice syntax to help structure my code.

Looking back I could have got these two things at a much lower “cost” with 1) a good habit using jslint and 2) adopting the commonly used revealing module pattern (or similar) (and getting used to a little boilerplate code).

The IDE part of the story, with solid language services inside Visual Studio, similar to C#, was only a very nice addition and nothing I looked for to begin with.

Now, lots and lots of typescript hours later, I have become so used to the intellisense and tooling help I find it hard to write javascript in an ordinary text editor anymore.

What I like about using Typescript

* Classes and modules to structure my code
* Creating more reliable javascript than I would myself
* Catching type errors
* Intellisense for my own code
* Intellisense for external libraries (with the help of community produced definition files)
* Robust code navigation
* Code documentation intellisense, using jsdoc
* Mapping js to ts for debugging within actual typescript while running the code

Laymans questions: Why Generics? And why not using C#?

When they introduced Generics in version 0.9 my first thought was – “why on earth would I want generics in javascript?” Perhaps for a version 2.0 of Typescript, but why this early?

Also – creating a compiler with such advanced features as generics must be several times more complicated to accomplish with the half finished version of the language itself. I wonder why they did not, at least to begin with, write it with C# or C++?


Typescript is simply awesome for my productivity and my ability to produce reliable, maintainable code.  I think Typescript, when it is finished, will be a great step forward for the web developer community, and in turn, for the quality and usability of the web itself.

So, it will be great – but I’m impatient. The compiler errors and the fact that the compiler is still Alpha today, 11 months after the first public announcement is surprising and a disappointment.


“Microsoft officials are saying TypeScript 1.0 will ship “later this year.””

I guess we just need to be patient a little while longer.

My current deploy to Azure setup

Azure is easy to use and powerful. We all know that. Right? This is the way I setup my current project after I moved from a physical server to Azure.

1. A regular Git repository, hosted on Github.
2. The master branch for my daily up-to-date-code. Other branches for experiments.
3. A .gitignore that ignores folders like node_modules and .idea
4. A deploy folder that I copy all the relevant deploy files to – and only them – when it is time to deploy to Azure. Manually or with grunt.
5. A .deployment file that points to the deploy folder.
6. A free (for my staging/demo site) Azure website pointing to my repository and the master branch.

With this I commit and push often, but only save files to deploy + push those when it’s time for a new deployment.

Setting up a Typescript Project Structure to make the compiler happy

While I was doing a lot of refactoring and cleaning up on a Typescript project – to be able to go further with it, and to make it work good with the newest version of the compiler – I re-thought my setup. And found a way I’m pretty happy with so far. So I’d thought I’d share it.

Disclaimer: this is an ongoing experiment, nothing to be considered as a best practice. I highly appreciate any comments.

Highly recommended read “7 Months with TypeScript” by Ted Patrick :

The project is a fairly large Single Page Application one, and it was rather cluttered when I started my refactoring. Test, experiments, dead code and the actual application code in one and the same folder structure, and one and the same Visual Studio project. (I only deployed the fresh parts though).

Be sure that you are not hit by tooling issues

If you’re having problems with Visual Studio not compiling a particular typescript file, check if all the .ts and .d.ts files have BuildAction property set to TypeScriptCompile. Seems to be a bug somewhere in the TS tooling which makes that property set to Content at rare cases. This issue.

Another VS gotcha is the ts files are being saved as ANSI which dows not work with international characters, should have encoding UTF-8 just like any other VS code file. This issue.

A third thing I bumped into on an upgraded project was I had an interface with an “export” declaration in one of my typescript files. From 0.9.1(?) that makes the compiler treat the whole file as an external module, without any further notice inside Visual Studio. So the class I had in the same file was never picked up, and did not appear in the intellisense. This is by design, but I really think VS should give me a warning about it, a TSC compile does.

Clean up the project

With the newest version of Typescript, the tooling in Visual Studio automatically references all included typescript files (d.ts and .ts, if set to TypeScriptCompile as they should be automatically). This means you should remove unused pieces of code, and unused definition files from your project, otherwise you are slowing down the compiler.

Treat the Solution as any C# one, keep separate projects for different uses

I took a step back, cleaned up the project as much as I could and realized that one way to keep the compiler happy, and my project easier to deal with – was actually to treat my solution pretty much as any C# solution. That is I now have separated projects, one for the js “assembly” and one for the actual application, and one for tests.

So this is my current solution structure (all these are Visual Studio HTML Application with Typescript projects):

  1. MyApp.Core [only typescript classes]
  2. MyApp.Core.Tests [karma based tests]
  3. MyApp.HtmlApplication [startup module and resources]
  4. MyApp.Experiments [old stuff and experiments]

Most of my coding goes into MyApp.Core obviously. There are all my classes. And as I mentioned the compiler now automatically references all typescript files, and all defintions, in the project. So I have no “reference path=” code in my files.

My assembly file

MyApp.Core compiles to a single javascript file “MyApp.Core.js” as any C# class library compiles to a single dll.

So MyApp.Core.js is the file I copy to my other projects where I need it. To get type checking and intellisense I also let the compiler to create a definition file.

I cannot (as far as I know) specify any actual order of the compiled typescript files. But, just like in C#, that does not matter as nothing is being run before I explicitly say so. I have a MyApp.Startup class with all necessary startup code. And that’s the one I instantiate from my Html application, on document ready. (Or from my tests).

A problem with this setup is as you probably note is I do not have the ts files in the running application, nor in my testproject, and because of that I get no mapped ts debugging. Currently I’m fine with debugging the js-files.

Tweak the project settings in the .csproj file

To make the compiler create a single “assembly” file + a declaration file you will need to tweak the project file slightly. 1) set the TypeScriptOutFile option to a file name, and 2) set the TypeScriptGeneratesDeclarations to true.

You do this by unloading the project, do your edits (xml) and then reload the project file. Obviously you need to be careful as the settings inside the file affect your project. However – it’s just code, and Visual Studio will inform you if you mess up. Keep a copy to be safe.

Unofficial Typescript options reference.

This is how my typescript build setup looks like: (MyApp.Core.csproj):

  <PropertyGroup Condition="'$(Configuration)' == 'Debug'">
  <PropertyGroup Condition="'$(Configuration)' == 'Release'">




Additional build instructions to copy files automatically to the test project

I also added instructions to make it copy the created files to my tests and application projects:

xcopy /y $(ProjectDir)myapp.core.* $(ProjectDir)..\MyApp.Core.Tests\<br />
xcopy /y /s $(ProjectDir)\Application\Interfaces\.* $(ProjectDir)..\MyApp.Core.Tests\Interfaces\

The test project consists of the compiled myapp.core.js, the myapp.core.d.ts, the interfaces from the core project and the actual test files.

Still happy with Typescript

With this I’m happy with Typescript and I see all kinds of reasons to keep using it. To be able to create javascript applications, with strong typing, and a similar syntax and structure as with C# is just so much nicer.

Sidenote, somewhat related: Classes vs Modules

I have said before that I think modules could often be used instead of classes in Typescript, as they are more light weight and they follow the style as lots of javascript libraries and samples out there.

I have changed my mind slightly about that. It is simply another style to code class free, and mixing the two can create confusion. So to keep my code clean and easy to deal with I decided to use classes only in my core project.

For the html application small startup code, and in tests, modules often makes sense tho.

An easy way to invoke function by http method and url pattern in WebPages Razor

We’re used to simply add a method named “get” or “post” in WebApi to do something for that particular http method, with a particular signature (url pattern). Can we do something similar in Razor (WebPages)?

Edit: I created a small nuget package using this approach + adding the aspnet data binder to WebPages razor, the result is an easy way to add json endpoints to your WebPages codebases “WebPagesApi”. WIP/WoMM Check it out.

Let’s say we like to handle a get requests to /products/:id (int) and /products and post requests to /products/:id separately. We can do that by letting all requests go through a chunk of code to check method and url data. Can we do that in a more elegant and safer way with Razor? Just like this:

    public object get(int id)
        // get data from somewhere
        return someSerializableObject;

Sure we can. Remember that a Razor page is also a class, and you can add methods to it by using the functions keyword. You can also override some built in methods, like for example InitializePage.

With this knowledge, and a bit understanding of Reflection, we can make the page try find a suitable method to invoke, based on http method with just a couple lines of code:

@using System.Reflection

    public object get()
        return "hello world";
    public object get(int id)
        return id;
    public object get(string id)
        return id + " is a string";
    public object post(int id){
        return "you posted something";
    protected override void InitializePage()

        var methodName = System.Web.HttpContext.Current.Request.HttpMethod.ToLower();
        var urlArgs = UrlData.Select<string, object>(itm => { int iItm; if (int.TryParse(itm, out iItm)) return iItm; return itm; }).ToArray();

        Response.Write(Json.Encode(this.GetType().InvokeMember(methodName, BindingFlags.Default | BindingFlags.InvokeMethod, null, this, urlArgs)));


Save this as products.cshtml and you have a nicely syntax separated, easy to update, code file for get on “/products” and “/products/:id” + post on “/products/:id”

a call to /products will return

hello world

a call to /products/123 will return


as the invoker is intelligent enough to figure out the signature with an integer. Where a call to /products/foo will return

foo is a string

As you notice I did not add any error handling. It can easily be done, but preferrably somewhere else. Or why not just rely on the built in error messages? At least if it’s for api calls.

RPC style urls
If you like the first part of the url be the method name instead of using http method names (/products/dosomething/123) you can change the code to this:

@using System.Reflection

    public object index()
        return "hello world";
    public object dosomething(int id)
        return "do something for id: " + id;
    protected override void InitializePage()

        var methodName = UrlData.Count==0?"index":UrlData[0].ToLower();
        var urlArgs = UrlData.Skip(1).Select<string, object>(itm => { int iItm; if (int.TryParse(itm, out iItm)) return iItm; return itm; }).ToArray();

        Response.Write(Json.Encode(this.GetType().InvokeMember(methodName, BindingFlags.Default | BindingFlags.InvokeMethod, null, this, urlArgs)));


And if we move it to a separate class (save it in App_Code if you like) we can shorten the razor file even more:


using System;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;
using System.Web;
using System.Web.Helpers;
using System.Web.WebPages;

public class RazorApiRpc : WebPage
    protected override void InitializePage()
        var methodName = UrlData.Count == 0 ? "index" : UrlData[0].ToLower();
        var urlArgs = UrlData.Skip(1).Select<string, object>(itm => { int iItm; if (int.TryParse(itm, out iItm)) return iItm; return itm; }).ToArray();
        Response.Write(Json.Encode(this.GetType().InvokeMember(methodName, BindingFlags.Default | BindingFlags.InvokeMethod, null, this, urlArgs)));
    public override void Execute()    {    }


@inherits RazorApiRpc
    public object index()
        return "hello world";
    public object dosomething(int id)
        return "do something for id: " + id;