Added more of Anton's articles from the main DB.

user/anton.tayanovskyy/20130305-upcoming-websharper-changes.done

@@ -0,0 +1,19 @@
+---
+title: "Upcoming WebSharper Changes"
+categories: "websharper,f#"
+abstract: "Soon-to-be released WebSharper includes Direct API that will greatly simplifies building tools that compile F# code to JavaScript via WebSharper. It has can work in FSI. We are also finishing some testing on a TypeScript definition file cross-compiler that emits WebSharper FFI definitions based on TypeScript \".d.ts\" files, allowing to reuse some work the TypeScript community has done in defining types for JavaScript libraries."
+identity: "3053,76214"
+---
+It is time for some long-awaited improvements in WebSharper: Direct API and TypeScript cross-compiler. 
+
+<h2>Direct API</h2>
+
+While working on the <a href="http://www.facebook.com/media/set/?set=vb.189105887856115&type=2">CloudSharper (WebSharper IDE)</a> project, we strongly felt the need to have a more flexible way to call into WebSharper, to have the compiler as a service. In particular, we wanted it to be able to compile code on the fly inside an FSI session, including parsing FSI-defined dynamic assemblies.  While very reasonable in retrospect, this requirement was not on the table in the original design, and we had to put in quite  a few changes to make it work.  The good news is that it is working, and you can even compile F# to JavaScript inside an FSI session.  The changes are already published in our <a href="https://bitbucket.org/IntelliFactory/websharper">official WebSharper repository</a>, in particular see <a href="https://bitbucket.org/IntelliFactory/websharper/src/06cd7b5110e2379f795dd6815dbbecc12b1bc4fd/IntelliFactory.WebSharper.Compiler/FrontEnd.fsi?at=default">FrontEnd.fsi</a>.  I am now finalizing some cleanup tasks and will soon release a NuGet package update incorporating the changes.
+
+Direct API makes a few frequently requested scenarios much easier. For example, it is now a lot more straightforward to avoid reliance on ASP.NET, to build more flexible tools, or to do things like targeting Node and a pure-JavaScript runtime.
+
+<h2>TypeScript</h2> 
+
+In case you have not noticed, there is a new language from Microsoft called <a href="http://www.typescriptlang.org">TypeScript</a>.  After working with deciphering its semantics for a bit, I am not a big fan of TypeScript design (this deserves another blog); but I will grant that it is a vast improvement on JavaScript.  Moreover, TypeScript defines a standard way to describe JavaScript library interfaces, and people have started doing so en masse, see for example <a href="http://github.com/borisyankov/DefinitelyTyped">DefinitelyTyped</a>.  With the TypeScript cross-compiler tool we are trying to reuse all this work - and generate WebSharper FFI bindings based on TypeScript ".d.ts" files, using either a F# 3.0 TypeProvider or bulid-time API.  A competing project, <a href="https://github.com/ZachBray/FunScript">FunScript</a>, has pioneered the approach.
+
+TypeScript bindings are likely to be the future of WebSharper extensions story, even though the quality of the present TypeScript bindings strikes me as very poor. Well, so does the quality of TypeScript definition language. TypeScript does not, for instance, allow generics in the specifications, though they are considering to add them in the next release.  Regardless, the reason that TypeScript bindings are exciting is social - due to excellent tooling and Microsoft backing TypeScript is picking up very quickly. There are already many more TS bindings than WebSharper bindings, and given the dynamic of its adoption, their quality is likely to improve quickly. We would like to ride the wave.

user/anton.tayanovskyy/20130305-upcoming-websharper-changes.md

@@ -0,0 +1,24 @@
+---
+title: "Upcoming WebSharper Changes"
+categories: "websharper,f#"
+abstract: "Soon-to-be released WebSharper includes Direct API that will greatly simplifies building tools that compile F# code to JavaScript via WebSharper. It has can work in FSI. We are also finishing some testing on a TypeScript definition file cross-compiler that emits WebSharper FFI definitions based on TypeScript \".d.ts\" files, allowing to reuse some work the TypeScript community has done in defining types for JavaScript libraries."
+identity: "3053,76214"
+---
+It is time for some long-awaited improvements in WebSharper: Direct API and TypeScript cross-compiler. 
+
+## Direct API
+
+While working on the [CloudSharper (WebSharper IDE)](https://www.facebook.com/media/set/?set=vb.189105887856115&type=2) project, we strongly felt the need to have a more flexible way to call into WebSharper, to have the compiler as a service. In particular, we wanted it to be able to compile code on the fly inside an FSI session, including parsing FSI-defined dynamic assemblies.  While very reasonable in retrospect, this requirement was not on the table in the original design, and we had to put in quite  a few changes to make it work.  The good news is that it is working, and you can even compile F# to JavaScript inside an FSI session.  The changes are already published in our [official WebSharper repository](https://github.com/dotnet-websharper/core)[^1], in particular see [FrontEnd.fsi](https://github.com/dotnet-websharper/core/blob/master/src/compiler/WebSharper.Compiler/FrontEnd.fs)[^2].  I am now finalizing some cleanup tasks and will soon release a NuGet package update incorporating the changes.
+
+Direct API makes a few frequently requested scenarios much easier. For example, it is now a lot more straightforward to avoid reliance on ASP.NET, to build more flexible tools, or to do things like targeting Node and a pure-JavaScript runtime.
+
+## TypeScript
+
+In case you have not noticed, there is a new language from Microsoft called [TypeScript](https://www.typescriptlang.org).  After working with deciphering its semantics for a bit, I am not a big fan of TypeScript design (this deserves another blog); but I will grant that it is a vast improvement on JavaScript.  Moreover, TypeScript defines a standard way to describe JavaScript library interfaces, and people have started doing so en masse, see for example [DefinitelyTyped](https://github.com/borisyankov/DefinitelyTyped).  With the TypeScript cross-compiler tool we are trying to reuse all this work - and generate WebSharper FFI bindings based on TypeScript ".d.ts" files, using either a F# 3.0 TypeProvider or bulid-time API.  A competing project, [FunScript](https://github.com/ZachBray/FunScript), has pioneered the approach.
+
+TypeScript bindings are likely to be the future of WebSharper extensions story, even though the quality of the present TypeScript bindings strikes me as very poor. Well, so does the quality of TypeScript definition language. TypeScript does not, for instance, allow generics in the specifications, though they are considering to add them in the next release.  Regardless, the reason that TypeScript bindings are exciting is social - due to excellent tooling and Microsoft backing TypeScript is picking up very quickly. There are already many more TS bindings than WebSharper bindings, and given the dynamic of its adoption, their quality is likely to improve quickly. We would like to ride the wave.
+
+
+[^1]: This link has been updated to point to new location.
+
+[^2]: This link has been updated to point to new location.

user/anton.tayanovskyy/20130306-websharper-2-5-2-alpha-on-appharbor.done

@@ -0,0 +1,12 @@
+---
+title: "WebSharper 2.5.2-alpha on AppHarbor"
+categories: "websharper,f#,appharbor"
+abstract: "Pre-release NuGet <a href=\"http://websharper.com\">WebSharper</a> 2.5.2-alpha NuGet package is available and can already be used to build <a href=\"http://appharbor.com\">AppHarbor</a>-ready sites.  Clone the sample application <a href=\"http://bitbucket.org/IntelliFactory/websharper-bootstrap-site\">websharper-bootstrap-site</a> to build your own cloud-based WebSharper site."
+identity: "3054,76218"
+---
+Pre-release <a href="http://websharper.com">WebSharper</a> 2.5.2-alpha NuGet package is available and can already be used to build <a href="http://appharbor.com">AppHarbor</a>-ready sites. AppHarbor is an attractive execution environment for WebSharper apps: its provides a free basic option, and builds and executes your code in the cloud (using Amazon EC2).  The basic option does not come with default permanent storage, but we found that combining it with <a href="http://windowsazure.com">Windows Azure</a> storage service is entirely viable. Small projects will incur 0 monthly cost because of Azure free storage quota.
+
+Up until now, running WebSharper on AppHarbor without committing the binaries has been a bit quirky. This is finally resolved, and here is a sample ready-to-clone application:
+<a href="http://bitbucket.org/IntelliFactory/websharper-bootstrap-site">websharper-bootstrap-site</a>.  We are now finalizing testing the 2.5 WebSharper release and working on preparing a matching extensions release.  In the meanwhile, you can already try to start your own cloud-based WebSharper site with AppHarbor and the alpha package.
+
+Your comments and suggestions on how to improve the app are very welcome.

user/anton.tayanovskyy/20130306-websharper-2-5-2-alpha-on-appharbor.md

@@ -0,0 +1,12 @@
+---
+title: "WebSharper 2.5.2-alpha on AppHarbor"
+categories: "f#,websharper,appharbor"
+abstract: "Pre-release WebSharper 2.5.2-alpha NuGet package is available and can already be used to build AppHarbor-ready sites."
+identity: "3054,76218"
+---
+Pre-release [WebSharper](https://websharper.com) 2.5.2-alpha NuGet package is available and can already be used to build [AppHarbor](https://appharbor.com)-ready sites. AppHarbor is an attractive execution environment for WebSharper apps: its provides a free basic option, and builds and executes your code in the cloud (using Amazon EC2).  The basic option does not come with default permanent storage, but we found that combining it with [Windows Azure](https://windowsazure.com) storage service is entirely viable. Small projects will incur 0 monthly cost because of Azure free storage quota.
+
+Up until now, running WebSharper on AppHarbor without committing the binaries has been a bit quirky. This is finally resolved, and here is a sample ready-to-clone application:
+[websharper-bootstrap-site](https://bitbucket.org/IntelliFactory/websharper-bootstrap-site).  We are now finalizing testing the 2.5 WebSharper release and working on preparing a matching extensions release.  In the meanwhile, you can already try to start your own cloud-based WebSharper site with AppHarbor and the alpha package.
+
+Your comments and suggestions on how to improve the app are very welcome.

user/anton.tayanovskyy/20130313-generating-vsix-and-vstemplate-packages-in-f.done

@@ -0,0 +1,11 @@
+---
+title: "Generating VSIX and VSTemplate packages in F#"
+categories: "f#,visualstudio,build,vstemplate,vsix,extensions"
+abstract: "Announcing a small utility library for generating VisualStudio VSTemplate and VSIX packages."
+identity: "3061,76244"
+---
+We just released a few utilities on NuGet under the temporary name of <c>IntelliFactory.Build v0.0.1</c> (see Apache-licensed <a href="http://bitbucket.org/IntelliFactory/build">source</a>). Right now this kitchen-sink assembly contains F# API for generating VisualStudio template files (VSTemplate) and extension packages (VSIX), and is usable from .NET-based build automation tools such as <a href="http://github.com/fsharp/FAKE">FAKE</a>.  Plans are to add support for item templates and multi-project templates, and also support for embedded NuGet repositories in VSIX. Our need for this is WebSharper 2.5 - but it might be useful to you too.
+
+If you ever tried to author VisualStudio templates and extensions by hand, you know the XML hell it creates. Various problems with the MSDN documentation do not help. In the end, we want to be programmers, not XML editing technicians running around trying to keep things in sync.  A good way to keep things in sync and to apply the do-not-repeat-yourself principle is to automate - to define things in code, not XML. F# is a good option for this. If you agree so far, and you envision building or maintaining VisualStudio templates/packages, consider giving our little library a look - it may save you some time. We also gladly accept code contributions.
+
+I notice there are a few more missing things I would like to have in FAKE; when the build utilities mature, we might consider re-labelling them and adding to FAKE or releasing under a more specific name. Documentation is coming - for now please consult FSI signature files in source.

user/anton.tayanovskyy/20130313-generating-vsix-and-vstemplate-packages-in-f.md

@@ -0,0 +1,11 @@
+---
+title: "Generating VSIX and VSTemplate packages in F#"
+categories: "f#,visualstudio,build,vstemplate,vsix,extensions"
+abstract: "Announcing a small utility library for generating VisualStudio VSTemplate and VSIX packages."
+identity: "3061,76244"
+---
+We just released a few utilities on NuGet under the temporary name of `IntelliFactory.Build v0.0.1` (see Apache-licensed [source](https://bitbucket.org/IntelliFactory/build)). Right now this kitchen-sink assembly contains F# API for generating VisualStudio template files (VSTemplate) and extension packages (VSIX), and is usable from .NET-based build automation tools such as [FAKE](http://github.com/fsharp/FAKE).  Plans are to add support for item templates and multi-project templates, and also support for embedded NuGet repositories in VSIX. Our need for this is WebSharper 2.5 - but it might be useful to you too.
+
+If you ever tried to author VisualStudio templates and extensions by hand, you know the XML hell it creates. Various problems with the MSDN documentation do not help. In the end, we want to be programmers, not XML editing technicians running around trying to keep things in sync.  A good way to keep things in sync and to apply the do-not-repeat-yourself principle is to automate - to define things in code, not XML. F# is a good option for this. If you agree so far, and you envision building or maintaining VisualStudio templates/packages, consider giving our little library a look - it may save you some time. We also gladly accept code contributions.
+
+I notice there are a few more missing things I would like to have in FAKE; when the build utilities mature, we might consider re-labelling them and adding to FAKE or releasing under a more specific name. Documentation is coming - for now please consult FSI signature files in source.

user/anton.tayanovskyy/20130507-chocolatey.done

@@ -0,0 +1,21 @@
+---
+title: "Chocolatey "
+categories: "fake,automation,chocolatey"
+abstract: "<a href=\"http://chocolatey.org/\">Chocolatey</a> looks very useful - it lets you install software into PATH on Windows by one-liner commands from PowerShell. A poor-man's package manager."
+identity: "3313,76533"
+---
+If you have not yet, check <a href="http://chocolatey.org/">Chocolatey</a> out. It looks very useful. This little utility lets you install software into PATH on Windows by one-liner commands from PowerShell. It is a poor-man's package manager for Windows.
+
+In particular, it automatically knows about NuGet packages. Packages with executable files under "tools" get aliased into <c>C:\Chocolatey\Bin</c> or similar, and the tools end up on your PATH.
+
+For example, to get started with <a href="http://github.com/fsharp/fake">FAKE</a> - the F# Make you can do:
+
+<code>
+cinst -pre FAKE
+mkdir my-project
+cd my-project
+fake boot init one # initializes the project, creates build.fsx
+./build.fsx # edit your build script in VS
+fake # build
+</code>
+

user/anton.tayanovskyy/20130507-chocolatey.md

@@ -0,0 +1,20 @@
+---
+title: "Chocolatey"
+categories: "fake,automation,chocolatey"
+abstract: "Chocolatey looks very useful - it lets you install software into PATH on Windows by one-liner commands from PowerShell. A poor-man's package manager."
+identity: "3313,76533"
+---
+If you have not yet, check [Chocolatey](https://chocolatey.org/) out. It looks very useful. This little utility lets you install software into PATH on Windows by one-liner commands from PowerShell. It is a poor-man's package manager for Windows.
+
+In particular, it automatically knows about NuGet packages. Packages with executable files under "tools" get aliased into `C:\Chocolatey\Bin` or similar, and the tools end up on your PATH.
+
+For example, to get started with [FAKE](http://github.com/fsharp/fake) - the F# Make you can do:
+
+```fsharp
+cinst -pre FAKE
+mkdir my-project
+cd my-project
+fake boot init one # initializes the project, creates build.fsx
+./build.fsx # edit your build script in VS
+fake # build
+```