Authentication

Summarized using AI

15 Minutes Rails Application

Marcin Stecki • March 15, 2014 • Wrocław, Poland

In the video titled "15 Minutes Rails Application," Marcin Stecki presents a rapid demonstration of developing a simple Ruby on Rails application within a constrained timeframe of 15 minutes, which he humorously refers to as a '15 minutes legacy Rails application.' The primary focus is on the challenges and pitfalls associated with quick application development in Rails, advocating that despite its ease of use, one can easily encounter significant issues during the process.

Key points discussed throughout the video include:
- Setup Process: Marcin highlights the bootstrap process for creating a Rails application, emphasizing the utility of Rails scaffolding to generate initial templates and code structure.
- Application Functionality: The demonstration centers on a club bouncer app where users can create events, with functionality for invited and non-invited guests. This distinguishes between user access based on invitations.
- Deployment Challenges: The speaker discusses deploying the application to Heroku and the need for proper database setup and migrations as foundational steps for successful deployment.
- Error Handling and Debugging: Throughout the demonstration, Marcin encounters errors related to user authentication and database migrations, illustrating the trial-and-error nature of development and the utility of resources like Google and Stack Overflow for problem-solving.
- Critique of Rails: Marcin critiques the Rails ecosystem, acknowledging that while it allows for quick application development, it can also lead to convoluted code and significant maintenance challenges. He reflects on his personal experiences with coding and debugging legacy applications, emphasizing the importance of continuous learning and adaptation in software development.
- Community and Learning: The talk encourages developers to share knowledge and help others avoid the common pitfalls of creating legacy applications, fostering a responsible growth of the Rails community.

The conclusion encapsulates Marcin's reflections on the Rails framework: while it serves as a fantastic foundation for rapid application development, its drawbacks require keen consideration from developers to ensure clean, maintainable code. The talk ends with a humorous note on the reality of developing within Rails, echoing the sentiment that with proper guidance and practice, developers can effectively harness the framework's capabilities.

Through this engaging presentation at the wroc_love.rb 2014 event, Marcin Stecki underscores both the potential and challenges of Ruby on Rails, motivating audiences to become mindful developers who actively contribute to improving the ecosystem.

15 Minutes Rails Application
Marcin Stecki • March 15, 2014 • Wrocław, Poland

This video was recorded on http://wrocloverb.com. You should follow us at https://twitter.com/wrocloverb. See you next year!

Slides: http://talks.madsheep.pl/talks/rapid

Marcin Stecki with 15 MINUTES RAILS APPLICATION

15 minutes apps with rails - where this will take you? Let's rant the 'easy application development with Rails' and show how fast can you go wrong. The "15 minutes legacy rails application".

wroclove.rb 2014

00:00:13.599 So this is a Rails conference, I think one of the best in Europe. I was thinking about writing a Rails application.
00:00:24.320 I did some workshops recently, and I had a lot of bootstrapping tasks. You know, every second day, I had to bootstrap a new Rails application.
00:00:35.920 Of course, there are scripts for that, but there are some key lessons I've learned.
00:00:40.160 Awesome! So, yet another Ruby on Rails application in X minutes and in easy steps. Let's set X to 15 minutes and see how far we can get within these steps.
00:00:56.800 The app is very simple; it's basically a simple club bouncer app. You know, the guy that doesn't let you into the pub? Well, I know that guy. He's always saying, 'Those are too sporty shoes; you can't go in.' So, this is a similar kind of app like Facebook events. Not invited people can only see that there is an event, but they won't see who's coming or where it is.
00:01:34.400 In our application, users can create a party. They can log in with Facebook, create a party, invite other users, and the invited users can see party details and the guests list. However, non-invited users can log in and see the party but without any details or other participants.
00:01:47.360 We will try to deploy this to Heroku. An easy Rails setup is straightforward; that's obvious and easy to Google. We are going to set up the database, migrate the data, and create the database. After firing up the server, it works awesome!
00:02:09.679 Using scaffold is a really useful tool. Every new Rails application now needs to be bootstrapped. The default layout has to be user-friendly. So let's generate some scaffolds, make them look pretty, and keep migrating again and again.
00:02:22.480 Awesome! Now we have users, but they cannot log in yet. So you Google how to log in a user with Facebook. Omniauth is supposedly the best solution. You just add some columns to your user model and update your routes, and it works!
00:02:38.319 For authentication, you need something in your user model to create the user from the Omniauth data. This is the default method that they suggest. Furthermore, you also need to make adjustments in the sessions controller. Here, we will fetch the info that Omniauth sends us. If we find the user, we're good to log him in; otherwise, we create the user. There is even a bit of security involved here as we reset the session to prevent session fixation.
00:03:04.640 To finish this off, we will set our current user in the application controller so we can use that everywhere and add a method to check whether we are logged in or not. Awesome! Now, let's see the results. Oh! Let's see what went wrong.
00:03:43.599 Oh, that was actually easy. I forgot to migrate and the helper methods needed to be specified in the proper way. Works! Awesome!
00:04:03.600 We assume the user will have parties and will be able to invite other users to those parties. So let's create the parties. We now know that we have to migrate every time we do something, so we do that again.
00:04:20.479 Again, we create some nice scaffolds for the parties. However, when we go to see them, it looks like the user was treated as a string, so you cannot create a party unless you somehow manage to serialize the user object to a string yourself. Let's fix that by changing the field to a select.
00:04:40.240 Well, there’s still an issue because the users are still not displayed correctly. Google again! Stack Overflow, etc. It's an easy fix, and that's awesome.
00:05:11.280 Time’s up! This went fast since I trained this a couple of times. However, in reality, I was Googling all over the place to find solutions that are default in the Rails community now. Time's up – we managed to do 16 steps or actions, which I guess is good.
00:05:44.000 Let’s see what we got: we have a working application! That’s fine. The external provider login is working, which is good. Users can create parties with descriptions. It’s not entirely usable but given that it was done in 15 minutes, come on, that’s okay.
00:06:05.920 It took another 16 minutes to finish this with the Rails thing, following guides and what we found on Google, so the total time was about 75 minutes. Thank you, Mr. President!
00:06:31.360 It looks like it's not bad; in 75 minutes, we've created a working application that makes people miserable because they can't see the party details. Come on, that’s good!
00:06:52.720 So can you say with me, 'Rails is awesome'? Come on! On three… One, two, three!
00:07:05.760 Oh! Did you just get excited about Rails? A few things went wrong, and we're going to see what exactly went wrong.
00:07:23.680 To be honest, I cheated a little bit. I only showed you what I did in 15 minutes; I didn't show you the sluggish process that followed in the next hour.
00:07:59.040 What went wrong? I was a bit slow at this, which was a surprising realization. I'm not very skilled at doing Rails scaffolds. I'm not sure if that's a skill you really need, but I got better after a few practice sessions.
00:08:31.480 There were more errors on the way, and toward the end, there were even more issues. Testing, surprisingly, turned out to be tricky, as the guides suggest.
00:09:21.760 A few tricky parts of code I copied from Stack Overflow proved to be problematic. I marked those parts for you. In your tests, you need to have the correct environment setup.
00:09:48.399 There's also a difference in workflows between creating a user and finding a user. The finding process is in your controller while the creation process is in your model, so you cannot treat them equally in your test, which is a bit frustrating.
00:10:39.600 In any stop in your user testing, it always has to respond to an ID. This is not a real issue, but it's something I found later during the final 16 minutes.
00:11:02.640 I was sending invites to parties. What party can go on without invites, right? I wanted the inviter to be able to send a batch invite, so that when they are inviting guests, they aren’t bombarded with invites themselves.
00:12:01.440 This is easy to implement, but it creates a dependency in your test. It can be challenging to track your user and the relevance of missed invites. My test was complicated by the fact that some validation on invites was firing all the time.
00:12:49.360 I was trying to make sure my users don't invite themselves to the party, so they don't feel forever alone. This requirement made testing complicated.
00:13:20.080 This presented numerous issues with Rails. It appears the whole Rails ecosystem has its drawbacks. It's hard to maintain and develop in the first place.
00:13:55.680 The code was convoluted and difficult to understand, especially the controller parts. The tests raised concerns as well.
00:14:15.920 In 2014, we already knew Rails had issues. We know that now, and we could have known for years.
00:15:04.560 Here’s a code climate score from a three-year-old project we maintain at work. It's getting better, but at the time we took it over, it had a score of around two. If you're not using code climate, anything below three is concerning.
00:15:47.680 This project was just nine months old and already very low at 1.5. It had several security issues flagged by standard code analysis.
00:16:09.120 What we have here is a few weeks old Ruby on Rails application that’s already at a very concerning 1. Anyway, a lot is going on and things need to change.
00:16:41.680 So, what we really see is a legacy Ruby on Rails application that we all need to be aware of, and that's regrettable. The truth remains that while Rails is great, its challenges are significant.
00:17:25.839 Rails is an awesome foundation, and it's great for startups. If I can build a meaningful application in just 75 minutes, imagine how quickly I could develop a full-fledged application with a few extra days!
00:17:50.239 For beginners, Rails is incredibly beneficial. Even though I was using only information found online, it worked eventually, though a bit challenging.
00:18:17.600 For me, Rails offers a good basis for a framework that fulfills your specific cases. No one template will cover all applications.
00:19:00.920 Every case is unique, and you, as the developer, will have to flesh out the framework for your needs. The way you structure your framework will ultimately define how your code will be followed by others.
00:19:44.320 Every other person who comes after you will see how you’ve constructed this code and probably mimic your approach. In essence, Rails sets the groundwork for developing your own coding rules.
00:20:07.760 It’s essential to note that it helps create a shared understanding for other programmers who will engage with your application down the line.
00:20:30.880 To conclude, I prepared a complicated graph that illustrates this well. Please focus because it took weeks to assemble this diagram.
00:20:53.440 This illustrates the structure of our community, with everyone represented, especially you, the most valued attendees. Many others couldn't or didn't bother to show.
00:21:12.560 I don’t have a one-size-fits-all solution for involving others in this scene. But remember, you can educate newcomers, lead workshops, and spread awareness.
00:21:25.280 Your responsibility is to extend your knowledge and inform them, ensuring they don't fall into the trap of creating more legacy applications.
00:21:43.720 That was my presentation on the 15-minute Ruby on Rails legacy application, aka 'The Cake Is a Lie.' Thank you!
00:22:04.320 Questions?
00:22:07.840 Yes?
00:22:11.760 The applications with the low scores? Those are clients just interested in our services.
00:22:25.760 Ultimately, we don't actively seek out projects like those.
00:22:38.240 The previous code base we had from India was acceptable; I can't really comment on it.
00:22:48.480 Don't call DHH! The issues appear to be multiplying, and Rails isn't scaling as needed. It's very much a responsibility for the developer.
00:23:08.560 Don’t rely solely on him for guidance on how to do your work.
00:23:14.720 We can certainly get better at this, and there are numerous solutions out there that aren’t part of default Rails, but since Rails serves as a great foundation for your application.
00:23:40.160 You can easily incorporate these alternatives, like service objects and decorators.
00:23:50.880 And finally, just out of curiosity, is anyone here using anything outside of Rails? I'm not using any other framework on the backend.
00:24:11.680 For my projects, I use a framework based on my own thoughts and ideologies over Rails.
00:24:22.560 This applies to all applications, and I won't blame the framework for my mistakes.
00:24:42.080 That's it. Thank you!
Explore all talks recorded at wroclove.rb 2014
+17