Before I start this post I am super excited to share my first YouTube video on Beyond Coding With Amish! 🚀 Inspired by my experiences at Digikala.com Ladder, I’ve launched this channel to delve into essential skills for success. From mastering both soft and technical skills, career growth strategies, fostering effective teamwork, and navigating project management & engineering management tips, we’re in for an enriching journey! 💼🌱 Let’s learn and grow together!

Lately, I’ve had the opportunity to interview candidates for React Native roles, and I’ve been delving into various categories of questions. One crucial area I always touch upon is security. This question isn’t restricted to any specific field; it applies across the board, whether it’s frontend or backend, iOS, Android, Xamarin, or React Native. It’s essential to gauge a candidate’s understanding and approach to security, no matter the platform or technology stack.

Alright, let’s focus on this screen. You’ve got two inputs and a submit button to send your data. Once you’ve filled in the inputs and hit submit, the server responds with a message: “Your password is incorrect.”

What’s the security issue here? Nearly 70% of candidates struggled to identify it initially. Even after guidance, only 10% could pinpoint it correctly. The rest were stumped.

The problem lies in the server’s response, which inadvertently reveals too much information. By stating “Your password is wrong,” it confirms to potential attackers that they’ve entered a valid email but failed with the password. This provides a clear advantage to attackers, as they can now focus solely on guessing the password without worrying about the validity of the email.

To address this vulnerability, the server’s response should be more generic, indicating that either the email or password is incorrect, without specifying which one. This adds an extra layer of security by not giving attackers any confirmation about the validity of the email they entered.

As a front-end or mobile developer, it’s essential to be aware of such security vulnerabilities and collaborate closely with back-end developers or security experts to ensure that these issues are resolved promptly. Ensuring app security is a shared responsibility, and understanding security issues is crucial for maintaining the integrity of your app.

In the realm of Continuous Integration and Continuous Deployment (CI/CD), maintaining consistency across multiple projects can be challenging. GitLab CI offers a powerful feature called “Shared CI Configurations”, enabling teams to streamline their CI/CD workflows and foster code reuse.

In this blog post, we’ll explore how to leverage shared CI configurations to enhance efficiency and maintain a standardized approach across projects.

Understanding Shared CI Configurations:

GitLab’s Shared CI Configurations allow teams to define CI/CD configurations in a separate repository and then include these configurations in other projects. This approach promotes code reuse, reduces duplication, and ensures a uniform CI/CD setup across different repositories.

Use Case: Reusable CI Configurations for Mini-Apps

Consider a scenario where a development team is managing several mini-apps or modules within a larger project. Each mini-app shares common CI/CD steps, such as building, testing, and deploying. Instead of duplicating these configurations in each mini-app, the team can centralize the CI/CD setup in a shared configuration repository.

Getting Started:

Create a Shared CI Configurations Repository: Start by creating a new repository specifically for storing shared CI configurations. This repository will house the .gitlab-ci.yml file and any scripts or configurations that multiple projects can reuse.

Define Shared CI Configurations: Craft the CI/CD configurations in the shared repository according to the needs of your projects. Consider defining stages, jobs, and environment variables that are commonly used across projects.

# .gitlab-ci.yml in Shared CI Configurations Repository

stages:
  - build
  - test

build_job:
  stage: build
  script:
    - echo "Building the application..."

test_job:
  stage: test
  script:
    - echo "Running tests..."

Include Shared Configurations in Projects:

In each mini-app or module repository, include the shared configurations using the include directive in the project's .gitlab-ci.yml file.

# .gitlab-ci.yml in Mini-App Repository

include:
  - project: 'your-group/shared-ci-configurations'
    file: '/path/to/.gitlab-ci.yml'
    ref: main

Advantages of Shared CI Configurations:

1. Consistency Across Projects: Shared CI configurations ensure that all mini-apps within the project follow the same CI/CD process. This consistency is crucial for a unified development and deployment experience.
2. Ease of Maintenance: Updates or improvements to the CI/CD pipeline can be made in a single location — the shared configurations repository — making maintenance more straightforward.
3. Code Reusability: Reusing CI configurations reduces redundancy and minimizes the effort needed to set up CI/CD for each mini-app. This is especially beneficial in projects with many modules.

Conclusion:

Shared CI Configurations in GitLab CI offer a powerful solution for maintaining a cohesive CI/CD strategy across multiple projects. By centralizing configurations, teams can enhance consistency, reduce duplication, and optimize their development workflows. As teams continue to embrace CI/CD best practices, the use of shared configurations becomes a valuable asset in their toolset.

The automation of software development processes has significantly evolved through CI/CD (Continuous Integration / Continuous Delivery) pipelines. GitLab CI is one of the platforms that offer this feature, allowing developers to automatically trigger pipelines on every commit. However, sometimes you want to prevent running your CI. You have different reasons, like:

1. You are in the middle of feat/fix, and no need to run ci
2. Your commit only includes fixing a typo, changing a word at docs, or …
3. You are testing a feature that does not need a ci
4. …

This list can continue. But one thing is clear Don't run the ci.
In Gitlab ci, you can prevent running ci easily. There are 2 methods for that:

A. Custom Tag at Your message
Put [Skip ci] or [ci Skip] in your commit message.

git commit -m “Your fancy message [skip ci]” or git commit -m “Your fancy message [ci skip]

B. Using Git push options
In this scenario, you can skip ci execution for a specific commit push

git push origin <branch> --push-option=ci.skip or git push -o ci.skip 

At Method B, you can do a lot of cool things. I recommend reading its documentation.

Recently, I had some React Native interviews. In this post, I want to share some questions that they ask me. Pay Attention: I don’t answer them, google it, please!

Soft Skills

1. What is the most challenging task you have had?
   Why this question is important? Because the interviewer wants to measure the scale of your projects. So answer carefully, please!
2. How do you improve your knowledge?
3. Do you can work under pressure? Tell me some examples.
4. How do you manage conflicts at work?
5. What are your strong/weak points? What are your plans for improving them?

Javascript

1. What is the event loop?
2. What is this keyword? how about Context?
3. Do you know Callstack?
4. Differences between var, let, const?
   It is an easy question! But it shows you know
5. How about Hoist Up?
6. How does inheritance work on JS?
7. What are the differences between React and React Native?
8. What are the differences between Js and TS?
9. How does React work under the hood? How about React Native?
10. Could you please describe React Native architecture? The old and new ones.
11. What is Flux? Describe it.
12. What other state managements do you use?
13. Describe your project’s architecture.
14. What is Closure? Stale Closure?

This post will be updated regularly.

In JavaScript, variables declared with let and const are hoisted to the top of their respective scopes, but they are not initialized immediately. Instead, they enter the TDZ until their declarations are reached during the execution of the code.

During the TDZ, if you try to access or reference a variable, a ReferenceError will be thrown. This is because the variable exists in the scope but has not been assigned any value yet.

For example:

In this example, trying to access myVariable before its declaration will result in a ReferenceError due to the TDZ. Once the variable is declared, it can be accessed normally.

The TDZ is a mechanism in JavaScript that helps catch potential errors caused by accessing variables before they are declared and assigned a value. It promotes good coding practices and prevents accidental variable usage before initialization.

There are several ways to handle security in a React app. Here are some best practices:

1. Secure API calls: Use HTTPS for all API calls to ensure data encryption during transit. Avoid making API calls from the client-side directly, as it exposes sensitive information and can be manipulated by attackers. Instead, set up a server-side proxy or use serverless functions to make the API calls securely.

2. Input Validation: Always validate and sanitize user input on both the client-side and server-side to prevent potential security vulnerabilities like cross-site scripting (XSS) attacks. Use libraries like React Hook Form or Formik for client-side validation and implement server-side validation as an additional layer of security.

3. Authentication and Authorization: Implement a robust authentication and authorization mechanism to control access to protected resources. Use industry-standard protocols like OAuth or JWT (JSON Web Tokens) for authentication, and implement role-based access control (RBAC) to authorize users based on their roles or permissions.

4. Password Storage: Never store passwords in plain text. Instead, use a secure password hashing algorithm like bcrypt to store passwords securely. Additionally, consider implementing features like password strength requirements and account lockouts after multiple failed login attempts.

5. Cross-Site Scripting (XSS) Prevention: React provides built-in protection against XSS attacks by default through its use of JSX syntax and automatic escaping of user input. However, it’s still important to be cautious when rendering user-generated content and properly sanitize and validate any dynamic content before rendering it in the UI.

6. Cross-Site Request Forgery (CSRF) Protection: Implement CSRF protection techniques like using anti-CSRF tokens and ensuring that requests made to your server are coming from your own domain. Libraries like csrf or csurf can help with implementing CSRF protection in your React app.

7. Secure storage of Sensitive Data: Avoid storing sensitive information like API keys, secret keys, or database credentials directly in your React app’s source code. Instead, use environment variables or configuration files to store and access such sensitive data securely.

8. Regularly Update Dependencies: Keep all dependencies used in your React app up to date to ensure you have the latest security patches and bug fixes. Regularly review and update your project dependencies to avoid using outdated or vulnerable libraries.

9. Security Testing: Perform regular security testing, including vulnerability assessments and penetration testing, to identify and address any potential security vulnerabilities in your React app. Tools like OWASP ZAP, SonarQube, or Snyk can help in identifying security issues.

10. Educate Developers: Ensure that all developers working on the React app are aware of secure coding practices and best practices for handling security-related tasks. Regularly conduct training sessions or workshops to keep the team updated on the latest security practices.

Remember, security is an ongoing process, and it’s important to stay updated with the latest security practices and vulnerabilities to keep your React app secure.

Hi guys :) How are you today? Did you learn a new thing today?

Everyone needs a mentor. I am trying to improve my web development knowledge. It includes HTML, CSS, JavaScript, TypeScript, React, and so on.

To achieve this goal I follow some great developers and coaches on LinkedIn, Youtube, Newsletters, and Blogs. Here I want to share with these guys.

Linkedin

1. ThisWeekInReact.com
   I follow this page because of sharing React/React Native news.
2. Mathew Dony
3. Sayeh Ghaderi
   Sayeh shares posts about JavaScript.
4. Adrian 🟣 Bogdan
   He is React Developer and shares good posts about React and Next.
5. Addy Osmany
   Addy works at Google. I follow him because he posts nice articles about management, becoming a leader, and so on …
6. Harley Ferguson
   He teaches developers how to accelerate their careers.
7. Murat Ozcan
   Are you interested in Test and Cypress? Great! Follow him.

Youtube

1. Online Tutorials
   If you want to learn HTML and CSS, this is a good option.
2. Web Dev Simplified
   is one of the most famous channels on Youtube to learn CSS and React.
3. Kevin Powell
   He is CSS King.

Newsletters

1. CSS Weekly
2. Your best source of web performance news. Every two weeks.

There are other great developers that share their knowledge. This is my list. If you want to follow me on Linkedin please click here.

The goal for this week was to re-learn about browser lifecycle and to boost performance by gaining a better understanding of page rendering.

I found some great articles that describe a lot of things.

1. How does the browser page lifecycle sequence work?

2. Populating the page: how browsers work

3. How browser rendering works — behind the scenes

4. Page Lifecycle API

5. Browser Life Cycle

Hope to enjoy reading them and improving your knowledge.

1. React components composition: how to get it right
2. The mystery of React Element, children, parents, and re-renders. It is a very important article. It shows some great mysteries.
3. React component as prop: the right way
4. React re-renders guide
5. React launched a new doc. It is much better than the old one. Sebastian Carlos in a post describes React JS Best Practices From The New Docs.
6. Is your React Native application protected against sensitive data theft? Do SSL Pinning today.

Hi guys! Long time no see. After a long time, I am here again. I hope you are well. Let’s jump to today’s post.

CSS is too tricky. You must know what is under the hood of properties to solve complex layouts or bugs.

One of these weird properties is the z-index.

You use z-index when you want a certain DOM element to be on top of another. Sounds simple, right?

But in stylesheets we see:

z-index: 9999999
z-index: 9999999999999

The reason is we do not have enough knowledge about its mechanism. The secret is behind stacking context. But what is stacking context?

One important thing before diving into the deep is to remember that z-index values are not global.

I found 3 great articles that explain z-index and stacking context.

https://www.freecodecamp.org/news/z-index-property-and-stacking-order-css/
https://www.joshwcomeau.com/css/stacking-contexts/
https://web.dev/learn/css/z-index/