We are very excited to begin the series of interviews with our honorable speakers!
With the first interview we present Florian Gilcher, a seasoned Rubyist and active member of German Ruby community. Being in the heart of local and foreign events Florian has lots experience with recent open-source projects, their problems and prospective, and on RubyC-2017 he will share his knowledge through the talk #Potential.
< favorite tools > Padrino, Rails, (J)Ruby, Python, Java, Elasticsearch, Postgres, Varnish, Vagrant
< loves > Rust, Haskell, ROM, public speaking and organizing events
Most of my involvement in is on the community side of things. I used by be chairperson and am still an active member of Ruby Berlin http://rubyberlin.org, a non-profit in Berlin running events and workshops around town. I also joined the Rust http://rust-lang.org community team when it was founded last year. My first bigger social activity on the internet was Bulletin Board moderation, which I still somehow do.
The reason I want to talk about this is that I see a lot of projects really struggling on the community side of things. They are having a hard time attracting and keeping contributors or not finding people for certain tasks. But there are simple standard techniques and approaches that don't take much time and have great effect to improve things.
Running is mostly easy. Most people are cooperative, interested and generally mind each other. Some are actively creating new stuff. The real problem is assessing things that aren't quite present yet - new opportunities, possible cooperation or upcoming problems. For example: The fundamental problem of communities is how to attract people and make them feel welcome. But how do I find that out? I cannot interview a person that hasn't got in touch with us yet. I haven't quite got an answer, but I have a few approaches. It's an interesting problem.
Interesting question. So, there's this picture out there of moderators and community workers spending their whole days kicking people out on short notice. In well-run communities, disasters of that kind are extremely rare. But due to the nature of the work, only disasters are worth news on Twitter.
The reason is that good handling is preferably through discussion, quick and to the agreement of all sides. And for most cases, that's enough. It's very important to know why things happen. For example, someone had a bad day, or is frustrated because of a topic and is letting that out on the first person they meet. In that case, clearing that situation for both sides - for example by giving that person a better place to point their anger towards and asking for an apology. Double points if you catch that early and no one really notices. And finally: keeping your mouth shut about the whole thing.
This also means that "offensive behavior" is a careful term to wield. For example, general unfriendliness may not make the easiest person to work with, but is no reason for intervening.
Initially, the language itself with its rather interesting memory concept. Then the open development process of the language. You rarely get the chance to watch a language grow as an open project somewhere. I was also amazed by how much the project, even in its early stages, was set up towards contribution of any kind.
With the combination of those, I decided to stick with the language and am still very happy here.
To get older and wiser :). Ruby is in the comfortable position of being in the TOP 20 of the most widely used languages - I would say that makes it irreplaceable. Every company I know uses Ruby in some capacity - be it through Puppet, Chef or classic Rails. Many would not openly admit it - or the HR department doesn't even know.
We have lots of secondary ecosystems, like the Hanami framework or ROM. Rails is still a great framework if you don't want to hand-assemble your stack for two weeks before getting started. With JRuby, we have great Java support. We should be less cautious about just saying that. This is the work of decades, no one can quickly catch up on that.
I don't get that excited about new concrete technologies anymore. But, mostly on the data side of things, the move towards data modelling as streams and finally people getting into http://offlinefirst.org/ through that: sync. In my opinion, that leads to an interesting shift: time becomes a more and more dominant concept in programming.
And that's all very independent of programming language of choice. It's about finding ways to model these things in a way that gives you a somewhat clear set of assumptions when reasoning about code. Just like REST did that for HTTP.