SlipknotFERMO

Bueeeno, tuve un rato para hacerlo pero bueno, espero que les guste!! Especial Garry's mod 10, POLOCIAS EN ACCION ARGENTINA! Estan en apuross!! Y candela?? Y la moto?!?! Seguimos con la efedrina... Se armo en la 9 de julio... Espero que les guste, como me gusta sacarle alguna que otra sonrisa a la gente... Si van a comentar con mala onda, diciendo que esto es re-post (cosa que no creo porque lo akbo de hacer), y diciendo huevadas ni siquiera comenten, comenten con onda si??

Hoy, a las 17:00 encontre un post para tener una key de un juegito (Como ahora estoy sin trabajo, no me queda mas que limosnear juegos para aumentar el nivel de mi virginidad), cuando me encontre con la palabra del comandante en el chat de la pagina, y mas aun, estaban mancillando la voz y la imagen de nuestro queridisimo. Espero haberlo defendido como se debe. Sin mas, les dejo las imagenes.

Buenas gente, espero que anden bien. Antes que nada quiero aclarar, no descubri la existecia de vida en Marte. Es solo un pequeño post, para programadores que por ahi no estan muy metidos, o estudiantes como yo, que aprenden mas de prueba y error e investigacion, que de los propios estudios. Hace un tiempo empecé a usar Ubuntu, y me di cuenta lo buen S.O. que es. Me empecé a plantear ciertos interrogantes, y principalmente sobre la portabilidad de los programas que estamos haciendo. Sobre todo con las funciones system( "cls" ) para Windows y system( "clear" ) para Linux. Realmente estaba programando en Vim, y no tenía ganas de cambiar la función clear cada vez que iba al Lab a programar, entonces empecé a investigar (De esto, hace un par de meses). Y llegue a varias respuestas, por ejemplo, hacer un for imprimiendo cout<<endl; que "limpiaba" la pantalla imprimiendo espacios vacíos. La verdad que esto quedaba feo, por lo que seguí investigando y di con una función, de la librería <cstdlib> que se llama getenv. Su prototipo es el siguiente: char* getenv ( const char* name ); Basicamente le pasamos una cadena de texto (Una variable de entorno) y devuelve otra. Parece que mucho no sirve, pero investigando un poco, llegue a esto: getenv( "OS" ); Así, esta funcion me retorna el nombre del sistema operativo, pero solo en el caso de Windows. Ejecutando en Windows 7 64 Bits algo así como: cout<<getenv( "OS" ); Saca por pantalla esto: Windows_NT Este ( "OS" ), es una variable de entorno del sistema operativo, únicamente de Windows, por lo que se. La particularidad de la funcion, es que si le paso una variable de entorno “incorrecta”, me devuelve un puntero NULL (El mismo tipo de dato cuando tenemos problemas para abrir archivos con fopen("",""; )...). Peeero, no sirve para Linux, ya que Linux no tiene (No conozco todas las versiones, pero Ubuntu no) una variable de entorno llamada "OS". Entonces me dije, bueno, no me sirve para identificar el sistema operativo, pero si para decantarme por si es Windows, o Linux. ¿Cómo? con lo siguiente: if( getenv( "OS" ) == NULL) { system( "clear" ); } else { system( "cls" ); } Con esas 7 líneas de código, me pregunto si el puntero que me devuelve es NULL (Indicando que no se está ejecutando el programa sobre Windows), y en ese caso hago un clear al estilo Linux. En el else, simplemente hago un clear al estilo Windows. Como ya dije, no me sirve para identificar un MacOS de un BerOS, pero aumento la portabilidad muchísimo, sabiendo en cuál de los 2 sistemas operativos líderes se está ejecutando el programa compilado. Y de yapa, les dejo la funcion que hice, que no es gran cosa, para reemplazar el system( "pause" ), por algo más portable: cout<<"Presione cualquier tecla para continuar..."; cin.ignore(); cin.get(); Las 2 funciones están probadas en Windows 7 64 bits y en Ubuntu, tanto en tiempo de compilación como de ejecución, y no dan ningún problema aparente. Nada más que eso. Si llegaron leyendo hasta acá, es porque de verdad les interesa. Son libres de usarlas cuantas veces y donde quieran. Me llevo mucho tiempo investigar sobre esto, así que si las usan, solo les pido un "Gracias", no cuesta nada. Saludos gente! Suerte!

Buenas gentes, espero que anden bien. Hoy estaba pensado que postear en Pori... Digo, Taringa!, y me puse a pensar, cosa que no hago muy seguido. Se me ocurrió hacer un post sobre algo que tiene que ver con la programación, que es donde veo que muchos fallan (Tanto principiantes como expertos...) El formateo de código, como darle formato a un código para que sea entendible lo más rápido posible con el menor esfuerzo necesario. Cabe aclarar, que es un post para principiantes. Es para ayudar a lo’ pibe’ que están estudiando hace poco, que no estudian y saben un poco, o para gente que quiera mejorar un poco el formateo. El formateo de código lo maneja cada uno, y es más, código “Spaghetti” para uno puede ser más entendible que para otro, es así. Pero manejarse de forma ordenada, es casi un estándar que se maneja en la industria. Corta, si tu código es un quilombo, nadie lo va a querer ver, y va a hacer más difícil que labures en equipo. El post lo escribo desde mi experiencia, y de haber leído algunos libros, entre ellos (Como programar C, C++ y JAVA, de Deitel & Deitel). Buenos vamos allá… El post está orientado a tips, ejemplos, y ayudas de cómo escribir código legible, tanto para nosotros, como para personas ajenas a nuestro código, que eventualmente tengan acceso al mismo. Yo voy a estar programando en un IDE (Code::Blocks), en lenguaje C++. Pero esto se aplica para casi cualquier lenguaje. Solo hay que saber aplicarlo, sin saber el lenguaje en sí. Primero vamos a empezar con un programa sencillo. Un programa por consola, que pida el ingreso de 2 números, haga operaciones y los muestre por pantalla. La programación serial algo así: El programa va a funcionar perfecto, y es un programa sumamente sencillo, y mucho mas para el propio programador. En el ejemplo, mucho no habría que formatear por la extrema sencillez del mismo, pero igualmente lo vamos a hacer. Lo primero que haría, seria separar las cabeceras (Los include), de las definiciones de los namespaces. No parece gran cosa, pero quedan mejor a la vista las cabeceras, para saber con qué cabeceras estamos trabajando. Vuelvo a repetir, para trabajos sencillos y cortos no haría falta, pero imagínense que trabajamos con 13 o 14 cabeceras, y no tocamos el proyecto por algunos meses… Sería algo así como empezar de 0… Lo segundo que haría, es, por ejemplo, la funcion main que tiene un parámetro vacío (VOID), lo aclararía, aunque no haga falta, para la vista es más fácil leer void, que no leer nada, y lo hace mucho más fácil de leer. Adicionalmente, todo lo que valla entre paréntesis, me gusta dejarle espacios entre cada paréntesis. Hace que las sentencias dentro de los paréntesis sean mucho más fáciles de leer, inclusive, cuando hay funciones dentro de esos paréntesis. Lo tercero que haría, seria bajar los corchetes, hace que visualmente, los corchetes queden alineados verticalmente, y créanme, ayudan MUCHISIMO. Otra cosa que haría, es, separar las definiciones de variables por tipo, y hasta separarlas por variables, hace que el código sea un poco más largo, pero mucho más entendible. Asimismo, los programadores tenemos la mala costumbre que, para escribir código rápido, usamos nombres crípticos para las variables. Tales como n1, n2, res, son fáciles de “sacar”, pero si usamos variables parecidas para representar cosas como Articulos por mes, y Articulos por mesada, si estamos lo suficientemente locos escribiríamos algo como artxmes, artxm, y cuando leemos ese código después de unas semanas, estamos al horno porque ni idea tenemos que es. Siempre recomiendo, nombres claros, más largos hacen que escribamos más, pero hace entendible el código. Por una elección personal, prefiero hacer nombres largos, que apunten de que se trata, aunque tenga que escribir más. Usando el ejemplo anterior, haría algo como Articulo_Mes y Articulo_Mesada. Cuando combinemos structs y vectores y objetos, este método hace que sea extremadamente fácil la comprensión y escritura de un programa. Luego, algo que hago, es separar con espacios verticales (Enter), distintos tipos de acciones que haga el programa. Por ejemplo, separo las entradas y salidas, cálculos, definiciones, decisiones o ciclos, para que a la hora de hacer una búsqueda rápida, sea más fácil para la vista. A nivel consola, agrego alguna pausa y algún clear, para que al momento de laborarlo (En tiempo de ejecución) quede más lindo. Al final el código terminaría quedando algo así: Se puede ver, que el programa se hace un poco más largo, de hecho se duplica, a nivel líneas de código, pero entenderlo se hace extremadamente fácil. Por ejemplo, acá dejo un main de un programa en el que estoy laburando, que no se va a ver nada, porque le hice un zoomout, pero ya se puede notar como esta ordenado el código, ya de lejos, se notan “módulos” de laburo, lo que hace más fácil entender ciclos, decisiones, y muchas cosas más. Vuelvo a decir, son cosas básicas, que gente experimentada no solo que ya lo sabe, sino que incluso, lo puede mejorar y muchísimo, pero a nivel de formateo de código, es lo mejorcito que se puede hacer. Recapitulando, algunas cosas básicas: -Modulariza, separa por módulos de programa, cabecera, definiciones, inicializaciones, etc… -Si usas paréntesis, sepáralos de la sintaxis interna, así queda más claro que es lo que pasa dentro de ese paréntesis. -Para las variables, funciones y demás cosas, usa nombres entendibles fácilmente, los nombres crípticos complican el código. -Aunque no sea necesario, en parámetros de funciones, si no pasas nada, usa el void, hace que sea más fácil leer las funciones. Bueno, ya se hizo muy largo el post, y no era la idea. Si veo que gusta, voy agregando algunas cosas para meterse más. Nos vemos linces trota montes de las estepas mesopotámicas del norte.

Buenas linces, robertos, troesmas, lincesas, adoracommanders y demas! Bueno les queria contar, que mi novia tiene una PS2 ya hace años, y la queria vender, el tema, es que no leia un culo, ni cds ni dvds, un pijaso... Tonces me puse a googlear, y me encontre que hay poca info del laser de la 77001. Por lo que decidi meter mano yo. En cuestion, el bicho es el modelo SCPH 77001... Esta en cuestion, pero muchisimo menos hecha mierda... Bueno, lo que hice fue calibrar el laser, tanto de CV como de DVD. Hay una realidad, los laser se van gastando y pierden potencia, hasta el punto, que hay que cambiarlo... Minga, las tarlipes, las bolas, no voy a comprar un repuesto que seguro me va a costar conseguir y va a salir caro para despues cambiarlo y venderlo. Este es el laser: Bueno, basicamente tiene el laser, 2 potenciometros, los cuales ajustan la potencia del mismo, a menos Ohms mas potencia... Si ya se, a mas potencia mas desgaste, pero a que no lea... Esta claro... Como esta en la imagen, los 2 potenciometros median lo siguiente apenas desarme todo: Los potes son los siguientes, y aca se marcan los 2 pines que deben medir! El pote de arriba 1,562 KOhms 1562 Ohms El pote de abajo 0,805 KOhms 805 Ohms Bueno, dije no me queda otra que ir probando, fui haciendo pruebas (Armando y desarmando la ps2, xq no tengo un banco de pruebas decente) y termine llegando a estos valores, los cuales hicieron que la play funcione como el primer dia. El pote de arriba 1,2 KOhms 1200 Ohms El pote de abajo 0,600 KOhms 600Ohms Con estos valores, no solo hice que la play lea juegos que daba por perdido (Fuck yeah, a viciar budokai hasta que la venda), si no que bajo los tiempos de carga de minutos a segundos. Eso solo gente, queria compartirlo, porque no vi mucha info para calibrar el lente de este modelo. Para saber como medir, o me preguntan, o buscan en inet, es una boludes... Nuestro mejor amigo www.google.com.ar, esta siempre presente. Hasta luego gente, nos olemos!

Bueno gente malformada mentalmente. Solo eso, estaba reparando el firm de un celular, un Samsung Galaxy I5500L el cual es imposible entrar al recovery por medio de combinacion de botones. Entonces me meti con el ADB y los putos drivers y cosas asi. Y se me ocurrio algo, hacer un ADB que "no necesite instalacion". Porque entre comillas? ahora lo explico. El ADB consiste en 2 partes. Una son los drivers del celular. Si bien no tienen nada que ver con el ADB, si no tenes los drivers, no lo podes usar. La otra, es el ADB en si. Son 4 archivitos. El adb, fastboot, y 2 dlls. Estas dlls generalmente se instalan en el system32, para que tengas acceso desde la consola. Bueno, para evitar una parte, que es la instalacion del ADB, hice un programa, que copia todo lo necesario, al system32 de las pcs (SI, SOLO FUNCIONA EN WINDOWS), y luego, tiene los comandos mas comunes del ADB. 1 - adb devices 2 - adb get-state 3 - adb reboot 4 - adb reboot recovery 5 - adb reboot-bootloader 6 - adb get-serialno 7 - adb backup -all 8 - adb restore backup.ab Solo descompiman, ejecuten como admin el ADB Tools.exe y ya. Si desconfian de un tadinga, pasenle el antivirus. Les dejo el print de mi AV, que dice que esta limpio como ojete de quinceañera. Con eso es suficiente para hacer lo justo y necesario para laburar el firm de un celu. Se los adjunto en mi carpetita de dropbox. Usenlo todo lo que lo necesiten. Puede que tengan que ejecutarlo como admin, si tienen las carpetas de sistema protegidas. Aca les dejo el link: https://www.dropbox.com/sh/7hzr2i0ey7058au/AAAwOH_eENHK4FPRtjxutI4xa?dl=0&s=so Saludos gente! PD: Cualquier cosa me preguntan en los comentarios.