00:00:14.830
Hello, I'm Maciek. I work for a large software company located in Josephin, Poland. The company has many Java developers, C# developers, and even a specialized front-end team focused on JavaScript. When I started a couple of years ago, I was just a junior Java programmer interested in Ruby. I was quite frustrated writing in Java and wanted to work with something different. Let's go back to 2012, and remember that old joke: how many Ruby developers from Jeff in 2012 would fit in the elevator? Yes, all of them. It was a vicious cycle because without developers, there are no companies, and without companies, no one wants to learn the technology.
00:00:49.299
I wanted to do something with Ruby because I didn't want to be solely a Java developer. At that time, there were very few Ruby developers. Fortunately, the University of Technology in Josephin offered Ruby courses, and I seized the opportunity to teach as well. I gave some talks and lectures and invited students to intern with us. At the time, I was not just a Java developer; I was the only Ruby developer in our company, along with one other. After some training and recruitment, we established an internship program. This presentation aims to detail how our students create potentially usable applications as per our requirements. The goal is to teach them how to deal with clients, so they provide us with what we request rather than what they randomly decide upon.
00:01:55.600
We start by teaching with the Rails framework because we want to provide them with a solid foundation. We want to give them a fresh start and a sense of accomplishment, enabling them to quickly build applications using a growing system. We also cover advanced concepts such as service objects, decorators, and clean architecture. During the internship, students must complete Ruby assignments. This helps them learn not only the framework but also advanced concepts in the Ruby language that may be challenging to grasp during web development. Moreover, through the internship, we familiarize them with the tools we use in our workflow, including JIRA and Capistrano, among others.
00:02:46.500
Now, to the processes we follow. Based on Scrum methodology, we conduct daily stand-ups to synchronize our efforts and plan each sprint, which gives interns a feel for estimating tasks. We all know estimating is challenging, but it's often necessary. At the end of each week, the interns do a review to present a functional application. They receive feedback, allowing them to customize the application according to our requirements. They also perform retrospectives to reflect on their processes and identify areas for change.
00:03:05.760
Thank you. Now, let’s discuss some frustrations with CI servers. I have found two major issues: they are slow and prone to random failures. We can argue about proper test-writing practices, emphasizing decoupling, but reality often doesn't allow us that luxury. So why not address both problems? Why not have a CI server that intelligently distributes work, dividing it into smaller chunks to run in isolation on separate machines? By doing so, we can run tasks in parallel and ensure some isolation, which helps alleviate the problem.
00:06:42.630
If we add retry mechanisms, we further protect against random failures, as the more we retry, the more our failures diminish. Let me introduce you to Delay, a CI server called Cider. It's open-source and written in Clojure. You can configure it in Llama and explore many interesting features.
00:07:00.840
To briefly summarize how Cider works: we have jobs managed by RSpec suites, and tasks run individual spec files. These tasks are composed of several scripts, which run bundles and execute RSpec commands. The scripts run on separate executors, aggregating their states and rerunning failed trials. Further enhancing this, there’s a gem called Cider Riser that simplifies CI configuration. If you have any questions, feel free to ask.
00:08:54.360
So, we discussed some functions and features of the CI server. Now, who here enjoys estimating projects? Honestly, it's time-consuming, boring, and often feels like a waste of time. The primary challenge with estimating is its inherent unreliability. One reason for this is the planning fallacy, which describes our tendency to underestimate the time needed to complete tasks.
00:09:07.750
Despite our past experiences indicating otherwise, we continue to underestimate. My name is Tomek, and I work at Lunar Logic. A year ago, we devised a tool aimed at improving the estimation process. While it is not a perfect tool—nor does it give precise hours—it is certainly an improvement over mere guessing. Since then, we have utilized this method for our clients. It’s called data-driven forecasts, and we use it to create estimates.
00:10:12.760
To explain the process: we gather data. If it’s an ongoing project, we reference previous data from that project. For new projects, we leverage data from similar past projects if available. For example, consider a five-day sprint with various tasks denoted by their lead times. If a client wishes to estimate additional stories, we can randomly select from previous lead times to forecast potential completion dates. The idea is to run simulations about ten thousand times, resulting in a histogram detailing the estimated completion timelines for our projects.
00:11:56.570
Hello, my name is Adam, and I want to discuss the Spree Commerce open-source project. I am part of the Spark Solution team, specializing in e-commerce applications, and I proudly stand as a member of the Spree code development team. Spree is a Rails-based e-commerce engine available on GitHub and it provides both front-end and back-end capabilities for online stores.
00:13:30.390
As of now, there are over 69,000 commits from around 600 contributors, making it one of the top 20 most starred projects on GitHub. The first version of Spree was released in 2007 by Sean Caulfield. Today, Spark Solution is responsible for maintaining and developing Spree Commerce. We are actively seeking contributions and new core development members and are preparing to release version 3.1.
00:14:39.580
Now, let’s quickly cover the features of the Spree engine. The RESTful API provides a broad idea of what is included in the project. For developers, using Spree can be beneficial because it’s built in Ruby, making it easy for Ruby developers to adopt. It presents an out-of-the-box solution that satisfies most common e-commerce needs, eliminating the need to reinvent the wheel. Our Spark Solution team has contributed a starter kit with a Rails, Spree, React.js, Redux setup, as well as Webpack and hot reload capabilities, providing developers with everything necessary to create a modern single-page e-commerce store.
00:15:57.600
Furthermore, we offer support through Slack for anyone needing assistance or guidance. I encourage you to download the starter kit from the official repository on GitHub. It's incredibly user-friendly, requiring just three commands for installation. With a fast computer, you can be set up in as little as 11 minutes!
00:17:01.450
If you're interested in becoming a core member of our continually developing project, please join our Slack team. You can ask questions there or contribute to the development of Spree Commerce. If you’d like to learn more tonight, feel free to reach out to me. Thank you!
00:18:55.300
Hello everyone, I’m Adam, running Sunday Coding, and I’d like to discuss tracking attacks. Let’s start with cookies. Cookies are an essential part of the modern web; can you imagine a website in 2016 without that annoying cookie pop-up? Truthfully, cookies allow us to store the state between requests and track users. However, there are challenges. Users are increasingly aware of tracking cookies and may choose to block them, which complicates tracking.
00:19:27.710
This brings us to attack tracking. An eTag is part of the HTTP protocol and serves as a cache validation mechanism. When your browser requests a static resource, the server responds with that resource and an eTag header representing a checksum of the image. The next time the browser makes that request for the same image from its cache, it sends that eTag value. The server verifies the values, and if they match, it returns a '304 Not Modified' response, allowing the browser to use the cached copy.
00:20:43.900
Much like cookies, we send a value to the client, and the client sends it back. However, the crucial aspect here is how we generate this eTag. There is no standard method for generating it, meaning it is entirely up to the web server's implementation. Typically, it is a checksum, ensuring invalidation when content changes. However, we can tailor it to be unique for each user.
00:22:35.580
For instance, when we encounter a first-time visitor (without a header), we can randomly generate a value, store it, and send it as an eTag. When the user sends this value back, we recognize them as a returning visitor, allowing us to associate them with past requests. This method enables tracking without cookies, works universally, and is difficult for users to block. Thank you for your attention.
00:23:42.520
Continuing with our discussion panel, let's explore some unheralded features of RubyMine. You can switch to distraction-free mode or presentation mode for different working environments. Additionally, using Shift + Command + A helps you find any IDE action. For example, you can split your editor vertically or unsplit it effortlessly.
00:24:50.820
To navigate effectively, pressing Command + E shows recently opened files, while using Shift lets you view recently edited files. When selecting code blocks, you can shrink the selection down to your specific snippet, save it, and use it throughout your project. You can also change the code style of a file with a single click, preview differences, and make changes directly.
00:26:12.690
Lastly, the find usages feature allows you to see all usages of your methods or variables, and you can use Command + B to jump to a declaration. You can run your tests in debug mode as well, monitoring variables as they change while executing code, which allows us to pinpoint where things go wrong during testing. If you're interested in a more personal demo or uncovering additional features, please reach out to me!
00:28:03.700
Focusing on Sonic Pi, which allows you to write Ruby code to create sound. I want to demonstrate how this software operates by playing a piece or code live! Sonic Pi utilizes Ruby syntax to produce sounds. You can code rhythm and melodies by utilizing the bridging of programming and musical creativity — allowing for fun and educational engagement. I encourage everyone here to explore Sonic Pi further after my demonstration.
00:36:42.470
Now, moving on to more serious content. I'm Michał Zając, and I specialize in recognizing and analyzing poorly written Ruby code. Today, I’ll share examples of bad code and insights into why obtaining fewer examples can be puzzling — perhaps because the quality around us is improving. I have curated around four examples which I'd like to present. Let's start with some straightforward code, which many of you might recall from your early days in Ruby programming.
00:38:35.890
This is a typical beginner's mistake; it's poorly constructed but still functional. As we dive deeper, I’ll present examples that showcase more advanced reasoning behind coding choices, such as using metaprogramming creatively — which uniquely highlights Ruby's flexibility. The greater our understanding of the language's capabilities becomes, the better we can appreciate its potential.
00:39:34.760
Our exploration of code quality doesn’t end here; it encompasses understanding doubts surrounding Ruby's meta programming techniques. I'll provide a deeper analysis of peculiar instances where associated coding risks come to fruition or become artifacts of legacy systems. Every code fragment tells a story, and despite many faces we encounter, they shape lessons we draw for future projects.
00:41:45.090
My goal isn’t just to showcase problems — rather to instill thinking that pushes Ruby coding towards maintaining better practices as we uncover the intricacies of metaprogramming. Consequently, let's transform the way we critique code: challenge existing conventions while appreciating Ruby's potency. Ultimately, garbage in means garbage out, so we must work toward refining everything we produce.
00:42:49.290
Simplicity can be key, but creativity doesn't take away from usability, and often we can combine these traits. My colleagues here will tell you how we analyze Ruby code, breaking down greater challenges when working with its patterns. They’ll highlight why it's simpler to grasp but still presents complexity; not merely a language, it’s an art form tied conveniently with logic.
00:44:30.550
By the end of our session, we want to improve our understanding of appreciation and respect towards the art of programming in Ruby — with all the quirks and nuances that persist. Entry into a discussion about language brings forth countless pathways for sharing ideas that completely evolve our approach. So let's continue to exchange tips and explore new realms together.
00:46:53.240
Hello again. My name is Marcin, and a colleague spoke yesterday about Codebeat. Within our team, we have analyzed various programming languages, one of them being Ruby. Analyzing Ruby is particularly interesting due to the flexibility allowed by the language, which can create unique challenges and opportunities. We often embrace the unpredictable nature of Ruby, finding beauty in its chaos, while sensing that our exploration is only beginning.
00:48:01.180
Through static analysis, we can explore myriad options given by Ruby's design—but we want to determine which constructions are effective and identify potential pitfalls. As Ruby continues to evolve, so too must our understanding of its patterns and structures. In doing so, we submit ourselves to uncovering efficiencies that yield good patterns.
00:48:56.210
I encourage each developer to reflect on their own journey with Ruby and consider sharing knowledge during our discussions. Particularly, I invite you to ponder your own experiences and inspire others—in this way, we strengthen the Ruby community and become advocates for innovation and conscientious coding practices.
00:50:17.840
In conclusion, I want to speak briefly about Grapefruit and why they matter, especially with our integration of Vega. Grapefruit functions as a microframework built within the Ruby environment that seamlessly combines various operations. Vega, as understood from its capabilities, serves as a communicative standard for APIs and has now been adopted widely within the industry.
00:51:45.860
Our aim in integrating with Vega is to ensure proper regulation and documentation of APIs while simultaneously providing a smooth transition between various programming practices. As we push this project forward, I encourage you to consider contributing. Your input and development involvement can help us reach industry standards, creating a cohesive approach to API specifications.
00:53:06.860
I would like to see strong participation from you, members of the Ruby community, and I'm genuinely keen to facilitate discussions around this. Your knowledge could help shape the direction of this initiative. Thus, let's work towards making Grapefruit a powerful model that intertwines our coding capabilities with user-friendly APIs and documentation.
00:54:39.490
Before we conclude, I'd like to share a few essential points regarding mentoring junior developers. It is vital to keep them engaged and motivated by giving small, efficient tasks leading to quick wins and satisfaction. This method sets a foundation for disciplined learning while reinforcing their learning through gradual increments in task complexity. By being mindful, you could instill in them a relentless drive towards greatness.
00:56:48.190
So, thank you for your time, and let’s discuss how we can work towards fostering that motivation and making the programming journey a rewarding one!