Programando “de forma normal”

La semana pasada, y de hecho también este lunes, estuvo simplemente fatal. En el trabajo aplicaron la súper estrategia de meter a alguien en un proyecto del que no tiene idea de cómo está compuesto, y le echan trabajo que, como siempre, era para ayer, sin contar que todo está hecho en un lenguaje que ese alguien nunca ha usado y un juguete que simula ser una base de datos (léase “Access”). ¿Necesito decir que ese alguien era yo?

He trabajado en desarrollo de sistemas antes y sé lo que son los tiempos que se manejan en el proceso: nunca son reales y uno tiene que andar a la carrera para poder sacar “los pequeños cambios” que curiosamente salen después de que los requerimientos fueron tomados, aceptados y congelados. Pero quizá lo que más me sorprende es la reafirmación de que en muchos lugares el software que se usa para producción dista mucho de tener una calidad siquiera aceptable, y Japón no es la excepción. Cierto. He visto código que sí está bien hecho, con buen formato y con su respectiva documentación, pero son pocos los casos.

Lo que tocó hacer estaba en C# y la base de datos en Access… simplemente increíble. El código estaba bien estructurado, pero había funciones que realizaban más de una tarea y que eran enormes; comentarios totalmente inexistentes que hacían mucho más difícil de entender lo que el programador pensó al momento de codificar. Lo grave del asunto es que, después de tanto tiempo y de haber trabajado en 3 países, ya considero esto como normal puesto que entiendo que muchas veces se anda a las carreras con tal de cumplir con los tiempos establecidos aunque tu vida social desaparezca por ello.

Justo el buen panda me envió este artículo en el que se habla de lo que aquí comento, especialmente aplicado a programas que manejan acciones de empresas y de cómo pueden hacer perder millones por un simple error. Además de los tiempos, muchas empresas no toman en consideración las pruebas ya que representan un costo extra, y es casi verdad universal que quienes manejan las empresas piensan que con ver correr el prototipo de un sistema es suficiente para decidir si funciona o no.

Aclaro aquí algo: yo también he estado en la situación de que hay que acabar a como dé lugar sin importar cómo quede el código, y estoy seguro que mi forma de estructurar programas puede mejorar. En resumen: no me creo ni soy el mejor desarrollador del mundo. No obstante, estoy completamente seguro de que muchos me darían la razón si vieran el código del que estoy hablando.

De código de investigación ni hablamos. Me da pavor ver lo que hice durante mi estancia en la universidad…

Como quieran y gusten, terminé lo que tenía que hacer en el tiempo que me establecieron, pero para lograrlo me tuve que quedar hasta muy tarde en el trabajo (el lunes salí a las 11:30 pm y apenas alcancé tren a la casa). Sin embargo, hoy ha comenzado a otra parte del proyecto, y para los tiempos que manejan no me va a quedar de otra que echarme un clavado al código ya hecho, entender lo que hace (y viendo como hay valores que pasan por referencia, como las propiedades de los objetos están definidas como públicas… y mejor no le sigo) y reusar lo que sea posible. El problema a resolver es interesante, y de hecho me gustaría pensarlo en términos de probabilidad y hasta algoritmos como el Hill Climbing, pero todo indica que no tengo el tiempo que necesito para realizar el análisis que eso implica.

Con todo, es totalmente un placer decirles que la diferencia entre mi trabajo anterior y éste es como del cielo a la tierra. Compadezco a mis ex compañeros por tener que trabajar en una situación tan estresante.

Aquí seguimos.

 

Encuentra la diferencia – versión Kanji – en Scala

Y ya con este código dejo el tema por la paz. Lo pongo para que quede en el registro:

object Uniques {
  def main(a: Array[String]) {
    if (a.length != 1) {
      println("Need an argument to analyze")
      sys.exit(1)
    }
    else {
      findUniques(a(0)) match {
        case l if (l.isEmpty) => println("All characters are the same")
        case l => l foreach println
      }
    }
  }

  def findUniques(seq: String) =  seq filter {c => seq.count(_ == c) == 1} map {c => "Unique instance found: " + c + " in position " + (seq.indexOf(c) + 1)}
}

Y probando el caso en cuestión:

mmedina@yggdrasil-m:~/Programming/Scala/Tests$ scala Uniques "麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈塵麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈 麈麈麈麈麈麈麈麈麈"
Unique instance found: 塵 in position 66

Hacerlo para que funcione con otros tipos de datos sin cambiar nada de código no es muy complicado.

Encuentra la diferencia – versión Kanji – en Haskell

Lo prometido es deuda. Siguiendo con el escrito anterior, aquí está el código que resuelve el problema, pero ahora en Haskell:

import qualified Data.ByteString as B
import qualified Data.ByteString.UTF8 as U
import System.Environment(getArgs)
import Data.List
import Data.Maybe

main = do
    putStrLn "Write the sequence you want to analyze:"
    B.getLine >>=  processArguments

processArguments :: B.ByteString ->  IO ()
processArguments xs = findUniques $ U.toString xs

findUniques = printUniques . findUniques'

findUniques' :: (Eq a, Show a) => [a] ->  [(a,Int)]
findUniques' xs = let uniques = filter (\i ->  countInstances i xs == 1) $ nub xs
                  in [(x,y) | x <- uniques, y <- mapMaybe (\i ->  i `elemIndex` xs) [x]]

printUniques :: (Eq a, Show a) =>  [(a,Int)] ->  IO ()
printUniques [] = putStrLn "All instances are the same"
printUniques us = mapM_ putStrLn $ map (\c →  ((("Unique instance: " ++ ) $ show $ fst c) ++ ) $ ((" in position " ++ ) $ show $ (+1) $ snd c)) us

countInstances :: (Eq a, Show a) =>  a ->  [a] ->  Int
countInstances _ [] = 0
countInstances c (x:xs)
    | c == x = 1 + countInstances c xs
    | otherwise = countInstances c xs

 

Es un hecho que puedo usar un where en la definición de printUniques, pero bueno, el caso es que funciona:

mmedina@yggdrasil-m:~/Programming/Haskell/FindDifference$ ./fdc
Write the sequence you want to analyze:
麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈塵麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈
Unique instance: '\22645' in position 66

Todo muy bonito, sí. Pero entonces: ¿para qué tanto código en Haskell? Explico:

Continue reading “Encuentra la diferencia – versión Kanji – en Haskell”

Encuentra la diferencia – versión Kanji

Hace unos días, me llegó un retweet con lo siguiente:

【間違い探し☆超超超超上級編】 麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈塵麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈麈 解けたらRT!

El punto es encontrar el kanji que es diferente, y al hacerlo, enviar el mensaje en un RT. Según el principio del mensaje, este problema es de nivel súper-súper-súper-súper avanzando.

“Buena forma de pasar el tiempo”, pensé, pero no para resolverlo “a mano”, sino creando un programa que lo hiciera por mí.

Viendo mis opciones, decidí programar el algoritmo en Python, tanto como práctica como para seguir dándome de topes por lo de las string unicode vs byte strings (quienes saben python entienden a lo que me refiero).

En sí, el algoritmo es sencillo, así que no tomó mucho tiempo:

# -*- coding: utf-8 -*-

import sys

def searchDifferentKanji(strseq):
    utf8Str = unicode(strseq,"utf-8")
    difstr = list(set(utf8Str))

    for c in difstr:
        if utf8Str.count(c) == 1:
            return c.encode("utf-8"), utf8Str.index(c) + 1

    return '',-1

if __name__ == "__main__":
    if len(sys.argv) != 2:
        print "Error: Need a string to check"
        exit(1)
    else:
        difchar, pos = searchDifferentKanji(sys.argv[1])
        if pos != -1:
            print "Different char: " + unicode(difchar,"utf-8") + " in position " + str(pos)
        else:
            print "All characters are the same"

Lo que hago es simple: creo un set a partir de la cadena, haciendo con esto que todos los elementos repetidos se esfumen, y lo convierto a lista, la cual contiene exactamente un carácter por cada carácter diferente en la cadena original. Después recorro esa lista buscando en la cadena si el elemento actual aparece una sola vez; de ser así, es el carácter que estoy buscando, por lo que lo regreso, junto con la posición en la que está.

Existen problemas similares que contienen más de una diferencia, es decir: entre un mar de repeticiones del mismo carácter se encuentran varios diferentes. Para resolverlos, el algoritmo arriba expuesto puede ser sencillamente modificado para que no rompa el ciclo con el primer carácter diferente que encuentre, y agregue la tupla de (carácter,posición) a una lista, que sería el valor que la función “searchDifferentKanji” regresaría.

Como nota adicional, el kanji de ese problema es , que se lee 「しゅ」(shu), y conlleva el significado de “ciervo grande”. El kanji diferente es , con varias lecturas, entre ellas las más comúnes 「ちり」 (chiri), que significa “polvo”, “basura” y 「ごみ」(gomi), que también significa “basura”.

Sí: me queda de tarea hacerlo en Haskell.