adrianus

Muchas veces me han preguntado de qué tipo eran los ficheros ".loquesea" y en múltiples ocasiones no he sabido responder. La extensión de un archivo puede indicarnos su tipo, pero puede no ser así. Si a cualquier programador se le ocurre que sus datos van a almacenarse del tipo .jlf ¿de qué me suena? :-) nadie puede decir lo contrario, su programa tendrá en cuenta que esa es su forma de denominarlos. Esto ocurre con un porcentaje muy alto de las aplicaciones que hay en el mercado. Habida cuenta que nunca se utiliza solamente un tipo de archivo, sino varios, el número de extensiones puede ser enorme y crecer, o cambiar de una versión a otra, por lo tanto es muy frecuente que no nos ofrezca ninguna información el conocerla. En cualquier caso sí las hay que por distintos motivos (requisitos del Sistema Operativo, principalmente) se consideran estándar. Intento hacer una relación, que distará mucho de ser exhaustiva, de las más frecuentes. .$00: Fichero del Ms-DOS. .$DB: Fichero temporal utilizado por el programa dBase. .$VM: Fichero de gestión de la memoria virtual utilizado por el entorno Microsoft Windows 3.x. .000: Fichero de datos comprimidos con el programa Doublespace. .075: Fuente de letra de 75 dpi utilizable en el programa Ventura Publisher. .085: Fuente de letra de 85 dpi utilizable en el programa Ventura Publisher. .091: Fuente de letra de 91 dpi utilizable en el programa Ventura Publisher. .096: Fuente de letra de 96 dpi utilizable en el programa Ventura Publisher. .0B: Fuente de letra para el programa PakeMaker. .123: Hoja de cálculo del programa Lotus 1-2-3. .1ST: Esta extensión de archivo normalmente siempre va junto a un fichero llamado«Readme». Si leemos el nombre de fichero completo en inglés obtenemos la frase«readme first», que se traduciría por «Leame primero». .2GR: Fichero utilizado por las primeras versiones del sistema operativo Microsoft Windows .386: Fichero de intercambio utilizado por el sistema operativo Microsoft Windows 3.x .3DS: Gráfico creado con el programa Autodesk 3D Studio. .3FX: Efecto especial creado con el programa CorelChart. .3GR: Fichero utilizado por el sistema operativo Microsoft Windows en modo 32 bits para visualizar texto y gráficos .4SW: Fichero de intercambio utilizado por el gestor 4DOS. .4TH: Código fuente escrito en lenguaje de programación Forth. .669: Fichero de música creado con el programa 669. .6cm: Fichero musical creado con el programa Triton FastTracker. .8: Código fuente de un programa escrito en ensamblador del chip Intel 8086. .8M: Fuente de letra para el programa Pagemaker. .8U: Fuente de letra para el programa Pagemaker. .906: Plotter Calcomp.A: Código fuente escrito en lenguaje de programación Ada. También puede corresponder a una biblioteca del sistema operativo Unix. .A00 a .A99: Paquetes que complementan a un fichero comprimido en formato ARJ. .A11: Gráfico almacenado en formato AIIM. .A3L: Biblioteca para el programa Authorware 3.0. .A3M: Fichero de una creación diseñada con el programa Authorware de Macintosh. .A3W: Fichero de una creación diseñada con el programa Authorware de Windows. .A4L: Biblioteca para el programa Authorware 4.0. .A4M: Fichero de una creación diseñada con el programa Authorware de Macintosh. .A4W: Fichero de una creación diseñada con el programa Authorware de Macintosh. .A86: Fichero de código ensamblador de un programa escrito para el chip Intel 8086. .AAM: Fichero del programa Authorware. .AAS: Fichero del programa Authorware. .ABK: Copia de seguridad que se realizan automáticamente de los diseños creados con la aplicación Corel Draw. .ABR: Extensión de fichero de un diseño de brocha creado con el programa Adobe Photoshop. .ABS: Fichero de sonido codificado en formato MPEG. .AC$: Información de la opción «deshacer» del programa Autodesk AutoCAD. .ACC: Programa ejecutable con el ViewMax del sistema operativo Dr-DOS. .ACL: Definición de una Aceleración de teclas. Las usa el programa Corel Draw 6. También puede corresponder a la Lista de autocorrección del software Microsoft Office. .ACM: Extensión de un fichero de directorio de Microsoft Windows. .ACP: Fichero de previsualización del Asistente de Microsoft Office. .ACT: Código fuente escrito en lenguaje de programación Actor. .ACV: Controlador de compresión y descompresión de audio utilizado por el sistema operativo IBM OS/2. .AD: Perteneciente a la aplicación After Dark (salvapantallas). .AD2: Fichero de sonido comprimido a 2 bits de calidad. .AD3: Fichero de sonido comprimido a 3 bits de calidad. .ADA: Código fuente de un programa escrito en lenguaje de programación Ada. .ADB: Puede ser el apunte de una base de datos del HP 100LX (un HPC) o un cuerpo de fichero en el lenguaje de programación Ada. .ADC: Gráfico con una paleta de 16 colores creado con ScanStudio. .ADD: Perteneciente a un controlador de un adaptador del sistema operativo IBM OS/2. .ADF: Fichero de descripción de un adaptador. .ADI: Gráfico diseñado con el programa Autodesk AutoCAD. .ADM: Fichero de After Dark multimodo. .ADN: Add-on para el programa Lotus 1-2-3. .ADP: Documento creado con el programa Aldus Pagemaker. .ADR: Fichero de After Dark de tipo aleatorio. .ADS: Fichero de especificación utilizado en el lenguaje de programación Ada. .AEX: Llave pública para el programa PGP. .AF2: Fichero generado con el programa ABC. .AF3: Fichero generado con el programa ABC. .AFC: Fichero de sonido en un formato propietario de Apple Computers. .AFI: Gráfico en formato Truevision. .AFL: Fuente de letra para el programa Lotus 1-2-3. .AFM: Fichero del Type 1 de Adobe Font Metrics. .AG4: Fichero que pertenece al programa Access G4. .AI: Gráfico vectorial creado con el programa Adobe Ilustrator. .....etc Como no cabe todo dentro del post aca les dejo un txt donde se listan una banda de extensiones y sus descripciones. fuente

Apaga tu ordenador con un doble clic Si quieres hacer un acceso directo para apagar el ordenador con un doble clic, haz clic en el botón derecho del ratón en cualquier parte del escritorio y selecciona nuevo acceso directo, en su línea de comandos escribe: shutdown.exe -s -t 5 Luego escribes un nombre para el acceso directo y listo. Nota :en win98 no anda.. en XP si, traten de probarlo en 2000, NT o 2003 y comenten como les fue fuente

Explosión y heridos en universidad de Río Cuarto Río Cuarto, Córdoba - El incendio ocurrió en la planta piloto de la Facultad de Ingeniería. Varios alumnos y docentes resultaron con quemaduras graves. Habría al menos veinte heridos. Fue por un experimento en un laboratorio. Se habrían usado "solventes". Las llamas fueron sofocadas por Bomberos. Evacuaron a los alumnos. Se estima que el origen de la explosión fueron unos tanques con solventes, que utilizaban alumnos para realizar una investigación. Evacuaron a los alumnos y a los niños del jardín de infantes que se encuentra en proximidades, según informó a Radio Río Cuarto el secretario de Coordinación Técnica y Servicios, ingeniero José Luis Pincini, informó Radio Río Cuarto (LV16). Algunos alumnos y docentes resultaron con quemaduras. Fueron trasladados hacia al Hospital San Antonio de Padua. Bomberos Voluntarios sofocaron las llamas. El ingeniero Pincini dijo que "aparentemente hubo solventes que motivaron las explosiones". Agregó que "es variada la cantidad de gente que estaba en el lugar, no se bien cuántas personas había en la planta", destacó. Jorge Vicario, profesor de la Facultad de Ingeniería, dijo a LV16 que al sentir las explosiones, los alumnos a los cuales estaba tomando examen, saltaron por la ventanas de aula del primer piso del pabellón 1 de la UNRC. Fuente

¿QUE ESTÁ MATANDO MI CPU? Algunas veces, a pesar de ver el sistema ocioso e incluso ver en el Administrador de tareas que la CPU está desocupada en más de un 95%, tenemos la sensación que algo está "fallando", que el sistema no responde como debiera. Estas "sensaciones" muchas veces son realidad. Un driver erróneo, un error hardware que está "friendo" a interrupciones la CPU (por ejemplo), quitan prestaciones a la máquina, e incluso pueden llegar a bloquearla o semibloquearla. Actualmente, tenemos una herramienta de Microsoft, que a pesar de ser una herramienta para desarrolladores, también un usuario final puede mirar e investigar lo que le puede pasar a la máquina. La herramienta está aca Una vez instalada, la parte más interesante debe ejecutarse en una consola de comando (cmd.exe). En ella, vamos a la carpeta de instalación: cd "c:\Archivos de Programa\KrView\Kernrates" dir y vemos tres archivos correspondientes a diferentes sistemas operativos: Kernrate_i386_Win2000.exe Kernrate_i386_XP.exe Kernrate_ia64_XP.exe En el caso de XP, debemos ejecutar el: Kernrate_i386_XP.exe Lo dejamos en ejecución un minuto para que recoja estadísticas y pulsaremos CTRL-C para pararlo. Esperamos un minuto y lo paramos con CTRL-C. dijo: /==============================\ < KERNRATE LOG > \==============================/ Date: 2005/02/04 Time: 18:19:49 Machine Name: JETSABE Number of Processors: 4 PROCESSOR_ARCHITECTURE: x86 PROCESSOR_LEVEL: 15 PROCESSOR_REVISION: 0205 Physical Memory: 3327 MB Pagefile Total: 7264 MB Virtual Total: 2047 MB PageFile1: \??\J:\pagefile.sys, 4095MB OS Version: 5.1 Build 2600 Service-Pack: 2.0 WinDir: K:\WINDOWS Kernrate User-Specified Command Line: Kernrate_i386_XP.exe Kernel Profile (PID = 0): Source= Time, Using Kernrate Default Rate of 25000 events/hit Starting to collect profile data ***> Press ctrl-c to finish collecting profile data ===> Finished Collecting Data, Starting to Process Results ------------Overall Summary:-------------- P0 K 0:00:00.500 ( 9.6%) U 0:00:00.000 ( 0.0%) I 0:00:04.703 (90.4%) DPC 0:00:00.468 ( 9.0%) Interrupt 0:00:00.015 ( 0.3%) Interrupts= 10188, Interrupt Rate= 1958/sec. P1 K 0:00:00.046 ( 0.9%) U 0:00:00.000 ( 0.0%) I 0:00:05.156 (99.1%) DPC 0:00:00.000 ( 0.0%) Interrupt 0:00:00.000 ( 0.0%) Interrupts= 2434, Interrupt Rate= 468/sec. P2 K 0:00:00.031 ( 0.6%) U 0:00:00.015 ( 0.3%) I 0:00:05.156 (99.1%) DPC 0:00:00.000 ( 0.0%) Interrupt 0:00:00.015 ( 0.3%) Interrupts= 2530, Interrupt Rate= 486/sec. P3 K 0:00:00.296 ( 5.7%) U 0:00:00.046 ( 0.9%) I 0:00:04.859 (93.4%) DPC 0:00:00.031 ( 0.6%) Interrupt 0:00:00.000 ( 0.0%) Interrupts= 2515, Interrupt Rate= 483/sec. TOTAL K 0:00:00.875 ( 4.2%) U 0:00:00.062 ( 0.3%) I 0:00:19.875 (95.5%) DPC 0:00:00.500 ( 2.4%) Interrupt 0:00:00.031 ( 0.2%) Total Interrupts= 17667, Total Interrupt Rate= 3395/sec. Total Profile Time = 5203 msec BytesStart BytesStop BytesDiff. Available Physical Memory , 2675724288, 2674913280, -811008 Available Pagefile(s) , 7047180288, 7046549504, -630784 Available Virtual , 213262336 2131574784, -1048576 Available Extended Virtual , 0, 0, 0 Total Avg. Rate Context Switches , 16507, 3173/sec. System Calls , 180324, 34657/sec. Page Faults , 1267, 244/sec. I/O Read Operations , 215, 41/sec. I/O Write Operations , 76, 15/sec. I/O Other Operations , 1408, 271/sec. I/O Read Bytes , 65260, 304/ I/O I/O Write Bytes , 119602, 1574/ I/O I/O Other Bytes , 384972, 273/ I/O ----------------------------- Results for Kernel Mode: ----------------------------- OutputResults: KernelModuleCount = 228 Percentage in the following table is based on the Total Hits for the Kernel Time 8273 hits, 25000 events per hit -------- Module Hits msec %Total Events/Sec intelppm 7817 5203 94 % 37560061 ntoskrnl 176 5203 2 % 845665 hal 168 5203 2 % 807226 win32k 53 5203 0 % 254660 USBPORT 43 5203 0 % 206611 usbohci 4 5203 0 % 19219 usbehci 3 5203 0 % 14414 dc21x4 2 5203 0 % 9609 NDIS 2 5203 0 % 9609 irstusb 1 5203 0 % 4804 tcpip6 1 5203 0 % 4804 STREAM 1 5203 0 % 4804 BT848 1 5203 0 % 4804 Ntfs 1 5203 0 % 4804 ================================= END OF RUN ================================== ============================== NORMAL END OF RUN ============================== Esta es la salida típica en mi máquina, con 4 CPU's. No se ve nada anormal, ya que el máximo consumo corresponde al driver intelppm que es realmente el núcleo de multiprocesador. Vemos a ver un caso posiblementa anómalo en otra máquina: dijo: /==============================\ < KERNRATE LOG > \==============================/ Date: 2004/12/21 Time: 15:33:21 Machine Name: AOSTOS Number of Processors: 1 PROCESSOR_ARCHITECTURE: x86 PROCESSOR_LEVEL: 6 PROCESSOR_REVISION: 0800 Physical Memory: 480 MB Pagefile Total: 1125 MB Virtual Total: 2047 MB PageFile1: \??\E:\pagefile.sys, 720MB OS Version: 5.1 Build 2600 Service-Pack: 2.0 WinDir: E:\WINDOWS Kernrate User-Specified Command Line: Kernrate_i386_XP.exe Kernel Profile (PID = 0): Source= Time, Using Kernrate Default Rate of 25000 events/hit Starting to collect profile data ***> Press ctrl-c to finish collecting profile data ===> Finished Collecting Data, Starting to Process Results ------------Overall Summary:-------------- P0 K 0:00:13.656 (38.2%) U 0:00:02.484 ( 7.0%) I 0:00:19.578 (54.8%) DPC 0:00:00.312 ( 0.9%) Interrupt 0:00:00.296 ( 0.8%) Interrupts= 107928, Interrupt Rate= 3022/sec. Total Profile Time = 35718 msec BytesStart BytesStop BytesDiff. Available Physical Memory , 107065344, 112259072, 5193728 Available Pagefile(s) , 374460416, 371945472, -2514944 Available Virtual , 2132889600, 2131841024, -1048576 Available Extended Virtual , 0, 0, 0 Total Avg. Rate Context Switches , 395167, 11063/sec. System Calls , 1106131, 30968/sec. Page Faults , 20595, 577/sec. I/O Read Operations , 2346, 66/sec. I/O Write Operations , 1102, 31/sec. I/O Other Operations , 32185, 901/sec. I/O Read Bytes , 346338, 148/ I/O I/O Write Bytes , 83614, 76/ I/O I/O Other Bytes , 5832690, 181/ I/O ----------------------------- Results for Kernel Mode: ----------------------------- OutputResults: KernelModuleCount = 135 Percentage in the following table is based on the Total Hits for the Kernel Time 13080 hits, 25000 events per hit -------- Module Hits msec %Total Events/Sec amdk7 7381 35718 56 % 5166162 nv4_disp 3834 35718 29 % 2683520 ntoskrnl 819 35718 6 % 573240 win32k 341 35718 2 % 238675 hal 288 35718 2 % 201579 Ntfs 180 35718 1 % 125986 NVENET 64 35718 0 % 44795 USBPORT 38 35718 0 % 26597 atapi 20 35718 0 % 13998 ino_fltr 19 35718 0 % 13298 nv4_mini 17 35718 0 % 11898 usbohci 11 35718 0 % 7699 watchdog 9 35718 0 % 6299 tcpip 7 35718 0 % 4899 HIDPARSE 7 35718 0 % 4899 Npfs 5 35718 0 % 3499 HIDCLASS 4 35718 0 % 2799 NDIS 4 35718 0 % 2799 sr 4 35718 0 % 2799 ftdisk 4 35718 0 % 2799 usbhub 3 35718 0 % 2099 PCIIDEX 3 35718 0 % 2099 ACPI 3 35718 0 % 2099 mouhid 2 35718 0 % 1399 hidusb 2 35718 0 % 1399 mouclass 2 35718 0 % 1399 TDI 2 35718 0 % 1399 PartMgr 2 35718 0 % 1399 rdbss 1 35718 0 % 699 psched 1 35718 0 % 699 VIDEOPRT 1 35718 0 % 699 imapi 1 35718 0 % 699 CLASSPNP 1 35718 0 % 699 ================================= END OF RUN ================================== ============================== NORMAL END OF RUN ============================== ¿Qué observamos?....... primero un elevado (excesivo) número de interrupciones por segundo: 3022 (frente al ejemplo de mi máquina, 3395 - lo cual es normal por tener 19 discos, 1 controladora IDE, 2 SATA, y una SCSI, y tener mas de 30 dispositivos USB conectados). Como segundo punto, vemos que el driver nv4_disp (correspondiente al driver de una tarjeta nVidia) se está llevando un 29%. Esto puede empezar a darnos una pista. Ese driver posiblemente es incorrecto, o no está diseñado para ese modelo de tarjeta gr´sfica.... o la propia tarjeta gráfica está dañada. ------------------------------------ En la misma máquina, ejecutamos ahora de nuevo el programa con el parámetro que indico más abajo ,y antes de pararlo, en otra consola de comandos, ejecutamos un: dir c:\ /S y cuando termine, paramos con CTRL-C. De esta manera veremos los consumos durante la ejecución de dicho comando. Vamos a investigar ahora el núcleo de Windows, ejecutando el mismo programa con un parámetro: Kernrate_i386_XP.exe -z ntoskrnl (y antes de parar, el dir c:\ /s comentado anteriormente). La salida en este caso es: dijo: /==============================\ < KERNRATE LOG > \==============================/ Date: 2004/12/21 Time: 15:37:38 Machine Name: AOSTOS Number of Processors: 1 PROCESSOR_ARCHITECTURE: x86 PROCESSOR_LEVEL: 6 PROCESSOR_REVISION: 0800 Physical Memory: 480 MB Pagefile Total: 1125 MB Virtual Total: 2047 MB PageFile1: \??\E:\pagefile.sys, 720MB OS Version: 5.1 Build 2600 Service-Pack: 2.0 WinDir: E:\WINDOWS Kernrate User-Specified Command Line: Kernrate_i386_XP.exe -z ntoskrnl Kernel Profile (PID = 0): Source= Time, Using Kernrate Default Rate of 25000 events/hit CallBack: Finished Attempt to Load symbols for 804d7000 \WINDOWS\system32\ntoskrnl.exe Starting to collect profile data ***> Press ctrl-c to finish collecting profile data ===> Finished Collecting Data, Starting to Process Results ------------Overall Summary:-------------- P0 K 0:00:01.406 (24.3%) U 0:00:00.859 (14.8%) I 0:00:03.531 (60.9%) DPC 0:00:00.031 ( 0.5%) Interrupt 0:00:00.062 ( 1.1%) Interrupts= 23804, Interrupt Rate= 4106/sec. Total Profile Time = 5796 msec BytesStart BytesStop BytesDiff. Available Physical Memory , 117850112, 114122752, -3727360 Available Pagefile(s) , 370819072, 368578560, -2240512 Available Virtual , 2132889600, 2130681856, -2207744 Available Extended Virtual , 0, 0, 0 Total Avg. Rate Context Switches , 206440, 35612/sec. System Calls , 372915, 64330/sec. Page Faults , 14872, 2566/sec. I/O Read Operations , 186, 32/sec. I/O Write Operations , 180, 31/sec. I/O Other Operations , 19183, 3309/sec. I/O Read Bytes , 39296, 211/ I/O I/O Write Bytes , 11940, 66/ I/O I/O Other Bytes , 3000748, 156/ I/O ----------------------------- Results for Kernel Mode: ----------------------------- OutputResults: KernelModuleCount = 135 Percentage in the following table is based on the Total Hits for the Kernel Time 1893 hits, 25000 events per hit -------- Module Hits msec %Total Events/Sec amdk7 1309 5796 69 % 5646135 ntoskrnl 292 5796 15 % 1259489 hal 91 5796 4 % 392512 Ntfs 79 5796 4 % 340752 win32k 56 5796 2 % 241545 NVENET 28 5796 1 % 120772 ino_fltr 8 5796 0 % 34506 atapi 6 5796 0 % 25879 CLASSPNP 4 5796 0 % 17253 Npfs 3 5796 0 % 12939 PCIIDEX 3 5796 0 % 12939 watchdog 2 5796 0 % 8626 nv4_mini 2 5796 0 % 8626 sr 2 5796 0 % 8626 PartMgr 2 5796 0 % 8626 ftdisk 2 5796 0 % 8626 nv4_disp 1 5796 0 % 4313 tcpip 1 5796 0 % 4313 USBPORT 1 5796 0 % 4313 NDIS 1 5796 0 % 4313 ===> Processing Zoomed Module ntoskrnl.exe... ----- Zoomed module ntoskrnl.exe (Bucket size = 16 bytes, Rounding Down) -------- Percentage in the following table is based on the Total Hits for this Zoom Module Time 292 hits, 25000 events per hit -------- Module Hits msec %Total Events/Sec CcUnpinDataForThread 32 5796 10 % 138026 KiDispatchInterrupt 27 5796 8 % 116459 ZwYieldExecution 18 5796 5 % 77639 FsRtlIsNameInExpression 14 5796 4 % 60386 KiIpiServiceRoutine 13 5796 4 % 56073 SeUnlockSubjectContext 9 5796 2 % 38819 NtAllocateVirtualMemory 8 5796 2 % 34506 ObReferenceObjectByHandle 8 5796 2 % 34506 ExAllocatePoolWithTag 8 5796 2 % 34506 NtRequestWaitReplyPort 7 5796 2 % 30193 ExInterlockedPopEntrySList 7 5796 2 % 30193 SeDeleteAccessState 6 5796 1 % 25879 ExAcquireResourceExclusiveLite 6 5796 1 % 25879 ExReleaseResourceLite 6 5796 1 % 25879 NtOpenProcessTokenEx 5 5796 1 % 21566 ObCreateObject 5 5796 1 % 21566 ObfDereferenceObject 5 5796 1 % 21566 wcstombs 4 5796 1 % 17253 MmMapLockedPagesSpecifyCache 4 5796 1 % 17253 IoBuildPartialMdl 4 5796 1 % 17253 RtlCopyUnicodeString 4 5796 1 % 17253 ============================================================================== Son importantes las 4 primeras lineas: dijo: CcUnpinDataForThread 32 5796 10 % 138026 KiDispatchInterrupt 27 5796 8 % 116459 ZwYieldExecution 18 5796 5 % 77639 FsRtlIsNameInExpression 14 5796 4 % 60386 ================================= END OF RUN ================================== ============================== NORMAL END OF RUN ============================== Esta vez no fue el driver de nVidia, y ha sido ntoskrnl. Podemos ver aqui que KiDispatchInterrupt (el cual probablemne corresponde a interrupciones del disco disco duro: atapi!IdePortInterrup). Vemos tambien a CcUnpinDataForThread, el cual parece ser el administrador de acceso a datos del caché de disco. Y vemos tambien a FsRtlIsNameInExpression, el cual corresponde a la rutina de búsqueda y coincidencia de nombres. Sorprende en este caso que se esté usando un 15% * 4% = 0,6% de tiempo de búsqueda cuando no hemos dado ningún patron de nombre en la orden dir. Bien, hay análisis aquí que tienen más sentido para un programador de sistemas, pero espero que pueda ser de ayuda en la búsqueda de situaciones anómalas en la máquina. fuente PD: tente alguna maquinita andando chabon... jujuju

Cómo usar dos ISPs y sumar el ancho de banda en conexiones ADSL/DSL/Cable Algunas veces se han planteado las siguientes preguntas: 1) Tengo dos conexiones ADSL, o una ADSL y otra de cable. ¿Cómo puedo "sumar" el ancho de banda y así aprovechar simultáneamente ambas? 2) Tengo dos conexiones ADSL y quiero usar una para navegar y otra para compartir datos con amigos, para lo cual uso algún programa seguro P2P. 3) Tengo dos conexiones ADSL y quiero usar una para Internet y la otra para conectarme a mi empresa en teletrabajo y sólo para ello. Bien, estos casos, aunque similares, son totalmente diferentes. Empecemos con una introducción al funcionamiento del TCP/IP. INTRODUCCIÓN: Funcionamiento del TCP/IP En una máquina, el TCP/IP tiene siempre el mismo comportamiento: en función de la tabla de rutas (visible mediante el comando 'route print'), la capa de red de TCP/IP selecciona por dónde y a quién enviar el paquete de datos. Si existe una ruta específica para una determinada dirección de red, o bien para un rango de direcciones, se enviará al gateway /puerta de enlace que está definida en la tabla de rutas. Si no, se enviará al gateway por defecto, el cual es aquel que en la tabla de rutas está definido como 0.0.0.0. Si existiesen varios con dirección 0.0.0.0 se seleccionará aquel que tenga menor "métrica", y a igualdad de métrica se seleccionará el primero de ellos (leyendo la tabla de rutas de abajo a arriba). Las capas del TCP/IP ante una tabla estática, una vez que han decidido no cambian su decisión. Y puerta de salida (gateway) activa sólo puede haber una: cuando salimos de una casa lo hacemos por una puerta, no por dos a la vez. Ante esto, podemos ver que los tres problemas planteados tienen "en principio" las siguientes respuestas: 1) No es posible, o un ISP o bien el otro. 2) No es posible ya que las IP de los destinatarios P2P pueden ser cualquiera. Es similar al caso 1 3) Es posible, siempre y cuando establezcamos la tabla de rutas correctamente, añadiendo una entrada a la dirección o direcciones de la empresa y apuntando al gateway que deseamos. Igualmente, para el resto de direcciones modificaremos si es necesario la tabla de rutas para que apunte al otro gateway. Esto es sencillo de realizar con el comando 'route add' y 'route delete' y con el parámetro 'persistent' si deseamos hacerlas persistentes y no tener que redefinirlas en cada reinicio de la máquina (la 'persistencia' sólo es posible en sistemas NT, XP, W200x y no es posible en sistemas W9X / ME). Pueden verse otros artículos míos de detalle sobre el funcionamiento del TCP/IP y cómo configurar en estos casos. El punto 1) puede solucionarse mediante el mecanismo de balanceo de carga, el cual sigue cumpliendo la normativa RFC del TCP/IP y, básicamente, y aunque no es real el funcionamiento ya que se utilizan otros mecanismos, podríamos "intuir" que si tenemos un software que va contando los paquetes enviados y va decidiendo en función del número de ellos por qué puerta de enlace enviar -mediante criterios más o menos 'inteligentes'-, simplemente cambiando la tabla de rutas irá el sistema enviando a uno u otro. Aunque realmente se usan otros procedimientos, esta lógica 'intuitiva' puede servirnos. Hay dos posibles soluciones para el Balanceo de Carga, una software (y me voy a ceñir únicamente a soluciones en el Sistema operativo XP) y otra hardware. Realmente la descomposición completa, para abordar toda la casuística, sería: * Balanceo de carga (Load Balancing) por software. * Balanceo de carga por hardware. * 'Circuit Bonding' -es solo solución hardware-. La diferencia entre balanceo de carga y 'circuit bonding' es que, en la primera, si tenemos dos líneas ADSL de 1024 Mbps cada usuario o cada conexión tendrá un máximo de 1024, lo que sucede es que lanzando las dos conexiones a la vez, tendremos un ancho de banda total de 2048, pero por cada conexión, limitado a 1024. En cambio en 'circuit bonding' -sólo hardware y que veremos al final- es una suma real y cada conexión puede alcanzar los 2048. El ejemplo clásico es si nos estamos bajando un archivo grande, un ISO por ejemplo, en Load Balancing, (sin usar gestores de descargas que realizan conexiones múltiples), sólo estaremos bajando a 1024 -y nos quedan los otros 1024 libres para cualquier otra cosa. En cambio en 'circuit bonding' tendremos realmente los 2048 de bajada disponibles para dicha conexión. BALANCEO DE CARGA POR SOFTWARE (XP) Necesitaremos al menos dos NIC's (tarjetas de red) si tenemos un PC únicamente, o bien 3 NIC's si tenemos una red: dos de las NIC's una a cada router ADSL, y la tercera NIC a la red local. Únicamente hay en la actualidad dos programas capaces de hacerlo: Intergate www.vicomsoft.com y surfdoubler de midpoint software www.midpoint.com. Esta última Web está cerrada en la actualidad -no sé si transitoriamente-, pero su software, al menos de demo, puede todavía encontrarse en muchos sitios de Internet. La solución de midpoint, aunque es un software un poco antiguo y para W95 / NT con una interface un poco 'cutre', es una solución sencilla de configurar, rápida de instalar, estable y de un funcionamiento correcto. Sus mecanismos de balanceo y toma de decisión de la interface es correcta y rapidísima. En este sentido me parece mejor que la solución de Intergate. En Intergate, existe actualmente la versión 9.02 en su Web, la cual puede bajarse para probarla. Esta versión, he sido incapaz de que funcionase, ni en XP-SP2 ni en W2000, ni en W2003. Entiendo que sólo es problema de la versión demo y no de la definitiva. El problema es que elimina el TCP/IP de Microsoft en las interfaces a Internet y lo sustituye por un servicio suyo que da la salida IP. Este servicio no arranca en ningún caso en sistemas limpios y recién instalados. Leyendo documentación en Google, encontré buenas criticas de la versión anterior (8.60) y, ante la imposibilidad de obtenerla de Intergate, decidí bajarla de la red con el consiguiente peligro que esto conlleva (25 spyware y 7 virus). Aislada en una máquina virtual, a pesar de la infección, conseguí extraer los ejecutables reales limpios para prueba en otra instalación. Una vez instalado, -los manuales de la 9.02 sirven perfectamente para la versión anterior 8.60- su funcionamiento es totalmente correcto. Únicamente la matización, a nivel particular, de que no me gusta la desactivación del TCP de Microsoft y el uso de su stack IP independiente para este caso. En las medidas realizadas, parece mas "ágil" la solución de Midpoint que por desgracia ya está sin soporte. BALANCEO DE CARGA POR HARDWARE El tema es más simple: un router con dos entradas WAN y 'n' salidas LAN. Cada router ADSL a una entrada WAN y el sistema hardware se encarga del balanceo en función de las peticiones de la LAN. Los routers que he localizado en la actualidad y que cumplen estas características son: Netgear FVS124G Xincom XC-DPG402 Xincom XC-DPG502 Xincom XC-DPG602 OvisLink MN200 HotBrick Firewall VPN 600/2 HotBrick Firewall VPN 1200/2 ZyXEL ZyWALL 35 ZyXEL ZyWALL 70 Linksys RV082 Linksys RV016 Linksys RV042 Edimax BR-6104K Xterasys XR-4106 Pheenet BIG-02/4 Symantec VPN 200 Nexland Pro800 BroDigit NFR3024 Hawking FR24 Esta lista no es exhaustiva y, aunque está actualizada en el momento de escribir este artículo, no estará de más una búsqueda en Internet de este tipo de routers si nos decantamos por una solución hardware. CIRCUIT BONDIGN Es una solución únicamente hardware (llamada también Bonding/muxing), en la cual los clientes tienen realmente la capacidad total, suma de ambas. Al contrario del Balanceo de Carga, en el cual dos líneas de 1024 equivalen a 2 x 1024 y limitada cada conexión a un máximo de 1024, esta solución da realmente los 2048 -suma de ambos- en este ejemplo. Se necesitan varias condiciones en este caso: 1) Se requieren dos routers y otros dos dispositivos llamados MUXS. 2) Un router y un mux deben estar colocados en el ISP, y el otro router y mux en nuestro punto final de conexión. 3) El ISP, por tanto,debe ser único y no dos ISPs diferentes. 4) El ISP debe soportar, por supuesto, esta configuración. En la actualidad solo está soportado en líneas T1. Fuente

Bueno esto es algo que decubri (obvio que si digo decubri es porque yo no lo sabia lo que no implica que ustedes no lo sabian, aclaro para aquellos que siempre bardean) intentando postear videos con extension flv. Casi siempre que queria postear un video me hiba directo al codigo fuente de la pagina donde estaba dicho video he intentaba ver la direccion donde estaba hosteado para luego poder ponerlo en algun post. Pero me he encontrado que muchas paginas lo hacen con un script, casi siempre con un JavaScript, y me re cagaban ya que solo le pasaban como parametro la direccion del archivo .flv que a diferencia de los archivos .swf necesita un reproductor para poder ser visto.Es mas, muchas veces le pasaban como parametro solo el nombre del archivo .flv pero bueno no va al caso. La cosa es asi... encontre un reproductor de este tipo de archivos que pasandole como parametro la direccion del video (siempre en formato .flv) te lo reproducia sin ningun problema sin filtrar por si el parametro estaba en la misma pagina que él. El reproductor es el siguiente : Cita:http://files2.youporn.com/player/player3.swf y si quero pasar como parametro la siguiente direccion : Cita:http://cache.lanacion.com.ar/lnol5/multimedios/videos/2007/04/trans.flv lo hago de esta manera: Cita:http://files2.youporn.com/player/player3.swf?file=http://cache.lanacion.com.ar/lnol5/multimedios/videos/2007/04/trans.flv luego solo resta agregarle el tag de flash: Cita:[*swf=http://files2.youporn.com/player/player3.swf?file=http://cache.lanacion.com.ar/lnol5/multimedios/videos/2007/04/trans.flv] obvio qe sin el asterisco y se vera asi: Asi que ahora solo resta saber la direccion del video .flv ya que tenemos el reproductor para poder verlo. Bueno espero que les sea util taringeros, en especial a los novatos como yo.. jejeje Aguante la legion de novatos!!!! PD: espero que entiendan lo que puse cualquier cosa chiflen, pero fuerte que soy medio sordo

Windows Vista trae una nueva tecnología que se llama ReadyBoost y lo que hace es que si conectas un dispositivo USB de almacenamiento lo utiliza como si se tratara de memoria RAM virtual y acelera el rendimiento de la carga de aplicaciones y del sistema en general , también se puede hacer con tarjetas externas de memoria SD , Compact Flash ,etc ...En el video se puede ver claramente la mejora de rendimiento del inicio de Windows , pasa de tardar 43 segundos sin utilizar el ReadyBoost a 14 segundos cuando lo utiliza .link: http://video.google.com/videoplay?docid=5902090796342771727Muchas veces el problema es que es el propio Vista quien decide si se puede utilizar ReadyBoost o no, dependiendo de la velocidad del pendrive. Sin embargo, podemos forzarlo para que lo utilice siempre, siguiendo estos pasos:1. Enchufamos el pendrive en cuestión. Nos vamos al menú inicio y pulsamos en Equipo. Allí hacemos clic con el botón derecho del ratón y pulsamos en Propiedades.2. En la pestaña ReadyBoost y marcamos la opción de “No comprobar este dispositivo cuando lo conecto“.3. Luego vamos al menú inicio, escribimos regedit, y pulsamos ENTER. Con el árbol de carpetas de la izquierda vamos navegando hasta llegar a HKLM (Local Machine) -> SOFTWARE -> Microsoft -> Windows NT -> CurrentVersion -> EMDgmt, donde verás una lista de dispositivos USB, uno de los cuales será el pendrive objetivo de este truco.4. Hacemos doble clic en DeviceStatus, cambiamos su valor a 2, y aceptamos. Hacemos lo mismo para ReadSpeedKBs y WriteSpeedKBs, pero los cambiamos a 1000, y cerramos el editor del registro.5. ¡Y listo! Ahora cuando vuelvas a enchufar ese pendrive, Vista te dará la opción de utilizarlo como dispositivo ReadyBoost.fuente1fuente2Ta buena la cosa, lastima que el forro del vista es muy rompe huevos SaludosPD: acuerdense que algunos pendrive tienen un ciclo de vida segun la cantidad de lecturas y escrituras que les hagas

Desarrollador Independiente Este artículo trata de abordar la problemática del ejercicio de la profesión independiente Introducción Este artículo está destinado a desarrolladores independientes del llamado tercer mundo. Si usted vive en el "más civilizado" primer mundo, posiblemente no encontrará este artículo de utilidad, así que le recomiendo no leerlo porque es acerca de una realidad diferente a la suya. En ediciones pasadas hemos estado hablando de los desarrolladores de shareware, los desarrolladores de freeware, etc., pero ¿qué hay de los desarrolladores independientes? La verdad es que una gran cantidad de nuestros suscriptores pertenecen a este grupo, y algunos de ellos solicitaron insistentemente un artículo dedicado a tratar los problemas que un desarrollador independiente tiene que enfrentar... Bien, intentaré hacer lo mejor que pueda aquí... Espero su retroalimentación para publicarla en la próxima edición junto con la continuación de este artículo. ¿Por qué trabajar como independiente? Pregúntele a desarrolladores independientes y seguramente obtendrá estas respuestas: 1. "No tengo jefe" 2. "No me gusta estar atado" 3. "No me gusta el horario de oficina" 4. "Me gustaría elegir la gente con la que trabajo" 5. "No me gusta el salario de un empleo fijo" 6. "No puedo encontrar un trabajo fijo" ¿Todas son ventajas? Seríamos todos desarrolladores independientes entonces, pero no, no todas son ventajas: 1. "No tengo jefe" Sus clientes se convierten en sus jefes, aunque el trato y la relación ciertamente es muy diferente, si entiende lo que quiero decir, pero aún así tendrá un jefe. 2. "No me gusta estar atado" Tenemos que convenir que ser independiente da a una sensación de libertad que no se logra cuando uno tiene un trabajo fijo, pero aún sigue "atado" a su trabajo y a sus clientes, y a veces pueden atarle demasiado si se los permite. 3. "No me gusta el horario de oficina" Los desarrolladores independientes generalmente terminan trabajando más horas diarias que los que tienen un empleo fijo. Si usted desea levantarse al mediodía y trabajar hasta 4:00 mañana, es cosa suya. 4. "Me gustaría elegir la gente con la que trabajo" El ambiente de trabajo en muchas empresas no es precisamente el mejor. Si usted ha trabajado en uno de esos lugares, no tengo que decirle qué son capaces de hacer sus compañeros de trabajo para "asegurar" su puesto de trabajo o ser ascendidos... Al ser independiente usted puede elegir la gente con la que trabaja, pero ciertamente no puede elegir la competencia... 5. "No me gusta el salario de un empleo fijo" Un desarrollador independiente puede llegar a ganar más que uno que tiene un trabajo fijo, pero no tiene asegurado un ingreso mínimo, beneficios sociales, vacaciones pagas, etc., y a veces incluso es difícil conseguir que le paguen. 6. "No puedo encontrar un trabajo fijo" ¿Puede ser cierto acaso que en la era IT un programador no pueda encontrar un trabajo??? Seguro, ¿por qué no? Mientras que algunos países "importan" profesionales IT, en otros hay más profesionales que trabajos y esos profesionales no pueden encontrar trabajos en otros países por una razón u otra. Como sea, los desarrolladores independientes no tienen el trabajo garantizado. Por otro lado, se estima que en el 2002 el principal empleador en los EE.UU. no será Microsoft, General Motors o ninguna otra gran corporación. ¿Sabe usted quién será el principal empleador en los EE.UU.? Uno mismo. Y esto no sucederá solamente allá, sino que es una tendencia global. Como un trapecista sin red No es fácil ser desarrollador independiente. Como desarrollador independiente uno no tiene la seguridad que da un trabajo fijo, no solamente en términos de un sueldo fijo, sino también en términos del respaldo que la empresa que le emplea puede darle y el apoyo que sus compañeros de trabajo pueden darle. Mientras que unos pocos desarrolladores independientes tienen éxito, la gran mayoría trabaja mucho para terminar contando los centavos. Está bien, estoy exagerando, pero la verdad es que la mayoría de los desarrolladores independiente sienten que su trabajo está subvalorado y mal pago... y tienen toda la razón en sentir eso. ¿Por qué el trabajo del desarrollador independiente está tan desvalorizado? Muchos colegas dicen que es porque la gente no ve que trabajemos y/o piensan que el trabajo es fácil, que la computadora lo hace todo por nosotros o algo parecido. Si necesitan cambiar el ventilador ("cooler" de la CPU, llaman un técnico, el tío viene, abre la máquina, procede a substituir la pieza defectuosa por una nueva, testea la nueva pieza, vuelve a poner la cubierta y se va en menos de una hora. Y la mejor parte es que él pide $ XX por ese trabajo y logra ser pagado sin quejas. ¿Por qué? Simplemente porque vieron al tío hacer sus cosas y reconocen eso como trabajo. Para los desarrolladores independientes, la situación generalmente es diferente. Nos llaman para hablar con nosotros sobre lo que desean, entonces nosotros nos entrevistamos con toda la gente que será afectada por el proyecto, después vamos a casa, desarrollamos la aplicación, y cuando la tenemos lista vamos a instalarla. ¿Cuánto trabajo era ése? Ninguno. El cliente nos vió solamente hablar todo el tiempo (no reconoce eso como trabajo), después jugamos el solitario en casa y luego regresamos para poner un disquete --otra demostración de cuán duro es nuestro trabajo! :-) Encima de todo, ¿qué sucede si algo no funciona? Para el cliente es otra prueba de nuestra incapacidad, otra razón por la que no debería pagarnos ni un centavo por no hacer nada, y mucho menos por hacerlo mal! :-) Dejando la exageración y las bromas de lado, la realidad es que debido a la ignorancia y otros factores culturales, a menudo nuestro trabajo no se reconoce como especializado, calificado o profesional. Pero hay otros factores económicos, sociales y culturales que crearon un círculo vicioso difícil de romper. Permítame explicarlo. Nuestras casas de altos estudios producen profesionales que no pueden encontrar un trabajo debido a la situación económica, y que tan inexpertos como son intentan ingresar al ya sobrepopulado mercado del desarrollo independiente. Una ley del mercado dice que demasiada oferta y poca demanda hace bajar los precios, y eso es lo que sucede. Los desarrolladores independientes inexpertos están listos trabajar para una remuneración muy baja, la experiencia es el valor verdadero para ellos, y consiguen trabajos independientes porque la situación económica lleva a la pequeña y mediana empresa a preferir barato sobre bueno. El resultado es que muchos profesionales sazonados terminan trabajando por una baja retribución porque no pueden competir de otra manera con sus colegas más jóvenes. ¿Qué clase de trabajo puede realizar una persona desmotivada y mal remunerada? ¿Qué clase de trabajo puede realizar un desarrollador inexperto? Al final, la calidad global del trabajo de los desarrolladores independientes se ha deteriorado significativamente, dándole la razón a aquellos clientes que piensan que nuestro trabajo no es profesional. Y es así como hemos entrado en un círculo vicioso de desprestigio del cual es difícil ver la salida. Consejos para tener éxito en el trabajo independiente Cuando uno tiene un trabajo fijo sólo se tiene que ocupar de hacer su trabajo, por ejemplo desarrollo, prueba y mantenimento de aplicaciones, o lo que sea en que su trabajo consista... Alguien más se hace cargo de los negocios, alguien más corre con los riesgos de negocio. Pero cuando uno intenta ganarse la vida como desarrollador independiente, es uno quien se debe ocupar de los negocios y correr con los riesgos comerciales, algo para lo que generalmente no estamos preparados para hacer simplemente porque nuestras universidades y otras instituciones de educación superior se enfocan en la preparación técnica, dejando las cuestiones de negocios a un lado. Estamos preparados para realizar un trabajo técnico como programadores, analistas, etc., pero no para dirigir nuestro propia empresa... En el resto de este artículo intentaré ofrecer algunos consejos acerca de cómo tener más éxito como desarrollador o consultor independiente, pero la clave aquí es que mientras más uno aprenda sobre negocios y mientras más uno piense en sí mismo y actúe como "Yo S.A.", más exitoso será. Poniéndose en los zapatos del cliente Mientras más entienda usted a sus (potenciales) clientes, tendrá más éxito al tratar con ellos. ¿Por qué deberían sus potenciales clientes contratarlo a usted en vez de un competidor suyo? ¿Por qué deberían pagarle lo que usted pide cuando otros piden mucho menos? Bien, usted tiene que aprender como revalorizar su trabajo apelando a hechos y sentimientos como un abogado que intenta convencer a un jurado. Justifique sus precios A los clientes se les hace difícil decidir a quién elegir para el desarrollo de una aplicación hecha a medida, y no es completamente cierto que por razones económicas eligen barato sobre bueno como mencionara en la primera parte de este artículo. Esto es lo que parece a primera vista, pero si uno escarba un poco bajo la superficie descubrirá que eligen barato y desconocido sobre caro y desconocido. ¿Qué opción elegiría usted? Ahora, si usted le explicara a sus clientes por escrito, clara y profesionalmente y con tanto detalle como sea posible por qué usted pide la suma que pide, y si provee su curriculum vitae como que lo presenta como uno profesional con "n" años de estudio y "n" años de experiencia, una lista de clientes, una descripción de sus último trabajos y todo, entonces la opción para los clientes será barato y desconocido (y ciertamente no tan profesional como usted) contra caro pero profesional. Este es un escenario mucho mejor. Garantice su trabajo La mayoría de los clientes están dispuestos a pagar un precio alto por un software garantido que un precio bajo por un software sin garantía y tarifas de mantenimiento altas o desconocidas, y hasta incluso bajas. Además, para un cliente la forma más clara distinguir a un profesional experimentado de uno sin experiencia es que el primero puede garantizar la calidad de su trabajo, por lo menos por cierto período de tiempo, mientras que el segundo tiene demasiada incertidumbre como para poder ofrecer esta clase de garantía, o de otro modo tendría que inflar sus honorarios demasiado para poder cubrir la garantía. ¿Qué debe usted garantizar? Básicamente, cuatro cosas: 1. Que usted acabará su trabajo dentro del plazo estipulado. Esto se aplica si a usted se le paga por trabajo realizado en vez de horas trabajadas, y la garantía consiste generalmente en una "multa" que será deducida de su paga y que generalmente se expresa como un porcentaje del monto total del proyecto, pudiendo por ejemplo ser de un 1% para cada día de atraso... 2. Que su software está libre de errores de programación. Por supuesto, la garantía sólo puede limitarse a la reparación por su cuenta y cargo de tales errores cuando éstos sean descubiertos, y usted no puede hacerse responsable por daños y perjuicios, etc. 3. Tiempo de respuesta. Por ejemplo que usted -o alguien designado por usted- concurrirá a las oficinas del cliente a evaluar la situación en el plazo de 24 horas de una llamada, y que cualquier error será reparado dentro de las 48 horas siguientes. 4. Su tarifa por trabajos adicionales. El mantenimiento no es únicamente reparar errores. Los sistemas necesitan ser actualizados, ampliados, movidos, etc. A los clientes les gustaría conocer cuál es su oferta de honorarios para los trabajos adicionales, por ejemplo $x/hora. Proporcione tanta información como pueda Nuestros clientes saben como trabaja un contador o un abogado y cómo facturan sus servicios, pero ¿qué hay de un analista-programador? La gente no sabe realmente mucho sobre nuestro trabajo y cómo determinamos el costo de una aplicación. En parte es nuestra culpa por no explicarles en términos simples y no técnicos como trabajamos y nuestros parámetros tasación. Sería de lo más profesional darle a nuestros clientes un documento escrito que explique como trabajamos, qué esperamos de ellos (como disponibilidad para las entrevistas), qué deberían esperar de nosotros (como los informes sobre la marcha de los trabajos y los documentos al final de cada etapa del proyecto), nuestros términos y condiciones de servicio y nuestra política de precios. No espere a que sus clientes le pidan un informe sobre la marcha de los trabajos. Hágales saber desde el primer momento que recibirán dichos informes sobre una base periódica. Poniéndose en sus propios zapatos Es muy bueno que usted se ponga del lado de su cliente puesto que esto lo ayudará a crear un puente de empatía y confianza entre ustedes dos, pero la calzada de ese puente debe circular en ambos sentidos. De la misma manera que como profesional debe velar por los intereses de su cliente, usted debe también velar por sus propios intereses. Logre que le paguen Si usted espera que le paguen cada semana, cada dos semanas o cada mes, más vale que tenga un contrato que así lo establezca. De otro modo su cliente puedo asumir que él tiene que pagarle solamente sobre la terminación del proyecto, y en muchas partes del mundo legalmente tendría razón. Normalmente usted no puede estar sin cobrar por un período tan largo de tiempo, y en el tercer mundo tiene que agregarle el riesgo de que ni siquiera le paguen una vez que haya entregado la aplicación. Por estas razones la única solución es un contrato escrito que le asegure que a usted deberá pagársele en ciertos puntos (semanalmente, mensualmente, basado en reportes de progreso o cuando sea). El contrato debe garantizarle que ante el primer incumplimiento del cliente usted puede rescindir el contrato sin más. Un cliente en problemas financieros no es un cliente. No otorgue descuentos Pedir descuentos es una práctica normal de negocios. Los desarrolladores exitosos no hacen descuentos (a menos que hayan inflado deliberadamente sus presupuestos Usted debe hacerle entender a sus clientes que no puede efectuar ninguna rebaja en el precio porque ya es una ganga para algo que solucionará sus problemas. Grábese estos mensajes en su mente y "presione 'Play'" cuando alguien le solicite un descuento: * "He estudiado 'n' años en la universidad, y aparte de eso me he capacitado 'n' años por mi cuenta, he atendido varios congresos y seminarios, y tengo 'n' años de experiencia en el campo laboral. Un profesional con mi curriculum no puede cobrar menos de lo que estoy cobrando..." * "Si alguien me pidiera que tradujera la Enciclopedia Británica, ese trabajo me tomaría toda una vida, y consiguientemente tengo que ganar lo suficiente para vivir toda una vida. Por razones obvias no podría hacer ningún descuento. Ahora, este trabajo me tomaría 'n' meses, así que tengo que ganar lo suficiente para vivir por 'n' meses. Y si usted piensa lo que le estoy cobrando demasiado por 'n', tiene que considerar que nosotros -los desarrolladores independientes- no tenemos sindicato, ni salario mínimo, ni beneficios sociales, ni vacaciones anuales pagas, etc., pero cada mes tenemos que pagar el alquiler, pagar las cuentas y pagar impuestos, así sea que tengamos trabajo o no. También necesitamos tener dinero para actualizar permanentemente nuestros equipos y software, y tenemos que poder pasar una cantidad considerable de tiempo aprendiendo cosas nuevas para estar al día con los continuos avances de la tecnología para poder seguir trabajando. Además doy garantías por mi trabajo y corro todos los riesgos si algo sale mal. Lo que le estoy cobrando es una ganga. No puedo hacer ningún descuento sobre eso..." Algunos clientes son persistentes e insisten en pedir un descuento. Si usted se rinde, algunos inescrupolosos -de los que puede encontrar muchos en el tercer mundo- lo tomarán como que usted es débil, inseguro y falto de confianza en sí mismo, y que simplemente con insistir ellos podrán conseguir cualquier cosa de usted. Otorgar un descuento es sólo el primer paso. El siguiente paso es que le pedirán algunos "pequeños" trabajos adicionales (gratis, por supuesto) y cuando usted acabe todo el trabajo, ellos le dirán que pagarán después que usted haga un par de "pequeños" trabajos adicionales... La moraleja de la historia es: NUNCA CEDA. Si realmente no pueden pagar lo que usted pide, entonces es muy probable que no lo puedan afrontar ni siquiera con un descuento, y esto significa que es muy probable que al final directamente no le paguen. Una vez más, un cliente en problemas financieros no es un cliente. Así que, ¿qué debe hacer si le insisten en un descuento? Niéguese y si es posible ofrezca una solución alternativa si es posible: la aplicación quizás se pueda podar para acomodarse al presupuesto del cliente. Y no se olvide de mencionar que seguramente pueden conseguir un precio mejor de un estudiante o de un desarrollador inexperto... Déjeles su tarjeta y déjelos pensar. No pierda más tiempo con ellos. Supongo que en el "Manual del Exitoso Hombre de Negocios" una de las reglas es dar algunas indirectas para hacer creer a los potenciales contratistas que después del primer contrato, otros seguirán, con el mismo cliente o con otros clientes. Pensando en las oportunidades que un contrato les dará, algunos desarrolladores desinflan sus presupuestos para conseguir a ese cliente, creyendo que después van a tener trabajo por un largo tiempo... Usted es inteligente, no caiga en esta trampa. Por lo general no siguen otros contratos, y si lo hacen, también serán "baratos", ¿o acaso piensa que más adelante podrá subir el precio después de darse la fama de ser "barato"? Condúscase como una empresa Como dijéramos en la introducción de este artículo, es fácil estar bajo la nómina. Alguien más se hace cargo del negocio. Pero cuando usted está por su cuenta, usted es una empresa unipersonal y es usted es quien debe tomar hacerse cargo del negocio porque nadie más lo hará. He aquí algunas cosas para que considere: * Una de las primeras cosas que debe aprender es como escribir cartas comerciales. Cuando me olvido de pagar una cuenta recibo una carta que me recuerda la deuda y que indica que si no pago para una fecha dada me cortarán el servicio. Usted debe hacer lo mismo con sus clientes. A propósito, aparte de cortarle el servicio, usted debe también reportar la deuda de su cliente a las entidades de verificación de crédito del mismo modo que cualquier empresa lo haría con usted cuando usted no les pague. * ¿Tiene tarjetas personales y papel membretado? Puede decir que esas no son más que pequeñas formalidades, pero esas pequeñas formalidades lo ayudan a definirse como una empresa. * ¿Tiene formularios preimpresos? Cuando alguien le solicita que usted le presupueste un trabajo, ¿dónde lo hace? Cuando entrevistando a alguien, ¿dónde toma notas? Cuándo realiza un trabajo adicional, ¿dónde usted señala lo que usted hizo, cuántas horas que tomó y cuánto dinero es eso? Cuándo alguien le solicita trabajos adicionales, ¿dónde está la Orden de Servicio firmada? * Nunca espere demasiado para una cita. Si la persona con la que usted tiene que hablar no está disponible y no lo estará en un tiempo razonable (digamos unos 30 minutos), usted debe dejar un mensaje con la secretaria (diciendo simplemente que usted estuvo allí), le deja su tarjeta y se marcha. No permita que lo tengan esperando. Su tiempo es demasiado valioso para eso. * Facture los trabajos adicionales inmediatamente. No espere hasta el final del mes para mandar la cuenta de los trabajos adicionales (aunque sí le puede dar ese plazo al cliente para pagarlos). Asegúrese de incluir los trabajos adicionales en su contrato y que la falla en pagarlos a su debido tiempo le permite terminar el contrato. * Nunca dé crédito. Los bancos están para eso. Si su cliente potencial tiene buen crédito, puede pedir un préstamo bancario y con eso pagarle a usted. Si le pide crédito a usted, entonces probablemente su crédito no sea tan bueno. Por última vez: un cliente en problemas financieros no es un cliente. Si un banco, con todos los recursos que tiene, con una estructura financiera capaz de soportar grandes quebrantos, con acceso a bases de datos de verificación de crédito, con abogados y todo, no le prestan dinero a alguien, ¿por qué debería hacerlo usted? articulo original Lo lei hace un tiempo y me parecio bastante interesante para los desarroladores como yo que laburamos en una empresa y por ahi nos sale alguna changuita particular y no sabemos como encararla desde el punto de vista administrativo y empresarial. Bue espero que les sirva y que pasen un muy buen dia mañana 1 de Mayo. saludos

Muy buena nota que lei hace un tiempo en un blog. Lo tenia en mis marcadores y ahora lo quiero compartir con ustedes. Espero que les sirva. Cosas que deberíamos aprender en la Universidad Recientemente leía el blog de un colega chileno y accedí al de Guy Kawasaki, donde encontré este "post" que, traducción mediante, decidí publicarlo acá y decirles que lo adhiero 100% y que espero que les resulte tan interesante como a mi: "Luego de unos años de trabajar en una empresa uno puede darse cuenta más fácilmente de lo que aprendió (y dejó de hacerlo) en las aulas de la Universidad. En este sentido pareciera ser que muchas veces en los ámbitos académicos se enseñan las habilidades opuestas a las necesarias para enfrentar el mundo del trabajo. Posiblemente durante la vida universitaria uno disponga de más tiempo que de dinero y es por ello que trabajos de amplia extensión, e-mails largos y las presentaciones orales no sean un problema diario. Sin embargo en la vida real, las personas cuentan con más dinero (al menos en términos comparativos) y muchísimo menos tiempo..... Esta es una lista de habilidades que deberían de aprenderse en la universidad y que nos permitirían enfrentar el mundo real del trabajo: 1. Cómo hablar con su jefe. En la universidad se supone que las personas tienen la posibilidad de llevar un problema a un profesor durante los horarios de consultas y que uno comparte la experiencia de encontrar una solución con la guía de otra persona. En el mundo real, se supone que debes enviar la solución del problema a tu jefe por mail, contársela en el medio de un pasillo o en una conversación de cinco minutos. Generalmente aunque tu jefe ya conozca el problema no quiere saber nada más sobre él. Tu rol es proveer de las respuestas, no de las preguntas. 2.Cómo sobrevivir a una reunión mal liderada. Desafortunadamente pasará un tiempo hasta que tengas la obligación de dirigir una reunión de trabajo. Mientras esto suceda, seguramente serás una víctima de ellas, por eso recomendaría adoptar estas tres prácticas para poder sobrevivirlas. Primero asuma que la mayor de las cosas que escuchará no agregan valor ni le sirven para algo y que eso es "parte del juego". Segundo, intente enfocarse en lo que usted necesita de esa reunión ignorando el resto de los temas tratados. Una vez que logra su objetivo, relájese, adopte una posición cómoda y "disfrute del show". Tercero, prométase a si mismo que el día que ponga en marcha una empresa las reuniones no serán como esa. 3. Cómo liderar una reunión. Posiblemente te corresponda liderar reuniones de trabajo en poco tiempo más. Para ello lo primero que deberías comprender es que el principal objetivo de una reunión de negocios es tomar una decisión. No se hacen para sentirse "acompañado", "cómodo" o para "compartir experiencias". Con esto en mente, aquí hay cinco puntos a tener en cuenta al momento de liderar una reunión de trabajo: (1) Comience de acuerdo al horario fijado, aún cuando no estén todos presentes porque la siguiente vez sí lo estarán; (2) Invite a la menor cantidad de personas posibles a la reunión; (3) Fije una agenda de temas y prioridades de lo que exactamente debe suceder en esa reunión; (4) Termine en el tiempo acordado de manera tal que todos se vean obligados a focalizarse en los temas pertinentes; (5) envíe un e-mail a los participantes que permita confirmar las decisiones tomadas. Seguramente hay otros temas a considerar para liderar una reunión con éxito pero si tienen en cuenta estos cinco, estarán adelante un 90% del resto del mundo. 4.Cómo adquirir autonomía para lidiar con las cosas. Armado con un buscador de Internet como Google, manuales impresos en versiones PDF y mucha autoestima, haga un esfuerzo para aprender de qué manera puede conocer a cerca de todo por sus propios medios. En el mundo real, no existen los horarios de consulta, ni los asistentes de docencia, ni los grupos de estudio. Actualmente en el mundo del trabajo es lago, muchas veces solitario al momento de estudiar un proyecto, así que vete acostumbrando a ello. 5. Cómo negociar. No creas en todo lo que ves en los programas de televisión sobre equipos y procesos de negociación, esas son todas mentiras. El único método que funciona en el mundo real implica estos cinco pasos: 1) Prepararse para la negociación conociendo al detalle los hechos reales, 2) Tenga en claro qué es lo que usted realmente quiere, 3) Tenga en claro qué es lo que usted realmente no desea, 4) Piense qué es lo que la otra parte realmente necesita y desea, y 5) Desarrolle una salida lo más ganadora para ambas partes asegurándose que están todos contentos. 6. Cómo conversar. Generalmente la expresión: "¿Qué onda?", no es la más utilizada en el mundo del trabajo. Generalmente, si escuchas más de lo que hablas (irónicamente), no solamente serás considerado como un muy buen conversador sino además como una persona inteligente... 7. Cómo explicar algo en 30 segundos. Desafortunadamente muchas universidades no cuentan con ascensores ni tampoco los estudiantes deben saber cómo explicar alguna cuestión en no más de 30 segundos. Piense en el concepto de mantra (formado solamente por tres palabras), no en una declaración de principios (de setenta palabras). Piense que el tiempo y no el dinero es el bien más preciado. Piense adelante suyo no sobre sus pies. Al final de una comunicación de 30 segundos debería haber una respuesta obvia a la pregunta:¿Entonces qué hacemos? 8. Cómo escribir reportes de una página. Recuerdo lo complicado que era durante mi época de estudiante universitario llegar a redactar con la mínima extensión requerida un trabajo. Muchas veces el espaciado doble, la letra tamaño 14 y los "bullets" me salvaban. Luego comencé a trabajar en el mundo real y me encontré con jefes que lo único que querían leer eran reportes de no más de una página de extensión. ¡Qué curioso!, los mejores informes son generalmente los que tienen una página o menos de extensión ya que van directo al punto de manera concisa, clara y concreta. 9. Cómo escribir e-mails de 5 oraciones. Los jóvenes tienen una ventaja sobre los adultos en esta área ya que escribir mails y mensajes cortos no son una nueva experiencia para ellos (la utilización del msn o del chat es un buen entrenamiento). No importa si eres un joven o un adulto lo importante es saber que la extensión ideal para un mail es de cinco líneas (u oraciones). Todo lo que necesita hacer es explicar quién es, qué desea, porqué debería tenerlo y cuándo lo necesita. 10. Cómo relacionarse con los demás. Mucho del éxito en la vida universitaria está dado por acciones individuales, calificaciones, test, proyectos, trabajos escritos, entre otros; generalmente en pocos cursos el trabajo en equipo (no en grupo) es valorado y/o promocionado. Luego, en la vida real del mundo del trabajo los mayores logros se dan en equipos y no por acciones individuales. Lo que se ha vuelto más y más importante es la habilidad de trabajar con, a través, a pesar y a veces alrededor de otras personas. 11. Cómo usar el PowerPoint. He tenido la oportunidad de ver presentaciones de profesores que piensan: " Si tengo una clase de 60 minutos, a un minuto por transparencia, necesito 60 slides para cada clase". Entonces terminan copiando el texto completo de un libro en la presentación. El mundo del trabajo aconsejo aplicar la ley 10/20/30: 10 slides, en 20 minutos de presentación y con un tamaño de letra de 30, si asumimos que usted quiere lograr tener lo que se propone. 12. Cómo dejar un mensaje de voz. Muy pocas personas de cualquier edad pueden dejar efectivos mensajes de vos en el contestador telefónico. El principal objetivo de un mensaje telefónico es que al final del tiempo la persona que lo escucha tenga una idea clara de qué es lo que usted quiere. El modelo óptimo de un mensaje de voz es la expresión oral de un mail de cinco oraciones y la extensión adecuada son 15 segundos. Dos consejos importantes: Primero hable despacio y mencione su número de teléfono al inicio y al final del mensaje, usted no querrá que el destinatario tenga que volver a escuchar nuevamente todo el mensaje para tomar nota de su número de contacto. El segundo (y también aplicado a los e-mails) siempre vaya un paso adelante. No diga "llámame y combinamos para encontrarnos", directamente diga:" Martes 10hs en tu oficina". Finalmente, el objetivo de ir a la universidad no es prepararnos para el mundo del trabajo sino prepararnos para la vida. El trabajo es parte de nuestras vidas y requiere de este tipo de habilidades sin importar la orientación profesional que tengamos. Como sea hay mucho más vida que trabajo así que es mejor que estudie lo que realmente ama. Fuente

Registrate y eliminá la publicidad! Las 10 cosas que más fastidian a los programadores Me ha parecido muy interesante y divertido el post de Kevin Pang, "Top 10 Things That Annoy Programmers", en el que obtiene los factores más irritantes para los desarrolladores combinando su propia experiencia con los resultados de una pregunta realizada en StackOverflow, la famosa comunidad de desarrolladores promovida por los populares Joel Spolsky y Jeff Atwood. Además de estar casi totalmente de acuerdo con los puntos expuestos en su post, que enumero y comento a continuación, añadiré algunos más de propia cosecha de agentes irritantes. #10.Comentarios que explican el "cómo" y no el "qué" Tan importante es incluir comentarios en el código como hacerlo bien. Es terrible encontrar comentarios que son una simple traducción literal al español del código fuente, pues no aportan información extra, en lugar de una explicación de lo que se pretende hacer. Muy bueno el ejemplo de Kevin en el post original... ¿eres capaz de decir qué hace este código, por muy comentado que esté? Cita :r = n / 2; // Set r to n divided by 2 // Loop while r - (n/r) is greater than t while ( abs( r - (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r) } # 9. Las interrupciones. Sin duda, el trabajo de desarrollador requiere concentración y continuidad, y las interrupciones son las grandes enemigas de estos dos aspectos. Una jornada de trabajo llena de llamadas, mensajes o consultas de clientes, proveedores, jefes o compañeros puede resultar realmente frustrante, a la vez que la distracción que introduce suele ser una fuente importante de errores en las aplicaciones. # 8. Ampliación del ámbito. Una auténtica pesadilla, sobre todo cuando se produce durante el desarrollo, consistente en el aumento desproporcionado del alcance de determinadas funcionalidades o características del software a crear. Es especialmente desmotivador si, además, no viene acompañado por el aumento del tiempo o recursos necesarios para su realización. Kevin incluye en su artículo un ejemplo, algo exagerado pero ilustrativo, de sucesivas ampliaciones de ámbito que convierten un requisito factible en un infierno para el desarrollador; seguro que os recuerda algún caso que habéis sufrido en vuestras propias carnes: Cita :# Versión 1: Mostrar un mapa de localización -- Bah, fácil, sólo tengo que crear una imagen; incluso puedo basarme en algún mapa existente que encuentre por ahí # Versión 2: Mostrar un mapa 3D de localización -- Uff, esto ya no es lo que hablamos; tendré que currarme bastante más el diseño, y ya no será tan fácil partir de alguno existente... # Versión 3: Mostrar un mapa 3D de localización, por el que el usuario pueda desplazarse volando -- ¡! # 7. Gestores que no entienden de programación. Otro motivo común de irritación entre los desarrolladores es la incapacidad de gestores para comprender las particularidades de la industria del software en la que trabajan. Este desconocimiento genera problemas de todo tipo en una empresa y suponen un estrés terrible para el desarrollador. # 6. Documentar nuestras aplicaciones. Lamentablemente, en nuestro trabajo no todo es desarrollar utilizando lenguajes y tecnologías que nos divierten mucho. Una vez terminado un producto es necesario crear guías, manuales y, en general, documentación destinada al usuario final que, admitámoslo, nos fastidia bastante escribir. # 5. Aplicaciones sin documentación. A pesar de que entendamos y compartamos el punto anterior, también nos fastidia enormemente tener que trabajar con componentes o librerías partiendo de una documentación escasa o nula. Si lo habéis sufrido, entenderéis lo desesperante que resulta ir aprendiendo el significado de las funciones de un API usando el método de prueba y error. # 4. Hardware. Especialmente los errores de hardware que el usuario percibe como un fallo de la aplicación son normalmente muy difíciles de detectar: fallos de red, discos, problemas en la memoria... por desgracia, hay un amplio abanico de opciones. Y lo peor es que por ser desarrolladores de software se nos presupone el dominio y control absoluto en asuntos hardware, lo que no siempre es así. # 3. Imprecisiones. Aunque Kevin lo orienta al soporte al usuario, el concepto es igualmente molesto en fases de diseño y desarrollo del software. Las descripciones vagas y confusas son una causa segura de problemas, sea en el momento que sea. Son irritantes las especificaciones imprecisas, del tipo "esta calculadora permitirá al usuario realizar sumas, restas, multiplicaciones y otras operaciones"... ¿qué operaciones? ¿divisiones? ¿resolver ecuaciones diferenciales? Tampoco es fácil encajar un mensaje de un usuario tal que "me falla el ERP, arréglalo pronto"... A ver. El ERP tiene cientos de módulos, ¿fallan todos? ¿podríamos ser más concretos? # 2. Otros programadores. Como comenta Kevin, el malestar que provoca a veces la relación entre programadores bien merecería un post independiente, pero ha adelantado aspectos que, en su opinión, hace que a veces el trato con los compañeros sea insoportable: Cita :# Personalidad gruñona, hostilidad # Problemas para comprender que hay que dejar de debatir la arquitectura del sistema y pasar a realizar las tareas # Falta de habilidad para mantener una comunicación efectiva # Falta de empuje # Apatía hacia el código y el proyecto 1. Tu propio código, 6 meses después. Sí, es frustrante estar delante de un código aberrante y darte cuenta de que tú eres el autor de semejante desastre. Y tras ello llega la fase de flagelación: ¿en qué estaba pensando cuando hice esto? ¿cómo fui tan estúpido? uff... Este hecho, sin embargo, forma parte de la evolución tecnológica, personal y profesional; todos estos factores están en continuo cambio, lo que hace que nuestra forma de atacar los problemas sea distinta casi cada día. Y hasta aquí la lista de Kevin en su post, ni que decir tiene que comparto sus reflexiones en la mayoría de los puntos. Por mi parte, añadiría los siguientes agentes irritantes que conozco por experiencia propia o de conocidos: * Extra 1. Requisitos evolutivos, como una ampliación del ámbito del punto 8 ;-), que son aquellos que van cambiando conforme el desarrollo avanza y que obligan a realizar refactorizaciones, descartar código escrito, e introducir peligrosas modificaciones, afectando a veces por debajo de la línea de flotación del software. Más rabia produce, además, cuando se atribuyen una mala interpretación por parte del desarrollador de una especificación imprecisa. * Extra 2. Problemas en el entorno. Nada más frustrante que cortes en el suministro eléctrico, cuelgues, problemas en el hardware, lentitud en los equipos de trabajo o de acceso a información... a veces parece que tenemos que construir software luchando contra los elementos. * Extra 3. El "experto" en desarrollo de software. Clientes, gestores y otros individuos que utilizan frecuentemente, y sin conocimiento alguno de causa, expresiones como "Esto es fácil", "Una cosa muy sencilla", "¿Eso vas a tardar en hacer esta tontería?".... A veces no es fácil hacer entender que la percepción externa de la complejidad es absolutamente irreal, y suele ser una causa frecuente de desesperación para los desarrolladores. * Extra 4. Usuarios corrosivos, que lejos de colaborar durante el desarrollo o la implantación de un sistema, aprovechan la ocasión para arremeter contra la aplicación, organización, jefes, compañeros, el gobierno, o lo que se ponga por delante. Es de justicia decir que muchas veces este comportamiento es debido a una mala gestión interna del proyecto, pero desde el punto de vista del profesional del sofware que sólo quiere realizar lo mejor posible su trabajo son una auténtica pesadilla. En fin, que ya a estas alturas es fácil ver que hay bastantes cosas que fastidian a los desarrolladores, y seguro que podríamos añadir muchas más; algunas son evitables, otras son inherentes a la profesión y hay que aprender a convivir con ellas, pero en cualquier caso son un interesante motivo de reflexión. ¿Y a tí, qué es lo que más te fastidia? Fuente <a href="http://ads.us.e-planning.net/ei/3/46bb/f9cfaf75666c1c8a?it=i&rnd=$RANDOM" target="_blank"><img width="728" height="90" alt="e-planning.net ad" src="http://ads.us.e-planning.net/eb/3/46bb/f9cfaf75666c1c8a?o=i&rnd=$RANDOM" border=0></a>