Digamos que usted tiene la siguiente tabla se llama votos que realiza un seguimiento de cómo la gente votó y que desea una consulta para contar el número de votos, en lugar de tener que recorrer todas las filas con un contador con un contador en PHP

person vote
obama yes
mccain no
obama yes
obama no
mccain yes
obama yes
obama yes
obama no
mccain no

Esta es la solucion con MYSQL

SELECT person,
SUM(IF(vote = “yes”, 1,0)) AS `yes_votes`,
SUM(IF(vote = “no”, 1,0)) AS `no_votes`,
COUNT(vote) AS `total`
FROM votes
GROUP BY person
ORDER BY yes_votes DESC

El siguiente sería el resultado de la consulta:
person yes_votes no_votes total
obama 4 2 6
mccain 1 2 3

Ahora, usted no tiene que recorrer los resultados de MySQL para contar valores de la columna =)

AWS has two concepts that relate to availability – Regions and Availability Zones. They have five Regions – two in the US (one east coast, one west coast), one in Europe (Ireland), and two in Asia (Tokyo, Singapore). Each region has within it multiple “Availability Zones” (AZs), which are supposed to be isolated so that they have no single point of failure less than a natural disaster or something of that magnitude. AWS says that by “launching instances in separate Availability Zones, you can protect your applications from failure of a single location”. It’s not clear whether ‘location’ means separate datacenters or separate floors/areas of a single datacenter, but it doesn’t really matter – the point is that AZs should fail independently until a catastrophic failure occurs. [Update below: it seems likely that they are in fact separate datacenters]

AZs also offer “inexpensive, low latency network connectivity to other Availability Zones in the same Region”. Inter-Region transfer, on the other hand, goes over the public internet, and is comparatively expensive, slow and unreliable.

These are the “rules of the game”. So if you’re playing the AWS game and setting up a master/slave MySQL database (to take a highly pertinent example), what you do is you put the master and the slave in the same Region, but make sure they’re in different Availability Zones. You don’t normally put them in separate Regions, otherwise you have to cross the expensive, slow and unreliable links between Regions, and you’ll likely have more problems trying to keep your databases in sync. You are at risk e.g. if a hurricane hits the eastern seaboard and destroys the datacenter, but short of that you should be OK – as long as AWS does what they promised.

So (finally) we come to the problem. This morning, multiple availability zones failed in the us-east region. AWS broke their promises on the failure scenarios for Availability Zones. It means that AWS have a common single point of failure (assuming it wasn’t a winning-the-lottery-while-being-hit-by-a-meteor-odds coincidence). The sites that are down were correctly designing to the ‘contract’; the problem is that AWS didn’t follow their own specifications. Whether that happened through incompetence or dishonesty or something a lot more forgivable entirely, we simply don’t know at this point. But the engineers at quora, foursquare and reddit are very competent, and it’s wrong to point the blame in that direction.

Of course it’s possible to protect against a catastrophic failure (multiple AZs), but for most businesses the additional expense and engineering effort isn’t worth it (or may even be counterproductive by introducing additional complexity). I’m sure all the sites that are down have backups they could go to. The problem is that bringing them online is likely complicated and risky – in practice you have to move everything to the new region, because otherwise the latency between your machines is too big. AWS has made this particularly complicated: the different regions have different features available, different AMI ids, I think reserved instances can’t be moved between datacenters – in reality failover between regions is not realistic. It’s probably as much work as failover to a completely different cloud, which is probably a better disaster recovery policy anyway. For all we know quora started the process the minute AWS had an issue and are still working on it – it could easily be a whole-day process. Perhaps they would have started that process had AWS communicated at the start that it would have been such a big outage, but AWS communication is – frankly – abysmal other than their PR.

So – in short – the blame here lies squarely with AWS, who ‘guaranteed’ a contract they then broke. Mistakes happen, but the mistake here was an AWS mistake.

Nor was this a failure of “the cloud”. It does show the importance of choosing your cloud provider carefully. I think many people will be reasssesing their choice of AWS.

A few other tidbits:

• The reason so many websites are in us-east is because that’s where the new features get rolled out first. It’s also the cheapest. It’s also probably best located in terms of many website’s traffic (good performance for the North America, reasonable performance for Europe)
• The actual failure was due to EBS (persistent disks), which have been a disaster in terms of reliability since their introduction. But that’s a whole different blog post!
• An EBS volume can only be in one AZ, and can only be used from that AZ. RDS seems to use a private API that lets EBS volumes be in multiple AZs, but those aren’t available to anyone competing with RDS (hmmm… a Seattle company using private APIs to gain competitive advantage – haven’t we been here before?)

EC2 FAQ offers a stronger guarantee:

“Each availability zone runs on its own physically distinct, independent infrastructure, and is engineered to be highly reliable. Common points of failures like generators and cooling equipment are not shared across Availability Zones. Additionally, they are physically separate, such that even extremely uncommon disasters such as fires, tornados or flooding would only affect a single Availability Zone.” http://aws.amazon.com/ec2/faqs/#How_isolated_are_Availability_Zones_from_one_another

So it sounds like AZs are, in fact, separate datacenters and not just separate floors / rooms. That makes multi-AZ failure even less acceptable.

Also, I used the word “contract” above, but I meant it in the technical sense, not the legal sense. The legal contract is the SLA, which I consider relatively worthless. Engineers designed to the AWS technical ‘guarantees’, but a multi-AZ failure shouldn’t happen if AWS is upholding their end of the ‘bargain’

Con el fin de ayudar un poco a evitar propagar claras mentiras por la red quiero dejar este post aquí. Si alguien no está de acuerdo con lo que comento es libre de usar los comentarios para argumentar porqué no cree que estoy en lo cierto. En fín, vamos a tratar el tema de moda: “Las granjas de Contenidos”.

Llevamos hablando de las granjas de contenidos unos meses. No es algo nuevo, simplemente Google ha hecho una de sus declaraciones “oficiales” y parece que nos hayan quitado una venda de los ojos. Lo primero es eliminar esta creencia. Quien hacía granjas de contenidos en los últimos años quizás no las llamaba así, pero sabía perfectamente que estaba haciendo “Black Hat” -Seo en contra de las normas de Google y que por tanto puede provocar penalizaciones-. Nutrir la web de Spam o de contenidos creados solo y absolutamente para SEO no sigue las directrices de Google, no nos hace falta leerlas, es de toda lógica que es así al igual que sabemos que comprar enlaces tampoco va a gustarle. A veces nos tapamos los ojos pensando en algoritmos y códigos pero lo que importa es saber que hay gente detrás de todo esto que llamamos “el algoritmo de Google” y la lógica se impone siempre, más tarde o más temprano.

Sin embargo, este último año hemos vivido como el SEO se ha popularizado y como el link fuera de contexto perdía fuerza. En conclusión la salida rápida para ganar links para cualquiera que trabaja SEO en serio ha sido la de crear contenido nuevo. Formas de hacerlo hay cientos pero os resumiré algunas por orden de complejidad y recursos necesarios:

- Robando por RSS el contenido de otros blogs.

- Robándolo a mano con un corta y pega.

- Robando fragmentos de varios contenidos distintos para montar el tuyo más amplio.

- Reescribiedno solo pequeñas partes y fragmentos del mismo (con el mito de que si es más del 20% no es duplicado).

- Automatizando la recogida de estos pequeños fragmentos de varias fuentes. Según el esquema HTML o de microformatos del site.

- Creando o aprovechando sites “sociales” donde subir noticias interesantes o publicar duplicados de nuestros blogs.

- Reescribiendo frase a frase los contenidos.

- Creando nuevos contenidos sin pensar. Solo hablar de un tema pero sin aportar nada (post de muy bajo precio que escriba cualquier chaval).

- Hacer lo mismo pero añadiendo además contenido multimedia (fotos, videos, etc.)

- Crear de verdad artículos nuevos.

De esta lista a poco que lo pensemos sabemos que absolutamente todo menos el último punto es medianamente Black Hat o directamente Spam. Y por eso estas cosas son a por las que va a ir ahora Google. Cómo va a conseguir detectar esto en función de algoritmos, plugins de chrome y barras de navegadores es, por mucho que debatamos, totalmente indiferente… ¿no creéis? ¿Qué nos importa la solución mágica que adopte Google?, es divertido seguirlo y hacer nuestras predicciones pero debemos asumir que lo conseguirá (o eso o a la larga se hunden).

Lo importante para nuestro negocio es saber que la actual meta de Google es detectar y descartar todo este contenido de dudosa o nula calidad y actuar en consecuencia. No ya solo por lo que está pasando ahora mismo, sino por lo que seguramente va a pasar los próximos meses. Porque seamos serios: no hay datos de que estos cambios estén actuando actualmente en ningún idioma distinto al inglés ni en ningún sitio fuera de USA así que dejemos de gritar “acojonados” en un rincón. Yo personalmente no me creo que en dos meses nos llegue -como se dice-… ¿cuando nos ha llegado al español tan rapido cualquier actualización? Pero puedo equivocarme e independientemente a eso, lo cierto es que hay que actuar lo antes posible como si la actualización ya nos afectase y así nos evitaremos futuros sustos.

Así que lo primero es detectar que estoy haciendo que podría llegar a ser penalizado. Aquí estoy viendo demasiada preocupación… parece que ahora crear un blog o dotar de contenido un site vaya a ser penalizado cuando esas son precisamente la metodologías que más le gustan al buscador. Además muchos tipos de estrategias que quedarían en la linea de si van a considerarse o no Granja de contenidos se da por supuesto que lo son. Así que tengamos claro que:

- Un blog con contenido propio no es granja de contenidos.

- Dotar a nuestro site de contenido extra haciendolo abarcar cada vez más temas no es granja de contenidos.

- Crear sites satelites con contenidos propios y relevantes no es granja de cotenidos a no ser que seamos muy bestias con los links o los dirijamos siempre hacia los mismos X dominios.

- Un site de productos con descripciones propios no es granja de contenidos.

- Una wiki con contenido propio no es granja de contenidos.

- Leer una noticia y escribir sobre la misma con un link a la original pero sin copiarla y aportando más datos o detalles no te acerca a ser una granja de contenidos.

Por el contrario:

- Copiar duplicar o parsear/scrapear contenidos para hacer un site, si te lo convierte en granja de contenidos.

- Reescribir post con tus propias palabras pero sin aportar contenido, si que podría llegar a considerarse granja de contenidos algún día (aunque en español, por las características de nuestro lenguaje estamos lejos de eso).

- Agrupar noticias y posts si que es granja de contenidos. Grandes como Meneame o Bitacoras pueden preocuparse.

- Montar sites de afiliación copiando y pegando las definiciones originales del producto si que es granja de contenidos.

…

Y hasta ahí con los ejemplos… ¿alguien da más?

JS

HTML

Abrir una terminal y colocar los siguientes comandos:

Si estas corriendo PHP tambien se necesita instalar el modulo de php para mysql5

Para crear una nueva base de datos:

Vieron?, es realmente facil

De esta manera, cuando la aplicación web ha dado un error, un mail nos notificara que ha sucedido, y en que linea de codigo.

CTR = Clicks / Impresiones

Un medio de marketing Online a medida que evoluciona mejora sus KPI (Key Performance Indicators) dándonos una información cada vez más valiosa. Antaño se compraban banners por meses o semanas de permanencia en la página, se evolucionó a comprar impresiones de los banners y más adelante a medir el CTR que estos producían contando así visitas reales que llegaban a nuestras páginas. El último paso de este proceso sería hablar directamente de ratios de conversión a lead, adquisición, etc.

El SEO es sin duda un canal del marketing online (más o menos importante dependiendo de cada web) y como tal la evolución de sus KPI dependerá de lo que lo profesionalicemos. Sin embargo, mientras que en otros canales de marketing online dispondremos de forma fácil de valores tan básicos como “impresiones” y “CTR” en SEO estos valores NUNCA vamos a conocerlos… Como no tenemos control sobre los SERPS (Search engine results pages) de google tan solo disponemos de número de clicks lo que nos priva de una información vital a la hora de tomar decisiones.

En otro post de este blog comentaba como estimar el volumen de trafico potencial de una keyword en SEO. Ese mismo texto debería servirnos para acercarnos lo máximo posible a las impresiones que va un SERP de una keyword concreta.

El tema de las visitas globales de un SERP no creo que pueda mejorarse demasiado, tenemos esas herramientas para estimar los volúmenes y tenemos que basarnos en algo. En cuanto al CTR en el mismo post se enuncian unos CTR según la posición de tu web en el SERP de google. Por desgracia esto no está tan aceptado y existen distintas versiones sobre cual es el CTR de los links de estas páginas.

En las especificaciones html del W3C se nos indica una colección de etiquetas que podemos usar a la hora de generar nuestra web. Pero estas etiquetas historicamente se han usado más por la apariencia que adquirían en la pantalla de los navegadores que por su significado real. Así, la web vivió muchos años con maquetas llenas de tablas y atributos que permitían a los diseñadores y maquetadores colocar cada elemento donde les apetecía.

Más adelante, cuando el uso del css 2.1 empezó a hacerse común estas tablas pasaron a ser sustituidas por divs, un elementeo sin ningún significado semántico que solo debe usarse como bloque agrupador de otros.

El html semántico se hace posible en un tiempo en el que la información sobre el propio html y el css en los distintos navegadores ha llegado a ser tan completa que nos permite, con algo de experiencia, empezar a preocuparnos por que nuestro código use realmente las etiquetas html que aportan al contenido el significado real que tienen. En una página con html semántico las tablas solo tienen sentido para mostrar datos tabulados, los divs solo se usan como bloques contenedores como pueden ser la cabecera o pie de la página, la barra lateral, etc… El resto de elementos deben incluirse con las etiquetas html que los representan: titulares, parrafos, listas, citas, estilos de letra, etc…

Seguidamente una mini guía muy básica de como representar con etiquetas html distintos elementos en una web.

Bloques bien diferenciados en la página (Cabecera, barra lateral, etc… ) : Único caso en el que contendremos los elementos dentro de una etiqueta <div/>.
Titulares, titulos de sección, subtitulos : Usaremos las etiquetas <hX/> que nos permiten marcar titulos. El titular principal de la página será la etiqueta <h1/>, los titulos de secciones los <h2/>, distintos titulos de partes del contenido los <h3/>, subtutitulos <h4/>, etc… y así hasta el nivel de títulos que necesitemos.
Menús, Pestañas, listas de links, footers de links, etc. : Usaremos las etiquetas de listado no numerado <ul/> para contener el elemento y luego para cada link usaremos <li><a/><li> marcando que cada link es en realidad un elemento de listado que solo contiene un link.
Contenido : Para redactar el contenido debemos usar etiquetas enfunción de lo escrito en el contenido. Para parrafos normales, usaremos <p/>para cada parrafo. Para listados ordenados <ol/>, sin orden definido <ul/>. Aparte tenemos la posibilidad de usar otras etiquetas para contenidos especiales: <pre/>, <blockquote/>, etc.

Pero la forma mas facil es generar un nuevo date y que nos devuelva el mes automaticamente, entonces todo ese codigo largo se trnansformaria en estas sencillas lineas de codigo

Llamamos a la funcion

Salida: