Can’t we just cut Qualcomm out of the supply chain and keep going as normal without too much disruption? Doesn’t even feel like a hard fork is needed. Just don’t buy Qualcomm’s crap.

Otherwise this is what we’ll be stuck with everywhere all the time. There won’t be a choice anymore if you don’t exercise that right. We’re already far down this slippery slope.

The days are numbered for boomer nostalgia based brands. One of these days those restaurants are going to be something else. PE deals years ago started the work of decoupling a stale old brand from the valuable real estate.

Who cares about selling millions of dollars less in bad food when you can access billions of dollars more in real estate value.

See also: https://www.nashvillepost.com/business/retail/cracker-barrel...

Comments URL: https://news.ycombinator.com/item?id=43728230

Points: 3

# Comments: 3

I like it that there's no hint, it just rewards exploration and experimentation.

I didn’t understand the “charging” mechanic. A little more explanation or some visual that shows charging would help.

Pretty sweet game! Keep it up!

I assume this is telling us it doesn't actually make an ActiveRecord instance out of each row when you do that. And instantiating big bunches of ActiveRecord model instances just to grab a few fields from a result set with a lot of rows can be sooo slow.

Like a lot of other ppl it seems I left off when they switched to composer. That didn't fit too well into the workflow I had at the time using cheap web hosting services where I didn't get a shell as dev environments.

Also the upgrade treadmill was brutal. A few nice little web apps I made got totally left behind by security updates and such and were also too hard to upgrade to newer versions of Drupal. I remember that also being a major motivator to make the big jump to Python and other things. More code but also easier to manage over long periods of time.

Lots of good lessons in Drupal for other frameworks. I haven't tried it in a while, but it's still in my mind one of the best low-code custom fields, forms, and views systems out there.

I think you could go a little lighter, pretty sure the actual trains have a lighter more saturated blue on them. Something closer to the blue you're using for the Mass Bay Trans Authority would be fine, and there's no overlap in service areas to make that confusing.

Or maybe different marker size/shape for regional vs national trains.

Also saw the South Shore Line is there now. Nice!

Just a little feedback: the color for Amtrak and for Chicago's Metra trains are so similar it's hard to see at a glance where the Amtrak runs are amongst the many Metras that are out at a given time. Would be awesome to differentiate those marker colors a bit more.

Very cool! Didn't know this was even technically possible with the available data feeds. Great work!

This usually takes about 5 to 7 years, in my experience. After about that much time working in a focused way on software you're probably pretty "senior" at dev work, without a whole lot more to learn in terms of just getting better at coding.

The author doesn't quite fit that description. This sounds more like what happens at lots of high turnover "fast paced" startups. As people come and go from the group they find themselves in a situation where their 1 or more years of experience is allowing them to significantly outperform those with 0 to 6 months of experience. Maybe high turnover or rapid growth at the employer makes it easy to get promoted to "senior" because there are so many other truly very junior people around.

Not to belittle the author at all. Sounds like a smart guy and I admire his enthusiasm and spirit. Just sounds like crazy-startup-battlefield-promotion "senior" rather than the more rigorous definition of senior some of us might be thinking about.

Even though this really doesn't affect my use case it does feel like kind of a dirty bait and switch. I do hope for a future where there's a version (and Terraform provider module versions) that are actively maintained under a true open source license. I'll favor using those over the official BSL version as much as possible.

I guess it's the CLA that all of the contributors signed that allows this to happen? I wonder if there's a way for open source licenses to address this, and disallow the use of CLAs, or require some CLA clause that doesn't allow sudden switches to non-permissive licenses?

I'm sure there are rare cases where these techniques are useful. Like creating developer tools or making your own object persistence layer or winning a code golf contest. But if you're an app developer for goodness sake just write a few extra lines of code. Do whatever it is you're doing the verbose and clear way, not the slightly shorter and super obtuse way.

Stuffing method definitions into classes at runtime, monkey patching, dynamically generating method calls with .send. These will all be very puzzling for any future developer that works on your code, senior or junior. And come with bunches of technical pitfalls. Writing clear and maintainable code is a higher calling for us than reducing LOC and showcasing neat tricks. Even if you call yourself a Rubyist. Speaking from experience.