Forem: linhvuquach

What are the common mistakes a person makes on the path to becoming Senior Software Engineer?

linhvuquach — Sat, 23 Mar 2024 14:51:04 +0000

I'll keep providing you with further perspective today, so you can identify and save time when you're trying to become a high-level Software Engineer.

Boost your perspective by kook at my last blog here to Harnessing The 80/20 Principle For High-Paying Software Engineering Roles.

Efficiency Unleashed: Harnessing The 80/20 Principle For High-Paying Software Engineering Roles | by linhvuquach | Mar, 2024 | Medium

linhvuquach ・ Mar 23, 2024 ・
linhvuquach.Medium

Becoming a senior software engineer is a significant milestone in one's carer, but it requires not only technical skills but also a strategic approach to career development.
Here's a step-by-step guide to avoid common mistakes and navigate your career path effectively.

✒️Phase 1: Entry Level (0–2 years)

Mistake: Jumping too quickly into advanced technologies without mastering the fundamentals.

How to avoid:

Step 1: Focus on mastering core programming languages (e.g Python, C#, Java, C++) and data structures/algorithms.
Step 2: Engage in projects or internships that reinforce these fundamentals
Step 3: Seek mentorship from experienced developers to understand best practices.

🏋️Phase 2: Mid Level (2–5 years)

Mistake: Getting comfortable with a single technology stack without exploring broader areas of software development.

How to avoid:

Step 1: Continuously learn new technologies, frameworks, and tools.
Step 2: Work on cross-functional projects to gain exposure to different parts of the software development lifecycle.
Step 3: Attend conferences, workshops, and online courses to broaden your skill set.

😎Phase 3: Senior Level (5–10 years)

Mistake: Focusing solely on technical skills and neglecting communication, leadership, and mentorship abilities.

How to avoid:

Step 1: Develop strong communication skills, both written and verbal, to effectively convey complex technical concepts.
Step 2: Take on leadership roles in projects or teams to hone your ability to lead and delegate tasks.
Step 3: Actively mentor junior developers and share your knowledge and experiences.

😎Phase 4: Lead/Principle Engineer (10+ years)

Mistake: Resting on laurels and not continuing to evolve and innovate.

How to avoid:

Step 1: Stay updated with industry trends and emerging technologies through continuous learning.
Step 2: Challenge yourself with complex problems and seek opportunities for professional development.
Step 3: Contribute to open-source projects, attend tech meetups, and engage in broader tech community.

🎁Bonus

Networking: Build a strong professional network through your company, conferences, meetups, and online communities like GitHub and Stack Overflow.

Feedback: Solicit feedback regularly from peers, managers, and mentors to identify areas for improvement.

Self-Awareness: Continuously reflect on your strengths, weaknesses, and career goals to ensure you're on the right path.

⏹️Conclusion

Avoiding common mistakes on the path to becoming a senior software engineer requires a combination of technical excellence, soft skills development, continuous learning, and strategic career planning.

When you find this post informative, don't forget to share it with your team and colleagues, thanks.

You can reach me on Twitter @linhvuquach
to get my new blog every week with a bunch of categories like software engineer, problem-solving, and how to make your product …

See ya!

How to save datetime data that is relevant to multiple countries or time zones?

linhvuquach — Sun, 17 Mar 2024 09:39:42 +0000

Solution

When you need to save datetime data that is relevant to multiple countries or time zones, it's important to follow best practices for handling time zones and storing datetime information. Here are the steps you can take to achieve this:

Use a Consistent Time Zone Choose a reference time zone for your application. It's common to use Coordinated Universal Time (UTC) as the reference time for storing datetime data because it's a standard time zone and doesn't have daylight saving time changes. When storing datetime values, always store them in UTC

// The example below just assumes local time
// In reality, we get local time from end users

// Convert a Datetime to UTC
DateTime localTime = DateTime.Now; // change for other DateTime value
DateTime utcTime = localTime.ToUniversalTime();

// Convert a DatetimeOffset to UTC
DateTimeOffset localTime2 = DateTimeOffset.Now; // change for other DateTimeOffset value
DateTimeOffset utcTime2 = localTime2.ToUniversalTime();

Convert to Local Time when displaying When you need to display datetime data to users, convert the stored UTC datetime to the local time zone of the user or the relevant country before rendering it. This ensures the users see times and their local time.

// 👇️ Example date and time in UTC
const utcDate = '2022-11-16T11:02:17Z';

const date = new Date(utcDate);

// 👇️ Wed Nov 16 2022 18:02:17 GMT+0700 (Indochina Time)
console.log(date);

// ✅ Convert to Local time
console.log(date.toLocaleString()); // 👉️ 11/16/2022, 6:02:17 PM

Identify User Time Zones If your application has user accounts or settings, allow users to specify their preferred time zone. Store this preference in their user profile or as a session variable. When display datetime data to the user, use their selected time zone for conversion.

// Assuming you have an event object with a dateTime and timeZoneId property
const event = { dateTime: "2023-11-11T15:00:00Z", timeZoneId: "America/New_York" };

// Parse the dateTime string and apply the user's preferred time zone
const eventTime = new Date(event.dateTime);
const timeZone = event.timeZoneId;
const eventTimeInUserTimeZone = eventTime.toLocaleString("en-US", { timeZone });

// Display the eventTimeInUserTimeZone to the user
console.log("Event time in user's local time: " + eventTimeInUserTimeZone);

Conclusion

When working with datetime data, I hope my post todays helps you find a solution to the relevant problem. To learn more about some real-case examples, I also recommend you read the topic I've provided below with references.

When you find this post informative, don't forget to share it with your team and colleagues, thanks.

You can reach me on Twitter @linhvuquach
to get my new blog every week with a bunch of categories like software engineer, problem-solving, and how to make your product …

Cheers! 🍺🍺

References:

https://stackoverflow.com/questions/44965545/best-practices-with-saving-datetime-timezone-info-in-database-when-data-is-dep

Clean Architecture In Enterprise Application

linhvuquach — Thu, 08 Feb 2024 01:41:45 +0000

A brief introduction to Clean architecture

Clean architecture is a software architecture guideline proposed by Robert C. Martin(Uncle Bob) that aims to build scalable, testable, and maintainable software. It's derived from many architectural guidelines like Hexagonal Architecture, Onion Architecture, etc. over the years.

Clean Architecture concepts

Clean architecture is a software architecture pattern that aims to achieve the following goals:

Independent of frameworks: The core business logic of the application should not be dependent on any specific framework or technology. This makes the application more flexible and easier to maintain.
Testable: The business logic should be easily testable in isolation from the rest of the application.
Maintainable: The code should be well-organized and easy to understand. This makes it easier for devs to make changes to the application without breaking things.

The basic principles of clean architecture are:

Dependency rule: Dependencies should always point inwards.
Abstraction: Use interfaces to abstract away the details of the implementation.
Separation of concerns: Separate the different parts of the application into different layers. This makes the code easier to understand and maintain.

Layers in Clean Architecture

1.Entities

This layer contains enterprise-wide business rules and is independent of the other layers. In OOP, this is the Object with methods and properties that comply with the Encapsulation principle - only inside the Object can change its own state.

Example: Entity could be a User object that contains properties like Age, etc. The Age property can't be less than 1. If we need to change Age, we must write a public function set Age, which is also responsible for checking conditions related to Age.

The business logic of the Entities layer won't care about or depend on the business logic in external layers such as Use Cases. Assuming the user must be 18 years old or older to create an account, the Age attribute rule in Entities remains unchanged.

2.Use cases
This layer contains application-specific business rules and is dependent on the Entity layer.

Example : The use case could be a CreateUser class that contains methods for creating a new user.

The business logic of the Use Case won't care and depends on where the data comes from, what libraries are used as adapters, how the data is presented, etc. Because that is the task of the Interface Adapters layer.

3.Interface Adapters
This layer contains adapters that convert data from the Use Case layer into a format that can be displayed by the user interface

Example: Interface Adapters could be a UserController class that handles HTTP requests and responses for user-related operations.

Thus, the input and output data at the Interface Adapters layer only needs to be sufficient and reasonable. It won't care how specifically the data will be displayed or collected. Because that is the task of the Frameworks & Drivers layer.

4.Frameworks and Drivers
This layer contains frameworks and tools that support the other layers such as devices, web, applications, databases, etc.

Example: An example of this layer could be a Database class that handles database operations for the application.

This table below is to help you quickly keep track of layers in Clean architecture.

Name	Content	Dependency
Entities	Core business data and rules.	None
Use Cases	Application-specific business rules.	Depends on Entities, independent of Frameworks
Interface Adapters	Input and output mechanisms (UI, databases, frameworks).	Depends on Use Cases, independent of Frameworks
Framework & Drivers	External tools, frameworks, and technology-specific details.	Depends on Interfaces and Use Cases

Project structure

🛠️MyAppServiceSolution/
├── #️⃣MyApp.Shared/ - (It contains shared components, which aren't required in Clean architecture. It serves as your common service or packages in the future)
│ └── …
├── #️⃣MyApp.API/
│ ├── 📂Controllers/
│ │ ├── UserController.cs
│ ├── 📂Extentions/ - Contains config extensions for the API layer
│ │ ├── AppExtension.cs
│ ├── Startup.cs
│ └── …
├── #️⃣MyApp.Dtos/
│ ├── 📂Users/
│ │ ├── UserRequestModel.cs
│ │ ├── UserResponseModel.cs
│ └── …
├── #️⃣MyApp.Application/
│ ├── 📂Services/
│ │ ├── 📂Interfaces
│ │ ├── IUserService.cs
│ │ ├── UserService.cs
│ ├── 📂Dtos/
│ │ ├── UserDto.cs
│ └── …
├── #️⃣MyApp.Domain/
│ ├── 📂Entities/
│ │ ├── User.cs
│ ├── 📂Repositories/
│ │ ├── IUserRepository.cs
│ └── …
├── #️⃣MyApp.Infrastructure/
│ ├── 📂Persistence/
│ │ ├── 📂EntityConfigurations
│ │ ├── 📂Migrations
│ │ ├── 📂Repositories/ - Implement interface repositories from MyApp.Domain
│ │ │ ├── UserRepository.cs
│ │ ├── 📂Extentions/ - Contains config extensions for the Infrastructure layer
│ │ │ ├── ModelBuilderExtensions.cs
│ │ ├── MyAppContext.cs
│ └── …
└── #️⃣MyApp.Tests/
├── 📂MyApp.UnitTests/
├── 📂MyApp.IntegrationTests/

Map project structure to Clean Architecture

Name	Layer	Content
MyApp.API	Interface Adapters	Could be considered as the entry point for your application, interacting with the application layer.
MyApp.Application	Use Cases (Application)	It contains services that implement application-specific business rules.
MyApp.Contracts	Interface Adapters	The interface layer for Data Transfer Objects (DTOs) is shared between layers.
MyApp.Domain	Entities and Business Rules (Core layer)	It contains business entities, repositories, and repository interfaces.
MyApp.Infrastructure	Frameworks & Drivers	It manages the database (persistence), contains external configuration extensions, and implements repository interfaces.

I'll skeleton Clean Architecture in the next chapter. See ya.

You also reach my blog on medium.com by this link: https://linhvuquach.medium.com/clean-architecture-in-enterprise-application-47d94015c93a

Cheers!

References

N-tier Architecture In Enterprise Application

linhvuquach — Sun, 07 Jan 2024 11:45:50 +0000

N-tier

An N-tier architecture divides an application into logical layers and physical tiers. These are the presentation tier, processing or logic tier, and data tier.

Layers are a way to separate responsibilities and manage dependencies. Each layer has a specific responsibility. A higher layer can use services in a lower layer, but not the other way around.

Tiers are physically separated, and they can also run on separate machines. A tier can call to another tier directly, or use asynchronous messaging (message queue). Although each layer might be hosted in its own tier, that's not required. Several layers might be hosted on the same tier.

Benefits

Physically separating the tiers improves scalability and resiliency.
The separation of concerns into distinct layers promotes modularity, making it easier to understand, develop, and maintain each component independently.
Component within each tier can be reused in different parts of the application or even in different parts of the application or even in different applications altogether.
Less learning curves.

Drawbacks

Complexity: N-tier architecture can be complex, as it involves multiple layers and components
Performance: Communication between different tiers, can introduce latency and overhead.

Project structure

🛠️MyApp.sln/
│
├── #️⃣MyApp.API/                   # Presentation Layer (API)
│   ├── 📂Controllers/              # API Controllers
│   │   └── TodoController.cs
│   ├── Startup.cs                # Application startup configuration
│   └── ...                        # Other API-related files
│
├── #️⃣MyApp.BusinessLogic/         # Business Logic Layer
│   ├── 📂Interfaces           # Interfaces for MyApp service
│   |     ├── ITodoService.cs           
│   ├── 📂Models                   # TODO (models | entities)
│   |     ├── Todo.cs                   
│   ├── TodoService.cs            # Implementation of MyApp service
│   └── ...                        # Other business logic files
│
├── #️⃣MyApp.DataAccess/            # Data Access Layer
│   ├── ApplicationDbContext.cs   # Entity Framework DbContext
│   ├── TodoRepository.cs         # Repository for MyApp data access
│   └── ...                        # Other data access files

I'll skeleton N-tier architecture for you in the future piece, guys.

Cheers!

Forem: linhvuquach

What are the common mistakes a person makes on the path to becoming Senior Software Engineer?

Efficiency Unleashed: Harnessing The 80/20 Principle For High-Paying Software Engineering Roles | by linhvuquach | Mar, 2024 | Medium

linhvuquach ・ Mar 23, 2024 ・ linhvuquach.Medium

✒️Phase 1: Entry Level (0–2 years)

🏋️Phase 2: Mid Level (2–5 years)

😎Phase 3: Senior Level (5–10 years)

😎Phase 4: Lead/Principle Engineer (10+ years)

🎁Bonus

⏹️Conclusion

How to save datetime data that is relevant to multiple countries or time zones?

Solution

Conclusion

References:

Clean Architecture In Enterprise Application

A brief introduction to Clean architecture

Clean Architecture concepts

Layers in Clean Architecture

Project structure

Map project structure to Clean Architecture

References

N-tier Architecture In Enterprise Application

N-tier

Benefits

Drawbacks

Project structure

References

linhvuquach ・ Mar 23, 2024 ・
linhvuquach.Medium