HN user

lvice

322 karma
Posts0
Comments35
View on HN
No posts found.

I just would like to give my opinion on some of your points, which I don't agree with:

Looking at the documentation directly, what they advise you to do is kind of the worst idea they could come up with: https://stripe.com/docs/webhooks/signatures – you need custom logic[2] to verify that their MAC ("signature" they call it incorrectly) is valid and you need to configure a different secret for each of your endpoints

It certainly help that I use their official SDK, but it's one line of code to add the signature validation. Also, I'm not sure why you would want to create a lot of endpoints to listen to these webhook. I simply have one, and the Stripe SDK helps me in determine the event type, its deserialization, etc.

Payment process information is such a vital business concern that "let's try to call them and if that fails... well we tried" is broken on principal alone

That's not how it works. The webhooks keep retrying with exponential backoff until they succeed. You can also manually retrigger them for individual events.

The obvious approach is to have an event list which you as customer long-poll or just poll every few seconds if your framework doesn't support async well

Nothing is preventing you to do that. In fact, in my codebase I do polling to the Stripe API as a fallback to check if payment is successful in case there are issues with webhooks. But it's nice to have the webhook telling you immediately if a payment fails/succeed, in order to give feedback to the user fast about the status of his payment (and not wait the next long polling iteration)

Not everything on Stripe is perfect, but I do find it really pleasant to work with in general

Here are the signs that I had during my burnout: - Hoping to get sick to get a few days without having to cope with work

- Trouble sleeping

- Not being able to enjoy my holiday / weekend due to the thought of having to go back to work with an increased backlog

- Enhanced imposter syndrome

- Work productivity drop

- Complete lack of purpose in the daily work

All of the above built up very slowly and I didn't realize until things got overwhelming. The good news for me was that all of the above disappeared almost instantly when I switched jobs.

We use an approach similar to what's described here: https://blexin.com/en/blog-en/build-scalable-and-resilient-a...

Using the Actor Model provided by Akka and an event sourced architecture does not fit very well with the request-response model of HTTP. Commands are usually issued in a fire-and-forget pattern, with resulting events being pushed to the client in a completely asynchronous way.

By using websockets via SignalR, we can better accomodate this pattern on the client code as well. On top of being a better fit with our backend architecture, it also provides some benefits in the frontend such as:

- Limited availability items disappear as soon as they actually are not available anymore, without the client having to refresh

- We can integrate more easily with payment gateways where payment confirmation usually arrives via a server side webhook. We can then easily push the "payment succeeeded" event to the client as soon as we receive it, without polling.

- Even the backoffice benefits from real-time, as all backoffice users are guaranteed that when they look up a customer/orders/products, they are looking at the most up-to-date information, even if somebody else edits the same record at the same time, or the record is updated by external APIs/scheduled job.

- We can provide easily real-time dashboboards that are listening to the feed of events being persisted

I've spent the last year working on an e-commerce project that esclusively uses websocket for real-time updates and communication. There are some great benefits to it, but websockets also introduce a lot of technical challenges that may not be obvious when you start. Things that come to mind are:

- Persistent connections make horizontal scaling more difficult

- Web Application Firewall don't usually support payload scanning for threats over websocket messages (eg. Cloudflare)

- If you need to integrate with third parties, you may end up needing a standard REST API anyway, since it's a lot less common to integrate via websockets (especially server-side). You then end up with two APIs. Also, websockets have less standard tooling for automatic documentation purposes such as Swagger/OpenAPI

- It's harder to load test the system, difficult to estimate the breaking point of the infrastructure via websockets

- HTTP Status Codes provide a standard error mechanism to HTTP server calls, while with websockets it's entirely up to you (which can be a good and bad thing)

- You need to manage explicitly situations where the connection drops and what to do when it recovers, as you may have lost some data in the meantime

- You give up a lot of standard mature tooling for caching and rate limiting

Ali, what’s up 4 years ago

I can confirm that this happens in Italian as well. I've never visited the site before and my search placeholders in the top bar are just full of weird NSFW terms.

Weirdly, it only happens to the desktop site, if I access it via mobile I get mostly normal suggestions.

I don't know java, but that's not the message I got from the comment. It looks like with java, 3 VMs with 2 cores are better than 6 VMs with 1 core, which may be forgotten when configuring equivalent kubernetes services.

I hope they are talking about hashed passwords. There is no reason why in 2021 passwords can be recovered in clear text, even in a legacy code base...

I've now worked for about six months on a Akka.NET codebase. I find it a very elegant high-performance framework that gives you a lot of flexibility in how you want to solve a wide range problems.

This being said, I've been burned already several times by the complexity and its raw power. The codebase tends to become verbose and difficult to navigate (everything being an ActorRef). Debugging is difficult and coding is challenging for junior engineers, as you said. I found it very unforgiving to mistakes, and it's easy to shoot yourself in the foot if you use the abstractions without knowing very well what's going on under the hood. Edge cases can be very tricky to manage.

I'm still very conflicted about it. One one side the services powered by Akka are quite stable and performant, but I'm not sure the complexity justifies the means.

I've used BEE editor many times before, and I've always always loved it.

When I found out the company was founded in Italy (my home country) I was very pleasantly surprised, as tech companies with such well designed products are very rare over here. Building a friction-less editor for engaging, reliable email layouts is a complicated engineering problem, and what your team built is absolutely outstanding.

Good job, really :) the company success is fully deserved.

I've recently started a remote job with a UK-registered company, and I am working from Italy. If the company does not have a local office in the country (which mine doesn't), the easiest way is just to become a contractor/freelance and send invoices for b2b services. I had to hire an accountant to manage taxes, but it's doable.

I live in Rome, so I can give a bit of feedback on it. The road has been turned to pedestrian-only since August 2013 by the mayor Marino. It has been like that ever since. There is currently no plan for deconstruction, and the future of the road is still up to debate. I think it makes for a very nice walk in the heart of Rome, with plenty of space for tourists to wonder around without being cramped.

I think this part is captured by Satisfactory "Tier" system. As you progress in the game, you unlock Tiers which allow you to build new materials and structures. The issue often is that you optimize the hell out of your factories to build something that is needed at you current Tier, and when you unlock the next one, you suddenly have to refactor everything to build the new items, that require different ratio of materials and inputs.

This winter break I spent an embarrassing amount of time on Satisfactory on Steam, which is essentially a nicer (and probably easier) modern refresh of Factorio.

While I played, I came to similar conclusions to the article. Building factories in this game is very very similar conceptually to building software. I ran into exactly the same problems that I ran while I build software like:

- If I don't plan ahead enough the scope and layout of the factory, I end up with a spaghetti mess that is very difficult to rectify (technical debt)

- If I plan too much ahead, I overwhelm myself without even starting. The amount over-engineering and over-preparation becomes counterproductive and demoralizing.

- Starting new factories is fun. Maintaining and extending a factory that is starting to show serious design issues is a chore. I always tend to want to scrap the factory and start fresh.

- While designing a factory, modularization is key. You can go with a "monolithic" factory where you provide all possible materials as input, and try to build everything as output. It is very efficient transportation wise, and can centralize all management, but it can and it will become an unmaintainable mess. You can also design factories as "microservices", where each factory is a very compact, clean and scoped. It will only produce nails, or rubber, or copper wire. When you need to increase production of that item, you just duplicate the module (horizontal scaling). It seems fantastic at first, but the issue is now transportation. Dozens of micro-factories have to communicate with themselves to combine and produce more complicated items. The physical distance makes planning transportation a logistic and construction nightmare. So you have to find the right compromise between monolithic and micro-services.

I think I agree with the article that you can extract a lot of information about how good a person can be at software development by the way he plays Factorio/Satisfactory. Not so practical though :)

The anti-vax crowd is complete nonsense, but the feeling I got from Italy wasn't so much "see! vaccines are dangerous! I am not getting a jab!, but rather "it looks like AstraZeneca may not be entirely safe, I demand a Moderna or Pfizer jab!".

Due to extremely skewed media coverage of the recent events, it may also be almost justifiable as a general reaction of population. If people are told that a vaccine has a rare but lethal side effect, and they are not in at-risk category, and there are two other vaccines that seem safer, it is almost reasonable to wait the other one. The main issue has been communication by media which made the investigation into side-effect seem much more severe than what it really was, undermining people trust in AZ. I think newspapers made an horrible job at it.

I would definitely still get the AZ vaccine, but I kind of understand where people are coming from, given the message given by media and their number-illiteracy that does not allow them to understand probability and the scale of numbers.

Impressive machine. As an Italian, I am pleased to see that the casting machine for Tesla is supplied by an Italian company.

Living in Italy, sometimes it's hard to see why the country is still in the top 10 economies in the world, due to the fact we lack mega-corps and global consumer brands (luxury aside). The truth is that Italy is all-in on small businesses, with thousands on niches companies that fill a very specific spot in the world supply chain. I really hope that this model proves to be sustainable and we can find a path to growth again at some point.

I see xtracto's point. You are "paying" to pursue a PhD in the form of missed additional revenue that you could have achieved by starting in the industry earlier on. Or pursue other paths that could be more industry-focused (MBA). It's an intellectual investment, sure. But for most PhDs, it will be a net negative on the financial side, and a potential hyper-specialization trap for moving to the private/industry sector.

I believe that abuse is more common in academia.

A relationship between a supervisor and his direct reports, both in academia and industry, is impacted by the power that the supervisor can exert. The relationship between a supervisor and his PhD students is not the same as a manager and his direct reports in industry because:

- The students are invested and committed into their PhDs for several years. It is much harder to change path or mentor compared to just change jobs. The energy and resources that the student needs to invest to apply a change are significantly higher, often involving moving to a different city.

- The reward of a job is, for the most part, the monthly paycheck. A PhD is a long-term investment that must be completed in order to have value. An employee that quits a job after one year is not an issue, and it is considered "experience", but quitting a PhD half way through can be perceived as a failure.

- Professors in academia have almost unlimited decision power in how they manage their budget and their reports. It can almost feels like an absolute monarchy.

- This may be anecdotal, but I feel like the role of professor in academia can attract people with larger egos and smaller empathy, especially in scientific subjects.

All of these points, combined with a bad supervisor, are fantastic fuel for anxiety and unhappiness. There is no worse thing that, after so much work, feeling that you have no control over your situation and you have no margin to improve it, without significant additional sacrifices.

My opinion on the Power Platform is:

- Canvas apps: worth it only for very simple applications that interact with another MS datastore (Sharepoint, CDS/Dataverse) and services. If you mostly need to interact with custom APIs, a simple custom webapp is probably a safer choice.

- Power Automate: stick to very simple flows, take advantage of the connectors but avoid at all cost complex business logic within the flow itself

- Model-driven apps: more interesting in my opinion. They effectively are mini-instances of Dynamics CRM, and you get A LOT of functionality out of the box. You can't tune the UI much, but you get the benefit to build an "interactive database" very quickly, with support for RBAC system, OData REST APIs, Views, Workflows, C# plugins, dashboards. If you need an internal application, used only by a few people (licensing), where you need an interactive data-store without complex requirements on business logic and custom UIs, then I think Model-driven apps can be terribly effective. Now, if only the licensing wasn't so damn complicated...

I think the Erasmus initiative is an outstanding EU programme, which helped collaboration between EU universities and to build a EU identity for young educated students. It's not an economic initiative per se, and it's hard to measure its effective results objectively, but I believe it's been an absolute net positive for the EU.

I had a go with a trial account. I like the UI/UX and the site is really fast. Impressive project, and it looks a billion times better than most Sharepoint-based intranets. Good luck!

I think the idea is: I trust the content of the website (ex. the actual weather forecast) but I don't trust/like the way it is served on their website (intrusive ads, cookie acceptance, heavy pages, etc). The fact that the core of the content is displayed directly through Google bypasses the problems above.