briandoll

Unfortunately many tickets in the state of California can not be written without a photo of the face of the driver. You ticket a person, not the owner of the car. I looked into this recently because as a cyclist I've witness horrific drivers AND caught many such instances on camera, which are utterly useless at getting any tickets issued. I realize a personal camera and a state-installed device are not the same thing, but I believe the fact remains -- face photo to identify the culprit, or no dice on tickets.

The idea though, that you should like, kill people in order to create a sort of chaotic attention to those ideas -- still kinda frowned upon IMHO

A friend of mine is a Vet at a place recently sold to a PE firm. If your wait times are crazy long, if you can't get through on a phone, if you realize your vet's office has parted ways with the great vet you used to see -- that's the PE firm counting beans and destroying the service for customers in an effort to squeeze every dollar out of the system.

As a specific obviously bad example -- Vet services in California are kinda seasonal. More visits in summer than winter, due to more time outdoors, etc. A PE firm looked at visits on a weekly basis and saw a downward trend in the winter and decided to re-set staffing based on that. Now that summer has arrived they are severely short staffed, have parted ways with great vets, and now wait times are horrific.

Thanks PE!

Here's a great talk relating Ways of Seeing to Ways of Selling as it pertains to software and communities from Deconstruct Conf in 2017: https://www.deconstructconf.com/2017/michael-bernstein-ways-...

In the US, the dairy industry tried this and thankfully lost (in California): The Animal Legal Defense Fund represented Miyoko’s Kitchen in its challenge of unconstitutional restrictions placed on plant-based dairy products’ marketing and labeling

Miyoko makes vegan cheese and brought the California Department of Food and Agriculture to court to challenge their ban on the term "cheese" to represent her products. She won.

https://aldf.org/article/miyokos-victorious-in-first-amendme...

I think it would take a significant effort to bring some of the features I love about Superhuman to a Pine-like workflow. (Definitely not impossible!) The one I use most of all is a reminder -- "punt this email to my Archive until next Thursday at 8AM" where it will then re-appear in my inbox. I do something like that a dozen times a day and would need a very reliable replacement for that.

Search in Pine is guaranteed to be better than Superhuman. Unfortunately, Superhuman uses stemming for _all_ search, and you literally can't turn it off. You can use quotes as much as you like, but search for "Shipped" and you'll find a billion emails with every permutation of the word "ship" in it. It's awful.

Firstly, speed. Opening that mailbox with a GUI-based email application on a developer desktop was orders of magnitude slower, if it opened at all. The volume was just far more than most desktop email apps was used to at the time.

Secondly, it's unix, so you're operating a tool that allows you to construct ad-hoc workflows very quickly. There was a scoring bug where the stats software (literally a pipe-delimited text file that was updated by midnight the day of the game) had given a safety to the wrong player with the same name. I had hundreds of emails complaining about this bug, and I needed to fix it. I can search in Pine, find a result set (ie. everyone who mentioned this players unique name), compose an email to all of them (BCCd), and pull in a text file as the email body that I'd written previously, that explained how and when this would be fixed.

I had TONS of canned email responses, saved as text files, so finding a set of emails, and sending replies w/ the contents from a saved text file, was a very routine workflow that happened dozens of times a day for various situations.

I knew nothing about american football really, but with perl and pine, I felt like there was nothing I couldn't do.

I built a fantasy football app in 1998 for WDVE in Pittsburgh, PA and had to act as the "Commissioner" to handle all disputes, complaints, and other interesting feedback, all via email, and as a person who couldn't give a shit about Football and never watched a game.

The backend was all perl, pulling data from stats.com or something like that. But the only way any of this was possible, was using terminal-based email (pine, not mutt, but similar enough).

Terminal-based email is a great example of a tool optimized for power users, and I'm realizing now that most of what I was able to do in Pine in 1998 I still can not do with any "modern" email client (I pay for Superhuman these days, which is still a far cry).

GitHub was hosted on Engine Yard[0] in the early days, and as part of that deal had an Engine Yard banner in the footer. We then moved to Rackspace[1] for a few years until the first funding round in 2012 when we built out our own datacenter in earnest.

[0]: https://github.blog/2008-05-07-rolling-with-engine-yard/ [1]: https://github.blog/2009-09-15-github-is-moving-to-rackspace...

I have the Elgato FaceCam and it's absolutely fantastic on the Mac. Zero issues, great adjustability, good quality (much better than a laptop webcam, not quite as good as an iPhone/"real" camera.

Very cool, reminded me of one of our fist winners of the first GitHub Data Challenge, where someone made a daily newspaper out of their GitHub feed using a thermal printer: https://github.com/alx/Le-Github via https://github.blog/2012-06-12-github-data-challenge-winners...

Surprised nobody mentioned Mux yet, who are really great at providing a video platform for all sorts of apps and businesses: https://mux.com/

MP3 is a good one. Although I had to develop a lot of perl to manage the various incantations of ID3 tags, especially when VBR became popular. MP3 files may still play, but the full experience (properly attributed w/ band, album, song title, song number, album art, etc.) is likely less than perfect over time.

Do Wordstar files open in modern Word applications, even on iOS? That's part of the access aspect over the long term -- files that can be used, everyday, with your daily-driver tools with minimal special software needed.

I assume this is a response to Derek Sivers post: Write Plain Text Files https://sive.rs/plaintext

I've been using computers daily for about 35 years now and I have a _lot_ of plain text files that I regularly use -- notes, lists, outlines, quotes, links, etc. Does anyone who has been around a while, have a large multi-decade collection of texts that are _not_ plain text? What formats do you use? How do you maintain access to those files over time?

I was wondering what the advantage is to building something like this, compared to just using a bluetooth adapter that connects via RCA cables (like this box does).

I suppose one advantage is that if you walk far away from your stereo, you can loose bluetooth connection and drop audio, where this device has it's own WiFi connection and pulls Spotify audio directly, and is just manually controlled via your phone.

I can see that. In the year that I've been using Camo, I've never personally had that issue, but I can see it being problematic if you're constantly needing your phone for a second factor all day (consider a yubikey?).

I'd say that another _advantage_ (IMHO) of Camo is that I don't have my phone to use for distractions while on calls, so that's a pro in my book.

Or just use your much better iPhone camera via Camo (https://reincubate.com/camo/) w/ great image tuning, etc. since you always have your phone with you and isn't yet another thing to deal with.

Not really hn fodder really, but since this article has no substance, folks who thought they might want to read this would likely enjoy this instead: https://www.nytimes.com/2019/07/12/arts/bob-ross-paintings-m...

Or just never sign NDAs since they are almost universally egregious and don't benefit you at all to become party to. 99% of the time when you say no, the other party will just shrug and say ok.

The free tier provides the stated usage levels at no cost, indefinitely. So if you were to stay under the quotas of data size, writes and reads, you don't pay at all. When you go over, you just pay for what you use. No servers, no pre-committed capacity, just simply pay for what you use.

Before GitHub launched, I built some large eCommerce sites, and for a vcs we used CVS, and then Subversion. We had a person on our team with the title of release manager, because branching in Subversion, and merging back to make releases, was a specialist effort that took time, patience, and managing a tremendous amount of fighting between teams of what features and fixes could even be merged together in order to ship this release.

When I started using git, it broke my brain. I wasn't really sure I understood it, but the idea of cheap local branches soon became the most important thing to me in a vcs, and everything became easier and so much faster. You could just work on code the way real life happens, not in some methodical pre-planned release schedule that always rubbed harshly against the reality of bug fixes and ever changing minds.

Planetscale is a lot like that transformation. We've been thinking of databases as this specialist thing, where the arcane knowledge required to make it perform well is a specialist role, and something completely untouchable by mortal engineers. While we've learned about the importance of good data modeling, we've dealt with a layer in our stack that is essentially static. Shipping features that require changes to a database schema sit and languish, because the pain and coordination required can often be too much for a team to want to deal with.

What PlanetScale has done is solve two massive problems in one platform. First, since it's built on Vitess, it Just Works At Scale. You don't need to fiddle with knobs to get it to perform well. You most definitely are not even in the top 10% of what is already running on Vitess, so you don't really need to worry about ever outgrowing PlanetScale. But the BIG innovation here is what is possible now that a database works the way the SDLC has evolved with git. Make a branch, change the schema, roll it out with your code. Just like anything else, really. Use the PlanetScale CLI to actually USE your database. Change the schema because it will make your code better, and don't worry that you're somehow going to do it wrong.

PlanetScale just made databases useful for developers beyond a nearly-static data store. It's a high-scale database that you can change like code. It will break your brain a little at first, just like git did. And then you'll wonder why the hell we waited so long to have a database this good.

You can definitely make your own templates. The link I shared above has links to the tool I use for this (https://github.com/moovida/remarkable-hyutilities)

Absolutely. I did the same for a long time. I work with a bunch of companies every year, and having notes organized by client has been really helpful. That and a nice workflow to send notes/sketches/ideas from the notebook to a client via email is pretty nice. But definitely not for everybody.

This is one of the reasons I've started to use the reMarkable tablet for taking notes. Sometimes I don't even look at them again, it's just a more efficient way to get the info into my head.

I wrote more about my current workflow/stack here if anyone is interested (w/ some reMarkable hacks): https://briandoll.medium.com/personal-setup-for-getting-shit...

Came here to say this, love how this works in Feedbin: https://feedbin.com/blog/2016/02/03/subscribe-to-email-newsl...

I'm a little surprised only 9 of the 302 articles appear to focus on marketing. For anyone looking for marketing specific guidance, we've got a lot of free materials on our blog: https://www.reifyworks.com/writing

We've helped 80+ developer-focused companies over the last few years as a consultancy, after our careers as founding marketing leaders.

The Heavybit Library is also really incredible, with lots of video content (transcribed, searchable) with a similar focus to what's here. https://www.heavybit.com/library/

Tilt is great for local development and coordinating teams of developers who build apps on Kubernetes: https://tilt.dev/

I'm not sure "hard to replicate technology" is a moat I'd often bet on, given that by definition that does not deliver any specific advantage to your customer.

User Experience. Developer Experience. Community. Those are moats you can bet on primarily because it takes so much dedication, expertise, and work. That's not easy to buy.

The main point here seems to be that the failure to build a SaaS product is blamed in part on the compounding technical debt incurred due to a fast-moving software ecosystem and the effort involved in keeping up.

The point I think most people should consider instead, is that building an app is not the same thing as building a business. Building the app is comparably easy, once you've proven that you understand the market, your target buyer, and have a unique insight/tool/solution to offer that you can deliver via software.

If you want to learn a technology, by all means build an app. But if you want to build a SaaS business, keep focused on building the _business_. The app, it turns out, is the easy part.

I loved the talk that Michael Bernstein gave at the Deconstruct Conference relating "Ways of Seeing" to "Ways of Selling", related to software specifically: https://www.deconstructconf.com/2017/michael-bernstein-ways-...