DevOps part 5

This has been a LONG activity so let’s begin.

First my journey with finally installing linux on my computer to use it FOR REAL instead of sticking with a virtualBox like i had done in the past. I decided to install AntergOs and with help of some of my friends that had installed it before i had no problems and was able to do the first parts of this activity smoothly. There was nothing i found extremely challenging from what was asked, you just needed to do your research before doing the things, simple.

A tool i fount particularly interesting in this excercise is Crono, i had never used it before and i think it is amazing how we can schedule things with a bash script for literally whenever we want. For real, if you are someone that often falls asleep while using your laptop and that makes it remain turned on longer than needed you can use a crono task to make your computer shutdown at a certain time everyday, it just sounds wonderful.

Another things that tool could do is that, when you are working on a project of some sort, maybe make a task that checks the status of the git, does pull/push requests, or another type of operations. I really don’t know, the potential is too big and full of fun :D, i will look into other great things that i could do with crono, the best part of this activities from my perspective, it’s something that might be able to save yourself a lot of time wasted for excise tasks that are so annoying.

In the end i found myself unable to finish all the devops activities because of a tragic incident with my linux operating system in which i had previously made the activities. An update led to a weird error, when i tried to fix the error it lead to an amazing and scary Kernel panic! so i decided to let my antergos die and i haven’t been able to re-install it since 😀

Pycharm

First of all i read Kent Beck’s class of Smalltalk Testing, I am not very familiar with Smalltalk but the reading was quite interesting, a different approach that focuses on catching certain things that other tests can, obviously each with their respective advantages and disadvantages. Also seeing the page through the WayBack Machine makes you realize how ubly the internet was back then and makes you glad that we have beautiful web pages now, and also that we can now do things like take notes in web pages using Hypothesis for example 😉

About the pycharm and pyunit tutorial, i was unable to access the benefits of the linkedin account that allows you to watch the full tutorial even though i created my account with my tec email and everything. So i decided to search for a tutorial somewhere else and try pyunit.

Following a youtube tutorial imade some tests using examples similars to the ones i have made using JUnit before, like testing for the functionality of some calculator functions. We created the .py with all the functions that we want our calculator to have (add, subtract, multiply, divide) and then we use prints to test :D…. jk the person that made the tutorial pointed out what a horrible way of testing that is and i felt called out tbh

Moving on, we need to import the unittest module without the need to install anything because it’s one of the default packages. After that, just like in JUnit, we create our test class in which we define methods to taste our different functions made in our calculator program. Here we also have the asserts to test what the program returns againts it’s expected output:

In conclusion, i don’t thing there’s a significant difference between the XUnit frameworks for different languages, if you learn how to use one (JUnit), your intuition and a little googling will tell you how to use the other ones (pyUnit).

References:

https://web.archive.org/web/20150315073817/http://www.xprogramming.com/testfram.htm

On Blogging

I don’t tink i ever owned a blog or even thought about creating one before starting my classes with Ken. What i thought was “A blog? what for?”. After starting to do it i understood, it was supposed to be like a diary of my learning during the course and even after understanding that and realizing it was useful to go back to refresh the memory and not having to address a subject from nothing like the beginning, you have right here what you learned back then written on a way you understand it and focused only on the things you thought useful when you learned in the past.

Despite all this i still didn’t feel like writting blogs, that’s not my way of learning, and about remembering things, maybe when you want to refresh the memory is better to look at it form the beggining, that way you can even find out some things you missed the first time you researched the subject.

I’m not pro nor anti blogger, i think i’m in a neutral position that when i do it i can find value in it and when i don’t i dont feel like im wasting a chance to do it.

Also, blogs are said to be useful to put out there something with your name out there for several purposes. About this, i’m not sure im too confortable sharing my thought to literally anyone that can access the internet, it’s kind of scary. Besides, if i saw¿y something wrong or do a terrible job then i’m staining “my good name on the internet”.

As a conclusin of this messy blog all i can say is that i remain completely neutral in the matter 🙂

Inspiration / Resource:

https://www.ohhelloana.blog/blogging-and-me

GitHub, SSH and keys

Today i will be enabling ssh in my github account.

We go to account -> settings -> SSH and GPG keys to register the ssh key that we created, as a result we should see this:

This is how you create the ssh key and what you should see on each step, it creates on the default place it should be created so that you dont have problems later on.

After that i created the repository and added it to my desktop, it asked me my passphrase and after typing it there was no problem:

By using the command git pull origin master i can see that it is working properly and that the changes i do are updated as it should:

Now, to update its as simple as adding a crontab that executes this command, but the problem is deciding how often, I don’t know hot to ensure there is no problem or overlapping. All this should depend on how often i’ll be working on the project.

Linux Setup

I will show my progress with the various installations that we are required to do.

First, install a Linux distribution. I chose to install Antergos on hardware instead of using my usual Ubuntu on Virtual Box

Now in this operating system I installed Eclipse to be able to run java programs and use JUnit. The reason I chose Java is because it is the language i have been using for this class and also its the language that the author of the book we are using uses. Here is Eclipse running with an empty JUnit test.

The github is also setup already, I just configured the global variables name and email.

For the setup of a web deployment I decided to use Node.js. To install and run a hello world example I made use of the example in the official documentation of nodejs that you can find here: https://nodejs.org/api/synopsis.html#synopsis_example

Once you install it with the packet manager of your OS (in my case pacman), I created a .js file with a hello world and to try it out i just need to type on the terminal $ node hello-world.js and check if it is working on a browser, here is how it should look like:

Finally, I installed and tested cron assigning it the simple task of writing into a file at a certain hour. I followed what this person did (https://teoten.wordpress.com/2017/02/06/mi-crontab-en-arch-linux/) but instead of shutting down my computer i wrote hello world to a file.

The crontab was scheduled to run at 12:12 everyday, and the command that is supposed to be executed each time is “echo “Hello world” > hello.txt”. On the screenshot you can see the time, at 12:11 the hello.txt file didn’t existed but once the clock hit 12:12 the file is created and Hello World is written in it as we can see with the cat command.

References:

https://nodejs.org/api/

https://www.howtogeek.com/101288/how-to-schedule-tasks-on-linux-an-introduction-to-crontab-files/

https://antergos.com/

DevOps

The DevOps acronim is the integration of the Development and Operation and, as the name suggests, it is the collaboration, communication and integration of both this sectors to be able to develop and put into production faster.

The idea is to get rid of this existent “wall” between the developers and the operation team to avoid the usual conflicts that happen between these two departments in companies.

It is a culture that is incorporated in companies, we want to make software faster, produce faster and ensure the quality of the products that are being done. There are key technical practices that need to be incorporated to the company trying to implement this culture:

• Automated configuration management, testing and application deployment;
• Version control of application and infrastructure code to enable collaboration and rollbacks;
• CI (continuous integration) to automate code builds and enable faster feedback and iteration through more frequent, lower risk releases.

Mike Dilworth have said before:

DevOps is a culture, not a role! The whole company needs to be doing DevOps for it to work.

DevOps is a lot of things, but is also not a lot of other things, it is a methodology, it is a culture, it is not a job position… it is a better practice to develop software by integrating people and help reduce errors and improve time that everyone is grateful for because it delivers more flexible software, higher quality, lower costs, and a lot of releases in short periods of time.

References

https://theagileadmin.com/what-is- devops/

https://www.paradigmadigital.com/techbiz/que-es-devops-y-sobre-todo-que-no-es- devops/

https://medium.com/@neonrocket/devops-is-a-culture-not-a-role-be1bed149b 0

The Secret Life of Bugs

Not gonna lie, i always have trouble reading papers because of the elevated language they use and i have to re-read each part a bunch of times to understand what they are saying and this one was no exception.

The thing that i understood while reading this is actually how complex is the existence of a big, the way they described they had to track down all the people that were involved with it and how it branched to many other different people made me surprised and made me realize that it takes a lot of people to deal with a bug or that bugs affect a lot the people involved in a project.

Bringing up all the people that know something about the bug like:

Different bugs are treated different obviously depending on the impact they have on the functionality of the end product that it is tried to create. There are different levels to obtain information about them and whatever you find depends on what others have reported and what they thought was relevant about the issue.

I find that it is a huge problem the bug documentation because programmers are usually not good at documenting (talking personally and what i see in my peers) so if someone wanted to know about the bugs of a progam i made through my documentation they’d probably wont find much and wil have to deal with it from the beggining which would take a lot more time and money.

In conclusion: the history of bugs is complex and require a lot to know them so better be very organized while reporting them.

References

https://plg.uwaterloo.ca/~migod/846/papers/aranda-secretLifeofBugs.pdf

JUnit

JUnit is a framework to conduct tests in Java applications. We are going to learn how to use it along with Eclipse IDE.

First you need to create a JUnit test:

Then a new class will appear with the method test(), this one is the one you need to modify to test whatever you want to test.

The first thing you do is instantiate your class to access the methods you are going to test.

Then you use the method that comes with JUnit called assertEquals, this method asserts that two objects are equal. If they are not, an AssertionError without a message is thrown. If expected and actual are null, they are considered equal. Here you put the expected result with the actual result you get to see if the test pass or fails, when you run it you can see if there are errors or failures or if everything went on according to planned:

On the left you see the amount of times you have run the project, the total errors and the total failures. If it fails the bar will turn red as shown in the next screenshot:

You can also add multiple test to do all of them in one go. You add a net test using @Test, also with JUnit you can write down pre-conditions that are things that have to be done before but are not actually part of the test (for example, you can put the instantiation of your class in here) and you can also add things to do after, this is done with @Before and @After respectively.

For parametrized tests you need to create a constructor of the class you are running your tests with that recieves the same variables you are going to replace as values when you run your tests. Your test has to be run differently so you add “@RunWith(value = Parameterized.class)”, after this we just make an iterable in which you are going to put the values you want to test with, it will en up looking like this:

The test will run with all those walues specified int the list of objects so your tests run all at once.

There is still a lot to see about JUnit but this is it for now.

References:

Github:

https://github.com/Guemez/junit

TDD Kent Beck

The Test Driven Development is something i have never done and I’m not used to, to be honest i had to take some time to fully grasp the idea because i found confusing the thought of generating test for a code that hasn’t even been written.

I feel like it make take some time to get used to this workflow because code has to be deleted often if you make mistakes (which i do very often) so it means changing everything. On the other hand it sounds like a great advantage to have in your master branch only code that has been tested and worked, it makes things more stable.

The technique  sounds amazing, basically you just need to have all tests in green, and if you have all of them green then the program as a whole is green because mistakes don’t propagate precisely because all your tests worked before…wow too much to think about.

I think TDD is perfect for pacient people because you are developing small parts of the code at a time, taking care of it until it’s as good as it can be and then move on. For people that are not as pacient it must feel like a burden to do all this test in small parts instead of having and entire thing and then from there solve the problems. Never hate on something without even trying it, you know?

In conclusion, only reading about it TDD sounds too tiresome for me but i will give it a chance to change my mind, i might get pleasently surprised. And i’ll keep in mind the most important: test && commit || revert

References:

https://hanselminutes.com/663/test-commit-revert-with-kent-beck