One company, one work’s infrastructure
Jul/094
Well, I was working in many develop’s companies since now. And the first thing I learned is:
“Whitout a unique, static, strict and complete work’s infrastructure is imposible that your company grow up.”
The employee came in and come out, but the code stay here, at company.
Think a new employee that arrive at company. Whitout a work’s infrastructure, this person will develop in her computer, use google source to save you source or directly, will writte source in production. Then, some time before, the developer go out; And you, as CEO, will have a problem.
What this person has done so far? How many things has he changed? And where?
Then, the only solution is spend the time of your new developer only to check all the source’s status.
Note: How said in Spain: “Cada maestrillo tiene su librillo” This isn’t the panacea. Only some tips to unify infrastructure, or simples ideas for everyone.
First: Spare and Control
Spare your jobs in three or four states.
- [own developer zone] This isn’t necesary, but soo recomended. All developer have here her own zone to develop and check her own source. Usually, this zones stay in developer’s PC.
- Develop zone. How it said, it’s the only zone where is “allowed” write code. If any change have to do, this must be do in this zone.
- Preproduction zone. When one step has been done and check, then it “go up” to preproduction zone. This zone can be see for the client. To check, change or approve the project’s steps. The only think that you have to do here is change the config parameters acording to preproduction system.
- At last, Production zone. Here, only source’s updates and config changes are “allowed”. This are been seeing to all internet, and errors here “can’t existis”1.
Note: It’s recomended that all states stay in diferent machines. What will be happen if a bug into developer zone kill the apache’s server?
Ok, but how control this new job’s flow?
Well, this is too simply with a version control system. Like Subversion (SVN) or Concurrent Versions System (CVS)2. This server will be in other or in dev3 machine.
This services take the control for you of the updates, commits, merges,… Only job in “dev” (or user’s dev) zone, where you can commit, and update the “pre” or “pro” zones with this sources. It’s so simply and have so much power.
This is only the first step. I will writte two or three more post to splain this and powered it.
Y, que es entonces la nuezAzul?
Jun/096
Bueno, desde que abrí el blog la semana pasada, mucha gente preguntado:
“Vale, según tú1, eres un fanático de la programación estricta bajo PHP, OOP y el uso de los patrones de diseño (GoF); pero, que es la nuezAzul? A que os dedicáis exactamente?“
Bueno, nuestro objetivo es bastante simple en la base.
Desarrollo web avanzado para llevar acabo ‘ideas 2.0′ de forma seria, profesional y de calidad.
Queremos evitar que una buena idea desaparezca y por esto, siempre que nos llega una nos dedicamos al 100% a esta, evitando coger más de una idea a la vez y poniendo así todo nuestro esfuerzo en un solo proyecto.
Y esto, que significa realmente?
Bueno, esto significa que no hay proyecto pequeño; saber que todos los proyectos se van a tratar de igual manera. Se mimarán y desarrollarán manteniendo siempre el mismo “mínimo de calidad“, muy superior a la media de empresas de desarrollo web.
Significa que como cliente, no tendrás que vivir verdaderos calvarios para sacar tu web al mercado, para ver avances en el proyecto o simplemente, para ser informado en todo momento del estado del mismo.
En cierta ocasión leí a @loogic “tuitear” algo similar a:
¿por qué no existe un Grupo Intercom en Madrid?
La verdad es que me sorprendió dicho tweet, pero es totalmente cierto. Hasta ahora no hay ningún Grupo Intercom en Madrid, y aunque suene a utopía, este es nuestro sueño. Llegar a ser en Madrid (y a nivel naciona, claro), lo que es el Grupo Intercom en Barna.
Ser una empresa donde poder llevar acabo esas ideas innovadoras y desarrollos que requieren una verdadera planificación, un desarrollo eficiente y una escalabilidad máxima para el día de mañana. Ese el objetivo de la nuezAzul, ambicioso, verdad!
Para esto, todos los proyectos los dividimos en varias etapas o fases, informando al cliente en todo momento del estado de su proyecto.
En una primera fase hablaremos, y mucho, de la idea, que quiere el cliente y como quiere rentabilizarlo, que ideas podemos aportar nosotros al concepto, como se puede llevar a cabo… Destriparemos por completo la idea, la reorganizaremos, la reensamblaremos y la potenciaremos todo lo que podamos.
Una vez clara la idea, nos pondremos manos a la obra con el proyecto, buscaremos el usuario objetivo, trabajaremos sobre la interacción y usabilidad del site, buscaremos marcar los ROI del proyecto, haremos la toma de requisitos del proyecto, crearemos la interacción completa del site, los wireframe necesarios, las bases de los libros de estilos…
Después de las fases de “recogida de información” el proyecto se divide en tres fases paralelas:
- Diseño y maquetación final de los bocetos de alto nivel; Dentro de los limites de los wireframes los diseñador tendrán que crear algo acorde a la filosofía del proyecto. Después nos tocará maquetarlo, siempre cumpliendo, en la medida de lo posible2 , con los estandares web establecidos.
- Programación del proyecto, tanto backend como frontend; Gracias a una toma de requisitos amplia se evitarán errores en la programación, situaciones confusas o errores en la navegación. Facilitando así el objetivo principal, realizar un sito escalable, potente y de calidad.
- Social/Online Branding de la marca; Mientras que las fases de diseño y programación están trabajando al máximo, aprovechamos para hacer un poco de “online brandig“, haciendo que empiece a sonar la marca en el mundillo web, que aparezca ya en varios sitios y que la gente empiece a interesarse por ella, incluso antes de que esté terminado el site.
Y por último, entendemos que cualquier proyecto de gran calado, es o debería considerse un “ser vivo“. Por lo que realizaremos un seguimiento continuado del proyecto, donde veremos como crece, hacia donde evoluciona, que cambios hay en los habitos de los usuarios,… Así estaremos siempre preparados y con posibilidad de modificar el proyecto con el entorno.
Está es (no) brevemente nuestra filosofía. Esto es lo que queremos hacer. Suena ambicioso, pero no dudo que podremos llegar a hacerlo. Así, que si te ha interesado, a que esperas para llamar?
Cuando las cosas se hacen bien, salen bien.
Jun/090
Bueno, como hablar de algo sin demostrarlo, es como no hablar de nada, vamos a centrarnos un poco en enseñar como entendemos y programamos un proyecto web desde la nuezAzul. Principalmente porque esta es mi área.
También es cierto que toco un poco algunas de las demás partes de un proyecto; maquetación, accesibilidad y usabilidad (de esto poquito), SEO y SEM, branding online,…. Pero de estas prefiero ir dejando pequeños apuntes técnicos sueltos y centrarme en lo que realmente es mi fuerte, la Programación Web Avanzada. Y si, se puede decir esto y sumarle PHP sin restar el más mínimo poder a la frase.
Y para ello, lo primero es desmitificar a los que piensan que PHP es inseguro y poco profesional; el inseguro y poco profesional es el programador, no el lengjuaje.
El primer problema que encontramos con PHP es su mayor virtud. La anarquía del lenguaje. Este lenguaje se creó principalmente con una máxima; la mayor libertad posible. No es necesario definir variables, no tiene una estructura de programación definida, puede mezclarse dentro de código html o html dentro de código php…
Esto ha hecho que desde un principio, PHP fuese muy suculento para todo el mundo. Tanto programadores profesionales, como amateurs e incluso completos “novatos” de la programación pueden hacer en PHP sus pinitos y programar cualquier cosa.
Claro, esto ha dado muchas lineas de código a PHP, de las cuales la mayoría se podría decir que son basura “no reutilizable” y sobretodo muy inseguras y difíciles de auditar/ampliar. Pero claro, no todo es culpa del código, no se le puede pedir a un newbie que entienda de “Sql Injection” o de calidad de código.
Y como se podría solucionar este problema? Bueno, lo primero aquí es saber que se quiere y distinguir los casos.
- Si eres un newbie, que solo quiere hacer sus pinitos, adelante, este es tu lenguaje y esto es todo lo que deberías leer de este blog.
- Si realmente quieres realizar código de calidad y reutilizable, empieza por lo básico. Se lo más estricto posible, estructura el código, declara las varibles al principio de cada método, usa patrones de programación y nunca olvides la flexibilidad de PHP, pero no supedites la calidad a la flexibilidad, hazlo al revés, supedita la flexibilidad a la calidad
El segundo problema es la rápida evolución del lenguaje frente a la lenta o inexistente evolución del programador. Tanto PHP como Apache y las bases de datos han tenido una evolución estos últimos años bastante fuerte, pasando de, por ejemplo, la programación funcional hasta la implementación de la OOP por parte de PHP, el famoso mod_rewriter de Apache o la potencia de las bases de datos relacionales. Todo esto implica un continuo esfuerzo por parte del programador para estar al día con todo lo que le rodea. Cosa que muchas veces no pasa, encontrandonos con que, por ejemplo, PHP4 no llega a desaparecer ya que implicaría restructurar mucho código o que no existan todavía casi ninguna aplicación que sea 100% OOP sino hibridos entre funcional y OOP.
Solucionar este problema es algo más complicado, cada día vemos actualizaciones de PHP, nuevas funcionalidades y otras decrépitas. Estar al día en esto podría ser algo fácil, pero si además hay que sumar el estar al día en las aplicaciones que usas, en Apache, en la base de datos con la que trabajas, revisando tu código para actualizarlo, … La cosa se complica un poco. Lo malo, esta es la única forma de solucionar el problema, es decir, si quieres realmente hacer buen código cada día, debes emplear cada día en formarte un poco más, y para esto no hay ayudas externas. Cada uno debe tener intención de leer y aprender cada día, sino, en poco más de un año, tu también estarás “decrepit“.
Otro de los defectos es la falta de estructura a la hora de programar, la falta de profesionalidad y de “seguridad de código” en lo que uno hace. Conozco muchos casos en los que un programador, que entiende y usa la OOP, deja esto de lado porque un “proyecto es pequeño” o porque “no es necesario“. Creando archivos faraónicos, sin estructura alguna en la programación, sin revisar los posibles bugs de la aplicación, … Esto siempre es un error, pero es más error cuando esto pasa de ser para “proyectos pequeños” (Aunque nunca llegue a entender que es eso de proyectos pequeños) y se utiliza en todos los proyectos que uno hace.
El mayor problema que esto acarrea es la imposibilidad del posterior mantenimiento del site, los problemas y el tiempo perdido a la hora de implementar nuevas funcionalidades, o simples cambios en el diseño. Como siempre, el mayor problema aquí es la desfatachez del programador al pensar en el hoy y no el mañana. El mañana serán problemas para el cliente, no para el programador.
Y por último, otro de los grandes errores con PHP, es la suma de todo lo anterior, es encontrarnos proyectos “cajón de sastre” en los cuales, los programadores con buenas ideas y sin tiempo para pensarlas bien, crean proyectos, donde se mezcla funcional con OOP, viendo funciones sueltas entre clases, donde no hay una estructura definida correctamente, donde no se tratan los objetos por paquetes como cualquier otro lenguaje de programación orientado a objetos. Donde se ven funciones obsoletas o donde se ven mezclados, entre grandes ideas, código y html. Dando así grandes “cajones de sastre” de los que no se puede reutilizar gran cosa…
Como se podría solucionar? Lo primero es obviar la programación para todas las versiones y centrarse en PHP5 o superior. Versión a partir de la cual se puede hablar realmente de OOP. Y después de esto, aprender de los demás lenguajes de programación, aprender realmente lo que es el paradigma MVC (o cualquier otro que sea válido) y ponerlo en práctica, no pensar que existe un proyecto pequeño, todos son igual de importantes, pues son tu carta de presentación, usar PHP igual que usarías Java o C++ y sobretodo
TENER RESPETO, MUCHO RESPETO, TANTO A TU TRABAJO, COMO A QUIEN PAGA POR ÉL.
Calendario
« Jun 
Ago » Julio 2010 L M X J V S D 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
