96 karma · joined January 18, 2019
I had never heard of this idea, and thought it was super interesting. Imagine aircraft that could stay in the air indefinitely (for some practical purposes), carrying massive loads without fuel being a concern.
Similar to nuclear aircraft carriers and submarines, at least conceptually.
In case anyone reads this and thinks it's just commentary - this is literally enshrined in the U.S. Constitution (13th Amendment, emphasis added):
> Neither slavery nor involuntary servitude, except as a punishment for crime whereof the party shall have been duly convicted, shall exist within the United States, or any place subject to their jurisdiction.
Switching to an Android phone at your next phone upgrade cycle will be a lot harder if it also means you need to switch your credit card. Plus, giving users a better rewards rate for using Apple Pay over the physical credit card will encourage them to build the habit of paying with their actual iPhone (and as a follow on effect, probably help encourage further Apple Pay adoption among merchants).
Smart defensive move as device manufacturers face an ever more saturated market.
If you don't have a debugging setup in place, it's well worth taking the time to set it up.
You can't really just start a debugger at the beginning and step all the way through - for a big code base it will take hours to step through one entire e.g. REST API call, most of it wading through unimportant framework and support code. Some strategies for finding a juicy place to stick a break point:
- pick up a small bug fix task and try to hone in on important areas from there - ask another dev where some of the "main" parts of the code are - if they've been there for any time at all, they will know where to point you - look for files with heavy commit activity over time. Don't limit your search to recent commits - often, core code becomes stable and less frequently changed, but still gives you the best picture of how the whole application works - use performance profiling / flame charts to figure out where the most CPU time is being spent. As a bonus, this functionality is often included in your debugger setup
Once you find some "main" areas of the code, take some time to step through individual lines, and step out to better understand the call stack that led there. This will get you up to speed way faster than trying to read through code, documentation, and even unit tests IMO.
After trying a few like MySQL Workbench and Navicat, I landed on Querious and haven't looked back since. It's not free in either sense of the word but well worth the ~$50 USD license IMO.
Interface-wise I found it to be easier/more familiar to switch to from Sequel Pro, as compared to some of the alternatives mentioned above - more on the light and nimble side, less on the heavy interface enterprisey-feeling side if that makes sense.
It's Mac native, performant, and very stable. Some very basic features that felt like a big upgrade from Sequel Pro:
- Arbitrary WHERE clause support in the data view, so you don't need to switch to a full manual query as soon as you need slightly more complex conditions
- Multiple query tabs - I used to spawn multiple Sequel Pro instances because this was so hard to live without. There's also good management of query history and saved queries.
- Robust and performant import/export tools
No affiliation with the developer, just wanted to give a shout-out to a high quality piece of software that I've really appreciated using.