webignition

"just"

How many zeros?

For my setup, absolutely none of it! Wholly incompatible with what I have.

My original question was purely hypothetical and not a practical consideration for me or, probably, anyone else.

A bit of a tangent, but do you mind saying what you pay per kWh?

I'm currently on £0.36 GBP per kWh (about $0.45).

Just wondering what counts as cheap!

I'm in the UK, a small town in Wiltshire.

The town I live in is bisected by a MOD railway and, from what I understand, permission was never granted for whatever was needed to supply natural gas on my side of the tracks. This rules out some of the more common traditional heating systems found in these parts.

We bought the house ~two years ago. The building itself was (and still is) quite sound but was a wreck in terms of features (no heating system at all, no flooring at all, and in terms of a kitchen and bathroom facilities it was quite ... minimal).

My partner had long hoped for underfloor heating downstairs as she loves the feel of walking on warm flooring. I have to agree that it is a delightful luxury and we don't otherwise have too many vices.

Direct electric underfloor heating felt like the least hassle in the long term and the easiest for self-installation. The alternative was a wet underfloor heating system (water filled pipework set in screed). The wet system is capable of leaking and eventually failing with expensive repairs, the electric system less so.

We use infrared wall-mounted heaters upstairs. As far as direct electric heaters go they're quite efficient. They heat the objects in the room rather than the air and it feels like the warmth of the sun on your skin.

I agree wholeheartedly that heat pumps are a more efficient option and could indeed be used as a direct replacement for our upstairs wall-mounted heaters. This is something we hope to put in but was not previously affordable when we were re-working the entire of the inside of the house from nothing.

As far as I understand, we would need a wet system for underfloor heating if we were to utilise heat pumps and at this stage that would be a prohibitively expensive re-work of what we already have.

Hopefully roof-mounted solar and a battery of some sort should even out the costs a bit.

I live in a house house exclusively warmed by electric heating (underfloor downstairs, wall-mounted upstairs). The heating system takes electricity as an input and provides heat as an output with no other direct benefits. As a whole the heating system can be quite power-hungry during cold periods.

A crypto mining rig takes electricity as an input and provides heat as an output with the possible benefit of creating some valuable digital assets. Serious crypto mining setups can be quite power-hungry.

Crypto mining for the sole purpose of making money is often considered an egregious and possibly wasteful use of power resources.

Is crypto mining for the purpose of using the heat to warm my house, with the possible benefit of generating valuable digital assets, similarly egregious, wasteful or inconsiderate in some way?

I'm left handed and have always used the mouse with my left hand.

The tilt on the cursor has never seemed odd or wrong or strange to me in any way.

I've been using computer mice in one way or another for more than 30 years and perhaps a lack of oddness comes from having so very much gotten used to it. Maybe newer left-handed mouse users would find the cursor tilt strange?

I work as a software developer but once trained as a barista when considering opening my own coffee shop. I can offer some fact-based reasoning as to how different coffees have the capacity to taste different (whether people have the capacity to discern the difference is another matter).

The dominant factors in the flavour of coffee comes from the preparation, both the roasting and the brewing.

Roasting reduces the acidity of the beans and draws out oils towards the outer surface. Both the acidity and oil content of the affect the flavour, with the acidity directly impacting bitterness and the oil impacting the smoothness.

The amount of total acidity contributors and oil contributors that are drawn out of the bean when brewing are a direct function of water temperature, water pressure and duration. Too low a temperature and the resulting drink is more akin to watery coffee dust. Too low a pressure and you get sort of the same results.

An ideal temperature and pressure combination, given a fixed duration (let's say 30 seconds) draws out enough of the oils to balance the acidity to get a good strength coffee (optimal bean to drink yield) that doesn't taste horrid. The acidity takes longer to draw out such that too long a duration results in a more bitter (and generally less acceptable) flavour.

That's a rough overview meant only to highlight that it certainly is possible, from both roasting and brewing, to significantly alter the flavour of coffee. I've oversimplified for brevity.

But can differently-grown beans of the same type affect flavour?

I don't grow coffee beans but I do grow tomatoes. From personal experience, the length of growing season, the amount of sunlight and the average temperature across the growing season affect the quality of the fruit. I find the same for sweetcorn, squash and many plants that grow above ground.

I don't think it is a stretch to suggest that the same factors have the capacity to impact the oil content of coffee beans if nothing else.

If growth conditions impact the oil content of the beans and the oil content of the resulting drink impacts the flavour, it seems plausible to suggest that the growth conditions can impact the flavour.

My main dev machine is the same age and is similarly chugging along just fine. Cost £1400 in 2012.

It has no moving parts and I hoped this could lead to it lasting well beyond what I would normally expect.

Regardless of part wear, or the apparent lack thereof, it feels to me as performant as the day it was born.

It's a security matter more than a performance matter, although improved performance is a nice side effect.

For assets served from a third party (a CDN), you don't want to send cookies that might include secrets (a session cookie that could allow access to a user's account for example).

You can trust that a third party won't intentionally log or make use of any sensitive information in cookies but you can't guarantee it. Best not to send it at all.

Might lab-grown diamonds have reached a point of being indistinguishable from natural diamonds such that people pass off lab-grown diamonds as natural diamonds without anyone being able to tell?

In my experience, the usefulness of live chat features varies wildly.

If the live chat service connects me to a human who is able to resolve my query in a timely manner, I'll take that any day.

Phoning a large company can result in waiting in a call queue for a long time. My attention is on the phone call instead of anything else. A live chat window can be relatively ignored and checked once in a while.

Emailing a large company can result in waiting for a reply taking 3-5 business years. Live chat gets me a response relatively quickly.

A live chat service that does not provide an easy means of interacting with a human and which instead easily allows getting stuck in a bot loop is a great example of poor customer service and, for me, a great way of quickly finding out who to not do business with.

That said, a poor live chat service for a business that I absolutely have to contact (most recently when terminating internet service after moving house) is an exercise in frustration and annoyance that is hard to replicate in any other manner.

I left a non 5 star review of an inexpensive Pixel 4 case. The case was too close around the flash resulting in the flash reflecting off the case resulting in absolutely awful pictures.

I was offered a refund and replacement of a newer version of the case in return for a better review.

The phone case was simply not fit for purpose as it was and the review fairly (I hope) highlighted this.

I accepted the replacement newer version and agreed to a more flattering review once the improved case was seen to indeed be improved. If the flaw had been fixed then it would be fair to reflect this in my review.

The improved case was no different and my review remained unchanged, except for an update reflecting the bribe.

I agree with the sentiments regarding the use of low-code/no-code tools for general purpose programming.

I'd like to present a specific use case as an example of how domain-specific no-code tools can help.

I'm developing a tool for automated browser testing. This fits well into the description of being no-code and is being developed as an alternative to writing C#- or Java-based browser automation tests in Selenium.

The "code" that you write is more akin to configuration that defines what page elements you want to interact with, how you want to interact with them and what you expect to happen. There's more to it than that, but this is not a sales pitch.

My project is in direct response to the experiences my partner encountered when providing browser automation training to manual testers within businesses.

Browser automation testing requires, in broad terms, a small subset of what is offered by C# or Java, however a significant understanding of and familiarity with matters such as objects, variables, sane naming and debugging is required to even begin reaching competence.

Many manual web testers, who were very capable, were just not able to grasp coding matters sufficiently. Many were, but plenty were not. For those that barely could, I feel for the people who have to maintain what would then have been created in their businesses.

Programming that requires only a subset of a general-purpose programming language has the capacity of being implemented in a no-code tool if the scope of the programming needs are narrow.

Yes, this is what I'm currently doing with a cloud-based website automated-testing system.

In my case, code supplied by the end user is compiled into a different language such that I think I can prevent intentionally-malicious activity.

Nonetheless, spinning up a VM to create an environment in which potentially untrustworthy code is executed before then destroying the VM seems the safest option.

Wood will not self-combust until reaching around 300°c. Hopefully that temperature is never reached.

What are the memory leak problems?

I was under the impression that PHP's stateless nature, with a whole new instance of everything coming into being for each request, somewhat sidesteps the capacity for problematic memory leaks that could otherwise exist for processes that remain alive between requests.

I'd think that such a solution doesn't solve but merely moves the problem.

A method with N arguments, where N > 2, with a call that is messy due to the number of arguments could instead take a single argument being a parameter object where the constructor for the parameter object takes the same N arguments.

A constructor with N arguments with a call that is messy due to the number of arguments ...

Side tangent: is it all seafood that you dislike?

My girlfriend finds all forms of fish and seafood distasteful - fresh water fish, salt water fish, shellfish, the lot. In almost all instances she finds it nauseating, even the smell from a distance.

I've not previously encountered anyone with such a broad dislike for seafood. I'm curious what your experiences are.

I'm full stack. I see what you're saying and I think that in some (many?) cases your impression is correct.

In my last job, I entered as a frontend developer and moved into more backend work in addition to frontend work. There was strong engineering vigour, rigorous code reviews and careful coding standards to ensure consistency. I'd like to think I was competent across the field and at least equal to my peers but that's not for me to judge. My peers and those to whom I reported were very pleased. This suggests externally-verified competency.

I find it better to enter as either a frontend developer or backend developer and then demonstrate internally competency at both rather than trying to sell yourself as full stack from the outset.

It helps to have been developing web-related software for the past 25 years. Over time you learn new things because they fascinate and interest you.

Recognisable competency throughout the stack is achievable by anyone with enough curiosity to explore combined with enough experience to know how little you actually know.

Whilst the classic Nespresso machines have potential recycling issues, the vertuo line of machines/pods are more favourable.

I was recently given a second-hand Nespresso vertuo machine and I'm very happy with the re-use options.

There are stainless steel refillable pods as well as single-use film lids to apply to emptied pods.

I'm giving the film lids a go first as the stainless steel pods are quite pricey (around £20 each).

I'm able to re-use the pods that came with the machine, refilling with the large supply of ground coffee that I receive as gifts and would otherwise use in a cafetiere.

My stash of bagged pre-ground coffee produces excellent results in the vertuo machine with a good crema on top as good as most coffee shops that I've been to.

With some freshly-ground good quality coffee, a re-usable vertuo pod or two and a vertuo machine you can make barista-quality coffee with zero non-degradable waste.

Is that unusual where you are?

Over the past few years I've seen the odd pheasant within ten minutes walk of the centre of Basingstoke as well as the occasional deer sprinting across the ring road dual carriageway.

Hopefully we all get to see more wildlife as life quietens down a little and, at least in the UK, we can be sure not to encounter anything even remotely dangerous.

Your email doesn't appear to be present in your public profile that I can see.

I certainly feel your pain when it comes to non-modular linear end-to-end scripts.

The DSL I'm working on is already quite modular so as to reduce repetition, to hide complex-looking things like CSS selectors behind user-defined names and to support the definition of data sets independent of the tests that use them.

A test for a given page can import test steps, adding further actions and assertions if required and injecting one or more sets of data over which to iterate.

Sets of data can be defined inline (to support quick learning) or defined in separate files and imported and referenced (more ideal).

Properties of a page being tested can be defined separately to the test itself, including aspects such as the URL and named locators expressed as either CSS selectors or XPath expressions, referenced later as needed by the user-defined name. This reduces to one the number places many page-specific details need changing, as well as allowing the tests (which reference by name pre-defined locators) to flow more naturally.

I'd greatly appreciate your feedback in a few months when we have something workable to demonstrate. My email is in my profile if you're happy to help.

Being in the UK myself, I'm curious about this.

Does Octopus provide the price of electricity at the current moment?

I had a quick look at their website but couldn't see anything obvious.

I'm currently developing a test automation DSL as part of a full automation service.

My partner worked for some time running on-site test automation courses. This was for organisations where the devs were average 9-5 workers without any passion for software development. Not the sort of places that would ever feature on HN.

Manual testers transitioning to automation testers within such organisations are, in most cases, fully incapable of doing so effectively.

Such testers cannot learn to code. Many could barely type with much proficiency. All were great people and great at manual testing, but coding was generally not what they were wired for.

There is a market for something easier.

It took me some time developing a plain-English DSL to realise myself that the majority of browser automation coding isn't coding.

You can abstract away the hard parts. What you're left with is not coding but configuration.

Given the right automation system you don't need to write code to define your tests, you instead need to configure the system to test as needed.

A DSL to replace current automation coding as-is is indeed an odd task.

A DSL for a minimal-grammar configuration language within an automation system can definitely work.

Will it work for everyone? No, absolutely not. Not you and not many who read HN. We're the outliers.

Will it work for boring dusty companies that we've never heard of and which can't afford to employ people who read HN? Yes, definitely.

I think your message asking for such advice is itself of a suitable length where the problem is clearly stated without deviation or distraction.

Taking your message on it's own, you have the ability to keep the message size small.

Keep to the point, avoid distraction, stay focused, replace three words with two where two will suffice, replace two words with one where fitting. Omit needless words, make each word count.

I have seen first hand that they do, not that I wish I hadn't.

About 20 years ago I stayed for two weeks on a rural rice farm in Goa.

The toilets fed directly into the pig sty. Very directly down a short chute add though a hole. An eager pig snout poked through the hole could make contact. Never before nor never again have I been so startled.

Except when a curious child flips the switch when the PC is running.