¿Qué es el Grado de Protección IP en móviles?

Ante la salida del Samsung Galaxy S5, en las especificaciones técnicas me ha llamado el certificado IP67. Y yo digo, ¿Qué es el grado de protección IP?
El Grado de proteccion IP es un sistema para clasificar los diferentes grados de protección aportados a los mismos por los contenedores que resguardan los componentes que constituyen el equipo.

 








Primer dígito (IP*X)

El estándar IEC 60529 establece para el primer dígito que el equipo a ser certificado debe cumplir con alguna de las siguientes condiciones.

Nivel Tamaño del objeto entrante Efectivo contra
0 Sin protección
1 <50 mm El elemento que debe utilizarse para la prueba (esfera de 50 mm de diámetro) no debe llegar a entrar por completo.
2 <12.5 mm El elemento que debe utilizarse para la prueba (esfera de 12,5 mm de diámetro) no debe llegar a entrar por completo.
3 <2.5 mm El elemento que debe utilizarse para la prueba (esfera de 2,5 mm de diámetro) no debe entrar en lo más mínimo.
4 <1 mm El elemento que debe utilizarse para la prueba (esfera de 1 mm de diámetro) no debe entrar en lo más mínimo.
5 Protección contra polvo La entrada de polvo no puede evitarse, pero el mismo no debe entrar en una cantidad tal que interfiera con el correcto funcionamiento del equipamiento.
6 Protección fuerte contra polvo El polvo no debe entrar bajo ninguna circunstancia

Segundo dígito (IPX*)


Nivel Protección frente a Método de prueba Resultados esperados
0 Sin protección. Ninguno El agua entrará en el equipamiento.
1 Goteo de agua Se coloca el equipamiento en su lugar de trabajo habitual. No debe entrar el agua cuando se la deja caer, desde 200 mm de altura respecto del equipo, durante 10 minutos (a razón de 3-5 mm3 por minuto)
2 Goteo de agua Se coloca el equipamiento en su lugar de trabajo habitual. No debe entrar el agua cuando de la deja caer, durante 10 minutos (a razón de 3-5 mm3 por minuto). Dicha prueba se realizará cuatro veces a razón de una por cada giro de 15º tanto en sentido vertical como horizontal, partiendo cada vez de la posición normal de trabajo.
3 Agua nebulizada. (spray) Se coloca el equipamiento en su lugar de trabajo habitual. No debe entrar el agua nebulizada en un ángulo de hasta 60º a derecha e izquierda de la vertical a un promedio de 10 litros por minuto y a una presión de 80-100kN/m2 durante un tiempo que no sea menor a 5 minutos.
4 Chorros de agua Se coloca el equipamiento en su lugar de trabajo habitual. No debe entrar el agua arrojada desde cualquier ángulo a un promedio de 10 litros por minuto y a una presión de 80-100kN/m2 durante un tiempo que no sea menor a 5 minutos.
5 Chorros de agua. Se coloca el equipamiento en su lugar de trabajo habitual. No debe entrar el agua arrojada a chorro (desde cualquier ángulo) por medio de una boquilla de 6,3 mm de diámetro, a un promedio de 12,5 litros por minuto y a una presión de 30kN/m2 durante un tiempo que no sea menor a 3 minutos y a una distancia no menor de 3 metros.
6 Chorros muy potentes de agua. Se coloca el equipamiento en su lugar de trabajo habitual. No debe entrar el agua arrojada a chorros (desde cualquier ángulo) por medio de una boquilla de 12,5 mm de diámetro, a un promedio de 100 litros por minuto y a una presión de 100kN/m2 durante no menos de 3 minutos y a una distancia que no sea menor de 3 metros.
7 Inmersión completa en agua. El objeto debe soportar sin filtración alguna la inmersión completa a 1 metro durante 30 minutos. No debe entrar agua.
8 Inmersión completa y continua en agua. El equipamiento eléctrico / electrónico debe soportar (sin filtración alguna) la inmersión completa y continua a la profundidad y durante el tiempo que especifique el fabricante del producto con el acuerdo del cliente, pero siempre que resulten condiciones más severas que las especificadas para el valor 7. No debe entrar agua











Espero que esto os haya valido para cuando veais las especificaciones de un móvil ya sepais un poquito de que va el tema. Un saludo.
















Búsquedas personalizadas en el motor de búsqueda Google

Todos sabemos que cuando buscamos algo en Google lo encontramos entre los primeros puestos, pero, podemos observar que si introducimos las mismas palabras clave en función de si estamos logueados en "Gmail" o no, los resultados son distintos.
Aquí un ejemplo de una búsqueda no estando logueado con nuestra cuenta de Google:


Podemos observar que los resultados son los que podemos ver siempre. Sin embargo, cuando estamos logueados, el resultado de la búsqueda con las mismas palabras, el resultado de las búsquedas varía:


Esto se debe a los resultados personalizados que se basan hacemos clic en cada búsqueda nuestra, así que con cualquier cuenta siempre los resultados varian para cualquier resultado. Ésto puede resultar perjudicial para nuestro trabajo como SEO, ya que éstas búsquedas no serán reales. 

Para obtener resultados limpios no se debe estar logueado con la cuenta de Gmail, hay limpiar todo del navegador o se puede utilizar la  opción de Chrome de navegación en modo incógnito (navegación privada) y en el Internet Explorer en la ultima versión oprimiendo CTRL + Shift + P.


IF, Elsif & else en Ruby


print "Entero, por favor: "
num_usuario = Integer(gets.chomp)

if num_usuario < 0
  puts "¡Escogiste un entero negativo!"
elsif num_usuario > 0
  puts "¡Escogiste un entero positivo!"
else
  puts "¡Escogiste cero!"
end

Concatenar resultados de prompts en Ruby

Programa en Ruby que te pregunta tu Nombre, apellido, ciudad y estado y los muestra en pantalla todos concatenados:

print "¿Cuál es tu nombre?"
nombre = gets.chomp.capitalize
print nombre.capitalize!

print "¿Cuál es tu apellido?"
apellido = gets.chomp.capitalize
print apellido.capitalize!

print "¿Cuál es tu ciudad?"
ciudad = gets.chomp.capitalize
print ciudad.capitalize!

print "¿Cuál es tu estado?"
estado = gets.chomp.upcase
print estado.upcase!

puts "Te llamas #{nombre}, tu apellido es #{apellido}, eres de #{ciudad} y tu estado es: #{estado}"

Sincronizando bases de datos MySQL


Replicación: replica una BD Mysql (MASTER) en una o varias BDs MySQL (SLAVEs) en un solo sentido (MASTER -> SLAVE)

Para implementar una sincronización en ámbos sentidos, debemos usar MySQL Cluster o crear una sincronizaciónoneway circular. Lo veremos en un próximo artículo.

Por defecto es una replicación asincrona (no necesita conexión continua, no hay problemas por fallos en al conexión).

La replicación se basa en el mecanismo binary logging. Para cada sentencia aplicada en la BD MASTER se escribe un registro (evento) en el binary log, la BD SLAVE descarga y lee el binary log del MASTER y reproduce cada sentencia aplicada a la BD MASTER en la BD SLAVE).

Cuando configuramos el binary logging en el server MASTER, el motor MySQL crea un fichero con el prefijo que le indiquemos, donde se incluirá todos los comandos SQL (sentencias) que modifiquen datos en la(s) base(s) de datos. Este archivo se guardará en el directorio de datos. MyQSL creará el archivo nombrandolo con el prefijo indicado en el archivo de configuración y un número. Este número se incrementará cada vez que se inicie el servidor o cuando se vuelquen los registros.

 Tareas a realizar:

  • En el MASTER: habilitar binary logging y configurar un único server ID
  • En cada SLAVE: configurar un único server ID
  • Antes de crear la BD replicada, debemos anotar la posición del Binary Log en el MASTER. Esto es necesario para que el SLAVE sepa a partir de qué evento debe empezar a sincronizar.
  • Para configurar el SLAVE necesitaremos necesitaremos el nombre/IP del servidor MASTER, user/password de MySQL, nombre del archivo Binary Log y posición.

Configuración del MASTER

Para configurar el Binary Log y server ID único  (nº entero entre 1 y 2^32-1) necesitamos apagar el servidor MySQL y editar el archivo de configuración my.cnf ó my.ini. Descomentar o añadir las líneas si no aparecen en el archivo de configuración.

Opcionalmente podemos seleccionar que solo se guarden en el binary logging las sentencias de una o varias BDs con la opción binlog_do_db (si no añadimos esta opción, se guardarán todas las sentencias de modificación que afecten a todas las bases de datos). En este caso solo se guardará las sentencias que se hagan posteriores a un USE sobre la BD seleccionada.
Tambien podemos seleccionar las BDs a ignorar para registrar las sentencias añadiendo la opciónbinlog_ignore_db en nuestro archivo de configuración.

Ejemplo: vamos a establecer un prefijo para nuestro archivo de Binary Log  de mysql-bin y un server ID de 1, además vamos a especificar que se guarden en el binary logging las sentencias que afectan unicamente a la dbname1dbname2,por lo que el archivo de configuración quedaría:


[mysqld]
log-bin=mysql-bin
server-id=1
binlog_do_db=dbname1
binlog_do_db=dbname2

Después de los cambios, reiniciar el servidor MySQL.
Nota: para transacciones usando InnoDB con transacciones, establecer innodb_flush_log_at_trx_commit=1 ysync_binlog=1 en el archivo my.cnf del master.
Nota: aseguraté que la opción skip-networking no está habilitada, o la sincronización fallará. En algunos sistemas, esta opción se denomina bind-address to 127.0.0.1, para permitir toda comunicación debemos asignar el valorbind-address=0.0.0.0


Configuración del SLAVE 

Para configurar el SLAVE hemos de establecer un server ID único  (distinto del MASTER u otros SLAVEs) y para ello necesitamos apagar el servidor MySQL y editar el archivo de configuración my.cnf ó my.ini al igual que en el MASTER.
Ejemplo:


[mysqld]
server-id=2

Después de los cambios, reiniciar el servidor MySQL.
Nota: si estamos configurando varios SLAVEs, el valor de server ID ha de ser único.
Nota: en ciertas ocasiones hemos de añadir en el archivo my.cnf ó my.ini del SLAVE la línea



report-host=hostname-or-IP-of-MASTER

 para que el comando 'show slave hosts' ejecutado en el MASTER funcione correctamente.



Creando un usuario para la replicación 

Cada SLAVE se conectará al MASTER usando un user/pwd de MySQL, por lo que habrá que crear tal usuario en el MASTER para dar acceso al(los) SLAVE(s). Este usuario deberá tener el privilegio REPLICATION SLAVE. Se podría crear una cuenta para cada SLAVE o una general para todos. No es necesario crear una cuenta para la replicación, pero hay que tener en cuenta que el user/pwd de esta cuenta se almacenará en texto plano en el archivomaster.info. Por tanto es recomendable crear el usuario específico por cuestiones de seguridad.

Un ejemplo sería:


mysql> CREATE USER 'repli'@'SLAVE-host-or-IP' IDENTIFIED BY 'replipass';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repli'@'SLAVE-host-or-IP';

 para que el comando 'show slave hosts' ejecutado en el MASTER funcione correctamente.


Nota: si cambiamos el nombre del host, deberemos hacer un FLUSH HOSTS para reiniciar el host cache de MySQL.


Obtener las coordenadas del Binary Log en el MASTER

Si nuestra BD a replicar contiene datos, antes de replicar deberemos volcar la información en SLAVE server. Para ello pararemos la ejecución de sentencias de escritura sobre el MASTER, obtendremos las coordenadas del Binary Log y haremos un volcado de datos (dump).
Los pasos serán:

1. Entrar en la consola MySQL y bloquear la escritura de tablas:


mysql> FLUSH TABLES WITH READ LOCK;

Nota: mientras no salgamos de la sesión, las tablas permanecerán en modo lectura (READ).
Nota: para tablas InnoDB, el comando FLUSH TABLES WITH READ LOCK también bloquea las operaciones COMMIT.

2. En una sesión diferente del MASTER, vamos a obtener las coordenadas del Binary Log (nombre del actual archivo binary log y su posición de ejecución).


mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 |      107 | pruebarepli  |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

 Nos muestra el nombre del archivo donde guarda las sentencias (mysql-bin.000003), y la posición desde que se la que se copiarán las nuevas sentencias (107). Además nos muestra las BD a registrar y las BDs a ignorar. Guardas esta información para la configuración del SLAVE.



Copia de seguridad del MASTER e importación en el SLAVE

1. Hacer una copia de la BD
Mientras mantenemos en una sesión el FLUSH TABLES WITH READ LOCK, ejecutaremos  en una sesión distinta mysqldump para hacer un backup de la BD MASTER:


shell# ./mysqldump --opt --databases pruebarepli -u root -p > pruebarepli_backup.sql

2. Anular el READ LOCK, si está todavía vigente. Para ello podemos cerrar la sesión abierta con READ LOCK o ejecutar el siguiente comando:


mysql> UNLOCK TABLES;

3. Importar el backup en el SLAVE, utilizaremos el siguiente comando en el servidor SLAVE:


mysql> mysql -u root -p < pruebarepli_backup.sql;


Establecer los parámetros del MASTER en el SLAVE

Lo primero de todo es establecer en el archivo de configuración del SLAVE el server ID.
Nuestro ejemplo será:


[mysqld]
server-id=2

Si configuramos diferentes SLAVEs, los ID's correspondientes han de ser distintos.
Reiniciamos el servidor del SLAVE.

Continuamos estableciendo los parámetros de comunicación entre el SLAVE y el MASTER (los cuales hemos ido recopilando en los pasos anteriores), para lo que ejecutaremos lo siguiente sobre la consola del SLAVE:


mysql> CHANGE MASTER TO
->     MASTER_HOST='master_host_name',
    ->     MASTER_USER='replication_user_name',
    ->     MASTER_PASSWORD='replication_password',
    ->     MASTER_LOG_FILE='recorded_log_file_name',
    ->     MASTER_LOG_POS=recorded_log_position; 

En nuestro ejemplo será:


mysql> CHANGE MASTER TO
->     MASTER_HOST='IP_servidor',
    ->     MASTER_USER='repli',
    ->     MASTER_PASSWORD='replipass',
    ->     MASTER_LOG_FILE='mysql-bin.000003',
    ->     MASTER_LOG_POS=107; 


Arrancar el SLAVE

Para finalizar arrancar el SLAVE con el siguiente comando:


mysql> START SLAVE;



Para finalizar mostramos una captura de pantalla del comando show slave hosts ejecutado en en la consola del MASTER para corroborar la conexión entre MASTER-SLAVE. Confirmamos que se produce la actualización de la BD SLAVE ante una inserción de datos en la BD MASTER.








Source: http://dev.mysql.com/doc/refman/5.7/en/replication.html

Backups desde consola. MysqlDump

Backups desde consola. MysqlDump

  • Hacer una copia de seguridad de la BD mysql
mysqldump --opt --databases mysql -u root -p > backup_mysql.sql
  • Modificar en el fichero backup_mysql cualquier referencia a la BD mysql y cambiarlas por backup_mysql
Ayuda: solo hay dos diferencias: una en la sentencia create y la otra en la sentencia use
  • Restaurar BD como mysql_backup.sql
mysql -u root -p < back_mysql.sql
  • Verificar desde una conexión mysql que se ha creado bien la base de datos mysql_backup

Avanzado
  • Migrar base de datos de un servidor a otro directamente
mysqldump -uUSUARIO -pCLAVE BD | mysql -h HOST_DESTINO -uUSUARIO -CLAVE BD
  • Hacer una copia de seguridad de todas las bases de datos
mysqlldump -u root -p --opt --all-databases --lock-all-tables > backup_full_file.sql
  • Exportar todas la base de datos MySQL a fichero con fecha en el nombre comprimido con gzip
mysqldump –password=CLAVE –single-transaction –all-databases | gzip -9 >RUTA_DESTINONOMBRE_`date +%Y-%m-%d`.sql.gz

Gestión de usuarios desde consola

Gestión de usuarios desde consola

Crear usuarios locales y remotos:
  • Verificar los usuarios que existen dados de alta
c:\> mysql -u root -p
mysql> SELECT user FROM mysql.user;
  • Crear un usuario profesor local con todos los privilegios en una BD determinada:
mysql>  GRANT ALL PRIVILEGES ON db.* TO ‘usuario‘@’host‘
IDENTIFIED BY ‘contraseña‘ WITH GRANT OPTION;
  • Crear un usuario profesor local con todos los privilegios en todas las BDs:
mysql>  GRANT ALL PRIVILEGES ON *.* TO ‘usuario‘@’host‘
IDENTIFIED BY ‘contraseña‘ WITH GRANT OPTION;
  • Crear un usuario con ciertos privilegios
mysql> GRANT privilegio1 [, privilegio2 ...] ON db.* TO ‘usuario‘@’host‘ IDENTIFIED BY ‘password‘;
Privilegios:
  • ALTER: Modificar tablas con ALTER TABLE
  • CREATE: Crear una nueva BD o tabla
  • DELETE: Eliminar registros de las tablas
  • DROP: Eliminar BD o tablas
  • INDEX: Crear o eliminar índices
  • INSERT: Crear registros en las tablas
  • SELECT: Listar registros de las tablas
  • UPDATE: Modificar registros de las tablas
  • Listar privilegios para un usuario USUARIO desde una dirección HOST
mysql> GRANTS FOR ‘USUARIO’@’HOST’;
  • Eliminar/quitar privilegios para un usuario USUARIO desde una dirección HOST para una base de datos DB
mysql> REVOKE privilegio1 [, privilegio2 ...] ON db.* FROM ‘usuario‘@’host;
  • Eliminar un usuario desde una dirección de HOST
mysql>  DROP USER ‘USUARIO’@’HOST’
  • Cambiar contraseña a un usuario desde una dirección host
mysql> SET PASSWORD FOR ‘usuario’@’host’ = PASSWORD(‘contraseña’);


Para finalizar el ejercicio vamos a crear una base de datos prueba, con unas tablas. Vamos a crear un usuario prueba que tenga permisos para ver solo 1 de las tablas. Cerrar la sesión de consola en mysql y abrirla de nuevo con este nuevo usuario. Comprobad la visibilidad del nuevo usuario.
Avanzado:
Para conectar desde un equipo remoto mediante consola ejecutaremos:
mysql -h nombrehost|ip -u usuario -p

Esquema E-R + Modelo Relacional + Create Table + Insert Data





1. Esquema E-R





2. Esquema E-R en WorkBench




3. Modelo Relacional

Profesores (Identificador, DNI, Nombre, Dirección, Teléfono)
Módulos (Código, Nombre, Identificador del profesor)
Alumnos (Número de expediente, Nombre, Apellidos, Fecha de nacimiento, Número de delegado)
Matrículas (Nº expediente del alumno, Código del módulo)



4. Creación de BDs y Tablas con Forward Enginner. Diagrama E-R => DB en MySQL Server

Para ello vamos a seguir el siguiente link de la documentación oficial de MySQL:

5. Scripts de Creación de tablas equivalente




CREATE DATABASE bd_instituto;
USE bd_instituto;

CREATE TABLE profesores(
id INT AUTO_INCREMENT,
nombre VARCHAR(50) NOT NULL,
direccion VARCHAR(100),
telefono VARCHAR(20),
CONSTRAINT pk_profesor PRIMARY KEY(id)
);

CREATE TABLE modulos(
codigo INT AUTO_INCREMENT,
nombre VARCHAR(50) NOT NULL,
id_profesor INT,
CONSTRAINT pk_modulo PRIMARY KEY(codigo),
CONSTRAINT fk_profesor FOREIGN KEY (id_profesor) REFERENCES profesores(id)
);

CREATE TABLE alumnos(
numero_expediente INT AUTO_INCREMENT,
nombre VARCHAR(50) NOT NULL,
apellidos VARCHAR(50) NOT NULL,
fecha_nacimiento DATE,
numero_delegado INT,
CONSTRAINT pk_alumno PRIMARY KEY (numero_expediente),
CONSTRAINT fk_delegado FOREIGN KEY (numero_delegado) REFERENCES alumnos(numero_expediente)
);
CREATE TABLE matriculas(
expediente_alumno INT,
codigo_modulo INT,
CONSTRAINT pk_matricula PRIMARY KEY(expediente_alumno, codigo_modulo),
CONSTRAINT fk_alumno FOREIGN KEY (expediente_alumno) REFERENCES alumnos(numero_expediente),
CONSTRAINT fk_modulo FOREIGN KEY (codigo_modulo) REFERENCES modulos(codigo)
);

SHOW TABLES;
DESCRIBE profesores;
DESCRIBE modulos;
DESCRIBE alumnos;
DESCRIBE matriculas;




6. SQL de inserción de datos



INSERT INTO profesores VALUES
(DEFAULT, 'Josep', 'C/Principal', DEFAULT),
(DEFAULT, 'Maria', 'Plaza Mayor', '93-555-67-78');

select * from profesores;

delete from modulos;

INSERT INTO modulos VALUES
(100, 'mates', 1),
(200, 'lengua', 2),
(300, 'física', 1),
(400, 'filosofía', 2);

select * from modulos;

delete from alumnos where numero_delegado is not null;
delete from alumnos;

INSERT INTO alumnos VALUES
(10, 'Isabel', 'Ribes',   NULL, NULL),
(20, 'Raúl',   'Ríos',   '1978-02-01', 10),
(30, 'Carmen', 'Giménez', NULL, 10),
(40, 'Laura',  'Lahoz',   '1981-11-20', NULL),
(50, 'Ana',    'Medina',  NULL, 40),
(60, 'Juan',   'Sánchez', NULL, 40),
(70, 'Jesús',  'Pena',    NULL, 40);

select * from alumnos;

INSERT INTO matriculas VALUES
(10, 100), (10, 300),
(20, 400),
(30, 200), (30, 400),
(40, 100), (40, 200), (40, 300),
(50, 200),
(60, 100), (60, 300),
(70, 100), (70, 200), (70, 300), (70, 400);

select * from matriculas;





7. Tablas resultantes de los scripts anteriores



Profesores
id
nombre
direccion
telefono
1
Josep
C/Principal
Null
2
Maria
Plaza Mayor
93-555-67-78




Módulos
codigo
nombre
id_profesor
100
mates
1
200
lengua
2
300
física
1
400
filosofía
2






Alumnos
numero_expediente
nombre
apellidos
fecha_nacimiento
numero_delegado
10
Isabel
Ribes
null
null
20
Raúl
Ríos
1978-02-01
10
30
Carmen
Giménez

10
40
Laura
Lahoz
1981-11-20
null
50
Ana
Medina
null
40
60
Juan
Sánchez
null
40
70
Jesús
Pena
null
40



Matrículas
expediente_alumno
codigo_modulo
10
100
10
300
20
400
30
200
30
400
40
100
40
200
40
300
50
200
60
100
60
300
70
100
70
200
70
300
70
400