My personal views, thoughts and opinions.

Tuesday, February 24, 2015

Free static web hosting with GitHub


My old hosting provider (GoDaddy) had a cheap, intuitive and powerful Website Builder interface I used to set-up a nice looking 4 page web site for a friend.

With this interface he managed to add content without asking a single question, although he has none of the technical skills usually involved with such task.

Actually the interface is still intuitive and quite powerful, but after the first year it is no longer cheap.


So I tried to find a replacement. I first tried some local web hosting companies, but the problem was that I had to configure my web server.

Then I took a look at Google Sites. The site offered free web-based editor. I was able to build a site for half an hour. Most of this time I spent trying to tweak the ugly templates.

After I gave up I decided to change the default host name with the domain I already had with GoDaddy. This took another 30 minutes, and neither CNAME, nor TXT validation actually worked. I guess I was quite impatient.


In the end I realized that I actually need a single page with 4 things on it and I can simply use a single HTML page for that. And probably a free hosting with several MB still exists out there.

Not quite true according to my google search for "static page hosting". Seems nobody really wanted to provide such static HTML hosting any more.

Then I remembered a talk I had with my colleague. We were wondering if we can blog directly on GitHub instead of using special blog sites (like this one). I decided to give it a try and came across this blog.

It described perfectly the pain I feel from the existing hosting solutions, plus 2 methods to host static web sites in Dropbox and GitHub.


Since I'm a developer I decided to try the GitHub way and came across this nice help guide on their site.

After 2 attempts I ended with a web site consisting of a single index.html and CNAME file describing the domain mapping I want to use.

Changing the DNS record in GoDaddy was taken in effect almost instantly (as with Google Sites by the way), and after 10 minutes I had a working site.

Picture Gallery

As a bonus I found out I can use to embed a nice looking gallery, instead of the monstrous widgets in Website Builder and InstantPage (both from GoDaddy) or the unsuccessful attempts to add a widget or iframe in Google sites.

Tuesday, August 05, 2014

Cloud Foundry on VirtualBox

There are a lot of ways to build and try Cloud Foundry, but the easiest (and most cost-effective) I found so far is to use the Nise Installer.

The installation process:
  1. Install VirtualBox 
  2. Download Ubuntu Server 10.04 LTS 64 bit
  3. Create a VM with at least 10GB disk and 4GB memory
  4. Leave the first network adapter NAT-ed (for internet access)
  5. Make a second adapter that is Host-only (for host OS access)
  6. Install Ubuntu Server
  7. Install curl
  8. Launch the script (as documented on the Nise Installer page)
  9. Restart the VM to get the new kernel in place 
If you are lazy go get the already created VM image from my Google Drive. 

To start the Cloud Foundry instance:
  1. Go to cf_nise_installer directory
  2. Launch CF with ./scripts/ 
You may need to relaunch the script or stop/start again in case some of the components failed.

To access the Cloud Foundry instance:
  1. Get the IP of the VirtualBox Host-Only Ethernet Adapter with ipconfig /all or ifconfig -a
  2. Add a route from to the IP of the VirtualBox Host-Only Ethernet Adapter. 

    For example in Windows that would be:  
    route add  

    , where is the IP of the Host-Only adapter.

  3. Install CF CLI on your client machine
  4. Login to the CF instance using the login command provided at the end of the start via
    the ./scripts/ script

To create organization and space you can use:
cf create-org me
cf target -o me
cf create-space development
cf target -s development

You are ready to push an app and have fun.

Thursday, February 06, 2014

SAP HANA Cloud: OpenSocial widgets auto-discovery and operation

Recently we added functionality that enables deployment of OpenSocial widgets and their auto-discovery in SAP HANA Cloud Portal. 

As Wikipedia states:
OpenSocial is a public specification that defines a component hosting environment (container) and a set of common application programming interfaces (APIs) for web-based applications. Initially it was designed for social network applications
You can check the developer guide for OpenSocial widgets in the Portal for more information how to create such widget. 

There is also a short topic on how to package the widget which notes that your spec.xml needs to be:
  • publicly accessible resource
  • named so that it ends with the .spec.xml suffix
  • with name, description and thumbnail that will be shown in Portal Content Catalog

Deploying & running your widget as SAP HANA Cloud application allows you to use the Portal auto-discovery. This means that when your application is started successfully on the HANA Cloud, it will be visible in the Portal Content Catalog, so you can build a site with such widgets.

Soon you should also be able to deploy Cloud Portal sites with the widgets layout you created. Of course we will also be able to do auto-discovery for them as well.

The widgets has to be running and accessible no matter if hosted or not in SAP HANA Cloud. This is needed so the Portal can fetch the spec.xml from the publicly accessible URL of the widget application.

Since widgets and sites are relatively small, they will make small application packages (WAR files). To run several widgets you may need several compute units and you may need to pay for all of them.

However there is a way to combine several small WAR files and run them on a single compute unit as a single application. 

Just copy all WAR files in one directory and use the Command Line deploy command to deploy the whole directory. As the documentation of deploy command states you can use the --source parameter to provide:
a comma-separated list of file locations, pointing to WAR files, or folders containing them
The result will be a single application from SAP HANA Cloud point of view (lifecycle, monitoring, billing), having multiple WAR files running inside.
Please have in mind that all these applications (no matter if widgets or plain Java apps) are running on  the same compute unit and they share the memory, CPU and storage resources of the unit.  

So if you have resource hungry applications, perhaps it is not very wise to save money by increasing the response time (or latency) of your customers.

You can however use this multiple-wars-in-a-single-application approach for development or testing environments, modelled for staged development

So use this for testing, but beware the performance impact for productive scenarios.

Thursday, December 05, 2013

Unbricking DD/OpenWRT routers

The recent news about a new Linux worm that attacks routers made me download and flash the latest version of dd-wrt with the hope that it will have newer versions of the binaries and thus ensure better protection.

Unfortunately after update and following restart the router was rendered useless. Obviously the downloaded firmware was damaged. I had a brick, while only a moment ago this was my home router - the ageing Linksys WRT160NL.

I had to search some sites on my mobile only to find out that in order to unbrick it I may:
  • do factory reset
  • use JTAG and serial cable (or on new machines USB-to-serial cable)
The factory reset did not work. Although the router happily flashed its LAN, WAN and power lights it did not establish connection with my Windows 7 machine, nor had its wireless SSID broadcast. 

So I started investigating the other alternative - uploading new firmware via the serial communication header in the router. The sites mentioned TFTP and then it hit me. I managed to flash Buffalo router a while ago, just by using the built-in boot-loader and TFTP PUT request. It should be possible to do the same since the router seemed to have its lights functioning and therefore at least part of the boot-loader working.

I asked Google and found out in OpenWRT wiki that this should be fairly easy to do. The wiki commanded:
1. Turn off the power to the router and leave it off until the final step.
2. Make sure your computer has a static IP address from 192.168.1.x (eg.
3. Make sure the ethernet cable is plugged into one of router's LAN ports and the other end into computer's ethernet port
3. cd to the folder where you have the image
4. change the name of the new firmware to code.bin , then type :
5. echo -e "binary\nrexmt 1\ntimeout 60\ntrace\nput code.bin\n" | tftp
6. plug the power into the router, it should flash.
Well needless to say this didn't worked - I was on Windows. I had the Microsoft TFTP client, that established connection instantly and never looked back to retry. 

Fortunately I had Cygwin installed as well. So I just had to download and install the tftp package. Without router and therefore an internet connection.

I've found the OpenWRT wiki on my iPad using internet via WiFi tethering. So I enabled the USB tethering this time, and used it to update Cygwin and add proper TFTP client to my Windows system. I also downloaded older version of the firmware.

It took me a matter of minutes to try the steps above and to restore my router's firmware.

I even flashed the (hopefully) latest and greatest version of the dd-wrt firmware for 160NL.
Re-downloaded of course.

Thursday, October 31, 2013

SAP HANA Cloud: Application properties. Multiple connections

The latest update of SAP HANA Cloud Platform (we've changed the name again) includes two small but important changes. Copied from the release notes:
  • Deployment with multiple connections:
"You can use the --connections parameter in the deploy command  to specify the number of connections to be used during deployment. Use the parameter to speed up the deployment of application archives bigger than 5 MB in slow networks."
  • Application properties listing
"You can now list the properties of a deployed application using the new command [...] display-application-properties."
Multiple connections

I already provided measurements on the impact of using more than one connection in slow or traffic/connection shaped networks in one of my previous blogs. You can now try this for yourself by using the --connections parameter during deployment.

For number of connections you can use:
  • --connections 1 means you want to disable the feature
  • maximum number of connections --connections 5

Although some networks allow higher number of connections than 5, this rarely pays off, unless you are the only person left in the office on Friday evening with the sole purpose to utilize the whole bandwidth of the company's leased internet line.

Splitting an archive in small chunks has performance penalty of 5-10% over simply transferring it via the line. We wanted to guarantee the split was really needed so we added the 5 MiB entry barrier for the new feature.

To determine the right number of network connections you can:
  1. Start  with the default settings
  2. Increase the number from 2 up to 5 looking at the times for deployment:
    [Thu Oct 31 10:22:53 FET 2013] Deployment started....
    [Thu Oct 31 10:22:58 FET 2013] Deployment finished successfully 
  3. Use the number of connections that provided the fastest deploy time
Application properties listing

This new feature is small, but quite important. Without this neat feature the operators and developers had to write down what they actually used as deploy parameters. There was no way to obtain the settings from the cloud.

Now we finally provided a way to get this info and be able to blame either yourself or a colleague for using a certain setting:

C:\sdk-\tools>neo display-application-properties samples\deploy_war\

SAP HANA Cloud Console Client

Requesting application properties for:
   application: test
   account    : i024099trial
   SDK version:
   user       : i024099

Password for your user:
[Thu Oct 31 10:35:24 FET 2013] Requesting application properties...
[Thu Oct 31 10:35:25 FET 2013] Request for application properties finished successfully

   runtime-version   : 1
   minimum-processes : 1
   maximum-processes : 1
   java-version      : 6

Wednesday, September 18, 2013

SAP HANA Cloud: Operator's Guide

The new Operator's Guide is available in the official documentation. The guide targets operators that usually:
  • don't have access to the application source
  • have to update to the latest version
  • maintain the stability and performance of the application

The new Operator's Guide has the following sections at present:

Console Client Reference

Contains information about the use of the console client and will gather all console commands that the SAP HANA Cloud SDK provides.

The new thing here is that finally we managed to provide a common convention of the exit codes that can be used when using the commands for scripting some operations.

Although the commands can still have their own exit codes they are now inside predefined ranges. This means that you may chose to care for a specific exit code, but generally you can just rely on the range for most of the operations.

For example handling exit codes range 40 to 109 guarantees you that you've covered all parameter validation errors. The operation may fail because the archive you are trying to deploy does not exist but you don't need to care about the exact exit code since you are sure it is in the range above.
Documents different aspects on the application configuration that can help the operators achieve improved stability and performance. The covered topics include (for now) how to:
  • update your runtime version
  • enable GZip response compression
  • configure JVM arguments
  • use Java 6 or Java 7
  • scale horizontally your application
  • assign roles
  • configure destinations

The section describes most of the parameters present in the deploy command and gives recommendations and explanation of all the features. Of course it contains security and connectivity information as well (the last topics).

We'll take care to expand it with everything you can configure so keep an eye for more information. 

This section contains information about features needed to ensure the update of your application is as smooth as possible:
  • Update with Zero Downtime
  • Update with downtime
  • Soft shut-down 

I've already described most of the features in my previous blog but since we have more to share I intend on writing a follow up to complete the picture with the support for custom Maintenance Page.

As you can see we have laid the foundation for the new Operator's Guide, but it's by no means complete. You can just check the release notes or have a look at the content every two weeks for new topics.

Monday, August 12, 2013

SAP HANA Cloud: gzip Compression

An easy way to save bandwidth is to use gzip compression and send less data to the client's browser.

Googling gzip provides some good explanations of the gzip compression. The first two results:
The rule of thumb is to turn on the compression for text based content (scripts, book, JSON or XML) since it would benefit from the heavily reduced bandwidth. Images and audio-visual formats would usually require no additional compression.

Following this recommendations up to now SAP HANA Cloud automatically compressed text based responses (MIME types text/html,text/xml,text/plain). 

The problem is that you could not say you don't want this to happen or to add another MIME type to the list of compressed responses. Setting compression threshold was also not supported.

To lift this limitation we introduced the ability to specify that you:
  • require compression or not
  • what MIME types you want to compress
  • what is the threshold that turns on the compression

We added 3 new parameters to the deploy command and you can specify when deploying your application:
  • --compressible-mime-type - comma separated list of MIME types for which compression will be used.Default: 'text/html, text/xml, text/plain'
  • --compression - enables or disables gzip response compression. Acceptable values: 'on', 'off', 'force' or an integer
  • --compression-min-size - responses bigger than this value get compressed and ones smaller than the value are not compressed. Default: 2048 bytes

To deploy your application with gizp compression of javascript you can issue: 
neo deploy --compression on --compressible-mime-type application/javascript

Behind the scene we are using Tomcat gzip compression described in the Apache Tomcat's Configuration Reference.

Google+ Followers