Category: Programación

Al ordenar por un campo de fecha los campos NULL se consideran menores que cualquier fecha definida.

Supongamos que tenemos una tabla con tres fechas: 1-1-2020, 1-1-2021 y NULL. Ordenando por ese campo de fecha ASC el resultado es:

NULL
2020-01-01
2021-01-01

y con DESC sería

2021-01-01
2020-01-01
NULL

Si queremos modificar este comportamiento y que al ordenar por un campo de fecha se considere NULL como mayor que cualquier fecha conocida tenemos que añadir un – al nombre del campo de fecha. ¡Ojo! Esto hará que si ordenamos por ASC el resultado sean fechas en orden descendiente y viceversa, así que quizá tengas que tenerlo en cuenta en tu código (en mi caso como es para ordenar una columna de una tabla de datos no importa mucho).

SELECT dateField FROM table ORDER BY -dateField ASC

NULL
2021-01-01
2020-01-01

SELECT dateField FROM table ORDER BY -dateField DESC

2020-01-01
2021-01-01
NULL

Para poder aplicar un selector :focus a una imagen debemos conseguir que sea focusable, y esto se consigue añadiéndole un atributo tabindex.

Cuando usemos la función is_a en PHP debemos usar el identificador completo de la clase:

use App\Models\ItemActiveErrorMessage;


// Esto no funcionará
is_a('ItemActiveErrorMessage');

// En cambio esto sí
is_a('App\Models\ItemActiveErrorMessage');

Si en el dominio en el que queremos integrar Redsys usamos Cloudfare las notificaciones (webhooks) que nos quiera enviar Redsys no nos llegarán porque Cloudfare las bloquea al considerar que no las está realizando un navegador al uso. Bien por Cloudfare, que para mucha morralla antes de que llegue a nuestro servidor, pero mal por el Koas que se tira un día y pico sin comprender por qué el webhook funciona si se llama a mano y no cuando lo hace Redsys.

La solución es incluir una regla en el cortafuegos de Cloudfare para que las peticiones que lleguen desde Redsys a la dirección del webhook no realicen esa comprobación. La forma de hacerlo está perfectamente explicada en esta entrada del blog de Marc Pàmpols.

La integración de la pasarela de pago de Redsys en modo insite es bastante simple pero tiene algunos momentos wtf. Dejo aquí algunos apuntes para no volver a tropezar con ellos en el futuro:

• Hay que hablar con el contacto del banco que nos ofrezca la pasarela y pasarle una lista con todos los dominios en los que vayamos a usarla, tanto de desarrollo como de producción. Esto es lo primero que hay que hacer, hasta que no nos habiliten esos dominios no nos aparecerá el formulario incrustado para meter los datos de la tarjeta.
• No se pueden repetir números de pedido. Si lo hacemos la petición de id de operación se completará sin error pero nos devolverá un id de operación de -1.
• El código de comercio y el número de terminal deben enviarse sin ceros a la izquierda, y el número de pedido debe pasarse como string, si se pasa como número se nos devolverá un error (no un código de error, el iframe solo devolverá la palabra Error).

Actualización: los dos últimos puntos no vienen indicados en la documentación de integración del Santander, pero sí vienen en la oficial de Redsys, así que lo mejor es usar esa.

Hay veces que en una aplicación de Vue tenemos una pantalla donde puede haber un número variable de componentes que el usuario puede configurar, por ejemplo en un dashboard o en una pantalla de definición de filtros.

En estos casos usar la sintaxis habitual para importar componentes se hace tedioso y es más sencillo utilizar el componente de Vue component y un sistema de carga dinámica. En esta página lo explican perfectamente.

TL,DR: en la parte de template definimos el componente:

component(:is="currentComponent")

Y definimos la propiedad computada así:

currentComponent()
{
    let name = "Aquí establecemos el nombre del componente a cargar";
    return () => import(`@/components/Ruta1/Ruta2/${name}`);     
}

Después de releer el libro de Phil Sturgeon Build APIs you won’t hate dejo aquí estas notas a tener en cuenta para el diseño de APIs:

• No usar un número autoincremental como identificador de los recursos, es mejor utilizar un identificador alfanumérico.
• Nombres de los recursos en plural (places, users, etc.)
• Los nombres de los recursos no deben ser verbos sino sustantivos. Por ejemplo, en vez de /users/5/send-message es mejor /users/5/messages
• Para generar documentación: Api Blueprint
• Principales códigos de respuesta:
  • 200 – Generic everything is OK
  • 201 – Created something OK
  • 202- Accepted but is being processed async (like video encodings)
  • 204 – The server has successfully fulfilled the request and that there is no additional content to send in the response payload body
  • 400 – Bad Request (should really be for invalid syntax but some folks use it for validation)
  • 401 – Unauthorized (no current user and there should be)
  • 403 – The current user is forbidden from accessing this data
  • 404 – That URL is not a valid route, or the item resource does not exist
  • 410 – Data has been deleted, deactivated, suspended, etc
  • 405 – Method Not Allowed (your framework will probably do this for you)
  • 500 – Something unexpected happened and it is the APIs fault
  • 503 – API is not here right now, please try again later
• Ejemplo de paginado:

{
  "data": […],
  "pagination" :
  {
    "total": 1000,
    "count": 12,
    "per_page": 12,
    "current_page": 1,
    "total_pages": 84,
    "next_url": "/places?page=2&number=12",
  }
}

En este blog escribo básicamente para mí mismo, pero hay algunos temas sobre los que creo que puedo escribir artículos que realmente sean útiles para más personas. Esos artículos los escribiré (en inglés) en dev.to, que es un portal de contenido para desarrolladores.

Y aquí tenemos el primero, habla sobre cómo usar cabeceras HTTP para ayudarnos a depurar sitios web que están en producción.