Week 9 – Python Unit Testing

• Screenshot image of your annotation left (using Hypothes.is with your login) on the document “Simple Smalltalk Testing: With Patterns“. PLEASE include a tc3045 tag in the annotation. See my example at the end of this document.
  • Note that you will need to login to Hypothes.is (Enlaces a un sitio externo.)Enlaces a un sitio externo. and most likely by using the Chrome browser with this. A previous assignment in the course had you set this up.
  • Note that this is on the WayBackMachine site. What is this and how is it important? Can you find an old (90s) version of a popular company and view that version of their website? Take a screenshot to include in your submission.

WayBackMachine is a website which periodically stores a website’s content for future revision, it can store many versions of the same page as years pass. It allows us to see how websites were before and view any information previously stored there in the case that in the future it is no longer there, or the website is no longer there, like it happened with the SmallTalk testing article.

 

• Your evidence (again screenshots) of using PyCharm with pyunit.

• Your evidence in the form of review/comments on the course in LinkedIn.

Secret Life of Bugs

Bugs are a pain in the ass for most developers. Most of a developer’s time is probably spent fixing bugs they created themselves (if they did not create them multiply that pain by a hundred). What is very interesting is the pattern we sometimes take when solving a bugs, it is almost like the five stages of grief:

DENIAL – I CAN’T BELIEVE IT DOES NOT COMPILE
ANGER – F*CK YOU FOR NOT COMPILING, EVEN IF THAT IS MY FAULT
BARGAINING – LET ME TRY AND FIND SOME WORKAROUND
DEPRESSION -DAMN, THIS IS GONNA BE A PAIN IN THE ASS TO FIX
ACCEPTANCE – OH WELL, BETTER GET WORKING ON IT

This process can happen in a matter of minutes, hours or days, it all depends on how serious the bug is and how much time and resources we are willing to spend fixing it.

The paper The Secret Life of Bugs notes that:

• Some bugs in the records are not bugs in strict sense.
• Some bugs have duplicate records
• Some bugs exhibit symptoms that are initially seen as different bugs and recorded separately
• Some bugs do not always die when they are marked as closed
• Some bugs basic field in the records are incorrect
• Some bugs have wrong status.
• Some life of bugs will never be understood without a face to face or personal investigation.

All of these factors affect how fast a bug is fixed, something in common with all these factors is that they all involve human error to some degree, and in the end, most bugs are caused by human error, mistakes in tracking bugs is also caused by human error, and how much time is spent fixing it depends on humans as well, so we better get good at bugfixing.

On Blogging

I found out after having a lot of late assignments for this class, that having to create blog after blog can be quite tedious, boring and tiresome, but after a while had passed and giving it some thought, I actually kind of enjoyed having to push blog after blog. It felt like I was creating a footprint of what I was learning and I could revisit it any time or share it with someone and tell them “HEY! I LEARNED THIS! YOU CAN TOO!”.

Of course right now most of my blogs are assignment related, but I actually kind of want to blog about other things, I just prefer to play videogames or something. However, if I ever get tired of playing League of Legends or sharing Facebook memes, I for sure will start blogging about anything I like! Sounds like a super fun idea, I am leaving my digital fingerprint on the Internet. I may die, but my blog posts will probably be stored in the internet forever, occupying space in WordPress’ servers without me ever paying a cent, FeelsGoodMan.

I really encourage anyone who doubts about bloggin to just give it a try, it is a really nice way to express yourself and I this is probably the blog I have enjoyed writing the most, because I finally am expressing what I think about blogging itself. Don’t be ashamed of posting something, just post it!

Intro to DevOps – Part 5

1. Reflect on what you already knew and what you learned in this exercise.

I actually learned quite a lot, first remembered how to create a Linux virtual machine,  I learned to use the Linux console again, learned how to write a shell script, learned how create basic a build status display for a project and a lot more, as well as how much of a hassle it can be to work with JUnit from console.

2. Much of this is simpler with already existing frameworks and services. Find ones would replace much of this work for you. What are the advantages and disadvantages of this?

I used some frameworks that helped me out with some stuff, like the Express server with Node.js, there are many Continious Integration tools out there that can help you out with these tasks, as well as some IDEs that easily run JUnit tests for you instead of having to do it from the command line.

3. Have you gained some appreciation for the concept of “excise tasks” and the value of those in our workplace that perform those as part of a team?

I indeed have, it is a pretty big task and should not be taken for granted or seen as a “lesser” task compared to “revenue programming”, since it can be just as complicated and in the end makes revenue programming less troublesome and more relaxing for developers.