Hacker Newsnew | past | comments | ask | show | jobs | submit | more PanMan's commentslogin

Quatt.io | Amsterdam, Netherlands | Full-time | Hybrid/ONSITE | https://quatt.io | climate tech

I'm head of Software at Quatt, a quickly growing scaleup building heatpumps to help fix climate change. Heating and cooling is 50% of all energy used in the EU. Heat pumps save 10 times more CO2 for each Euro spent on them compared to electric cars. We're building the most accessible and smartest heatpumps on the market. Our first product is live, the next ones announced, we have thousands of customers, tons of data, and I really like the impact we're having. We also just raised €25 million for further expansion. I’m currently looking for a few roles for my department, as we believe having the best software will allow us to have the best product. Our backend and frontend is Typescript.

  * Team Lead Internal Tools (Engineering manager, Typescript)
  * Senior Backend developer (Typescript)
  * Senior & medior QA / test engineer
  * Freelance QA
  * Senior app developer (React native)
Now is a great time to join, as the software team is still small but growing quickly. These and other vacancies are on our careers page: https://www.quatt.io/working-at-quatt Email me directly ( my-hacker-news-username@quatt.io ) for questions or apply via the career page. Unfortunately, at this time, you have to be allowed to work in the EU: we're not able to sponsor Visa, and do look for people that can be in the office regularly.


What are you looking for in a freelance QA? Writing tests or just building frameworks?


Writing tests and doing partially manually testing too.


Quatt.io | Amsterdam, Netherlands | Full-time | Hybrid/ONSITE | https://quatt.io | climate tech

I'm head of Software at Quatt, a quickly growing scaleup building heatpumps to help fix climate change. Heating and cooling is 50% of all energy used in the EU. Heat pumps save 10 times more CO2 for each Euro spent on them compared to electric cars. We're building the most accessible and smartest heatpumps on the market. Our first product is live, the next ones announced, we have thousands of customers, tons of data, and I really like the impact we're having. We also just raised €25 million for further expansion. I’m currently looking for a few roles for my department, as we believe having the best software will allow us to have the best product. Our backend and frontend is Typescript.

  * Senior Backend developer (Typescript)
  * Senior QA / test engineer
  * Senior app developer (React native)
  * Devops engineer for our fleet of thousands of devices
  * Data Architect (AWS)
Now is a great time to join, as the software team is still small but growing quickly. These and other vacancies are on our careers page: https://www.quatt.io/working-at-quatt Email me directly ( my-hacker-news-username@quatt.io ) for questions or apply via the career page. Unfortunately, at this time, you have to be allowed to work in the EU: we're not able to sponsor Visa


Quatt.io | Amsterdam, Netherlands | Full-time | Hybrid/ONSITE | https://quatt.io | climate tech

I'm head of Software at Quatt, a quickly growing scaleup building heatpumps to help fix climate change. Heating and cooling is 50% of all energy used in the EU. Heat pumps save 10 times more CO2 for each Euro spent on them compared to electric cars. We're building the most accessible and smartest heatpumps on the market. Our first product is live, the next ones announced, we have thousands of customers, tons of data, and I really like the impact we're having. We also just raised €25 million for further expansion. I’m currently looking for a few roles for my department, as we believe having the best software will allow us to have the best product. Our backend and frontend is Typescript.

  * Senior Backend developer (Typescript)
  * Senior & Medior QA / test engineer
  * Senior app developer (React native)
  * Devops engineer for our fleet
Now is a great time to join, as the software team is still small but growing quickly. These and other vacancies are on our careers page: https://www.quatt.io/working-at-quatt Email me directly ( my-hacker-news-username@quatt.io ) for questions or apply via the career page. Unfortunately, at this time, you have to be allowed to work in the EU: we're not able to sponsor Visa


Quatt.io | Amsterdam, Netherlands | Full-time | Hybrid/ONSITE | https://quatt.io | climate tech

I'm head of Software at Quatt, a quickly growing startup/scaleup building heatpumps to help fix climate change. Heating and cooling is 50% of all energy used in the EU. Heat pumps save 10 times more CO2 for each Euro spent on them compared to electric cars. We're building the most accessible and smartest heatpump on the market. Our product is live, we have thousands of customers, tons of data, and I really like the impact we're having. I'm currently looking for a few roles for my department, as we believe having the best software will allow us to have the best product. Our backend and frontend is Typescript.

  * Medior QA / Test automation engineer
  * Senior app developer (React native)
  * Senior Backend developer (Typescript)
  * Medior Full-stack developer (Typescript)
  * DevOps Engineer
Now is a great time to join, as the software team is still small but growing quickly. These and other vacancies are on our careers page: https://www.quatt.io/working-at-quatt Email me directly ( my-hacker-news-username@quatt.io ) for questions or apply via the career page. Unfortunately, at this time, you have to be allowed to work in the EU: we're not able to sponsor Visa


"Hybrid/ONSITE"

What exactly does that mean? Part time remote from within the EU is possible, with regulary travelling there, or does it mean, some days of the week remote is possible but otherwise office time is required (and therefore relocating)?


It depends a bit on the role, we're considering more remote options, but for now we mostly hire people that are in the office part of the week.


Correct me if I’m wrong but: SQLite sounds like: runs on one server. While that will work most of the time, it won’t work 100% of the time. I don’t know the specifics, but I’m fairly sure if a queue server crashes, SQS will keep working, as stuff is redundant. So while it can work in a best case, this (probably) won’t have the same reliability as SQS has..


I break it down two ways.

First, the project does not yet have a distributed implementation, you’re correct. Stay tuned!

Second, SQLite is incidental. Data is still stored on disk, just as SQS must be, but I’ve chosen SQLite as the file format for now.


Strictly speaking, SQS does not necessarily store data on disk and being highly available and fault tolerant does not exclude one from operating a completely volatile data store. Indeed, SQLite itself has an in-memory option which, when appropriately architected, could be used as the primary data store for a highly available and fault tolerant queue.

Having said that, I think it is safe to assume that SQS probably stores information to non-volatile storage.

Nice work on the project!


Does this even need to compete feature wise with SQS?

If it faithfully reproduces the SQS Api what could possibly stop me from using this product now (if he ever does hosted) and then switching to SQS if the scale is ever justified?

I'm all for a full suite of solutions targeting the same API. Can I run this thing on a single server with my dashboard app for the 3 person team I'm developing for and all that it cost them is per hour for tech support and server hardware and deloy my multi million user app on SQS but have effectively the same code.


The choice of SQLite is a great one as the distributed sqlite space is also growing. You have things like rqlite (raft+sqlite), and you have cloudservices like CloudFlare D1 which is basically distributed/HA sqlite. Plus you can swap it for basically any other sql database.


This depends on your definition of few.. but SQS costs us more than the servers handling the messages… It’s cheap until you do billions of messages…


Quatt.io | Amsterdam, Netherlands | Full-time | Hybrid/ONSITE | https://quatt.io | climate tech

I'm head of Software at Quatt, a quickly growing startup/scaleup building heatpumps to help fix climate change. Heating and cooling is 50% of all energy used in the EU. Heat pumps save 10 times more CO2 for each Euro spent on them compared to electric cars. We're building the most accessible and smartest heatpump on the market. Our product is live, we have thousands of customers, tons of data, and I really like the impact we're having. I'm currently looking for a few roles for my department, as we believe having the best software will allow us to have the best product. Our backend and frontend is Typescript.

  * Senior Backend developer (Typescript)
  * Medior QA / test engineer
  * Senior app developer (React native)
  * Medior fullstack developer
Now is a great time to join, as the software team is still small but growing quickly. These and other vacancies are on our careers page: https://www.quatt.io/working-at-quatt

Email me directly ( my-hacker-news-username@quatt.io ) for questions or apply via the career page - please mention you found us at HN! Unfortunately, at this time, you have to be allowed to work in the EU: we're not able to sponsor Visa.


I can’t see any of these vacancies in the careers page


They're in the 'Software & Data' section that's farther down the list, not the 'Product & Engineering' section near the top.


Which canal? :)


It's in Houthavens. You should be able to spot us if you cycle through the bit that's still under construction!


Quatt.io | Amsterdam, Netherlands | Full-time | Hybrid/ONSITE | https://quatt.io | climate tech

I'm head of Software at Quatt, a quickly growing startup/scaleup building (hybrid) heatpumps to help fix climate change. Heating and cooling is 50% of all energy used in the EU. Heat pumps save 10 times more CO2 for each Euro spent on them compared to electric cars. We're building the most accessible and smartest heatpump on the market. Our product is live, we have thousands of customers, tons of data, and I really like the impact we're having. I'm currently looking for a few roles for my department, as we believe having the best software will allow us to have the best product. Our backend and frontend is Typescript.

  * Cloud engineer, focussed on AWS infra
  * Backend developer (Typescript) senior 
  * Senior/medior QA / test engineer
  * Senior app developer (React native)
  * Full-stack developer
  * Systems administrator 
Now is a great time to join, as the software team is still small but growing quickly. These and other vacancies are on our careers page: https://www.quatt.io/working-at-quatt Email me directly ( my-hacker-news-username@quatt.io ) for questions or apply via the career page. Unfortunately, at this time, you have to be allowed to work in the EU: we're not able to sponsor Visa


Hi, are applicants from elsewhere in the EU considered?


Certainly! We have quite a few nationalities in the company, I think over 20. However, for these roles we look for hybrid people, so working part of the week from our (Amsterdam) office.


Sorry, should have been more clear, I meant other EU citizens working exclusively remotely.


Nope, sorry, not for now. That's the hybrid/onsite part...


Are there any Data / AI-related internships planned soon :)?


We don't have many internships planned right now but do welcome open applicants.


Cool article. What I've wondered, and the article doesn't touch on: In "normal" usage (not damaged QR codes), what's the best error correction to use, with a fixed output size (eg a sticker)? Using a higher level, results in more bytes, and thus a larger QR, which, when printed, results in smaller details. Is it better to have a low error correction, resulting in large blobs, or to have higher error correction, resulting in smaller details, which I guess will be harder to scan, but more room for correction?


I guess this is a trade off that depends on your use case: from which distance does the qr code need to be scannable, what cameras do we expect to be used for scanning, how likely is what kind of damage to parts of the qr code, ...


Indeed. The local bus transit has a digital ticket system with QR codes for tickets. I haven't actually tried decoding the codes but just seeing them and interacting with them I can tell they have gone WAY overboard with either the amount of data they try to fit or the amount of error correction. Probably both. They are nearly unscannable due to their size and all the bus drivers just wave you along if you don't manage to scan it.


Yeah, I had had the same question! One of my earlier articles experiments with this: https://huonw.github.io/blog/2021/09/qr-error-correction/

Figure 8 and its surrounding section are the undamaged case.


That was a nice read.

> I also tested only one background image, so the behaviour may differ greatly with QR codes contained in different surrounds.

This likely does not matter much. It could theoretically affect binarization near the edges of the code (near module boundaries, depending on how you did the resizing), but in practice as long as the code itself is high-contrast, this is unlikely. The more usual issue is that real images often do not have a proper quiet zone around the code, but that is mostly going to be irrelevant for what you are trying to test here.

> The QR codes are generated to be perfectly rectangular and aligned to the image pixel grid, which is unlikely to happen in the real world.

This is a much bigger deal. A large source of decoding errors for larger versions (for a fixed "field of view") is due to alignment / sampling issues. A lot of work goes into trying to find where the code is in the image and identify the grid pattern, and that is just inherently less reliable for larger versions, particularly if there is projective distortion (so the module size is not constant). The periodic alignment patterns try to keep the number of parameters that can be used to fit this grid roughly constant relative to the number of modules in the grid, but locating those patterns is itself error-prone and subject to false positives (they are not nearly as unique-looking as finder patterns), and the initial global transform estimate has to get pretty close for them to work. I am actually happy that damaging these was not causing you more trouble. This is definitely somewhere that ZBar can be improved. It currently does not use the timing patterns at all, for example. I'm not actually aware of an open-source QR decoder that does.

(I'm the original author of ZBar's QR decoder)


Thanks for the kind words and the insight!


A slightly more common way to express "field of view" is "module pitch", measured in pixels between adjacent module centers. I went back and tried to express the numbers from Figured 6 as a module pitch, and I think it works out to around 1.6 pixels / module. IIRC, the QR code standard recommends a module pitch of at least 4 pixels. So it is nice that ZBar is able to do around 2.5x better before running into issues (a margin that is a lot bigger than the gains from higher EC levels).

In theory there could still be room for improvement. Right now ZBar estimates finder and alignment pattern locations to quarter-pel precision, but rounds each module location to the nearest pixel so it can sample a binarized version of the image to decide the value of that module. At the extreme limits of small module pitch this effectively turns the resampling filter in whatever you are using to resize your QR code image into a nearest neighbor filter. You can see why that would start to cause issues. Imagine a version 7 code (45x45 modules) sized to be 80x80 pixels. Most of your columns will be 2 pixels wide, but with binarization, somewhere in there you have to have 10 columns that are only 1 pixel wide. Good luck lining up your grid to hit all of them perfectly (without looking at the timing pattern, which would likely only help in the perfectly axis-aligned case). Some kind of sub-pixel integration of the original image before thresholding to decide each module value could probably do better. That would make decoding a lot more computationally expensive, though.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: