Skip to content

Instantly share code, notes, and snippets.

View practicingruby's full-sized avatar

Gregory Brown practicingruby

View GitHub Profile
print "How many sides? "
sides = gets.to_i
puts "You rolled a #{rand(1..sides)}"

They came in search of gold, but what they needed most was water. Without it, they would be driven out of their camp and into the wilderness, where they would need to start the search for paydirt all over again.

The land the miners had settled on was rich, and the Triskett Gang knew it. But unlike the wide-eyed rubes that spent their days poking around in the dirt, they knew the lay of the land, and its great weakness.

A single stream flowing through the rugged mountainside was the only source of water for miles around. Up in the hills, the bandits had built a crude but functional system of dams that let them control the water flowing down into the Kneeland Ravine where the miners had set up camp.

And with this simple act of engineering, Boss Triskett became the baron of Kneeland Ravine. Week after week a lockbox was carted through town, and week after week it either came back filled with cash, or the water got shut off. As miserable as it was, folks learned pretty quickly just what to expect if they didn

This plan is meant to keep you busy for at least four weeks, but feel free to go at your own pace. You definitely don't need to complete the whole plan in that timeframe, and it'd be better to take it slow than to rush through it all and only gain a surface level of understanding.

Once you've completed your first week of practice, send me an email and share your progress with me. We will revisit the plan from there and tweak as needed based on what you found interesting, challenging, etc. We'll then repeat that process on week 2 and week 4 of your studies.

Enjoy!

How to practice

You will be working through reading materials, exercises, and a realistic project.

The kinds of fears you have about failure, mediocrity, getting stuck, etc. I think are normal even for people who have excellent mental health -- I experience them daily. We work in a field in which continuous learning and progress are expected, and real learning and growth are necessarily uncomfortable. You have to spend a lot of time scratching your head and feeling like you're confused and not good at something before you can get good at it, and that can be very discouraging.

So for me (and I'm sure it'll be the case for you too), the challenge is to find a way to work with what you have rather than somehow expecting your mindset to change. It'll be great if and when you do feel like you've found some peace of mind and stability, but until that day comes, you can and should do what you can with what you have. Structure your work and life around what you can do, not what you can't do. It seems like you've already taken some steps to do that, and that's something to see as a strength rather than a weakness.

I think you might benefit from a detailed study plan when you're a little further along with your studies. For now, I'd recommend following your interests, and taking a project-based approach towards learning.

Start with an idea of something you might want to build, and then make a list of all the stuff you'd need to learn to build it. Then, strip down the idea to make it a little more simple, and redo the list. Keep doing that until you have a list that's small enough to manage

Fair warning: full-scale applications tend to look like "first invent the whole world, then build your app", so you may need to come up with really simple ideas to start on. That's OK! You may also not know what you need to know until you try building things, that's OK too.

Once you have a few ideas, start reading and watching videos related to the technical tools and concepts you need. But only go just as deep into those resources as you need in order to build one small piece of a real project... you can always come back later i

Keep reading and watching videos, but cut that time down in half and use the rest of the time for exploring codebases and writing code of your own. If you do a code reading exercise, make sure you have the code open in your editor, and that you're able to interact with it via a REPL, its tests, etc.

Then from there, I'd recommend starting with very small, tiny projects. Ideally your first one should be something so simple you can do it in an hour or two.

Gradually work your way up from those tiny projects to slightly bigger ones. So start with one that takes an hour or two, then move up to one that might take 5-10 hours, then one that might take 20 hours, then 40 hours, etc. It's OK to stop at the size where you're feeling you're getting the most learning benefit.

Each time you try a new project, make it realistic if you can, but don't worry too much if you'll actually use it. The value is in having a rich context to try out ideas, not in the actual utility of whatever you build.

For each project you wor

# Sources
* Cunningham / Beck on CRC
* GOOS
* Wirfs-Brock + Wilkerson "OO Design, a responsibility driven approach"
* Object-oriented brewery
----
> What we often do is "procedural programming with objects" or
class Foo
class << self
def bar
baz
end
private
def baz
puts "Hello there!"
# coding: binary
class BMP
class Reader
PIXEL_ARRAY_OFFSET = 54
BITS_PER_PIXEL = 24
DIB_HEADER_SIZE = 40
def initialize(bmp_filename)
File.open(bmp_filename, "rb") do |file|
# coding: binary
class BMP
class Reader
PIXEL_ARRAY_OFFSET = 54
BITS_PER_PIXEL = 24
DIB_HEADER_SIZE = 40
def initialize(bmp_filename)
File.open(bmp_filename, "rb") do |file|