Course Evaluation

--Originally published at Fernando Partida's Blog

There were many things i liked about the “Software Quality and Testing”course and some i dislike. In this case I’ll start with some of the things I disliked about it.

I really didn’t enjoy the length of the course, meaning that I don’t think it was really necessary to have to take this course to times a week with 3 hours each of the classes. i think the course should’ve had a regular extension like all the other classes that I have taken throughout my time in the Tec de Monterrey. The other thing i didn’t really like was that most of the course was focused on reading the book, whilst this made it so that assistance wasn’t truly necessary,  it did make the class a bit more mundane.

For what i liked, i really enjoy taking classes with the flipped learning style, as they give us a bit more freedom than most other classes do. Making it up to the student on what he or she has and wants to learn. Also i really enjoyed some things about the class, such as all the DevOps assignments. The previously mentioned assignments at first gave me a lot of boredom but when I started doing them i found out they gave me quite a bit of joy and i learned much about them.

In the end i did enjoy taking this class, and i hope to be taking more classes imparted by Ken Bauer.

Thank you very much for the class, Ken.

DevOps part 5, Reflection

--Originally published at Fernando Partida's Blog

Finally, this is the last DevOps assignment, is what i thought upon reading what the assignment entailed. I’ve been working learning and changing many things i knew about regular development throughout the progress of doing these assignments.

I really already knew all of the things that were assigned with these practices, but I never did actually use them at all. Well, the previous was until I started the assignments. I learned the actual importance of automation, not only for testing, but also for mundane tasks such as checking changes on a git/GitHub repository.

With the realization of the use of automation, tasks that seemed easy but time consuming now were completely gone, as they could be done automatically without any need to lose time over them.

I gained appreciation for so many things whilst working with the DevOps assignments, and the overall values of team working in not only work but everyday tasks.

On Blogging

--Originally published at Fernando Partida's Blog

For me blogging has been a complicated thing because i don’t really like the idea of making my ideas and my general life out there in the internet (even though it is already there through social media). The previous is the big reason of why blogs aren’t really my favourite thing to do.

Now in relation to Ana’s blog, I find it truly amazing that she can have the valor to post about herself on blogs online and even more so because she’s been writing since the early 2000s.  How Ana describes it, it seems to be a dying art, something of the past. Still though and as I said before, it is quite impresive for someone to freely speak their mind on the internet.

DevOps part 4, JUnit(or other) Automation (Individual)

--Originally published at Fernando Partida's Blog

This DevOps assignment is probably the most compicated of them all as it was a culmination of everything done in the previous DevOps. First of all I used pyTest as my unit testing tool as it was the easiest to install and use in my virtual machine. Then for all the gitHub stuff I used my pytesting-Quality repository.

First I created a script in python that creates a local webserver that reads the index.html file located at my scripts root folder. This file is constanly overwritten, and the code for the server is the following:

import http.server
import socketserver

PORT = 8080
Handler = http.server.SimpleHTTPRequestHandler

with socketserver.TCPServer(("", PORT), Handler) as httpd:
    httpd.serve_forever()

Then I created another python string in charge of testing the pytest_test.py file and seeing if it throws a “.” if the test succeeds or “F” if it fails. Then it updates the index.html file, with the status of the test. After doing so, the program updates the README.md file according to the status. Finally the script adds, commits with message and pushes the pytest_test.py and README.md files. The following is the code for doing so:

import subprocess

c = subprocess.check_output('pytest ~/PycharmProjects/pytest_test/pytest_test.py |grep "pytest_test.py "', shell=True)

s = c.split(b' ')[1].decode("utf-8")

if (s=="."):
        subprocess.call('echo "pytest test passed" > index.html', shell=True)
        subprocess.call('echo "# pytest test passed" > ~/PycharmProjects/pytest_test/README.md', shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test add pytest_test.py',shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test commit -m "pytest_test updated"', shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test add README.md', shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test commit -m "README.md updated"', shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test push origin master', shell=True)
else :
        subprocess.call('echo "pytest test failed" > index.html', shell=True)
        subprocess.call('echo "# pytest test failed" > ~/PycharmProjects/pytest_test/README.md', shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test add pytest_test.py',shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test commit -m "pytest_test updated"', shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test add README.md', shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test commit -m "README.md updated"', shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test push origin master', shell=True)

Now finally for the pièce de résistance the crontab file was updated so that it runs the server continuously, and the tester on every pc reeboot. The following is teh code obtained from running the sudo crontab -l command.

# Edit this file to introduce tasks to be run by cron.
# 
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
# 
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').# 
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
# 
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
# 
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
# 
# For more information see the manual pages of crontab(5) and cron(8)
# 
# m h  dom mon dow   command
* * * * * /usr/bin/python3 /home/ferpart/Documents/Scripts/server.py
@reboot /usr/bin/python3 /home/ferpart/Documents/Scripts/gitPusher.py

The following is a GIF showing everything working. (Obviously not using crontab at the moment, as it wouldn’t update that quickly).

DevOps part 4, JUnit(or other) Automation (Individual)

Week 9 Practical – Python Unit Testing (Individual)

--Originally published at Fernando Partida's Blog

For the first part of this assignment we were tasked with reading Simple Smalltalk Testing: With Patterns and posting a Hypothes.is annotation and the following is evidence of that.

Week 9 Practical – Python Unit Testing (Individual)

Now for the WayBackMachine it is a website that allows the user to see versions of a website for the past basically. This allows us to see how something used to look some years ago. For the following I used the Amazon website from the year 2006 and this was the result:

Week 9 Practical – Python Unit Testing (Individual)

We were also assigned for doing a course on Unit Testing and Test Driven Development in Python the following is evidence of pytest running on pyCharm:

Week 9 Practical – Python Unit Testing (Individual)

The course was a bit longer than I had expected, and got bored at many times, but it did allow me to learn how to start using unit testing for something different than java (in this case python). Something I did find quite interesting was the section about best practices. That is because learning how to do testing in the most “correct” way helps others and yourself in the future understand what you’re doing.

DevOps part 3, GitHub, SSH and keys (Individual)

--Originally published at Fernando Partida's Blog

For this week we were assigned to use 2-factor authentication and ssh for our github profiles. Fortunately or unfortunately (in context of this practice) I had already done the previous, so not much can be written about the previous task.I will of course insert an image to prove the previous.

DevOps part 3, GitHub, SSH and keys (Individual)

As for the automation i will be automating the pull of the following repository:

Advanced Programming GitHub

This is the code used for the automatic pull (note that the server automation used for the previous DevOps assignment has been removed)

# Edit this file to introduce tasks to be run by cron.                          
#                                                                               
# Each task to run has to be defined through a single line                      
# indicating with different fields when the task will be run                    
# and what command to run for the task                                          
#                                                                               
# To define the time you can provide concrete values for                        
# minute (m), hour (h), day of month (dom), month (mon),                        
# and day of week (dow) or use '*' in these fields (for 'any').#                
# Notice that tasks will be started based on the cron's system                  
# daemon's notion of time and timezones.                                        
#                                                                               
# Output of the crontab jobs (including errors) is sent through                 
# email to the user the crontab file belongs to (unless redirected).            
#                                                                               
# For example, you can run a backup of all your user accounts                   
# at 5 a.m every week with:                                                     
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/                               
#                                                                               
# For more information see the manual pages of crontab(5) and cron(8)           
#                                                                               
# m h  dom mon dow   command                                                    
0 18 * 1-6 1 /usr/bin/git pull origin master /home/ferpart/Documents/Code/gitClones/gitAPobed

The previous script that was added to the crontab, will pull from the aforementioned GitHub repository every Tuesday at 7:00 pm (or 19:00) for the rest of the semester which is the time at which the class is taken every week. A thing to note is that i wrote the time as 18 instead of 19 because the time value starts at 0.

Kent Beck Audio

--Originally published at Fernando Partida's Blog

The following is a review of a podcast done by “Scott Hanselman” on collaboration with “Kent Beck”. This is my interpretation and reflection of what i thought was interesting in the interview heard on the podcast.

Although the podcast was a bit longer than i had expected in the beginning it was quite satisfactory to listen to (although a bit heavy). As someone who never ever heard or read much about Kent Beck beforehand, listening to him about ho he talked about how he enjoyed making “nerds” feel more comfortable.

Kent Beck talks about testing and committing/reverting changes which is a theme that interested me a lot as i have been through this. What I meant previously refers means that the programmer updates a lot of code, and when it fails whilst testing all changes are reverted and everything is lost. I enjoyed hearing about the “test, commit, revert” workflow, in which not so much work is destroyed because it es made in a way so that a programmer only makes small changes before testing, leading to much less destruction of code and ideas.

In general i thoroughly enjoyed the podcast and even though i didn’t quire learn anything new it was pleasing to hear alternatives to the way I’ve been working so far.