Aprende programación






30 ago 2010

¿Hay diferencia entre vector y matriz?


Una pregunta muy sencilla ... prácticamente de 1º de ... no de ingeniería ... de formación básica. Al menos a mi siempre me han enseñado que el vector son colecciones de elementos de 1 dimensión y matrices las de 2 dimensiones que son las más utilizadas en el tema de juegos de tablero. Más de dos, las suelo llamar vectores de 3,4...N dimensiones, pero no recuerdo como me lo enseñaron.

El caso es que preparando una documentación he consultado en la wiki y he encontrado esto:
http://es.wikipedia.org/wiki/Vector_%28inform%C3%A1tica%29
En programación, una matriz o vector (llamados en inglés arrays) es una zona de almacenamiento contiguo, que contiene una serie de elementos del mismo tipo, los elementos de la matriz. Desde el punto de vista lógico una matriz se puede ver como un conjunto de elementos ordenados en fila (o filas y columnas si tuviera dos dimensiones). En principio, se puede considerar que todas las matrices son de una dimensión, la dimensión principal, pero los elementos de dicha fila pueden ser a su vez matrices (un proceso que puede ser recursivo), lo que nos permite hablar de la existencia de matrices multidimensionales, aunque las más fáciles de imaginar son los de una, dos y tres dimensiones.

Toma ya! Según esta definición dá igual como se llame. Cuando nos referimos a matrices también estamos hablando de 1 dimensión. Estonces, mientras una gota fria bajaba en mi frente, pensaba ¿Habré estado equivocado durante estos 15 años?

El caso es que he buscado más información para comprobar si era yo el único que veia algo raro en esto o no y, menos mal, he encontrado gente como yo:
http://www.foroz.org/foroz/topic5540.html
http://www.forosdelweb.com/f13/diferencia-entre-vector-matriz-420381/
http://www.mailxmail.com/curso-aprende-programar/estructuras-datos-arreglos
http://elvex.ugr.es/decsai/c/apuntes/vectores.pdf

Pero también encontré lo contrario:
http://html.rincondelvago.com/arreglos.html

Veamos lo que dice la RAE:
Vector: No hay ninguna definición que encaje con colecciones de datos o algebra. ... ¿Agente que transporta algo de un lugar a otro? ... Un poco rebuscada ¿no?. Con esa definición una variable también podría ser un vector.
Matriz: Conjunto de números o símbolos algebraicos colocados en líneas horizontales y verticales y dispuestos en forma de rectángulo.

Y mi pregunta es ... ¿llamais vosotros a los arrays de 1 dimensión matrices? ¿Y como llamais a los de dos y tres dimensiones?

Un saludo para los que los llamaron "arreglos" y no se liaron con diferentes términos :P

28 ago 2010

Lady Java - Humor

Hoy he estado buscando alguna canción para el podcast que tratase de algún tema de programación (para variar un poco). El caso es que he encontrado un video muy bién producido para la javazone 2010.

Así que... poniendo voz de locutor de listas de exitos...

¡¡¡De los creadores del Trailer de "Java, why not to use .NET" ... el último hit que romperá todas las listas top 10 ... "Lady Java".!!!


21 ago 2010

Caso Spanair, ¿puede el sistema informático tener parte de responsabilidad en el accidente del JK5022?


Precisamente ayer 20 de agosto, hace dos años en España se sufrió un trágico accidente aereo en la términal T4 de barajas.

A día de hoy se sigue el secreto de sumario sobre la investigación de las causas del accidente, pero los tentaculos de la prensa son muy amplios y existen filtraciones. Una de las noticias con las que nos levantamos es precisamente un artículo del país:
http://www.elpais.com/articulo/espana/ordenador/Spanair/anotaba/fallos/aviones/tenia/virus/elpepuesp/20100820elpepinac_11/Tes

En este artículo comenta que además de los fallos técnicos del avión, el sistema informático no estaba disponible por software malicioso. Por ese motivo los técnicos no pudieron apuntar las incidencias y como consecuencia no saltó la alarma a control para revisar más profundamente el problema. A pesar de ser prensa escrita (que muchas veces lanzan rótulos o noticias partidarias o exageradas) me gustaría comentar que hoy en la radio han entrevisado al presidente de la asociación de dagnificados por el accidente JK5022 y ha dicho que eso era secreto de sumario pero que era una cosa que se había solicitado.

El famoso "sistema caido" son causas que nos encontramos cada vez más en puntos de venta, gestiones o administración. En este caso, ha coincidido con una tragedia y, por supuesto, hay que revisar absolutamente todo. En ningún momento se dice que esta sea la principal causa ya que es una cadena de circunstancias pero si puede ser un eslabón más. Sin embargo si es interesante analizar como de responsable es el sistema, los técnicos informáticos o los gerentes y directores.

Sistema informático, ¿crítico o no crítico?.
El primero de los temas que nos debemos plantear es, ¿es el sistema informático crítico para la vida de las personas?. Un sistema informático puede ser muchas cosas, desde una simple extensión de lo que gestionabamos antes con bolígrafos y papel, hasta sistemas de control de máquinas. Determinar ese nivel de responsabilidad de cada sistema y poner recursos y presupuesto en función la responsabilidad depende de la parte gestora y dirección. Cuando de un sistema puede ser responsable de vidas humanas, es necesario que exista una regulación al respecto, ¡pero ojo!, no vale con decir si has estudiado 3-5 años una ingeniería vales o no. Los ingenieros informáticos no tenemos control de, por ejemplo, el código que se implanta en las actualizaciones de Windows o si un runtime o actualización de software funcionará para todas las operaciones que se hagan. Si pueden evitar y probar el sistema para minimizar el error pero a diferencia con otros campos de ingenieria que trabajan con medidas y valores invariables, en la informática se trabaja sobre el trabajo de otras personas que no cuantifican su trabajo.

El CLUF: la mayoría de software excluyen de responsabilidad de fallos al proveedor
En todos los sistemas operativos o aplicaciones que solemos utilizar en ordenadores personales existe un CLUF o contrato de uso en el que los proveedores de software excluyen toda la responsabilidad de fallos del programa o sistema. No se puede certificar un trabajo que funciona sobre otro trabajo en el cual el propio fabricante excluye su responsabilidad en el caso de fallos. Por todo ello, se utilizan excusas como "fallo informático" para evadirse de la responsabilidad de fallos o errores. En cuestiones de gestión que lo único que provoca son retrasos no es tan crítico pero en sistemas en los que depende la vida de la personas la cosa es más seria.

Para que de la informática pueda depender de vidas humanas, hay que tener sistemas operativos, lenguajes y aplicaciones certificados en seguridad y disponibilidad. Decir que algo está certificado es decir que va a funcionar para ciertas condiciones y para ciertas tareas y por supuesto responsabilizarse de ello en vez de tener un CLUF de exclusión de resposabilidad. Un sistema multiuso como Windows, Linux o Solaris que son multiuso no pueden estar certificados asegurando que todo lo que hacen lo va a hacer bién al 100% bién porque realizan muchas tareas y existen muchos agentes que pueden tirar abajo el sistema. Por ejemplo, un sistema operativo sin ninguna aplicación instalada, el propio hardware lo puede tirar si dá problemas.

¿Que es necesario para sistemas críticos?
Para sistemas críticos, nos tenemos que ir a sistemas informáticos especializados (Mainframes menos conocidos para usuarios) que llevan el hardware y software incorporado de fábrica y no se permite la realización de actualizaciones o modificaciones de ficheros por otras aplicaciones ajenas al sistema. Estos realizan tareas concretas y certifican que estas funcionan en las tareas en las que están especializadas.

Por los datos de la noticia sobre malware, deduzco que el sistema operativo era un Windows Server por lo que se deduce con esas condiciones parece que optaron por reducir costes e ir a un sistema más comercial (menos industrial) y más inestable. Desde el punto de vista de dirección, no era un sistema crítico para la empresa. Tan solo una herramienta de gestión más.

En tal caso, si esa tarea de anotación de incidencias era vital para la vida de las personas, debía existir un procedimiento alternativo (como llamar por teléfono, apuntar en una hoja, etc), en el que se pudiese realizar la misma tarea si ocurriese algo con el sistema informático. En tal caso es responsabilidad del director de sistemas y/o organización establecer más alternativas en el caso de que el sistema falle.

Informática es ahorrar, pero volcarte a otro sistema y ahorrar en informática es perder en disponibilidad del sistema.
En general la informática dá muchas ventajas. Se ahorran costes porque una misma persona puede gestionar muchos más datos que escribirlo en papel. Sin embargo, apuntes que son más serios se deben tener también en papel.

Gestionar del mismo modo información abundante que sirve a modo estadístico para optimizar procesos e información seria de problemas es un error. Ambos pueden ir en el sistema informático, pero los problemas serios al ser menos abundantes deben tener una gestión alternativa (en papel o un sistema cerrado y certificado, por ejemplo).

En fin, no debemos olvidar que la informática multiuso (PCs personales) son una evolución del bolígrafo y papel. Al igual que cuando antes nos fallaba un boligrafo teniamos la alternativa o la precaución de tener varios y tomar otro, el PC también puede fallar y debemos tener previsto que hariamos en tal caso.

Resumen:
Como conclusiones, ha salido a relucir unos de los problemas que cada vez existen en multitud de negocios. Que yo haya sufrido personalmente haciendome ir otro día: al comprar billetes del tren, en el polideportivo, en un juzgado y en el banco/caja. Existe una gran tendencia a informatizar todo para poder sacar estadísticas o para centralizar la información, pero muchas veces nos olvidamos de pensar en que ocurriría si el sistema informático cae. Esto es algo tolerable en negocios pero no en sistemas críticos.

Por todo ello, como hemos comentado, si existiese alguna resposabilidad, y la tarea de anotar estas incidencias sea esencial para proteger la vida de las personas, sería de la parte de dirección de sistemas y/o organización o gerentes por no evaluar este procedimiento de anotación de incidencias como nivel crítico para la vida de las personas, y en tal caso, instalar un servidor que puede ser vulnerable a ataques tan comunes a costa de reducir costes y no tener un procedimiento alternativo en el caso de fallar el sistema.

18 ago 2010

¿Programar en español o en inglés? - Opinión


En una ocasión me encontré con un proyecto en el que el responsable había decidido hacer el proyecto en inglés. La cuestión es ¿es ventajoso programar en inglés?. Con programar en inglés me refiero a declarar todos los nombres de las tablas, métodos y ciertas variables totalmente en inglés. A primera vista puede parecer una gran idea. Acostumbrarse a desarrollar en inglés puede facilitarnos a participar en proyectos de software libre que podemos ver en sourceforge, perfeccionar el inglés y quizá en un futuro nuestro proyecto pueda ser desarrollado en el extranjero.

Sin embargo, esas ventajas se volvieron totalmente en contra del proyecto por los siguientes motivos.
  • Empleo de términos incorrectos. Aunque sepamos inglés y hayamos estudiado bastantes años, nos podemos encontrar un término asociado a un tipo de negocio que no conozcamos. En ese caso, lo primero que haremos es utilizar un diccionario o utilizar un traductor. Lo más probable es que el término en concreto tenga varios significados y elijas el incorrecto.
  • Ampliación el grupo de trabajo. Un problema siempre ha sido la incorporación de personal en un proyecto. Si utilizas términos en ingles perjudicarás en su incorporación ya que puede que no todo el mundo tiene el mismo nivel de ingles. Lo que ocurrirá es que estas personas intentarán escribir en español y finalmente quedará un batiburrillo de conceptos en inglés y español.
  • Poca probabilidad de ser un proyecto internacional. Salvo que el proyecto tenga un enfoque internacional, pocas veces he visto que un programa se desarrolle mitad en España y mitad en extranjero. No digo que no haya pues si conozco algún caso, pero en general, los proyectos que tienen proyección de desarrollo en España no pasan fronteras (refiriendonos en el desarrollo)
  • Pocas personas hacen software libre. Quizás una de las ideas que tenias era practicar para familiarizarte en proyectos internacionales o participar en proyectos sourceforge. Sin embargo, existe un porcentaje muy pequeño que estén interesados en participar en este tipo de proyecto. Por ello, lo único que has hecho es hacer algo que te divertía pero al grupo quizá no.
Además de estos problemas, creo que tenemos una ventaja también al escribir en Español frente a desarrolladores en Inglés y es poder detectar en un momento que código es nuestro y que código pertenece a una librería externa. Por ejemplo, en algún tutorial escrito en inglés a veces he copiado una función que a su vez hacía referencia a otra pero como esta estaba en inglés no sabía que también la tenía que incluir y luego me daba fallos. Sin embargo, cuando leo un tutorial con funciones en español, al ver la llamada ya sé que eso no pertenece a la librería y debe estar en otro sitio o la debo crear.

Finalmente, también es perjudicial pensar solo en español pues gran parte de documentación técnica está en inglés. En mi opinión hay que saber inglés para entender la documentación técnica pero en el día a día, donde no todo es perfecto, hay que facilitar las cosas.

16 ago 2010

Documental - Los creadores de Google

He encontrado por casualidad un documental interesante sobre Google. En este habla de sus inicios, progresión y filosofía de empresa. El documental parece un poco viejo 2004, cuando Google acababa de entrar en bolsa. Aquí teneis el link:


Como conclusiones del documental, "no hacer algo innovador que puedas hacer es como no regar una jardín" y "siempre se tendrán problemas legales por entrar en campos inexplorados antés".

8 ago 2010

No temer y reconocer los errores nos hace grandes - Opinión

Hoy he visto via meneame una noticia que quizá esté relacionada con una frase que alguna vez he dicho. "No hay que temer por equivocarse". La noticia es:

Google celebra el fracaso de su producto 'Wave' [ENG]

Según la teoría de la evolución la celula ha mutado sin ningún tipo de razón, creando otros organismos que deberán luchar a sus nuevas características y que muchos de ellos, practicamente el 99%, se extinguirán por no saber adaptarse. Sin embargo, ese 1% dispone una nueva caracteristica que de manera aleatoria puede mejorar o empeorar la versión anterior y tendrá más o menos éxito en reproducirse. Continuadamente, siguiendo estas mutaciones aleatorias, se ha llegado a crear el ser humano, la fauna y todo nuestro entorno.

Igualmente, muchos inventos han sido creados a base de realizar experimentos extraños, y a veces involuntarios, que nos han llevado a ver las cosas de otro modo.

En el mundo empresarial y el mundo de la informática ocurre lo mismo. Entre una escala de grises, existen dos filosofías, hacer inversiones de capital riesgo o hacer inversiones en capital seguro. Haciendo un simil con la biología invertir en capital riesgo sería mutar un negocio a otro que deberá saber adaptarse. Invertir en algo seguro sería como dejar la celula como está.

Normalmente a los inversionistas les dá igual donde invertir siempre que les dé el mayor beneficio posible. Y realmente eso es una pena. El capital riesgo que muta los negocios puede ser un beneficio para el empresario si sale bién, pero siempre será un beneficio para todos tanto si sale bién como si sale mal. Si sale mal, se habrá visto que otro enfoque diferente y quizá ese enfoque lleve a otras ideas que a su vez lleven otro enfoque. Un caso clarísimo de este es Napster. Quizás sin Napster no tendríamos redes p2p o se hubiesen desarrollado de otra forma.

Pero lo más intigrante de todo es el modo exponencial de esas mutaciones. Actualmente, el coste de desarrollo de una empresa riesgo es bastante más bajo y el nivel de difusión más alto. Las redes sociales hacen que las ideas y los negocios se transmitan más deprisa y en cuestión de pocos años una empresa suba como la espuma y en cuestión de otros pocos años caiga en picado.

¿Se ha visto alguna vez un negocio que en cuestión de un año pueda tener cientos de miles de usuarios e igualmente se cierre?. Google Wave es un ejemplo. Esta ha sido una mutación que no ha podido sobrevivir al entorno pero que seguramente nos habrá dado ideas de lo que nos gustaba y de lo que no. Por ello, cuando Google dice que ellos celebran también los fallos, transmite la idea de que crear mutaciones en el mercado es bueno para que se generen herramientas y productos más espectaculares todavía.

6 ago 2010

JavaHispano Podcast - 078 - Introducción a Integración Continua

Publicado un nuevo número del podcast de javaHispano. En esta ocasión realizaremos una charla que tratará de integración continua. Nuestros invitados serán Alfredo Casado y Manolo Carrasco (commiter del proyecto Hudson). Durante la charla hablaremos de que es Integración Continua y para que sirve dando algunos consejos para iniciarse con esta tecnología.

Links de interés:

Blogs:

A proposito de la introducción, ponemos un link a un fragmento del documental "Historia Secreta de los Hackers Informáticos" donde se puede ver los inicios de unas 23 empresas de informática, de entre ellas Apple. Aquí se destaca la importacia de la motivación, la ilusión por la tecnología y el compartir información para crear este nuevo sector. Pulsar aquí para ver el fragmento.

Pulsar aquí para acceder a la noticia.

4 ago 2010

JavaHispano Podcast - 077 - Mujeres en comunidades de software libre (Grupo centroamericanas)

Publicado un nuevo número del podcast de javaHispano. En esta ocasión Abraham Otero entrevistará a Helen Ocampo, Gaby Mejia y Maria del Carmen Castillo. En esta ocasión hableremos de la participación de las mujeres en comunidades de software libre. Se tratarán temas como el porcentaje de profesionales técnicos en ambos sexos y el porcentaje en comunidades. Adicionalmente, comentarán problemas o circunstancias al participar en estas comunidades y, finalmente, hablarán del proyecto centroamericanas en el que se pretende fomentar la participación de la mujer en estas comunidades.

Links de interés:

Mujeres Centroamericanas por el Software Libre

Otras iniciativas:

Audio en formato OGG.


Finalmente, a proposito de la entrada ponemos un link a una tira de humor sobre el tiempo de desarrollo de un cambio en software. Pulsar aquí para acceder.

Pulsar aquí para acceder a la noticia

2 ago 2010

JavaHispano Podcast - 076 - Programación de Videojuegos OnLine (Entrevista a Andrés Sahún)

Publicado un nuevo número del podcast de javaHispano. En el número 62 hicimos un podcast sobre programación de videojuegos de manera general. En esta ocasión entrevistaremos a Andrés Sahún que nos hablará del desarrollo de videojuegos online en base a su experiencia. Andrés es participe de la creación de un videojuego online que dispone de una comunidad y ganó un concurso de emprendedores en un canal de televisión local. A partir de ahí, creo la empresa y se dedica a gestionar dicho videojuego así como una arquitectura para videojuegos genérica.

La entrevista estará dividida en varias partes. En la primera parte Andrés nos hablará del videojuego y como se le ocurrió la idea. En la segunda parte pasaremos a la parte técnica y pasaremos a hablar a como está desarrollado, como se ha realizado el diseño y que problemas técnicos tuvieron en la historia del mantenimiento del software. Por último, hablaremos de otras circunstancias como las consecuencias de participar y ganar el concurso, la creación de la empresa y la atención a la comunidad.

Links de interés:

Pulsar aquí para acceder a la noticia