Last day of the year

Today is the last day of 2015. Something weird, that we still celebrate some date in half of the world because some hundred years ago it was decided this way (and could have been decided different)

A fine year has been, I would say, being on holidays.

This 2016 is going to be even better...  For now, we are trying to increase the number of people working on the project. We have offers from partners to participate or increase participation, and we have offers from customers that want to make this better.


I believe we have created something new, that adds value to all elements of the chain. Customers have overcome build vs. buy - and old IT mantra- with a build to buy, powered by open source. Partners have discovered a fine way to learn and get new hires in a market where finding trained cloud professionals is so difficult, and of course we have a new way of interacting and adding value to partners and customers, while enhancing the product.

The question remains: how to make this better?. Continuous improvement is needed, we need to refine, enhance and update the model so more value is given to all parties. Any ideas? We have 365 opportunities, starting tomorrow, to use them.

Meanwhile, rest in peace, Ian. We'll keep working on Open Source.

It's nearly Christmas

So Merry Christmas and Happy New Year! Enjoy the holidays if you want and enjoy my good will if you don't, or just don't feel identified with it.

Meanwhile we have advanced a lot. Yesterday we had a review of the things we are doing and it looked quite impresive.

- Rafa showed tier rating. Now you can use tiers (i.e. from 0 to 2 CPU --> x $/month, 2-4, another amount).... and also a new way to tariff: fixed+variable. Easier to say than to do, I should say. This is a great enhancement, as we know can make tariffs that covers a lot of new uses - with the example that now we can use the same schema that Red Hat uses in its subscription model.
- Amaury showed us the new interface to edit rates. You can now add rows in a table instead of having all the options already there. It will become quite important when we increase the number of options allowed.
- Tamara showed us how to put currencies into the rates, and the initial translation of CF4 into Spanish.

On the other hand, we have new offers to collaborate in the project from different companies. Too early to say, but I expect a significant increase of resources with the start of the new year... coming from different companies.

We also have decided to take a try of an open source project to follow our scrum process
https://tree.taiga.io/

We used Trello before and is great, but we were lacking some measurements that would be great to have, let's see how we adapt to the new platform.

Next steps are harder. We have done everything we can without modifying the models, and now we need to change configuration files, models and everything around.
Focus points: assignment of rates to users, resources and groups, and being able to charge at different levels, not only with the data coming from the C&U database. We are also starting to see how we can integrate with external billing systems.

We've had some contacts with opencell, an open source billing company and product, and we need to work hard on that.

Stay close, this is going to evolve quickly.

Attribution 2.0 Generic (CC BY 2.0) https://www.flickr.com/photos/07anycolouryoulike/6566897119/

Some useful addresses

This sprint we have really advanced quickly, now we are able to do tier rating (almost), choose currencies (almost), we have changed the way rating is selected, and prepared the interface for the next steps. So with this sprint we will have the interface in a status that will be the base line, what is done today, but some good tier rating and all done in a more sensible way.

Results are good, but we are still learning the craft, there are too many small details that change how things are seen and done.

We need to migrate to patternfly (https://www.patternfly.org/), and use haml
We need to improve our tests. For some extrange reasons we go straight to code instead of going through testing first, and then things break down... Perhaps because rspec and capybara are great, but defining your tests with them is not so obvious.

For instance, I am still working to know where are described the contexts of capybara, as you can't access all the methods from all they test types... And all of us need to revisit patternfly.

And we need to polish the way we work, basically.

We are getting there.


Next: we are now adding new functionality beyond rating, we will be focusing on adding some capabilites to the exiting paradigm, just before we change things internally.

It is being fun

References:
http://guides.rubyonrails.org/
http://railscasts.com/episodes/267-coffeescript-basics
http://www.bootply.com/new#
http://www.rubydoc.info/github/jnicklas/capybara
https://gomockingbird.com/
http://rspec.info/
http://guides.rubyonrails.org/
http://www.rubular.com/
http://haml.info/

Another sprint goes by and we have something to celebrate

Let's celebrate!

 

So... we've got the first functionality inside ManageIQ. On time for the next version of the tool... and it has costed us some blood, I have to say.



Let's cellebrate :D This week is Red Hat Week, and we are proud to reach a milestone in our little project.

https://github.com/ManageIQ/manageiq/pull/4887

It has taken 11 days to merge it.... And we have learnt a lot while we worked on it.

First:

You need to visually know what you intend to do... We had a revision web conference and discovered that we had agreed to deliver something... that was not what we wanted.

Solution: mockups of the final solution. Now we are doing it first, with the rspec: Tests and mockups to know what we want exactly the tool to do.
It is such a stupid thing  trying to use TDD and fail on doing this properly.
Consequence: some functionality won't be included in ManageIQ until we refactor it because we have learnt a lot - meaning: we have done it wrong.

Second:

We need to focus more in the basis, iteratively. Git, patternfly, ruby, rails, we can't take them for granted, we need to improve how we do things. We make mistakes, we don't understand why tools are used for... and one month later you know why that functionality was there...

Third:

Sometimes the business part of things is hard. Even being myself the product owner, I don't get specifications detailed enough to make everything understandable, and thus it is good we are using Scrum... Imaging if we discovered that the functionality was wrong after 3 months instead of 3 weeks.... We wouldn't be talking about learning, but other things.

Pull requests

Our first pull request is here... and the second one.

Last week we had a wonderful conference call with some senior developers in ManageIQ. Amazing how easy things can be if you have the right knowledge in front of you.

So today we have done a couple of pull requests:

One real:
https://github.com/ManageIQ/manageiq/pull/4669
One pathetic (mine):
https://github.com/ManageIQ/manageiq/pull/4668

So mine is just to add .ruby-version file, so rbenv does know what version to install, and anyone programming with the source code know which version of ruby he needs to set up the environment to.

The other one is quite more interesting: Tariffs in real life are not linear. They are based on tiers. So anything down 512MB has one price, and if you ask for 473 MB, you are still charged for 512MB. So we need to reflect that.

Interesting thing about this. It is not so easy to get a pull request, we want to collaborate, not being a burden:
1. We need to do it in smaller pieces. These pull requests are perhaps too big. Functionality is ok, everything works together, but reviewing perhaps it is a little too long. Next time, we will do smaller chunks. Hard to know whether is better to do a full functionality pull request or divide it...
2. git is a wonderful tool, so we are learning to stash, rebase, update, squash. Thanks god pro-git is free :D
3. manageiq does not work with postgres 9.4, the default version in Fedora 22, so now we need to use 9.3 or 9.2 (the one included in RHEL 7/CentOS 7)

rbenv

So you need to develop in Ruby.

I am working now with a couple of different environment:
- ManageIQ needs Ruby 2.2.3
- Openshift.com, where I am developing an application (PaaS is nice), needs to use 2.0.0p645.

So I started to have a look at how is the best way to do it.  In RubyonRails.org it is recommended to use rbenv, so I did give it a try.

I followed the instructions to set up the environment, compiled a new ruby, installed it for my application... and did a bundler install.... "ERROR"

Those things of installing with git clone. Dependencies where not there. It took me a while to search the web and see that I need to install cmake, and some libraries for development that were needed to compile the gems (mariadb-devel, etc).

After that
$ gem update --system
$ gem update
$ gem pristine --all
$ gem install

And then
$sudo dnf install npm  #for node.js needed to run jscript and rails generate with it

made the day.

Second sprint

We have closed the second sprint.

Wow! Things are more complex than we expected. This sprint we have focused on upgrading what is already there:
 - Change how rates are defined. Now we can define a tariff in different units (i.e. 1€/KHz/month or 10€/MHz/month, etc)
- Tiered rates. Now we can define tiers for rating (1-2 CPU 5€/mont, 3-4 CPU 9€/mont, etc)
- Currency management, we have starting adding definition for currencies.

And then we came to Rails... Coding an enterprise grade application is complex, and there is a bunch of controllers that we need to understand... and we couldn't.

So we have closed the sprint a little too soon and we will need to continue working on this. We needed to take the decission of whether to delay the sprint for a week or close it as it is... and we decided to close it. No demo to be shown, a lot of things learned.

Now we need to define the next sprint.