Programate algo - Programming Blog/Blog de Programación

Spanish version / Versión en Español Lately, there's been a buzz in the IT world about "Serverless" technologies. The term can be a bit misleading, because there is still a server machine doing server-side processing; the key difference is that when we talk about a "serverless" environment, the whole server infrastructure is managed by a third party. In a serverless environment, a developer only needs to provide his custom server-side code, and the platform will take care of running it when suitable. This takes the concept of cloud computing taking things off developer's hands a bit further. Let's recall those different kinds of cloud offerings and try to fit serverless there: IaaS : Infastructure as a Service. The cloud vendor offers an interface for the users to manage their infrastructure: servers, databases, and networks, using a special interface. That way, the user can allocate and consume computational resources using a pay-as-you-go mo...

Versión en inglés / English version Últimamente, ha habido un revuelo en el mundo IT sobre tecnologías "Serverless". El término puede ser un poco confuso, porque sigue habiendo una computadora haciendo procesamiento del lado del servidor; la diferencia clave es que cuando hablamos de un entorno "serverless", toda la infraestructura del lado del servidor es manejada por terceros. En un entorno así, un desarrollador sólo necesita proveer su código a ejecutar del lado del servidor, y la plataforma de la nube se encargará de desplegarlo y ejecutarlo de manera conveniente y escalable. Esto lleva el concepto de cloud computing de delegar cosas a la nube un poco más allá. Recordemos los distintos tipos de servicios de cloud e intentemos meter a Serverless en esa lista: IaaS : Infastructure as a Service. El proveedor de cloud ofrece una interfaz para que sus usuarios manejen la infraestructura: servidores, bases de datos, redes y otros recursos. De esta manera, e...

Spanish version / Versión en Español Problem : In a .NET Web API app, inside a class which extends ApiController, it is desirable to receive an object in both XML and JSON format, in the most transparent form possible. Receiving the whole XML as a string, or using attributes (.NET's annotations) in the class to serialize are not acceptable solutions. What tends to happen is that the object is always set to null when calling the method. There are various possible solutions, among them adding an "=" at the beginning of the POST message body. But doing so is not optimal, because it's a .NET specific convention and would limit us (if a partner used an HTTP client made with C++ running on Linux, we'd be in trouble). We cannot receive a string directly because that would prevent us from receiving the object in JSON format. Solution : Receive the object with the attribute (.NET annotation) [FromBody], and enable the xml serialization inside our controller. A...

Versión en inglés / English version Problema : En un aplicación .NET de tipo Web Api, dentro de una clase que hereda de ApiController, se desea poder recibir un objeto tanto en formato XML como JSON de la forma más transparente posible. Recibir el XML como string, o poner atributos (las annotations de .NET) en la clase a serializar no son soluciones aceptables. Lo que suele ocurrir es que el objeto siempre llega como null. Hay varias soluciones posibles, entre ellas anteponer un "=" al principio del cuerpo del pedido POST. Pero eso no es aceptable, porque es algo específico de MVC y nos estaría limitando (si nuestro partner hace un cliente HTTP en C++ y Linux vamos a tener problemas). Tampoco podemos recibir un string porque eso nos impediría recibir JSON. Solución: Recibir el objeto con el atributo (en el sentido de annotation de .NET) [FromBody], y habilitar el serializador xml en nuestro controller. Un lugar ideal para hacerlo es en el constructor estático de...

Spanish version / Versión en Español Say we want to change the database host because we changed our hosting service provider. We happily edit parameters.yml and upload it back up to the server, but we still get the "Connection timed out" error. The solution is clearing the cache, but without direct access to the server, doing that via FTP might take ages. In my case, a simpler solution was to delete only the app/cache/prod/appProdProjectContainer.php file, which seems to be where Symfony 2 caches its parameters. I'd like to personally thank the debug_print_backtrace() function. If you use it, make sure to do so with the DEBUG_BACKTRACE_IGNORE_ARGS flag, or you will get an illegible chunk of text.

Versión en inglés / English version Supongamos que queremos cambiar el host de la base de datos porque migramos de hosting. Lo cambiamos alegremente en parameters.yml , pero sigue dando el error "Connection timed out". La solución es borrar la cache, pero si no se tiene acceso directo al servidor, hacerlo por FTP puede demorar una eternidad. La solución en mi caso fue borrar sólo el archivo app/cache/prod/appProdProjectContainer.php , donde aparentemente Symfony 2 cachea los parámetros. Quiero agradecer cordialmente a la función debug_print_backtrace() de PHP. Si la usan, asegúrense de invocarla con el flag DEBUG_BACKTRACE_IGNORE_ARGS, o les va a salir un choclo ilegible.

Spanish version / Versión en Español You might have run into this scenario: a Windows application, which uses native/unmanaged C++, works perfectly fine in your development box. But in the productions environment, it crashes and a message like this one appears: Sometimes, that exception can be caught with a try-catch block. But in other cases such as an Access violation, division by zero and similar ones, it can't be caught. Windows offers a specific solution for this: the __try - _except block, but it has some limitations . Specifically, it can only capture SEH exceptions. And those must be enabled on a project basis for this to work. A better alternative, which is the one we'll analyze next, consists in using the SetUnhandledExceptionFilter function from the Kernel32.lib library . This allows us to catch the exception, but how can we get more information? Well, it is possible to obtain a stack trace by using additional functions from the psapi.lib and dbghlp...