DEV Community: daltonfury42

In case anyone is looking to learn serverless by doing a hands-on project

daltonfury42 — Sat, 09 Oct 2021 17:14:36 +0000

In case anyone is looking to learn serverless by doing a hands-on project, let me know.

I have a beginner friendly backend requirement.

It will be simple CRUD of three resources.
Data will be stored to DynamoDB.
For language, you can use golang or node.
All code you write will be open source under GPL.
Our repositories are participating in Hatoberfest.

The project: simplq.me is an open source queue management software. The backend is written in Springboot and we want to migrate it to serverless as it's more economic given our traffic volume.

https://github.com/SimplQ/simplQ-frontend
https://github.com/SimplQ/simplQ-backend

What's your experience with VSCode for Java development?

daltonfury42 — Sun, 30 May 2021 13:47:41 +0000

Anyone using VSCode for Java development?

I've been trying to set it up, it's partially working, looks like I would go back to good old IntelliJ.

Have you tried it? Did you stick on with it?

PS: VSCode is a great TextEditor + Git + Terminal + Docker + File Comparison Tool for me at work, where I mostly write Java in IntellIj.

Understanding Git EP01: The Five Zones of Git

daltonfury42 — Sun, 23 May 2021 15:30:48 +0000

Hello everyone.

Last week at work, a sudden requirement tested my git skills. I had to go through and understand two complex git use cases: git-subtree and git-filter-branch. While reading through long articles and manpages, I realised that even though I have been using this tool for years, I don't really understand what's happening under the hood.

So I set out to understand the tool, posting my notes from watching an intro course on Git Core Concepts that I found online.

The three main zones:

If you want to read the git documentation, it's very important to know the git terminologies so that you can understand what's written.

Working directory is your code present in your filesystem. These are the regular files and folders and they have nothing to do with git.
Index, also popularly referred to as "staging area", is where we gather our changes before making a commit out of it.
The local git repository that forms the collection of all commits, and other version control data.

How to navigate between the first three zones:

Working Directory to Index: git add <file>...

Index back to Working Directory: git restore --staged <file>...

Index to Local repo: git commit -m "<commit message>"

Local repo to index: git reset -—soft HEAD~1

Local repo to the working directory: git reset -—mixed HEAD~1

Local repo to thin air (you lose the change): git reset —-keep HEAD~1

Commits have a link to their parent like a linked list. Merge commits have two parents. You can also get more than two in what is called "octopus".

Lifecycle of a file:

Untracked: When a file is created, it's "untracked". Git doesn't know about it.
Indexed: git add make it "indexed" / staged.
Unchanged: git commit makes it "unchanged". The file on fs matches with what git knows.
Modified: now when you modify this file that's tracked by git, it becomes "modified". Now when you stage and commit it, it goes through states (2) and (3) again.
Removed: finally one last state is "removed" when you do a git rm and commit that change. It's just another commit that removes the file.

What is stash?

Building on the terminology from the last section, imagine there are some untracked and some indexed files, and you are not ready to commit yet. Suddenly your manager comes and tells you that there is a priority task that you need to immediately take up.

Stash is a fourth zone where you can keep aside (stash away) these tracked and untracked files temporarily while you jump to something else.

Move changes to the stash: git stash -u <file>...

Move changes back from the stash: git stash apply --index

Fifth zone: remote repo

You can push your commits to a remote shared git repo, and pull other people's commit from it into your local repo.

Two ways for beginners to start using Docker to increase developer productivity

daltonfury42 — Sat, 08 May 2021 10:44:57 +0000

Hii.. thanks for stopping by. What you will find in this post:

What is docker? What does it solve?
Why should you know about docker?
Three ways in which you can start using docker every day.
Why you should learn docker and have it in your dev toolbox.

Before we come to what's in this for you as an individual, a quick introduction to docker, and the problem it's trying to solve:

Docker is a software platform for building applications based on containers — small and lightweight execution environments that make shared use of the operating system kernel but otherwise run in isolation from one another.

Four phases from the above sentence sum it well. Docker provides a:

small and lightweight
isolated
execution environment
based on "containers"

What does this mean? It means that with docker you can package your application, along with the environment to run it.

Why is this a big deal? Because before containers, people used to just share the application binary. When Jenna sends Ria a program that she wrote and compiled, this is what might happen before docker:

It didn't happen just between the developer and QA, but it was happening everywhere. QA tested the program, but when he deployed the program into production it broke because... for example, he had node v12 on his test system, while in production they were still on node v10.

Or maybe you wrote your awesome code on a Mac OSX 11.3 but someone wants to run it on his Ubuntu 18.04 where node is not even installed. Bleh.

Yuck. It was a total mess! And the solution? Package the program as well and the environment together. And thus was born containers.

You can package your application along with all its dependencies into a docker container.

But why should I know about docker?

Now you might be telling, "Hey, I am good without docker because I don't have these sort of problems to deal with".

Hmm. Not really, buddy. People have already packaged a lot of applications as Docker images and have made them publicly available. So you can use docker to grab and use any software when required.

How you can use docker in day to day life?

These are some ways in which you can take advantage of docker to boost your own developer productivity. These are three ways in which I leverage docker.

1. No more need to install software on your laptop.

I'm just making this up, say one fine morning, someone comes to you and says that you need to install and run a new type of database named "FoobarDB" on your laptop... now that you know about docker, you just go to google and type "foobardb docker". You do get the docker image name, and then type in:

docker run foobardb

That's it. FoobarDB is up and running on your machine. How awesome is that?

What if you want to run multiple versions of the same DB at the same time. Fret not,

docker run foobardb:6.2
docker run foobardb:3.2
docker run foobardb:8.2

I mostly use it to run databases, so for example, if you want to run Postgres:

Almost anything you need for development is available through 100s of images, created either by official maintainers or the community.

Here is the Postgres image on DockerHub. Instructions and different configurations for the images are available along with it on DockerHub.

Now that you know about this, next time you are looking at different ways of installing software, take the docker route if they provide docker images:

2. Get a Linux environment on your Mac.

I am a Linux lover but have to use a MacBook at work. There are things that I like to do from a linux shell, so I have a ubuntu image running:

docker run -d --name myubuntu ubuntu

This is where "lightweight" and "environment" helps...

You get the full ubuntu "environment", but since it's just an environment, it's lightweight, you get the entire OS feel, and it takes under 5MB when not being used!

To summarise, docker is awesome, I wanted to cover the absolute basic usage of Docker in this post. It's highly recommended that you start using it, there are a lot of other advanced things that you can do to achieve it.

No software needs to be installed locally. So the system is clean.
You can run multiple version of the same software.
You can delete the container and start fresh anytime.
Dependencies for any software is packaged along with it.
Docker is production-ready software.
There are hundreds of public images available for almost anything that you need for software development.
Docker images/containers are platform-independent. So you can generate a docker image/container on a Linux machine and run it on windows/mac / any other os supported by docker.

I'd love to know in the comments about other ways you've seen docker being used to improving dev productivity. Thanks for reading. :)

I do 1-1 mentoring for young developers, you can book a slot here if you are interested.

My first attempt at micro-SaaS; suggestions and feedback please.

daltonfury42 — Sat, 17 Apr 2021 11:49:56 +0000

One Friday evening, on pre-covid good old days, me and my friends went to a very busy fine dine restaurant in HSR Layout, Bangalore. There was a crowd in front of the restaurant, and two muscular men stood with a notepad, I gave my name and contact number, and we chilled around, occasionally pushing through the crowd to ask if our turn was up.

Later in the office, there was a free help checkup for all employees, and I went multiple times, only to come back because there was a big queue. Once the lockdown was announced, unable to go outside and chill our weekends, we saw on the TV or when we stepped outside were long queues.

These few things made me think if there is some generic problem here that we could use technology to solve. Thus was born the idea of Simpl-Q (Simple Queue), a "generic" virtual crowd management website.

The idea was very simple. Instead of waiting in a queue, enter a link or scan a QR and wait using your smartphone. A virtual waiting room.

No standing in an unfair physical queue
No wondering if your turn is approaching.
Crowded businesses can use the system to make the customer waiting experience more delightful.

I worked on a basic prototype, iterated over it a couple of times (more on that, and some learnings here), and we have a fully working MVP now: http://simplq.me/

SimplQ is not a startup. It is just an idea and a MVP as of now. Honestly, it's more of a hobby project / experiment than a startup idea. We have no plans to monetize it. Our code is open source, we have around 30 active collaborators from around the globe who have contributed to the project.

I am currently thinking of making an android app that would listen in to events on the queue that the user created (here), and send out SMS in the background to the people when they join the queue. Otherwise thinking of how to market the app and get some real users.

Thoughts? Looking for any feedback, ideas, or any advice. Thanks.

Backend Musings E01 - Stability vs Velocity.

daltonfury42 — Sun, 04 Apr 2021 18:55:46 +0000

Any complex software must be cynical if it has to be stable. Such systems expect bad things to happen, and do not trust external external systems. They are designed and developed in a way that it doesn’t even trust itself, so internal barriers are put to protect itself from failures. They also avoid getting too intimate with other systems, because it could get hurt.

When writing complex enterprise software, it is practically impossible to ensure bug free code when you release to production. In an early stage startup environment, the focus is on implementing features at minimal cost, which would lead to choosing the easiest design over the more costly but correct design. This happens mostly because you have a very short runway before you go bankrupt, and the business team might be following multiple leads or features out of which only one or two would ultimately make the product a success.

Highly stable design usually costs the same to implement as the unstable one. The product as a whole being “stable” doesn’t mean that your individual applications or services have to stay up and running, but rather that the user can still get the work done. No matter how smart the engineers you hire are, individual services are going to crash. A robust system keeps processing user requests even when there are component failures.

Before the catastrophic failure, some component of the system has to initially fail. The key is to contain the trigger, preventing it from spreading and taking the entire system down. Denying the inevitability of failures robs you of your power to control and contain them. Once you accept that failures will happen, you will have the ability to design your system’s reaction to specific failures.

At each step in a chain of failure, the crack may accelerate, slow or stop. A highly coupled system with many degrees if coupling offers more pathways for the cracks to propagate along.

The initial design decisions you take has a huge impact on stability in the long term, but those ironically are the exact decisions you have to make in the early stage with the least amount of knowledge. These are also sadly the decisions which are the most difficult to reverse later on. Stability can’t and should not be traded for velocity.

Thoughts?

SimplQ: How we went from a hackathon project to a fully open source project with contributors

daltonfury42 — Sat, 16 Jan 2021 16:56:59 +0000

TLDR; What started a few months ago as a small hobby project is slowly gaining traction as an open source project: github.com/SimplQ. Key lessons learned:

Get a Minimum Viable Product up and running.
Iterate over a Design Prototype.
Work on a Product Roadmap and create small independent tasks.
Use labels to let new collaborators identify easy issues to start with (up-for-grabs, good-first-issue etc).
Add an informative readme and add detailed setup instructions, make the local dev environment easy to set up.
Be open-minded when discussing solutions for issues and leave helpful reviews on PRs.
List your project on websites where people look for projects to collaborate on
Invest in good automation, CI/CD (TravisCI is free for public repositories).
Use affordable cloud hosting. I used AWS free-tier (Got AWS Activate $1000 founder's credits).
Invest in a meaningful domain name.
Create a Github Organisation, update the description and create a simple logo. It gives your project a professional look... these things matter.

The key is not to find collaborators, but to make your project collaboratable.

Now the whole story...

In early April this year, we were four young software engineers locked up in our apartment, with no plans for the weekend, and wondering what to watch on Netflix.

The Idea

I've always been awed by apps like Splitwise, where technology is used to create a free software that solves some annoyances in our life. That's when my flatmate saw a newspaper article (yeah, he reads the newspaper) about how there are long queues in front of grocery stores, beverage shops etc during the lockdown. Us being reasonably tech-savvy, soon the topic of discussion changed to see if we could build a simple website, which would allow people to enter a queue virtually, without having to stand in a line. And voila, SimplQ was born.

The idea was very straight forward: If someone wants to manage a crowd using a queue, go to simplq.me, give the queue a nice name and your queue dashboard is created instantly. You can then manage people in the queue, add and remove, notify, call them up etc. A joining link / QR code is generated, which can be stuck onto wherever people used to line up, and now instead of waiting in the line, they can get into the queue by going to the link.

The database structure, backend, and the screens to be build were quickly finalised on a notebook, and we set out to work developing a basic MVP. Most of the work was completed in a weekend. Weekdays went with us focusing on our day jobs. We didn't want to leave it half done, so we worked on it over the next few weekends. We also enrolled in a Hackathon with this idea, which was very helpful as it gave us a deadline.

By the end of the hackathon, a fully functional prototype was completed.

Open Sourcing

Weeks went by, after which we decided that we should productionize it, so we worked on it in our free time to see if we can turn it into something that people would gladly use. We did two things:

1) Redesigned the UI to give it a more professional look. I got my artistic friend to help out. He learned and work on a new design prototype using Adobe XD.

2) We decided to open source the tool.

By this time, our companies had gone completely remote, we left Bangalore and went to our hometowns. We met online regularly over the weekend and iterated over the design prototype. This exercise gave three benefits:

We could finalise on a design, and everyone had a clear picture about what is to be done, and what it's going to look like at the end.
We discussed and incorporated a lot of UX improvements which we would have missed while implementing. The cost of iterating over a design prototype is lesser than iterating over an already implemented product.
We were able to take the design, and use it to create an implementation roadmap, and then break into small tasks. The design link and screenshots were used heavily in the issues created, and this proved to be very helpful as anyone why was interested in picking up an issue had a clear idea about the task.

Though we used XD I've also seen Figma being used a lot for prototyping. We haven’t had a chance to try it out yet, but free plans for both have all that's needed. If you are a creative mind like Akash, there are tons of tutorials for both the tools available online to get you started.

It is very important to have a Readme.md for the project, it should have detailed setup instructions to clone the repo and get the code running locally (ours here). Also needed is a Contributing section with some instructions(ours here).

Once we had a design, next was a website roadmap. It gives anyone who want to help out an idea about what's been planned, and how they can contribute in a way that their work fits into the project's overall plan. (ours here)

The key is not to wait for collaborators, but make your project "collaboratable". One of the biggest learning was to break a problem into independent tasks, and create well-defined issues on GitHub. The XD design that we created paid off. You can find a sample issue here. Someone looking at the issue should get a clear understanding of the task, then they send a PR most of the time.

The code should be easy to maintain and easy to change. We kept this in mind, and had to refactor and iterate till the code became decently S.O.L.I.D:

Once you create your well-defined issues, the next step is to label them properly. We use labels like You can do this and Good First Issue to mark issues that don't have any blockers which someone new can readily work on. People/tools discover open issues on Github through labels.

After this, list your project on sites where people look for open source projects to work on:

https://up-for-grabs.net/#/
https://goodfirstissue.dev/
https://github.com/MunGell/awesome-for-beginners
https://firstcontributions.github.io/

In the last few months, I also finished two books which were really helpful, The Lean Startup which speaks the importance of thinking MVPs and Zero to One which is a good startup myth buster.

Finally it proved very helpful that my good friend @maaveric was around to review all my PRs. We reviewed each other's code. When your code goes through someone's review, you naturally start structuring your PRs well, and maintain the code quality.

There are some more points in the beginning of the article that I did not cover in detail. Let me know in the comments if there are any specific questions. I will encourage you to give this a try, you will learn a lot along the way. Thanks for reading!

If you would like to collaborate with me on SimplQ, do check it out. Feature ideas, bug reports, feedback and suggestions are all welcome. (You can raise them as issues here). Please do comment on the code structure and how we could improve there if you are a seasoned web developer. My CSS is horrible, I think it can be improved.

React/CRA: Invitation to Collaborate to SimplQ

daltonfury42 — Sat, 03 Oct 2020 22:11:11 +0000

We maintain a web based queue management software called SimplQ, that anyone can use to create instant queues to manage crowd with a smartphone.

We revamped our UI, and we have been getting a lot of collaborators thanks to #hacktoberfest

It's a straightforward React CRA app. We have a lot of easy to fix issues and have been merging lot of quality PRs:

Open Issues: https://github.com/SimplQ/simplQ-frontend/issues

You can see the site here: https://simplq.me/

AWS SES + Gmail = Free Business Email ID

daltonfury42 — Sat, 12 Sep 2020 19:50:15 +0000

My website is hosted on AWS Free Tier, and I wanted to create a free company/business email address for people to contact me. If you are already on AWS, and want to create an email address like contact@simplq.me it doesn't cost anything.

What you need:
1) An AWS Account
2) A domain name (simplq.me in my case)
3) Gmail account (Other email services should also work)

What you don't need: A GSuite Account

(If your domain is on Google Domains, setting up email forwarding is easy.)

I've covered all the necessary steps in brief, but if you need help or get stuck somewhere, let me know in the comments.

If you want two way communication, not all regions support it. I set this up in us-west-2 (Oregon) even though my website is hosted in ap-southeast-1 (Singapore).

Setup SES - Simple Email Service

On AWS Console, switch to us-west-2, go to SES, and verify your domain:

If your DNS is managed by Route53, Amazon can automatically update the entries, click on "Use Route53" button on the next page. Otherwise, you have to manually set the entries in your current DNS registrar.

Verify Your Current Email

This step is easy, your current Gmail address that you want Amazon to relay all communications to, verify it with SES.

You'll get a confirmation email, as part of the verification process.

Configure SES Email Forwarder

In the coming steps, we will configure SES to trigger a lambda which will forward emails to our personal email.

Create a blank Node.js 12.x runtime Lambda function with no triggers in the same region, and use this file as the function code.

There is a config object in the code which requires some tweaking:



var defaultConfig = {
  fromEmail: "contact@simplq.me",
  subjectPrefix: "",
  emailBucket: "<s3-bucket-name>",
  emailKeyPrefix: "mails/",
  allowPlusSign: true,
  forwardMapping: {
    "contact@simplq.me": [
      "<your-gmail-id>@gmail.com"
    ]
  }
};

fromEmail should be the business email which your customers would see. We will later create an S3 bucket to store our emails. Choose a bucket name and give it as emailBucket. In the forwardMapping section, you should configure the gmail address which you verified in the previous step.

arithmetric/aws-lambda-ses-forwarder is a awesome repo, it supports many more configurations, you should check it out if you want to create and forward multiple emails, or forward emails to multiple people.

Attach this policy to the service role of the Lambda, to give it access to the S3 bucket, and also SES:



{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject"
            ],
            "Resource": "arn:aws:s3:::<s3-bucket-name>/*"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "ses:SendRawEmail",
            "Resource": "*"
        }
    ]
}

Create a Rule in SES

This ties everything together, go back to SES console and create a new Email Receiving -> Rule Set. You will set a rule, where you configure two "Actions", one to save all emails to a S3 bucket which you can create from this screen, and another to trigger the Lambda created in the previous setup to forward the mails. Use the below screenshot as reference:

At this point, if you send an email to your business email, the personal Email ID should receive it. Test and make sure that it works, use Cloudwatch Logs for the lambda to debug in case of issues.

Configure Gmail

Next is to add this new email as a new identity to your Gmail account. Go to SES's SMTP Settings and create a new SMTP Credential.

At the end, you'll get a username and a password, which you should add to your Gmail Settings:

Last Step - Verification

Initially your newly configured Amazon SES service will be quarantined (sandboxed) by Amazon as a measure of protection against possible abuse and spam. To remove it from quarantine and allow normal mailing, as the last step, you need to open a support ticket to Amazon and fullfill a request. Otherwise you will see how the emails you send bounce with the following error message:



554 Message rejected: Email address is not verified. The following identities failed the check in region ...

They approved within minutes in my case. Go to Sending Statistics section to raise a request:

That's it! Your business email is ready to use. Let me know in the comments section if you face any issues. Hope you enjoyed it.

If you want to reach out to me for consulting or mentoring, you can book a slot here.

SimplQ, a Modern Web Based Queue Manager

daltonfury42 — Wed, 10 Jun 2020 16:31:54 +0000

I've recently been inspired by services like jit.si, scribble.io where you go, generate an instant link and share it with others. As an experiment on how this model can be applied for crowd management, me and a few friends have developed SimplQ.me, a website where anyone can go create a queue and use it to keep people in a... queue. :p

Some screenshots...

The web app is really simple, the first screen shows how someone can create a queue and the second screen is the queue admin page, where you can manage people who have joined. The third screen is what a person who is waiting in the queue will see.

Once people start queuing up, you can notify users by clicking on the bell icon. People can give phone numbers while joining the queue, so you can click on the person to call them. We are working on integrating with an SMS service, so that the users can also be notified via SMS. Also a design overhaul is being planned.

The frontend is built with React, backend in Java and all the code is open source and is available here on gitHub. Feel free to fork and improve if you have any cool ideas in mind :)

https://simplq.me