Desbloquear un proyecto atascado

PROBLEMA

El cliente (A) vendió un proyecto a un cliente suyo (B) .

Es un proyecto con varias partes, principalmente de márketing y de desarrollo de un nuevo producto para B.

Todo está bloqueado porque uno de los componentes, una plataforma para poder vender ese nuevo producto, no acaba de arrancar.

El problema de base es que nadie tiene claro como podría hacerse, cuales son los pasos a dar, y por tanto cuánto tiempo puede llevar desarrollarlo o cual puede ser su coste.

Hasta ahora, B ha trabajado siempre con una gran consultora con quien preferiría no seguir trabajando. Todos sus sistemas están controlados por la consultora que es bastante opaca y no les permite ninguna flexibilidad a la hora de hacer cambios.

El nuevo producto debería lanzarse al mercado en tres meses.

CONCEPTO

El objetivo es ayudar y facilitar la toma de decisiones por parte de un cliente (B) del cliente, y aportarle al cliente (A) un presupuesto del proyecto que tiene con B.

Independientemente de cuándo se implemente o cuándo se establezca el deadline para ese proyecto, es necesario diseñar una solución que pueda encajar en tiempo y presupuesto con lo planteado por el cliente (A) a su cliente (B) inicialmente.

Durante la segunda quincena de febrero, se apoyará al cliente en las reuniones que tenga con B.

Además, para antes del día 1 de marzo, se le entregará al cliente un presupuesto de la solución que mejor parezca encajar para completar el proyecto en tiempo y forma, y que contemplará los siguientes puntos:

  • Definición detallada del proyecto.
  • Análisis de los requisitos.
  • Diseño de la arquitectura del proyecto.
  • Descripción de la interconexión de los componentes.
  • Estimación de tiempo de implementación.
  • Estimación del coste de implementación.
  • Posibles altenativas con sus pros/contras.

TIEMPOS

El presupuesto se entregará antes del 1 de marzo.

PRECIO

El precio de este proyecto de análisis es de 1.822,50€.

Nota aclaratoria:

Este proyecto tipo, es un ejemplo de proyecto que se ha realizado o se podría realizar. En ningún caso tiene validez como presupuesto real y sólo pretende documentar las distintas posibilidades que existen.

Actualmente, con los cambios que ha habido en cuanto a las posibilidades existentes, la propuesta podría ser diferente en estos momentos.

Se han omitido nombres de empresas y productos.

Por favor, si tuviese necesidad de algo similar, no dude en ponerse en contacto.

How to implement a distributed OAuth 2.0 system

Some months ago (more than a year), I was playing with the WordPress REST API. I did an analysis about how to implement a distributed OAuth 2.0 system as an attempt to collaborate with the community. I wrote it as a comment over a discussion post, but I am going to replicate that here in order to save it with my other ideas and works.

  • coolapp.com is the site of the app
  • cooldev.com is the WP site of the developer in which I defined the app as multitenant
  • cooluser.wordpress.com is the WP site of the user who wants authorize coolapp.com to interact

01- User access to coolapp.com and says “Hey, I want to use this cool app”
02- coolapp.com ask for its server and user writes cooluser.wordpress.com
03- coolapp.com ask to cooluser.wordpress.com to identify the user
04- the user writes his credentials in cooluser.wordpress.com
05- cooluser.wordpress.com redirects to coolapp.com with a code saying “Yeah, this man is my man”
06- coolapp.com then ask to cooldev.com and says “Hey, I have a user with a code that wants to acces to the resource cooluser.wordpress.com and I am the coolapp.com (this is my client_id and this my client_secret)”
07- cooldev.com generates a token
08- cooldev.com says to cooluser.wordpress.com “Hey, I just generated this token that expires in 3600 seconds”
09- cooluser.wordpress.com says “I would prefer not to work, but you know, it’s ok”
10- cooldev.com sends the response to coolapp.com with the token
11- then coolapp.com using the token, can now ask to cooluser.wordpress.com to do some stuff

If you look at this diagram

Abstract Protocol Flow
Abstract Protocol Flow

Client = coolapp.com
Resource Owner = cooluser.wordpress.com
Authorization Server = cooldev.com
Resource Server = cooluser.wordpress.com

The RFC says:

“The interaction between the authorization server and resource server
is beyond the scope of this specification. The authorization server
may be the same server as the resource server or a separate entity.
A single authorization server may issue access tokens accepted by
multiple resource servers.”

but with some conversation like the one in 8 and 9 it could be resolved.

Patrones cloud: protocolos gossip

Con los protocolos gossip vamos a dar por interrumpida esta serie, en la que hemos hablado de cachés, de particionado y de tablas hash siempre en torno a un ejemplo de Infinitext, un caso realista aunque no real.

Podéis encontrar definiciones mucho más detalladas y con categorizaciones y todo, pero ya sabéis que me gustan las cosas simples y un protocolo gossip simplemente es un algoritmo de comunicación que montas para “que todo el mundo lo sepa todo”.

Seguir leyendo en CantabriaTIC.

Patrones cloud: Tablas Hash

En esta serie ya hemos hablado de las cachés, del particionado, y hoy vamos a hablar de las tablas hash.

Las tablas hash no son más que estructuras de almacenamiento clave-valor. La clave se suele establecer usando el hash de un objeto y por eso se llaman tablas hash. El hash de un objeto es un código de texto que identifica al objeto más o menos inequivocamente, y suele existir un método por defecto en la clase base de muchos lenguajes de programación orientados a objetos: por ejemplo con el método hashCode de Object en Java o con el GetHashCode de Object en C#; aunque habitualmente toca reescribirlo. Pero no quiero liaros, que en realidad para dónde vamos nos importa poco si usamos el hash del request, el nombre del usuario o cualquier otra cosa como clave.

Continuar leyendo en CantabriaTIC.

Patrones cloud: Particionado

Continuamos con esa serie que ya lleva una y dos entregas de soluciones de común aplicación en cualquier entorno pero especialmente en los entornos de nube. Hoy veremos el particionado, que aunque es una solución generalmente poco eficiente, nos puede salvar el culo más de una vez.

Database Partitioning Diagram

Continuar leyendo en CantabriaTIC.

Patrones Cloud: Caché

Si recordáis mi último post (en CantabriaTIC), planteamos un problema: teníamos un servicio en una máquina que tardaba mucho, entre otras cosas por el acceso a la BBDD. Hoy veremos como solucionar eso usando una caché.

Aunque no sepáis nada de la Nube™ esta palabra os sonará, y es que la Nube™ no ha traído nada nuevo (ni siquiera ella misma, pero eso es otra discusión que tendrá que ser mantenida en otro momento). Las cachés se usan continuamente en informática para resolver problemas de acceso a datos como al que nos enfrentamos. El aparato que estés usando para leer esto tendrá una caché física, el sistema operativo que lo corra tendrá una caché virtual y el navegador con el que estés accediendo tendrá una caché de aplicación.

Cache Diagram

Seguir leyendo en CantabriaTIC.

Patrones Cloud: Intro

Aprovechando esa arrancada que ha tenido Cecilio sobre patrones, voy a aportar mi granito de arena ya que leer, escribir, hablar sobre patrones siempre es algo divertido e interesante.

Cecilio no llega a dar una definición, y aunque debería de estar claro con la catalogación y los ejemplos que él ha puesto, pongámosle nombre a las cosas para los que no lo tengáis claro aun: “patrones” es como se llama a las formas de resolver problemas que se repiten. Por ejemplo para un ingeniero de obras públicas que está construyendo una carretera habrá un patrón “puente” que puede usar cuando se encuentra cosas como ríos, vías de tren y otras carreteras, y habrá otro patrón túnel que se emplea casi siempre cuando se encuentra montañas, pero que también se puede usar en otros casos.

Patrones: túnel
Oresund Line, es un puente/túnel entre Dinamarca y Suecia

Seguir leyendo en CantabriaTIC.