Batch: Shutdown Windows por línea de comando

Para apagar o reiniciar un sistema Windows des de la línea de comandos tenemos el comando “SHUTDOWN”

Estas son las diferentes posibilidades

Reiniciar

shutdown -r

Apagar

shutdown -s

Cerrar Sesión

shutdown -l

Retraso en segundos para las operaciones anteriores

shutdown -t xx

Abortar operación de SHUTDOWN

shutdown -a

Hibernar

shutdown -h

 

Share

Posts relacionados:

  1. Batch: Script para conectar unidades de red en Windows
  2. Batch: crear secuencia de carpetas

Exchange server: Añadir dominio a la Lista Blanca

Des de la Consola de Administración no tenemos acceso para gestionar la lista blanca de dominios, por lo que tenemos que hacerlo des de la Consola PowerShell de Exchange.

Podemos consultar el contenido de la lista blanca

(Get-ContentFilterConfig).ByPassedSenderDomains

Podemos añadir remitentes a la lista blanca

$WhiteDomain = (Get-ContentFilterConfig).BypassedSenderDomains
$WhiteDomain.add(“domain.tld”)
Set-ContentFilterConfig -BypassedSenderDomains $WhiteDomain

Puedes añadir tantos dominios como necesites mediante la ejecución de la instrucción $WhiteDomain por cada dominio y luego ejecutar la instrucción Set-ContentFilterConfig para guardar todos los dominios en bloque.

Share

Posts relacionados:

  1. Exchange server: Añadir remitente a la Lista Blanca
  2. Exchange Server: Mover buzón entre base de datos

Exchange server: Añadir remitente a la Lista Blanca

Des de la Consola de Administración no tenemos acceso para gestionar la lista blanca de remitentes, por lo que tenemos que hacerlo des de la Consola PowerShell de Exchange.

Podemos consultar el contenido de la lista blanca

(Get-ContentFilterConfig).ByPassedSenders

Podemos añadir remitentes a la lista blanca

$WhiteSender = (Get-ContentFilterConfig).BypassedSenders
$WhiteSender.add(“mail@domain.tld”)
Set-ContentFilterConfig -BypassedSenders $WhiteSender

Puedes añadir tantos remites como necesites mediante la ejecución de la instrucción $WhiteSender por cada remitente y luego ejecutar la instrucción Set-ContentFilterConfig para guardar todos los remitentes en bloque.

    


Share

Posts relacionados:

  1. Exchange Server: Mover buzón entre base de datos

Exchange Server: Mover buzón entre base de datos

Des de PowerShell podemos mover búzones de Exchange. Para ello tenemos que saber el buzón y la base de datos de destino

Saber la base de datos de destino:

>Get-MailboxDatabase

Resultado: Devuelve la lista de base de datos

Crear la solicitud de movimiento:

>New-MoveRequest –Identity "NOMBRE BUZON" –TargetDatabase "BASE DE DATOS DE DESTINO"

Ver el estado de la solicitud de movimiento

>Get-MoveRequest -Identity "NOMBRE BUZON"

Resultado:  CompletionInProgress | Completed

 

Share

Posts relacionados:

  1. Titanium : Cerrar conexión con una base de datos
  2. Titanium : Abrir conexión a una base de datos
  3. Vb.net: AutoComplete

Android: activar el Bluetooth

Una vez que hemos comprobado que el dispositivo tiene Bluetooth, podemos usarlo.

La primera cosa que debemos hacer es activarlo, pero lo haremos consultando si ya lo está:

if (!miBluetoothAdapter.isEnabled()) {
    Intent enableBtIntent = new Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE);
    startActivityForResult(enableBtIntent, REQUEST_ENABLE_BT);
}
BluetoothAdapter.ACTION_REQUEST_ENABLE creará un mensaje para que el usuario valide la activación del Bluetooth
La respuesta quedará en "enableBtIntent".
Para activarlo de forma efectiva utilizamos "startActivityForResult" con la respuesta del usuario.

 

Share

Posts relacionados:

  1. Android: Saber si el dispositivo tiene Bluetooth
  2. Android: Permisos sobre los elementos de Comunicación
  3. Titanium : Truco – Abrir configuración wireless en Android

Android: Saber si el dispositivo tiene Bluetooth

Para saber si el dispositivo en el que está nuestra app dispone de Bluetooth podemos hacerlo consultando el Adapter correspondiente al Bluetooth.

Lo que hacemos es consultar al Adapter y si este nos devuelve Null podemos estar seguros que el dispositivo no soporta Bluetooth.

BluetoothAdapter miBluetoothAdapter = BluetoothAdapter.getDefaultAdapter();
if (miBluetoothAdapter == null) {
    // El dispositivo no soporta Bluetooth
}

Recordad que para acceder a ciertos elementos de los dispositivos hay que activar los permisos correspondientes. En este caso los permisos de comunicación que podeis consultar en un post anterior Android: Permisos sobre los elementos de Comunicación

Share

Posts relacionados:

  1. Android: Resumen sobre Permisos
  2. Android: Permisos sobre los elementos de Comunicación
  3. Android: Permisos sobre las Configuraciones del dispositivo
  4. Android: Definición de los permisos en una App
  5. Android: Permisos sobre el Audio i la Cámara

Si mi mente no es estática, mi tipado tampoco debería serlo…

Despues de haber leído el articulo de Fernando en Cocoa Mental, se me ocurrió retuiterarlo…y me vi inmerso en un debate con unos interlocutores a los cuales en principio no iba destinado el dardo del autor.

Fernando apuntaba a “Javeros” y “Cpluspluseros”…pero fueron en mayoria “.neteros” (hoy estoy “sembrao” con los palabros) los que se dieron por aludidos, y principalmente usuarios de C#.

Para los que no me conozcáis llevo desde los 10 años rascando código, y voy a cumplir 35 dentro de un mes, y si bien la cantidad y la calidad son los mismo que el tocino y la velocidad, os ruego que hagáis un “auto de fe” sobre lo que os quiero explicar, y al final del post saquéis vuestras propias conclusiones.

En mi día a día principalmente me peleo con .NET y con ObjC+Cocoa, aunque también tengo que entrar al trapo en otras guerras, pero estas no nos aportarían demasiado para el tema que quiero tocar aquí.

Así que, vamos a meternos en harina…

Al contrario que Fernando…veo mas similitudes que diferencias en las dos plataformas que toco, y creo que podemos extrapolar ese pensamiento a todas las plataformas actuales…ahora me explico… ;)

Todas han sido ideadas (con mayor o menor fortuna) para solucionar problemas estándar…y nos ponen en la manos unas herramientas que yendo por la línea  rápida y recta, o dando un largo rodeo…nos permiten (al menos que seamos unos patanes integrales) llegar al mismo sitio…

-Unos harán ese camino dejando suciedad por todos sitios y dando saltitos de aquí para allí mientras caminan…

-Otros irán limpiando el camino y tomando apuntes, incluso dejando miguitas de pan para los que lleguen después…

-Otros, lo harán acompañados de gente y de manera ordenada (estos irán en carreta, turnándose para tirar de la misma y conseguirán cansarse menos)

-Los hay que preferían no hacer ese camino sin consultar previamente los mapas, leerán los apuntes de algún viajero anterior…estudiaran la mejor manera de llegar y verán que con un estricto análisis se podía tomar un atajo que evite pasar una y otra vez por la misma encrucijada…

Al final todos se encuentran delante de una puerta  y pueden abrirla con una llave, o de una pedrada, pero los dos métodos te permitirán entrar

Como veis existen múltiples maneras de hacer las cosas…y eso es común para todas las plataformas…

Bien…a estas alturas del post os estaréis preguntando hacia donde os quiero llevar…seguirme, que ya queda menos… ;)

Los lenguajes y las plataformas, no dejan de evolucionar. Cada una a su ritmo…pero observándose mutuamente…

Si alguno tiene algo realmente bueno, el otro intentara asimilarlo dentro de su core, o implementara algún tipo de “parche” o invento para conseguir el mismo fin…y eso esta pasando constantemente…

Por ejemplo uno de los creadores de Java era un fanático de la plataforma NEXT y se llevo cosas de Objective-C para su nuevo lenguaje.

Un ejemplo técnico sencillo es el tema de los auto-synthetize que nos ahorra unas líneas de código en Objective-C…pues eso existía integrado desde hacia un tiempo antes en .NET, donde declarando las property de una cierta manera se nos generan “por detrás” los getters y los setters necesarios para acceder a ellas…

El otro día descubrí (buscando otra cosa) como “atacar” colecciones de datos con querys’s estilo “SQL” en Objective-C me pareció súper potente para ciertos asuntos…y profundizando en esa búsqueda,  también me di cuenta que eso mismo, se podía hacer en .NET desde la versión 4 del framework atacando los datos con LINQ y con una sintaxis también sospechosamente parecida a SQL

Muchos estaréis pensando que si, que todo muy bonito…pero que, en esencia, el tema de los tipados si que separa a las dos plataformas de manera total…o no?¿

Pues si, y no, una vez más (seguid leyendo hasta el final del post, por favor… ;) xD)…

Para mi el tipado estático realmente representa una carga en el desarollo, y mas cuando has probado las mieles del dinamismo

Yo lidio todos los días con .NET…y puedo trabajar como lo haría con otro lenguaje con tipado dinámico…a eso se le llama “inferencia de tipos” que permite a los lenguajes funcionales soltar lastre y no ser tan estrictos…un buen ejemplo de esto es el lenguaje F# .

En .Net, a partir del framework 4.0 usando declaraciones del tipo “dynamic” el compilador no se queja y manda la llamada necesaria al nuevo motor de ejecución DLR (Dynamic Language Runtime) en lugar del clásico CLR (Common Language Runtime). Y si nos paramos a pensar, antes usando “reflexión” también podíamos  hacer algo parecido (usando Get types), aunque eso era algo mas feote… ;) xD

Por cierto ese nuevo DLR permite cosas muy chulas como ejecutar lenguajes dinámicos como Python (o deberíamos decir Iron Python) bajo .NET y integrarlo plenamente en Visual Studio con muy buenos resultados…

Una vez mas llegamos a lo mismo pero de distinta manera…y todo eso servirá para demostrar algo al final de todo (si no me lio dentro de mis propios pensamientos) ;)

En el post del que surge todo este embolao, Fernando califico a los patrones de diseño como : “una señal de ineficiencia”…

Estoy de acuerdo con esta afirmación?¿ Pues una vez mas si y no, y el que no llegue al final del post no sabrá porque… ;) xDDD

En .NET tenemos mucha libertad para rascar código…tenemos un IDE muy chulo (me encanta Xcode, pero VS2012 esta también muy bien) que permite fácilmente ponerte directamente a crear algo…pero eso no acostumbra a ser una buena idea…Y ahí entran los patrones de diseño…que no dejan de ser una “plantillas” para que no nos descarriemos mucho por el camino…

Y en que lugar deja esto a Objective-C? No usamos con el los patrones de diseño?¿

Pues en realidad si que los usamos y mucho, en casi todo momento…usamos el MVC, el delegado, el observador constantemente…y casi no nos damos cuenta de que lo hacemos…

Simplemente Objective-C y el IDE te empujan a usarlos sin darte cuenta…

Os recomiendo un libro que os ayudara sobre este tema especifico : Pro Design patterns for IOS ;)  y este otro que os servirá para todo…un imprescindible : Design patterns : Elements of reusable object oriented software.

Y ahí es donde quería llevaros desde el principio…

Para mi, el quid de la cuestión no es tanto el tipado, ni los patrones…sino el paradigma o la esencia en si de las propias plataformas y lenguajes

No es un algo, sino el conjunto, el todo, que las hace mejor o peor para conseguir un objetivo

La curva de aprendizaje de alguien que aprende Java o .NET es ascendente…fácil al principio y difícil según se complican las cosas…

Con Objective-C es totalmente a la inversa…te llevas un mazazo al intentar adentrarte en el…y cuando superas ese muro, ya puedes empezar a hacer cosas muy vistosas o complicadas en otras plataformas, sin apenas esfuerzos

Programar con Objective-C te hace tomar decisiones para solventar problemas de manera en cierto modo inducida,  o guiada (un poco como si te llevaran de la mano).

Desarrollas de una cierta manera, cambias la manera de pensar, de enfrentarte a los problemas…usas la potencia del lenguaje dinámico, la potencia al mas alto nivel de los patrones…y puede ser que nunca hayas profundizado ni te hayas interesado en leer nada sobre ninguna de las dos cosas…y sin embargo ahí estas…

Evidentemente, os recomiendo conocer lo mejor posible la plataforma que uséis para poder sacarle rendimiento…y no hacer las cosas por inercia…

Cuanto mas conozcas sobre datos, arquitectura de software, pros, contras, fuerzas y restricciones etc…en mejor profesional te convertirás…necesitas esa información para asimilarla y aplicarla correctamente…

Buenos developers y chapuzas los hay en todas las plataformas…

Pero una de las cosas que me a enseñado la vida, es que no los reconocerás por el lenguaje que dominen, por la plataforma que usen, los reconocerás por la apertura de miras que tengan, la curiosidad que presenten o las ansias de aprender que demuestren…

Por eso quizás el titulo de este post no sea del todo correcto, o quizás si…eso ya lo decidirás tu…

Amplia horizontes, prueba, tantea, estudia, experimenta, pero sobretodo que tu mente no se quede estática… ;)

 

Share

No hay entradas relacionadas.

Android: Resumen sobre Permisos

Para cerrar esta vuelta sobre los permisos en Android os propongo un resumen con los enlaces a los POST relacionados.

Vimos como se indican los permisos en la aplicación Android que estemos desarrollando

Luego vimos según los diferentes usos o categorías los permisos disponibles

 

Este repaso por los permisos que pueden requerir ciertas aplicaciones nos puede ayudar a saber qué podemos hacer en nuestra aplicación Android.

Espero que os haya gustado la serie…

Share

Posts relacionados:

  1. Android: Permisos sobre los Archivos y el Almacenamiento
  2. Android: Permisos sobre el Acelerómetro y el Vibrador
  3. Android: Permisos sobre los elementos de Comunicación
  4. Android: Permisos sobre las Redes
  5. Android: Permisos sobre las Llamadas

Android: Permisos Deprecated

Como vimos en un post anterior hay que definir ciertos permisos en el fichero AndroidManifest.xml para acceder a ciertas características de los dispositivos.
Existen ciertos permisos que han ido quedando obsoletos o que simplemente se han eliminado.

Constante: PERSISTENT_ACTIVITY
Declaración: <uses-permission android:name=”android.permission.PERSISTENT_ACTIVITY” />
Descripción: Esta constante está Deprecated des del nivel de API 9. Esta funcionalidad no hay que utilizarla. Permitía que una aplicación estableciera sus actividades como persistentes.

Constante: READ_INPUT_STATE
Declaración: <uses-permission android:name=”android.permission.READ_INPUT_STATE” />
Descripción: Esta constante está Deprecated des del nivel de API 16. Esta funcionalidad no hay que utilizarla.

Constante: RESTART_PACKAGES
Declaración: <uses-permission android:name=”android.permission.RESTART_PACKAGES” />
Descripción: Esta constante está Deprecated en el nivel de API 8. El restartPackage (String) API ya no es compatible.

Constante: SET_PREFERRED_APPLICATIONS
Declaración: <uses-permission android:name=”android.permission.SET_PREFERRED_APPLICATIONS” /
Descripción: Esta constante está desfasada en el nivel de API 7. Deja de ser útil seeaddPackageToPreferred (String) para más detalles.

 

Fuente: http://developer.android.com/reference/android/Manifest.permission.html

Share

Posts relacionados:

  1. Android: Permisos sobre los Gráficos
  2. Android: Permisos sobre los elementos de Comunicación
  3. Android: Permisos sobre la Mensajería
  4. Android: Permisos sobre las Redes
  5. Android: Permisos sobre las Configuraciones del dispositivo

Android: Permisos sobre los elementos de Comunicación

Como vimos en un post anterior hay que definir ciertos permisos en el fichero AndroidManifest.xml para acceder a ciertas características de los dispositivos.
Veamos hoy los permisos para acceder, manipular y utilizar los elementos de comunicación del dispositivo.

Constante: BLUETOOTH
Declaración: <uses-permission android:name=”android.permission.BLUETOOTH” />
Descripción: Permite que la aplicación empareje dispositivos por Bluetooth

Constante: BLUETOOTH_ADMIN
Declaración: <uses-permission android:name=”android.permission.BLUETOOTH_ADMIN” />
Descripción: Permite que la aplicación descubra y empareje dispositivos por Bluetooth

Constante: INTERNET
Declaración: <uses-permission android:name=”android.permission.INTERNET” />
Descripción: Permite a las aplicaciones abrir sockets de red.

Constante: MODIFY_PHONE_STATE
Declaración: <uses-permission android:name=”android.permission.MODIFY_PHONE_STATE” />
Descripción: Permite a las aplicaciones modificar el estado telefonía – el encendido, mmi, etc

Constante: NFC
Declaración: <uses-permission android:name=”android.permission.NFC” />
Descripción: Permite a las aplicaciones realizar operaciones de E / S a través de NFC

Constante: USE_SIP
Declaración: <uses-permission android:name=”android.permission.USE_SIP” />
Descripción: Permite a la aplicación para utilizar el servicio SIP

 

Fuente: http://developer.android.com/reference/android/Manifest.permission.html

Share

Posts relacionados:

  1. Android: Permisos sobre las Configuraciones del dispositivo
  2. Android: Permisos sobre los Archivos y el Almacenamiento
  3. Android: Permisos sobre los Datos de usuario
  4. Android: Permisos sobre las Redes
  5. Android: Permisos sobre las Aplicaciones