Coding for cases you know how to handle. e.g. I want to display file contents but have fallback text until it’s available. Vs let unexpected cases crash. e.g. I must read a file to proceed. The file server connection broke. Let it crash, process restarts in a known good state, future calls may work.
4 years ago, I was locked down in the Capitol. When the majority of the Republicans voted to overturn the election AFTER the attack, something broke in Congress that still hasn’t healed. Truth is truth. And while it should never be partisan to defend democracy, we can’t pretend it isn’t.
My new deep dive on how Trump “won” the popular vote.
I put “won” in quotes because it wasn’t his win, but Harris’s loss. The results were not a “swing right” embracing Trump/MAGA, but a vote of no confidence in Democrats (and in our system as a whole).
www.weekendreading.net/p/how-trump-...
Usually `Stream.unfold/2` or `Enum.reduce_while/3` works well enough for me when I find myself wanting something similar to a while loop. But plain recursive stuff can be nice too.
Really interesting comparison. Do you see an overlap between the ways the SPA world tackles CSS issues and this ecto query question? Abstractly they feel a little similar to me. In addition to CSS I also often find SPA data queries living close to calling UI component code with some utility helpers.
Sounds like you and I have different experiences. I can definitely appreciate that plenty of companies do get mired in tech debt and plenty of them in ways that could be avoided.
To be clear my point is that I do see people essentially throw away POCs all the time and I agree that type of quick iterative behavior overlaps a lot with company success. I didn’t intend to suggest anyone add anything to anything. Just reacting to the claim that POCs are always stacked on.
I find product iteration in seed through series B-ish startups is refactoring and rewriting most POC code. The thing I keep is an understanding of the business space.
The framing and design of business code is most useful early as a guidepost for new and junior hires if hiring kicks up.
I’d be surprised if that made a big difference. Every JS dev I’ve seen mix a non-JS ecosystem replaces the out-of-the-box integration no matter what it is. IMO making it easy to replace is more important to adoption than aiming for a friendly integration.
I’m open to being surprised though.
I think there was but it was deprecated (discussion linked from the old check page) hexdocs.pm/credo/Credo....
The story of Jan 6 is like this now. Trump supporters throw out several different and sometimes contradictory explanations: that it was a just cause, that it wasn’t a big deal, that the FBI did it. The point isn’t to convince but to sow doubt in the truth… of an insurrection attempt incited by lies.
Phoenix LiveView 1.0 is out!!!
Official blog post with a history of LiveView: phoenixframework.org/blog/phoenix...
Full changelog here: github.com/phoenixframe...
Also several junior devs I’ve worked with struggled with merges conceptually when learning git and found it easier to learn with rebase or even cherry picking and applying because they felt they understood what was happening better. Which again speaks to tooling friction to me.
In workplaces I’ve mostly seen UX as an impediment to people using merges. If `--first-parent` or something similar was the default in more tools I bet there would be much less pushback from people expecting a linear history.
Nice to have some company up on this hill :)
I think the way I would summarize the advantages of Phoenix to a lay person would be: it's like the simplicity of building MPAs in Ruby on Rails, except it's actually fast and actually maintainable. It's everything that's good about Rails. With pretty much none of the downsides.
a bingo card with * WTF is detached HEAD state * I hate git * git's design is so elegant * I've used git for 10 years and I have no idea how it works * commits are immutable snapshots * just use magit * git is a directed acyclic graph * you have to understand the linux kernel dev workflow * mercurial is better * git is not github * subversion was so much worse * I only know 5 commands * a branch is just a pointer to a commit * the CLI is badly designed * you should just read Pro Git * rewriting history is bad * just spend 15 minutes learning git's internals * something about "porcelain" * merge sucks, only use rebase * rebase sucks, only use merge * I just do not care how git works * content addressed storage * subversion was better * something about Linus Torvalds * I just delete my git repo if I mess it up
git discussion bingo card
