انتشار نسخه 15.2 از Next.js

که امکانات جذابی برای بهبود تجربه توسعه‌دهندگان به همراه دارد. در اینجا به خلاصه‌ای از ویژگی‌های جدید می پردازیم:

رابط کاربری جدید برای خطاها و بهبود استک‌ترِیس‌ها: یک رابط کاربری بهتر و طراحی‌شده برای نمایش خطاها که با دقت بیشتر به شما کمک می‌کند تا سریع‌تر مشکلات را شناسایی و رفع کنید.

استفاده از Streaming Metadata: حالا متادیتاهای async مانع از رندرینگ صفحات نمی‌شوند و بهبود زمان بارگذاری صفحات را به همراه دارد.

بهبود عملکرد Turbopack: زمان کامپایل تا 57.6% سریع‌تر و کاهش 30 درصدی مصرف حافظه در توسعه محلی.

تغییرات ویوها با استفاده از API جدید React View Transitions (آزمایشی): امکان انیمیت کردن بین ویوها و کامپوننت‌های مختلف در برنامه شما.

پشتیبانی آزمایشی از Node.js در Middleware(آزمایشی): قابلیت استفاده از Node.js در Middleware قبلا از این نمی شد از ویژگی های node مثلا package هاش در داخل middleware استفاده کرد .

https://nextjs.org/blog/next-15-2

@DevTwitter | <Alireza soltanian/>

🔶 استفاده دانشجویان از هوش مصنوعی، ناقوس مرگ برای تفکر انتقادی است.

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

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

به عنوان مثال، فهرست‌های مطالعه تنظیم‌شده برای استفاده دانشگاهیان در پژوهش اغلب توسط دانشجویان نادیده گرفته می‌شوند و جست‌وجو در «گوگل» جای آنها را می‌گیرد. اگر دانشجو از آنچه می‌خواند خوشش نیاید، می‌تواند به سادگی به گوگل روی بیاورد. الگوریتم‌ها می‌توانند دانشجویان را به جهت‌های غیرمنتظره بفرستند و اغلب آنها را از سختگیری تحصیلی به سمت منابع غیر دانشگاهی منحرف می‌کنند.

#خبر

@TheRaymondDev

نونگاه اول؛
🔰 «سودای منطق»
درآمدی بر دست‌یارهای اثبات

همراه با ارائه نسخه ایرانی
توسط توسعه‌دهندگان:
حمیدرضا کلباسی؛
دانشجوی رشته هوش مصنوعی دانشگاه شریف
ارشیا معینی؛
دانشجوی رشته ریاضی دانشگاه شریف

📆 سه‌شنبه ۱۴ اسفند ۱۴۰۳ | ساعت ۱۳:۳۰
📍 دانشگاه صنعتی شریف، کلاس ۱ معاونت فرهنگی
🌐 پخش مجازی در اتاق مجازی ژرفا

🔸 چنانچه دانشجوی دانشگاه شریف نیستید اما مایل به حضور در برنامه هستید، لطفاً تا ساعت ۹ روز سه‌شنبه ۱۴ اسفند این فرم را تکمیل فرمایید.

🔻 توضیحات بیشتر

🆔 @Zharfa90

من خیلی این دوستان رو نمی‌شناسم منتهی با یک سرچی که کردم فکر کنم دارن روی این پروژه کار میکنن. اول از همه باید بگم که خیلی دمشون گرم. توسعه‌ی theorem prover کار بسیار سختیه. منتهی به نظرم سخت تر از اون رقابت کردنه. البته شاید کلمه‌ی رقابت خیلی درست نباشه ولی خب هست.
قبل از اینکه ادامه بدیم، اگر با مفهوم Theorem prover آشنا نیستید و نمی‌دونید که چه نقش مهمی می‌تونن توی علم software بازی کنند توصیه می‌کنم این پست‌های کانال رو بخونید :

"Most Successful Program Based on a Wrong Idea - بخش اول"
"Most Successful Program Based on a Wrong Idea - بخش دوم"
"برنامه‌نویسی با طعم شیرین اثبات"
"You Want Poof? I'll give you proof!"
"باگ نه تنها در سافتور، بلکه در ریاضیات"
"اِوِرِست"
"معرفی منابع برای یادگیری Program به همراه Proof"

و اما بعد،‌ من تا جایی که متوجه شدم اسم پروژه‌ی این دوستان بَبَعی هستش(البته شایدم حکیم). این نام‌گذاری احتمالا بخاطر coq، تئورم پرور معروفه. خب coq یا همون خروس نماد کشور فرانسه‌است. جایی که این تئورم پرور ساخته شده. منتهی ببعی بعید می‌دونم نماد ما باشه. کاش اسم بهتری انتخاب بشه. مهم تر از اسم، رقابته. ببینید وقتی صحبت از Theorem prover می‌کنیم، باید حواسمون باشه که در مقابل ما یک کوهی از Theorem prover ها وجود دارند مثل coq و Agda و Isabelle/HOL و Lean و ACL2 که هر کدومشون یک غول بلا رقیبن. مثلا coq سی و پنج ساله که داره دولوپ میشه. یا Agda بیست و شش ساله که داره دولوپ میشه و پشت هر کدوم از این‌ها یک community چند صد نفره وجود داره. خب اگر ما قراره یک Theorem prover دیگه بسازیم، نقطه‌ی اتکا مون رو اگر فقط بذاریم روی بومی بودنش، سرنوشتش به لینوکس بومی، اندروید بومی، و کلی چیز بومی که دیگه اثری ازشون نیست می‌پیونده. ببعی یا هر حیوون دیگه‌ای :)) باید چیزی داشته باشه که کامیونیتی رو مجاب به استفاده ازش کنه. اینکه حقیقتا چه نقطه‌ی برتری‌ای نسبت به دیگر prover ها داره برای من روشن نیست و امیدوارم که توی ارائه‌شون این قضیه رو روشن کنن. یا حتی توی readme و wiki پروژه‌شون بهش اشاره کنن.

اما یک توصیه برای اونایی که کله‌شون باد داره و میخوان دست‌شون رو به نوشتن یک Theorem Prover آلوده کنند. تمرکزتون رو بذارید روی توسعه‌ی یک prover خاص منظوره. به‌طور خاص هدف رو روی program verification بذارید. و به طور خاص برنامه‌های concurrent و distributed. الان F* و Iris و KeY رو در نظر بگیرید که مسیری شبیه رو طی می‌کنند. مثلا KeY برای وریفیکیشن برنامه‌های جاوایی که spec شون با JML نوشته شده توسعه یافته. یعنی ورودیش یک برنامه‌ی جاوا با annotation های JML هستش و اینو ترنسلیت می‌کنه به dynamic logic. زیر بناش هم یک first order theorem prover مبتنی بر sequent calculus داره. منتهی با همه‌ی این حرفا، کار خاصی روی برنامه‌های multi-thread جاوا نمی‌تونه انجام بده. اینجا یک گپی وجود داره که باید یکی پرش کنه. شاید اون یک نفر تو باشی.

البته که رئیس زبان تندی داره و یکمی باید چیل داون کنه :))) ولی نکات مهمی رو لابه‌لای دق و دلی هاش اشاره کرد

آقا من این رو هم بگم،
قبول دارم که بعضی وقتا ادایی میشم و مثلا توی متنام به جای سخنرانی میگم talk یا مثلا به جای رویداد میگم event، ولی بیاید و در پویش حفظ و نشر لغات فنی و آکادمیک کوشا باشم. همونطور که غرب وقتی با جبر و خوارزمی آشنا شد، ترجمه‌اش نکرد، بیاید ما هم چیزایی که غرب ابداع کرده و توسعه داده رو دست نزنیم.

یادی کنیم از این وویس استاد روحانی :)

جا داره یادی کنیم از این وویس استاد روحانی :)

خطرات هوش مصنوعی (جالب!)

کوشیار عظیمیان فارغ التحصیل دانشگاه شریف که مدتی مهندس فیسبوک در سیلیکون-ولی یا محله‌ی غول های فضای مجازی مثل گوگل و آمازون بوده،
امروز خودش شرکت هوش مصنوعی تأسیس کرده که مولکول های عجیب طراحی می کنن!
مولکول های شرکت ایشون قادر هستن که در بدن با بیماریهایی مثل سرطان، آلزایمر یا حتا پیری مقابله کنن!
ایده‌ی ساخت این شرکت از اونجا بوده که شنیده هر ۵ دقیقه در بدن سلولهای سرطانی ساخته میشن اما تکامل باعث شده که بدن با آزاد کردن مولکول هایی به جنگ این سلولها بر‌ه. حالا با هوش مصنوعی تولید این مولکول ها با سرعت بالاتر و در زمان کمتر ممکن شده!

خیام | رباعیات | رباعی شمارهٔ ۱۰

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

#خیام | گنجور
📍@iipoem

### 10. گراف وابستگی‌ها

go mod graph

- کاربرد: یه گراف متنی از همه وابستگی‌ها و ارتباط بینشون رو نشون می‌ده (ماژول‌ها و نسخه‌هاشون).
- مثال:

  go mod graph
  

- خروجی: مثلاً main github.com/gorilla/mux@v1.8.0 نشون می‌ده که ماژول اصلی به mux وابسته‌ست.

---

### 11. چرا یه وابستگی استفاده شده

go mod why -m <module>

- کاربرد: توضیح می‌ده که چرا یه ماژول خاص توی پروژه‌ت لازمه و کدوم بخش از کدت بهش وابسته‌ست.
- مثال:

  go mod why -m github.com/gorilla/mux
  

---

### 12. پاک کردن کش ماژول‌ها

go clean -modcache

- کاربرد: کش محلی ماژول‌ها (توی ~/go/pkg/mod) رو پاک می‌کنه. اگه مشکلی با وابستگی‌ها داری، این می‌تونه کمک کنه.
- مثال:

  go clean -modcache
  

---

### 13. استفاده از vendor

go mod vendor

- کاربرد: یه پوشه vendor/ توی پروژه‌ت می‌سازه و همه وابستگی‌ها رو اونجا کپی می‌کنه (برای سازگاری با پروژه‌های قدیمی یا بدون اینترنت).
- مثال:

  go mod vendor
  

- نکته: بعدش می‌تونی با go build -mod=vendor ازش استفاده کنی.

---

### 14. تغییر نسخه Go

go mod edit -go=<version>

- کاربرد: نسخه گولنگی که پروژه‌ت باهاش سازگاره رو توی go.mod تغییر می‌ده.
- مثال:

  go mod edit -go=1.21
  

---

### 15. حذف یه وابستگی خاص

go mod edit -droprequire=<module>

- کاربرد: یه ماژول خاص رو از لیست وابستگی‌های go.mod حذف می‌کنه (بدون چک کردن استفاده).
- مثال:

  go mod edit -droprequire=github.com/old/repo
  

---

### 16. حذف جایگزینی (replace)

go mod edit -dropreplace=<old-path>

- کاربرد: یه قانون جایگزینی رو از go.mod پاک می‌کنه.
- مثال:

  go mod edit -dropreplace=github.com/old/repo
  

---

### 17. اجرا با حالت فقط خواندنی

go build -mod=readonly

- کاربرد: پروژه رو می‌سازه بدون اینکه go.mod یا go.sum رو تغییر بده (برای تست سازگاری).
- مثال:

  go build -mod=readonly
  

---

### 18. دانلود نسخه خاص بدون تغییر go.mod

go get <module>@<version>

- کاربرد: فقط نسخه خاصی از یه ماژول رو دانلود می‌کنه، ولی اگه توی کدت استفاده نشه، توی go.mod ثبت نمی‌شه (با go mod tidy پاک می‌شه).
- مثال:

  go get github.com/gorilla/mux@v1.7.0
  

---

جمع‌بندی:
دستورات بالا بیشتر برای مدیریت پیشرفته‌تر یا رفع مشکلات خاص کاربرد دارن. مثلاً go mod graph و go mod why برای دیباگینگ وابستگی‌ها عالی‌ان، یا go mod vendor برای سناریوهای آفلاین. اگه بخوای روزمره کار کنی، همون دستورات قبلی (مثل go get و go mod tidy) کافین، ولی اینا توی پروژه‌های بزرگ یا پیچیده به کار میان.

➖➖➖➖➖➖➖➖
👑 @gopher_academy

به به!

دوره ی 5 روزه ی گوگل (رایگان) برای یادگیری GenAI برای developerها...

سرفصل هاش بسیار جالبه و شخصا سعی میکنم برم این دوره رو...

یه پروژه ی پایانی هم بتون میدن که انجام بدین...

https://rsvp.withgoogle.com/events/google-generative-ai-intensive_2025q1

@DevTwitter | <Sam92/>

موزیلا فایرفاکس ۱۳۶ با تب عمودی و باینری آرم۶۴ منتشر شد.


https://9to5linux.com/mozilla-firefox-136-is-out-with-vertical-tabs-and-official-arm64-linux-binaries


@SohrabContents

خیلی وقته که براتون لینک تخفیف دوره یودمی نذاشتم.
دوره پرامپت نویسی chat gpt با قیمت ۲۰ یورو.
با لینک زیر رایگان برای شما

https://www.udemy.com/course/chatgpt-101-42/?couponCode=4FD47E6896B03DA2C89E

@DevTwitter | <Farhad Fallah/>

چون این رو خیلی‌ها فرستادید.

لذت می‌برم می‌بینم اعضای کانال همه حرفه‌ای و با دقت هستند، دمتون گرم آدم امیدوار می‌شه.

Github

استراترژی های cache eviction متنوع هستند و ما معمولا از ساده ترین و دم دست ترین گزینه که eviction by ttl هست استفاده می کنیم. اما شیوه های مختلفی از eviction وجود داره که میتونه کاربردی باشه. مثلا فرض کنید یه فروشگاه دارید که اطلاعات هر محصول رو کش می کنید با ttl مشخص، احتمالا لود این محصولات یکسان نیست و ممکنه محصولی باشه که خیلی دیده میشه و یک محصولی هست که خیلی دیر به دیر دیده میشه، تو این شرایط بهتره سیاست هوشمندانه تری برای eviction داشته باشیم.


1. Least Recently Used (LRU):
- Evicts the least recently accessed items first.
- Assumes that items accessed recently are more likely to be accessed again soon.
- Implemented using a linked list and a hash map for efficient access and updates.

2. First In, First Out (FIFO):
- Evicts the oldest items in the cache first, regardless of how often or recently they were accessed.
- Implemented using a queue.

3. Least Frequently Used (LFU):
- Evicts the least frequently accessed items first.
- Assumes that items accessed frequently are more likely to be accessed again.
- Can be implemented using a min-heap and a hash map.

4. Most Recently Used (MRU):
- Evicts the most recently accessed items first.
- Useful in scenarios where older items are more likely to be accessed again.
- Implemented using a linked list and a hash map.

5. Random Replacement (RR):
- Evicts a random item from the cache.
- Simple to implement but may not be as efficient in terms of cache performance.

6. Least Recently Used with Time-to-Live (LRU-TTL):
- Combines LRU with a time-to-live (TTL) value for each item.
- Evicts items that have expired (TTL has elapsed) first, then falls back to LRU.

7. Segmented LRU (SLRU):
- Divides the cache into two segments: a probationary segment and a protected segment.
- New items enter the probationary segment and are promoted to the protected segment upon subsequent accesses.
- Evicts items from the probationary segment first.

8. 2Q (Two Queues):
- Uses two queues: one for items accessed once (A1 queue) and one for items accessed multiple times (Am queue).
- Evicts items from the A1 queue first, promoting items to the Am queue upon subsequent accesses.

9. Clock (Second Chance):
- Uses a circular buffer (clock) and a reference bit for each item.
- Evicts items with a reference bit of 0, giving items with a reference bit of 1 a "second chance" by resetting their bit.

10. Adaptive Replacement Cache (ARC):
- Combines LRU and LFU to adaptively balance between recency and frequency.
- Maintains two lists: one for recently accessed items and one for frequently accessed items.
- Adjusts the size of these lists dynamically based on access patterns.

11. Greedy-Dual Size (GDS):
- Evicts items based on a cost-to-size ratio, considering both the cost of fetching the item and its size.
- Useful for caches where items have varying sizes and fetch costs.

12. Time-Aware Least Recently Used (TLRU):
- Extends LRU by considering the time of access and the duration since the last access.
- Evicts items that have not been accessed for the longest time.

13. Write-Once:
- Specifically for write caches, evicts items that have been written once and not read.
- Useful in scenarios where write operations are more frequent than read operations.

14. Not Recently Used (NRU):
- Evicts items that have not been used recently, based on a simple heuristic.
- Often implemented using a single reference bit per item.

15. Low Inter-reference Recency Set (LIRS):
- Focuses on the inter-reference recency, which is the time between consecutive accesses to the same item.
- Evicts items with low inter-reference recency.

این مقاله هم خوبه که مطالعه بشه
https://newsletter.systemdesigncodex.com/p/cache-eviction-strategies



@gocasts

Ai for Software
@aicasts_ir

کمپانی Pebble بین ۲۰۱۲ تا ۲۰۱۶ ساعت هوشمند میساخته و همون دوره هم گوگل اون ها رو خریده. حالا آقای Eric Migicovsky، بنیان‌گذار شرکت، بعد این که گوگل، سیستم‌عامل ساعت رو اوپن سورس کرده دوباره تصمیم گرفته ماجرا رو تحت عنوان rePebble از سر بگیره.

Pebble is an e-paper smartwatch with simple functionality, long battery life, and fun, quirky design. It first launched on Kickstarter in 2012 and sold over 2 million watches before the company's IP was sold to Fitbit in 2016.

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

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

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

نکته‌ی ماجرا کجاست؟
برای من دیدن این فرآیند و چالش‌ها و شنیدن ماجرا از زبون آدمی که یک کاری میکنه‌س که هیجان‌انگیزه. چه کاری؟ هر کاری! میخواد سازنده‌ی pebble باشه، میخواد Daniel Stenberg باشه سازنده‌ی curl یا میخواد یک آدم رندوم باشه که تو یه کانال تلگرامی، که از وضعیت زندگیش در هفته‌ی گذشته، خوب و شفاف مینویسه. معتقدم که خوندن تجربیات دست اول و بی‌واسطه آدم‌ها، هزاران برابر با ارزش تر از خوندن کتاب‌های این کاره. فکر میکنم این بی‌پرده بودنه، نه‌تنها اون ویژن و درک رو گسترش میده، که بار‌ها و بار‌ها انگیزه‌بخش تره. به اثر‌بخشی تزریق مستقیم مرفین به نخاع.

برای تمام این‌هاست که فکر میکنم یک کتاب خاطرات از بهترین زندگی‌نامه‌ها صد‌ها بار بهتره.