Este es un anuncio para trabajar en: STRONGHOLD ASSET MANAGEMENT.

STRONGHOLD ASSET MANAGEMENT (SAM) es un fondo de inversión donde nos dedicamos a financiar operaciones de desarrollo inmobiliario. Es decir somos el socio capitalista para un promotor que quiere construir por ejemplo una promoción de chalets. SAM por lo tanto es una empresa a medio camino de una FINTECH y una PROPTECH. Puedes curiosear la web https://strongholdam.com/ para entender un poco mejor qué es lo que hacemos.

Un poco de historia

En torno al año 2016 Matt Calner, nuestro socio director, llegó a Madrid procedente de Londres, con la intención de establecerse en Madrid. Según sus propias palabras, la mejor ciudad del mundo.

Una vez aquí se dio cuenta de que existía una posibilidad de negocio ya que había dificultades para obtener financiación inmobiliaria. Había producto, había mercado, pero el principal freno era la financiación. Y con esta idea en la cabeza y espíritu emprendedor, se asoció con algunos inversores, conocidos y amigos, y empezaron a hacer operaciones pequeñas, principalmente préstamos puente y reestructuraciones de deuda.

En el año 2019 se fundó oficialmente SAM y en 2020 entró como socio de referencia Goldman Sachs, los que financian al FC Barcelona, con una línea de crédito de 100 millones que ha ido incrementando con el paso del tiempo.

Dentro de este camino de maduración de la compañía, a mediados del año 2020 nos contactan para desarrollar una plataforma que les ayude en su trabajo diario. Calculo de intereses, generación de certificados, gestión documental, etc. Lo que sería un pequeño proyecto de solo unos pocos meses nos llevó a finales del 2021 a incorporarnos a tiempo completo en la compañía.

Momento clave

Durante el 2021, con una plantilla realmente pequeña hemos sido capaces de financiar proyectos por un importe de más de 120 millones de euros y el objetivo es poder duplicar esa cifra cada año. Creemos que es un momento clave para los objetivos de la compañía, y queremos que nos ayudes a materializarlos.

¿Qué cosas tenemos en mente?

Estas entre otras cosas es lo que queremos hacer en el medio plazo.

• Continuar mejorando y optimizando las herramientas y procesos de la plataforma que ya tenemos.
• Mejorar la inteligencia de negocio para ofrecer información útil en tiempo real.
• Internacionalizar la compañía.

A nivel de IT nos gustaría.

• Mejorar nuestras habilidades para producir código cada vez más confiable, sostenido por una buena test suite, y que se pueda ampliar / modificar fácilmente.
• Innovar añadiendo nuevas piezas a nuestra infraestructura.

¿Qué vas a hacer?

En tus primeros días

• Conocer a tus compañeros, familiarizarte con el entorno de trabajo y el código que ya tenemos desarrollado.
• Comenzar a asimilar toda la terminología / conocimiento que necesitarás para desarrollar tu trabajo.
• Resolver algunas issues sencillas.

En algunas semanas

• Resolver issues que requieran un mayor conocimiento del proyecto.
• Gestionar tu trabajo diario, desde la toma de requisitos, hasta poner el código en producción.

En algunos meses

• Ayudar a definir y ejecutar la estrategia de IT, en base a los objetivos y necesidades de la compañía. SAM es una empresa orientada a resultados.
• Formar al equipo en aquello que creas que puedes aportar.

¿Con que lo harás?

• La pieza principal de la arquitectura está desarrollada en un monolito sobre Symfony 5.4 y PHP 8.1
  • Nos preocupan los principios SOLID y el contenido del libro CLEAN CODE, aunque no somos talibanes.
  • Tenemos test funcionales ( smoke test ) + test unitarios, que se ejecutan además de en local, en un entorno de integración continua.
• Un poquito de javascript + bootstrap.
• git + github.

¿Cómo es el equipo?

Serás el tercer compañero de un pequeño equipo de IT. Somos un equipo horizontal, autónomo y ágil. Tenemos total libertad para hacer lo que queramos.

Alvaro Cebrián

Apasionado de la tecnología y la informática, le encanta probar todo tipo de tecnologías y lenguajes nuevos que van saliendo. Aunque a nivel profesional está más enfocado en el desarrollo web, también le divierte programar mis aplicaciones de escritorio, en otros lenguajes como C o aplicaciones móviles para Android.

• https://www.linkedin.com/in/alvarocebriangarcia/
• https://github.com/alvarocebrian

Daniel González

Cree que nada es imposible si se hace con pasión y honestidad.

• https://www.linkedin.com/in/desarrolla2/
• https://github.com/desarrolla2

¿Qué buscamos?

Indispensable

• Experiencia consolidada en las todas o casi todas las siguientes tecnologías.
  • PHP, Symfony, MySQL, Git, Linux, JavaScript, Bootstrap.
• Sólidos conocimientos de programación.
  • Principios SOLID, test unitarios y funcionales.
• Capacidad para entender y proponer soluciones a problemas de negocio. No nos pagan por resolver issues, nos pagan por ayudar a la compañía a llegar al siguiente nivel.
• Alto rendimiento en el día a día, somos un equipo pequeño, pero muy productivo.

Interesante

• Conocimientos en el mundo financiero y/o del mercado inmobiliario.
• Analítica de datos.
• Comunicación en inglés.
• Docker.

¿Qué ofrecemos?

• Lo básico
  • Contrato indefinido / 23 días de vacaciones / flexibilidad horaria.
  • 100% remoto, o si lo prefieres puedes venir a nuestra oficina en Castellana 60, Madrid.
  • 40k - 70k brutos anuales.
• Otros perks:
  • Formación continua.
  • Cheques restaurante / guardería / transporte / seguro médico.
  • Viaje anual de toda la compañia. Viaje a una conferencia del equipo de IT.

¿Quieres participar?

Si estas interesad@ ¡Queremos crecer junt@s!.

aplica aquí

No obstante hemos elegido un stack que se encuentra a la cabeza de la innovación en el desarrollo de proyectos web, para ofrecer el mejor servicio para nuestros clientes.

En esta entrada queremos explicarte cuáles son las diferentes partes que lo componen. Por supuesto dependiendo de las necesidades de cada proyecto algunas de las piezas pueden variar.

PHP / SYMFONY

Symfony es un marco de trabajo para el desarrollo web que ha revolucionado el desarrollo en este lenguaje de programación. Es en nuestra opinión el mejor marco de trabajo para este tipo de proyectos que existe en la actualidad, así lo hicimos en nuestra charla en Symfony Live, la conferencia oficial y la más importante en relación con el framework Symfony.

BOOTSTRAP / GRUNT / LESS

Bootstrap es un marco de trabajo que facilita el desarrollo de interfaces responsive para aquellas empresas que no son especialistas en este tipo de trabajo.

Compartimos el cartel con gente tan importante en esta comunidad como: Fabien Potencier, Javier Eguiluz, Nicolas Grekas o Ryan Weaver. Es un honor compartir cartel con todos estos grandes desarrolladores. Puedes ver el panel completo en este enlace.

Desde aquí dar las gracias a la organización por confiar en nosotros. WE LOVE YOU!

¿Qué es Symfony Live?

Symfony Live es la conferencia oficial y la más importante en relación con el framework Symfony. En ella se tratan temas relacionados con el framework, con el ecosistema php, con las tendencias en buenas prácticas en el ámbito del desarrollo de software.

Esta será una edición online, en la que se pierde una parte importante de la esencia de acudir a un evento, y es conocer y relacionarte con profesionales y empresas del sector.

Sin embargo al ser online tienes la ventaja de que el límite de asistentes no es el espacio disponible en la sala de conferencias, por lo que posiblemente la audiencia será mucho mayor. Además las charlas quedarán grabadas, por lo que los asistentes podrán verlas de nuevo en cualquier momento.

¿De que vamos a hablar?

Todavía no hemos preparado la charla por lo que el contenido está definido del todo, pero la charla tiene el título "refactoring with phpstorm", por lo tanto hablaremos de dos cosas que ya hemos profundizado bastante en este blog y en nuestro canal de youtube que es de código limpio, y de edición con phpstorm.

Dar una charla siempre es una oportunidad para aprender, por lo que de aquí al 7 de mayo vamos a estar poniéndonos a tope para mejorar estos contenidos y añadir nuevos, leyendo nuevos libros como por ejemplo el "Refactoring: Improving the Design of Existing Code" de Martin Fowler, al que le teníamos ganas.

Mezclando estos cuatro conceptos: symfony, clean code, refactoring, y por supuesto nuestro editor favorito, phpstorm, creo que nos puede quedar una charla más que interesante.

Estate atento al blog y al canal, por que probablemente publicaremos contenidos relacionados próximamente.

¿Por qué nos encanta participar en este tipo de eventos?

Como ya hemos dicho dar una charla en un evento, especialmente cuando tiene mucha repercusión es una situación que te pone al límite. De golpe estás fuera de tu zona de confort, y vas a tener que enfrentar ante una audiencia de mucho nivel, que ha pagado por verte y que no se va a sentir feliz ante una charla de baja calidad.

Es por esto que debemos enfocar esto como una oportunidad para:

1. Seguir aprendiendo, y profundizando en el ámbito del contenido de la charla.
2. Demostrar que desde una empresa pequeña como la nuestra y con unos recursos contenidos se pueden hacer cosas de mucho nivel.
3. Dar visibilidad a nuestra marca.

Si todavía no tienes tu entrada y quieres hacerte con ella, puedes conseguirla en este enlace.

¡Nos vemos por allí!

bloques de código

Por regla general deberías evitar el uso de comentarios. Los comentarios pueden parecer una herramienta muy útil ya que cuando estamos desarrollando puede que nos encontremos con que queremos explicar mejor cómo funciona nuestro código o por que hemos tomado una determinada decisión.

Pero cuando usamos un comentario de código donde antes teníamos un problema: que nuestro código no era suficientemente sencillo de entender, ahora tenemos dos: nuestro código sigue sin entenderse con facilidad, y ahora además debo ocuparme de mantener los comentarios que he realizado.

Puedes pensar que mantener ese comentario no es mucho trabajo, pero que tal si esa energía qué has gastado en mantener un comentario la hubieras gastado en hacer algo más productivo. ¿mejor, no?.

Vemos un ejemplo con el TokenStorage del componente Security de Symfony.

namespace Symfony\Component\Security\Core\Authentication\Token\Storage;

use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Contracts\Service\ResetInterface;

/**
 * TokenStorage contains a TokenInterface.
 */
class TokenStorage implements TokenStorageInterface, ResetInterface
{
    // ..
    public function setToken(TokenInterface $token = null)
    {
        if ($token) {
            // ensure any initializer is called
            $this->getToken();
        }

        $this->initializer = null;
        $this->token = $token;
    }
    //..
}

El autor de este código necesitaba hacer algunas llamadas antes de configurar el token. Se dio cuenta que que no era sencillo de entender y que otra persona que viniera detrás probablemente no entendería el motivo de esa llamada, asi que utilizó un comentario para aclararlo todo. ¿Pero que te parece si hubiera hecho esto?

namespace Symfony\Component\Security\Core\Authentication\Token\Storage;

use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Contracts\Service\ResetInterface;

/**
 * TokenStorage contains a TokenInterface.
 */
class TokenStorage implements TokenStorageInterface, ResetInterface
{
    // ..
    public function setToken(TokenInterface $token = null)
    {
        if ($token) {
            $this->callInitializer();
        }

        $this->initializer = null;
        $this->token = $token;
    }

    private function callInitializer(): void
    {
        $this->getToken();
    }
    //..
}

Como ves hemos eliminado el comentario y hemos mantenido e incluso mejorado la expresividad, ya que el código es igual de explícito. Por lo tanto siempre que nos veamos en la necesidad de añadir comentarios, debemos plantearnos si podríamos mejorar la expresividad de nuestro código mejorando los nombres que estamos utilizando o extrayendo métodos como en el ejemplo.

DocBlock y documentación autogenerada

Algunos editores de texto añaden documentación de forma más o menos automática que permite indicar los tipos de los argumentos y del valor devuelto, así como información adicional.

Veamos un ejemplo

    /**
     * get movements
     *
     * @return array
     */
    public function getMovements()
    {
        return $this->movements;
    }

Este tipo de documentación no aporta ningún valor adicional ya que simplemente está repitiendo lo mismo que ya dice el nombre de la función. Quizá esto tenía sentido antes de la versión 7, para ayudar al IDE en el autocompletado. Pero a partir de esta versión es mucho mejor eliminar estos comentarios y utilizar el tipado nativo del lenguaje.

   public function getMovements(): array
    {
        return $this->movements;
    }

Usos permitidos

Por supuesto el autor contempla algunos casos en los que sí estaría permitido y justificado el uso de comentarios.

Licencias y textos legales

Es un uso completamente justificado el incluir la licencia y otros textos legales en el encabezado de nuestros ficheros. Además esto no supone ningún trabajo adicional, por que es habitual utilizar sistemas que se encargan de añadir estos comentarios de forma automática, y además los IDE suelen ocultarlos por lo que no molestan.

APIs

Si estás construyendo una api y probablemente quieras generar la documentación a través de algún sistema automático, sí estaría justificado el incluir toda esta información adicional en tu código.

Confunden al lector

En general los argumentos booleanos confunden al lector. Veamos un ejemplo, con una clase del componente Config. Esta clase en concreto es la responsable de buscar un fichero de un determinado nombre en un array de paths definidos en los que se podría encontrar.

namespace Symfony\Component\Config;

/**
 * FileLocator uses an array of pre-defined paths to find files.
 */
class FileLocator implements FileLocatorInterface
{
    // ..
    public function locate(string $name, string $currentPath = null, bool $first = true)
    {
        // ..
    }
   // ..
}

¿Sabrías decirme qué hace exactamente el tercer argumento? Quizá tengas la siguiente intuición, si le pasamos true probablemente devolverá la primera coincidencia, pero ¿qué ocurre si le paso un false?. Si realmente quiero entender esta función voy a necesitar ir al código y leer que es lo que hace.

Una vez que ya nos hemos leído el código entendemos que el funcionamiento es el siguiente:

• si le paso un true, me devolverá la primera coincidencia
• si le paso un false me devolverá todas.

¿No se lo pondríamos mucho más fácil al lector si somos explícitos de esta forma?

namespace Symfony\Component\Config;

/**
 * FileLocator uses an array of pre-defined paths to find files.
 */
class FileLocator implements FileLocatorInterface
{
    // ..
    public function locateAll(string $name, string $currentPath = null)
    {
        // ..
    }

    public function locateFirst(string $name, string $currentPath = null)
    {
        // ..
    }
   // ..
}

Como siempre esto no significa que debamos duplicar el código, ya que probablemente podemos encontrar la forma de que uno llame a otro o utilizar funciones privadas más pequeñas, para evitar cualquier duplicidad.

Hace dos cosas

En muchas ocasiones un argumento booleano indica que la función hace dos cosas diferentes. Como ya vimos en la entrada dedicada a funciones, estas deberían hacer una única cosa y deberían hacerla bien.

Veamos un ejemplo con el componente DomCrawler de Symfony. Este componente permite crear un cliente que simula ser un navegador y que se utiliza en pruebas funcionales y para tareas de scrapping.

La función que vamos a ver se llama después de haber ejecutado una query sobre un documento HTML $message = $crawler->filterXPath('//body/p')->text();

namespace Symfony\Component\DomCrawler;

/**
 * Crawler eases navigation of a list of \DOMNode objects.
 */
class Crawler implements \Countable, \IteratorAggregate
{
    // ..
    /**
     * Returns the text of the first node of the list.
     *
     * Pass true as the second argument to normalize whitespaces.
     */
    public function text(string $default = null, bool $normalizeWhitespace = true)
    {
        // ..
    }
    // ..
}

¿No da la sensación de que el segundo argumento responde a una necesidad del programador que a una decisión de diseño? ¿Quién realizaría un diseño así? Obviamente el siguiente ejemplo es mejor.

namespace Symfony\Component\DomCrawler;

/**
 * Crawler eases navigation of a list of \DOMNode objects.
 */
class Crawler implements \Countable, \IteratorAggregate
{
    // ..
    public function text(string $default = null)
    {
        // ..
    }

    public function normalizeWhitespace(string $text)
    {
        // ..
    }
    // ..
}

Y una vez realizado este diseño, ¿no parece evidente que normalizeWhitespace debería ir en otra clase? esto lo veremos más adelante en la entrada dedicada a las clases.