jueves, 18 de julio de 2013

ITEMS DE STOCK
Los items de un stock deben poder identificarse a a partir de: clasificaciones alfanuméricas del ámbito del tipo negocio , identificacion que usa el proveedor , identificacion numérica generada por el propio sistema.(los tres simultaneamente)
Así podremos por ejemplo utilizar los códigos de barra o generar los propios para uso interno, organizar las vistas con criterios habituales
las clasificaciones alfanumericas sirven en casos de item de pequeño valor  ej:ropa , calzado , algunos electrodomésticos
Los items se organizan por rubros y marcas , o por rubros familias y marcas (para tiendas)
Puede usarse el criterio de talle para identificar mas detalladamente
Ej: 
rubro=calzado
familia=deportivo americano
marca=topper
talle=40
Cada clase identificada de esta forma tiene un numero interno que a la vez sirve como identificador
ej 1254 para calzado,deportivoeamericano,topper

Para mercaderia valiosa y/o con granatías deberá ser posible (además) identificar cada elemento mediante un numero de serie que puede ser el que le asigna el proveedor o generado internamente
El programa deberá ser capaz de generar el seguimiento de cada elemento

miércoles, 17 de julio de 2013

Extraido deDr.Dobb's

Consejo a un programador nuevo
Por Andrew Binstock , 16 de julio 2013   dr.dobb's



Así que muchos consejos se amontona en los principiantes que puede ser difícil saber por dónde empezar. Sin embargo, estas cinco prácticas son la base sobre la cual todo lo demás se construye.
Cada pocos meses, reciben la petición de un nuevo programador que, con diligencia encomiable, quiere saber la mejor manera de convertirse en un buen programador. También veo mucho esta pregunta en los foros de programadores, que es una tendencia alentadora. Las respuestas más reflexivos tienden a seguir en canales similares a mis pensamientos sobre el tema, lo que sugiere que efectivamente existe un cierto acuerdo de base sobre las mejores prácticas fundamentales. Me apresuro a añadir, por tanto, que estos consejos no son originales, pero tal vez el color agrego proporcionará información adicional.
El principiante que tengo en mente tiene una comprensión básica de cómo funciona la programación, ha escrito en su mayoría pequeños programas de diversa complejidad, y se dirige fuera ya sea a una carrera en el campo o el compromiso con la excelencia de su personal o de proyectos propios.

Sólo hay una verdadera actividad fundamental en la programación: la escritura de código. Para ser bueno en ello, vas a tener que escribir mucho código. Esa gran cuerpo de trabajo puede ser un vehículo para el crecimiento, o un ejercicio en la práctica repetida de un conjunto limitado de habilidades. Para evitar esto último, es necesario:

Leer mucho código . Específicamente, leer una gran cantidad de código de excelentes programadores. No sólo los buenos programadores, como el hombre en el pasillo, pero excelentes. Debido a la gran cantidad de software libre hoy en día, esto es fácil de hacer. Cuando yo estaba aprendiendo Java, leí código del proyecto Tomcat y el servidor CI, Control de velocidad. He leído un montón de buen código desde entonces.

Podría ser tentador buscar main () y comenzar desde allí, pero es muy probable que pasar mucho tiempo leyendo el código de configuración y análisis de la línea de comandos. Prefiero analizar los nombres de archivo a buscar alguna actividad que me interesa y luego cavar en esos archivos. No es crucial para entender la totalidad del proyecto o de las entradas y salidas de todo el diseño, que usará a ti mismo haciendo esto. Lea el código. Mira los comentarios, ver lo que los autores están haciendo, y cómo se fueron al respecto.

Conozca sus herramientas bien . Creo que la mayor pérdida de tiempo de programación no está en la depuración o reescribir el código, sino en las innumerables segundo perdido aquí y allá por los desarrolladores que realmente no conocen a sus herramientas. Me refiero a: el IDE, el idioma, el sistema de construcción, y el VCS. De éstos, el IDE y el lenguaje son, con mucho el más importante. Usted debe, después de algunas semanas de práctica, conocer casi todos los combo de teclas en el IDE, por lo que se toca el ratón sólo cuando se ahorra una gran cantidad de pulsaciones de teclas. Si conoces a los golpes de teclado, ya sabes los comandos. Si utiliza el ratón sólo, ya sabes sólo menús en los que tienden a hacer clic en el mismo una o dos entradas. Conocer el IDE es la disciplina pura.

Saber grandes idiomas, como Java o C + +, tiene más de disciplina. Son enormes, como lo son sus bibliotecas. La lectura es el mejor enfoque, en mi opinión. Leer el código que utiliza características que no conoces y te busca oportunidades para usarlos. Libros (en lugar de blogs) son otra fuente excelente. Lea acerca de las características que se encuentran en la periferia de lo que se utiliza actualmente, y pronto encontrarás la periferia en expansión. Conocer los sistemas de control de versiones y la construcción hacen que un miembro del equipo deseable - que no pierde el tiempo debido a la ignorancia de las operaciones importantes.

Planifique su código antes de escribirlo. Creo que esto es lo más difícil en esta lista. En cambio, es probable que brinda el mayor beneficio. No estoy pensando en diseño formal - en el escenario, que es poco probable que sea necesario. Pero usted tiene que planificar el código de alguna manera que no sea lo lleva todo en su cabeza. La forma más sencilla es redactar un documento pequeño (Suelo utilizar un mapa mental ): ¿Cuáles son los requisitos de este código? ¿Cómo va a ponerlo en práctica? ¿Qué necesito saber que no sé ahora? ¿Cuáles son los objetos que necesitaré o la necesidad de crear? Y escribir esto. A continuación aplicar el código, encontrará el código mucho más fácil escribir, documentar, y para conseguir la correcta. Guarde sus notas - son un gran material de referencia.

Escribe un montón de código y lo han revisado. Si su sitio no hace las revisiones de código, ellos lo hacen a ti mismo. Encontrar el mejor programador que te dará consejos útiles de una manera que puede ser escuchado y comprendido. No sea una plaga, pero no evita el proceso porque usted es tímido, ocupado, o siente que eres lo suficientemente bueno, etc revisiones de los códigos deben ser parte de su vida la programación. Sea creativo. Pruebe la programación en parejas con alguien de mayor jerarquía de lo que por la tarde. Lo importante es que se necesita información que no se puede dar a sí mismo.

Escribe pruebas cuando escribe código . Este consejo es quizás el único elemento controvertido aquí. No es una recomendación de TDD. Pero es un aval de saber que su código funciona en la mayoría de los escenarios que se enfrentará. Comience con las pruebas unitarias y ejercer nuevo código con los valores de borde de casos. Por ejemplo, ¿el trabajo de su función si se pasa un valor negativo, o el tamaño máximo número entero? Si no, no se produce una excepción informativa o simplemente volar? Si no es una excepción, ¿ha reducido la variedad de entradas con asevera? Si es así, pruebe la afirma. Utilice la planificación que hiciste antes de escribir se burla y, a continuación, empezar a probar el nuevo código con objetos que todavía tienen que escribir. Esto aclarará los problemas de diseño en el código actual y las próximas objetos. Guardar tus pruebas y ejecutarlas antes de cada registro, de modo que puedan ser los sistemas de alerta temprana para el código más tarde que rompe el código actual.

Hay muchos más consejos y muchos dichos sabios que se puede agregar a esta lista. Pero eso es parte del problema: Hay tantos consejos disponibles que es difícil saber exactamente por dónde empezar. Por esa razón, a propósito limito mis recomendaciones a sólo cinco puntos. Si se las aplica con diligencia, pronto encontrará dos cosas: Usted será capaz de manejar las tareas cada vez más grandes y más importantes, y mirarás hacia atrás con vergüenza en código que escribiste hace apenas unos meses.

Ambas experiencias son signos claros de progreso. ¡Buena suerte!

- Andrew Binstock