Course Evaluation

Software Quality & Testing.

Course Evaluation.

This course is quite different to a lot of courses in which I have been in my entire degree., there is no doubt about that. Of course as a student I love the flexibility and the lack of stress that comes from a trust based grading system. It is true that I have done a lot of the stuff that the course asks me to do, but at some point, but I also wish I would just have taken advantage of what the course offers me and done the things I didn't really do. And at some point of the course I come to the conclusion that I am not going to do them at all. Personally, I think it is all about the deadlines. I am the kind of student for which deadlines were created for. I just think I have all the time in the world to do an assignment but the present. On the other hand, when I do an assignment I really dislike doing things just for the sake of getting a grade, it feels wrong to me, I just do that when the deadlines are over me and the grade of such assignment or project will have a great impact on my overall performance. In this course I was quite amused that I went through putting effort to things that are not really demanding upon grades.  I believe that setting some sort of way to motivate (or push) slackers to get things started. would be very good for the course.

I think the course content was good, I'm currently refactoring my own code at work to make it testable and it is pure pain. At this point of the semester I begin to understand how important so many of the good practices and concepts are in the real world development. I would suggest to make some sort of hands on classes in which we follow more of the "dev-ops" kind of tasks along with the instructor. They are super useful out there. 

I really enjoy blogging, it is like some kind of rubber-ducky technique , but after you get things done. You can express your frustration and showoff your achievements, tech related work comes with a lot of emotions and feels nice to be able to release them in my blog. I don't really mind spending time doing this.

I don't like reading. Maybe its personal but I think I learn much more from short descriptions on theory and then intermediately doing something to apply it. While some readings were quite interesting, there were a lot of readings in which my eyes were merely following the lines rather than paying attention before reaching the half of it.

Finally, I'd like to suggest to have some sessions or tasks in which we do unit testing to some code given by the instructor. I think it would be kind of fun and very valuable for the course.

DevOps part 3

For this task we were asked to work on the configurations of SSH for GitHub. The very first task of course was to ask Git to generate an SSH key. Everything ran pretty smoothly when following the instructions given by GitHub on how to do this. I was pretty happy to see myself doing this on my Ubuntu VM rather than having to deal with a bash for Windows or anything. The only point in which I had any problems was to copy the public key off the directory in which I created it. While I was aware of the place in which I left the SSH files, I didn't quite understand the command for creating them. While messing with it for 10 minutes or so adding and removing points and dashes I ended up opening a file open on gedit, but it turned out to be the private key. After another 10 minutes of doing the same thing I got the public key and managed to successfully added the key at the GitHub website.

Now I just had to test it quickly. I created a

file quickly directly on the GitHub website and pushed it. I just had to make a pull from my virtual machine, and yeah I had this problem in which I wasn't able to login. After some research I found out that it had nothing to do with the SSH configuration, it actually came from setting the two factor authentication. I asked for a token at the website and tried again with it and it worked. Good thing on my way doing so is that I learned that I can also use a SSH key specific to a repository for additional security. In the end the important thing was that the file was where it was supposed to be.

On Ana's blogpost...

Back at middle school I love writing those lame freestyle essays back at literature classes,.Writing is a really comfortable way to express yourself without having to deal with the anxiety of speaking in person, since you can just think over what you are going to write. I have never been a great speaker and there are a lot of things I wish I could share with people around me just as fluently as a text can do.

Reading Ana's article I think I can relate a lot to her. While I was no cyberpunk in my childhood, I didn't surf through a koalas fanpages nor was a an active visitor on experimental art websites, I can see the beauty that was in it and the nostalgia that might come from it. I believe that back them people did not visit the web for instant entertainment or interesting content, there was some "surfing" that had to be done and more interestingly there was some space for people to produce this interest upon each other, and as a consequence it created a certain kind of feeling of connection and community which was one of Ana's central points in her post. Even though I agree with her on this one, there are so many places in the web that people visit for this purpose. As mainstream as it is, I love visiting the smaller communities on Reddit that focus merely on reading and posting about their own bizarre interests such as bonsais, a specific music group, or  weird videogames such as Stellaris. And I have noticed how the purpose of some subreddits change as its popularity increases. For instance r/stellaris used to be full of discussions about builds, strategies and fanart and turned into memes, bug screenshots and shitposting. 

Well, while I would never write a technical blogpost because of the reasons expressed in this tweet, I believe it might be just a matter of time until I get the confidence to do so.In the meanwhile I must say I enjoy doing some technical blogposts for this course because I can just throw away some of the frustrations that I catch while doing the technical part. 

Testing with PyTest

It's been so long since I have done anything serious on Python, even though it was the very first serious programming language that I've ever used. I took my introductory course to programming back at the University of Toronto. The lecturer had a set up environment on an Ubuntu virtual machine with PyCharm over several frameworks. He made us write some testing functions over there. So when I first started this assignment I was quite happy thinking that everything was going to be as easy as it was back up there. Turns out I was wrong and the lecturer really did a big favor to us by setting up the environment. I don't usually have too much trouble on setting stuff up but, something happened this time that I nearly went bananas on the set up for PyTest. The main problem on the setup was that my PyCharm wasn't able to recognize the PyTest variable on my my virtual environment. After a while I figured that I had to install pytest-runner as an administrator and install the library for PyTest in the IDE. That took 90% of my time for this task.
Concerning the course I believe it was nice, clear and well paced. Hands on were quite simple so I took this opportunity to skim over the tutorial's code and create my own version of the source in order to remember some basic Python. The only thing that was slightly annoying was having to install and set up my environment while following a tutorial that is somehow outdated.
Anyways, here's the requested evidence media:

DevOps Part 2

HANDS ON!

Its been so long since I had my Operative Systems class, it was one of those classes in which the lab instructor was not really sure what was the lecture professor asking him to work on. Supposedly we were to work on mutex locks, system calls, and other things that fall more into the theoretical spectrum of the Operative Systems class. But instead the instructor wt this panted to give us a dive into the life of being a Linux administrator. And right now I am very happy that he did so.

So well, the first part of this whole thing was to install some Linux distribution. Even though during the lab mentioned previously I worked over CentOS, this time I decided to pick on Ubuntu because I had the feeling that it would make this whole thing easier for me, For those struggling to install and configure Ubuntu (which is quite simple in my opinion) you can always use this handy site, it contains pre-built images of the most popular operative systems for Oracle's Virtualbox. I was a bit short on time for installing Ubuntu, aditionally I consider that I have fair amount of knowledge on installing operative systems on a virtual machine since I had to go through the nightmare of installing Gentoo during the same class.

First of all I started by installing Java and Git for my virtual machine. Even though both were easily completed with a couple commands on the console for each I had to virtually google everything since I didn't really remember. I believe git was the one that I had slightly more problems with since the first time I installed it I chose my user path for git, and I thought that if I just left it like that, whenever I wanted the cron to push the files into that directory, I would be pushing everything that is in the directory, most of which were files of the OS itself, so I had to redo the Git configuration.  As for Java I screwed up slightly in the same page. I didn't remember were did I put the JDK so at the time I was trying to get over with the installation of IntelliJ I had to wast a handful of minutes looking for it. Additionally took some minutes in order to enable the two factor authentication for my Git account.

For my web server I decided to go for Apache. One of the main tasks of my Operative Systems lab which took several sessions, was to install 3 different web servers: Joomla, Moodle and Apache. From these, Apache proved to be way nicer and simpler in its installation and deployment, since it was not necessary to manually configure the files inside of the build, additionally, Apache is widely more used than the other two, so installing it on CentOS proved as easy as I just did on Ubunbtu. The whole thing took to follow the steps given in this website. The only thing I had to look up from other sources for was to set up the port number. But after a couple minutes of research I just found which file I was supposed to rewrite. I wanted to refresh a bit my skills on using an in-console text editior so I decided to do this configuration on /etc/apache2/ports.conf by making use of the vim editor. Finally and honestly I did just a small research and a simple test of my cron file. Even though it is not something that buggers me too much, I didn't have the need to install cron since OSboxes' image came with it installed. I found this video that was really handy in helping me understand the structure of the crontab file, which seemed quite misleading to me in the official documentation . However I still have my doubts since I don't fully understand the git commands in the script (I always deal with VCS by making use of the IDE plugins, not the terminal).Anyway it just worked by writing the file just as it shows in the video with my own files and timing.

I think this assignment is nice and it is helping me to refresh my mind on some of this OS administrator skills.

DevOps?

DevOps is one of those tech words that is in mouth of everyone in any IT workplace. In this post I will try to paraphrase about DevOps and what is its function in the IT environment.

Apparently DevOps is a term that bears no canonical definition, this means that the definition of DevOps can change from one company to another. I am not ashamed to tell you that my personal favorite general definition of the term was the one I found on Wikipedia and it goes as it follows:

  "... DevOps is the immediate response to the interdependence of software development and IT operaions...".

 So based on this definition, we can picture a DevOps employee as a person whose duty is to facilitate the life of a developer by helping out with nuisances such as putting up and maintaining the server in which an application is going to run. Even though this is a good brief definition there is much more to it. For showing this, I'm bringing up Atlassian's definition of the term: 

"DevOps is a set of practices that automate processes between software development teams and IT teams, so that it is easier to compile, test and publish software quickly."

This definition seems to take a fair amount of disciplines and work on the part in which they connect in the process of software development. And yes DevOps people require to be fond of a wide skillset, but they also require to adopt a different mindset towards collaboration.  Some authors cite that the implementation of DevOps most of the time requires an internal cultural shift.In order to understand this it is necesary to look back to 2008, the time around DevOps started to come out. At the time a developer was completely responsible for writing code exactly the way IT operations asked them to. This of course made both of these departments to have different goals which usually caused a conflict among them. DevOps aims to blend them into a collaborative team that is able to understand the needs of each department and the enhancement of each. 

For the particular set of exercises assigned in class,  I believe there is a greater focus towards the job of a system administrator  rather than the DevOps practices as a whole. For that we would need a team of developers and a team of system administrator, testers, database administrators, etc.  In order to focus towards DevOps. 

The Secret Life of bugs - some thoughts

As a developer I believe I spend around 75% of the time at my work and academic projects solving bugs. Jorge Aranda in this paper taught me that it is not just me, I might be pretty bad at design but seems like bugs are something that is so big in the software industry that there are databases exclusively dedicated to keep track of bugs. This is something new to me and I was a bit amused that bugs would come out to such extend. And of course if the bug deal is one so big, it naturally becomes harder to keep track easily of them as Jorge shows later on the paper. If I have something in common with Microsoft is that I am able to fix within 10 minutes almost every bug I come across on my code, however bugs that are not easily reproducible by placing print statements around or bugs that are created due to my own poor design, are the ones that I tend to slack or partially fix until I leave them unfixed. If my programs were used as much as a Microsoft program would all of my bugs would eventually show up. And yes I also feel related that a lot of the loosing track of a bug comes from is mostly due to the human factor. I've recently got my very first job as a developing and I finding it ridiculously annoying to keep proper documentation of the functionalities of my code. As much as I love typing my commit messages in a console document editor, it seems like every time I go back there is something wrong or missing, I either should have opened a different branch and made some commits there then merge rename etc. It seems just impossible for me as a human developer to now have to keep a careful and close look at my bugs, and makes total sense that if you take all of the developers in a big company and multiply each tiny mistake of documentation over a bug it seems to be something that you just can`t deal with. At the end the paper seems to come up to the fact that we screw up too much in taking care of out bugs and their respective meta-data that it would even be impossible to automated processes and algorithms to follow up on where did they originated.

Thoughts on Kent Beck's Podcast

Kent Beck seems to be a person that is pretty convinced that TDD is not only a programming paradigm, for him it is a whole new strategy on attacking problems that come up in life. Personally I have never developed any code basing solely tests as my guideline. And I think I don´t really feel like trying so not only because it is comfortable, but also because I would end up convinced that I do not know how to program. Even though, this podcast convinced me a little bit to start being more aware of the functionality of smaller segments of my code, perhaps not as extreme as making 16 pushes for a Fibonacci code, but to start building over solid ground. 

As Kent mentions, as long as there are no design mistakes if you program with this test driven mindset it is more unlikely to get this bug that after working on it uncovers a few thousand more. Something that I found fascinating during this podcast is the value that Kent gives to the programmer's motivation. Solving a bug and see a line full of greens seems is definitively much more of an incentive than being afraid to unbury bug after bug. As he mentions on of the things that programmers enjoy the most from programming is actually solving a problem. In my opinion there is nothing that makes me feel more happy at work than following a trace and solving a problem by yourself in your own code, a mixture of feelings comes up between self hate for making such silly mistakes and ironically feeling really smart for solving the problem. And yes, this feeling doesn't come up when I am convinced that most of my code is garbage and thousands of other bugs are coming up in queue after that. 

I believe some sort of TDD might actually suit my needs and help me improve as a programmer, however I am not willing to go to the extremes mentioned in the podcasts. Just like limbo I am willing to start up and go down somehow slowly. 

Week 1 Plan

Week 1 Plan

January 21, 2019

Credits to @rawpixel

https://unsplash.com/photos/mcLpPD36-2k

• Get familiar and a brief introduction to software testing.
• Read Chapter 1 of the Introduction to Software Testing Book.
• Define team roles.
• Figure out which project are we going to be working on this semester.
• Share Github credentials (Usernames).
• Set up Github Team Repository.
• Brief Review on how to use Github.
• Get to now each other, by sharing cellphone numbers and creating a WhatsApp group

What we managed to do:

• We have a good overall knowledge of what are going to be working on.
• We've managed to define team roles.
• A Github repository is up and all of our team members are connected. 
• We have a WhatsApp group.

My expectations for the course:

After several semesters, I have been convinced by my professors to actually adopt a testing mindset as something that any good programmer should be proficient on. Additionally I have just been hired for development, which means I am expected to code effectively and I believe this course is going to help me on my struggle to get my code bounced back by the company's testers as little as it is possible. If I understand the way testing works and which parts of my work they are going to set eye on, I will be able to make this my job easier for me in a shorter time. Additionally I do feel a little interested for the work of a tester. I'm looking forward to learn all of those methodologies and get as much experience as possible from this course.

How are we going to manage our project: