domingo, 15 de enero de 2017

Ubuntu Server en Oracle VirtualBox


Introducción.

En este post, detallaremos los pasos necesarios para tener disponible Ubuntu server (16.04 LTS) en VirtualBox 5.0.30r.

Ubuntu es actualmente una de las distribuciones Linux más populares y de gran alcance; pero, no siempre es nuestro sistema operativo de uso diario, o, sólo queremos usarlo periódicamente.
Por ello es que, muy probablemente, esta configuración puede ser de utilidad.
Para que puedas ejecutar virtualBox sin problema, asegúrate de temer al menos 2GB de memoria RAM.

Descargar Oracle VirtualBox

Primero descargaremos VirtualBox, VirtualBox es una herramienta para virtualización, hay instaladores para Windows, Linux y Mac, y es patrocinado por Oracle.

Puedes descargarlo en: https://www.virtualbox.org


Puedes validar la instalación, ejecutando VirtualBox y revisando el "about/acerca de...".


Ahora, descargaremos la imagen ISO de UbuntuServer.

Descargar Imagen (ISO) de Ubuntu Server.

Podemos descargar una imagen de Ubuntu server en la siguiente URL:
https://www.ubuntu.com/download/server


Hacemos click en Download y, debe de comenzar la descarga del archivo.
Para este ejercicio usaremos la versión para AMD: ubuntu-16.04.1-server-amd64.iso
Puedes ver las distintas versiones para descargar haciendo click en  "Alternative download and torrents".


  • ubuntu-16.04.1-server-amd64.iso
    • 699400192 bytes (Aprox. 699.4 MB)

Una vez que esté descargado completamente, estamos listos para continuar con el proceso.

Instalar Ubuntu Server a partir de la imagen.

La intención de bajar el .iso es que, haremos una instalación desde cero, pero, será una instalación virtualizada.

Crear nueva maquina virtual.

Iniciamos abriendo VirtualBox e indicando que queremos crear una nueva maquina virtual:


El botón [New] que se encuentra en la parte superior derecha de la ventana principal de VirtualBox es la manera de iniciar este proceso.

La primera ventana nos solicita los siguientes datos:

Name: UbuntuServer1604_64bits
Type: Linux
Version: Ubuntu (64 bits)

Procura utilizar un nombre que te ayude a reconocer la maquina virtual, por lo general, llega un momento en que se tienen varias y es posible que llegues a confundirte.


La siguiente ventana nos pide que indiquemos la máxima cantidad de memoria RAM que puede utilizar nuestra VM, si bien se indica una cantidad recomendada (768 MB), el valor estará más en función de la utilidad que le darás a esta VM.

Para este ejercicio le daremos: 4GB


En la siguiente pantalla debemos indicar que, queremos crear un nuevo disco duro virtual.

Al hacer click en [Create] inicia otro proceso cuyo objetivo es crear dicho disco duro.

Elegimos primero el tipo de disco duro, debe ser: VDI.

Hacemos click en [Continue]

A continuación debemos elegir que tipo de almacenamiento tendrá este nuevo disco duro, para efectos de este ejercicio usaremos un tamaño fijo.

Si tu intención va más allá de tener ubuntu para hacer pruebas pequeñas y/o lo piensas instalar muchas más cosas de las que ahora recuerdes, mejor intenta con [Dynamic allocated].

Nosotros seguimos con [Fixed Size].




La siguiente pantalla nos pide ubicación del disco duro virtual y cual será el tamaño del mismo.
La ubicación la dejaremos con su valor por default, y el tamaño del disco duro nuevamente dependerá del destino de esta VM.

Dejaremos el valor por default, si ya tienes claro que vas a instalar, puedes aumentar el valor.
A fin de cuentas, siempre puedes volver a crear una nueva VM  ;) .

Hacemos click en [Create].

Esto inicia la creación del disco duro virtual.



Nuestra VM ya esta creada, pero aún no está lista para ser utilizada.

De momento ya debe aparecernos en el listado de VMs disponibles,  debemos seleccionarla y hacer click en [Settings].


Al hacer click en [Settings] nos aparece un nuevo cuadro de diálogo con varias opciones, debemos elegir [Storage].

Aquí lo que vamos a hacer es, seleccionar el disco duro que recién hemos definido ( por eso está en vacío/empty).
Lo seleccionamos y en la parte derecha, haciendo click en el icono del CD, debemos indicar que queremos definir un Disco virtual (nuestro ISO).



Ya sólo debemos elegir el archivo que bajamos al inicio de este post desde el sitio de Ubuntu.


Una vez hecho esto, ya podemos arrancar nuestra VM con ubuntu.
Seleccionamos nuestra VM de la lista de la derecha y hacemos click en [Start/Iniciar].




Lo que sigue ahora es instalar UbuntuServer en esta VM.

Elige el idioma que quieres para realizar la instalación.

Y arrancamos:


Nuevamente idioma:


La ubicación:


El char-set:

El teclado:





Aquí ya inicia el proceso de instalación.

La siguiente pantalla después de que se ejecutan las configuraciones iniciales es la que nos pide el nombre que tendrá el servidor.

Le pondremos: ubuntuServer



Ahora, debemos crear el usuario de trabajo inicial(tareas no administrativas).

La instalación nos pide primero el nombre real del usuario.

Usaremos: Isaac Ruiz Guerra


Luego nos pide el username de acceso.
Usaremos: rugi




Ahora el pwd; asegúrate de no olvidarlo.


La instalación ahora nos pide que indiquemos si queremos o no cifrar el directorio home.
Es a gusto del cliente, para este ejemplo indicaremos que: no.



Ahora la configuración del reloj (ya falta poco).

Por fin, nos pide indiquemos que partición usaremos.
Dado que para eso creamos el disco duro virtual, indicaremos que use toda la partición.






Por fin inicia la instalación per se.


Una vez terminada la instalación de los paquetes principales, la instalación pide que le indiquemos si queremos actualizar o instalar paquetes adicionales.

Esto se puede realizar después, así que, continuaremos para concluir con la instalación.

Al finalizar la instalación nos debe aparecer una ventana indicándonos que debemos remover el dispositivo que usamos para el arranque y así evitar que el instalador cargue nuevamente.


Hacemos click en [Continue]

Al hacer esto, iniciará automáticamente la carga del sistema operativo.

Al finalizar la carga, nos pide primeramente el usuario:

Y después el pwd.
Dando de estrada estos valores, podemos ya estar firmados en nuestro UbuntuServer.


Listo.

Tenemos una VM con Ubuntu Server 16.04 lista para ser utilizada desde nuestro VirtualBox.

Ahora, podemos seguir con nuestro sistema operativo principal y comenzar a usar UbuntuServer cuando sea necesario. ;)

Saludos
---
@RuGI


Este documento está basado en: http://www.psychocats.net/ubuntu/virtualbox

sábado, 9 de julio de 2016

Artículos en OTN en Español.


Listado de artículos publicados en OTN en Español.
---
RuGI

domingo, 6 de septiembre de 2015

[4 de 97]. A perfeição é inimiga do bom o suficiente.

“‘Perfect’ is the Enemy of ‘Good Enough’”


A rigor e com toda a honestidade, a frase completa é: "A ‘perfeição’ é inimiga do ‘bom o suficiente’", e ela é creditada igualmente a Voltaire e a Leonardo Da Vinci.


mandala.png


Aqui um extrato do que ele escreve no livro 97 things Every Software Architech Should Know:
---


Software designers, and architects in particular, tend to evaluate solutions by how elegant and optimum they are for a given problem. Like judges at a beauty contest, we look at a design or implementation and immediately see minor flaws or warts that could be eliminated with just a few more changes or re-factoring iterations.  Domain models simply beg for one more pass to see if there are any common attributes or functions that can be moved into base classes. Services duplicated in multiple implementations cry out their need to become web services. Queries complain about "buffer gets" and non-unique indexes and demand attention.

My advice: Don't give in to the temptation to make your design, or your implementation, perfect! Aim for "good enough" and stop when you've achieved it.

Remember that application development is not a beauty contest, so stop looking for flaws and wasting time chasing perfection.


---


Eu pensei em iniciar dessa forma a revisão dessa regra, quando me lembrei que no podcast de JavaHispano #36; durante a entrevista com Eduardo Pelegri (responsável pelo Glassfish), enquanto comentava sobre a especificação inicial das JSP’s  lhe perguntaram o que ele achava dessa especificação e como tinham chegado a ela.


Eis aqui uma transcrição de suas palavras.


“Uma especificação que é tecnicamente perfeita, mas não tem apoio na indústria, é inútil….
Você tem que ter uma especificação que é tecnicamente válida…
Não é só questão de dizer:
‘Esta é a melhor especificação que eu poderia fazer’
senão:
'Esta é a melhor especificação que todos poderíamos fazer juntos”
Entrevista com Eduardo Pelegri por Abraham Otero (10:12min)


Eu imagino vários gurus reunidos tentando chegar a um acordo sobre como deveria ser a especificação (minha mente geek vê-los como uma reunião de Ent’s), eu imagino todos  tentando obter uma especificação que considerasse a melhor de suas propostas. Eu também imagino como seria difícil chegar a um acordo em que provavelmente mais de um deles tivesse que subjugar seu ego para permitir que outras propostas fossem aceitas.


Se cada um tivesse agarrado com unhas e dentes o seu ideal de perfeição provavelmente a especificação teria levado mais tempo para sair e talvez a história seria outra.


Neste ponto você está ciente de tudo o que a regra adverte:
não é apropriado aferrar-se ou alienar-se para obter um aplicativo ou um fragmento de código perfeito, e melhor ajudar a preencher esse tempo com coisas que poderiam dar mais valor ao nosso aplicativo.


  • Quanto? Ou quanto tempo isso é o bastante?
  • Como saber que já temos o suficiente?
  • Em que medida devemos parar de busca a perfeição?


Eu acho que o principal indicador é o tempo gasto procurando por essa perfeição.


Se esse tempo que investimos em pesquisar, refatorar e maquiar nosso código à procura de perfeição mais do que o tempo necessário para:
  • Adicionar novas funcionalidades para o nosso aplicativo.
  • Corrigir erros de alto impacto.
  • Enfrentar novos requisitos.


...É hora de parar e aceitar que já temos dado uma boa ou suficiente solução para o que solicitaram.


Eu fico com a última frase de G. Nyberg que diz:
“Lembre-se que o desenvolvimento de aplicativos não é um concurso de beleza, assim que pare de procurar defeitos e pare de perder tempo perseguindo a perfeição.”


Afinal de contas, é difícil agradar a todos.... não é? ;)


clean_code.jpg
---


---------------------
Créditos:
A imagem é de: J Eberl
A imagem da porta aparece no livro:
---------------------

sábado, 29 de agosto de 2015

WebSocket. Una visión general.


Hace unos minutos tuve el gusto y honor de terminar mi presentación en el JavaDayMX 2015 realizado en la ciudad de Guadalajara, México.

El instituto tecnológico de estudios superiores de occidente. (ITESO) fue la sede de este evento.

Esta ocasión decidí hablar sobre websocket's, un tema que si bien no es nuevo, sí es poco conocido aún, y, desde mi perspectiva una tecnología con mucho futuro (sí, también con muchos retos pero con futuro).

La presentación la hice con remark, y aquí está en link para que puedan verla:


Espero les sea de utilidad.
:)

---
@RuGI

lunes, 17 de agosto de 2015

[3 de 97]. Controlar os dados, não só ao código.

“Control the data, no just the code.”




Eli diz (extraído do livro  "97 things Every Software Architech Should Know"):


---
Control de data, no just de code.
Source code control and continuous integration are excellent tools for managing the application build and deployment process. Along with source code, schema and data changes are often a significant part of this process and thus warrant similar controls. If your build and deployment process includes a list of elaborate steps required for data updates, beware.


....


Database changes shouldn’t create a ripple in your build’s time-space continuum. You need to be able to build the entire application, including the database, as one unit. Make data and schema management a seamless part of your automated build and testing process early on and include an undo button; it will pay large dividends. At best it will save hours of painful, high-stress problem solving after a late night blunder. At worst it will give your team the ability to confidently charge forward with refactoring of the data access layer.
---


Eu acho que antes a gente  não dava muita importância ao banco de dados (a partir da nossa  perspectiva de desenvolvedor), porque era uma tarefa, no melhor dos casos entediante, e na pior das hipóteses muito complexa para explicar aos clientes.


Mas à medida que nós participamos em projetos, descobrimos que o sucesso desses projetos começa com uma boa definição da camada de dados.


Também, conforme têm evoluído as metodologias e técnicas para o desenvolvimento e integração dos aplicativos, e com o advento dos métodos ágeis, eu acho que chegou a hora de dar aos bancos de dados o seu devido lugar na foto.


Um dos meus piores pesadelos sempre foi o de atualizar  uma tabela (parâmetro) e ao fazer COMMIT perceber que eu esqueci a cláusula WHERE,
Uma catástrofe !!!


Felizmente, ter um script para preencher inicialmente as tabelas de configuração sempre dão a tranquilidade de saber que você pode voltar ao último “estado correto”.


E esses scripts não estão sozinhos, temos também scripts para:
  • Criar / Apagar tabelas.
  • Criar / Apagar procedimentos armazenados (store procedures).
  • Criar / Apagar sequências
  • etc, etc.


E há um tipo de script que sempre fica no esquecimento: os scripts de migração ou de backup do banco de dados.


Se você ainda não esteve em uma conferência por telefone onde todo mundo está à beira da histeria, porque ninguém sabe o que faltou ao migrar para a nova e brilhante base de dados recém adquirida (por muitos milhares em $), leve sempre em conta a seguinte pergunta:


>>> Cara,  será que você não se esqueceu de migrar os store-procedure e  os triggers?


Se isso realmente acontecer, haverá um grande silêncio.
E o gerente de plantão dirá:
>>> Bem, vamos rever isso e, em seguida, a gente te liga.


Essa ligação nunca chega ;)


Enfim de volta ao ponto de partida, nestes tempos em que necessitamos ser mais ágeis, é uma boa ideia considerar essas estratégias para ter um pouco mais de controle sobre o nossos aplicativos e  criar um ambiente de desenvolvimento mais saudável e menos estressante .


Depois de tudo isso, só resta uma dúvida:


Você levou em conta os scripts de dados para fornecer uma solução integral para as suas aplicações?


Saudações!!


---


----------------------------------------------------- Autor da foto acima: brunociampi https://www.flickr.com/photos/brunociampi/2745217216
------------------------------------------------------

sábado, 1 de agosto de 2015

[2 de 97]. Comece com um esqueleto funcional.

“Start with a walking skeleton”.

Clint Shank


Seguindo os comentários do livro:
97 things Every Software Architech Should Know.

---
Start with a walking skeleton.

One very useful strategy for implementing, verifying, and evolving an application architecture is to start with what Alistair Cockburn calls a Walking Skeleton . A Walking Skeleton is a minimal, end-to-end implementation of the system that links together all the main architectural components. Starting small, with a working system exercising all the communication paths, gives you confidence that you are heading in the right direction.

Once the skeleton is in place, it's time to put it on a workout program. Bulk it up with full body workouts. This means implement incrementally, adding end-to-end functionality. The goal is to keep the system running, all the while growing the skeleton.
---

Esta estratégia é uma das minhas favoritas, especialmente para integrações muito complexas ou que tenham uma média ou grande equipe  de desenvolvedores.

Concordo plenamente com o comentário de Clint Shank, em pequenos desenvolvimentos uma pessoa pode fazer tudo da sua própria maneira e não precisa  desse tipo de estratégia.

A ideia é simples, você deve alcançar um esqueleto funcional que vá de uma extremidade a outra da integração.

O objetivo também  é simples,   verificar que o caminho seja eficiente e  descobrir oportunamente as implicações que podem ter construí-lo, fortalecê-lo, modificá-lo.


Os objetos e serviços mock podem ajudar muito com esta estratégia.

Imagine um cenário hipotético, mas muito comum, temos de fazer a integração de vários sistemas, incluindo: um serviço de nível muito baixo (que ainda não tenha sido criado) passando por uma transformação dos dados (não totalmente definidos) seguida por uma tradução (um pouco confusa) e terminando com uma visualização dos dados (ainda em desenho).

Nosso esqueleto usaria objetos mock para:

  • Simular a invocação de serviços para o nível mais baixo.
  • Simular a transformação de dados, que receba a saída do passo anterior como entrada para este passo.
  • Traduzir um conjunto de dados válidos, mas arbitrários e retornar o formato esperado pela camada superior.
  • Mostrar o componente de visualização de dados com os dados arbitrários.


E o nosso esqueleto está completo. :)

A partir desse esqueleto pudemos crescer e fortalecer o nosso aplicativo, sem afetar  significativamente as camadas superiores. A construção do esqueleto nos ilumina o necessário para saber o custo de modificar qualquer um dos pontos de conexão;  de cada "bone" do esqueleto.
E saber o custo, ajuda a definir pontos de conexão mais fáceis de serem trocados.

E você?

Quantos esqueletos já encontrou pelo caminho?
Somente contam os que vemos no início, os que vemos ao final do projeto nem os mencione.

;)

---
RuGI Isaac Ruiz Guerra.

-----------------------------------------------------
Autor da foto acima: germeister
------------------------------------------------------