# Justin Weiss Published articles for Justin Weiss. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## When you've taken a learning break, how do you catch back up? DevFeed: [When you've taken a learning break, how do you catch back up?]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2019-05-01T04:40:15Z Content type: opinion Language: en Sources: [Justin Weiss]() Topics: [Learning](), [Programming]() Tags: [learning](), [programming]() ### AI overview The article recommends catching up after a learning break by making time for learning both outside work and during work. It suggests scheduling learning sessions, using reminders, discussing job-related study with employers, and choosing useful foundational programming books. ### Source excerpt When you've been deeply focused on a big project or a new job, you might poke your head up and feel lost. Like the tech world has moved beyond you. Did that time you didn't spend learning new things finally catch up with you? And how can you close that gap? Study at home? Or learn at work? If you haven't been making time for learning, that time has to come from somewhere. But where will that time come from? Should you study on your own time? Or study on the job? It's a trick question. The answer is both. Finding time outside of work can be a struggle. It definitely has been for me, as I've gone from 0 to 1 to 2 kids. But learning something in my own time makes that thing feel more like mine. It feels more exciting, and you can pick up a topic that's more interesting than practical. If you feel like the time just isn't there, plan ahead. Set aside a specific time of day, or make up a trigger. For example, "I'll read a few pages right after I wake up", or "I'll read from 5:30-6 PM." Have the book sitting right there, and it can be its own reminder. I've also had some great times reading programming books after the family has gone to sleep. It works, but you have to be careful not to sacrifice much sleep of your own. What about on the job? When it comes to studying as part of the job, it's the same thing: plan time for yourself. I'll even block it out on my work calendar. At most jobs, nobody will specifically give you that time. Count yourself lucky if they do! (Aha!, my current employer, is one of those rare ones). For the rest, the first step is to build trust. Can you have a conversation that starts, "I'm going to spend time learning this so I can become more effective at the work we do every day?" If so, you're on the right track. You might be limited to learning something directly related to the job. For example, reading up on React if you're going to be doing more front-end JavaScript work. But that's not as limited as it seems. Work time is a great time to read ## How do you do a Rails deep dive? DevFeed: [How do you do a Rails deep dive?]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2017-08-22T04:40:15Z Content type: article Language: en Sources: [Justin Weiss]() Topics: [Rails](), [Documentation](), [Learning](), [Code]() Tags: [code](), [deep-dive](), [documentation](), [guide](), [learning](), [rails]() ### AI overview The article explains how to undertake a deep dive into a technical topic, using Rails as an example. It recommends starting with comprehensive books or official guides, then pairing reference documentation with those broader sources before reading source code. ### Source excerpt Maybe fixing a bug just spawned a dozen new ones. Or your code breaks in such a weird way that you wonder if you really understand it at all. You think it's time for a deep dive. But knowing you need to dive deeply into a topic? That's only step 1. How do you actually learn a topic down to its fundamentals? How do you learn enough that it comes naturally to you? Where do you start? There are a lot of places you could start your learning. But when I need to learn a lot about a topic quickly, books are my favorite place to start. For example, if you're doing a deep dive into git, a book called Pro Git is probably exactly what you're looking for. Books are great for deep dives because they're comprehensive: Most medium-sized topics are pretty well covered by a 200-400 page book. At the end, you might not be an expert, but you'll have a pretty good understanding and solid fundamentals to grow from. That'll help if you decide to move on to reading source code or specs. But maybe you don't want to buy a book. Or a book on your topic doesn't even exist. When that happens, where else can you look? Official documentation is a good alternative. If you're doing a deep dive into a single part of a framework like Rails, or a web technology like OAuth, official docs are an especially good match. For projects and frameworks, something named "The X Guide(s)" is your best bet for starting. For example, I often recommend the Rails Guides for new Rails developers, and the Elixir Guides are a great place to learn how to write Elixir code. But while guides are more comprehensive than, say, a blog post, they aren't totally comprehensive. Instead, you can use the guide as a jumping-off point to the reference documentation, like RDoc. Reference material is hard to understand if you don't have a way to put all those methods and classes into context. It's just a mess of details with no real structure. So I find that references work best when you pair them with guides or books. For example, a ## When to take a Rails deep dive DevFeed: [When to take a Rails deep dive]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2017-08-15T04:40:15Z Content type: opinion Language: en Sources: [Justin Weiss]() Topics: [Rails](), [Programming](), [debugging](), [Caching](), [data-modeling]() Tags: [debugging](), [deep-dive](), [programming](), [rails]() ### AI overview The article explains when developers should take a deep dive into a Rails topic: when unexpected behavior or recurring bugs reveal that their mental model is incomplete. It recommends focusing on a specific topic and building a deeper understanding to make better decisions and write more reliable code. ### Source excerpt Have you ever found a Rails topic that didn't make any sense to you? Like, you thought you knew it, so you wrote some code, and something completely different happened? Or you know you don't understand, but you kind of know enough to get by, except you spend so much time fighting edge cases that you could have been an expert in it by the time you were done? Well, what if it didn't have to be that way? Wouldn't it better to just know how things worked? To have a solid mental model of the problem in front of you? So you could just make the right decisions, and write the right code? When I was first learning web development, sessions were That Thing: I thought I kind of knew them, but I didn't. And my misunderstanding of sessions caused so many bugs that I was criticized, a lot, for the problems I created. Soon, I realized I had to take time to actually understand how sessions worked. To demystify them, to make them not scary or weird. And eventually, to be able to guess how they'd behave - and to be right. "Sessions" isn't the only topic I've done a deep dive into. Data modeling, caching, metaprogramming, they're all confusing things that are really easy to get to kind of work. But you'll run into eternally hard debugging problems if you don't understand them. In Practicing Rails, I wrote about T-Shaped learning: When you have good baseline knowledge, but push much further into specific topics as you need to. Those pushes are deep dives, and they'll help you solve huge problems over the course of your programming career. When should you do a deep dive? So how do you know when it's time for a deep dive? First, to do a deep dive, you have to know what you're diving into. Deep dives are most helpful when you're dealing with a single topic. A specific thing you can describe in a word or a short phrase. SQL query performance. Sessions. HTTP Caching. Too specific, and you miss the interactions that make a topic so complicated. Too general, and you're doing a deep dive into ## A decorator vs. a subclass DevFeed: [A decorator vs. a subclass]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2017-05-09T04:40:15Z Content type: tutorial Language: en Sources: [Justin Weiss]() Topics: [Rails](), [Inheritance](), [Polymorphism](), [Code]() Tags: [article](), [code](), [design-patterns](), [implementation](), [inheritance](), [rails]() ### AI overview This article explains when to use a decorator instead of a subclass in Rails. It shows how decorators add behavior to existing objects without inheritance, while preserving the option to use the original object and reducing dependence on implementation details. ### Source excerpt In my most recent article, I mentioned a great new feature in Rails 5.1, delegate_missing_to. With delegate_missing_to, any method that you can't find on one object is called on another object, instead: class Player delegate_missing_to :@user def initalize(user) @user = user end def points Game.points_for_user(user.id) end end Player.new(user).name # calls user.name But, like Gavin mentioned in the comments, this seems like an odd way to avoid inheritance. Why not just use a subclass? You'd get the same effect, and you don't have to add a whole new feature. It seems like a weird thing to add. There must be a reason delegate_missing_to was added, though. And for Rails features, pull requests are a great way to find those reasons. In this pull request, DHH mentioned why he suggested the feature: Here's a common pattern if you want to build a decorator: That seems like a pretty good place to start digging. Why decorators? When you build a decorator, you're changing the way an object acts, without creating a new subclass. For example, in the code from earlier: class Player delegate_missing_to :@user def initalize(user) @user = user end def points Game.points_for_user(user.id) end end You'd say that "Player decorates user," because a Player almost acts like a User, but has an extra method, points. And it does this without inheritance. Why would you need something like this? That's a tough question to answer, because like many design patterns, it's not always clear where you'd want to use it instead of something else. When would you use a decorator? Decorators could just be a more complicated way to do inheritance. I mean, which of these two lines of code is better? player = Player.new(User.new(name: "Justin")) # Player decorates User player = Player.new(name: "Justin") # Player subclasses User Clearly the second one, right? Here, creating Player as a decorator instead of a subclass is just a waste of code. But sometimes, you want to add functionality to an object later o ## The lesser-known features in Rails 5.1 DevFeed: [The lesser-known features in Rails 5.1]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2017-05-02T05:49:00Z Content type: tutorial Language: en Sources: [Justin Weiss]() Topics: [Rails](), [Ruby](), [JavaScript](), [HTML5]() Tags: [2017](), [features](), [html5](), [javascript](), [new-features](), [rails](), [ruby]() ### AI overview This article surveys lesser-known Rails 5.1 improvements, including consistent HTML5 tag helpers, the assert_changes test helper, delegation with delegate_missing_to, and the replacement of alias_method_chain with prepend. ### Source excerpt Last week, during RailsConf 2017, Rails 5.1 shipped. If you followed the announcements, you've seen the big features: better integration with modern JavaScript, encrypted secrets, and system tests. And there's my personal favorite: finally getting rid of the weird combo of form_for and form_tag, and replacing it with form_with. I can't wait to try it. But the reason I love Rails isn't the big new features. It's the little, constant improvements. It's those quality-of-life changes that make me happier when I'm writing Rails apps. And Rails 5.1 is full of them. More consistent tag helpers Have you used Rails' tag helpers, like tag and content_tag? <%= content_tag :p, @user.name, class: "name" %> Rails 5.1 adds a new tag helper syntax. Use calls like tag.div or tag.br, and you can stop worrying about parameter order and juggling two different methods: <%= tag.p @user.name, class: "name" %> <%= tag.br %> These new tag helpers support HTML5 by default, and even let you create your own elements: <%= tag.pea @user.name, class: "name" %> Assert more than just differences I love assert_difference. Before assert_difference, I spent way too much time juggling local variables in tests: old_score = @user.score @user.answer_question!(...) assert_equal old_score + 10, @user.score With assert_difference, it's much clearer what you're trying to do: assert_difference "@user.score", 10 do @user.answer_question!(...) end In Rails 5.1, assert_changes takes this one step further. assert_difference only checks changes in count. But assert_changes can check non-numerical changes, like changes between two strings, or between nil and something else: assert_changes "users(:justin).name", from: "Justin", to: "Bob" do @user.update_attributes(name: "Bob") end Instead of a string, you can give it a lambda: assert_changes -> { users(:justin).name }, from: "Justin", to: "Bob" do @user.update_attributes(name: "Bob") end to: can be anything tha ## Write that first complicated test DevFeed: [Write that first complicated test]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2017-03-01T05:05:56Z Content type: tutorial Language: en Sources: [Justin Weiss]() Topics: [Testing](), [unit test](), [Pull Request](), [Git](), [networking](), [Concurrency](), [ui]() Tags: [also](), [code](), [git](), [integration-test](), [testing](), [tests](), [unit-test]() ### AI overview This article explains how to approach testing complicated code involving threads, commands, Git, networking, or user interfaces. It recommends investing in fakes, mocks, fixtures, and test-specific configuration, and using integration tests as a practical starting point when fast unit tests are difficult to write. ### Source excerpt What code of yours isn't tested? Is it code that deals with complicated situations that you don't control? Threads, running commands, git, networking, or UI? Our apps are most interesting when they're complicated. They're also most dangerous. And that's why code that's hard to test is exactly the kind of code that needs to be tested well. That doesn't always happen. Instead, every time you touch that code, you touch lightly. You tread carefully. Maybe you do some manual testing. And when you send the pull request, you hope your teammates don't realize those tests don't exist. But that won't make things better. You'll run into the same problems, the same bugs, the same stress next time - and every time after that. How can you finally make those challenging tests something you can rely on? Shift your mindset The most frustrating thing about these tests? It's going to take ten times as long to write it as it feels like it should. If you estimate the time the test saves you against the time you spend writing the test, it just doesn't seem worth it. But it's not just about this test. It's about all your future tests. Most of the best-tested code I've seen has a lot of support. It's not just the code in test/models. Extremely well-tested code has fakes, it has mocks, it has a good set of test fixtures, it has configuration options specifically for the tests. All that takes time to write and put together. But once you have it, it feels so good. You can come up with test after test, feeling comfortable about your code, and confident in quickly you can move after the investment you've made. You can rely on the work you've already done. So it's not just about preventing bugs in complicated code. It's also about making future code easier to test, piece by piece. Make it an integration test (for now) Sometimes, though, it's not about understanding the value - I get it. Instead, I just get stuck because I can't figure out how to write a small, fast, unit test. How do you know yo ## Writing a one-time script in Rails DevFeed: [Writing a one-time script in Rails]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2017-02-14T06:08:51Z Content type: tutorial Language: en Sources: [Justin Weiss]() Topics: [Rails](), [Script](), [data](), [migration](), [import](), [CSV](), [Database]() Tags: [capistrano](), [csv](), [data](), [database](), [heroku](), [import](), [job](), [migration](), [other](), [rails](), [rake](), [scheduler](), [script](), [sidekiq](), [structure]() ### AI overview This Rails tutorial explains how to handle one-time data tasks, comparing database migrations with rake tasks and scheduled background jobs. It recommends rake tasks for code that must be tested locally and run in production, while noting when migrations are appropriate and what risks model changes can create. ### Source excerpt Have you ever wanted to import a bunch of data into your app from a CSV file? Or maybe you need to fix badly encoded characters in some of your customer reviews. Or you changed your mind about how you wanted to store data in Redis, and had to move everything from the old format to the new one. At Avvo, we called these "ad-hoc tasks." As in, you probably only need to run them once. So what's the best way to handle an ad-hoc task in Rails? Write a database migration A migration works well if you need to change the structure of the data in your database. It tracks whether the task was run, it carries over changes to other environments - it's what migrations were built for. It's also what you're probably already using them for. If you're changing data at the same time, a migration might work well. But there are some things to watch out for. Calling something like Permissions.create(...) in your migration can cause you trouble. If the model has changed, your migration might break, because your model might not be available when the migration runs. Or your model might have changed between the time you wrote the migration and when it ran. There are ways to get around this, but they're error-prone and can fail in weird ways. Migrations are also less useful if your task doesn't involve ActiveRecord. These aren't deal-breakers. But I tend not to import or change much data in migrations. There are better options. Write a rake task You have a task. You probably only want to run it once. And you want to be able to test it on your machine and run it in production. Rake tasks work really well for this. Rails can even generate rake tasks for you: $ be rails g task locations import create lib/tasks/locations.rake This creates a file for you to stash your code into: lib/tasks/locations.rakenamespace :locations do desc "TODO" task import: :environment do end end Inside that task block, you can use all your models and the rest of the code in your Rails app. It's easy to import and chang ## How to get from theyâEUR ™re to they're DevFeed: [How to get from theyâEUR ™re to they're]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2015-09-22T06:35:48Z Content type: tutorial Language: en Sources: [Justin Weiss]() Topics: [Ruby]() Tags: [encoding](), [how-to](), [ruby]() ### AI overview A tutorial explains how text becomes garbled when UTF-8 bytes are misread as Windows-1252 and then encoded again. It shows how to reverse those steps in Ruby to restore the original characters. ### Source excerpt In last week's article, you learned a short process that solves most encoding problems. But there's one encoding problem that's much harder to solve. I know you've seen it. (Or maybe youâEUR ™ve seen it?) It's when a curly quote turns into âEUR ™, or an em-dash turns into âEUR ". It'll make you think you've gone crazy. It should just work! You could create a giant table, so you could find bad characters and replace them with good ones: [{broken: 'âEUR "', fixed: "--"} {broken: "âEUR "", fixed: "-"} {broken: "âEUR ˜", fixed: "'"} {broken: "âEUR ™", fixed: "'"} {broken: "âEUR œ", fixed: """} {broken: "âEUR ", fixed: """}, ...] But there's an easier, more reliable way to fix those broken characters. Why does good typography always break? Last week, you learned that an encoding is just a way to turn groups of meaningless bytes into displayable characters. Not every character can be represented in a single byte, because there are more than 256 possible characters. So some characters, like the curly quote ', are represented with more than one byte: irb(main):001:0> "they're".bytes => [116, 104, 101, 121, 226, 128, 153, 114, 101] Even though the string only has 7 characters, they're represented by 9 bytes! When you focus on just the curly quote: irb(main):002:0> "'".bytes => [226, 128, 153] You'll see it uses 3 bytes. And our messed up string, theyâEUR ™re, has three characters where it should just have one. That seems like more than a coincidence, right? It seems like those three bytes should be read as UTF-8, where they'd represent a curly quote. Instead, each byte is showing up as a different character. So, which encoding would represent [226, 128, 153] as âEUR ™? If you look at a few tables of popular encodings, you'll see it's Windows-1252. You can check this in irb: irb(main):003:0> "they're".force_encoding("Windows-1252").encode("UTF-8") => "theyâEUR ™re" (We need that last .encode("UTF-8") to display the string in the console.) Yep! That's the problem. But it gets worse. The data is supposed to be UT ## 3 steps to fix encoding problems in Ruby DevFeed: [3 steps to fix encoding problems in Ruby]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2015-09-16T06:59:11Z Content type: tutorial Language: en Sources: [Justin Weiss]() Topics: [Ruby](), [Exception]() Tags: [array](), [exception](), [numbers](), [ruby]() ### AI overview A Ruby tutorial explains how string encodings relate bytes to characters, why changing an encoding can alter printed text without changing the underlying bytes, and how conversion errors occur. It introduces Ruby methods for converting strings, inspecting bytes, and interpreting bytes under another encoding, then presents a three-step process for fixing encoding bugs. ### Source excerpt You only really think about a string's encoding when it breaks. When you check your exception tracker and see Encoding::InvalidByteSequenceError: "\xFE" on UTF-8 staring you in the face. Or maybe "they're" starts showing up as "theyâEUR ™re". So, when you have a bad encoding, how do you figure out what broke? And how can you fix it? What is an encoding? If you can imagine what encoding does to a string, these bugs are easier to fix. You can think of a string as an array of bytes, or small numbers: irb(main):001:0> "hello!".bytes => [104, 101, 108, 108, 111, 33] In this encoding, 104 means h, 33 means !, and so on. It gets trickier when you use characters that are less common in English: irb(main):002:0> "hellṏ!".bytes => [104, 101, 108, 108, 225, 185, 143, 33] Now it's harder to tell which number represents which character. Instead of one byte, ṏ is represented by the group of bytes [225, 185, 143]. But there's still a relationship between bytes and characters. And a string's encoding defines that relationship. Take a look at what a single set of bytes looks like when you try different encodings: # Try an ISO-8859-1 string with a special character! irb(main):003:0> str = "hellÔ!".encode("ISO-8859-1"); str.encode("UTF-8") => "hellÔ!" irb(main):004:0> str.bytes => [104, 101, 108, 108, 212, 33] # What would that string look like interpreted as ISO-8859-5 instead? irb(main):005:0> str.force_encoding("ISO-8859-5"); str.encode("UTF-8") => "hellд!" irb(main):006:0> str.bytes => [104, 101, 108, 108, 212, 33] The bytes didn't change. But that doesn't look right at all. Changing the encoding changed how the string printed, without changing the bytes. And not all strings can be represented in all encodings: irb(main):006:0> "hi∑".encode("Windows-1252") Encoding::UndefinedConversionError: U+2211 to WINDOWS-1252 in conversion from UTF-8 to WINDOWS-1252 from (irb):61:in `encode' from (irb):61 from /usr/local/bin/irb:11:in `
' Most encodings are small, and can't handle every pos ## Keeping your logs from becoming an unreadable mess DevFeed: [Keeping your logs from becoming an unreadable mess]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2015-09-08T07:23:49Z Content type: tutorial Language: en Sources: [Justin Weiss]() Topics: [Rails](), [Logging](), [log management](), [debug](), [GitHub API]() Tags: [api](), [debug](), [gateway](), [github](), [json](), [logging](), [logs](), [rails]() ### AI overview This tutorial explains how to use Rails TaggedLogging to make log messages easier to categorize and filter. It shows how tagged logs can clarify request activity, calls to other APIs, background jobs, and logged-in user activity, helping developers trace complex paths and investigate bugs. ### Source excerpt When you run into a strange, seemingly unsolvable bug, improving your logging can be the best step you can take. Great logging is the easiest way to detect and fix entire classes of bugs. When you log enough information, you can see how your data changes during a request. You can track the calls you make to other services, and investigate the response. In fact, when debuggers failed, logging helped me fix the toughest bug I've ever run into. But log too much, and your log files will quickly turn into a jumble of unreadable, unhelpful messages. How can you slice just the information you care about out of that pile of data? Can you print messages in a way that's easy to filter later? Marking your log messages Rails includes TaggedLogging, which can help you quickly categorize related log messages. When you tag a logger, you'll get a marker at the beginning of your message. So instead of: Finding people... Person Load (0.3ms) SELECT "people".* FROM "people" Found 0 people! You could tag the Rails logger: logger.tagged("People") do logger.debug "Finding people..." @people = Person.all logger.debug "Found #{@people.length} people!" end And you'd see something like this: [People] Finding people... [People] Person Load (0.3ms) SELECT "people".* FROM "people" [People] Found 0 people! Now, log messages that care about different things can look different. Some tagged logger examples As you log more often, and log more complicated things, you'll naturally notice areas where those tags will make your messages clearer. But there are a few places I've found tagged logging particularly helpful. I'll usually tag those right away. You can log requests you make to other APIs: logger.tagged("GitHub API") do uri = URI("https://api.github.com/repos/rails/rails/tags") logger.info { "Fetching #{uri}" } tags = JSON.parse(Net::HTTP.get(uri)) logger.info { "First tag: #{tags.first["name"]}" } end [GitHub API] Fetching https://api.github.com/repos/rails/rails/tags [GitHub API] First tag: v4.2 ## Should you use scopes or class methods? DevFeed: [Should you use scopes or class methods?]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2015-09-01T07:30:32Z Content type: tutorial Language: en Sources: [Justin Weiss]() Topics: [Rails](), [Ruby]() Tags: [activerecord](), [code](), [rails](), [ruby](), [scopes]() ### AI overview The article compares Rails scopes with regular Ruby class methods. It explains that scopes are useful for simple, chainable object selection and express intent, while class methods are preferable for more complicated logic or when preloading scopes is needed. ### Source excerpt This article is also available in Korean, thanks to Soonsang Hong! Scopes are a great way to grab the right objects out of your database: app/models/review.rbclass Review < ActiveRecord::Base scope :most_recent, -> (limit) { order("created_at desc").limit(limit) } end You'd use the scope like this: app/models/homepage_controller.rb@recent_reviews = Review.most_recent(5) Calling that scope, though, looks exactly like calling a class method on Review. And it's easy to build it as a class method, instead: app/models/review.rbdef self.most_recent(limit) order("created_at desc").limit(limit) end app/controllers/homepage_controller.rb@recent_reviews = Review.most_recent(5) So why would you use a scope when you could use regular Ruby class methods? Is it worth keeping these totally separate, but equivalent, concepts in your head? What if you run into weird bugs? Isn't all this extra stuff the kind of thing that makes Rails harder to learn? When would it make sense to use a scope instead of a class method? Why use scopes when we already have class methods? What if you wanted to grab all the reviews written after a specific date? But if no date was specified, you wanted all the reviews returned instead? As a scope, that looks like this: app/models/review.rbscope :created_since, ->(time) { where("reviews.created_at > ?", time) if time.present? } Easy enough, right? What about the class method? app/models/review.rbdef self.created_since(time) if time.present? where("reviews.created_at > ?", time) else all end end It takes a little bit of extra work. Scopes prefer to return scopes, so they're easy to chain together: Review.positive.created_since(5.days.ago) But to get the class method to work the same way, you have to specifically handle the case where time is nil. Otherwise, the caller would have to figure out whether it has a valid, chainable scope. Methods that always return the same kind of object are really useful. You don't have to worry as much about edge cases or errors ## How to predict the future of programming DevFeed: [How to predict the future of programming]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2015-07-29T05:52:27Z Content type: opinion Language: en Sources: [Justin Weiss]() Topics: [Programming](), [software-architecture](), [Rails](), [Refactoring](), [Agile](), [Test-driven development](), [Wiki](), [CRUD](), [REST API](), [Java](), [XML]() Tags: [agile](), [architecture](), [programming](), [rails](), [refactoring](), [rest-api](), [tdd](), [xml]() ### AI overview This opinion article argues that software development problems often recur even as their solutions evolve. It recommends studying older work by Martin Fowler and the authors of the Agile Manifesto, along with resources such as the C2 Wiki, to understand recurring patterns in architecture, refactoring, testing, and application development. ### Source excerpt Why did Rails become so popular, so quickly? The simplicity helped, especially if you came from the Java, XML, Enterprise world. It was also marketed incredibly well. But that's not everything. A lot of Rails' success in the startup world came from a simple fact: The problems businesses have aren't that unique. Rails was great at creating CRUD sites, while remaining flexible. And that's really all a ton of businesses need. Especially at the beginning. But this isn't just true for businesses. A lot of the problems we face as software developers don't change. Sure, our solutions evolve. They cycle. We get better. But the same solutions discovered by the last generation of developers can still help us today. So, do you want to know the answers to the problems you'll face in the future? The best thing you can do is look to the past. Look to the past On his website, Martin Fowler has an unbelievable collection of good solutions to common problems. Have you been hearing devs talk about Event Sourcing? He wrote the definitive article on it 10 years ago. Chasing performance and reliability problems with your new REST API or Service-Oriented Architecture? It's his first law of distributed objects, from close to 15 years ago. Avdi Grimm told me that "If you want to lead the technology curve, start investigating whatever Martin Fowler was writing about a decade ago." That's totally true. The time you spend reading through the patterns on his website will be a great investment in your programming future. And that's not even mentioning the refactoring patterns. Going further, just about any book or article written by the authors of the Agile Manifesto is worth reading - 15 years ago, they were working through the same software architecture problems we run into today. You can find a lot of their discussions on the C2 Wiki. The debates we have about when TDD makes the most sense? They're all there. And they've been there. The wiki has been around for a while, and it's still a fant ## Turn Ruby conference videos into your own personal podcast DevFeed: [Turn Ruby conference videos into your own personal podcast]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2015-07-21T06:58:03Z Content type: tutorial Language: en Sources: [Justin Weiss]() Topics: [Ruby](), [Homebrew](), [dropbox](), [Tool](), [RSS Feed](), [Code]() Tags: [code](), [dropbox](), [homebrew](), [install](), [rss](), [ruby](), [tool]() ### AI overview This tutorial explains how to turn conference video talks into a personal podcast. It describes extracting audio with youtube-dl, hosting the file through Dropbox, and adding it to Huffduffer to obtain an RSS feed for a podcast player. ### Source excerpt Ruby conferences are awesome. There are so many people sharing so much knowledge, and you'll take something away from almost every talk. And even if you can't be there, new conferences mean lots of new talk videos. But there's a problem. Videos take time. Even at 1.5x, they'll still last 20 or 30 minutes each. And that's focused time that's hard to find as often as I'd like. Podcasts, though, have already found a place in my life. I start almost every commute by firing up Overcast and listening to a few episodes. And besides the commute, you can listen to them while you walk the dog, or do the dishes. You can hear them as you go off to sleep. So, after conference videos are posted, I'd love to take some of the non-code-heavy talks and put them where I'll naturally hear them: inside my podcast player. And it turns out there's a pretty easy way to do just that. Creating a personal podcast with Huffduffer Huffduffer is a website that turns audio files you find anywhere on the web into your own personal podcast station. This is really cool! But there's a problem when you try it with conference talks: Most conference videos are conference videos. So, before you can add a talk to Huffduffer, you have to grab just the audio out of it. And to do that, you have to find a way to download the video. Fetching a video with youtube-dl When you see a video on a site like Youtube, Vimeo, or Confreaks, and you'd rather have it on your machine, you can use a little tool called youtube-dl. On a Mac, it's easy to install using Homebrew: brew install youtube-dl (You can install it on other systems using the instructions on the site). Once it's installed, if you wanted to download Kylie Stradley's great RailsConf 2015 talk so you could watch it offline, run: youtube-dl http://confreaks.tv/videos/railsconf2015-amelia-bedelia-learns-to-code This is close to what we want. But to put it in a podcast, you only need the audio. youtube-dl supports that with the -x flag, but you have to install ## A web server vs. an app server DevFeed: [A web server vs. an app server]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2015-07-15T07:13:18Z Content type: tutorial Language: en Sources: [Justin Weiss]() Topics: [Rails](), [servers](), [Deployment](), [nginx](), [SSL]() Tags: [code](), [deploy](), [deployment](), [nginx](), [rails](), [server](), [software](), [ssl]() ### AI overview This tutorial explains the difference between web servers and application servers in a Rails deployment. It describes how web servers such as Nginx and Apache handle requests, static assets, SSL, and forwarding, while application servers run the Rails application and manage requests in production. ### Source excerpt When you research how to deploy your Rails app, you'll see a lot of names: Apache, Unicorn, Puma, Phusion Passenger, Nginx, Rainbows, and many more. They all seem to fit under the "deploying Rails" category of software, but there's a key difference between them. Some are "web servers," and others are "app servers." Once you understand which is which, and where each category fits in your system, deployment will make a lot more sense. But the categories aren't always clear. What's a web server, and how is it different than an app server? Can you use one without the other? And where does Rack fit in? What's a web server? A web server is a program that takes a request to your website from a user and does some processing on it. Then, it might give the request to your Rails app. Nginx and Apache are the two big web servers you'll run into. If the request is for something that doesn't change often, like CSS, JavaScript, or images, your Rails app probably doesn't need to see it. The web server can handle the request itself, without even talking to your app. It'll usually be faster that way. Web servers can handle SSL requests, serve static files and assets, compress requests, and do lots of other things that almost every website needs. And if your Rails app does need to handle a request, the web server will pass it on to your app server. What's an app server? An app server is the thing that actually runs your Rails app. Your app server loads your code and keeps your app in memory. When your app server gets a request from your web server, it tells your Rails app about it. After your app is done handling the request, the app server sends the response back to the web server (and eventually to the user). You can run most app servers by themselves, without a web server in front of it. That's probably what you do in development mode! In production, though, you'll usually have a web server in front. It'll handle multiple apps at once, render your assets faster, and deal with a lot ## Documentation fixes as a starting point for open-source contributions DevFeed: [Documentation fixes as a starting point for open-source contributions]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2015-07-08T03:23:04Z Content type: tutorial Language: en Sources: [Justin Weiss]() Topics: [Open Source](), [Documentation](), [Pull Request](), [GitHub](), [Rails](), [Elixir]() Tags: [contribute](), [documentation](), [github](), [open-source](), [pull-request]() ### AI overview The article recommends documentation fixes as an accessible way to begin contributing to open-source projects. It explains that doc changes can often be made without setting up the project, are easier to revise during pull-request review, and help maintainers address unclear documentation. ### Source excerpt This article is also available in Korean, thanks to Dohyung Ahn! Thom Parkin made a great point in the comments of an earlier article of mine: Great advice. But you missed one very important [final] point. Since this is Open Source, once you have figured out the details of that feature/function where the documentation is a bit light, YOU SHOULD UPDATE THE DOCS AND SUBMIT A PULL REQUEST. In that way the entire community benefits, and you can even gain some "coder cred" for your participation! I'm happy Thom mentioned this, because it's so important. Fixing documentation is the easiest way to start contributing back to the projects you use and love. My first contributions to projects like Rails, Rubinius, and Elixir have all been doc fixes. I've made small tweaks to make things clearer, explained some things that you could only discover by reading the code, even just fixed broken formatting. These have all been quick, easy ways to help out some big open source projects. Even when they're my only contributions to a project, they've still helped future users, and Future Me. And that's what open source is all about. Why documentation fixes are such a great way to get started Doc fixes are the least intimidating way to contribute to a big project like Rails: You don't have to set up the project in order to fix the bug. Since you're just updating the documentation, you don't have to get the tests or the app running. Sometimes, you won't even have to clone the project to your machine - you can make your change right on GitHub! If the maintainer asks you to make changes to your pull request, they're usually a matter of wording or taste. Those kind of changes can be easier to stomach than criticism of your code. And it's easier for you to make those changes, because you don't have to update tests or code, just words. Documentation is hard for a project maintainer, so updates are appreciated. Often, authors are too close to the code to understand where the confusing parts are. ## Creating easy, readable attributes with ActiveRecord enums DevFeed: [Creating easy, readable attributes with ActiveRecord enums]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2015-06-30T07:39:15Z Content type: tutorial Language: en Sources: [Justin Weiss]() Topics: [Rails](), [enum](), [Ruby](), [Code](), [Database]() Tags: [activerecord](), [code](), [database](), [enum](), [enums](), [rails](), [ruby]() ### AI overview A tutorial on Rails ActiveRecord enums for attributes with a small, mostly fixed set of values. It explains how enums map readable values to database integers, provide query and predicate methods, and introduce maintenance concerns such as ordering and sharing mappings outside Rails. ### Source excerpt Imagine a question that can be either "pending", "approved", or "flagged". Or a phone number that's a "home", "office", "mobile", or "fax" (if it's 1982). Some models call for this kind of data. An attribute that can have only one of a few different values. And that set of values almost never changes. It's a situation where, if it were plain Ruby, you'd just use a symbol. You could create a PhoneNumberType or QuestionStatus model and a belongs_to relationship to hold these values, but that doesn't seem worth it. You could stuff them in a yaml file, but now you have to look in a totally different place to figure out what your object can do. In 4.1, Rails took a stab at solving this problem with ActiveRecord enums. A few values, in the model ActiveRecord enums are pretty easy. You give your model an integer column: bin/rails g model phone number:string phone_number_type:integer List the values that attribute can take: app/models/phone.rbclass Phone < ActiveRecord::Base enum phone_number_type: [:home, :office, :mobile, :fax] end And now you can deal with strings instead of numbers. Instead of this: irb(main):001:0> Phone.first.phone_number_type => 3 You'll see this: irb(main):002:0> Phone.first.phone_number_type => "fax" You can change that attribute using either strings or ints: irb(main):003:0> phone.phone_number_type = 1; phone.phone_number_type => "office" irb(main):004:0> phone.phone_number_type = "mobile"; phone.phone_number_type => "mobile" Or even using a bang method: irb(main):005:0> phone.office! => true irb(main):006:0> phone.phone_number_type => "office" You get methods for asking if your attribute has some specific value: irb(main):007:0> phone.office? => true And you can find all objects with the value you're looking for: irb(main):008:0> Phone.office Phone Load (0.3ms) SELECT "phones".* FROM "phones" WHERE "phones"."phone_number_type" = ? [["phone_number_type", 1]] If you want to see all the different values you can use, along with the numbers they're as ## How to preload Rails scopes DevFeed: [How to preload Rails scopes]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2015-06-23T20:17:34Z Content type: tutorial Language: en Sources: [Justin Weiss]() Topics: [Rails](), [App](), [SQL]() Tags: [activerecord](), [how-to](), [performance](), [rails]() ### AI overview This tutorial explains why Rails scopes can cause N+1 queries when loading related records. It shows how to wrap a scope in an association so it can be preloaded, reducing the example from six SQL calls to two, and recommends keeping the scope definition in one place. ### Source excerpt This article is also available in Korean, thanks to Soonsang Hong! Rails' scopes make it easy to find the records you want: app/models/review.rbclass Review < ActiveRecord::Base belongs_to :restaurant scope :positive, -> { where("rating > 3.0") } end irb(main):001:0> Restaurant.first.reviews.positive.count Restaurant Load (0.4ms) SELECT `restaurants`.* FROM `restaurants` ORDER BY `restaurants`.`id` ASC LIMIT 1 (0.6ms) SELECT COUNT(*) FROM `reviews` WHERE `reviews`.`restaurant_id` = 1 AND (rating > 3.0) => 5 But if you're not careful with them, you'll seriously hurt your app's performance. Why? You can't really preload a scope. So if you tried to show a few restaurants with their positive reviews: irb(main):001:0> restauraunts = Restaurant.first(5) irb(main):002:0> restauraunts.map do |restaurant| irb(main):003:1* "#{restaurant.name}: #{restaurant.reviews.positive.length} positive reviews." irb(main):004:1> end Review Load (0.6ms) SELECT `reviews`.* FROM `reviews` WHERE `reviews`.`restaurant_id` = 1 AND (rating > 3.0) Review Load (0.5ms) SELECT `reviews`.* FROM `reviews` WHERE `reviews`.`restaurant_id` = 2 AND (rating > 3.0) Review Load (0.7ms) SELECT `reviews`.* FROM `reviews` WHERE `reviews`.`restaurant_id` = 3 AND (rating > 3.0) Review Load (0.7ms) SELECT `reviews`.* FROM `reviews` WHERE `reviews`.`restaurant_id` = 4 AND (rating > 3.0) Review Load (0.7ms) SELECT `reviews`.* FROM `reviews` WHERE `reviews`.`restaurant_id` = 5 AND (rating > 3.0) => ["Judd's Pub: 5 positive reviews.", "Felix's Nightclub: 6 positive reviews.", "Mabel's Burrito Shack: 7 positive reviews.", "Kendall's Burrito Shack: 2 positive reviews.", "Elisabeth's Deli: 15 positive reviews."] Yep, that's an N+1 query. The biggest cause of slow Rails apps. You can fix this pretty easily, though, if you think about the relationship in a different way. Convert scopes to associations When you use the Rails association methods, like belongs_to and has_many, your model usually looks like this: app/models/re ## A guide to the best beginning Rails resources DevFeed: [A guide to the best beginning Rails resources]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2015-06-16T06:19:09Z Content type: tutorial Language: en Sources: [Justin Weiss]() Topics: [Rails](), [Ruby](), [Tutorial](), [Development]() Tags: [beginner](), [books](), [guide](), [learning](), [rails](), [ruby](), [tutorial]() ### AI overview A guide for beginners choosing resources to learn Ruby and Rails. It recommends starting with programming fundamentals, then progressing through introductory guides, books, tutorials, and Rails documentation, with advice on debugging, feature development, and testing. ### Source excerpt There are a ton of books, videos, podcasts, and courses for learning Rails. There's no way you'd have time to go through them all! So what's the best way for an absolute beginner to learn Ruby and Rails? Which resources should you start with, and when? Books and websites If you're totally new to programming, the best place to start is Learn to Program, by Chris Pine. It's an intro to the core programming ideas you'll need to know. If you're planning to learn Ruby and Rails, it's especially great, because it uses Ruby for all of the examples. After that, Daniel Kehoe's Learn Ruby on Rails is a gentle introduction to Rails. It teaches you a small part of Rails that will prepare you to take on the harder resources. If you already know a few other languages or frameworks, check out the free Getting Started with Rails guide. It's a good, short intro to Rails, that will teach you Rails' concepts and core ideas. Once you know the basics, there are two bigger books that will fill out your Rails knowledge. Agile Web Development with Rails is my favorite general Rails book. It does a good job of teaching first by example, and then by reference. We use it at work to teach devs without Rails experience, and like most of the rest of the Pragmatic Bookshelf books, it's very good. The Ruby on Rails Tutorial is the other big Rails resource. It walks you through most of what you need to know to build a fully functional example app. I know a lot of great Rails developers who got started with the Rails Tutorial. And the web version is free, so you can see if it's your style before you commit to it. If you put in the effort, you'll get a lot out of it. Once you've gone through one or two of these books, it's pretty normal to feel confused and frustrated. Especially when you try to put everything together and build your own apps. My book, Practicing Rails, will help you solve the most painful problems you'll run into as you start your programming career. In Practicing Rails, you'll lear ## You've got the Rails basics. So why do you feel so slow? DevFeed: [You've got the Rails basics. So why do you feel so slow?]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2015-06-09T03:56:10Z Content type: opinion Language: en Sources: [Justin Weiss]() Topics: [Rails](), [Refactoring](), [Testing](), [Test-driven development](), [Learning]() Tags: [beginner](), [code-quality](), [maintainability](), [rails](), [refactoring](), [tdd](), [testing](), [writing]() ### AI overview This article explains why developers often feel slower after learning more about testing, maintainability, refactoring, and design. It recommends working in stages: begin with a rough draft, produce a simple working implementation, and then refine it through testing and refactoring while recognizing diminishing returns. ### Source excerpt You're confident about the core ideas behind Rails. You can write working code, no problem. And you're learning more about code quality, refactoring, writing great tests, and object-oriented design. By this point, you're starting to feel like you're getting it, that you're on the path to becoming an expert. When you look backwards, you see just how far you've come, and you're pretty happy with your progress. So why do you feel so slow? Now that you care about testing, maintainability, and design, it feels like it takes you way more time to ship anything! Is it even possible to ship high quality code quickly? It's all part of the process This feeling is incredibly common, no matter what you're learning. Now that you're no longer a beginner, you're starting to see all the different shapes that your code could have. You have more alternatives to think through whenever you put down a line of code. You have to test edge cases you never recognized before. You've learned lots of helpful skills. But right now, they still take a lot of thought. You have to weigh every decision you make, so you feel comfortable that you're making the right decision based on the things you've learned. It will get faster, though. The skills you've learned will become more automatic. You'll build intuition. And you'll be able to make better decisions more quickly. Which is nice to know, but it doesn't help you right now. So what can you do now, to finish things faster? Take it in stages If you're obsessed with writing perfect, high-quality, highly-maintainable code every time you put your fingers on the keyboard, you'll never get anything done. When I get stuck, I write code the same way I write articles. You'd start with a rough draft. Maybe sketch out some tests, code, or comments. Or even write some ideas out on paper. At this point, you wouldn't worry about structure, you're just using code to clear up the vague ideas you have in your head. Then, I turn those ideas into a straightforward imp ## 3 ways to configure your Ruby API wrappers DevFeed: [3 ways to configure your Ruby API wrappers]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2015-06-01T21:01:05Z Content type: tutorial Language: en Sources: [Justin Weiss]() Topics: [Ruby](), [API](), [configuration](), [Environment Variables]() Tags: [api](), [configuration](), [implementation](), [ruby]() ### AI overview This tutorial compares three ways to configure Ruby API wrappers: global configuration, per-instance configuration, and a default-instance pattern that combines convenient access with configurable instances. It discusses the tradeoffs of each approach, including shared mutable state and repeated setup. ### Source excerpt When you use Ruby to wrap an API, you have to have a way to configure it. Maybe the wrapper needs a username and secret key, or maybe just a host. There are a few different ways to handle this. So which one should you choose? The easy, global way You might want your service to act like it's always around. No matter where you are in your app, you'd have it ready to use. Otherwise, you'll spend three lines of configuring it for every line of using it! You could make the configuration global, using constants or class attributes: config/initializers/product_api.rbProductApi.root = "https://staging-host.example.com/" ProductApi.user = "justin" ProductApi.secret = "mysecret123" app/controllers/products_controller.rbdef show @product = ProductApi.find(params[:id]) end Lots of gems use this pattern. It's pretty easy to write, and really easy to use. But it has some big problems: You can only have one ProductApi. If you want to use the Product API as two different users, or hit different servers from a single app, you're out of luck. ProductApi has global data that's easy to accidentally change. If a thread or a part of your app changed ProductApi.user, everything else using ProductApi would break. And those are painful bugs to track down. So, class variables have some problems. What if you configured instances of your Product API class, instead? What would it look like with #initialize? If you used instances, you'd create and configure your API wrapper when you need it: app/controllers/products_controller.rbdef show product_api = ProductApi.new( root: "https://staging-host.example.com/", user: "justin", secret: "mysecret123") @product = product_api.find(params[:id]) end Now, you can pass different details to your API whenever you use it. No other methods or threads are using your instance, so you don't have to worry about it changing without you knowing it. This seems better. But it's still not as easy as it should be. Because you have to configure your API every time you u