Oh Hi There! I am Eyaadh

Since coming back from my break, I've been wrestling with lack of motivation to dive into my work. But, lo and behold, last Monday, I summoned the strength to crack open my laptop and kickstart this project. Why? Because I made a commitment to you to see this application through. And let me tell you, when I make a promise, I stick to it like glue. eyaadh@Ahmeds-MacBook-Pro-173 WebstormProjects % npm create hono@latest qrquickBackend Need to install the following packages: [email protected] Ok to proceed? (y) y create-hono version 0.7.3 ✔ Using target directory … qrquickBackend ? Which template do you want to use? nodejs ✔ Cloning the template ? Do you want to install project dependencies? yes ? Which package manager do you want to use? npm ✔ Installing project dependencies 🎉 Copied project files Get started with: cd qrquickBackend This will set up a default Hono project for us. But before we dive in, let's lay down the foundation with a basic directory structure. Usually, I&

I recently reached out on my social networks to gauge interest in developing an application for generating and managing QR codes. Surprisingly, the response was quite positive, with more engagement than I initially anticipated. Despite being on vacation, I'm enthusiastic about diving into this project and laying down its foundations. As with my previous projects, I intend to document the entire process, but with a twist this time: breaking down the blog posts according to the project's progress. In this initial post, I aim to discuss the application's structural planning, the frameworks and libraries it will utilize, and establish some fundamental goals and features. First things first, let's decide on a name for the application. After considering options provided by ChatGPT, I narrowed it down to QRify and QRQuick. While QRify seemed popular, I opted for QRQuick due to its uniqueness. While graphic design and vector illustration aren't my forte, I recognize the

This article serves as a continuation of my previous blog post about the Ewity e-commerce wrapper I developed. Since its publication, I've received feedback, some of which has been constructive. As always, I appreciate constructive feedback and have made adjustments to the source code accordingly. One recurring suggestion I've recently received is to transition to TypeScript. Taking this advice into consideration, I've migrated the entire project to TypeScript. Additionally, I've made some aesthetic changes to better suit a grocery environment. Moving forward, all updates to the project will be made exclusively in the TypeScript repository. Another significant change I've made is adopting a proxy for communicating with the Ewity API instead of directly interfacing with it. This decision was driven by security considerations, as I aim to prevent the exposure of our Ewity API key to clients, which could pose significant security risks. In essence, the objectives of

Recently, I've been assigned the responsibility of developing an e-commerce application that seamlessly integrates with the renowned POS system, Ewity. The primary objective was to establish a platform enabling customers to browse store inventory and make online purchases. Tackling this task presented its challenges, and I'd like to walk you through my approach and the steps I took to bring this project to fruition. Rest assured, I obtained permission before sharing this post. In order to optimize the process, I segmented the project into five distinct phases: authentication, inventory listing, order placing, notifying cashiers of placed orders, and generating bills within the POS system without completing the sale. Additionally, I aimed to avoid maintaining separate databases for these processes, relying solely on Ewity's existing infrastructure. This approach minimizes data duplication, reducing the risk of discrepancies and other complications that might arise with it.