DEV Community: Brett Codes

Over 100 project ideas for developers learning any new programming language

Brett Codes — Mon, 17 Oct 2022 13:53:38 +0000

I've kept a private list of ideas for programming projects for years. These projects aren't dream ideas for striking it rich. No. They're projects for learning. Little projects. Things I'd like to see exist. Projects that would stretch my skills a bit but not require working another 20 hours a week.

I know I learn best by building things, trying to figure out what I don't know, and doing online research when I'm stuck.

When it comes to learning a new programming language, library, or framework, knowing what an appropriate project is for learning can be overwhelming on top of learning the new thing! So I've collected over 100 project ideas of varying difficulty and type into a free book called Projectbook. It's free and open source.

The projects contain specifications, concepts, examples, and mock-ups I designed to get you inspired and building things. From CLIs to apps to games, I've collected all of the projects I'm personally interested in building.

📺 Prefer a video intro?

Okay, let's dig into some examples of some of the projects.

HTTPal CLI

The gist: write a CLI that makes HTTP network requests and responds with the output.

curl and wget are common programs used to transfer data to or from a server, like downloading a file over HTTP. This project is writing something similar to them. Start with just GET requests and then go from there.

I always call this idea httpal because it's kinda fun. It's your buddy for making requests!

Spec

This could look something like:

httpal https://openlibrary.org/books/OL7353617M.json

That would make a GET request to that API endpoint for Fantastic Mr. Fox and return the JSON, which could then be output to a file like:

httpal https://openlibrary.org/books/OL7353617M.json > fmf.json

Concepts

Making network requests, often times available within the standard library of a language
Outputting the response body
Basic CLI interactions

Extra Credit

Follow redirects
Support different forms of authentication and request headers
Support other HTTP methods like PUT, POST, and DELETE
Support specifying a request body file, like a JSON file, to include in the request body
Support other protocols! Maybe a better name would be reqbud. 😬
What if program specifically catered to those interacting with GraphQL APIs? That means it would always POST to the same endpoint but allow for configurable requests and variables. gqlpal???
What if there was a way to load requests for a project from a variety of spec files and easily make those requests? Like a CLI version of Postman or Paw.

RecipeHub

Want to build a full-stack web app? Okay!

The gist: GitHub for recipes! But for food, not software.

I love cooking and baking. It's seriously so fun and creative. I love taking recipes and adjusting and tweaking them to my liking. The neat thing about recipes is that they're not observed by copyright! The photos, the descriptions, etc. are, but the actual ingredients and steps aren't. That always gets me thinking about how awesome it would be if there was a web application for people to share their recipes on. It would be centered around loading quickly, browsing by tags, collecting your favorites, and copying and modifying others' recipes.

I'm hungry and excited just writing this!

Mock-Ups

There are a lot of features that could exist for this app, and mocking them all up would be a lot, but here's a gist of what some of the key elements of the UI could be like (viewing your recipes, viewing a recipe, and the recipe form):

Specs

User accounts (authentication)
Recipe management
- Data model for a recipe:
  - Name
  - Description
  - Ingredients
  - Instructions
Viewing another user's recipes
Fork a recipe (make a copy to edit and adjust to your liking, but maintain an association to the original)

Concepts

Authentication
Permissions
Data management
Network graph

Extra Credit

Add ability to favorite another user's recipes & view your favorites
More metadata like prep time and cooking time (and thus total time)
Image upload for a recipe
Tags for things like vegan, breakfast, etc. where you can discover similar recipes
If you build the back-end with an API, you could then build out a mobile app that consumes it! That would be pretty handy when cooking in the kitchen
- Dream feature: when viewing a recipe on the mobile app, prevent the phone from sleeping

Find over 100 more projects in Projectbook.

Let me know what you think and if it inspires you to build anything.

Happy building!

RSpec's spec_helper vs rails_helper Explained

Brett Codes — Thu, 06 Oct 2022 12:00:00 +0000

When you install RSpec in your Rails application, two of the files it generates are spec/spec_helper.rb and spec/rails_helper.rb. The generated source contains a lot of helpful comments, but it might not be immediately clear why there are two helpers instead of one.

Intro to the helpers

When you write specs in your Rails app, at the top of each file you require a helper that loads RSpec and other dependencies:

require "spec_helper"
require "word_count"

RSpec.describe WordCount do
  # your specs here
end

Or with rails_helper:

require "rails_helper"

RSpec.describe User do
  # your specs here for the User model
end

Which file you choose to require has implications when it comes to running unit tests for a given file or directory. Let's dig into what those implications are and the differences between them.

spec_helper’s purpose

spec_helper is intended to be the most lightweight, fast RSpec config in your app. It's great for testing plain old Ruby objects (POROs) that don't require Rails. Even if those POROs require a gem or other classes, if they don't need Rails, you can use spec_helper.

The spec_helper is what you'd use if you are testing a Ruby gem with RSpec or anything non-Rails. It configures RSpec and that's just about it.

rails_helper’s purpose

rails_helper requires spec_helper at the very top of the file, so it pulls in all of the config from that. So spec_helper is our base and rails_helper stacks on top of it.

You might be thinking, why not just have one helper and keep it easy?

I've certainly worked in codebases that do that, but that was before people understood that keeping them separate is important, especially when it comes to fast TDD cycles.

Running individual tests that require spec_helper is much faster than requiring rails_helper because it's not loading all of the Rails app and gems. It's just loading RSpec, the spec_helper, and the files required for the test.

The rails_helper exists to be used with specs that test functionality that can't exist without Rails—controllers, routes, models, views. When testing a model's validations, you'll want to make sure those are happening in the context of Rails and working correctly, so you need to require Rails.

The rails_helper is also useful for configuring gems and support files needed by those tests, like setting up FactoryBot. It's also where you might want to reset and clean up the database after every test run (an timely operation in the context of fast tests).

The speed differences

With a fresh Rails 7 codebase (source), here's the difference in speed for testing one plain Ruby class's method that lives in lib:

spec_helper: Finished in 0.00182 seconds (files took 0.04228 seconds to load)
rails_helper (cold run): Finished in 0.01671 seconds (files took 1.07 seconds to load)
rails_helper (warm run): Finished in 0.01058 seconds (files took 0.45144 seconds to load)

There are two values to be aware of. The time it takes to run the specs (the first number) and the time it takes to load the files from disk. They are separate values and their aggregate is the total time it takes to run a given spec (or specs).

The spec_helper loads the files for testing 25x faster on cold runs! Even on a warm run with the files already loaded, spec_helper is still 10x faster at loading the files!

On top of that, running the actual code in the specs is 10x faster than both.

That's a huge difference when it comes to the time it takes and you'll notice it as you're going through the Red -> Green -> Refactor TDD cycle.

Why is this?

This happens because the rails_helper is loading hundreds, potentially thousands of Ruby files and configuring the Rails app. Rails does a lot! Look at your Gemfile.lock and see the dependency tree. Even if you have only ~15 gems in in your Gemfile, it's likely there are far more than that because each gem has its own dependencies.

There's a cost to pulling in dependencies and working with an application framework as large as Rails—it slows things down.

What does this mean?

This means that if you want to have faster tests when you're actively writing your code, you'll want to require spec_helper.

But what does this mean, really? I'm building a Rails app, I need `rails_helper`.

I get it. You're writing view, controller, and model code that all needs Rails to test them properly. That's true. And those tests are valuable. But there are still things you can do and should be aware of.

Use plain old Ruby objects (POROs)

There comes a point when writing code you actually aren't doing anything related to Rails. Sure, maybe the objects being acted upon are models, but you could use POROs and then in your tests pass in instance_double and require spec_helper. When you build complex applications beyond CRUD, you'll begin to write more Ruby code that's not dependent on Rails.

You'll also be writing more unit tests, which, in general, won't need Rails. So you want to really leverage spec_helper when writing unit tests for POROs.

Your POROs can live in lib or in app, wherever you want to put them. That's up to you ultimately.

Slowest common denominator

It is important to note that the speed of your tests will ultimately come down to the slowest required helper. If you have three spec files that get run and one of them requires rails_helper, that'll cause all of them to run slower because the file loading time is as slow as the slowest helper.

Since you're most likely running all of your tests on CI or occassionally on your machine, that's not a big deal. But it's something to be aware of. What you require won't impact the speed of your entire test suite running. For that, you'd need parallelization and a deeper dive into fixing your slowest specs.

What we're optimizing for is the tests you run while you're actively writing your code. Those individual file test runs need to be fast. Any friction and slowdown breaks focus.

Create other helpers

Just like how rspec-rails creates two helpers from the get-go, you can do the same! Do you use Capybara for acceptance tests? Create spec/acceptance_helper.rb that requires rails_helper (thus also requiring spec_helper) that configures Capybara and then in those specs:

require "acceptance_helper"

There's no reason to slow down all of your Rails unit tests with the loading and configuring of even more code.

You can create whatever helpers you want. If you've got a directory of POROs in lib that all require a common set up, create a helper for them that requires spec_helper.

In summary

Optimize for fast single file test runs, which is where speed matters most with TDD
Keep spec_helper as minimal as possible, basically only configure the core of RSpec in it
Be mindful of what you require
Use POROs when possible for their clarity, their single responsibility, and faster unit tests
Create separate helpers for different needs in your app, don't make single file test runs slower just because you need something loaded and configured in other specs

Managing your spec helpers and being intentional about them and understanding the difference is a major part in having fast, maintainable tests with Rails and RSpec.

Why I'm Learning Rust

Brett Codes — Wed, 05 Oct 2022 13:51:09 +0000

I keep asking myself: Why learn Rust when there are so many other languages I could learn? Why not learn Go instead? Everyone seems to pit them against each other. Why not double-down on TypeScript? Why even bother learning a new language or framework if it's unlikely I'll get to use it for anything aside from hobby projects?

These questions are valid ones, but they are based upon a flawed premise. It is 100% okay for someone to learn anything without any good reason! Learning can be purely just for fun, based on a hunch, based on an intuition. So while I don't have great answers to those questions, I at least have some hopes and dreams and a few motivating factors.

Why Rust

My first programming language was Java. My computer science teacher in high school made us print out our code to grade it. I'm not sure why, but that's what he wanted.

Then I started programming in C# because XNA (Microsoft's game engine for indie Xbox 360 development) required it. Then I dabbled in ActionScript 3 for Flash programming, C++ for college classes, a bit of PHP, and somehow landed on using Ruby and JavaScript. Then 10 years flew by. Strange how time works. I've dabbled a bit here and there. A little Go. A little Haxe. But nothing aside from a few weeks or months of experimenting.

As I've grown as a developer, I've found myself longing to get a bit lower level. I'm thinking a lot more about performance and memory. I'm a bit tired of the slowness and memory usage of Ruby (and Rails). Sure, they work and are mature. But they are, in many ways, resource hogs. They don't encourage thinking about program structure and correctness. Performance just seems like less of a priority and concern. But I'd like to write more performant code. I'd like to understand threading and memory usage more. I'd like to build cross-platform tools and games and code.

The thought of writing lower level code that isn't C or C++ is appealing. I enjoyed coding in those languages over a decade ago, but they felt dated in many ways, like writing separate header files. It's been too long for me to have any salient thoughts on them thought. 😅

Also, through TypeScript, I've been re-exposed to the joys of statically typed languages. Having a great language server with types increases confidence with coding and is much more ergonomic than having to look at the docs online whenever one wants to look something up. The idea of a performant, strongly-typed, modern language is extremely appealing!

I'm also continually annoyed by dealing with nil errors in Ruby and null and and undefined errors in JavaScript. I understand why they exist, and they can be manageable, but to think that there's another way is interesting to me.

Programming Beyond the Web

I've primarily done web application development for the last 13 years. It's enjoyable and ever-changing. But I'd like to do some other types of programming too. There are only so many web forms you can build before it begins to feel a bit rote. Game dev, desktop GUIs, command line tools, networking code—Rust seems like a great for all of them. There's so much breadth to the types of programming out there that it feels like I've barely scratched the surface.

The Promise of Polyglot

While there will surely be a bit of overhead of context switching between languages, I think learning a variety of languages will make me a better programmer over all. Rust, so far, seems like it will help me reframe how I think about programs and write my code. That's major! Breaking out of the paradigms of a language and come back with a fresh perspective can be really valuable.

Is Learning Rust Good for My Career?

Without question, learning a new language is good for anyone's career because you're learning something new and being exposed to other types of programming. Whether or not I'll ever have a full-time job programming Rust or that I'd even want to do that remains to be seen.

I'm curious to see how Rust feels for building APIs and web applications. That'll be really interesting coming from Rails and Ruby. I'm not sure of the maturity there yet or what to expect.

But I'd be willing to bet that we'll continue to see more widespread usage of Rust. Even in just the last few years where I've casually followed it, its usage has continued to grow. It's also matured, has a solid package manager, great docs, and a wonderful community. It doesn't seem destined for obscurity. It, in so many ways, seems like an ideal language to have in one's toolkit.

What I've Done So Far

Built a simple open-source CLI driven by tests: https://github.com/brettchalupa/werds
Reading through The Rust Programming Language Book
Halfway through the Rustlings exercises
Went through the Command Line Applications in Rust guide
Reading Hands-On Rust (really fantastic so far)

Hopes & Dreams

I'd really like to use Rust for building some significant hobby projects! That's my goal at least. We'll see how it goes. Early learning and progress has been promising. I've been enjoying it. It's been clicking. I've got ideas for what I want to build (collected in Projectbook).

I'm gonna get to it! I'll share what I learn, what I make, and how it's going.

DEV Community: Brett Codes

Over 100 project ideas for developers learning any new programming language

HTTPal CLI

Spec

Concepts

Extra Credit

RecipeHub

Mock-Ups

Specs

Concepts

Extra Credit

RSpec's spec_helper vs rails_helper Explained

Intro to the helpers

spec_helper’s purpose

rails_helper’s purpose

The speed differences

Why is this?

What does this mean?

But what does this mean, really? I'm building a Rails app, I need rails_helper.

Use plain old Ruby objects (POROs)

Slowest common denominator

Create other helpers

In summary

Why I'm Learning Rust

Why Rust

Programming Beyond the Web

The Promise of Polyglot

Is Learning Rust Good for My Career?

What I've Done So Far

Hopes & Dreams

But what does this mean, really? I'm building a Rails app, I need `rails_helper`.