420stalin69 [he/him]

  • 0 Posts
  • 18 Comments
Joined 2 years ago
cake
Cake day: November 7th, 2022

help-circle


  • Don’t forget refinement where you describe your plan to add the “height: 80pt” rule (literally what the client wants), and then poker planning where you say it will be 1 point and the lead dev says 3 points and the other dev asks what is a point anyway leading to a time consuming discussion, and then the task gets scheduled for not next sprint but the sprint after, and then you do it and push your code, make a pull request, then during code review it is suggested you use tailwind instead but your project isn’t using tailwind because it’s some legacy PHP monster started by a junior who was just learning PHP, so now there’s a POC to consider using tailwind meanwhile the lead dev (who has a background in QA) designs a reusable “height engine” which uses rabbitmq to alert all worker nodes (there’s only one) about any changes to the height rules in mongodb. The height engine doesn’t include units so you have to hardcode if the client is expecting rem or pt. The product owner asks you in sprint review why this ended up taking a week when you said 1 point initially and the team agreed on 3. A team decision is made that all future CSS rule changes require a POC prior to implementation.







  • It’s because in a capitalist or other market driven system, economic planning is decentralized.

    Let’s say trucks become really popular. There’s a lot of demand for trucks, so you can charge a higher price and make more profit. People want to buy 1000 trucks a day but only 500 are being built per day. Demand exceed supply. You’re making bank.

    Other people see that profit and want a piece so they decide to build a truck factory of their own. Let’s say 10 people decide to make a factory and each factory is capable of making 100 trucks a day.

    You’ll note this increases the total supply of trucks to 1500, the original 500 plus additional capacity of 1000.

    But these factories take some time to build so for a while everyone is happy. Slowly and gradually supply catches up to demand but only slowly. At first we reach 600 trucks per day, then 700, then 800… demand still exceeds supply so the economy is growing and we are all making profit.

    But then the rest of the factories get finished. Now we are making 1500 trucks per day which exceeds demand. Now we have a problem. Now supply exceeds demand and the price of trucks crash which means we can’t pay back the loan we took to fund our factory.

    We overinvested in the capacity to build trucks because we all wanted a piece of that profit, and as a result of over investing we have now crashed the market for trucks because we are simply making too many trucks.

    This creates a cascading effect in the economy since now the market needs to “correct” this imbalance, which is economics-speak for some of us need to go bankrupt and shut down our factories since the market only supports 1000 trucks per day but we are making 1500.

    As some factories start losing money, we lay off staff, some of us start going bankrupt which means the banks (we got a loan from to build our factories) have to take a loss. The economy is now in recession because in our earlier exuberance to chase that amazing profit we built too much capacity and over invested creating a “bubble” in the market. Bubbles have to pop to restore equilibrium.

    You don’t get this dynamic in a centrally planned economy because in a centrally planned economy we can make a more straightforward investment decision: there is demand for 1000 trucks but we are only making 500, so only create capacity for 500 more trucks. Since our centralized planning allows for a coordinated investment decision with access to full economic data, we don’t over-invest meaning we don’t create excess capacity meaning there is no need for a “correction”.

    A market based system is decentralized. Every corporation is making their own investment decisions, each corporation is trying to make and sell as many trucks as they can. A corporation doesn’t care if the economy as a whole is making too many trucks, their sole interest is to sell as many of their trucks as possible which is why a market system results of cycles of over- and under- supply.

    It’s a cycle. Capital chases profit and invests in production, leading to first a boom as production soars but then inevitably leading to a bust as capital keeps piling in chasing that profit result in over-investment and excess capacity.

    Markets are decentralized. A socialist system is centralized meaning it can make decisions that take the entire economy into consideration instead of only the immediate interests of a single corporation.

    Obviously this pretty idealized and all actually existing socialist systems have had at least some degree of internal markets and all have had exposure to markets in the form of international trade so you still see ups and downs in centrally planned economies since an economy is never fully centralized or fully decentralized.

    Also in socialist systems there is still the risk of over-investment due to bad decision making or inaccurate economic data, or eg in the USSR the economic interests of the collective farms were over-protected which resulted in something analogous to overinvestment in agriculture so there is also political risk, etc.

    So you still saw periods of economic stagnation in socialist systems but the swings are massively dampened. Also with centralized planning the state can more easily intervene to correct these issues when they arise (assuming the political will exists) which makes it easier to reboot the economy when things go awry - eg the socialist economies recovered more rapidly following WW2.

    The main drawback is that a socialist economy can be less responsive to demand. Like, if blue jeans suddenly become very fashionable, in a socialist system the economic planners might be worried that denim is a passing fashion trend and averse to the risk of over investing in denim production, whereas in a market system the corporations will say fuck it let’s make money today and let the future worry about excess supply issues not my problem I’ll already be rich.

    So the benefit of central planning is that growth is more stable and sustained at the cost of being potentially less responsive, whereas a market economy can be very responsive but at the cost of boom-bust cycles, and at the cost of concentrating enormous political and economic power into the hands of the individuals who own the factories.

    China for example seeks to get the benefit of both in a partially mixed system where consumer products and growth industries that are more likely to see rapid shifts in demand are left to private industry while the backbone of the economy that is more stable (eg mining, energy generation, etc) are subject to planning directives.


  • 420stalin69 [he/him]@hexbear.nettoAsklemmy@lemmy.mlWho's winning the war in Ukraine?
    link
    fedilink
    English
    arrow-up
    5
    arrow-down
    1
    ·
    edit-2
    10 months ago

    It was a fringe position in the Polish far-right before the election and now that the libs have won it’s even less likely to happen.

    The Polish far-right are a dominant political force.

    And it’s under the relatively lib coalition that relations have reached their lowest point.

    I think if Ukraine comes out of this with borders that roughly resemble the current front lines then they’ll keep Lviv but there’s a real possibility of political collapse in Ukraine, if things get worse and if the currently cooperating power centers turn on each other, and in that collapse scenario it becomes pretty plausible.

    probably still less likely to happen than not but it’s definitely plausible and there are multiple plausible-to-likely pathways where you can see the political situation in Ukraine deteriorating to the point of collapse.

    I don’t think I buy the current Russian narrative that the military camp are about to coup Zelenskyy but he’s definitely under enormous pressure right now, and even if a coup likely isn’t about to happen you can nonetheless see Zelenskyy and the military camp making political defense lines between each other, and the number of high level aides, spouses, and the like opening boxes that accidentally contained a grenade or suffered an unfortunate food poisoning incident is pretty eyebrow raising.







  • 420stalin69 [he/him]@hexbear.nettoProgrammer Humor@lemmy.mlI Hate It
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    11 months ago

    Yeah I would never use vanilla JS unless forced to these days. Always Typescript if I’m doing anything JS related that isn’t completely trivial.

    As for HTMX, it looks fun but I would consider that kind of fancy and fresh framework more appropriate for hobby projects or a rapid iteration proof of concept and not for production. For a start it’s just fresh and that alone means you can’t really use it yet except for more trivial cases since you need to be assured that the tool will be able to scale with your needs and it just hasn’t been proven for that yet.

    Secondly if you need to be able to scale a team then you need to either be willing to pay to train people in a new framework (and there are a constant stream of cool new frameworks so training should be conservative), or you need to be able to hire for it easily and to hire for it easily it should be a widely used framework with a deep of talent available.

    Finally it lacks type safety, at least so far as I can see, and so I wouldn’t want to use it for anything more complex than a storefront.

    I can totally see that being a fun tool to use for a hobby project and maybe in two to five years we will all be using it just like we are all using react and vue today but there’s value in being conservative in these choices when you’re looking for scalability, long term maintainability, and the ability to assemble a team.

    And finally it’s not the first js in html framework. It’s been done before and hasn’t really caught on. Maybe HTMX will be different, im not saying it won’t be the one to crack that nut because it very well might be the future who knows, but I would want to see it’s approach to be proven before selecting it since in the past js in html has tended to hit a wall. Like you can often do some really cool shit with minimal code and you fall in love but then you hit some use case that requires more complex logic and bam you find yourself either resorting to traditional JS anyway or even worse you are left stuck.

    These are general remarks on why fancy fresh isn’t necessarily the best. I haven’t used HTMX so it’s possible it will be the next big thing. Eventually something will replace React / Vue / Svelte for sure and maybe it’s HTMX.

    But that’s the rationale for considering for a hobbyist tool or a rapid prototyping tool rather than a production ready framework.

    Today for anything that really needs to scale and where SSR is desired i would almost certainly be choosing Vue or React or maybe Svelte. And if I was feeling adventurous I might use Qwik since it’s not a radical departure from those others, being a lot of the best of Svelte with some cool new ideas.

    These things move in cycles of course and clearly we need to start moving on from Vue and React soon since SSR is an afterthought in their design. But that needs to be balanced against a healthy conservativism if the product needs longer term scale and maintenance.

    I think the more immediate path forward is to get much better server side runtimes such as bun and smarter caching and bundling techniques. Bun or some other very snappy and optimized server side js engine, using html templating more than jsx components, with very smart webpack bundling and extensive caching using an islands or micro frontends architecture for progressive enhancement is a more conservative choice that can achieve a lot.

    Maybe something like HTMX will be a paradigm shift. It will happen soon enough of course. But I wouldn’t throw away a decade of tooling and development in those less sexy frameworks too easily. Not when there are less radical changes we can make to achieve dramatically better results that are still on the table that don’t require the adoption of unproven and not widely used frameworks.

    Sorry I’ve written a lot here xD but to add one more comment, for server side code dotnet is making huge strides and modern dotnet core is blazing fast now. Sure it’s not necessarily the fastest but it’s nonetheless really fast now and it comes with DECADES of proven use, a massive community, and tooling that is second to none. If I didn’t want to use server side JS it would take a very fancy framework indeed to convince me to forgo the decades of proven reliability and development that is available to me there. Plus I can say with a very high degree of certainty that dotnet will still be around in 5-10 and probably even 20 years from now while HTMX has a high chance of disappearing to another fresh faced sexy framework in the near future.

    My apologies if this was too long or repetitive :)


  • 420stalin69 [he/him]@hexbear.nettoProgrammer Humor@lemmy.mlI Hate It
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    11 months ago

    If rapid iteration is more important than performance or cost then you can more easily have a monolithic-ish build system that creates the client and the server from a single code base, or with shared code between them.

    If you are trying to upgrade frontenders to be fullstack it’s an easier entry point.

    Sometimes the performance characteristics of node actually is useful for serverless since a cold start and a hot start are not very different, closer to a fixed cost just to run a script when compared to something like dotnet which has slow cold starts but fast hot starts. Which is also why it sucks for most server code but on occasion this can be a useful characteristic.

    If you want to do serverside rendering with client side hydration then it can be handy to implement the display logic once and run on both the client and the server (eg server side rendering react or vue etc)

    Those are a handful of decent reasons but broadly speaking agree, it’s not the best choice if you care about cost and the benefits in the specific cases above are either rare or short lived.

    Except really for SSRing with client hydrarion, that’s really the slam dunk case where it’s the more often than not correct choice due to the advantages of not duplicating logic.

    The real reason why I often use server side JS is that it’s just faster to write in the first instance if I need to spin something up real quick or for infrequently invoked code where performance and cost don’t really matter. Of course for anything serious it’s a bad choice.




  • You have a drink in your hand, you go “oh hey it’s Alex how have you been man?”

    Alex tells you about his new hobby.

    You gesture to your friend “hey Alex have you met Jamie?”

    Alex and Jamie get to know each other.

    Rinse and repeat.

    Jamie meets a friend and starts chatting. You awkwardly stand beside Jamie taking sips of your beer until Jamie says “hey Andrea have you met my friend 420?”

    You introduce yourself.

    After a while everyone has met and had a few drinks and some good music starts playing and you start dancing in the dance floor. At first it’s very self conscious but after several songs and another drink you start vibing.