Team.

--Originally published at Enro Blog

Working as a team

A project is not accomplished by only one person and in this chapter we focus in the many individuals that are directly related to the development of code, that is the working project team. The idea of the pragmatic programmer behind the pragmatic project is about to make the team a pragmatic team, by expanding the universe of action of pragmatism we now have a functional unit of people willing to cooperate for the sake of good programming.

As your project gets under way, we need to move away from issues of individual philosophy and coding to talk about larger, project-sized issues. We aren’t going to go into specifics of project management, but we will talk about a handful of critical areas that can make or break any project.

As soon as you have more than one person working on a project, you need to  establish some ground rules and delegate parts of the project accordingly. In Pragmatic Teams, we’ll show how to do this while honoring the pragmatic  philosophy.

When working on a team you must look up at the team while looking for broken windows, make your code clean and good to avoid this, and keep the communication about what is happening with the project in a pragmatic team people are looking for a meeting to keep in touch communication with the team is very important and helps to take more important decisions.

Testing

Testing is by no means an easy task, there is quality to be maintained and many things to keep in consideration when doing this, the testing is the part of the project where we look forward to the quality guide lines and go outside to look up defects in the code.

We need testing because programmers are unable to create

04pbmxd
rclmiuy
Continue reading "Team."

5 minutes until midnight.

--Originally published at Enro Blog

Introduction

This is the part of the proyect where we find again that the proyect basics must be stablished before the proyect even begins,  determine the requiremets, AKA listening the user is not enought, is one of the basics the proyects need in the planning stage, and requiremets is one of the biggest parts of the proyect because as the experience of the many proyect managers that have been to our class have pointed out, requirements are at the mercy of the imagination of the client.

xlh3u3y

What a fantastic show

Requirements

Many books seem to imply that the requirements are already there the moment you aproach the user to request them, the reality of the requirements and what is important to understand is that they are hidden beneath the ground.

Requirement : A statement of something that needs to be accomplished. Good requirements might include the follow.

  • An employee record may be viewed only by a nominatd group of people.
  • The cylinder-head temperature must not exceed the cirtical value, which varies by engine.
  • The editor will highlight keywords, which will be selected depending on the type of file being edited.

The first statement in the list above may have been stated by the users as “Only an employee’s supervisors and the personnel department may view that employee’s records.” Is this statement truly a requirement? Perhaps today, but it embeds business policy in an absolute statement. Policies change regularly, so we probably don’t want to hardwire them into our requirements. Our recommendation is to document these policies separately from the requirement, and hyperlink the two.

Abstractions Live Longer than Details

One very important thing to take into account when we make the system is that the user interface is as important as the system itself, we cannot create a system that is not addecuate

rglfizf
baddabl
Continue reading "5 minutes until midnight."

While you are coding.

--Originally published at Enro Blog

Chapter 6. Common knowledge with programming is once the codding part beggins is all about the keyboard the machine and the programmer, in reality programming is another kind of communication, and communications requieres understanding, being careful with what you do, and knowing what you do, what it does and why it does that, otherway we may end up coding by concidence.

rglfizfThat sweet sweet corsair K70 will have to wait until after proper colaboration with the testing team is stablished.

The programmers need to know the algorithm speed of the methods they created, most nontrivial  algorithms handle some kind of variable input. Normally the size of this input will affect the algorithm: the larger the input, the longer the running time or the more memory used.

More significant algorithms are not linear. The good news is that many are sublinear. A binary search, for example, doesn’t need to look at every candidate when finding a match. The bad news is that other algorithms are considerably worse than linear; runtimes or memory requirements increase fer faster than n. An algorithm that takes a minute to precess ten items may take a lifetime to process 100.

xw539eaRobbie Rotten finds out the intern name selection bubble sort.

Moving forth and afar from the diferent kinds of algoriths that may take another post or two to talk about. The next thing we need to take into account when coding is the refactoring. Refactoring the action of reviewing the code and modifing the code in order to make it more organic and natural the the solution in question. Clearly refactoring is an activity that needs to be undertaken slowly, deliberately and carefully.

Testing against contract

We like to think of unit testing as testing against contract. We want to write test cases that ensure that a given unit honors

Continue reading "While you are coding."

Bend or break

--Originally published at Enro Blog

This is about chapter 5 in The pragmatic programmer. The job of  a programmer is always evolving, new things come out everyday, many new frameworks come and go and that applies to many areas of programming, web programming is affected the most because the nature of how the INTERNET moves. In this chapter we dedicate some time to the best practices to keep your programs flexible and maintainable.

rglfizf

keeping a cake shop is not as bad of an idea now we envy you Stephany.

The Law of Demeter for Functions

attempts to minimize coupling between modules in any given program. It tries to prevent you from reaching into an object to gain access to a third object’s methods.law of demeter

Dynamic configuration

Use metadata to describe configuration options for an application: tuning parameters, user preferences, the installation directory, and so on.

We use the term in its broadest sense. Metadata is any data that describes the application—how it should run, what resources it should use, and so on. Typically, metadata is accessed and used at runtime, not at compile time. You use metadata all the time—at least your programs do. Suppose you click on an option to hide the toolbar on your Web browser. The browser will store that preference, as metadata, in some sort of internal database.

 

Bibliography

McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.


You are (not) perfect

--Originally published at Enro Blog

Everyone knows that they personally are the only good driver on Earth. Well its the same with codding, we go around making sure everything is perfect when we have in hand the code of another person. And pragmatism is about taking this one step further, to not trust ourself. We know that no one makes perfect code, including ourselves. Ahead well find some measures to protect ourself from what software we create.

Design by contract is about focusing in the documentation and the rights and responsibilities of software modules to ensure program correctness. Correctness is something that does what it claims to do?

Every function and method in a software system does something. Before it starts that something, the routine havve some expectation of the state of the world, and it may be able to make statement about the state of the world when it concludes. These are.

Preconditions. What must be true in order for the routine to be called; the routine’s requirements.

Postcondition. What the routine is guaranteed to do; the state of the world when the routine is done. The fact that the routine has postcondition implies that it will conclude: infinite loops aren’t allowed.

Class invariants. A class ensures that this condition is always true from the perspective of a caller.

The contract between a routine and any potential caller can thus be read as

If all the routine’s preconditions are met by the caller, the routine shall guarantee that all postconditions and invariants will be true when it completes.

All errors give you information. You could convince yourself that the error can’t happen, and choose to ignore it. Instead, Pragmatic Programmers tell themselves that if there is an error, something very, very bad has happened.

Tip 32
Crash Early

enjuowp

with style

One of the benefits

Continue reading "You are (not) perfect"

How to handle programming tools.

--Originally published at Enro Blog

Many are the tools that have been created by programmers for programmers, we tend to have very specific tastes when it come to languages, paradigms, text editors and IDES that it is hard to track the really useful tools. But after reading this chapter I can deduct that there are some tools that never get old, vi, emacs, are the ones that stand the curse of time the better, but there are also new tools that are worth mention. For example atom, and sublime text can be very powerful on their own and can handle many kinds of language while keeping the simple plain text for everyone to use, even better atom already comes with source code control integrated in the form of github. Github tracks the files you are working on and  keeps track of the changes you make to said files. pgcif7h

Bibliography

Hunt, Andrew, and David Thomas. “The Pragmatic Programmer.” Addison Wesley 15
(2000).

Pragmatic approach

--Originally published at Enro Blog

Welcome to my views and thoughts regarding episode 2 of the fantastic book “the pragmatic programmer”, in which a hope to share some of the already digested insight from this chapter. The main focus of this chapter is the aproach to solutions in the development plan of a project and it starts by discusing the advantages that a well though project can avoid the duplicate problem. Inside a software project information can tend to duplicate itself for many reasons, some of this reasons are.

  • Imposed duplication. Developers feel they have no choice, the environment seems to require duplication.
  • Inadvertent duplication. Developers don’t realize that they are duplication information.
  • Impatient duplication. Developers get lazy and duplicate because it seems easier.
  • Interdev eloper duplication. Multiple people on a team duplicates a piece of information.

And also, speaks about the project orthogonality, a concept taken from geometry that implies independence from code module to module or from person to person, good orthogonality can be applied even outside the programming concept. In every day’s work the orthogonality is reflected on the lack of information repetition. The advantages of this are many, but it is simplified in code reuse and little modifications in case of need of more features. On the other hand, projects that lack orthogonality are those that are really chaotic, adding new button in the AI needs the whole architecture to take a new approach.

spxwmpsThe fact this thing can fly is pure coincidence.

Reversibility is about the simple solutions, how the simple solution is not always the desired one and how we the developers must be looking at the bigger picture. Is our project likely to be client based or server-client? even if we don’t know yet (or even if we know) we must consider that the specifications and the marketing team can

Continue reading "Pragmatic approach"