A Counting Problem

I really love sites like Hackerrank and their programming challenges. Lately, one of them took my attention given that the simplest and standard solution didn´t work. The challenge is named “Find a String” and the idea is really simple: Count substring occurrences inside a string.

My first impression was the obvious one: “Hey, Python have this implemented”, so I tried the count method. This counts the number of times a sub string appears in a string, it is used like this:


But, the program failed. Look at this (there was another restriction, strings should have less or equal 200 characters):

If you run this, the result is 1 but the expected result is obviously 2.

My second thought was using regex library, something like this:


But again, the result was 1.

So, times like this is when you have to stop thinking in default language methods and libraries and start thinking in algorithmic solutions.

Here is something that happens to me when something standard is not doing what I want: I do things like a craftsman, so this is a quick approach of the function:

This might overkill the problem and there are many improvements in the code that can be done to make it faster, but for now, this would work.

So, the lesson is: always test your code, maybe some things that you think are OK because you are using the language standards can fail.

Testing AR XIII Conference

Once again I was invited to speak in Testing Ar meetup. This time the meetup was in Belatrix that is really a great place to do this kind of events.

This time I talked about the “Non event” of 2016, Selenium 3. Why small changes made a great change towards the future of testing automation.

Testing Ar is a great QA community from Argentina, very well organized and with superb people. Every month they do meetups in different companies.  If you want to see Testing Ar events you can see their meetup site here. If you want to see past events you can see their youtube channel.


Here is the conference (In spanish):

Creating a Twitter Bot II – Random Twits


Hello again, welcome back to this “tutorial” about creating a Twitter bot, if you missed first part, please read it here.

So, now that we can Twit, maybe we can do some interesting things with that.

Creating random Tweets

As I wrote in the last article, one problem of tweeting “Hello World” is that you can’t twit twice the same text. In the other hand, we want the program to run all the time, tweeting different things, so we will make our program twit every x seconds a random text.

First thing is to create a class that will have some common functionalities and in there create a method that will create random texts of x characters.


Even if the code is easy, here is a little explanation of how this works:

I have an array of characters that can be used for the text, and then a for from 0 to the number of desired characters it concatenates a string with new random character. In the end that string is returned.

Now that we have the functionality to send some random text, we can post tweets with a fixed delay. Here is one way to do that. Remember main file we have? Let’s work on that file and do something like this:

We need time library to make it post every x time. time.time() returns the time as a floating point number expressed in seconds since the epoch, in UTC. For more information about Time library look here. Next step is to make objects of class Common and Twitter and connect to our Twitter account.

Now that we are connected we enter in an infinite loop and say sleep x seconds (in the example I putted 30, but you can put what you want) and then post a random tweet of 140 characters calling the randomText method.

If you want the code, fork it, review it, do whatever you want just clone it from here

Next time we will do some changes to our profile, see who follows us, follow people, etc. so stay tuned!


Creating a Twitter Bot

In this series of articles I will be creating a Twitter bot in Python (because, maybe I said this before, but Python is THE language). Creating a basic bot is something really easy and at the end of this article we will have a basic bot posting tweets.

All the code up to date is in a public repository in github, so you can freely clone it from here

What we need:

  • Python (the glorious computer language) 3.X
  • Tweepy (there are other libraries, but, this one is great).
  • A Twitter account (that will be the bot’s account)
  • A Twitter app (I will explain this in the first point of the article).

Create a Twitter App

First of all you need a Twitter app, this is a way to tell Twitter guys that you will be using their API. To do that you need to go to developers link in Twitter, then search for “Manage my apps” and there you will see a “Create new App” button.

From there is just to complete a form with some basic data about the application you want to create:

  • Name of the application
  • Description
  • Website (a place where people can download, use or get info about the app).
  • Callback URL (optional, it depends if you will use it or not).

Once you save, you will have a access token, access secret token, consumer key and a secret key to access your account and do things with your bot.

Get Tweepy

Ok, now Twitter know we are going to do something with his API, so we need a library to easily access that API. We are going to use Tweepy for this tutorial but there are plenty of other libraries out there. Simply pip install it (you may need sudo on Linux)

pip install tweepy

Now we can start programming!

Basic coding

Now, lets open our favorite python (the almighty) IDE (in my case is Pycharm), and lets start

The first class I will like to create is the connector class, I will call it Twitter.py

Let me explain a little what we did here:

First I imported Tweepy so this class can use it (kind of obvious but I am here for all level of developers).

In the init part of the class I added the keys I get when I created the app in Twitter and two more variables for auth and the api manager.

The first method “connect” is self descriptive 🙂  it does the OAuth part, connecting to Twitter (if you want more info about OAuth please check this website) and sets the API manager for future use.

Now that we have this class (in future articles we will update this class, but for now it is a good start) we want to tweet something, so, lets create another class to do a main class to send a tweet (it is obvious that this will be updated as the project grows).


This works, but, second time you run it, it will not post your message because you cannot duplicate twits. But the idea of this first article was just to understand how you can twit something as a bot, from here you can do lots of things. For example you can do a loop to twit different things with some time in the middle.

Stay tuned, next time we will do lots of fun stuff with Tweepy!

Python Tutorial Chapter 1 -Hello World!-

python logo


As I said in one of my first posts, there are plenty of good reasons to program in Python and as I love this language, I will try to do tutorials, kind of  “from zero to hero”. I wish this tutorial makes you learn about Python.


What you will need for this tutorial:

  • Python 3
  • PyCharm (well, any other IDE will work, I just chose this one for this because I feel it is the best one).
  • Eager to learn

So, any comments, ideas, questions, whatever, just comment here or in the video I will answer.


P.S.: Notice that I don´t have any script for the videos, so when I press “record” I only have the idea of what I am going to talk, so I am not sure of what I am going to say at the beggining of the video.

Code & Beer. Belatrix Oktoberfest!


Today I am in Chacras de Coria, Mendoza, at “Code & Beer” event, where I am was invited to talk about migration to Selenium 3. If you are near, please join us, it will be fun. Programming, food, beer, what else is needed for a good night?

Getting to Mendoza is not easy right now, the local airport is closed so you have to go to San Juan and from there take a bus…



But then good things happen… A day of work in a peacefull place…

20161027_140520 20161027_140531 20161027_140620 20161027_140625 20161027_140629


Developers life is something great, it takes me to great places like this, meet cool people, learn lots of new things.


Today I am at University of Palermo for assisting in a hackaton sponsored by Belatrix, the company where I work. My role is to help the competitors to make the best possible work, I wish all goes good!

Four teams creating social applications, competing for the glory.  Let the game begin!

A week in Perú


One good thing of my work is that from time to time I have to leave Buenos Aires and travel to another city/country.

Taking my flight to Lima
Taking my flight to Lima

This is my second time in Lima, both times for work (and yes, made a little tourism), and let me tell you something, traveling for work have good and bad things.

Luckily I am travelling one or two times per year, so I don’t leave home often, I have a wife and two little daughters, so some times it is hard to be alone in another country. I know of people that travel so often that I think that airports are their second home.


The good thing of traveling for work is that no technology replaces face to face meetings. ten minutes here talking with the team some times replaces hours of Skype, Slack or whatever. This is something for an entire post, but nothing replaces face to face.

View from the office, sometimes I think that the sun doesn't exist in Lima.
View from the office, sometimes I think that the sun doesn’t exist in Lima.

Talking about the industry, from what I was talking here with people, there are lots of great people (I really hate the term “human resource”), but lack of big system companies compared to other places, so maybe it is a bit harder to get a dream job, but not to hard. But Perú is growing, you can see it easily, so I think that lots of companies will start and grow big in no time.


Final words: food in Perú is GREAT. I don’t do advertisement, but places like “La Lucha” are a must. You have to eat “Cerdo al cilindro” (pork at cylinder), you will have a better understanding of the meaning of life.

TestingAr VII a really nice Meetup


Yesterday I had the honor to speak in one of the greatest QA meetings in Argentina: TestingAr. In the seventh edition it was hold at Belatrix headquarters in Buenos Aires and I talked about What, when, where and why to automate. It was a great experience, I wish I can be in more meetings like this.

The video is in Spanish (as it was the Meetup) and cannot be inserted, so the link is shown:

Link To The Video

After that there was a lot of food and beer and then a great explanation of Docker was done by Matias Lespiau, he really knows a lot about Docker, really enjoyed hearing his conference.

Link To The Video

And then a lot of questions, more contacts, more beer, exchanging experiences, well it was a great night.

Test automation. Dealing with common excuses


Some companies still reject the idea of doing automation, and they have some arguments for that. In this post I will talk about the four most common that I heared:

  1. It takes time to program the base.
  2. It needs some difficult to get QA/Developers.
  3. It is easier to make only manual testing.
  4. “Maybe in the future…” excuse. So, the QA lose a lot of time testing manually and not getting time to automate test cases.

Let me say it clear:  I think that are only excuses of people that are afraid to change thinking that they are buying a risk. So for any of those excuses there is an answer, so lets talk about each one of them:

It takes time to program the base.

Yes, it takes time, but in long term it saves more. Automating the regression makes people in the team only think in new features leaving the everyday teting to a computer.

It needs some difficult to get QA/Developers.

Maybe this is the strongest excuse. The profile of a QA automation is someone that is half QA and half developer (depending on the project maybe more QA than developer or more dev than QA is needed, but lets say it is half and half). The truth is that today any developer should learn a little about QA (at least for knowing about how to face unit testing) and QA people should learn at least a little about development, not only because of automation, but because knowing what the developers are doing is a great thing. I remember being on the QA side and having to debug some Cobol code (even if I don’t know Cobol, knowing how to program made me understand a lot about what the developers were doing). So, if you get the right and motivated people, they will learn how to deal with the other part.

It is easier to make only manual testing.

Maybe you think that is easier to click a button and see the result than make the computer click the button and see the result. But think of this: a person works for 8 hours, he gets tired, makes mistakes, needs time to take a coffee, gets frustrated, have bad days. The computer doesn’t care about all this, it just works and do what was told to do. Another advantage: automated test can run at any time, you can make a scheduled task to make lists of tests run every night, or you can integrate a smoke to any new code commit, so the automation program can quickly see if the basic functionalities work well.

“Maybe in the future…”

If you make a QA team go over and over again a regression, a smoke or whatever, they will be running in circles without really doing lots of new things. Having those things automated will not only give lots of time to your QA team to work on more productive things, but will save time and money.

I am not saying that manual QA must disapear, there are lots of things that must be done manually, but adding automation to your project you will save lots of time and money and you will win quality and value. In future posts I will talk about what kind of test must be manual and which test cases should be automated.

1 2