This looks amazing purely from an engineer's perspective that wants to level up on something they have worked on for a while with enough understanding to build working systems with it. Just confirming, this is more useful for developers that have worked with Erlang/Beam correct? Not so useful for a Beam newcomer?
My experience is that TDD just ensures that the code is unit-testable. This can lead to more complex code when it need not be complex. I definitely write tests, but my default approach is to make the test simulate how a user would use the functionality. So mostly a higher level test like a system test. And you can do this only when you have a bigger picture of the program that you write (which need not be driven by unit tests, just need to elucidate what the program needs to do and break it into steps). I don't rule out unit tests, but my approach is to start with tests that resemble system tests, and if i specifically need a unit test for a hairy algorithm in a function, use a unit test to help.
Also the higher level you test at, the less probable that you have to change the tests when you change a piece of functionality.
I frequently do TDD with integration and end to end tests. The type of test should be dictated by the nature of the code, which TDD doesnt have an opinion on.
Good for you then. I myself have not come across the (loud/louder) TDD exponents advocating for using TDD in system/integration testing, they mostly focus on unit tests. If you can point to some examples, it would be a learning experience for me. If not that's fine too, I am glad that there are voices out there like yours.
I wrote a systems/integration testing framework for this purpose specifically and I wrote a few essays alongside it. It has the same name as my handle.
Not much traction, unfortunately. Id be interested in any comments you might have.
I have pondered this question before and I have seen people recommending "Philosophy of software design" by John Ousterhout, but my qualms with Clean Code is not that it needs a substitute, its just that its a fairly simple set of concepts about which Bob makes a big deal. I did read some of his books, but I realized its only about 10% of what makes a competent software engineer. My suggestions to people starting out or even seasoned programmers are that get an idea of what he advocates (TDD, SOLID and all that) but then design of programs is just a small part.(And I also can debate the usefulness of both TDD and SOLID. Personal opinion coming: they are great for small or greenfield projects but almost always don't hold up in the real world).
Learn about other kinds of (much more effective) testing like System/Integration testing, Property-based testing. Spend a lot of time learning about databases and SQL. Maybe get into somewhat esoteric topics like constraint solvers and logic programming. You may not use these but it helps to know there's a wide world out there, and they do bend your brain enough to enable you to think differently.
Time is limited. It does matter what we spend it on.
And you can use struct for heterogenous data =) It has a neat DSL for packing/unpacking the data, reminiscent of the "little languages" from classic book The Practice of Programming. Python is actually pretty nice working with binary data.
> Python is actually pretty nice working with binary data.
It really is! I’ve been working on a project to generate large amounts of synthetic data, and it calls out to C for various shared libraries to do the heavy lifting *. Instead of encoding and decoding back and forth, I can just ship bytes around, and then directly write them out to a file. Saves a lot of time.
*: yes, I should just rewrite it into a faster language entirely. I intend to, but for the time being it’s been “how fast can I make Python without anything but stdlib,” as long as you accept ctypes as being included in that definition.
I use it on my 2015 Macbook pro. Its amazing how quickly you can get set up, kudos to the authors. Its a dog in terms of response time for questions, but that's expected with my machine configuration.
Also they have Python (and less relevant to me) Javascript libraries. So I assume you dont have to go through LangChain anymore.
Thanks for the talk link, it completely kept me engrossed and was a pleasure to watch! Addendum question: what is the state of database drivers for Elixir? Does it have mature libraries for Postgres for eg? I imagine if it's targeting web development, it will need those.
You should look at the command `python -m venv`. Its built in, and is a breeze to create virtual environments. I guess it does not provide shortcuts for activation etc, but I am ok with that.
I used pyenv in my previous company. At first it was fine, but after a while with multiple versions of Python installed, things stopped working. The right virtual env was not activated, etc. (It could have also been because our software updates like OS and security upgrades were pushed by desktop support). I removed all of it, and just resorted to installing multiple versions of Python the old way (downloading from python.org) and then use `python<version> -m venv /my/virtual/env` to manage my virtual environments. Things are more stable, and I don't feel like its magic. I am not going back to pyenv.
I thought one of the advantages of pyenv was that you switched to also creating virtual envs using pyenv and managed virtual environments with it too. Maybe not.
Amidst all these great discussions, I would like to point out that this article really helped me get my head around a B tree and why its a great optimization on top of the Binary Search Tree. Thanks to the author!
Mitchell is the only person I can think of who went through the cycle of tinkerer/IC -> founder -> CXO and then back to IC in his own company. Also, his writings on Zig has been tremendously helpful for someone like me who is curious about it. Huge respect from a fellow IC!
Integrated Circuit. Insatiable Craving. Irrevocable Crust. Indifferent Creator. Ignatios of Constantinople. Instigating Crime. Irritating C**. Individual Contributor. Your guess is as good as mine!
It’s standard big corp parlance for a role that has no direct reports. Obvious terminology for anyone who has worked in an org with a moderate size HR or higher, but anyone else has probably never heard of it. I knew immediately that it meant Individual Contributor but I can easily see someone not knowing it if have never worked in BigCorp
Go on Blind and you'll see it used all the time, along with a flurry of other incomprehensible acronyms that make Silicon Valley the TV show seem more real than ever. Blind is probably the strongest representation of BigCo population on the internet in terms of percentage of users.
You'll see it in plenty of Reddit discussions as well. It just so happens that a good hunk of this site happen to work in the kind of environment that the acronym is used frequently so perhaps it's not entirely unreasonable to expect it to be well known.
I swear though, if you haven't been on Blind and you just visit it's like decoding another language with all the acronyms.
At Unity, Joachim Ante always stayed very close to the underlying engine and its tech, rather than the broader market strategies and moves. Of course, every situation is unique and difficult to compare 1:1.
