> 1. For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.
That said, right now the industry is going through some turmoil. We're coming off the high of low interest rates, and it's turning into a mighty hangover. Plus, we're trying to automate ourselves away with AI, and (working in) tech just isn't fun with Scrum/Agile/Meetings/Sprints/Bluh.
Different incentives. A publically traded corporation with thousands of workers trying to grow in perpetuity, has different goals than a community project. While the former has more resources, the latter is more mission driven.
if you have a task that is easy to split, make a python script that runs on a subset of the task, split into N subsets, and write one output per process? Once they all complete, join together the outputs. Maybe https://docs.dask.org/en/stable/ is a good start if you want a framework. I don't think there's a consensus, it depends on the problem.
The software support just isn't there. The drivers need work, the whole ecosystem is built on CUDA not OpenCL, etc. Not to say someone that tries super hard can't do it, e.g. https://github.com/DTolm/VkFFT .
What's even better is that net zero isn't doing anything for _already emitted carbon_, or the already accumulated heat energy. We can get to net zero and average temperature is still going to keep rising.
These vectors are lower-dimensional than traditional vectors though, aren't they? Vector embeddings are in the hundreds to low thousands range of dimensions (roughly between 128-1024), whereas TF-IDF has the same dimension as your vocabulary. It's also not just about being flat-out better, but about increasing the recall of queries, as you're grabbing content that doesn't contain the keywords directly, but is still relevant. You are also free to mix the two approaches together in one result set, which gives the best of both.
User/Item/Query embeddings are the most common. That way you can generate per-user recommendations, or search results for a given query (with personalization using side information). Video will be interesting, once we have video embeddings (maybe this exists already). It depends on the use-case but a few of your ideas are certainly possible. Generally I've seen them at a coarse rather than fine level, but I'm sure that's out there too.
IMO there are many Americans who would work in IT/Tech if you paid them to do it, but the risk calculation doesn't currently make sense. If you're an adult making $25-35/hour in your current job, just meeting rent/utilities/obligations, it's hard to accept going back to school for several years to complete a Bachelor's degree, with zero guarantee of employment, but a definite guarantee of debt on the order of ~60K (taking a cheaper option). This is also true for those lower on the socioeconomic totem pole, whose parents are not going to pay for them to go to school. We've seen the result of making student loans widely available, there are many under-employed Americans in debt.
Numerically I agree with you, the debt load is worth the risk, if you're specifically going for software/IT, but the risk is not zero.
Perhaps more precisely: the defacto Apache-as-runtime + PHP model simplifies a ton of things. Namely your request state is created and destroyed all within the context of a single process, and you don't have to reason about shared state with other in-flight requests (unless you explicitly choose to go this route). It makes some bad programming patterns workable, because your state doesn't linger over a long-running period. Deploys are also super fast, you just have to swap the application code on disk and it'll get picked up on the next request (in-flight requests will keep processing with the old version IIRC). It's productive if not necessarily pretty. Also it has a type system now!
As a related thought, a lot of the modern serverless stuff feels like it's reinventing the ideas of Apache + PHP, or perhaps CGI?
PHP has some excellent ideas that other languages can't replicate, while at the same time having terrible ideas that other languages don't have to think about. Overall a huge fan of modern PHP, thanks for this writeup.
Yes, things are worked out pretty well, in the end it didn't take long to find _something_ as a dev, but I think early next year should be a good time to apply to "good" companies. In-network people are telling me things are frozen where they're at, and to wait for Q1 next year.
Get a few RPis and get https://k3s.io/ running on them. Get familiar with kubectl. Deploy a few apps to your cluster, tail some logs, restart containers, scale them, etc. Install Prometheus, get monitoring working, make some dashboards with Grafana. This point is to gain familiarity with "modern" cloud infrastructure, but in a low stakes environment where nothing can go wrong. Then, you can talk about your experience, and it will technically be true!
if you apply to roles within finance you'll have a better shot of landing something. Also, do a quick project using k3s and / or docker to get the basics, so it sounds like you know what you're doing. You can be creative with the truth.
You'll need to send much more than 12, try 2-3 a day for a month. Of those, maybe 5% will reply, but it's not bad that bad once you get into the swing of it.
Yeah I've noticed we've done an about-face on degrees in industry. It used to be super legit to drop out. As things get more specialized MS and PhD are seen more favorably now.
Referrals are also not a golden ticket right now. Got a few tossed in the bin, we've got a lot of FAANG engineers on the market right now, companies are scooping them up at bargain rates.
I was in this boat a few months ago, doing a lot of exercises on leetcode legitimately helps, because you can quickly type an ~80-90% solution immediately from memory, and you have a lot of time left over to finish the remaining portion. It also looks super impressive from the hiring side.
RE point 1: in the actual job these days, we're coding through so many layers of distributed madness that you end up doing YAML/JSON engineering and gluing systems together more than anything, for years on end. A lot of "software engineers" are not writing software, or engineering. Candidates will have to brush up on the basics, because it's been so long. An anecdote: explicit for loops were banned from a codebase I worked on, only interior iteration was allowed. I too, forgot how to use for loops. I spent quite some time writing in embedded YAML DSLs as well (complete with static analysis and compiler).
RE point 2: after sending out a lot of applications, you tend to forget the specifics of where you applied, sometimes companies reach out after weeks or months, and everyone wants 3-5 rounds of multi-hour interviews, so it all becomes a blur. Maybe spreadsheets or a CRM would help candidates here. There is no excuse on the candidate's part for not brushing up before the interview though.
RE point 3: very fair, candidates should jot down a few good questions to ask beforehand.
It's crazy on both sides, not sure how to fix tech hiring. Somehow the industry soldiers on.