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

ماجرا برمی‌گرده به سال ۲۰۱۰، زمانی که Oracle شرکت Sun Microsystems رو خرید و MySQL هم وارد مجموعه Oracle شد. همین اتفاق باعث شد خیلی از توسعه‌دهنده‌ها نسبت به آینده MySQL نگران بشن و بعضی‌ها حتی قبل از اینکه اتفاق خاصی برای پروژه بیفته، شروع به بررسی و مهاجرت به گزینه‌های دیگه کنن.

به گفته استون‌بریکر، همین ترس یکی از نقاط شروع رشد جدی PostgreSQL بود. جالب‌تر اینکه سال‌ها بعد، وضعیت MySQL واقعاً تغییر کرده. در سپتامبر ۲۰۲۵، Oracle تعدادی از نیروهای تیم اصلی MySQL رو تعدیل کرد و این موضوع دوباره بحث آینده MySQL رو داغ کرد.

در طرف مقابل، PostgreSQL طی این سال‌ها رشد خیلی زیادی داشته. این دیتابیس در سال ۲۰۲۳ به محبوب‌ترین دیتابیس بین توسعه‌دهنده‌ها تبدیل شد و شرکت‌هایی مثل Microsoft، Google و Amazon هم سرویس‌های خودشون رو بر پایه سازگاری با PostgreSQL توسعه دادن.

استون‌بریکر درباره وضعیت امروز MySQL حتی از عبارت خیلی تندی استفاده کرده و گفته این پروژه داره به رقیبی تبدیل می‌شه که عملاً در حال محو شدنه.

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

شاید بزرگ‌ترین مزیت PostgreSQL همین استقلال باشه. وقتی یک پروژه به یک شرکت واحد وابسته نباشه، تصمیم‌های تجاری یک شرکت نمی‌تونن به‌تنهایی مسیر آینده اون رو تعیین کنن.

در واقع Oracle احتمالاً هیچ‌وقت قصد نداشت با خرید MySQL به PostgreSQL کمک کنه، ولی نگرانی‌ای که ایجاد کرد باعث شد بخشی از جامعه توسعه‌دهنده‌ها به سمت PostgreSQL برن. پانزده سال بعد، این تصمیم عملاً یکی از بزرگ‌ترین مزیت‌های PostgreSQL رو شکل داده.

#PostgreSQL
#MySQL
#Oracle
#Database
#OpenSource
#SQL
#SoftwareEngineering
#Developers
#Backend
#Technology
#Programming
#DatabaseManagement

صرفاً Prompt نوشتن و کپی کردن خروجی AI ازت Developer نمی‌سازه.

اگر کدی که AI برات نوشته رو نمی‌فهمی، نمی‌تونی Debug اش کنی، نمی‌دونی چرا این Architecture انتخاب شده و وقتی چیزی خراب می‌شه نمی‌فهمی مشکل از کجاست، در واقع بیشتر از اینکه Developer باشی، AI Babysitter هستی.

وایب کدینگ خودش مشکلی نداره. مشکل از جایی شروع می‌شه که فکر کنی استفاده از AI جای فهمیدن Programming رو گرفته.

#VibeCoding
#Programming
#SoftwareEngineering
#AI
#Developers
#Coding

واقعاً چرا هنوز توی خیلی از مصاحبه‌های Programming ازت می‌خوان Code رو از صفر و با دست بنویسی؟

وقتی قراره در دنیای واقعی از AI برای کدنویسی استفاده کنیم، شاید بهتر باشه مصاحبه‌ها هم از این مدل ارزیابی فاصله بگیرن.

به‌جای اینکه ببینیم کسی چقدر سریع می‌تونه چند خط Code رو بدون کمک بنویسه، بهتر نیست درباره Fundamentals سؤال بپرسیم؟ اینکه چرا یک تکنولوژی رو انتخاب می‌کنی، چطور یک مسئله رو تحلیل می‌کنی، چطور Architecture مناسب رو انتخاب می‌کنی، چطور یک Bug رو پیدا می‌کنی و چطور تشخیص می‌دی کدی که AI تولید کرده واقعاً درست و قابل استفاده هست یا نه.

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

شاید وقتشه Technical Interview هم خودش رو با دنیای AI وفق بده.

#AI
#Programming
#Coding
#SoftwareEngineering
#TechnicalInterview
#Developers
#VibeCoding
#ArtificialIntelligence

به نظرم خیلی‌ها دارن بدون اینکه واقعاً بفهمن کدی که تولید می‌کنن چطور کار می‌کنه، همین‌طوری YOLO می‌کنن.

با Vibe Coding بعضی وقت‌ها واقعاً می‌تونی از A برسی به Z.

ولی خیلی وقت‌ها چیزی که تحویل می‌گیری اینه:

A → F + N → Z

وسطش خالیه.

مدل بهت می‌گه:
«انجام شد، از A تا Z کامل شد.»

و تو هم بررسی نمی‌کنی.

یا حتی بدتر؛ از خود مدل می‌خوای که کد خودش رو بررسی کنه.

اینجاست که یه مشکل جدی به وجود میاد.

مدل ممکنه روی اشتباه خودش اصرار کنه، چون به جای اینکه واقعاً صحت کار رو ثابت کنه، دنبال کامل‌کردن همون چیزی می‌ره که فکر می‌کنه باید کامل شده باشه.

برای همین من فکر می‌کنم Vibe Coding قرار نیست جای فهمیدن رو بگیره.

هوش مصنوعی رو استفاده کن.

سریع‌تر کد بزن.

کارهای تکراری رو بده بهش.

ولی از Loop خارج نشو.

کدی که نمی‌فهمی چطور کار می‌کنه، واقعاً هنوز مال تو نیست.



#VibeCoding
#AI
#Programming
#SoftwareEngineering
#Developers
#LLM