516 karma · joined March 13, 2008
Twitter (and almost everywhere else): JitterTed
Blog: https://TED.dev
Twitch: https://JitterTed.Stream
My Discord: unlisted, but DM me for an invite: JitterTed#4770
Email: tedyoung@gmail.com
I'm happy for the folks behind Accusonus, but sad that I'll likely see my valuable tools disappear into the Meta-verse.
I gave a talk a few years ago on how people learn: https://ted.dev/learntalks
Once I have that, I get detailed enough on the UI, either by writing some code, or understanding what information it needs to get from and send to the underlying parts. As soon as possible, I write an automated test that defines the behavior I want (which fails), then "move inward" to the next boundary, such as the Use Case/Service layer (I use Hexagonal Architecture), write a (failing) test at that layer, and then start implementing some behavior.
I'll refactor, which often leads to the creation of a new class with a bit of behavior (this is the "inside"). I'll TDD that new behavior until it's all Green. Then I'll go back out to the Use Case boundary and write more tests/code, TDDing at that level, with continuous refactoring to extract new classes.
Once I'm done at that boundary, I'll return to the Outside/UI test and if it passes, I'm done (and maybe I have some UI cleanup to do). If it fails, that tells me I need another spiral down the boundaries (toward the inside) and then back out.
At each boundary, I may pause and do some CRC Card (class-responsibility-collaborator) design work, if I feel I don't have a good sense of what I'll need ("do I need a Group class here, or will the existing Roles for a User be enough?").
The whole template problem, along with customization (or is it configuration?) is the biggest blocker for me. I'm going back to a straightforward Markdown-like to HTML generator for my next blog revision.
(You can DM me on Discord for an invite if interested: JitterTed#4770)
Even given the recent turmoil, being bearish like he was in June 2020 would have cost you lots of money.
It’s easy to “call” the bubble if you keep saying it every six months
I don't think he's saying anything about self-promotion? I believe many folks have the opposite problem: not promoting themselves, often because they think their stuff isn't very good.
In what sense? What do you like about KP: the doctors, nurses, etc.? The billing department? Single-payer would not take the staff away. It would get rid of large swathes of the billing department that are pure waste.
Not everyone has had your positive experience with KP. We switched away due to lack of availability of certain specialists.
Security - even just understanding the various protocols and limitations of things like JWT would be useful.
Automated Testing - I'm a Test-Driven Development advocate, but I also know that's rarely easy to incorporate into existing codebases. However, the ability to write good, small, focused, developer tests is a very useful skill. And not just because of the tests, but often because it helps you implement functionality in smaller steps.
HTTP API Design - Especially since it involves designing protocols without you realizing you're designing a protocol.
Anti-Terror Police Project - https://antipoliceterrorproject.org/
Lots of journalism: Hechinger Report, Grist, ProPublica, NPR, etc. They're not perfect, but they're necessary.
(I also pay for subscriptions to individual journalists such as Matt Stoller, Emily Atkin, etc., but those aren't tax-deductible.)
Depending on the language, there may be other services that work just as well, but AWS/Google Cloud/Azure are either more expensive or will require more time to setup and maintain.
> if research results are selectively chosen, a review has the potential to create a convincing argument for a faulty hypothesis. Improper correlation or extrapolation of data can result in dangerously flawed conclusions.
1. Break things down into small "complete" steps. Nope, smaller than that. Nope, you can still break that down. Test-Driven Development can help here, not by making sure you've got good test coverage, but by encouraging you to break down the solution into small, testable pieces.
2. When learning something new, don't copy-and-paste. Retype it if you have to, but at least understand _why_ that code will work, and maybe a bit about _how_ it will work. As you get more experienced, you can copy-and-paste, though you'll find you'll do that less anyway.
3. Related to 2 and the post about technical communication: learn how to concisely ask questions. The number of juniors (and seniors) asking questions, but failing to show the precise problem (or at least what they think the problem is), with enough code (but not everything!) to evaluate is...frustrating for those of us who want to help. Tell us what you tried, tell us what the errors are (precisely, i.e., here you want to copy-and-paste!), but do so with as few words as possible. This is _definitely_ a skill, so you'll get better as you do it more, so pay attention to the questions you get in response to your question. Reflect on whether that could've been included in your original question.
In early 2022, I'm going to manufacture a small number of the game using The Game Crafter (it's more than just cards), but the whole idea of manufacturing 500 copies and the logistics of shipping are daunting.
[0] https://jitterted.podia.com/print-and-play-version-of-jitter...
Would help if it was smart enough to show only latest information for your search. For example, no more XML configuration results for your question about modern Spring Boot applications.
[Edit: didn't realize Backblaze has cloud storage, I still think of them as the cloud backup company.]