بچهها ممکنه خیلی از اوقات نیاز به یک منتور داشته باشید که توی مسیر شغلی بهتون کمک کنه، سایت ADPList با هدف منتورینگ رایگان برای همه ایجاد شده و میتونید توی این سایت ثبتنام کنید و خیلی راحت با منتورهای این پلتفرم جلسه رایگان ست کنید و ازشون کمک بگیرید.
https://adplist.org/explore?tab=mentors
#DevTwitter | <boby cloud/>
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
https://adplist.org/explore?tab=mentors
#DevTwitter | <boby cloud/>
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
🔥8
💙کامپیوترها حتی وقتی خاموش هم باید زمان رو نگه دارن.
💙 در این قسمت از آموزش #لینوکس در مورد زمان و سنجشش حرف میزنم.
💙 قسمت جالبیه و کلی چیز باحال و کاربردی داره؛بخصوص که پروتکل مورد استفاده، پروتکل مورد علاقه من یعنی NTP است و دستوراتش
🔴https://youtu.be/GN54NlA4wC4
🔴https://youtu.be/Ihm6AYNFUKA
#جادی
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
💙 در این قسمت از آموزش #لینوکس در مورد زمان و سنجشش حرف میزنم.
💙 قسمت جالبیه و کلی چیز باحال و کاربردی داره؛بخصوص که پروتکل مورد استفاده، پروتکل مورد علاقه من یعنی NTP است و دستوراتش
🔴https://youtu.be/GN54NlA4wC4
🔴https://youtu.be/Ihm6AYNFUKA
#جادی
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
👍8❤1
❎Order of execution of a Query
▶️https://sqlbolt.com/lesson/select_queries_order_of_execution
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
▶️https://sqlbolt.com/lesson/select_queries_order_of_execution
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
👍3❤2
🔴URL, URI, URN - Do you know the differences?
🔹 URI
URI stands for Uniform Resource Identifier. It identifies a logical or physical resource on the web. URL and URN are subtypes of URI. URL locates a resource, while URN names a resource.
🔹 URL
URL stands for Uniform Resource Locator, the key concept of HTTP. It is the address of a unique resource on the web. It can be used with other protocols like FTP and JDBC.
🔹 URN
URN stands for Uniform Resource Name. It uses the urn scheme. URNs cannot be used to locate a resource. A simple example given in the diagram is composed of a namespace and a namespace-specific string.
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
🔹 URI
URI stands for Uniform Resource Identifier. It identifies a logical or physical resource on the web. URL and URN are subtypes of URI. URL locates a resource, while URN names a resource.
🔹 URL
URL stands for Uniform Resource Locator, the key concept of HTTP. It is the address of a unique resource on the web. It can be used with other protocols like FTP and JDBC.
🔹 URN
URN stands for Uniform Resource Name. It uses the urn scheme. URNs cannot be used to locate a resource. A simple example given in the diagram is composed of a namespace and a namespace-specific string.
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
👍3❤2🍾2
👍4
😁برای اهل دل هاش👇🏻👇🏻
🔵Create a new production-ready project with backend, frontend and deploy automation by running one CLI command!
🟢https://github.com/create-go-app/cli
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
🔵Create a new production-ready project with backend, frontend and deploy automation by running one CLI command!
🟢https://github.com/create-go-app/cli
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
👍7💊2❤1
#دون
یک باگ بزرگ کامپیوتری وجود داره به اسم Y2K38 که 19 ژانویه ی 2038 ساعت 03:14:07 اتفاق میوفته.
همونطور که میدونید کامپیوتر ها تاریخ رو بر اساس ثانیه های گذشته از اول ژانویه ی 1970 تا حالا حساب میکنن. (که بهش Unix timestamp میگن)
این عدد در اکثر سیستم ها توی یک signed 32-bit integer ذخیره میشه که میتونه از عدد
-2,147,483,648
تا
2,147,483,647
توی خودش ذخیره کنه
توی تاریخ 19 ژانویه ی 2038، عدد تاریخ از این مقدار فراتر میره، سر ریز حافظه اتفاق میوفته و شمارشگر تاریخ ریست میشه
هم اکنون: 1,688,061,955
راه حلش ذخیره ی تاریخ توی یک عدد 64 بیتی هست
البته تا اون تاریخ قطعا این مشکل حل خواهد شد و همین حالا هم خیلی از سیستم ها حلش کردن
#DevTwitter
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
یک باگ بزرگ کامپیوتری وجود داره به اسم Y2K38 که 19 ژانویه ی 2038 ساعت 03:14:07 اتفاق میوفته.
همونطور که میدونید کامپیوتر ها تاریخ رو بر اساس ثانیه های گذشته از اول ژانویه ی 1970 تا حالا حساب میکنن. (که بهش Unix timestamp میگن)
این عدد در اکثر سیستم ها توی یک signed 32-bit integer ذخیره میشه که میتونه از عدد
-2,147,483,648
تا
2,147,483,647
توی خودش ذخیره کنه
توی تاریخ 19 ژانویه ی 2038، عدد تاریخ از این مقدار فراتر میره، سر ریز حافظه اتفاق میوفته و شمارشگر تاریخ ریست میشه
هم اکنون: 1,688,061,955
راه حلش ذخیره ی تاریخ توی یک عدد 64 بیتی هست
البته تا اون تاریخ قطعا این مشکل حل خواهد شد و همین حالا هم خیلی از سیستم ها حلش کردن
#DevTwitter
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
👍5🤔2🐳2
درود دوستان این مقاله کوتاه خوندنش خالی از لطف نیست
🔵 Unobvious things you need to know about key-value stores
🔴 https://event-driven.io/en/key-value-stores
🟢یکی از موضوعاتی که قبلا هم در موردش صحبت کردیم بحث استفاده از uuid به عنوان primary key بود که میتونه فاجعه به بار بیاره
برخی از دوستان هم به درستی اشاره کردند که دیتابیس ها سعی کردند این مشکل رو تا حدودی حل کنند، تو این مقاله نکات خیلی جالبی در مورد پیاده سازیش گفته شده
🔻 https://www.2ndquadrant.com/en/blog/sequential-uuid-generators/
#database #index
#gocasts
✍️ https://t.me/lifography
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
🔵 Unobvious things you need to know about key-value stores
🔴 https://event-driven.io/en/key-value-stores
🟢یکی از موضوعاتی که قبلا هم در موردش صحبت کردیم بحث استفاده از uuid به عنوان primary key بود که میتونه فاجعه به بار بیاره
برخی از دوستان هم به درستی اشاره کردند که دیتابیس ها سعی کردند این مشکل رو تا حدودی حل کنند، تو این مقاله نکات خیلی جالبی در مورد پیاده سازیش گفته شده
🔻 https://www.2ndquadrant.com/en/blog/sequential-uuid-generators/
#database #index
#gocasts
✍️ https://t.me/lifography
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
👍9🤣1
اگه گاهی اوقات توی برنامه نویسی اعصاب یا حوصلهات نمیکشه، یادت باشه که Ken Thompson (کسی که Unix، utf-8، grep رو ساخت و روی C هم خیلی کار کرد) توی 63 سالگی تازه رفت تو گوگل تا با چند نفر دیگه Golang رو بسازه.
#DevTwitter | <Pesar/>
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
#DevTwitter | <Pesar/>
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
❤18👍5🕊5🤔1🤣1
How can Redis be used?
🔹Session
We can use Redis to share user session data among different services.
🔹Cache
We can use Redis to cache objects or pages, especially for hotspot data.
🔹Distributed lock
We can use a Redis string to acquire locks among distributed services.
🔹Counter
We can count how many likes or how many reads for articles.
🔹Rate limiter
We can apply a rate limiter for certain user IPs.
🔹Global ID generator
We can use Redis Int for global ID.
🔹Shopping cart
We can use Redis Hash to represent key-value pairs in a shopping cart.
🔹Calculate user retention
We can use Bitmap to represent the user login daily and calculate user retention.
🔹Message queue
We can use List for a message queue.
🔹Ranking
We can use ZSet to sort the articles.
#systemdesign #coding #interviewtips
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
🔹Session
We can use Redis to share user session data among different services.
🔹Cache
We can use Redis to cache objects or pages, especially for hotspot data.
🔹Distributed lock
We can use a Redis string to acquire locks among distributed services.
🔹Counter
We can count how many likes or how many reads for articles.
🔹Rate limiter
We can apply a rate limiter for certain user IPs.
🔹Global ID generator
We can use Redis Int for global ID.
🔹Shopping cart
We can use Redis Hash to represent key-value pairs in a shopping cart.
🔹Calculate user retention
We can use Bitmap to represent the user login daily and calculate user retention.
🔹Message queue
We can use List for a message queue.
🔹Ranking
We can use ZSet to sort the articles.
#systemdesign #coding #interviewtips
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
👍12👎1
⚄لاگها بخش مهمی از دنیای گنو/لینوکس هستن. تقریبا هر چیزی که اجرا میشه کلی لاگ درست میکنه که اجازه میده ته و توی هر چیزی که در جریانه رو در بیاریم. ما عاشق لاگهامون هستیم و توی این ویدئو یاد میگیریم ازشون به خوبی استفاده کنیم (:
⚂قسمت اول:
⚃https://youtu.be/vBDgTA-VYXo
⚂قسمت دوم:
⚃https://youtu.be/T-ut4oQfJI8
#جادی
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
⚂قسمت اول:
⚃https://youtu.be/vBDgTA-VYXo
⚂قسمت دوم:
⚃https://youtu.be/T-ut4oQfJI8
#جادی
➖➖➖➖➖➖➖➖➖
🕊 @gopher_academy
👍4🍾2
🔵proposal: runtime: change mutex profile to scale contention by number of blocked goroutines
🔴https://github.com/golang/go/issues/61015
➖➖➖➖➖➖➖➖
🕊 @gopher_academy
🔴https://github.com/golang/go/issues/61015
➖➖➖➖➖➖➖➖
🕊 @gopher_academy
👍3
🔵Can I convert a []T to an []interface{}?
🔴Not directly.
🟢It is disallowed by the language specification because the two types do not have the same representation in memory. It is necessary to copy the elements individually to the destination slice. This example converts a slice of int to a slice of interface{}:
➖➖➖➖➖➖➖➖
🕊 @gopher_academy
🔴Not directly.
🟢It is disallowed by the language specification because the two types do not have the same representation in memory. It is necessary to copy the elements individually to the destination slice. This example converts a slice of int to a slice of interface{}:
➖➖➖➖➖➖➖➖
🕊 @gopher_academy
👍4👎1🔥1🐳1
✅ Top software engineering principles
1. SOLID: An acronym for five design principles that improve code maintainability and readability:
- *Single Responsibility Principle (SRP)*: Each class or module should have only one reason to change, meaning it should have a single responsibility.
- *Open/Closed Principle (OCP)*: Software entities should be open for extension but closed for modification, promoting the use of inheritance and interfaces.
- *Liskov Substitution Principle (LSP)*: Subtypes must be substitutable for their base types, ensuring that derived classes follow the same contracts as their base classes.
- *Interface Segregation Principle (ISP)*: Clients should not be forced to depend on interfaces they do not use. Instead, create smaller, more focused interfaces.
- *Dependency Inversion Principle (DIP)*: High-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions.
2. DRY (Don't Repeat Yourself): This principle states that developers should avoid duplicating code and logic. Reusing code through abstraction and modularization increases maintainability and reduces the potential for bugs.
3. KISS (Keep It Simple, Stupid): KISS emphasizes simplicity in software design. Developers should aim for solutions that are easy to understand and maintain, avoiding unnecessary complexity.
Here are a few more software engineering principles to consider:
4. YAGNI (You Aren't Gonna Need It): This principle encourages developers to avoid adding functionality until it is absolutely necessary. Over-engineering and adding features "just in case" can lead to bloated, hard-to-maintain code.
5. Separation of Concerns (SoC): This principle involves organizing code into distinct sections, each with a specific responsibility. Separation of concerns promotes modularity and maintainability.
6. Composition over Inheritance: Favor object composition over class inheritance when designing your code. Composition provides greater flexibility and promotes code reuse without the tight coupling often associated with inheritance.
7. Law of Demeter (LoD) or Principle of Least Knowledge: An object should only communicate with its immediate neighbors and should not have knowledge of the inner workings of other objects. This principle helps create loosely coupled systems.
8. Fail Fast: Design your software to fail as soon as possible when an error occurs, making it easier to identify and fix issues during development.
9. Encapsulate What Varies: Identify the parts of your code that are likely to change and encapsulate them to minimize the impact of future modifications.
These principles, along with SOLID, DRY, and KISS, can help guide you in creating well-designed, maintainable software systems. Keep in mind that these are guidelines, not strict rules, and should be applied with consideration for your specific project and its requirements.
➖➖➖➖➖➖➖➖
🕊 @gopher_academy
1. SOLID: An acronym for five design principles that improve code maintainability and readability:
- *Single Responsibility Principle (SRP)*: Each class or module should have only one reason to change, meaning it should have a single responsibility.
- *Open/Closed Principle (OCP)*: Software entities should be open for extension but closed for modification, promoting the use of inheritance and interfaces.
- *Liskov Substitution Principle (LSP)*: Subtypes must be substitutable for their base types, ensuring that derived classes follow the same contracts as their base classes.
- *Interface Segregation Principle (ISP)*: Clients should not be forced to depend on interfaces they do not use. Instead, create smaller, more focused interfaces.
- *Dependency Inversion Principle (DIP)*: High-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions.
2. DRY (Don't Repeat Yourself): This principle states that developers should avoid duplicating code and logic. Reusing code through abstraction and modularization increases maintainability and reduces the potential for bugs.
3. KISS (Keep It Simple, Stupid): KISS emphasizes simplicity in software design. Developers should aim for solutions that are easy to understand and maintain, avoiding unnecessary complexity.
Here are a few more software engineering principles to consider:
4. YAGNI (You Aren't Gonna Need It): This principle encourages developers to avoid adding functionality until it is absolutely necessary. Over-engineering and adding features "just in case" can lead to bloated, hard-to-maintain code.
5. Separation of Concerns (SoC): This principle involves organizing code into distinct sections, each with a specific responsibility. Separation of concerns promotes modularity and maintainability.
6. Composition over Inheritance: Favor object composition over class inheritance when designing your code. Composition provides greater flexibility and promotes code reuse without the tight coupling often associated with inheritance.
7. Law of Demeter (LoD) or Principle of Least Knowledge: An object should only communicate with its immediate neighbors and should not have knowledge of the inner workings of other objects. This principle helps create loosely coupled systems.
8. Fail Fast: Design your software to fail as soon as possible when an error occurs, making it easier to identify and fix issues during development.
9. Encapsulate What Varies: Identify the parts of your code that are likely to change and encapsulate them to minimize the impact of future modifications.
These principles, along with SOLID, DRY, and KISS, can help guide you in creating well-designed, maintainable software systems. Keep in mind that these are guidelines, not strict rules, and should be applied with consideration for your specific project and its requirements.
➖➖➖➖➖➖➖➖
🕊 @gopher_academy
👍4🕊3🗿2💊1