20 Síntomas De Que Podrias Ser Un Geek

¿Quien no se ha hecho la clara pregunta, o presume de ser un Geek?

Pues aquí les traigo una lista de 20 síntomas de que podrías ser un Geek.

• Coleccionas mensajes de SPAM graciosos.
• Le hablas a tus computadoras, no porque estés aburrido, sino porque tienes miedo de que ellas estén aburridas.
• La proporción de computadoras a humanos en tu casa es de por lo menos 4:1.
• Estás totalmente libre de las líneas de bronceado.
• Cuando alguien dice ‘deportes organizados’ piensas en ‘LAN party’
• Has perdido prácticamente todas tus habilidades sociales.
• Nunca las usaste de todas formas.
• Cuando tienes que conversar con otros, hablas un lenguaje encriptado de acrónimos descifrables solamente por otro geek.
• Ningún “sello de garantía” está seguro en tu presencia.
• Tienes una caja gigante de cables de sobra que nunca usas.
• Nunca podrían convencerte de separarte de ella.
• Quieres que te entierren con tu monitor CRT Trinitron de 21″.
• Entiendes porqué ‘42′ y ‘AYBABTU’ son graciosos, y todavía te causan gracia.
• Le tienes miedo al teléfono.
• Siempre estás libre un viernes en la noche. Libre para jugar tu MMORPG favorito.
• Consideras el término ‘Geek’ un cumplido.
• Tus amigos no-geeks no tienen idea de qué haces para ganarte la vida.
• Acampar en el bosque, sin electricidad, o acceso wireless es tu idea de una pesadilla, no de unas vacaciones.
• Tienes más de 30 cuentas de E-mail, y las chequeas todas regularmente.
• Entiendes mejor a las computadoras que a la gente.

Yo se que muchos, se sienten Geek ahora…

¡En mi máquina sí funciona!… excusas comunes de los programadores

20. ¿Pues es raro??
19. ¿Nunca había pasado antes.?
18. ¿Pues ayer funcionaba??
17. ¿Cómo es posible??
16. ¿Tiene que ser un problema de tu hardware.?
15. ¿Qué hiciste mal para lograr que fallara??
14. ¿Algo debe de estar mal en tus datos.?
13. ¿Si no he tocado ese módulo en meses!?
12. ¿Debes de estar usando una versión anterior.?
11. ¿Es solo una desafortunada coincidencia.?
10. ¿Es que no lo puedo probar todo!?
9. ¿ESTO, no puede ser la causa de ESO?
8. ¿Funciona, pero no lo he probado?
7. ¿Alguien debe de haber cambiado mi código!?
6. ¿Has comprobado que no haya algún virus en tu sistema??
5. Ya se que no funciona, ¿pero te gusta??
4. ¿No puedes utilizar esa versión en tu sistema?
3. ¿Por qué quieres hacer eso??
2. ¿Y tú dónde estabas cuando se colgó el programa??
1. ¿EN MI MAQUINA SI FUNCIONA!?

Ahora ya saben qué decir cuando el sistema no les funcione, el código no corra y afines…

21 errores comunes programando en PHP

Leyendo en Zend.com, encuentro una completa lista de errores comunes de los programadores de PHP.
Aunque muchos de los que programamos constantemente en PHP hemos superado varios puntos, siempre hay cosas en las que caemos, pudiendo mejorar la calidad de nuestro código.

Los errores están divididos en 3 partes, siendo los primeros los mas "benignos" y los últimos, "críticos". Comentare los más importantes.

Parte 1

Uso impropio del printf

Abusando de la semántica
Esto es, básicamente, no usar una misma variable para guardar en un momento números, en otras cadenas de texto, o hacer funciones que por parámetros reciban variables de varios tipos de datos.
Una adecuada forma es la declaración de variables antes de usarlas, mantener un mismo tipo de datos para todas las variables, etc.

Falta de documentación por línea
En pocas palabras, es saber crear comentarios adecuados, no hacer un comentario por línea, pero tampoco una palabra por función, además de hacerlos comprensivos, lógicos y no estupidos, como:

Código :

//Esta función imprime
function imprimir($datos){
    echo $datos;
}

Creación de demasiadas variables temporales

Rescribir funciones existentes de PHP
Esta es muy común, si no sabes que hace PHP y tienes un problema para lo que PHP tiene ya una función que lo soluciona, pero haces una función propia que haga lo mismo.
Hay que leer

No separar el lado del cliente del lado del servidor
Lo que muchos principiantes hacen, llenar de echos el código HTML, no hacer plantillas, ni siquiera funciones para separar lógicamente la parte de PHP de la parte de HTML.

Usar paradigmas del siglo pasado
PHP es muy flexible, por lo que puedes usar aun cosas como "if endif" o "while endwhile", pero eso es taaan viejo, como usar GOTOs.
Otro ejemplo similar es seguir usando variables globales al recibir valores de formularios, hay que actualizarse.

Parte 2

No seguir convenciones básicas en los nombres
Poner cosas como $xdb2 a una variable o convfunxml() a una función, son practicas muy malas, que llevan al desastre al mantener una aplicación. En las variables, lo mas recomendado es mantener "simples" las cosas, mientras que en las funciones, hacerlas lo mas "verbales" posible seria lo mejor.

Usar de una manera horrible la conexión a bases de datos
Gente que trae todos los resultados de una consulta solo para ver si es mayor que cero, hacer la consulta columna por columna en vez de traer un recordset completo, usar PHP para ordenar los resultados en vez de SQL, esas son formas horribles de conectarse a una DB.

Falta de detección de errores
Asúmanlo, ocurrirán errores, sea porque al hosting se le lleno la tabla de temporales, porque se acabo el espacio en disco que tenían, porque un usuario encontró una manera de saltarse una validación de datos o por lo que sea, siempre, en cuestiones delicadas (Consultas, escritura al disco, etc) hay que hacer control de errores.

Sobrepasarse con la programación orientada a objetos
PHP aun no esta 100% orientado a objetos de una manera estricta, de modo que aunque usemos MVC, frameworks como PEAR entre otras muchas cosas, podemos llegar a sobrepasarnos en el uso de POO en PHP, creando una serie de clases, métodos y propiedades exagerada que probablemente nos den mas problemas que beneficios en el futuro. No hay que exagerar

Mal uso de las expresiones regulares
Aunque es un tema muy avanzado, las expresiones regulares son muy útiles en muchos casos donde debemos analizar cadenas de texto raras para obtener resultados; pero son lentas, por lo que no hay que usarlas para tooodo, como reemplazar patrones simples en cadenas, buscar un carácter, etc.
Existen muchas funciones de manejo de strings ya hechas y más fáciles de usar.

Programar en PHP como si fuera otro lenguaje
Mucha gente que empieza en PHP, viene de otros lenguajes y con ello, traen también sus mañas y costumbres de acuerdo a cada uno de ellos.
Los de Perl que les fascina programar todo en una sola línea, los de Java que directamente hacen un framework orientado a objetos de modo que en el código HTML solo haya $pagina = new Pagina();, los que se ponen a renombrar o rescribir funciones inherentes de PHP, etc. De nuevo, hay que leer.

No ser consciente de la seguridad
PHP puede ser programado elegante o terriblemente... y aun así dar el mismo resultado a los ojos del usuario; cosas como las protecciones básicas de seguridad son olvidadas.
No permitir que, en un campo que se usara en una consulta a una DB, un usuario ponga comillas simples o punto y coma, tomar todos los valores raros y hacerles "escape" (Es decir, poner un backslash en frente de ellos) y en general validar dentro de PHP todos los valores que puedan haber sido escritos a mano es una responsabilidad nuestra.

Parte 3

Cortar y pegar; el camino incorrecto
Siempre haces la misma función de validar un correo electrónico, la misma de conectarse a la base de datos, etc... ¿Copias y pegas cuando lo haces?
Es mas optimo crear una librería de tus propias funciones, también puedes usar librerías como PEAR y demás, pero recuerda, solo usa librerías de una fuente conocida o crea las tuyas.

No tener guías de estilo de codificación en un proyecto
Iniciar proyectos "por mis huevos" siempre ha sido un error; cuando inicias un proyecto, sin importar si eres tú solo o tienes un grupo de trabajo, hay que definir unos lineamientos de codificación.
Que variables son globales y como deberían ser marcadas como global, la estructura de las carpetas de código, convenciones de los comentarios, procesos de documentación, etc.

No hacer una revisión de código
Revisar nuestro código después de hecho, ver que hace, que se puede mejorar, etc, es algo que siempre se obvia, mucho mas en nuestra cultura donde todo es "urgente" (Sobre todo hacer prilouders).
¿Cuál era el propósito de X código?, ¿Cómo se relaciona el archivo X con los demás en el proyecto?, ¿Cómo verifica los errores el programa?, ¿Dónde podría encontrar errores el usuario?... etc.

Hacerle "hacks" al código PHP abusando de fallos de diseño
Tu lo sabes, tu sabes cuando estas haciendo un código feo, sabes cuando estas solucionando algo de la peor manera, sabes cuando estas metiendo a las patadas un código para que algo funcione... no lo hagas, recapacita, piensa en los niños.

Excluir al usuario del proceso de diseño
El usuario, ese engendro infernal que nos hace eliminar, corregir, cambiar, actualizar, repetir, borrar y maldecir. ¿Por qué no lo metemos al proceso, hacemos prototipos de prueba, le mostramos todo, vemos si vamos por buen camino? La mayoría de problemas con los usuarios finales es por culpa de nuestra discriminación (con razón) hacia ellos... Cada vez que ignoras a tu usuario, Dios le quita un punto y coma a una parte aleatoria de tu código.

No apegarse al plan del proyecto
¿Seguiste el análisis, diseño e implementación como estaban planeados?, de hecho, ¿Lo hiciste si quiera en ese orden?; cuando se planea un proyecto y en un punto debes salirte del esquema planteado, sabes que las cosas irán mal.

Perderte en el tiempo
Los programadores, por defecto, son optimistas; "Si, eso sale en un mes", decimos.
No subestimes la complejidad de nada, tiende a pedir el doble de lo que necesitas, de cualquier manera, siempre lo querrán en la mitad del tiempo. Conocete a ti mismo, conoce tu trabajo, pide el tiempo real, pide mas que eso y se conciente de cuanto código llevas, cuanto te falta y cuanto tiempo tienes.




No solo a PHP aplican estos "errores comunes", pero de cualquier manera tenerlos en cuenta muy seguramente te ayudara en la mayoría de proyectos que inicies.
Aunque claro, siempre hay gente que jamás cae en estos errores.

¿Como tu?

Tomado de http://www.cristalab.com/blog/14290/21-errores-comunes-programando-en-php

10 errores comunes programando orientado a objetos en PHP

El dominio de la programación orientada a objetos es, sin duda, uno de los paradigmas más codiciado por los programadores. Sin embargo, muchas veces estos cometen "atrocidades" al intentar implementarlo solo por decir a sus amigos, empresas u otros "Yo sé programar orientado a objetos".

A continuación verán una lista de 10 cosas que no se deben hacer al implementar programación orientada a objetos enfocándonos en el lenguaje PHP.

1. Usar variables globales dentro las clases: una de las ventajas más importantes de la programación orientada a objetos es la reusabilidad de los códigos. Al usar variables globales ($_GET, $_SESSION, $_POST, $_COOKIE, global) dentro de las clases, esta se ve comprometida considerablemente. La razón es que todos los proyectos no tienen las mismas variables globales.
   
   
2. Mezclar código HTML en la definición de las clases: es una de las cosas que me sorprenden cada vez que la veo. Es inaceptable que esto se le haya ocurrido a algunos. Al mezclar HTML en el código PHP se compromete la reusabilidad de la clase, no todos los proyectos tienen el mismo código HTML.
   
   
3. Imprimir salida (echo) dentro de las clases: aunque esto se parece a la anterior, me refiero a los echo o similares dentro de los métodos. Si una clase no está destinada para emitir salida no lo debe hacer. Para eso muchos utilizamos sistemas de plantillas.
   
   
4. Identificadores de clases, métodos y propiedades sin sentido: un identificador siempre debe ser lo más descriptivo posible. A muchos le gusta usar identificadores increíblemente irrelacionados con su propósito. Esto compromete enormemente la lectura de un código. (Mira las reglas de codificación en PHP)
   
   
5. Mezclar uso de versiones de php en una misma clase: a partir de la versión 5 de PHP, la programación orientada a objetos se puede implementar de una manera más formal, pues se introdujo los modificadores de visibilidad public, private, protected. Aparte de que se pueden crear clases de alto nivel (clase Abstractas) y métodos abstractos con la palabra reservada abstract. También se pueden definir los métodos y propiedades estáticas formalmente con la palabra reservada static. Mezclar la programación orientada a objetos en PHP 4 (donde todo era publico) con la de PHP 5 hace un código “sucio”. Consejo: elige una de las versiones y programa para ella.
   
   
6. Más de una clase en un mismo archivo: definir distintas clases en un mismo archivo es otra de las cosas que no se debe hacer. Las clase se han de componer lo más reusables posible y si puedes nombrar al archivo con el nombre de la clase muchísimo mejor. Sigue el camino de los grandes lenguajes como: Actionscript, Asp.net, Java entre otros.
   
   
7. No hacer pruebas unitarias a las clases: al terminar de codificar una clase recuerda de hacer pruebas unitarias para asegurar el correcto funcionamiento de clase. Esto es simplemente probar todos los posibles caminos que pueda tomar un estado (propiedad), parámetro de método, etc para que la clase no “explote”.
   
   
8. Todos los métodos y las propiedades publicas en una clase de PHP 5: los programadores novatos cometen el error de definir todos los métodos y propiedades como públicos, por desconocer las ventajas de los modificadores visibilidad. En PHP este es un problema grave porque no hay tipeado de datos. El problema de las propiedades públicas es que no podemos controlar de manera fácil el tipo de datos que contiene por lo que nuestra clase pudiera explotar por un tipo de dato inesperado. Si no estas seguro de que visibilidad le debes poner a una propiedad hazla privada. Valida los tipos de datos de las propiedades al menos de una manera básica.
   
   
9. Duplicación de métodos para ocultar falla de lógica: A diferencia de otros lenguajes como Java y C++, PHP no admite la sobrecarga de métodos. Al menos no de la manera tradicional. Esto, sin embargo, no es excusa para duplicar métodos sólo porque un dato cambia para la operación que éste realiza.
   
   
10. Variables de configuración dentro de las clases: Los datos de configuración de base de datos, web services y otros deben ir en un archivo de configuración aparte, NO dentro de la clases que hacen uso de estas. Aunque se admite en clases que sea exclusivamente para ello.

Tomado de http://www.cristalab.com/blog/41916/10-errores-comunes-programando-orientado-a-objetos-en-php

Un poco de seguridad en redes WIFI

Simplemente daré algunos consejos para proteger nuestra red inalámbrica de manos ajenas, la metodología varia según el router ( que tengamos 3com, Zyxel , GST, Lynsys, D-Link… así que estos son los pasos a seguir :)


1- Inhabilitar la emisión de broadcast del SSID, esconder el ESSID.

Con esto evitaremos que nuestra red pueda ser detectada por cualquier scanner, si no sabemos el nombre no podremos conectarnos.

2- Activar el filtrado de direcciones Mac.

De esta forma solo podrán acceder a la red aquellos ordenadores cuya Mac de su tarjeta de red este configurada en nuestro router ( a menos que nos suplanten la dirección Mac) :S .

3- Utilizando passwords.

Poniendo una clave WPA o WEP ya estaremos poniéndole las cosas más difíciles a cualquiera que quisiera entrar en nuestra red.


4- Cerrando puertos.

Esto puede variar según el router, lo configuraremos de tal manera que solo se pueda acceder al router por medio de nuestra Lan nunca desde Internet. (23 Telnet (nuestro router) , 21 FTP, 80 http, etc…).

5- Cambiando el user y pass por defecto.

Cambiaremos el Usuario y pass de acceso por defecto al router, normalmente suele ser 1234, adminttd, intel… depende del modelo.

6- Poniéndole nombre a nuestra red.

Si seguimos el paso 1 y dejamos el nombre por defecto “Wireless“, cualquiera podría entrar,… por ello cambiaremos el nombre, y si encima ponemos algo de “Lan” “WLAN”, quizás hagamos pensar que no tiene salida a Internet por ejemplo…, aquí cada cual con su imaginación :P .

7- Inhabilitar DHCP.

Las ip’s deben ser fijas, no se le asignara ip a alguien que intente conectarse, por lo tanto se lo tendrá que currar adivinando los rangos y tal.

8- Actualizar el firmware del router.

Esto como siempre depende del modelo, a mi personalmente solo me ha servido para que valla mejor el aMule y añadirle una nueva característica a la configuración de mi Router para poder limitar el ancho de banda, aparte de esto suelen también corregir alguna falla de seguridad, bug…

9-Reducir el alcance de la señal.

Reducir la señal lo justo que necesitemos (esto varia según el modelo del router, en algunos no es posible).

10- Desconectar el punto de acceso cuando no este en uso.

Lógico, ¿si no lo usamos para que tenemos nuestro router encendido?, ¿para que el vecino navegue por el hiperespacio?, ¡a menos que dejemos nuestro ordenador con la mula, server, irc o lo que sea, claro!.

Creo que con estos pasos nuestra red estara un poco mas segura :)

Optimizar ICEWEASEL para navegar más rápidamente

Escribimos en la barra de direcciones de Iceweasel lo siguiente: about:config
En el campo "filtro" ponemos: pipelining

Modificamos los valores tal como aparecen aquí. Para ello hacemos doble click sobre cada línea.
network.http.pipelining como true
network.http.pipelining.maxrequests como 10
network.http.proxy.pipelining como true



Por último, creamos un nuevo valor picando con el botón derecho en un espacio vacío y seleccionamos NUEVO / ENTERO y escribimos:

Nombre de la cadena: nglayout.initialpaint.delay [ENTER]
Valor: 0 [ENTER] es un cero

Una vez realizados estos pasos y dependiendo de la conexión, la navegación será más rápida, pues el navegador procesará varias consultas a la vez y mostrará los datos conforme van llegando.

Fuente: http://www.therror.com/weblog/2005/ago/como_optimizar_firefox

Instalar Envy en Debian Lenny y Sid

Envy es un script de instalación de drivers gráficos del que ya hemos hablado en Kernel Source. En principio fue diseñado para Ubuntu, aunque más tarde dio soporte para Debian Etch. Ahora en su blog oficial explican algunas modificaciones que aplicarle al script para que los usuarios de Debian Lenny (testing) o Sid (inestable) puedan usarlo en sus sistemas. Si es tu caso y quieres usar Envy debes editar el fichero /usr/share/envy/instun/classes.py, y en la línea 324:

 elif self.details['osname'] == 'cassandra':#SUPPORT FOR LINUX MINT CASSANDRA
 self.details['osname'] = 'feisty'#this will make it act like feisty

Si usas Debian Lenny (testing) sustituir donde pone ‘cassandra‘ por ‘lenny‘ y donde aparece ‘feisty‘ por ‘etch‘. En caso de querer adaptarlo a Debian Sid (inestable) habrá que poner ‘sid‘ en vez de ‘lenny‘:

 elif self.details['osname'] == 'lenny':#SUPPORT FOR LINUX MINT CASSANDRA
 self.details['osname'] = 'etch'#this will make it act like feisty

Como siempre digo con este tipo de scripts hay que ser muy cuidadoso, ya que no son herramientas que realicen su tarea con la eficiencia de los gestores de paquetes de las distribuciones. No digo que no sean útiles, sólo que se debe extremar la precaución por ejemplo haciendo copias de seguridad de los ficheros de configuración de las X (/etc/X11/xorg.conf). No en vano, estaremos configurando la tarjeta gráfica y si algo falla, obtendremos una bonita terminal como premio.

La insólita ocurrencia de una pareja china

Una pareja china ha intentado llamar a su hijo “@”, alegando que el caracter usado en las direcciones de correo electrónico se hacía eco de su amor por el bebé.

El inusual nombre sorprende especialmente en chino, que no tiene alfabeto y en su lugar usa decenas de miles de caracteres múltiples para escribir las palabras.

“El mundo entero lo usa para escribir el correo electrónico, y traducido al chino significa ‘lo queremos’”, explicó el padre, según el vicerresponsable de la Comisión Estatal del Lenguaje, Li Yuming.

Aunque la “@” es familiar para los usuarios de correo electrónico, el término se pronunciada en inglés “at” y si se extiende el sonido de la “T” suena como “ai ta”, o “le quiero”, según los hablantes de mandarín.

Li no dijo si las autoridades habían aceptado el nombre, pero este mismo año había anunciado que el Gobierno había prohibido nombres que usaban numerales o idiomas extranjeros y símbolos que no pertenecen a las lenguas de la minoría china.

Unos 60 millones de chinos se enfrentaban al problema de que sus nombres usan caracteres antiguos que los ordenadores no reconocen, según Li.

Vía Yahoo, Reuters