Rahul Poonia

Hi 👋 this is Rahul If you are interested in: 💻Software Engineering 📚System Design ☕️Java ☁️ Cloud 🛠️ DevOps 🐳 Docker & K8s 🔑 Security 🐧 Linux ✔️ Follow me → @_rahulpoonia I'll be using Twitter to share my learnings everyday. Join this journey along with me!!

That's all folks🙂 If you enjoyed this post: 1⃣Give it a like♥️ 2⃣Bookmark🔖 for future reference 3⃣Retweet🔃 to share this with your audience 4⃣Follow me🤝 @_rahulpoonia for more of this content. I am sharing my experience with software engineering and other cool stuff everyday!

5⃣ Remote jobs platform : Actively applying in open positions through sites like RemoteOk, AngelList, WeWorkRemotely. AngelList worked for me personally in getting a remote job 3 years back. Also reach out to folks you know for referral. If you have a good network, referrals work like a charm.

4⃣ Open source projects : Start with making a GitHub profile. Make contributions to open source projects of your interest. Also add your own projects here to showcase to a potential employer. Working on projects will give you an edge over others. It showcases you are keen to learn new things.

3⃣ Networking : Connect with like minded people on twitter and LinkedIn. Try to participate in tech conferences and hackathon. Every thing matters to make you standout in crowd.

2⃣ Development skills : Upskill yourself in development projects as well. Backend or frontend whatever interests you more. Always lookout for latest skill that is in demand. If you are starting with backend, python is the way to go. For frontend Javascript and frameworks like React are very much in demand in the market.

Want to crack a remote software developer role in 2024!👇

1⃣ DSA : DSA is still relevant in interviews. Pick one website and try to solve a range of questions from various topics. Personally I like leetcode.

I have been working remotely as software developer for 3+ years. Here are the 5 things you need to do, to crack a remote job in 2024!

Adapter pattern🔌 The Adapter Pattern is a structural design pattern used to allow incompatible interfaces to work together. It acts as a bridge between two incompatible interfaces(called Target and Adapter) by converting the interface of a class into another interface that a client expects. This pattern is particularly useful when integrating new functionality into an existing system without altering the existing codebase. This is required all the time in legacy sytems! Lets look at the illustration to understand it🚀 Components of pattern 1⃣Client: The code that uses the target interface to interact with objects. 2⃣Target: Defines the domain-specific interface that the client uses. This is the existing functionality of system. 3⃣Adaptee: Defines an existing interface that needs adapting. Here we need to use SpecificRequest() functionality in our system. 4⃣Adapter: Adapts the interface of the Adaptee to the Target interface. Adapter inherits from Target class and overrides Request() method. It injects Adaptee as dependency via composition and calls SpecificRequest() in override Request() method. As a result when client class calls Request() on Target class using adapter, SpecificRequest gets executed(). ---------------------------------------------------- That's all folks🙂 If you enjoyed this post: 1⃣Give it a like♥️ 2⃣Bookmark🔖 for future reference 3⃣Retweet🔃 to share this with your audience 4⃣Follow me🤝 @_rahulpoonia for more of this content. I am sharing my experience with software engineering and other cool stuff everyday!

@Franc0Fernand0 Just to add one more aspect about urls, query parameters are also used in authentication. We can pass tokens as part of url. Thanks for sharing Fernando. Great share.

6. Query: This part sends additional information to the server. It begins with a "?" and includes key-value pairs, such as the search term and category in "?color=green". 7. Fragment (Anchor): This works like a bookmark and lets you go straight to a specific part of a web page.

What are all the different parts of a URL? {1/6} ↓

Story pointing 🔢 I have seen colleagues, across teams, saying how futile the whole exercise of story pointing is . Well it is not! Lets understand what story pointing is? It is a key practice in Agile methodologies, primarily used to estimate the effort required to complete a story or task within a project. It involves assigning relative point value to each story, which helps teams plan, prioritize, and track their work more effectively. How to point stories? 1⃣Grooming : Before sizing a story, the story must be groomed before the whole team so that everyone has clear idea as to the requirements and scope of the work at hand. 2⃣Estimation : Estimation of story includes everything viz design, development and testing. A story by definition is an independent end-to-end deliverable. 3⃣ Pattern : Pattern of sizing could be either in fibonacci series, prime numbers or even t-shirt sizes. 4⃣ Meaning of points : The points indicate overall effort and complexity required to complete the story. Do not equate it to time to complete the work. A single point story might take just one day for senior developer while it might take 3 days for junior developer. So time based thinking makes the whole effort subjective. 5⃣ Revealing together : so that estimation happens independently without knowing what other team member is estimating to avoid biases. 6⃣ Consensus building: Anyone who has estimated the size as too big or too small should be a given chance to explain his viewpoint. The idea is to have a consensus. This helps identify any hidden complexities or misunderstandings. Story pointing helps facilitate better planning, more collaboration and communication and identify risks early. It also ensures accountability of work. Here is an awesome tool you guys can use to do story pointing. We use it in our team. Its fun.😃 pointingpoker.com

🌐Domain Name System🌐 Have you ever wondered how domains put in web browser reach the appropriate server? A lot goes behind the scenes. Lets find out🔎🚀 Computers and network devices use IP addresses to locate and connect with each other on the internet. DNS provides a way to associate domain names with their corresponding IP addresses, making it easier for users to access websites and services. Look at the following illustration to understand various parts of DNS and how it is resolved to reach the final destination🎯! Steps involved 1⃣ User puts domain in the browser 2⃣ Browser checks for the domain in Local DNS server cache🛢️ 3⃣ If not found local DNS server reaches out to Root DNS Server 4⃣ Root DNS finds .com in domain and thus returns the address of Top Level Domain name server for .com 5⃣ Top Level DNS server looks for example.com and returns address for SLD name server 6⃣ Second Level DNS Server returns the actual IP of the domain 7⃣ Local DNS server caches it for future reference ------------------------------------------------- That's all folks🙂 If you enjoyed this post: 1⃣Give it a like♥️ 2⃣Bookmark🔖 for future reference 3⃣Retweet🔃 to share this with your audience 4⃣Follow me🤝 @_rahulpoonia for more of this content. I am sharing my experience with software engineering and other cool stuff everyday!

@ujjwalscript Reading someone else's code and understanding it is a skill in itself. Code reviewing, in the similar breath, is also crucial skill.

90% of your job as a developer is navigating sh*t code and making sense out of the unknown. Once you understand that, adding the piece you need is usually simple.

@RaulJuncoV It is really an attitude thing. If you take it in positive spirit it opens up doors for more learning. Makes you understand different points of view.

Feedback is a Gift, even if it's wrapped in sandpaper. Early in my career, I took any comment on my code as a personal attack. Now, I'm hungry for feedback. It may hurt your ego, but different viewpoints teach you to think outside the box. Look for feedback from people you trust; it will be constructive or complimentary.

Anyone planning a release today?

@Franc0Fernand0 Great share Franc. Happy that there exists such playlist. Sad that i did not see it earlier. Already read that awesome book couple of months back.

This course based on the DDI book is pure gold. It contains 89 videos about: - Data Models and Query Languages - Replication and Partitioning - Transactions - Consistency and Consensus - Batch and Stream Processing Hasso-plattner-institut: 100% Free. Here is the link:

Presigned Urls Context : While working with storage services like AWS S3 or Azure storage account you need to provide your application with connection strings to access these services. The problem with this is access given is broad and permanent, not to mention security issues associated with storing these strings in application One alternate to these connection strings and credentials is presigned url! Key features: 1⃣ Permissions: Specify permissions that are to be given like read, write 2⃣ Granularity : Specify the resource that needs to be given access to. Granularity can be till a specific object. 3⃣ Temporary: These are time based. So access is time bound and expires beyond the specified time 4⃣ Secure :  as secret connection strings need not be stored. Ultimately a URL for the specific resource is generated that has token that contains enough information for accessing it. This url can be shared now. These presigned urls are extremely powerful when access is to be given to a third party client or service for a very limited access. Very commonly used in downloading files in web app or shared links in emails. -------------------------------------------- That's all folks🙂 If you enjoyed this post: 1⃣Give it a like♥️ 2⃣Bookmark🔖 for future reference 3⃣Retweet🔃 to share this with your audience 4⃣Follow me🤝 @_rahulpoonia for more of this content. I am sharing my experience with software engineering and other cool stuff everyday!

If the calling service does not expect a response, queue based asynchronous is the best approach. I have seen architectures where Http is used, even when calling service is really not expecting a response and the called service simply returns 202(accepted) instead of your regular 200 signifying the request will be processed. I always prefer queue brokers in these kind of situations.

Many of the problems with microservices appear only once you hit production. Choosing the right communication style can save you 50% of them. You can classify the communication into major groups. Synchronous & Blocking: - REST over HTTP - GRPC With request-response (synchronous), we expect the response to return to the instance that sent the request. Asynchronous & Nonblocking: - Queue-Based brokers - Even-Driven - Common Data With asynchronous communication, the response can come back later, even to a different instance. One of my favorites is Even-Driven Event-driven communication is, by definition, asynchronous. A microservice emits an event, and other microservices can react if they are interested. An event is a statement that something happened (for example, OrderPlaced). With event-driven communication, a microservice doesn't tell another microservice what to do. It's up to downstream microservices to make a judgment call on what they do with that information. Two things to consider: 1. Event-driven collaboration can promote more loosely coupled architectures. But, understanding how the system behaves requires more work. 2. You also need a message broker, which can further complicate matters. Request-response and event-driven both have their place. Some problems just fit one model more than another, and it's common for a microservice architecture to have a mix of styles. Sometimes it is about personal choice, what's yours?

Understand how a feature of a product is delivered in an agile based organization from start to end in this awesome post!