Ball Aerospace

Yesterday I was listening to an episode of the Common Wealth Club on the B612 foundation. They are fund raising $200M to build a space telescope to detect and track all the asteroids that are big enough to destroy a city.

All of that is really interesting, and a very cool effort. However in doing research this morning I learned another amazing fact.

screenshot_137

 

Ball Aerospace is the private company that will build the telescope. They built the Kepler space telescope for NASA, and are doing the James Web space telescope as well. I’d heard of them, but until google this morning, I’d never seen their logo. Which I know… from all the canning jars my mom used when I was a kid.

From Wikipedia:

1956, Ball formed Ball Brothers Research Corporation to produce goods and services for the aerospace sector. This was converted to a wholly owned subsidiary, Ball Aerospace & Technologies Corp., in 1995.

Who knew that one of the top aerospace companies has it’s origins in making glass jars. Not I, until today.

One-Room Schools at the Vermont Folklife Center

 

Granville One Room School

One-Room Schools at the Vermont Folklife Center.

For grades 1 – 5, I was educated in a one room schoolhouse. A throw back to a time before cars, given that everyone had to be able to walk to their school. In small towns around the country a few remained late into the 20th century.

That’s me in the dark shirt in the front, probably about 4th grade. I think that’s about the same time we ended up in a national segment in the CBS morning news for being the oldest continuously running one room school house in the country.

The school is no more. It closed down a few years ago.  But I remain thankful that I had that opportunity as a child. I also think it means I completely expended my 15 minutes of fame before I entered high school (was on national TV twice related to the school), so I consider everything else gravy from here on out.

New Cosmos

“The Cosmos is all that is or was or ever will be. Our contemplations of the Cosmos stir us. We know we are approaching the greatest of mysteries.”
― Carl SaganCosmos

“It’s time to get going again.”

― Neil deGrasse Tyson, Cosmos a Space Time Odyssey

Tonight, a new Cosmos series premieres on Fox. Ever since I heard about this project 2 years ago, I’ve been eagerly awaiting it’s premier. And we are finally here.

The trailer itself gives me goose bumps. Watch the trailer above, and then watch the show. I’m sure it will not disappoint.

Why you should be reviewing more OpenStack code

“Read, read, read. Read everything—trash, classics, good and bad, and see how they do it. Just like a carpenter who works as an apprentice and studies the master. Read! You’ll absorb it.”

– William Faulkner

Icehouse 3 is upon us, and as someone that is on a bunch of core review teams, it means a steady drum beat of everyone asking how do they get core reviewers to review their code. My standard response has been “make sure you are also reviewing code”.

Why?

Understanding implicit style

While most projects use the hacking program to check for trivial style issues (wrong formatting), there are a lot of other parts of style that exist inside a project. What’s a good function look like? When is a project handling exceptions vs. doing checks up front. What does spacing inside functions look like. What “feels” like Nova code, and what feels foreign and odd.

This is like when you are invited to a party at someone’s house for the first time. You walk in the door, and the first thing you do is look to the host, and the guests, and figure out if people are wearing shoes in the house or not. And follow suit if there looks like there is a pattern. It’s about being polite and adapting to the local environment.

Because unless you read other people’s code, you’ll never understand these things. There are lots of patches I look at briefly, realize that they are in some whacky style that’s so foreign to the code at hand, that I don’t have the energy to figure out what the author means, and move on.

Taking load off review teams

As a core reviewer, I currently have about 800 patches right now that I could +2 or -2. Given the rate of code coming in, that might as well be infinite. And it grows all the time.

By reviewing code, even when you don’t have approval authority, you’ll be helping the review teams weed out patches which aren’t in any way ready to move forward. That’s a huge time savings, and one that I appreciate.

Even if it’s something as simple as making sure author’s provide good commit messages, that’s huge. Because I’ll completely skip over reviews with commit messages that I can’t understand. That’s your opportunity to sell me on why I should spend the next 30 minutes looking at your code. A good commit message, being really clear about what problem this code hits, and what this solution is, and why this implementation is the right approach, will make me dive in.

A terrible or unclear commit message will probably just make me ignore the code, because if the author didn’t care enough to explain that to me in the commit message, there are probably lots of issues in the code itself. Even if you and I had a conversation about this code last week, don’t assume I remember all of that. That was probably 50 code reviews ago for me, which means the context of that conversation has long since flushed from my brain.

If you review a bunch of code, you’ll understand how these things impact your ability to review code, and will naturally adapt how you write commits (including the message) to make life of a reviewer easier.

Seeing the bigger picture

People tend to start contributing in just one corner of OpenStack, but OpenStack is a big, interconnected project. What you do in one corner can effect the rest of the project. If you aren’t reviewing code and changes happening at other layers of the project, it’s really hard to know how your piece fits into the larger picture.

Changes can look fine in the small, but have a negative impact on the wider project. If you are proactive in reviewing code more broadly you can see some of that coming, and won’t be surprised when a core reviewer -2s you because you were going in a different direction than the rest of the project.

Becoming a better programmer

When I started on the OpenStack project 2 years ago I hadn’t done python in a real way for years. My python was very rusty. But one of the first things I did was start reviewing a bunch of code, especially by some of the top people in the project.

There are some really smart and really skilled people in the OpenStack project. There are people that have been part of the python community for 15+ years. People that live and breath in python. Just reading their code makes you realize some of what can be done with the language, and what the “pythonic” way of doing things is. Nothing is better training for becoming a better python developer than learning from these folks.

Some times you’ll find a real issue, because no one is perfect. Some times you’ll find something you don’t understand, and can leave a comment as a question, which you’ll probably get an answer to. But all of it will be learning. And you will become a better developer.

It does make a difference

I’ll be 100% honest, with 800+ reviews I should be looking at, I play favorites. People that I see contributing a lot on the review side (not just volume, but real quality reviews that save me time) are people who’s code I want to review, because they are contributing to the whole of the project, not just their little corner.

So that’s why you should review more code in OpenStack. It will really contribute to the project, make you a better developer, and through all this you’ll find your code is naturally aligning better with OpenStack and gets reviewed more often. Realize this is not an overnight fix, but a long term strategy for aligning with the community and becoming part of it.

OpenStack doesn’t need a leader, it just needs to evolve

Third, and perhaps the best argument against OpenStack needing a leader, is the open nature of the beast itself. It’s precisely because there’s no dominant leader that OpenStack remains so transparent and competitive – everyone’s contributions can be seen by everyone else, and this drives people to do even better.

Most likely, those who say that OpenStack needs a leader do so because of history – previous open-source projects like Java, Linux and Android have all had a ‘dictator’ at the helm, but that doesn’t necessarily mean it’s the best path for OpenStack.

via OpenStack doesn’t need a leader, it just needs to evolve | SiliconANGLE.

If you remember correctly, Linux’s leadership and development model was largely dismissed by pundits, until it had 15 years of success under it’s belt. Then it became gospel of how Open Source projects should run.

But everything evolves over time. It doesn’t really surprise me that the pundits see OpenStack’s leadership model as different, and immediately dismiss it. We’ve got 3.5 years under our belt. Maybe at 5 or 6 everyone will now say all Open Source projects need to run like OpenStack.

Which would of course be wrong. While there are certain common threads between different Open Source communities, every community is different. Why? Because Communities are made of real people. Real people with different passions, strengths, weaknesses, biases, loves, constraints, and moments of brilliance. This isn’t something you can model with spheroid approximations of upstream developers. Replicating another project’s leadership model might be easy, but in most cases isn’t what your community actually needs.

Are there areas for improvement? Sure. There always are. But improvement is a watch word for OpenStack, something we apply everywhere: to code, to process, to communication.

So I agree, we don’t need a single leader. And the evolution that continues in OpenStack will be a key strength, not a weakness as the project goes forward.

Why IBM Should Stop Buying Its Stock – WSJ.com

For the past 20 years, IBM has been an avid, methodical buyer of its own stock. In 1993, it had 2.3 billion shares outstanding. Today it has 1.1 billion, shrinking at more than 1% per quarter over the past few years. At that pace, there will be no more publicly traded IBM shares left by 2034.

via Why IBM Should Stop Buying Its Stock – WSJ.com.

This was a key reason that I decided to leave IBM. The current focus on earnings / share at the expense of all else isn’t becoming of a company with a 100 year tradition of innovation. In the quest of this it also looks like there will be another massive layoff in the next couple of months.

Still makes me sad, as there are tons of great people doing great work at IBM. But it’s more in spite of the executive leadership than because of it.

Newegg Patent Victory

Chalk one up for the enemies of patent trolls: The Supreme Court on Monday threw out a request for trial from alleged patent troll Soverain Software.

The case, called Soverain Software LLC. v. Newegg Inc., is one of three such cases the Supreme Court is expected to consider this year. While the Court will likely hear the remaining cases, which deal with finer points of patent law, its dismissal of Soverain speaks to the potential frivolousness of its claims.

via Supreme Court Sides With Newegg Against Patent Trolls | Inc.com.

Remember, Newegg took the hit to go and fight this in court, which very few entities have been willing to do, and that made the world better for all of us. Consider that next time you are considering purchasing computer equipment.

Various rambling thoughts from my personal corner of the internet