De todos es sabido que cuanto antes se solucione un problema en un proyecto de desarrollo de software, menos coste tiene para el mismo y de ello salen beneficiados tanto proveedor como cliente.

Por ese motivo resulta esencial que un proyecto sea sólido desde la base, siendo la misma el análisis funcional, lo que hace que sea muy importante la figura del analista que es la persona o grupo de personas (si el proyecto es grande) que se tienen que encargar de entender, interpretar y traducir lo que el usuario demanda, sentando las bases de los posteriores procesos de diseño y construcción del sistema de información.

Hacer un buen análisis es una tarea bastante compleja, ya que resulta muy complicado obtener todos los requerimientos del usuario desde etapas muy tempranas, ya que por regla general el usuario empieza a descubrir el detalle de todo lo que quiere cuando empieza a utilizar el producto ya construido con ejemplos reales de su día a día de trabajo (también suelen comentar nuevos requisitos o enmendar requisitos previos, en otras etapas conforme se le vaya presentando la evolución del proyecto, de hecho no es malo que se corrijan, ya que cuanto más avanzado esté el proyecto, el esfuerzo de hacer los cambios es mucho mayor). De hecho es prácticamente inevitable no hacer evolutivos que solventen esos flecos que no se detectaron en análisis para dejar el producto lo más próximo posible a lo que los usuarios necesitan y demandan. Como consecuencia de lo anterior, y como es lógico, se puede considerar que un análisis funcional es más bueno conforme sea menor el número de ajustes que haya que hacer en etapas posteriores del proyecto.

Es importante matizar que un proyecto de desarrollo de software no es una barra libre y que es importante que el usuario conozca sus responsabilidades en el proceso de definición del sistema y que no se pueden estar cambiando de requisitos continuamente, como tampoco podría estar cambiando frecuentemente de opinión si le están construyendo una casa. Todo lo anterior además hay que compatibilizarlo con que todas las partes están interesadas en el que el proyecto vaya a buen término, por lo que tampoco es una buena política ser inflexibles en la modificación del catálogo de requisitos, porque si el resultado final no es el que quiere el usuario, el sistema de información tendrá muchas papeletas para no ser utilizado. Equilibrio complicado: evitar que los usuarios modifiquen continuamente requisitos y tener un poco de mano izquierda cuando se planteen esos cambios. Como ese equilibrio es complicado de mantener y es fuente frecuente de conflictos, hay que intentar que el análisis tenga la mayor calidad posible.

Hacer un análisis funcional por tanto es una tarea compleja, a lo que hay que sumar que en muchos casos hay que aprender mucho sobre el proceso de negocio que se pretende informatizar, para entender de mejor manera lo que el usuario demanda, ya que resulta todo más fácil si el lenguaje que se utiliza es el mismo. En muchas ocasiones esos procesos de negocio son tremendamente complejos y además se dispone también de poco tiempo para entenderlos, teniendo en cuenta que por regla general y como he comentado muchas veces en mi blog, los proyectos informáticos suelen estar infravalorados (por el que contrata y/o por el que es contratado (para conseguir el contrato)).

Dado que el análisis funcional consiste en abstraer un conjunto de necesidades de los usuarios es muy importante la implicación de los mismos y eso no siempre se consigue. Si los usuarios no están implicados, por muy buen analista funcional que tenga el proyecto, las probabilidades de que este salga mal crecen exponencialmente. Evidentemente un buen analista puede paliar esos huecos que deja el usuario e incluso conseguir una mayor participación de los usuarios, pero más tarde o más temprano los problemas aparecerán y al final siempre termina pagando el proyecto (en primera instancia) y el que lo desarrolla (en segunda). Por todo lo anterior, se puede pedir que un analista funcional aprenda un proceso de negocio complejo, que consiga extraer de los usuarios lo que buscan y necesitan y que además lo haga en un tiempo record, pero lo que no se le puede pedir es que haga magia y resuelva problemáticas que le trascienden, como el caso que he comentado de la inacción de los usuarios en determinados proyectos, siendo esa falta la implicación la primera causa de que un análisis no salga bien y por tanto una de las causas más importantes del fracaso de un proyecto y no se trata en este caso de tirar pelotas fuera y ponerme del lado de mis colegas de profesión, se trata de algo que he podido vivir en diferentes proyectos de manera muy directa.

Nadie es infalible y un analista funcional tampoco lo es. Habrá errores (independientemente de que la causa de los mismos sea provocada por circunstancias adversas en el proyecto o no), puede que en este proyecto sean muy pocos y que en otros sean mayores, por eso es importante que el analista lo tenga asumido desde un principio, como también lo es que de esos errores se debe aprender y que resultarán fundamentales en la formación del mismo. Al final esos errores terminan curtiendo y permiten que cada vez los análisis que se realicen sean mejores. Por tanto, la experiencia resulta importante. En cualquier caso, suponer un análisis perfecto es suponer que en un proyecto se dan circunstancias ideales y que todas las variables que pueden influir en que las cosas vayan mejor o peor, están todas a favor.

De todo lo comentado en los párrafos anteriores se extrae que es importante que un analista funcional sea un buen comunicador, primero con el usuario ya que resulta fundamental que el usuario conozca todo lo que hemos entendido y cómo se pretende llevar a cabo (no conseguir eso es ir a ciegas) y segundo con el equipo de proyecto ya que tiene que trasladar a documentación y hacerles entender la interpretación de lo que el usuario quiere y cómo lo quiere.

Un buen análisis funcional no asegura el éxito del proyecto, ya que la ejecución técnica del mismo también tiene un peso importante, pero lo que sí es seguro es que si el análisis funcional no es bueno, la ejecución técnica difícilmente puede salvar las deficiencias del mismo y tocará corregir el producto una vez construido y además, por regla general, en diferentes evoluciones, lo cual es muy costoso y tampoco asegura que ese árbol que empezó torcido, termine por enderezarse.

Otra semana más se acerca el domingo, que desde hace unos meses se ha vuelto el día mas importante de la semana para muchos vecinos de Fuente de Piedra ya que dos de nuestros vecinos están participando en Pekin Express, un programa de televisión.

Somos muchos los que estamos animandolos y ellos nos corresponden con su buen hacer en esta aventura, esta semana es muy importante en el concurso ya que están en semifinales y este domingo se juegan el pase a la final.  Todos queremos que estén en ella y por eso desde Guadalinfo Fuente de Piedra les animamos y animamos a que todos vosotros les animéis a través de la página web oficial de cuatr, os dejo el enlace mas abajo para que le escribaís un mensaje de animo..

http://www.cuatro.com/pekin-express/concursantes/segunda-temporada/carmela-y-antonio

Saludos…

A partir de ahora podremos saber el recorrido de nuestros ojos cuando miramos, durante los primeros 5 segundos, a una web, gráfica, fotografía…
Gracias a una web creada a partir de un estudio de inteligencia artificial que detalla el orden que nuestra mirada recorre al observar algo.
El site se llama Feng-Gui y permite subir un pantallazo de tu site, blog… y comprobar el recorrido que hacen los ojos de los lectores.
Aquí tenéis la prueba del blog publired:

Experimento Publired

Continuación de la primera parte (http://pymeslatam.wordpress.com/2009/11/17/10-pautas-y-consejos-utiles-para-el-diseno-de-paginas-web-parte-1/)

6. El mejor color para los enlaces es el azul

El tener un diseño único en su sitio web está muy bien, pero, cuando se trata de usabilidad, lo mejor es hacer lo mismo que los otros (sobre todo cuando los otros son los sitios más visitados y exitosos).

Siga los convencionalismos, porque cuando la gente visita un nuevo sitio web, el primer lugar donde buscan las cosas es en los lugares donde las ha encontrado en los sitios que visita habitualmente. Esto se conoce como patrones de uso. La gente espera que ciertas cosas sean de la misma manera, tales como colores de los enlaces, la ubicación del logo de la web, el comportamiento de la navegación por pestañas, etc.

Fuente: http://www.googlelabs.com/

Google mantiene todos los enlaces de sus sitios web en color azul por una razón: el color es familiar para la mayoría de los usuarios, lo que hace que sea fácil de localizar.

¿De qué color deben ser los vínculos? La primera consideración es el contraste: los vínculos tienen que ser oscuros (o claros, según sea el caso) lo suficiente como para contrastar con el color de fondo. En segundo lugar, deben destacarse del resto del texto, no debe haber enlaces negros con texto en negro. Y, por último, la investigación muestra (Van Schaik y Ling) que si la usabilidad es su prioridad, lo mejor es elegir el azul para los enlaces. El color del navegador de enlace por defecto es de color azul, la gente espera esto. Puede elegirse un color diferente pero afectará de alguna forma a la velocidad con la que los usuarios lo encuentren y lo sigan.

7. La mayoría de los usuarios ignoran la publicidad

Jakob Nielsen reporta en los informes de AlertBox que la mayoría de los usuarios son prácticamente ciegos a los banners publicitarios. Si están buscando información en una página o están concentrados en el contenido, no se distraerán lo más mínimo con los anuncios en la parte lateral.

La implicación de esto no sólo es que los usuarios evitarán los anuncios, sino que evitarán cualquier cosa que se parezca a un anuncio, aunque no lo sea. Algunos elementos de navegación muy estilizados pueden parecer banners, así que tenga cuidado con estos elementos.

Fuente: http://activeden.net/

Los banners cuadrados en la barra lateral izquierda de FlashDen no son anuncios en realidad: son los enlaces de contenido pero resultan muy parecidos a banners publicitarios y, por esta razón, podrían llegar a ser ignorados por algunos usuarios.

También ocurre el efecto contrario, los anuncios que parecen contenido resultan más fáciles de ver y de seguir. Esto puede generar más ingresos, pero el costo es la confianza de sus usuarios, ya que ellos hacen clic en lo que creían eran contenidos genuinos, siendo de alguna forma “engañados”. Antes de ir por ese camino, tenga en cuenta el equilibrio: los ingresos a corto plazo frente a la confianza a largo plazo.

8. Las etiquetas de los formularios funcionan mejor si están encima de los campos

Un estudio realizado por UX Matters ha encontrado que la posición ideal para las etiquetas en los formularios es encima de los campos. y no como aparece en muchos formularios, donde las etiquetas se sitúan a la izquierda de los campos. ¿Por qué sucede esto? porque los formularios son, en general, de orientación vertical, es decir, los usuarios deben completar los formulario de arriba a abajo. Los usuarios pueden seguir el formulario hacia abajo a medida que avanzan e ir siguiendo la etiqueta para el campo de abajo es más fácil que encontrar la etiqueta y el campo a la derecha.

Fuente: http://www.tumblr.com/

Tumblr utiliza un simple y elegante formulario de inscripción que se apega a la recomendación de UX Matters.

9. El largo ideal de un cuadro de búsqueda es de 27 caracteres

¿Cuál es el largo ideal de un cuadro de búsqueda? ¿Existe tal cosa? Jakob Nielsen realizó un estudio sobre la longitud de las consultas de los cuadros de búsqueda de los sitios web (dando prioridad a la utilidad). Resulta que la mayoría de los cuadros de búsqueda hoy en día son demasiado cortos. El problema con los cuadros de búsqueda cortos es que a pesar de que se puede escribir una consulta larga en ellos, sólo una parte del texto será visible, lo que hace difícil revisar o editar lo que se ha escrito.

El mismo estudio encontró que un cuadro de búsqueda promedio es de 18-caracteres de largo. Se demostró que el 27% de las consultas eran demasiado largas para caber en él. Si se amplía el cuadro a 27 caracteres, se daría cabida al 90% de las consultas.

El cuadro de búsqueda de Google es lo suficientemente amplio como para dar cabida a frases largas.

Fuente: http://www.apple.com

El cuadro de búsqueda de Apple es un poco corto, cortando la consulta, “Microsoft Office 2008.”

En general, los cuadros de búsqueda amplios son mejores que los cortos, de modo que los usuarios pueden rápidamente examinar, verificar y mandar la consulta. Esta pauta es muy simple, pero por desgracia a menudo rechazada o ignorada.

10. Si realiza test de usuarios, no es necesario molestar a mucha gente

El estudio de Jakob Nielsen sobre el número ideal de sujetos en las pruebas de utilidad encontró que con cinco usuarios se  muestra alrededor del 85% de todos los problemas con su sitio web, mientras que con 15 usuarios se encuentran casi todos los problemas.

Fuente: Jakob Nielsen’s Alertbox

La mayor parte de los problemas suelen ser descubiertos por los primeros dos usuarios, los siguientes usuarios confirman estos problemas y descubren los detalles  restantes de menor importancia. Es probable que sólo dos usuarios de prueba encuentren la mitad de los problemas en su sitio web. Esto significa que la prueba no tiene que ser amplia o muy costosa para obtener buenos resultados. Las mayores ganancias se obtienen cuando se va de cero usuarios de prueba a uno, así que no tenga miedo de hacerlas: hacer pruebas es mejor que no hacer nada.

Documento de interés:  http://www.slideshare.net/doyournet

Fuente del Documento:

http://www.smashingmagazine.com/2009/09/24/10-useful-usability-findings-and-guidelines/

Nos distinguimos por apoyar a nuestros usuarios en todas sus necesidades informativas. Búsqueda de libros personalizada, ayuda en el uso de Internet, notificación telefónica de reservas. Estamos especializados en búsqueda de oposiciones.

Somos una biblioteca pequeñita pero con mucha información. Estamos dispuestos  a ayudarte en tus necesidades de conocimiento.

Tras leer una noticia del periódico Publico en la que se cuenta que Google libera el código de su sistema operativo Chrome OS me da la impresión de que google pretende con ello ganar adeptos por que se da cuenta de que cada vez es más la gente que utiliza el software libre.

En los comentarios de dicha noticia se puede apreciar como cada vez que sale una noticia de este tipo, las diferencias entre las personas que estas a favor del software libre y las que están a favor del software privativo.

También se puede leer que todavía hay mucha gente que no conoce lo que quiere decir software libre, creen que este tiene que ser gratuito y esto no tiene por que ser así. El software libre viene del ingles Free Software, entendiendo el free como libre, no como gratuito. Con este “libre” se quiere decir que ese programa o sistema operativo puede ser copiado, modificado y redistribuido en las mismas condiciones en las que te llegó a ti, sin tener que dar explicaciones a nadie.

Me quiero detener en una apreciación, una de las preguntas que se hacen muchos usuarios de ordenadores. ¿Se puede utilizar Software Libre en Windows?. La respuesta es sí, hay muchos programas de software libre que están preparados para poder utilizarse en windows sin ningún problema, es más yo recomiendo utilizar este tipo de programas y no los programas piratas que todo el mundo utiliza. A la larga seguro que dan problemas.

Sin mas me despido hasta la próxima esperando haber resuelto algunas dudas sobre este tema.

El plugin Authlogic (de BinaryLogic) es un excelente recurso a la hora de facilitar la autenticación de usuarios en nuestros sitios web. Se caracteriza por ser muy fácil de configurar, utilizar y extender (existen otros plugins que le agregan funcionalidad, como Lockdown). Por supuesto, tiene un muy buen nivel de seguridad y muchas funcionalidades extremadamente útiles que, de hacerlas a mano, nos tomaría mucho tiempo implementar.

Este tutorial está basado en el sitio de ejemplo oficial de Authlogic, en GitHub.

1- Instalación

Authlogic se puede instalar como gem o como plugin.

A) Para instalar como plugin (recomendado por ellos mismos):

$ ./script/plugin install git://github.com/binarylogic/authlogic.git

B) Para instalar como gem, basta agregar lo siguiente a environment.rb

# config/environment.rb
config.gem "authlogic"

Luego, ejecutar en la consola (si usás linux quizás necesites correrlo con sudo):

rake gems:install

2- Crear el modelo UserSession

El modelo UserSession es aquel que se va a encargar de administrar todo lo que tiene que ver con una sesión en nuestro sitio: su creación (login), su actualización, y su destrucción (logout). Como ellos mismos comentan en su sitio de ejemplo, de la misma forma que ActiveRecord se sitúa entre nosotros y la base de datos, el modelo UserSession se situá entre nosotros y las cookies del usuario.

Asumiendo que lo que queremos autenticar es un modelo nombrado User, vamos a crear nuestro modelo UserSession. En la consola:

script/generate session user_session

Esto va a crear un archivo similar al siguiente:

#app/models/user_session.rb
class UserSession < Authlogic::Session::Base
  # aquí va la configuración
end

Es importante destacar que este modelo hereda de Authlogic::Session::Base, lo cual nos permitirá configurarlo muy fácilmente. Por ejemplo, es aquí donde podemos proteger a nuestros usuarios de ataques de fuerza bruta. Para más información, ver la documentación de los submódulos de Authlogic::Session.

3- Crear el modelo User

El modelo User es el modelo que guarda la información de registro de los usuarios. Se pueden incluir todos los campos que sean necesarios para nuestra aplicación, pero existen algunos campos que Authlogic administra de forma automática, facilitando muchísimo nuestro trabajo. Pero primero, creemos el modelo: en la consola,

script/generate model user login:string crypted_password:string

Authlogic utilizará este modelo para autenticar. El tutorial oficial (en inglés) incluye una lista que muestra cuáles son los campos administrados por Authlogic. Todos los campos son opcionales excepto el que se utiliza para que la sesión persista: persistence_token. Para este tutorial utilizaremos una combinación de nombre de usuario y contraseña para autenticar. Como fueron especificados como parámetros, ambos campos (login y crypted_password, respectivamente) fueron añadidos automáticamente por Rails a nuestro archivo de migración cuando corrimos el generador anterior. Por lo tanto, podemos directamente ejecutar rake db:migrate para crear la tabla users junto con dichos campos en nuestra base de datos.

4- Configurar el modelo

Configurar el modelo es extremadamente simple:

class User < ActiveRecord::Base
  acts_as_authentic do |c|
    c.opcion = valor # ver documentación
  end # el bloque es opcional
end

A partir de ahora el modelo intentará validar automáticamente los campos nombre de usuario, email, contraseña, etc. La configuración en bloque nos permite personalizar cómo queremos que se validen esos campos, definir nombres distintos para los campos o incluso cambiar el algoritmo de encriptación para la contraseña.

5- Crear el Controlador para UserSessions

Es a través de este controlador que el usuario iniciará y cerrará su sesión. Es importante aclarar que este controlador no debería ser usado para registrar usuarios u otras acciones similares que tienen que ver con la administración de usuarios; lo utilizaremos simplemente para iniciar o cerrar sesión. En la consola:

script/generate controller user_sessions

Aquí hay un ejemplo del contenido básico de un controlador de UserSessions. También existen ejemplos paras las vistas correspondientes. Sin cambiar lo básico, podemos agregar toda la funcionalidad que queramos, tanto a las vistas como al controlador.

En cuanto a las rutas, hace falta conectar el modelo UserSession con el controlador. Para lograrlo:

#config/routes.rb
map.resource :user_session

6- Persistiendo Sesiones

Para persistir sesiones utilizaremos el ApplicationController. Agregaremos algunos métodos al controlador y a dos de ellos los convertiremos en métodos helper, para poder accederlos desde las vistas. Estos métodos fueron extraídos del sitio ejemplo, son simplemente ilustrativos y pueden ser personalizados según la necesidad.

# app/controllers/application.rb
class ApplicationController < ActionController::Base
  helper :all
  filter_parameter_logging :password, :password_confirmation
  helper_method :current_user_session, :current_user

  private
  def current_user_session
    return @current_user_session if defined?(@current_user_session)
    @current_user_session = UserSession.find
  end

  def current_user
  return @current_user if defined?(@current_user)
    @current_user = current_user_session && current_user_session.user
  end

  def require_user
     unless current_user
       store_location
       flash[:notice] = "You must be logged in to access this page"
       redirect_to new_user_session_url
       return false
     end
   end

   def require_no_user
     if current_user
       store_location
       flash[:notice] = "You must be logged out to access this page"
       redirect_to account_url
       return false
     end
   end

   def store_location
     session[:return_to] = request.request_uri
   end

   def redirect_back_or_default(default)
     redirect_to(session[:return_to] || default)
     session[:return_to] = nil
   end
end

Ahora tendremos acceso al usuario y su sesión en toda nuestra aplicación, con sólo llamar a current_user y current_user_session, respectivamente.

7- Restringiendo Acceso

Authlogic se encarga simplemente de la autenticación, pero nos permite restringir acceso en nuestros controladores de forma muy fácil. Lo podemos hacer a mano o utilizando algún otro plugin que agregue esta funcionalidad. Lockdown es un plugin muy bueno que permite restringir acceso según los roles que tenga un usuario, y se integra de forma excelente con Authlogic.

Sin embargo, aquí incluiremos un ejemplo muy simple de cómo restringir acceso manualmente dentro de uno de nuestros controladores. En nuestro ApplicationControler:

# app/controllers/application.rb
class ApplicationController < ActionController::Base

  #... (código anterior)

  def require_user
     unless current_user
       store_location
       flash[:notice] = "You must be logged in to access this page"
       redirect_to new_user_session_url
       return false
     end
   end

   def require_no_user
     if current_user
       store_location
       flash[:notice] = "You must be logged out to access this page"
       redirect_to account_url
       return false
     end
   end

   def store_location
     session[:return_to] = request.request_uri
   end

   def redirect_back_or_default(default)
     redirect_to(session[:return_to] || default)
     session[:return_to] = nil
   end
end

Y luego utilizamos estos nuevo métodos en nuestros controladores. Por ejemplo, si queremos que una lista de productos pueda ser vista por cualquier persona, pero que sólo usuarios logueados puedan administrarla (crear productos, actualizarlos, borrarlos, etc.), hacemos lo siguiente en nuestro ProductsController (asumiendo que existe):

# app/controllers/products_controller.rb
class ProductsController < ActionController::Base
  before_filter :require_user, :except => [:index, :show]

  #GET /products/new
  def new
    #...
  end

  # ... (resto del código)
end

De esta forma, si una visita intenta añadir un producto accediendo a “sitio.com/products/new”, será redirigida automáticamente al formulario de login para que se identifique con su usuario antes de poder continuar. Esta lógica se encuentra en el ApplicationController, dentro del método require_user.

8- Registrando Usuarios

Registrar usuarios es muy simple con Authlogic. De hecho, funciona exactamente igual que si no lo usáramos, siempre y cuando utilicemos las acciones CRUD estándar. Esto es debido a que Authlogic se inyecta automáticamente en el modelo, y por lo tanto no nos tenemos que preocupar en absoluto de nada que tenga que ver con lógica que hay detrás de registrar un usuario. Es más, tampoco es necesario preocuparnos de encriptar la contraseña antes de almacenarla en la base de datos. Authlogic se encarga de todo. Y si lo que buscamos es un poco más avanzado, Authlogic es muy fácil de configurar y extender (ver la documentación).

9- Próximos Pasos

La gente de BinaryLogic incluye una lista de próximos pasos que pueden o no ser implementados. Todos remiten a una sección en particular dentro de la documentación de Authlogic. Aquí la incluyo traducida:

1. Querés usar otro algoritmo de encriptación, como BCrypt? Ver Authlogic::ActsAsAuthentic::Password::Config
2. Migrando de autenticación REST? Ver Authlogic::ActsAsAuthentic::RestfulAuthentication::Config
3. Querés que las sesiones expiren automáticamente después de un período de inactividad? Ver Authlogic::Session::Timeout
4. Necesitás restringir tus sesiones a una cuenta o modelo en particular? Ver Authlogic::AuthenticatesMany
5. Necesitás muchos tipos diferentes de sesiones? Ver Authlogic::Session::Id
6. Querés permitir que los usuarios reestablezcan sus contraseñas o confirmen su subscripción? Utilize una clave de expiración automática. Ver Authlogic::ActsAsAuthentic::PerishableToken
7. Querés dar acceso privado a una API o canal RSS? Utilice autenticación básica por HTTP o por parámetros. Ver Authlogic::Session::HttpAuth o Authlogic::Session::Params
8. Necesitás ayuda con tus pruebas? Consulta Authlogic::TestCase

Créditos

Este tutorial está estructuralmente basado en el tutorial oficial de Authlogic (en inglés). Mucho del código lo extraje de allí directamente, aunque me tomé libertades en cuanto a su presentación y en algunos casos le cambié en formas que me parecieron más convenientes.

Si este tutorial fue de provecho, no dudes en comentar! Lo mismo si encontraste errores o quisieras dar alguna sugerencia.

También podés subscribirte al feed para mantenerte al tanto de los artículos más frescos.

El nuevo sistema operativo Windows 7 permite un mayor control sobre cómo se utilizan sus recursos. Entre otras cosas es posible controlar cómo algunos usuarios acceden al sistema e incluso impedirles ciertas acciones. La aplicación PC Safeguard (ahora incorporada al sistema operativo) permite a los usuarios que determinemos que hagan el uso que quieran del sistema, pero una vez hayan terminado la sesión no queda rastro de ella.

Ni archivos en el disco, ni programas instalados ni cambios en los archivos de configuración de los programas o el sistema.

Para utilizar este sistema hay que abrir el Menú de inicio y acceder a Control Panel. Luego haremos clic sobreUser Accounts and Family Safety luego en User Accounts, Manage Another Account y finalmente Create a new account. Introducimos el nombre para el nuevo usuario y haremos clic en Create. Una vez creada la cuenta, haremos clic sobre ella, elegiremos Set Up Safeguard luego sobre Turn on PC Safeguard. También podemos impedir el acceso a determinados discos duros haciendo clic en Lock Hard Drives. Finalmente haremos clic sobre Apply. Esa cuenta de usuario tal y como está creada ya no permite realizar ningún cambio ni en el sistema ni en los discos.

Youtube no deja de innovar en publicidad online y se está convirtiendo en un formato de gran relevancia.

Primero, nos sorprende con un nuevo formato denominado “Unidad de cabecera tándem”; se trata de un vídeo que aparecerá en la página principal de la plataforma y que el usuario tendrá la opción de visionar o no cuando quiera. En España, el primer anuncio se trata de Telefónica para promocionar su nueva tarifa plana de Internet para móviles.

Ver  Telefónica

Y después, youtube nos deleita con otra forma de llamar la atención al usuario, mediante la integración del vídeo en el entorno, o la autodestrucción. En este caso, ha sido Acciona con su campaña Re-acciona y Canal +.

Ver Re-Acciona

Linux ya es casi conocido por todos y sus diferencias con Windows, la forma de administrar los usuarios no es una excepción, si creamos un usuario por el asistente puede parecer que los administra del mismo modo, pero si creamos uno a mano veremos que no tiene nada que ver.

En todo sistema que sea de tamaño mediano a grande, es necesario tener una division de las responsabilidades, esto se puede lograr a traves de capas lógicas, que no necesariamente son capas fisicas.

¿La Diferencia?, En realidad no estoy muy seguro si estos sean los terminos correctos, pero yo los he denominado asi por que tuve un cliente que me hizo la siguiente pregunta: ¿Cuantas capas tiene el sistema? obviamente mi pregunta fue 4 capas: Interfaz de Usuario, Reglas de Negocio, Entidades, Acceso a Datos; pero luego de una revisión el llego a la conclusión de que solo teniamos 2 capas.

¿Cual fue la diferencia?, en realidad es simple, estas 4 capas en las que dividimos la aplicación cuando las compilamos para luego implantarlas, se quedo en el siguiente esquema: los ejecutables (cliente) y la Base de datos (servidor).

Entonces para el usuario, solo teniamos 2 capas y no 4 como le habiamos dicho, fue aca donde pense cual seria el término correcto para poder explicarle al usuario que habia una diferencia entre lo que nosotros habiamos programado y como se veia una vez implantado pero (seguro que esto ya lo saben) el usuario era un cabezota que no entendia lo que se le explicaba (en realidad hablaba en chino para él), asi que quedamos en que ambos conceptos eran diferentes y decidi llamarlos Lógico y Fisico.

El diseño Lógico es el esquema de como hacemos la programación por ejemplo crear capas que luego se convertiran en DLLs, para que contengan una gran responsabilidad del proyecto.

El diseño Fisico es el esquema de como se va a implementar esta solución es decir que archivos iran a la parte cliente y que archivos iran al servidor. A primera vista pareciera que siempre van a ser 2, es decir el Cliente y el Servidor, pero esto puede cambiarse, por ejemplo en una aplicación WEB (que a esto va el MVC), no interactuan 2 equipos en realidad deberian de interactuar minimo 3, el Cliente, el Servidor y la Base de Datos, ahora podriamos implementar la logica del negocio como un SOA a fin de poder reutilizar los componentes, entonces fisicamente tendriamos 4 capas, y asi sucesivamente.

A veces es una frustración ver como el usuario conceptualiza las cosas, pero esto nos debe dar una mejor perspectiva para explicarle algunos temas, ya que muchas veces hablamos en chino con el usuario.

 En una migración de Exchange 2003 a 2007, no solo hay que migrar los buzones. También hay que adaptar o reconvertir determinados objetos para que sean accesibles desde la nueva versión. De entre los objetos creados con una versión Legacy (2003) que hay que convertir a 2007, destacan las listas de direcciones (GAL) del site, ya sean las creadas por defecto  o manualmente; y las políticas o directivas de destinatarios (E-mail Address Policies).

Listas de Direcciones:

Accederemos desde “Organization Configuration/Mailbox/Address List”. De todas las listas que se nos muestran, veremos que todas, a excepción de “All Rooms” son inaccesibles, presentando el siguiente mensaje al intentar acceder:
“The specified Address list could not be edited. Addres lists created by using a legacy version of Microsoft Exchange must be upgraded by using the “ForceUpgrade” parameter of the “Set-AddresList” cmdlet.” 

El hecho de que al acceder a “All Rooms” no nos de este error es porque esta lista es nativa de 2007 y se ha creado con esta nueva versión. El resto, son heredadas de 2003 y, por tanto, inaccesibles desde 2007. Para saber las versiones de cada una de las listas, tenemos que ejecutar el siguiente comando desde la Shell de 2007:

Get-AddressList | Format-List Name,AllRecipients,ExchangeVersion

Esto nos devolverá una pantalla similar a esta:

Esta pantalla nos indica si el objeto pertenece a la versión de Exchange 2003 (versión 0.0) o bien a la de Exchange 2007 (versión 0.1).
 

A continuación nos interesa convertir la lista de “Todos los usuarios” a la versión de 2007. Lo haremos ejecutando:

Set-Addresslist “Todos los Usuarios” -IncludedRecipients AllRecipients

Nos preguntará si estamos seguros, y tendremos que confirmar [y].

Ahora podemos volver a ejecutar el comando inicial para comprobar de nuevo las versiones. Veremos que la lista de “Todos los usuarios” se ha actualizado a la versión 0.1 (Exchange 2007), por tanto este objeto ya es accesible y editable desde el snap-in de Exchange 2007.

Políticas de Destinatario (E-mail Address Policies):

Para acceder a las políticas, nos dirigiremos hacia “Organization Configuration/Hub Transport/E-mail Address Policies”. Ahí se nos mostrará la política por defecto (Default Policy) además de las que hayamos creado.  Paver ver las versiones de cada política existente, ejecutaremos desde la  Shell: 

Get-EmailAddressPolicy | Format-List Name,*RecipientFilter*,ExchangeVersion

Para convertir una política determinada a versión compatible 2007:

Set-EmailAddressPolicy “Default Policy” -IncludedRecipients AllRecipients

En donde “Default Policy” es el nombre de la política a modificar. Como en el caso de las listas de direcciones, se aconseja volver a ejecutar el comando que muestra las versiones tras haber realizado los cambios y apreciar así las modificaciones.

MSDE sólo puede manejar alrededor de 200-250 usuarios con BlackBerry Enterprise Server. 
Aunque oficialmente de Microsoft sobre el papel indica que son 500, pero de acuerdo con el personal de apoyo de BlackBerry es sólo 200-250 y a partir de ahí empiezan los retrasos con el correo electrónico de su servidor al  BlackBerry.

La solución pasa por migrar de MSDN a Sql Server, y los pasos son:
 1.  Crear el usuario administrador BES en SQL Server.
 2.  Ejecutar la herramienta createdb.exe, por lo que crea la base de datos SQL (se necesitará hacer esto desde el CD de instalación de BES).
 3.  Conceder al usuario admin BES derechos dbo y public.
 4.  Detener los servicios en el servidor BES.
 5.  Copia de seguridad de la base de datos utilizando osql-E en la línea de comandos.
 6.  Restaurar la base de datos a la base de datos SQL que fue creada por la herramienta de createdb.
 7.  Cambiar la base de datos sobre la configuración del servidor de Blackberry.
 8.  Reinicie todos los servicios.
 9.  Cambiar la base de datos sobre el DSN de sistema ODBC si es 3,0 o 4,0.
 10.  No  olvidarse de cambiar la base de datos en el Administrador de BlackBerry (o dominio), haciendo clic derecho y seleccionando Propiedades y seleccione la base de datos, y asegúrese de que la información es correcta.

Vamos ser claros, o Twitter não é fácil de entender, é pior do que o beisebol em complexidade, se você não entender as regras desse esporte, você não vai gostar nem entender o que está acontencendo. Para complicar mais a situação, a maioria das regras do Twitter nem sequer estão escritas ou vistas por todos. Todo mundo adapta a ferramenta a suas necessidades e inventa a sua própria forma de usar.

A primeira vez que você loga no Twitter é difícil, há muito silêncio e pensa que é mais seguro que venha com uma mente facebookiana cheia de déias pré-estabelecidas. Esqueça tudo isso, relaxe e siga algumas dessas dicas.

1 – Se você ainda não escolher um nome de usuário ou apelido, escolha o mais curto que venha à sua cabeça. No Twitter você pode enviar mensagens com apenas 140 caracteres, quanto mais curto seja o nome, maiores serão as mensagens que você poderá escrever aos outros usuários.

2 – Quando você cria uma conta no Twitter, no final você irá sugerir uma lista de usários recomendados, não siga o padrão, veja quem realmente lhe interessa.

3 – No Twitter você pode fazer apenas três grandes coisas: seguir pessoas/usuários, ler mensagens de 140 caracteres ou menos e escrever mensagens de 140 caracteres ou menos. Para que seu Twitter crie vida você necessita começar a seguir outros usuários do serviço. Até que você faça isso o seu Twitter está em coma.

4 – Sua primeira mensagem pode ser uma saudação ou apresentação ou o que quiser, afinal ninguém vai ler. Mas isso vai mudar muito rapidamente.

5 – Procure seus amigos por nome e apelido, usando a busca de pessoas do Twitter. Para seguir aqueles que encontrar pressione o botão + .

6 – Depois de encontrar seus amigos, cumprimente-os para ver se eles também começam a segui-lo. Para se comunicar com alguém no Twitter escreva primeiro @nome + mensagem. Pode ser algo assim: “@kurtcobain como está amigo? Não sabia de você desde 1992, sou Rafael Ramires e estou no Twitter”.

7 – Convide seus amigos, o Twitter vai ser muito atrativo se você começar a seguir pessoas que você conhece pessoal ou virtualmente. Pode enviar emails convidando-os à usar a rede social.

8 – Você pode também porcurar por pessoas que admira. Muitos artistas estão no Twitter, e você pode seguí-los e saber as últimas notícias e o que estão fazendo.

9 – Pode também seguir pessoas ligadas à sua profissão. Se você é um fotógrafo, siga os fotógrafos, se é engenheiro, siga os engenheiros, e assim por diante.

10 – Bem com essas dicas acima você já deveria estar seguindo algumas pessoas em seu Twitter. Agora, na sua página do Twitter você verá o que as pessoas que você seguem escrevem.

11 – Nunca escreva no Twitter como se fosse enviar um SMS (mensagem de texto).

12 – Decida se você quer ou não proteger suas mensagens no Twitter. Se não forem protegidas (com cadeado) lembre-se de que todas as informações que você escrever serão publicadas e indexadas pelo Google.

13 – A reprocidade no Twitter não existe, portanto não ligue se alguém que você segue não te seguir. Na verdade a grande vantagem sobre o Facebook é que você pode ser seguido por pessoas que voês não segue, e vice e versa.

14 – Para responder a alguém use o botão de resposta.

15 – Tente criar conteúdo interessante. Não seja totalmente impessoal e não conte apenas a sua vida. Participe das conversações.

16 – Recomende as coisas que gosta e envie mensagens sobre coisas em que você é especialista.

17 – Se você quer se promover ou vender algum produto, você pode, contando que isso não represente mais que 20% das suas mensagens.

18 – Não insulte as pessoas. Caso isso ocorra com você, bloqueie-a.

Fonte: Infochaos

Windows 7 Whopper

Burger King ha aprovechado el lanzamiento de Windows 7 para lanzar su Windows 7 Whopper. Se trata de una Whopper de 7 hamburguesas (12,7 centímetros) lo que equivale a unos 777 gramos de carne.

Sólo se podrán beneficiar de esta oferta los 30 primeros clientes que cada día llamen a Burger King pidiendo una Whopper 7 . Y sólo durante 7 días por un coste de 777 yenes (cinco euros). 

El resto tendrá que rascarse el bolsillo y pagar el doble para probarla: 1.450 yenes (10,6 euros). 

Segundo Sheryl Sandberg, diretor de operações do Facebook, a receita do Facebook está crescendo tão rápido, que já atingiram os seus objetivos econômicos estabelecidos para 2010 .. estamos falando de 500 milhões de dólares.

O aspecto mais importante do artigo publicado pelo MarketingVox é a comparação do confronto das receitas de publicidade do Google e Facebook.

De acordo com o parecer de Sheryl Sandberg, o Google atende 10% da demanda de publicidade, interceptando as pessoas que já sabem o que querem e já decidiram avançar com qualquer compra.

Facebook é um pouco como uma pirâmide invertida, e espera ir além de ganhos no futuro ou para tirar proveito da nova publicidade direta com 350 milhões de usuários ao redor do mundo.

Nos vemos por aqui.

Fonte: Ninja Marketing
Tradução: Patrícia Scholze