azirbel

This looks great. I found the docs helpful for getting a clear idea of what it does: https://docs.gradient.ai/docs/introduction

Playbook (https://www.playbook.com) | Software Engineer | San Francisco or Remote (US timezones +/- 1 hour)

The tools for keeping track of creative work haven't gotten an update since Dropbox launched. You wouldn't expect the creative process to involve hours of digging through folders and files, but it does, and we're here to change that.

Playbook is a visual cloud storage platform for creatives. Whether you're a designer, marketer, photographer, or artist, your tools should help you stay in flow. Your current and past work should be right at your fingertips, and it should be a snap to bring in collaborators or share your projects with the world.

We're a small team of ~10, growing quickly and looking for help as we scale. We're hiring generalist software engineers (2+ years exp) and a senior infrastructure-focused software engineer. Our stack is Rails/React/GraphQL/Postgres. More here:

https://www.playbook.com/p/play/software-engineer/

https://www.playbook.com/p/play/infrastructure-engineer/

Email me directly to apply or ask any questions! alex@playbook.com

Playbook (https://www.playbook.com) | Software Engineer | San Francisco or Remote (US timezones +/- 1 hour)

The tools for keeping track of creative work haven't gotten an update since Dropbox launched. You wouldn't expect the creative process to involve hours of digging through folders and files, but it does, and we're here to change that.

Playbook is a visual cloud storage platform for creatives. Whether you're a designer, marketer, photographer, or artist, your tools should help you stay in flow. Your current and past work should be right at your fingertips, and it should be a snap to bring in collaborators or share your projects with the world.

We're a small team of ~10, growing quickly and looking for help as we scale. We're hiring generalist software engineers (2+ years exp) and a senior infrastructure-focused software engineer. Our stack is Rails/React/GraphQL/Postgres. More here:

https://www.playbook.com/p/play/software-engineer/

https://www.playbook.com/p/play/infrastructure-engineer/

Email me directly to apply or ask any questions! alex@playbook.com

What I found most interesting:

His latest Twitch deal includes a performance quota; he streams 200 hours a month.

50 hours a week of on-stream time! And any other business/branding/merchandizing must happen on top of those 50 hours where he already has to be 100% on. It does sound exhausting.

Playbook (https://playbook.com) | Software and Infrastructure Engineer | San Francisco or Remote (US timezones +/- 1 hour) The tools for keeping track of creative work haven't gotten an update since Dropbox launched. You wouldn't expect the creative process to involve hours of digging through folders and files, but it does, and we're here to change that.

Playbook is a visual cloud storage platform for creatives. Whether you're a designer, marketer, photographer, or artist, your tools should help you stay in flow. Your current and past work should be right at your fingertips, and it should be a snap to bring in collaborators or share your projects with the world.

We're a small team of 9, growing quickly and looking for help as we scale. We're hiring generalist software engineers (2+ years exp) and a senior infrastructure-focused software engineer. Our stack is Rails/React/GraphQL/Postgres. More here:

https://www.playbook.com/p/play/software-engineer/

https://www.playbook.com/p/play/infrastructure-engineer/

Email me directly to apply or ask any questions! alex@playbook.com

Playbook (https://playbook.com) | Software and Infrastructure Engineer | San Francisco or Remote (US timezones +/- 1 hour)

The tools for keeping track of creative work haven't gotten an update since Dropbox launched. You wouldn't expect the creative process to involve hours of digging through folders and files, but it does, and we're here to change that.

Playbook is a visual cloud storage platform for creatives. Whether you're a designer, marketer, photographer, or artist, your tools should help you stay in flow. Your current and past work should be right at your fingertips, and it should be a snap to bring in collaborators or share your projects with the world.

We're a small team of 8, growing quickly and looking for help as we scale. We're hiring generalist software engineers (2+ years exp) and a senior infrastructure-focused software engineer. Our stack is Rails/React/GraphQL/Postgres. More here:

https://www.playbook.com/p/play/software-engineer/

https://www.playbook.com/p/play/infrastructure-engineer/

Email me directly to apply or ask any questions! alex@playbook.com

What I got from the article was that system as a whole is consistently throwing roadblocks in the way of experimental/small-time science. The author focuses on YouTube, but also cites a government investigation as well as deplatforming by PayPal, Square, LinkedIn, Amazon, Facebook, and Patreon. These are private companies, with their own policies, but private companies are part of the system too. So I don't think the concerns are conflated.

Regarding YouTube, I think the author would agree with you:

The problem is big tech companies making billions of dollars aren’t capable of doing basic analysis of scientific work, or hiring a team that can, which is why the best they’re capable of on the pandemic front, for example, is attaching a link to the CDC website on every post that mentions “Covid” or “vaccine.”

I don't think we need to assign blame to YouTube here, but it's still the reality, and we should consider what it means for access to science.

Maybe we (as a society) should in fact keep experimental science off YouTube. (I don't agree, but I can see an argument.) Even in that case, the decisions made here are disproportionate. The author starts the article by describing how he's banned from even logging in, not just uploading; he ends by saying how he has to worry about being locked out of his email. I agree with the author that we're in dangerous territory by giving companies unilateral control over this process, even if we do it for good reasons.

Playbook | Backend Engineer | Remote or SF Bay Area | https://www.playbook.com

Playbook is a media management tool that acts as a beautiful, organized home base for creative work.

We're looking for a senior backend engineer (4+ years experience, Ruby on Rails is a plus) to join our Founding Team. You'll be working on problems like visual search, image similarity/tagging, and large-scale data pipelines. More info: https://www.playbook.com/p/play/founding-engineer.

About us: we're a small team (6 of us total; 4 engineers). We care about creativity, freedom to shape your work, and product-building over cult-building. We're a seed-stage company backed by Founder’s Fund, Abstract, Inovia, and others.

Please email hello@playbook.com to apply or learn more!

I really like hooks. I previously spent a lot of time in HOCs, and I find hooks much simpler. But I also have problems with #5 (control flow):

The main issue I have with hooks is that I can't easily trace why updates are being triggered in my app; this makes it hard to debug performance issues. For example, my app once got really slow, and the profiler told me that a root(ish)-level component was causing a lot of re-renders. Unfortunately, that component used multiple hooks, and the only way I was able to isolate the problem was by binary-searching, deleting hooks until the re-renders stopped.

Anyone have better ways of dealing with this?

I for one preferred the diplomacy.

The 'magic' involved in hooks is a tradeoff; there are real benefits in the way you can consolidate logic, or mix in behaviors. Personally, I strongly prefer hooks to HOCs.

Many technologies have magical behaviors and are still very popular and useful (Rails comes to mind). I'm really liking the pros and cons being brought up in the rest of this thread.

The comments here seem very negative compared to e.g. the Google employee protests over Project Dragonfly. [1]

There are two questions here: whether GitHub should allow ICE to buy its software, and whether employees should influence the direction of their company via protests, petitions, and threats to quit.

GitHub specifics aside, I think employees absolutely should organize and quit over issues they feel strongly about (at least when they have the flexibility to find other jobs). Company policy should be guided by the people who work there, and the a company's leadership structure is set up well to resolve the conflict.

[1] https://news.ycombinator.com/item?id=18542830

I made this for a really minimal version of daily time tracking. The touch bar turned out to be a great place for a stopwatch: tapping is easy, and you can easily check if it's running or not - even in fullscreen mode.

More info in a little blog post: https://www.alexzirbel.com/touch-bar-timer

It's open source, code here: https://github.com/azirbel/touch-bar-timer

Finally, thanks to Pixel Point for their Mute Me project, which was the starting point for this codebase. https://muteme.pixelpoint.io/

Sounds like the homepage copy could use some work. Thanks for the list of questions you had, that's very useful. jsonbin definitely does a good job of explaining it.

Made it myself in Sketch! It took me forever, I'll probably find a real illustrator next time.

That's a good point. Since I don't have that feature, I'll be happy to remove data manually if it ever comes up.

That sounds like a perfect way to use it.

Here's an example of charting data, using npoint.io as the data storage "backend":

https://beta.observablehq.com/@azirbel/npoint-io-charting-de...

If you made a charting app that used an anchor tag to load data like you described, and made the resulting chart embeddable, I'd actually be interested in using it to power charts in blog posts. Cool idea.

Ouch, that would suck. Thanks for the heads-up.

Easy - I'll just inject text-based ads into the saved data!

(Kidding, of course...)

I think it's unlikely that this site can be monetized, so I don't have my hopes up. The clearest direction would be to move up the "backend-as-a-service" spectrum into Headless CMS land (which I have a diagram for here: http://alexzirbel.com/npoint). But I think it would be hard to balance that with the quick setup / unstructured data nature of the project.

One feature (maybe a premium feature) I'd love to add is form-based data editing. Theoretically you could generate the right kind of input fields (text, date, number) from the JSON schema and expose that as alternative editing interface. That would make the tool more like a CMS.

Hi HN! This is a side project I've been working on for a while now.

It's similar to https://jsonbin.io (which was an inspiration!), but focuses on the second step of prototyping with data - once you're editing JSON online, how do you make sure you don't break your app? npoint.io lets you enforce a structure using JSON schema (http://json-schema.org).

More background info: http://alexzirbel.com/npoint

Also, it's open source! https://www.github.com/azirbel/npoint

All feedback is super welcome. Also happy to answer any questions here.

Ah, they're just tools that can be learned. I had to run around the company quite a bit to make sure I got all the information right.

We don't require experience in any of these tools to get a job at Opendoor. Most programming experience can be transferred between different technologies. We do a lot of pair programming to bring people on board, plus feedback in code reviews.

Thanks for the comment -- and it's very accurate in terms of where we'd like to go.

On a tangential note: empowering untrained individuals is important, but we often do the opposite too. Many of our internal tools are designed to make trained professionals/experts as efficient as possible.

For more speculation on Opendoor's business and where we might take it, I think Stratechery has a good writeup. https://stratechery.com/2016/opendoor-a-startup-worth-emulat...

Longer comment on "flipping": https://news.ycombinator.com/item?id=13835150.

Also, I guess I don't understand where they actually make money.

Sorry for not being more clear on that. When we make an offer on a home, we present a headline price ("we think your home is worth $X"), and an upfront fee for our service (6-12% depending on our estimation of the risk, where traditional real estate fees are 6%).

We try to make the fee as transparent to our sellers as possible, so they can make a fully informed decision.

That's fair - the customer experience is a layer on top of the business model. The second part of my comment is more relevant:

We typically don't spend very long renovating our homes. We'd rather reinvent the buying and selling experience itself, and do a larger number of transactions.

I think we're getting a bit hung up on definitions in this thread. We do flip houses, in that we buy them and then resell them right away. But in real estate, the connotation of a "flipper" is someone who's either (1) really good at identifying underpriced houses, or (2) really good at getting return on investment (ROI) through renovations. One of the best ways to identify underpriced houses is to take advantage of people who are down on their luck and need to sell fast, so many people also think of "flippers" very negatively.

Opendoor's model isn't based on finding underpriced houses or renovation ROI. We charge a fee (transparently and upfront) for the service of buying your home and taking on the risk of selling it. Our goal is to make that fee as small as possible, and to provide our services to as many people as possible.

We're not trying to make huge amounts of money on every transaction. We're trying to do a lot of transactions, at a fair price.

Sure! My email is alex@opendoor.com.

I'd say the main direct effects were (1) we were able to iterate very fast on our internal tools, which are used by internal operators to manage each transaction; and (2) our data science setup has allowed us to price homes incredibly accurately. Many companies have estimates of a home's value, but Opendoor puts its money where its mouth is ;)

Happy to answer any more questions about it.

It looks similar, but we're actually very different than flippers.

House flipping is about finding underpriced houses (either by having a sharp eye, or by buying distressed houses), and then optimizing the amount of money invested vs. the return.

Opendoor is much more focused on the customer experience, trying to give fair offers to every home - everyday homes, not distressed ones. We typically don't spend very long renovating our homes. We'd rather reinvent the buying and selling experience itself, and do a larger number of transactions.

More info: https://www.opendoor.com/blog/flipping-the-real-estate-indus...

Very true on the financing, and how it connects to our business. There have been plenty of companies in the past whose business model is to buy distressed houses and flip them; Opendoor is coming from a very different angle. We'd like to buy and sell houses at normal prices, do a lot more volume, and make smaller margins on each transaction than the traditional "flipping" business.

Because of that model, it's very important that we (1) have access to a lot of capital, and (2) renovate and resell the property quickly, so we can put the money to use again.

Sad to hear this news, but also excited to hear that Sandstorm is continuing as an open source project.

I'm mainly excited because Sandstorm makes indie web apps viable. I've been amazed to see how quickly members of the Sandstorm community can spin up sophisticated apps like collaborative editing or file sharing. If you have a framework like Meteor to handle sync, and Sandstorm handles authentication and sharing, then you can make a serious multi-user app in a weekend.

Even better, once you've made your app, you don't have to worry about security or scaling. So a junior developer could make an app which stores my sensitive financial information, and I'd still try it because I trust Sandstorm to keep my data safe even if the app is poorly written.

Sandstorm's foundation is solid, and I think a few UI and developer-happiness improvements will make this a reality. Wishing the team all the best!