My thoughts about blogging

After reading Ana’s blog about blogging I started questioning why I had been blogging all along, my first interaction with blogs was when I was in elementary school and making my own blog with HTML was one of the things that made me want to become a programmer. I have to say that when I enter university the idea of blogging wasn’t one of my favorite ones, but I have seen how helpful it is, as Ana said it helps you keep track of the things you have learned and see how much you have growth.

I have to say that blogging is a really good tool for learning, it helps you solidify what you have learn and even if you forgot how you did something you can consult your previous post and remember how you did it and maybe come up with a better idea. All I have left to say is that blogging is an activity that even do it help a lot with learning also can be use to share your thoughts and ideas about any topic it doesn’t have to be just about jobs, have that freedom is what makes it awesome.

Python Unit Testing

This time we were left with the task of learning more about Python Unit Testing PyTest, this time we used the IDE Pycharm which I found very useful and cool, I had used it when i was in first semester but back then I didn actually knew how to do something.

We also read the Simple Smalltalk Testing: With Patterns, we started using Hypothesis to make notations in the web documents so that we can keep track of our readings and also share ideas or ask questions, I think this is a great tool that has been given to us.


So Ken gave us a great online course from LinkeID Learning about Python Unit Testing in which we can learn about pytest, from the basic configuration to the creation of unit test and unit suits, the conventions and best practices.

This is an example code from the course, use to teach about the three steps for making tests.

I think the course is very complete and made me realise the importance of TDD, it is a way of writing code that I haven’t implemented I much but I’ll try to put it into practice, it covers from basics to mid, so it is easy to understand.

DevOps part 3

It’s time to fo the third part of the tasks that Ken gave us, so let’s start:

    • Ensure that you have your GitHub account.

Well this was done pretty much when i started my carrer, here is my account if you like to check it out:


    • Ensure that you have a repository created for testing. I recommend some form of web content, but you can choose your content for the testing. You should put this in the root of your web server that you created in DevOps part 2, Linux Server Setup (Individual)

This one was also done from the time we started the semester:


  • Setup your GitHub two-factor authentication.


  • Setup your SSH keys so that you are able to connect to GitHub repositories using ssh.



  • Ensure that you can do a git clone (use ssh) to your server from your repository. You should do this.


So I an make a git clone so everything should be okey

  • Make changes to your repository (you can do this any method including via the GitHub site).

I made a small change to a web page I’ve been creating for another class, to test, I changed the title from «Evo» to «Evo 2015» (don’t ask why 2015):


  • Ensure that you can update your server copy with a simple «git pull origin master» at the command line from the directory where you have pulled your data.

I found a problem, when i was trying to make the push to the repository, it would told me that my username or password was wrong, but i knew they were correct, so I search and found that I had to create a new token and use that token as password, I will have to search if there is another way to authenticate my account because there is no way i can remember that token from heart. If there is no other way then I guess it adds more security because it will have to access through HTTP first then retrieve the token and etc.


  • Does the webpage update if you reload that this code sits in?

And yep, the page title change so everything is great.


  • Automate those updates using what you learned about cron in DevOps part 2, Linux Server Setup (Individual). How often should you update? How do you ensure (and you should do this) that you do not end up with two copies of your update script running at the same time?

I must say that this part is still a little confusing for me, but i think the updates should be every week maybe, i don’t use it much. But if I’ve been honest I have no clue of how to do it correctly, I think i’ll have to ask Ken!!


DevOps part 2, Linux Server Setup

Remember the task that we talk about last time, well they are now divided into 5 parts, this is the second as you can see in the title, this time we have to make this:

  1. Install a Linux distribution
    1. You may choose to create a virtual machine for this (or right on hardware), you may already have this and you also may choose to create a new one.
  2. Install support for your development environment. This should include:
    1. Your coding language setup.
    2. git installed for pushing to your GitHub repository.
    3. Setup web deployment.
  3. Setup your first test use of Cron  on your server.

For the first one I already talk about my history installing Linux ( a little hilarious, a classmate said) you can check it at my previous post, so number one check!!!


here is my desktop!!! I had a little problem with my computer do to the memory optane component, but it’s all fine now, if you have a computer that has the memory optane you might have some problems when you turn it on after you made the partitions, mostly because the optane only works on Windows, so it mess Linux a little bit, but all goes back to normal if you just turn it off.

The second part i have already install the programming languages that i mostly use ( Java, Python, C++ and JavaScript) and git configured. Also I install Node.js as my web deployment environment. So second task check!!!


For the third task I had to do a little more research and I don’t know I totally get it. I made a server with node.js only with the «Hello World» code and use Cron so that it runs it every first of each month. I had to download a Cron implementations because ArchLinux doesn’t come with a default one because the system uses systemd/Timers


So that would be all, see you on the next update!!!

DevOps and Assignment progress

Last week we were given a set of assignments for us to improve as programmers and to be better prepared as what’s out there in the professional world, even do Windows is a popular operating system it isn’t the best environment for developing, our professor gave us this assignment so that we have better tools for working and growth as a professional. The assignments are the follow:

  • Install a Linux distribution
  • Install support for your development environment. This should include:
  • Your coding language setup( Python 3.5, Java, Ruby, C#, Javascript, Smalltalk or anything really)
  • git installed for pushing to your GitHub repository.
  • Setup web deployment. You can choose a classic LAMP stack or go with another option like Node.js
  • Secure GitHub external setup
  • GitHub repository that you have permissions to push to yourself.
  • Setup Two-Factor Authentication on your
  • Setup your ssh keys for use with GitHub
  • You will want to look at setting up personal access tokens to access GitHub repositories through clients without ssh key support.
  • Testing environment.
  • Setup your chosen testing environment for your language. JUnit, SUnit, PHPUnit, unittest (PyUnit), or any of the XUnit family.
  • Automation with Cron
  • Learn to create a simple cron job.
  • Make it run every 5 minutes and check that is working.
  • Advanced setup should ensure that not two instances of the same cron script is running simultaneously (why?). Check that is working.
  • Automate a git pull from your repository to update your local version (will need to clone to local system first)
  • Automate testing of that code. How can you monitor results of that test?
  • Automate deployment. For this example we can do a git pull of the web code to the web environment locally.
  • What is next? What ideas and struggles came up in this exercise. Write about it and document what you still need to learn in this area.

As you can see these are interesting assignments to do, and they seem pretty fun too, for the moment I finish installing ArchLinux, must say it was a real pain hahaha, because I wanted to be able to boot either Windows or Arch at the start of the computer I didn’t knew that in my school network it wouldn’t let me download the files, and because it was link to the boot of windows I ended up corrupting the image, one thing let to another and at the end had to download Windows again and lost all my file, but good think that the important files are or in my git repositories or in google drive, so just remembered to back up everything constantly.

I have already installed Java and Python on Arch so first and second assignment check. I’m in the process of configuring GitHub, I have Eclipse on Windows so I have JUnit in it, so I’ll give a try to PyUnit in Arch.

For the end, what is DevOps? For what I read from the links provided (What is DevOps? And DevOps) DevOps are a set of practices already stablish that are tended to help shorten the system development life-cycle, which is the process of planning, creating, testing, and deploying an information system.


This will be all, next post I hope to have all the assignments done.



PD: I think you should try Arch it really is awesome!!

The secret life of bugs

We as programmers find bugs not only in the pizza we left next to our computer but also in the code that we write. It is very common to find them messing our hard work and sometimes they can make our life a living hell, they can be simple, like missing a semicolon in stupid java, or something even more complex like trying to get the hash of a null object, whatever the bug is they are so annoying. In this study name: The secret life of bugs, it was studied the different patterns that programmers use to find and resolve bugs in the code.

They had some questions they wanted to answer: how is the process of fixing bugs coordinated in software teams? do electronic traces of interaction provide a good enough picture of coordination, or is nonpersistent knowledge? With these questions in mind they define some cases and began the experiment. In the end, they studied 10 bugs and interviewed 26 people.

The result of this experiment was that the way most of the people found bugs was with manual testing, up to 60%, that is a lot! And the most common bug was a code bug, which is the one that I complain the most. There are also the errors and omissions involved but what’s important is the patterns that they identified.


Test and Commit || Revert

We have been presented with different types of methodologies for developing a project/ program, one of the most common used is the waterfall methodology where when you finish a task you continue to the other one until you have pass all the stages and then you are done, the problem with this method is that you never go back to previous stages and see if they are some failures, making this the most dangerous type of methodology.

In the podcast call Test && Commit || Revert, Kent Beck discuss a new type of workflow, call «test && commit» , the main idea is to test every new piece of code that you want to add to your program, if it passes the test then you can commit it, but if it doesn´t then you have to discard all the changes till the last commit that pass satisfactorily the tests, not try to fix it or make some changes, but really delete it, erased it, take it to the trash.

Deleting the code that took you a decent amount of time to make might sound rough, and you might be wondering that why I’m not allow to make some mistakes and try to fix them, well the same question occurred to Kent Beck, and also made him question if someone could really program this way, and the answer as surprising as it sound was YES!! you can!! the way this methodology works is that it pushes you to find a different path that you had already imagine. By doing this it allows you to find even a better way to code your program giving you the chance of exploring you options and your skills as a programmer.

In my own personal opinion I think that the best thing to do if something is not working the way it supposed too then you have to find another way to make it happend, dont be stuborn and try to fix or solve something that is an death end, you should try going to another path, maybe the new path you find could resolve the issue you’ve been dealing with for a hole month 😛

Bernard Golbach Stress

See you next time!!!