Groovy's Eclipse GroovyRuntimeException error with Log4J

When I updated my Eclipse's Juno plugins, all my Groovy projects came in with exception.   The error seems to be with the Log4J annotation "@log4j". This is what they said:

I was able to solve it by adding the latest snapshot here:

Once I was able to add this, all my errors went away.

What is the product of your company? - is a byproduct

I follow Zach Holman, he works at GitHub. I follow him not because the guy is a techy, or because he works at GitHub, but because the guy just makes sense. Many of his blogs resonate through the different start-ups and companies I've worked. Specially, how to run a company which he talks in hist post the product is a byproduct.

I worked in many places that cared more about the "perception" of the company rather than the people. Many manager/directors worry about the image of the company without realizing that they are setting the tone of the company's culture (their workers), and this will affect their bottom-line/product. For example, "we expect you to work from 9 am - 6 pm", "we expect you to work AT the company, not at your house", "we expect you to dress a certain way - we have a dress code", "we need to ship this feature, we don't care how you get it done…that's your problem."

When we started a my former start-up, we thought we understood our customers, we thought we knew what they wanted, and we just wanted an application that WE would like. After all, "build it, and they will come", right? WRONG! The bottom line is that we were assholes. We really didn't have it right. It was until hard lessons learned that we started listening to our customers and focused on what they wanted rather on what we thought they wanted.  But also, it was until we started changing our culture and hiring the right people that the company finds its product.

Zach talked about things like:

Your product should be a byproduct of the people, process, and technology of your company.

Foster a good environment, be more likely to create a good product.

Hire those bothered by suck. You want fixers

I'm very committed to my companies, but I'm also in LOVE with my family. This is constant tough of war in my head. I do want to help the company in everything I can, but I also want to help my son with homework, and spend some time with my daughter and wife.  I do feel that where I work is MY company. I know that there are some people that said that it shouldn't be like this, "you shouldn't live for work, but work to live". But that's not what I mean. I work as it's my company in the perspective of shutting down my MacBook Pro,with the feeling of "I kicked ASS today".  It is not always like this, but most of the time, they are.   I like the fact that people (coworkers and directors) say, "ever since we hired Marcelo, this place is TIGHT", but I also want my family to say, "we love were you work, because we can see you and spend quality time with us".

As Zach mentions:

Any time you interview a potential hire, you need to ask yourself not only if they're talented or collaborative but also if they're capable of literally running this company, because they will." - VALVe

Hire broad people. Hire diverse people.

Good culture attracts good people

Be family friendly

Flexible location, hours, workload

Groovy's each does not exit when using return

Groovy's each is a very useful closure in collections. However, if you want to exit out of the code using return, it does not work. Below is the code. In this case, if the listId is empty, it sets the value for the "isValid" variable but never returns or break from the loop. The way that I was able to solve it was using a "find" method. Inside the if statement, I set the value for the "isValid" and then return true. The "true" value tells the "find" statement that the value was found, and therefore, it exits out.

Installing Graphite on Ubuntu 12.04

Install dependencies: Install whisper: Install and configure Carbon (data aggregator) Install Graphite (webapp): At the moment, uncomment the following line Configure Apache:

Edit the following file:/etc/apache2/sites-available/default
Make sure that the configuration for WSGISocketPrefix is set as follows:

Otherwise, you will get the following error:

[Tue Jun 19 13:21:28 2012] [error] [client 192.168.0.112] (2)No such file or directory: mod_wsgi (pid=19506): Unable to connect to WSGI daemon process 'graphite' on '/etc/apache2/run/wsgi.19365.1.1.sock' after multiple attempts.

Create initial database: Create the admin for graphite: Start carbon (data aggregator)

Check the log file for any error:
/opt/graphite$ find . -name '*.log' | xargs tail -F

To Feed the data do the following:

Go into the server localhost in your prefer browser and you should see graphite site.

First and last day of the month using Joda text

I had to create a SQL dump right after a new quarter starts. For example, if today is April 1st, then I had to create a dump file with the dates from 2012-01-01 to 2012-03-31.  The only problem was generating the first and end of the month using Java.  The best calendar/date API is by far Joda Date.  Here is the script on how I generated the two dates:

My two cents on failure

Dan North once said: "Fear leads to risk, risk leads to process, process leads to hate...and suffering and Gantt charts." I've worked for many companies (banks, financial institutions, and government) and most of them do not have the type of tolerance for failure. As a matter of fact, they encourage a "blame game" culture - people point the finger at the person who makes the failure. In these companies I was told that if you are the person that is given more bad news than good news to the boss, then you will be labeled as incompetent. The first thing out of my boss mouth when he noticed a problem/failure was, "Who did it? Who's responsible for that? Who's fault is it?" In these companies, if there was something wrong, people would fix it and didn't tell anyone. This created a nightmare when there were bugs on the system because no one would admit to the problem or how it happened. For the last five years, my career took a different turn. I joined a startup and eventually I end up in management, and I found a different paradigm, "failure is part of the business."

According to Harvarv Business Review, there are different type of failures:

• Preventable: this is when it could have been prevented. For example, testing in production, deploying code before testing it, logged in as root and doing an "rm -rf /".
• Complexity related: a large number of organizational failure are due to the inherent uncertainty of work: A particular combinations of needs, people, and problems may have never occurred before. Although serious failures can be averted
• Intelligent: failure when experimentation is necessary. An example will be like "spike" in Agile.

Intelligent failures are normal in startups because you are trying something that hasn't been tried before. The company IDEO has the slogan:

Fail often in order to succeed sooner

This is something that not so many companies have. Entrepreneurs embrace failure and uncertainty. In startups, there is just too much uncertainty and as Steve Blank puts it,

In a startup no business plan ever survives first contact with customers.

So what happens if the original business plan fails? An entrepreneur adapts! He/she learns what went wrong, makes adjustments, and then monitors the new business plan. This means that failure is a natural part of doing business.

I am sure that all these previous businesses are aware of this issue. Obviously, they want to learn from their mistakes and avoid them in the future. But more often than not, bosses get irritated when a person presents them a problem. This is the difference between startups and stablished companies. As per HBR, companies can learn through three different activities:

1. Detection: the should be to surface failure early.
2. Analysis: find out what is the root-cause of the problem, or in agile terms: root-cause analysis (RCA).
3. Experimentation: try to generate intelligent failure for the express purpose of learning and innovation.

It is rare for a business to be an overnight success. There are just a few FaceBook and YouTubes out there. It is going to be hard, and for many failure is the beginning of the journey. As per North, "uncertainty isn't just about expecting change, it's assuming that some unexpected bad thing will happen during the project and we can't even know about them when we start."

Implementing the "No Asshole Rule" at work

I'm usually the person that does the interviews when we have a programming position. There are three criteria that I look for when I interview potential candidates:

1. Technically savvy - can the candidate do the job? Does he/she has a good foundation on computer science (data structures, algorithms, etc)
2. Quick learner or persistent when it comes to finding a solution.
3. Is he/she an asshole

As I mentioned before, my interviews are very technical. For the first criteria, I start with a phone interview and present problems that deal with algorithms and basic fundamentals of computer science. If the candidate does well, then I schedule a personal interview and give them a small project to bring to the company. In person, we do a code review of the project along with the team and then along with the candidate. This is simply a "creative criticism" and a way to find out more about the programming skills of the candidate.

The second criteria is hard to gauge. I usually try to give some questions and if I see them struggle, then I see how they handle it. I also ask questions like "what is the latest thing (programming language, framework, tool) that you learned?", "what do you do when you get stuck on a problem?", etc.

The third criteria is extremely important to the team and the hardest to catch. Everyone has worked for or with an asshole. Just so we are clear, I really liked the definition from Robert Sutton's "The No Asshole Rule":

THE DIRTY DOZEN

Common Everyday Actions That Assholes Use

1. Personal insults

2. Invading one’s 'personal territory'

3. Uninvited physical contact

4. Threats and intimidation, both verbal and nonverbal

5. 'Sarcastic jokes' and 'teasing' used as insult delivery

systems

6. Withering e-mail flames

7. Status slaps intended to humiliate their victims

8. Public shaming or 'status degradation' rituals

9. Rude interruptions

10. Two-faced attacks

11. Dirty looks

12. Treating people as if they are invisible

I usually call the candidate's references and asks some "what if" scenarios. Despite all of this, it is hard to identify an asshole.

It is very hard to build a cohesive team, but when you have one...it's amazing. The team works like well-greased machine. Introducing an asshole is almost like throwing a monkey wrench to the machine. As Jim Collin's mentioned in his famous book "Good To Great:"

If you have the wrong people, it doesn’t matter whether you discover the right

direction—you still won’t have a great company. Great vision without great people is

irrelevant

Managers, if you have an asshole, you need to handle them right away! You need to let them know that this type of behavior is simply unacceptable and if it continue, they will be terminated. It is simply not fair for the team or to the company. Simply put, assholes will bring down production and cohesiveness to the team. Worse, you can potentially loose some great resources.

Questions:

How do you find people that are quick learners?

How do you handle or filter assholes?