hcrean

Running your own private discount web hosting used to be fun and lucrative, less so with AWS nowadays and it takes time to build up a customer base. Still fun though.

Short term project contracting is what got me out of my burnout. As did learning music on the side and just treating work like a day job rather than a calling.

You can also probably speak to some recruitment consultants about pitching you to companies as part time. So much work going one is bound to be happy with that.

And you can complete this task remotely...

Monkey troops that have not yet entered their stone age are domesticating dogs [https://youtu.be/U2lSZPTa3ho]

It stands to firm reason that this symbiotic living was reached by humans at a similar point in our development.

Are you saying that our justice system is un-scientific? lol

A silly-string canon is likely to be highly effective against most propeller driven drones. Safer for the people under it too.

Regarding (2.) The gimbals on DJI drones are actually crazy good! As is the flight stabilisation and on-drone EIS. They make sub-millimetre and sub-arcsecondary orientation corrections every couple of milliseconds.

When you put these all together you find that you rarely have to stabilise footage in post.

python3 -c "import pyotp ; print(pyotp.TOTP('<MY_TOTP_2FA_SECRET>'.lower()).now())"

This is a bash one-liner that takes the place of an RSA/2FA token/AuthyApp

If they had been wrong it would have catapulted humanity forwards in understanding. Instead it just affirmatively ruled out a big class of future mistakes...

The Google SRE books are good, they cover most of the major things. There are then lots of books on specific tooling you might want to use. This is not a one book subject!

DevOps should really mean "Someone who builds systems and pipelines that allow developers to more seamlessly and sensibly deliver value to the end user".

What DevOps actually means in practice is "We had someone without any operations knowledge build a system before someone with the correct design skillset arrived, you can't remove it or change it because it is business critical, your job is now to maintain this like a classical Sysadmin would".

(I have been an Ops/DevOps engineer for slightly more than 15 years)

This is a late stage cause. There are also many early stage causes.

If you are in FOSS for the money, you are not in FOSS.

Humanity could be sat around eating fruit and making art, instead we have mortgages and credit scores, because the venal systems corrupt and extortionate the progressive ones.

So the correct solution is really to pre-approve dependencies and store them in a local PyPi. Defence, Medical and some other high-sec industries do this as a matter of course. The problem with this approach is the amount of security toil required to vet packages is large, generally too large for most companies to buy into.

So one solution I see in the wild a lot is to prefix your company packages with a company identifier, then to set proxy rules to prevent fetching these from public PyPi (often these are set directly on the private PyPi and all traffic is directed through it).

Having been an agency pentester, I can tell you that given access to one company package (Open Sourced?), you can correctly guess the package structure, naming conventions and internal build infra of the company 90+% of the time.

I wonder if the target of loglib-modules and hkg-sol-utils is a specific company running its own internal PyPi server, or something like a scientific collaboration (which can be thousands of people and billions of dollars, especially in the drugs discovery domain).

PIP is designed to treat all indexes as mirrors, rather than to specify the source of a package: So a higher package version of an internal package name would be chosen whether it is on public or private PyPi. Equally a certain percentage of the time it would choose public over private with the same package version.

This kind of comment is why I read these sort of things: Elegant but unexpectedly simple solutions.

I started in CPP and now mostly write Python. Honestly, it is just so much easier. Gone are the insane number of helper functions and custom types you have to wade through to make a tiny change. The reality is that boundary-level checking is all done with validation libraries (like Pydantic) anyway, and invalid types traversing an interface between sections of the codebase, in an unexpected way, happens so infrequently as to be almost a non-issue.

There is an equation governing fatality along the lines of:

D% = A% * F%

A% = Chance of getting into an accident

F% = Chance of a given accident being fatal

D% = Chance of cyclist dying in a given time period

There is a possibility that the increase in A% caused by wearing a helmet is greater than the corresponding decrease in F%, in this case it is indeed safer not to wear helmets. To justify this there would have to be some VERY conclusive statistical evidence support both sides of the calculation, or the company will open itself up to a massive lawsuit the first time someone has an accident.

Having 1600 applicants for a SE role is not a unique, but definitely a very niche, problem to have...

I had been programming for over ten years when I first ran into FizzBuzz, suffice to say I failed the exercise and wasn't offered the job. So I just moved onto the next interview and passed that one.

Sure, you can't prove that finding subcycles in a directed-graph is an NP-Hard problem on a whiteboard, or implement a linked-list or invert a binary tree by hand: But what you have is hard-earned common sense and a meaningful understanding of how software evolves over time. This is valuable to any company and many have identified that they are in desperate need of it.

Don't tell the IMCF that medieval times have ended, they will laugh at you.

At the point you feel they are being rude, you know you don't want to be dependent on them for your income. There is nothing more to do here but waste everyone's time.

This is the core truth of the situation. Be gentle with how you tell them this; but not telling them, or letting them believe something else is fundamentally dishonest.

I have just finished three years of beating a department of 50 developers into breaking up a fifteen year old mono-repo. The rewards have been quite considerable.

Mono repos come with a particular challenge: If you have five projects {A,B,C,D,E} in the same mono-repo, you definitely do not want to be building B,C,D and E every-time someone commits code to project A! This is unimportant at small scales, but as the team grows, building and continuously deploying 'all the things' on every commit just doesn't work out.

So the first naive solution is say "we can enumerate all the things that need to be built for project A". This rapidly breaks down when someone figures out they can abstract a shared dependency for A,B and D into some other part of the mono-repo.

So now we enter build dependency tools, first Make then some other flavour, then we jump straight to Bazel because someone read about it in a Google publication, then to some custom build scripting because Bazel didn't do this hyper-specific workflow thing someone wanted... In the end maintaining a mono-repo build process becomes a hyper-specialised job function that is almost always kicked to the wayside.

In small companies, fewer developers than you can count on your fingers, or truly huge Googles that have their own VCS flavour, it can be shown to work well: But I have yet to hear a story of something in the middle succeeding with a mono-repo.

What are you specifically looking for someone to do?

Or is there just a correlation between truthfulness and usefulness of a model...

A saying normally attributed to Churchill: "If you are not a liberal in your twenties you have no heart, if you are not a conservative in your thirties you have no brain".

Toppling the federal government would be easier; people don't like that much, people however like Facebook.

His point is that Ops time is more expensive than Dev time, they get paid more. The Dev teams should really fix their own bugs if they happen in the wee-small-hours.

If a company is having trouble recruiting, it normally means the package on offer just isn't competitive. Remote work and money are the big ones nowadays. It might also mean your company is unattractive to engineers; location, negative reviews, difficult tech stack, business model based around clubbing baby puppies... Whatever it is.

I have led Ops teams in one shape or another for about 10 years. I second that having a junior dev do Ops work without supervision will not bring joy to your life, mostly because they do the darnedest things! One of the trainees here decided to remove a ControlTower guardrail from a root account, for a personal experiment in a sandbox; then three weeks later created a public S3 bucket in a production subaccount and leaked a bunch of data...

90% of developers just don't have the mindset for Ops work.

A sysadmin team leader walks into the room and says, "Everyone, you are now DevOps engineers, carry on", and walks out to collect a bigger paycheck...

They should sue the fact checker rather than Facebook; easier and this will likely have the same impact on the fact-checker market.