Skip to content

Instantly share code, notes, and snippets.

View practicingruby's full-sized avatar

Gregory Brown practicingruby

View GitHub Profile
# coding: UTF-8
require_relative "lib/prawn"
address = %{
Four score and seven years ago our fathers brought forth on this continent a
new nation, conceived in liberty, and dedicated to the proposition that all
men are created equal. Now we are engaged in a great civil war, testing
whether that nation, or any nation so conceived and so dedicated, can long
endure. We are met on a great battlefield of that war. We have come to
# this code fills out a login form,
# finds and clicks a "clock in" button on the user's dashboard
# and then inspects an HTML table representing a week calendar
# view and ensures the right time shows up in the right place
scenario "clocking in" do
timestamp = Time.now.noon
day = timestamp.to_date.cwday
simulator.log_in(employee)

In order to become a permanent member of the RMU community and move on to take additional courses, each student must pass an entrance exam and then go on to successfully complete their core skills course. The entrance exam is mainly used for ensuring that the people joining the program are diligent workers who have sufficient background knowledge to do well in our core skills course. The core skills course itself though, is something I think is something genuinely unique that you can’t find anywhere outside of RMU.

Each core course starts with roughly 15 students submitting a proposal for a personal project to work on during their session. This can be anything Ruby related, but typically involves the student building an open source application or library that scratches a particular itch of theirs. This is the first learning opportunity of the course, as it filters out those who can’t think of anything to work on. There isn’t a list of suggested projects to pick from, students need to come up with an idea the

# 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|
class Foo
class << self
def bar
baz
end
private
def baz
puts "Hello there!"
# 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

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

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

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.