ilkhan4

Heh, I'm guessing this comes from one of the Reddit threads below where it mentions "Size 14 feet"

Not all that crazy but I worked for a high-end golf community for a short time. We had free lunch in the building catered in by the (really nice) restaurants, but could also eat at those restaurants (dine in or takeout) for half price. I had many a $7 lunch and a few $20 filet dinners while I was there. We could also get free tee times on the golf courses as long as they didn't conflict with the members, but I'm not a golfer so never took them up on that.

Didn't this already happen? Like, a long time ago?

"Software creators" have been making software sans large teams and capital since the earliest computers, up through BBSes, shareware, the early internet, and app stores. The latter two lowered the cost of distribution to almost nothing quite a while ago. I'd even say the concept pre-dates today's "content" creators by a couple decades at least. I mean, there's even a character archetype in media of the lone genius creating groundbreaking software all by themselves free of (or in spite of) corporate control.

I guess maybe it's trying to say that the new thing will be that you don't need the technical expertise anymore? I feel like that already happened about a decade ago too with everyone learning how to "make apps". Or maybe that you'll "follow" your favorite software creators? I guess I could see that, but that sort of already happened too (John Carmack, for example). .

What's the insight I'm missing here?

Sure, not having to spin up a separate server is nice, but this aspect is underappreciated, imo. We eliminated a whole class of errors and edge cases at my day job just by switching the event enqueue to the same DB transaction as the things that triggered them. It does create a bottleneck at the DB, but as others have commented, you probably aren't going to need the scalability as much as you think you do.

As far as I know, there is no "union" for military officers and pay only went up 5.2% this year (about equal with inflation). Are you thinking of police officers?

Twilio has their SuperSIM (https://www.twilio.com/docs/iot/supersim) for these use cases but the pricing might be too high for what you're looking for. There's also Hologram (https://www.hologram.io/). I'd try looking for IoT data providers (rather than cellular ones).

I've also personally worked with these guys before and they are legit: https://www.zipitwireless.com/

IMO, it didn't really make a smooth transition to the web. Webforms was the attempt but it was a leaky abstraction (iirc, it kept state for UI components but not variables so things got... weird) and kind of worked against the paradigms at the time (everything was a POST).

Yeah, maybe a little more tactfully, but I would ask that.

As a guess based on what you've said, are there too many seniors? Maybe folks are spending more time (over)designing or making sure they don't look bad in front of the others?

Sure, I get that they have to justify themselves, but when the answer to that question is (almost) always "Because Nubank!" for the past 10 years it doesn't feel like much of a justification.

I wish people would stop bringing up Nubank when it comes to Clojure/FP as if it's some sort of mic drop that proves that it's the Right Way to develop financial software. When you have to keep bringing up the same example, it's not a very good argument.

I have a pet theory that it's because it's too easy to write code in. I think there needs to be just enough pain with a language or library that it becomes worthwhile to allow someone else to write X and just deal with it being imperfect if it still solves your problem.

AWS' own Amplify seems like it's what you want: https://aws.amazon.com/amplify/

Wow, I've finally found my tribe. All of this rings true for me. I kept hearing about how Clojure is this life-altering programming language that would make me forget all others and want to write parentheses for the rest of my life. But after working at a startup using Clojure for a couple of years, I've come to a couple conclusions about it: a) it is indeed a really nice, consistent language that's really nice to read and write, and b) the choice of programming language is a rounding error when determining whether a project or company is successful.

Ugh, I can't wait to find out if "USB4" cables and devices are 1.0 or 2.0.

Why not just call it USB5?

I mean, that's pretty much what ORMs do, right? Hasura et al too.

Stop using GitHub?

Yeah, I'm with you. I was effectively a solo dev for a few years and definitely had a "grass is greener" mentality so I joined a team. I quickly realized the grass was not greener.

I think my ideal is working on a project solo, but still having other folks (doing other projects) to bounce ideas off of.

Well, I'm still feeling out the platform, but I'm tossing around some ideas for components like these:

- A generic GraphQL query component. It would be nice to be able to pop open an embedded GraphiQL UI to set up the query and maybe set variables.

- A generic "state" component that could have a list of state vars you want to track. The UI I'm envisioning would let you add a list of state vars (essentially wrapping `useState`) and their default values.

- An authorization component that could show/hide children based on a role or auth status. The UI would need to be able to select the role or user property to key off of.

Maybe these would be built into the platform itself in the future, but they could probably be done as components in the meantime.

Are there any plans to add more extensibility to the code components, e.g. showing a custom UI for setting properties? I think the whole concept of being able to bring in external React components is a big differentiator for Plasmic and something like that would enable a bunch of new use-cases around making it easier for non-devs to build stuff on it.

I was working on this at my previous employer. We started with Elasticsearch and were planning to move to Timescale (https://www.timescale.com). Another project used Cassandra which had some issues but they were happy with overall.

You might also want to look into Thingsboard (https://thingsboard.io) which supports both Timescale/Postgres and Cassandra.

Kind of takes the edge off of it when you use the wrong word. You're looking for "abject."

Mapping/driving directions

I'm with you on this one. I was thinking it would be cool to "bake in" the DB layer of an application and have it run in-process. Then you'd just provide it with block storage and it would handle the rest without having to have a separate server. You could even do compile-time migration and index generation based on your queries. With a distributed actor framework like Akka.NET or Orleans, it could probably be made to scale too.

The only downside is that the only interface to your data is through the application, but there's certainly a use-case for something like that.

If the number of possible permissions is small enough, sure. Otherwise it ends up being a huge token that gets sent over the wire for each request.

One "hybrid" approach that seems to work well is pulling permissions from the DB but then caching them in-memory on the server. That way you can still keep them granular but you'll only hit the DB on the first request or if the cache expires. It also lets you immediately kill access (rather than waiting for the JWT to expire) if you can send a message to your servers to clear the cache for that user.

Yeah, I would think most companies would kill for that kind of brand recognition. So will we see "Don't call it Coke" or "Don't call it Bandaid" campaigns next?

We are. My wife has to put in a ton of time to make it all work, but my kids are excelling and enthusiastic about learning now because of it. We ended up doing it because it turned out that teachers were either keeping kids busy with make-work, mollifying bullies until they could pass them on to someone else, or cramming for standardized tests. We just decided that we'd had enough one day, and thankfully right before our youngest even started.

Funny thing is, they tested as "gifted" (95-99th percentile in the county) but it turned out they were ~2 years behind where they should have been. They've been catching up, but the "D's get degrees" mentality is alive and well in K-12 too.

This what I do: all writes go to Dynamo and it replicates to ES for querying/filtering. It's the best of both worlds for operational stuff, IMHO, although still not perfect for ad-hoc querying like SQL.

Not an answer to your question (I primarily write C#), but sounds like you dodged a bullet, really. That guy would have been horrible to work for/with based on what you described.

Isn't the problem this is trying to solve what GraphQL already solves? Instead of two different queries (one for the master record, one for the details):

  {
    post(id: $id) {
      id
      title
      text
    }
  }


  {
    commentsOfPost: comments(postId: $postId) {
      comment
      owner {
        name
      }
    }
  }

Shouldn't it just be

  {
    post(id: $id) {
      id
      title
      text,
      comments {
          comment
          owner {
              name
          }
      }
    }
  }

?

I tried using this for a project a few months ago. On paper it sounds great, but I kept running into issues with their goofy schema system. It brought back bad memories of working with AD and LDAP. I ended up rolling my own (simpler) version with DynamoDB.

That said, it looks like they've somewhat addressed that problem with their automatic schema upgrades. If they were able to add Lambda integration I'd give it another look.