Test && Commit || Revert

--Originally published at Hackerman's house

The podcast with Scott Hanselman and Kent Beck called test && commit || revert based on the idea previously posted in Kent Beck blog was really interesting as the idea they discussed was something a bit extreme to me, but it made kind of sense. The basic programming workflow is to program, then test the code and if it works you commit it, if it doesn’t work you have to erase everything you did until the last test was passed. The thing that I find extreme in this procedure is that as programmers (and humans) we don’t wan’t to throw what we did to the garbage. We usually prefer to fix what we did, and explore the same solution making minor adjustments.

Resultado de imagen para tirar basura dibujo

Altought the first time Kent Beck heard of this idea he wasn’t really sure if it would work, he decided that he would give it a try. In this workflow the programmer can experiment really quick so you can quickly determine how comfortable you feel with this weird and different technique. The idea is really easy to understand, but it is not that simple to do it right, a complete change in mentality has to be made for this to work, the test should be made more often and have more inmediate goals, this way you won’t throw away a lot of time of work. Another thing to consider is that the code that passes a test usually can be improved, so if you pass a test you may require to take a look at your code to make sure it is robust enough.

Resultado de imagen para test

To conclude I want to talk about my opinion of this programming workflow. I agree with some of the points exposed, and personally I may try to acquire the habit of testing little parts Continue reading "Test && Commit || Revert"

Test && Commit || Revert

--Originally published at Hackerman's house

The podcast with Scott Hanselman and Kent Beck called test && commit || revert based on the idea previously posted in Kent Beck blog was really interesting as the idea they discussed was something a bit extreme to me, but it made kind of sense. The basic programming workflow is to program, then test the code and if it works you commit it, if it doesn’t work you have to erase everything you did until the last test was passed. The thing that I find extreme in this procedure is that as programmers (and humans) we don’t wan’t to throw what we did to the garbage. We usually prefer to fix what we did, and explore the same solution making minor adjustments.

Resultado de imagen para tirar basura dibujo

Altought the first time Kent Beck heard of this idea he wasn’t really sure if it would work, he decided that he would give it a try. In this workflow the programmer can experiment really quick so you can quickly determine how comfortable you feel with this weird and different technique. The idea is really easy to understand, but it is not that simple to do it right, a complete change in mentality has to be made for this to work, the test should be made more often and have more inmediate goals, this way you won’t throw away a lot of time of work. Another thing to consider is that the code that passes a test usually can be improved, so if you pass a test you may require to take a look at your code to make sure it is robust enough.

Resultado de imagen para test

To conclude I want to talk about my opinion of this programming workflow. I agree with some of the points exposed, and personally I may try to acquire the habit of testing little parts Continue reading "Test && Commit || Revert"

Week 3 Plan

--Originally published at Hackerman's house

This week we are going to start developing the UI of the app as well as the navigation trough it. We won’t start the functionality yet, but we will start investigating how to use firebase or some other platform to save pertinent data.

As we are not going to implement any functionality this week, the testing won’t be necessary yet.

List of responsibilities

  • UI (Max and Paco)
  • Navigation (Oscar and Daniela)
  • Firebase Investigation (Everyone)

Cloudscape

Photo by: Stuart Rankin

TDD Kent Beck

--Originally published at Computer Systems Engineering

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.

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.

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

Week 2 Progress

--Originally published at Hackerman's house

As a team we made progress in this week according to the plans defined on monday. We have a basic idea of a project we want to do, an android app that will allow the user to create tier lists of anything they want; we decided the name of our team “God Tiers” based on the main idea of the project.

Basic requirements:

  • Login to enter the app
  • Create lists separated by tiers
  • Upload images and/or text of the elements in the list
  • Export an image of the full list
  • See lists of people you follow

Mockup:

tier2

tier1

 

Mastery 14 – OO and Agile

--Originally published at Sierra's Blog

Agile life cycle works like this:

agile

https://number8.com/common-mistakes-using-agile-method/

It is a new way to see the development team, Agile is flexible, doesn’t have guidelines, creativity is valued, there is freedom to fail.

Agile believes that the team is aware of their responsibilities and that they will the necessary and adequate things in order to accomplish their tasks.

Scrum adapts this beliefs in the development process, a sprint meeting is about the desired output, not about the how since the software developers are the experienced members of the team that actually knows what should they do to correctly get the output.

This methodology also allows that the whole team decides what to do, there’s not a leader selecting tasks among subordinates. Nonetheless, there is a leader role called the Scrum Master which will led the team and supervise if they are following the scrum methodology correctly. In addition, there’s one extra position called the product owner which represents the business, customer or user and its main job is to led the team towards developing the correct tool.

sprints are time segments that could last between one week and no more than one month.

At the start of the sprint, there is a meeting were the objectives of the sprint are selected and the team members commit to aboard them. At the end, a registry that contains the tasks that are going to be done during that sprint is generated.

After the initial meeting, the team participate daily in a 15 minutes long meeting to keep track of who is doing what and what has already been done.

 

References

https://number8.com/common-mistakes-using-agile-method/

http://www.mountaingoatsoftware.com/agile/scrum

Lisp: Good News, Bad News, How to Win Big

--Originally published at Hackerman's house

Lisp: Good News, Bad News, How to Win Big is an essay written by the American computer scientist Richard P. Gabriel in 1991. At that time, he worked a lot on the Lisp programming language. The main topic of the essay is the advantages and disadvantages of that programming language, and how accepted it was by the programmers, as well as some of its uses.

Lisp’s successes

Standardization

One of the biggest successes in Lisp is that there is a standard Lisp called Common Lisp. This wasn’t considered the best Lisp but it was the one ready to be standardized. There was a Common Lisp committee formed by users of different Lisps across the United States; Common Lisp was a coalescence of the Lisps these people cared about.

Performance

It used modern compiler technology of that time, so compared to older Lisps it had a very good performance. It also had multitasking and non-intrusive garbage collection, both were great features that weren’t possible before that time.

Good environments

The environments had a lot of good qualities like windowing, fancy editing and good debugging. Almost every Lisp system had these kinds of environments; a lot of attention had been paid to the software lifecycle.

Good integration

Lisp code would coexist with C, Pascal, Fortran and other languages. Lisp could invoke them and be invoked by them. This was useful to manipulate external data and foreign code.

Resultado de imagen para c language

Object-Oriented programming

At the moment it had the most powerful, comprehensive object-oriented extensions of any language. This was really important because OO was the new trend.

Lisp’s failures

The rise of worse is better

One of the biggest problems of Lisp was the tension between two opposing philosophies. The right thing and worse is better. Lisp designers used the right thing, while Unix and C

Resultado de imagen para hard to program
Continue reading "Lisp: Good News, Bad News, How to Win Big"

Object Oriented and Agile

--Originally published at Newbie Programmer

The Agile software development it’s a set of methods and practices expressed in the Agile Manifesto, this solutions evolve through the collaboration of teams in their context, the manifesto is based in twelve principles, customer satisfaction, welcome changing requirements, software delivery frequently, daily cooperation between people and developers, face to face communication, working software is a measure of progress, sustainable development, attention to technical excellence and good design, simplicity, best architecture, requirements, and design for emerging teams and the teams reflects how to be more effective. One of this type of methods are the Extreme Programming.

The extreme programming it’s an intense methodology that is focused on improving the quality of the code and to adapt to a rapidly change of the customer requirements, as a part of agile software development it has frequent releases and short development cycles to adjust to the new requirements more quickly, in this methodology we can found things like code revision, this is done for avoid programming features that are not needed, this gives the code simplicity and clarity that is moldable for changes, for doing this is a must a frequent communication with the customer and developers, the name was taken from the software practices that are taken at extreme levels.

38891650224_6ec3e98246_k.jpg

Agile 101

Extreme Programming: A gentle introduction

Code revision

--Originally published at Hackerman's house

Code review (also called peer review) is a software quality assurance activity in which one or more developers check a program by reviewing and reading parts of its source code. At least one of the reviewers must not be the code’s author, the purpose of this is to have another point of view, and different ideas to judge the code in a more objective way. The people performing the checking (except for the author of the code) are called reviewers.

Resultado de imagen para peer programming

The main objective of this process is to detect quality problems, although it can be used to reach more goals. Better code quality: improve the readability, maintainability and understandability. Finding defects: finding performance problems, security vulnerabilities among other flaws. There are many more goals that can be achieved through this process, but the general idea is to create better software and to avoid errors.

Types of review processes

Formal inspection

This is the traditional method of review. Software developers attend a series of meetings where the code is reviewed line by line. This method has been proven to be very effective in finding defects in the code.

Regular change-based code review

This is a more lightweight type of code review. This type uses something called Version Control, it is basically a system that records changes to a file or a set of files over the time. Github is one of the most popular applications that does this; the developers are constantly checking the changes made by every member of the team. They can see who is the responsible for the code and they can check it, but they do not dedicate the time to read it line by line.

Resultado de imagen para git

Source:

https://en.wikipedia.org/wiki/Code_review