Primera práctica en C# Suma de enteros

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace suma
{
class Program
{
public static void Main(string[] args)

{
int numero1;
int numero2;
int suma;
Console.Write("Escriba else primer entero");
numero1 = Convert.ToInt32(Console.ReadLine());
Console.Write("Escriba el segundo entero");
numero2 = Convert.ToInt32(Console.ReadLine());
suma = numero1 + numero2;
Console.WriteLine("la suma es {0}", suma);

}
}
}

NUEVO SISTEMA DOMÓTICO Y DE ENTRETENIMIENTO DISEÑADO CON HARDWARE LIBRE Y SOFTWARE DE CODIGO ABIERTO

INTRODUCCIÓN

En este trabajo se presenta la descripción del desarrollo realizado de un nuevo sistema domótico y de entretenimiento que utiliza como elementos en su implementación a plataformas tanto de hardware libre como de software de código abierto. El sistema podrá ser realizado y reproducido de forma libre por cualquier persona.

Lo anterior tiene un fuerte impacto en la actualidad en el diseño de espacios inteligentes, en la economía del usuario y en alternativas de independencia a los fabricantes comunes de software.

La convergencia de distintas tecnologías de hardware y software, y de diferentes estándares de comunicación, representa un reto importante para el desarrollo de nuevas aplicaciones y servicios.
La combinación de tecnologías de red con dispositivos inteligentes e interfaces multimodales ofrece un enorme yacimiento de servicios posibles para todos los consumidores a nivel mundial. El objetivo es ofrecer buen servicio a la persona específica en el tiempo oportuno y sin limitación de espacio. Las tecnologías aplicadas en este marco pertenecen a un nuevo ámbito, denominado inteligencia ambiental o informática omnipresente (Pervasive Computing).
El espacio privado (casa, automóvil) o público (oficina, almacén) se convierte en un espacio interactivo y cooperativo, explorando permanentemente los deseos e intenciones de las personas que están dentro, e intentando anticipar sus necesidades involucradas en sus actividades. A estos escenarios se les conoce como espacios inteligentes.
Por consecuente, el presente artículo presenta la descripción completa de la metodología empleada y los resultados obtenidos en el diseño de un sistema domótico y de entretenimiento, dando énfasis a que se han utilizado en su implementación plataformas de hardware libre y software de código abierto, y que un sistema como el que es descrito de este trabajo de investigación no ha sido reportado en la literatura.

DESARROLLO

En el desarrollo de este proyecto informático se utilizó el Visual Studio como herramienta de software tecnológica para la codificación. El sistema de control diseñado aboca la domótica y el entretenimiento. La parte de domótica involucra la integración de distintas tecnologías en el hogar, el objetivo es mejorar la seguridad, el confort, la flexibilidad, las comunicaciones, el ahorro energético, facilitar el control integral de los sistemas para los usuarios y ofrecer nuevos servicios. El control del entretenimiento se refiere a la administración y gestión del contenido multimedia que existen almacenados en los distintos dispositivos que se encuentren dentro de la red del usuario en el hogar o en la oficina. El diseño del sistema es de alto nivel, debido a que las partes que lo componen se diseñan de acuerdo a su arquitectura en capas, donde en cada capa se validó el diseño. Es decir, a fin de agilizar el desarrollo de cada uno de sus componentes se llevó a cabo la integración de todos los subsistemas.

SHDH Tijuana .NET

Asisten in the ATX West

Manufacturing's Marketplace
for Automation and Assembly

See the world's leading suppliers showcase the newest products
and technologies for lean manufacturing, cost reduction,
enhanced productivity, and six-sigma process control.

More information in the web page http://www.anaheimconventioncenter.com/custom.cfm?name=main_noflash.cfm&CFID=2619528&CFTOKEN=11132292

Arduino Open Hardware

“Arduino” es una plataforma de hardware libre (Open-Hardware) basada en una sencilla tarjeta electrónica, terminado en una placa con puertos de Entradas y Salidas (E/S), analógicos y digitales, y se encuentra dentro de un entorno de desarrollo que implementa el lenguaje Processing/Wiring. El chip Atmega8 representa el corazón o núcleo del Sistema Arduino, este es un chip sencillo y de bajo costo que permite el desarrollo de múltiples diseños [3]. Así pues, la plataforma Arduino es muy conocida actualmente gracias a que puede utilizarse libremente para desarrollar cualquier tipo de proyecto sin tener que adquirir ningún tipo de licencia de uso.
Para la realización de las pruebas técnicas, hemos decidido utilizar la tarjeta Arduino para llevar a cabo todas las simulaciones de funcionalidades de control de iluminación, aire Acondicionado y Alarma. Además, hacemos énfasis a que el sistema Arduino se está codificando en Visual estudio.NET para desarrolla el interfaz de control de entretenimiento, el lenguaje Processing/Wiring, se desarrollo el codigo que se grabo en en el pequeño procesadro de la placa para mejorar el proyecto de investigación para realizar un sistema completo e integral.
En las siguientes fotos muestran algunos resultados del trabajo llamado: "Sistema de Control de Entretenimiento utilzando la tarjeta Arduino conectada directamente a una tarjeta de prueba que contiene resistencias y diodos emisores de luz (Leds), que se utiliza en las pruebas iníciales de la simulación del control de automatización. Más información en la otra publicacíon...

Arduino

Los principios del programador

Hola colegas comparto con ustedes este pequeño artíulo que encontre en la red, para mi es importate saber y conocer lo que hacemos como programadores... espero que no me juzguen por hacer un copy de este artículo, incluyo los derechos del autor...

By Daniel Read

Published June 1, 2003
Maganize for software developers chinuxsoft

Traducido desde English por Juan A. Romero desde el Universidad de Cordoba por España. Muchas gracias Juan.

El Principio del Carácter Personal

Lo sepamos o no, nos guste o no, nuestro carácter está reflejado en cada línea de código que escribimos, en cada informe que diseñamos, en cada interfaz de usuario que construimos, en cada diagrama que hacemos. Cuando otra persona mira nuestro código —o lo que es tan importante, la salida que produce nuestro código— esa persona, conscientemente o no, se hace un juicio de nosotros. Piensa en el código que has escrito hasta ahora... ¿cuál sería ese juicio? ¿Estarías orgulloso, te pondrías en pie y dirías que ese código lo has escrito tu? ¿o solo admitirías tímidamente que es tuyo, y lanzarías excusas de por qué no es lo bueno que debería ser?. Si tu código es malo, alguien que lo lea probablemente asuma que no es el único código que has hecho mal, que no es lo único que haces mal. La buena noticia es esta: tenemos control absoluto sobre la calidad de nuestro código.
La cuestión no es si uno es capaz de escribir el mejor código posible, sino si se preocupará por intentarlo. Si un programador carece de ciertos conocimientos o de cierta experiencia, pero hace lo posible por escribir el código de forma clara, entendible, bien comentada, de forma que muestre que al menos ha invertido tiempo en aprender algunos fundamentos básicos, entonces habrá actuado como debía con diligencia— y eso será obvio para un observador que lea con atención. No es razonable que alguien juzgue mal a un programador porque le falte algo de experiencia o porque desconozca aún algunas técnicas. Sin embargo, es absolutamente razonable encontrar una conexión entre la calidad global del código de un programador y la calidad del carácter de dicho programador.
El Principio del Carácter Personal establece: Escribe tu código de forma que refleje, y saque a relucir, solo lo mejor de tu carácter personal.

El Principio de la Estética
Un aspecto de la programación que con frecuencia descuidamos es la estética. La estética trata sobre la belleza y la elegancia, y de el valor de estas cualidades. Mucha gente, sin embargo, cree que la estética es solo importante cuando se habla de arte y literatura. Pocas personas se dan cuenta de la importancia de la belleza y la elegancia en las cosas cotidianas, y muy pocos programadores se dan cuanta de la importancia de éstas cuando se escribe código. La estética es especialmente importante en el desarrollo de software, un terreno en el que siempre estamos tratando con niveles de abstracción. Los aspectos estéticos de nuestras abstracciones están directamente relacionados con su entendibilidad y, por lo tanto, con su utilidad.
Un programador debe esforzarse en conseguir la belleza, sin importar la herramienta o el lenguaje de programación que esté utilizando. La belleza puede conseguirse a muchos niveles, desde el alto nivel de la elegancia en el diseño del sistema hasta el más bajo nivel de la apariencia visual del código en la pantalla. Ser ordenado y claro cuenta. El mejor código no solo funciona de forma correcta y eficiente, y está bien formado desde el punto de vista del compilador; el mejor código es también agradable de ver por el ojo humano— y por lo tanto más fácil de absorber y de comprender para el cerebro humano.
Steve McConnell escribe en su libro Code Complete, "El disfrute visual e intelectual de un código bien formateado es un placer que pocos no-programadores pueden apreciar. Pero los programadores que se sienten orgullosos de su trabajo experimentan una gran satisfacción artística puliendo la estructura visual de su código." (Página 399)
El Principio de la Estética establece: Esfuérzate por conseguir la belleza y la elegancia en cada aspecto de tu trabajo.

El Principio de la Claridad
La claridad en el código es un estado que debemos buscar activamente. Uno de los mayores delitos que como desarrolladores podemos cometer es olvidar que nuestro código tiene una vida más allá de los pocos momentos que nos lleva escribirlo. Las probabilidad de que alguien, posiblemente nosotros mismos, maneje nuestro código en el futuro son muy altas. Incluso aunque escribamos un código que funciona perfectamente y nunca causa problemas al usuario, estaremos perjudicando a otros compañeros desarrolladores (sin mencionar a nuestra empresa) si no escribimos nuestro código de la forma más clara posible.
Hay una diferencia entre claro y correcto, y muchas veces se confunden. La corrección es siempre el principal interés del desarrollador, como debe ser. La corrección lleva a que la sintaxis del código sea correcta a los ojos del compilador, que el diseño de la interfaz cubra las necesidades del usuario, y que los algoritmos que se implementan cumplan con sus requerimientos. Pero si no se dedica una atención igual a la claridad, la comprensibilidad y la mantenibilidad del código sufrirán mucho. Para que nuestro código sea lo más claro posible, debemos deliberadamente usar técnicas como la utilización de identificadores descriptivos, la modularidad, la indentación (el sangrado), los espacios en blanco, la cohesión del código, el acoplamiento débil del código, propiciar la fácil realización de las pruebas y la documentación, y comentar adecuadamente.

La falta de claridad en nuestro código causa problemas innecesariamente, y también situaciones profesionalmente embarazosas. A nuestros colegas desarrolladores que tienen que tratar con nuestro código en años (o incluso décadas) sucesivos. Y a nuestra empresa, con la que no jugamos limpio devaluándola; incluso en algunos casos nuestro código puede convertirse en un problema de responsabilidad legal para nuestra empresa. Dejar a nuestros colegas en esa situación es como mínimo descortés, pero dejar a nuestra empresa en esa situación es mucho peor: nosotros llegamos al acuerdo de producir código de calidad por un precio. La empresa ha cumplido pagándonos ese precio pero, ¿en qué situación sale ella de este acuerdo con nosotros?

El Principio de la Claridad establece: Dale el mismo valor a la claridad que a la corrección. Utiliza activamente técnicas que mejoran la claridad del código. La corrección vendrá casi por sí sola.

El Principio de la Distribución
Este principio se refiere a la distribución visual del código. El Principio de la Distribución es un corolario a los dos principios anteriores: El Principio de la Estética y El Principio de la Claridad. El Principio de la Estética nos dice que, además del disfrute intelectual que supone la lectura de código bello y elegante, la propia belleza y la elegancia juegan un papel crucial para conseguir dicho buen código. Por otro lado, El Principio de la Claridad nos dice que hagamos nuestro código lo más claro posible a un lector humano, y que la claridad va de la mano con la corrección. El Principio de la Distribución pone estos dos principios duales en práctica.
Es difícil discutir la importancia de la distribución visual del código sin referirnos al principio fundamental de Steve McConnell (Fundamental Theorem of Formating) que establece: "Una buena distribución visual muestra la estructura lógica de un programa." (página 403, Code Complete) Esto significa que la distribución visual no solo sirve para hacer el código visualmente más atractivo, sino que también actúa a nivel del subconsciente haciendo el código más entendible al lector. El objetivo es reducir la cantidad de trabajo que un lector necesita para entender el código. La apariencia visual debe ser nuestra primera herramienta para comunicarnos con claridad con un lector humano que esté leyendo nuestro código.
Hay varias técnicas que aseguran que la distribución visual del código ayude a entender su estructura lógica. Estas técnicas deben formar parte de los conocimientos fundamentales de todo programador: uso adecuado de los espacios en blanco (y líneas en blanco), indentación, agrupamiento de líneas relacionadas, uso de paréntesis extra para que las expresiones lógicas y las fórmulas matemáticas sean más claras, márgenes para alinear el código relacionado de distintas líneas, emplazamiento adecuado de delimitadores de bloque, etc. Como Steve McConnell sugiere en su teorema, la idea es utilizar la distribución visual de nuestro código para comunicar a nivel de subconsciente con el lector. Recuerda que cuando estamos trabajando en el terreno del desarrollo de software, estamos siempre trabajando con abstracciones, y una abstracción es más útil cuanto mas entendible es.
El Principio de la Distribución establece: Usa la distribución visual de tu código para comunicar la estructura de tu código a un lector humano.

El Principio de lo Explícito
Seguir el Principio de lo Explícito nos ahorrará, a nosotros y a nuestros sucesores, innumerables problemas. El Principio de lo Explícito es un corolario de El Principio de la Claridad. Pero el Principio de la Claridad nos dice que hagamos nuestro código de forma clara y entendible para el lector humano. Y el Principio de lo Explícito también se aplica a esa misma entendibilidad, y a lo que es más importante, a hacer nuestro código más tolerante a cambios.
Veamos un ejemplo simple: muchos lenguajes de programación ofrecen el concepto de "fichero". Normalmente el fichero no lo proporciona el lenguaje de programación directamente, sino que se utiliza a través de una librería. Cuando escribimos el código necesario para abrir el fichero, normalmente existen propiedades para determinar el estado del cursor del fichero. Cuando nuestro código llama a la función que abre el fichero, la función probablemente tenga un estado del cursor por defecto, lo cual significa que no tenemos que especificar explícitamente el estado del cursor— simplemente podemos aceptar el estado por defecto.
Si un desarrollador acepta ese estado por defecto, entonces el desarrollador ha introducido una suposición implícita en su código, lo cual, para empezar, reduce la claridad del mismo. Y lo que es mucho peor, ha creado una oportunidad gigantesca para que se den futuros errores. El estado del cursor afecta directamente el comportamiento del fichero. Nuestro código obviamente depende de ese comportamiento. ¿Qué ocurriría con nuestro código seis meses después cuando se actualice la librería de manejo de ficheros?¿Qué ocurre si la nueva versión cambia el estado por defecto del cursor del fichero?¿Sabes lo que va a ocurrir con el código que asumía el estado por defecto del fichero? Simplemente va a fallar por completo. O peor, va a cambiar su comportamiento en algo leve: alguna condición de un IF va a ser Falsa en vez de Verdadera, y el bloque ELSE se va a ejecutar en vez del bloque IF que debería ejecutarse; y entonces, meses después, alguien se dará cuenta de que los datos corruptos y los daños se han extendido por todo el sistema.
Por no haber sido explícito, el desarrollador del código del ejemplo aceptó implícitamente el estado del cursor por defecto, haciendo su código menos tolerante a futuros cambios. Esto es inaceptable. Debemos aprender a detectar donde pueden darse este tipo de problemas (el ejemplo del fichero es uno de muchos, y cada lenguaje de programación y plataforma tiene otros muchos), y debemos usar nuestros conocimientos para que no nos afecten en el futuro. Como profesionales, debemos saber que el cambio es algo constante en nuestra profesión, y debemos hacer lo posible para asegurar que nuestro código soportará fácilmente esos cambios sin producir errores o resultados incorrectos. Incluso cuando nuestro código falla, debemos asegurarnos que lo hace correctamente, es decir, que a pesar de fallar, nos proporciona la mayor cantidad de información específica acerca de dónde y por qué ha fallado.
El truco para que estos problemas no ocurran es ser explícitos. Los problemas merodean por lo implícito— en las suposiciones indocumentadas y no probadas, en las técnicas crípticas, en las secciones indocumentadas explícitamente, en las cuales nos perdemos como un barco hundiéndose silenciosamente en el vasto y opaco océano.
El Principio de lo Explicito establece: Intenta siempre favorecer lo explícito sobre lo implícito.

El Principio del Código Auto-Documentado
El código auto-documentado no se consigue accidentalmente.
Como desarrolladores, debemos esforzarnos en el desarrollo de un estilo de codificación sólido, lo cual es la clave del código auto-documentado. Debemos estar constantemente mejorando y perfeccionando nuestro estilo, de forma que cada programa que escribimos sea mejor que el anterior. Un estilo bien desarrollado se consigue incorporando técnicas probadas, como el uso de identificadores informativos y consistentes; la modularización bien cohesionada y acoplada; evitar el uso de técnicas difíciles de comprender; hacer una buena distribución visual del código; dar nombres adecuados a las constantes; probando y documentando las suposiciones; y muchas otras.
Para aprender estas técnicas debemos leer los textos realizados por otros que nos precedieron, y que abrieron camino. Buscar en la bibliografía clásica. Aprender de los maestros. Suscribirse a revistas. Unirse a listas de discusión de Internet. Leer código y código de otros programadores. Cuando veas código que decepciona estas expectativas, analízalo y trata de ver por qué. Cuando veas código que alcanza el alto nivel que buscamos, trata de identificar las técnicas que el desarrollador usó para alcanzar ese gran nivel. Hay un dicho que dice: cualquier tonto puede aprender de sus propios errores; una persona sabia también aprende de los errores ajenos.
¿Y qué ocurre con los comentarios? ¿Los necesitamos aunque nuestro código esté auto-documentado? Auto-documentar el código, como la perfección, es un objetivo difícil de conseguir, probablemente imposible. Sin embargo, eso no debe detenernos en nuestro empeño. Allí donde esa perfección no se pueda conseguir, debemos suplementar nuestro esfuerzo añadiendo buenos comentarios. El código bien escrito no debe necesitar demasiados comentarios; debe explicarse por si mismo. De todas formas, añadir ciertos comentarios es necesario—solo que deben ser del tipo adecuado (ver El Principio de los Comentarios).
Visto de cerca, el código verdaderamente auto-documentado es un placer de contemplar, y a su observador le queda claro que esa maravilla solo pudo ocurrir mediante el esfuerzo de un ingeniero de software concienzudo y diligente.
El Principio de Código Auto-Documentado establece: La documentación más fiable para el software es el propio código. En muchos casos, el propio código es la única documentación. Por lo tanto, esfuérzate en hacer que tu código sea auto-documentado, y allí donde no sea posible, añade comentarios.

El Principio de los Comentarios
Los comentarios son armas de doble filo. Usados correctamente, pueden mejorar infinitamente la entendibilidad y el mantenimiento del código. Usados de forma indebida, pueden hacerlo confuso y menos legible. Comentar indebidamente es en el mejor de los casos de poca ayuda, y en el peor de los casos un enorme desastre.
El Principio de los Comentarios tiene tres apartados:
Primero, comenta mediante frases completas. Esta simple técnica incrementa en gran medida la comprensión por parte de un lector tanto de los propios comentarios como del código que comentan. Los fragmentos de frases tienden a ser crípticos. Escribir cada comentario mediante una frase completa también hace que lo entiendan más personas, lo cual es muy importante en el entorno multi-cultural en el que nos encontramos hoy día. Los comentarios de alta calidad escritos mediante frases completas también son una ayuda para instruir a desarrolladores con menos experiencia.
Segundo, usa los comentarios para resumir código. El "comentario resumen" describe un bloque de código con la idea de ahorrar a una persona el tiempo que llevaría leer todo el código que el comentario describe. El comentario resumen aparece normalmente unas líneas por encima de un bloque de código. Un buen resumen no repite de nuevo el código, sino que explica diversas líneas de código en dos o tres frases.
Tercero, intenta siempre comentar "a nivel de la intención". Lo que esto quiere decir es que se debe comentar a nivel del problema, más que a nivel de su solución. El código es la solución al problema. Idealmente, el código debería hablar por si mismo (ver El Principio del Código Auto-Documentado). Una persona que lea el código, si el código es bueno, debería entender fácilmente qué hace el código y cómo lo hace. Sin embargo, la información que no permanece en el código es precisamente lo que había en la mente del desarrollador que lo escribió: su intención. En general, esto es lo que necesita estar comentado. ¿Cuál era la intención del desarrollador?¿Con qué intención se ha usado ese código? ¿Cómo intenta este código solucionar el problema en cuestión? ¿Cuál es la idea que hay detrás de ese código? ¿Cómo este código explícitamente se relaciona con las otras partes de código?. Uno de los mayores pecados que un desarrollador puede cometer es abandonar su código sin que su intención quede clara a futuros lectores del código.

El Principio de los Comentarios establece: Comenta mediante frases completas para resumir y comunicar la intención.

El Principio de las Suposiciones
El Principio de las suposiciones es un corolario al Principio de lo Explícito. Hacer comprobaciones y documentar bien las suposiciones hechas en el código tiene varios beneficios: uno, incrementa su comprensión; dos, hace el código más predecible; tres, hace el código más fácil de mantener; cuatro, reduce la necesidad de comentarios; cinco, hace el código más fiable; seis, hace el código más comunicativo cuando algo va mal; siete, la detección temprana mediante comprobaciones protege los datos de que se corrompan ; ocho, obliga que prestemos atención a las suposiciones y comprobaciones que hace una rutina, y por tanto a su relación con otras rutinas y datos compartidos, lo cual reduce la incidencia de errores.
Las comprobaciones son la piedra angular de la programación defensiva. En realidad en cada pieza de código hacemos suposiciones. Lo que ocurre es que algunas son obvias y no es necesario que se comprueben ni se documenten. Sin embargo, podemos y debemos comprobar (y documentar) las muchas otras suposiciones que son menos evidentes.
El tipo de suposiciones más común que deben ser comprobadas (y documentadas), son los pre-requisitos en los que una rutina se basa. Estas comprobaciones normalmente son una serie de sentencias If...Then al principio de la rutina. Si alguna de las comprobaciones falla, entonces el código debe ejecutar una acción que corrija la situación, o bien devolver un mensaje de error explicando que una de las suposiciones falló. (Otra forma de hacer comprobaciones de las suposiciones, a veces pasada por alto, es el uso de asertos, que son expresiones Verdadero/Falso que normalmente sólo se compilan en versiones de "depuración" del programa para su prueba.)
El Principio de las Suposiciones establece: Da los pasos que sean razonables para comprobar, documentar y prestar atención a las suposiciones hechas en cada módulo y rutina.

El Principio de la Interfaz con el Usuario
La formulación de esta regla está tomada prestada de About Face: The essentials of User Interface Design, escrito por el gurú del diseño de interfaces de usuario: Alan Cooper. Cooper abunda en esta idea en su posterior libro, The Inmates are Running the Asylum : "La mayoría del software se usa en entornos de trabajo, donde las víctimas de los malos interfaces de usuario son los trabajadores. Sus trabajos les obligan a usar el software, ellos no pueden elegir no usarlo—deben tolerarlo lo mejor que puedan. Están obligados a aguantarse su frustración y a ignorar la vergüenza que sienten porque el software les hace sentirse estúpidos".(Página 34) Esta es una afirmación que debe hacer que nos paremos a considerar el impacto real, bueno o malo, que nuestro software tiene en la gente.
¿Cómo llega un usuario a sentirse estúpido?. Alan Cooper ha dedicado dos libros enteros a responder a esta pregunta, y otros autores se han enfrentado también a este tema (incluyendo a Donald Norman en su excelente libro, The Design of Everyday Things.) Obviamente, aquí no podemos extendernos tanto. Pero de todas formas, aquí va un ejemplo sencillo: un usuario hace click en un botón e inmediatamente le sale un mensaje que que dice: "No puede usar esa función en este momento". ¿Entonces por qué estaba el botón habilitado para ser pulsado? El desarrollador, por no tomarse la molestia tan sencilla de deshabilitar o bien ocultar el botón, ha creado una situación en la que él o ella es como un bromista que señala una falsa mancha en la camisa del pobre usuario y le da en la cara cuando éste mira hacia abajo. Muy divertido.
El mal diseño de la interfaz de usuario es un enorme problema que afecta a toda la industria del hardware y del software. Es triste comprobar como desarrolladores tanto de hardware como de software regularmente diseñan soluciones que terminan haciendo que los usuarios se sientan estúpidos. Es incluso más triste que muchos desarrolladores sean felices en su ignorancia de desconocer el estrés que causan a la gente. Sin embargo, como desarrolladores estamos en la posición de ayudar a resolver este problema.
Como desarrolladores software, nuestra principal responsabilidad en cuanto a la interacción con el usuario descansa en el diseño de la interfaz de usuario. Afrontémoslo: en la mayoría de los casos no hay un diseño de la interfaz de usuario preparado con antelación. La mayoría de las decisiones de diseño de la interfaz de usuario (y esto incluye el diseño de los informes que genera el software) son tomadas por el desarrollador mientras se construye. Por lo tanto, en la mayoría de los casos, es solo responsabilidad del desarrollador tomar los pasos necesario para no hacer que el usuario se sienta estúpido. El desarrollador es el que sitúa los botones y los campos. El desarrollador, por tanto, tiene casi control total de la experiencia que vive el usuario delante del software.
El Principio de la Interfaz con el Usuario establece:Nunca hagas que el usuario se sienta estúpido.
El Principio de Volver Atrás
Todos hemos sido culpables alguna vez de esto: "No tengo tiempo de hacer eso ahora. Ya volveré y lo haré luego". Este tipo de decisiones suelen aplicarse a tareas como comentar el código, su adecuada distribución visual, el control de errores, la modularización adecuada, la correcta implementación, etc. Quizás tu seas esa persona, rara, que siempre vuelve más tarde a ese código y hace todo ese trabajo tedioso, pero la mayoría de nosotros los mortales nunca lo hacemos.
El momento de hacer todas esas tediosas tareas asociadas a la codificación es el preciso momento en el que se está escribiendo el código. La principal razón por la que nadie vuelve más tarde a "limpiar" su código es que una tarea que es tediosa de realizar mientras escribes el código, es monumentalmente más tediosa cuando tienes que volver atrás y hacerla después. ¿Alguien cree de verdad que volver y codificar buenas comprobaciones de errores en cientos de rutinas a posteriori es menos tedioso que crear esas rutinas con sus comprobaciones de errores desde el principio? No solo odiarás cada minuto de esa tarea, sino que casi con toda probabilidad introducirás errores que no estaban allí antes.
En el caso de los comentarios, los comentarios que añadas después nunca serán tan buenos como los comentarios que podrías haber escrito justo en el momento en que escribiste el código. ¿Y qué ocurre si tienes que dejar un trabajo antes de tener la oportunidad de volver atrás y hacer todas esas tareas? Habrás dejado esa tediosa y mucho más monumental tarea a otro, lo cual es muy poco profesional.
El Principio de Volver Atrás establece: El momento de escribir buen código es justamente el preciso momento en el que lo estás escribiendo.
El Principio de El Tiempo y El Dinero de Otros
El Principio de El Tiempo y El Dinero de Otros se aplica a todo el trabajo que realiza un desarrollador: código, informes, interfaces de usuario, modelos, diagramas, pruebas, y documentación. Esta regla no solo se aplica al código, sino a la profesionalidad. Recuerda la regla con la que empezamos: El Principio del Carácter Personal establece: Escribe tu código de forma que refleje, y saque a relucir, solo lo mejor de tu carácter personal. El Principio de El Tiempo y El Dinero de Otros es una forma menos cordial de decir lo mismo.
Enorgullécete de tu trabajo, porque tu trabajo eres tú, y te juzgarán por el trabajo que has hecho—y a veces sólo por eso. Incluso si no te preocupa que te juzguen, ¿Te preocupa hacer las cosas bien hechas? ¿Te sientes bien habiendo aceptado dinero por ese código? ¿Te preocupa como tú y tu trabajo se refleja en la profesión de ingeniería del software en general? Escribir código para alguien no es un tan solo un juego divertido, la calidad del trabajo de cada desarrollador se refleja en todos los demás desarrolladores.
El Principio de El Tiempo y El Dinero de Otros establece: Un verdadero profesional no gasta el tiempo ni el dinero de otras personas produciendo software que no esté razonablemente libre de fallos; que no esté mínimamente probado; que no cumpla con los requisitos establecidos; que esté falsamente adornado con características innecesarias; o que tenga un aspecto deplorable.

Fracmentos de códigos en Matlab

Hola amigos, disculpen, no he tenido tiempo para actulizar mi Blog, en esta ocasión les traigo algunos códigos para empesar a programar en Matlab, para los que no conocen, voy a definir sobre este lenguaje de programación para uso cientifíco, espero que la disfruten.

The MATLAB and Simulink product families are fundamental computational tools at the world's educational institutions. Adopted by more than 3500 universities and colleges, MathWorks products accelerate the pace of learning, teaching, and research in engineering and science. MathWorks products also help prepare students for careers in industry, where the tools are widely used for research and development. más información, http://www.mathworks.com/

Para mejor la defición un poco de información en Español..

MATLAB (abreviatura de MATrix LABoratory, "laboratorio de matrices") es un software matemático que ofrece un entorno de desarrollo integrado (IDE) con un lenguaje de programación propio (lenguaje M). Está disponible para las plataformas Unix, Windows y Apple Mac OS X.

Entre sus prestaciones básicas se hallan: la manipulación de matrices, la representación de datos y funciones, la implementación de algoritmos, la creación de interfaces de usuario (GUI) y la comunicación con programas en otros lenguajes y con otros dispositivos hardware. El paquete MATLAB dispone de dos herramientas adicionales que expanden sus prestaciones, a saber, Simulink (plataforma de simulación multidominio) y GUIDE (editor de interfaces de usuario - GUI). Además, se pueden ampliar las capacidades de MATLAB con las cajas de herramientas (toolboxes); y las de Simulink con los paquetes de bloques (blocksets).

Es un software muy usado en universidades y centros de investigación y desarrollo. En los últimos años ha aumentado el número de prestaciones, como la de programar directamente procesadores digitales de señal o crear código VHDL.

Tipos de secuencia

Este código que presento, es funcional son tipos de secuencias que se declaran para utiilzar al programar.

function [x,n]= impseq (n0,n1,n2)

n=[n1:n2]; x= [(n-n0)== 0];

function [x,n]= stepseq (n0,n1,n2)

n = [n1:n2]; x=[(n-n0) >= 0];

function [y,n]= sigadd (x1, n1, x2, n2)

n = min(min (n1), min(n2)): max(max(n1); max(2));

y1= zeros (1,length(n));y2=y1;

y1(find ((n>=min(n1))& (n<=max(n1))== 1)=x1;

y2(find ((n>=min(n2))& (n<=max(n2))==1)=x2;

y=y1+y2;

function [y,n]= sigmult(x1, n1, x2, n2)

n = min(min (n1), min(n2)): max(max(n1); max(2));

y1= zeros (1,length(n));y2=y1;

y1(find ((n>=min(n1))& (n<=max(n1))== 1)=x1;

y2(find ((n>=min(n2))& (n<=max(n2))==1)=x2;

y=y1.* y2;

function [y,n]= sigshif(x, m,n0)

n = m+n0; y=x;

function [y,n]= sigfold(x,n)

n = fliplr(x); n= - fliplrm(n);

Hecho estas secuencias, ahora presentamos algunos ejemplos, dentro de las secuencias de nuestra aplicación.

Nuestra ecución se plantea de la siguiente manera

x(n)=2&(n+2)-&(n-4), -5<-n<-5.

Soluci[on

n=[-5:5];
x = 2*impseq (-2,-5,5)-impseq(4,-5,5);
stem (n,x); title ('Sequence in problem 2.1a')
xlabel ('n'); ylabel('x(n)');