deleted by creator
deleted by creator
Often I use Python for exploratory purposes. Like, I got a bunch of data, and I want to know if a particular algorithm might work or not. I implement the algorithm, but realize the results don’t look good enough. So I tweak the algorithm, maybe even do major refactoring. Or maybe I realize my visualizations or metrics don’t capture what I need to see. Or maybe I must settle for some compromise?
I iterate on this repeatedly until I find something I’m happy about (or until I give up). Sometimes I end up with something completely different from my initial idea.
TDD won’t help me much here because the end result is unknown. For each iteration of this idea process I might even need to rewrite all the tests because none of them are valid anymore.
TDD only works well if the problem is clearly specified before the first line of code has been written, which is rarely the case when I need Python for something.
Mostly number crunching and data exploration tasks. Just so I can make informed decisions about the data I got. I do this rarely enough so it hasn’t been worth for me to install all these extra third party support wheels.
“Ohh, I got all these numbers I want to crunch using numpy or pandas and plot it using matplotlib. Hold on, I just need to write unit tests first.”
Catching some errors is better than catching no errors. No compiler in any language can protect you from all runtime errors either way, but some are better at it than others.
I shouldn’t need to do unit tests for quick one off scripts
I would swap Python with C++. Constantly dealing with stupid runtime errors that could’ve been easily captured during compile time.
Did you forget to rename this one use of the variable at the end of the program? Sucks for you, because I won’t tell you about it until after 30 minutes into the execution.
although in the context of version control, the term master simply refers to the gold master, a term borrowed from the recording industry which refers to the final mixed version of a recording, and does not have a corresponding slave.
Either way, I think “main branch” is easier to say, so it’s a win.
At least move the CAPS LOCK key. There’s no good justification for why it should be on the home row.
One benefit of using dropwhile is that (with a bit of practice) it can actually be easier to read than a for loop. All for loops look similar. You need to read the for loop line by line to understand what it really do.
With dropwhile (or map, filter and reduce), it’s immediately obvious it will drop all elements until a certain condition turns false.
Don’t touch things unless you have a good reason to do so. And when you have a good reason, touch it exactly as much as you need - but never more.
So TL;DR: there might be unexpected time zone rule changes in the future. The solution presented in the article is to store both UTC and local time, so the application can easily adjust itself if such change happens.
I can feel it coming in the air tonight, oh Lord
Learning about reflog was a game changer. Now I’m never afraid of breaking my branch. If I mess up, I can always git reset —hard
to a previous state.
Another game changer was learning that a perfectly valid way of doing squash is to do git reset
to an earlier commit and then do git commit -a
. Saves a lot of rebasing headache.
Use a jokeless architecture
Well at least we got a backup, right?
Right???
Maybe the it’s the English language that is wrong?
Serverless is more associated with micro services where each micro service can scale independently from each other.
I’m at least happy head hunters stopped spamming my LinkedIn