What many may not know is that RubyKaigi is in its 6th iteration and it has always been organized by volunteers effort. Their leader is Masayoshi Takahashi-san. He is also the founder of Nihon Ruby-no-kai (Japan Ruby Group) which also helds the e-zine Rubyist Magazine. You should check those resources out to see what the Japanese Rubyists are doing. Great resource.
The main group seems to surround around Takahashi-san and then Shintaro Kakutani-san who works for Eiwa System Management and he is the main Ruby Evangelist in Japan, doing talks all around the country, helping create and organize Regional RubyKaigi, translating books such as the recently released Agile Samurai (from Pragmatic Programmers). As an Evangelist myself, I have to honestly say that Kakutani-san puts me to shame (which inspires me to try harder!). He is doing a remarkable work and if you didn’t know him, you should.
The Program Chair for the conference is no other than Dr. Koichi Sasada, PhD in Information Science and Engineering from The University of Tokyo, he runs the Sasada Labs researching on programming languages and its processors. Oh, and did I mention that he is the creator and current maintainer of “YARV”, the Ruby 1.9 series’ heart? You can read a small interview with him from the Rails Magazine.
There are several individual contributors for RubyKaigi that you really should spend some time knowing about. They are very active and very committed. “Friendship”, “effort”, “unity” and most specially “respect”, were words that came to mind knowing some of them.
Being honest, I can speak a bit of Japanese, but just casually, so I can’t understand more advanced techie-vocabulary, my skills are poor like that, I apologize.
So, it’s a bit difficult to understand some of the most interesting talks presented by Japanese speakers. But they had a nice and geeky workaround. Both halls had the main big screen for the slide projections and also two vertically oriented, narrower screens for Twitter stream projection at the left-hand side (#kaigi1 for the Big Hall and #kaigi2 for the Small Hall – which was not that “small”) and IRC streams on the right-hand side.
This is a clever idea for community driven real time translation. When a foreigner speaker is presenting on stage, the staff would write translations of some of the key phrases at the official IRC stream and anyone could contribute tweeting at an specific hall room channel, which shows in the other screen.
More than that, there was another staff volunteer, Makoto Inoue who helped us, foreigner speakers to place proper Japanese subtitles in our English-written slides, which really helps a lot. I will come back to Makoto in the last section, hold on.
Unfortunately, though it does help, it’s still difficult to follow more technical talks, such as the talk about ThreadGroup class that I tried to attend. But again, this is something that I want to try in our own RubyConf Brazil. Here in Brazil, because we have Locaweb organizing the difficult logistics of the event, we’re able to contract professional narrators to deliver voiced real-time English to Brazilian Portuguese and vice-versa through wireless earphones, and I can say that this is an expensive investment. I’ll talk more about RubyConf Brazil in another article.
Thanks to Dr. Koichi Sasada and the staff, the program is very well balanced. They had,
Hard-core tech-talks such as:
- The Real Time Profiler for Ruby
- Dynamic Component System and Memory Reduction of VM for Embedded Systems
- Parallel World of CRuby’s GC
- How to read JIS X 3017
- CRuby lock design improvement and why it sucks
Business oriented case talks such as:
- Large-scale web service and operations with Ruby
- Issues of Enterprise Rubyist
- Critical mission system implemented in Ruby
Community oriented and motivational talks such as:
A bit less hard-core tech-talks such as:
- Advancing Net::HTTP
- Drip: Persistent tuple space and stream
- Actors on stage
- Use rails_best_practices to refactor your rails codes
- MacRuby on Rails
- Writing custom DataMapper Adapters
And finally some Agile related talks that most should be used to see by now such as:
- 5 years know-how of RSpec driven Rails app. development
- BDD style Unit Testing
- Toggleable Mocks and Testing Strategies in a Service Oriented Architecture
And there are many more that you must see. And speaking of which there are even a KaigiFreaks (probably a homage to the venerable Confreaks that you all know and love) volunteers staff group dedicated to stream videos of the conference in real time, record, edit and then organize and merge volunteer-made English subtitles. Editing video is a laborious work and to have volunteers doing it, I really applaud this wonderful volunteer group.
You want more? Lot’s of session video recordings are already available. You can watch the Japanese sessions from the Main Hall Room and from the Secondary Hall Room. This is huge, I just wish RubyConf Brazil video recording contractors could be this efficient! But hang on, this year we will improve on the video services as well.
Opening Keynote – Bridging the Gap
Aaron Patterson, our friendly @tenderlove delivered a great opening keynote. It’s very interesting because you all know that he’s probably the only person that is both a Ruby Core and Rails Core committer, moreover, having the opportunity to talk to him a few times makes me feel like he really “understands” the Japanese-ways. Watch him talk:
The gist of his talk was about the differences in organization between the Ruby and Rails Core teams. The Ruby Core Team is sort of role oriented, where each committer usually has very specific responsabilities, being the maintainer of certain features of Ruby. There’s even the important role of a “Release Manager” currently held by ms. “Yuki Sonoda”, a.k.a. @yugui, who’s been doing a great job. You can see the list of maintainers in the official Wiki.
Aaron himself is responsible for the YAML parser, Psych, Fiddle, DL. He notes that this kind of organization makes you take more care when messing around someone else’s area. It’s not a deterrent, but you have to be more careful. On the other hand, there are areas that are lacking a full time maintainer. And the other thing is that the release cycle is long, so it takes time for changes and even fixes to reach a broader audience sooner.
The Rails Core, on the other hand, doesn’t have very specific roles, so everybody kind of “owns” everything. But the side-effect is that at the same time no one is actually “responsible” for any particular part. They don’t have a release manager, for example, so there’s no one actively organizing what’s missing to close a release. Again, you saw Rails 3.1 Release Candidate being announced at RailsConf back in May and we’re closing July without a final 3.1 release.
But he’s not stating that one of them is better than the other but instead that they can learn from each other. For example, he made the case that the Ruby Core could be less ceremonious about commits and specially about reverts, people should be able to touch the code without getting afraid of offending anyone. And also that the Ruby Core could put more thought in deciding what should be maintained inside Ruby’s subversion repo and what should be removed and maintained separately as gems, to make it easier for parallel features to evolve independently.
Watch his presentation, he goes on several ideas and also talks about DTrace, other tech stuff and lot’s of funny jokes.
[TL;DR] The Language Barrier
Aaron reminded us again that many people still complain that there are two distinct Ruby development mailing lists, ruby-core and ruby-dev. The first in English, the other in Japanese. A few paranoid developers even go crazy enough to think that there are some kind of “conspiracy” going on in the Japanese list, stuff that’s decided without never showing up in the English list. As Aaron said, there’s no such thing going on.
The more usual complaint is always the same “why don’t the Japanese people communicate in English?” And again, the old bad habit of “taking things for granted”. The ignored reality is that the Japanese people, in general, doesn’t have good English skills. It’s not arrogancy, lack of effort, it’s a simple lack of skills.
I’m from Brazil and here people don’t usually speak good English as well. For me, it feels like Brazilians and Japaneses have a similar level of English understanding. It’s very frustrating. But on the other hand, it’s also frustrating to see Americans taking for granted that everybody else in the world understands English. It reminds me of that memorable scene from the fantastic movie Inglourious Basterds where Diane Kruger’s character Bridget von Hammersmark sarcasticaly says:
Gotta love Tarantino :-)
I can’t tell the American’s reaction to that scene, but I’m pretty sure everybody else had a good laugh. Now, seriously, I shouldn’t laugh because we usually only speak Brazilian-Portuguese, which is a language that almost no other country use. The same for Japanese. But the sarcasm was just to raise the discussion.
It doesn’t feel good when a foreigner expects us to talk his language instead of the other way around. But it’s also not good that we don’t increase our efforts to learn more languages, like Europeans seem to do. I’ll talk more about this in another article.
That said, my point is that there are too many assumptions in communications, and I don’t mean only different grammar or vocabulary. More importantly, there are particular protocols in each culture that we also take for granted and expect that everybody else will comply. But communication between people from different cultures can lead to a lot of misunderstandings. Being geeky, it’s the same as an MSN Client trying to connect to an XMPP-based server :-)
After lunch we had the Ruby Core Team on stage discussing what’s going on in the current Ruby development afairs. Sonoda-san confirmed 1.9.3 for August, with not so many new features, more bug fixes, security updates, stability in general. But they presented a few small controversial features. One in particular was interesting.
We have the private class method to hide particular methods in Ruby. Now they have implemented private_constant to hide class and module names that we don’t want exposed publicly. It’s an interesting feature, though it annoyed some, like Yehuda, a bit.
It was fun (not in the bad sense, please) to see him raise his hand in the Q&A session and state that the Ruby Core could discuss a bit more about new features like that with the other library developers before releasing them. The Japanese Ruby Core team didn’t fully understand what he said at first. Then Matz attempted to translate what he said, but they were still puzzled, until Matz added that it was more of a statement than a question. So the Ruby Core made that “ah, got it!” face and moved on, but Yehuda kept waiting for some answer, kind of feeling ignored maybe.
Again, it’s not my intention to make plain fun out of this, and this was just my personal understanding. But it was an example of a situation where people try to communicate without using the same language and the same protocols. After the session, I was shortly talking to Aaron, Yehuda showed up, and he said that he was actually waiting for some discussion, and we tried to explain that it sounded more like a statement, which is why they didn’t address it.
The Ruby Core Team
Another interesting thing that was not entirely news, but I wasn’t aware of, was the introduction of Shota Fukumori-kun, @sora_h on Twitter. With only 14 years old, he is the youngest Ruby Core committer. He did some work on making the Ruby test suite run in parallel if multiple cores are available. Sounds easy when I explain like this, but it is not. He made several other contributions to Ruby and other open source projects, take a look at his website. I am more and more amazed by the amount of very young developers exposing themselves all around the world. I wonder if this is starting a new trend. Just pay attention and keep looking.
The sense of humor of the Ruby Core was also interesting to see. Yuki Sonoda-san with her kind of serious posture were making lots of small jokes and comments, kind of breaking the ice between the developers on stage. She inquired Matz if they would have a 1.9.4. She complained, kidding, that she wouldn’t like to deal with the maintenance of 1.9.2, 1.9.3 and even 1.9.1 that’s still supported, plus a future 1.9.4. Matz made a funny troubled face and played with the option to delegate it to Shyouhei Urabe-san, one of the maintainers of the 1.8 series. As Sonoda-san moves to 1.9.3 maybe Urabe-san could also graduate from 1.8 to 1.9. They made some fun out of releasing 2.0 instead of 1.9.4 as well. Matz agreed for a while, Sasada-san was against, and they didn’t settle on 2.0 just yet. Just a humorous session between the core developers. But don’t expect 2.0 any time soon.
The only other news around Ruby is that Kirk Haines, the brave maintainer of the venerable 1.8.6 version said that there will be just one more release in the next couple of months to close most outstanding bugs remaining, then 1.8.6 will finally reach its end of life. Rest in piece!
And the last bit is that Ruby will change its license to become BSDL + Ruby. There’s a discussion around this topic if you are interested in license stuff.
As I’ve mentioned before, RubyKaigi had a very balanced program with several different themes for everybody. I want to congratulate everybody for a very well thought out mix of sessions. As usual, I had the same dilemma that I have in every conference I attend, I either miss sessions because I’m tweaking my slides until the last minute or I’m trying to meet new people, record interviews, do networking.
Thankfully people more disciplined than me not only attended most sessions but also described them (please, send comments with links to other blogs with reports from the Kaigi). One of them is Stoyan Zhekov who wrote three articles, for Day 1, for Day 2 – Part 1 and Day 2 – Part 2.
If you understand Japanese or if you want to test the strengths of Google Translator, you can read the huge report in the Gihyo website made reports for Day 1, Day 2 and Day 3. It’s 21 pages long! (And I’m on Page 4 of the Day 3 Report, yay!) I also recommend that everybody keep an eye on the RubyKaigi 2011 website because I’m sure they will also post links to the slides in Slideshare. And you already have all the video recordings from this year and the previous years as well, so save some time to watch as many as you can.
Books on Sale
I don’t know if this is something that every RubyKaigi had, but they have set a small book selling booth with several nice titles. They were releasing a few new titles at the Kaigi, so they also had a book signing session in the lunch interval where Matz signed several books. The other day, Takahashi-san, Morohashi-san and Matsuda-san signed their brand new book as well. They released books for Rails 3 and Ruby 3 Recipes.
That was great, I had my book signed by all four of them (yay!). And they have several books about Ruby, some books are very specific such as an entire book just on dRuby, another specific for Mac desktop app development with Ruby. They also have several translated books from The Pragmatic Programmers such as The Agile Samurai, by Kakutani-san. Agile is growing bigger in Japan, still far from mainstream, but people are interested.
(TL;DR) Lightning Talks
Special remarks goes for the YamiRubyKaigi (something like “Dark RubyKaigi”) and the next two Lightning Talk sessions. Because it was three days long, there were plenty of time for several quick (5 min long) talks. I was surprised by how many people did talk about many different – and sometimes just funny – subjects. That’s something that unfortunately in Brazil, we are still lacking behind, I have a hard time with lightning talk sessions because they usually have very few people willing to talk and usually the topics are still basic in content. After seeing so many lightning talk sessions from RailsConf and RubyKaigi, I know that we still have work to do here.
A few highlights and examples from those lightning talks are:
- Zenpre a web tool to make it easy to upload your slides at Slideshare, prepare a UStream transmission and make an online video + slides presentation.
- ODBA or “Object Database Access” which defines itself as an unobtrusive Object Cache system for transparent object persistence.
- Rios Proxy a framework for command line interface tools.
- ActiveLDAP is a Rails 3.1 compatible library to access LDAP directories.
There are several other interesting talks that I recommend you to watch. Some are just funny, some are motivational, but it can’t be denied that 39 lightning talks (17 YamiRubyKaigi Talks, 11 lightning talks on the 2nd day, 11 lightning talks on the 3rd day), accounting for around 3 hours and 15 minutes of content is a lot. Congratulations to the community for spending time assembling slides and interesting content and showing up on stage to present them.
And as I promised to my new good friends from Australia, Andy Kitchen and Jonathan Cheng, I will give my support to their brand new and revolutionary software development technique, introduced at YamiRubyKaigi, that would make even Kent Bech rethink his concepts! :-) I present to you: V.D.D
Now seriously, putting some thought in this subject, I always wondered how come I see lots of people lining up to talk at US conferences such as RailsConf and now I saw lots of people again lining up to talk at RubyKaigi. Here in Brazil I usually have a hard time coming up with enough interesting talks to fill one single session.
It’s just another speculative theory of mine. In the US there are several smaller Ruby user groups that keep meeting with certain frequency, such as the Seattle.rb group. I speculate that people start “training” there, showing small talks in front of small audiences, testing the acceptance of their content, then they attend larger conferences. In Japan, the Ruby Evangelist Kakutani-san and Rails Evangelist Matsuda-san have been raising regional “kaigis”, groups, such as Asakusa.rb, inspired by the US user groups. Again, this model helps to raise good speakers, providing space for practice in front of smaller audiences, and only then going to larger conferences.
In Brazil, the Ruby community started late, developed fast, and all of a sudden we already had a large conference such as Rails Summit, breaking an important period of time where the regional communities could grow and mature. We now do have regional communities, but few of them actually gather together, presenting ideas in front of each other with frequency. Most smaller communities only meet online at mailing lists. So most people never presented to smaller audiences, never got feedback, and couldn’t know if their content is engaging or not.
My recommendation: regional communities are awesome, if you’re from some place in the world where they don’t exist, please start one. It always starts like this: with one person, perhaps two, for some time you will feel very small, but persistency and consistency will attract people and all of a sudden you are a few dozen. And you’re practicing social skills, testing ideas, getting direct feedback.
In São Paulo, there are companies such as Caelum Training Center which always supported small communities. They provide a monthly space in their facilities so the regional Ruby group can gather and present their ideas at least once every month. One can tell the difference in quality of speakers that have been training in groups like this. It doesn’t matter if it’s not perfect, because it’s not supposed to be. You exercise precisely because you’re still not good. I have presented almost 100 times at events, and I’m still very bad at several points that I need to improve. Perfection comes with practice. And practice comes with repetition and feedback. Regional user groups are a great place for people to practice.
Matz closing keynote was particularly interesting. It was the first time I’ve seen him talking live, and it’s the first time I’ve seen him speak about anything different than Ruby 2.0 or RiteVM. He talked about 4 different topics, first about his career, then about pendulums, about PG and the next 100 years, exactly as the title of his talk describes. In general, it was his vision about the future.
As you all know, Matz is now a member of Heroku. He’ll have official support to hire some Ruby committers and assemble a full time team to maintain the development of the Ruby platform. He confirmed that he’ll not move to San Francisco and that the pace of development of Ruby should not change that much, at least not at first. He’ll do his work as he has always done it, from Matsue, his home town, and he’ll remain a fellow researcher at NaCl, the Japanese company where he has been working for from the last 10 years or so.
The first developer hired to be a full time employee on that team was the remarkable mr. Nakata Nobuyoshi, the top committer, surpassing even Matz in commits into the Ruby trunk, and one of the oldest and most senior developer of Ruby. Great choice, and expect to watch an interview I recorded with him. He has been contributing on his free time from the last 15 years, a very committed developer that you rarely see nowadays.
Then Matz explained that Japanese programmers like to build their own small languages, something like a hobby. Lightweight Language events have been going on for a long while now. Even highschool students attempt to build their own languages. And he’s been seeing lots of attempts in several places. It would be interesting if the next mainstream language comes out of this. But he also mentioned one of his personal characteristics: “負けず嫌い”, meaning that he hates to lose. Speaking just like this it may sound kind of harsh, but it just means that he is not the kind of person that will sit tight and wait. He will always be looking for new ways to improve his language design. He welcomes the challenge with open arms, that’s what he means, in general terms.
He actually first mentioned that he is “大人げない” literally meaning “immature” but more like “not acting like an adult is supposed to” or just being plain “childish”. It was fun when he dived into the “PG” section of his talk, mentioning the famous essayist and entrepreneur Paul Graham, whose fantastic essays are a must-read to every serious programmer. Matz reminded that Paul Graham created a Lisp-ish language called Arc, but it was not very popular. But imagining the 100 year language, we can improve on current languages, to get to the taste of Paul Graham’s. And there’s this Lisp-ish language called Ruby, invented by a guy named Matz, and this language is popular. So, maybe as a language designer, Matz is better than Paul Graham?? Of course he was kidding, but it was very interesting to listen Matz himself saying this particular remark, showing his “大人げない” and “負けず嫌い” sides.
He kept saying about his thoughts of the 100 year language, that something like Ruby would still be around. With the current trend of hardware evolution following Moore’s Law, we would not build languages just for the purpose of raw performance, but for the purpose of being hospitable by humans. So his last remark for the future generations was “大人げない大人になろう”, literally meaning “Be immature adults” or also “don’t become too serious” or an even better analogy is Steve Job’s remark at the famous 2005 Stanford Commencement Address, where he closed saying “Stay Hungry, Stay Foolish”. It’s a similar advice.
Just before that, he mentioned again that “Rivals are always welcome, of course” … “But I will crush you!” :-) Again, don’t take this seriously, it was explicitly intended to sound comical.
And it was interesting because for the longest time people in the Ruby community have been hearding the meme “Matz is nice and so we are nice.” I don’t recall where this started, but I think everybody that has been at the community for some time knows this. Which is why it was fun to see this other “dark side” from Matz, being “immature” and “hating to lose”. This is great, I think that this side doesn’t contradict the other, it’s just that we can be fiercer without losing kindness.
(TL;DR) The Last RubyKaigi
As I’ve mentioned before, this big event is all organized by the sheer will and effort of a group of very dedicated volunteers. They join every year, for the last 6 years, to put together this great event. You can feel that it’s different from a company-organized event such as RailsConf or RubyConf Brazil. Don’t get me wrong, the quality is on par or superior in many aspects. It’s the mood that is different.
After Matz closing keynote, Takahashi-san made a small closing speech. He thanked all the sponsors, the attendees, and the volunteer staff. It was very nice to see all of them gathering on the stage. I had no idea that the staff group was so large. I felt very humbled by that sight and they deserved the applauses.
But this year’s conference was born from a seed planted last year. I don’t know how far have Takahashi-san and the other leaders thought about this, but if it’s half of what I speculate, I think it’s a bold move.
Before I start, let me introduce you to another Ruby developer from Japan, Makoto Inoue. This year he volunteered to help the foreigner speakers to have their slides translated to japanese, to make it easy on the real time translators during the talks (Thanks for the help, Makoto-san!). He started his Ruby career because of Rails a few years ago and now he got himself a good position at New Bamboo, in London, the company that also delivered the very awesome Pusher service.
Makoto attended last year as well and wrote his thoughts in two articles that you should read before going on (Part 1, Part 2). In the second part he mentions another article originally wrote by Shyouhei Urabe, a Ruby Core developer. This article is titled RubyKaigi must die and it seemed to have inspired Takahashi-san on the theme for RubyKaigi 2011. Because I feel it’s important to point out, I will quote the article here:
1: The quality of RubyKaigi is unnecessarily high
The fee of Ruby Kaigi (JPY 6000 for 3 days) is way too low considering average conference fees, yet the quality is too high. We should think about how come this is possible. It looks to me that it is relying too much on volunteers. It is as if we are burning the motivation of these volunteers as fuel. I am worried that people get burnt out, and nothing is going to be left in the end. I don’t think buying someone’s motivation by money (= paying money to stuff, or hiring professional event company) is necessarily bad, especially if it helps to sustain the community.
To be frank, there is no structure for RubyKaigi to continue. This is because we were not sure if the Kaigi will continue when we first started. We thought “just give a try”. We continued because its continuous good response, but this is not sustainable.
2: RubyKaigi should be starting point, not the goal
The initial purpose of Ruby Kaigi was to find people (who have contributed to Ruby , or use Ruby for interesting ways) and put spotlight on them. There must be so many Rubyists who kept low profile unless attended Ruby Kaigi. I do agree that it’s a great thing, but that should not be the start point. RubyKaigi is almost like a cradle for Rubyist, but that’s not the end goal. I feel that the number and quality of theses people start outweighing RubyKaigi and RubyKaigi will become constraints to people as it grows.
How can we avoid this? We need some sort of scale up/out strategy such as increasing the capacity of the Kaigi, do it more frequently, or incorporate RubyKaigi as sustainable organisation, but not sure if there are anyone who want to do that. Then the alternative goes to “Stop it!!”.
3: Isn’t RubyKaigi creepy?
I was expecting that someone is going to say this at some point. Why you guys always mentions “Love” or “Feels” good, and everybody gets so moved? That’s so creepy. You need to calm down a bit. Isn’t it abnormal? If you start hearing something sounds smooth, that means there are something else behind.
To say brutally frank, RubyKaigi is an instrument for a few leading people to agitate other people, and this is so called “cult”. It may not be that bad. Having said that, I am insider of the community (NOTE: The author is one of the Ruby core committers), so even I may underestimate this phenomenon.
This is dangerous, because it is a sign of temporarily fever and people soon go away when the hype goes. It’s nice that Ruby becomes so popular, but we have to think about how to have sustainable community, so the further fever should stop. It’s now time to cool down a bit.
That’s all. If you keep saying “It is too hard (to organise)” or “(RubyKaigi organisation) is so fragile”, then you should stop now. RubyKaigi is not all of your life, isn’t it?
So at the closing speech from RubyKaigi 2010, they announced that 2011 would be The Final RubyKaigi. The idea is close this cycle, reorganize and come back. Takahashi-san will found a proper organization to be the stewardship of an yet unnamed new conference that will come back probably in 2013. So 2012 will be the first gap in 6 years of RubyKaigi. It is still unknown how this will be reorganized, but it seems clear that it’s not the end.
Don’t take everything literally, those are wise word that deserve some reflection. So pay attention.
It’s already a great achievement to be able to deliver six consecutive conferences like this. I was involved in three consecutive conferences of similar sizes and I can appreciate the effort. I said it’s a bold move because it takes courage to dismantle something like this. Once you start and you really like it, it’s difficult to let go. But on the other hand you need to step up to the next level once you reach the first ceiling, and I think RubyKaigi served its purpose.
In the US, Chad Fowler, Rich Kilmer, David Black organized the first RubyConf back in 2001 and just after that they founded RubyCentral, a non-profit organization, to organize the next conferences and support regional events. It was very “American” and a smart move that payed off in spades, specially with the following support from O’Reilly and other companies. They are delivering the 11th RubyConf and they just delivered the 6th RailsConf. The “founding fathers” of the American Ruby Community were able to foster a sustainable ecosystem. I’ll come back to this subject in another article.
There are several similarities in the Japanese and Brazilian Ruby communities, there are specific challenges and there are lots of things that I have personally learned in my trip. I will share some of those insights in my next articles, for now I will wrap up my impressions of this Final RubyKaigi by saying that it succeeded in going beyond my expectations and I really appreciate all the effort spent by the staff in putting this great conference together, and I wish them luck in coming back.