srhtftw

https://www.copyright.gov/circs/circ33.pdf

> ... aa recipe that creatively explains or depicts how or why to perform a particular activity may be copyrightable. A registration for a recipe may cover the written description or explanation of a process that appears in the work, as well as any photographs or illustrations that are owned by the applicant. However, the registration will not cover the list of ingredients that appear in each recipe, the underlying process for making the dish, or the resulting dish itself.

While their FQL looks useful, I can't imagine using a SaaS-only proprietary query language in this age for anything other than a research proof-of-concept to learn more about my problem before building a real product on an open platform.

Curious that Bob Muglia (ex Snowflake) is on their board. I believe he's also on the board of Relational AI which is another SaaS with an interesting but proprietary query language. Snowflake is a huge success in spite of being proprietary because its SQL isn't hard to learn or use, but I can't say the same about rAI. Makes me wonder how they will turn out.

¹ https://jepsen.io/analyses/faunadb-2.5.4

The problem is on-call is an essential and critical part of a managerial role, but toxic to those in a developer role.

Managers must be on-call to ensure the appropriate people and resources are brought to bear on unexpected problems that threaten the business.

Developers must NOT be on-call to ensure appropriate attention is spent designing, developing and maintaining the code that makes the business possible.

The rise of software-as-a-service led to companies promoting "devops" engineering which conflates these roles and unfortunately helps unscrupulous executives unfairly squeeze more work from employees.

The core idea of devops, that managers/operators and developers should understand and be capable of performing each other's role, isn't a bad one. Those who understand how the business works at all levels can do more to make it successful. It goes hand-in-hand with continuous delivery.

The best engineers alternate between these roles in a predictable schedule. When in the managerial role they need to observe, react, delegate and escalate problems as appropriate. When in the development role they need to deliver features that create recurring value for the business.

But businesses should not expect engineers to play both roles at the same time!

This form of "on-call" is a toxic moral hazard. It's a sign of instabilty. It's a signal of executive grift looking for a quick pop. "on-call" robs developers of attention they need to develop the features and increases risks that schedules will slip.

It doesn't need to be this way. If a business needs software development it should hire or train engineers with that experience. Likewise if it needs managers or operators to deliver software as a service.

As an operator or manager I look forward to working a shift, but as a developer I will never again accept on-call rotation.

¹ https://news.ycombinator.com/item?id=42230215

¹- https://github.com/jmforsythe/Git-Heat-Map

²- https://www.win.tue.nl/~vanwijk/stm.pdf

* Your perfect tech stack exists only in your comments - a beautiful utopia where everything is type-safe, reliable, and nobody is ever on-call.

* You evaluate programming languages the way wine critics evaluate vintages: 'Ah yes, Effect-ts 2023, a sophisticated choice with notes of functional purity and a robust type system, though I detect a hint of API churn in the finish.'

ROFL :-)

These weren't his last words, but Jim Gray had this to say about this so-called "antipattern".

Queues Are Databases (1995)

Message-oriented-middleware (MOM) has become an small industry. MOM offers queued transaction processing as an advance over pure client-server transaction processing. This note makes four points: Queued transaction processing is less general than direct transaction processing. Queued systems are built on top of direct systems. You cannot build a direct system atop a queued system. It is difficult to build direct, conversational, or distributed transactions atop a queued system. Queues are interesting databases with interesting concurrency control. It is best to build these mechanisms into a standard database system so other applications can use these interesting features. Queue systems need DBMS functionality. Queues need security, configuration, performance monitoring, recovery, and reorganization utilities. Database systems already have these features. A full-function MOM system duplicates these database features. Queue managers are simple TP-monitors managing server pools driven by queues. Database systems are encompassing many server pool features as they evolve to TP-lite systems.

https://arxiv.org/abs/cs/0701158

https://pastebin.com/fnf4CeBM

¹ https://www.tampermonkey.net

Well, having relied on a similar product (Carbon Copy Cloner) to keep a bootable backup in addition to time machine backups for myself and members of my family to reduce MTTR for many years, I find the idea of being unable to trivially recover from a hardware failure in a few minutes to be defective.

Any of our clones can be booted on any similar system. On a few occasions people have used borrowed machines until repairs were complete without relying on cloud or internet connectivity. Of course these are all older systems and working while booted from an external drive is definitely a degraded experience akin to driving on a spare tire until you can get to a proper service station.

There's a lot I like about Lua but it so happens that a few days ago I spent longer than I'd like to admit debugging a trivial typo for Advent of Code day 5 that would have been caught by this.

Wondering if Luon will also prohibit or at least warn about storing nil in a table.

I've held several management positions where I've carried a pager. At one employer I helped keep trading databases operational in 7 time-zones on 3 continents. At another I helped fix a backup issue on Christmas eve. Helping those customers was a core part of my responsibility. I fully understood that and took great pride in it.

But as a developer I too will never accept another on-call rotation.

Companies which assign on-call duties to developers make the mistake that development, management and operations are different kinds of work which require different environments and skill-sets. Other engineering tasks include testing, documentation, training, and maintenance. At small startups the founders and early employees may do some or all of these but that becomes impractical at larger established businesses.

Engineers should learn and do all these things in the course of their career but not all at the same time unless quality isn't a concern.

My experience at a unicorn a few years ago convinced me companies which assign developers on-call rotation either don't understand or don't care about the quality or sustainability of their business. In that company senior management was replaced by folks from Google and Facebook shortly after I joined. I was moved into a team where I had no role in the design, develop or deployment of its services. I had no say in the hiring or firing of the so-called engineers who rushed failing services into place past a wholly ineffective QA department.

I should have seen the writing on the wall when I began to be pressured by managers and recruiters to rubber-stamp candidates who couldn't pass our coding tests but had spent lots of time on-call. The company's priorities slowly became clearer to me as they grew evermore desperate to live up to their promises. Ultimately I suffered an ischemic attack from the stress of this environment and left the company to focus on my health.

Oh and the company? It let go of most of its engineers a year later and was eventually acquired by competitor for a few hundred million after having raised over a billion dollars.

¹ https://en.wikipedia.org/wiki/Prince_%28software%29

   Where lies the land to which the ship would go?
   Far, far ahead, is all her seamen know.
   And where the land she travels from? Away,
   Far, far behind, is all that they can say.

   - Arthur Hugh Clough

To me it's a signal the author either doesn't care about the overall quality of their post, or doesn't know or care that it's no longer special.

Which may be fine for some kinds of posts but not a good look for anything significant.

That said, the person who built the ZIO project which inspired Effect-ts is now working on an exciting project called Golem Cloud¹ which aims to provide durable and reliable location-transparent execution of Wasm programs.

Mike Stonebraker's DBOS² looks to provide something similar for Typescript.

¹ https://github.com/golemcloud

² https://www.dbos.dev

It's great for workflows with clear points in the logic where things should happen and it provides more sophisticated (i.e. powerful but harder to master) tools like Fibers and Streams which allow you to reason about failure cases of reactive asynchronous operations. In many cases it offers a clear path out of callback-hell that is more reliable than promises and async/await.

However while the Effect-ts docs are getting better and may be ok for people with a good knowledge of functional programming and Typescript, they are nowhere near the quality they need to be for those who don't. People looking for examples online will get frustrated because Effect API churn over the past three years has made many old posts and articles obsolete. Old github repos won't work out of the box. And you better be comfortable with codemods if you haven't frozen your Effect-ts version.

Fortunately the Effect-ts Discord channel is full of friendly and helpful people and the Effect team provides high quality assistance to people who ask for it. It makes me sad this treasure trove of information is trapped in Discord where search is of little value.

A good book or collection of high quality examples of how to use Effect-ts with de-facto standard frameworks like React could help its adoption grow significantly.

It's unfortunate OP wrote plenty about their displeasure with the candidate but failed to tell us anything about their role in the hiring process, how well the job description matched the actual job requirements or how HR got the impression it did.

But the situation as described strikes at a reason I've left previous jobs: the feeling that I couldn't trust the competency and integrity of those I worked with.

Like the time our in-house recruiter presented me "resumes" they fabricated from linked-in profiles of people they wanted me to interview but who hadn't actually applied to our company, or the time I was pressured give passing reviews to candidates who couldn't pass basic programming tests from managers eager to hire loyal toadies.

A small outfit with a focus on personal development, intrinsic motivation, good climate, and low turnover can't afford incompetent or perversely motivated HR people who "hire at any cost" candidates with mediocre reviews.

A few years ago my wife and I took an Amtrak from Oakland to Chicago with a brief stop in Colorado to visit a hot spring. We weren't impressed with the menu on the first leg of the trip so we bought take-out meals in town before boarding. Boy were we lucky we did - the train didn't get restocked properly and ran out of food a day early. Many onboard got to enjoy some intermittent fasting...

Now I tell people to by all means enjoy Amtrak but always make contingency plans.

Surprising that creating a whole new language made more sense then a backend. I wonder if they did a proof of concept with an existing logic system like Souffle¹ or Rel² first.

¹ https://github.com/souffle-lang/souffle

² https://relational.ai/blog/rel

    visidata - https://www.visidata.org
    just - https://github.com/casey/just
    ripgrep - https://github.com/BurntSushi/ripgrep
    macports - https://www.macports.org
    sloth - https://github.com/sveinbjornt/Sloth