Slov – Helicon Tech Blog

Offline installation of Zoo components

Slov — Wed, 11 Sep 2013 15:50:54 +0000

Sometimes you may need to install Helicon Zoo components on a machine that is not connected to the Internet. In this article we will show how to prepare offline installation packages for Zoo products and engines that you can use to install these components without Internet access. This could be also useful when you need to clone exact environment across different instances in the cloud, or when you need to save current state and version of installation package to reuse it for future installations.

Creating offline hosting package

In Zoo infrastructure the most convenient way to prepare the server to host some application is to install appropriate technology Hosting Package from Zoo –> Packages on it. These hosting packages include everything needed to run an application of particular type on a previously clean system. And all these packages can be installed offline using Web Platform Installer command line tool called WebpiCmd.exe. You can find official webpicmd.exe syntax reference here: http://www.iis.net/learn/install/web-platform-installer/web-platform-installer-v4-command-line-webpicmdexe-rtw-release

To install Hosting Package on a machine without Internet access you will first need to create an offline installation package. And you will first need a workstation that is connected to the Internet to do this. Let’s call it internet-enabled machine. So install Microsoft Web Platform Installer on the internet-enabled machine. Then run Windows Command Prompt as Administrator – right click on Start –> Accessories –> Command Prompt and select Run as administrator.

Running Command Prompt as administrator is needed to avoid need of opening new window on every WebpiCmd.exe command, so you can see the command output. If webpicmd.exe file is not in your Path, you can find it by navigating to

cd "C:\Program Files\Microsoft\Web Platform Installer"

Assume we need to install Redmine on the internet-disabled machine. This means we need to create offline installation for Ruby Hosting Package first. To install a product using WebpiCmd.exe you need to know it’s internal name. We can use /List mode to list all products and applications available with their internal names. It is better to save output into products.txt file because the list is long and may be truncated in the Command Prompt window. So run this command:

webpicmd.exe /List /ListOption:All /Feeds:http://www.helicontech.com/zoo/feed.xml > products.txt

Here is a list of all Hosting Packages with their internal names currently available for your convenience:

CFMLHostingPackage     CFML Hosting Package
JavaHostingPackage     Java Hosting Package
RubyHostingPackage     Ruby Hosting Package
NodejsHostingPackage   Node.js Hosting Package
PerlHostingPackage     Perl Hosting Package
PHPHostingPackage      PHP Hosting Package
PythonHostingPackage   Python Hosting Package

Please run the following command to create offline copy of Ruby Hosting Package product and all it’s possible dependencies:

WebpiCmd.exe /offline /Products:RubyHostingPackage /Path:C:\offline-package /Feeds:http://www.helicontech.com/zoo/feed.xml

This command will create a copy of al feeds, installation packages and other dependencies that may be required to install Ruby Hosting Package on another machine in the C:\offline-package folder. The /Products:RubyHostingPackage key is a comma separated list of products you are saving for offline usage. Notice C:\offline-package\bin folder – there you may find a copy of WebpiCmd.exe you will be using to install products on the internet-disabled system. Please copy content of the C:\offline-package folder to the internet-disabled machine, navigate to the C:\offline-package\bin folder and run following command to install products:

WebpiCmd.exe /install /Products:RubyHostingPackage /XML:C:\offline-package\feeds\latest\webproductlist.xml /Feeds:C:\offline-package\feeds\latest\supplementalfeeds\feed.xml /AcceptEula

This will install Ruby Hosting Package without internet access required.

Warning: Same technique will work for any other Hosting Package except Java Hosting Package. Because Oracle currently prohibit inclusion of JDK into any other packages or feeds we cannot include JDK directly into feed. You will need to download JDK 7 from Oracle web site separately and install it on internet-disabled machine. Once installed Helicon Zoo will recognize it’s installation and you can install Java Hosting Package then without internet access, all other components will be installed successfully.

Installing application

The hosting package is installed and server is ready to host the application. Please don’t try to create offline installation package of the application, such as Redmine or Python project template – this will not work because most of applications, like Redmine, will require internet access to install gems or some other components anyway. Instead of creating offline installation package for the application you will need to install needed application on the internet-enabled machine first. Please follow the instruction for specific application to install it. For example you can find detailed Redmine installation instruction here. Make sure to use Helicon Zoo Web Console or Helicon Zoo Manager Start IDE function to run console and IDE for applications so all components and dependencies (like gems, modules, etc.) will be installed in the application’s web site folder. Some technologies, like Java, will pack dependencies into the application folder by default. Some other needs additional means, like running web console, etc. While Helicon Zoo provides all needed tools to develop self-contained applications, it is up to developer to maintain application portability and pack all dependencies inside, which may require some sort of development discipline.

After you installed application on the internet-enabled machine make sure it is working as expected. If application needs additional configuration, configure it. Then, if you configured application following Helicon Zoo best practice, you can simply copy the application’s web site folder to another machine with required Hosting Package installed following normal deployment process and it will work. No internet access should be required for this operation again.

Helicon Zoo 3.0 what’s new

Slov — Tue, 16 Jul 2013 15:11:00 +0000

New version of Helicon Zoo is available for installation and this version is a significant step towards usability and application portability comparing the the previous. To install it open Web Platform Installer and install one of the Hosting Packages, one of the Templates or Helicon Zoo Module from Modules as usual. Below please find a list of most important changes in this major release:

Helicon Zoo now include GUI manager, where you can configure various aspects of Zoo engine. You can edit existing engines, clone or add new engines, enable or disable engines, ets. Go to Start –> Helicon –> Zoo –> Helicon Zoo Manager to start it.
With Helicon Zoo Manager you can edit individual application settings, like engines used, environment variables, etc.
Now you can control which engines are allowed to use for individual web sites. This is useful for hosting services were administrators wish to restrict user abilities to call particular engines, even if corresponding software is installed in the system.
The most important feature is built-in web console – an HTML based command line application where users can run console commands directly to the web applications. This feature is required for most Ruby, Python, Node.js and Perl projects as well for some other web application technologies that rely on console commands. This web console is launched in the web application context and configured to use local application path, therefore all commands users call in this console will apply to the application folder. For example ‘gem install’ Ruby command will allow users to download and install gems into the web site’s local folder where they will run with Helicon Zoo application. No write access to global folders required. This differs from the traditional technique when users install gems and modules globally into the system. The console can be called from the Helicon Zoo Manager using Start web console button or from the project’s template start page. For security reasons only local or authenticated requests are allowed. Server administrators can restrict console access either globally or for individual web sites using Helicon Zoo Manager.
Helicon Zoo Manager now include CHM documentation. Please use this documentation as we’ll prepare it’s online version soon. To open it use Help –> View help.
Philosophy of applications has changed significantly to obtain better portability and isolation in shared environment. Now to start new application or host existing application users need to use Templates in Zoo –> Templates. You just install template for desired application technology and then use web console to configure application as normally. A quick start instruction will be provided on the projects home page. For existing applications you simply copy existing files into application template’s folder, keeping existing files intact. To use third party IDE it is recommended to start it from Helicon Zoo Manager using Start IDE button while the developed application is selected. In this case IDE will be started in pre-configured environment to work with application local folders and to store modules and components inside application. Most current IDEs support this technique to configure folders, but when started separately they will try to install everything globally by default. While it is still possible for some applications to download and install missing components into the application local folder during Helicon Zoo Application Deployment process we recommend to start IDE using Helicon Zoo Manager. More articles with use cases and instructions will be available soon.
The new ability to start IDE of your choice pre-configured for current application environment directly from Helicon Zoo Manager. You can configure individual IDE for each application. The IDE will be started in the application environment, configured to run scripts using exactly the same interpreter as used for Zoo application, installing modules and components inside application folders, etc. Most current IDEs support this technology.
Helicon Zoo applications are easily portable. If the application is based on Helicon Zoo Template and developed using our guidelines, the only requirement you need to host it on another server is to have corresponding Hosting Package installed on this server using Zoo feed. By installing one of the Hosting Packages you are allowing whole class of web applications to be hosted on a server. Users who has their applications running with Zoo in their development environment can easily push their applications to production servers just by copying web site folders. Even more, different versions of Ruby, PHP, Python, all other technologies available form Helicon Zoo feed can easily coexist on the same server without any conflicts. And users can switch their applications between different versions of PHP or Ruby just by switching engines. Web application portability has never been easier.

Currently Helicon Zoo 3.0 is a release candidate and still evolving. This version will be fully compatible with previous one, which means all old applications installed with Helicon Zoo 2.x will continue to work with version 3.0 but some rarely used engines and templates will be deprecated. If your existing system rely on Helicon Zoo 2.x feed we strongly recommend you to test your system against version 3.0 RC as it will be a main release within a week.

Installing ContentBox CMS on Windows with IIS

Slov — Wed, 23 Jan 2013 10:37:25 +0000

ContentBox CMS is a professional open source modular content management engine that allows you to easily build websites, blogs, wikis, complex web applications and even power mobile or cloud applications. In this article you will find an instruction how to install ContentBox CMS on Microsoft IIS web server using Helicon Zoo.

Configuring Helicon Zoo

First we need to get Microsoft Web Platform Installer and configure it with Helicon Zoo:

Download and install Web Platform Installer.
Run Web Platform Installer and click “Options”.
Add Helicon Zoo feed into “Display additional scenarios” box: http://www.helicontech.com/zoo/feed. New “Zoo” tab will appear.

If it is a development machine it is convenient to choose IIS Express as a target web server for installations. For production environment please choose IIS.

Installing ContentBox CMS

In Web Platform Installer go to Zoo –> Applications, select ContentBox, click Add and then Install:

On a clean system installation may take a while as many components needs to be download and installed. These components usually include: Oracle JDK, Jetty, Railo, Helicon Zoo. Web Platform Installer may also install IIS or IIS Express and WebMatrix if they where not installed before. After installation of all required components is completed if you have selected IIS Express as target web server, the web site with ContentBox will be launched automatically. If you have selected IIS, then you will need to complete the form, choosing a location for new application – this could be application folder inside existing web site or a new web site.

On the first launch of web site you will see the Application deployment in progress page, with the progress of downloading and installing ContentBox CMS files.

It will then refresh automatically to the ContentBox installation wizard:

If you don’t have a database server you can use Web Platform Installer, to install MS SQL Server Express, MySQL or PostgreSQL on your system.

Since we’ve just created new Railo application the Railo Web Administrator password is not set yet. You need to navigate to the Railo web administrator page to set it. Use the URL like this: http://localhost:54973/railo-context/admin/web.cfm Here the host name and port may vary depending on where you have installed ContentBox CMS.

After completing ContentBox installation wizard you should see the web site up and running:

Multi technology hosting with Helicon Zoo

Slov — Thu, 22 Nov 2012 15:31:56 +0000

When we were making Helicon Zoo our main goal, aside from technology integration, was to create simple and unified solution for hosting providers to offer all mainstream web technologies and application engines to users. And now with better integration into WebsitePanel 2.0 we are even closer to that goal. This article will show how to build the most advanced and technology-rich hosting and PaaS solution on a market.

Helicon Zoo is a solution to host web applications written on multiple technologies inside Microsoft IIS and as regular IIS web sites. These technologies include: PHP, Perl, Java, Ruby, Python, Node.js, Erlang and ColdFusion. And when we say, for example, Ruby we mean everything-Ruby. This includes Ruby on Rails, Sinatra, Thin, Goliath, simple Rack or FastCGI applications, etc. The same variety applies to other technologies like Java, Python, etc. Add here native IIS support for ASP and ASP.NET and you’ll get the most technology-packed hosting service available.

All these technologies can be installed on the same server, shared by all users and even mixed within one web site. Consider, for example, users may have their main web site content running on ASP.NET, blog made with WordPress (PHP), forum on DjangoBB (Python), online chat with Node.js, Git repositories with Java, helpdesk solution with Perl and e-commerce solution with Ruby on Rails – all running within the same IIS web site on the same server. Sounds hardly possible? Well, this is nearly how Helicon Tech web site works. Below please find instructions on how to set the same technology on your hosting.

Installing components

Helicon Zoo is delivered as a custom Microsoft Web Platform Installer repository, so all parts of the solution can be installed from one place and you can be sure that everything is tightly integrated and tested to work together.

New WebsitePanel 2.0 includes support for Web Platform Installer and Helicon Zoo repository is also enabled by default. So if you are using this hosting control panel, you need to simply select the server where you wish to install components and click on Web Platform Installer in the Server tools menu.

This will open Web Platform Installer interface where you can install many useful tools and components on your server, like MySQL, MongoDB, PostgreSQL and various IIS components like WebDeploy, URL Rewrite, etc. But we are here to install web application engines. In the Packages tab you can find complete and ready to use hosting packages for various web technologies.

Each of these packages includes everything needed to host applications of specific technology on your server and thanks to Web Platform Installer all required dependencies will be detected, downloaded and installed automatically. So select for example PHP Hosting Package, Java Hosting Package and Ruby Hosting Package and click install, then accept licenses and this will start installation process.

To install Java Hosting Package you will need to download and install Oracle JDK 7. Unfortunately, Oracle prohibits direct downloads of Java packages, this means we cannot include JDK into our repository and you will have to go to Oracle web site and run JDK installation manually. Other packages will install dependencies automatically. Ruby package, for example, includes Ruby 1.8, Ruby 1.9, Ruby DevKit, Thin, Sinatra, Goliath and of course Ruby on Rails 2 & 3, plus it depends on IIS itself and Helicon Zoo Module.

If you don’t plan to use WebsitePanel 2.0 to manage your server you can install Helicon Zoo hosting packages using Microsoft Web Platform Installer. Simply add this feed in Options dialog and install packages you need: http://www.helicontech.com/zoo/feed/

After installation is completed your server is ready to run selected technologies immediately. No other components or configurations are necessary. If you need to configure engines further or restrict customer access to some engines or maybe create custom configurations for running web applications, please read the next chapter.

Configuring Helicon Zoo

Helicon Zoo was designed with shared hosting environment in mind and is capable of functioning in a fully automatic mode. It delivers concept of web engines and applications: where web application is something that resides within user’s web site folder and that is executed by web engine, while web engines are declared globally by server administrator and are located in applicationHost.config. Each engine declares commands, options and environment settings which are used to execute application of particular technology. Hosting users can’t change engines; they can only run applications using them.

There is no need to enable Helicon Zoo engines anywhere after installation. The concept is the same as you normally expect from PHP or ASP applications – simply put the application files into the web site folder and they run. But with Helicon Zoo these files also include web.config file which is used to actually configure the application in a folder, so user web.config files should be enabled for this concept to work.

Applications are executed in the context of IIS Application Pool. This means that if you run each user’s web site in a dedicated Application pool (which is default in WebsitePanel), each application is executed in an isolated user’s environment and with restricted permissions. When user creates a web site or application and uses Helicon Zoo new backend application will be created.

Helicon Zoo can talk to backends using FastCGI or HTTP protocols. “Backends” are for example php.exe or ruby.exe processes. Helicon Zoo will manage backend processes automatically. By default one backend process is started for each application when IIS application starts. Helicon Zoo can then increase the number of backend workers as the load to the application increases to keep response times within reasonable boundaries. It will then shut down excessive workers automatically as load decreases to save server resources.

Engines are configured in applicationHost.config file as and sections. If you want to edit some engine settings, copy it’s content from section to section first as engines section can be overwritten when Helicon Zoo Module is upgraded. You can read more about Helicon Zoo Module configuration in the product documentation.

User scenario

So now we have a web server that supports multiple web application technologies, but how will users actually install their applications to use on your servers? There are several options to do that:

Web Application Gallery

If you have WebsitePanel 2 on your hosting services, users can simply use Web Application Gallery to install applications and application templates for particular web technology. For example, assume that user is going to create new Ruby on Rails application. Since we already have Ruby Hosting Package installed on a server, user will open Web App Gallery:

Select Templates:

Scroll down to the Ruby on Rails project and click Install.

During installation user will have to choose a web site where to install the application and whether to put application into subfolder or web site’s root. After installation is completed application can be launched immediately right from WebsitePanel. After first application launch user can then edit and create files and scripts using normal development techniques for the applications of this type. It will be more convenient to download application files locally and work with them on client’s machine, then uploading files using FTP or WebDeploy.

Helicon Zoo provides templates for various web application technologies. List of these templates is constantly growing and updated. The content of each template project depends on the technology used. These projects usually include configuration files required to run application, some basic folder structure to hold static files, modules, etc., some scripts for application deployment and other useful components. We strongly recommend to use these application templates as a starting point for application development as these templates already include pre configurations and patterns for best development experience. If users already have some applications they want to host on your services, they can use application template available with Web Application Gallery to create a new application and then overwrite files in the template by the files of their actual application.

Web Platform Installer and WebMatrix

Another option for the user is to use Web Platform Installer to create a new application or template. The first thing to do here is to get Web Platform Installer from Microsoft. In Options add Helicon Zoo repository feed and select IIS Express as a target web server.

After that user can install any of the Hosting Packages on the client machine and get exactly the same environment as installed on a remote server that will run these applications online. Or user can bypass this step and install project template (like Ruby on Rails project) without installing hosting package, as all required components to run this application template will be downloaded and installed automatically, including WebMatrix and IIS Express itself. This will not probably allow user to run other types of Ruby applications, but the selected applications will run as expected.

After installation is completed WebMatrix will be launched running web application and providing file editors. It is possible to use Visual Studio or any other preferred web application IDE to work with these files.

Then use WebDeploy, FTP access or any other convenient way to upload application to the remote server.

Helicon Zoo applications are normally portable – you can move application from one machine to another simply by copying web application’s folder content, and as long as corresponding Hosting Package is installed on both machines application will run. Obviously if the application connects to a database or other remote services, this has to be taken into account.

One more thing to remember is folder permissions. With IIS Express and WebMatrix applications are usually executed with local user’s permissions (which has full permissions to the application folder), but on remote server applications are run in a restricted environment. Most of the applications require Write permissions to the web site folder for various reasons – write logs, store data, cache, intermediate pre-compiled scripts, save additional modules and components. We recommend enabling Write permissions for entire web site or application folder unless you know exactly which folder permissions should be given to your particular application. Insufficient Write permissions is the most frequent cause of the application failure. With WebsitePanel you can enable Write permissions in the web site’s security options.

Custom modules

The application template is installed and running but what happens if we need to install something more complex than a “Hello world” app? Many applications require additional modules to run. With Helicon Zoo we now have a concept where all modules and requirements of the application are installed inside the application work folder, which is usually user’s web site folder.

Previously web hosting administrators had to install a number of modules globally on the server and maintain up-to-date versions of every component, but with growth of web technologies variety, when new modules and versions are released every day, this becomes an overwhelming task. Different applications may require different versions of components and some of these components may conflict with each other. There definitely has to be a way to isolate application environments. Most modern web application frameworks support an ability to isolate applications and Helicon Zoo actively uses this technique. Each application template project available from Zoo repository includes code examples of how to install modules and components into local application folders.

Users have to be aware of these techniques and appropriate documentation has to be available. For example for Python applications users need to list all application dependencies in the requirements.txt file, instead of installing components globally on the development machine. This is a standard technique for application deployment and all components listed in these requirements.txt files will be installed automatically by deployment script. Users only need to understand that they have no permissions to install components on the server, instead they need to install everything inside the application folder.

Is it safe?

Frequent question from hosting providers – is it safe to allow users to install their custom components? The short answer is: there’s not more threat than allowing users to run their custom (PHP/ASP) scripts. Helicon Zoo executes everything in the context of IIS Application pool, there are no privileged processes or something that users can hack to gain more permissions than they already have. If you restrict permissions for IIS users on your hosting, then running custom modules is the same as running custom scripts on sites. Modules are installed inside user’s web site folder and executed with App pool permissions, no other user environment or global server settings can be affected.

Application deployment

One of the highly important features of Helicon Zoo is Application deployment. Complex applications usually require executing some operations before they could be launched on a server. These operations may include check for installed modules and their versions, download and installation of missing requirements, executing database scripts for data migrations, initialization of application files configurations and data structures. All these operations have to be executed outside of the main application context and before first request to the application will be handled.

Helicon Zoo provides means to execute deployment tasks on a remote server without having RDP or command line access and in restricted user environment. For example if you install one of the web applications available from Zoo repository, like Redmine or DjangoBB, you will see the “Application deployment in progress” message on the first request to the web site:

This application deployment process actually installs the application. You can see as various modules (gems) are installed, as database is created and configured, etc. And all these steps are taken in a local user’s environment with restricted user’s permissions. These application deployment scripts can configure only things inside web application folder or other resources available to user, but they are safe because they cannot change global components or write into shared or system folders.

Web application templates also include deploy script examples which can be used in the client’s applications. To learn more about application deployment with Helicon Zoo please read this documentation chapter.

Advantages of Helicon Zoo over existing solutions

Some of the web engines listed in this article can be executed on Windows and IIS without Helicon Zoo services. PHP is traditionally installed on IIS using Microsoft FCGI module, Node.js can run as a separate server or can be configured using iisnode, ColdFusion server supports Windows platform and can proxy sites into IIS using Jakarta connector. We don’t count other old solutions, like running apps as ISAPI modules (PyISAPIe) or executing scripts with CGI protocol as these solutions can’t be treated seriously because of their very poor performance. Here is a list of reasons why we think Helicon Zoo solution is better for providing shared hosting services:

Unified environment. Helicon Zoo is a single tool to run all these technologies and it provides single administration point.
Ability to run multiple technologies and versions on the same server and even same web site. For example you may have PHP 5.2, 5.3 and 5.4 installed and used on the same server at the same time.
Better isolation. Every application is executed in the restricted environment with credentials of application pool user. There are no privileged processes (like with traditional ColdFusion). No data, processes or settings are shared between different hosting users.
Custom modules. Users can have their custom modules installed into the application directory. No pain for administrators to maintain modules on the server. Additionally PHP users may have their custom php.ini files to configure PHP engine for their needs.
Automatic process management. Backend processes are created and recycled automatically to satisfy demand of the application and free resources for other users when possible.
Slow client optimization. With growth of the number of slow mobile clients this problem is becoming more significant. Synchronous web engines (like PHP) are very vulnerable to unbuffered slow connections and this vulnerability is often used as a DOS attack. Helicon Zoo buffers client communications protecting backends from slow connection problems.
Application deployment. Ability to execute deployment tasks without having command line or RDP access to the server.

Other things to consider

Many free and open source web applications where designed with Apache environment in mind as it is currently the most popular web server, especially when it comes to open source. While Helicon Zoo provides environment for running numerous applications on IIS, you can make application fall into thinking that it is executed on Apache by emulating Apache environment inside IIS. Helicon Ape product does exactly this thing by bringing support for .htaccess and .htpasswd files and emulating most Apache modules inside IIS environment.

These modules are very useful, not only for URL rewriting, proxying or permission control. There are usage scenarios that can improve user experience significantly. Consider, for example, following articles illustrating some basic applications of Helicon Ape product:

Search Engine Friendly (SEF) URLs for phpBB – doing search friendly URLs for phpBB with only several rules while phpBB does not support SEF URLs at all.
Make your websites work faster – with caching and performance improvements.
IIS reverse proxy and load balancer with web admin panel.
Counting downloads from your site – how to make comprehensive counters for specific resources.
Enabling site authentication not using Windows users.
Prevent DoS attacks with Helicon Ape mod_evasive module.
Protecting image gallery with Helicon Ape mod_hotlink.

Conclusion

Integration of Helicon Zoo and WebsitePanel is constantly improving. Our future plans are to integrate web application engines management into WebsitePanel interfaces. So the administrators will be able to choose which web engines users are allowed to run and manage restrictions in hosting plans. While it is possible to do this now by manually editing applicationHost.config files, web interface can significantly improve administrator performance. Users will also be able to turn web engines on or off for particular locations which can also add flexibility to the solution.

We will upgrade this article as new things come out and new questions get answered. Please stay tuned. You can read more articles about Helicon Zoo here.

While other companies invest hundreds of thousand dollars into development of their own cloud management solutions, you can already benefit from using free and powerful solution for running web applications on your facilities.

Please send your feedback to our support service or community forum.

Hosting Git, SVN and Hg (Mercurial) repositories on Windows with IIS

Slov — Thu, 30 Aug 2012 12:51:16 +0000

Git, SVN and Hg (Mercurial) currently are the most popular version control systems. In this guide we are going to show how to host repositories for these systems on Windows with Microsoft IIS 7+.

We will be using a magnificent free and open source tool – SCM-Manager. This is simple and nifty looking manager tool for Git, SVN and HG written in Java. Probably the best thing about SCM-Manager is that it includes all dependencies inside and does not require you to download and compile any third party components. You don’t have to install Git or any other kind of servers to host repositories. It does require Python and Hg package to host Mercurial repositories, but these packages can be installed automatically into the SCM-Manager home directory directly form web interface. So if your host support hosting of Java applications you don’t need access to the server console to install some components or run additional commands.

Hosting Java applications with Helicon Zoo

First of all you need to configure your IIS server to host Java applications. The easiest way to do this is to use Web Platform Installer.

Download and install Microsoft Web Platform Installer.
Run Web Platform Installer and click “Options”.
Add Helicon Zoo feed into “Display additional scenarios” box: http://www.helicontech.com/zoo/feed. New “Zoo” tab will appear.
Go to the Zoo –> Templates and select Java (Jetty) project.
Accept licenses to start installation process.

This will install all dependencies required to run Java application on IIS, including JVM, Helicon Zoo Module, etc. After installation of all dependencies is completed you will be presented with the standard Web Deploy dialog to create new web application:

Select “New web site” in the web site field and configure other options as usual.

Another good way to install all required dependencies is to install Zoo –> Packages –> Java Hosting Package. This package is usually installed on servers to allow them to host Java applications. The idea is that Java application can be simply moved from one IIS server to another just by copying web site folder, if both servers has Java Hosting Package installed.

Installing SCM-Manager

First you need to download SCM-Manager as a single WAR file here: https://bitbucket.org/sdorra/scm-manager/wiki/download Save this WAR file to the IIS web site folder and edit web.config file as follows:

Here the WAR_FILE environment variable contains the downloaded WAR file name. The SCM_HOME points to the /.scm folder under web site home, this will instruct SCM-Manager to store all files and repositories inside a web site folder. Note that write permissions to the web site folder for the user running Web Application Pool are required.

Now navigate to the web site created. The first start usually takes some time as SCM-Manager will create files and folder structures, configurations and Java Virtual Machine also needs time to start-up. After application initialization you should see a login screen. Enter the following default credentials to log in:

login: scmadmin
password: scmadmin

Don’t forget to change default password later. Now welcome to the dashboard:

Working with SCM-Manager

After installation you can immediately start creating empty Git and SVN repositories. To start using Hg open Repository Types page under config section and start Configuration Wizard for Mercurial. Select “download and install” and required packages will be installed into /.scm folder under web site automatically.

More often users ask how to import your existing repositories into SCM-Manager. All repositories are stored in the folder /.scm/repositories inside your web site. If you have FTP access to these folders you can simply copy entire directory structure of your repositories to the corresponding folders under /.scm/repositories. For SVN this is the only viable option to import repository as it uses central repository storage. Then click on Import Repositories link on the dashboard and your repositories will be imported into SCM-Manager.

Since Git and Hg uses decentralized repository storage, you can simply create empty repositories with web interface and then push your local repositories to the new location.

Now you can create users and groups, manage permissions, view commits and sources. And the most important feature of SCM-Manager is that it provides central point to administer all of your repositories from different source controls on a remote servers and over internet. And it is so easy to start work with!

Running Railo on Windows with IIS in production

Slov — Tue, 29 May 2012 14:38:27 +0000

Railo is a free, open source CFML engine, that is released under the GNU license. It is known to be highly performing and supported CFML engine available. Most existing ColdFusion applications will work on it. This article provides simple instructions how to install Railo on IIS web server in production. This solution can be used to run CFML applications on your Windows servers or provide CFML hosting to others.

Environment installation

First we need to configure the Windows server to run CFML applications. Please follow these instructions:

Download and install Microsoft Web Platform Installer.
Run Web Platform Installer and click “Options”.
Add Helicon Zoo feed into “Display additional scenarios” box: http://www.helicontech.com/zoo/feed. New “Zoo” tab will appear.
Go to the Zoo –> Engines and install Railo 3 or Railo 4 (or both).

Alternatively you can install Zoo –> Packages –> CFML Hosting Package. This will install both Railo 3 and 4 and all other requirements to host CFML applications on IIS.
Accept licenses to start installation process.

All required packages and dependencies will be downloaded and installed. Whole installation process may take time. After installation is completed your server is ready to run CFML applications as usual IIS web sites.

Usage

To create new Railo web site you can use Web Platform Installer again. Go to Zoo –> Templates and install Railo 3 or Railo 4 project.

You can set either IIS or IIS Express as target environment for this project and if you have not installed CFML Hosting Package, then all required dependencies will be installed automatically. After installation is completed Railo web site will start working immediately.

If you want to create Railo web site manually, please add an empty IIS web site for your application:

Create web.config file in the web site folder and put the following content into it:

This will enable Railo 3 to process requests for the registered file extensions in this IIS web application folder. To use Railo 4 set scriptProcessor=”railo.4″ instead. As there is no currently application files in this folder navigating to the root of the web site will trigger 403 error. So please navigate to the http://localhost/railo-context/admin.cfm to open Railo administration interface. For the first start you will be asked to create server and web administrator passwords.

After that you may just put your CFML application into this IIS web site folder.

Manual installation

Sometimes you may need to install specific version of Railo, or you may only want to install Railo for a specific IIS web site instead of installing it on a server globally. There could be a case when your hosting service does nto provide Railo support, but instead has support for generic Java applications. In this situation please follow this instruction:

If you are installing on your own server first you need to follow first three steps from “Environment install” chapter to get Helicon Zoo feed in Web Platform Installer. Now go to Zoo –> Packages and install Java Hosting Package. This will install support for generic Java applications for IIS.

Then go to the Railo Download page and get the WAR archive distribution version. Put this WAR file into IIS web site root folder and create a web.config file there with the following content:

Note the name of the file here is railo-3.3.1.000.zip. You may need to change it if your version of Railo is different. Also as you can see handlers are mapped to the asterisk – “*”, which mean every request to this web site will be processed by Java, including static files. Sometimes this is a good idea, especially if you are using some kind of URL rewriting or request filtering tools in your Java or CFML application. We have chosen to use asterisk map as it is more generic and will provide better application compatibility. But if you feel confident in server configuration, mapping handlers to specific file extensions (as it is done in web.config from automatic installation chapter) will give you some performance points, as static files will be processed directly by IIS.

Now you can navigate your browser to the web site root, which will bring you Railo welcome page. Then simply put your CFML application in this IIS web site folder to start working with Railo!

Installing Perl Dancer on Windows with IIS

Slov — Tue, 15 May 2012 14:21:56 +0000

Dancer is a popular open source web application framework written in Perl and inspired by Ruby’s Sinatra. Here is a simple step-by-step guide to install Perl Dancer on IIS for production use.

Environment installation

First we need to configure our Windows server to run Java Servlet applications. This is easily doable using following instructions.

Download and install Web Platform Installer.
Run Web Platform Installer and click “Options”.
Add Helicon Zoo feed into “Display additional scenarios” box: http://www.helicontech.com/zoo/feed. New “Zoo” tab will appear.
Go to the Zoo -> Packages and install Perl Hosting Package.
Accept licenses to start installation process.

After installation is completed your server is ready to run Perl applications using either FastCGI or Plack/PSGI protocol. Perl Hosting Package includes Strawberry Perl and some other modules, like CPAN Minus, etc.

Creating Perl Dancer web site

For the beginning create a new web site or application in IIS Manager. Either IIS or IIS Express are supported. Let’s name this site “dancer” and folder for it will be “C:\intepub\dancer\”. Now navigate to this folder using command line and run following commands in it:

cpanm -n -L .\perl Dancer

Installation process may take time and after it we will have Dancer compiled and installed with all dependencies in the “C:\intepub\dancer\perl” folder. Local installation is preferable as when you’ll need to deploy your application to the production server your site will have no dependencies, except for Perl Hosting Package from Helicon Zoo.

Now let’s create new Dancer application and call it “mysite”. This is done with the following two commands in the same location:

set PERL5LIB=.\perl\lib\perl5\
perl\bin\dancer.bat -a mysite

After site is created we need to provide write permissions to the “C:\intepub\dancer\mysite\logs\” folder. Dancer requires this permissions to run. Since we already have command line open in the right location, let’s use Windows “icacls” tool for it. Run the following two commands:

md mysite\logs\
icacls mysite\logs\ /t /grant:r "IIS_IUSRS:M"

As the last step we need to create web.config file in the root of the web site – “C:\intepub\dancer\web.config”. Put this code into the web.config file to activate Helicon Zoo for this location:

A little portion of magic and we have it all set. Just point your browser to the web site created and you should see a Dancer welcome page:

Slov — Mon, 02 Apr 2012 10:56:23 +0000

Provocative SEF URLs with ISAPI_Rewrite

Search Engine Friendly (SEF) URLs for phpBB

Slov — Wed, 21 Mar 2012 14:32:53 +0000

phpBB is the most popular bulletin board engine at the moment. It offers fantastic set of features but unfortunately Search Engine Friendly (SEF or SEO) URLs is not among them. Why you may need to have SEF URLs for your phpBB forum? Because Search Engines give higher rank for pages with keywords in links. Forum is usually a great traffic generator for your web site and by using SEF URLs you can significantly increase its search engine ranking. Additionally these URLs are more pleasant for human eyes since contain readable and understandable keywords and look cleaner.

By default URLs in phpBB are not search or human friendly. So here you can find simple solution how to turn this http://www.example.com/viewtopic.php?f=46&t=212 into this http://www.example.com/Search_Engine_Friendly_URLs_212.html

Our solution is to use Helicon Ape with mod_seo module. Unfortunately Apache does not have mod_seo module, so to use this solution you will need to have phpBB running on Microsoft IIS web server and install Helicon Ape on it. You can download latest version of Helicon Ape here.

mod_seo is a generic module that allows to modify (grep) portions of HTML output on the fly by using filters and regular expressions. Along with other features provided by Helicon Ape, like rewrite rules, conditions and database key-value maps it turns into a very powerful instrument for SEO. Various forums, blogs, shops and other services with dynamic content can be easily optimized for search engines with this module.

mod_seo can extract all links on the page, compare these links with regular expression patterns, find matching links, extract forum and post numeric IDs from these links, connect to existing forum database, get human readable and keyword reach topic names form database by IDs and then write modified links back to the HTML page before it gets to the user. Then mod_rewrite rules can be used to rewrite URLs back when user requests using these modified links. Main advantage of this technique is that it does not require any change to the forum source code. This means that you do not lose ability to upgrade your forum in future and use standard packages from the code vendor.

So what you need to do to get it working. Suppose you already have phpBB running on Microsoft IIS server. Install Helicon Ape on the server. You can find installation instructions here. By default Helicon Ape will be enabled for all sites on the server, so you may just create .htaccess file in your phpBB folder and put the following content into it:


# Enable mod_rewrite and mod_seo for current location
RewriteEngine On
SetEnv mod_seo

# Connect to database
DBDriver mssql
DBDParams "Data Source=(local)\SQLEXPRESS;Initial Catalog=phpbb;User ID=sa;Password=123456"

# Prepare SQL queries to find topic or forum name by ID
DBDPrepareSQL "SELECT forum_name FROM phpbb_forums WHERE forum_id=@KEY" getBBForum
DBDPrepareSQL "SELECT topic_title FROM phpbb_topics WHERE topic_id=@KEY" getBBTopic

# Declare database rewrite maps
RewriteMap BBForum dbd:getBBForum
RewriteMap BBTopic dbd:getBBTopic

# Needed to make strings URL-safe
RewriteMap slug int:slug

# SEO rules to change topic links on pages:

# viewtopic.php?f=46&t=2151&start=15 -> Topic_Title-46-215.html?start=15
SeoRule viewtopic.php\?f=(\d+)\&t=(\d+)(?:&start=(\d+))?$ \
    ${slug:${BBTopic:$2}}-$1-$2.html(?3\?start=$3) [Redirect, Scope=A]

# viewtopic.php?f=6&t=3&p=28#p28 -> Topic_Title-46-215.html?p=23#p=23
SeoRule viewtopic.php\?f=(\d+)\&t=(\d+)\&p=(\d+)$ \
    ${slug:${BBTopic:$2}}-$1-$2.html(?3\?p=$3) [Redirect, Scope=A]

# Check for possible incorrect topic name and redirect to prevent duplicate content
RewriteCond ${slug:${BBTopic:$3}}#$1 ^([^#]+)#(?!\1).+
RewriteRule ^(.+?)-(\d+)-(\d+)\.html$ %1-$2-$3.html [NC,R=301,L]

# Rewrite topic URLs back
RewriteRule ^.+-(\d+)-(\d+)\.html$ viewtopic.php\?f=$1&t=$2 [NC,QSA,L]

# SEO rules to change forum links on pages:

# viewforum.php?f=6&start=100 -> viewforum-Helicon-Zoo-6.html
SeoRule viewforum.php\?f=(\d+)(?:&start=(\d+))?$ \
    ${slug:${BBForum:$1}}-$1.html(?2\?start=$2) [Redirect, Scope=A]

# viewforum.php?f=8&sid=xxxxx -> viewforum-Helicon-Zoo-6.html?sid=xxxx
SeoRule viewforum.php\?f=(\d+)&sid=(\w+)?$ \
    ${slug:${BBForum:$1}}-$1.html?sid=$2 [Redirect, Scope=A]

# Check for possible incorrect forum name and redirect to prevent duplicate content
RewriteCond ${slug:${BBForum:$2}}#$1 ^([^#]+)#(?!\1).+
RewriteRule ^(.+?)-(\d+)\.html$ %1-$2.html [NC,R=301,L]

# Rewrite forum URLs back
RewriteRule ^.+-(\d+)\.html$ viewforum.php\?f=$1 [NC,QSA,L]

Don’t forget to use your database user name and password to connect. We are using SQL Server Express as a database for phpBB. For MySQL database connection string may look like this:

DBDriver mysql "MySql.Data, Version=6.2.2.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d"
DBDParams "Data Source=server;Initial Catalog=database; User ID=database;Password=password"

The rules above are rather generic and you may want to change them to better meet your specific needs. Nevertheless, after putting them into the .htaccess file SEF URLs on your phpBB forum should immediately start working. New links will appear on forum pages and old links will be redirected to the new format to prevent duplicate content penalty. You can try example of mod_seo optimized phpBB on our community forum.

Hope you will enjoy this solution and wish you highest search rankings!

Ruby on Rails on Windows in production

Slov — Thu, 02 Feb 2012 12:49:01 +0000

Windows environment has been traditionally treated as no-way for Ruby developers, especially when it comes to production. In the following article I will show how easy and efficient it could be setting up your Ruby environment in Windows for both development and production purposes using Helicon Zoo. And performance tests at the end of the article will show whether Windows system can be treated seriously as a production environment.

This article covers following topics:

Installing development environment.
Writing a simple application.
Preparing your application for deployment.
Deploying the application to the production server.
Compare performance with Windows Server 2008 with IIS 7.5 and Ubuntu Linux with Apache and Nginx.

Setting-up development environment

Before we can publish our application to the world, at least we need to test if it works in our environment. And here how you can set up working Ruby environment that will use IIS as a web server. Windows XP, Vista, Windows 7, Windows 2003, Windows 2008 (R2) and Windows 2012 are supported.

First please download and install Microsoft Web Platform Installer ( WebPI ), run it and click Options. Add the link to Helicon Zoo Feed http://www.helicontech.com/zoo/feed.xml into the «Custom feeds» field.

Please note web server choice – IIS Express or IIS. The main difference is that IIS Express runs as interactive user application which usually means Administrative permissions if you are logged in as Administrator. This simplify development process and decrease number of possible issues you may encounter with insufficient NTFS permissions to run application. With IIS web applications are executed as a restricted user and may require additional permissions tuning, but you will get environment that is more close to those which will be used to run application in production. In this article we will be using IIS Express with WebMatrix as a development environment and IIS for production.

After adding custom feed new Zoo tab will appear with Applications, Templates, Packages, Modules and Engines sections in it.

Applications – are some ready to use web applications that are included into Helicon Zoo feed, that come with all required dependencies and can be installed on a clean system in a few clicks. You can use this section if you simply need to install one of these applications on your server.
Templates section contain empty projects for each web application technology that is currently supported by Helicon Zoo. You use these templates as a starting point to develop application of particular technology or to host existing application. For example in this article we are going to use Ruby project template.
Packages include complete Hosting Packages for each web application technology that is supported by Zoo. You install one or more hosting package from this section to enable hosting of the whole technology class on the server. Each package contains all dependencies that may be needed. For example Ruby Hosting Package contain Ruby 1.8, Ruby 1.9, Ruby 2.0, Dev Kit, Helicon Zoo Module and some other modules that may be needed and have to be installed globally. We will be installing Ruby Hosting Package in a production environment later.
Modules contains some useful applications and modules that are usually installed on server globally, like Helicon Ape, MongoDB, PostgreSQL, RabbitMQ, etc. Some of these modules are not intended to be installed separately from Hosting Packages.
Engines section contains engines itself, like Ruby, Python, Perl. Please note that installing these engines will not enable them in IIS environment. You should not install these engines manually, please use corresponding Hosting Package or Template instead.

Creating simple Ruby application

The good thing about Helicon Zoo is that creating new application and installing application environment is done in one step because application will check and install all needed dependencies automatically. Please go to Zoo –> Templates, choose Ruby project and install it.

Depending on the server chosen (IIS or IIS Express) and your system configuration many components may be downloaded and installed first time. Hopefully everything goes right and all sites with required components will be online, so your environment should be configured soon.

Warning: If you have already manually configured Ruby environment, please use packages that come with Helicon Zoo through the feed and Web Platform Installer instead. The Helicon Zoo packages has nothing magical inside, we simply install Windows Ruby Installer and DevKit packages from official web site in default locations (like C:\Ruby19, C:\Ruby18, C:\Ruby20) which is important since these locations are hardcoded in some other components, set correct NTFS permissions for IIS_IUSRS group, etc. And even though it is possible in theory to use your custom Ruby installation with Helicon Zoo, our experience shows that it will most likely bring numerous issues. Helicon Zoo requires default Ruby configuration and needs no globally installed gems – this is the idea of isolation. If you configure your Ruby instance manually we may be unable to provide support for it.

If you have chosen IIS Express as a web server, after installation is finished the WebMatrix will be launched automatically and you should see project’s index page with further instructions. With IIS installations additional step is required where you choose port and host name bindings, a folder on disk where to put web site, etc. IIS Express web sites are created in \Documents\My Web Sites\.

This Welcome page is displayed when no Ruby application is present in the folder using URL Rewriting Module, therefore Microsoft URL Rewriting Module is a dependency for Ruby project template, otherwise you may see the error. When application with a config.ru file appears in the folder this page will be substituted by a real index page.

The initial project’s content is very simple:

An empty console folder that is simple placeholder if you wish to configure authentication for web console access later. Public folder that is used to store static files (including welcome page), deploy_sample.rb file that we will talk on later and web.config file that is essential to configure Zoo application in this folder. If you have some existing Ruby Rack application you can simply copy it’s files into the root folder keeping existing files intact and it should start working with very little or no modifications at all.

The instruction on Welcome page asks us to click on a link and start Web console, but we will learn one more tool before – Helicon Zoo Manager. Go to Start menu, Helicon –> Zoo –> Helicon Zoo Manager (either for IIS or IIS Express depending on the server type you are using). This manager lists all your current web sites and here you can modify configuration of Helicon Zoo Module, enable or disable engines, set environment variables, start Web Console or IDE, etc. By default Helicon Zoo will run Ruby application using Ruby 1.9 Rack and you can change this using Helicon Zoo Manager. After launching the manager select the web site you are currently working with in the left tree. The only application named ruby.project will be pre-selected, so let’s click on Edit button and change RACK_ENV environment variable from production to development. Press Apply on the properties window and Apply on the main window to save settings into web.config. Production mode ensures faster operation, but with development mode we don’t need to restart IIS Express application every time we modify some files in the application and additionally we get more verbose error messages. With some hosting services you can have two different web.config files for production and development environment which is convenient.

Then click Start web console button to launch console for this application.

You may ask why using this web console if I can just run cmd.exe or any other IDE to run commands? The answer is because Helicon Zoo web console is designed to run commands in the isolated environment of your application, so all these commands are applied to the application you are working with, using local folders and environment variables and executed by the same interpreter and same IIS Application pool user that runs the application itself. This is needed to keep applications portable because all modules and components are installed into the application folder and execution environment is easily replicable with Helicon Zoo Hosting Packages installations on other machines. On the other hand if you launch Windows console from start menu you may actually have number of environments and interpreters installed on your machine, like several different versions of Ruby and Python. With Windows console when you run a command you can’t tell for sure what exact version of interpreter you are calling, where it is located, where will it store it’s settings, etc. IDEs and commands to install modules will usually install them globally into the system, so your application will lose portability. There could be conflicts between different versions of engines or modules installed in the system when you run global command line interface. This is why it is always recommended to install web application engines like Ruby or Python distributions using Helicon Zoo repository, for example by installing Hosting Packages, instead of installing engines manually. And use of Helicon Zoo web console or launching IDE from Helicon Zoo Manager may also be essential if you want to avoid version conflicts and retain application portability.

This console runs by Zoo Module as HTTP application in your browser. Anonymous remote requests to console is prohibited by Zoo engine for security reasons. So if you wish to access console on a remote server you will have to enable one of the authentication methods for the console folder (or whatever location you have configured as a console). Or you can use IIS Manager to connect to remote server and start console from Helicon Zoo IIS Manager snap-in. The Helicon Zoo Manager installs snap-in for Internet Information Services Manager, which you can use even in remote mode, when IIS Manager is connected to a remote server.

The one-time hash code will be used to authenticate console session and will be invalidated when you close the console window. The ability to start web console can be enabled or disabled globally and for individual applications which is useful for hosters. Please read more about web console here.

So start web console and type:

gem install rails

And go get some coffee, because this command takes really, really long and works mostly silently. Please be patient and don’t try to restart the console, honestly, it is working. For me sometimes it takes about 20 minutes of ‘installing Rails’, which I guess, depends on internet speed, system configuration, etc. If you close console window it will kill the console process on the remote server within 10 minutes and all spawned processes as well. Same if you click on Cancel button in the bottom right corner – this will kill console and all child processes on remote (or local) machine immediately and restart the console. This button is useful if something went really wrong, like a command hang. After command is finished you should see normal output of ‘gem install’ command.

Notice short path in console – these are needed because many Ruby scripts don’t work well with long path. And forget about umlauts and other national characters in file names. If you need them in links, you can add them later using URL mappings. The ‘gem install’ command can not only download and install gems, but thanks to DevKit can also compile native C-gems right on your system.

Let’s look into our project file structure now. You may need to hit F5 on the root node in WebMatrix to refresh it.

Notice new GEM_HOME folder – this is where all gems have been installed. When the application is executed Helicon Zoo will use gems from this folder. The sad thing here is that you will have to repeat ‘gem install’ operation for each application you are working on. Though you can still have global gems it is not recommended. But the good thing is that you may have different versions of gems for each application. You may have different versions of Rails, Sinatra or anything else for every application with no conflicts. You can update Rails for one application and still have your legacy code running on older versions in other sites. Isolation – is the key feature of Zoo.

So rails and other dependent gems are installed, but this is not a Rails application yet. Let’s create one by running the following command:

rails new .

Now if we look at web site content we’ll see new folders and files – new Rails application is finally created.

Refresh the application page in the browser and you should see Ruby on Rails welcome page now (may require IIS Express application restart sometimes):

Integrated Development Environment

Another useful feature of Helicon Zoo Manager is the ability to start IDE for the application environment. This is not just a shortcut to your favorite IDE. Before launching IDE Zoo Manager will configure environment according to the environment variables of the selected application. Most current IDEs can read these environment variables to configure locations correctly. Locations like gem installation folders, working directories, Path variable with correct locations of Ruby interpreter of required version, etc. Open Helicon Zoo Manager and click on Start IDE. When you do this first time for the application a small Select IDE dialog will appear. By default it opens Windows Command Line (cmd.exe) and this is a convenient replacement for the Web Console if you develop application locally. This command line interface will be launched with all path configured for your application, therefore ‘gem install’ command will install gems into the application folder same as with web console. The difference with web console is this cmd.exe is executed as interactively logged on user, while web console is executed as IIS application pool user, which may differ in permissions significantly. So for development purposes and on local machine using Start IDE command is even more convenient than web console.

But instead of using ascetic command line you can configure your favorite IDE to start with this command. Environment variables will be configured before launching application and IDE will know correct locations of files, like GEM_HOME, location of Ruby interpreter, etc. For example to start Aptana with the project’s folder already open you can use following command:

AptanaStudio3.exe "%APPL_PHYSICAL_PATH%

If you prefer IDE with debugger and refactoring tools, we recommend one of the following options:

Aptana (free, http://aptana.org)
NetBeans (free, http://netbeans.org)
RubyMine (commercial, http://www.jetbrains.com/ruby/)

Each of these offers a bunch of development and testing tools for Ruby apps and supports version control.

For those who will make do with simpler solutions there are:

KomodoEdit (free, http://www.activestate.com/komodo-edit)
Redcar (free, http://redcareditor.com/)
SciTE (free, http://www.scintilla.org/SciTE.html)
E TextEditor (commercial, http://e-texteditor.com/)

For our app we used Aptana:

MVC

Ruby on Rails is based on the MVC architecture (model, view, controller). This approach has several advantages:

Isolation of business logic from interface;
Less code repetition (DRY principle — don’t repeat yourself);
Relatively simple development hanks to strict code distribution based on purpose (e.g. the code for HTML form output is not mixed with the code for DB processing).

Model defines the database structure in terms of object-oriented programming. In Rails model is an ordinary class inheriting all necessary functions from ActiveRecord::Base class. Instance (object) of this class defines one line from the corresponding database. Thus, models conceal the peculiarities of interaction with particular DBMS from developer.

View is the interface shown to users. On this stage developer creates templates which are transformed into HTML, CSS orJavaScript code.

Controller connects model with view. It’s usually controller that contains the main logic. Essentially, controllers are Ruby classes. Each public method of controller is called action. If you have controller named “Home” and it contains the method named “index”, then running /home/index in browser will evoke “index” action.

When a request comes to the application, the routing mechanism (in config/routes.rb file) decides which controller cares about that type of requests. Aside from the URL a set of other conditions may be taken into consideration, e.g. you can assign different controllers for different browsers, for mobile clients etc.

So, having chosen the controller, it defines what action will process the request. At this point one can also apply numerous conditions. The action itself performs some calculations and DB-related operations. When the action is finished the view comes on the scene. The data from DB or some result are transmitted to the templates. Then the HTML page is generated from the templates (there are templates from CSS and JavaScript as well) and the response page in sent to the user.

Writing the application

The classic example of Rails app is the simplest blog. We won’t ignore this tradition. So, let’s create controller “Home” with action “index” – this is going to be the blog main page. This is done with the following command:

rails g controller home index

If we now request /home/index, we’ll get the page from the template created for “index” action.

Afterwards, we’ll create a simple Post model which will define each blog entry in the DB. In Ruby code the model is a class and it is represented in DB as a table. Thus, the object of Post class is a line in the corresponding table in database.

To create model you can simply run “rails g model Post…” but let’s make use of a very handy tool – scaffolding. The “rails g scaffold” command creates not only the model class itself and tests for it, but also actions drafts and views templates for adding, editing and removing model objects. If we execute this

rails g scaffold Post name:string title:string content:text

we’ll get “Post”model in app\models\post.rb, “Posts” controller in app\controllers\posts_controller.rb with actions index, show, new, edit, update, create and destroy, plus a DB migration scenario in db\migrate. The command will also have created the headers for tests and HTML templates. Notice that we haven’t yet written a single line of code!

Now we are going to install the database. In this example we use SQLite which is default for Rails. However Rails can work with many other DBMS hiding details of their cooperation from the user. Please call the following command to install SQLite:

gem install sqlite3

Next, we’ll run the command to create the database (if it’s not yet created) and the table “posts” with the fields “name”, “title” and“context”:

rake db:migrate

The command for database migration is applied for creating and editing database structure in accordance with our object model. It should be executed every time you make changes to the application model. All the magic of matching the DB structure with our model is done automatically and all the data stored in the database are retained.

Actions of “Post” controller are accessible at /posts/ address.

If you press “New post”, you’ll see the form:

After filling all fields we get to the new post page:

Note that there was still no code written. Now let’s do some editing. For instance, we may need to make post name and post title obligatory fields so that corresponding cells in the DB are always non-empty. Luckily, Rails provides very simple validation mechanism. We should just fix the model file, which is app\models\post.rb as follows:

class Post < ActiveRecord::Base
      validates :name,  :presence => true
      validates :title, :presence => true,
                :length => { :minimum => 5 }
end

In there we specify that “name”and“title” fields are obligatory and “title” should contain not less than 5 characters. No need to apply migration after this change as validators are not directly related to database; the check is performed on the level of Ruby code.

If you now leave the “name” field empty, you’ll get an error:

Let’s make it a little more complicated and add the comments feature. We’ll create a “Comment” model with the following command:

rails g model Comment commenter:string body:text post:references

Pay attention to “post:references” parameter. It connects «comments» table with “posts” table.

Now refresh the database:

rake db:migrate

next, we’ll set up the relation “has many” for Post model:

class Post < ActiveRecord::Base
      validates :name,  :presence => true
      validates :title, :presence => true,
                :length => { :minimum => 5 }

      has_many :comments, :dependent => :destroy
end

The code is intuitively clear. Each Post object may have a number of comments. “:dependent => :destroy” tells that when post is deleted all comments are deleted as well. As we didn’t use scaffolding this time to create a model for comments, we now need to generate corresponding controller:

rails g controller Comments

In config\routes.rb file replace “resources :posts” with:

resources :posts do
   resources :comments
end

In this way we specify how the “comments” controller will be available. In our case it’s put into “posts”, so the links will look like http://localhost:41639/posts/1/comments/3

Then we need to refresh the template app\views\posts\show.html.erb so that it will become possible to add comments. After:


  Content:
  <%= @post.content %>

add the following code:

Comments
<% @post.comments.each do |comment| %>
  
    Commenter:
    <%= comment.commenter %>
  
  
    Comment:
    <%= comment.body %>
  
  
    <%= link_to 'Destroy Comment', [comment.post, comment],
                :confirm => 'Are you sure?',
                :method => :delete %>
  

<% end %>

Add a comment:
<%= form_for([@post, @post.comments.build]) do |f| %>
  
    <%= f.label :commenter %>

    <%= f.text_field :commenter %>
  
  
    <%= f.label :body %>

    <%= f.text_area :body %>
  
  
    <%= f.submit %>
  
<% end %>

Finally, we’ll define the logic of controller operation in app\controllers\comments_controller.rb

class CommentsController < ApplicationController
  def create
    @post = Post.find(params[:post_id])
    @comment = @post.comments.create(params[:comment])
    redirect_to post_path(@post)
  end

  def destroy
    @post = Post.find(params[:post_id])
    @comment = @post.comments.find(params[:id])
    @comment.destroy
    redirect_to post_path(@post)
  end
end

And everything is ready for adding comments to the post:

The basic functionality is implemented. As the last step we’ll protect some of the actions, so that unwanted people don’t have access to them. The more comprehensive way is to use registration, sessions, cookies etc., but to stay simple we’ll take Basic authentication, the more so because in Rails we need only one line to enable it. Put the following in posts_controller.rb:

 http_basic_authenticate_with :name => "admin", :password => "123",
                              :except => [:index, :show]

We have hard coded the login and password. “:except”parameter excludes “:index” and “:show” actions as they don’t need authentication.

Deploying on production server or hosting

So, we’ve created the application and now, logically, want to publish it to the Internet. For that purpose we’ll set up Windows server to work with Ruby in production. We’ll have to repeat several steps from the beginning of the article which were used to install development environment, but this time we’ll configure production IIS server. If you are considering to organize Ruby hosting on Windows servers you will need to complete exactly the same steps as following:

Install Microsoft Web Platform Installer.
Add Helicon Zoo feed. Naturally this time you choose IIS as a target server instead of IIS Express in WebPI options.

Now install Ruby Hosting Package from Zoo –> Packages.

This will install Ruby 1.8, Ruby 1.9, Ruby 2.0 and Development Kit packages from RubyInstaller normally into C:\Ruby18; C:\Ruby19 and C:\Ruby20 folders respectively and set correct NTFS permissions for these folders for default IIS installations. You can update these installation packages manually then, leaving installation folders as they are, because these folders are hardcoded in some WebPI components. But remember – installation packages form Zoo repository has been tested with Zoo while you are upgrading on your own risk. You may consider that installing all three packages of Ruby is waste of resources when you need only one, but they are small and installation completes fast so it doesn’t worth worrying. Plus with Zoo system these packages will not conflict. Ruby Hosting Package may also install IIS and other required Windows components if they are not already installed in the system. Eventually it will install Helicon Zoo Module which is required to host these applications with IIS.

After these steps are completed the server is ready to host our application. For the moment the following server platforms are supported: Windows Server 2008 and 2008 R2 and Windows 2012, all 32-and 64-bit versions when applicable. The reason why older versions are unavailable is because Helicon Zoo Module uses native IIS 7 API, therefore everything prior IIS version 7 is unsupported and all newer versions of IIS should be fine.

So, at first, we create an empty web-site via IIS manager or your hosting panel. Then simply upload entire web site folder with your application to the server via FTP or Web Deploy or any other way. I would recommend to configure Web Deploy on the production server. This tool makes deployment of applications from WebMatrix or Visual Studio really easy, plus all application folders and files will be given proper permissions automatically, as they’ve been set by Helicon’s Ruby project template. Generally you may need to enable write permissions for entire web site folder for the user running application because Ruby application will want to write things sometimes. You can also use Git or any other version control system and deployment system, but that falls beyond the scope of this article, same as write permissions fine tuning.

Then, in general, you just navigate to the web site and it opens. The application will be executed on Windows Server under IIS with the help of Helicon Zoo Module. This module was initially designed as a hosting solution, so all applications are isolated and do not interfere. The module with its default options works in fully automatic mode, creating one worker process per application by default, when the load is low and increasing the number of workers up to the number of CPU cores of the server providing maximal performance under heavy loads. These settings can be changed on per-engine level using Helicon Zoo Manager.

Helicon Zoo implements the concept of engines and applications. The engines define how to run an application, which interpreter to use, which protocol and port, what maximum number of workers are allowed and other global settings which are defined in applicationHost.config, so if the user has no write permissions to applicationHost.config then he can’t change engine settings. Then, Helicon Zoo application ‘uses’ the engine by referencing it from web.config file from inside web site folder. Each engine may have list of parameters – Environment Variables, which users can set. This concept allows for separation of hosting administrator duties from the clients’ burden (and client from client as well). You can learn more about Helicon Zoo Module configuration here.

Sometimes, when your application is not just an empty database-less blog as in our example, simply copying files to the production environment is not enough. For example, your application may use external database server and you may need to execute database migration tasks in production environment before the new code could be executed. For this purpose Helicon Zoo offers very convenient tool called deploy scripts. Please notice DEPLOY_FILE=”deploy.rb” environment variable in the Helicon Ruby project template. This means every time when Helicon Zoo engine finds deploy.rb file in the root of the web site it will do the following:

All currently running Ruby processes will be shut down using soft-shutdown sequence.
All running requests and transactions will be allowed to run till they are finished, unless soft-shutdown timeout is exceeded.
All newly coming HTTP requests to the application will receive 503 Application Maintenance status.
These new requests will see the “Application deployment in progress” page.
When no running workers left, the deploy.rb file will be executed in a separate process using same interpreter (i.e. Ruby) and same user as declared in web site’s configuration.
After deploy script execution is finished with no errors all users currently seeing “Application maintenance” message will be redirected to the pages they where originally requested.
The deploy.rb file is renamed to deploy_done.rb.
New worker processes will be started and application execution continues.

Here is how Application deployment in progress message looks by default:

In Ruby project template there is a file named deploy_sample.rb. This file contains common deployment instructions for database migrations, etc. So to initiate deployment process you will only need to rename that file from deploy_sample.rb into deploy_rb and push it to server. You may want to make it your last change to the project when you upload changes so to make sure all other scripts and files has been updated before deployment process initiates. If the RACK_ENV environment variable is set to production, Ruby will not load updated code files unless restarted, so initiating deployment process will do all things synchronously – migrate database and then load new code into engines. This is so-called “cold application maintenance” which is needed because if other user requests (with either new or old code) will be running while database migrations and other deployment tasks are executed the data could be corrupted or user could get unpredicted responses. Helicon Zoo minimizes application downtime to even seconds and automates whole deployment process so it becomes easy to deploy large applications across array of servers.

Please read more about deployment scripts in Helicon Zoo documentation.

Performance tests

Machine used as a server contained Core 2 Quad 2.4 Ghz, 8 Gb RAM, 1Gb LAN. For load generation we took more powerful PC and Apache Benchmark tool with a command “ab.exe -n 100000 -c 100 –k”. For Apache and Nginx servers we used Ubuntu 11.04 Server x64. IIS 7 tests were run on Windows Server 2008 R2. No virtual machined where used – bare hardware.

We’ve conducted three test scenarios:

Rails had to output the current time in high resolution. The time was chosen to ensure the response doesn’t come from cache;
Rails read from MySQL database and;
Rails performed writing into MySQL database.

We performed tests with Ruby 1.9.3, Rails 3.1.1 and MySQL 5.1.54. in case of HTTP transport, Thin acted as a backend HTTP service. Neither Unicorn nor Passenger work for Windows. So, there were three configurations for testing: Windows + IIS 7.5 + Helicon Zoo + Thin, Ubuntu + Apache + Passanger, Ubuntu + Nginx + Thin.

Below are tests results (in requests per second):

Here are more detailed ab graphs for the first test (time output):

Resume

Ruby on Rails proved itself a perfect framework for quick and easy web development. Of course, Ruby is not the one and only. In the next articles we’ll shed some light on Goliath and Sinatra.

We would also like to underline that Windows is a mighty platform for both development with Ruby and running Ruby-apps in production. And if earlier the difference in Ruby performance on Linux and Windows was dramatic, now the performance, as well as convenience of Ruby on Rails for Windows has significantly improved to a degree that performance is no more a key criteria for choosing the platform.