fullstackchris

I try to focus on software and everything I've encountered through projects throughout my software career, but often a general post about thoughts on life / software in general sneak in here & there.

My goal is always to share real world examples and code snippets, instead of the 1,000th iteration of the todo app.

"instead, here's our way with a DIFFERENT set of frameworks and libraries!"

...you're kidding me right?

Oh yeah?

and netlify is totally free for an infinite amount of sites! how crazy is that?

> We use a short Python script with exactly 45 lines of code. Including comments and blank lines. > > In summary, this is the simple toolchain for building our web: > > Developer updates index.src.html > Watchdog.py detects the file change and ... > ... renders Jinja template into index.html and ... > ... calls Tailwind CSS CLI to generate styles.min.css.

love posts like these that insult literally any other way of doing things except their way, claiming it's "simple" when in the end they don't even show the step by step code or link to any repository that shows how it's done. regardless of "without frameworks or tons of libraries", its esoteric and definitely not an average or common way of doing things (to the rest of us), and clearly DOES use codes (and/or?) a framework!!!

no description of what the heck "Watchdog.py" is, no description of what Jinja - I for one don't know what either of those are, sorry if i'm an "ignorant normie"

simply put, it's quite clear you ARE using frameworks, just in your mind, perhaps, you "aren't"

this whole framework vs no framework vs BS vs BS vs BS has gotten really out of hand, and 99% of devs cant see the forest from the trees

what in the world did i just read

My go to 'cloud' path is just a digital ocean droplet, using docker containers to spool up whatever you need and connect it all on a docker network.

A single server (2-4 cores) running quite literally ANY modern backend framework (node, go, C#) should be able to handle _thousands_ of requests per second, I'm not sure where or when this idea has disappeared, it seems like everyone automatically assumes their small SaaS or webshop needs an autoscaling kubernetes 20 rack workhorse of a server. Not the case at all!!!!

Scale when you need to - if you're getting the kind of traffic where you need to, by then you won't need to worry about the added cost to do the actual scaling / upgrading.

Sorry for the winded / ranty answer, I've done this like 20+ times at this point and always had to battle against the "let's put it on AWS with kubectl and 2349023 redundant instances!", when in the long run it was never needed...

Comparing something as vast and broadly reaching as "Cloud" is a disengenous comparison to something as specific as a tool like Google Analytics, kind of a wierd comparison IMO. The entire pattern of tech is towards the "cloud" - even if you refuse to use the big ones like Amazon, Microsoft, or Google, it's still technically "cloud" if it's managed servers (wherever they may be).

To be honest I never got into the hype behind Google Analytics and I'm glad that I never spent more than 5 minutes at a time dropping the occasional tag on sites I built. (I've also never worked for anyone big enough where the analytics ultimately proved useful or valuable anyway). These tags are now easy to remove by deleting a few lines of code. I really wonder if the larger orgs really should have spent the extra few hours / weeks of development to develop an in house solution all along...

> We were doubling the size of our customer base every 9 months, and pretty soon this meant we needed more servers.

I've found that a moderately sized 4 core 'droplet' from Digital Ocean handles nearly anything I can throw at it (at least in terms of the web application world) - I see you product is doing employee management / scheduling - is there heavy compute / resources associated? Or is it more due to privacy requirements (i.e. you need a siloed instance / server per client?). Not trying to sound smug at all, just genuinely curious where the load comes from.

This is the problem however for many (older) companies. They either don't care, or quite literally don't know the infrastructure solutions out there which can save literally thousands of hours per year of headache. Sure, for many companies with legacy systems they have a "dont fix what isn't broken" mindset, but from what I've seen, I always ask, if shipping and modifying new versions of a system takes hours or even days to complete, is the system really not 'broken'? I guess I never realized it, but having automated and clean infrastructure with tests and uptime metrics is a must-have for me on anything I build going forward. Take 2-3 weeks to save months of headache.

basically, this effort ended up failing because, well, problem solving itself is inherently complex.

https://en.wikipedia.org/wiki/Fifth-generation_programming_l...

seems like the exact same thing happened with ChatGPT / AutoGPT / GPT4, and this will keep happening.

Absolutely no risk of terminator here, just ignorance masquerading as such.

Imagine thinking that a list of 20 or so items is the 'software lock' on a billion parameter language model... literally any longer than one second of thinking can tell you what the real answer is.

There's no illumati stuff going on here, just people wanting it to be that way.

Keep in mind a lot of these "AI" Twitter guys (this guy included, definitely more of the management type, NOT software engineer. Yes I know he and his team won the Boring project blah blah blah, so let's see some code that you've written - oh, 5 whole repositories on GitHub, wow, none even remotely associated with machine learning) are just snake oil goons hopping (and profiting) from the current AI hype bubble who have never actually written code for, or trained a model, or even probably know the concepts behind training or building models anyway.

Getting really sick of clueless goons around this AI stuff. Educate yourself!

My intuition leads me to believe that almost some sort of other dimensional effects are at play, and our feeble math just can't accurately describe it. Perhaps it's just the nature of quantum itself, and no special dimensional consideration is needed. It's been a long time since I studied any math or physics...

Fully prepared to be downvoted for these because I am all too aware of Python's (IMO) undeserved popularity, but the facts are clear: Python lags in performance against nearly any other "backend" or "scripting" language (compare to C, C++, C#, Go, Rust, and many more)

My reasoning: every day I see stack overflow filled with repetitive Python questions, and random finance furus talking about their cool data analysis tools, all in Python, all with poor performance and hacked together with god knows how many libraries.

The problem is indeed because Python is so accessible: anyone who can write Python doesn't know enough about computing in general to even know what the concept of performance is, let alone risks of relying on 1903287012 libraries to get the job done.

Hell, I know half a dozen companies still using Python 2... jeez

Thanks for coming to my TED rant.

It's in fact the data itself is the closest to reality, not the ML model...

It's a conundrum in the flow of reality for me:

Reality -> data that reflects reality (hopefully as best it can) -> train model based on data (typically takes a non-trivial time scale!) -> make decision / do stuff based on algo with newest data

If you ask me, even with all known technology we have, seems like it's impossible to simultaneously aquire realtime data and train a model to operate and or make decisions on exactly that data. It's a catch 22, there will always be a lag

Even as humans with super big brains we can't hope to do this outside of extremely simple tasks like "throw and catch the ball"

You don't want to rerender? Use useEffect with an empty array! Or don't use any state variables!

You want to show something new to your customers / users without rerendering? Well sorry, that's impossible, regardless of any framework you use and you should go back to UI development 101.

Bottom line: if you write clean code and are aware exactly of what your local state / redux variables are (or whatever state management you are using), you should never have a problem with too many rerenders. I've been writing React for 6+ years now and have NEVER had to reach for useMemo or useCallback.

meanwhile a post not too long ago was upvoted quite high which claimed that it's anyway impossible to prove / disprove code is "clean" or not - because it's all subjective anyway

I've commented a few times here and there about this AI hype, but might as well repeat myself: I think people largely misunderstand the technology and I see major missing aspects that are non-trivial to solve before we really get to anything looking like iRobot (or insert here any other scifi of your choice). These input / output models can only go so far, even if they are ever increasing in size. We don't just need 2 or 3 prompt memory, but full dynamic memory that the model can access throughout it's lifetime as well as the ability for the model to reflect and introspect on itself (much like human thought and communication). Without these things, an LLM will just remain an LLM, albiet larger and larger. Unfortunately I don't think size for sizes sake will bring much more improvement to such models.

Aside from any of the aforementioned breakthroughs being incorporated, I see this type of chat GPT stuff plateauing in ~1-2 years.

honestly i'll be happy when we collectively get over this lame hype