Tras tres años programando en la plataforma Android esta es la película de mi vida como Android Developer, un conjunto de buenas practicas y conceptos necesarios que aún a día de hoy sigo viendo que no se cumplen en la mayoría de proyectos con los que me cruzo. Son la conclusiones sacadas de mi experiencia y de multitud de debates con compañeros. Se abordan temas como: fragmentación, uso de la clase Context, naming, maquetación en Android, memory leaks y S.O.L.I.D.
Paso a paso explico como estructurar nuestros proyectos para ir solucionando y separando problemas para ver finalmente como la foto general de lo que hemos montado coincide con los principios de Clean Architecture y como esto nos ayuda a construir un software más solido, extensible y refactorizable.
Esta charla comprende las lecciones aprendidas convirtiendo la app de Android de Teambox (una app repleta de deuda técnica y con un alto nivel de acoplamiento entre clases), en la versión actual de Redbooth, que intenta cumplir la arquitectura Hexagonal y los principios SOLID. Durante la exposición explicaremos como fuimos desenredando el código paso a paso; como aplicamos por partes los conceptos de la arquitectura hexagonal; como dejamos de lado componentes del framework de Android que dificultaban el mantenimiento de la app; y que errores cometimos, como los solucionamos y como se podrían haber evitado.
Paso a paso explico como estructurar nuestros proyectos para ir solucionando y separando problemas para ver finalmente como la foto general de lo que hemos montado coincide con los principios de Clean Architecture y como esto nos ayuda a construir un software más solido, extensible y refactorizable.
Esta charla comprende las lecciones aprendidas convirtiendo la app de Android de Teambox (una app repleta de deuda técnica y con un alto nivel de acoplamiento entre clases), en la versión actual de Redbooth, que intenta cumplir la arquitectura Hexagonal y los principios SOLID. Durante la exposición explicaremos como fuimos desenredando el código paso a paso; como aplicamos por partes los conceptos de la arquitectura hexagonal; como dejamos de lado componentes del framework de Android que dificultaban el mantenimiento de la app; y que errores cometimos, como los solucionamos y como se podrían haber evitado.
Comenzamos con lo básico, la creación del primer proyecto en Android Studio.
Creación del Proyecto
Vistade Diseño y Código
Depuración y Ejecución del Proyecto
Enlace a guía de instalación de drivers para depurar en dispositivo físico.
A monitoring system is arguably the most crucial system to have in place when administering and tweaking the performance of any database system. DBAs also find themselves with a variety of monitoring systems and plugins to use; ranging from small scripts in cron to complex data collection systems. In this talk, I’ll discuss how Box made a shift from the Cacti monitoring system and other various shell scripts to OpenTSDB and the changes made to our servers and daily interaction with monitoring to increase our agility in identifying and addressing changes in database behavior.
HBaseCon 2012 | Lessons learned from OpenTSDB - Benoit Sigoure, StumbleUponCloudera, Inc.
OpenTSDB was built on the belief that, through HBase, a new breed of monitoring systems could be created, one that can store and serve billions of data points forever without the need for destructive downsampling, one that could scale to millions of metrics, and where plotting real-time graphs is easy and fast. In this presentation we’ll review some of the key points of OpenTSDB’s design, some of the mistakes that were made, how they were or will be addressed, and what were some of the lessons learned while writing and running OpenTSDB as well as asynchbase, the asynchronous high-performance thread-safe client for HBase. Specific topics discussed will be around the schema, how it impacts performance and allows concurrent writes without need for coordination in a distributed cluster of OpenTSDB instances.
Comenzamos con lo básico, la creación del primer proyecto en Android Studio.
Creación del Proyecto
Vistade Diseño y Código
Depuración y Ejecución del Proyecto
Enlace a guía de instalación de drivers para depurar en dispositivo físico.
A monitoring system is arguably the most crucial system to have in place when administering and tweaking the performance of any database system. DBAs also find themselves with a variety of monitoring systems and plugins to use; ranging from small scripts in cron to complex data collection systems. In this talk, I’ll discuss how Box made a shift from the Cacti monitoring system and other various shell scripts to OpenTSDB and the changes made to our servers and daily interaction with monitoring to increase our agility in identifying and addressing changes in database behavior.
HBaseCon 2012 | Lessons learned from OpenTSDB - Benoit Sigoure, StumbleUponCloudera, Inc.
OpenTSDB was built on the belief that, through HBase, a new breed of monitoring systems could be created, one that can store and serve billions of data points forever without the need for destructive downsampling, one that could scale to millions of metrics, and where plotting real-time graphs is easy and fast. In this presentation we’ll review some of the key points of OpenTSDB’s design, some of the mistakes that were made, how they were or will be addressed, and what were some of the lessons learned while writing and running OpenTSDB as well as asynchbase, the asynchronous high-performance thread-safe client for HBase. Specific topics discussed will be around the schema, how it impacts performance and allows concurrent writes without need for coordination in a distributed cluster of OpenTSDB instances.
Primer artículo de la serie El Archipiélago Eclipse.
Esta serie expone qué es Eclipse, cuál es su estructura, en qué se diferencia o se asemeja a otros productos ya existentes, cuáles son sus ventajas e inconvenientes, cuál podría ser su utilidad para los desarrolladores (centrándose en la comunidad Java), qué estrategias empresariales subyacen bajo el proyecto Eclipse y cuál podría ser su futuro.
Autor: Miguel Ángel Abián
Publicado originalmente en javaHispano.
Node.js
Code Blast 2012 en el marco de charlas de por la Semana de la Ingeniería de la Universidad Tecnológica Nacional, Facultad Regional Tucumán.
Juan Maria Martinez Arce compartió un poco de sus investigaciones en el uso de node.js para la creación de aplicaciones de red de alta concurrencia.
Slidedeck de la charla que "Consejos de un perro viejo programador"
Hola me llamo Braulio y llevo más de 34 años programando (más de 20 años como profesional), en este tiempo me ha tocado
trabajar con un montón de tecnologías y proyectos: basic, pascal, ensamblador, cobol, clipper, delphi, c++, mfc, c# / .net framework, winforms,
asp .net web forms, silverlight, asp .net mvc, javascript, typescript, angularjs, react, ...
Después de tantos años sin colgar el ratón, me gustaría compartir contigo varias cosas que creo que me han sido
útiles, en esta charla vamos a tocar muchos palos :):
- Carrera.
- Toma de requerimientos, proyectos y estimaciones.
- Arquitectura.
- Código.
Ponente: Braulio Diez @braulio_sl
LLevo un montón de años programando (empezé en 1985, y como profesional en 1998), he trabajado con muchas tecnologías y proyectos de muchos tipos.
En 2010 me monté por mi cuenta, soy uno de los fundadores de Lemoncode Formación y de BaseFactor (consultoría).
Me dedico sobre todo a Front End, y echo un cable a otras empresas a aprender y llevar adelante proyectos front
desarrolladores con React, Redux, Typescript, ES6...
Si nos queréis seguir, nuestras cuentas de twitter son:
@braulio_sl
@lemoncoders
@basefactorteam
Si bien los hospitales conjuntan a profesionales de salud que atienden a la población, existe un equipo de organización, coordinación y administración que permite que los cuidados clínicos se otorguen de manera constante y sin obstáculos.
Mario García Baltazar, director del área de Tecnología (TI) del Hospital Victoria La Salle, relató la manera en la que el departamento que él lidera, apoyado en Cirrus y Estela, brinda servicio a los clientes internos de la institución e impulsa una experiencia positiva en el paciente.
Conoce el Hospital Victoria La Salle
Ubicado en Ciudad Victoria, Tamaulipas, México
Inició operaciones en el 2016
Forma parte del Consorcio Mexicanos de Hospitales
Hospital de segundo nivel
21 habitaciones para estancia
31 camas censables
13 camillas
2 quirófanos
+174 integrantes en su plantilla
+120 equipos médicos de alta tecnología
+900 pacientes atendidos
Servicios de +20 especialidades
Módulos utilizados de Cirrus
HIS
EHR
ERP
Estela - Business Intelligence
Escaneo y eliminación de malware en el equiponicromante2000
El malware tiene muchas caras, y es que los programas maliciosos se reproducen en los ordenadores de diferentes formas. Ya se trate de virus, de programas espía o de troyanos, la presencia de software malicioso en los sistemas informáticos siempre debería evitarse. Aquí te muestro como trabaja un anti malware a la hora de analizar tu equipo
5. EL Porqué DE ESTA PONENCIA
¡Sube, Marty!
¡El cliente quiere un proyecto para ayer!
Equipos con poca experiencia.
Problemas para optimizar y corregir.
Repetimos los mismos errores.
No aplicamos Unit Testing.
No hay excusas.
YOU ARE YOUR CODE but...
It's easy to hate code you didn't write, without an
understanding of the context in which it was written.
(Martin Fowler)
6. La REALIDAD
Un proyecto no dura mucho…
Un proyecto no dura poco…
Dura exactamente lo que se necesita.
COMO MíNIMO
(Gandalf en una stand up de SCRUM)
8. ¿CÓmo LO HAGO?
Kaizen 改善
(Mejora continua)
Done is better than perfect.
Si tras 6 meses tu código no te da
vergüenza, no lo estás haciendo bien.
(PROGRASTOTOLES 499 a.c)
11. Naming
Mi nombre es Íñigo Montoya
¡El que sea, pero aplica uno!
Identifica actores del framework.
Identifica patrones.
Respeta los nombres comunes y crea los tuyos.
Aplícalo en todos los niveles.
Muy importante en los recursos.
16. Architecture
MVC, MVP, Clean Architecture,
Ports and Adapters...
Usa la arquitectura que quieras,
pero aplica S.O.L.I.D.
(Barroso dixit)
Te permitirá aplicar TESTING unitario.
https://www.youtube.com/watch?v=I0qDmbwGz3o [Fernando Cejas]
https://www.youtube.com/watch?v=EwcrTVmu7f4 [Jorge Barroso]
Te conducirá a aplicar PATRONES.
https://www.youtube.com/watch?v=tt3zI9cKiWU [Pedro Vicente]
Hará tu app más sólida y ESCALABLE.
https://www.youtube.com/watch?v=ROdIvrLL1ao [Jorge Barroso]
https://www.youtube.com/watch?v=N6yqe88ysNw [Pedro Vicente]
17. S.O.L.I.D.
The Single responsibility principle
The Open closed principle
The Liskov substitution principle
The Interface segregation principle
The Dependency inversion principle
18. S.O.L.I.D.
Principio de Responsabilidad Única
“Una clase debería tener una y sólo
una razón para cambiar”
(Robert C. Martin)
Un objeto debe tener una única
responsabilidad.
Contraejemplo: The God Activity
19. S.O.L.I.D.
Principio Abierto / Cerrado
Todo módulo debe estar abierto
para la extensión, pero cerrado
para la modificación.
Contraejemplo: El Adapter pintalotodo
20. S.O.L.I.D.
Principio de Sustitución de Liskov
“Si parece un pato y grazna como un pato,
pero necesita pilas,
probablemente no sea un pato.”
Los objetos de un programa deben poder
reemplazarse por instancias de sus subtipos
sin alterar la correctitud del programa.
Contraejemplo: Context
21. S.O.L.I.D.
Principio de Segregación de Interfaces
“Los clientes no deben ser forzados a
depender de interfaces que no
necesitan”
Es preferible muchas interfaces
específicas de cliente que una interfaz de
uso general.
(Robert C. Martin)
Contraejemplo: ViewPager.OnPageChangeListener
22. S.O.L.I.D.
Principio de Inversión de Dependencias
Debemos depender de las abstracciones
y no de las concreciones.
Ejemplos: Capas, base de datos, servicios, librerias...
23. S.O.L.I.D.
Es la única manera de disminuir el número de
programadores que cometen suicidio.
(BECARIOTON 470 a.c.)
24. Fragmentation and the framework
Desacoplar
del framework es
parte de la
solución
Hardware
Versiones
Pantallas
Forks Fabricantes
25. Context
Context es probablemente el elemento más usado en
el desarrollo de aplicaciones Android…
y quizás también el peor usado.
Application Activity Service
BroadcastReceiver ContentProvider
29. Context
Más información en
Context, What Context?
http://www.doubleencore.com/2013/06/context/
30. Memory Leaks
Se considera una fuga de memoria a cualquier objeto
que perdura tras no utilizarlo o necesitarlo más.
Cada vez que guardamos una referencia al
Context de una Activity el Garbage Collector llora.
Llora muuuucho.
31. Memory Leaks
No guardar referencias al context-activity
Trata de usar context-application en lugar de context-activity
Usa WeakReference cuando no tengas más remedio que guardar las referencias.
Evitar Inner Class no estáticas.
Cuidado con las Static References.