In this lesson you're going to build a RubyGem that provides a CLI interface to an external data source. Your code will be packaged as a RubyGem and install a CLI for the user. The CLI will be composed of an Objected Oriented Ruby application.
- Package as a gem
- Provide a CLI on gem installation.
- CLI must provide data from an external source, whether scraped or via a public API.
- Data provided must go at least a level deep, generally by showing the user a list of available data and then being able to drill into a specific item.
- Movies Opening Soon - Enter your zip code and receive a list of movies and their details.
- Libraries Near You - Enter your zip code and receive a list of libraries and their details.
- Programming meetups near you, list details.
- News Reader - List articles, read article.
now-playing is an example of a gem that would meet these requirements. worlds best restaurants was built by a Learn student and meets these requirements and is well coded.
There is also a video walkthrough of building a CLI Gem called Daily Deal if you're having a hard time getting started.
- Create a new repository on GitHub for your gem, ie:
name-cli-gem
. - Build your gem. Make sure to commit early and commit often.
- While you're working on it, record a 30 min coding session with your favorite screen capture tool. During the session, either think out loud or not. It's up to you. You don't need to submit the video, but we may ask for it at a later time.
- Prepare a video demo (narration helps!) describing how a user would interact with your working gem.
- Write a blog post about the project and process.
- On Learn, submit links to the Github repository for your gem, your video demo, and your blog post each to the corresponding textbox in the right rail, and hit "I'm done" to wrap it up.
Watch for an email from Learn with instructions to schedule a pairing process. If you don't receive the email within a day or so after submission, get in touch!
- Explain your code from execution point to exit point. We're making sure you wrote it and understand how it works, nothing else. 5-10 minutes
- Write tests together. You'll be responsible for making tests pass, not writing test code. However, you'll be expected to provide expected return data of methods. You'll need to know how your code should work, not rspec or testing. 20-30 minutes
- Refactor code. 20-30 minutes
- Extend the application with a new feature, more data, a different domain etc. 20-30 minutes
- Submit an improved version.
- Write a README.md.
- Use the best vocabulary you can. Technical terms allow for you to be more precise which makes conversations about code much easier.
- If you make a mistake, correct yourself! We all make mistakes, I promise.
- Trust yourself
- Trust us
- Think on your feet. Feel free to look things up while you're pairing with us. You'll be asked to expand on concepts you implemented and you will be pushed to the edge of your knowledge.
- Explain the details. We're curious!
- You're going to learn a ton. We will give pointers and show you ways to improve your code. This isn't telling you that your code is wrong, it's simply us teaching. Whatever you don't quite understand will be explained
- You won't be told you're ever wrong
- You won't be yelled at, belittled, or scolded
- You won't be put on the spot without support
- There's nothing you can do to instantly fail or blow it.