Author: Forcén

Hay dos formas de verlo: o eres muy negativo o eres el que piensa en todos los posibles problemas de cualquier situación/feature/email.

Y se aplica a todos los ámbitos, técnicos o no. El problema viene cuando te toca lidiar con dos tipos de personajes: el que piensa que lo que está empeñado en hacer/implementar/arreglar es una buena idea y el buenrollista profesional, también conocido como “a quién se le va ocurrir lanzar un ataque contra nuestra web, si somos guenos”?

En otros universos paralelos es costumbre escuchar a alguien con una cierta experiencia y entender que no dice las cosas por aburrimiento. En apaña lo normal es que los que acaban de salir de un curso rápido de naderías hagan lo contrario de lo que se les ordena o se salten todos los mecanismos/protocolos/devolucionesdefunción de seguridad “porque es aburrido y así es más rápido”. O directamente pregunten “por qué hay que comprobar que el cliente está conectado a la base de datos si ya he llamado a la función de conexión?”.

Así que con el tiempo eres el borde negativo que no se alegra cuando alguien envía un email a una startup diciendo “estupendo lo que habeis creado. me gusta mucho. ¿cuándo puede mi técnico hablar con el vuestro para que lo cambieis para que haga lo que a mí me interesa?”.

Hace poco leí, en uno de esos momentos de relajada investigación (traducción: leyendo blogs al tuntún) una frase de un diseñador: “el problema es que los que tienen que decidir sobre el diseño de un producto no tienen ni idea del tema”. Realmente es una queja muy frecuente entre el gremio. Por ejemplo, esto mismo lo dijo alguien que sufre a diario las decisiones de un departamento de producto. Donde decisiones tiende a incoherencias los días pares e indecisiones los pares.

Hace unos meses sufrí, indirectamente, a ese mismo departamento de producto en cierto ministerio de cuyo nombre prefiero no acordarme. Pongamos, para simplificar, que se llama Mordor: un edificio poblado por tribus de orcoficinistas cordialmente enfrentados (del buenrollismo de funcionario hablaremos otro día).

(more…)

The problem: we want to have a page in several languages. Without having to create one html file for each page for each language.

The solution can be divided in three parts:

1. how to know in which language we must show the page,

2. how to render the “structure” of the pages and

3. how to get the content of the pages.

In this entry I’ll show how to code, in PHP, the fist part of the solution.

(more…)

I was involved in a project this December where, in order to simplify the code and due to some ill-conceived piece of code, it was required to pass some variables from PHP to JavaScript. On other projects you may need to pass arrays or localized text to your JavaScript, for example to show messages. Or to fill a dinamic interface.

There are multiple ways to pass data from PHP to JavaScript: populating hidden inputs or writing the JavaScript into the main page. But I wanted to have a more clean approach.

So, I subclassed a class I wrote some time ago as an utility for handling interface configurations to handle those JavaScript globals without having to worry about the problem in each project. As a result now I have a set of three classes to ease the coding of both configuration strings and JavaScript globals. In appearance very disparate problems, but that use the same basis: magic PHP methods.

(more…)