self.deprecate

Learning that Ruby is a self.aware programming language has been one of the highlights of my experience with the Flatiron curriculum. Not only does this concept provide for a nice, deep dive into some metaphysical pontification, but I also have always had a flair for the dramatic. I, too, am fairly self.aware. While my built-in methods are certainly less tidy and direct (and I would most likely be considered less user-friendly), Ruby and I share the habit of occasionally needing to stop and say, “Wait. Is it me?”

As I have mentioned in two previous posts (and clearly made no attempt to correct), I could benefit from planning my applications out in a more careful, specific manner. I do love to plan, so this is somewhat out of character for me. But I also rarely make it to the end of a plan before needing to set said plan into motion. Thus goes my coding. At least until I learn some self.control.

In an effort to continue to develop practical applications (a not terribly subtle attempt to establish my self.worth), I decided to create a grading application that I could use in conjunction with my college classes. As I continue this journey toward self.awareness as a programmer, I am finding that by creating applications that I would actually want to use, I’m actually creating more work for myself. I sort of become my own demanding client, knowing exactly what I need from the application and imagining precisely how I want it to work. Student-developer-me knows the project parameters are fairly basic and straightforward; client-teacher-me wants a cute, functioning application that I can casually pass around the chat at a Zoom faculty meeting. “Oh, just something I’ve been working on. You’re welcome to try it out…”

Because the focus of this project is on the Sinatra-ActiveRecord back end, I’ll spare the details of wrestling with React over an initially scattered and deeply flawed data distribution. As it is my nature to make things hard on myself, I decided it would be a fun challenge that if once my back end was set up the way I thought it should be, I wouldn’t change it, or at least I would really try not to. Why? I’m not sure. I thought it would be good for me. (It was not.)

I also decided to fulfill the requirement of two one-to-many relationships by creating a many-to-many relationship: each submissions is for one assignment, by one student. Each student has the potential of many submissions. Each assignments can also receive many submissions. Students have many assignments through submissions. A pretty ideal many-to-many setup.

This is the bit of Ruby code that really got me out of a chokehold with React:

Specifically, line 3. More specifically, the request in parenthesis that each submission be returned to my front end with the assignment information and student information in tow.

In all fairness, I didn’t realize this was an option when I started to create my back end. At some point, I looked up from underneath React’s agile framework, reconsidered my back end, and knew there had to be a better way. And, of course, there was. I imagine this is a pretty standard route definition pattern; make sure the join table — which holds the single instances which join together a pair of one-to-many relationships — returns all the details of each instance of its many’s.

This saved me about four separate fetch requests. And it’s just so accommodating. It’s almost…self.less.

While I am a fairly progressively-thinking educator, I may never be able to divorce my own concept of my success with my students from their grades. So, in accordance, I opted to display the class’s average grade with the roster.

While this could have been done easily with my now more compliant React front end, I wanted to give Ruby a shot at it. She made it a challenge, wanting things converted to floats and getting rid of a NaN or two. But in the end, she and I saw eye to eye over this pair of methods.

Not to create a self.fulfilling prophecy, but I wish I cold say I would plan better for my next project. I learned so much from my mistakes on this one, it was almost worth the slog through my messy swamp of fetches and prop drilling.

Not to sound too self.centered, but coding continues to teach me a lot about myself and my approach to problem solving. Aside from the need to self.regulate and plan my applications better from the onset, I have to find a balance between self.discipline and self.care. Or else I may self.destruct.

Related posts:

In some of the courses I’m teaching, as an adjunct, we spend the last week of class focused on careers. We look at jobs in the industries we’ve been studying, select a job online, and go through a…

Adoption is more than programming. Elixir is an exciting new language, but to successfully get your application from start to finish, you're going to need to know more than just the language. The case studies and strategies in this book will get you there. Learn the best practices for the whole life of your application, from des

You think agile techniques might be for you, but your projects and organization are unique. An "out-of-the-box" agile approach won't work. Instead, unite agile and lean principles for your project. See how to design a custom approach, reap the benefits of collaboration, and deliver value. For project managers who want to use agi