548 karma · joined July 22, 2013
Socials: - github.com/tn1ck - linkedin.com/in/tom-nick
Interests: Fintech, Entrepreneurship, Hiking, Mentorship, Open Source, Remote Work, Programming, Startups, Web Development
---
It's not only unpractical, but hard to get it done. Recently tried to run Postgres in an AWS Lambda to create an anonymized DB dump. It was so painful that I gave up and created an access restricted database to do the anonymization instead. An in-memory mode for Postgres that would be as easy to run as sqlite or duckdb would be so useful for things where one can not replace it with either of them (sql dumps, testing).
[1] https://www.happyscribe.com/public/the-joe-rogan-experience/...
> LiteFS is currently in beta and is not recommended for production use yet.
Kind of JS dev in a nutshell, always bleeding edge.
> The idea is still right, but of course, as you have seen, we've gone through the storming phase, a norming phase, now you know, having to deliver in the performing phase, but it's what you would expect
I can guess what these phases are, but is that a common workflow in the industry? I never heard anyone to refer to these cycles in software development. For me it just sounded like a poor attempt to explain the delays with some buzzwords.
I would actually look more into their "professional" behavior purely from a code viewpoint. As an example, I once had a coding interview submission that I was looking through and at first sight it seemed everything is there, tests, code comments, framework patters. My first thought was "Oh nice, they really are thorough". But looking deeper at it, these things hid the actual problems. E.g. The function interfaces were poor and mixed side effects when not necessary, tests tested _something_, but not what was important. And the algorithmic challenge wasn't even really attempted. This made me acutely aware of how easy this person could have passed a less technical interviewer, as everything looked professional. The effects are worse that someone whose obviously a junior or poor coder, their code looks off at first sight.
[0] https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html [1] https://htmx.org/
Source is at https://github.com/TN1ck/super-sudoku if anyone is interested
One can always add some lemon juice if one is forced to bake an apple pie with substandard apples at hand, works quite well.
Though not a fan of some rants and the bashing on Zoomers, give them a chance to build the next iteration of the common tools, the oldest Zoomer is 25 at the moment.
[0]: http://acko.net/files/pres/siggraph-2014-bof/online.html
[1]: https://acko.net/files/gltalks/pixelfactory/online.html#17
[0] https://github.com/TN1ck/super-sudoku/blob/master/src/engine...
App: https://sudoku.tn1ck.com/ Repo: https://github.com/TN1ck/super-sudoku
So there are some solutions available if normal mobx is not enough.
Quite the claim! For me the moment I never want to look back to is to refactor a substantial part of the architecture of a JS app with more than 20k lines of code (And I did write most of it myself). If you don't do large scale refactorings or work mostly on smaller apps, then indeed, types won't be much of an issue.
But you should become aware about how often you see "undefined is not an object" and similar, that's a type error that is almost gone when using TypeScript.