"GEDME" disponible para descarga

Desde SoftProman estamos contentos de anunciar que ya está disponible para descargar desde nuestra página web la aplicación "GEDME" en modo Trial de 30 dias.

¿Que es el GEDME?

Tal y como mencionamos en su dia bajo la entrada "Gestor de metadatos" el diccionario (ahora llamado Gedme) es una aplicación que nos permitirá definir la estructura completa de nuestra base de datos, independientemente de que esta vaya a ser de MS SQL o de MYSQL o de cualquier otro tipo.
Esta herramienta ha sido pensada para los desarrolladores de aplicaciones que hacen uso de las bases de datos.
Podremos definir las tablas, campos, indices, relaciones de integridad e incluso las actualizaciones y preactualizaciones que se debe pasar en esa base de datos así como funciones y procedimientos.
La aplicación finalmente genera en unos directorios una estructura de ficheros XML que más tarde desde nuestros programas solo hay que interpretar y que para que el usuario no tenga que hacerlo, distribuimos una DLL que hará que no tengas que programar ni una sola linea de codigo para gestionar estos XML y que se podrá llamar desde Visual Basic, C#, Delphi, etc.

Lo dicho, descargalo, pruebalo y danos tu opinión.

SoftProman cambia de imagen

Desde SoftProman se ha estado trabajando en un cambio de imagen. ¿Como? Con un nuevo diseño web y un nuevo logotipo.

Todo ello ya disponible en la web (www.softproman.es).

Ejecutar aplicaciones 32 bits en sistemas operativos de 64 bits

El autor de artículo es originario de geeks pero he creido conveniente que sería interesante también mencionarlo en nuestro blog.
La dirección exacta del artículo lo podeis encontrar en:
Ejecutando aplicaciones de 32 bits en puestos con S.O. Windows de 64 bits


Inicio del artículo:

"Las versiones x64 de Windows (entre ellas la reciente de Windows Vista 64 bits) no son capaces de ejecutar código de 32 bits de forma nativa. Como hoy en día la mayor parte de las aplicaciones siguen siendo de 32 bits, las versiones x64 de Windows hacen uso de un emulador conocido como WOW64 para permitir que las aplicaciones de 32 bits funcionen en ellas.

Uno de los problemas con el funcionamiento de código de 32 bits en un sistema operativo de 64 bits es que el OS debe mantener una separación completa del código. Microsoft ha creado una carpeta nueva llamada \Windows\SysWOW64 que se utiliza para almacenar las DLL y componentes de 32bits. En las versiones de 32 bits de Windows, los archivos DLL se almacenan normalmente en la carpeta \Windows\System32. Sin embargo, en las versiones de 64 bits de Windows se utiliza la carpeta \Windows\System32 para las DLL de 64bits.

Como se puede ver, el emulador WOW64 debe realizar el cambio de dirección del sistema de ficheros para garantizar que el código de 32 y 64 bits siga separado. Pero mantener archivos del DLL separados es solamente el principio. El emulador WOW64 realiza el cambio de dirección del sistema de ficheros para varios componentes clave del sistema operativo de Windows.

Otro lugar en Windows en donde se utiliza el cambio de dirección del sistema de ficheros es en la carpeta de archivos de programa. Casi todas las aplicaciones instaladas copian sus archivos a la carpeta “C:\Program Files” dentro de una carpeta propia para la aplicación. En las versiones x64 de Windows, las aplicaciones de 64 bits están instaladas en la carpeta “C:\Program Files” y las aplicaciones de 32 bits están instaladas en una carpeta nombrada “C:\Program Files (x86)”.

Sin embargo, la carpeta de archivos de programa puede no estar siempre en el mismo lugar en cada microordenador. Por ello, la mayoría de los desarrolladores no hacen referencia dentro sus programas directamente a “C:\Program Files” sino que llaman a funciones para obtener el nombre real de esta carpeta en el PC en cuestión.

En las versiones de 32 bits de Windows, la función SHGetSpecialFolder() se utiliza para determinar el nombre y la localización de la carpeta de archivos de programa. Pero en la versión de un S.O. x64, la función mira si la aplicación funciona a 32 bits o a 64 y realiza el cambio de dirección de la carpeta apuntando a la adecuada.

La instalación de una aplicación no es la única vez que se hace referencia a la carpeta de archivos de programa; puede también ser referenciada en el tiempo de ejecución. Aunque hay varias maneras que una aplicación pueda determinar el nombre y la localización de la carpeta de archivos de programa, el empleo de las variables de entorno es lo más utilizado. En una versión de 32 bits de Windows, la variable de entorno %ProgramFiles% contiene la trayectoria a la carpeta de archivos de programa. En una versión x64 de Windows, esta variable de entorno también se utiliza, pero trabaja de una forma diferente.

La regla más importante de la plataforma x64 es que no puedes mezclar de ninguna manera código de 64 y 32 bits. Las variables de entorno se llaman a menudo dentro de ficheros de comandos por lotes (.CMD o .BAT) o por scripts. Siendo éste el caso, ejecutar scripts puede ser un poco peligroso en un entorno de 64 bits. ¿Debe Windows tratar el script como código de 32 bits o como de 64? La respuesta afecta no sólo al contenido de las variables de entorno, sino también que los programas que llame el propio script. Por ejemplo, un script de 64 bits no puede lanzar un proceso de 32 bits (por lo menos no de la manera normal).

Windows consigue solucionar estos problemas ofreciendo dos intérpretes de comandos: uno de 64 bits y otro de 32. Las variables de entorno se establecen de acuerdo al intérprete de comandos utilizado.

Por ejemplo, si se abre una ventana de comandos lanzando el comando CMD.EXE en la ventana “Inicio/Ejecutar …” (Run), Windows abrirá una ventana de comandos de 64 bits. En la mayoría de los casos, la variable de entorno %ProgramFiles% para el entorno de trabajo será fijada a “C:\Program Files”. Si se lanza un script, éste podrá ejecutar aplicaciones y comandos de 64 bits, pero no de 32 bits.

En el lado contrario, si se lanza “C:\Windows\SysWOW64\cmd.exe” en la ventana “Inicio/Ejecutar …”, la ventana de comandos que se ejecuta es de 32 bits. En ese caso, la variable de entorno del %ProgramFiles% será “C:\Program Files (x86)”.

Como se puede ver, la localización de la carpeta de archivos de programa se redirige dependiendo de si se está funcionando a 32 ó 64 bits. Pero hay una excepción a esta regla: si una aplicación tiene la referencia a la carpeta de archivos de programa escrita directamente como “C:\Program Files”, por ejemplo, se utilizará esta carpeta directamente, sin tener en cuenta el entorno en el que se está trabajando y esto podría dar lugar a diversos problemas, al intentar ejecutar código de 64 bits de algún componente cuando la aplicación es de 32 bits. Afortunadamente esto no es una buena práctica de programación y esperamos no encontrarlo en nuestras aplicaciones.

También en el registro hay una estructura a utilizar cuando se está trabajando a 64 bits y otra a usar cuando se está en 32 bits. Así, dentro de HKEY_LOCAL_MACHINE/SOFTWARE hay una arborescencia llamada Wow6432Node, que será utilizada en lugar de HKEY_LOCAL_MACHINE/SOFTWARE cuando se esté trabajando a 32 bits. Aquí tenemos el mismo funcionamiento y problemas que con las anteriores redirecciones.

Por ejemplo, si lanzamos un cambio del registro haciendo doble-click sobre un fichero .REG, las entradas a añadir o modificar se harán sobre las claves exactas que haya en este fichero y no como relativas a Wow6432Node si estos cambios son para una aplicación de 32 bits.

Si este fichero .REG es ejecutado por una aplicación o una ventana de comandos de 32 bits, los cambios se incluirán en la parte del registro correspondiente a 32 bits.

En resumen, con este sistema empleado por el emulador WOW64, se puede conseguir que la mayor parte de las aplicaciones de 32 bits puedan convivir con las de 64 en un puesto de trabajo que utilice un S.O. de 64 bits. Sin embargo, cuando estas aplicaciones, por alguna mala práctica de programación o por algún truco obligado hacen referencia o utilizan de una forma no estándar las carpetas \Windows\SYSTEM32 (o \Windows\SYSWOW64), Program Files (o Program Files (x86)) o el registro, puede haber problemas que impidan su correcta ejecución.

El registro de Windows es un archivo que contiene a mayoría de los datos de la configuración del sistema operativo de Windows. El registro contiene una variedad enorme de información, pero los datos de la configuración en que el emulador WOW64 está más interesado son una lista de todos los objetos del Component Object Model (COM) que han sido registrados por el sistema operativo.

COM proporciona una manera para que las aplicaciones (archivos .EXE) y las bibliotecas (archivos .DLL) puedan hacerse accesibles a cualquier otra aplicación o fichero de comandos que cumpla las normas COM. COM permite que alguien con habilidades de programación mínimas pueda escribir una aplicación o un script que interactúe con Windows. La persona que escribe la aplicación o el script puede hacerlo sin tener que aprender un lenguaje de programación tal como C++, y sin tener que aprender todos los interfaces de programación de Windows (APIs).

Windows se diseñó de manera que todos los objetos COM disponibles estuvieran dentro del registro. Para garantizar que el código de 32 bits esté aislado totalmente del código de 64 bits, los objetos COM de 32 y 64bits se almacenan en dos partes distintas del registro.

En lenguaje de Microsoft un servidor COM es un objeto que hace disponible su funcionalidad a través de COM. Las aplicaciones y scripts que hacen uso de esa funcionalidad se llaman clientes COM.

Cuando se habla de un servidor COM in-process se refiere generalmente a las bibliotecas (archivos .DLL), porque éstas se ejecutan como parte del mismo proceso que las aplicaciones y scripts que los llamaron. Un servidor COM out-of-process es un objeto COM (generalmente un fichero ejecutable) que se ejecuta en un proceso distinto que la aplicación o script que lo llamó.

Cuando una aplicación intenta registrar un objeto COM, el emulador WOW64 pondrá las entradas correspondientes en la sección apropiada del registro, dependiendo de si el objeto COM es un objeto de 64 o de 32 bits.

Cuando una aplicación o un script que se supone que son de 32 bits intentan cargar un objeto COM en el proceso, el emulador WOW64 redirecciona el registro para estar seguro que la aplicación o script lee la porción del registro que refiere a objetos COM de 32 bits. Si el registro no contiene una referencia a una versión de 32 bits del objeto COM solicitado, WOW64 dirá a la aplicación que no existe el objeto, aunque exista una versión 64 bits disponible. La misma cosa sucede si una aplicación de 64 bits solicita un objeto COM. Windows comprobará la parte del registro correspondiente a 64 bits para saber si hay una referencia al objeto y no hará caso de cualquier objeto COM de 32 bits.

Servidores COM Out-of

La manera que WOW64 vuelve a dirigir peticiones de servidores COM in-process es bastante directa. Pero las cosas funcionan diferentemente para los servidores COM out-of-process. La redirección del registro todavía hace falta, pero esto es solamente una parte del proceso.

Las llamadas a un servidor COM out-of-process son la excepción a la regla de mantener separados el código de 32 bits y el de 64.

Aislar el código de 32 bits es normalmente un requisito porque no puedes mezclar código de 64 bits y de 32 dentro de un proceso. Pero cuando son servidores COM out-of-process, el objeto COM está funcionando en un proceso totalmente distinto del del código que lo llamó. Esto significa que la aplicación puede funcionar con código de 32 y llamar a un objeto COM de 64 bits, o viceversa.

Ya que la aplicación y el objeto COM están funcionando en procesos distintos, es fácil ver que sería posible que funcionaran ambos en el mismo sistema. ¿Pero cómo puede la aplicación comunicarse con un objeto COM si uno está funcionando en 32 bits y el otro en 64? Aunque la aplicación y el objeto COM no puedan interactuar directamente uno con otro porque estén funcionando en procesos distintos, pueden comunicarse con Remote Procedure Calls (RPCs).

Los ordenadores que funcionan en una versión x64 de Windows utilizan la redirección del registro para conseguir el funcionamiento de aplicaciones de 32 y 64 bits. Esta redirección del registro evita que las aplicaciones sobre-escriban la configuración de las de 64 bits, pero permite todavía que las aplicaciones y los archivos DLL que utilicen arborescencias escritas a mano continúen funcionando.

Las claves del registro relacionadas con las aplicaciones están instaladas generalmente en la clave HKEY_LOCAL_MACHINE\SOFTWARE. En una versión x64 de Windows, esta entrada se utiliza exclusivamente para almacenar los datos de la configuración relacionados con las aplicaciones de 64 bits. Los datos de configuración relacionados con aplicaciones de 32 bits se almacenan en la clave del registro HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432node.

Obviamente, las aplicaciones de 32 bits no están diseñadas para buscar en la entrada HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432node. El emulador WOW64 intercepta las llamadas del registro de las aplicaciones de 32 bits y, de forma transparente, vuelve a dirigir estas llamadas al lugar apropiado dentro del registro de Windows.

La entrada HKEY_LOCAL_MACHINE\SOFTWARE a menudo contiene algo más que los datos de la configuración para las aplicaciones. En ella se almacenan los datos de configuración relacionados con cosas tales como la incrustación y vinculado de objetos o las llamadas remotas (RPCs). Por ello, las llamadas a las llaves secundarias debajo de esta entrada también se redirigen.

Desarrollo de software informático

Hay diferentes sistemas de gestión para el desarrollo de un software informático, pero considero que la metodología SCRUM es la más extendida en la actualidad.

¿Qué es SCRUM?
Es una metodología del software que ayuda a la autogestión de los equipos de programación para realizar el trabajo.
Se gestiona el proyecto mediante los llamados Sprints (ver def. más abajo) para obtener algo "tangible" que permita al cliente probar el producto aunque éste no esté finalizado.
Este sistema, permite al grupo de programadores decidir cómo hacer las tareas y determinar el tiempo que se va a dedicar para realizarlas.
Con este sistema, también se facilita que, todos los miembros del equipo trabajen juntos en una misma dirección, evitando así, los llamados “Reinos de Taifas”.
Scrum también nos permite realizar un seguimiento del avance del proyecto de una forma muy transparente, dónde se puede ver, día a día, como se progresa.
En resumen, prodríamos decir que esta metodología está basada en el desarrollo ágil de software y más concretamente, en la programación extrema

¿Características del SCRUM?
El scrum está formado por diferentes roles, de los cuales, los principales son:

ScrumMaster, ProductOwner, Team

• ScrumMaster es el director del proyecto y el encargado de eliminar los obstáculos que impiden que el equipo de desarrollo alcance el objetivo del sprint.

• ProductOwner es el "cliente o representante de la voz del cliente" que nos indica sus necesidades y sus prioridades.
  

• Team es el equipo de desarrollo para llevar acabo las necesidades del cliente.

¿Cómo funciona SCRUM?
Antes de explicar el funcionamiento hay que saber el significado de las siguientes expresiones:

• Sprint es una división de un conjunto de tareas componen un proyecto en un periodo de tiempo. Normalmente los sprints suelen ser de 15 a 30 días). En cada sprint se busca poder tener una parte del proyecto que sea "entregable" para poder ver la evolución del mismo hasta llegar al producto final.

• Sprint Planning Meeting es la primera reunión que se realiza para determinar el sprint que se va a realizar. Los asistentes a la reunión són: ProductOwner y Team.

• Product Backlog es el conjunto de funcionalidades y tareas a realizar. El ProductOwner es el encargado del mantenimineto y de establecer las prioridades.
  

• Sprint Backlog es la tarea o el conjunto de tareas que se detallan del Product Backlog.
  

• Daily Scrum Meeting es una reunión diaria con el Team (no supera los 30 minutos) donde se habla del las tareas realizadas, los impedimientos (si hay), que tareas se van abordar y si se necesita ayuda.

• Sprint Review es una revisión de unas 2h aprox. del sprint finalizado.

• Sprint Retrospective es la revisión de los objetivos del Sprint Backlog, se aplican los cambios y los ajustes necesarios. También se comentan los aspectos positivos y negativos.
  

El funcionamiento de Scrum, es sencillo.
Primero se realiza una reunión dónde se exponen las necesidades del cliente y se priorizan. En otras palabras, realizamos lo que se denomina el Sprint Planning Meeting.
Una vez realizado, se establece como va a ser el Sprint y se generan los Product Backlogs correspondientes con sus Sprints Backlogs.
Finalizado esto, el Scrum se pone en marcha y cada día se realiza el Daily Scrum Meeting.
Cuando el sprint acaba, se realiza el Sprint Review y el Sprint Retrospective.

Espero que ésta explicación sobre Scrum haya ayudado a entender mejor la finalidad y el funcionamiento de ésta metodología de trabajo.

Para más información, dejo en los enlaces externos, unos links, dónde se puede obtener más información.

Enlaces externos

1. Página oficial Scrum
2. Wikipedia
3. Explicando Scrum a mi abuela
   

Verbatim STORE 'N' GO Micro 4 GB ¡¡¡ No se puede formatear !!!

De nuevo mi hermano me ha venido con un problema que me parece interesante comentar en el Blog.
Lo que le ha pasado es lo siguiente: A raíz de pinchar su PenDrive Verbatim STORE 'N' GO Micro 4 GB en un lector de DVD resulta que se le ha... digamos... dañado. El resultado es que al pincharlo de nuevo en el PC le dice que el disco no tiene formato y además no le deja formatearlo porque le dice que el disco está protegido contra escritura. ¿Contra escritura? ¡Si el PenDrive no tiene nada de eso! Bueno... no nos preocupemos. Total que me lo ha dado para ver que se podía hacer.

Lo primero que he hecho es ir a la página de verbatim y en soporte mirar si había algún software para formatear estos PenDrive pero nada de nada. De hecho cuando te dice que escojas el tipo de pendrive basándote en su foto resulta que los Verbatim STORE 'N' GO Micro 4 GB ni siquiera aparece. He optado por enviar un email al soporte técnico de Verbatim pero aun no me han contestado (han pasado 7 horas desde que lo envié) por lo que he decidido buscar alternativas.

No me voy a enrollar contando la cantidad de porquería que me he tenido que instalar para hacer pruebas ni la de páginas que he tenido que leer con este mismo problema por lo que vamos a ver como lo he solucionado.

La base para que haya podido encontrar una solución la propuso un usuario invitado (desconocido) en los foros de FIXYA.COM

La idea es ir a la web de APACER y descargar el REPAIR TOOLS que este usuario indica pero yo lo hice y no me funcionó así que decidí probar con todas las versiones de "Repair Tools" de esta casa ya que tienen la aplicación para distintos IC (Circuitos Integrados que al fin y al cabo es lo que tienen los pendrive).

Pues eso que me fui a la siguiente web: http://emea.apacer.com/en/support/downloads.asp y en Keyword Search puse "Repair Tool" y salió una pantalla con todas las versiones disponibles. En mi caso para el Verbatim STORE 'N' GO Micro 4 GB hay que bajarse el "AH323 Handy Steno 2.0 Repair Tool"

Lo lanzamos y seguimos las instrucciones.

Ahora desde el propio windows lo formatee en NTFS o FAT32 y ¡¡Listo!! Ya tenemos recuperado el PenDrive, eso si, no gracias a la ayuda de Verbatim que ocho horas después no me han dado ninguna solución (si me dicen algo ya lo anotaré aquí).

Asus EEEPC 904HD

Este viernes pasado a última hora de la tarde mi hermano me trajo un mini portatil de esos que se venden tanto últimamente y que yo no habia tenido tiempo de trastear. El problema que me presentaba era el siguiente:

- El eeePc no tiene lectora de CD/DVD y el windows se ha fastidiado. ¿Que hago?

Al principio pense que sería sencillo. Lo conecto via red, comparto la unidad de CD e instalo. Total que al final mi hermano se fue varias horas despues dejandome con el cacharro.

Inicialmente lo más sencillo hubiera sido instalar el windows desde una lectora externa pero como que no tengo ninguna... va a ser que no.

Despues se me ocurrio que ¿porque no instalar el windows desde un Pendrive? Me he pasado todo el fin de semana intentando crear uno que botee y funcione pero nada. El principal problema que me he encontrado es que el windows al intentar copiar los ficheros no es capaz (no copia ni uno). Usé una alternativa con el viejo conocido Hiren's BootCd (version 9.9 en mi caso)

No me voy a explayar contando todas las pruebas que llegado a hacer porque al final se me escapó lo más obvio, y esto era que el problema era que la partición se habia ido a la mierda.

Aquí os detallo como he llegado a instalar XP desde un PenDrive en un Asus EEEPC 904 porque aunque en internet hay multitud de guias, todas omiten un par de pasos que son importantes.

Vamos alla:

Los requisitos son:
- 1 PenDrive (en mi caso de 8Gigas)
- Disco Original de Windows XP (Home o Professional). En caso de no tenerlo, lo podriamos solucionar con el TEU 8 y Daemon Tools (luego veremos como)
- 1 PC para poder preparar el Pendrive de instalacion

Paso 1: Descargar el paquete USB_MultiBoot_10.zip o desde USB_MultiBoot_10.zip o desde USB_MultiBoot_10.zip y descomprimirlo en C:\ (no usar espacios en las rutas y mejor dejarlo en la raiz)

Paso 2: Si usas Windows Vista hay que desactivar el control de cuentas (si, adios a la seguridad pero es lo que hay). Se hace desde Inicio-->Panel de control --> Cuentas de Usuario --> Activar o desactivar el control de cuentas de usuario.

Paso 3: Crear una carpeta en el disco duro llamado WINXPSETUP y copia dentro TODO el contenido del CD de Windows. En caso de usar el TEU 8 basta con guardar la ISO en el HD y con el DaemonTools montar la imagen.

Paso 4: Ejecutamos el fichero USB_MultiBoot_10.cmd . Saldrá una pantalla. Pulsamos enter. En esta pantalla pulsamos H para proceder a formatear el Pendrive. Lo formateamos con formato rápido y sin marcar lo de crear un disco de arranque DOS.

Paso 5: Una vez formateado cerramos la aplicación de formatear y volvemos a la ventana MS-DOS. Ahora hay que rellenar los valores para las opciones 1,2 y 3.

La opcion 1: No pide que indiquemos la ruta donde está el Windows XP. En mi caso la carpeta WINXPSETUP.
La opcion 2: Nos pide la letra que tiene asignado el PenDrive que vamos a usar para arrancar.
La opcion 3: Genera el PenDrive de arranque y copia todo lo necesario. Durante este proceso hay un momento que nos dice si queremos copiar XP + Extras. Le diremos que SI.

Paso 6: Un paso que se olvidan la mayoria de las guias es que al lanzar el proceso desde un Windows Vista (es mi caso) hay ficheros que no se copian. Por eso me he preparado un BAT que copia los ficheros que me faltan para dejar el Pendrive listo. Os los pego. En mi caso G es donde tengo el Windows XP y H es mi Pendrive.

copy G:\i386\si3112.sy_ H:\$WIN_NT$.~BT
copy G:\i386\SIREMFIL.SY_ H:\$WIN_NT$.~BT
copy G:\i386\SI3114R.SY_ H:\$WIN_NT$.~BT
copy G:\i386\KR10N.SY_ H:\$WIN_NT$.~BT
copy G:\i386\KR10I.SY_ H:\$WIN_NT$.~BT
copy G:\i386\NVRAID.SY_ H:\$WIN_NT$.~BT
copy G:\i386\NVATABUS.SY_ H:\$WIN_NT$.~BT
copy G:\i386\JRAID.SY_ H:\$WIN_NT$.~BT
copy G:\i386\JGOGO.SY_ H:\$WIN_NT$.~BT
copy G:\i386\JAHCI.SY_ H:\$WIN_NT$.~BT
copy G:\i386\ITERAID.SY_ H:\$WIN_NT$.~BT
copy G:\i386\IASTOR.SY_ H:\$WIN_NT$.~BT
copy G:\i386\VIAMRAID.SY_ H:\$WIN_NT$.~BT

Hasta aquí ya tenemos preparado el PenDrive. Ahora vamos a armarnos de paciencia y a instalar.

Paso 7: Pinchar el Pendrive. Entrar en la BIOS pulsando F2 y configurar El HD de arranque al Pendrive y tambien el Boot Order. guardar cambios y reiniciar.

Paso 8: Al arrancar en el menú de opciones escoger la opcion 1 (TXT....) a partir de aquí la instalación de Windows es la standad de toda la vida pero hay que tener en cuenta que cuando el XP quiera reiniciar HAY QUE FORZAR A QUE ARRANQUE DESDE EL PENDRIVE para continuar con la instalación y que cuando nos indique que ya ha terminado de copiar ficheros y que va a reiniciar, al reinciar (forzando el arranque desde el pendrive) debe usarse la opcion 2 del menu de arranque. Si despues de este caso vuelve a reiniciarse seguimos pulsando ESC para forzar el reinicio desde el Pendrive y seguiremos escogiendo la opcion 2.

Paso 9: Una vez termine la instalacion y aparezca la opción de logarnos con un usuario entramos en windows. Ya podemos apagar el PC y quitar el PenDrive. Windows deberia arrancar perfectamente.

Paso 10: Como que al arrancar aparecen 2 opciones en el menú (una haciendo referencia al recovery del Pendrive) para quitarlo basta con desde windows editar el Boot.ini de c:\ y eliminar la linea que haga referencia a la entrada del recovery. Ten en cuenta que el fichero estará oculto y será marcado como de sistema. Ahora solo falta que descargues los drivers de la pagina oficial de Asus y los instales.

Pues nada, creo que con esto ya está todo dicho. Para que podais comparar y entre toda la información obtener el exito aquí os dejo un link a una de las fuentes de informacion en las que me he basado:
- http://www.eeeguides.com/2007/11/installing-windows-xp-from-usb-thumb.html
- http://www.boot-land.net/forums/?showtopic=4900
- http://www.msfn.org/board/install-XP-USB-t111406.html&st=6

Cliente Vs Programador

Los informáticos tenemos la mala fama (aunque a veces merecida) de que cuando tenemos que hacer un programa a medida tendemos a hacer las cosas como nosotros parecemos que es mejor pasando totalmente de lo que el usuario nos ha pedido que haga ese programa. Creo que este chiste gráfico lo representa muy bien...

De aquí que cuando algún cliente nos pida un proyecto a medida lo que deberiamos hacer es sentarnos y hablar tranquilamente y el tiempo necesario sobre que es lo que el cliente necesita exactamente, no sobre lo que nosotros creemos que necesita.

12 señales para saber si eres un buen programador

El escrito original está en la pág web de Digg y el texo traducido se ha sacado de mundogeek
Lo espongo aquí porque también lo considero interesante.

1. Java es todo lo que necesitas.
No ves la necesidad de usar ningún otro lenguaje, ¿por qué no se puede hacer todo con Java? No te importa ver código en Python o Ruby que logra en 10 lineas lo que llevaría varias hojas de código Java. Además, seguramente las nuevas características de la próxima versión del lenguaje lo arreglaran de todas formas. (Esto es aplicable a casi cualquier lenguaje, pero ocurre que entre la comunidad Java parece estar más extendida esta forma de pensar)

2. El término "enterprisey" (NT: se trata de un término sarcástico utilizado para designar productos complejos más allá de lo necesario) no te suena a broma.
"Enterprise" no es sólo una palabra, es una filosofía, una forma de vida, un camino a la iluminación. Cualquier cosa que pueda ser escrita, desplegada o actualizada con un trabajo mínimo es descartada como un juguete que no "escalará" para futuros usos. Mientras tanto la mayor parte del trabajo real en tu oficina se hace enviando hojas de cálculo en Excel mientras esperan a que termines de construir tu nueva visión corporativa.

3.Te opones férreamente a las funciones/métodos de más de 20 líneas de código.
(o 30 o 10 o cualquier otro número) Lo siento, algunas veces una función larga es justamente lo que necesitas. Normalmente las funciones cortas son más sencillas de entender, pero algunas veces se pueden expresar más fácilmente en una sola función más larga. El código no debería hacerse más complejo sólo para adecuarse a criterios arbitrarios.

4. "¡OH DIOS MÍO! ¡PATRONES!"
Los desarrolladores que buscan constantemente la forma de aplicar patrones a cualquier problema de código con el que se encuentran están añadiendo una complejidad innecesaria. Lejos de ser algo que busques, deberías sentirte mal cada vez que tienes que utilizar un patrón de diseño, significa que estás escribiendo código que hace las cosas más complicadas y que puede ser de dudosa utilidad. Pero, ¡ey!, tu código tiene patrones, bien por ti.

5. Los ciclos de CPU son un recurso precioso y tu estilo de programación y lenguaje reflejan esas creencias.
Hay montones de problemas en los que tienes que tener muy en cuenta el consumo de CPU (modelado/simulación, procesado de señales, kernels de sistemas operativos, etc), pero no es tu caso. Para la mayor parte de los desarrolladores de software sus principales problemas de rendimiento están relacionados con las bases de datos y la entrada/salida. El único efecto de optimizar tu código para mejorar el uso de CPU será disminuir en 2 milisegundos el tiempo necesario para la próxima consulta a la base de datos. Mientras tanto el desarrollo de la aplicación se hace más lento, no puedes hacer frente a los nuevos requerimientos y te encuentras con problemas serios de calidad. Pero al menos estás ahorrándote montones de ciclos de CPU… eventualmente.

6. Piensas que ninguna función/método debería tener más de un return.
Esta la he oído alguna que otra vez, y normalmente la razón que me dan es que el código es más sencillo de analizar. ¿Según quién? Yo encuentro más fácil de leer un código más simple, y normalmente el tener más de un return simplifica el código.

7. Tus usuarios son estúpidos. Realmente estúpidos.
Simplemente no puedes creer lo estúpidos que son, olvidándose constantemente de hacer las cosas más sencillas del mundo y cometiendo errores tontos al usar tu aplicación. Nunca has considerado que quizás es tu aplicación la que es estúpida porque eres incapaz de escribir software decente.

8. Te enorgulleces enormemente del gran volumen de código que escribes.
Ser productivo es bueno, desafortunadamente escribir montones de líneas de código no es lo mismo que ser productivo. Los usuarios nunca comentan "Guau, este programa puede ser difícil de usar y estar lleno de errores, pero al menos sé que hay un montón de código por debajo." En lugar de ser productivo, generar toneladas de mal código retrasa a los demás desarrolladores y en el futuro su mantenimiento constituirá una pesada carga.

9. Copiar y pegar es genial, te ayuda a escribir código desacoplado.
Defiendes tu uso del copy paste con extraños argumentos sobre desacoplar código y eliminar dependencias, mientras ignoras el aumento del tiempo de mantenimiento y los problemas de duplicación de errores. A esto se le llama "racionalizar tus acciones".

10. Piensas que la gestión de errores consiste en capturar todas las excepciones, registrarlas, y continuar como si nada.
Eso no es gestionar errores, eso es ignorar errores y es el equivalente semántico al "on error next" de VB. Sólo porque hayas registrado el error en algún sitio no significa que lo estés tratando. Tratar errores es algo duro. Si no sabes qué hacer exactamente cuando te encuentras con un cierto error, simplemente deja que la excepción se propague y que un nivel más alto del código lo trate.

11. Modelas todo tu código en UML antes de escribirlo.
El modelado entusiasta de UML se lleva a cabo normalmente por aquellos que no escriben demasiado código, sino que se consideran arquitectos de software. Las herramientas de modelado atraen más a aquellos que piensan que el código se puede escribir en una sala de conferencias manipulando pequeños gráficos. Los gráficos no son el diseño, y nunca serán el diseño, para eso está el código.

12. Tu código borra datos importantes.
Escribiste un cierto código que se supone que debe sobrescribir los archivos de la aplicación con otros nuevos, pero se vuelve loco y borra todos los datos del usuario.

Windows ReadyBoost... mas RAM para el PC

Cuando era pequeño, yo como la mayoria de los niños, cuando recibia un regalo iba a todo correr a abrirlo. Lo que me diferenciaba del resto de los niños era que si el regalo llevaba un manual de instrucciones o de uso, me gustaba mirarmelo para ver que es lo que "habia de nuevo".
Bueno, pues eso es lo que me ha pasado con mi nuevo Pendrive, en particular con el modelo JetFlashV30 de 8Gigas. Leyendo las propiedades de este PenDrive el manual indica que es compatible con ReadyBoost, pero... ¿Que es ReadyBoost?

ReadyBoost es un nuevo concepto en cuanto a ampliación de memoria se refiere. La idea básica consiste en poder ampliar la memoria del PC usando un Pendrive. ¿Y como se consigue esto? Facil, el acceso a la memoria del pendrive es mucho más rápido que acceder fisicamente al disco duro por lo que los señores de Microsoft han hecho que en Windows Vista se pueda hacer precisamente esto, ampliar la memoria del ordenador pinchando un pendrive a un puerto usb aunque hay que puntualizar que la memoria que se añade pasa a formar parte de la memoria cache del windows en particular.

Vamos a ver como se activa esto. En mi caso como he dicho al principio he realizado las pruebas con un PenDrive de la casa Transcend, en particular con el modelo V30 de 8Gigas.

Lo primero que hay que hacer (lógicamente) es pinchar el PenDrive a un puerto usb. Una vez windows lo detecte y nos avise de que este está listo para trabajar.

Si no tenemos ninguna acción predeterminada para el dispositivo nos aparecerá la siguiente ventana donde vemos que tenemos la opción de "Aumentar la velocidad del sistema con Windows Ready Boost":



En nuestro caso, cancelamos esta ventana y nos vamos al Explorador de Windows y en el dispositivo correspondiente al pendrive hacemos click con el boton derecho-->propiedades. Debería aparecer una pantalla como esta:


Aquí están las opciones para configurarlo. Lo primero seria marcar "Usar este dispositivo" y lo segundo indicarle cuanto espacio del Pendrive dejamos que Windows use para la cache de sistema aunque por defecto el ya nos propone la cantidad que debería ser.

Hay que tener en cuenta que la memoria que se usa del PenDrive no aparece sumada a las propiedades del sistema.

Como último comentario, todo lo visto con respecto al PenDrive también se aplica a las targetas de memoria SD (Secure Digital).

YA.COM y su router Arcadyan AR4505

Hemos añadido la primera aplicación en descarga gratuita para todo el mundo. Se trata de ARFYR (Arcadyan Reset For YACOM Routers) que te premitirá evitar esos "cuelgues" del router Arcadyan AR4505 que YA.COM regala al darse de alta (si, ese que es como el de SMC pero que no lo es).

La aplicación la podreis encontrar en la sección de descargas (www.softproman.es) y aquí os dejo un pantallazo.

Gestor de metadatos

Estamos trabajando en una herramienta externa para agilizar las actualizaciones de los metados para las siguientes bases de datos: MYSQL y SQL SERVER.

Esta herramienta está pensada para facilitar y centralizar aquellas aplicaciones que tienen múltiples scripts para generar sus actualizaciones.

¿Existen TPVs para peluquerías?

Actualmente disponemos de un sencillo pero útil TPV (Terminal punto de venta) especializado en peluquerias. Este software, permite agilizar todas las gestiones típicas de este sector.

En un futuro próximo, sacaremos la nueva versión del TPV donde incorporará gran variadad de mejoras tanto en funcionalidad como de aspecto visual.

Actualmente utiliza como gestor de base de datos MySQL y en un futuro podrá soportar también las versiones de SQL Server.