On Blogging

--Originally published at Hackerman's house

After reading Ana’s Blog I realized how blogging can become part of our life. It is a tool we use to share our experiences with people we don’t know, but it also can be a place where we are free and can express everything we have inside of us. My personal experience with bloging isn’t as big as Ana’s, but it has been evolving since day 1.

Something important to mention is that my teacher Ken Bauer has given me classes in 4 different semesters, each one has been a little bit different. First semester I had to create a blog for the course and I wasn’t thrilled about it, but after a few days I started messing with the template I was using, the colours and I had a lot of fun doing that, it was a good first experience, at some time I even started using images and gifs to share everything I could about me in there.

In fourth semester I had my worst experience where my blog had to be in Blackboard, that was very boring and didn’t really reflect my personality.

Fifth and six semester were really similar, the thrill about blogging had mostly dissapeared. I enjoy some alone time with my blog, but I rather spend my time doing something else.

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"

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

OO and Agile

--Originally published at Hackerman's house

There are lot of agile methodologies, each one has its own practices and characteristics, but in general they share the same philosophy. These ideas were expressed in the Manifesto for Agile Software Development.

Resultado de imagen para agile manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

The origin of these methodologies arises in 1990s in a world shaped by two major influences: Object-Oriented programming replacing procedural programming as the programming paradigm favored by the industry; the other influence was the rise of the internet. This situation made that the requirements started to rapidly change and shorter product life-cycles were required; this was incompatible with the traditional methods of software development. There was a need for new methodologies that could adapt to this new world.

Extreme programming

Extreme programming is a methodology which is intended to improve software quality. It advocates frequent releases in short development cycles; it uses checkpoints at which new customer requirements may be added. Other main elements of this methodology is pair programming, extensive code review, unit testing of all the code, avoiding to develop features until they are actually needed, and one of the most important ones is constant communication between the client and the programmers to assure all the requirements are being fulfilled. The origin of the name is that traditional software engineering practices are taken to extreme levels, such as pair programming that is basically extreme code review.

Resultado de imagen para extreme programming

Sources:

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

http://agilemanifesto.org/

Test Driven Development

--Originally published at Hackerman's house

Test Driven Development is a software development process that repeats very short development cycles, the requirements are turned into specific test cases, and the software is improved in order to pass these new tests. This way all the software is proven to meet the requirements set. One of the main responsibles for this methodology is Kent Beck who rediscovered the technique.

A Test Driven Development cycle consists of a series of steps. According to the book Test-Driven Development by Example these are the steps.

Add a test

Each new feature begins writing a test. The test defines a function or the improvement of an existing function. The developer must start by fully understanding the feature and its requirements. Some of the tests can be updates of an existing test. The use of tests before starting to write code lets the developer to focus on the requirements while writing code.

Run all tests and see if the new test fails

In this step the existing code is proven to see if the new test is passed. If the existing code passes the new test it means that the test is useless or flawed. The new test should always fail because there should not be code that fulfills the requirements yet.

Resultado de imagen para tests

Write the code

The next step is to write the code to pass the test. It is not that important that the code is elegant or really well written. The most important thing is to pass the test. One thing you should consider is that the code must only fulfill the test and not add more functionality beyond that.

Run tests

If all test cases now pass, then the new code meets the test requirements and doesn’t break any existing features.

Refactor code

The last step in the cycle is to

Resultado de imagen para code
Continue reading "Test Driven Development"

Verification and validation

--Originally published at Hackerman's house

These are two different processes utilized to test if the software we are producing satisfies certain characteristics. Both are directly related with what the client wants to build. Let’s see the differences between them and why both or them are important in the process of building great software.

Verification

Verification is the process of evaluating work-products of a development phase, this doesn’t evaluate the final product. The evaluation done decides if the software satisfies the specified requirements of that phase.

Are we building the product right?

Verification is done trough reviews, walkthroughs and inspections. These check if the software satisfies each of the requirements it should.

Resultado de imagen para verify

Validation

Validation is the process of evaluating software at the end of the development process to determine if it satisfies specified business requirements. It basically evaluates if the software does what the client needs, it is directly related to the specifications done at the beginning of the project, if these were wrong in the first place then the software won’t be validated.

Are we building the right product?

There are two ways to perform software validation, internal and external. In the internal way it is assumed that the goals of the stakeholders were correctly understood, and if the software meets the requirement specification then it is internally validated. External validation happens when you ask the stakeholders if the software meets their needs.

Resultado de imagen para validation

Source

http://softwaretestingfundamentals.com/verification-vs-validation/

Classes to code

--Originally published at Hackerman's house

If you have read my blog up until now, you should know the basics about software design, and specifically about the use of UML in this area. Let’s see how to take advantage of all the analysis and design we have done. The class design that we already know how to do can be converted into code that will be the actual implementation of the system.

Resultado de imagen para class diagram

The quality of the diagrams used has a direct implication on how to translate it into code. Diagram classes are object oriented, so it may be convenient for you to convert these diagrams into a object oriented language; this will allow you to keep the identity and functionality of the system you design; if you consider that using a non-object oriented language is more appropriate in your own case feel free to do so.

It is important for you to have a profound understanding of your system and your diagrams before starting to code. You will be able to see that the class diagrams offer you a lot of information to that you can take advantage of; the first example is the attributes you will need to initialize in your code. The method’s name gives you a basic understanding of what you have to program. Even the inheritance is specified within the diagrams, all you have to do is implement all the design you already have. Just take your time and select a language you are familiarized with.

Resultado de imagen para coding

As we can see, the hard part is already done when the analysis and design is finished. The implementation is just a translation of what we already know about the system.

Classes to tables

--Originally published at Hackerman's house

When you have to map objects to relational databases, the place where you have to start is with the data attributes of the class. It is important to define in how many columns these attributes will be mapped, it can be from zero columns to many more. Not all attributes are persistent, this means that they are used for some temporal calculation in the application, this has a direct impact in the way the database is designed because it’s possible that this attribute is not necessary in your database. In the case that an attribute is an object in their own, the attribute will map into several columns in the database.

The easiest mapping is when each attribute goes into a single column. In this case the class model and the physical data model can be very similar; the main differences will be that the data model needs at least one primary key, and in case there are more classes interrelated you need to add the foreign keys for the occasion.

Inheritance

Inheritance is a big deal when mapping a class into a table. The issue is figuring out how to organize the inherited attributes in your model. There are three fundamental solutions for this.

This class hierarchy will be modified using the three approaches.

Figure 1. A UML class diagram of a simple class hierarchy

Using one data entity for an entire class hierarchy.

This means that you will map an entire class hierarchy into just one data entity that contains all the attributes of all the class in the hierarchy. It is important to add the primary key to the data entity. The advantage of this approach is that you have all the information available in just one table; this supports polymorphism in an easy way. The cons are that has a high level of coupling and an error

Figure 2. Mapping the class hierarchy to one single data entity.
Figure 3. Mapping each concrete class to a single data entity.
Figure 4. Mapping each class to its own data entity.
Continue reading "Classes to tables"

Modeling Languages and Tools

--Originally published at Hackerman's house

A modeling language is a graphical or textual computer language that is used to design models of new software or system.

Graphical modeling

Graphical modeling languages use diagrams, symbols and arrows to represent relations, real life concepts or even steps.

The most popular is the Unified Modeling Language (UML) this is also the most popular modeling language in general. Thanks to its popularity there is a lot of software that supports this language.

Another one is the flowchart, is a diagram used to represent an algorithm, workflow or process.

Both of these languages are supported by https://www.draw.io/ 

Textual modeling

The textual modeling languages are formalized natural languages. TMLs have the ability to describe whole software. The language has to be readable, this is really important because is common that the programmer needs feedback from the user, the model needs to be easy to understand. It is also important that it is unambiguous.

Some examples of these languages are, PlantUML that is an adaptation of UML into a text only format. TextUML does not suppose the user knos UML concepts, it requieres a large amount of information about classes and relations. Umple is model-oriented programming, it is integrated in Eclipse IDE.

Writing

Photo by Chris Campbell

References:

Martin, M; Macek, O (2012) On General-purpose Textual Modeling Languages, recovered from: http://ceur-ws.org/Vol-837/paper10.pdf

Use Cases

--Originally published at Hackerman's house

Use cases is a methodology used to identify, clarify and organize system requirements. Use cases describe the step by step process a user goes to complete a goal using a software system, each use case has an specific goal and it has to consider the things that can go wrong, creating this way not only one path for the user but many paths.

Main characteristics of a use case:

  • Organizes functional requirements
  • Models the goal of the user
  • One main flow of events, and other possible ones (alternate courses of action)
  • Multi-level, this means one use case can use the functionality of another one

21 Steps to Success

Photo by Bernard Goldbach

How to write a use case

You need to have a clear actor, and describe the scope of the use case.

Describe the set of steps the actors take to accomplish the goal of the use case. In case there are alternate flows you have to describe it as well. There is another type of flow, exception flows are the things that prevent the user from achieving their goal, this steps should also be in the use case. The alternate and exception flows must be marked as not part of the main path.
Path less travelled

Photo by Kate Rusell

References:

Brandenburg, L (2018) How to write a use case. Bridging the gap. Retrieved from: https://www.bridging-the-gap.com/what-is-a-use-case/