neovintage

I feel like your con about not making the right design choices isn't a con. Solo development doesn't mean throwing out the principles that help you learn. Prototyping and beta releases exist to validate design choices without needing a team to debate them. If your software has users they become the sounding board. You mentioned only asking your friends about your ideas. The best part about prototypes and betas is that you get to build something, use it, and see if you like it before committing. If the idea doesn't get traction, throw it away!

“Data Downtime” is very real and can have terrible impacts on understanding what’s happening to customers or your business. I like that this series is taking the simple approach of using SQL to help identify the problems. (Its also a good lesson on window functions) Run these queries on some kind of schedule and you’ve got a decent solution to monitor the situation. Granted there’s different levels of sophistication to monitor these problems with better tools as your data volumes grow. The bigger problem beyond downtime is how to recover from these situations. I’ve seen many databases architected in ways where you can’t recover said downtime. That’s where change data capture could really help but I think that’s beyond the scope of this series.

I'm sorry code search isn't working. I'm more than happy to help. If you reach out to me via my email I can see whats up. neovintage [at] github [dot] com.

The premise around arrow is that when you want share data with another system, or even on the same machine between processes, most of the compute time spent is in serializing and deserializing data. Arrow removes that step by defining a common columnar format that can be used in many different programming languages. Theres more to arrow than just the file format that makes working with data even easier like better over the wire transfers (arrow flight). How this would manifest for your customers using your applications? They'd like see speeds increase. Arrow makes a lot of sense when working with lots of data in analytical or data science use cases.

Hey everyone. I had a lot of folks reach out to me about this change. We've heard y'all loud and clear that you want a better code search. The goal of this change was to balance performance and search relevance while we work on a new code search backend. The vast majority of folks shouldn't notice a change in their search results. The folks that will are those that are using code search to count things across all the repositories in GitHub. That's a use case that we don't expressly support as part of code search but we know folks are doing it anyway. My goal for publishing this was to be open about the change and for those folks that are using code search for analytics not have to guess at what happened.

I apologize the changelog wasn't more clear. For repos like that, they continue to show up in search results. Every time they do, that resets the clock on when the repo ages out of the index. We tried to strike a balance between performance and having _all_ the code in the index.

Agree with the improvement on code search results. Our team is working on it!