"Everyone says that AI replaces developer: Shows him this demo"
https://www.trendingtopics.eu/github-wearedevelopers-conference/

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

اگه به گوشتون نخورده، ردیس نسخه ۸ اومده. و تغییرات خیلی خوبی داشته.
هم از سمت فنی قابلیت های جدید (مثل کار با Json) هم بهبود پرفورمنسی و توانایی استفاده بهتر از تردهای بیشتر رو داره.
هم از سمت لایسنس، ماژول ها و چیزهای close source رو اوپن سورس کردن و همه رو مرج کردن در قالب لایسنس درست و حسابی منتشر کردن.

اگه کاربر ردیس هستین، بلاگ پست خودشون رو به نگاهی بندازید به نظرم.
https://redis.io/blog/redis-8-ga/

✅ دوستان خوب و عزیزم سلام، من و تیم خوبم در #رسمیو، مدتی رو سرمون خلوت خواهد بود و دوست داریم به شکل مشاوره یا همکاری در انجام پروژه های شما (به صورت صفر تا صد یا مشارکت در پیاده سازی بخشی از سرویس هاتون) همراه باشیم .

✅ ما توی تیممون به جز توسعه دهندگان .net و React ، پروداکت منیجر و دیزاینر هم داریم اگر لازم داشته باشید برای این پروژه ها.

✅ کد تمیز و قابل گسترش مینویسیم، با هم سر استانداردهای مستندسازی به تفاهم خواهیم رسید.


✅ بعد از پایان پروژه هم، پروژه رو به تیم تون تحویل میدیم و اگر نیاز به آموزشی باشه، در حد توان راهنمایی و آموزش نیروهاتون رو هم بر عهده خواهیم گرفت.

خیلی به من لطف خواهید کرد اگر این پست را در همه ی گروه های فنی و بیزنسی تان منتشر کنید.
متاسفانه فعلا فقط از طریق اکانت تلگرام @StartupNerd وشماره 09308282925 در خدمت شما و پاسخگو خواهم بود.

🫂 مجددا از شما خواهش میکنم این پست رو (در همه ی گروه های خودتون که فکر میکنید ممکنه کسی به توانایی ما نیاز داشته باشه) بازنشر کنید

کسب و کار اینترنتی یک لطیفه‌ست.
خود top level domain به مشکل خورده. اونم وسط روز. :))))

https://www.zoomit.ir/tech-iran/443943-domain-downtime-irnic/

در مورد اینسیدنت cloudflare روی ۱.۱.۱.۱

بلاگ پست جالبی نوشتن و خلاصه ایده ش اینه که به خاطر سیستم legacy کانفیگ اشتباه باعث خطا شد و ما دیگه سیستم مدرن(!) میاریم بالا و حل میشه همه چی.

https://news.ycombinator.com/item?id=44578490


چند تا نکته به نظرم میرسه:
۱. چقدر خوبه که تا حدی شفافیت دارن و براشون مهمه و هم عذرخواهی کردن و گفتن کاری میکنیم که دیگه تکرار نشه.
۲. این که یه مشکل رو به اشتباه یه مهندس تقلیل نمی‌دن برام قشنگه، چون آدما اشتباه میکنن و باید سامانه ها و روند ها جوری باشه که خطا رو نشون بده (مثال ساده میشه پایپالاین تست یا محیط تست جدا از پروداکشن)
۳. به نظر میاد که خطا رو محیط تست بوده ولی باعث خراب شدن پروداکشن شده. این یکی از بدترین اتفاق هاست. به چند دلیل از جمله این که تغییر تو محیط تست زیاده و قاعدتاً داکیومنت نمیشه و پیدا کردن ریشه مشکل ممکنه خیلی سخت بشه.
۴. این روحیه که همه چیزو بندازیم گردن سیستم قبلی و بگیم legacy بود رو دوست ندارم. یهو با این اینسیدنت متوجه شدید که legacy بوده و همه اشکالاتش در اومد؟ قاعدتا مشکل از این هم هست که وقت کافی به حل بدهی فنی هاش اختصاص پیدا نکرده در طی ماه ها و سال های اخیر.
۵. نکته ای که برام جالبه اینه که اینسیدنت ۲۰۲۱ meta هم که باعث شد کل زیرساختش از بیرون قابل دسترسی نباشه هم به خاطر یه کانفیگ اشتباه بود. شاید اون تمرکزی که برای قابل اطمینان کردن لایه های بالاتر داشتیم (زبان های type safe و انواع تست و canary release و ...) رو باید رو لایه های پایین تر هم داشته باشیم.

باگ امنیتی روز صفر (zero day) کروم حل شده که دسترسی به سیستم رو به اتکر می‌ده.
مرورگرهای chromium based خودتون رو آپدیت کنید زودتر.
https://thehackernews.com/2025/07/urgent-google-releases-critical-chrome.html

کلا همیشه ایده خوبیه که مرورگر ها رو بروز نگه دارید.

راهنمای خوبی از شبکه از کوبرنتیز!
https://www.tkng.io/

نتیجه نظرسنجی از هزاران برنامه نویس در مورد ابزار های مورد استفاده، شامل ابزارهای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 شروع می‌شن.
اینطوری کامپیوتر می‌فهمه این یه کاراکتر چندبایتیه و چطوری باید رمزگشایی‌ش کنه.