HTML - Basic Concepts

Introduction

On this post we're gone to talk about how to write html code, so first we need to know what is html. The acronym HTML means "Hypertext Mark-up Language". Consist on a language that need tags for declare the necessary functions for work up. The html code help us on the web page development, this because is easier and quicker used it.

Tags

On this language are necessary tags for represent some characteristics on the page. We use the symbols "less than <" and the "more than >" for start a tag. For example:

<tag>

And we ended with almost the same symbol. Something like this:

<!tag>

So, a complete instruction on html look like this:

<tag> Some text if we need it <!tag>

There exist a lot of tags that can help us to perform our web applications, so the order or the use of this tags are improve for our imagination and abilities for design and distribute the elements, you can consult a list of tags ordered for the type of element here: list of tags for element.

Attributes

The attributes are classes that perform some behaviour on the html elements. The html code, allow us to just put some element on the page, but the attributes allow us to give some structure to our pages. For example:

If we want to upload an image we need to specified the resource in where the image is. Some in the tag img we use the attribute src for specified the path of the image.

<img src="path/of/picture.jpg">

 

Every tag can be combined with different attributes, that can modified the behaviour of the component on the page on different ways.  

Here is a index of the principles attributes for html tags.

Indentation & Spacing

This section is just a guide about the spacing and indentation on html code. This advices are for have more ordered code:

• Open and close your tags at moment.
• Try to have short modules of code. Encapsulate some elements in different files if can.
• Keep things simple.

Read more

Programming Oriented Objects - Basic Concepts

The paradigm of programming oriented objects it is a paradigm very young compare with others but actually is very strong, that happens for the simplicity of the paradigm of simulate the reality of the life, is thinking for represent the behaviours of events, this make it very useful.

Here we represent the concepts as objects with different attributes and methods for represent the actions on this objects. The objects are instances of the classes, and this instances act like the behaviour of the respective class.

Basic Concepts

Abstraction: Is the capacity of extract the most important parts in an activity of the real life, for represent it omitting details less important.

Classes: Are an template for represent behaviour for an instance.

Members: The components of any class.

1. Methods: This components are the actions that can be perform for any object on the class.
2. Attributes: This components are the data that can be store or represented for the object, this data can be another type of class.

Object: Are instances of a specific class, all the instances of a class has the same kind of members. Also, has an state, behaviour and identity unique.

1. State: The state of any object can be altered with interaction with other objects.
2. Messages: The objects send messages (information) through the methods to other objects or classes. If the state of any object change the behaviour also change.

Encapsulation: Is defined the scope of the objects for have a relation with other objects or classes.

Heritage: Is the capacity of the objects for have another behaviour far from the own class. There is a hierarchical pyramid for simulate the relations from the reality to the virtual.

Polymorphism: Is set the capacity to a class or object for represent different behaviours for one name only.

Modularity: It's make groups of discrete units, for reduce the complexity and allow the test of smaller modules and complexity of the objects or classes.

There are basic concepts about the paradigm of the oriented objects.

Read more

Clean Code - Chapter 1 & Chapter 2

Hi readers, in this and other post we are gone learn a little about the chapters of an amazing book, that will be "Clean Code: A Handbook of Agile Software Craftsmanship" of the author Robert C. Martins. In fact this a resume about what he and other professional people and developers said about improve our practices on making good code. So, let's started.

Chapter 1 - Clean Code

In this chapter Martins try to give us an introduction about the meaning of write code, what it this purpose or how we can defined on right way the practices for do - write - quality code.

As a principal point the author signs this: "If you learn from beginning to do bad things and write bad code, some time you will mess up and everything is gone be wrong"; so is a good proposal do right things from beginning, is better do that than try to correct bad practices from people. Is - maybe - a slow way to learn trying to has good practices doing great code, that can help us in the future, than be a machine writing code but making bad code.

When something is wrong with the people that in any project an others come the project because the oldest are gone, they discover that everything is poor, an unstable. So they solution to the problem becomes in a "redesign on the sky" that is too much expensive and doesn't help for the deadline project.

People who know about the business, doesn't waste time trying to solve problems after making a mess, they try to prevent the mess; because a problem can delay the deadline of the project and this affects negative the position of the company. In fact, the better way to prevent that this happens is "KEEP CODE AS CLEAN YOU CAN".

In other case, for help you to keep your code clean, learn the Boy Scout Rule, an boy scout has the rule that they don't leave a place more dirty than they found it. The same pass with code, if you see bad code, try to make it better.

Chapter 2 - Meaningful Names

Well, the title of the book said everything... Meaningful names... Meaningful names... ... ... Always remember that. In this job you always need to be clear about your code, about what you do, about what you trying to solve and invent, about everything. Just like an writer try to be clear for sell his book like a best seller, a programmer need to clear for the other people can understand theirs master pieces.

Let me explain this with an example. Is no the same type:

        int x; // hours of work

than this:

        int laboralHours;

Let's continue, in the first part of the example you see that we need a comment for explain the meaning of the variable, in the second one that wouldn't be necessary; that is ;because in the second one we wrote a meaningful name. The second variable explain for herself the usability of her, and that is a very good practice. 

If we can avoid comments for explain the usability of our variables is better, this doesn't mean that we don't need comments but is better and help us for typed less.

Other tips from the book are: use pronounceable names - don't write something like gendmyhms, than is a generator of days, months, years, hours, minutes and seconds - for your projects, use searchable names, don't be cute, don't repeat names for variables and classes, avoid encoding the names (don't type something that only you can understand), add context to the name (is better a larger variable name than a code than no one can read), don't add funny context to the names, etc...

There exists another rules for type better names, but I leave you the others; because - yes, this is a summary but - the only way to learn something, and learn it right is practising and expend hours trying to understand the meaning of the things.

So, let me know if this help, if is not, the feedback is well received. In the next post we're gone to see Clean Code - Chapter 3 & Chapter 4.

References

Clean Code: A Handbook of Agile Software Craftsmanship
Robert C. Martin

Read more

WhiteBoard for Our Stories and Acceptance Criteria

Hi readers, on my last post I talk about acceptance criteria y and user stories, now we are gonna talk about how to make a whiteboard with stages that can help us for has a better administration of our projects:

In the last picture, we can see four areas, this areas in fact represent our stages of the development of software. Let's explain some more of that:

• Backlog: On this stage we are gone to put our user stories, this stories are a weak idea of the requirements of project that we want to complete on the paper. For start this stories we used the templates of the user stories and the acceptance criteria for begin given an structure to the requierements of the project.

• Ready: This stage on the whiteboard represent all the stories that has an acceptable story and acceptance criteria. In this moment our stories are a guide for our project, and help us write code more clearly and efficient.

• Working: In this stage the development team put the stories that their are developing on real time. The user stories are complete and the acceptance criteria satisfy the requirements of the project and the user.

• Completed: Here the user stories are complete and functional. The team has develop succesfuly the requirements of last stage and get closer to finish the project.

Use the format of SCRUM give to the team a global vision of the project. Made weekly reunions help to empowerment the team, so this help to mark a specific way to complete the goal. Something than is very useful is keep in mind the acronym DRY, that means "Don't Repeat Yourself", because this guide us for make the things just once, this help us for make the code: better, faster, and more efficient.

Read more

Acceptance Criteria. How to improve our user stories.

In the last post we talk about the user stories, so now we need to speak about what is the acceptance criteria. Well, acceptance criteria is a technique for improve our abilities for write requirements for any project. It will help us to make better user stories. It consist on describe step by step actions that complete the user stories, this help us for make more testable and more precise ours functions about the user story.

Like everything, we also are gone to used a structure for the acceptance criteria - remember, the acceptance criteria is related with the user story so you never forget this- and follow the next sentences, the acceptance criteria is describe like scenarios:

• Scenario  An scenario presented, always related with a user story
• Given        a context for the user story
• And           more context for the same user story
• When        the moment which the action is execute
• Then      the result of the action following the contexts of the user story
• And           others result for the same action

For be clear, we are have to check an example, lets use the past user stories. For our acceptance criteria let's use our sign up user story; it say this:

• As a sign up user.
• I want to fill the form of my personal data correctly.
• So that confirm me as a regular and new user, so I can access the features of the page.

On this story we want to sign up a new user in an application, so if we used our acceptance criteria, it will be look like this:

• Scenario: In action to become in a new user for the application, fill the form for the personal data.
• Given a page with a form to be filled with check-boxes and text camps
• And buttons for cancel or sign up for
• And complete all the camps for the register
• When click on the button of sign up
• Then I can see my profile page with all my data
• And can access for search other users

We need to have present that with can use more than one acceptance criteria for a user story. In other cases with can add more "And" tags for represent better the acceptance criteria, and can add more scenarios for the story. On the next post we're gone to talk about making a kind of whiteboard for keep in order our stories.

References

For made this topic I used as reference the post of 10 Tips for Writing Good User Stories and the article What's in a Story?. I hope they don't demand me.

Read more

User Stories. How can I use it? How can I eat it?

On this topic we're gone to talk about what is and how to make good "User Stories". First at all, user stories are a tool that can be used for the practice known as "Scrum" , which is used for teams of development on projects. It consist of make some questions about the purpose of the application and requirements also needs of the customer.

The user story is a structure is an scenario of the requirements of the application, so it used this basic structure:

As a <person>

I want <what>

so that <why>

Let's try an scenario when we need to sign up for any application, fill in the boxes of a form. So we need to digit our personal data.

 As a

This is the subject of the user story, so we could say this, as example:

• As a sign up user.
• As a administrator.
• As a regular user. 

I want

In this step of the structure we say our need, so we want to express our vision of the results of the application, for example:

• As a sign up user --> I want to fill the form of my personal data correctly.
• As a administrator --> I want to check the request of the new and regular users.
• As a regular user --> I want to access and view correctly my home page.

So, we could see how we want a result for our user, and this user need some result for his actions. At this part we only need the <so that> part.

So that

The third part represent the result of the action of the person (our user). It's the acceptance scenario of our request as user. For example:

• As a sign up user --> I want to fill the form of my personal data correctly --> So that confirm me as a regular and new user, so I can access the features of the page.
• As a administrator --> I want to check the request of the new and regular users --> So that give me rights for accept the new people and respond the doubts of the regular users.
• As a regular user --> I want to access and view correctly my home page --> so that allow me to interact with other users and bring me rights for contribute with the page making new posts.

As we see, the user stories help us for make great requirements for the applications. This is a usual practice on the develop software teams, this practice reduce the time of thinking on the needs of the customer and help us for make better code.

Like always, this is my understanding of what is the user stories, I could be making a mistake of the description of the situation. On the next topic we are gone to talk about the acceptance criteria of the user stories, this practice give us a plus and help us to understand better the user stories.

References

For made this topic I used as reference the post of 10 Tips for Writing Good User Stories. I hope they don't demand me.

Read more

First Steps - Introduction

Hi readers,

        Well, hi to you, the people who are reading my blog. Looking the wall you can notice that I'm a amateur about made blogging and this stuffs, making posts is very new for me, so I gone to  try to share my knowledge because I think that this is the goal of the blogs. Share!!!

     
        I has weekly goals on an apprentice program in a corporation to communicate and express the things that I has learn throw the process, giving my interpretation about the things and everything. So, I want to apologize if in any blog I express erroneous information or something like that, because this is no my intention. If any of you - readers - know a better way to explain something I invite you to leave a comment sharing your knowledge.

        The program of apprenticeship use a method called "Mentoring" where you are a student from a mentor. This mentor help you to understand basic concepts about the real topics that you want to learn y guide you to make the things in order and precise. It's very interesting. Also is very important has a point of out to make any help to the society with ours opinion. So, what do you think about mentoring?

Jesús Ramos

Read more