Los ultimos meses he tenido exceso de trabajo por unos problemas con respaldos masivos en el lugardonde trabajo. Básicamente estamos hablando de tablas de 7 gb, generaciones de archivos temporales de 40 gb a la semana por apache, y 200 usuarios FTP simultáneos.

Estudiando esa problemática me he convencido que lo mas necesario para un CMS independiente es el ser pequeño, y de ser posible no usar Bases de datos para la consulta publica. Uno de los dos mecanismo de control que uso normalmente no puede manejar a precios razonables una base de datos con muchas visitas, como el foro rojointenso, que es un foro bajo invision con un promedio de 5000 hits no de google al día.

Una reorganización que tuve que hacer derivado de la situación laboral me ha permitido entender que el concepto de que la superviencia es directamente proporcional la simplicidad me ha hecho replantearme los objetivos. De momento tengo varios scripts que me dejan manejar varios cientos de sitios web, y un script reciente que sustituye las estadísticas internas normales de los paneles de control, incluso sin bases de datos.

Creo sinceramente que en un futuro la mayor parte de foros PARTICULARES que no son mantenidos por personas como yo, desparecerán o serán mas lentos, por que la carag geométrica que representan los cambios de precio y tamaños de bitácoras causarán por un lado un incremento en los costos y una mayor carga en los respaldos, que muchas personas son incapaces de hacer.

En los ultimos diez años he visto desaparecer muchos foros particulares y varios servidores, no propios , de rodillas. Tampoco creo que la nube sea la solución. El futuro de sitios web estará ligado a una metodología que se .htaccess (apache) pero no puede estar ligado a cheyenne (sin .htaccess) porque es la única forma que los servidores actuales, que deben servir unos tres años mas, puedan hacer frente a los parásitos digitlaes como crawlers spammers y similares.

Pero el problema no es un sitio aislado (cualquiera lo puede mantener o donar) pero si hablamos de decenas de sitios , alguien tiene que controlarlos, o incluso sitios masivos, que si usan bases de datos . Deberá salir una alternativa de bloqueo a los parásitos digitales, pero no es posible desarrollarla sin tener las estadísticas, experiencia y problemática de sitios masivos como los mencionados, adelantando el tiempo.

Lo que un sitio sencillo de wordpress que se ua consume de recursos en cinco años, es mas de lo que muchos mexicanos han pagado en toda su vida en relación a internet.

El problema es cuando tu propósito, como el de Ojos Alerta AC, es mantener una estructura de difusión que lleva docenas de sitios masivos, y varios cientos de dominios aislados, a lo largo de muchos años.

Es cuestión de perspectiva.

Es importante hacer un módulo para guardar ciertas estadísticas de un sistema de sitios, por varias razones:

1 ) puede ser necesario cambiar el server de cpanel a hsphere, perdiendo estadisticas en medio. Guardarlas con un script propio no base de datos es emjor.

2 ) poder filtrar y blockear parásitos como Baidu y sistemas de búsqueda no importantes.

3 ) Poder rastrear los intentos de hackeo o intrusiones como las que han tratado de hacer en loborojo.net después que el reclutador de sectas Marco Antonio Arenas Chipola (http://www.chipola.info ) mencionara sin pruebas que ese sitio tenía problemas de vulnerabilidad y de otros que realizaban Phising. (claro quese necesita ser idiota para poner una hoja a un whois de un dominio, para "demostrar" phising....)

4 ) Guardar tiempos de carga. Los tiempos de carga no los dan la mayor parte de estadísticas.

El sistema debe funcionar bajo Linux/Windows, y usar un sistema con soporte nativo para CURL.

Debido a que los servidores de Ojos Alerta, empresa que tendrá el software en comodato maneja servidores php, el diseño se hace en base a PHP vigente (5.3+ ) con globals off, habilidad de usar rewrite y con módulos CURL e IMAP configurados.

No se hará compatible con versiones anteriores de php, y se usara como base de datos MYSQL/MSSQL, por el hecho de estar disponible en diversos lugares y usar sistema dual. El sistema puede ser vendido a terceras empresas en un futuro, pero la licencia de MYSQL sirve para pruebas propias y no se difunde el código debido a que siempre habrá un beta (rama edge), estando pensado sobre todo el sistema para uso de Una AC sin fines de lucro.

El diseño de la base de datos debe contemplar el ser migrable, se tratará que sea compatible con ORACLE y sus SEQUENCEs, pero para servidores de producción se usará INNO en Mysql o MSSQL.

A lo largo de los ultimos seis años he visto muchos problemas causados en sitios web por los diferentes navegadores. He leido hoy una noticia de Google, que dejarán de dar soporte a Firefox 3.5, l oque me parece buen parámetro.

http://googledocs.blogspot.com/2011/06/our-plans-to-support-modern-brows...

Él sistema debe ser compatible con IE 8, firefox 3.6 y chrome vigente. Soporte a Explorer 7 opcional.

Esto obliga también a establecer una "theme" compatible en lugar de propietaria.

Como parte previa a la generación de especificaciones funcionales, haré cinco preguntas al usuario final, que seré yo.

¿Que?

Debido a limitaciones de diseño de software existente, y de limitaciones de tiempo, es necesario actualizar un sistema de gestión que se usó en etapas previas, para poder cumplir requisitos que no cumple otro software, principalmente multidominios, facilidad de uso, autorespaldo, y sistema de estadísticas incorporadas.

¿Quien?

El usuario final soy yo, y en el caso de otros usuarios puede hacerse una instalación codificada por su dominio o su dirección IP. No tiene caso hacer un sistema multieditor, o derechos internos de usuarios porque debería ser a nivel dominio, que se resuelve con una instalación diferente en ese dominio, y una clave extra adicional a la de usuario por si el usuario la pierde. Es decir, algo similar a "si existe el archivo x, entonces aceptarás entrar como developer/pass también."

Personal que desarrollará: Yo. No voy a asignar a empleados de las Pymes a algo de uso personal.

¿Cuando?

El sistema debe estar funcional a finales de 2011, y registrarse en el 2012 ante IMPI.

¿Porqué?

Porque los programas existentes tienen problemas o de granularidad, o de no generar xml, o carecen de autorespaldo y una verdadera gestión integral o estadísticas.

¿Para qué?

Para permitir tener en una sola instalación mas de 100 dominios sin que sea evidente al usuario y sinque los problemas de curva de aprendizaje de Drupalo de diseño afectan el control de los documentos/artículos. Un artículo debe poder pertenecer a varios sitios, pero debe controlarse de manera independiente del dominio en que se está en ese momento.

El objetivo del sitio LoboNegro es concentrar información de un proyecto de código para llevar control multidominios, a través de un manejador de contenido, CMS, con un nombre clave por definir. Resulta necesario asignarle un nombre al proyecto porque este sistema no es el primer Manejador de contenido que hago, así que en el futuro cuando me refiera al proyecto LoboNegro, o LoboNegro a secas, es el proyecto gestor de contenido que detallaré aquí

Desde un principio se ha decidido por una limitación de la licencia de Mysql, que el código no será distribuido. Explicaré el tema con detalle después, pero con fecha del primero de junio del año 2012 estará registrándose ante el IMPI el uso de dos marcas, que NO serán lobonegro, sino dos palabras que usaré internamete para referirme al proyecto en sus dos versiones:

a ) Rama Stable y usada en producción
b ) Rame Edge: Para pruebas de software

Es un proyecto de un solo hombre, y que no está a la venta, y que cederé en comodato a Ojos Alerta AC y otras pymes de las que soy socio y/o apoderado.

Alfonso Orozco Aguilar
Ojos Alerta AC
Director General