React Native Isn't as Popular as You Think
https://youtu.be/E3Yjx0fFeaA

#react

انتقال مخازن پارچ پایان یافتند.

به محض به‌روزرسانی مخازن ppr و pcp از روی سیستم شما حذف و با مخزن world جایگزین می‌شوند.

sudo pacman -Syyu

اگر به هر دلیلی، این اتفاق رخ نداد به صورت دستی می‌توانید این کار را انجام دهید، کافی است تا این مقادیر را در pacman.conf

[ppr]
SigLevel = Optional TrustAll
Include = /etc/pacman.d/parch-mirrors


[pcp]
SigLevel = Optional TrustAll
Include = /etc/pacman.d/parch-mirrors

به

[world]
SigLevel = Optional TrustAll
Include = /etc/pacman.d/parch-mirrors

تغییر بدید.


با احترام
تیم توسعه توزیع پارچ

@ParchLinux

جالبه بدونید که میانگین IQ ایران 106 هستش که فقط یدونه پایین تر از چین هست که رتبه اوله.

( خودمم باورم نمیشه حقیقت )

سورس ها :
https://worldpopulationreview.com/country-rankings/average-iq-by-country

https://www.thecaliforniacourier.com/average-iq-by-country-2025-update

https://brght.org/iq/country

—
حتی سایت اپل اخیرا یه مقاله ای ای منتشر کرده بود به اسم The Illusion of Thinking که ۴ نفر از author های این مقاله اسم ایرانی داشتن.
https://ml-site.cdn-apple.com/papers/the-illusion-of-thinking.pdf

بچه ها بدبخت شدیم؛ دیزاینرا می‌فهمن آیکون هارو از یه پک انتخاب نکردیم و بهمون اون پشت می‌خندن


@Linuxor

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

لینک ریپازیتوری :
https://github.com/thekourox/Geek-Clothes

@DevTwitter | <Koroush/>

چرا Async تو کار با دیتابیس همیشه کار امد نیست؟ 🧵

یه باور رایج بین برنامه‌نویس ها اینه که استفاده از Async (برنامه‌نویسی ناهمزمان) تو همه‌چیز معجزه می‌کنه، مخصوصاً وقتی با دیتابیس کار می‌کنین. اما می‌دونستید که Async زدن کد برای کار با دیتابیس همیشه اون تأثیر که فکر می‌کنید رو نداره؟ تو این پست قراره ببینیم چرا.

🧠 چرا Async تو دیتابیس تأثیر کمی داره؟

وقتی با دیتابیس کار می‌کنین (مثل PostgreSQL، MySQL یا MongoDB)، عملیات‌ها مثل خوندن (SELECT)، نوشتن (INSERT) یا آپدیت کردن معمولاً CPU-bound هستن، نه I/O-bound. حالا این یعنی چی؟

‏CPU-bound:
یعنی گلوگاه اصلی تو عملیات، پردازش CPUئه. مثلاً وقتی یه کوئری SQL اجرا می‌کنی، دیتابیس باید کارایی مثل پارس کردن کوئری، بهینه‌سازی پلن، پردازش داده‌ها و مرتب‌سازی رو انجام بده. اینا همشون به CPU وابسته‌ان.

‏I/O-bound:
یعنی گلوگاه اصلی منتظر موندن برای ورودی/خروجی (مثل خوندن از دیسک یا شبکه). Async تو این سناریوها خوب عمل میکنه چون می‌تونه CPU رو آزاد کنه تا وقتی منتظر I/O هستیم، کارهای دیگه انجام بده.

دیتابیس‌ها معمولاً تو محیط‌های خودشون بهینه شدن که عملیات CPU-bound رو سریع انجام بدن (مثل استفاده از ایندکس‌ها یا کش). برای همین، وقتی از یه کلاینت (مثل یه برنامه پایتون) به دیتابیس وصل می‌شین، بیشتر زمان صرف پردازش کوئری تو خود دیتابیسه، نه منتظر شبکه یا دیسک. حالا Async (مثل async/await تو پایتون) اینجا کمک زیادی نمی‌کنه، چون CPU داره کار اصلی رو انجام می‌ده و چیزی برای "منتظر موندن" وجود نداره.

مثال ساده:
فرض کنین یه کوئری سنگین مثل این تو PostgreSQL دارین:

SELECT * FROM orders WHERE total > 1000 ORDER BY created_at;

این کوئری CPU دیتابیس رو حسابی درگیر می‌کنه (برای فیلتر کردن و مرتب‌سازی). حالا اگه تو پایتون اینو با یه کلاینت sync (مثل psycopg2) یا async (مثل asyncpg) اجرا کنین، تفاوت سرعت خیلی کمه، چون گلوگاه اصلی تو خود دیتابیسه، نه تو کلاینت.

📚 چرا Async همیشه مفید نیست؟

وقتی از یه کلاینت Async استفاده می‌کنین (مثل asyncpg یا motor برای MongoDB)، انتظار دارین عملیات دیتابیس سریع‌تر بشه چون می‌تونه همزمان کارهای دیگه رو انجام بده. اما چندتا دلیل باعث می‌شه این تأثیر کم باشه:

1⃣ گلوگاه تو دیتابیسه:
همون‌طور که گفتم، بیشتر عملیات دیتابیس CPU-bound هستن. Async فقط می‌تونه I/O شبکه رو مدیریت کنه (مثل زمان ارسال کوئری یا گرفتن نتیجه)، ولی این بخش معمولاً کسری از کل زمانه.

2⃣ ‏Overhead خود Async: استفاده از async/await یه مقدار سربار (overhead) به کد اضافه می‌کنه. اگه عملیات دیتابیستون سریع باشه (مثلاً چند میلی‌ثانیه)، این سربار ممکنه حتی باعث شه Async کندتر بشه.

3⃣ مدیریت اتصالات:
دیتابیس‌ها معمولاً تعداد اتصالات همزمان (connection pool) رو محدود می‌کنن. حتی با Async، اگه تعداد کوئری‌ها زیاد باشه، ممکنه منتظر اتصال بمونین.

🔍 کی Async به کار میاد؟

هرچند Async تو اکثر عملیات دیتابیس تأثیر زیادی نداره، تو یه سری سناریوها می‌تونه خوب عمل کنه:

1⃣ دیتابیس‌های توزیع‌شده:
تو دیتابیس‌های NoSQL مثل MongoDB یا Cassandra که عملیات شبکه‌ای (مثل اتصال به نودهای مختلف) زمان‌بره، Async می‌تونه کمک کنه کلاینت همزمان چند درخواست رو مدیریت کنه.

2⃣ عملیات I/O-heavy:
اگه دیتابیستون روی یه سرور دور باشه یا شبکه کند باشه، Async می‌تونه زمان انتظار برای اتصال و انتقال داده رو بهتر مدیریت کنه.

3⃣ چندین درخواست همزمان:
اگه برنامه‌تون نیاز داره چند کوئری رو به‌صورت موازی اجرا کنه (مثل یه API که باید از چند جدول داده جمع کنه)، Async می‌تونه این درخواست‌ها رو همزمان مدیریت کنه.

4⃣ دیتابیس‌های خاص:
بعضی دیتابیس‌ها مثل CockroachDB یا Redis که برای عملیات سریع و توزیع‌شده طراحی شدن، با کلاینت‌های Async بهتر کار می‌کنن.

✍ جمع‌بندی
اینکه بگیم Async تو کار با دیتابیس معجزه می‌کنه یه کم زیاده‌رویه چون بیشتر عملیات دیتابیس CPU-bound هستن، استفاده از کلاینت‌های Async مثل asyncpg یا motor معمولاً تأثیر چشمگیری روی پرفورمنس نداره. اما تو سناریوهای خاص مثل دیتابیس‌های توزیع‌شده، عملیات شبکه‌محور یا درخواست‌های موازی، Async می‌تونه مفید باشه. پس قبل از اینکه همه‌چیز رو Async کنین، نوع عملیات‌تون رو بررسی کنین و ببینین کجا واقعاً به کارتون میاد.

#️⃣ #web #programming #db

➖➖➖➖➖➖➖➖➖➖ 

🥷🏻 CHANNEL | GROUP

بعضی دوستان میپرسن چطوری این نمودار های موبایل و دستکاپ سبز میشه بعد یه هو قرمز میشه

یکی از دلایل اصلیش اینه وقتی که شما راکت یا لایت اسپید رو کانفیگ میکنید از اون نوار بالا تند تند کش رو پاک میکنید یا تایم کش رو میزارید روی ساعت کم در صورتی که باید روی بینهایت باشه یا 0

خوب به چه درد میخوره هی پاک میکنید؟ راکت بخواد 4 هزار محصول کش کنه 2 ساعت طول میکشه بعد شما یه محصول بروز میکنید کل کشو پاک میکنید دوباره راکت دو ساعت زور میزنه کش میکنه دوباره شما کشو پاک میکنید

اگر عادت دارید مدام کش راکت و لایت اسپید پاک کنید از این نمودار سبز ها نخواهید داشت

یا اگرم دارید زمانی دارید که پاکش نکردید کش شده بعدش که پاک کنید دوباره خراب میشه

بعضی مشتریان ما روزی هزار بار کش راکت پاک میکنن خوب اصلا چرا کش نصب کردی

@poinair پوینا

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

یه سایت مشتری داشتیم که هیچ بهینه‌سازی خاصی روش انجام نشده بود. رو یه هاست با ۱۲ هسته قرار داشت و طبق تصویر بالا، به طور میانگین ۴ هسته مصرف می‌کرد.

بدون اینکه حتی یه خط کد یا تنظیم خاصی رو تغییر بدیم، فقط منتقلش کردیم به یه هاست دیگه با ۸ هسته.

الان مصرف CPU به طور میانگین به کمتر از نیم هسته رسیده

سرور میخرید یا هاست به تعداد هستش نگاه نکنید

@poinair پوینا

https://youtu.be/JeNS1ZNHQs8
برنامه نویسی تو سال ۲۰۲۵

تلگرام در کره شمالی، و یوتیوب، تلگرام و واتس‌اپ در روسیه فیلتر نیستند!

© AliSaedvandi

🔍 ircf.space
@ircfspace

یه اپی با پایتون زدم که میتونه از یک single source (برای مثال یک عکس) برای چندین پلتفرمی که داریم توسعه میدیم ( برای مثال یک اپلیکیشن اندرویدی یا حتی برای IOS و..) که قراره ایکون لانچر اپ از اون Folder Structure ، بخونه ، به راحتی این فولدر و عکس های مختلف در سایز های مختلف درست کنه و اون رو توی پروژه تون اضافه کنید

https://github.com/aminrms/app_icon_generator/

@DevTwitter | <Amin Ramezani/>

آقای ayub_kokabi اومدن و کتاب Refactoring UI رو ترجمه کردن؛ دانلودش کردم خیلی خوب بود شما هم تستش کنید : دانلود

@Linuxor

Today I Learned: animation-composition from this article

#css #animation

مقاله «Writing Go Code like a Pro!» در Go Chronicles، همراه با نکات مهم و مثال‌های کوچک برای درک بهتر:

---

🧠 نکات کلیدی برای نوشتن کد حرفه‌ای در Go

1. نام‌گذاری متغیرها و توابع

* از camelCase استفاده کنید و از snake\_case پرهیز شود.
مثال: myVariable بجای my_variable ☑️
* نام‌ها را کوتاه ولی واضح نگه دارید؛ بسته به scope، اسم کوتاه‌تر مناسب‌تر است.
* برای شاخص‌ حلقه‌ها از حروف تک مثل i استفاده کنید، نه index.

> بیشترین زمان را برای خواندن کد دیگران می‌گذارید، پس کدی بنویسید که دیگران بدون دردسر بفهمند.

---

2. نام‌گذاری پکیج‌ها

* نام پکیج‌ها باید کوتاه، پایین‌نویس (lowercase) و معمولاً مفرد باشند (مثلاً service بجای services, utils توصیه نمی‌شود).

---

3. طراحی ساختار پروژه

* پروژه‌های کوچک: تمام فایل‌ها در ریشه، مثل main.go.
* برای پروژه‌های با چند executable: ساختار پیشنهادی:

  cmd/
    app1/
    app2/
  internal/
  go.mod
  README.md
  

* فقط وقتی نیاز واقعی به جداکردن logic دارید، پکیج مجزا در internal/ بسازید.

---

4. رعایت اصول Domain-Driven Structure

* پکیج‌ها را براساس سرویس‌ها و موجودیت‌های دامنه تعریف کنید (مثلاً پکیج‌هایی مثل account, inventory).
* اجتناب از ساختار تقلیدی MVC یا مدل‌هایی که ممکن است منجر به circular dependency شود.

---

5. شروع ساده و افزایش تدریجی ساختار

* اگر ایده‌ای ندارید، فقط با go.mod و main.go شروع کنید؛ بعد با رشد پروژه، نیاز به طبقه‌بندی دقیق‌تر را تشخیص دهید. شروع مینیمال، کد قابل نگهداری را تسهیل می‌کند.

---

6. فایل‌های مرتبط را کنار هم نگه دارید

* توابع مرتبط، typeها و handlerهای یک واحد منطقی را در فایل‌های نزدیک یا مشابه قرار دهید؛ این کار خوانایی را بالا می‌برد.

---

7. اندازه فایل مهم نیست... مگر نگهداری را دشوار کند

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

---

8. وقتی لازم نیست پکیج جدا نسازید

* از ایجاد پکیج‌های کم‌اهمیت یا بسیار جزئی خودداری کنید؛ مگر قصد reuse مجزا یا جداسازی واضح logic را داشته باشید.)

---

9. به علائم هشدار ساختار دقت کنید

اگر موارد زیر را دیدید، زمان بازبینی ساختار فرارسیده:

* مشکل در یافتن نقاط کد،
* تغییرات گسترده در بخش‌های متفاوت،
* سخت شدن debug،
* وابستگی حلقوی یا پیچیدگی error handling.

---

💡 جمع‌بندی نهایی

* تأکید روی خوانایی، نگهداری‌پذیری و ساختار معقول.
* شروع از ساده‌ترین حالت، حفظ نام‌گذاری استاندارد Go و اجتناب از ساختارهای پیچیده غیر idiomatic Go.
* اجازه دهید پروژه در طول زمان ساختار مناسب خودش را بیابد، نه طراحی اولیه‌ی کاملاً دقیق.

📝 نکات کاربردی درباره strings.Builder

1. چهار روش نوشتن مختلف

strings.Builder از چهار روش برای افزودن محتوا پشتیبانی می‌کند:

* Write([]byte), WriteByte(byte), WriteRune(rune), WriteString(string)
بسته به نوع داده‌ای که در اختیار دارید، می‌توانید روش مناسب را استفاده کنید

2. نحوه ذخیره‌سازی داخلی

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

3. استفاده‌ی بهینه با Grow(n)

قبل از نوشتن با حجم بالا، بهتر است با Grow(n) ظرفیت را از پیش افزایش دهید تا از realloc جلوگیری شود:

* اگر ظرفیت فعلی کافی باشد، گسترش اتفاق نمی‌افتد.
* اگر ظرفیت کافی نباشد، با فرمول current_capacity*2 + n افزایش پیدا می‌کند

4. عملکرد String()

متد String() بدون تخصیص حافظه اضافی، یک رشته جدید از buffer داخلی ایجاد می‌کند—با استفاده از `unsafe`، فقط اشاره‌گر را باز می‌گرداند

### 5. هرگز یک Builder غیرصفر را کپی نکنید

کپی کردن یک `strings.Builder` که قبلاً نوشته شده باشد منجر به panic می‌شود:

var b1 strings.Builder
b1.WriteString("ABC")
b2 := b1
b2.WriteString("DEF") // panic!

فقط اشیاء صفر مقدار (بدون نوشتن) قابل کپی هستند

6. عدم پشتیبانی هم‌زمانی (Concurrency)

strings.Builder ایمن برای استفاده هم‌زمان از چند goroutine نیست؛ خواندن یا نوشتن هم‌زمان می‌تواند منجر به نتایج غیرمنتظره شود

7. پیاده‌سازی io.Writer

رابط Write(p []byte) (int, error) پیاده‌سازی شده است، بنابراین می‌توانید از strings.Builder به عنوان یک io.Writer استفاده کنید—مثلاً log‌سازی، fmt.Fprintf و …

---

⚡️ مثال استفاده

package main

import (
    "fmt"
    "strings"
)

func main() {
    var sb strings.Builder
    sb.Grow(100) 

    sb.WriteString("Hello")
    sb.WriteByte(' ')
    sb.WriteRune('世')
    sb.WriteString("界")

    fmt.Println(sb.String()) // خروجی: "Hello 世界"
    fmt.Printf("Len=%d, Cap=%d\n", sb.Len(), sb.Cap())
}

در این مثال:

* از Grow(100) برای کاهش realloc استفاده کردیم.
* با ترکیب WriteString, WriteByte, و WriteRune یک رشته UTF‑8 ساختیم.
* قابلیت گرفتن طول و ظرفیت نیز وجود دارد.
|