By
/02.05.23

When people answer your call for conference talk submissions

Failed experiments should be published as well as successful ones. This is especially important in research where reproduction even of famous studies proves to be difficult at times. This can be merely the case because of statistics, not even malevolence. If your experiment results have a significance level of 5% you can assume without bad conscience that your findings are probably correct. Only one out of twenty trials would come to the same results by chance. But what now if your experiment didn't find an effect? You should still publish the results. Otherwise you might exactly be one of those failed 19 trials to the one by-chance-successful experiment. The incentive to publish only successful results is called publication bias and we need to fight it actively.

Simon, Alessandro and me submitted the following talks for the Helvetic Ruby Conference 2023:

  • Learning Week: Lessons Learned from 8 Years of Annual Company Retreats

  • Rails 0.5 – It’s just Ruby

  • Rails Frontend Journey

They were all rejected and other talks were preferred by the organizers (people known to us).

Learning Week: Lessons Learned from 8 Years of Annual Company Retreats

Author

Simon is a full-stack software engineer. He joined Renuo in 2015 after graduating from HSR CS in Rapperswil with a B.Sc. in Computer Science. Having volunteered with the Swiss Scouts and Guides movement for many years as an active leader and course instructor, he has developed a passion for team building and training. As one of the organizers of our annual company retreat, he strives to incorporate the best practices of volunteering into our daily work lives.

Abstract

How do you stay up to date, have enough communication within the company with growing teams, and stay visionary? At Renuo, we've found a solution that combines learning, team building, and fun! Our annual week-long Learning Week retreat, where we immerse ourselves in sessions on technical topics, company-related issues, and daily sessions interwoven with team-building activities throughout the week. It's the perfect way to learn from each other, develop skills, and build a strong team: We look forward to taking you on a journey through 8 years of experience.

Key takeaways

  • Company retreats are a very effective way to combine learning from each other, developing skills, and having fun.

  • It is not free: Preparation and everyone attending must be supported by the company and has its price

  • 5 days is the optimal duration, also for family members.

  • Rural locations often work better than cities

  • The program should include both technical and business sessions.

  • Company retreats are a great way to integrate new team members and interns.

Target audience

Developers who could bring the idea to their company and entrepreneurs, company owners

Pitch

Through my involvement with the Scouts of Switzerland in courses over the last 15 years, I know the importance of a cohesive team and constant motivation, not only in volunteer work, but also in a professional environment. I have participated in all of our Learning Weeks at Renuo since the very beginning and have been able to bring my volunteer experience to the coordination and organization of most of the Learning Weeks. I think I have a lot to share about volunteer best practices and especially about our learning week experiences

Rails 0.5 – It’s just Ruby

Author

Josua started his journey into the web with HTML 4.01 and PHP4 on the LAMP stack in 2004. After receiving some formal education (B.Sc. HSR CS, 2013) he started working as a software engineer for Renuo in Zurich. He slightly missed the Ruby 1.8.7/1.9.3 mess and started to love Rails. Ten years down the road, he is still fascinated by Matz's desire for beauty and DHH's mission to fight pain. When Josua is not cooking up software then he is probably brewing his own beer in Rapperswil.

Abstract

Rails 7 is a moloch. It has more than 300k lines of Ruby code. Grasping even small parts of this framework is a serious undertaking nowadays. This wasn't always the case. The first published version of Rails was less than 5k lines of code. Even if it was magical already, it was just Ruby code. You could read and understand it completely. Let's go back almost 20 years to when things were simpler. Let's see what the first published Rails version could do (live on stage) and why Ruby was precisely the right programming language for it.

Key takeaways

  • Everyone knows what Rails 0.5 contained

  • Digging up code history may help you to understand concepts

  • Well-made software ages well

  • You may carry around a lot of overhead

Our software stacks are ever-growing. I think it's valuable to remind ourselves that there were times when we could grasp the full stack from top to bottom. I'd like to show that we could still use Rails 0.5 in production (with some limitations security-wise). Sure, Rails 7 is very comfortable, but you need to know Rails. Once it was enough to know Ruby.

Target audience

Experienced Rails developers will find it interesting for the Rails part, Ruby beginners for the Ruby part.

Pitch

You get a Rails topic which actually is a Ruby topic. I've been with Rails for almost 10 years, and I've already investigated two historic Ruby topics in the past – RSpec Includes Matcher and Rails Route Mapping

Rails Frontend Journey

Author

Alessandro studied Computer Science in Bologna and obtained his Bachelor's degree back in 2008. He started working with Ruby On Rails in 2012 within the context of political movements happening in Bologna in those years, where he collaborated in the development of online platforms. In 2013 he moved to Switzerland and started working at Renuo as Software Engineer, where he made sure that Rails was the primary framework adopted by the company. Blog writer, and Open Source Maintainer, he is today the father of two boys and continues working in the Ruby On Rails environment.

Abstract

In my 20 minutes talk, I will guide you through the relationship between Rails and the Frontend world in the last 8 years. We will start from Rails 4 and Sprockets, and what pushed us towards Turbolinks, and, afterwards, Webpacker. We will look at how we (Rails community and Renuo) embraced the new Assets Pipeline looking at Tweets, Blog Posts and Pull Requests from those years. We will then jump to the first rumors about Turbo, and how Rails 7 revolutionized the relationship with Frontend. The talk will finish with a final look into the future. The talk will be a history lesson, but hopefully more fun. It will be filled with personal opinions and my experience and the one of Renuo.

Key takeaways

  • How and why we use the Frontend tools that we have today

  • Taking decisions is the hardest part of the job.

  • Have the courage to rollback and review decisions

Target audience

Senior and Junior Rails Developers

Pitch

I struggled a lot in thinking what I wanted to submit. I had a lot of technical talks ideas, but none of them seemed interesting enough. What makes a talk interesting and rememberable is the story behind it. This is going to be an interesting story and could be kept as a future reference as you keep history books. I am a good candidate for this topic because I went actively through these phases, I wrote blog articles, I moved the community through these steps and my company as well. I had to take decisions that had an impact both financially and in the way everyone was working at Renuo.