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.

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.

DevOps part 2, Linux Server Setup (Individual)

--Originally published at Fernando Partida's Blog

For part 2 of DevOps we were assigned to install a linux distribution, run a server, and use crontab to schedule execution.

The linux distribution that i chose to use is that of Ubuntu 18.10 because i already had it installed as a virtual machine.

DevOps part 2, Linux Server Setup (Individual)

For setting up the server I installed nodejs with the following command:

sudo apt install nodejs

With nodejs installed, a script for running the server was created at a folder designated for testing. The script written was the following:

const http = require("http");
const hostname = "127.0.0.1";
const port = 8080;

const server = http.createServer((req, res) = >{
        res.statusCode = 200;
        res.setHeader("Content-Type", "text/plain");
        res.end("Server testn");
});
server.listen(port, hostname, () = > {
        console.log("El servidor esta corriendo");
});

For testing the following bash command can be run:

node test_server.js

This will show us the following screen:

DevOps part 2, Linux Server Setup (Individual)

After that it was just question of sheduling it to run. For now i set it for running 24/7, 365 for testing with the following code:

First to enter crontab the following command was run:

sudo crontab -e

Then the script used was the following

# 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/node /home/ferpart/Documents/Code/DevOps/test_server.js

Asterisks were used so that it runns all the time.

Intro to DevOps (Individual plus peer review)

--Originally published at Fernando Partida's Blog

DevOps as its name states is short for “Development Operations”. This is a term that started from the combination of the agile operations and that which is the collaboration between the development and operation staff on all stages of the development cycle.

In general its described as stated before “it is a collaboration of the developer and operations”. The following are the generally known levels of a DevOps structure.

  • DevOps Values: These are fundamentally the same as those seen within the agile methodology. Just with slight tweaks focused on the service delivered to the customer.
  • DevOps Principles: One of the most commonly cited principles is that of “Infrastructure as code” otherwise, no other general principles have been agreed collectively upon.
  • DevOps Methods: Methods for implementation are generally the same as with other methodologies. these could be “scrum”, “kanban”, etc…
  • DevOps Practices: The most important practices is that of continuous integration and continuous development.
  • DevOps Tools: Tools that could be used are vast, but these are some examples; “configuration management”, “orchestration”, “monitoring”, “virtualization and containerization”, etc…

In general we can then understand that even though DevOps is a very good, versatile and easy to use tool, It is not very easily defined.

 

Secret Life of Bugs (Individual)

--Originally published at Fernando Partida's Blog

I enjoyed reading the secret life of bugs paper. Even though it was a bit on the long side it had analogies that made everything easier to understand. It gave the reader a way to understand and analyze where it is that software “bugs” come from. The paper also gave a overview of how it is that bugs are commonly found, observed, and finally corrected.