In the previous post, I have shown how you could write a simple Twitter bot using JavaScript and Node.js very quickly. However, I ran the bot on my local machine, which is probably not something that you want to do for a real application. Instead, you’d probably want to host it on a cloud platform. In this article, I will show how you can do that also in no time using Heroku. Heroku is a cloud platform for building and running applications that takes away the complexity of setting up an entire infrastructure. This makes it well suited for simple things like the bot we previously created.

A word on Azure

Since I have an Azure account and MSDN subscription my first choice for hosting the bot was Azure. However, I learned something important.

After wasting too much time looking into both web apps and Azure Cloud Services, installing Azure Power Shell, learning to use it, setting up worker roles, deploying, etc. and still not getting the bot to work (unless accessed through a URL) I decided to move on and find something that even someone unfamiliar with can quickly grasp in minutes.

Starting with Heroku

Heroku is a platform that you can use for free for experimenting if you don’t require too many resources. Of course, there are paid plans, depending on your needs. However, for the simple bot I was building there would be no incurring costs.

Pricing is based on dyno hours. Dynos are lightweight Linux containers in which an application runs. A dyno can belong to one of the three possible configurations: web (that receive HTTP traffic from routers), worker (typically background jobs, queueing systems, and timed jobs), and one-off (temporary dynos that can run detached, or with their input/output attached to your local terminal, typically used for administrative tasks, such as database migrations and console sessions). You can get up to 1000 dyno hours per month for free, which is enough to run an application with no costs. Should you need to host more, then you’d have to pay for it.

After creating the account, you should download and install the Heroku CLI (previously known as Heroku Toolbelt). This allows you to create and manage Heroku apps from the command line on Window, MacOS and Debian/Ubuntu.

Creating a Heroku app

After creating an account and signing in you can create applications from the dashboard. You must specify a unique name and a data center where it should be hosted.

Heroku has its own git to store your project sources. You can find instructions under the Deploy page for how to create the project locally and commit it to Heroku’s git repository.

Defining a Procfile

Apart from the bot source files that we created in the previous article (package.json, bot.js, and others that might be necessary), we need to declare a Procfile in the root directory of the app. This is a text file that defines what command should be executed to start the application. The content of this file should be the following (assuming that the entry point of the bot is called bot.js).

This is necessary because the Twitter bot is not a web app, but a worker app that runs on the server and does something periodically in the background, not based on HTTP requests.

After uploading the source files including the Procfile to the heroku git repository, go to the application and under the Resources tab, stop the web dyno and start the worker dyno.

Note: a web dyno is created by default for every application.

And that’s it, the Node app now runs successfuly on the platform in the background.

See more

Deploying Node.js Apps on Heroku
Getting Started on Heroku with Node.js
Dynos and the Dyno Manager

, , , , , , , Hits for this post: 3919 .

I this post I will talk about the deployment changes in VC++ 2010. When you deploy an application to another machine you have to install not only the application but all the libraries that it depends on. When you build with VC++, you have dependencies on CRT (C/C++ runtime) and possible on MFC and/or ATL.

Visual Studio 2005 introduced a new deployment model for Windows client applications based on isolated applications and side-by-side assemblies. Assemblies can be either shared (globally registered in the system, installed in the Global Assembly Cache – GAC folder in Windows – and available to all applications) or side-by-side (described with a manifest, distributed with the application and available only to that application).

In Visual C++ 2005, library assemblies (such as MFC, ATL, CRT) have been rebuilt as shared side-by-side assemblies and installed in the native assembly cache, WinSxS folder in Windows. That means they are not globally registered in the system, but are globally available to the applications that specify a dependency with a manifest file.

With VC++ 2005 or 2008 there are several options for deployment:

  • static linking: when you link your application statically against VC++ libraries (CRT, MFC or ATL) the application doesn’t have any dependencies so you don’t have to deploy any other VC++ DLLs to the target machine
  • shared side-by-side assemblies: the VC++ DLLs are deployed in the WinSxS folder; this can be done either with the Visual C++ Redistributable Merge Modules or the Visual C++ Redistributable Package; the application requires a manifest file that describes the dependent DLLs and their version
  • private assemblies: the VC++ DLLs are all installed in the same folder with the application; the application requires a manifest file

When you deploy an application built with Visual Studio 2005 or 2008 a manifest file that describes the dependencies, whether you deployed these VC++ DLLs in the local folder or they where installed in the WinSxS folder. If the manifest is missing you get an error. The next image shows the error received when running an MFC application (called Wordpad2008) build with VC++ 2008 on another machine without a manifest.

Though the purpose of this change was to simplify deployment, the result was probably the opposite. As a result Microsoft changed deployment requirements in Visual C++ 2010. You can now deploy applications without a Fusion or satellite manifest. All you need to do is copy the VC++ dependent DLLs to the application folder and run. The next image shows an MFC application (called Wordpad2010) built with VC++ 2010 running on another machine, without a satellite assembly. No error occurs any more when trying to start the application, because local deployment no longer require a satellite manifest.

With VC++ 2010 there are several options for deployment:

  • static linking: same as earlier
  • central deployment: the VC++ DLLs are deployed in the system32 folder; this is useful for updates, because Windows automatically identifies and updates the DLLs that are deployed here
  • local deployment: the application executable and its dependent DLLs are all installed in the same folder; no manifest file is required.

To find more information about deployment and manifest files I suggest these links:

, , Hits for this post: 54569 .