I worked on an automated reply system like this previously and we had intentional delays with randomness as well as variance in our responses to make it “feel more human”.

ActiveRecord has changed a lot over the years, but as an example in the original ActiveRecord you used dynamic finders. None of the finder methods existed initially, but if you passed a message to an active record object for a non existent method rather than fail it would determine if that should be a method and then it would build and persist a method to the process for future calls.

It allows for some really interesting and powerful applications in horizontally scaling as well.

Behind the scenes everything is a message passed using __send__ and you can do this directly as well, but you generally don’t.

So when you write

5.times { puts "Hello" }

It’s sort of expected by the average programmer that you are telling 5 to call the times method and expect it to exist and do what it’s told.

In reality you have indirectly sent a message that looks like

5.__send__(:times) { puts "Hello" }

What we are really doing is sending a message to 5 (the receiver) and giving it the opportunity to decide how to respond. This is where method_missing comes in to allow responding in a custom fashion regardless if a method was explicitly defined.

So you’re not telling 5 to call the method times, rather you are asking, “Hey 5, do you know how to handle the message times?”

These are fundamentally different things. This is actually super important and honestly hard to really grok _especially_ in ruby because of the syntactic sugar. I came from a C/C++ background originally, then Java and then moved to Ruby. After a few years I thought I understood this difference, but honestly it wasn’t until I spent a couple years using Objective-C where message passing is happening much more explicitly that I was able to truly understand the difference in a way that it became intuitive.

That would be simple enough for most people (1 job, 1 home, maybe some kids) and it doesn’t require the government to know anything additional.

In that most common scenario no tax accounting service should be needed. Honestly a 1040 isn’t that complicated in that scenario either, but is still too difficult for a good number of people and it’s just unnecessary.

Wisconsin is no different in that. Most of Jackson, Levis, BRF, and that whole area is gravel except for major highways and in town. Pretty poorly maintained gravel at that.

The roads do seem disorganized and wandering, but much of that is because the roads are built wherever they won’t flood since we’re nothing but marshes, wetland, lakes, rivers and ponds

These are data and compute heavy workloads that take anywhere from minutes to hours for a request to be completed, but the UI takes this into account.

Users submit a request and then continue onto whatever is the next thing they intend to do and then they can subscribe to various async notification channels.

It’s not the right choice for everything, but it’s the right choice for something’s.

Bottom line is it’s about the talent and the discipline. At the end of the day it’s not bad languages that are the problem it’s bad engineers.

I been in this field for almost 30 years and have worked with whatever tech the job required. Still I learned more at a Rails shop with more than 200 engineers all working in the same monolith shipping to production multiple times every day.

Despite her positive attitude, she is working because social security isn't enough and grocery workers also get an employee discount.

Engineering with constraints builds discipline. Maybe we are lacking as engineers in software because the constraint bar just continues to raise.