There is definitely a re-balancing of the employment market. I assume its because of capital drying up. Tech workers labor is more to build things that pay off in the long run (in theory) I think the lower minimum wage jobs tend to be more operating costs.With interest rates rising there is less capital to build stuff that will take years to pay off. More focus on just keep things going as is by throwing bodies at the problem. Im not sure. Honestly I would have thought that tech would have come in more demand as salaries rose to make the people you are paying for more efficient.
tiny hell (like tiny tower)
Instead of customers for different types of businesses (retail, restaurant, etc.) it will be souls to be tortured for different sins. Occasionally a well know politician or celebrity appears that you get to pick which torture you want to apply.
One thing that often gets ignored is the importance of getting new developers up to speed. You go to an existing C# ,node.js or Java app and its painful to twist your mind around the architecture. Ruby on Rails helps you with that. Oh db change well lets jump in to models. Oh the business logic change well jump into the controllers. Its easy to get up to speed when joining an existing project.
i love rails, but i’d point out that business logic exists all over the place in a rails app, not just in the controllers. that’s because rails has no standard solution for compound requests (those involving many models and/or multiple actions) that go beyond the simple semantics of http verbs (which i totally appreciate for what they are). some might say that’s a design issue to be worked out depending on the situation, but sometimes, you just need to do lots of different stuff in a single request context.
rails doesn’t cope with that issue very well (some suggest a command or strategy pattern, others service objects, etc.), which is one of the only major criticisms i have with rails. node/npm dependency was another big criticism, but they’re fixing that with rails 7. =)
I like creating a service/coordination layer between controllers and models to put the business logic. Controllers call the services or coordinators which can interact with models, kick off jobs, or call other services. Easy to test and change and keeps controller and model code more manageable. For smaller apps you can get away with shoving all your business logic in the models but that can become a little tough to manage as the logic becomes more complex.
I would argue fixed rate debt is your best friend in a high inflation scenario. With the cash being reinvested in staples type stocks (food and basics)
IKR. Excel and the other spreadsheet variants are the gateway drug to software development. There is no other tool that has such a low entry to barrier and is so enticing to scale up into a ridiculously complex product. It eventually does get to a point that when the original user/developer is ready to change their job someone says 'OK can we turn this into a webapp or something... this is nuts. Lets hire someone from guru.com to do this.'
I struggle with this whole article. It implies keeping a sailing ship labor intensive just with a few electric winches. Wing Sails seem like a better approach and I assume they are much less labor intensive.
You're spot on. I've followed this topic area for some years out of curiosity. Saildrone style wingsails only require a very small electric actuator to move a control surface. The control surface sets the overall net angle of attack of the assembly. The wing tracks the wind, only needing the control surface changed as the bow crosses the wind.
A system like this can be entirely labor free.
Tall ships on the other hand... I don't care how many electric winches you have, they'll always require massive numbers of people for sail handling.
Worked for a SaaS that took in sales data and generated customer surveys. There were a few things I did
1. Create an easy way for support to login as a different user so that they could see what the customer sees.
2. Created a report that figured out how often each customer sends data and noticed when they were 2 standard deviations away from their average data send. We went from customers calling upset that their data is not up to date to us calling them and letting them know that they stopped sending us data.
