Madiva Soluciones http://localhost/MadivaWeb Fri, 16 Mar 2018 10:17:32 +0000 es-ES hourly 1 Six steps to the Accidental DBA Nerdvana http://localhost/MadivaWeb/archivos/645 http://localhost/MadivaWeb/archivos/645#respond Thu, 15 Mar 2018 12:13:58 +0000 http://localhost/MadivaWeb/?p=645 Spoilers ahead. You have been warned.

In small companies there is the occasional role of the Accidental DBA (type that into an Internet search portal if necessary… from 10.000 feet it’s just about a developer taking sysadmin/devops responsibilities), these are typically less-than-part time occupying tasks one of your developers is taking care of, with more or less success and conformity.

The Accidental DBA is in great trouble, so let’s get straight to the helping tips for her/him.

Step #1 – Understand your mission as the cork of the bottle.

Imagine this wine is the evil shenanigans you have to confront, you are the cork preventing evil from spreading out of the bottle. That, my friend, is your job.

#1 – Be aware of your responsibilities.

In other words, the first thing you are going to learn, no matter if one way or the other, is you have to make sure the first time an incident happens is the last one. That’s the reason they are called incidents. If not, they are another different thing. If you are just a little meh about this, resign now while it’s not too late.

Step #2 – Get in charge and show them who is in charge now.

You belong to me.

#2 – Get those folk the f$%^ out of there.

Quite a part of your problems come from your fellow developer colleagues, so never too soon to begin retaliating back. Mercy is for the weak.

Find some kind of way to establish a private or semiprivate repository. Ensure the persistence of your knowledge after your death by bringing read write credentials to a selected part of your team, never more than half of your team and in no case more than two or three trustworthiest fellow developers. Ask them not to change your stuff unless in moments of great need, or if absolutely necessary, like your holidays or so.

You need to do this as is pre-charging a bill on your team in payment for all the future pain you are yet to get (#5 later on this document). Also your stuff is not their thing, things being strict. And many of them most probably won’t even really care, even though they possibly are making like it seems they do. And they really have important business-related development stuff to do anyway. It works the same as with management. You want them for they free you from having to deal with their stuff. They are your Accidental DBA abstraction layer. So you are going to be OK on your own… Most likely.

Step #3 – Know everything all the time.

Theo knows everything about you all, and Penny is eager to find you and kick your ass.

#3 – Get a big enough information delivery pipeline.

Following the article about automated service and server information delivery up with this mini raid into the particular facet of the Accidental DBA needs. Adding up to the scarce information your cloud provider is giving you about your data bases, each one of them (or the alternative dedicated agent/s) should report your platform’s vitals residing in your data bases. What? You say you don’t have any of those? Think again. Believe us, your platform has vitals residing in your data bases. Either as information or as meta-information. You are going to know.

If you can’t really run code on all your data bases because you don’t know, or you suck at it, or it seems you can not do in all or any of them can not; just code something written in your favorite programming language, abstract it in a way you can host it in different forms, but don’t try to code every one of them at once and please please please do a favor to your future self and make it not only simple but do the actual main deployment of it in a server-less style.

Chances are you have to manage a multi vendor data bases ecosystem, so look carefully what do you need to abstract data base operations regardless the exact type, vendor, family, and even paradigm if you can. Even though mileage may vary, we encourage you to write a connection (or cursor, ugh… don’t get dirty with the technical insights right now…) wrapper using a well known (if possible also well known to your team) programming language for which data base libraries are already written for all the vendors and families of all your data bases; it’s not hundred percent sure, but chances are you are going to need either Java or Python here. Too bad those two are not at all the better languages to code in 2018, fortunately soon those will be just a remembrance.

Step #4 – Release an endless storm of fire.

Long you have waited until this cathartic day when you finally come to enforce the rules you already warned of.

#4 – Automatic issue management.

An issue is the same as an incident, it just was detected early on its buildup and got taken care of before becoming an actual incident.

Establish a process (meaning,.. a business one, you know) to limit the data base connections of all the data bases at the company, not just the SPOF master/s, or your read write data bases, but also the read only replicas; or your abstract cluster or your multi master replicas, if you / your company could afford any of those operation models.

E.g. make sure data base connections are closed when reaching a particular number over a given level, measured on a per-user and per-host and per-application basis. At first it will be hard because your fellow developer colleagues may have not coded their applications in a way so those report their application name, if so, you are going to need to fix that first… and remain vigilant of possible rogue new applications, as long as you are serving as the Accidental DBA of the company.

The last couple paragraphs of the previous step apply verbatim. But do not try to achieve this step together with the previous one, or it is you who will burn in flames.

Step #5 – Face the unknown.

It’s like I’m suddenly in another world. And there I feel… cold.

#5 – Master trans vendor migration.

At some point, if not because management (or, hopefully not, mis-~), eventually stuff and sh will arise and you are going to need trans vendor migration. Arguably the most typical type now is from opensourcedb to proprietarydb, on an unexpected turn backwards of history; but probably as a society we have somehow achieved a maturity were the two directions are happening at the same time in similar rates. If numbers don’t seem to be fitting to your point of view, bear in mind that a large piece of that cake is really about deploying proprietary provisioning of opensourcedb, so assign numbers considering that freedom and surely you can understand the rationale then. The middle in there is actually a quite large grey area you can consider either proprietary or open as you might need.

Moving forward from the digression, at some point you will end up having recently migrated (as in different data base vendor) a data base and turning out that the application tier is not really hundred percent compatible, although in pre-production seemed to. This is a rare case because the data base migrations are not taken lightly, but even so, still stuff and sh can slip and permeate through the intensive screening development folk did. It can relate to a malfunction in a service of your own platform which has worked OK… all the time during and before the migration from its very inception, revealing itself in all its toughness only after the migration seems to be concluded.

This is frightening. If not, you were a bad pick to serve as the Accidental DBA, so shame on your boss/employer! This has necessarily to be frightening because it likely can be the source of the hardest incident in your career as Accidental DBA.

Here at the company, it so far seems we were lucky enough to have detected this one before it caused an impact, and believe us it could have been quite a bad strike. But that has also a lot to do with the fact we collectively decided to go on with the steps towards Accidental DBA Nerdvana way before being hit by an incident that would absolutely have justified it post mortem.

Yeah! We successfully performed trans vendor data base migration, it seems so far! We have a draft trilogy of blog entries about that, hopefully we will release that at some point.

Have this small appetizer: software people use to do this… really really suck.

Step #6 – Remain vigilant.

You need to be always in control, else nasty stuff is going to happen sooner or later.

#6 – Keep the reach towards constant Nerdvana. Don’t let it go down.

If you went that far, congratulations, so your data bases are no longer SPOF (but chances are you are now… yet, in any case, to way a lesser extent than those data bases were when you started); chill out, just a little bit, and keep up the hard work because that’s the true source of Nerdvana. That’s how you keep the evil held back in the bottle.

Sorry for the spoilers.

Throughout this article we picked IP bits from the series LOST, The Walking Dead, The Following, Game of ThronesStranger Things and Black Mirror. Madiva doesn’t own any rights on the six images shown in this post. We care about your intellectual property. So you see we played nice with your stuff, please do the same with ours.


http://localhost/MadivaWeb/archivos/645/feed 0
Operating system updates for pet servers http://localhost/MadivaWeb/archivos/618 http://localhost/MadivaWeb/archivos/618#respond Mon, 26 Jun 2017 06:52:02 +0000 http://localhost/MadivaWeb/?p=618 In a small company with a small team handling few but solid products, a number
of spawned projects for customers, and fleets of cloud machines provisioned for
serving the former; automation is key, even though not always necessarily
silver bullet. True complete automation reached in all technology operations is
utopia, or fake. Do not ever trust such claims.

Any operating system update can break the software, or the operating system,
even the underlying server in extreme cases. If you still have not found the
case, you better start applying operating system updates.

Completely automated information delivery is a different and healthy thing, for
the most part. Everything reducing fog of war in the modern company is key to
success, and maybe not as much recommended as it should be, when compared to
the continuous integration and continuous delivery groupthink of the second
half of the 2010s; not writing about the justified advocacy of the first half.
Current team and collaboration web application madness is good. Proper
resources discovery policies are gold.

Of course the modern platform thinking and current business constraints forces
us to treat servers as cattle, as everybody else, and some the information am
giving will not apply to servers such as web, application, data base read
replica servers or under certain safe k failure conditions elements in a read
write data base cluster. All of these am referring jointly as the pack.

Think more of a server that is ultimately responsible for the complete build of
absolutely everything. Or maybe a temporary architectural single point of
failure for convenience. Or instead something not critical at all, maybe not
even critical enough to be in the build and server orchestration
configurations, like to be expired proceedings for expiring customers. Think
about the phased death of biicode. Few companies disappear from dusk till dawn,
fewer technology platforms, even fewer in the case of technology platforms
intending becoming a build toolchain component. Bear in mind every single
company is doomed to disappear or else being intervened or merged. I just long
not to be there already when it gets to happen.

The pack action by default is just bring up a fresh machine and wipe out the
previous. For each case meriting distinction from the pack, a proper balance
must be reached when deciding update patching policy, between reaction speed to
the dreadier menaces, platform stability guarantees, low traffic hours, if any,
and operator time and involvement in the assessed stages of the proceedings, if

It does not really matter the degree of operator involvement with patch
applying you could want to use, like it or not, either way you are going to
know what your mileage is needing, and you are going to do what is cheaper in
your mileage.

Proper information delivery procedures are, instead, a must go. It is actually
quite simple, have here a snippet for servers info delivery:

You get to have a proper server discovery procedure first to populate your
server portfolio. That gets up to you, out of the scope of this article.

$srv_portfolio GETS RESULT OF CALL TO $populate_srv_portfolio

FOR $server IN $srv_portfolio DO

  (*   '$type' is probably kind of an enumerated type, pun intended. *)
  $type GETS RESULT OF CALL TO $assess_type PASSING $server

      CALL TO $check_for_updates PASSING $server AND $type

(*   Here is where you do IRC instead of Slack,
 * for it is free so you won't get sold by. *)
CALL TO $deliver_msg

That is all. Keep it simple. Nice pride ’17, stay safe, and do not take
anything for granted. Please do the challenge if you already have not.


http://localhost/MadivaWeb/archivos/618/feed 0
Why and how to use UTC http://localhost/MadivaWeb/archivos/588 http://localhost/MadivaWeb/archivos/588#respond Mon, 13 Feb 2017 09:14:21 +0000 http://localhost/MadivaWeb/?p=588 And other intelligent devices and inventions like using UTF-8 whenever can be
used, and why not forget nor close thyself to other formats like official time
or ISO-8859 formats.

Previously it has been written about official time zones. Their use have been
deprecated. They have been ridiculized, as being a standard based upon the
familiarity of a system that was a great advance on its day, but now not only
is not useful, but a drag for technological advance and human health. This is a
literal reading.

What is actually intented is just the internalization that official time is an
arbitrary instrument from a time in which it was necessary to solve several
problems, that today can be solved better using alternative procedures,
therefore its use could be stopped, if we wanted. It will be stopped, when the
proper time for that comes. That internalization, openness of mind, is an
important exercise, came to help overcoming the imminent generational gap
between people already in the workforce today and those who are little
children (native in perpetual war against terrorism, native in mass
surveillance and geolocation, native in ubiquous and ‘of things’ Internet) when
confronting time management problems with a brain different in plasticity.

This internalization does not mean the action to be performed should be
radical, maybe we even prefer anchor to our customs because having crystalized
the part of our brains that manages it, but now already warned in order to be
able to understand the future; in many years from now, people critizicing this
little part of the system.

GMT (Greenwich Meridian Time) is one part of those customs, but special,
different from the remaining. Because, not joining discussion about if it is
technologically a redefinition of UTC or is UTC that is defined as a series of
operations to be performed over GMT, in its essence UTC is like it is very much
because of GMT being like it is, and it is similar because of the time
standardizing process started when the United Kingdom (where Greenwich is) was
the greatest of the great powers.

As introduced, UTC is very important. In the globalized world, time
synchronization is most important than ever before. When UTC does not get used
problems often arise. Think about some potential cases ahead:

The potential average consumer of data from social media companies’ APIs most
probably will not care which is the time of the day information gets published.
We are thinking about this prototypical online news (or whatever) source. Now
think about the typical naive but sophisticated startup focusing on applying
machine learning procedures over data from social media. Companies like this
are kind of a plague and arise in numbers just by scratching the Internet. Say
those are the remaining 20% consumers of social media APIs that actually do
care about local time of publishing. Those kind of initiative needs applying
kind of a procedure to turn moments of airing UTC encoded into local time.

Guess what? Not only publisher local time is missing from social media APIs.
Even though there can be no doubt global social media work embracing UTC
internally, paradoxically UTC is completely missing from their surface APIs.
But UTC is actually a big part of the solution to this problem, no matter the
procedures. Turns out so hated damm and obsolete official time zones,
disrespectfully anti human, can be leveraged for some profit.

Enough about the good part of the good story. There are potential not so
successful cases. Have a look on this one: greeks unexpectedly using local time

Winter at last came, but the worst is yet to come. Some people in a work group
in Greece send data to another work group, including dates, not labeled with
any time zone. It is assumed that everything is in a corporate environment in
which data comms are obviously using UTC, until the day comes of data having to
be transmitted in real time, discovering with horror data is coming one hour
ahead CET, local time zone of the receivers at that moment, instead of one hour
behind, as would correspond to UTC, which everyone in random company would have
expected as the only reasonable default. So two hours ahead UTC, the time zone
in which is based all business logic core software, zealously tied to UTC
during development.

A comms problem happened, and some people had been sending data in their own
local time, for a while, and that means lost time (pun not intended), if it can
not be recovered. To recover, it has to be taken into account not only time of
people are different from that of other people, but data is also tied to each
implicated time zones and daylight saving schemes, that are driven by
government, so they might not be the same and here human (broad sense)
anarchism joins the play. Even so, this all is the good part of the potentially
bad story.

Now for the bad part of the bad story. A system in Madrid, commissioning a
proposal of routing to a component outsourced or being held to Greece, must
move an autonomous vehicle in Germany, but starts moving with a five minutes
delay. Turns out an engineer supervising the operation has restarted the
application now including a patch to override dates, because the car was
discarding frames it was receiving referencing a future that not even knows
will exist. This would be the last time that team did not use assertions over

All this mess applies to ISO-8859 character encoding sets exactly the same,
with potentially terrorising stories about multiple chaining of badly applied
conversion stages of character encoding. Those would be very similar in
essence to the introduced potential cases.


http://localhost/MadivaWeb/archivos/588/feed 0
http://localhost/MadivaWeb/archivos/573 http://localhost/MadivaWeb/archivos/573#respond Mon, 12 Dec 2016 08:09:45 +0000 http://localhost/MadivaWeb/?p=573 El título de este artículo debería haber sido EXCLUSIONES EN BASE AL PRODUCTO CARTESIANANO CON LIMITACION POR IGUALDAD DE CLAVE EN PARES DE DOCUMENTOS DE SISTEMAS DE PERSISTENCIA UNIX SIN SINTAXIS SQL, esto parece ser un poco largo para un documento Markdown como título, finalmente se ha abreviado en NOTA TÉCNICA #20161200 porque aunque pierda capacidad descriptiva va a seguir siendo igual de fácil de referenciar, que es de lo que se trata al fin y al cabo la escritura de artículos, aparte de que intentemos hacer algo útil para la mayor cantidad de gente posible y que todos aprendamos algo; y porque la alternativa era escribir en docutils’ reStructuredText o LaTeX, lo que en principio habría sido una formalidad excesiva para un artículo de blog.

En esta breve y sencilla nota tecnica se explica la aplicacion de exclusiones y composicion sin SQL sobre documentos a nivel de interfaz de linea de comandos, lo más genéricamente posible intentando maximizar la compatibilidad y los destinatarios.

Desde los comienzos de la ahora tan de moda ciencia de datos, en el popular modelo relacional las tablas de datos están relacionadas entre sí mediante claves, y debido a que por motivos de uso eficiente de disco los conjuntos de tablas debían de estar normalizados, la relación de tablas de datos entre claves ha venido definiendo unas serie de operaciones muy típica.

Muchas de estas relaciones son muy parecidas o pequeñas variaciones del producto cartesiano de la matemática aritmética matricial, sólo con la única diferencia de que normalmente se hace una limitación en los resultados por igualdades de claves. Por ejemplo con dos tablas que hacen un uso eficiente de recursos de persistencia:

| country |
|  id | code_two | code_three |    short_name |            complete_name |
|   0 |       us |        usa | United States | United States of America |
|   1 |       ca |        can |        Canada |                   Canada |
|   2 |       mx |        mex |        Mexico |    United Mexican States |
| ... |      ... |        ... |           ... |                      ... |
| 314 |       ss |        ssd |   South Sudan |  Republic of South Sudan |

|  user |
|    id |    name | country_id |
|     0 |  Alicia |          2 |
|     1 |     Bob |          0 |
|     2 |    Carl |          1 |
|   ... |     ... |        ... |
|   108 | johndoe |          0 |
|   ... |     ... |        ... |
| 32993 |    Ziva |        314 |

| video |
|    id | user_id |                   name | cycles |
|   ... |     ... |                    ... |    ... |
|     4 |       0 |          star wars kid |    ... |
|   ... |     ... |                    ... |    ... |
|     8 |       1 |      dramatic chipmunk |    ... |
|   ... |     ... |                    ... |    ... |
|    15 |     108 |                badgers |    ... |
|   ... |     ... |                    ... |    ... |
|    16 |       1 |               narwahls |    ... |
|   ... |     ... |                    ... |    ... |
|    23 |       2 | crazy german gamer kid |    ... |
|   ... |     ... |                    ... |    ... |
|    42 |       0 |           keyboard cat |    ... |
|   ... |     ... |                    ... |    ... |

El uso del espacio es eficiente porque cada video no almacena ningún detalle acerca de su autor/a sino una referencia minimal a su fila correspondiente en otra tabla. Lo mismo para los usuarios respecto de sus países.

Para recuperar más rápidamente el número de videos que tienen los usuarios de una nacionalidad determinada, por poner un ejemplo, o cualquier otro cálculo combinación aritmética y/o algebraica de los datos contenidos en las tablas; se pueden hacer desnormalizaciones, que son operaciones muy interesantes, son la persistencia, o por lo menos el inventariado en el sistema para su posterior recuperación continuada, de una serie de operaciones aritméticas y/o algebraicas sobre otras tablas de datos u otras desnormalizaciones. Suena versátil, ¿verdad? Lo es. Está lejos de permitir todo lo que se le exigía a la ciencia de datos en los años diez del siglo veintiuno, pero ayuda bastante.


La operación de ejemplo que se mencionaba, el número de videos subidos por usuarios de una nacionalidad determinada, podría tener p.e. el siguiente aspecto:

SELECT country.code_three, country.short_name, COUNT(*)
FROM country
JOIN user ON = user.country_id
JOIN video ON = video.user_id

Analizándolo por partes, revisamos primero una parte menor de la expresión, ésta es:

FROM country
JOIN user ON = user.country_id
JOIN video ON = video.user_id;

La estrella indica, para entenderlo fácilmente, mostrar todas las columnas. El resultado será el siguiente, se muestra en modo expandido para mejorar su legibilidad:

---------- = 0
country.code_two = 'us'
country.code_three = 'usa'
country.short_name = 'United States'
country.complete_name = 'United States of America' = 1 = 'Bob'
user.country_id = '0' = 8
video.user_id = 1 = 'dramatic chipmunk'
video.cycles = ...
---------- = 0
country.code_two = 'us'
country.code_three = 'usa'
country.short_name = 'United States'
country.complete_name = 'United States of America' = 1 = 'Bob'
user.country_id = '0' = 16
video.user_id = 1 = 'narwahls'
video.cycles = ...
---------- = 2
country.code_two = 'mx'
country.code_three = 'mex'
country.short_name = 'Mexico'
country.complete_name = 'United Mexican States' = 0 = 'Alicia'
user.country_id = '2' = 42
video.user_id = 0 = 'keyboard cat'
video.cycles = ...

Se produciría una explosión de combinaciones a consecuencia del uso de la operación de producto cartesiano, sin embargo al existir una limitación de combinaciones por identificación de pares relacionados, el conjunto de salida tiene la misma cardinalidad que el conjunto de entrada de mayor cardinalidad, el cual será probablemente o la tabla de vídeos o la de usuarios, según detalles de la plataforma que no nos interesan, pero no necesariamente en un sistema en inicialización (bootstrap).

Retomando la operación que queríamos introducir:

SELECT country.code_three, country.short_name, COUNT(*) AS videos_ct
FROM country
JOIN user ON = user.country_id
JOIN video ON = video.user_id

La salida sería estructuralmente así:

| country.code_three | country.short_name | videos_ct |
|                 us |      United States |     78557 |
|                 ca |             Canada |      1728 |
|                 mx |             Mexico |     65537 |
|                ... |                ... |       ... |
|                 ss |        South Sudan |       163 |

El uso de la agrupación por columna y operaciones sobre columnas de otras tablas relacionadas distintas a la que hospeda a la columna sobre la que se agrupa comprime notablemente los resultados y entrega “nueva información” habitualmente combinación lineal de la información utilizada como base.

En sistemas UNIX desde tiempo inmemorial (al menos desde 2004 en FreeBSD) se puede hacer composiciones (al menos las más simples) en ficheros, sockets, comunicacion entre procesos o cualquier otro flujo de caracteres; sin necesariamente usar SQL; ya que se incluye un programa (join) al efecto.

Para los operadores de los históricos sistemas AIX, HP-UX, etc., finalmente ya en extinción; y para los usuarios de GNU/Linux, GNU/Hurd, BSD o sus derivados (notablemente Darwin); esto no es ninguna novedad. Para algunos usuarios de OS X podría serlo. Ellos pueden reproducir los ejemplos explicados más o menos fácilmente. Para los usuarios y operadores de sistemas Microsoft puede que sea un poco más complicado, pero también deberían poder usando Cygwin.


Sean A y B documentos de alguno de los sistemas de persistencia parte de un sistema computacional, y ficheros, además de documentos, ya que contienen fichas; se piden los elementos de A no componibles con elementos de B (en base a una determinada clave de referencia) en un nuevo documento. La clave para la identificación de la relación, para hacer la composición, será la primera columna en A y la segunda columna en B. Para minimizar la confusión con las letras minúsculas, que van a representar celdas de información en los documentos, usaremos demo0 para referir A y demo1 para B.

$ cat demo0 demo1
$ _

El programa cat sencillamente concatena e imprime los contenidos de todos los documentos cuyo nombre es listado a continuación de la palabra. A modo de demostración, el documentodemo0 tiene cinco filas y tres columnas, mientras que el documento demo1 tiene dos filas y ocho columnas. Más adelante se mencionarán las magnitudes habituales en estudios y procesos de negocio en explotación.

El programa que hace la composición propiamente dicha es join:

$ join -t ';' -2 2 demo0 demo1 | tee demo2
$ _

Como paso intermedio adicional para obtener lo que se pide, una forma fácil de proceder es obtener filas con el formato igual que en demo0.

$ awk -F ';' '{ print $1 ";" $2 ";" $3 }' demo2 | tee demo3
$ _

Se obtienen las filas de A deseadas (para ser excluidas de A y así obtener lo que se pide) en el formato exacto en el que se encuentran en A. La explicación que merece este paso no es más que la de que ese programa llamado awk es una de las más utilizadas de entre las múltiples herramientas que existen en UNIX, en donde incluso existen hasta navajas suizas, una de ellas esbusybox.

Si el número de campos es muy elevado, hecho que sucede en la mayor parte de los casos, se usa un procedimiento distinto llamado gensub (que tiene muchos usos posibles, algunos ciertamente arcanos) de esta forma:

$ awk 'BEGIN { f="([^;]+;)" }\
> { print gensub("("f"{0})("f"{3}).*", "\\3", "1")}' demo2 | \
> sed 's/;$//' | tee demo3
$ _

Esta es sin duda la mayor de las dificultades en las que se entra en la nota técnica. Por motivos de que el shell fish gestiona los escapados de distinta forma a otros shell más antiguos (no sabemos si esto ocurre también en zsh porque no lo usamos ni lo hemos usado nunca), si se ejecuta esto en fish habrá que sustituir la secuencia “\\3” por “\\\3”. Básicamente la llamada a gensub (sustitución generalizada) está indicando que se va a hacer una vez la sustitución (tercer argumento) de la tercera parte (segundo argumento) de una expresión regular que contiene varios patrones (definición previa de f y primer argumento) por nada (argumento implícito).

Si se ha conseguido el paso anterior entonces finalmente se puede obtener lo que se pide en un último paso atómico.

$ grep -F -x -v -f demo3 demo0 | tee demo4
$ _

Extracto de man grep, la opción ‘-x’ ordena considerar la coincidencia a nivel de línea, la opción ‘-v’ marca la exclusión (negación de la coincidencia) sobre la inclusión que se hace por defecto, y la opción ‘-f’ indica que los patrones serán tomados de un documento (demo3) del sistema de persistencia de documentos de la máquina.


Resumiendo y generalizando en un programa (script):

|          |


#   This is free and unencumbered software released into the public
# domain.
#   Anyone is free to copy, modify, publish, use, compile, sell, or
# distribute this software, either in source code form or as a compiled
# binary, for any purpose, commercial or non-commercial, and by any
# means.
#   In jurisdictions that recognize copyright laws, the author or
# authors of this software dedicate any and all copyright interest in
# the software to the public domain. We make this dedication for the
# benefit of the public at large and to the detriment of our heirs and
# succesors. We intend this dedication to be an overt act of
# relinquishment in perpetuity of all present and future rights to this
# software under copyright law.
#   For more information, please refer to <>

#     * Failures are expected for documents not using the same character
#       set encoding as the virtual terminal.
#     * Semicolons are expected as only possible CSV separators

#   This is returned by clean executions.

#   Incorrect usage: arguments count errored.

#   Incorrect usage: wrong argument syntax or semantics.

#   If running on OS X, the `echo` prgoram is being used, because the
# shell builtin might not have the '-n' argument to omit the EOL
# character.
if test `uname` = 'Darwin'
  ECHO=`which echo`

print_usage () {
  ${ECHO} -n "Use like ' WORKING_DOC W_DOC_KEY_INDEX "
  ${ECHO} -n '  Key indexes are expected to be in the interval (0, '
  ${ECHO} '#DOC_COLS_CT] for each document.'

cell_ct_ck () {
  sed s/[^\;]//g <$1 >${TMP_DOC_0}
  uniq <${TMP_DOC_0} >${TMP_DOC_1}
  wc -l ${TMP_DOC_1} >${TMP_DOC_0}
  ct=`awk '{ print $1 }' ${TMP_DOC_0}`
  rm ${TMP_DOC_0} ${TMP_DOC_1}
  if test ${ct} != '1'
    ${ECHO} -n "Document $1 not well formed? Detected non homogeneous "
    ${ECHO} 'cell count int at least two data rows'.

col_ct () {
  sed s/[^\;]//g <$1 >${TMP_DOC_0}
  uniq <${TMP_DOC_0} >${TMP_DOC_1}
  wc ${TMP_DOC_1} >${TMP_DOC_0}
  ct=`awk '{ print $3 }' ${TMP_DOC_0}`
  rm ${TMP_DOC_0} ${TMP_DOC_1}

process () {
  join -t ';' -1 $2 -2 $4 $1 $3 >${TMP_DOC_0}
  awk 'BEGIN { f="([^;]+;)" } { print gensub("("f"{0})("f"{'\
"${I_W_DOC_COL_CT}"'}).*", "\\3", "")}' <${TMP_DOC_0} >${TMP_DOC_1} \
  sed s/\;$// <${TMP_DOC_1} >${TMP_DOC_0}
  # cp ${EXCL_LINES_DOC} ./excl_lines_removeme
  if test $5 = 'OUTPUT_UNSPECIFIED'
    grep -F -x -v -f ${EXCL_LINES_DOC} $1
    grep -F -x -v -f ${EXCL_LINES_DOC} $1 >$6
  rm ${TMP_DOC_0} ${TMP_DOC_1}

if test $# -lt 4 -o $# -gt 5
  ${ECHO} 'Bad usage'
  if test $# -eq 4

#   Correct number of arguments, do basic argument syntax and semantics
# checking.






  ${ECHO} 'One of the input documents is not?'

  if test -f ${OUTPUT_DOC}
    ${ECHO} 'The output document exists?'

#   Check the number of cells per row is homogeneous per input doc.

cell_ct_ck ${INPUT_WORKING_DOC}


#   Check the requested key indexes are valid to each document.

if test ${I_W_DOC_KEY_INDEX} -le 0 \
    -o ${I_W_DOC_KEY_INDEX} -gt ${COL_CT_RETV}
  ${ECHO} -n "Invalid key index ${I_W_DOC_KEY_INDEX} specified for "
  ${ECHO} "document ${INPUT_WORKING_DOC}?"


if test ${I_E_DOC_KEY_INDEX} -le 0 \
    -o ${I_E_DOC_KEY_INDEX} -gt ${COL_CT_RETV}
  ${ECHO} -n "Invalid key index ${I_E_DOC_KEY_INDEX} specified for "
  ${ECHO} "document ${INPUT_EXCLUSIONS_DOC}?"

#   Arguments enough good. Process.




AVISO LEGAL: Todo el contenido de este artículo está sometido a las leyes de propiedad intelectual aplicables a bitácoras en Internet en los estados nación soberanos a los que se adhieran potenciales ofendidos y ofensores en la extensión que decidan los tribunales, salvo indicación en contra por parte ( – entendiendo el artículo (NOTA TÉCNICA #20161200) como el todo – en extensión restringida y fácilmente identificable, además de perfecta e inequívocamente delimitada por los siguientes 5.395 caracteres (y bytes) a partir de la primera aparición de la secuencia ‘#!/bin/sh‘, incluyendo la secuencia referida e incluyendo espacios en blanco (whitespace) en su definición normalizada según la documentación de Unicode versión 9 (aparentemente sin edición en castellano disponible a fecha de entrega de este texto) como character property, terminando en la secuencia ‘# END OF SHELL SCRIPT‘, en la cual prima en lo sostenible por cada marco jurídico aplicable la voluntad de U.P, otorgante de licencia. El documento ejecutable parte (‘‘) ha sido elaborado en su completa extensión por el otorgante de licencia fuera del marco de cualquier relación contractual, en particular laboral, con cualquier persona física o jurídica, en particular Madiva Soluciones S.L., Madiva, fuera de las instalaciones de Madiva (tanto presencial como remotamente (telecommuting)) y del horario u otras obligaciones o responsabilidad laboral del otorgante de licencia para con Madiva, sin que además se haya utilizado ni directa ni indirectamente para su elaboración algún tipo de conocimiento aportado ni directa ni indirectamente por Madiva. El otorgante de licencia es por los motivos mencionados evidentemente el único responsable legítimo de las decisiones sobre el ámbito de publicidad y licenciamiento de parte (‘‘). FIN DEL AVISO LEGAL.

Para quien pueda estar leyendo en tiempo contemporáneo a la escritura del artículo y se pueda estar preguntando por qué un programa completamente en inglés en un artículo de una serie en la que se intenta no usar nada el inglés llegando incluso a forzar el límite a justo antes de introducir palabras nuevas no existentes en Español/Castellano. La respuesta es muy sencilla: tiene que ser así y no puede ser de otra manera. No hace falta argumentación porque su obviedad es tal que no se va a entrar en ese nivel de detalle en este artículo. Sólo existe una carta de excepción que se puede (evidentemente sin ser imprescindible) usar para escapar a esta regla: el caso de software militar en algunos de los estados nación de tradición chovinista, como puedan ser Francia, Italia o España, por empezar correctamente la lista con los casos más extremos de esta particularmente absurda y fútil lacra anti internacionalista.

En Madiva utilizamos una versión supervitaminada (quizás que ya no tiene nada que ver e incluso sin ser ya Shell) del documento ejecutable mencionado para extraer conjuntos de entrenamiento y validación a partir de bases de datos en procesos de negocio que incluyen procesamiento y análisis sobre conjuntos masivos de datos (big data). Un caso típico es que el documento que se representa aquí como demo0 sea de varias decenas de columnas y decenas de millones de filas y que el documento representado como demo1 sea de cientos de columnas y cientos de miles de filas.

Programar es difícil. Aparte de que a algunas personas les pueda resultar más fácil que a otras, o lo parezca, quizás la realidad sea más bien que a algunas personas les puede gustar más que a otras o por lo menos parecer más interesante. En cualquier caso, programar sistemas grandes siempre es complicado. No hacerlo es, SIEMPRE, la alternativa más inteligente. Por eso no quieres obligar a aprender a programar a personas a las que no les resulte sin ninguna duda interesante. Por eso tender a incrementar las tasas de software de alto nivel sobre el conjunto de todo el software, siempre que se pueda, ayuda; escribir programas para tareas de procesamiento por lotes (scripts) ha sido durante generaciones una de las técnicas para hacer eso.

Migrar código C/C++ o Java a Perl, Python, Tcl o incluso shell, o mas recientemente Groovy, Scala o Ruby; antiguamente lo era, cuando las cosas eran diferentes a hoy, que la situación normal es la más deseable de escribir todo en alto nivel en un primer momento, en Scala, Ruby, Python o JavaScript, para luego optimizar procedimientos (workflows) reescribiendo servicios críticos puntualmente en Java o C++, u aplicándoles técnicas de optimización de compilación para Python y JavaScript como Cython, asm.js, TypeScript, Dart, etc., o lo que sea aplicable a Scala, Ruby o similares.

Escribir software de integración también es difícil. Si es posible, es mejor usar software que pueda interoperar suavemente usando interfaces perfectamente definidas, como por ejemplo el protocolo de terminal; en vez de perder el tiempo escribiendo módulos de integración de bajo potencial de reutilización y por tanto minorado valor añadido.


Sí puede existir valor añadido en software de integración cuando este sea un producto en sí mismo. Pero descartad el software de integración que sea malo por su esencia (escrito en Java o Ruby es bastante probable que así sea), o por que percibais dejadez de su equipo de mantenimiento de cara a sus obligaciones para con la versión libre (si ya existe) o más aún respecto de la o las versiones restringidas, o cualquier otra razón que os parezca obvia.

Si trabajando con tareas ETL y se plantea empezar a usar Pentaho (un software de integración en particular), y a primeras de cambio ordenando una conexión a un punto final usando HTTPS Pentaho no soporta eso correctamente para todos los tipos de endpoint, la conclusión correcta es que Pentaho es basura. Si no hay el tiempo y las ganas necesarias para hacer una versión heredera (fork) de Pentaho que funcione de una forma mínimamente respetable, habrá que desistir de usar o intentar adoptar Pentaho.

Esto mismo aplica o ha aplicado a otro software tan dispar como pueden ser: nuevas empresas (start-ups) que envejecen sin terminar ni de arrancar apropiadamente ni de pivotar convenientemente ni de morir (por ejemplo Speaky), buena parte del software freemium supuestamente maduro (por ejemplo CARTO, además de Pentaho) con versión abierta, y afecta también a servicios gestionados sin versión abierta como algunas partes de SourceForge, de BitBucket e incluso de GitHub (véase la clásica discusión sobre GitHub en el mirror GitHub de Linux en mayo de 2012; en realidad todos los servicios de hospedaje de código son bastante malos menos GitLab, por supuesto incluyendo a otros productos minoritarios como Launchpad o CodeCommit, que por algo son minoritarios), o sistemas enteros como obviamente las distribuciones de software no libre de Microsoft (que encima seguían siendo de pago cuando se escribió este artículo), pero se podrían encontrar fácilmente argumentos también contra Mac OS, Amazon Linux, o no imaginemos ya acerca de aparentes contrasentidos como Oracle Linux.

Por poner un ejemplo de aroma que fue especialmente doloroso. Si a medidados de 2016 la guía pública de instalación del software todavía no contempla entornos Debian o Red Hat like(CentOS); mal, muy mal, pero dentro de lo horrible es aceptable. Que sólo contemple Ubuntu pero todavía se mencione la versión 12.04 como la más reciente, es una alerta (sólo una, pero con el tiempo aprenderéis a detectar otras) ya bastante más peligrosa de las que se advienen a la revelación de una base de código con déficits severos de inversión; en un nuevo mundo en el que la paquetería se está continuamente reclicando y reentregando via yum/rpm, apt, npm, pip, brew, pacman y el largo etcétera que conocemos los desarrolladores de software. Los desarrolladores del software normal, no otro tipo de gente especializada y anichada como son por ejemplo los desarrolladores de software COBOL o Java.

Es lamentablemente extra cierto en casos de software hecho en España como Speaky, CARTO o Redbooth. Es público y/o notorio en ciertos círculos que todas estas empresas tienen o han tenido problemas de bases de código deficientemente mantenidas. Como “aquí todos somos amiiigos, chico”; no vamos a revelar quien ha arreglado ya sus problemas y quien no. Porque además no se trata de eso, sino de que todos reconozcamos que tenemos un problema. Después ya discutiremos cuánto de causa es por mala financiación, cuánto por problemas de formación y cuánto debido a la naturaleza del capital humano; qué hechos realimentan a qué otros; y cómo solucionarlo. Al final no se trata más que de la apariencia contemporánea de un problema que ha habido durante generaciones. Si seguimos mirando para otro lado se agravará.

Cerrando esta divagación y ya el artículo, que son 4.096 palabras ya; si te parece bien lo que hacemos, o comprendes que en determinadas circunstancias lo hagamos así pero en general discrepas de la forma o el cómo, puede que tengamos un trabajo para ti. O puede que no en este momento, incluso puede que no nunca de ninguna manera. Aún así quizás quieras arriesgarte a darnos una oportunidad (porque, estáte seguro, no son las empresas las que te dan las oportunidades a ti, es al revés), resuelve el reto ( y puede que aprendas algo de nosotros. Y puede que no. Nosotros procuraremos aprender de ti incluso si por algún motivo esto pueda acabar siendo lo único que podamos aprender de ti.



http://localhost/MadivaWeb/archivos/573/feed 0
Modularidad y reforma progresiva http://localhost/MadivaWeb/archivos/560 http://localhost/MadivaWeb/archivos/560#respond Mon, 24 Oct 2016 06:57:19 +0000 http://localhost/MadivaWeb/?p=560 Ahora se viene haciendo menos, aunque se sigue haciendo; antiguamente era muy habitual tener un PC (un ordenador personal) grande en casa en formato de caja modular, llamada popularmente torre. Los teléfonos al principio solo servían para hablar y más tarde también para comunicar SMS y usar juegos básicos como pong, esto del ordenador en caja era mucho más barato que un portátil y más fácilmente extensible con piezas más modernas según el uso que se le iba dando, partes que se rompían o quedaban obsoletas; según también los usos y necesidades de cada familia y del propio PC.

En algunos software pasa lo mismo. Una misma aplicación se puede montar en diferentes sistemas de ventanas, por ejemplo programas escritos en Python originalmente para Linux usando el enlazado de Python a GTK, uno de los toolkit gráficos más usados en Linux; se pueden usar en Microsoft ya que GTK ahora está disponible para Microsoft.

Al igual que en los grandes sistemas de ingeniería, como UNIX, entendido como un ecosistema de software diverso, alguno muy usado otro menos, en el que hay una serie de máquinas objetivo, una serie de kernel intercambiables, por que respetan interfaces superiores en común, una serie de utilizadores de esas interfaces, por ejemplo programas de usuario como son los programas comunes de línea de comandos que usan los informáticos; las interfaces son parte del sistema también, una de ellas es por ejemplo el protocolo de terminal. Suelen ser, o estar destinadas a ser, estándares, y al final hay muchas piezas que son intercambiables, más o menos laborioso pero muy habitualmente posible.


El protocolo de terminal es lo que define que el método de e/s humano básico en la interacción humano máquina sean caracteres atómicos, en vez de que además de los caracteres esté definida una matriz subyacente de grano más fino para que por ejemplo fuera posible:

  • Mostrar de imágenes nativamente en el protocolo e/s, en vez de ser un artificio del framebuffer; es decir, la riqueza pixel a pixel es siempre un protocolo secundario montado sobre un sistema que soporta al protocolo primario. Su celular funciona así también, otra cosa será si vd. es o no consciente de ello.
  • Usar software programático de dibujo sobre la consola, por ejemplo graphviz.
  • El dibujo libre sobre la consola, clásicamente el dibujo de estilo tortuga, contemporáneamente dibujo con touchpads y pantallas táctiles.

Hay un momento en que los desarrolladores se puedan llegar a plantear cambiar el protocolo de terminal virtual para que proporcione riqueza al nivel de pixel individual, pero hay tantas piezas relacionadas que al final nadie lo hace porque los beneficios de ingeniar el nuevo sistema no justifican el coste que emana de analizarlo rápidamente sin mucha rigurosidad.


La elaboración de un nuevo protocolo de terminal requeriría una adaptación por parte de los núcleos, del servicio de terminales virtuales, de los clientes de consolas, de los programas intérpretes de comandos, finalmente de las aplicaciones usuarias. Por tanto pasarían años desde una posible especificación hasta que el protocolo tuviese una prueba de concepto desarrollada a todos los niveles implicados, debido a la multitud de piezas que habrían de ser adaptadas. Pero se podría hacer, y tendría interesantes casos de uso. Sin embargo en la informática tradicionalmente se vienen prefiriendo los desarrollos evolutivos en vez de los grandes cambios, que normalmente se dejan para cuando no queda más remedio. Este es un motivo para que una inmensa cantidad de software siga utilizando flujos de caracteres para e/s entre procesos y en comunicación humano máquina, siendo algo en principio primitivo y aparentemente anticuado.

Otro motivo es la presencia de alternativas muy razonables. No hace falta fusionar el sistema gráfico al de texto porque el sistema gráfico ya está normalmente suficientemente bien como está (esto es, por desgracia mucho más inestable que el sistema de texto) y el de texto en realidad no necesita más complicaciones ni nadie las quiere, tal como está es mucho más estable y universal que las GUIs y las fuentes truetype, y así y todo tiene su cierta complejidad derivada de que a día de hoy ya por fin soporta todos los lenguajes humanos escritos habidos y por haber.

Además las interfaces de sólo texto son mucho más fáciles de usar que las gráficas, al no existir como problema a mitigar la mala experiencia de usuario, y más importante muchísimo más cómodas y económicas para el operador, al no requerir precisión de punteos, al no existir la imprecisión en el toque, y al ser las unidades atómicas mucho más grandes y adecuadas a la vista, el tacto y el oído humanos.

Las interfaces gráficas siempre son mutuamente incompatibles por su propia naturaleza de no ser un estándar común a todos los informáticos; como sí son los códigos Unicode, los códigos ISO-8859 y similares, las páginas de códigos ANSI y en origen de todos ellos ASCII.


Los códigos de ocho bits están respecto a Unicode en una situación parecida a la hora oficial respecto a una forma nueva de entender el calendario. A la larga los cambios son inevitables, pero en el primer contacto en su contexto de nacimiento son ideas insólitas, exóticas, fantásticas, o ingenuas. En ambos casos, y al igual que si quisiéramos un nuevo gran protocolo de e/s proceso proceso humano, un gran esfuerzo y compromiso técnico es necesario por muchas personas, la propuesta de cambio inicialmente es ridícula e idealista, pero poco a poco la idea va siendo aceptada, finalmente un grupo de personas lo prototipa, los desconfiados van siendo poco a poco menos, se alcanza un punto en el que más o menos todo el mundo quiere adoptar el nuevo sistema, pero sin poder hacerlo, porque todavía suponga una pérdida de compatibilidad; o siquiera declararlo, por rigidez corporativa… Finalmente cuando los sistemas facilitan una interoperabilidad suave para el usuario final se produce una migración masiva.

Pasó con la casete y el compacto, con Lotus 1-2-3 y Excel, pasó en la telefonía móvil, pasó en la gestión del intercambio electrónico de texto escrito, empezó a pasar en la informática personal pero los fabricantes tradicionales supieron jugar bastante bien las cartas y han amortiguado bastante los cambios (que son imparables como todos los demás casos), por poco le pasa a Excel con Docs, los bancos temen con pavor que les pase, pasará con el vehículo de combustible fósil, se empiezan a comentar cosas sobre el vehículo autónomo, tantas cosas… Sólo ponte a pensar…

Siempre empujado por una evolución técnica y sujeto a diversos costes asociados y a la resistencia humana como en los casos que se han mencionado.

En Madiva trabajamos con pasión de forma que nuestros partner que tecnológicamente son más lentos que nosotros cuenten con nuestra mejor paciencia, comprensión y mimo; mientras que aquellos que son más rápidos que nosotros tengan siempre nuestra mejor consideración, atención y consejo.


http://localhost/MadivaWeb/archivos/560/feed 0
http://localhost/MadivaWeb/archivos/545 http://localhost/MadivaWeb/archivos/545#respond Fri, 26 Aug 2016 09:22:39 +0000 http://localhost/MadivaWeb/?p=545 En el principio hubo oscuridad, después hubo cielos, tierras y mares. Las plantas y los animales prosperaron. Apareció la humanidad y se armó para combatir a los cielos y los mares y victoriosa pudo reclamar para sí las tierras y comerciar con ellas y sus frutos.
El día y la noche gobernaba el ritmo de las personas. Grandes civilizaciones aparecieron y las personas pudieron comenzar a dedicarse a observar el cielo y escribir sus observaciones. El Sol fue venerado por ser una de las condiciones necesarias para que los cultivos prosperasen. Múltiples mitos solares aparecieron en incontables culturas.

Screen Shot 2016-08-17 at 12.48.58

Pero gracias a los hidrocarburos, tan irónicamente, se ha perdido una parte de esa veneración por el Sol. En Asturias, junto a la Galicia española, el reloj está puesto a la misma hora que en Województwo ma?opolskie, junto a ????????, la antigua Galicji, sin embargo el día solar difiere en unas dos horas. El paisano de las civilizaciones de la antigüedad se estaría rascando la cabeza ante el absurdo aparente de que a mediodía no sea mediodía.

Esto es un escándalo protesta alguna gente, pero paralizada. Tienen relojes y teléfonos en los que pueden ponerse la hora que les dé la gana, pero no se les oye hacerse esa apología ni siquiera mencionar ningún cambio unilateral en grupo o similar para así forzar un conflicto y acelerar el debate. Entonces hay ahora una discusión sobre si dejar el calendario como está o adoptar un retraso de una hora (dos en verano) para tener el horario que por geografía corresponde a España. Una tercera opción es la obsolescencia de la hora oficial. Interesantemente esto sería tecnológicamente posible en unos pocos meses en cualquier lugar de la OTAN.

Screen Shot 2016-08-17 at 12.53.29

La civilización occidental registra sistemáticamente la posición de todas las personas en todas las tierras, en determinados momentos con precisión al menos al metro.

La astronomía local está, afortunadamente para todos, lo suficientemente estable como para que cualquier persona pueda saber a través de un sencillo mecanismo cual es la hora civil del lugar, esto es, la hora en los términos en los que a mediodía el Sol está en la máxima altura de un lugar cualquiera.

Lo importante no es la hora a la que ocurren las cosas. Esto no le interesa a nadie. Es una ilusión, una costumbre. A la gente lo que le importa es cuándo ocurren las cosas, y dónde.

Con cada aproximadamente 15 grados de arco recorridos (360 grados sexagesimales de la circunferencia que el Sol aparentemente describe alrededor de los cielos, divido entre 24 horas que tiene el día), esto sobre el Ecuador son unos 1670 kilómetros, por ejemplo entre Tours y Wien sin embargo son más de 300 kilómetros menos distancia por la mayor cercanía de los meridianos entre sí en latitudes más cercanas a los polos, pero el dispositivo gestiona estos cálculos con mucha facilidad.

Naturalmente no esperamos que la humanidad se acostumbre rápidamente a que el concierto sea a una determinada hora civil, en la posición que sea, sumado o restado otro tiempo, que en realidad es una distancia, que se deberá recorrer, pero en un tiempo que ahora ya sí se conoce, para llegar allí. Pero la hora oficial tal como se está gestionando hoy en día es un instrumento pasado de una época por fin superada.

Screen Shot 2016-08-17 at 12.48.37

Una serie de profesionales y empresas están revolucionando las relaciones laborales, con trabajo por objetivos en vez de por tiempo, vacaciones decididas en libertad, políticas salariales más igualitarias… no sería muy extraño que personas en esas circunstancias empiecen a plantearse si el estado nación no les estará robando parte su eficiencia imponiéndoles una hora que no se corresponda con lo que para esa persona pueda estar biológicamente preparada. Sabemos que este puede ser un mercado importante, a pesar de ser muy reducido.

Empieza a haber una discusión sobre a qué nos dedicaríamos si el futuro trajera a las tierras muchos más frutos que los que la humanidad pueda consumir. Si finalmente el futuro en ese sentido también actúa dándonos más tiempo, entonces sería posible que sean mayorías los que adopten un sistema de gestión del tiempo basado en la posición en vez de en la convención.

Tarde o temprano los cielos, las tierras y los mares estarán pobladas además por grandes flotas de agentes artificiales. Esto ya ha comenzado, de hecho en los tres elementos. Es una posibilidad que su principal fuente de energía vaya a seguir siendo el Sol. Si eso fuera así, quizás algunos de ellos tendrán que cuidarse de gastar mucha energía por la noche. Quizás aunque seguramente funcionarán con un reloj que vuelve a cero y pasa al siguiente día más o menos cuando el Sol está en la máxima altura en Labasa (Fiji) estén programados para saber perfectamente en todo momento cual será la hora a la que el Sol estará en la máxima en cualquier sitio. Quizás para perseguirlo, desde luego para orientarse, y con veneración por sus absurdos creadores, que siguen utilizando la hora que decidieron unos semejantes suyos que habitualmente lo único que perseguían era su propio beneficio, no el bien común. Qué cosa más bárbara, dañina, y del pasado.

Con unos cálculos muy sencillos que tu dispositivo hoy ya puede hacer en un instante.


http://localhost/MadivaWeb/archivos/545/feed 0
l10n http://localhost/MadivaWeb/archivos/540 http://localhost/MadivaWeb/archivos/540#respond Mon, 11 Jul 2016 08:46:26 +0000 http://localhost/MadivaWeb/?p=540 La gestión de fechas, del calendario, en la informática, no es difícil, pero
sí es laboriosa. Hay diferentes zonas horarias en el mundo, bastante más que
asientos en muchos organismos mundiales [1]. Extremo ejemplo es Indiana, en
donde según qué criterios se consideren hay entre tres y ocho zonas horarias
diferentes [2]. El manejo del tiempo es más complicado que simplemente la
posición en la tierra de cada lugar, ya que los colectivos humanos
arbitrariamente tomamos la decisión política de cambiar la hora,
frecuentemente; y la fecha, aunque esto pasa mucho menos. Esta realidad a la
que la informática tiene que adaptarse deja trazas en repositorios de datos y
código públicos [3]. La gestión de calendarios es aún más complicada [4]
que lo expuesto por motivos que escapan al ámbito de este texto.

Cualquier tratador de datos puede confirmar lo diferente entre el
funcionamiento de las máquinas y los entornos de información imperfecta,
desorganizada, o sujeta a cambios arbitrarios. En el tratamiento de datos la
pureza formal de las matemáticas y sus aplicaciones prácticas choca
habitualmente con la naturaleza de la vida, con la impredecibilidad de la
aparición y detalles y consecuencias de una mutación en una reproducción, o
con la posibilidad de que la voluntad actúe en contra de una predicción. El
caos similar al que ocurre en la gestión del tiempo del que escribimos en el
párrafo anterior se reproduce fractalmente en muchos ámbitos sobre los que
la humanidad ejerce acción, por ejemplo a nivel colectivo en la península
ibérica respecto a varios asuntos… en su medida correspondiente.

En un modo parecido a las decisiones arbitrarias (en el sentido de la
impredecibilidad, sin valorar la justificación que el poder tuviera en el
momento) e históricas que se han tomado políticamente desde la antigüedad en
todo el mundo sobre la hora, la fecha y el calendario, existen arbitrariamente
múltiples formas correctas de referirse a las entidades geográficas a todos
los niveles en todos los ámbitos humanos. Con nuestro afecto por el anarquismo
(en su sentido amplio) generamos continuamente casos de multiplicidad de
grafías aceptadas para los nombres de los lugares [5]. Esto afecta de un modo
u otro a las tareas resueltas por máquinas.

Existiendo además múltiples identidades colectivas que se solapan
geográficamente a otras más generales y comunes, se suman posibilidades a la
forma de referir lugares [6]. En este punto entendemos que la problemática
obliga a aplicar técnicas de consideración por similitudes y a la pérdida de
importancia de unas palabras sobre otras, pero el problema da giros inesperados
debido a casos como que existan lugares como [7] que por nombre tienen una
palabra que en algunas lenguas (otra circunstancia a considerar) es un
artículo definido. Típicamente los artículos pierden importancia al hacer
búsqueda por similitud.

También hay casos en los que los nombres de dos lugares existentes contienen
las mismas palabras [8] pero en distinto orden [9]. Esto requiere la toma en
consideración del orden de palabras. Pero en la búsqueda en texto por
similitudes hay frecuentemente motivos que promueven que el orden no sea

En Madiva nos dedicamos entre otras muchas cosas a la búsqueda de conocimiento
a partir de datos de diversas fuentes, entre ellas las que proporcionan
ministerios y agencias gubernamentales. La naturaleza imprecisa y combativa de
nosotros con y contra nuestros vecinos y colegas añade otro efecto
multiplicador a este problema debido a las dificultades de coordinación y
falta de homogeneidad de criterios entre administraciones públicas, esto no
facilita la relación entre ficheros de datos provenientes de diferentes
organismos oficiales.

La incapacidad organizativa humana, consecuencia del libre albedrío, del
sentimiento mayoritario de jovialidad y tolerancia de las personas, de la
histórica incapacidad logística para el ejercicio del poder, contrasta con
las aspiraciones calvinistas por la sistematización y homogeneización para
facilitar la gestión a todos los niveles de los asuntos que tratan sobre las
personas y su actividad.

La civilización occidental, incontestablemente dominante en política
internacional, contribuye activamente al proceso de globalización, que ayuda a
facilitar la unión y colaboración de la acción humana en todas sus posibles
dimensiones, individual, familiar, gremial, empresarial, política; sin en la
mayoría de los casos ejercer una acción definitiva sobre la defensa o
abandono de las costumbres individuales, locales y regionales en las
dimensiones mencionadas de las relaciones humanas. Esto es la aceptación por
parte de la autoridad política de algo sobre lo que en realidad no puede

Individualmente, cuanto más anticipada y asumida esté esta circunstancia
inevitable, con más preparación se afronta un futuro en el que el individuo
es cada vez menos importante en favor de las redes, la colaboración, y los

¿Sois capaces de cruzar datos de población [10] con datos de empleo [11] a
nivel municipal con un 100% de aciertos?

Hay algunos más municipios (y creciendo) que la cifra en la que estás
pensando. Por supuesto esto implica que la elección entre documentos de unos
años u otros (o cuantos de ellos se consideren) afecta a la longitud de la
solución… Sean sesenta mil caracteres cuadrados la medida de, por ejemplo,
un código de quinientas líneas de largo y ciento veinte columnas (caracteres)
de ancho… ¿sois además capaces de encontrar una solución no usando más de
420k caracteres cuadrados (C), o 230k (C++), 180k (Python), 160k (Java), 140k
(Ruby o PHP) o 130k (Javascript)? Excluyendo el acceso a hojas de cálculo, PDF
y textos ISO/UTF de ese cómputo.

Más acertijos como este en



http://localhost/MadivaWeb/archivos/540/feed 0
http://localhost/MadivaWeb/archivos/517 http://localhost/MadivaWeb/archivos/517#respond Wed, 15 Jun 2016 11:37:30 +0000 http://localhost/MadivaWeb/?p=517 Data Analytics Concept

Ha habido muchos momentos en la historia de la humanidad en los que la irrupción de avances tecnológicos han provocado cambios radicales en nuestra civilización. A todos los niveles.

En la segunda mitad del siglo XVIII la revolución industrial supuso una optimización sin precedentes en los procesos de producción. Dicha revolución trajo consigo otros muchos cambios en medios de transporte, producción y consumo de energía, etc

Más recientemente otras revoluciones han cambiado la forma en que trabajamos, nos comunicamos y en definitiva, vivimos. Pocos años después de la aparición del primer movil (1973, Motorola) una persona podía hablar desde el centro de Tokio con otra en Central Park, algo que hasta ese momento sólo cabía en la ciencia ficción.

En 1991 empezó a funcionar la World Wide Web, que supuso el inicio de la democratización del acceso a Internet a nivel mundial. Desde entonces Internet ha permitido que el intercambio de datos y conocimiento a gran escala entre personas, empresas e instituciones sea un proceso instantáneo. Pronto cualquier “cosa” podrá conectarse a Internet (IoT)

Este cambio de paradigma ha sido el catalizador que ha permitido incrementar exponencialmente la velocidad a la que se producen avances en todas las disciplinas: ciencia, tecnología, negocios, etc. Básicamente ha hecho que la humanidad se convierta en una “mente colmena”: un descubrimiento o noticia es compartido en cualquier lugar del planeta y es inmediatamente consumido por otras personas o procesos.

Como suele ser habitual, las sinergias entre distintas tecnologías dan paso a otras nuevas. Esto es lo que sucedió en 2007 con la presentación del primer iPhone: hoy día nadie concibe vivir sin móvil y sin Internet. Su uso ha sido tan ampliamente aceptado que ha supuesto una espectacular catarsis en sectores en los que hacía siglos que no se introducían cambios: Prensa escrita, Discográficas, Viajes…

Hace dos décadas no quedaba rastro de quién/donde/cuando leía un articulo de un periódico de papel. No había manera de saber que canción escuchaba una persona en su Walkman. No sabíamos como estaban compuestos los círculos sociales de las personas, o al menos no podíamos hacerlo a gran escala.

Analyst Working on Laptop

Hemos llegado por tanto a un punto en el que prácticamente toda la actividad humana genera información. Cada segundo se generan cantidades ingentes de datos que hasta hace poco tiempo era inconcebible manejar. Hoy día, gracias al incremento de la potencia de cálculo de los procesadores, al Cloud Computing y sobre todo a nuevas técnicas de análisis de datos, el análisis de esta información no sólo es posible sino que es inevitable.

Estamos asistiendo a una nueva revolución, que la historia bautizará convenientemente pero que de momento conocemos como BigData.

La aparición del BigData y su conjunción con técnicas de Machine Learning permite ya conocer, explotar y predecir los patrones de comportamiento y de consumo de millones de personas: que consumimos, cuando, donde, con quien.

El conjunto de cambios que estas tecnologías están empezando a introducir en nuestras vidas es ya muy significativo:

– Sistemas de recomendación de todo tipo: productos, amigos, contactos, viajes
– Optimización de flotas y rutas de transporte, precios, stock de productos
– Permite a las empresas mejorar el servicio a sus clientes, a los bancos conocer mejor los riesgos crediticios, a los gobiernos gestionar mejor las infraestructuras…

Esta revolución acaba de empezar así que es difícil predecir a que nuevo escenario nos llevará y que nuevas tecnologías y revoluciones nos están esperando en pocos años.

http://localhost/MadivaWeb/archivos/517/feed 0
Buscamos Full-Stack Developer http://localhost/MadivaWeb/archivos/483 http://localhost/MadivaWeb/archivos/483#respond Thu, 28 Jan 2016 15:20:31 +0000 Buscamos desarrolladores full-stack. Para nosotros son importante las capacidades y conocimientos de front-end pero también en el desarrollo de aplicaciones desde el punto de vista del back-end.

Qué hacemos en Madiva:

  • Buscamos preguntas difíciles, que resolvemos utilizando tecnología.
  • Creamos conocimiento basado en la agregación de información y el desarrollo de algoritmos propios.
  • Utilizamos conocimiento funcional cruzado para dirigirnos a distintas industrias.
  • Innovación con impacto en la cuenta de resultados.

Qué buscamos en ti:

  • Que seas amante de tu trabajo, te sientas orgulloso de él.
  • Seas un defensor del código limpio.
  • No te de miedo abrir un terminal en Linux, usar vi e instalar o modificar cualquier servicio.
  • Que pienses que Git es nuestro pastor.
  • Lo importante es el cliente. Hay que pensar en él como usuario antes que en nosotros como desarrolladores.
  • Pensar que el trabajo bien hecho, es la única manera de hacerlo.
  • Pensar que las plataformas, frameworks, librerías, pasan. Nosotros permanecemos, nos adaptamos a la que mejor cumpla con nuestro objetivo y con el proyecto.
  • Queremos oírte, que participes y que seas parte de las decisiones técnicas de los proyectos.
  • Que te sientas cómodo trabajando con las aptitudes y conocimientos que buscamos.

Qué podemos ofrecerte:

  • Solvencia, profesionalidad y muy buen ambiente de trabajo.
  • Queremos que si algún día nos dejas, seas mejor que cuando llegaste.
  • Tendrás la oportunidad de participar en proyectos interesantes, de calidad y que emocionan a ese niño de 10 años que todos llevamos dentro.
  • Compartir experiencias con un equipo impresionante.
  • Lo desconocido es nuestra motivación y diversión.
Experiencia y aptitudes deseadas
  • HTML5, CSS3 / SASS, Twitter bootstrap,
  • Javascript, jQuery, React.js / backbone.js / angular.js,
  • Java, conocimientos de Struts (MVC),
  • Oracle, PostgreSQL, PrestoDB, Redshift
  • Git,
  • Sistemas de visualización d3.js, Soluciones GIS (CartoDB, Leaflet, OpenStreetMap)
  • Técnicas de agregación / Web scraping
  • Manejo de sistemas Linux, AWS, UNIX
  • Hadoop, Spark

Puedes ver la oferta en Linkedin
Hemos preparado un pequeño reto en el que nos gustaría que participases, para nosotros es importante y espero que para ti también.

http://localhost/MadivaWeb/archivos/483/feed 0
http://localhost/MadivaWeb/archivos/451 http://localhost/MadivaWeb/archivos/451#respond Mon, 18 May 2015 08:28:22 +0000 En Madiva Soluciones siempre hemos apostado por la evolución y el crecimiento, trabajando cada día en nuevos servicios y productos.
Ahora toca cambiar las oficinas, ya que no nos permitían seguir creciendo.
Las nuevas oficinas se encuentran en la dirección   C/ Serrano Galvache Nº56, Edificio Abedul, 4ª planta, CP(28033), Madrid.
También hemos cambiado los teléfonos de contacto.

Línea general : 91 756 84 87
Línea de soporte : 91 756 84 94

Este cambio ya es efectivo.
Por favor actualicen los datos de contacto almacenados por estos nuevos.


http://localhost/MadivaWeb/archivos/451/feed 0