Microsoft® Silverlight™ Tools para Visual Studio 2008 SP1 (RC1)

Para todos aquellos usuarios del Visual Studio 2008 en Español, ya esta libre para su descarga la versión en este idioma, aunque aun dice RC, esta para la fecha del 21 de Octubre. Este paquete es un complemento para Visual Studio 2008 SP1 con el que se proporcionan herramientas para Microsoft Silverlight 2. Se puede instalar sobre Visual Studio 2008 SP1 o Visual Web Developer 2008 Express con SP1 y proporciona un sistema de proyectos de Silverlight para desarrollar aplicaciones de Silverlight mediante C# o Visual Basic.

Descargar

Windows Live Tools para Visual Studio

Windows Live Tools para Microsoft Visual Studio 2008 es un conjunto de complementos para hacer la incorporación de los servicios de Windows Live en una aplicación Web de manera fácil que se implementan en Visual Studio 2008 y Visual Web Developer Express 2008.

Cuando instalamos este CTP de Windows Live Tools nos agrega seis controles que son:

Herramientas de desarrollo:

Descarga el CTP de Windows Live Tools para Visual Studio

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é?
    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:
    • 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:
    • 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.

Siempre acaba pagándola el más tonto...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?

Enlace: Top 10 Things That Annoy Programmers

Repair My Word

Repair My Word es un programa gratuito que te permite reparar archivos dañados de microsoft word. Esta diseñado para recuperar texto de archivos corruptos de archivos de word (.doc).

Entre los errores mas comunes de microsoft word están:

  • “The document name or path is not valid. Try these suggestions.
    Check the file permissions for the document or drive.
    Use the File Open dialog box to locate the document.”
  • “Word cannot open the document.”
  • “Word cannot open the document: user does not have access privileges.”

Para reparar archivos dañados de word simplemente ejecuta Repair My Word, abre el archivo dañado, previsualiza el texto recuperado y guardalo como un documento nuevo.

Repair My Word funciona en versiones de word 6.0, Word 95, 97 2000, XP y 2003

Descargar

 

Fuente : Web Adictos

Motorola también apuesta por Android

 

La expansión de Android a otros terminales es cuestión de tiempo. El primer asalto será mañana, cuando T-Mobile, HTC y Google pongan en manos del mundo su primer teléfono. La segunda parte del combate que juega Google llegará cuando otras marcas se interesen por su software. Según desvela Businessweek.com, la próxima compañía que aproveche el proyecto de Google será Motorola.

El proyecto es firme, puesto que Motorola ha mostrado imágenes del terminal y ha hecho públicas algunas características del teléfono, que contará con pantalla táctil. Businessweek.com asegura que el proyecto de Motorola estará disponible en el mercado para el segundo trimestre de 2009.

Una de las características que llaman más la atención será su adaptación a las redes sociales. La compañía espera facilitar el acceso a plataformas como Facebook o MySpace que cada vez son más utilizadas en los distintos dispositivos móviles.

Fuente : El Pais

Off-topic

Hola,

Hoy acabo de modificar algo el blog despues de más de un Mes sin actualizar el blog con mi ausencia por algunos problemillas pues estoy de nuevo aqui para seguir actualizando este humilde espacio espero que siga siendo de su agrado este sitio y disculparme por la poca atencion 😛 bueno no solo quiero hablar de mis problemas y mis dificultades les pienso recomendar un blog muy pero muy bueno

http://www.miguelmatas.es/blog/

Un excelente Blog se los recomiendo, estado leyendo casi todos sus articulos y son muy interesantes aptrones de diseño, programacion en capas, workflow y otros articulos que son de mucha ayuda en el desarrollo de una aplicacion algo mas tediosa.

Bueno me despido y si pueden apoyarme con el cafe 😛  se los agradesco

Saludos a Todos 🙂

Introducción a la Programación Web

La Universidad de Washington ha creado recientemente unos interesantes tutoriales de introducción a la programación web y tecnologías relacionadas, el Google Code University es un sitio gratuito que contiene clases, conferencias y ejemplos de programación de tecnologías como: AJAX, computación distribuida, seguridad web y los lenguajes web de programación.

Google Code University

Mitos de Computadoras

1. LE HACE MAL A LA COMPUTADORA TENER IMANES PEGADOS A LA TORRE.
FALSO. A la torre no le hace mal, pero al monitor sí, desgasta sus colores. Para comprobarlo basta acercar enfrente al monitor un desarmador que tenga iman en la punta y veran como los imanes que posee dentro hacen distorsión en los colores de la pantalla.

2. EMPUJAR EL CD CON EL DEDO PARA INSERTARLO EN LA TORRE ES DAÑINO.
FALSO. Nada sucede mientras se lo empuje con una fuerza normal. Está hecho para eso.

3. EL AGUA DERRAMADA SOBRE EL TECLADO PUEDE ARRUINAR SU FUNCIONAMIENTO.

VERDADERO. Se arruinan las pistas de metal que están debajo de las letras. Hacen cortocircuito y se queman.

4. ES NECESARIO QUE HAYA ESPACIO ENTRE EL MONITOR Y LA PARED DETRÁS DE ÉL.

FALSO. No es necesario. El ambiente en general debe estar ventilado, pero no es indispensable que sea mucha la distancia. Es peor tener otro monitor detrás (como sucede en muchas oficinas) porque se corre el riesgo de tener interferencias entre las computadoras.

5. CUANDO LA COMPUTADORA PASÓ TODA LA NOCHE ENCENDIDA ES MEJOR APAGARLA Y VOLVERLA A PRENDER, O REINICIARLA.

FALSO. Puede seguir funcionando perfectamente. Aunque parezca lo contrario (y den ganas de dejarla un rato apagada para que descanse, siguiendo la lógica humana), el disco duro se conserva más si permanece prendida y no es apagada una y otra vez. Por una cuestión de ahorro no conviene dejarla encendida por varios días, pero esquivando el factor económico podría permanecer en actividad todo el tiempo. Fueron creadas para ello.

6.GASTA MÁS ENERGÍA AL SER ENCENDIDA QUE EN VARIAS HORAS DE USO.

FALSO. Al encender no consume tanto como para superar las horas de funcionamiento. Si se apaga se ahorra energía y si permanece prendida gasta, como cualquier otro electrodoméstico.

7. LE HACE MAL A LA COMPUTADORA TENER EL CELULAR CERCA.

FALSO. No le hace daño, solo puede provocar interferencias.

8. LUEGO DE APAGAR LA COMPUTADORA ES MEJOR DEJARLA DESCANSAR UNOS SEGUNDOS ANTES DE VOLVER A PRENDERLA.

VERDADERO. Es recomendable esperar algunos segundos antes de volver a apretar el botón de encendido. Con 10 segundos es suficiente.

9. NO SE PUEDE MOVER LA TORRE CUANDO LA COMPUTADORA ESTÁ ENCENDIDA PORQUE PUEDE QUEMARSE EL DISCO DURO.

FALSO. Es tanta la fuerza centrífuga con la que gira el disco duro que no pasa nada si se mueve la torre. Mucho menos si se trata de una computadora portátil, porque están hechas para eso. Claro que nada de esto vale si se la golpea.

10. POR EL BIEN DEL MONITOR, ES CONVENIENTE USAR PROTECTOR DE PANTALLA CUANDO NO ESTÁ EN USO.

VERDADERO. Porque el mecanismo del protector de pantalla hace que el desgaste de los colores de la pantalla sea uniforme. Al estar renovando las imágenes constantemente, no se gasta en un mismo lugar.

11. CUANDO HAY TORMENTA, ES ABSOLUTAMENTE NECESARIO DESENCHUFAR LA COMPUTADORA.

VERDADERO. Es casi una obligación cuando se trata de una tormenta eléctrica. Una cantidad asombrosa de modems se rompen por descarga de rayos.

12. NO ES CONVENIENTE MIRAR LA LUZ ROJA QUE ESTÁ DEBAJO DEL MOUSE MODERNO.

VERDADERO. No va a dejar ciego a nadie, pero es una luz fuerte. Mucho más dañino es todavía el mouse con láser debajo, esa luz va directo a la retina del ojo.

13. EN LAS NOTEBOOK SE DEBE ENCHUFAR PRIMERO EL CABLE DE ELECTRICIDAD A LA MÁQUINA Y LUEGO ESE CABLE A TIERRA.

FALSO. Puede hacerse indistintamente. Si lo que se quiere evitar es que un cortocircuito afecte la computadora al enchufarla, es bueno saber que las fuentes de las portátiles son multivoltaje, soportan de 90 a 240 voltios, por lo que son sumamente estables.

14. SIEMPRE QUE SE APAGA LA COMPUTADORA CONVIENE APAGAR EL MONITOR.

FALSO. Al apagar la torre queda en un estado en el que consume muy poca energía y no sufre desgaste. La decisión termina siendo en función del ahorro, aunque lo que consume sea realmente mínimo.

15. NO SE DEBEN PONER CDS, DISQUETES O CUALQUIER OTRO ELEMENTO SOBRE LAS TORRES.

FALSO. Nada de lo que se coloque sobre ella la afecta, a menos que esté húmedo y el agua pueda llegar al equipo.

16. LA COMPUTADORA NUNCA PUEDE ESTAR AL SOL.

VERDADERO. Se recalienta más de lo que lo hace con el uso habitual y se acorta la vida útil del equipo.

17. SI ESTÁ LLENO MÁS DEL 80 % DEL DISCO DURO, SE ENLENTECE LA MÁQUINA.

VERDADERO. Siempre es una cuestión de porcentajes, por más que se tengan
10 GB libres, si eso es menos del 20 % de la capacidad del disco, el funcionamiento de la computadora será lento.

18. NO SE DEBE SACAR EL PEN DRIVE (PUERTO USB) SIN AVISARLE A LA MÁQUINA.

VERDADERO. Se debe seleccionar la opción para “retirarlo con seguridad” antes de desenchufarlo. De lo contrario, se corre el riesgo de quemar la memoria del USB.

19. TENER EL ESCRITORIO LLENO DE ÍCONOS ENLENTECE EL FUNCIONAMIENTO DE LA COMPUTADORA.

VERDADERO. Los que importan son los íconos de programas o archivos, los que son de acceso directo no molestan. Sucede que la tarjeta de video de la computadora renueva constantemente la información que se presenta en la pantalla y cuando hay más íconos, tarda más. Esto se nota más en computadoras más viejas o con tarjetas de sonido no muy grandes.

20. APAGAR LA MÁQUINA DESDE EL BOTÓN, SIN SELECCIONAR PREVIAMENTE LA OPCIÓN DE APAGADO DEL EQUIPO, DAÑA EL DISCO DURO.

VERDADERO. Si se le quita corriente al disco mientras está leyendo o escribiendo en alguna parte del sistema, se puede quemar. Además, cuando se apaga súbitamente, las placas que cubren al disco (que gira hasta 10 mil revoluciones) aterrizan sobre él y pueden ir picando hasta la posición de descanso, dejándole marcas importantes. Al seleccionar la opción “apagar el equipo”, todo el sistema se apronta para reposar y suspende las actividades. Cada pieza se ubica en su lugar.

SharpDevelop – IDE para .NET

Las características que nos gusta más …

* Formas de diseño para C #, VB.NET y Boo
* Código de terminación para C #, VB.NET y Boo (incluyendo Ctrl + Espacio de apoyo)
* Integrado NUnit apoyo más la cobertura de código (NCover)
* Integrado depurador
* Código de análisis de FxCop
* Refactorización apoyo
* Multi-marco de apoyo (. NET 1.1 y 2.0, Mono, Compact Framework)
* Edición de XML (fuente y vista en árbol), con XPath búsqueda
* Análisis basado en el código del convertidor (C # a VB.NET / Boo y más)
* Recopilar C #, VB.NET y Boo código en el IDE out-of-the-box
* Código AutoInsert (Alt + Ins)
* Xml una vista previa de la documentación
* Configuración de proyectos apoyados con Windows Installer XML (WIX)
* Integración de Subversion
* Open Source, bajo licencia LGPL

Y aquí hay algunas más … 

* Interfaz de usuario traducido a muchos idiomas
* Escriba C #, ASP.NET, ADO.NET, XML, el código HTML
* Proyecto o archivo basado en el desarrollo (Proyecto Scout y Scout de archivo)
* Ricos opciones de proyecto
* Resaltado de sintaxis para C #, HTML, ASP, ASP.NET, VBScript, VB.NET, XML
* Inteligente tirantes
* Plegable
* El código de favoritos
* Código de plantilla de apoyo
* Componente de Inspector
* Feature-rich Buscar y reemplazar los cuadros de diálogo (incluyendo la búsqueda incremental)
* Fácilmente extensible con herramientas externas
* Fácilmente ampliable con Plug-Ins
* Re-anfitrión con SharpDevelop SDA
* … y mucho más

Si muchos ya tendran ganas de probar esta IDE asi que vallan a la pagina de descarga AQUI haber que tal

Saludos. 8)

Examen Reprobado

Valla yo cuantos exámenes entrege en blanco, uffff ni contarlos hay veces que uno no estudia jajá y creo que al próximo examen pondré un código similar esta buenísimo ese Code  me causo mucha gracia así que les comparto la imagen P