سازنده 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

خیلی‌ها از Programming می‌ترسن، ولی اگر بخوام صادق باشم، خود کدنویسی برای من بخش ساده‌ی ماجراست. بخش سخت‌تر، تمام زمانی‌ـه که صرف ساختن Logic توی ذهنت می‌کنی و فکر کردن به تمام حالت‌هایی که ممکنه یک راه‌حل در اون‌ها شکست بخوره.

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

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

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

واقعاً نمی‌دونم اگر Programming و Chess وارد زندگی من نمی‌شدن، امروز چه شکلی فکر می‌کردم یا کجا بودم. ولی مطمئنم هر دو، بیشتر از اینکه فقط یک مهارت یا سرگرمی باشن، روی نحوه فکر کردنم تأثیر گذاشتن.

#Programming
#Coding
#Chess
#ProblemSolving
#CriticalThinking
#Logic
#SoftwareEngineering

شاید یکی از دلایلی که امروز صدها Open Source C2 داریم ولی تعداد خیلی کمی از اون‌ها واقعاً در دنیای واقعی قابل استفاده‌ان، همین باشه.

بعد از یه نقطه مشخص، واقعاً Coding بخش کوچکی از نتیجه نهایی می‌شه. شاید حتی همون ۱۰ درصدی که همه بیشتر می‌بیننش. بخش اصلی ماجرا جاییه که باید خارج از چارچوب معمول فکر کنی، Research خودت رو انجام بدی، فرضیاتت رو به چالش بکشی و یک سناریو رو بارها و بارها تست کنی.

ساختن چیزی که روی کاغذ کار می‌کنه یک مسئله‌ست. ساختن چیزی که در دنیای واقعی قابل اتکا باشه، مسئله کاملاً متفاوتیه.

برای همین فکر می‌کنم تفاوت بین یک پروژه معمولی و یک ابزار واقعاً کاربردی، اغلب نه در تعداد Lines of Code، بلکه در میزان فکر، تحقیق و Testing پشت اون مشخص می‌شه.

در نهایت Coding شاید فقط ۱۰ درصد نتیجه باشه. ۹۰ درصد دیگه مربوط به طرز فکر، Research و تست بی‌پایانه.

#Programming
#Cybersecurity
#RedTeam
#C2
#OpenSource
#OffensiveSecurity
#Pentesting
#SoftwareEngineering
#Research
#ProblemSolving

یک موضوع دلی رو بگم بهتون دوستان.

امروز داشتم با یکی از دوستام صحبت می‌کردم و یاد یه عادت قدیمی افتادم. سال ۲۰۱۸، وقتی تازه شروع کرده بودم Windows Internals رو یاد بگیرم، من و چندتا از دوستام یه عادت نسبتاً ساده برای خودمون ساخته بودیم.

هر روز ۱۰ تا فایل EXE یا DLL از System32 انتخاب می‌کردیم و فقط درباره‌شون می‌خوندیم. نه خبری از Hack خاصی بود، نه Reversing و نه کار عجیب‌وغریبی. اسم فایل، کاربردش، اینکه چرا وجود داره، چه کاری انجام می‌ده و هر چیزی که می‌شد درباره‌ش پیدا کرد.

این کار رو تقریباً ۶۰ روز ادامه دادیم و حجم دانشی که فقط با Google کردن و خوندن به دست آوردیم واقعاً عجیب بود.

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

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

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

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

و البته بله، من خودم چندتا Course هم می‌فروشم؛ ولی حتی با وجود این، هنوز فکر می‌کنم چیزی که بیشتر از هر منبعی نتیجه می‌ده، Time + Consistency + Discipline هست.

#WindowsInternals
#Cybersecurity
#Programming
#Fundamentals
#Learning
#ReverseEngineering
#Infosec
#Security
#SoftwareEngineering
#Discipline

صرفاً 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

براتون 250+ Python One-Liners برای تقویت Problem Solving آوردم.

واقعا One-Linerها فقط ترفندهای عجیب برای کوتاه‌تر کردن کد نیستن.

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

این مجموعه با عنوان 250+ Killer Python One-Liners بیش از ۲۵۰ مثال کوتاه و کاربردی داره؛ از کار با String و List گرفته تا Date، Math، Validation و Random.

📌 موضوعاتش شامل:

• String و List manipulation

• کار با Arrayها
• Date & Time
• Math و Geometry
• Random Generatorها
• Validation برای Email، IP، URL و...
• Recursion
• Bitwise Operations
• Utility Functionهای کوچک

نکته جالب اینه که هدف صرفاً حفظ کردن One-Linerها نیست؛ ایده اصلی اینه که ببینین یک مسئله‌ی نسبتاً ساده رو چطور می‌شه با ابزارهای خود Python به شکل تمیز، کوتاه و Pythonic حل کرد.

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

📚 برای تمرین Python و تقویت Problem Solving می‌تونه مجموعه جالبی باشه.

❤️ Share & Support

#Python
#Programming
#ProblemSolving
#PythonTips
#CyberSecurity
#Coding

یه فکت جالب:

به نظرم نرم‌افزار هیچ‌وقت فقط کدنویسی نبوده.
قرار بوده یه سری کارایی که از توان آدم خارجه رو برامون انجام بده و دست و ذهنمون رو قوی‌تر کنه.

#فکت
#Software
#Programming

یه چیزی که این روزا خیلی از برنامه‌نویسا حسش می‌کنن:

ما کلی وقت گذاشتیم یاد گرفتیم، تمرین کردیم و مهارت ساختیم؛ ولی بازار با سرعت زیادی داره تغییر می‌کنه.

چیزی که دیروز مهم بود، شاید امروز دیگه کافی نباشه.

به نظرم الان مهم‌تر از بلد بودن یه تکنولوژی خاص، توانایی یادگیری و سازگار شدن با تغییره. ⚡️

#Programming
#AI
#Developer

مهندسی معکوس بازی‌ها و برنامه‌های اندرویدی

با این اسکیل می‌تونید سراغ مهندسی معکوس فایل‌های APK برید و بعضی از سازوکارهای داخلی بازی‌ها و برنامه‌های اندرویدی رو بررسی کنید.

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

⚠️ حواستون باشه تغییر و انتشار نسخه هک‌شده برنامه‌ها می‌تونه ناقض قوانین یا حقوق سازنده‌ها باشه. تست امنیتی هم باید با مجوز و در محدوده مشخص انجام بشه؛ باگ‌بانتی قرار نیست بهانه‌ای برای تهدید یا اخاذی از شرکت‌ها باشه.

این ابزار بیشتر می‌تونه برای یادگیری و آزمایش‌های آموزشی مفید باشه؛ برای کار حرفه‌ای امنیت، باید دانش عمیق‌تری از اندروید و روش‌های تحلیل اپلیکیشن داشته باشید.

پ.ن : خودم تست نکردم هنوز و خبر ندارم!

تست کردید خبر بدید.

🔗 گیت‌هاب:

https://github.com/newliver666/apk-reverse

#Ai
#Programming

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

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

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

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

به بیان ساده، مهم‌تر از توانایی AI در تولید کد، توانایی ما در درک، ارزیابی و هدایت اون کدهاست.

#AI
#Programming
#SoftwareEngineering