Eclipse C/C++ Development Toolkit (CDT)

Eclipse is an Integrated Development Environment or IDE. The Eclipse was originally created by IBM, but the Eclipse Foundation has since taken over direction and development of the project. Eclipse started out as a Java IDE, but has since grown into much more.

C/C++ development with the Eclipse Platform

This article, which is a follow-up to “C/C++ development with the Eclipse Platform,” is intended for C++ developers who want to learn C++ development using the Eclipse CDT. A simple C++ application is developed in the article. The application makes use of the C++ STL. Readers should be familiar with the STL, as well as with basic object-oriented programming principles such as inheritance and polymorphism. A familiarity with Eclipse will be helpful, but is not required.

HOW TO: Use CDT and MinGW for Eclipse (i.e. develop C/C++ applications in windows)

 

 

Paso 1:

Bajar de mingw.org lo siguiente:

Paso 2:

Extraer los archivos al directorio c:mingw y instalar mingw32-make-3.80.0-3.exe en c:mingw.

Paso 3:

Agregar c:mingwbin a la variable de ambiente de sistema Paths. Verificar con el comando gcc -v .

Paso 4:

Descargar Eclipse e instalarlo.

Paso 5:

Instalar C/C++ Development Toolkit (CDT) usando el menú de actualización Help-> Software Updates -> Find and Install -> Search for new Features to Install.

Paso 6:

Crear un proyecto nuevo file->new ->Managed Make C Project.

Paso 7:

 

Agregar el archivo main.cc con el siguiente código (para probar la instalación):

#include
#include
using namespace std;

int main()
{
string yourName;

cout << “Enter your name: “;
cin >> yourName;
cout << “Hello ” + yourName << endl;
return 0;
}

 

Law of Leaky Abstractions

Una de las paradojas del desarrollo actual es que la disponibilidad de herramientas con grados de abstracción cada vez más altos ha hecho el convertirse en un programador de alto de nivel cada vez más difícil.


Si bien es cierto que se puede desarrollar en ASP .Net con el ratón, inevitablemente llega el momento del error extraño, o del requerimiento fuera del alcance de los asistentes y la ayuda en línea. La única manera de salir de esos pozos es entendiendo el código base, debajo de la capa del IDE y de los asistentes.

Point-and-click VB es un cómodo sillón, pero que flota en aguas turbulentas y más nos vale saber nadar.

Law of Leaky Abstractions:

All non-trivial abstractions, to some degree, are leaky.

Abstractions fail. Sometimes a little, sometimes a lot. There’s leakage. Things go wrong.

Joel Spolsky

TDD by Example con Python 3

Después de leer Test Driven Development- By Example (Addison-Wesley Signature Series) me quedo un sensación mixta de intranquilidad.

Seguí los ejemplos del libro, la primera parte usando C#; aunque el libro usa Java y la segunda parte con Python 3.1, haciendo algunas adecuaciones al código del libro. De hecho, primero lo intente con IronPython para seguir con el tema de .Net, pero con Python 3.1 y IDLE me fue más fácil hacer trabajar el código.

TDD es una técnica avanzada que en su expresión ortodoxa no es seguida ni por el mismo Beck. Es fácil caer en callejones sin salida y el desarrollador debe tener un plan top-down  implícito basado en su experiencia y dominio técnico. Por otro lado su aceptación y referencias de éxito son evidencia de su validez.

La primera parte del libro me pareció incompleta, llena de manitas de puerco, visión nocturna, multiplicaciones por el número que pensaste, y conjuros de magia negra.

la segunda parte es de más alto nivel de abstracción pero muestra claramente los fundamentos del marco de xUnit. El uso de Python aquí parece apropiado ya que permite desarrollar la estructura básica de xUnit de manera clara y directa.

En resumen, Test Driven Development- By Example es un buen libro para desarrolladores expertos.

Referencias

Test Driven Development- By Example (Addison-Wesley Signature Series)

http://dinsdale.python.org/dev/peps/pep-0008/

http://docs.python.org/3.1/tutorial/index.html

http://www.python.org/

http://www.swaroopch.com/notes/Python

http://www.wrox.com/WileyCDA/

http://www.wrox.com/WileyCDA/Section/Browse-Titles-for-Code-Downloads.id-105127.html

http://www.wrox.com/WileyCDA/WroxTitle/Python-Create-Modify-Reuse.productCd-0470259329,descCd-DOWNLOAD.html

http://pybites.blogspot.com/

good programmers

Joel on Software

Hitting the High Notes

by Joel Spolsky
Monday, July 25, 2005

In March, 2000, I launched this site with the shaky claim that most people are wrong in thinking you need an idea to make a successful software company:

The common belief is that when you’re building a software company, the goal is to find a neat idea that solves some problem which hasn’t been solved before, implement it, and make a fortune. We’ll call this the build-a-better-mousetrap belief. But the real goal for software companies should be converting capital into software that works.

For the last five years I’ve been testing that theory in the real world. The formula for the company I started with Michael Pryor in September, 2000 can be summarized in four steps:

Best Working Conditions Best Programmers Best Software Profit!

It’s a pretty convenient formula, especially since our real goal in starting Fog Creek was to create a software company where we would want to work. I made the claim, in those days, that good working conditions (or, awkwardly, “building the company where the best software developers in the world would want to work”) would lead to profits as naturally as chocolate leads to chubbiness or cartoon sex in video games leads to gangland-style shooting sprees.

flops in Matlab

Somebody asked how one may count the number of floating point operations in a MATLAB program.
Prior to version 6, one used to be able to do this with the command flops, but this command is no longer available with the newer versions of MATLAB.
flops is a relic from the LINPACK days of MATLAB (LINPACK has since been replaced by LAPACK). With the use of LAPACK in MATLAB, it will be more approrpiate to use tic andtoc to count elapsed CPU time instead (cf. tic,toc).
If you're interested to know why flops is obsolete, you may wish to read the exchanges in NA digest regarding flops.
Nevertheless, if you feel that you really do need a command to count floating point operations in MATLAB, what you can do is to install Tom Minka's Lightspeed MATLAB toolbox and use the flops counting operations therein.


@cise.ufl.edu>

@cise.ufl.edu>
To count flops, we need to first know what they are.  What is a flop?

LAPACK is not the only place where the question "what is a flop?" is
relevant. Sparse matrix codes are another. Multifrontal and supernodal
factorization algorithms store L and U (and intermediate submatrices, for
the multifrontal method) as a set of dense submatrices. It's more
efficient that way, since the dense BLAS can be used within the dense
submatrices. It is often better explicitly store some of the numerical
zeros, so that one ends up with fewer frontal matrices or supernodes.

So what happens when I compute zero times zero plus zero? Is that a flop
(or two flops)? I computed it, so one could argue that it counts. But it
was useless, so one could argue that it shouldn't count. Computing it
allowed me to use more BLAS-3, so I get a faster algorithm that happens to
do some useless flops. How do I compare the "mflop rate" of two
algorithms that make different decisions on what flops to perform and
which of those to include in the "flop count"?

A somewhat better measure would be to compare the two algorithms based an
external count. For example, the "true" flop counts for sparse LU
factorization can be computed in Matlab from the pattern of L and U as:

[L,U,P] = lu (A) ;
Lnz = full (sum (spones (L))) - 1 ; % off diagonal nz in cols of L
Unz = full (sum (spones (U')))' - 1 ; % off diagonal nz in rows of U
flops = 2*Lnz*Unz + sum (Lnz) ;

The same can be done on the LU factors found by any other factorization
code. This does count a few spurious flops, namely the computation a_ij +
l_ik*u_kj is always counted as two flops, even if a_ij is initially zero.

However, even with this "better" measure, the algorithm that does more
flops can be much faster. You're better off picking the algorithm with
the smallest memory space requirements (which is not always the smallest
nnz (L+U)) and/or fastest run time.

So my vote is to either leave out the the flop count, or at most return a
reasonable agreed-upon estimate (like the "true flop count" for LU, above)
that is somewhat independent of algorithmic details. Matrix multiply, for
example, should report 2*n^3, as Cleve states in his Winter 2000
newsletter, even though "better" methods with fewer flops (Strassen's
method) are available.

Tim Davis
University of Florida
davis@cise.ufl.edu
@cise.ufl.edu>

Nubes

El continuo abaratamiento de la infraestructura computacional y la omnisciencia de conexiones de banda ancha están generando un cambio de paradigmas en el industria de tecnología de información y se ven nubes acumulándose en el cielo informático.

Referencias

Clear code that works

A partir de una visión clara e intima del proceso de desarrollo de software, Kent Beck a creado un enfoque metodológico que  a primera vista pareciera contra intuitivo pero que ha resultado exitoso y ampliamente aceptado en la comunidad de programadores.

En Test Driven Development: By Example (Addison-Wesley Signature Series), el libro seminal de TDD, Beck aplica el refrán de divide y vencerás al precepto de calidad en la producción de código:  Clear code that works.

Beck propone contracorriente que es posible separar las consideraciones de calidad de código, desde la perspectiva de ingeniería de software, de la verificación de la funcionalidad, y que el primer paso en cada iteración del proceso de desarrollo es definir y aplicar las pruebas de funcionalidad.

Beck utiliza un proceso de refactorización para pasar de código funcional a código limpio, utilizando la eliminación de redundancia o duplicidad  como guía metodológica.

Haciendo una analogía con un semáforo,  Beck describe un proceso iterativo de 3 pasos:

  1. Rojo. Empezar con una prueba que debe fallar, tal ves ni compilar siquiera.
  2. Verde. Hacer que el código pase la prueba de la manera más expedita y simple, sin consideración alguna a normas y patrones de calidad de código.
  3. Refactorizar. Eliminar redundancia en código, pruebas, y datos.

De tan sencillo enfoque Beck elabora la metodología de desarrollo dirigido por pruebas.

Levantamiento de requerimientos

El siguiente escenario es tí­pico: Un consultor trabaja con los usuarios para describir los procesos de negocio que serán soportados por el software. El equipo de desarrollo recibe la descripción del consultor pero no están familiarizados con los términos de negocio y consideran la descripción demasiado informal. Los desarrolladores escriben su propia descripción desde un punto de vista técnico. El usuario no entiende esta descripción pero la acepta para que el proyecto avance. El resultado puede ser un sistema que desde el punto de vista del usuario es difícil de usar y que no cumple con sus expectativas.

Parte de este problema es metodológico, y en parte es intrínseco a las caracterí­sticas de los usuarios. Algunas de las problemáticas que se presentan:

  • Los usuarios no saben que es lo que quieren
  • Los usuarios no aceptan como un compromiso los requerimientos escritos
  • Los usuarios insistirán en nuevos requerimientos después de fijar costos y agendas.
  • Los usuarios no están disponibles y la comunicación con ellos es lenta
  • Los usuarios no participan en revisiones de avance.
  • Los usuarios no entienden el proceso de desarrollo y no les interesa.

Existen herramientas y metodologías para el levantamiento de requerimientos. Casos de uso y UML son medios para formalizar este proceso. Que diagramas UML es apropiado usar dependerá del sistema a desarrollar.

Una guía simple en términos de la complejidad del sistema:

  • Aplicación mono usuario
    • Diagrama de casos de uso.
    • Diagrama de clases.
    • Diagrama de interacción.
  • Aplicación mono usuario, con manejo de eventos:
    • Añadir: Diagrama de estados.
  • Aplicación cliente servidor:
    • Añadir: Diagrama de despliegue y diagrama de componentes, dependiendo de la complejidad.
  • Aplicación compleja distribuida:
    • Todos.

Para una aplicación sencilla debemos realizar entre tres y seis tipos de diagramas, y para una aplicación compleja unos nueve tipos. El diagrama de casos de uso puede modelar el contexto de un sistema o los requisitos del mismo. Se puede extender la colección de elementos base de UML utilizando estereotipos.

Referencias: