Pues no, no la hay, antes solo existía el debate de Windows vs Linux, luego se sumo Intel vs AMD, ahora ya tenemos un poco de todo Java vs .NET, PHP vs Ruby… –¿dónde quedo ensamblador contra C?-.
Ahora evolucionamos al mundo framework, en JavaScript un festival, React vs Angular vs Aurelia vs Boostrap vs …. pero tampoco pasa nada porque en el fondo unos se pueden mezclar con otros, si al final hasta se quieren llevar bien.
Por otro lado tenemos los lenguajes de nueva hornada en general surgidos de la nueva ola funcional, desde Scala a F# a Clojure, para todos aquellos que os habéis preguntado si hay vida más allá del imperativo, pues si, la hay.
NoSQL viene a romper el inmovilista mercado de las bases de datos, más de un dba debería preocuparse, por mi perfecto, por fin alguien se molesta en hacer bases de datos para desarrolladores y si yo quiero guardar un objeto lo guardo y no tengo que partirlo en trozos para luego volver a juntarlos.
Breve recorrido por el mundo arquitectura, desde los grandes clásicos de 3 capas a N capas, pasando por DDD, EDA, aspectos… como no permitiendo combinaciones entre ellos no vaya a ser que alguien se quede atrás y decir que si solo haces 3 capas es de pobres y DDD es de innovadores que matan moscas a cañonazos cuando realmente deberías estar haciendo SOA que sirve para todo, lo de ahora y lo que vendrá.
Como no podía ser de otra manera tocan las metodologías, TDD, BDD, por supuesto TDD es lo que te hará tener una aplicación con menos errores que una hoja en blanco y BDD hará que quieres irte de cañas con los funcionales de tus proyectos, cuando llegues a las copas estarás hablando de ATDD.
Parece muchas veces que haya que tomar partido, no existe esa necesidad, los extremos en informática no funcionan, ni desde el lado propietario cerrando puertas al campo ni desde el código libre teniendo tal diversidad de distribuciones y software repetido que la fuerza se dispersa.
La virtud está en el término medio, es bueno que haya código libre pero tiene que haber una base a la que agarrarse, con Linux se han intentado crear consorcios con más pena que gloria, en desarrollo a .NET se le supuso una teórica capacidad multiplataforma (sin contar Core) que nunca llego y al final Java siempre termina ejecutándose en entornos Unix.
Las pruebas unitarias son útiles y necesarias pero no un pilar que te condicione un desarrollo como en TDD, BDD no te va dar fiabilidad integral a tu aplicación pero cada uno en su lado (¿Back y Front?, ¿microservicios y SPA?, ¿entorno técnico y funcional?) suponen una buena combinación.
DDD te puede dar escalabilidad y la transversalidad se la puedes dejar a AOP, si has perdido la pista de tú código EDA te puede poner en la senda y si el frontal es ligero un n-capas estilo MVC te responderá bien.
No entrare en el oscuro mundo de la arquitectura corporativa o como coger tu aplicación partirla en trozos y lanzar cada uno por separado a través de buses de conectividad proporcionando todo tipo de servicios, al menos se puede decir que en este ámbito existe más combinación.
Los frameworks estan de moda en líneas generales, son útiles siempre y cuando el framework no tape el lenguaje, –se jQuery pero no se que es JavaScript-, siempre he creído que un framework es bueno cuando inviertes más tiempo en leerlo que en escribir código.
Politizar la informática haciendo bandera de «¿ves como te decía que la tecnología Pokemon iba a triunfar?» quizás no sea la opción, habría que optar más por formas de arreglar problemas que por intentar encontrar el santo grial que nos permita no tener que volver a leer un manual de informática, yo por lo menos sabía lo que me esperaba cuando me metí en esto (bueno, quizás no tanto).
Mes: octubre 2015
Actualizando Raspberry Pi 2 a Jessie
Jessie trae características nuevas como por ejemplo PHP 5.6 que no estaba disponible en wheezy, si queremos tener esta versión o alguna otra solo disponible en Jessie tendremos que realizar el siguiente proceso, antes de nada es recomendable realizar un backup del sistema que en una raspberry es tan fácil como volcar la imagen de la tarjeta SD a disco (usando el comando dd en linux o Win32DiskImager en Windows).
Lo primero es actualizar la versión que tenemos (wheezy).
# sudo apt-get update
# sudo apt-get upgrade
# sudo apt-get dist-upgrade
Update actualiza la lista de paquetes, upgrade actualiza los paquetes y dist-upgrade actualiza toda la distribución (incluyendo kernel, librerías, loader, etc…)
Si no ha habido problemas pasamos al siguiente punto que consiste en actualizar la lista de repositorios, esta lista se encuentra en /etc/apt/sources.list, con el siguiente comando lo que hacemos es modificar la línea del repositorio que apunta a wheezy para que apunte a los repositorios de jessie.
# sed –i ‘s/wheezy/jessie/g’ /etc/apt/sources.list
Y dentro del fichero sources.list veremos lo siguiente:
deb http://mirrordirector.raspbian.org/raspbian jessie main firmware contrib non-free
Con esto le estamos diciendo que busque paquetes dentro de la distribución jessie para todos los componentes indicados (main, firmware,…)
Ahora procedemos a actualizar el sistema, durante la instalación se nos preguntará si queremos reiniciar los servicios afectados automáticamente, lo recomendable es que si pero teniendo en cuenta que no hay que deshabilitar el acceso root por SSH si no tenemos acceso físico a la raspberry, esto no es problema ya que por defecto el usuario root no está disponible en raspbian, durante el proceso se reiniciará el propio proceso ssh pero eso no nos cortará la conexión con un cliente ssh estilo putty.
La actualización la lanzamos con los siguientes comandos:
# sudo apt-get update
# sudo apt-get upgrade
# sudo apt-get dist-upgrade
Es posible que durante la instalación se nos indique que algunos archivos han sido modificados por otros paquetes y que versión del mismo queremos mantener, si la modificación no ha sido realizada por nosotros mismos actualizar suele ser una buena idea, en cualquier caso siempre se nos dará la opción de ver las diferencias.
Cuando terminamos repetimos el proceso de actualización para verificar que no hay paquetes pendientes, en caso de que nos aparecieran paquetes “retenidos” que no se instalan tendríamos que volver a lanzar la actualización de la distribución (dist-upgrade)
El proceso en si es bastante largo pero quitando alguna que otra pregunta de actualización de ficheros es bastante automático.
Finalmente reiniciamos.
# reboot
Información obtenida aquí
Atajos de edición Visual Studio 2013
Visual Studio tiene infinidad de atajos de edición, muchas veces no se usan precisamente por la cantidad que tienen, así que a veces lo recomendable es empezar por usar unos pocos, en este caso he cogido esta selección sacada de Ninja-Tips, recomendable dedicar unos minutos a probarlos:
Alt + Flecha arriba / Flecha abajo: Posicionado sobre una línea de código la mueve hacia arriba o hacia abajo, si se selecciona un conjunto de líneas las moverá juntas.
Ctrl + U / Ctrl + Shit + U: Pone en minúsculas / mayúsculas el texto seleccionado.
Ctrl + K + C / Ctrl + K +U: Comenta o descomenta una línea de código, si se selecciona un conjunto de líneas las comentará juntas.
Ctrl + E + F: Formateo insensible al contexto, el texto seleccionado se formatea independientemente del resto del código.
Ctrl + E + D: Formatea todo el documento teniendo en cuenta el contexto.
Mayus + Alt: Permite selección en vertical, una vez hecho esto, se pueden editar varias líneas a la vez, también se puede hacer con Alt + botón izquierdo del ratón.
Ctrl + K + S: Surrounding, permite elegir una estructura de código que se aplicará a todas as filas seleccionadas (try-catch, try-finally, if,…)
Snippets de código: Hay varios snippets, por ejemplo “prop” + Doble tabulador, crea el código de una propiedad, “propfull” crea una propiedad completa,…
Ctrl + K + X: Permite acceder a los shortcuts personalizables.
Ctrl + K + M: Crea un método automáticamente sino existe con la firma adecuada extraída el contexto de llamada.
Ctrl + . : Saca el menú de opciones para resolver referencias no resueltas y otras opciones.
Instalando MongoDB
Las bases de datos NoSQL están cogiendo cada vez más popularidad, MongoDB posiblemente sea la que más atención acapare ahora mismo, mucha gente se centra en su capacidad de almacenar y procesar gran cantidad de información pero de cara al desarrollo su interés radica en su cómodo acoplamiento con el código.
En desarrollo se llama impedancia a esa separación que existe entre las bases de datos y el código, las BBDDs tradicionales funcionan con tablas mientras que el código si es POO funciona a través de clases, esta impedancia se ha intentado resolver con varias soluciones (Active Record, ORM,..) aunque en el desarrollo resulta evidente que siguen surgiendo diferencias entre un sistema y otro.
En el caso de MongoDB (y posiblemente otras) esta diferencia queda mitigada, el simple hecho de que tus objetos se puedan guardar “tal cual”, si además a esto le sumamos un mantenimiento fácil que simplifica la parte de IT es normal que haya calado entre la comunidad de desarrolladores
En este caso voy a dar unas breves notas de cómo se instala y un poco de configuración básica sobre MongoDB, hay que tener en cuenta que MongoDB se puede programar usando un lenguaje javascript lo cual facilita mucho las cosas, al final veremos un ejemplo.
Una vez descargada la aplicación está se instalará por defecto en C:\Program Files\MongoDB, por defecto la ruta de los datos se almacena en \data\db.
La aplicación se lanza con el ejecutable mongod, una vez abierta se puede cerrar con Ctrl+C.
Es posible indicar un archivo de configuración, por ejemplo:
#where data files will reside
dbpath=G:\MongoDB\Data
#where the log file will be stored
logpath=G:\MongoDB\Log\mongo-server.log
#how verbose the server will be logging
verbose=vvvvv
Esto indica que los datos se guardarán en la ruta G:\MongoDB\Data, el log se guardará en la ruta G:\MongoDB\Log\mongo-server.log el nivel de detalle se especifica en verbose.
Para poder instalar como un servicio se ejecutaría la siguiente línea apuntando al archivo de configuración.
mongod –f “c:\Program Files\MongoDB\Server\3.0\bin\mongod.conf” –install
Para poder lanzar la línea de comandos del cliente hay que usar el ejecutable mongo.
Algunos comandos básicos son:
| show dbs | Muestra las bases de datos que existen |
| db | Muestra la base de datos actual |
| Use nombre_de_base_de_datos | Cambia a la base de datos indicada |
| help | Muestra la ayuda |
| db.getMongo() | Devuelve los datos de la conexión |
Se pueden lanzar comandos administrativos sin invocar la Shell de comandos, por ejemplo para poder lanzar comandos de administración:
mongo server1/admin –eval “db.runCommand({logRotate:1})”
En este caso la opción eval evaluará el comando entre comillas y lo ejecutará sin entrar en Shell (en el ejemplo se rota el archivo de log para archivarlo).
Si son muchos comandos entonces se puede lanzar un archivo que contenga todos los comandos:
mongo server1 myDailyChores.js
Existe la opción de ejecutar una secuencia de comandos y después ingresar en la Shell para seguir introduciendo órdenes, en este caso introduciendo –shell al final:
mongo server1 myDailyChores.js –shell
Podemos introducir la cadena de conexión y la base de datos directamente donde ejecutar el comando.
mongo localhost/admin –eval “db.runCommand({logRotate:1})”
La salida de este comando no es muy descriptiva, si queremos ver la información que emite la consola podemos hacer:
mongo localhost/admin –eval “printjson(db.runCommand({logRotate:1}))”
Unos accesos rápido y útiles en la shell desde teclado:
Ctrl+K Borra desde el cursor hasta el final de línea
Ctrl+L Limpiar pantalla
Se puede usar un editor externo para la edición de javascript asociado a MongoDB, para ello se establece la variable de entorno EDITOR.
C:\>set EDITOR = “notepad++.exe”
Después desde el Shell de mongo haríamos:
mongo> myFunction = function(x) {}
mongo> edit myFunction
Para cargar desde la Shell un archivo primero usaríamos pwd() para saber la ruta actual y después para cargar el archivo safer.js que contiene el código haríamos load(‘safer.js’).
Se puede ejecutar un fichero siempre que se entra en la shell de mongo para esto se crea un fichero con nombre mongorc.js y se coloca dentro de la ruta de usuario c:\users\{username}\.mongorc.js
Si se quiere evitar la carga de este fichero inicial se puede usar el parámetro –norc
Finalmente un script útil para evitar borrar base de datos o apagar el servidor:
var _no_ = function() { print(“Nope!”);}
db.prototype.dropDatabase = _no_;
db.dropDatabase = db.prototype.dropDatabase;
db.prototype.shutdownServer = _no_;
db.shutdownServer = db.prototype.shutdownServer;
Otra forma sería:
db.prototype.dropDatabase = function() {
print(“No”);
}
db.dropDatabase=db.prototype.dropDatabase;