domingo, 22 de julio de 2018

Ejemplo de uso de interfaces

Por poco contacto que tengan con la programación orientada a objetos (POO), muy probablemente han escuchado de las interfaces. Esas cosas que no son clases, pero que éstas (las clases) implementan. Que no se pueden instanciar y sus funciones no están implementadas, pero que no son clases abstractas. Si lo anterior suena confuso, no se preocupen, está escrito para que suene así.

Las interfaces son un concepto clave de la POO, pero que a la mayoría se nos complica entender de primera instancia. En mi caso, no las entendí sino hasta que tuve que solucionar un problema donde realmente eran necesarias. Así que, para intentar ayudar con eso, les dejaré un ejemplo en el que las interfaces son una buena opción, mucho mejor que la que encontré en el proyecto del cual extraigo el ejemplo. Cabe mencionar que no es el código tal cual, por cuestiones de confidencialidad, pero la escencia es la misma.

La situación es la siguiente: "Se tienen varias instancias de clases diferentes. Las clases no tienen propiedades en común. Lo único en común es que éstas se deben poder compartir en forma de texto plano". Por ejemplo:

lunes, 9 de julio de 2018

Conjetura de Goldbach (Prime sum)

En matemáticas, la Conjetura de Goldbach es uno de los problemas más famosos que existe y que aun están por demostrarse (De ahí que sea conjetura y no teorema), el cual, en resumen dice:

Todo número par mayor que dos, puede escribirse como la suma de dos números primos.

Pero el día de hoy no vengo a hablarles sobre ésta, sino a traer un código que obtiene esos dos números.

Realmente, el código lo utilicé como respuesta para éste problema de interviewbit.com, y me gustó cómo quedó.

El código completo lo pueden encontrar en ésta dirección. Aquí sólo iré explicando lo que hacen los diferentes bloques.

lunes, 25 de junio de 2018

Tipos de pensamiento

Hace unos cuantos días, me encontraba platicando con dos de mis mejores amigos y como casi siempre pasa con ellos, uno de los temas de conversión giró en torno al ámbito profesional.

Para poner algo de contexto, somos amigos desde la secundaria y, aunque no nos vemos ni hablamos muy seguido, siempre estamos ahí cuando se necesita. Mi amigo es licenciado en derecho, mi amiga administradora de empresas y yo ingeniero en Ciencias de la Computación (Aún no me acostumbro).

Lo que me inspiró a escribir esto, es que en cierto momento de la plática, mientras mi amigo comentaba que como trabajadores somos reemplazables y que tenemos no más de 10 años para aprender todo lo que puedas y montar algo de manera independiente, me llegó a la mente una plática que tuve con un roomie donde él decía justo lo contrario.

Para poner más contexto, esta otra persona trabaja como ingeniero en sistemas en un empresa cuyo nombre desconozco, pero lo importante es que su punto de vista era que, sin importar lo que hicieras, nadie más debía entenderlo. Según él, si los demás saben qué y cómo estás haciendo las cosas, pueden contratar a alguien más para que te reemplace a futuro; pero si sólo él lo entiende, entonces no van a contratar a nadie más y tiene seguro su trabajo.

Para no dar rodeos, concuerdo (hasta cierto punto) con lo que dijo mi amigo, y estoy en total desacuerdo con lo que mencionó mi roomie.

Hablando como programador, desde la universidad (y ahora en la industria) me ha tocado ver proyectos buenos y malos, proyectos que ves y piensas "Wow, quisiera ser así de bueno algún día" y otros en que te preguntas quién hizo tanto daño a la persona que desarrolló el proyecto para haber hecho semejante desastre. Con los primeros es un placer programar, con los segundos te acostumbras a pensar "¿Qué carajo con esto?", "¿cómo demonios es que está funcionando?", "Me lleva el diablo" y más, con cada función que revisas y tienes que arreglar/refactorizar/eliminar. Así que lo que puedo decir al respecto es que no, hacer las cosas mal, de tal manera que sólo tú lo entiendas, no garantiza que vas a conservar tu trabajo; quizá al siguiente le tome 5 veces más de tiempo trabajar con ese proyecto, pero de una u otra manera, lo va a sacar.

Mi opinión es que, sin importar el proyecto (Y realmente aplica para cualquier área), debes hacer el trabajo de la mejor manera posible. Intentar dejar el proyecto mejor que como lo encontraste. Quizá no te va a asegurar un trabajo (Siendo honesto, nada lo hace), pero sí te ayudará a conseguir otros en caso de que sea necesario.

De mi anterior trabajo aprendí que no basta con que el producto funcione, sino que tiene que estar bien hecho. Que si algo no te queda claro cómo funciona, no lo hiciste bien. Que si al leer el código, hay partes que no se ven bien, seguro están mal y debes arreglarlas, y más importante, que no hay que entregar chingaderas.

En resumen, y como alguien alguna vez lo mencionó, cambiemos de mentalidad, no hay que apostar por mantener un empleo, sino por ser el mejor en lo que seas que hagas. Citando al Chicharito: Imaginémonos cosas chingonas, ¡Carajo!

Saludos.

sábado, 3 de marzo de 2018

¿Se necesitan matemáticas para programar?

Antes de comenzar, quiero dejar en claro que esto refleja única y exclusivamente mi opinión. Continuando...

"¿Se necesitan matemáticas para ser programador?" Esta es quizá la pregunta más recurrente que hacen las personas interesadas en iniciar una carrera dentro del área de Ciencias de la Computación y afines. Y la respuesta corta es: Sí*, se necesitan.

Hace un par de días, por recomendación de YouTube, vi un video de un dude (con 17 años de experiencia como programador, como lo menciona en él) que hablaba sobre detalles a considerar si quieres dedicarte a la programación. Más que nada aborda las desventajas de la profesión, como lo son las muchas horas que se pasa sentado.

Sin embargo, en algún punto del video, también se hace la pregunta del título de este post, y su respuesta es: NO. Parafraseando a esta persona: "No se necesitan matemáticas. No necesitas ser un matemático para ser programador, un programa son instrucciones que se ejecutan una después de la otra, simple lógica."

Ahora, si bien concuerdo con que no necesitas ser un matemático para programar, no estoy de acuerdo con la declaración de que no se necesitan matemáticas para programar. Es más una discordancia por la manera en que lo dijo que el mensaje real detrás de las palabras.

martes, 20 de febrero de 2018

Matriz caracol: Prueba 2

Hace tiempo escribí un post para crear una matriz en la que los números se escribieran en espiral usando DFS. Si bien el algoritmo funciona, es lento ya que revisa las 4 posiciones adyacentes del punto en que se encuentra en cada llamada.

Habiendo dicho lo anterior, hay una forma mucho más sencilla, eficiente e intuitiva para lograr lo mismo, la cual dejo abajo.

viernes, 30 de diciembre de 2016

Matriz caracol en C++ (Prueba 1)

Cuando recién entré a la universidad recibí un curso propedéutico de parte de un profesor y un par de alumnos de (en ese entonces) tercer semestre. En dicho curso nos pusieron varios ejercicios de programación, entre los cuales hubo uno que no puse resolver por más que intenté.

Pasó el tiempo y olvidé que no lo había resuelto, pero hoy mientras cavilaba lo recordé y se me ocurrió ver si ya era capaz de resolverlo. El problema en sí es sencillo, pero para los conocimientos que tenía en aquel entonces no me sorprende que no lo pudiese resolver.

El problema es "La matriz caracol", que no es más que imprimir una matriz de tal manera que los números sigan una espiral (Ya sea de afuera hacia adentro o viceversa).

miércoles, 19 de octubre de 2016

Bugs estoréricos

Comienzo a escribir esto siendo las 11:27pm del 18 de octubre del 2016 y teniendo mil y un cosas más importantes que hacer (quizá no mil, pero sí 5 o 6) pero tenía muchas ganas de escribir sobre esto.

Como ya lo he mencionado en múltiples ocasiones por aquí, estudio una carrera relacionada con Ciencias de la Computación y, como en cada carrera, hay memes relacionados. Dentro de la carrera de ISC, y afines, quizá el meme más famoso sea el del punto y coma. Sí, punto y coma ";". Para aquellos que no estén inmersos en la programación, en muchos de los lenguajes de programación (o al menos en la mayoría de los más comunes), lo que marca el fin de una instrucción es un punto y coma.