نتیجه نظرسنجی از هزاران برنامه نویس در مورد ابزار های مورد استفاده، شامل ابزارهایai مورد استفاده.
به نظرم گزارش جالبی شده یه نگاهی بکنید،
https://newsletter.pragmaticengineer.com/p/the-pragmatic-engineer-2025-survey?publication_id=458709&post_id=168396454&isFreemail=true&r=4eia8j&triedRedirect=true

تجربیاتی جالب در مورد نوشتن یک برنامه code formatter
چالش هایی داره که اصلا بهشون فکر نمی‌کردم هیچوقت موقع استفاده.

journal.stuffwithstuff.com/2015/09/08/the-hardest-program-ive-ever-written/

یه تجربه جالب از پینترست بابت اهمیت دادن و دیباگ یه timeout نادر روی سرویس هاشون
https://medium.com/pinterest-engineering/debugging-the-one-in-a-million-failure-migrating-pinterests-search-infrastructure-to-kubernetes-bef9af9dabf4

یک سری راهنمایی خوب برای طراحی ساختار پروژه گولنگی
https://www.alexedwards.net/blog/11-tips-for-structuring-your-go-projects

مقاله خیلی جذابیه. نکات بسیار ارزشمندی رو میگه. نکات مهمی رو در مورد استفاده از PostgreSQL میگه وقتی که شما همزمان Write-Heavy و Read-Heavy هستی.

مقاله ایده های جالب و متفاوتی رو ارائه میکنه:
داشتن جداولی با حداکثر ۱۰۰ هزار رکورد برای داشتن index scanهای سریع و جلوگیری از کاهش عملکرد PostgreSQL

استفاده از index-only scans و مکانیزمی شبیه loose index scan برای کم کردن io operations

داشتن استراتژی compaction و VACUUM Analyze برای جلوگیری از عملکرد read queries با بزرگ شدن جدول دیتابیس

استفاده از دستور COPY به جای Insert برای batch insertهای زیاد و سنگین

استفاده از golang string type به جای byte slice برای transfer داده که عملکرد تقریبا ۲ برابر بهتری داشته!

Lessons from scaling PostgreSQL queues to 100k events per second

https://www.rudderstack.com/blog/scaling-postgres-queue/

@gocasts

مثل این که کمتر از یک ماه دیگه، Bitnami قراره بلاهایی سر تیم ها و دولوپرها بیاره.

ماجرا از این قراره که از ۲۸ آگوست به بعد فقط به آخرین تگ هر چارت میتونیم دسترسی داشته باشیم (latest) و نسخه های استیبل و مشخص فقط از طریق برنامه جدیدشون که پولیه میشه استفاده کرد. (به اسم bitnamisecure)

لازم به تاکیده که استفاده از تگ latest برا پروداکشن مطلقا ایده خوبی نیست و هر روز ممکنه اتفاقات جدید بیفته. تو این مدت تگ های فعلی رو تو یه ریپوزیتوری به عنوان lagecy قرار دادن ولی نسخه های جدید وارد این نمیشه.

به عنوان دولوپر چیکار کنیم؟ تو محیط دولوپ که میتونیم از latest استفاده کنیم ولی تو محیط پروداکشن فعلا و برای نسخه های فعلی از docker.io/bitnamilegacy به جای docker.io/bitnami استفاده کنیم.

برا اپدیت به نسخه های جدید و در ادامه هم باید واقعا دید که چی میشه. جایگزینی میاد یا چی!

https://github.com/bitnami/charts/issues/35164

چرا abstraction اشتباه در کد، از کد تکراری بدتر است:
https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

بلاگ پست قدیمی‌ایه ولی به نظرم هنوز کاملا می‌تونه نمود داشته باشه، مخصوصا وقتی که کد به مرور تغییر می‌کنه و ما میخوایم لاجیک جدید رو به زور توی همون تابع یا کلاس یا اینترفیس قبلی بگنجونیم.

یکی از پترن های بد ولی رایج توی نصب نرم‌افزار اینه که اسکریپت نصب رو curl کنیم و مستقیم اجرا کنیم.
مشکلی که وجود داره اینه که ممکنه تنی اون اسکریپت هرچیزی وجود داشته باشه و ما اون رو اجرا میکنیم، گاهی حتی با sudo


مثال:
curl -sSL https://example.com/install.sh | bash

برای این که سمت این پترن نریم، راه خوب اینه که اول اسکریپت رو بگیریم و تو دیسک ذخیره کنیم و بعد با ادیتور یا pager محتواشو بررسی کنیم.

ابزار vet اومده این کارو ساده کرده. با گرفتن آدرس میاد و اسکریپت رو دانلود می‌کنه، محتواشو (یا diffشو به نسبت دفعه قبل) بهتون نشون میده و حتی با shell check براتون چک می‌کنه و اگه مشکلی نبود، با اوکی شما اجراش می‌کنه. یه مقدار هم منو یاد aur helper ها میندازه که باید اول بررسی کنید اسکریپت رو و بعد نصب اتفاق میوفته.
https://github.com/vet-run/vet


این ابزار کار خاصی نمی‌کنه که اگه نصب نکنید ممکن نیست، ولی دیدگاهی که داره، «ساده کردن عادت خوب»ـه که برا من جالب بود.

جهت فان:
مصاحبه با یک DevOps engineer سنیور!

https://youtu.be/rXPpkzdS-q4?si=yB9totHR9pDmOk27

لیفت یه برنامه تاکسی اینترنتیه و تو این مقاله توضیح میده که چطوری راننده ها و مسافرها رو بر اساس شرایط مختلف (مثلا مجاورت) به هم وصل می‌کنه. برای توضیحش از گراف و به شکل خاص از bipartite graph استفاده می‌کنه و به نظرم متن جالبی بود.

https://eng.lyft.com/solving-dispatch-in-a-ridesharing-problem-space-821d9606c3ff

یه ابزار جدیدی که پیدا کردم و دوستش دارم، proton authenticatorئه.

یه برنامه مدیریت کدهای two factor authenticationئه که برای سیستم‌عامل های مختلف (شامل لینوکس و اندروید) نسخه داره. با این که تازه معرفی شده من باگ خاصی ندیدم و خوب و مناسب و رایگان بین دستگاه ها کدها رو سینک می‌کنه. من قبلا برای گوشی از google authenticator استفاده می‌کردم که اگرچه اون سینک می‌کرد ولی راه خاصی نداشت که روی سیستم هم داشته باشمش. در نتیجه مجبور بودم کدش رو خروجی بگیرم و با یه چنین کامندی کد رو تولید می‌کردم. که طبیعتا قابلیت سینک هم نداشت.

oathtool -b --totp '<my code>'

از قابلیت های خوب دیگه‌ی proton authenticator اینه که امکانات import export خیلی خوبی داره و میتونه از اکثر برنامه های دیگه ورودی بگیره و میتونید کدهاتون رو هم ازش export کنید و مثل microsoft authenticator به زور زندانی نمی‌کنه. =)

اگه براتون جالب بود از سایتشون می‌تونید لینک های نصبشو پیدا کنید:
https://proton.me/authenticator

چطور پرفورمنس postgresql رو ۴۲هزار برابر بدتر کنیم؟
همیشه تو مقاله ها به افزایش پرفورمنس می‌پردازیم ولی این مقاله اومده و با تنظیمات WAL و بافر و وکیم و ... پرفورمنس دیتابیس رو خیلی کم کرده!

برای من خیلی جنبه آموزشی داشت و با مفاهیم جدیدی از پستگرس آشنا شدم. امیدوارم برای شما هم همینطور باشه.

لینک مقاله اصلی:
https://byteofdev.com/posts/making-postgres-slow/

لینک ری‌اکت بهش در یوتوب:
https://www.youtube.com/watch?v=EeGCxH_0zx4

این مقاله/پست درباره string خیلی جاله،‌ من قبلا درباره فرق unicode با utf-8 خونده بودم، اما اینجا بیشتر درباره تاریخشون فهمیدم،

زمانی که ascii معرفی شد کلا برای حروف انگلیسی ساخته شده بود، و البته یکسری از کاراکتر‌ها و دستورات دیگه.
مثلا برای اسپیس کد 32 و مثلا برای حرف A از کد 65 داخلش استفاده میشد.
ولی کد‌های قبل 32 چی؟ اون‌ها برای دستورات استفاده میشه مثلا کد 7 برای صدای beep هست!

حالا تمامی این کاراکتر‌ها کلا توی 7 بیت قرار می‌گیرن و بیشتر نیاز ندارن.
مثلا اگه حرف z رو درنظر بگیریم، کد اسکیش میشه 122
و باینری 122 میشه 1111010 و همینطور که می‌بینید، با فقط هفت بیت حروف انگلیسی، اعداد، سیمبل‌ها و دستورات رو می‌تونم داشته باشیم،
اما کامپیوتر ها با هشت بیت کار می‌کنند، پس پیاده سازی ascii که داخل کامپیوتر یک بیت اضافه‌ای به ما میده!(آخرین بیت سمت چپ) پس از کد 128 تا 255 برای هیچکاری استفاده نمیشه داخل تیبل ascii

اینجاست که شرکت‌ها و برنامه نویس ها تصمیم می‌گیرن اون بیت آخر رو برای کار های خودشون استفاده کنند.
همچنین هر زبانی مثلا یونانی از برای خودش یه کد پیج داشته
مثلا توی بعضی از سیستم عامل ها از کد 130 برای کاراکتر é استفاده میشده، و یه ورژن دیگه‌ای از همون سیستم عامل(DOS) از این کد برای کاراکتر ג استفاده میشده.
اینم باید بگم که همه قبول کردن که تمامی کد های زیر 128 دست نخورده بمونه خوشبختانه.
اینکه کدهای بالای 128 نماینده چه کاراکتری باشه بستگی داره به اینکه از چه code page استفاده می‌کردن. مثلا code page 862 در اسرائیل استفاده میشده و 737 در یونان.
حالا سیستم عامل DOS از کلی کد پیج ساپورت می‌کرده، ولی همزمان نمیشده توی یک فایل تکست از دو زبان استفاده کنی.


حالا عجیب‌تر اینکه این سسیتم توی زبان هایی مثل چینی بدرد نمی‌خوره، چون خب از 'حرف' استفاده نمی‌کنند و کاراکترهاشون نماده و هزاران کاراکتر دارند،
پس توی 8 بیت جا نمی‌شن. خب اینا چیکار کردن؟ از چیزی به اسم DBCS استفاده کردن این یعنی double bytes character set
درواقع برای پیاده‌سازی زبان چیزی باید تعداد بایت ها رو دو برابر می‌کردن،
این خودش یه مشکلی داره، اینکه تایپ یک کاراکتر ساده‌ست(حرکت رو به جلو) اما اگه بخای به عقب برگردی، این یه چالشه، چون نمی‌دونی کاراکتری که تایپ کردی یک بایتی بوده یا دو بایتی.
تا اینجا انچنان مشکلی نداشتیم، اما وقتی پای اینترنت به کامپیوتر‌ها باز شد، دیگه اینجا بود متن‌ها توی سیستم‌های مختلف به خوبی کار نمی‌کردند. و unicode اختراع شد.

به صورت خلاصه unicode به ازای هر کاراکتری یک کد داره، که بهش میگن character set، یونیکد طوری ساخته شده که حتی اگه در آینده‌هم کاراکتری و یا زبانی اختراع بشه، با unicode میشه یک کد منحصر بفرد بهش داد.
مثلا برای کاراکتر A از کد U0041 استفاده میشه،
و یا برای مثال U+0048 U+0065 U+006C U+006C U+006F. میشه Hello.
این کد‌ها هگزا دسیمال هستند.


اوکی حالا سوال اینجاست که ما برای هرکاراکتری یک کد در نظر گرفتیم، اوکی خب چطوری روی هارد قراره ذخیره‌ش کنیم؟
در حالت اول و خب خیلی ساده میشه اکثر کد ها رو داخل 16 بیت دخیره کرد، اما دو مشکل وجود داره:
اول اینکه فضای بیشتری برای ذخیره می‌گیره،
دوم اینکه خب اینهمه تکست که از قبل نوشته شده، یکی باید همه اونها رو تبدیل کنه.
یا شاید یه بتونیم الگوریتم backward comaptible ایجاد کنیم.

اینجاست که جادوی utf-8 که یک encondig هست میاد وسط،
توی utf-8 از 0 تا 127 توی همون 8 بیت ذخیره می‌شه
و چیزی که به فضای بیشتری نیاز داره چی؟
وقتی کاراکتری بیشتر از 127 (یعنی نیاز به بیش از 7 بیت) نیاز داشته باشه، UTF-8 از چند بایت استفاده می‌کنه:
بایت اول یه "الگو" داره که نشون می‌ده این کاراکتر چند بایتیه، و بایت‌های بعدی با 10xxxxxx شروع می‌شن.
اینطوری کامپیوتر می‌فهمه این یه کاراکتر چندبایتیه و چطوری باید رمزگشایی‌ش کنه.

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

https://dotfyle.com/

در ۱۵ آگوست ۱۹۹۷، Migueldeicaza شروع پروژه GNOME را در ایمیل لیست GTK اعلام کرد. بیست و هشت سال بعد خیلی چیزها تغییر کرده.اند، اما ما همچنان به توسعه و بهبود «مجموعه‌ای آزاد و کامل از برنامه‌ها و ابزارهای میزکار کاربرپسند… که کاملاً بر پایه نرمافزار آزاد است» ادامه می‌دهیم.

برای اینکه این مسیر را برای آینده هم ادامه بدهیم، امیدواریم در جشن تولدمان به ما بپیوندید و امروز دوست GNOME شوید! 🎂

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

توی گولنگ با کمک امکانات داخلی پکیج sync می‌تونید یه object pool داشته باشید. هدف اولیه‌ش استفاده بهتر از مموری توی برنامه‌های گولنگی شماست.

استفاده‌ش می‌تونه برای زمانی باشه که با ریت خیلی بالا آبجکت‌هایی از یه تایپ رو می‌سازید و رها می‌کند. یه sync.Pool می‌تونه به شما کمک کنه همون آبجکتی که رو که رها کردید بهتون برگردونه و دیگه نیاز نباشه GC حذفش کنه و دوباره allocateش کنید.

توضیحات بیشتر و نمونه کد رو اینجا بخونید.
https://www.codingexplorations.com/blog/creating-efficient-go-applications-with-syncpool


البته نظر شخصی من اینه که خیلی کاربرد خاصی داره و در اکثر موارد نباید استفاده بشه، به جاش یه allocator خوب داشته باشید (که گولنگ خودش داره) و حتما قبل از استفاده و پیچیده کردن کد، بنچمارک بگیرید.

وقتی وارد یه شغل جدید می‌شیم یکی از مهم‌ترین کارها onboard شدن مناسبه. متاسفانه خیلی کیس در موردش صحبت نمی‌کنه و کیفیتش خیلی بستگی به محیطمون داره. البته که محیط تاثیر داره ولی می‌تونیم در موردش بیشتر بدونیم که چه سوالایی رو بپرسیم و چه کارایی رو باید بکنیم و چه توقعاتی داشته باشیم.

در این موضوع، من مطلب زیر رو پیدا کردم که هم mindset جالبی رو ارائه می‌ده هم timeline می‌ده که چه زمانی باید چه کاری کرده باشیم. البته طبیعتا به خیلی عوامل ربط داره ولی می‌تونه سرمشق خوبی باشه.
https://eugeneyan.com/writing/onboarding/


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

In your first week, you might find 10 things that seem wrong to you. Perhaps the build system is too complex or the machine learning too simple. Don’t be too quick to judge and make changes! Make a note of it somewhere and work hard to disconfirm your beliefs. Revisit these notes every month or so and notice how your initial hypotheses change.