Mostrando entradas con la etiqueta Programacion. Mostrar todas las entradas
Mostrando entradas con la etiqueta Programacion. Mostrar todas las entradas

jueves, septiembre 19, 2013

Crear un Exe con VFP8 en Adelante.



*!* Para ejecutar el VFP8 portable.
foxcode.exe
MSVCR70.DLL
FOXCODE.FPT
FOXCODE.DBF
vfp8.exe
VFP8ESN.DLL

*!* Para ejecutar el exe de tu aplicación (RunTime) sin usar el VFP8
MSVCR70.DLL
vfp8r.dll
VFP8RENU.DLL

 -- VFP8 Runtime Files --
http://fox.wikis.com/wc.dll?Wiki VFP8RuntimeFiles


*-- Genero el PRG, PJX y EXE

BUILD PROJECT Ejemplo.pjx FROM Ejemplo.prg
BUILD EXE Ejemplo.EXE FROM Ejemplo.pjx 

lunes, agosto 19, 2013

Los 10 errores más comunes en las empresas


 Secretaría de Comercio identificó los 10 errores más comunes en la micro y pequeña empresa.

Se los explico y ustedes analicen su empresa para que se vayan calificando con palomita y digan: cumplo, cumplo, cump... ah caray, ¡ahí me falta!, cumplo y cumplo.

1.- Falta de misión y visión
La Misión expone el ¿POR QUÉ? de la existencia de la organización.
Responde ¿quiénes somos?, ¿para qué existimos?, ¿qué hacemos?, ¿para quién trabajamos?, ¿cuáles son nuestros valores?
Todas las decisiones estratégicas surgen a partir de la misión.
La Visión consiste en una declaración formal de lo que la empresa trata de lograr. La descripción minuciosa de este elemento ayuda a guiar la formulación de estrategias.

2.- Desconocimiento de la matriz FODA
Fortalezas. La carta de presentación, es todo aquello que la empresa puede hacer bien. Habilidades, capacidades, recursos valiosos o logros. Cualquier característica que le dé una posición favorable o ventaja competitiva en el mercado.
Oportunidades. Aquellas áreas que están descuidadas, potencial desaprovechado que ofrece importantes vías de crecimiento y desarrollo.
Debilidades. Cualquier actividad que provoque una posición desfavorable para la empresa.
Amenazas. Factores del ambiente externo de una empresa que pueden afectar su bienestar y crecimiento.
Ambiente interno de la empresa: fortalezas y debilidades.
Ambiente externo de la empresa: oportunidades y amenazas.

3.- Estructura organizacional deficiente
Falta de organización ordenada, funcional, jerárquica y responsable.

4.- Centralización del poder
La mayor parte de las empresas son familiares, priorizan intereses personales y sentimentales.

5.- Carencia de establecimiento de objetivos
El empresario se forma mentalmente cuál es el objetivo de su empresa, sin embargo no lo establece de manera escrita ni formal por lo que el personal que colabora con él no los conoce y por lo tanto las actividades que realiza muchas veces no se encaminan a la consecución del objetivo.

6.- Falta de evaluación y seguimiento
La mayoría de las empresas carecen de sistemas de evaluación de desempeño del personal. Cuando se establecen políticas en las empresas no se supervisan que ésta sea cumplida por el personal, incluso el primero en romper las políticas de procedimientos es el dueño del negocio, lo cual trae como consecuencia que el personal minimice la importancia de las mismas.

7.- Comunicación deficiente
El no tener definidas las líneas de autoridad genera una comunicación deficiente entre los miembros de la organización ya que estos no saben con certeza a quién acudir o no se generan vínculos de confianza para que se puedan comunicar los problemas que surjan en la operación cotidiana del negocio.

Recomendación: la comunicación debe ser escrita y firmada, teniendo así respuesta efectiva y eficiente.

8.- Falta de controles administrativos
Los empresarios en su mayoría desconocen la situación financiera exacta de su negocio, debido a que no llevan los controles ni registros necesarios para conocer sus ingresos, egresos, rotación de inventarios, porcentaje de ventas a crédito etc.
La contabilidad sólo se utiliza con fines fiscales y no para la toma de decisiones de las empresas.

Recomendación: El dueño debe fijarse un "salario del mercado" por ejemplo $20,000 y sobre ese salario fijar su nivel de vida. De ahí debe pagar sus viajes, compras personales, etc., y no tomar más dinero de la empresa para su uso personal.

9.- Desinterés por los aspectos jurídicos - corporativos
Tomando en consideración que la mayoría de las empresas son familiares se les da poca importancia a los aspectos jurídico-corporativos de los negocios ya que se cree que el único requisito que se debe cumplir es concurrir al notario para estar legalmente como sociedad.

10.- Utilizar un estilo de administración reactiva y no preventiva
No perder de vista aspectos de planeación, organización, dirección y control. Para esto deben agruparse en áreas las diversas actividades que se llevan a cabo como: ventas, servicio, personal, finanzas.
Identificando lo que se hace en cada una con la finalidad de delegar autoridad y responsabilidad.

Mitos del software


Ahora en la actualidad, la mayoría de profesionales de la ingeniería de software reconocen los mitos como lo que son: actitudes equivocadas que han ocasionado serios problemas a los administradores y a los trabajadores por igual. sin embargo, las actitudes y hábitos antiguos son dificíles de modificar, y persisten algunos remanentes de los mitos del software.

A continuación voy a listar los mitos más comunes del Software:

  • Mitos de la administración. Los gerentes que tienen responsabilidades en el area del software, como también otras disciplinas, con frecuencia se hallan bajo presión para cumplir el presupuesto.
  • Mito: Tenemos un libro lleno de estándares y procedimientos para elaborar software. ¿no le dará a mi personal todo lo que necesita saber?
  • Realidad: Tal vez exista el libro de estándares, pero ¿se utiliza? ¿saben de su existencia los trabajadores del software? ¿refleja la práctica moderna de la ingeniería de software? ¿es completo? ¿es adaptable? en muchos casos las respuestas a estas preguntas es: no.
  1. Mito: Si nos atrasamos, podemos agregar más programadores  y ponernos al corriente.
  • Realidad: El desarrollo del software no es un proceso mecánico similar a la manufactura. en palabras de Brooks: "agragar personal a un proyecto de software atrasado lo atrasará más". a inicio, esta afirmación parece ir contra la intuición. sin embargo, a medida que se agregan personas, las que ya se encontraban trabajando deben dedicar tiempo enseñando a los recién llegados.
  • Mito: Si decido subcontratar el proyecto de software a un tercero, puedo descansar y dejar que esa compañia lo elabore.
  • Realidad: Si una organización no comprende cómo administrar y controlar proyectos de software internamente, de manera invariable tendrá dificultades cuando subcontrate proyectos de software.
  • Mitos del cliente. El cliente que requiere software de computadora puede ser la persona en el escritorio de al lado, un grupo técnico en el piso inferior, el departamento de mercadotecnia por ejemplo. En muchos casos, el cliente sostiene mitos sobre el software porque los gerentes o prefesionales de éste hacen poco para corregir la mala información. Los mitos generan falsas espectativas (por parte del cliente) y, en la última instancia, la insatisfacción con el desarrollador.
  • Mito: para comenzar a escribir programas, es suficiente el enunciado general de los objetivos.
  • Realidad: Aunque no es posible tener el enunciado axhaustivo y estable de los requerimientos, un "planteamiento de objetivos" ambiguo es una receta para el desastre. Los requerimientos no son ambiguos (por que por lo general se obtienen de forma iterativa) se desarrollan sólo por medio de una comunicación eficaz y continuan entre el cliente y el desarrollador.
  • Mito: Los requerimientos del software cambian continuamente, pero el cambio se asimila con facilidad debido a que el software es flexible.
  • Realidad: Es verdad que los requerimientos del software cambian, pero el efecto que los cambios tienen varían según la época en la que se introducen. cuando se solicitan al principio cambios en los requerimientos (antes de que haya comenzado el diseño o elaboración de código), el efecto sobre el costo es relativamente pequeño. Sin embargo, conforme pasa el tiempo, el costo aumenta con rapidez: los recursos ya se han comprometido, se ha establecido la estructura del diseño y el cambio ocasiona perturbaciones que exigen recursos adicionales y modificaciones importantes en el diseño.

miércoles, agosto 07, 2013

Recomendaciones para trabajar en la computadora

 
Uno de los temas con los que mas dedicación debemos tener es todo lo relacionado con nuestra salud y como aquí hablamos de computadores, entonces vamos a hacer referencia específicamente a algunas recomendaciones para trabajar en la computadora sin poner en riesgo nuestra salud, las cuales espero que todos pongamos en práctica de ahora en adelante.

En el blog hemos enfatizado ya varias veces en los temas de salud respecto a la computadora, por ejemplo en un articulo anterior abordamos las principales enfermedades asociadas al uso de los computadores, en el cual explicamos a que nos podemos enfrentar si no tenemos cuidado al trabajar constantemente en el PC.
El día de hoy vamos a tomar como base una interesante infografía que encontré en Internet y vamos a tomar en cuenta algunos consejos que pueden ayudarnos a evitar problemas de salud cuando trabajamos mucho tiempo frente a un computador, así que tomen nota.

Consejos para evitar la fatiga ocular

Consejos para evitar el cansancio físico

  • Levantarse de la silla cada 30 minutos y mover el cuerpo en forma circular (cuello, muñecas, tobillos y hombros).
  • Sentarse de forma adecuada frente al computador. Se recomienda que las rodillas estén por debajo de la cadera, los ojos directamente a la pantalla y los pies en el piso delante de la silla.

Consejos para evitar el túnel carpiano

  • Extender los brazos, apretar los pulgares con los otros dedos y mover las muñecas hacia arriba y hacia abajo
  • Extender los brazos con los dedos abiertos apuntando hacia abajo, apoyar las manos sobre la pared y presionar durante 10 segundos
  • Extender los brazos, abrir las manos y estirar por 10 segundos. Luego cerrar los puños y mover las muñecas hacia arriba y hacia abajo
  • Tener en cuenta esta guía de ejercicios para prevenir el síndrome del túnel carpiano
Espero que estos pequeños consejos sean de gran utilidad y recuerden que la salud siempre esta primero. Les dejo la infografía completa para que la compartan.
Recomendaciones para trabajar en la computadora

martes, junio 11, 2013

10 preguntas a los mas reconocidos programadores del mundo

Estas son 10 preguntas que un blogger hizo y se las envio a varios de los mas grandes programadores, entre los cuales se encuentra uno que todos los lectores de este blog(paraisolinux.com) deberian conocer.
La sorpresa fue grata cuando empezaron a responder y al final quedo una lista de 10 preguntas a 9 grandes programadores. Algunas muy curiosas como el tipo de musica que les gusta y otras muy interesantes como el rol de la universidad en su desarrollo personal.
Lista de los 9 programadores que respondieron:
  • Linus Torvalds - Creador de Linux y GIT, no necesita presentación.
  • Dave Thomas - Autor de “El programador pragmático”, “Programación en Ruby” y otros grandes libros de programación.
  • David Heinemeier Hansson - Creador de Rails Framework(framework web), escritor y conductor de autos de carreras. Autor del weblog Loud Thinking.
  • Steve Yegge - Uno de los menos conocidos del grupo, pero que tiene respuestas muy interesantes. Programador y blogger. Tiene unas 2 decadas de experiencia en esta industria.
  • Peter Norvig - Director de Investigación en Google, autor de varios libros importantes de inteligencia artificial. Pueden visitar su página principal.
  • Guido Van Rossum - Creador del lenguaje Python.
  • Bjarne Stroustrup - Creador de C++. Pueden visitar su página principal.
  • James Gosling - Creador del lenguaje Java.
  • Tim Bray - Uno de los autores de la especificación de XML y Atom. Publica en su blog ongoing.
Prepare esta imagen por si alguna vez se los cruzan 
10 preguntas a los mas reconocidos programadores del mundo
A continuacion las 10 preguntas y sus respuestas:

1 - ¿Cómo aprendió a programar? ¿Las escuelas le resultaron de alguna utilidad? ¿O acaso ni siquiera se molestó en terminar la escuela? :)

  • Steve Yegge: Aprendí por mi cuenta a programar en una calculadora HP usando el lenguaje de pila de notación polaca inversa (RPN) cuando tenía 17 años. Había intentado aprender a programar antes, pero nunca terminaba de “captar” el concepto. Las calculadoras científicas HP 28c y 48g eran bastante poderosas y tenian excelente documentación. Escribí un visualizador de mallas 3D para la 48g – tenía un libro de gráficos 3D y muy laboriosamente logré traducir un ejemplo desde Pascal al lenguaje de pila RPN. Fue muy inspirador verlo funcionar. Luego compré una PC y Turbo Pascal, y comencé a estudiar programación con ganas. Ya programaba bastante bien cuando ingresé a la universidad para el curso de Ciencias de la Computación.Fui a la Universidad de Washington y conseguí un título terciario en Ciencias de la Computación. Definitivamente valió la apena, y le recomiendo a todos los programadores que consigan un título en sistemas si pueden.
  • Linus Torvalds: No aprendí a programar en la escuela, sino por mi cuenta leyendo libros y practicando (inicialmente en una Commodore VIC-20, más tarde en una Sinclair QL).Dicho esto, creo que en especial la Universidad me resultó muy útil. En vez de ir a una universidad de ingeniería, fui a la Universidad de Helsinki, que es bastante teórica, así que la enseñanza no se centra mucho en la programación (que era una pequeña parte, y de todas formas terminé haciendolo “por otro lado”), sino que la mayoría de los cursos se enfocaban en los conceptos fundamentales y en cosas como análisis de complejidad.Si bien puede parecer aburrido e incluso una pérdida de tiempo, creo que fue útil y lo disfruté la mayor parte del tiempo. Y probablemente soy un mejor programador gracias a eso.
  • David Heinemeier Hansson: Aprendí a programar al crear mi primer página web en HTML. Después quise crear algunas partes dinámicas y elegí primero ASP, luego PHP. Luego de que aprendí a programar, comencé a estudiar a la vez una carrera de Ciencias de la Computación y Administración de Empresas.
  • Peter Norvig: Hice cursos en la secundaria y en la universidad, pero siempre sentí que aprendí más por mi cuenta.
  • Dave Thomas: Durante la secundaria tomé clases sobre computación. Me enganchó totalmente: me enamoré de la programación, y busqué universidades que dieran cursos de software. Eventualmente fui al Imperial College, parte de la Universidad de Londres. Era el segundo año que ofrecian un curso en software, y fue absolutamente maravilloso: el plantel y los estudiantes trabajaban juntos para hacer que los materiales resulten mejor, y todos aprendiamos un montón. Este curso me dio una excelente base para el desarrollo de software. Me quedé para comenzar un PhD, pero luego lo dejé por un proycto.Pero la pregunta general es “¿cómo aprendí a programar?”. La respuesta real es que “todavía estoy aprendiendo a programar”. Creo que cualquier buen desarrollador sigue aprendiendo toda su carrera. No es sólo agarrar un lenguaje nuevo y sus librerías: los buenos programadores también refinan sus técnicas y prácticas durante los años.
  • Guido Van Rossum: Fui a la universidad donde tenían un enorme mainframe y había varios cursos de computación. Fue muy importante para mi.
  • James Gosling: Al principio aprendí por mi cuenta. Conseguí mi primer trabajo como programador antes de ir a la universidad. Pero estoy contento de haberlo hecho, me divertí un montón. Después seguí adelante hasta obtener un PhD.
  • Bjarne Stroustrup: En la universidad (Aarhus y luego Cambridge). Las universidades me enseñaron muchas cosas útiles, incluso la mayoría de las bases que sería mi trabajo futuro. Además, aprendí bastante programando por dinero – donde comprender el problema real, mantenibilidad, entrega a tiempo, etc. son temas más importantes que en un entorno educacional.
  • Tim Bray: Pensaba que iba a ser maestro de matemáticas. El programa de matemáticas en la Universidad requería algunos cursos de computación.

2 – ¿Cuál cree que es la habilidad más importante que debería tener un programador?

  • Steve Yegge: Habilidades para comunicarse en forma escrita y verbal. Nunca vas a llegar muy lejos como programador si no podés transmitir tus ideas a otras personas de manera efectiva. Los programadores deben leer asiduamente, practicar escritura, tomar cursos de escritura, e incluso practicar el hablar en público.
  • Linus Torvalds: Es una cosa llamada “gusto”. Suelo juzgar a las personas que trabajan conmigo no por su aptitud: algunas personas pueden escribir mucho código, sino más bien por cómo reaccionan al código de otras personas, y luego obviamente viendo cómo se ve el código que ellos mismos escriben, y que enfoquen toman. Esto me dice si tienen “buen gusto” o no, y la cosa es, una persona sin “buen gusto” en general no es buena para juzgar el código de otras personas, y su propio código termina siendo no del todo bueno.Pero bueno, no es lo único. Una cosa que es muy útil, especialmente en proyectos de código abierto, es la habilidad de comunicar bien lo que se quiere hacer, y cómo se va a hacer. La habilidad de explicar a otros porqué hacés algo de determinada manera es muy importante, y no todos tienen esta habilidad.Dicho esto, también hay personas que simplemente generan buen código. No son buenas explicándolo, e incluso puede que no tengan buen gusto, pero el código funciona. A veces necesitás a otra persona (una que si tenga ese “buen gusto” tan dificil de definir) para masajear el código y que resulte útil en forma más amplia, pero tan solo la habilidad de escribir código claro para problemas dificiles es obviamente una parte bastante fundamental de cualquier programador.
  • David Heinemeier Hansson: Un sentido fuerte del valor. La habilidad para preguntarse a uno mismo: ¿vale la pena hacer esto ahora mismo? Muchos programadores parecen derrochar océanos de tiempo en cosas que simplemente no importan. Y no dedican el tiempo suficiente a cosas que si importan.
  • Peter Norvig: No creo que sea una sola, pero digamos concentración.
  • Dave Thomas: Pasión.
  • Guido Van Rossum: Las pregunta son bastante generales y dificiles de responder Creo que tener la habilidad de cocinarse un huevo para el desayuno es invaluable.
  • James Gosling: Auto motivarse. Para ser realmente bueno, tenés que estar enamorado de lo que hacés.
  • Bjarne Stroustrup: La habilidad de pensar con claridad: un programador tiene que comprender los problemas y expresar soluciones.
  • Tim Bray: La habilidad de preferir la evidencia a la intuición.

3 – ¿Cree que las matemáticas o la física son un conocimiento importante para un programador? ¿Por qué?

  • Steve Yegge: Hay una gran rama de la matemática que es muy importante para los programadores, llamada “matemática discreta” o “matemática concreta”. Incluye disciplinas como la probabilidad, combinatorias, teoría de grafos, pruebas por inducción, y otras herramientas útiles. Aliento a todos los programadores a que estudien matemática discreta todo lo que puedan. Incluso un poquito es mejor que nada.En cuanto a la matemática tradicional, bueno, no la uso tan a menudo, pero siempre resulta útil cuando la necesito. Por ejemplo, sólo usé cálculo matemático una vez durante el año pasado como parte de mi trabajo. Tenía que estimar la carga en la hora pico del día para un servicio cuya carga “seguía al sol” aproximadamente por una curva senoidal. La forma más simple para estimar era integrar sobre 1/24 de la curva en una hora específica. Si no hubiera sabido cálculo matemático, no hubiera podido hacer estimaciones razonablemente exactas.Cuando escribía mi juego, Wyvern, me fue sumamente útil tener conocimientos sólidos en geometría de planos básica. Y es bastante común usar álgrebra y álgrebra lineal a diario. Pero casi nunca uso trigonometría o ecuaciones diferenciales en el trabajo, ni tampoco mucho cálculo numérico.Diría que mis conocimientos básicos de matemática me hicieron entre un 5% y un 10% mejor programador. Si supiera mucha más matemática, sin dudas sería un mucho mejor programador de lo que soy hoy en día, por lo que estudio y practico matemática varias horas por semana.Amo a la física y llevo una odisea permanente y de por vida para lograr entender los fundamentos de la mecánica cuántica. Pero, personalmente, nunca encontré que la física resulte muy útil para mi trabajo como programador. Por supuesto, esto sería diferente si estuviera haciendo algo en el campo de la física, como programar un juego en 3D, o en ciertas áreas de la simulación.
  • Linus Torvalds: Personalmente creo que es bueno tener conocimientos sólidos en matemática. No estoy tan seguro en cuanto a la física, pero estoy convencido que comprender matemática y tener una buena base te ayuda a ser un programador mejor. Así sea tan sólo porque usan modelos mentales similares – podés construir un conjunto de reglas de cualquier tipo que quieras, pero siempre debe ser consistente consigo mismo.
  • Dave Heinemeier Hansson: Para nada. Al menos no resulta útil para el tipo de programación de negocio necesaria para crear aplicaciones web. Considero que es mucho más importante ser un buen escritor.
  • Peter Norvig: Si. Muchas ideas son inherentemente matemáticas: inducción, recursión, lógica, etc.
  • Dave Thomas: Quizás. Pero, para ser honesto, no vi mucha correlación entre estos tipos de disciplina y los buenos desarrolladores de software.Sin embargo, si he visto una fuerte correlación entre la gente que tiene algo de sentido musicales y la habilidad para programar. No tengo idea porqué, pero sospecho que algunas áreas del cerebro que hacen que alguien tenga sentido musical también las hace buenos desarrolladores de software.
  • Guido Van Rossum: Matemática, sí (algunas partes; no me importan las ecuaciones diferenciales, pero el álgebra y la lógica son importantes). En cuanto a la física, no creo que sea tan útil, excepto que siempre sirve estar interesado en varias cosas.
  • James Gosling: ¡Si! Te enseñan lógica y deducción… a tener un ojo analítico. Y no hay como las matematicas al momento de analizar algoritmos.
  • Bjarne Stroustrup: Depende del programador y de las tareas de programación. Algunas formas de matemática se usan con frecuencia; la física menos seguido, pero por otro lado aprender física es una de las mejores formas de aprender matemática práctica.
  • Tim Bray: En mi caso, casi nunca usé matemática de nivel universitario para apoyar mi programación.

4 – ¿Cuál cree que será la próxima “gran cosa” en la programación? ¿Programación orientada a X, el lenguaje Y, computación cuántica, o qué cosa?

  • Steve Yegge: Creo que la programación de aplicaciones web irá gradualmente convirtiéndose en la programación más importante para el lado del cliente. Creo que va a volver obsoletas a las herramientas del lado del cliente: GTK, Java Swing/SWT, Qt y por supuesto todas las propias de cada plataforma como Cocoa y Win32/MFC/etc.No es algo que vaya a ocurrir de repente. Ya ha venido pasando durante los últimos diez años, y bien podría llevar otros diez años más para que las aplicaciones web “ganen”. Las herramientas, lenguajes, APIs, protocolos y navegadores van a tener que mejorar mucho más todavía. Pero año tras año se acercan un poquito más, y finalmente decidi cambiar todo el desarrollo de mi aplicación a una programación basada en navegadores.Por supuesto que Microsoft y Apple no quieren que esto ocurra, por lo que el primer paso necesario va a ser lograr que un navegador de código abierto como Firefox gane una posición dominante en el mercado, lo cual va a requerir una aplicación ganadora para Firefox (una aplicación ganadora sería algo como iTunes, algo que todo el mundo quiera usar, tanto como para descargarse Firefox).
  • Linus Torvalds: No creo que veamos un “gran salto”. Vimos muchas herramientas que nos ayudan a simplificar las tareas de todos los días – lenguajes de alto nivel y quizás la integración de bases de datos simples dentro de lenguajes. Pero la mayoría de estas modas tuvieron un uso limitado.Por ejemplo, personalmente creo que “Visual Basic” hizo más por la programación que los “Lenguajes Orientados a Objetos”. Y sin embargo, la gente se rie de VB y dice que es un lenguaje malo, mientras hablan de los lenguajes OO por décadas.Y no, Visual Basic no es un gran lenguaje, pero en mi opinión las interfaces simples para bases de datos en VB fueron fundamentalmente más importantes que la orientación a objetos, por ejemplo.Así que creo que van a ocurrir muchas mejoras incrementales, y las mejoras en hardware van a hacer más facil la programación, pero no espero ningúna gran mejora en la productividad o una revolución en la forma que la gente hace las cosas.Al menos no hasta que comenzamos con la inteligencia artificial real, y no creo que la IA real sea algo que “programemos”.
  • David Heinemeier Hansson: No trato de predecir el futuro. No creo en la adivinación. La mejor manera de predecir el futuro es implementarlo.
  • Peter Norvig: Procesamiento distribuido a gran escala.
  • Dave Thomas: La próxima gran cosa en la programación va a ser eclipsada por la próxima-próxima gran cosa en la programación, y así, y así. Estoy cansado de esta búsqueda sin fin de grandes cosas, porque mientras tanto la gente se olvida de los temas reales: tener los fundamentos correctos. Necesitamos mejorar un montón al hablar con nuestros clientes, enfocarnos en entregar valor, y tener orgullo por lo que hacemos. Un desarrollador que puede hacer estas cosas puede entregar software con cualquier herramienta, y no necesita preocuparse por andar siguiendo tendencias y modas.
  • Guido Van Rossum: Lo siento, no soy de los que tienen una bola de cristal. Predije el CGI cinco años después de que fuera inventado. :-)
  • James Gosling: Los dos temas en los que estoy más interesado ahora son manejar el paralelismo y la complejidad.
  • Bjarne Stroustrup: No sé, y no me gusta adivinar.
  • Tim Bray: Ni idea.

5 – Si tuviera tres meses para aprender una tecnología relativamente nueva, ¿cuál eligiría?

  • Steve Yegge: De hecho tengo 3 meses (part-time), y los estoy usando en aprender Dojo (http://dojotoolkit.org) y AJAX y DHTML avanzado. Estoy aprendiendo mientras escribo una aplicación web bastante ambiciosa. Dojo es muy interesante, y estoy seguro que irá mejorando con el tiempo.
  • Linus Torvalds: Hmm. Me encataría hacer FPGAs, pero siempre estuve demasiado ocupado para sentarme y aprender. Me encanta la noción de jugar con el hardware: obviamente es una de las razones por las que terminé haciendo sistemas operativos, ya que (junto a los compiladores) es lo más cerca que podés llegar a jugar con el hardware, sin tener que diseñarlo o construirlo vos mismo.
  • David Heinemeier Hansson: Programación en Cocoa para Mac.
  • Peter Norvig: Me gustaría saber Javascript mejor. También Flash.
  • Dave Thomas: Si por “nuevo” querés decir “nuevo para Dave Thomas”, creo que tomaría lecciones de piano intensivas.
  • Si “nuevo” se refiere a cosas de tecnología, creo que elegiría tecnologías relacionadas con la accesibilidad para personas con discapacidades.
  • Guido Van Rossum: Snowboarding.
  • James Gosling: Para divertirme, me pondría al día con lo último en render 3D. Probablemente escribiría un render de mapeo de fotones.
  • Bjarne Stroustrup: Hay muy pocas cosas de importancia que se puedan aprender en tres meses. Me imagino que estás pensando en capacitación en algún campo determinado.
  • Tim Bray: Seguridad, encriptación, firmas digitales, identidad, etc. Es un gran problema para mi ya que nunca aprendí estas cosas.

6 – ¿Qué hace que algunos programadores sean 10 o 100 veces más productivos que otros?

  • Steve Yegge: Creo que si te detenés a pensar porqué todos los atletas no son igual de buenos, ahí tendrías tu respuesta. Thomas Edison tiene una cita acerca de los genios que también te puede dar algunas pistas.
  • Linus Torvalds: No tengo idea. Creo que algunas personas son capaces de concentrarse en las cosas que importan, y mucho del asunto es hacer eso. La mayoría de los programadores realmente buenos que conozco comenzaron a serlo desde jóvenes.
  • David Heinemeier Hansson: La habilidad de replantear problemas difíciles como fáciles.
  • Peter Norvig: La habilidad de ver el problema completo en sus cabezas.
  • Dave Thomas: Les importa lo que hacen.
  • Guido Van Rossum: Estructura del cerebro genéticamente diferente.
  • James Gosling: Piensan lo que hacen. No se apuran en hacer las cosas. Tienen una visión holística de lo que necesita construirse.
  • Bjarne Stroustrup: Primero es una falta general de profesionalismo y capacitación adecuada que hace que el nivel báse sea muy bajo. Segundo, algunas personas tienen una combinación de “trucos” (la habilidad de pensar claramente y llegar al corazón del asunto), experiencia, y conocimientos de las herramientas. La programación deja más espacio para esto ya que es una combinación de teoría y práctica – ninguna de las cuales sirve de mucho sin conocimiento del dominio.
  • Tim Bray: La sorprendente diversidad de la menta humana.

7 – ¿Cuáles son sus herramientas favoritas (sistemas operativos, lenguajes de programación/scripting, editor de texto, sistema de control de versiones, shell, motor de base de datos, y otras herramientas sin las que pueda vivir) y por qué le gusta más que otras?

  • Steve Yegge: OS: ¡Unix! Uso linux, cygwin, y darwin por igual bastante a menudo. No se los puede igualar como herramientas de productividad. Cada programador debería aprender a usar todos los comandos de /bin y de /usr/bin.Lenguaje de scripting: Ruby. Domino casi cualquier lenguaje de scripting importante que existe: Perl, Python, Tcl, Lua, Awk, Bash y otros que me estoy olvidando. Pero soy bastante vago, y Ruby es por lejos el más facil, así que somos una pareja perfecta.Lenguaje de programación: no tengo un favorito; creo que todos apestan. Tiendo a preferir Java porque es robusto, tiene una plataforma portable y buenas herramientas y librerías. Pero el lenguaje Java a a evolucionar o morir; actualmente no es tan bueno como para mantener el liderazgo en forma indefinida.Editor de texto: Emacs, porque es lo mejor que hay hoy en día.Control de versiones: SVN. Perforce es mejor, pero es muy caro.Shell: Bash, porque soy muy vago para aprender otro.
    Motor de base de datos: MySQL, por supuesto. Nada se le compara.
    Otros: me encanta GIMP, aunque sea increíblemente poco intuitivo. Lo vengo usando por años y aún apenas puedo hacer algo con él. Pero no podría vivir sin el GIMP, aunque suene irónico.
    Firefox se está convirtiendo en una herramienta crítica para mi. Me siento sofocado cuando estoy forzado a usar IE o Safari.
    Nótese que todas estas herramientas (Unix, Emcas, Firefox, GIMP, MySQL, Bash, SVN, Perforce) tienen algo en común: son extensibles. Por ejemplo, todas tienen un API de programación. Los buenos programadores aprenden a programar sus herramientas, no sólo las usan.
  • Linux Torvalds: De hecho no suelo terminar teniendo muchas herramientas con las que trabaje, y con las que pasé algo de tiempo les dediqué tiempo propio para hacer que funcionen para mi. El sistema operativo es claramente la mayor ejemplo, pero también escribí mi propio sistema de control de versiones (git), y el editor de texto que uso (micro-emacs) lo terminé personalizando y extendiendo.Sin contar estas tres partes, lo único que me importa realmente es mi lector de emails. Uso “pine” – no porque sea el mejor lector de emails, sino porque estoy acostumbrado a él, y hace lo que necesito con una mínima intrusión.
  • David Heinemeier Hansson: OS X, TextMate, Ruby, Subversion, MySQL. Ese el el combo que me mantiene feliz hoy en día. Me gustan las herramientas que muestran un buen gusto y se enfocan en las cosa que importan.
  • Peter Norvig: No me gusta ninguno de los sistemas operativos principales – Windows, Mac, Linux. Me gusta Python y Lisp. Emacs.
  • Dave Thomas: Me cambié a las Mac hace un par de años luego de ser un usuario de Linux por más de 10 años. Las herramientas no son necesariamente mejores, pero no necesitan ser mejoradas o mantenidas tan a menudo, lo que me permite concentrarme en usarlas.No creo en las herramientas únicas: suelo cambiar bastante seguido para ganar experiencia con la mayor cantidad de herramientas posible. Ahora estoy usando OSX, Emacs, TextMate, Rails, Ruby, SVN, CVS, Rake, make, xsltproc, TeX, MySQL, Postgres, y un montón de ayudas más. Quien sabe lo que voy a estar usando el año que viene.
  • Guido Van Rossum: Unix/Linux, Python, vi+emacs, Firefox.
  • James Gosling: En estos días vivo en NetBeans. Hace todo lo que quiero, y resulta ser muy claro, simple y eficiente. Es el mejor entorno que usé.
  • Bjarne Stroustrup: Unix, sam (un editor de texto muy simple), y por supuesto un buen compilador de C++.
  • Tim Bray: Me gustan los sistemas operativos basados en Unix, los lenguajes dinámicos como Python y Ruby, y los lenguajes estáticos como Java (en particular las API de Java), Emacs, cualquiera, bash, cualquiera, NetBeans.

8 – ¿Cuál es su libro favorito relacionado con la programación?

  • Tim Bray: Esa es dificil. Quizás *Gödel, Escher, Bach: an Eternal Golden Braid *(Hofstadter). Aunque no es estricticamente de programación. Si querés decir “libro favorito de programación”, entonces quizás SICP (mitpress.mit.edu/* sicp*/).
  • Linus Torvalds: Heh. Hoy en día cuando leo algo, tiende a ser ficción, o cosas no relacionadas con la computación (uno viejo pero bueno: “El gen egoista”, de Richard Dawkins).Hablando de programación, el único libro real de programación que me viene a la mente es el clásico de Kernighan y Ritchie “El lenguaje de programación C”, porque es un libro increíblemente útil, facil de leer y a la vez corto. Teniendo en cuenta que podés aprender uno de los lenguajes más importantes de nuestro tiempo con el libro, el hecho de que sea tan pequeño y facil de leer es una maravilla.Dicho esto, muchos otros libros que disfruté un montón no eran de programación en si, sino acerca de arquitectura de computadoras y hardware. Obviamente está el libro de Patterson y Hennessy sobre arquitectura de computadoras, pero yo prefiero incluso más el libro “Programación en 80386″ de Crawford y Gelsinger, el cual fue el que usé cuando empecé con Linux.Por la misma razón, me gusta “Sistemas Operativos: Diseño e Implementación” de Andrew Tanenbaum.
  • David Heinemeier Hansson: Me gusta Extreme Programming Explained por desafiar al pensamiento común sobre las prácticas de programación, y Patterns of Enterprise Application Architecturepor tener el balance perfecto entre la abstracción y lo concreto.
  • Peter Norvig: Structure and Interpretation of Computer Programs
  • Dave Thomas: Depende qué quieras decir con “favorito”. Probablemente el mejor libro que leí es “IBM/360 Principles of Operation” de IBM.
  • Guido Van Rossum: Quicksilver, de Neil Stepehnson.
  • James Gosling: Programming Pearls, de Jon Bentley.
  • Bjarne Stroustrup: K&R.
  • Tim Bray: Programming Pearls, de Bentley.

9 – ¿Cuál se su libro favorito que NO esté relacionado con la programación?

  • Steve Yegge: ¿Sólo un libro? Es imposible. Hay demasiados libros buenos para elegir sólo uno.Los libros favoritos que leí este mes son “Stardust” (Neil Gaiman) y “The Mind’s I” (Hofstadter/Dennet).Mis escritores favoritos son Kurt Vonnegut, Jr. y Jack Vance.
  • Linux Torvalds: Bueno, ya mencioné El gen egoista de Dawkins. Por el lado de la ficción, hay un montón de libros que leí y disfruté, pero de pocos podría decir que fueron “favoritos”. No suelo re-leer libros, y la selección cambia con el tiempo. La mayoría es ciencia ficción y fantasía, por ejemplo mi libro favorito en la adolescencia era “Stranger in a Strange Land” de Heinlein, pero no lo es tanto estos días…
  • David Heinemeier Hansson: 1984, George Orwell.
  • Guido Van Rossum: Quicksilver, de Neil Stephenson.
  • James Gosling: Guns, Germs & Steel, por Jared Diamond
  • Bjarne Stroustrup: Cambia con el tiempo. Actualmente, la serie de O’Brian’s Aubrey/Maturin. Vean también http://www.research.att.com/~bs/literature.html.
  • Tim Bray: One Day in the Life, de Ivan Denisovich.

10 – ¿Cuál es su banda/músico/compositor de música favorito?

  • Steve Yegge: Géneros favoritos: clasica, bandas de sonido de animé, música de video juegos.Compositores favoritos: Rachmaninoff, Chopin, BachMúsicos favoritos: David Russell (guitarra clásica), Sviatoslav Richter (piano).OSTs de animé favoritos: Last Exile, Haibane Renmei
  • Linus Torvalds: No estoy muy metido en la música, pero cuando escucho algo, tiendo a escuchar varios clásicos de rock, desde Pink Floyd hasta los Beatles, desde Queen a The Who.
  • David Heinemeier Hansson: Me gustan muchos géneros. Beth Orton, Aimee Mann, Jewel, Lauryn Hill. De hecho, todos esos ejemplos entrarían dentro de Chicas y Guitarras ;).
  • Guido Van Rossum: Philip Glass.
  • James Gosling: Suelo escuchar músicos de folk: Christine Lavin, Woody Guthrie, Pete Seeger…
  • Bjarne Stroustrup: Banda: The Dixie Chicks. Compositor: Beethoven.
  • Tim Bray: Lean mi blog.
Conclusion: a Peter Norvig no le gustan las respuestas largas

domingo, septiembre 23, 2012

Lista de herramientas ágiles

Articulo ORIGINAL

Este es un directorio de utilidades, servicios y programas para gestión ágil (proyectos, tareas, backlogs o listas de requisitos …)

  • Comenzamos recopilado más de 80, que hemos etiquetado según la licencia de uso: (Se puede filtrar la lista pulsando sobre el nombre de las etiquetas)
  •  Comercial: Servicios o programas de venta directa o tras un periodo de prueba (shareware). Freemium: Servicios o programas que además de poder contratar un uso completo, sin limitaciones de funcionalidad o capacidad, también pueden emplearse gratuitamente sin limitación de tiempo pero sí de algunas funcionalidades o capacidades. 
  • Open: Servicios o programas que pueden emplearse de forma gratuita, al menos para uso personal. Freemium?: Servicios o programas que se ofrecen de forma gratuita, pero sin especificar si se trata de un periodo de prueba o beta, y si en el futuro se cobrará o limitará el uso. 
  • Por favor, si conocéis alguno que se nos haya pasado, lo podéis añadir directamente, o comentárnoslo. También podéis compartir vuestra opinión o valoración de aquellos que conozcáis. Apuntadnos también si véis alguna errata o clasificación incorrecta. Así, entre todos podremos ir mejorando la utilidad de esta lista. Gracias!!
Lista de Herramientas AGILES.

viernes, abril 01, 2011

10 Recomendaciones para Aprender a Programar



Si eres de los muchos que estan constantemente investigando y siendo autodidactas, aprendiendo poco a poco programación aca les traigo una pequeña lista de recomendaciones a tener en cuenta si apenas vas a empezar en este grandioso mundo, y si depronto ya tienes nociones de programación aca puedes aprender un poco más , no siendo más les presento mis 10 recomendaciones:
  1. Aprender Pseudocódigo:

    Lo fundamental para aprender a programar es tener una clara y profunda noción de la lógica de programación, esto se logra mediante el “falso código“, gracias a esto podemos entender más adelante lo que son las (estructuras de control, estructuras repetitivas, tipos de datos, etc). La página que recomiendo para profundizar acerca de este tema.
  2. No Desesperes:

    En el mundo de la programación es muy alta la tasa de error que cometeremos en la codificación y más si apenas estamos aprendiendo a programar, pero a medida que vayamos adentrando a este mundo más fácil podremos identificar los errores.
  3. Inicia en Lenguajes Sencillos:

    Ahora que sabemos programar en pseudocódigo y aprendimos las sentencias básicas para darle un flujo a nuestros programas podemos empezar con lenguajes de programación tales como Javascript, Php, C++, Html, etc.
  4. ¿Quieres ser Programador Web?:

    Si lo que más te gusta es la programación web, y hacer aplicativos para sitios en Internet te recomiendo que inicies con la lengua madre para maquetar los sitios Html y vayas adentrandote más y más… Si ya estas dominando el Html pues empieza con el diseño con Css, ahora si los dominas empieza a darle “vida” a tu sitio con Javascript, jQuery y Php.
  5. ¿Quieres Programar Software para PC?:

    Si tu sueño es que la gente descargue tus propios programas aceleradores de descarga, utilidades, programas de mensajeria, y todo lo que quieras , pues tu lugar esta en programar en Java, C#, Python, Visual Basic, Cobol, etc. Mi recomendación personal es que inicies programando en C++, es muy fácil de entender y en Internet encuentras muchisimo material para aprenderlo, y lo bueno es que si aprendes te va a quedar unas muy grandes bases de programación, pero si eres un tipo impaciente y entusiasta mejor te recomiendo y empiezes con el Visual Basic 6.0 que con el método Drag & Drop (arrastrar y soltar) podrás crear programas de manera muy rápida y con poco código.
  6. Participa en Foros y Comunidades:

    Es importante tener en cuenta este punto ya que en los diferentes comunidades que se encuentran en Internet podremos interactuar con muchas personas y algunos “maestros” en la programación con ganas de colaborarnos, encontraremos gente buena onda con la cual hacer un equipo de trabajo online en la cual la ayuda mutua se brindará, te lo aseguro.
  7. Comenta tu Codigo: Una Útil Practica

    Escribir comentarios en nuestros aplicativos es de suma importancia ya que semanas o meses despues tendremos que hacerle algún cambio o retocarlo y con un comentario podremos ahorrarnos muchisimo tiempo.
  8. Tiempo libre para hacer otras cosas:

    Personalmente me encanta programar, pero hace poco aprendí que no es lo único que hay en la vida, que algunas desenchufadas en el mundo virtual es verdaderamente necesarias, para aclarar tus ideas y darte un descanso compartiendo con tus amigos, llendo al cine, al parque o a crearte un torneo de Xbox con ellos
  9. La humildad ante todo:

    El verdadero programador es el que acepta consejos, el que aprende de su entorno y el que acepta de la mejor forma sus errores, nadie es perfecto en esta vida lo tenemos claro. Cada vez aprendes algo nuevo así lleves programando hace 7 años, pero eso es lo lindo de este mundo.
  10. La Practica hace a el Maestro:

    la verdad no soy un “excelente programador”, pero en la solución de problemas estoy algo adelantado ¿por qué?, se lo debo principalmente a mis ganas de investigar y ser autodidacta como tú , y lo que me ha ayudado tambien es las resoluciones de algunos algoritmos que me encuentro por la red

viernes, enero 21, 2011

30 Leyes epónimas relacionadas con el desarrollo de software

Tomado de: Tomado de



Un epónimo es el nombre de una persona o lugar que cede su nombre a una época, pueblo, unidad, ley, etc. Son epónimos por ejemplo "Diesel", cedido por Rudolf Diesel, inventor de este tipo de motores, o "Hamburguesa", infame trozo de carne picada cuyo nombre procede de su lugar de origen.

Hace unos años, el gran Phil Haack posteó sobre leyes epónimas relacionadas con el desarrollo de software en "19 Eponymous Laws Of Software Development", y seleccioné las que me resultaron más interesantes en un par de posts.

Ahora los he vuelto a maquetar y les he añadido un nuevo conjunto de leyes muy interesantes para todos los que nos dedicamos al mundo del desarrollo de software, y muchas de ellas incluso aplicables a otros ámbitos.




1. Ley de Postel




dijo:
Sé conservador en lo que hagas y liberal en lo que aceptes de los demás


Esta frase, de Jonathan Bruce Postel, también llamada Principio de Robustez, es la piedra filosofal del protocolo TCP, y está recogida en la RFC 793, sección 2.10, de septiembre de 1981.




2. Ley de Parkinson



dijo:
El trabajo se extiende siempre hasta rellenar la totalidad del tiempo disponible para completarlo


Esta ley fue postulada inicialmente en 1955 por C. Northcote Parkinson en The Economist y más tarde entró a formar parte de su libro, basado principalmente en las experiencias de la administración británica.




3. Principio de Pareto



dijo:
Para muchos fenómenos, el 80% de las consecuencias derivan del 20% de las causas


Vilfredo Pareto fue un estudioso de la economía y sociología del siglo XIX, y se fijó que el 80% de las propiedades y riqueza estaban repartidas entre el 20% de la población, enunciando su famoso principio. A partir de ahí, se piensa que esta proporción es cierta en múltiples ocasiones, hasta en el número de bugs en el código fuente de un software, o el tiempo de desarrollo de funcionalidades.




4. Revelación de Sturgeon



dijo:
El noventa por ciento de cualquier cosa es basura


Theodore Sturgeon era un autor de ciencia ficción americano que escribió esta frase defendiendo a este tipo de literatura de críticos que opinaban que el 90% era una porquería.

Hay un corolario que dice "La revelación de Sturgeon es cierta salvo para la basura, donde el 100% es basura".




5. El principio de Peter



dijo:
En una jerarquía, todo individuo tiende a subir hasta alcanzar su nivel de incompetencia


Seguro que todos conocéis ejemplos de ello: un fabuloso desarrollador es ascendido a directivo en una empresa, la cual gana un gestor pésimo y pierde un programador excelente. Doble penalización. Lawrence J. Peter, pedagogo de profesión, ya lo enunció en 1968 en el libro El principio de Peter.




6. Ley de Hofstadter



dijo:
La realización de un trabajo siempre dura más de lo esperado, incluso habiéndose tenido en cuenta la Ley de Hofstadter


Esta genial y recursiva Ley creada por el científico, filósofo y académico estadounidense Douglas Hofstadter es absolutamente cierta. Y si no, pensad un poco, ¿cuántas veces habéis estimado plazos en un desarrollo, lo habéis incrementado de forma considerable por los imprevistos y aún así os habéis quedado cortos?




7. Ley de Murphy



dijo:
Si algo puede ir mal, lo hará


La famosa ley, también enunciada en forma de tostada que recurrentemente cae con la mantequilla hacia abajo, fue dictada por Edward A. Murphy, Jr., mientras trabajaba para la fuerza aérea americana como ingeniero, diseñando un sistema de cohetes experimental. Sería lógico pensar que el experimento acabó en tragedia, pero parece ser que la creación y consideración de esta ley les ayudó a evitar graves desastres en sus pruebas.




8. Ley de Brooks



dijo:
Incluir trabajadores en un proyecto retrasado hará que éste avance aún más lentamente


Fred Brooks postuló esta ley en su famoso libro The Mythical Man-Month: Essays on Software Engineering como resultado de su experiencia en IBM. Existen variantes y corolarios como "Una señora es capaz de tener un hijo en nueve meses, pero este plazo no puede disminuir por muchas mujeres embarazadas que pongamos a ello". Simplemente genial.




9. Ley de Conway



dijo:
Cualquier software refleja la estructura organizacional de quien lo produjo


A pesar de que suena a guasa, la ley de Melvin Conway no puede ser más cierta. Una empresa con tres grupos de desarrollo tenderá a generar software distribuido en tres subsistemas, reflejo fiel de las relaciones entre los grupos participantes. Y por cierto, extrapolando un poco... ¿habéis pensado alguna vez que el software que se hace en vuestra empresa es un desastre? ¿creéis que con esta ley podríais obtener alguna conclusión? ;-D




10. Principio de Kerckhoffs



dijo:
En términos de criptografía, un sistema debería ser seguro incluso si todo sobre el mismo se conoce públicamente, salvo una pequeña porción de información


Es increíble que Auguste Kerckhoffs lingüista y criptógrafo alemán, enunciara en el siglo XIX este principio, base de todos los sistemas de criptografía de clave pública actuales.




11. Ley de Linus



dijo:
Dados suficientes ojos, todos los errores son obvios


Pues sí, Linus Torvalds, uno de los más famosos artífices de Linux tal y como es conocido hoy en día, no sólo desarrollaba software, también emitía este tipo de aseveraciones en las que exponía las ventajas del modelo de desarrollo cooperativo y abierto frente al propietario; otros simplemente ven esta teoría como una barbaridad desde el punto de vista de la seguridad y mantenimiento de los sistemas.

Aunque la frase fue cosa de Linus, fue Eric S. Raymond, un hacker a la antigua usanza, el que la popularizó y le dio el nombre de su creador.




12. Ley de Reed



dijo:
La utilidad de grandes redes, y en particular las sociales, crecen exponencialmente con el tamaño de la red


David P. Reed, científico americano, enunció esto que parece obvio en los tiempos actuales dado el tamaño y utilización de este tipo de redes. En esta entrada de la wikipedia podéis encontrar una introducción del soporte teórico en el que se basa, que explica en esencia la facilidad con la que crece el número de subgrupos posibles entre usuarios en relación al número de usuarios o de pares.




13. Ley de Moore



dijo:
La potencia de los ordenadores se duplica cada dos años, reduciendo además su coste


Repetida hasta la saciedad en revistas de cacharreo, y constatada desde hace décadas, fue promulgada por Gordon Earl Moore, quien por cierto es co-fundador de Intel, fijaos si lo tenía claro el muchacho, en 1965 (!). No sé si entonces utilizó la bola de cristal, era una declaración de intenciones, o simplemente es un genio, pero desde luego su ley es una referencia de la medida del avance en los ordenadores y demás dispositivos basados en tecnología similar, y un objetivo mínimo a cumplir.




14. Ley de Wirth



dijo:
El software se ralentiza más deprisa de lo que se acelera el hardware


Brillante la frase de Niklaus Wirth, que allá por el año 1995, aún sin conocer Windows Vista, observó su entorno y predijo la situación actual: cada vez el software es más lento y pesado, a pesar de que según la Ley de Moore tendría que ser al contrario. Este señor, una eminencia, es conocido sobre todo por haber dirigido la creación de los lenguajes Pascal, Modula y algunos otros menos difundidos.

¿Será coincidencia que en ese mismo año, 1995, fue el lanzamiento oficial de Java? ;-P




15. Ley de Zawinski



dijo:
Todo programa intenta expandirse hasta que pueda leer emails. Aquél que no pueda ser expandido hasta ese punto, será sustituido por otro que sí tenga esa capacidad


Lo que más me ha llamado la atención de Jamie Zawinski aparte de su metafórica ley que critica el crecimiento, a veces sin sentido, del software, es su página web personal. No os la perdáis, pues es bastante indicativa del tipo de individuo de que se trata, todo un friki, padre entre otros de una versión de Netscape, Grendel, Netscape Mail & News, Lucid Emacs, etc. También es curioso que es propietario de un club nocturno en San Francisco, este sí que sabe ;-)




16. Las tres Leyes de Clarke



Primera Ley de Clarke
dijo:
Cuando un anciano y distinguido científico afirma que algo es posible, probablemente está en lo correcto. Cuando afirma que algo es imposible, probablemente está equivocado.


Segunda Ley de Clarke
dijo:
La única manera de descubrir los límites de lo posible es aventurarse hacia lo imposible.


Tercera Ley de Clarke
dijo:
Cualquier tecnología lo suficientemente avanzada es indistinguible de la magia.


El conocido científico y escritor británico Sir Arthur Charles Clarke enunció estas tres leyes porque, según comentaba, "si tres leyes fueron suficientes para Newton, modestamente decido parar aquí".

Arthur C. Clarke fue autor de un gran número de libros, relatos y obras de divulgación, destacando su novela y participación en el guión de 2001: Una odisea en el espacio.




17. El principio de Dilbert



dijo:
Las compañías tienden a ascender sistemáticamente a sus empleados menos competentes a cargos directivos para limitar así la cantidad de daño que son capaces de provocar


Este complemento perfecto para el Principio de Peter fue observado por Scott Adams, autor de Dilbert, una popular tira cómica sobre el mundo de la empresa que se publica en 1200 periódicos de todo el mundo.

Scott Adams es considerado uno de los 50 pensadores más influyentes en el mundo de la empresa, incluso por encima de personajes como Steve Jobs o Al Gore. Se trata, además, de un epónimo curioso en cuanto a que su nombre no proviene directamente de su autor, sino de la obra de su autor.




18. Ley de Gilder



dijo:
El ancho de banda aumenta a un ritmo tres veces superior a la potencia de los ordenadores


Pues sí, cualquiera lo hubiera dicho hace unos años... pero la verdad es que hoy en día la velocidad en las conexiones a la red son increíbles. Y por suerte, sin subir proporcionalmente el coste ;-)

George Gilder es un controvertido escritor e intelectual americano, entusiasta de la tecnología e internet, que en la actualidad dirige el Gilder Technology Report, un sitio exclusivo de información de ámbito económico y tecnológico. Según comentan, "sus hijos no estudian español, sino C++" (visto en Wikiquote).




19. Ley de Amdahl



dijo:
El incremento de velocidad de un programa utilizando múltiples procesadores en computación distribuida está limitada por la fracción secuencial del programa


Esta ley, de gran aplicación en el cálculo de rendimiento de sistemas cuando uno de sus componentes es mejorado o en contextos de procesamiento en paralelo, fue enunciada por Gene Myron Amdahl en 1967, en sus tiempos como trabajador de IBM Corporation, que abandonó varias veces por disconformidad con el escaso trato humano en esta empresa, muy encorsetada y llena de burocracia.

Según demuestra matemáticamente, llegados a un punto el rendimiento de un sistema no está relacionado con el número de procesadores instalados, sino con la eficiencia de los algoritmos empleados.




20. Ley de Myhrvold



dijo:
El software es un gas; se expande hasta rellenar su contenedor


Claro, esto explica por qué da igual la potencia y capacidad del ordenador que tengamos: nuestro software lo llenará como si se tratara de un globo, hasta ponerlo a reventar.

Y lo dijo ni más ni menos que Nathan Myhrvold, ex-director de tecnología de Microsoft y fundador de Intellectual Ventures, una empresa dedicada crear y patentar, pero curiosamente no a poner en explotación, inventos para sectores como el software, semiconductores, redes, lásers, biotecnología y otros dispositivos.




21. Las leyes de Bryce



Así las llama él, aunque algunas encajarían mejor en una recopilación de frases célebres. Ahí van algunas, aunque pueden encontrarse más de 150 aquí.


dijo:
Tal y como el uso de la tecnología va aumentando, disminuyen las habilidades sociales

El 85% del trabajo de desarrollo de todos los sistemas consiste en introducir modificaciones y mejoras

A la vez que la capacidad del hardware incrementa, el software se vuelve más pesado

Olvidar al ser humano durante el diseño del sistema provocará que el ser humano se olvide del sistema en el momento de echarlo a andar


[...]

Tim Bryce es un controvertido escritor y consultor de gestión de recursos de información (IRM), famoso entre otras cosas por sus aseveraciones sobre el ego, las manías y extrañezas de los desarrolladores, y sus consejos para manejarlos apropiadamente. Aparte de su habilidad para hacer amigos entre los programadores, es sin duda un gran experto en el mundo de las compañías de desarrollo de software, con más de 30 años a sus espaldas en este campo.




22. Primer principio de Spaf



dijo:
Si eres responsable de seguridad pero no tienes autoridad para establecer reglas y castigar sus incumplimientos, tu cargo real en la organización es asumir la culpa cuando ocurra algo grave


Eugene Spafford, más conocido como "Spaff", es un reputado experto en seguridad informática y profesor de la Purdue Univertity. Según parece, fue uno de los primeros en escribir un libro sobre virus informáticos en 1989, utilizar el término autopsia software para referirse al análisis de aplicaciones para intentar localizar a sus autores, y un sinfín de aportaciones al mundo de la seguridad en sistemas informáticos.

Además, es tan prolífico creando frases y analogías a la hora de explicar conceptos de informáticos queMahesh V. Tripunitara, uno de sus estudiantes, mantiene una página donde las recoge: "The Page of Spaf's Analogies".




23. Ley de Alzheimer de la programación



dijo:
Si lees un código que escribiste hace más de dos semanas es como si lo vieras por primera vez


Efectivamente, el psiquiatra y neurólogo alemán Aloysius Alzheimer no enunció esta ley a primeros del siglo pasado, pues estaba muy ocupado estudiando las enfermedades mentales de sus pacientes. Sin embargo, el síntoma de pérdida de memoria tan habitual en ellos propició la utilización de su nombre en esta Ley tan ligada a la escritura de código limpio, documentado y sencillo.




24. Ley de Amara



dijo:
Tendemos a sobreestimar el efecto de la tecnología en el corto plazo y a subestimarla a largo plazo


Esta ley, causa de la existencia de problemas debidos a excesos de optimismo o de la formulación de predicciones disparatadas, fue enunciada por Roy Amara, que fue presidente del Instituto para el Futuro, un grupo de investigación sin ánimo de lucro dedicado al análisis de tendencias que ayuden a la toma de decisiones basándose en predicciones sobre el futuro.




25. Ley de Hick



dijo:
El tiempo que se tarda en tomar una decisión aumenta a medida que se incrementa el número de alternativas


Puede sonar a obvio, pero la cuestión es que William Edmund Hick, pionero en psicología experimental y ergonomía, fue capaz de idear, a mediados del siglo pasado, la fórmula que explica por qué tardamos tanto tiempo en responder a un cuadro de diálogo con botones para Aceptar, Cancelar, Reintentar, Ignorar y Omitir:
T = blog2(n + 1)Cosas de las matemáticas, seguro. :-D




26. Principio de Liskov



dijo:
Los subtipos deben ser sustituibles por sus clases bases


O en otras palabras, que un subtipo no debe modificar el comportamiento esperado de la clase de la que hereda; de esta forma, si el subtipo puede sustituir a su clase base sin causar daños, la herencia será correcta. Citando a Enrique Place en PHPSenior, "No basta conser hay que comportarse como tal".

Barbara Liskov es profesora del Massachusetts Institute of Technology (MIT) y fue la primera mujer en conseguir el doctorado en informática de Estados Unidos.





27. Principio de Hanlon



dijo:
Nunca le atribuya a la maldad lo que puede ser explicado por la estupidez


A pesar de su nombre, no está claro quién definió con tanta claridad su confianza en la capacidad del ser humano. Bill Clarke, Goethe, William James, Napoleón Bonaparte, Richard Feynmann, Einstein, Robert A. Heinlein (cuyo apellido podría haber degenerado en "Hanlon", o un desconocido Robert J. Hanlon del que no existen demasiadas referencias podrían ser los padres de esta Ley tan utilizada por los hackers para definir situaciones creadas como consecuencia del trabajo de incompetentes sin mala intención.




28. Ley de Joy



dijo:
El número de empleados inteligentes en una empresa es una función logarítmica del número de empleados totales


También formulada como "no importa quien seas, la mayoría de la gente inteligente trabaja para otro", la Ley dictada por Bill Joy ofrece una visión un tanto pesimista (¿realista?) de nosotros mismos y nuestro entorno de trabajo. Pero ojo, que no lo decía cualquiera, que este señor es co-fundador de Sun y, probablemente, estuviera describiendo lo que veía.




29. Ley de Lister



dijo:
La gente bajo presión no piensa más rápido


Bonita frase para escribir en un post-it y pegárselo en la frente a alguien a ver si se da por aludido. Y es que efectivamente, la presión y la velocidad de pensamiento no son magnitudes proporcionales, pero es Tim Lister, un consultor, formador y escritor experto en gestión de riesgos en procesos de desarrollo de software, el que lo enunció de esta forma tan tajante y certera.




30. La navaja de Occam



dijo:
En igualdad de condiciones la solución más sencilla es probablemente la correcta


En el siglo XIV, Guillermo de Ockham, fraile franciscano y filósofo, postulaba de esta forma el principio de economía, utilizada en disciplinas tan dispares como la teología, informática o lingüística. De hecho, podríamos considerarlo la base de principios como KISS (Keep It Simple, Stupid), o YAGNI (You ain't gonna need it), asociados habitualmente a la programación extrema pero válidos en cualquier tipo de desarrollo.



Fuente: Variable Not Found