Someone recommended to read Blogging and me by Ana and without a doubt It spoke so much truth that many and my self are afraid to admit.

They way Ana tells her story, how she felt when she couldnt write, for myself I am not a writter of blogs, but I like to write another things, and I allways think people wont like it or its not good enough.

Ana tells the truth about what people do when they found things in the internet, and more importantly about Tech. Because i´m a student I still havent lived the work-life, and to be pressured by it in my life. Its true I wouldnt write what I learn, but if someone asked me in school I would be afraid to expres my knowledge in case I didnt know all of it, someone knew more or they would critisis my for something I just learned and «should» know it before.

After reading Ana´s post I feel more inspired to write, to pass my knowledge to anyone that could use it and most importantly never be afraid to say what I know and dont know. Because we can allways learn, be better and get smater.

Never let fear stop you from making what you like and be happy with what you know, and If you want get better, be better, no one should stop you.

Another entry on JUnit, first we will have to make sure that we can use pytest via the command line and setup a status page that shows the status of the build.

verify that we have pytest installed:    sudo apt install python-pytest

Next we will make the status page:

I used Rhino which can be downloaded in ubuntu using the command: sudo apt-get install rhino

(but you can use other methods)

 

For last, someone asked me:

1. How could you update the README page on your repository to reflect the build status using this setup?

First I was thinking to make a change in the main html to call a job that edits the README using badges that I can save as images hosted on free services like ImgBB and change them at the beginning of the README and then commit and push those changes. But you can also

Firts I read of Kent Beck talk about testing using smalltalk with patterns and a framework for it on Simple Smalltalk Tesign: With Patterns.

In this part I used Hypothes.is to make anbotations and find them latter:

Next I watch the course of Unit Testing and Test Driven Development in Python from LinkedIn Learning. With out saying is was very informative, it has a complete introduction to TDD and Unit Testing including the definition of terms used in this kind of testing, you can learn of test discovery and test fixtures using basic examples of how to use pytest to perform within PyCharm. I really liked it a lot and learnd even more, I really recommend it.

Here I used Pycharm to make a task and test it, when I run the tests «you» should see this:

Today I also worked with the WayBackMachine site, which is a digital library of Internet sites, it includes different versions of them throughout time. I searched for the Youtube page and found one of the olders version that they had. Without saying is has gone a long way since then, this is from August 30 of 2005:

 

 

The first thing to do is generating a new SSH key and adding it to the ssh-agent:

(we need a Github account for this)

Generating a new SSH key:

$ ssh-keygen -t rsa -b 4096 -C «your_email@example.com»

 

Adding your SSH key to the ssh-agent:

# start the ssh-agent in the background
$ eval $(ssh-agent -s)
> Agent pid 59566

$ ssh-add ~/.ssh/id_rsa

 

Then to make a git clone through ssh:

git clone ssh://git@github.com/<user>/<repository name>.git

 

ssh and git pull from remote server:

ssh root@server2 ‘cd /root/.example; git pull origin master’

 

Today I will explain how I installed Linuz and other usefull things for it.

 

First is to install a Linux distribution:

For this I choose to do it inside a virtual machine (virtualBox with Ubuntu)

Link to download Ubunto:

https://www.ubuntu.com/download/desktop/thank-you?country=MX&version=18.04.2&architecture=amd64

After installing it into virtualBox:

After that I Installed support for your development environment.

In my case I installed python, Java, etc (but you can use the ones you will need and use)

$ sudo apt-get install build-essential checkinstall

$ sudo apt-get install libreadline-gplv2-dev libncursesw5-dev libssl-dev \

libsqlite3-dev tk-dev libgdbm-dev libc6-dev libbz2-dev

$ wget https://www.python.org/ftp/python/3.7.0/Python-3.7.0.tar.xz

$ tar xzf Python-3.7.0.tgz

$ cd Python-3.7.0

$ sudo ./configure –enable-optimizations

$ make

$ sudo make install

 

Then for setup web deployment, I choose a classic LAMP stack.

For that I had to install Apache2:

(In the terminal)

sudo apt install apache2 -y

Then install MySQL:

sudo apt install mysql-server -y

(You can secure it):
sudo mysql_secure_installation

For Password I choose NO  (n)

After that all YES (y)

 

The last step to install LAMP on Ubuntu is to install the PHP preprocessor.

sudo apt install php -y   sudo systemctl restart apache2

 

For extra you can Install PHP Modules:

sudo apt install php-curl

 

References:

https://github.com/byt3bl33d3r/SILENTTRINITY/wiki/Setting-up-your-development-environment

https://mediatemple.net/community/products/dv/204643880/how-can-i-create-a-phpinfo.php-page

https://dzone.com/articles/install-lamp-on-ubuntu-1804-1

 

After reading for interesting information in the web about DevOps I have learned a lot about its area and about for what its used.

DevOps is the practice of operations and development engineers working together in the entire service lifecycle, from the design through the development process into production support. It is also characterized by operations staff making use many of the same techniques as developers for their systems work.

It also is a new term emerging from the collision of two major related trends, it sprang from applying Agile and Lean approaches to operations work, but also from the understanding of the value of collaboration between development and operations staff throughout all stages of the development lifecycle when creating and operating a service, and how important operations has become in our increasingly service-oriented world.

Some call DevOps as being “developer and operations collaboration,” or it’s “treating your code as infrastructure,” or it’s “using automation,” or “using kanban,” or “a toolchain approach,” or “culture,” or a variety of seemingly loosely related items all because the discussion around it covers a lot of ground.

DevOps is not simply implementing a set of tools to use; some people only use the automatization without the thinking and theory.

DevOps is a little tricky, but the most important is that the people that use it should understand and practice that software isn’t done until it’s successfully delivered to a user and meets their expectations around availability, performance, and pace of change.

In the end its aim its to provide a faster and reliable software product development and careful implementation with the use of the assistance of automation.

It also helps with: finding pain points inside the development operation system. It provides reliable strategies, reduces the amount of risk, and reduces the failures in new launches.

References:

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

https://www.atlassian.com/devops

https://www.cioreview.com/news/advantages-of-devops-in-the-software-development-process-nid-27602-cid-99.html

 

 

 

After readying The Secret Life of Bugs: Going Past the Errors and Omissions in Software Repositories, by Jorge Aranda and Gina Venolia, The paper uses rich bug histories and survey results to identify common bug fixing coordination patterns and to provide implications for tool designers and researchers of coordination in software development.

Research on coordination of software professionals faces the problem of having too many possible events and variables to observe and too limited observation and analysis resources. The need to be selective permeates our data collection and analysis strategies.

There is the studies of root cause analyses, which explore a number of process failures to uncover and fix their root causes. Which I think its pretty cool.

The goal that they had was in my opinion of most importance, like contextualized, work-item-centric account of coordination in bug fixing tasks.

They also ask really interesting questions to consideration:

How is the process of fixing bugs coordinated in software teams? What is the lifecycle of bugs? What are the most common patterns of coordination involved in this work? How does their resolution play out over time and over the socio-technical network of the teams that work on them?

Lets not forget the levels of data collection and analysis:

• Automated analysis of bug record data
• Automated analysis of electronic conversations and other repositories.
• Human sense-making
• Direct accounts of the history by its

They discovered a number of coordination patterns of bug fixing, which were validated through a survey of software professionals. From an analysis of the underlying purpose of the people that engage in these patterns, we derived eight goals for bug fixing that are useful as a framework to design better tools and practices.

 

In this part I will talk a little about unit testing framework, I choose for the example the language of Java.
UNIT TESTING, its a level of software testing where individual units or components of a software are tested. The purpose is to validate that each unit of the software performs as is was designed. A unit is the smallest testable part of any software. It usually has one or a few inputs and usually a single output. In procedural programming, a unit may be an individual program, function, procedure, etc. In object-oriented programming, the smallest unit is a method, which may belong to a base or super class, abstract class or derived or child class.

It has many benefits:
• Increases confidence in changing/ maintaining code.
• Codes are more reusable
• Development is faster
• Lesser cost in fixing
• Debugging is easy
• Codes are more reliable
For my example I will use JUnit:
It is a test framework which uses annotations to identify methods that specify a test.
For JUnit test, is a method contained in a class which is only used for testing. This is called a Test class. To define that a certain method is a test method, annotate it with the @Test annotation. This method runs the code under test. You use an assert method, provided by JUnit or another to check an expected result versus the actual result. These method calls are typically called asserts or assert statements.
This is a great tool that should help you save a lot of time and energy going back over code that isn’t working right because it wasn’t regularly tested.
The code that I used can be found here:
https://github.com/alexdelmed/Unit-Tests/tree/master

In here we test that the method of JunitTest, that takes a string and counts the number of time designated letter occurs in the string.

I used Netbeans for this.

The code JunitTesting.java is the program that will run.

Then Click on Tools and Create/Update Tests(You have to be on the Operator class)
The code JunitTestingTest.java is to verify that it is correct.

Then Run the Test program with «Run» -> «Test Project» and i will pop the results.

 

References:
https://www.tutorialspoint.com/junit/junit_test_framework.htm

thanks a lot to this blogg:

How to use JUnit with NetBeans

Link to the audio:

After listening to the podcast of Ken Beck, I had some ideas and wrote some things I learned.
People ARENT convinced that being agile, iterating, making small commits, that are so important, they think its not so necessary.
Some people think that first you have to figure out what you have to do, then do it, and its done. Mostly it doesn’t work, but in my opinion it’s a life lesson that we have to go through to learn.

If someone is working on something (like code or other thing) if you break it or crash it, it’s the responsibility of the person to fix it. Some fear to break the code, but in some cases its need to break to become better.
But this doesn’t mean to beak things for fun, be smart and think what moves you are going to make.
They also talk about Workflow, wich consist of an orchestrated and repeatable pattern of activitys, enabled by the systematic organization of resources into processes that transform materials, provide services, or process information.

In computer way, its the way you work to get the code to function or to found if it works properly.

One of the topics that they mensioned that called my atention was the Test commit or revert.

It is where every time the tests run correctly the code is committed. It is suguested that suggested that if the tests failed the code should be reverted. But I think a part should be that if the tests fail, then the code goes back to the state where the tests last passed. But that can cause a lot of problems and time lost. Sometimes it can be something little.

We are human and we make mistakes.

If you don’t want a bunch of code wiped out then don’t write a bunch of code between greens. Yes it can be frustrating to see code disappear but you almost always find a better, surer, more incremental way of doing the same thing.

This is where they talked about Limbo, wich scales technical collaboration by propagating tiny changes instantly. TDD won’t work in Limbo because each of a hundred thousand programmers can’t saddle all the other programmers with even one failed test. If thousands of tests are failing, then nobody knows what’s going on.
«Make smaller changes, in a stable way»

One of the last things where tips, on how to make a good program, wich I myself have learned in the years. Here are some: (wich they also talk about)

• Write Useful Comments.
• Use Meaningful Names
• THINK before coding
• Use Automated Build Tools.

There are many more, but this are the one´s that I first though about.

Good luck and never give up.