Thursday, March 8, 2012
Wednesday, March 7, 2012
MySQL Conference, Percona, the Ecosystem...
This year O'Reilly isn't running the MySQL conference, Percona is doing it. Santa Clara, April 10-12. The usual time and place.
This is great news. They run a great conference. They always get rave reviews.
This isn't the first one they've done. They've done San Francisco, New York, London, more.
What's different about Santa Clara?
This isn't their typical 300-person one-day conference. They're picking up the annual MySQL users conference and carrying the torch forward. This is a 1000+ person, huge expo hall, 8 concurrent tracks, several days conference.
This year is a banner year for the MySQL ecosystem. Why?
Because now the conference is focused on MySQL again. This is the central conference for the ecosystem. And now it's managed by a company that understands both the community and business side.
And the MySQL Ecosystem? Thanks to cloud vendors it continues to grow.
The sessions? Better than ever. In the past there was a lot of auxiliary content. Take a look. This year it's easily the best technical content I've ever seen. And I've led the selection committee for years.
The sponsors and exhibitors? Pretty much anyone who's anyone will be there. Looking for solutions to your MySQL problems? You'll meet the folks who can help you. Visit the expo hall. There is great sponsor support for this year's event. HPCloud, Facebook, Clustrix, Google, et cetera.
The keynotes are nothing to sneeze at too. There will be talks from Marten Mickos, Mark Callaghan, myself, and more of the old gang.
Is there more? Yes there is.
There are the community awards, BOFs, lightning talks. There is a Tuesday welcome reception, Wednesday community networking.
More? Yes. There is not one, not two, but three follow-on events. Stay an extra day and on Friday you can attend Drizzle Day, SkySQL and MariaDB Day, or Sphinx Search Day. Three awesome technologies for MySQL users.
This is a really big deal. If you are even slightly interested in MySQL, this is the event of the year. Don't miss it. By the way, early-bird pricing is almost expired. Register before March 12th or you'll pay more for the ticket and the hotel.
This is great news. They run a great conference. They always get rave reviews.
This isn't the first one they've done. They've done San Francisco, New York, London, more.
What's different about Santa Clara?
This isn't their typical 300-person one-day conference. They're picking up the annual MySQL users conference and carrying the torch forward. This is a 1000+ person, huge expo hall, 8 concurrent tracks, several days conference.
This year is a banner year for the MySQL ecosystem. Why?
Because now the conference is focused on MySQL again. This is the central conference for the ecosystem. And now it's managed by a company that understands both the community and business side.
And the MySQL Ecosystem? Thanks to cloud vendors it continues to grow.
The sessions? Better than ever. In the past there was a lot of auxiliary content. Take a look. This year it's easily the best technical content I've ever seen. And I've led the selection committee for years.
The sponsors and exhibitors? Pretty much anyone who's anyone will be there. Looking for solutions to your MySQL problems? You'll meet the folks who can help you. Visit the expo hall. There is great sponsor support for this year's event. HPCloud, Facebook, Clustrix, Google, et cetera.
The keynotes are nothing to sneeze at too. There will be talks from Marten Mickos, Mark Callaghan, myself, and more of the old gang.
Is there more? Yes there is.
There are the community awards, BOFs, lightning talks. There is a Tuesday welcome reception, Wednesday community networking.
More? Yes. There is not one, not two, but three follow-on events. Stay an extra day and on Friday you can attend Drizzle Day, SkySQL and MariaDB Day, or Sphinx Search Day. Three awesome technologies for MySQL users.
This is a really big deal. If you are even slightly interested in MySQL, this is the event of the year. Don't miss it. By the way, early-bird pricing is almost expired. Register before March 12th or you'll pay more for the ticket and the hotel.
Wednesday, February 29, 2012
Drizzle Day at the Percona MySQL Conference
The major annual event in both the MySQL and Drizzle worlds is the conference week in April. This year Percona is organizing the Percona Live MySQL Conference and Expo from Apr 10-12 and as usual we follow up with a Drizzle Day on Apr 13. It's the 4th Drizzle Day!
I will be giving a keynote at the main conference, on Wednesday April 11. I will be giving a keynote on the state of the MySQL Ecosystem and how cloud is evolving it. (HPCloud is a sponsor of the conference.) Of course, it is aboutDatabases in the Cloud so MySQL and Drizzle are still with me :-)
There are a few Drizzle specific talks though. Check outScripting MySQL with Lua and libdrizzle inside Nginx and Getting Started with Drizzle 7.1.
Then on Friday, April 13it's all about Drizzle. I will be giving a mini-keynote to start the day, and then we have great talks about new and old features in Drizzle. The Drizzle Day is free entry, so even if you're not attending the main conference, but if you're interested to learn about using Drizzle, please consider joining us. At the end of the day there is also some content for those who might want to start hacking on Drizzle itself. Especially if you live in the Bay area, just pop in, it would be great to meet Drizzle users and hackers in person.
Oh, and I also want to say it is really great that Percona and Technocation are sponsoring this event and also that SkySQL has invited us to their lunch and after party. Since Drizzle is purely a community project, we really appreciate this. It is what makes Drizzle Day happen.
Speaking of lunch:Please RSVP to us so we know how many are coming.
I will be giving a keynote at the main conference, on Wednesday April 11. I will be giving a keynote on the state of the MySQL Ecosystem and how cloud is evolving it. (HPCloud is a sponsor of the conference.) Of course, it is about
There are a few Drizzle specific talks though. Check out
Then on Friday, April 13
Oh, and I also want to say it is really great that Percona and Technocation are sponsoring this event and also that SkySQL has invited us to their lunch and after party. Since Drizzle is purely a community project, we really appreciate this. It is what makes Drizzle Day happen.
Speaking of lunch:
Wednesday, February 1, 2012
Error Messages
I have written a number of libraries that are frequently used, and I have yet to find a pattern for error messages that I am completely happy with.
Let me tell you about a few of my thoughts on this.
I have found that there are two parts to an error, the code and the message. The code is a numerical value, and the message is an expression that you expect a human to read.
Error codes and messages do not have to map one for one.
You only really want to provide a specific error code if you believe the developer who is working with your code can do something about the error.
I've definitely gotten myself into the trap of creating a dozen or so error codes that all relate to how a host has failed a connection. In almost all cases of a connection failure there is very little that the end user of the end user of the library can do.
While one error code might be fine, you should create specific error messages which provide more information for an end user to diagnose a problem.
The developer who is looking at the error will appreciate the message. It might make the difference between someone spending five minutes, instead of five hours diagnosing the problem.
Never return an error message that is just a number.
No one wants to try to figure out what "error 13" means. A number tells me nothing, and while I could google the number, that is an extra step I don't want to have to take each time I look at a problem.
If you need a paragraph to explain the error, make the error searchable.
If a developer wants more information on the error, they will search for it. Make this a very simple process. It drives your users to your website. This may sound obvious, but I continue to meet people who haven't realized this.
Do not map to ERRNO.
Mapping to ERRNO. ERRNO is not very flexible, and it comes with the baggage of a preconceived notion of what the error means (which does not map across operating systems).
Give yourself enough information to diagnose a problem for the end user.
In the last few years I have taken to embedding the line of the code, and the file that the error was in, every error messages. This has allowed me to better support software that I write by creating context for me. An error is not only a tool for the end user, it is a tool for you to provide support.
Consider the case that multiple failures may occur.
Sometimes you don't have one failure in a given context, so try to store up all of the errors that occur. If you can, design your error system so that you store all of what failed.
In the end,...
Be consistent. Format your error codes and messages in a consistent manner. Make sure that if someone wants to, they can parse them in batch. Never under estime the creativity of an end user armed with a regular expression.
Let me tell you about a few of my thoughts on this.
I have found that there are two parts to an error, the code and the message. The code is a numerical value, and the message is an expression that you expect a human to read.
Error codes and messages do not have to map one for one.
You only really want to provide a specific error code if you believe the developer who is working with your code can do something about the error.
I've definitely gotten myself into the trap of creating a dozen or so error codes that all relate to how a host has failed a connection. In almost all cases of a connection failure there is very little that the end user of the end user of the library can do.
While one error code might be fine, you should create specific error messages which provide more information for an end user to diagnose a problem.
The developer who is looking at the error will appreciate the message. It might make the difference between someone spending five minutes, instead of five hours diagnosing the problem.
Never return an error message that is just a number.
No one wants to try to figure out what "error 13" means. A number tells me nothing, and while I could google the number, that is an extra step I don't want to have to take each time I look at a problem.
If you need a paragraph to explain the error, make the error searchable.
If a developer wants more information on the error, they will search for it. Make this a very simple process. It drives your users to your website. This may sound obvious, but I continue to meet people who haven't realized this.
Do not map to ERRNO.
Mapping to ERRNO. ERRNO is not very flexible, and it comes with the baggage of a preconceived notion of what the error means (which does not map across operating systems).
Give yourself enough information to diagnose a problem for the end user.
In the last few years I have taken to embedding the line of the code, and the file that the error was in, every error messages. This has allowed me to better support software that I write by creating context for me. An error is not only a tool for the end user, it is a tool for you to provide support.
Consider the case that multiple failures may occur.
Sometimes you don't have one failure in a given context, so try to store up all of the errors that occur. If you can, design your error system so that you store all of what failed.
In the end,...
Be consistent. Format your error codes and messages in a consistent manner. Make sure that if someone wants to, they can parse them in batch. Never under estime the creativity of an end user armed with a regular expression.
Saturday, January 21, 2012
CenturyLink, Suck, US Tech Support
I wake up and discover the internet connection is down to the house.
I log into my router and run the diagnostics software that is built into it. Everything is good (BTW this is an actual router which bridges the DSL signal to ethernet (built by Cisco)).
So I call tech support. The fellow immediately blames the device and tells me that they will send out a new one on Tuesday. It will have built in WiFI, and since "I don't pay for a static IP address" it will be "easy to configure".
Ugh,... I have a routable subnet, and no I don't want your cheep assed device that won't do what my current device does.
We go around and around for a bit, and finally he gets me his manager.
His manager stumbles through the conversation for a bit, and repeats the "we can be out by Tuesday, and our new device is better...".
I escalate, and he pushes back.
So? I escalate again, and point out that I am happy to call the city and bitch about their service (I also drop words like "911 service", etc...).
I get transferred to Idaho.
This nice woman bounces the line for me, and....
Everything works.
In the future, I am going ask to be transferred to the US first.
I log into my router and run the diagnostics software that is built into it. Everything is good (BTW this is an actual router which bridges the DSL signal to ethernet (built by Cisco)).
So I call tech support. The fellow immediately blames the device and tells me that they will send out a new one on Tuesday. It will have built in WiFI, and since "I don't pay for a static IP address" it will be "easy to configure".
Ugh,... I have a routable subnet, and no I don't want your cheep assed device that won't do what my current device does.
We go around and around for a bit, and finally he gets me his manager.
His manager stumbles through the conversation for a bit, and repeats the "we can be out by Tuesday, and our new device is better...".
I escalate, and he pushes back.
So? I escalate again, and point out that I am happy to call the city and bitch about their service (I also drop words like "911 service", etc...).
I get transferred to Idaho.
This nice woman bounces the line for me, and....
Everything works.
In the future, I am going ask to be transferred to the US first.
Tuesday, November 1, 2011
Tuesday, October 18, 2011
Contributor Agreements, Open Stack's Contributor
I have not been a fan of the Open Source Contributor agreements that have been used for the last two decades. All of them tend to have an onerous bit whereby a developer has to hand over the copyright to a group, organization, or company.
I’ve never felt like this is a very honest exchange. With MySQL you were handing over copyright to a company that was making money off your work. With the FSF I have always been bothered by Richard’s insistence that FSF has the right then to take that code and relicense it. His stance on dual licensing under commercial licenses is my issue with this.
The Open Stack contributor’s agreement is a bit different then much of what we have seen thus far. It basically states, and please keep in your mind firmly that I am not a lawyer, that you have the right to submit the code you are submitting. It states directly that you can do whatever you want in the future with the code you wrote.
It is not Apache specific. I don’t see any reason why it couldn’t be used with a GPL project as well.
It is worded such that the group that the code is contributed too couldn’t just take your code, and then hold the contribution hostage. By hostage I mean that the contribution would sit in a limbo where you couldn’t do anything with it, and would therefor be at the mercy of the new owner of the code publishing it.
The GPL, BSD, Apache, MIT, and other licenses where a watershed in their time. Lawyers learned the licenses, and each of these licenses have been “debugged”.
Every time a company sees a new license, or a new legal agreement, there is a huge bar that must be met before it can be signed.
If you are an engineer, think of lawyers as a picky c++ compiler. Some lawyers issue better warnings then others. Some organizations turn the compiler flag “all warnings to error” on. Other organizatiosn not only do this, but add they add in -Wextra for good measure.
We have software licenses, the OSI stamped out quite a few of these.
What is missing then?
Where is the advantage in using it? We already have a long list of companies who signed it for Open Stack. It has been debugged, and a number of large companies are willing to sign it.
I’ve never felt like this is a very honest exchange. With MySQL you were handing over copyright to a company that was making money off your work. With the FSF I have always been bothered by Richard’s insistence that FSF has the right then to take that code and relicense it. His stance on dual licensing under commercial licenses is my issue with this.
The Open Stack contributor’s agreement is a bit different then much of what we have seen thus far. It basically states, and please keep in your mind firmly that I am not a lawyer, that you have the right to submit the code you are submitting. It states directly that you can do whatever you want in the future with the code you wrote.
It is not Apache specific. I don’t see any reason why it couldn’t be used with a GPL project as well.
It is worded such that the group that the code is contributed too couldn’t just take your code, and then hold the contribution hostage. By hostage I mean that the contribution would sit in a limbo where you couldn’t do anything with it, and would therefor be at the mercy of the new owner of the code publishing it.
The GPL, BSD, Apache, MIT, and other licenses where a watershed in their time. Lawyers learned the licenses, and each of these licenses have been “debugged”.
Every time a company sees a new license, or a new legal agreement, there is a huge bar that must be met before it can be signed.
If you are an engineer, think of lawyers as a picky c++ compiler. Some lawyers issue better warnings then others. Some organizations turn the compiler flag “all warnings to error” on. Other organizatiosn not only do this, but add they add in -Wextra for good measure.
We have software licenses, the OSI stamped out quite a few of these.
What is missing then?
- Agreements for developers who are on advisory boards.
- Contractor agreements that carve out open source projects such that they don’t become entangled with “work for hire”.
- Contribution agreements.
Where is the advantage in using it? We already have a long list of companies who signed it for Open Stack. It has been debugged, and a number of large companies are willing to sign it.
Subscribe to:
Posts (Atom)