697 karma · joined October 15, 2012
At least thats been my experience with it ~3months back. I was familiar enough with elixir/phoenix/channels to source dive and figure out whats happening, and today i know liveview well enough to avoid the weird interactions, but I imagine it can be a pretty miserable experience for beginners to start with.
Its nice that it comes with a proxy `fetch` implementation that you can use to make requests to your API backend from the svelekit "backend", but there are many leaky API surfaces around it, esp when dealing with cookies.
The docs is also rather lacking regarding the many callbacks that can run on both server/client, though it is somewhat understandable given everything is still very much in flux...
I use a Galaxy S10e, which is a "flagship" compact phone from few years back, and it has been a great phone that I still use today, but even on the day I bought it, battery life has been much shorter than what I was used (an IP8) to I suspected I got a lemon...
Its a media play, they dont want to be a media player. They want to have a hand on deciding what you listen to.
can you elaborate more on the "Don’t pipe into case statements" point though? Not entirely what you're saying with this one as there isn't any explanation why one might be better/worse than the other, other than aesthetic/personal preference. Needing to access the result from the previous pipe in the case maybe?
Its to make people buy into stocks they already have a position in..
and if you happen to know German, is there any mention of where are they getting their data?
This is an issue with tmux on macos to be clear, not with alacritty, but it kinda is related as alacritty doesn't come with any window management features so you kinda have to use tmux..
Just checked out the project repo, seems like the warning is still there on the faq[1], so I'm guessing it is still the same.
I remember using vim-go few years back, and I was very impressed of how much it "just works", it really turned my vim into a Go-IDE with very little effort.
I had to come back to go recently after not using it for quite a while, and a lot of the magic seems to have faded somehow. Ran into a number of issues that I had to find workarounds for.
Meanwhile, theres been a lot more big podcast that basically just bank on the personality of the host (e.g. Joe Rogan's) that can pretty much cost nothing to produce, and can churn out episodes after episodes talking about random stuffs.
Bummer though, coz I enjoy Gimlet's model of podcast a lot more.
Thats pretty much it for me. Everyone keeps saying that the performance issue is a myth, but I still experience a very noticeable lag with VSCode, and that keeps me from using it as my main editor.
And multi-cursor editing is still the best on ST.
I personally use vim as my main editor, and the ST for the occasional batch text-editing. Though the out-of-box experience of VSCode is really good.
I agree tech is getting democratised, but when talking about products that allows it, I'm thinking of products like Firebase or the recent darklang, not AWS Lambda. From all the Lambda usage that I've encountered so far, they are still very much in the domain of a "sysadmin".
Is this even achievable with Lambda though? Even with Lambda, you still have to configure your "infrastructure", just that instead of ELB and EC2, you now have to manage APIGW and Lambda, and any other "wiring" that you need to put in to do what you needed.
All in all, I can't really say Lambda is really all that "easy" considering options like AWS EB/ECS can be setup relatively easily.
Ideally, I'd like to be able to have native iterm windows and panes, but with tmux keybindings..
I agree it is. But just I took a quick look at the book, while I understand the book is not done yet, looking at the table of contents, I doubt this would help. Like, do you have to cover kerberos, IP Subnetting, OSI IP model, Agile, git, REST API, docker, and many more in a single book about "data engineering"? If anything, it would confuse beginners even more. Its like the author tried to cram as many buzzwords as possible into a single book.
After reading the book, googling for something like "mongodb v.s. cassandra" would start to feel as silly as googling for something like "javascript v.s. css" as you start to understand the fundamental differences between them.
No more need to hope the vague Medium post you found while trying to decide which DB to use would match your use case closely enough.
Really should've just linked to that hackernoon post though IMO, contains a lot more details thats very helpful in understanding what actually happened.