Oracle Instaclient SQL Plus en Ubuntu

Probablemente algunos (como yo) requieren tener instalado SQL Plus de Oracle en sus equipos sin tener que instalar Oracle completo. Para que funcione correctamente hay que hacer algunas cosas, y aquí les explico cuales son para que se ahorren algunos dolores de cabeza.

Paso a paso

1. Descargar el InstaClient: Oracle es "algo" quisiquilloso cuando se trata de sus herramientas, así que la opción es buscar en Google o navegar directamente en el sitio de esta empresa.
2. Descomprimir InstaClient: Típicamente habrán descargado el archivo comprimido. Cuando se trata de herramientas que requieren instalación manual yo las dejo en la carpeta /opt
   
   
3. Configurar variables de ambiente: Estas son varias, así que creé un script que las setea y des-setea según corresponda:

unset NO_PROXY
unset UBUNTU_MENUPROXY
unset no_proxy

unset ORACLE_HOME
export LD_LIBRARY_PATH=/opt/instantclient_12_1

para la versión 11_2 es análogo pero tendrán que poner la carpeta que corresponde.

Finalmente ejecutar SQL Plus: Fácil y bonito, desde la misma ruta

./sqlplus

 Y eso debiera funcionar.

Bonus: Si quieren ejecutar  una conexión para administrar una base de datos remota (y poder reiniciar la base con un shutdown abort, por ejemplo) el comando es:

./sqlplus 'usuario/clave'@IP_de_la_BD/SID as sysdba

obviamente cambiando los datos acorde.

Emprendimiento busca desarrollador: Aquí hay un problema

Hace poco les contaba algunas apreciaciones personales respecto a los emprendimientos TI. Hoy les quiero comentar, queridos y honorables lectores, un par de problemas que he notado, cuando los mismos chicos que ayudaba con su emprendimiento comienzan su búsqueda de  desarrolladores.

Cito el aviso (y omito los enlaces para proteger a los "inocentes"):

Chicos estamos buscando a un desarrollador para que se convierta en nuestro CTO . Aquí mayor información ... [link]

Somos un NUEVO EMPRENDIMIENTO y estamos en busca de un DESARROLLADOR Back-end, idealmente con conocimientos de Front-end, nos encontramos en el desarrollo del M.V.P.

Lenguajes: PHP, Java, Ruby on Rails, CoffeeScript y bases de datos como MySql, Mongodb.

Si eres Entusiasta, Emprendedor y te gusta la Música, contactanos para concretar una reunión!

Buscamos alguien que llegue a ser nuestro socio, por ahora no hay dinero de por medio pero si un gran Proyecto.

Start Small - THINK BIG!

Lo primero que me llama la atención del aviso es el tipo de requerimientos que se solicita:

• PHP
• Java
• Ruby on Rails
• CoffeeScript
• Bases de datos como MySql, MongoDB

Personalmente aún no me ha tocado ver un proyecto en el cual converjan PHP, Java y RoR, por lo que se me hace que fue producto de una búsqueda en Google de que lenguajes y tecnnologías son los más utilizados en los emprendimientos.
Con las bases de datos me sucede algo similar.

Lo no tan bueno de considerar en el aviso una variedad de tecnologías es que refleja poca claridad respecto de que se necesita en términos informáticos.

Lo segundo que me llama la atención es lo que se busca:

• Un socio y CTO

CTO es el nombre de fantasía para "el informático" del equipo (Chief Technology Officer, que le dicen) y todas las siglas de CEO, CDO, etc. son las denominaciones de moda de las startups para los puestos "gerenciales". A proposito ¿no que estaban buscando desarrollador? ¿CTO desarrollador? ¿Existe eso?

Esto por si mismo no es tan terrible, salvo que se suma a lo tercero qeu me llama la atención:

por ahora no hay dinero de por medio pero si un gran Proyecto.

El problema aquí es que el CTO al ser "EL informatico del equipo", va a ser además quien se haga cargo de las definiciones técnicas, y de buena parte de la implementación, si es que no toda.

Mano en el corazón: ¿Trabajarían gratis?, considerando que por muy emprendimiento que sea igual hay que cumplir con los plazos que se hayan definido.

Y sigo viendo problemas, el "gran Proyecto" es una calificación absolutamente subjetiva para una idea que no se conoce a priori.
Decir inmediatamente que no hay dinero mata al instante el posible interés de buena parte de los potenciales candidatos. No le da tiempo al emprendimiento de venderles su excelente idea y proyecto, y convencerlos que realmente vale la pena tomar el riesgo de formar parte de este equipo.

¿Cómo mejoraría el aviso?

1. Eliminar el exceso de honestidad. OK, sabemos que no hay dinero, pero no es estrictamente necesario mencionarlo, sobretodo si quieres darle la oportunidad a tu emprendimiento de convencer a los candidatos. Sin tener conocimientos formales en marketing, creo no equivocarme al pensar que el objetivo es vender la idea, convencer que es buena. Si no motivas a tus "clientes" (en este caso candidatos al puesto de desarrollador) dificilmente van a "comprar" tu idea.
2. Eliminar la promesa de CTO. Se ve bonito, pero ¿qué buscan? ¿Desarrollador o CTO o ambas?... ¿han evaluado la compatibilidad real de ambos cargos?
   Aparte, y esta es opinión 100% personal, ser CTO de un emprendimiento que aún no se concreta es ponerse un título de papel higiénico, se deshace con agua. No es algo que pondría en mi LinkedIn.
3. Ser claro en las especialidades requeridas para postular. Un profesional que maneje esta variedad de tecnologías no es un profesional barato, y posiblemente tampoco tenga demasiado tiempo disponible para dedicar a la filantropía, ergo no muy compatible con emprendimientos donde no haya un incentivo monetario.

AngularJS UI Router, resolve & Unknown service provider ERROR

La noche de ayer me quedé en la oficina terminando de corregir algunos aspectos de una aplicación. Una aplicación móvil híbrida con AngularJS, Angular UI Router y Bootstrap. El código estaba bien, pero uno de mis controladores estaba gatillando el error Unknown service provider.

Angular UI Router  permite conceptualizar una aplicación web como una máquina de estados.
Cada acción que se realiza puede ser un estado separado, y cada estado, desde el enfoque de desarrollo que estamos adoptando, tiene sus propias vistas.
A su vez, cada vista esta manejada por su propio controlador, y eventualmente antes de cargarse puede requerir que resuelva determinada petición (resolve).

Ejemplificando con código:

app.config(function ($stateProvider, $urlRouterProvider) {
    $urlRouterProvider
          .when('/', '/login')
          .otherwise('/');

    $stateProvider
        .state('login', {
            url: '/login'
            , views: {
                'login': {
                    templateUrl: 'include/login.include.html'
                    , controller: 'loginCtrl'
                }
            }
            , onEnter: function() {
                loggedin = false;
                localStorage.setItem('loggeduser', null);
            }
        })
        .state('plan', {
            url: '/plan'
            , views: {
                'menu': {
                    templateUrl: 'include/menu.include.html'
                    , controller: 'menuCtrl'
                } 
                , 'plan': {
                    templateUrl: 'include/plan.include.html'
                    , controller: 'planCtrl'
                }
                , 'client': {
                    templateUrl: 'include/client.include.html'
                    , controller: 'clientCtrl'
                    , resolve: {
                        clients: ['pouchWrapper', function(pouchWrapper){
                            var cliMap = function(doc){
                                if(doc.dbtable === 'cli'){
                                    emit(doc, null);
                                }
                            }
                            // Rescata el listado de clientes desde un repositorio local
                            return pouchWrapper.retrieveList(cliMap);
                        }]
                    }                  
                }            }           
            , onEnter: function($location) {              
                if(!loggedin){
                    console.log('No ha ingresado al sistema');                                       
                    $location.path('/logout');
                }
            }
        }) ;
});

Si se dan cuenta algunas plantillas (template) tienen indicado cual es su correspondiente controlador (controller).

Y en el controlador clientCtrl

app.controller('clientCtrl', ['$scope', '$location', 'clients', 
    function($scope, $location, clients){
        // ... aqui va mucho código
    }]);

El problema es que estando bien codificada la máquina de estados, y cargando cada vista como correspondía, AngularJS reportaba el error Unknown service provider para clients, sin indeicar origen del error ni líneas de referencia (es una maravilla depurar código a ciegas :-/ ).
Después de mucho buscar y leer en la Wiki y sección de Issues del Github de Angular UI Router, llegué a un post en StackOverflow (lo siento, perdí el enlace  original), donde explicaban que

el error se genera cuando el estado tiene el controlador referenciado tanto en la configuración como dentro de la plantilla.

En la plantilla include/client.include.html

<div data-ng-controller="clientCtrl">
    <!-- ... aquí va el contenido de la plantilla para el bloque client -->
</div>

El error lo he destacado en negrita, el controlador o está referenciado en la configuración del estado, o está referenciado dentro de la plantilla, pero NO en ambos.

Después de ver la solución, y corregir el problema (eliminando la referencia al  controlador en la plantilla) es entendible lo que está sucediendo. Si recuerdan, el controlador recibe como tercer parámetro clients (que es lo indicamos en el atributo resolve del estado, que queremos resolver antes de desplegar) . Al poner la referencia directamente en la plantilla, clients queda vacío, ergo Unknown service provider.

Yo vs emprendimientos TI

Inicialmente iba a ser un artículo lleno de argumentos y explicaciones. Era sobre mi propio enfoque y el porqué de mi incompatibilidad con los emprendimientos. Al final el éxito de un emprendimiento se resume en una sola cosa: 

SACRIFICIO.

Hace algún tiempo tuve la oportunidad de conversar en extenso con un suizo, residente en Chile. La conversación con este exitoso empresario del rubro inmobiliario pronto derivó en su visión sobre los emprendimientos en Chile.
Me comentó sobre una experiencia que tuvo con unos amigos de él. Tenían una idea muy buena, auspiciosa en cuanto al mercado y a las potenciales ganancias a obtener. Él con su experiencia les señaló:

"La idea es buena, tiene potencial, pero para poder llevarla a cabo tienen que destinar al menos 10 horas diarias para trabajar en ella."

Se podrán imaginar que la réplica fue que no podían destinar 10 horas diarias de trabajo, ya que todos los involucrados podían entregar dedicación parcial al proyecto, debido a que trabajaban jornada completa.

Me arriesgo a decir que un alto porcentaje de los emprendimientos que quedan en nada (léase sólo en la idea y las buenas intenciones) se debe a que los integrantes no pueden destinar el tiempo necesario para trabajar en el proyecto.
Lamentablemente los emprendimientos no pueden llevarse a cabo a ritmo propio o cuando tengas ganas/puedas de dedicar tiempo a ello.

Finalmente todo se reduce a SACRIFICIO. ¿Cuánto estás dispuesto a sacrificar?:

• ¿Sacrificarías no ver a las personas que amas? 
• ¿Sacrificarías horas de sueño y descanso? 
• ¿Sacrificarías dejar de ganar una remuneración por hacer lo mismo (o similar)? Nota: Puse dejar de ganar y no perder, hay una sutil diferencia.
• ¿Sacrificarías rendir en tu trabajo actual por dedicar tiempo a tu emprendimiento? y de paso asumir el costo que esto puede significar (normalmente ser despedido).

Y quedo corto en este listado. Responder NO a cualquiera de estas preguntas ya es un riesgo que no estás dispuesto a tomar.

¿Cuánto estás dispuesto a sacrificar?

¿Cuánto?

En mi caso las cuentas eran negativas, demasiadas responsabilidades en mi quehacer cotidiano, repercusiones familiares, costo de oportunidad descompensado y una que por donde la mirara tenía demasiado peso. Después de una jornada de 8 horas diarias frente a un computador, resolviendo problemas de las más variadas especies, física y mentalmente termino disminuido para seguir haciendo lo mismo en casa (fuera de horario).

Hay que ser sincero con uno mismo y no tratar de auto-convencerse con falsas ilusiones. Las charlas TED y de la universidad suenan muy lindas y convincentes, pero llevarlas a la práctica dependerá de realidad personal de cada uno.

Spring REST Services y el error Required String parameter is not present

Desarrollando una API REST utilizando Spring MVC, y consumiéndola con AngularJS, me enfrenté al problema "Required String parameter is not present". Así es como lo solucioné.

Hace poco "vendí" (en rigor sólo convencía  mi jefe que es buena idea tomar este enfoque) una idea para abordar nuevos desarrollos. Consiste en desarrollar una API REST, utilizando el generador de código Telosys, y generar las interfaces con HTML5, CSS3 y JavaScript de modo de consumir los servicios con AngularJS.
Nada nuevo dirán, pero ofrece la ventaja que el mismo desarrollo web puede ser portado sin demasiado esfuerzo a una aplicación móvil usando Phonegap, o bien a una aplicación de escritorio utilizando Node-Webkit.

Este tipo de desarrollo resulta bastante rápido, y si logras una combinación entre Angular-UI-router y plantillas web con controladores propios (los controllers de AngularJS), se obtiene una modularidad bastante atractiva.

El problema

El código no tenía problemas, pero al tratar de realizar una llamada POST con Restangular a pesar de que el JSON con los datos que debía recibir la petición estaba bien construido, la llamada arrojaba el error:

Required String parameter 'usr' is not present

Soluciones propuestas

De las soluciones propuestas, después de realizar muchas búsquedas, ninguna funcionó:

• Forzar que todas las peticiones POST indicaran en sus headers
  Content-Type = 'application/x-www-form-urlencoded' con el código:
• $httpProvider.defaults.headers.post['Content-Type'] = 'application/x-www-form-urlencoded';   
• Agregar el atributo enctype="application/x-www-form-urlencoded" a la etiqueta form.
• Realizar la llamada con AngularJS nativo vs usar Restangular.

Hasta pensé en cambiar el enfoque y usar HATEOAS, pero significaba realizar demasiados cambios a la aplicación (en rigor regenerar el código, Telosys se encarga del trabajo sucio).

Solución

Dí con este artículo de StackOverflow, donde explican que el servicio debe recibir un objeto que tenga todos los parámetros de la petición. Algo como:

@RequestMapping(value = "events/add", method = RequestMethod.POST)
public void addEvent(@RequestBody CommandBean commandBean){
    //some code
}

donde se debe indicar que el objeto (puede ser un POJO) CommandBean es el  @RequestBody. Y Spring se encargará de capturar los parámetros adecuadamente.
Y eso funcionó sin problemas.

GulpJS amistoso con AngularJS

Hace poco después de mi lectura diaria descubrí GulpJS. Es una simpática herramienta de línea de comando que permite optimizar muchas cosas del desarrollo web, desde la minimización de imágenes, hasta la "liposucción de código" como le llamamos en la oficina al proceso de eliminar comentarios y mensajes de debug.
El resultado normalmente es un archivo .js minimizado, un archivo .css también minimizado, e imágenes y archivos .html "optimizados".

No les voy a enseñar a usarlo, eso lo pueden ver en detalle en los siguientes enlaces (todos en inglés):

• Why I like GulpJS more than GruntJS 
• Quick intro to Gulp.js
• Y obviamente en Google ;)

Los primeros problemas a los que me enfrenté fueron básicamente que las configuraciones por defecto son muy agresivas, por lo que mis HTMLs quedaron sin algunos atributos necesarios para que mis controladores Angular funcionaran, y que derechamente mis controladores Angular dejaron de funcionar.

Después de leer algo de documentación para revisar las opciones de los plugins de Gulp que decidí usar, y trás algunas pruebas, llegué al siguiente código, que me ha arrojado los mejores resultados:

// Include gulp
var gulp = require('gulp'); 

// Include Our Plugins
var jshint = require('gulp-jshint');
var concat = require('gulp-concat');
var changed = require('gulp-changed');
var uglify = require('gulp-uglify');
var rename = require('gulp-rename');
var stripDebug = require('gulp-strip-debug');

// Lint Task
gulp.task('lint', function() {
    return gulp.src('js/*.js')
        .pipe(jshint())
        .pipe(jshint.reporter('default'));
});

// Concatenate & Minify JS
gulp.task('scripts', function() {
    return gulp.src(['js/angular.min.js', 'js/Directive/bindonce.min.js', 'js/jquery-2.0.3.min.js', 'js/bootstrap.min.js',  'js/app.js', 'js/*.js', 'js/Service/*.js', 'js/Filter/*.js', 'js/Directive/*.js', 'js/Controller/*.js'])
        .pipe(concat('appjs.js'))
        .pipe(stripDebug())
        .pipe(gulp.dest('dist'))
        .pipe(rename('app.min.js'))
        .pipe(uglify({ mangle: false }))
        .pipe(gulp.dest('dist'));
});

// include plug-ins
var minifyHTML = require('gulp-minify-html');
 
// minify new or changed HTML pages
gulp.task('htmlpage', function() {
  var htmlSrc = '*.html',
      htmlDst = 'dist';
 
  gulp.src(htmlSrc)
    .pipe(changed(htmlDst))
    .pipe(minifyHTML({ empty: true, spare:true, quotes: true }))
    .pipe(gulp.dest(htmlDst));
});

// include plug-ins
var autoprefix = require('gulp-autoprefixer');
var minifyCSS = require('gulp-minify-css');
 
// CSS concat, auto-prefix and minify
gulp.task('styles', function() {
  gulp.src(['css/bootstrap.min.css', 'css/*.css'])
    .pipe(concat('styles.min.css'))
    .pipe(autoprefix('last 2 versions'))
    .pipe(minifyCSS())
    .pipe(gulp.dest('dist'));
});

// default gulp task
gulp.task('default', ['htmlpage', 'scripts', 'styles'], function() {
});

Lo único que no pude resolver a través de parámetros (y si alguien lo sabe se agradece si comparten el dato) fue el hecho que el plugin minify-html se "come" mis espacios en blanco intencionales (a veces necesarios) y los atributos que no tienen valor (como el bindonce). Tan grave no es si sabes donde ponerlos de vuelta, pero eso ya es parte del trabajo manual.

¿Es el fin de las aplicaciones de escritorio?

Hace poco me encomendaron  el desarrollo de un sistema de software. Inicialmente pensé en usar Java, pero terminé con algo "más web".

Cuando nos enfrentamos al desarrollo de software, aparte del diseño acorde a la captura de requerimientos que se haya realizado, y las interfaces de usuario; entre muchas otras cosas; se debe escoger la tecnología adecuada.

La elección de que tecnología utilizar normalmente va ligada a la instalación, vale decir en las características de la máquina del cliente donde se instalará la aplicación. En la propuesta inicial pensé en realizar el desarrollo usando Java y una base de datos H2. Logré un avance para la generación medianamente rápida de la GUI, sin embargo me di cuenta que para conseguir interfaces de usuario sencillas, y por sobretodo intuitivas, Java me limitaba demasiado, aún considerando Swing, JavaFX y muchas otras librerías de terceros que entregan infinitas alternativas.

La alternativa:

Hacer un desarrollo "más web", vale decir desarrollar el FrontEnd en HTML y el backend en modo "servidor". Entre las elecciones "lógicas" estaba utilizar un servidor Apache Tomcat, un Jetty, o algo para contener JSP y Servlets, o usar Apache (o similar) con PHP.
El problema de esas opciones es que el computador huésped, la máquina del cliente y usuario final, de una u otra manera termina convirtiéndose en un servidor, eso sin considerar la cantidad de dependencias que se deben considerar:

• JDK de Java
• Servidor web
• Motor de base de datos
• Plugins varios
• etc.

Pensé ¿.NET será una alternativa? y el problema es similar al de Java, necesitas previamente instalar muchas dependencias. Si el PC del cliente no tiene todo lo necesario, una aplicación que pesa un par de megas significa finalmente descargar sobre 40 MB de instaladores anexos. ¿Cómo evitamos eso?

De vuelta al enfoque inicial

¿Una WebApp local quizás? Con eso se soluciona el peso de la aplicación, aunque hay 2 problemas:

1. El almacenamiento de datos usando WebDB está limitado a las restricciones del navegador que se utilice. Eso y los riesgos que el usuario utilice distintos navegadores, generando inconsistencias en la información, o que haga una limpieza agresiva del caché del navegador (lo que eliminaría la BD).
2. La versión del navegador es un elemento que no se puede ignorar, y créanlo, aún hay usuarios de Internet Explorer 6...

Busqué alternativas disponibles, y ahorrándoles el proceso de análisis y selección de la a mi parecer mejor, finalmente llegué a node-webkit.
Aprovechando mi reciente incursión con Node.js decidí hacer algunas pruebas, que luego de resolver un par de problemas han resultado en una aplicación que cumple todas mis expectativas. Lo que utilicé:

• Bootstrap para las interfaces.
• Fontello para los íconos de la aplicación.
• Angular y jQuery para la lógica de aplicación.
• node-webkit para embeber Node.js y poder generar una aplicación ejecutable "tipo escritorio" pero con "olor a web".
• Sequelize y SQLite para la capa de persistencia y la base de datos.

Y una vez llegado a esto empiezo a cuestionar que tanto vale la pena desgastarse tratando de hacer una aplicación de escritorio, con miles de dependencias y limitaciones. Más considerando que hoy en día todo avanza hacia convertirse en Web:

• La comunicación entre las personas se vuelve más y más Web, sólo piensen en las redes sociales.
• La experiencia de juego cada vez se enlaza más a la Web.
• Aplicaciones móviles desarrolladas de manera híbrida, vale decir HTML5+CSS3+JavaScript+API nativas. Phonegap lleva mucho avanzado en esta línea.
• Las aplicaciones de Windows 8, que muchas veces están desarrolladas 100% usando tecnologías web.
• Los temas de escritorio de GnomeShell utilizan CSS para muchas de sus definiciones.
• Muchos widgets de escritorio de cada uno de los distintos sistemas operativos
• El mismo Node.js que es JavaScript en el servidor.
• Me arriesgaría a decir que más del 90% de los desarrollos de Google.

Incluso escalar este el modelo de aplicación de escritorio web no es tan difícil, pensando en un escenario en el que se decida masificar el uso de la aplicación en la organización.

Estoy claro que esta línea puede no ser la respuesta a todos los problemas que podemos enfrentar en desarrollo de software, pero al menos a mi me hace dar una segunda mirada cada vez que me hablan de desarrollar una aplicación de escritorio.

Si tienen dudas sobretodo respecto a como resolver la persistencia de datos con node-webkit, Sequelize y SQLite no duden en hacerlas.