SumUp | Android, Full-Stack and many more Engineering positions | Berlin / São Paulo / Cologne / Sofia / Copenhagen | https://sumup.com
SumUp is a leading financial technology company, serving millions of merchants across 35 markets. We empower business owners by enabling them to accept card payments in-store, in-app and online, in a simple, secure and cost-effective way.
While there are many roles open, I would like to specifically mention two for teams that I personally work closely with:
Senior Android Engineer [Berlin or Cologne, Germany / São Paulo, Brazil]
In SumUp's highly motivated and engineering-driven Identity team, we are working on providing best-in-class authentication experiences and account protection for millions of users globally.
We are looking for a Senior Android Engineer with a passion for security to join us!
We are hiring for a Backend-focused Fullstack developer to help build out our internal backoffice. This role focuses on building a platform for internal teams to build out backoffice components focused on their business while also supporting internal employees in optimizing their workflows through consistent design patterns, and streamlined flows.
The role stack will require working on ReactJS, NextJs, Typescript and Golang, but we none of the tools are a hard requirement, as we are eager to work with people who are willing to dive in head-first and learn something new.
Many many more roles (Data Analytics, Data Engineering, Backend Engineers (mostly Go [golang] or Kotlin/Java), iOS and Android, as well as many non-engineering roles): https://www.sumup.com/careers/positions/
That should be rather easily doable but finding a company obviously depends on what you're looking for. Most likely you're in Software Engineering? If so, with which preferences and specialities?
Here at SumUp we're hiring fully remotely across the EU and most teams are very flexible regarding the working hours. A 4-day week should be easily doable and I've personally done that before.
Contact me via my email address in my profile and I'm happy to connect you with the best matching team.
SumUp | Multiple Software Engineering and DevOps positions | Berlin / Cologne / Sofia / Paris / Barcelona / Warsaw / Copenhagen / REMOTE (Germany or EU) | VISA | https://sumup.com
SumUp is a leading financial technology company, serving millions of merchants across 32 markets. We empower business owners by enabling them to accept card payments in-store, in-app and online, in a simple, secure and cost-effective way. We're already 3000+ SumUppers around the globe and growing fast!
For me personally the top reason to work for SumUp is probably our engineering and team culture. We invest heavily into our DevOps capabilities and work in small autonomous and cross-functional teams.
We offer bi-weekly Hack Days for projects of your choice, as well as annual Hack Weeks (in May we're all going to Portugal), a generous learning and development budget and plenty of perks.
I'm mostly looking for new colleagues to join us building our first consumer-facing solutions and help our millions of existing merchants to connect with their customers to turn payment transactions into relationships:
• Backend Engineers: Go (golang) / PostgreSQL / k8s / AWS stack. You should bring some backend experience, but Go knowledge is a bonus, not a must. We're happy to train you https://grnh.se/49a869762us
At least for atomic access, I still believe that using wrapper types that prevent non-atomic access are the better idea: e.g. https://github.com/julienschmidt/atom (or uber/atomic).
That already ensures safe access at dev / compile-time. One explicitly states on declaration that the variable is accessed atomically by using the wrapper type.
A linter could then simply check that sync/atomic isn't used directly anywhere.
Note that this also exists in the gVisor code base, the atomics support here is mostly for mixed-mode operation (read atomic, write locked) which is also common. It’s pretty new, so I still need to annotate a lot of the code.
It took until December of the same year until we got the first bug report and figured out what was going on. While the semantic change might look subtle, it was certainly not from our (driver maintainer's) perspective.
We were quite disappointed that such a change was made 1) without informing the driver maintainers 2) making sure the changes were in place before this change made it into a Go release.
We regularly test against Go's master (now using a Travis CI cron job), but that only helps if the existing tests fail. We don't have the time to constantly monitor all changes in the Go repo.
If there is a need to make such changes (not just in database/sql and not just in Go), PLEASE actively communicate early with the community / the direct users.
I'm sorry. This is clearly my fault and I'm sorry this wasn't communicated.
Please look into Go1.15. It should all be backwards compatible, but where the session resetter is called changes, and a new call is added for verifying if the connection is valid or not. I'll have the release notes updated soon for Go1.15, but until then, look at the driver docs for tip.
I'll make announce the change on the golang-sql mailing group.
I really appreciate the work that is done to improve the database/sql package. It is still rather young and not as mature as for example JDBC. I would rather thank the people who work on it for the work they do, than to point fingers for anything that is not done. The original design of database/sql was sometimes a bit too simplistic and will probably require some more ugly changes or workarounds in the future.
This specific change was a bit unfortunate. It tried to fix another bug caused by the introduction of Context cancellation support, but it unfortunately caused some other major bugs due to the changed semantics. Like the very same comment already indicates, other drivers also required changes. In retro-perspective I think it would have been better to try to handle the original issue entirely in database/sql, instead of changing the "contract" with the drivers.
Go MySQL Driver was, and I believe still is, developed mostly by some random programmers in their free time (I originally started it as a side-project during high school and until now was never paid for any work on it). It probably makes anyone who worked on it proud that now some major companies, not just GitHub, employ it. But like many such projects, it is not a perfect or finished product. If you use community-driven open source software at work, try to convince your management to set some work hours aside for actually contributing back to those, like GitHub did.
Go is still undergoing intensive R&D, especially in the runtime. Its releases are quietly tested against internal Google projects, but not formally tested with widely-used open source projects.
Any org that deploys Go apps should designate someone to watch the Go issue tracker, and subscribe to all issues that might affect them.
Notifying users of the code of a semantic change does not mean it's not a semantic change.
Even if the Go team can find a way to notify all of the public drivers impacted, they aren't going to be able to know about the private drivers or forks to notify those people. Nor are they going to be able to notify all the consumers who, using MVS, have the version of the driver set to one that's not fixed.
Bugs from this change will propagate and there's nothing the Go team can do to stop them all. This is why projects following semantic versioning are not supposed to make breaking changes in minor releases.
This is, unfortunately, not the first time I've seen this kind of change in Go. Some previous changes have caused bugs for me a few times in the past. Not knowing which version of the compiler one would use I ended up needed to craft code to handle before and after cases for the change along with the bug reports from users.
I feel like this should require the user's explicit permission, just like audio, camera, location or Flash and Java Applets at the end of their life.
WebGPU is a great innovation, but we have both privacy and security concerns here. It should be available where and when the user wants it, not silently in the background.
Why don't you say the same about CPU or RAM? In the end it's just resources that are abstracted away to the user, used with the purpose of performing tasks in the most efficient way possible.
What you really want is a security first web browser, not something that must prioritize feature completeness to achieve commercial success. I would love a spin-off of the Tor browser sans Tor.
ACME is an open protocol (and very soon it will be an IETF Internet Standard too). There are many alternative implementations. Just find one you trust.
We actually did our own DNS-based implementation for our infrastructure.
I don't want to run someone else's code on my server just for this (the default certbot wants root access too, yikes), nor do I want to analyze someone else's implementation before running their code, and I sure as heck don't have the time, patience, or interest to write my own implementation of ACME just for the one service that uses it.
I want to go to a website, have it tell me to put a string into a meta tag or DNS TXT record, and then save the key it returns on my box. Then I want to forget about it for the next 2-3 years.
Honestly I don't even want to do that. I want my nameserver to generate a DANE/DNSSEC record for me automatically, and for browsers to honor that. It isn't like domain verification is any more secure than a DNSSEC record would be.
We do something similar, although not through a REST API. We handle all this cert management centralized on one server, which publishes the DNS records for DNS verification etc.
On our other servers is then just a simple script that periodically checks if the certs on the machine are near the expiry date and if so pulls a new one from the central system.
ACME protocol is fairly straight forward to implement, and you can easily write your own implementation with existing code (OpenSSL, Apache/nginx, etc).
With many commercial registrar's, although they offer a valid and long certificate, their technical aspects aren't very good. Many CAs don't support ECC certificates, the must-staple flag or CT SCTs embedded in the certificate.
I work a lot with web PKI, and every time I have to deal with a CA that's not LE or Digicert, I sigh out loud.
This blog post doesn't answer likely the biggest of all questions: Will there be breaking changes?
If so, how will those be handled?
"As a rule of thumb, we should aim to help at least ten times as many developers as we hurt with a given change" sounds like there might be breaking changes, but on the other hand Robert still talks about including new features in the Go 1 compatibility guarantee.
I'd love if the compiler would stay backwards compatible and packages / modules could be pinned to a certain version, either during import or in the package / module itself. Then one could write Go 2 code but still use packages which are not yet updated to Go 2.
Personally I think that making breaking changes is a good idea, as it allows to clean up previous mistakes. However, Go should at all cost avoid incompatibilities like between Python 2 and 3.
It is very clear that there are breaking changes for Go 2.
However, they are testing out their new proposal-review system using non-breaking changes included in Go 1.
That's just BS. (IETF) QUIC was developed from scratch by an IETF working group. Google submitted its (Google) QUIC version as input, however the IETF version is not directly based on it.
> HTTP/3 (originally named QUIC) is an experimental transport layer[1] network protocol designed by Jim Roskind at Google,[2] initially implemented in 2012,[3] and announced publicly in 2013 as experimentation broadened
and then
> In June 2015, an Internet Draft of a specification for QUIC was submitted to the IETF for standardization
Unless you count 'developed independently by Google and then three years later submitted to IETF for standardization' as 'developed from scratch by an IETF working group', I fail to see how your assertion is backed by actual events.
For the record, SCTP has been standardized since 2000, and it was actually developed by an IETF working group.
AFAIK the proposal for HTTP-over-QUIC was to race with a TCP connection. Similar to Happy Eyeballs for IPv4/IPv6 dual stacks (meaning we could end up with 4 connections attempts?).
SumUp is a leading financial technology company, serving millions of merchants across 35 markets. We empower business owners by enabling them to accept card payments in-store, in-app and online, in a simple, secure and cost-effective way.
While there are many roles open, I would like to specifically mention two for teams that I personally work closely with:
Senior Android Engineer [Berlin or Cologne, Germany / São Paulo, Brazil]
In SumUp's highly motivated and engineering-driven Identity team, we are working on providing best-in-class authentication experiences and account protection for millions of users globally. We are looking for a Senior Android Engineer with a passion for security to join us!
Berlin/Cologne: https://www.sumup.com/careers/positions/berlin-germany/mobil... São Paulo: https://www.sumup.com/careers/positions/são-paulo-brazil/mob...
Senior Fullstack Engineer (Backoffice) [Berlin, Germany]
We are hiring for a Backend-focused Fullstack developer to help build out our internal backoffice. This role focuses on building a platform for internal teams to build out backoffice components focused on their business while also supporting internal employees in optimizing their workflows through consistent design patterns, and streamlined flows. The role stack will require working on ReactJS, NextJs, Typescript and Golang, but we none of the tools are a hard requirement, as we are eager to work with people who are willing to dive in head-first and learn something new.
https://www.sumup.com/careers/positions/berlin-germany/fulls...
Many many more roles (Data Analytics, Data Engineering, Backend Engineers (mostly Go [golang] or Kotlin/Java), iOS and Android, as well as many non-engineering roles): https://www.sumup.com/careers/positions/