ElestudianteFantasma

Hola a toda la comunidad, abro este tema con la finalidad de compartir un poco desde mi punto de vista, los conocimientos y habilidades que debe tener un desarrollador Front End El desarrollador front end no solo debe saber usar JS, CSS3 y HTML5, esas son las habilidades que debe tener como programador pero eso no lo es todo, también debe adquirir las bases del diseño. Un error muy común que se comete cuando uno empieza en este medio es el creer que sentarnos en frente del pc y codear, saldrá toda la magia ahí y el sitio nos quedará muy padre. La verdad es que no, al hacer esto se esta cometiendo un grabe error, este error sera el inicio de una serie de errores que sucederán uno a uno, como el efecto domino. Algunas de las consecuencias de los errores que se pueden cometer, repercutirá mucho en la perdida de tiempo, trabajo en vano, frustración, estrés, etc. para evitar este tipo de circunstancias (o al menos, disminuirlos) es necesario implementar una metodología de trabajo y que sea apropiada, en este caso. Lo primero que se debe hacer es Tener una comunicación con el cliente, con ello, se analizan sus necesidades y limitantes, posiblemente él no tenga mucha idea de lo que quiere , tenemos que orientarlo para poder ser muy precisos y así ofrecerles las soluciones que permitan que el cliente quede satisfecho, una vez concluida esa comunicación, el cliente debe proporcionar el Material y/o contenido que tendrá el sitio web. De preferencia, el material que te proporcione, debe ser accesible, si es texto, que este en un documento de Word o PDF donde se te permita tener una interacción apropiada, si son imágenes, estas no deben necesitar de ningún retoque extra (en el archivo) con extensiones "jpg, png o gif" dependiendo del uso que se le necesite dar (ahora también en SVG). Una vez que hacemos un análisis de las necesidades del cliente y del material, lo primero que debemos usar como herramienta es el lápiz y papel (olvídense de la computadora por el momento), empezamos a hacer algunos bosquejos (Sketch), para plasmar las primeras ideas de como estará la estructura del sitio web (OJO, pura estructura, no nos metemos aun con los colores ni con las fuentes tipográficas), en este bosquejo se identificarán los elementos y se distribuirán con respecto a su importancia, no deben ir las imágenes como tal, solo una representación, eso aplica también para todo el contenido audiovisual (video, audio, texto, etc.). Alguien podría decir ¿por que hacer un Sketch a mano cuando tenemos infinidad de Templates y maquetas prefabricadas que visualmente se ven bien y son accesibles? Mi respuesta es la siguiente: La diferencia entre diseñar un Sitio y usar una maqueta, está en el propósito del diseño en base al material (contenido), podrías hacer o usar 20 maquetas diferentes y posiblemente ninguna se adapte a la necesidad del cliente, El contenido no se debe adaptar a la estructura de la página web, es la página web la que se tiene que moldear al contenido para poder alcanzar los objetivos que se buscan COMUNICAR Ejemplo de un Sketch Al concluir el Sketch, tenemos que hacerle llegar a nuestro cliente, la propuesta, explicando y fundamentando la razón del por que los elementos están distribuidos de esa manera, se pueden llevar algunas propuestas, recibir la retroalimentación correspondiente y aplicar los cambios que sean necesarios, una vez que el Sketch quedo listo, procedemos a usar el equipo de computo.(no se emocionen, aun no estamos en la etapa para codear, no coman ansias ) Con un software de diseño, pasamos los bosquejos que realizamos a mano y lo digitalizamos, revisamos que visualmente se vea bien, que los elementos estés distribuidos apropiadamente (composición) aquí podemos usar las fuentes tipográficas, se recomienda que máximo se usen 3 por página, para no cargar mucho el aspecto visual, aun que lo ideal es usar de una a 2 fuentes, se pueden generar muchas variantes con una sola fuente tipográfica haciendo parecer que sea mas de una. Si el cliente tiene una imagen corporativa, tendrás que trabajar con sus fuentes tipográficas. Las fuentes tipográficas, aun que no lo parezca, juegan un papel muy importante en el diseño y en la comunicación, dependiendo del tipo de fuente, puede transmitir elegancia, modernidad, seguridad, etc. hay que saber elegir apropiadamente de acuerdo al "mercado objetivo" (usuarios) de a cuerdo al tipo de tipografía que elijas, sera la imagen que estarás transmitiendo. hasta este punto, aun no tocamos los colores, hay una regla muy importante: Si se ve bien en blanco y negro y es funcional, la primera etapa del diseño quedo lista. Te preguntaras ¿por qué quedo lista? por qué el Mensaje se está transmitiendo de manera apropiada. Con esto, tenemos terminado la parte del Wireframe (así se llama a este “bosquejo” digitalizado) Ejemplo de un WireFrame una vez terminado los wireframes, nos reunimos con el cliente para mostrarle las propuestas, si el cliente esta de acuerdo, seguimos al siguiente paso, de lo contrario, recurrimos a la retroalimentacion y se aplican los ajustes correspondientes . ahora vamos con E L C O L O R aquí pueden pasar 2 cosas: 1) Si el cliente tiene una imagen corporativa, tendrás que acatarte a los colores que vienen indicados, ya que eso es parte de la identidad de el, por ejemplo, imagina si quisieras diseñar una pagina web para Coca Cola y no usaras el color Rojo, no, ¿verdad? 2) supongamos que el cliente no tiene una imagen corporativa, entonces, tendrás que apoyarte con el poco material visual (logotipo) y la información que tengas del cliente para determinar los colores de la página web, ¿qué información nos es útil? simple, hay un tema llamado Psicología del Color, donde nos habla de los colores cálidos y fríos, así mismo, de las cosas que están relacionadas al color, por ejemplo, el Rojo es un color visualmente muy agresivo, llama la atención con mucha facilidad, está ligado al Amor, la Pasión, el Fuego, etc. En base a la Psicología del Color, a los valores del cliente o (en caso de que no tenga definido la Misión, Visión y Valores) a la imagen que el quiere que se intente transmitir en la web, nos podemos apoyar inicialmente con ello. ahora, tal vez ya tengamos uno u otro color pero ¿Cómo saber si los colores son funcionales y tienen una “armonía en conjunto”? simple, hay una herramienta que Adobe nos proporciona con un navegador web y es totalmente Gratuita, en este momento se llama Adobe Color CC, está en el siguiente enlace https://color.adobe.com/create/color-wheel/ ¿Cómo usamos la paleta de colores? simple, en base a los colores que consideramos apropiados, los introducimos en la paleta de colores, ya sea en formato RGB o el hexadecimal, a mano izquierda tenemos un recuadro que tienes diferentes Reglas cromáticas que podemos utilizar para definir la paleta de colores. Tenemos los colores análogos, monocromáticos, en Triada (muy recomendable), complementarios, compuestos, tonos y Personalizado. en lo particular, me eh sentido muy cómodo trabajando con los colores monocromáticos, en triada y compuestos, si te apoyas con la Adobe CC Color, no sufrirás mucho con los colores. para tener una idea mas visual, pueden entrar a la siguiente pagina, adobe muestra como juega con la rueda cromatica, ejemplo: http://blogs.adobe.com/contentcorner/2015/09/09/create-inspiring-color-themes-adobe-color-cc/ una vez que ya seleccionamos una o algunas paletas de colores, empezamos a implementarlo en el wireframe, nos daremos cuenta que la idea del sitio empieza a tomar vida, puedes hacer algunas propuestas con una o varias paletas de colores, al final, el que se vea que alcanza mejor los objetivos, es la paleta de colores que se queda. Los colores no son algo que se definan por los gustos, se definen en base a si son funcionales y cumplen con los objetivos que se buscan alcanzar en la comunicación. A este archivo colorido, se le llama Mockup, inclusive, en el mockup podemos sustituir los recuadros de imágenes y líneas representativas de texto por el material que nos proporcionó el cliente, de esa forma podemos darnos una idea más completa y real de cómo quedaría el sitio web. Una vez finalizado el Mockup, se presenta al cliente para que le de el visto bueno, de ser asi, ya se puede empezar a codear, de lo contrario, hacemos los cambios apropiados de la retroalimentacion (lo ideal es hacer 3 propuestas) Hasta aquí, podemos decir que puede quedar la parte metodológica para definir como será visualmente el diseño, tanto los sketchs, como wireframes y mockups son entregables que se le hacen al cliente, cada uno en diferentes etapas del proceso, para verificar que la idea es clara y que se busca alcanzar esos objetivos, si haces los mockups pero no le mostraste los wireframes o sketchs al cliente, podrías llevarte la sorpresa de que no esté satisfecho, lo cual, tendrías que hacer cambios, y esto repercute en trabajo y tiempo desperdiciado. Eso sí, si el cliente ya autorizo un wifreframe y a última hora quiere hacer cambios, tu puedes cobrar algo extra por esos cambios que salieron de último momento, ya que fue responsabilidad del cliente al no hacer la observación en el momento apropiado. Hay quienes hacen prototipos del sitio, para ver de una manera más visual como es la interacción, hay 2 tipos de prototipos, los desarrollados en html5, css3 y JS, y los que son creados con herramientas como inDesing, flash, Adobe Xd, puede llegar a ser útil para valorar los efectos, transiciones, etc. (cosas plus, que hacen el sitio visualmente mas dinámico) esta parte ya es opcional, los que lo hacen en html5, css3 y JS, lo desarrollan así para aventajar el en tiempo de producción, una vez que terminan, el sitio queda concluido. Ahora si, ya estamos listos para codear y aplicar todo el conocimiento que tenemos relacionado a la programación Finalmente, lo que para un pintor, su herramienta para dibujar y transmitir su arte es mediante pinceles y tintas, para los front end, sus pinceles y tintas son sus entornos de desarrollo integrado (IDE) y el código que ira en sus respectivos archivos. por ultimo, les comparto lo siguiente que refleja una de mis maneras de pensar. Con esto, finalizo el tema, espero que sea de su gusto y les pueda resultar útil. Pueden dejar sus dudas, sugerencias y comentarios, cualquier cosa, estamos en contacto, Saludos

Hola a toda la comunidad, abro este tema con la finalidad de compartir un poco desde mi punto de vista, los conocimientos y habilidades que debe tener un desarrollador Back End Introducción Un desarrollador Backend, debe tener conocimiento sobre algún lenguaje de programación del lado del servidor (como php, Python, ruby, Java, etc.) y también algún lenguaje de base de datos, sea SQL o NoSQL pero ¿este tipo de conocimientos son suficientes para ser un desarrollador backend? La respuesta es No, puede tener el conocimiento esencial para desarrollar software del lado del servidor pero, si no implementa una metodología para programar, sería como un albañil que quiera construir una casa sin tener los conocimientos del arquitecto, podría terminar la casa, pero no optimizaría los recursos y no tendría la misma calidad que si un arquitecto lo hubiera diseñado. Como desarrollador backend, hay que trabajar con metodología, esto ayudara mucho para prevenir errores, pérdida de tiempo, trabajo, esfuerzo, inclusive nos ayudara a tener un mejor orden, una visión con mejor enfoque a lo que necesita el cliente, etc. Aquí les comparto un poco desde mi punto de vista que conocimientos y habilidades debe tener un desarrollador Backend Analisis de requerimientos, primeros pasos Cuando un cliente nos llama por que tiene el interés de que se desarrolle un sistema informático para facilitar algunas actividades en la vida cotidiana en su empresa, oficina, trabajo o negocio, lo primero que debemos llevar es una libreta y un lápiz o bolígrafo, esto nos permitirá ir tomando nota de las necesidades que el tiene, así mismo, de los recursos que dispone para la delimitación del proyecto, a toda esta parte donde adquirimos toda la información que se necesita para idear el proyecto, se le conoce como Análisis de requerimientos. Una vez que tenemos la información, podemos ir generando muchas ideas sobre como estaría la interacción con los usuarios en los diferentes procesos, posiblemente, si intentamos platicarle al cliente nuestras ideas, el cliente se quede con una expresión muy similar a la siguiente: Diagramas de casos de uso Por muy “sencilla” que utilicemos una terminología como informático, el cliente no nos entenderá para nada, entonces ¿Qué podemos hacer para mejorar nuestra comunicación con el cliente y tener una apropiada retroalimentación para ver que efectivamente estamos abordando el problema de manera correcta? La respuesta es simple, nos apoyaremos con algunos de los diagramas UML, hay de muchos tipos, no todos se llegan a usar a la hora de abordar un proyecto pero si por lo menos se usan los siguientes 4 a los que hare mención, se tendrán muchas facilidades a la hora de abordar un proyecto ya sea de manera individual o en equipo (Los diagramas UML forman parte de la documentación de soporte que debe tener el software), para esta primera etapa de interacción con el cliente, usaremos los diagramas de casos de uso. Este diagrama es muy claro y visual, ya que nos permite representar diferentes tipos de procesos concretos con la interacción de los usuarios y el sistema, aquí tenemos el siguiente ejemplo Caso de uso Registro y Compra en plataforma electronica podemos ver que los actores (diferentes tipos de usuario) son representados por monigotes de palo (stickman), el rectangulo representa el limite del sistema, el ovalo es conocido como el caso de uso, los conectores representan la asociacion de comunicación, si le explicamos las ideas al cliente de esta forma, el puede ver claramente la forma como tenemos visualizado el problema y puede darnos alguna retroalimentacion en caso de que nos haya hecho falta abordar algo. hay otros elementos en los diagramas de caso de uso donde se manejan inclusiones, exclusiones y generalizaciones, yo recomiendo que esto se use unicamente para documentar el software y para comunicarlo con el equipo de desarrollo, ya que al incluir muchos elementos en nuestros diagramas de caso de uso y presentarselos al cliente, el podria llegar a sentirse incomodo al tener una hoja muy saturada de imagenes, asi mismo, podria perder el interes al proporcionar la retroalimentacion y esto nos puede generar problemas a la hora de avanzar con el desarrollo del software (Es muy importante colocar el titulo a cada diagrama de caso de uso, esto nos permitira tener un mejor orden). Bases de Datos Una vez que tenemos concluido el análisis de requerimientos, procedemos a (aun no programaremos ) diseñar el sistema, comenzamos a elegir el tipo de base de datos a utilizar, ¿Cómo podemos determinar que tipo de base de datos es mejor para el proyecto (por lo general, la tendencia es SQL -> Relacional, NoSQL-> no relacional)? Simple, esto se debe a las necesidades que tenemos que abordar, Una base de datos relacional, nos permite tener consistencia en la información, esto quiere decir que el manejador de base de datos nos ayudara a no tener información fantasma, datos perdidos, etc, la desventaja a esto es que las consultas de la información pueden llegar a ser un poco mas lentas y a la hora de escalar el sistema, nos puede costar bastante mas trabajo y recursos tanto de hardware como en $$$$ (cuando un sistema llega a crecer mucho, puede llegar a ser necesario la migración) pero al menos garantizamos que la información esta completa y no presenta errores. Por otro lado, si nos interesa que la velocidad de las consultas sea muy rápida, su escalabilidad sea mucho mas fácil y no nos interesa mucho la perdida de información o inconsistencia de ella (Datos repetidos, datos fantasma, etc.) podemos optar por una base de datos no relacional, esto también implica que si necesitáramos incluir seguridad y algunos métodos de integridad de datos, todo eso, tendríamos que programarlo a mano desde el lenguaje de programación del lado del servidor y/o apoyándonos un poco con JavaScript para los procesos de validación. Les comparto la siguiente infografia útil de packhosting.hk Los sistemas gestores de bases de datos (SGBD) SQL tienen una sintaxis estándar, son muy similares, las diferencias entre los diferentes manejadores de bases de datos de este tipo son algunas funciones y tipos de datos que traen incluidas a demás del soporte. Los SGBD mas conocidos son Oracle, postgresql, mysql y mariaDB. Los SGBDNoSQL son más variados todo depende del la necesidad y del propósito que se quiera alcanzar, algunos guardan la información en documentos, objetos, columnas, clave-valor, grafos, etc. Los SGBD NoSQL mas populares son: Cassandra, redis, mongoDB, couchDB, ArangoDB, SimpleDB, Neo4j, etc (mysql puede trabajar como clave-valor si cambiamos el formatos de la tabla de innodb a myisam). Una vez que elegimos el SGBD, procedemos a diseñar nuestros diagramas que nos servirán de guía para el desarrollo de la base de datos, UML tiene uno para SGBD SQL, este tipo de diagrama se llama Entidad-Relación (E-R), los NoSQL, desconozco que tipo de diagrama usen para planificar y diseñar la base de datos, ya que pueden variar mucho por el propósito que puede tener cada SGBD NoSQL. La simbología que usa un diagrama E-R es la siguiente: Esa es la simbología que tiene un diagrama entidad relación, puede ser que cambie muy poco dependiendo del autor pero, en esencia se puede ver la cardinalidad de las relaciones (1 : 1, 1 : N N:1 N:M), también se colocan los atributos mas importantes de la tabla (entidad) incluyendo las llaves primarias y las llaves foráneas. Hasta aquí, podemos decir que tenemos un 50% de la planificación terminada, si no tenemos ningún error aquí, el proyecto backend ya tienen una base muy solida. Diagramas de clases En caso de que se use el paradigma de la programación orientado a objetos, puede utilizar el diagrama de clases para identificar la estructura que tendrá cada una de las clases (métodos y objetos), cuando se trabaja en equipo, es muy practico, ya que se puede distribuir el trabajo iniciando con las clases independientes. También se puede aprovechar para hacer el diagrama de objetos, este consiste en la representación de un objeto por clase, con la finalidad de ver los posibles datos que se podrían crear con las clases Diagrama de secuencias El diagrama de secuencias no es muy útil para explicar como será la dinámica al realizar una tarea dentro del sistema, ver lo módulos con los que tendrá interacción y las funciones de los mismos.) una vez terminado los wireframes, nos reunimos con el cliente para mostrarle las propuestas, si el cliente esta de acuerdo, seguimos al siguiente paso, de lo contrario, recurrimos a la retroalimentacion y se aplican los ajustes correspondientes . Hay otros tipos de diagramas UML, al menos, estos son los mas básicos para poder llevar acabo el análisis de requerimientos con su respectivo diseño. Después de la planificacion posteriormente a esta etapa, ya podemos empezar a programar, pero aquí no concluye todo, no podemos animarnos a programar todo el sistema con el primer análisis de la información, ya que nos exponemos mucho a sufrir cambios todo el tiempo, lo ideal es, en base al análisis, tomar los módulos mas importantes y que tengan interacción con el usuario, para construir una primera etapa del software, en base a lo que se tomo y se programo, se hace la respectiva documentación mas la etapa de pruebas (testeo) que también debe ser documentada, una vez terminada estas pruebas, procedemos a utilizar una herramienta de gestión de versiones Con esta herramienta, nos protegemos a la hora de querer seguir avanzando con el sistema, ya que hacemos de manera cíclica el análisis de requerimientos (mediante la nueva retroalimentación), el diseño de los nuevos módulos a incorporar, el testeo y el “respaldo” de versiones con alguna herramienta GIT, si por alguna razón se llegara a construir o a dañar alguna parte del sistema, podemos recuperarla o trabajar mediante alguna de las versiones anteriores que se encuentren “limpias”, cada vez que creemos una nueva versión con una nueva integración de módulos, tenemos que probar todos los componentes del sistema, para asegurarnos que nada este trabajando de manera incorrecta, todos los resultados se deben documentar, de esta forma, podemos construir software de muy buena calidad y evitando el mayor numero de errores posibles gracias a la etapa de planificación (diseño). Esto prácticamente es Ingeniería de Software, basado en el modelo de proceso en espiral y este a su vez, esta basado en el modelo de Cascada, con la diferencia que en modelo de cascada se enfoca a construir todo el sistema de golpe, mientras que en el espiral, se enfoca en construir bases del sistema e ir incorporándole más módulos hasta concluirlo, por experiencias pasadas, me di cuenta que es mucho mejor el modelo en espiral, ya que en algunos proyectos, el uno los tiempos. por ultimo, les comparto lo siguiente que refleja una de mis maneras de pensar. Con esto, finalizo el tema de la metodología de que debería seguir un desarrollador BackEnd., espero que sea de su gusto y les pueda resultar útil. Pueden dejar sus dudas, sugerencias y comentarios, cualquier cosa, estamos en contacto, Saludos Si les interesa ver otro de mis post