JulienSchmidt

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!

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/

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

• Android Mobile Engineers: Java / Kotlin / Android frameworks https://grnh.se/e0c5b9162us

• VP of Consumer Business / Consumer Business Leader https://grnh.se/c9454c5f2us

Many many more roles (e.g. DevOps / JavaScript/TypeScript/React Frontend / Platform / Hardware / Embedded / QA Engineer, Java/Kotlin/Node.js/Go Backend Developer roles, and UX and Product Designer, Product Manager, Engineering Manager, ML, Data and Analytics): https://grnh.se/a27fea202us

Happy to answer any questions. My email is in my profile.

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.

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.

Bug #3 (The race) was silently introduced by a semantic change in Go's database/sql in January 2018: https://github.com/golang/go/commit/651ddbdb5056ded455f47f9c...

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 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.

Take a look at https://github.com/joohoi/acme-dns/ (which of course still requires trust in the client lib)

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 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.

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.

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.

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?).

microG is certainly not perfect and I wouldn't recommend it to the average user. Expect some things to not work or even certain apps to crash. It's a techie-solution for people who value their privacy highly.

Android (the Android Open Source Project) itself is not the Problem. It's the lock-in ecosystem that Google tries to establish with the Google Services Framework, Play Store and the like. What is missing, is an open and privacy-friendly alternative to GSF. Without GSF we don't have efficient push notifications (Firebase Cloud Messaging), a geolocation provider, a maps API etc.

Personally, I have been using microG (https://microg.org/) instead of GSF on my phone for many years now. However, that is still just a partial solution. While it does its best to be privacy-friendly and does not have any integrated tracking / analytics like GSF, it still has to use Google's servers for push notifications, thus tracking is still possible to some degree.

The title should start with "Show HN:", followed by something more readable than the repo path. E.g. "Show HN: Test your sysadmin skills"

China still also has Dida Pinche.

But I agree, before Uber left the Chinese market, there was more pressure to be customer friendly. And the regular promos (with ridiculous amounts of free rides) where also nice from a customer perspective.

Regarding non-reliable streams: There is https://tools.ietf.org/html/draft-tiesel-quic-unreliable-str..., while it won't be part of the initial standard, it's likely that the working group makes sure that it can be added later.

Lower connection establishment latency: SCTP over UDP using DTLS requires 4 roundtrips (that's worse than standard TCP) while QUIC (which includes DTLS like encryption) only requires 1 roundtrip for the first connection and 0 RT for subsequent connections, when it cached some information.

After Google presented the protocol to the IETF several months ago, a working group was formed: https://datatracker.ietf.org/wg/quic/about/ / https://quicwg.github.io/ There will soon be a standardized version of QUIC with a fixed specification, probably by the end of next year.

I guess Google will still continue to experiment, but then probably based on the standardized version.

PPTP is obsolete and fundamentally insecure. And that isn't news but known at least since 1998 (!): https://www.schneier.com/academic/pptp/

It is unlikely that it would be blocked in China since eavesdropping is easily possible.

(Vanilla) OpenVPN is blocked in China, likewise is IPsec and L2TP. SSTP can also easily be detected via Active Probing but I'm not sure if the GFW currently does that.

For Hotel bookings, many (all?) Expedia subsidiaries seems to be just a different UI for the same offer with slightly different prices since they target different users (premium vs budget etc). All bookings are made under the name Expedia.

In case of Priceline Group, it depends on the market. E.g. in China Agoda seems to be just another front-end for booking.com. All bookings are actually made through booking.com. But e.g. in Malaysia Agoda lists some Hotels which I could not find on Booking.com.

The Flight search engines seem to have major differences, e.g. in Southeast Asia Momondo lists a lot more local agents and more airline websites directly than Kayak.

Neither Ctrip nor eLong are owned by Priceline / Expedia. They invested in the respective companies and own a stake, but Chinese law prevents that any foreign company owns the majority of any Chinese company. (Yes, even the Chinese McD, Apple, Starbucks etc are majority Chinese owned)

I am a bit shocked though, that Momondo is owned by Kayak. For me, Momondo has so far been the best alternative. And Skyscanner is owned by Ctrip, which has a strategic partnership with the priceline group...

Likely she searched for the name "porter" at some point suggesting that she is interested in people with that name.

Combined with 2nd and 3rd degree phone and email connections that might be a strong indicator for FBs algorithm.

parsed (+compressed), not compiled.

Parsing is unavoidable, regardless if the code is interpreted or compiled. This proposal seems to further compress the AST somehow.

Basically the idea is to already preprocess the text source, so that the client can skip two steps on execution: lexical analysis and the parsing of the text source resulting in the AST. The post explains why the authors believe that this is a good idea.

Open an issue on the repo and suggest it!

I assume it is a bit difficult though, since the encryption is performed in the browser. Thus API clients had to perform the exact same crypto to use this service.

The problem is that none of the default protocols work in China. Either they are blocked via DPI in combination with techniques like TCP RST injection / null-routing of the destination IPs, or they are known to be insecure, like PPTP (which is why it is removed in iOS 10)

Most likely Apple cooperates with the respective agencies as requested by Chinese laws. If not yet, they will have to start very soon or iMessage will also be blocked.

Are there any signs of Censorship on iMessage so far? Are terms that are known to be blocked on WeChat, QQ etc (e.g. 法轮功 / Falun Gong) still working on iMessage?

The website also has info pages about the authors: 3 from Spain and 1 from Andorra. The first language of all authors seems to be either Spanish or Catalan.

Bouncing is a bad idea as it can be abused for spam:

1. Fake the origin to actual destination of choice

2. Your server bounces the original message wrapped by the SMTP error report.

3. Actual destination receives error report containing spam content from YOUR server

A proper solution would be to REJECT the message before it is accepted. However, Dovecot Pigenhole doesn't support that (yet).

Go to Preferences > Search and set keywords for each search engine.

E.g. I use "g" for Google and "w" for Wikipedia. "g hacker news" in the AwesomeBar would then search for "hacker news" on Google and "w hacker news" likewise on Wikipedia.