Consideraciones sobre los sistemas de blogs, solo técnico de infraestructura, como paso previo a la programación de un motor que me sirva para unificar varios textos sueltos.
Funcionalidad:
Una de las cosas que noto de manera frecuente en la humanidad, es la incapacidad de la mayoría de dar resultados en su àrea de trabajo, o mejor dicho, el problema de dar prioridades a lo que es mas cómodo y no al objetivo.
El objetivo de este software, es una salida funcional para concentrar notas, y eso debe ser.
Uno de los libros sobre diseño que leí hace unos años, es de Joel Spolsky y menciona de la necesidad de llegar un acercamiento entre la idea del desarrollador y el público objetivo.
Asi que aclaro. El publico objetivo en este caso, soy yo, y como el software se está haciendo para uso privado, debe cumplir la funcionalidad que necesito. Es decir, sus adecuaciones deben venir de las funciones que yo llegue a requerir, y eso va a necesitar una especificación funcional, siguiendo la misma metodología de Spolsky. Lo haré en unos dias y lo paso a pendientes.
Conectividad:
Baches de conectividad. De repente mi ping sube en un ISP a 1200 o 2000, mientras que la alptop, que tengo con el BAM, suele estar en 200 a 250.
Hay algunas implicaciones filosóficas a la necesidad de tener 3 proveedores de ISP o comunicación bidireccional. Me acuerdo cuando hace años Alestra era popular.
Elección de bases de datos:
En este software en especial usaré MYSQL porque es lo mas práctico para servidores con PHP, y usaré como modelo INNO. Sin embargo, mi inclinación particular para proyectos que no son WEB es MSQL Server 2000.
Aunque he trabajado con ORACLE, y lo sigo haciendo, he visto una serie de problemas tremendos por errores de configuración del DBA. Usar imp y exp, porque alguien no sabe configurar el RMAN, es algo común. Aunque tengo oracle XE y he hecho sistemas mayoritariamente ORACLE desde hace unos tres años, sigue sin gustarme, pero el proqué es tema para otro día.
Estoy consciente de los problemas de SUN y su relación con ORACLE, y estoy tratando de mantener una estructora limpia de Triggers y Store procedures, sobre todo porque este server tengo acceso también a bases de datos MSSQL que pertencen al mismo server.
Es decir, desarrollado para MYSQL pero listo para migrarse si hace falta a MSSQL server.
Elección de servidores:
Uno de los inconvenientes que tiene el medio moderno tecnológico, es que algunas personas sin experiencia conocen algo del vocabuilario pero no tienen la mas minima idea de las implicaciones.
En este caso particular, el problema de la "cultura de la nube", es su tendencia a crear mas puntos vulnerables a fallas, asì que el usar un integrador ùnico, que no haga outsourcing en lo posible, debe ser la ruta mas segura.
Una de las cosas que he hecho en mi tiempo libre, desde 1995 aprox, es dar apoyo tecnológico(asesoría pues)a personas que buscan crear comunidades sociales, o concentrar información que necesitan para sus negocios o vida normal. Con la aparición de PHP hace unos diez años, las alternativas web son mucho mejores que antes (afortunadamente llevo mas de 10 años sin hacer paginas de Active Documents).
En el caso específico de PHP, lenguaje que es gratuito, tiene tendencias Legacy que causan problemas. Es decir, un servidor mal configurado, probablemente va a tener mal configurada la seguridad de PHP, y en ese caso todo el esfuerzo de desarrollo puede perderse de manera simple.
Un server es tan seguro como su admin.
Así que, si quiero un server seguro, yo soy el admin.
Una de las cosas que he detectado ultimamente es la tendencia de algunos Managed Servers a poner cosas en modo inseguro sin avisar. Asi que lo que pretendo en este caso, es aprovechar a monitorear este server, activandole todo lo revisable automaticamente, y despues configurando el software en que escribo para que me de aviso de lo que no es seguro, y si le es posible continue de modo seguro.
Esto es solo un acercamiento inicial, sobre un proyecto a largo plazo.