anynines Beta is drawing to an end

They grow up so fast…

At anynines we are shaping up to leave Beta. Besides good times, this means that we have updated our Cloud Foundry system so that it’s compatible with the command line utility (CLI) v6. Have a look at this article to get a more detailed description of the changes.

The CLI v6 has been completely rewritten and is much faster and easier to install than the previous versions. What is more is that the new CLI allows you to tail the application logfiles, so you can see what happens to your applications in realtime. Read here how to install the new CLI.

The new Cloud Foundry setup is more stable with multiple instances of important CF components in different availability zones.

As soon as we will remove the Beta label from our website we will offer trial periods of 30 days to our new customers. Existing beta customers will automatically enter the trial period. More information on the beta and the trial period can be found here.

Please don’t hesitate to ask us any questions you might have regarding the updated Cloud Foundry version, or us leaving the beta phase. We are happy to help.

We attended codefront.io – the frontend conference in Austria

Being a member of the organizing team, I spend last weekend in Linz for codefront.io, a frontend conference counting 3 tracks and no less than 26 speakers. I led one of the tracks at the Johannes Kepler Universität and still got to enjoy some other talks and highlights. To summarize…

Architecting Resilient Frontends

Andy Hume works in the engineering team at Twitter and pointed out to a full room how ‘companies spend hundreds of thousands of dollars on the uptime of their server infrastructure and yet real world websites are slow and failing all the time’. The web is inherently unreliable, yet resilient. So how do we fix that?

Hume says that loading content first, before getting to the (JavaScript) enhancements (and then all other leftover styling elements) is preferable. “If everything after content fails, you at least have that.” Improving the ‘time to screen’ – getting content to the page as soon as possible with fewer http requests – will make your site seem faster. Hume also suggested to eliminate whatever blocks DOM construction, like fetching a remote script that needs to be executed synchronously. Using an inline script node that waits for the relevant stylesheet match instead, with the script tag in your HTML (although it hurts newer browsers and excludes you from using the HTML pre-parser feature of modern browsers) will make you website (appear to) load faster. (more…)

Meeting Rubyists in Vienna

The Vienna Ruby User Group meetup yesterday felt a bit like a home-coming party to me as I actually cofounded it. I am happy to see that many Rubyists make their way to sektor5 every month to share a drink and knowledge. Let’s get straight to the summarizing the talks part!

iPhone Apps with RubyMotion and ProMotion

Jan Jezek showcased how to combine RubyMotion, ProMotion and Teacup to create iOS apps, ‘Ruby-style’. Jezek: “RubyMotion is Ruby compiled into native Objective C, during development you run REAL iOS, not a sandbox or something else.” Indeed the ProMotion scaffold generates .rb files. RubyMotion uses Rake, is extendable with both 3rd party Objective C libraries and gems especially written for RubyMotion (and there are a LOT of those). Jezek: “And the real cool thing is that RubyMotion has access to all iPhone native features like sound, camera, gps and datastorage!”

Jezek praised how RubyMotion is fully supported by RubyMine, including a debugger and code completion, and how TDD and BDD (using frank-cucumber) are considered. That it’s a commercial product and priced as such is one of the cons Jezek mentioned. He’d additionally like to see RubyMotion adopt the MVC pattern from Rails and (better) support for game development.

Skimming over Teacup’s features, Jezek mentioned its CSS like behavior, how it fits nicely into ProMotion and how it enables you to use constraints.

Setup & deploy an Octopress blog in 5(ish) minutes

Aaron Cruz then made an attempt to setup an Octopress blog and deploy it to GitHub Pages in under 5 minutes. Octopress is a framework designed for Jekyll. To get your blog up and running, clone the repo and install the dependencies:
git clone git://github.com/imathis/octopress.git octopress
cd octopress
gem install bundler
rbenv rehash   
bundle install
rake install

In the _config.yml you get to configure your Octopress Blog (read: change the url, title, subtitle and author of your blog):

Third party integrations – like a list of your Github repositories and a button for sharing of posts and pages on Twitter – are already set up for you. Simply fill in the configurations and they’ll be added to your site.

Next, head over to GitHub and create a new repository named username.github.io, where ‘username’ is your GitHub username. Go to the folder where you want to store your project, and clone the new repository. Enter the project folder and add an index.html file. Then add, commit, and push your changes, fire up a browser, head over to http://username.github.io and marvel at your accomplishments.

The 12 Factor manifest – sane guidelines or utopian devop fantasy?

A new concept at the vienna.rb meetups is the group discussion. This time around Andi Fink kick-started a discussion about the 12 Factor App manifest, that lists a number of best practices for building software-as-a-service apps.

The tl;dr for those of you getting the creeps only browsing to 12factor.net:

A 12 Factor app uses declarative formats for setup automation, minimizing time and cost for new devs joining the project. They have a ‘clean contract’ with the underlying operating system and maximum portability between execution environments. 12 Factor apps are suitable for deployment on cloud platforms, minimize divergence between development and production, which in turn enables continuous deployment.

The discussion round was quite conclusive: Ruby developers know and live the manifest. Clemens Helm mentioned how he’d be interested how a similar discussion would go down at a JavaScript meetup, for instance. Florian Motlik from Codeship (who sponsored the meetup yesterday) rather thinks the rules are not strict enough. Someone mentioned how 12 Factor ‘forces you to put your deployment structure under version control and how it provides reliable information which version you are currently running’. Up close and personal style. I enjoyed the mini-discussion about config files versus environment variables (we are all for the latter btw).

The next vienna.rb meetup will take place June 5th, and you should drop by.