bcarroll22

got it, thanks.

so based on this context and some other comments, it seems like the potential crime isn't so much that they use these sources to algorithmically suggest a price or contrived vacancy, it's that their agreement enforces that any of their subscribers has to use their suggestions on price and availability, thus making it likely price fixing. correct?

genuine question here, apologies if i missed it in the article, but what's RealPage's crime in this? how is using an algorithm to set prices on apartments more criminal than using an algorithm for anything else we use algorithms for?

i'm not saying it's not criminal, i just don't think i understand what american laws they're breaking by doing this.

Hiring for a particular tool-chain or framework

Anecdata, but it wasn't helpful for my company to remove this boundary. I bought into the idea based on some other articles and threads posted here recently, but when we actually widened searches and removed the requirements from the postings, it didn't really move the needle.

I'm sure there's a group out there who isn't married to one stack, or is interested in learning a new one, but it was tough for me to feel like it was worth the added complexity of effectively screening and interviewing to accommodate it.

Is the suggested approach to focus sourcing on certain stacks but be open to interviewing promising applicants who don't use them? I suppose I could see that if your technical interviews can accommodate it without much rework.

I can dig this.

That said, if a mechanic says “if you don’t get this repair your tailpipe is gonna fall off” and you say “nah let’s risk it”, you’re not gonna go back to him when it falls off and say “wow I can’t believe you let me drive my car until the tailpipe fell off, you should’ve done better!”

If, however, a dev team says “hey guys, if we don’t fix this tech debt we’re gonna run into some perf issues and the site may crash” it’s a lot more likely they’ll come back and still find a way to blame the dev team when the product inevitably does crash or really struggle to deliver results.

Again, like my other comments say, this could be completely anecdotal on my part and totally greener grass thinking on my part, but it definitely does feel like this is the way the product teams I’ve worked with behave toward development teams.

I gotcha. I guess the confusion from my end is that I’ve yet to have a software development job where I wasn’t developing a product. No one in the orgs I’ve been a part of refer to the “product” team as the “product development” team. It’s just the product team, and the development team.

If that’s not been your experience then maybe you fall outside the target demographic of this article? I say that because it was super clear to me exactly what the author was talking about (in fact it even resonated with other members of my scrum team).

Alternatively, I suppose my experience could be anecdotal and not what most development teams encounter daily and struggle with.

"us" = development team "them" = stakeholders/product owner/project managers/managers/ux designers/etc.

this isn't the point of the article which is, in my opinion, a very good narrative of what its like to try to practice agile development in an organization with not very agile tendencies.

it was just a way to demonstrate that this kind of request at least _can_ be made to a restaurant staff and you don't think "wow they're totally gonna blow it" but you'd rarely, if ever, see a product team make a similar request to a development team.

great job to the author of this post for capturing this.

I echo this as well. Would be very nice to have Crashlytics for web.

Research the concept of "Death Prices".

Google doesn't come up with anything on this one, is there a different term for the same thing?

Channing, thanks for sharing this. I hope it’s an inspiration for some other entrepreneurs out there!

I see what you’re saying and I agree. But to continue down this path one last time, I still think what you’re saying meshes with my original point. If you’re big enough for Facebook to care to leverage this against you, you’ll have a legal team who can negotiate one of these nice reciprocal agreements. Until you reach that point, Zuck or his theoretical sinister successor probably won’t know, or care, that your company exists. Can we at least agree on that?

Okay sure, they could “afford” it, but that doesn’t mean they would want to. And if there’s even a feeling on the legal team that some day it might be an issue, why not just use what you’d someday have to switch to and start investing in that ecosystem instead? That would be making a business decision that you know could be flushing years worth of work and investment down the toilet just because.

Besides, isn’t the wording in this clause immediate loss of use? You’d either have to take the time to convert your app to something else before you sue them, which would still take a long time and give them the time to build/perfect your new lethal competitor, or sue them and shut your business down until you converted it to something, which is equally lethal.

I’d agree if Airbnb were the only large company using React, but they’re not. They were just the company I chose to mention. There’s also Twitter who just went all in building Twitter lite, Wix who is huge in the native navigation world, and plenty more. So would you guess that Facebook is negotiating a separate license with all of them? And besides, wouldn’t that nullify concerns even more because that means they’re willing to negotiate a more lenient license with any company that makes enough money to make them worth knocking off?

I’m not trying to be sarcastic, I just really don’t understand how these fears are justified. Besides, if Facebook decides they want to crush you and use React as a shield, you’ll probably have bigger problems in that moment than your choice of front end libraries. A bigger problem, I would think, is that you have something worth Facebook thinks is worth stealing. Facebook doesn’t need a React patent clause to smother a company.

I don’t know if this really answers my question. You have to assume Airbnb, for example, has a legal presence that is very involved in tech decisions and how they might hurt the business. What I imagine was a very thorough scrutinization process came back with a green light to use it. Most of the startups worried about this don’t have the luxury of anything near that level of legal scrutiny, but can’t a startup that can’t afford it extract some value from a company like Airbnb using it without worries?

I think this is exactly what I am saying. There are companies using React that are much larger than anyone who is worried about this, and they don’t seem phased by it. That has to mean something.

Serious question. React has been around for a while. Companies like Airbnb and Wix, for example, have been using React for a while. If Facebook were going to leverage this the way people are scared of, wouldn’t there be some example of them using it the way people are scared of? You know, on a company doing something it’s proven that they could make major money on? It’s not like this is a new provision, it’s been around for a while, and they’ve not used it to backhand a single company that I’ve come across (please, correct me if I’m wrong on this). So can’t this be boiled down to a conspiracy theory? There are massively successful, profitable companies who they haven’t tried to leverage these provisions on, so I’m honestly trying to figure out, what’s the basis for this fear?

I guess probably just fundamentally different experiences. We couldn’t have afforded to put any more time into optimizing for mobile, but most users I talked to didn’t even care to look at the mobile site before insisting they couldn’t use it unless it was an app. No need for push notifications, camera, anything like that—heck we even put in the iOS add to home screen stuff to try to get them to see it as more “app” like—but still, they just insisted an app straight from the App Store was necessary.

Here's what I've realized lately. Our product is for teachers (K-6 mostly) who tend to not be very techy. They use phones, tablets, etc. to the extent that they need to. We spent TONS of time optimizing our website for mobile. At one point it was a PWA that was very optimized and had like a 95 lighthouse score (not anymore because of finicky SW behavior). They didn't care one bit. Like, not even one little bit. To them, it was annoying that it wasn't "an app".

I don't think this battle is one of "build good enough mobile web experiences", it's more "convince non-techy users that a good mobile web experience is good enough for you in x% of cases." For us who read HN, we're jaded on apps, installs, 100mb of storage wasted. For the less techy world, they don't feel the pain we do, and that will continue to be a problem.

JavaScript used to do this, and we fixed it by encapsulating everything in modules and using tools like webpack to stitch everything together.

We've done the same with CSS, and CSS modules work extremely well. For us, they've even eased the need for SCSS.

Hey everybody! One of the creators here.

This idea came from a pain point I felt when I was trying to become better at selling my main project. I was trying to learn to become a better sales person, so I watched Jordan Belfort’s straight line persuasion which requires building a really solid sales script and sticking closely to it.

I followed his guidelines and wrote a script, but I realized that it was annoying to jump around to different sections of the script and follow along on paper. I figured it would probably be better if I could build a web app that would link me to the correct section of the script based on customer responses, so I built something that did it! Once I used this instead of the paper script, it was much easier to stay on track and not get lost in the pages of the script anymore.

Excited to get feedback on whether or not this is useful for any other sales teams!

We keep track of ticketing, so whenever a customer has a support question, it opens a new Slack channel as a "ticket", and invites the people you want added to support conversations.

We're planning on extracting it in the near future so others can use it. Will definitely be posting it as a ShowHN when it's ready!

We just finished building our own customer support tool to save some money (we're a bootstrapped startup). We wanted live chat for customers that went straight to our Slack, since we already use it for so much. We couldn't find anything else that worked the way we wanted, so we built it.

Founder here. To start the conversation, I figured I'd share that this was built with React and Laravel. We use React, React Router and Redux for the frontend. We use Laravel mostly as a Rest API, and to hydrate our initial Redux state.

Overall, things worked well building with this stack, but sooner than later we'll probably split the frontend into its own codebase and use Node.js to serve it so that we can utilize SSR to gain some extra speed. But overall, the application performs pretty well, we think.

If you'd like to read a little more about what Prolio does for classrooms, feel free to check out the write-up at Medium:

https://medium.com/@brandoncarroll/hello-prolio-298170b3067c...