Showing posts with label open source. Show all posts
Showing posts with label open source. Show all posts

Tuesday, 5 April 2016

I won't make big pull requests (repeat 500 times)

Lately we are getting some pull requests through into ManageIQ, and some people has come to ask me some questions...

What size should a pull request have?

Possible answers:
  1. Complete functionality (i.e. that big awesome pull request that creates a new chargeback, fixed the world and praises God at the same time)
  2. Independent functionality (i.e. that big pull request that needs others)
  3. Something that works (i.e. complete feature but only part of a use case)
  4. A small pull request (i.e. nothing works here but it is fine)

Choose wisely.....


Thursday, 17 December 2015

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.






Friday, 20 November 2015

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/




Tuesday, 27 October 2015

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.


Wednesday, 26 August 2015

Gathering requirements

So, in a closed development process,  the main (and only?) source of information would be the customer. Perhaps with a little bit of work on our side to see how that can be reused, and even with more than one customer been queried about their opinion.

In this case, the result has to be good and useful for the community, so I am opening an open wiki:

https://sites.google.com/site/chargethecloud/

You are invited to participate, comment, and enhance it... I will be reviewing comments and requests for enhancements to the content.

Let's make this a real solution, with a clear definition of what is needed and the priorities of it.

Friday, 7 August 2015

A thought on internships and Open Source



I often wonder what would be the best outcome of an internship - for every one, the company, the intern, even society. I as an intern myself for most of the years of my studies - something not quite normal in Spain - and as a result I want to make sure that everybody gets something out of this.

Being an intern is good - for me was quite an experience - because you really start looking at the world from a different perspective. In my time that didn't mean too much, I was just cheap workforce, but nevertheless I came to see things from a different perspective completely: my colleagues were real workers, and the kind of things they talked about was not what I was used to see and hear with my fellow students.

In this case, this group is different. They are still located in a environment that is still mostly university related, and thus they will have a limitation on the kind of soft skills they will have. That is a pity, but makes things easier for them, as they don't have to be physically in a place, and can adjust their schedules to their studies.

On the other hand, they are involved in an amazing project, I would have loved to have an internship like this. And, more than that, we are making a great effort to have them trained. After this internship, our team should be the first ones to get a job - and I hope that Red Hat and our partners Logicalis and Produban are their first options.

Nonetheless, participating in an open source community makes thing easier to get a job afterwards. Red Hat in fact employees a lot of engineers that starting working in a community in their free time, and finished working in the community under a contract.

So, it is training the solution? I want to make sure that any body that goes through this internship ends up being a better worker in the future, and quite biased to Open Source (and Red Hat). So we are getting them trough the best training we can get.

I believe that is good, it is something that adds value to the internship, students really need to learn a lot after they finish, and we are getting them access to a lot of great people inside the organization to make things even better. Of course they can't have a coffee with them - most of them being in the US (United States), only with me. It is hard to have a coffee with somebody in the US (Universidad de Sevilla) - but they have meetings, video calls, and the contacts to work with them.

Finally, and in any case, pressure is there, this is not coffee brewing, but doing work in a real environment, with quality, a real customer behind, something so good that can  become open source.  Sometimes I hear comments about how this work should not be done with interns... and I wonder if that is something we should say to all those people that are already contributing in their free time to open source: "hey, you don't know enough to do this, go and have some drinks with your fried".

The answer is no, I am convinced that in this group we have some of the future stars of the community. We need to train people to work with Open Source, not just hope that they will for whatever reason that got us here. Having them doing something meaningful, a challenge, having trust in them, is part of the open source way. Of course this will be more difficult for them that going around for three months doing easy tasks that nobody wants to do... but that would be a case of money only.  I often find people that dedicate their careers to do manual things that should be automated, and the reason is the same: it' easier to make it start, it's easier to keep going without finding a new challenge every day... but it's a waste of talent.

Let God help us live up to the expectations. And let's put some value in people's life, just a little bit.


Tuesday, 7 July 2015

And.... we started

Last week we started.

July 1st, and I couldn't be with the interns... July 2nd, and I was there for a day.
Not enough, tomorrow I will go back again.

So I have a lot of things to think about:
- How do I empower the interns? We are a team, and they need to make decisions, more decisions than myself.
- I need to teach them while I am remote, and I need to learn from them. I can't forget they are the professional in this... I am just learning. The problem is the big list of things to learn
  •  What is charging and billing
  • Ruby
  • Ruby on Rails
  • ManageIQ, what is it for
  • Open Source...
So we had an interesting meeting where I talked with them about Open Source, charging, a little about the product.... and that is all. This week I expect to show them a demo, see how they are doing, start listening...

At least, we know:
- We are going to be using TravisCI for CI... Trello, Rspec... More things to learn in the real world

Saturday, 23 May 2015

Interns

So... If you have to find interns, what would you be looking for...

In my case:
  • Passion for open source
  • English, at a good level
  • Technical knowledge at a certain level
  • Something more that I just can't define

I was told as a student - eons ago - that you can have to types of university studies that are worth looking for:
- The first one has high marks, they are good students, you know they can learn and do academic things.
- The second one is the collaborative one. They work, they do more things than just studying, they are open to the world, work in teams.

I like both. I understand that every team need to have a mix of different people, and profiles, be balanced. I wonder what is the best for Red Hat. So I want to see their grades so far, I want to know how they work with people, and I want to see if they are good programming. I've asked them to bring a small program in a language that they don't normally use but they will need in the project, Ruby and Ruby on Rails.

And, what do you ask them? I haven't realized how complex is to do the right questions in a short interview to know them.

We are so close to start now...

Monday, 18 May 2015

The starting point

What is our starting point?


Imagine you want to collaborate in an open source project. It should be easy, you think, just go there and program, but in fact, there are some soft rules to follow:

- First: you need resources. So we have started to work with the University of Seville to find people interested in Open Source, in cloud, and in working with us for an internship. Amazingly, we won't be alone, at least 3 companies will be collaborating.
- Second: a good value proposition,  I was going to recommend one of the books I am reading, but I have discovered that although the first book on business models was using licenses from creative commons for charts and slides, and thus was perfect to share, this one is not, so I don't recommend it any more...
- Third: we need some infrastructure, a small one, just enough to run RHEV so it can be managed. Working on that
- Fourth: whatever is needed to make the development, TDD (test framework), CI (Maven and/or Jenkins), a compiler,.
- Fifth: let's not reinvent the wheel... what open source components can be used which license is compatible with ManageIQ? The license should be compatible and no problem created beacuse of it. And architectural should be compatible too...
- Sixth: Documentation: where should we store documentation? Wiki style?

So I've been investigating and:
- Trello is a good tool to keep requirements and make them go through a Kanban process. Building a project there.
- Github is needed, upstream uses it already, so aligning is the sensible thing to do. We could think of some tool like Gerrit for code approval, but due to the small team we are, it wouldn't make sense to have an installation for gerrit onsite. We need to evaluate gerrithub as an interface to github, any way
- We are not mandating anything to code, as long as it works :D

Saturday, 9 May 2015

Starting point

Back to the future

A few years ago I was having the best time of my life at work. I was doing standardization at OMA, working in R&D on charging and billing at Vodafone, travelling around the world, singing every morning.
For different reasons, I decided to move on. Let's say that I was comfortable with my work but the impact was somehow tiny, just pats in the back, and pay "could be better", so I was impelled to change work. A pity, as I believed - and still believe - that I was making a difference.
I've been missing that since I left, enjoying my new work, learning new things, and thinking how could I have done the work better, and created new opportunities for me and for the company.
A few weeks ago I had the opportunity to do it again. I am currently working with a couple of universities to see if we can develop, in the best of the R&D world, a new functionality into the ManageIQ Open Source product. 
Coming back to charging and billing, with universities, researching new ways of gather and present information in the cloud, developing something real and that can make a change.

 I will use this blog to show what we are doing and, in the best of the open source world, gather inputs and ideas to implement

This is so good :D

Sergio