Recuerdo que en la época pre-pinchazo de las .com ya andaba yo programando webs... y como todo buen webmaster, tratando de ganar algo de dinero con ellas, aunque sólo fuera para sacarse la pasta del dominio y el hospedaje.

Y como todo buen novato, me fiaba de la empresa que más dinero me daba. En sus inicios, aucland ofrecía la friolera de 50 pesetas por cada clic, y ni tal si quiera te revisaban la web!! La cosa es que en poco menos de tres meses ya tenía en mi cuenta 25.000 pesetas... dinero que jamás llegó a mis manos (obviamente). Dejé pasar un tiempo hasta que llegó una "fantástica idea prepinchazo" llamada yotuel.com, por la que con instalarse un programita en tu ordenata que te enseñaba publicidad a todas horas, te pagaban un tanto por hora navegada. Pero no sólo eso, sino que te pagaban por cada persona que convencieras a que se instalara el programa (de ahí la ventaja de tener un web muy visitada). Yo llegué a tener unas 20, y me alegré cuando recibí mis primeras 5000 pesetas... pero ahí se quedó la cosa, ya no recibí ni un duro más. Por cierto, en esa época, 5000 pesetas era lo que costaba el nombre del dominio al año.

Después estuve trabajando con tradedoubler. Estos parecían una empresa más seria, y aunque poco, me pagaban regularmente... eso sí, sólo la mitad de lo que me correspondía, puesto que a tradedoubler la chuleaban y los anunciantes pasaban de pagarle. La cosa es que unas 20.000 pelas les saqué, aunque amigos míos como Nacho se sacaron hasta 50.000 en menos tiempo ;)

Al tiempo, tradedoubler me echó, y pasé un vacío de unos dos años sin publicitar con empresas especializadas (sí con publicidad propia), hasta que llegó la ola de empresas para logos y melodías de móvil. La cosa es que no estaban nada mal para nuestro viejos móviles sin color y monotono, pero con la llegada de móviles que se podían conectar al ordenador fácilmente, se acabó lo que se daba. De todas formas, nunca me he llegado a sacar más de 15 euros al mes con ellos, mientras que con publicidad propia superaba los 100 euros.

Finalmente conocí el adsense de google en octubre de 2004, año y tres meses después de su nacimiento... bueno, lo conocía antes, pero ya estaba tan harto de las empresas publicitarias que Nacho y demás gente me tuvieron que convencer. La cosa es que el asunta pintaba bien. En menos de año y medio, google ya había hecho quebrar a todas las empresas intermediarias de publicidad chupasangre.

Y en mi opinión eran dos las razones básicas:
1.- Todo el mundo se fía de google. Los anunciantes saben que google es de fiar y confían su dinero pq saben que los clics entrantes van a ser buenos, o al menos los mejores que se puedan encontrar. En cuanto a los webmasters, también se fían mucho de google pq saben que los anunciantes pagan antes de anunciarse (algo insólito hasta el momento), saben que hay muchos anunciantes y que google paga (casi) siempre.
2.- Publicidad contextual. Vamos que la publicidad que te insertan en tu web varía y depende de la temática de tu web, lo cual es cojonudo, pq tú sólo insertas el script y te olvidas. Además, la publicidad que aparece es la que más se paga (gracias al sistema de subastas).

Con todo y con esto, google se ha hecho con el mercado de los ads, y tanto sus acciones como sus beneficios han subido como la espuma. Si a ello le sumamos que la sociedad de la información va a ir creciendo por cojones, y con ello la publicidad por Internet, parece un panorama inmejorable para Larry y Sergey.

Eso sí, no todo son flores para el adsense. Eso de que un webmaster se profesionalice basándose únicamente en lo que le paga una empresa que ni le conoce tiene muchos peligros. Uno de ellos se da comúnmente, y es que google te eche de su sistema de la noche a la mañana, sin previo aviso, aunque suele deberse a cosas mal echas por el webmaster.

Con este panorama, aparece yahoo diciendo que va a traer al mundo algo similar al adsense de google... cojonudo, ¿no?
Vamos a pensarlo un poco, yahoo vendrá con todo lo bueno que tiene google (se fían todos de él y la publicidad depende de tu temática) y elimina lo malo, que es depender de una sola empresa.

Bien, pues en realidad no es tan fácil, muchos expertos adsenseros piensan que no, que la cosa es más compleja y acabará en detrimento de los webmasters. Y la razón para que piensen esto es que creen que para google y para yahoo nosotros no somos los clientes, sino que lo son los anunciantes, y por tanto la lucha estará en darles el mejor servicio al menor precio... y dónde está la parte débil de la cadena?? Pues precisamente en los anunciantes. Nos pagarán menos y así les cobran menos a ellos.

Y yo qué opino? Pues que NO. Rotundamente NO. Parece que nos estemos volviendo tontos. ¿Acaso nos creemos que acabamos de inventar las leyes del mercado?, ¿Somos tan ilusos de creer que la publicidad por internet es algo totalmente nuevo en la historia de la humanidad?. Pues no. Ni tal siquiera es nuevo el hecho de anunciarse en un medio (sea el que sea).
La publicidad por Internet es un subconjunto de la publicidad en los medios, y la publicidad en los medios en un subconjunto dentro del mercado global... incluso el mercado global es un subconjunto dentro de la vida!!!! pero no sólo de la vida humana, sino de la vida de todos los seres vivos de este planeta.

Bueno, me estoy yendo por la ramas, volvamos al tema G vs Y!
Todo obedece a las leyes de oferta y demanda. Si no hay anunciantes, no funciona el juego, pero si no hay webs que anuncien tampoco! Además, las curvas de oferta y demanda se conocen desde hace muuucho tiempo, así que lo mejor que puede pasar para la salud de la publicidad por internet es que se destruya el monopolio de Google.

Google y Yahoo van a competir mucho entre sí, pero su lucha no va a estar en pagarnos menos a los webmasters, y a la vez tampoco deben descuidar el cobrarles menos a los anunciantes... entonces, qué va a pasar??
Pues muy fácil:

A webmasters
Nos van a atraer con nuevos servicios y más opciones.
Está claro que a los webmasters no nos importa otra cosa que ganar más pasta, que el panel de control sea muy bonito o sencillo de usar no es más que secundario. Pero si nos ofrecen nuevos servicios para poder hacer que nuestros visitantes cliquen más, eso se acaba traduciendo en más CTR y más CPM.
Del mismo modo, no deben olvidar en que lo que se nos pague por cada clic sea como mínimo lo mismo que se nos pagaba hasta el momento, y a medio plazo esto debe aumentar. Por tanto, más CTR y CPM se traducirá en más dinero.
Para comenzar, parece que yahoo! va por buen camino con una de las nuevas opciones que no recuerdo como se llaman. Parece ser que podremos cercar un texto del que yahoo sacará la temática y mostrará publicidad referente a ese texto. De este modo, para cada artículo de un blog podemos poner publicidad relacionada de yahoo, lo que será más interesante para el visitante y hará más clics.

A anunciantes
Al igual que a los webmasters, a los anunciantes sólo les interesa pagar menos por más clics y mejor servicio. Pues bien, aquí viene el problema... cómo vana hacer google y yahoo! para pagar igual o mejor a los webmasters y cobrar menos a los anunciantes?? Pues lo mismo que se ha venido haciendo desde hace siglos: reduciendo el margen de beneficios!!!
Las leyes del mercado dictan que el margen de beneficios se acaba estabilizando (y minimizando) siempre, y de ahí la imperiosa necesidad de terminar con el monopolio de google.

El modo de proceder de un monopolio es establecer los beneficios antes de que comience el año y adaptar la empresa para conseguirlos, cobrando más a los anunciantes, pagando menos a los webmasters y descuidando el servicio.
La entrada de otra gran empresa en el mercado (destrucción del monopolio), implica luchar durante todo el año por los beneficios atrayendo a más anunciantes (cobrando menos), atraer a medios de publicitación (pagándonos más) y sobretodo mejorar el servicio (lo que ofrece una tasa beneficio consecuente/coste real mayor).

Teoría sobre esto podríamos exponer muchísima, aunque ya sería conveniente hacerlo con gráficas e historias y ya os tendría que cobrar, jeje :)
Por ejemplo habría que ver los escalones de precios a cobrar a los anunciantes con respecto al número de anunciantes que aceptarían el precio.
Es decir, a lo mejor 10 anunciantes están dispuestos a pagar un euro por clic, pero hay 50 que están dispuestos a pagar 50 céntimos y 1000 que están dispuestos a pagar 10 céntimos. Todo esto hay que superponerlo a los webmasters que están dispuestos a cobrar tanto por clic también de forma escalonada...
Vamos, que es una historia larga y merecedora de algún que otro proyecto fin de carrera o doctorado.

Espero vuestras opiniones!!! Nadie sabe toda la verdad, y menos en el mundo del mercado.

Hoy es viernes, y el pasado lunes comencé a saco con letrasenlared.com... han sido cuatro días al máximo, y he hecho más que lo que había hecho hasta ahora en varios meses.

El lunes comencé con muchas ganas, aunque no con todo el tiempo que quisiera; yo le calculo unas cinco horas de trabajo, sólo con las capas DAL y BLL. Dejé terminada las clases dedicadas a la categorización de contenidos.

Como va a ser norma general (y esto lo pienso hoy viernes, pero el lunes no lo tenía claro), todo lo que haga va a poder ser reutilizado en un futuro, y lo de la categorización es cojonudo, porque categoriza todo lo que quieras... por lo menos todo lo que se me ha ocurrido categorizar durante todos mis años de webmaster (aficionado).

Me explico con ejemplos prácticos: en letrasenlared.com han de haber categorías según los géneros literarios (poesía, teatro, prosa, relatos, cuentos), y para cada uno han de haber subcategorías (cuentos fantásticos, cuentos infantiles, etc.). Pero además, también han de haber categorías para los foros y subforos (foro de escritores, foro de libros, foro de la madre del topo) o para las noticias de la página principal (noticas de actualidad, cambios en la web, mundo literarios, etc.).
Y no sólo eso, en discotequeros.com también me viene muy bien lo de la categorización, ya que a parte de noticias y foros, también hay zonas de discotecas para la guía de discotecas, esta la sección de infofiesta, categorías para las fotos, y un largo etc.

Vamos, es como un árbol y sus correspondientes ramas y hojas, y la tabla de la BBDD es tan sencilla que me da hasta vergüenza que el lector crea que para mí es algo novedoso; he aquí:
- Id: es la clave primaria, y es un string... sí, ya sé que hacer clave primaria a un string es algo dudosillo, pero en la BLL me aseguro de que es único. Además no suele ser demasiado largo, por lo que no pierde demasiadas cualidades como índice. Y lo hago string para optimización de buscadores (esto es otra historia).
- Madre: no hace falta saber mucho para imaginarse que la madre es la id de la rama superior. Por cierto, la parte más alta del árbol se llama "madre" (qué original, ¿no?)
- Título: pues eso. Por cierto, Id es una googlelización del titulo.
- Descripción: en ocasiones es necesario, si no lo fuera no hace falta ponerlo.
- Visibilidad: esto es una historia propia que me ha sido aconsejada por mi experiencia de tantos años de webmaster (aficionado). Así no tengo que borrar categorías, simplemente las oculto... por si acaso.
- Prioridad: 1 máxima (más arriba), 200 mínima. Es un tinyint, por lo que SQLServer ni se entera.

Pues lo dicho, la tabla no es demasiado complicada, lo que sí es algo más elaborado es la BLL y la DAL. La BLL porque propone una serie de funciones superinteresantes y que van a ser utilizadas en mucho lugares, y sólo hace falta escribirlos una vez (como me gusta la OO); y la DAL pq es megaóptima y muy rápida.

Pues eso fue el lunes, así que pa cagarse, porque esto ya me sirve para toda la vida.

En cuanto al martes, jueves y viernes (el miércoles tuve un día movidito: piscina, regalo a mi niña, Fosters con mis padres, cine, ver el fútbol con los colegas y algo de mi enemiga la PS2; vamos que no entré en mi casa), he estado trabajando con el foro... bueno, mejor dicho, he estado trabajando con TodoPub.

Me explico, TodoPub responde a la misma manía de generalizar varias cosas similares. Hasta ahora, en mis webs tenía una tabla de la BBDD para el foro, otra para el libro de visitas, otra para las fotos, otra para las noticias y así hasta que la muerte nos separe. No hace falta ser un genio para ver que todas esas entes responden a una estructura análoga, ya que todas tienen: Id, Título, Autor, Texto, Fecha y otros 7 campos... y esto no me lo he inventado yo, y si no que se lo pregunten a RSS o al resto de "estándares" de sindicación.
Pues eso, todas los módulos de letrasenlared que me sea posible los endosaré a TodoPub. Por ejemplo el foro, las noticias e incluso las obras publicadas.
Del mismo modo que con la categorización, la tabla es sencillita, lo que es más complejo son las capas BLL y DAL.

Me lo he currado en la DAL pq la magia de ADO.NET permite operaciones hiperrápidas, aunque claro, lo tienes que implementar, y aunque realmente no cuesta casi nada, el exceso de comodidad (o falta de conocimiento), puede hacer que no nos aprovechemos de ellas. Pero bueno, es el pan nuestro de cada día: siempre es más fácil ejecutar una sentencia SQL desde la UI sin más que copiar y pegar, que seguir un proceso más elaborado que paso a comentar dada su importancia:
1º Enlazar la UI con la BLL mediante los novedosos DataSources.
2º Llamar tantas veces como haga falta a la DAL desde la BLL haciendo múltiples comprobaciones.
3º Que la DAL se comunique con la BBDD mediante los procedimientos almacenados. Los procedimientos almacenados son sentencias SQL (T-SQL) que le damos a la base de datos para que se vaya haciendo a la idea de que se las vamos a pedir, con lo que se mejora muchísimo en velocidad. Si alguien sabe del tema se estara riendo de la definición, pero así no entendemos.
4º Yo he hecho funciones que se heredan de una clase madre para ser ejecutadas desde la DAL, sobre todo de las que no requieren respuesta (insert, update y delete), y algo de las que sí requieren (selects). De este modo, el código disminuye en 5:1

SIEMPRE:
- Se usan clase tipadas para todo, por lo que, por ejemplo, de un post de un foro no se lee desde un datareader como se viene haciendo siempre: dr["TitulodelPost"].ToString(), sino de una forma tipada: post.Titulo. Entre otras cosas, a parte de tener un código más claro y sencillo, nos aprovechamos de la intellisense del VisualStudio, por lo que escribir las pocas líneas que tenemos que escribir es muy rápido.
- Se usa la orden using para las partes más críticas del código. La orden using (que creo que sólo existen en C#, no en VB.NET) hace un try - catch y luego un finally liberando las variables mediante un .dispose(). Useasé, en lugar de:
try
{
sqlconnection con = new sqlconnection("string de conexion");
sqlcommand comm = new sqlcommand("nombredelprocedimientoalmacenaco", con);
con.open()
sqldatareader dr = comm.ExecuteReader();
while (dr.read())
{
//ejecutar operaciones
}
}
catch (Exception e)
{
//tratar la excepcion
}
finally
{
dr.close()
con.close();
dr.dispose();
comm.dispose();
con.dispose();
}

Vale con hacer:

using( sqlconnection con = new sqlconnection("string de conexion"), sqlcommand comm = new sqlcommand("nombredelprocedimientoalmacenaco", con), con.open(), sqldatareader dr = comm.ExecuteReader())
{
while(dr.read())
{
//Hacer cosas
}
}

Como veis se ahorra mucho espacio, y sobretodo no se te olvida cerrar nada, incluso se cierra si nos da error. Además, using lo hace todo de forma óptima, por lo que nos olvidamos del performance. Por cierto, el código no es del todo correcto, y se puede mejorar, pero lo he hecho rapidito.

El quid de la cuestión es que si hacemos este proceso una vez, nos va a servir no sólo para esta web sino para todas las que vengan en el resto de nuestras vidas, jeje, ya que siempre podemos mejorarlo.

Pero no nos desviemos del tema. Estábamos con que el martes y el jueves me pasé el día con TodoPub, así que el jueves por la tarde comencé a hacer el foro, me di cuenta de que faltaban algunas personalizaciones que sólo sirven para el foro, y creé la clase foro que heredaba de TodoPub, con las pirulillas que me hacían falta.
Hoy viernes he comenzado con la UI del foro (useasé, lo que ve el usuario) y lo he terminado.

El problema es que a final de tarde he decidido que voy a utilizar TodoPub también para las obras que la gente publique (ya os digo que en principio iba a hacerlo diferente, pero ha quedado tan bien que lo voy a reutilizar). La DAL y la tabla de la Base de datos van a ser las mismas, lo único es que he decidido almacenar el texto de la obra en un fichero XML, así será más rápido y no le daré tanta carga a la BBDD (los megas de la BBDD van caretes). Al hacerlo así he añadido un par de campos a la tabla de la base de datos (valoración y votos), por lo que ahora me da error y no funciona bien el foro, pero el lunes lo arreglo en unos minutos.

Mi gran duda ha sido si, para TodoPub, utilizar una tabla con muchos campos o dos tablas, una con campos importantes y otra con campos secundarios. Al final me he decidido por una sola tabla, ya que en el 90% de las veces me hace falta toda la info a la vez, así que paso de estar haciendo uniones de tablas cada dos por tres. Además, las variables de cache de ASP.NET me permiten hacer que no se entre en la BBDD siempre, sólo cuando sea necesario.

Para acabar con TodoPub y sobretodo con el tema del foro, sólo decir que lo bueno de tenerlo organizado en tres capas es que es muy fácilmente ampliable. De momento el foro es superbásico, con lo que tiene cualquier foro, pero en un futuro se pondrán muchas más pijadas, de las que ahora mismo se me ocurren dos (aunque hay muchas más):
- La típica de que el sistema analice si el usuario ha leído ya el mensaje y sus respuestas. Supongo que será algo así como hacer otra tabla con una correspondencia IdPost, FechadeLectura, Lector, y que luego la BLL analice si has leido todos los mensajes del post, incluso cuántos has leido y cuántos no.
- Otra funcionalidad (que yo no he visto demasiado) es la de permitir al escritor el adjuntar tantos adjuntos como le de la gana. Vamos, que no haya número máximo de adjuntos. Por ejemplo: ficheros excel, word, imágenes, archivos flash, links, y todo ello tanto externo como almacenado en el servidor. Se trata de que el usuario adjunte un fichero y que el sistema identifique de qué se trata.

Bueno, paro ya de escribir. Antes del 12/8 debe estar acabada la versión beta de letrasenlared... tendré que echarle un par de wevos la semana que viene!!!