00:00:20.480
User groups are awesome, and I'm going to go really fast. There's a blog version linked at the end that has a bunch of links, so be ready for it. Awesome people go to user groups. I'm Christopher Krailo, and I go by C krailo on the internet—GitHub, Twitter, all that good stuff. I work for Calami, and we are looking for interns. So if you're new to Ruby and you're here to learn, stop by, say hi to me, and get to know the Calami team.
00:00:43.800
I run Dallas Ruby. Now, Mark is working full-time as well, I guess full-time, if you would say, right? I'm also an Elixir language enthusiast. This year, I'm working on a user group for Elixir and we'll get some more of that going. In case it wasn't obvious, I love bacon. So who here considers themselves awesome? By awesome, I mean you go to user groups and talk to your fellow Rubyists. Raise your hand. Excellent!
00:01:11.600
So why should you go to a Ruby user group? Well, you can make a lot of friends, network, and learn plenty. You can also do some teaching. As we all know, when you're teaching, you're also learning at the same time, which helps you become really good at your craft. Often, there are hack nights where you can work on code in coffee shops with others. You can even give short talks—don’t be afraid to speak! New developers are always welcome, and speeches can be as short as 5 minutes.
00:01:37.560
It turns out if you package up four lightning talks you can get to a conference. We're in this together, so bring your friends, co-workers, and significant others—it's a grand time! Ask questions, get help, and stay updated on cool new tools, like the latest gems and vulnerabilities. Here are some local user groups: the Dallas Ruby group meets every Tuesday, with presentations on the first Tuesday and hack nights on other Tuesdays. There's also Ruby Fort Worth, which meets on the fourth Tuesday for presentations.
00:02:11.680
There's a downtown Dallas Ruby on Rails group that meets once a month, usually on a Tuesday. Additionally, there are Ruby groups in Austin that meet on Tuesdays. Spread the word! You can find local Ruby groups through bitly Ruby groups. I’ll put the rest of this lightning talk on that blog soon, so get everyone you know to a Ruby group. We're nice people, we're here to help, and we’ll make you better!
00:02:55.040
My name is Aaron Lasseigne, and I work for OrgNC. There are a number of us here; you might have seen us walking around. I want to talk to you about interactions. I want to start by talking about controllers and actions within a controller. When you first start with Rails, you probably saw a video about making a blog or scaffolded something.
00:03:16.360
It looked nice, right? It was clean; you could understand what was going on, and you were happy with it. You wanted to notify a new user to welcome them, so you gather communities and groups. You need to put that person in a default group when they join and notify the admin so they know. What started off nice and clean began becoming less so over time. After a while, things escalate and you reopen the file to find it's ballooned to 500 lines, and you get concerned. Others have faced similar issues, and we rallied around the idea of making skinny controllers and fat models.
00:03:43.640
We decided that all the business logic should go into the model where it belongs. We refactored and we got there. Users could now join groups, send password reminders, find other users, and start dating—all thanks to some good refactoring. But a year later, we open that file again and find we have God objects and 1500-line models. Everyone has faced this at some point, and we ended up with the same problem again.
00:04:17.000
We yelled for more models to take advantage of the 'M' in MVC more. The problem is, Rails tends to point us towards nouns when we think of models, and we usually create purely persisted models. It took a while to get our heads around not doing this. Even after blog posts like the Kingdom of Nouns, we still struggle with this. We often drop actions onto nouns as second-class citizens in our code. We need to elevate these verbs into first-class citizens and find a space for business logic that keeps it together instead of spreading it across five models.
00:04:43.920
That’s where interactions come in handy. In Orcs Inc., we found this pattern useful. The idea is to take all your business logic, encapsulate it, and push your models into it. This way, everything stays organized in a tight package. We tried a few methods and ended up writing our own gem called ActiveInteraction.
00:05:03.680
Let's consider a user sign-up. I know it's a bit small, but bear with me. We create an interaction for signing up a user where all the logic is contained within this interaction. So when you call it, it’s simply sign_up_user.run, and you pass in any parameters you want. The run method is your only option; it follows single responsibility. It’s a straightforward way to sign up a user.
00:05:08.400
Once you pass in your parameters, we parse them properly. If there are issues, like passing a word when you need a date, it throws an error, notifying you of the problem. You can set defaults, even as nil, which makes them optional. We’ve also added the ability to ensure that an incoming array has all strings if you require that, or other preferences in your parameters. In the end, we handle validations—similar to active model validations—which should look familiar. If everything passes those validations, we then call the execute method, which runs whatever logic we've defined.
00:05:45.600
In this case, we can build other interactions, like joining a default group. If they fail, the errors will propagate up to the primary object. So calling it looks something like user_sign_up.run. You get an outcome—the outcome contains errors and validity predicates. This can be integrated easily with forms, including Formtastic, and it behaves as you’d expect because it acts like an active model.
00:06:05.440
Now, our code resembles the initial clean state much more and is easier to digest when you're trying to figure out what's going on. With ActiveInteraction, we achieve slim controllers and models, keeping it Rails and forms-ready, giving us a very good place to encapsulate business logic. If this sounds good to you, you can find it on GitHub under orgnc/active_interaction.
00:06:40.000
Myself and Taylor are the primary developers, and we're both at the conference. Feel free to grab us if you have questions. Thank you for listening.
00:07:30.760
So I want to talk a little bit about the Lone Star Ruby Foundation. It's set to be a 501(c)(3) organization dedicated to the overall health and well-being of the Texas software development community. We started off mainly doing Ruby events and functions, organizing the last two Lone Star Ruby Conferences. However, we want to do more, and this year, we're not hosting an LSR conference.
00:07:51.640
We want to focus on smaller events and find better ways to assist the community. Our goal is to be a place where user groups can come for sponsorship or to attract speakers. For conferences that find themselves short on cash or need assistance to help pay for services, the Lone Star Foundation aims to fill that gap.
00:08:22.920
We provide sponsorships and scholarships, aiming to help make events like the Lone Star Ruby Conference a Texas-wide initiative, not just limited to Austin or Central Texas. We view the conference like Cascadia—move it around every year. We're committed to helping developers in any way we can, and promoting diversity in the Texas developer landscape.
00:08:47.440
We want to sponsor initiatives like Rails Girls and RailsBridge and get kids interested in software development, whether in Ruby or not. We also want to help with educational events that excite children to learn programming. You can send us an email or follow us on Twitter. This presentation is a step toward connecting with the community.
00:09:13.000
Now, I'm Jeremy Perez, and I work for Calami. Last year, I had my first web development interview. Calami hired me as an intern, and a month ago, I transitioned to full-time, marking a significant step for me. So, I decided to share a little about my journey.
00:09:30.360
I want to talk about how I went from the bottom to where I am now. The inspiration arose when I was asked by a candidate during an interview about how I made the jump from intern to full-time. My initial thought was, I just worked hard and they decided to keep me. After reflecting on it, I crafted three key points that helped me make the transition.
00:10:02.080
To summarize my strategy, it revolves around the acronym APP. The first 'A' stands for Ask Questions. Kayo, a mentor of mine, emphasized the importance of inquiry. While asking questions can be intimidating, it's essential for learning and moving forward. It’s a skill and an art. Knowing how to ask the right questions will yield the right answers, leading to effective strategies and results.
00:10:46.600
The second 'P' symbolizes Purpose-Driven Development (PDD), which I developed to prompt myself to answer three questions before writing any code. First, what's the intention of this code? Am I creating something new? Am I testing or refactoring? Second, what is the unmet need driving this code? Lastly, what is its significance? Will anyone use this code? These questions help clarify my focus while coding.
00:11:27.760
The last 'P' stands for Practice. Mastery involves repetition and often requires an obsession with coding. I've noticed that great programmers typically share a common trait of being obsessed with their craft at some point in their lives. Balance is often emphasized as crucial, but I've found that deep dedication can also lead to remarkable achievements.
00:12:09.680
Using myself as an example, before starting my web development career, I was a barista while identifying as a web developer, rock climber, and traveler, dabbling in different fields but rather balanced. In contrast, adopting an unbalanced approach like that of Peyton Manning, who focused intensely on training and game analysis, led to great success.
00:12:56.240
It's essential to ask whether unbalanced dedication might result in equal or greater happiness than maintaining balance. Thus, my three keys to progressing from intern to full-time status are asking questions, having a purposeful development process, and practicing compulsively. Thank you!
00:14:26.960
Now, I’m Jeffery Davis, and you can find me on GitHub as Penland365. I work at Sabre in the labs group, and Mark is my direct boss. If you don’t enjoy what I have to say, blame him! I was pondering what to present, and the inspiration struck me after hearing the news about Jim Wren's passing yesterday morning. As someone relatively new to the Ruby community, I appreciate the kind words shared by many who have been here longer.
00:14:56.960
Last year was my introduction to the Ruby community, where I asked Jim what I thought was a very newbie question. He responded thoughtfully, dedicating his time without rushing me away, which left an impression. Afterward, I looked him up and came across his esteemed talk, 'Why Not Adventures in Functional Programming,' from RubyConf 2012.
00:15:28.120
This talk inspired me to revisit functional programming, which has become my current passion alongside Ruby. I'll briefly cover three functional programming concepts or "words" that enthusiasts often reference, which also exist within Ruby's ecosystem.
00:16:00.560
First is Closure. For instance, if we have an array of numbers and use the select method, we usually pass a block. Is the expression x mod 2 equal to 0 a closure? Technically, it's not; it's an anonymous function. However, within the context of Ruby, we can treat it as a closure. To make it an actual closure, we can define a proc. So we can think of these concepts as closures for practical use, integrating them into our Ruby structures.
00:17:02.680
Next up is Tail Recursion, a significant concept in functional programming used for iteration. The difference between recursion and tail recursion is that in the latter, calculations are performed first before passing the result into the function rather than waiting to return the result up the stack. This can lead to better memory allocation.
00:17:42.440
For example, to sum numbers from one to seven with recursion, you would pass the calculation first in a tail recursive manner. This will reduce memory usage, especially in cases where you might be traversing complex recursive structures, such as trees or API endpoints that are difficult to manage.
00:18:48.800
The final concept I want to address is Monads. A monad is a structure that encapsulates several operations as a single step or flow of operations. In Ruby, we can consider them analogous to 'duck typing,' where we determine an object's capabilities based on its methods rather than an explicit type check.
00:19:33.680
In closing, thank you all for listening! I hope my discussion on functional programming concepts resonates with your programming experience in Ruby.
