434 karma · joined February 26, 2012
>If your monthly egress data transfer is greater than your active storage volume, then your storage use case is not a good fit for Wasabi’s free egress policy
>If your use case exceeds the guidelines of our free egress policy on a regular basis, we reserve the right to limit or suspend your service
Unless I am misreading, wasabi can shut you down if your egress is high.
Tldw: Do an extreme version of agile for getting better. E.g, do 1 minute sketches of a cup 12 times, trying different variations, and understand WHY some variations worked and some didn't. After experimenting, see how other people did it. And do it again.
I used to hate drawing, but after trying this approach for months I think I love it. I do not regret the time I spent learning to draw, and after putting in the hours it changed the way I see the world.
This makes no sense, if gme isn't shorted then why then break the law and restrict buying it?
And it does feel like they are restricting buys. Seems unlikely that all the trading platforms that rely on citadel coincidentally decided they wanted to hedge against volatility by restricting user buys.
I remember first day of speech in college when it was my turn to speak. I got up, walked out the door, and dropped the class.
It was hard to even work up the courage to post this comment. But i did. Baby steps.
https://stackoverflow.com/questions/15568405/youtube-api-lim...
https://www.youtube.com/watch?v=UDGG3hK4Bg8
Its a simplified version of a problem from work a while ago where we had to generate ui from lots of csv files. The last dev on it was taking weeks, but with vim I was able to come in and finish the boilerplate instantly. (We were commited to non-dynamic ui at that point, I think I made the right play especially with how we ended up using it).
Vim is, in my opinion, inferior to an ide or a good text editor, but if you have it as a plugin you get the best of both worlds and vim suddenly can do... basically anything you can think of. Like here's putting a breakpoint on every line in a file
The best part of vim in an ide is when you're pair programming and you do something fancy, and your friend says "Wait, go back, howd you do that??"
My ide lets me f12 to my config.js file and i can use editor hotkeys like comment toggle so by this metric my method is superior.
>You still have to rebuild the app for those environments.
As i said above you dont have to rebuild for python and javascript since they can load the config file on the fly. I use xml or json for compiled languages because beign able to change the program without recompiling is of critical importance.
>you shouldn't have different code for prod and test and dev.
You dont have different file for test/dev/prod, you have 1 config file that has a few inline if statments based off of runtime args. For me 1 file is less confusing than 2 or 3.
With scripting languages theres no reason to use json for configurtion unless the config is shared between programs. The main reason config files exist is so you can edit the program without recompiling, i feel like people forgot that and kept blindly using json when js or ts is better. My config file is just like 20 lines but putting the extremely simple conditional logic of if its debug if its client if its server there reduces program complexity by a couple hundred sloc.
if i follow your logic i should replace the 5 if debug statements in my config.js with 50 littered throughout my codebase. Also i lose strong typing and in line documentation.
edit:ill add im against emitting json from a config script, that seems like additional complexity. just reference a file, you can use json if and only if you need program interop and reference it from the config script
#1) no impossible to reproduce bugs
Any one off bugs you find a are instantly replayable, often times things that you think are bugs were actually just misclicks. Since issues you open in eg github are timestamped (and commits) you can go back to the video and see what happened
#2) You can now quantify what's wasting your time in numbers
By randomly sampling hundreds of hours of video I can say 60% (60%!) of my development time was spent on premature optimization. With this data I have now effectively doubled my programming productivity. An added bonus is now you know exactly how long everything took to complete in hours (837h for current project)
#3) Helps you stay on task
At the end of the day i tell myself what i need to do tommorow in a very short 5 minute video and suddenly its really easy to jump in.
In short, I highly recommend it, and theres really very little reason not to do it.
If you just count material and look 30 moves ahead you will not get outvalued by a human. The reward system does not need to be perfect to be useful, but there does need to be one.