To me the real amazing thing about Erlang is more the fact that these patterns based on queues and messages and supervisors scale so well. They are easy to implement on a small, single node application. You can compose them. You don't need to complete reauthor your calls to start distributing them and fanning out responsibility across your nodes because you've been doing RPCs from the start. A multi-node application is not that much more difficult to reasonable than a single-node application
The weakest part about distributing these tools in Ruby for me has been rbenv wiping them away on switches. I rarely switch Ruby versions these days, but this used to be pain all of the time
It is ridiculous to me that HN is the sink for these issues. We have no context about what you were trying to do and you are making assumptions that you were in the right the whole time. You could have been violating ToS for all we know. What is the point of this thread?
Mathematical proofs. I studied math in college and didn't really understand anything I was doing until well after school. When I read Book of Proof a few years later it all suddenly clicked for me and made perfect sense. Half of studying math is just surviving. Same thing for my Fourier analysis and signal processing classes. I didn't grok it until a few years after my classes. Don't even get me started on statistics which I still find difficult to really understand "why do I trust this magic formula?". The hard science behind statistics is actually incredibly complicated when you start to dig into it
I've always thought the caching Rails added was invaluable most of the time. Granted I've also worked with plenty of people who don't even look at the query logs and wonder why their API's are slow
I love using Linux from a platform perspective, but it has been terrible from a usability perspective. Awkward default keybinds, broken software all of the place (e.g. anti-blue tinting), twitchy trackpads that require constant reconfiguring vs. just being excellent out of the box, power savings just works and doesn't require explicit configuration. I find Macs terrible to run software on/write software for/fix by hand, but I think they're great for text editing and navigation which is how I spend the vast majority of my time
My experience with DragonRuby was really poor. I was dismayed how restrictive it was (e.g. with libraries). Images were particularly painful and I was annoyed that the toolkit couldn't dynamically resize them for me (nor could I pull in ImageMagick). Perhaps it was trying to deal with sprite sheets and having to hardcode pixel offsets. Yes, it uses Ruby syntactically, but it doesn't feel like Ruby to me as far as ecosystem and productivity go. This was a few years ago - maybe this has changed. I probably wouldn't give it another go, but I'd love to see something built in DragonRuby hosted online to see what it can do.
Godot, while not perfect, fit my expectations better. I found myself simply using the prebuilt abstractions I was already building by hand in DragonRuby. Things mostly work. When it came time to cross-compile for hosting on itch.io, I was really delighted by how easy it was to get my games in front of people. That quick feedback loop got me hooked for a while.
Yep, let’s not forget that your “simple” Postgres cluster gets complicated really fast when you start having to graft layers of tools on top of it. There’s a reason why Spanner and DynamoDB exist. God forbid someone try to use Postgres to solve the same problems and actually get the configs wrong leading to years of inconsistent data. Definitely never seen that happen…
People blame airports for letting people board with bombs, we blame pharmaceutical companies when someone switches the bottles with poison, we blame gun manufacturers for public shootings
Zero configuration sounds like the opposite of why I like vim. I want things to work exactly how I want them to work. Vim’s composability of normal, day-to-day actions you already know is its best feature
This is a good list. I need to get more comfortable with quickfix and location. I’d like to build something like the fzf plug-in some day
I’d highly recommend folks learn some vimscript. Mappings, functions, commands. My most recent use for these was for quickly generating a lot of permalinks for building internal documentation. Macros and argdo are also invaluable for large scale edits.
Writing too much is just as bad as writing too little. It really depends on context. If I write you an essay and the salient points are buried, that’s even worse than being short and lacking clarity. At least in the latter case the receiver can ask for clarification
Having complexity without understanding the “why” behind the complexity is a major issue. My best advice is to balance pragmatism with simplicity and always prioritize personal learning and understanding. If you use React, ask yourself why. You will eventually learn a lot of microtopics the more you do this. I like working in infra because microtopics are treated as first class. There is no shortage of articles about database consistency models for example. Learn the microtopics and you future proof yourself from mindless tech decisions
Unfortunately the real power ask is creating these offline so they can be embedded and shared in other contexts. I don’t have confidence in gating by a web service. Others have come before you and tried
Create a compound signature. You don't just take one measurement but many measurements and then assess the probabilities. You may have people talking in a mall, but they will be in a narrow frequency band. Similarly you can analyze the repeating elements. Keep iterating and adding stuff until f(signal) performs well
Shazam is not particularly complex, however it is a very clever solution and a great example of applying a simple engineering concept broadly. I still hold it as one of the best examples of clever engineering in the app world
I think of ML eng as more infrastructure and scalability. Possibly doing tasks like converting lab models into models that can be run at production scale. There is a blurry line between the two because it makes sense for some tasks to have shared ownership - just like you tend to have with people reaching across the stack to get something done in front-end vs. back-end web roles. As with anything, as you get more experience you get more comfortable jumping around and maintaining a larger set of concerns
> This is written as speculation of course, but it matches some long-time "conventional wisdom", that most Rails apps spend most of their time on I/O waiting for something external.
> Can we put this rumor to rest?
You have only given one example though. What rumor is there to put to rest? I think the statement is still accurate: "most Rails apps spend most of their time on I/O waiting for something external"
To your specific concerns though - I have also see ActionView and ActiveRecord casting take up non-trivial amounts of time (I recall a situation in a past job where the mysql driver being notoriously bad with allocations of enums - probably our own doing however).
Why do I need to authorize you with my GH in order to see your track's contents? I would recommend opening the curriculum so a potential buyer can preview whether the product is right for them
I think this is an interesting idea. I find it hard to justify paying $80/mo for an extended period of time for just Git, Docker, Redis, and SQLite clones though. You'd need a plethora of content to have me stay for more than a month to simply power through it all. $80 is even a lot for just those considering there are easy to find tutorials for these. The real selling point is having a lot of modules colocated and I am merely paying for convenience and manicured delivery rather than novelty
Interesting idea. Tech lead at our company is mostly a TPM role mixed with the TL responsibilities listed here. In fact every senior engineer is expected to act in the TL capacity at our company. No commentary as to whether that is good or bad just relating that is how our (fairly large, well-known) org works
There are plenty of critical, unglamorous jobs which need to be done. It’s not unreasonable for an engineer to value high six figure/seven figure salaries over a feeling of work fulfillment and skill utilization
I’m visiting Peru soon. People choose to take day-long bus rides rather than a <2h flight getting from Lima to Cusco. I find it hard to believe that a train wouldn’t have at least some interest for budget travelers or people who value time less than most of us here
Dealing with a separate table is still hard (I know because we do this). What happens when you do a migration or need to shard something and want consistent partitioning across your data? You have to consider your one off table that everyone inevitably forgets about. I agree that a deleted_at column is too big of a liability for compliance reasons though
This reminds me of the time I worked for a disaster recovery company in their backup provider division. You could choose to encrypt all of your data end-to-end, but doing so meant you had to be responsible with the encryption keys; we could not bail you out if you lost them. Unsurprisingly clients were a lot less interested in that option once we had this conversation
I thought Spotify was much worse. The silent playlist song cap alone was infuriating. I constantly had issues syncing between devices. UI feedback was miserable making it so you didn’t understand whether a button was pushed due to the callbacks over cellular, not that Apple Music is much better here. The worst part of Apple Music is the distinction between Apple Music and your library. You can rate things in your library but not Apple Music - which I’m guessing is an artifact of iTunes days when you had MP3s locally. The like feature in Apple Music is also terrible compared to Spotify
A lot of new tech is also spun out of large companies where the original ideas were piloted internally (see Kubernetes, Bazel, a number of distributed databases)