یکی از اولین قربانیهای پیدایش LLMها مثل ChatGPT یا Claudi رفیق قدیمی و وفادار برنامهنویسها بود، یعنی Stackoverflow.
عملا LLMها کلی مطلب از Stackiverflow یاد گرفتن و باعث زوالش شدن. شاید شما هم این روزها کمتر بهش مراجعه کنید، ولی سوال اینجاست که در آینده اگر دیگه استکاورفلو نباشه، یا حتی اینقدر پر و پیمون نباشه، LLM ها، پاسخ شرایط خاص، ایرادهای نادر، و نکات تجربی رو از کی یاد بگیرن؟!
حداقل تا الان LLMها چیزی فراتر از یک auto complete خیلی خیلی بزرگ نیستن. درک و شعور به معنی رایج ندارن که خودشون استنتاج و تحلیل کنند. مگه اینکه آینده مدلهایی مثل o1 یا دستیابی به AGI شرایط رو تغییر بده!
به دو دلیل سعی کنیم از stackoverflow و google بیشتر استفاده کنیم:
۱: پویایی بیشتر، فرصت یادگیری و پرهیز از copy/paste که باعث میشه کمسوادتر بشیم و باسوادتر به نظر بیاییم!
۲: محیط زیست! هر یک سوال از ChatGPT مقدار زیادی کربن و گرما ایجاد میکن
عملا LLMها کلی مطلب از Stackiverflow یاد گرفتن و باعث زوالش شدن. شاید شما هم این روزها کمتر بهش مراجعه کنید، ولی سوال اینجاست که در آینده اگر دیگه استکاورفلو نباشه، یا حتی اینقدر پر و پیمون نباشه، LLM ها، پاسخ شرایط خاص، ایرادهای نادر، و نکات تجربی رو از کی یاد بگیرن؟!
حداقل تا الان LLMها چیزی فراتر از یک auto complete خیلی خیلی بزرگ نیستن. درک و شعور به معنی رایج ندارن که خودشون استنتاج و تحلیل کنند. مگه اینکه آینده مدلهایی مثل o1 یا دستیابی به AGI شرایط رو تغییر بده!
به دو دلیل سعی کنیم از stackoverflow و google بیشتر استفاده کنیم:
۱: پویایی بیشتر، فرصت یادگیری و پرهیز از copy/paste که باعث میشه کمسوادتر بشیم و باسوادتر به نظر بیاییم!
۲: محیط زیست! هر یک سوال از ChatGPT مقدار زیادی کربن و گرما ایجاد میکن
👍9
tech-afternoon
مقدمه: ESME یا CMAScript modules و AMD یا Asynchronous Module Definition دو روش برای مدیریت و بارگذاری ماژولها در جاوااسکریپت هستند. AMD قدیمیتره و برای کار در مرورگرهای قدیمی طراحی شده، در حالی که ESM استاندارد جدیدتر و بخشی از خود زبان جاوااسکریپت است.…
🔅 چند هفته پیش نوشتم که تیم VS Code در حال پیادهسازی ECMAScript modules است، نتیجه ۲ سال توسعه مداوم و برنامهریزی شده به اتمام رسید.
حالا VS Code جدید توی کانال اینسایدر قرار گرفته و این نمودار بهینگی پرفرمنس اجرای اولیه نرمافزار است.
شاید در نگاه اول بگیم «خب به ما چه؟» ولی نکته اصلی درس چگونگی «مدیریت تغییرات» و نگاه همیشگی به تغییرات و روزآمدی زیرساختهای نرمافزار در کنار تغییرات فانکشنال است...
نظرتون چیه؟
حالا VS Code جدید توی کانال اینسایدر قرار گرفته و این نمودار بهینگی پرفرمنس اجرای اولیه نرمافزار است.
شاید در نگاه اول بگیم «خب به ما چه؟» ولی نکته اصلی درس چگونگی «مدیریت تغییرات» و نگاه همیشگی به تغییرات و روزآمدی زیرساختهای نرمافزار در کنار تغییرات فانکشنال است...
نظرتون چیه؟
🔥5
✨ نکات ادمینی برای مهاجرت به PostgreSQL ویژه SQL Server DBA ها
حتی بهعنوان معمار یا توسعهدهنده، در صورت آگاهی از قابلیتهای دیتابیس انجین، میتونیم سولوشنهای بهتری برای نیازهامون طراحی کنیم.
بخش ۷ فلشکارتهای قرمزمون، ویژه Failover، Disaster Recovery و Backup است. و بهصورت روزانه کامل میشن ✍️
#MSSQL_to_PGSQL
حتی بهعنوان معمار یا توسعهدهنده، در صورت آگاهی از قابلیتهای دیتابیس انجین، میتونیم سولوشنهای بهتری برای نیازهامون طراحی کنیم.
بخش ۷ فلشکارتهای قرمزمون، ویژه Failover، Disaster Recovery و Backup است. و بهصورت روزانه کامل میشن ✍️
#MSSQL_to_PGSQL
👍4
🔐 گوگل، کاهش ۷۴٪ی آسیبپذیریهای امنیتی حافظه در اندروید رو به بازنویسی بخشهایی با Rust به دست آورده.
اصلا و ابداً دوست ندارم جَو بدم که «امروزه، عصر Rust است و...» هدفم از این اشتراک این خبر، Rust نیست، بلکه اشاره به اهمیت اصل Security by Design و تکنیکهای Safe Coding است.
اگر هر کدوم از مفاهیم زیر براتون جالب است، کامنت بگذارید، شاید بتونیم یه جلسه از تکافترنون یا چند فلشکارت رو بهش اختصاص بدیم 😉
- Secure Software Development Life Cycle (SSDLC)
- Security Development Lifecycle (SDL)
- Safe Coding
- Security by Design
- DevSecOps
- Threat Modeling
- Static Application Security Testing (SAST)
- Dynamic Application Security Testing (DAST)
اصلا و ابداً دوست ندارم جَو بدم که «امروزه، عصر Rust است و...» هدفم از این اشتراک این خبر، Rust نیست، بلکه اشاره به اهمیت اصل Security by Design و تکنیکهای Safe Coding است.
اگر هر کدوم از مفاهیم زیر براتون جالب است، کامنت بگذارید، شاید بتونیم یه جلسه از تکافترنون یا چند فلشکارت رو بهش اختصاص بدیم 😉
- Secure Software Development Life Cycle (SSDLC)
- Security Development Lifecycle (SDL)
- Safe Coding
- Security by Design
- DevSecOps
- Threat Modeling
- Static Application Security Testing (SAST)
- Dynamic Application Security Testing (DAST)
🔥6
- خیلی از نوآوریها و بهینگیهای پایگاهداده چه در سطح قابلیتهای کاربردی، چه در سطح بهینهسازیهای الگوریتمی و محاسباتی طی ۳۰ سال گذشته اول توی PostgreSQL اومد. مثلا Multiversion Concurrency Control (MVCC) (کنترل همزمانی چند نسخهای) یا مثلا GiST (Generalized Search Tree) مفاهیمی بودند که بقیه از PostgreSQL الهام گرفتن. یا برخی بهینگیهای Query Optimizer.
- از اونجایی که محصول رایگان و کدباز است، طبیعتا انتظار بلوغ ابزارها، خصوصا توی لایهی مدیریت رو نمیشه ازش داشت و مثلا همین Citus یا Barman یا ابزارهای جانبی متعددی کنارش ارائه میشن که شاید توی محصولات گرون و اینترپرایز مثل Oracle یا SQL Server همراه با خود محصول و با پشتیبانی رسمی ارائه میشن.
- خصوصا وقتی پای خرید لایسنس و استفاده قانونی از محصول به میون بیاد، دانش PostgreSQL لازم میشه.
- 🗿 تجربه شخصی: من حدود ۲۰ ساله به صورت تخصصی در کنار هر فعالیتی که توی حوزه نرمافزار داشتم، در زمینه دیتابیس فعال بودم، از تدریس، مشاوره، طراحی تا نگهداری و بهینهسازی دیتابیسهایی از چند ده گیگابایت تا چندصد ترابایت. خلاصه میتونم بگم زمان و انرژی نگهداری PostgreSQL در فضای غیر ابری (On-premise) نسبتا بیشتر از محصولاتی مثل Oracle یا SQL Server است (هرچقدر هم ساختار و دیتا بزرگتر، زمان و انرژی بیشتری لازمه). ولی از نظر معماری و مفاهیم آکادمیک دیتابیس، وقتی به query planner / optimizer نگاه تخصصی و علمی داشته باشیم، 💎 فوقالعاده است. اما توی محیط واقعی، خصوصا وقتی دیتابیس بزرگه، تعداد کاربر و کوئریهای همزمان زیاده، و یا شرایط بدی پیش بیاد، عموما ایرادیابی و مدیریت Oracle یا SQL Server به مراتب سریعتر و بیدردسرتر است. ولی اگر روزی پای خرید لایسنس به میون بیاد، بعیده حتی سازمانهای بزرگ هم قادر به حفظ محصولاتی باشن که الان بدون یک ریال هزینه لایسنس استفاده میکنن. اگر مهاجرت کرده باشید، یا پلنش رو داشته باشید، موضوع لایسنس خیلی ملموستره.
من PostgreSQL رو خیلی بعدتر از بقیه پلتفرمها شروع کردم (از نسخه ۹.۱، حدودا سال ۲۰۱۲) و تمام این سالها شاهد نوآوریهایی بودم که بخش زیادیش کاربرد تخصصی داشت و مثلا ابزارهای بکاپگیریش تا همین نسخه ۱۷ حتی با SQL Server 2005 شاید قابل مقایسه نباشه! (البته به جز Object Restore که دلیلش هم تفاوت مکانیزمشونه) هر پروژهای، هر تیمی، هر سازمانی، هر محصولی، هر بودجهای و دهها از این «هر» ها باعث میشن تا انتخاب بهینه تغییر کنه. نمیشه به همه گفت MySQL یا PostgreSQL یا ... استفاده کنید. بلکه بخشی از مهندسی، انتخاب ابزار مناسب و متناسب است. و سعی کنیم توی بازیهای بچهگانهی این بهتر است یا اون نیوفتیم. بدون شک، PostgreSQL یکی از بازیگرهای اصلی حوزه دیتابیس است و برای سناریوهای مختلفی میتونه گزینه خیلی خوبی باشه. فقط یادمون باشه، مثلا تنوع ایندکسهاش بیشتر از SQL Server است، یا پیادهسازی HA با مکانیزمهای اوراکلی مثل اکتیو دیتاگارد یا RAC فرق داره، حتی روشهای ذخیرهسازی یا ایراد یابیش، ابزارهای مونیتورینگ و... پس صرف اینکه بخش عمده دستورات SQL توی همشون مشابهه توی تلهی توهم بلد بودن نیوفتیم و تیم و محصول رو به مشکل نندازیم. حتی چون مثل Microsoft یا Oracle ساختار یادگیری آزمونمحور و Certificateی نداره، انتخاب کتاب خوب هم گاها نیاز به تورق و چک کردن چند تا کتاب داره تا بتونین گزینه بهتر رو انتخاب کنید.
منتظر کارتقرمزهای 🟥 بعدی باشید... 😉
خوشحال میشم تجربیات، نظر یا پرسشهاتون رو طرح کنید و گپ بزنیم 💬
- از اونجایی که محصول رایگان و کدباز است، طبیعتا انتظار بلوغ ابزارها، خصوصا توی لایهی مدیریت رو نمیشه ازش داشت و مثلا همین Citus یا Barman یا ابزارهای جانبی متعددی کنارش ارائه میشن که شاید توی محصولات گرون و اینترپرایز مثل Oracle یا SQL Server همراه با خود محصول و با پشتیبانی رسمی ارائه میشن.
- خصوصا وقتی پای خرید لایسنس و استفاده قانونی از محصول به میون بیاد، دانش PostgreSQL لازم میشه.
- 🗿 تجربه شخصی: من حدود ۲۰ ساله به صورت تخصصی در کنار هر فعالیتی که توی حوزه نرمافزار داشتم، در زمینه دیتابیس فعال بودم، از تدریس، مشاوره، طراحی تا نگهداری و بهینهسازی دیتابیسهایی از چند ده گیگابایت تا چندصد ترابایت. خلاصه میتونم بگم زمان و انرژی نگهداری PostgreSQL در فضای غیر ابری (On-premise) نسبتا بیشتر از محصولاتی مثل Oracle یا SQL Server است (هرچقدر هم ساختار و دیتا بزرگتر، زمان و انرژی بیشتری لازمه). ولی از نظر معماری و مفاهیم آکادمیک دیتابیس، وقتی به query planner / optimizer نگاه تخصصی و علمی داشته باشیم، 💎 فوقالعاده است. اما توی محیط واقعی، خصوصا وقتی دیتابیس بزرگه، تعداد کاربر و کوئریهای همزمان زیاده، و یا شرایط بدی پیش بیاد، عموما ایرادیابی و مدیریت Oracle یا SQL Server به مراتب سریعتر و بیدردسرتر است. ولی اگر روزی پای خرید لایسنس به میون بیاد، بعیده حتی سازمانهای بزرگ هم قادر به حفظ محصولاتی باشن که الان بدون یک ریال هزینه لایسنس استفاده میکنن. اگر مهاجرت کرده باشید، یا پلنش رو داشته باشید، موضوع لایسنس خیلی ملموستره.
من PostgreSQL رو خیلی بعدتر از بقیه پلتفرمها شروع کردم (از نسخه ۹.۱، حدودا سال ۲۰۱۲) و تمام این سالها شاهد نوآوریهایی بودم که بخش زیادیش کاربرد تخصصی داشت و مثلا ابزارهای بکاپگیریش تا همین نسخه ۱۷ حتی با SQL Server 2005 شاید قابل مقایسه نباشه! (البته به جز Object Restore که دلیلش هم تفاوت مکانیزمشونه) هر پروژهای، هر تیمی، هر سازمانی، هر محصولی، هر بودجهای و دهها از این «هر» ها باعث میشن تا انتخاب بهینه تغییر کنه. نمیشه به همه گفت MySQL یا PostgreSQL یا ... استفاده کنید. بلکه بخشی از مهندسی، انتخاب ابزار مناسب و متناسب است. و سعی کنیم توی بازیهای بچهگانهی این بهتر است یا اون نیوفتیم. بدون شک، PostgreSQL یکی از بازیگرهای اصلی حوزه دیتابیس است و برای سناریوهای مختلفی میتونه گزینه خیلی خوبی باشه. فقط یادمون باشه، مثلا تنوع ایندکسهاش بیشتر از SQL Server است، یا پیادهسازی HA با مکانیزمهای اوراکلی مثل اکتیو دیتاگارد یا RAC فرق داره، حتی روشهای ذخیرهسازی یا ایراد یابیش، ابزارهای مونیتورینگ و... پس صرف اینکه بخش عمده دستورات SQL توی همشون مشابهه توی تلهی توهم بلد بودن نیوفتیم و تیم و محصول رو به مشکل نندازیم. حتی چون مثل Microsoft یا Oracle ساختار یادگیری آزمونمحور و Certificateی نداره، انتخاب کتاب خوب هم گاها نیاز به تورق و چک کردن چند تا کتاب داره تا بتونین گزینه بهتر رو انتخاب کنید.
منتظر کارتقرمزهای 🟥 بعدی باشید... 😉
خوشحال میشم تجربیات، نظر یا پرسشهاتون رو طرح کنید و گپ بزنیم 💬
👌6