Diego Pacheco Tech blog

Neo4J is a graph database built in Java with full support for Transactions. It work with nodes and relationships, you're able to put properties in both, graph structure are very simple structures but have great expressiveness and great work for some problems domains. Graph are perfect for social media, because you have friends and the friends have friends and they have twitter, email, cellphone. You do have properties on the relationship like for how long time you know that find or where did you meet him last etc. This is the classical Matrix movie relationship sample. Let's see how we structure this graph on code, I will show ruby code through JRuby. I made some changes and add new properties but the relationship didn't change that much.

You should try Ruby language . Ruby is a OO development language created by a Japanese called Yukihiro Matsumoto in 1993.  It's a old language BUT far to be on the mainstream. Ruby is a niche language, I don't dare tell what will happen in the future BUT I see Ruby more and more stronger in world and Brazil as well. Part because Java community is detaching(caused by ORACLE actions). There is a first strike that get you if you start coding with ruby. I called "It works :-)" If you work with Java you know what I'm talking about. Learn Java eco-system is hard and take long time, things are complex and often stuff that you get on the web just don't work. How many times did you get a tutorial or a blog post code that don't work because version of some jar that change, missing dependencies, environment setup and so on and on. You get really happy coding and learning Ruby because everything that you get on the web works, it's amazing y...

Google Guice is a very interesting framework. Some folks look him as a replacement for Spring Framework . I really don't think that is the case, Spring is a great kick ass framework really big with lots of utilities like a swiss army knife. Spring have a huge ecosystem, Guice is not a replacement, IMHO I see Guice as a very lightweight simple object register dependency resolution engine.  It can be very cool and useful in some specific scenarios like coding a Android solution or even a Java web application. It's really fast and simple to use it. Guice embrace Java annotations implementing the JSR330 for Java common annotation and dependency injection annotations like @Inject, @Qualifier, @Singleton, @Named, @Scope and others. You use annotations to wire up your components & POJOs and use a simple DSL to define your object graph dependencies. This dependencies can be assemble with lots of ...

It's been a while since I'm using Martin proulx Facilitation Cards . I'm not using the cards alone I printed for each person in my team. The team receive the idea to use the facilitation cards very well and them we start using it. The experiment was a attempt to improve the communication in the team and see how people react using this kind of visual sign on most diverse situations. Cards like Yes, NO, Abstention we didn't use maybe because the team get used to talk and make quick calls about stuff that happed, I din't miss using this card but maybe I'm missing something here, anyway the team have all cards and nobody use this 3 ones so I think we're OK about it.

XP is about getting the right values and practices and maximize it to the extreme. CODE it's essential and practices like pair programming and unit testing / test driven are a must have. I don't think they are enough, so i like to work a lot with team code reviews and design sessions. As a Software Architect I found such techniques very effective specially in scenarios that the team is beginning with XP and don't do pair programming effective or the team technical skills have a huge contrast.  I'm not against pair programming of testing BUT this old fashion techniques work as well.

The world is changing. It's becoming more and more complicated. Systems are getting that as well, more and more real time, on-the-fly, available, concurrent, dynamic. If all that things are happening why we still suck when you talk about development and operations working together ? There is a old war between dev and ops, there're two worlds, two cultures, two totally different ways of thinking, concerns, there're 2 departments often with different managers, I don't talk about my company I talk about the majority of the world, there're this false dichotomy. Have you ever throw something over the dev or ops wall ? I did! It's amazing how still there're this wall and how dev and ops don't know how to work together effectively. Devs often think that the only that matter is teach ops how to restart the server and where put the God Damn EAR file. Ops often think there're is only life after QA. Both are totally wrong. If you have a stupid smal...

Workplace it's a critical factor of people satisfaction, create agile workplace its not just put a bunch of post-its on the walls but create a environment that some behaviors can emerge and people are able to do they're best on the work, Environment and workplace are not the same thing to me :-). Many companies say they care about good workplace and I believe they do but not always a good workplace is a good agile environment. You deserve a good workplace, it's amazing how at least one time in life (or several) we end up working in such a terrible workplaces. No body deserve it work on a bad workplace, in fact I think(this is my devil side) it's good, so this serve to teach us to value a great workplace. 

Agile is really about culture. Culture not only means how we approach on software development but how we tech teams and customer the new mindsets.  Change culture is hard, growing teams its harder, culture is something really powerful and yet danger. Training is a must have, to promote change, but is not the only thing and is far to the be game change act, don't get me wrong, I'm totally pro training BUT I'm just saying that training is the basic not the big deal nor the big turning point. The title of this should should be actually: "Promote the culture and keep doing it". That's key element of changing culture, every meeting, every retrospective, every planning, every training, everything 'ts a opportunity to keep promoting the culture. It's like that great quote says: “We are what we   repeatedly   do. Excellence, therefore,   is not an act ,  but a   habit .” There is a implicit thing here, I m...

I couple of weeks ago I gave some trainings about Lean/Kanban and Agile core values and mindsets , later I will provide several blog posts to cover with more details that presentations. Lean kanban View more presentations from Diego Pacheco Agile & lean View more presentations from Diego Pacheco Cheers, Diego Pacheco

I couple of weeks ago I gave 3 days training of SOA focused on development perspective. This training was really focused on general main concepts and SOA mindsets and development using REST, later I will prove posts to cover with better details some aspects of this training. Soa for DEVs View more presentations from Diego Pacheco Cheers, Diego Pacheco.

Growing a team and developing people is a primary agile coach duty. Such of thing ain't happen easy. Take time and lots of actions to archive it. The main issue could be being part of a company that don't have the agile team culture and mindsets, so when you fight against bad mindsets you must be very persistent and make the right moves to make things happens. Agile practices from scrum and XP will help you BUT sometimes they are not enough, dealing with different people culture indeed its a big challenge. I don't see you promoting change only by changing the practices or the tools, I do see the changing slowly happening when you evolve people and let they be part of the change. Change is something people said they want but often they don't want do it. I talk by my self when I said that, I known how something are important and even that sometimes I don't do it, because I really don't care deep inside ? NO, because to follow...

DEMO sessions or Review session are skipped more offen then you can imagine. I do understand the reasons why people may skip this sessions, sometimes people don't have working software to show, team could be not happy with the sprint results or could be that you have so few stories to show. I worked in projects with lack of demos and this sticks as not only lack of demos but also lack of openness and really could be a sign of doing agile wrong. Because you don't have nothing to hide of your customers, right ? We don't need get paranoiac about that because in several adoptions team do daily meetings with the team everyday smooth integrated. If the team does regular daily meetings with the business(team + business(pos)) together, why bother to do DEMOs sessions, let's say you do have a great communication in place, I do really need regular DEMO sessions ?

Pair Programming is one of the most simple and yet harder on XP practices. It's amazing how much sense of private ownership we built before embracing XP practices, lots of folks argue that private ownership is better or fits better for they believes. For years I had this thoughts about my classes are not yours. Some mindsets are harder to get, like developer written tests, that's hard one too but I will not talk about tests today, this is another conversation :D Ownership has power and this is one of the compelling reasons what should you care about pair programming.

Retrospectives are ones of the most critical must have agile practices. Is really easy to see the differences between a team who does retrospectives and other who don't. Unfortunately so many so called "Agile Adoptions" avoid doing teams retrospectives in regular basis. Unless you have a great Lean-like culture of continuous improvement in place in don't see sense killing retrospectives(Even if you have - IMHO the difference is that you do retrospectives in small batches and you don't need a especial day to do it). Retrospective Format & Styles There are several ways to perform an agile retrospective, some are time fixed like 1h or 2h. Other formats are very driven like the 6 hats, in this style of retrospective you have specific moment for talk good or bad about somethings. I found interesting work with these formats and for young and new agile teams they cloud help to focus on the right spot. IMHO i found really boring a...