چند وقت پیش فایل‌های Protocol Buffer پروژه‌ای رو مرتب‌ می‌کردم که دیدم این دو فیلد در بین چندین message پروژه تکرار شده:

message A {     ...     int64 seconds = n;     int64 nano\_seconds = m;     ... }

با توجه به این که این دو خط عیناً تکرار شده بود، یک message تعریف کردم و به جای اون دوتا فیلد از message جدید استفاده کردم:

message Timestamp {     int64 seconds = 1;     int64 nano\_seconds = 2; } message A {     ...     Timestamp timestamp\_utc = p;     ... }

بعداً متوجه شدم که Timestamp هم یکی از تایپ‌هاییه که به صورت استاندارد تعریف شده و نیازی نیست خودمون تعریف کنیم. به همین خاطر message‌ها رو به دوباره بازنویسی کردم:

```
import "google/protobuf/timestamp.proto";

message A {
    ...
    google.protobuf.Timestamp timestamp = p;
    ...
}
```

جدا از Timestamp، تایپ‌های Empty و Duration هم از بین تایپ‌های از پیش تعریف شدهٔ protobuf خیلی پرکاربرد هستن. لیست کامل این تایپ‌ها رو هم می‌تونید اینجا ببینید.

#protobuf
@aminrbg

"معذرت می‌خوام". آیا همین کافی است؟یادداشتی در مورد اشتباه کردن.

در گذشته کار کردن معنای متفاوتی با الان داشت. کمتر نیاز بود که افراد هر روزه تصمیم‌های متعددی بگیرن. هرچی جلوتر می‌ریم، فضایی که توش کار می‌کنیم و ابزارهایی که باهاشون کار می‌کنیم پیچیده‌تر و متنوع‌تر می‌شن. توی این شرایط، ابهام و عدم قطعیت هم بالاتر میره.

کار خیلی ماها اینه که توی این عدم قطعیت تصمیم‌های هر روزه بگیریم. معمولاً شرکت‌ها هم بیشترین حقوق و مزایا رو به افرادی می‌دن که تصمیم‌های بزرگ‌تر، مهم‌تر و پرریسک‌تر می‌گیرن. از طرفی هم دانش و آگاهی ما به مسائل محدوده و همیشه همهٔ داده‌های لازم رو در اختیار نداریم. اساساً اگر میشد همه این داده‌ها رو در اختیار داشت، احتمالاً شرکت‌ها هم نیازی به استخدام این همه نیروی متخصص و با این هزینه گزاف نداشتن.

با وجود همهٔ این عدم قطعیت‌ها، اشتباه کردن می‌تونه یکی از خروجی‌های احتمالی تصمیم‌گیری‌هامون باشه. ممکنه اشتباه کردن ریشه در دانشی داشته باشه که از تجربیات و یا مطالعات قبلی کسب کردیم ولی با شرایط جدید انطباق کامل ندارن. یا این که در شرایطی قرار بگیریم که مجبور باشیم که با دادهٔ محدود و ناقص تصمیم بگیریم و عملاً روی تصمیمی که گرفتیم شرط ببیندیم.

پس از اشتباهاز نگاه من افراد بعد از گرفتن تصمیمی به غلط، به چند دسته تقسیم می‌شن.

- دسته اول -> انکار آنچه که پیش آمدهیک دسته از افراد با وجود اشتباه و دریافت خروجی نامطلوب، اون رو انکار می‌کنن و حاضر نیستن بپذیرن که نقشی در این اشتباه داشتن. این افراد در مواجهه با شرایط موجود یا مسئله رو کاملاً نادیده‌ میگیرن و مشکل به روی خودشون نمیارن، یا این که سعی می‌کنن تقصیر رو گردن بقیه بندازن.
با توجه به این که بخش خوبی از یادگیری، پذیرش اشتباهات و تلاش برای تحلیل خروجی‌هاست، این افراد به سختی از اون حیطه دانش فعلیشون خارج می‌شن و احتمالاً دوباره همون اشتباه‌ها رو تکرار خواهند کرد.

- دسته دوم -> پذیرش بدون برنامهدسته دوم افرادی هستن که ابایی از پذیرش مسئله پیش آمده ندارن و از افراد درگیر معذرت خواهی می‌کنن و سعی می‌کنن با کمترین هزینه از وضعیت موجود گذر کنن و به راحتی حاضر به جبران و یا حل مسئله پیش آمده ندارن.
همین که این افراد بقیه رو مقصر نمی‌دونن، کار کردن باهاشون حس بهتری نسبت به دستهٔ اول داره.

- دسته سوم -> پذیرش با برنامهاین دسته بعد از اشتباهاتی که مرتکب میشن (حتی بعضاً اشتباهات دیگران) احساس مسئولیت می‌کنن و سعی می‌کنن که نسبت به مسئله extreme ownership داشته باشن. به این معنی که اولاً مشکل رو گردن فرد دیگری نمی‌ندازن، دوماً مسئولیت مشکل رو می‌پذیرن، و در نهایت تمام تلاششون رو می‌کنن که وضع موجود رو بهتر کنن. اگر تصمیمی برگشت‌پذیر باشه، در راستای تغییر وضعیت فعلی تلاش می‌کنن. اگر اتفاقیه که نمی‌تونن به حالت قبلی برگردونن، سعی می‌کنن هزینه رخداد رو کاهش بدن. در بدترین حالت هم تلاش می‌کنن که با آگاه‌سازی هرچه بیشتر،‌ از تکرار اتفاق جلوگیری کنن.
کار کردن با این افراد خیلی لذت‌بخش تر از بقیه است. این افراد هم خودشون رشد می‌کنن و هم باعث رشد اطرافیانشون می‌شن و همچنین در حفظ آرامش و psychology safety افراد تیم هم نقش پررنگی دارن.

ماها احتمالاً نمیتونیم به صورت قطعی بگیم که توی کدوم یک از این سه دسته هستیم چون مسئله خیلی سیاه یا سفید نیست. شاید در بعضی از موارد به راحتی در دسته سوم قرار بگیریم اما در بعضی دیگر از موارد از دسته اول پایین‌تر نیایم (به خصوص مواردی که روشون ادعای دانش و تجربه داریم).
از نظرم کاری که می‌تونیم بکنیم اینه که سعی کنیم همواره شرایط رو ارزیابی کنیم و به صورت خودآگاه فکر کنیم که در کدوم یک از این دسته‌ها قرار گرفتیم تا در صورت نیاز بتونیم تغییری ایجاد کنیم.

اگر فکر می‌کنین این نوشته برای دوستانتون مفید خواهد بود، با به اشتراک گذاشتنش به انتشار نوشته و همچنین رشد کانال کمک بزرگی خواهید کرد.#یادداشت
@aminrbg

How to create software quality.

کیفیت نرم‌افزار چیه دقیقاً؟ اگر برای توسعهٔ یک محصولی Automated Test خیلی خوبی توسعه بدیم می‌تونیم بگیم که کیفیت بهتر شده؟ یا این که اگر برای دیپلوی‌ها Automated Rollouts داشته باشیم می‌تونیم بگیم حتماً کیفیت رو بهبود دادیم؟

توی این نوشته Will Larson سعی کرده مشاهدات و تجربیاتش در مورد کیفیت نرم‌افزار رو جمع‌آوری کنه و خلاصه کنه.

در ابتدا سعی می‌کنه یک تعریف کلی از کیفیت ارائه بده. بعد این مسئله رو به پیچیدگی محصولی که داریم روش کار می‌کنیم ارتباط می‌ده. در ادامه هم به برخی موضوعات دیگر پیرامون همین موضوع می‌پردازه.

اما شاید مهمترین حرفی که داره می‌زنه اینه که کیفیت بر اساس context تعریف می‌شه. یک الگویی که خیلی از جاها باعث افزایش کیفیت می‌شه، ممکنه توی context متفاوتی اتفاقاً کیفیت رو بیاره پایین.

? لینک نوشته

#software_quality
@aminrbg

Lethain

How to create software quality.

I’ve been reading Steven Sinofsky’s Hardcore Software, and particularly enjoyed this quote from a memo discussed in the Zero Defects chapter: You can improve the quality of your code, and if you do, the rewards for yourself and for Microsoft will be immense.…

My Thoughts on The Clean Coder Book
مدتی پیش کتاب The Clean Coder از Uncle Bob رو خوندم.
کتاب عموماً موضوعات سطح بالای مهندسی نرم‌افزار مثل اهمیت تست کردن کد، نحوهٔ مدیریت ددلاین‌ها، تمرین زبان‌های جدید برنامه‌نویسی و ... رو مطرح کرده بود.

بعضی از بخش‌های کتاب برام تازگی داشت و یا موضوعاتی که از قبل بهشون آشنا بودم رو مجدداً بهم یادآوری کرد. توی این پست نظرم رو دربارهٔ بعضی از این موارد نوشتم.

? لینک نوشته

#book
@aminrbg

aminrb.me

My Thoughts on The Clean Coder Book

This post shares my thoughts on 'The Clean Coder' by Uncle Bob, focusing on topics that I found particularly interesting or debatable.

سلام روزتون بخیر.
یک موقعیت شغلی مربوط به برنامه‌نویس Golang در تیم ما (آلمان، شرایط ریلوکیشن هم دارن) باز شده. اگر خودتون یا دوستانتون علاقه‌مند بودید و شرایطتون مطابق با توضیحات نوشته شده بود، می‌تونید براش اپلای کنید و اگر هم سوالی داشتید یا خواستید معرفی‌تون کنم می‌تونید بهم پیام بدید: @amin_671

? لینک موقعیت شغلی

@aminrbg

CHECK24jobs

Golang Developer (m/f/d) for our newest product Explorer

CHECK24 is growing continuously and regularly founds new start-ups. And right now is one of these exciting phases:  You can help build a new product right from the start, take on responsibility and contribute innovative ideas. Experience and attitude are…

استک‌اورفلو هر سال گزارش کاملی از دنیای برنامه‌نویسی و بر اساس نظرسنجی از برنامه‌نویس‌ها ارائه می‌ده. اخیراً هم برای ۲۰۲۴ هم این نظرسنجی رو شروع کرده.
اگر علاقه‌مند بودید پیشنهاد می‌کنم شرکت کنید تا بتونن آمار دقیق‌تری (به طور خاص در مورد ایران) ارائه بدن. حدوداً ۲۰ دقیقه طول می‌کشه تا به سوالاتش جواب بدید.

? لینک نظرسنجی

@aminrbg

Qualtrics

2024 Stack Overflow Developer Survey

Stack Overflow is the largest, most trusted online community for developers to learn, share​ ​their programming ​knowledge, and build their careers.

What is DDD - Eric Evans - DDD Europe 2019
آقای Eric Evans که پدیدآورندهٔ نگاه Domain-Driven Design هستش، توی این ویدیو سعی می‌کنه که خیلی سطح بالا اهمیت Domain و Model و تفاوت‌هاشون رو در طراحی‌های نرم‌افزاری توضح بدن.
برای این کار هم از چندین مثال واقعی استفاده می‌کنه تا تفاوت شیوه‌های مختلف Model کردن یک مسئله در دنیای واقعی به طراحی نرم‌افزاری رو نشون بده.

? لینک ویدیو

#ddd
@aminrbg

YouTube

What is DDD - Eric Evans - DDD Europe 2019

Domain-Driven Design Europe 2019 https://dddeurope.com https://twitter.com/ddd\_eu Organised by Aardling (https://aardling.eu/) What is DDD Join us for an introduction to DDD by the man who has been explaining the longest. Biography Eric Evans is the…

Scaling to Count Billions - Canva Engineering Blog
تولیدکننده‌های محتواهای هنری مثل لوگو، تمپلیت عکس و ... می‌تونن محصولاتشون رو برای فروش توی Canva بذارن تا کاربرها بتونن این محصولات رو بخرن و توی طراحی‌هاشون استفاده کنن. توی این نوشته از بلاگ فنی Canva، به چالش پرداخت سهم این تولیدکننده‌ها پرداختن.

نویسنده‌ از اینجا شروع کرده که در ابتدا طراحی رو خیلی ساده و ابتدایی پیش بردن و به مرور مقیاس بزرگ شده و باعث شده که کدها خیلی پیچیده بشن و دیباگ‌هم سخت‌تر شده. بعد نحوهٔ بازطراحی سیستم‌ها و تغییر تکنولوژی‌ها رو توضیح دادن. دوتا تغییر کلی که دادن به این شکل بوده:
- دیتابیس رو از از MySQL به DynamoDB تغییر دادن (از OLTP به OLAP)
- مسیر پردازش دیتا و رسیدن به داده‌های نهایی رو کاهش دادن (ETL راه انداختن)

نکته‌ای که برای من جالب تر بود که طراحی این فیچر رو با MySQL شروع کرده بودن. با این که شاید در نگاه اول انتخاب معقولی به نظر نرسه، اما نویسنده به مسئله اشاره کرده بود که دلیلشون برای این انتخاب، دانش اون زمان تیم فنیشون بوده و عملاً با تصمیم می‌تونستن کار رو سریع‌تر شروع کنن. بعداً که مقیاس بزرگتر شده و سیستم جوابگو نبوده، کل پروسه رو بازطراحی کردن.

*?*** لینک نوشته
#canva #mysql #olap #dynamodb
@aminrbg

canva.dev

Scaling to Count Billions - Canva Engineering Blog

How we built a scalable and reliable content usage counting service.

Vector Search: An Introduction
من در بازهٔ اخیر زمان قابل توجهی بر روی مسئلهٔ‌ جستجوی برداری یا vector search گذاشتم. این شیوهٔ جستجو که چند سالیه که بیشتر باب شده و در شرکت‌های بزرگی مثل Netflix و Pinterest به کار گرفته میشه، این امکان رو میده که بر روی مدیاهای غیر متنی مثل صوت، تصویر و ویدیو هم جستجو کنیم. جدا از این مدیاهای غیرمتنی، می‌تونه کمک کنه که جستجوی متنی بهتری رو هم داشته باشیم و به کمکش بر روی اطلاعات استنباط شده از متن جستجو کنیم.

در این نوشته توضیح دادم که جستجوی برداری چی هست، چه کاربردهایی داره و کجاها می‌تونیم ازش استفاده کنیم. همچنین اجزای سازنده‌اش و نمونه‌ای از طراحی سطح بالاش رو توضیح دادم.

اگر در محصولی کار می‌کنید که جستجو یکی از بخش‌های مهمشه، خوندن این نوشته می‌تونه براتون مفید باشه.

*?*** لینک نوشته
#vector_search
@aminrbg

aminrb.me

Vector Search: An Introduction

In this post, we explore the fundamentals of vector search, discussing how it operates and its applications across different data formats. You'll discover the key components required to implement vector search and its potential to enhance search functionalities.