هرچیزی که برنامه‌نویس های سی در مورد رفتار غیرقطعی باید بدانند:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

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

این ابزاره (presenterm) یه ابزار برای تولید اسلاید و پرزنتیشن توی ترمیناله. به این صورت که یه فایل markdown می‌نویسی و بهش میدی و اسلاید تحویلت می‌ده. حداقل خیلی به درد من خورده گفتم شاید به درد شما هم بخوره :)

https://github.com/mfontanini/presenterm

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

https://github.com/Rigellute/spotify-tui

سایت بسیار خوبیه در مقایسه llm‌ها با هم از نظر معیارهای مختلف (کیفیت و سرعت و هزینه و ....):


https://artificialanalysis.ai/

آیا مهندس نرم‌افزار، واقعا مهندس حساب می‌شود؟
https://www.hillelwayne.com/post/are-we-really-engineers/

روز مهندس رو بهتون تبریک می‌گم :)))))

یه شعر کم محتوا ولی احتمالا نوستالژی در مورد C!

https://www.youtube.com/watch?v=H4YRPdRXKFs

یه مطلب خیلی خوب در مورد تاثیر generative ai بر برنامه‌نویسی و تیم‌های توسعه. در آخر هم نظراتش در مورد برنامه‌نویس جونیور و اینکه چرا برای اکثر تیم‌ها وجودش لازمه رو می‌گه.

https://stackoverflow.blog/2024/12/31/generative-ai-is-not-going-to-build-your-engineering-team-for-you/


خلاصه ماجرا اینه که نوشتن کد کوچکی که قیافه خوبی داشته باشه، کاریه که ai خوب امکان میده ولی کار سخت برنامه‌نویس‌ها نیست. در واقع برای ai از مثال برنامه‌نویس جونیوری استفاده می‌کنه که همیشه هم جونیور می‌مونه و سازوکار و ساختارهای فعلی پروژه/شرکت رو یاد نمی‌گیره.

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

یه نکته خودم اضافه کنم: فرض کنیم یه برنامه‌نویس با کمک ai الان پروداکتیویتیش ده برابر شده، خب این به این معنی نیست که ۹ تا برنامه‌نویس قراره اخراج بشن، بلکه به این معنیه که شرکت قراره زودتر به اهدافش برسه و از رقیب‌هاش جلو بزنه و پروداکت‌های جدید رو سریع‌تر لانچ کنه و ...

به نظر میاد موزیلا داره هرکاری در توانش هست انجام میده که کاربرای فایرفاکس رو ناراحت کنه.

در ساعت‌های اخیر یه تغییری در FAQشون دادن و اون قولی که داده بودن از دیتای ملت استفاده نکنن رو برداشتن! همچنین یه acceptable usage policy اضافه کردن که چیکار ها حق ندارید با این مرورگر بکنید.

مهم ترین چیزی که مردم رو ناراحت کرده اینه:
When you upload or input information through Firefox, you hereby grant us a nonexclusive, royalty-free, worldwide license to use that information to help you navigate, experience, and interact with online content as you indicate with your use of Firefox.

توضیحات:
https://www.omgubuntu.co.uk/2025/02/mozilla-introducing-terms-of-use-to-firefox

نظرات مردم در هکرنیوز:
https://news.ycombinator.com/item?id=43194536

نظرات مردم در ردیت:
https://www.reddit.com/r/firefox/comments/1iyuvjf/introducing_a_terms_of_use_and_updated_privacy/


یک ویدیوی خوب در X
https://x.com/LundukeJournal/status/1895198058289471966?t=UaJHNMxAgOfeCdbLzKXRDg&s=19

متن aup رو میتونید از اینجا بخونید:
https://mozilla.org/en-US/about/legal/acceptable-use/

این کامنت‌ها روی کامیتی که مربوط به حذف «ما هیچوقت دیتای شما رو نمی‌فروشیم» هم قابل توجه بود:
https://github.com/mozilla/bedrock/commit/d459addab846d8144b61939b7f4310eb80c5470e#commitcomment-153095625

یه سایت برای پیدا کردن پلاگین‌های جدید و مطرح برای vim/neovim!

https://dotfyle.com/

دوست دارید فرق Developer و Tech lead و Engineering manager رو بدونید؟

این ریپوی گیتهاب، میاد و میگه هر نقش چطوری رو تکنولوژی، سیستم، افراد، پروسه ها تاثیر می‌ذاره (یا تاثیر می‌پذیره). همچنین می‌تونه ایده خوبی بده چطوری می‌تونیم تو نردبان شغلی پیش‌رفت کنیم.

https://github.com/jorgef/engineeringladders

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

در مورد این که چه مدلی خوبه که از برنچ‌های گیت استفاده کنیم، ایده‌های مختلفی مطرح می‌شه.
یکی از بهترین‌هاش در این دوره زمونه، trunk based developmentئه. (مدلهای دیگه مثل git flow هم وجود داره)

در مورد trunk based اینجا می‌تونید اطلاعات خوبی کسب کنید.
https://trunkbaseddevelopment.com/

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

ساختمان داده ها احتمالاتی، ساختمان داده هایی هستن مثل bloom filter که پاسخ نزدیکی به ما میدن ولی نه لزوما دقیق. با این که گارانتی دقت رو نمیدن، مزایای دیگه‌ای دارن مثلا مصرف مموری کمتری دارن یا از نظر محاسباتی سبک‌تر هستن.

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

https://engineering.fb.com/2018/12/13/data-infrastructure/hyperloglog/

۱۰ برابر شدن سرعت TypeScript با پورت کامپایلر به GO

در این ویدئو Andres Hejlsberg (خالق تایپ‌اسکریپت و سی‌شارپ) توضیح می‌دهد که چگونه با پورت کردن کدهای کامپایلر TypeScript به GO، سرعت کامپایل را 10x بهتر کرده‌اند!

او همچنین توضیح می‌دهد که چرا زیرساخت JavaScript برای این کار مناسب نیست. در حقیقت این زبان بیشتر برای کارهای UI طراحی شده بوده و زیرساخت‌های لازم برای کارهای performance-intensive مانند این کار را ندارد.

برای من خیلی جالب بود خالق سی‌شارپ، زبان GO را برای این کار انتخاب کرده، پس مستندات مربوط به این تصمیم را خواندم.
https://github.com/microsoft/typescript-go/discussions/411

اولین نکته جالب این بود که چقدر بدون تعصب و با ذهن باز زبان‌های مختلف رو بررسی کردن.
با توجه به اینکه هر دو زبان‌ C#, GO از لحاظ پرفورمنسی بسیار خوب هستند، یکی از مهم‌ترین دلایل انتخاب GO تشابه بسیار بالای سینتکس آن با TypeScript بوده است.

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

از بین زبان‌های C#, GO و Rust، زبان گو تشابه سینتکسی بیشتری با تایپ‌اسکریپت داشته و در نهایت انتخاب شده.

به نظرم نحوه انتخاب زبان برای این کار توسط خالق سی‌شارپ و تایپ‌اسکریپ، درس‌های تکنیکال و بیزسنی زیادی برای یاد گرفتن داره. نظر شما چیه؟


https://www.youtube.com/watch?v=pNlq-EVld70

#مهران_داودی (لینکدین - بلاگ)

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنت‌ها به اشتراک بگذارید.

کانال تلگرام:
@SoftwarePhilosophy

______

🤔 تا حالا به این فکر کردی که تحصیلات طرفدارای پرسپولیس بیشتره یا استقلال؟

🤔 یا اینکه آدمایی که ازدواج کردن خودشونو خوشبخت‌تر میدونن یا مجردا؟

🤔 یا تا حالا فکر کردی که بشه از همه کسایی که مهاجرت کردن نظرشونو در مورد مهاجرتشون پرسید؟


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

برای اینکه همراهمون باشی از طریق این بات نظراتت رو ثبت کن:
🆔 @prisma_poll_bot

برای دیدن نتایج هم کافیه توی چنلمون عضو شی:
🆔 @prisma_thoughts

اگه خوشت اومد ما رو به دوستات هم معرفی کن که به تحلیل بهتر نظرات کمک کرده باشی 🤌

ابزار مدیریت محصول Linear که یکی از استارت‌آپ‌های خیلی موفق چند سال گذشته است، به خاطر نگاه متفاوتی که به روند توسعهٔ محصولشون داشتن در کامیونیتی‌های پروداکت و UX خیلی ازش صحبت می‌شه. اونا تونستن که محصول خیلی باکیفیتی ارائه بدن و خیلی‌ها معتقدن از رقیب‌های بزرگشون مثل Jira و Clickup تجربهٔ کاربری بهتری ارائه می‌دن.

یک محصول خوب با پشتیبانی یک تیم مهندسی خوب ساخته می‌شه. Sabin Roman که Engineer Manager و Hiring Manager این شرکته، اخیراً مصاحبهٔ خیلی خوبی با Gergley Orosz داشته. هر دوی این افراد در گذشته در Uber با هم همکار بودن و به همین دلیل مقایسه‌های جالبی بین شرکت بزرگی مثل Uber و استارت‌آپ نسبتاً جدیدی و کوچکی مثل Linear شکل می‌گیره.

نکاتی در مورد فرهنگ شرکت Linear که برام جالب‌ بود:
- شرکتشون کاملاً ریموته و بر روی این اصل پافشاری می‌کنن. مصاحبه‌کننده بر این باوره که remote first بودن مزایای زیادی رو به شرکت‌ اضافه می‌کنه، حتی با وجود این که سربار بیشتری برای مدیرهای شرکت‌ داره.
- حل یک باگ همواره براشون اولویت بالاتری از توسعهٔ محصول داره و همهٔ اعضای تیم موظفن که در زودترین زمان ممکن باگ رو رفع کنن و برای این مسئله فرآیند مشخصی دارن.
- مهندس‌هاشون ارتباط مستقیم و بدون واسطه‌ای با مشتری‌ها دارن و حرف‌هاشون رو می‌شنون و مشکلات محصول رو می‌بینن.

ویدیو رو می‌تونید از این لینک ببینید.

@aminrbg

https://iximiuz.com/en/posts/containers-distroless-images/

دوست دارید از بیس ایمج scratch استفاده کنید برای داکر فایل هاتون، ولی خیلی خالیه و امکانات مورد نظر رو نداره؟
از طرفی alpine هم زیادی امکانات و attack surface داره؟

یه ایمج استاتیک وجود داره که در حد پوشه بندی استاندارد و tzinfo رو فراهم می‌کنه ولی پکیج‌منیجر نداره.

یه نکته که الان در مورد چنل متوجه شدم اینه که از دسامبر به بعد پیام زماندارهایی که برا ساعت ۲۰:۰۰ می‌ذارم، با تاخیر خیلی زیاد میرسه. قبلا خود ۲۰:۰۰ یا ۲۰:۰۱ می‌رسید ولی تاخیره به ۳ تا ۵ دقیقه رسیده!
حتی در یه مورد یک دقیقه زودتر بوده!

راستی، فرض کنید می‌خوایم سیستم پیام زماندار تلگرام رو طراحی/پیاده‌سازی کنیم، به نظرتون چه چالش‌هایی داره و چطوری میشه حلشون کرد؟

ابزاری هم اگه می‌شناسید که کمک می‌کنه برای پیاده‌سازی بگید بهمون.

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

لینک گیتهاب پروژه:

https://github.com/myanvoos/algoMIDI

لینک صفحه لایو پروژه:
https://algomidi.vercel.app/


دو تا قابلیت داره، یکی ساخت صدا از الگوریتم های پیمایش گراف که فقط تو کامپیوتر در دسترس هست.
یکی هم این که بهش یه زمین Conway's game of life میدید و به ازای هر پیمایش که می‌ره جلو، صدای خونه‌های متناظر رو پخش می‌کنه.