Post B7oFkmWozzE46CNa8u by hyc@mastodon.social
 (DIR) More posts by hyc@mastodon.social
 (DIR) Post #B7j6JNQYLTir3KVNlQ by hyc@mastodon.social
       0 likes, 1 repeats
       
       Have I mentioned recently that gitlab sucks?WhoTF writes world-facing code in ruby, the absolute slowest of the recent interpreted language fads? WhyTF do you need postgres to run a git repo? And then of course postgres is too slow for what you're asking it to do, so you throw redis in there too.God I hate crap written like this. All the more offensive that OpenLDAP infrastructure depends on this - the most efficient DB software in the world, depends on crap like this.
       
 (DIR) Post #B7j6JNpMrDZWII7CRU by hyc@mastodon.social
       1 likes, 0 repeats
       
       Stop using scripting languages to write production systems.Just stop it.They're fine for your toy experiments. Not for internet-facing servers. Use a decent, efficient, compiled language.
       
 (DIR) Post #B7j6JO3Y0Uul0GkWXo by hyc@mastodon.social
       0 likes, 0 repeats
       
       Pro Tip: if your complex DB queries are so frequent that caching in redis helps, You're Doing It Wrong.Any DB can return static answers to simple queries quickly. If your queries are complex and slow, that probably means you're generating dynamic data too, as intermediate or final results, using temporary tables, etc. If these results are cacheable, and caching is making a difference, that means they're not really very dynamic. Which means you've modeled your data wrong.
       
 (DIR) Post #B7j6JOaW1vHmeWAqvo by hyc@mastodon.social
       0 likes, 0 repeats
       
       And you're creating data on the fly that should have been stored statically in the first place.Whenever you have a "slow database" problem and putting a separate cache process in front "fixes" it, you've modeled your data wrong.If it *really* needs to be processed dynamically, a cache won't help.
       
 (DIR) Post #B7nWmME7GMnvAS0Vwu by hyc@mastodon.social
       0 likes, 0 repeats
       
       And to top it off - the thing that consumes the most of our bandwidth is a stupid webfont. Triumph of form over function.
       
 (DIR) Post #B7nWmMPoYsA5kjTrBQ by hyc@mastodon.social
       0 likes, 0 repeats
       
       If the largest volume of traffic on your git server is anything other than actual git pulls and pushes, You're Doing It Wrong. Serious tail wagging the dog action. Developers don't care how your fonts look, as long as they're legible. Nobody needs "pretty" bells and whistles on a code repo.
       
 (DIR) Post #B7nWmMbrq3nqM77TyC by hyc@mastodon.social
       0 likes, 1 repeats
       
       My mistake. Monaco isn't a webfont. It's a freaking text editor. https://microsoft.github.io/monaco-editor/7MB of javascript. Downloaded to your browser every time you look at a commit, or a diff, on gitlab. How nice.
       
 (DIR) Post #B7oFkmIHs1bFN7ZyUK by rl_dane@polymaths.social
       0 likes, 0 repeats
       
       @hycPlease, nobody tell him what Mastodon is written in. 🤭
       
 (DIR) Post #B7oFkmWozzE46CNa8u by hyc@mastodon.social
       0 likes, 0 repeats
       
       @rl_dane fortunately snac2 exists
       
 (DIR) Post #B7oFkmkIBu08lygL8i by mirabilos@toot.mirbsd.org
       0 likes, 0 repeats
       
       @hyc @rl_dane buggy as it is…
       
 (DIR) Post #B7oFo0EIVxFFSfFc2K by mirabilos@toot.mirbsd.org
       0 likes, 0 repeats
       
       @hyc @rl_dane (it is the way it is buggy for people reading posts written by people on snac2 instances that grates me, not the bugginess for those who use it, all software is)