EZeats (ez-eats.com)| Software Engineers | On-site in Cairo, Egypt (remote possible in MENA region)

We are shaping the future of F&B and contactless dining with a cutting-edge POS tailored for the MENA region.

Open Roles:

- Senior Backend Developer (NestJS): Expert in architecting scalable backend systems using NestJS, with deep proficiency in cloud platforms, microservices, and API optimization. Collaborates with cross-functional teams to deliver secure, high-performance solutions aligned with industry best practices.

- Senior React Native Mobile Developer: Skilled in building cross-platform mobile apps with React Native, focusing on performance optimization, third-party integrations, and CI/CD pipelines. Partners with designers and product teams to craft intuitive, user-centric mobile experiences.

- Senior UI/UX Designer (F&B Products): Specializes in creating visually compelling, user-friendly interfaces for food and beverage platforms, leveraging user research, wireframing, and prototyping. Balances brand identity with usability to drive customer engagement and business growth.

- Senior Product Manager (F&B Products): Leads end-to-end product strategy for F&B digital solutions, from market analysis to roadmap execution. Bridges stakeholder needs with technical teams to innovate and scale products in a competitive industry landscape.

if you are interested send your resume to careers@ez-eats.com with the job position in the title.

The original document initially mentioned the 'software industry' and I indicated that by signing it, I would be legally agreeing not to work in the software industry at all. They mentioned they would provide a more specific definition, but I still found it unusual. I understand signing an NDA, but a non-compete agreement feels more like giving them the right to sue me if they choose to.

> The original document initially mentioned the 'software industry' and I indicated that by signing it, I would be legally agreeing not to work in the software industry at all.

If that's the clause, then 100% don't sign it. I've never heard of a noncompete that locks you out of an entire industry before. More typically, a noncompete restricts you from working at companies that directly compete with the company hiring you.

Personally, that they'd even ask for something that extreme, even if it can be negotiated to be less onerous, would put me off of working for them. I'd take it as a sign that they're a bad company to work for.

If they don't want you working in the software industry for 16 months, then there's a simple and straightforward solution: they should pay you. Look up "garden leave" for more about the practice.

Excellent point. Thank you.

I am outside the US, and they told me this is the common practice for startups now, and to be honest, I don't feel comfortable signing it.

I gave my daughter this advice about contracts in general that may apply to you: if you aren't comfortable with it, don't sign it. Do explain to the other party why you're uncomfortable with it, though. The point of discomfort may be negotiable. If it's not, then don't sign it anyway.

Is the startup requiring the noncompete just because that's what everyone else does? Often, when a company is requiring a noncompete, what they're actually trying to do is to prevent the use of proprietary information by competitors. If that's the case with this one, then maybe they'd be willing to use a nondisclosure rather than a noncompete.

These are just the thoughts I go through when I'm faced with one of these things. You are a different person with different needs, of course.

The solid advice I have for you is to talk to an attorney with experience in employment matters if at all possible to get his take on what that particular agreement means for you, and to think about the whole thing very carefully. For instance, if you'll be locked out of sorts of businesses that aren't of much interest to you anyway, a noncompete with this startup might not be big a deal.

Going to work for a startup is already taking a gamble in the first place. Being locked out of similar businesses should you leave can be a big ask of someone who's already taking a risk.

Thank you!

People aren’t necessarily opposed to commercial use (which many licenses allow), but are upset that license terms like attribution requirements are completely being ignored by Microsoft/Github, turning Copilot into a sort of laundering machine for open-source content.

That's what I am trying to say. Personally, I don't mind if my code is being used for commercial or not. I do mind when Microsoft uses my code without a reference and asks me to pay for copilot just because they decided to put it behind a paywall.

Still, it's good to be an option. If you see this as an advancement you can choose something like MIT if you don't like your code to be trained by a paid copilot then you can choose something like MIT-Human only.

It's a better solution than don't use GitHub at all. And whether we like it or not, a new license should be introduced to address the new data model.

Glad it does. Thanks for the feedback.

Demos in the site are behind the current version and not being updated to the latest one [1]. And updating the demos will take a while since I have to take resizing containers into consideration. So the current version is 2.x.x while the last one was 3.7.0. Sorry about that.

[1] - https://github.com/dflex-js/dflex/pull/573

Ah makes sense. How big is the packaged file you import?

It's not the size of the package. DFlex is actually small compared to other libraries. But I need to reconsider the size of the demo container before updating the version because when you resize there's a possibility to add a scroll to the container. Adding/removing scroll while dragging is not shipped yet.

I was just curious how big the file was for using it in a project. Not the demo page.

The entire package bundled and minified is ~14.4kb. No extra dependency needed. Just one package `@dflex/dnd`.

Cloning elements and duplicating containers are what DFlex tries to avoid. Because the usual implementation is to clone the element (ghost it) and then append a new one with a fixed position. The result is to reconstruct the DOM tree directly with every user interaction which leads to poor user experience and not a very practical transformation. That's why the default thing to do with DFlex is not to clone or change the element position unless there's a need to do so, for example: transforming from a container with a scroll.

That sounds reasonable!

To be clear, though: In my old example, there would only be DOM manipulation on drag start and drag end. All interactions between are handled with JS and CSS.

Cheers.

I should add this comment as a description in the main readme :)

Sorry for not updating the demo included on the site. But scrolling is working in the newer version. Also, DFlex is not meant for uploading assets to the browser otherwise, it's the future of interactive apps when elements can be transformed and positioned smoothly. This is what I am trying to achieve with DFlex that's why I spent so much time figuring out the optimal solution for reconciling a transformed element instead of adding a layer to html5 and call it a day.

Thanks for the feedback. DnD kit is amazing and the initial library also is so powerful [1]. But we still need a comprehensive solution. Committing changes to DOM with each interaction and shadow caching is not a sustainable solution for building interactive apps. React or any other framework is not designed for interactivity. So even if you are using React you are not actually getting the benefit of React to reconcile because you still committing changes directly to DOM. That's why I built DFlex which has its own reconciler and transformation mechanism.

[1]: https://shopify.github.io/draggable/

> React or any other framework is not designed for interactivity.

I thought that was the whole point. Are we using different definitions of interactivity?

In the drag-and-drop context, an interactive element is an element that can traverse the DOM tree and change its position without causing a layout shift and with a proper reconciler and transformation mechanism.