https://virgool.io/feed/@aliebrahimnezhad Web Developer علاقه مند به یادگیری fa 2026-06-16 00:36:30 https://files.virgool.io/upload/users/4838379/avatar/73r6LK.jpg?height=120&width=120 https://virgool.io/@aliebrahimnezhad https://virgool.io/@aliebrahimnezhad/payment-gateway-ybucszobkhxg یکپارچه سازی درگاه پرداخت یک فرآیند خیلی حساس در توسعه وب هست کوچکترین اشتباه در جریان داده (Data Flow) می تواند باعث خطا ها و باگ های امنیتی یا تراکنش ناموفق شود و یا می تواند باعث شود اطلاعات ناقص یا اشتباه در دیتابیس سیستم ما ذخیره شوددر این پست، فرآیند استاندارد یک تراکنش مالی را از اولین درخواست کاربر (یعنی کلیک رو دکمه پرداخت) تا تایید نهایی و بازگشت به کلاینت را بررسی میکنیم .درگاه پرداخت (Payment gateway)چرخه تراکنش مالی :1. درخواست شروع تراکنش (initiation) :کاربر (سمت کلاینت) : کاربر در سایت یا اپلیکیشن روی دکمه پرداخت کلیک میکندسرور (Server) : سرور اطلاعات اولیه پرداخت (مبلغ و توکن شناسایی (merchant-id) و callback و ... ) رو به درگاه پرداخت ارسال میکنددرگاه پرداخت (Payment Gateway) : درگاه پرداخت اعتبارسنجی انجام می دهد و بعد از تایید یک شناسه یکتا موقت (Authority) به صورت پاسخ به سرور برمی گرداندطبق تصویر این بخش مربوط به فرآیند 1 و 2 و 2.1 هست و منظور از callback ادرسی هست که درگاه پرداخت اطلاعات را بعد از پرداخت یا کنسل کردن توسط کاربر به آن ارسال میکندنکته : در این مرحله شما باید به عنوان یک توسعه دهنده اطلاعات تراکنش را به صورت موقت در دیتابیس خود ذخیره کنید2. ریدایرکت کردن کاربر به درگاه پرداخت (Redirect) :سرور پس از دریافت Authority باید کاربر را به در گاه پرداخت امن بفرستد یا به اصطلاح ریدایرکت کند تا کاربر بتواند پرداخت خود را انجام دهدسرور کاربر را به درگاه پرداخت با آدرس گفته شده در مستندات همراه با Authority ارسال میکند و کاربر را به آن ریدایرکت میکند یعنی به صورت :http://example.com/{Authority}کاربر به درگاه پرداخت امن هدایت می شود و اطلاعات خود را وارد می کند3. بازگشت به سایت (Callback) :بعد از تکمیل پرداخت توسط کاربر (پرداخت موفق ، پرداخت ناموفق ، کنسل شدن) درگاه پرداخت وضعیت را به سایت callback که مشخص کردیم ارسال می کنددرگاه پرداخت یا یک متد GET یک درخواست به آدرس Callback که به درگاه داده شده ارسال میکند که داخل آن وضعیت Status و Authority در قالب Query Parameters ارسال می شود مثلا ادرس : http://localhost:8000/api/callback?Status=OK&Authority=authorityدر مسیر زیر در سرور خودمون اطلاعات را پردازش میکنیم4. تایید تراکنش (verify) :صرفا دریافت وضعیت در callback برای تایید پرداخت کافی نیست چون این درخواست قابل دستکاری هست پس سرور باید یک درخواست به درگاه پرداخت بزندسرور یک درخواست تایید با متد Verify به درگاه پرداخت ارسال می کند و همراه با آن مبلغ و Authority را میفرستددرگاه پرداخت اطلاعات تراکنش را بررسی میکند و برای سرور می فرستدسرور تمام اطلاعات بررسی می کند و اطلاعات را در دیتابیس ذخیره میکند (در اینجا بر اساس وضعیت موارد ذخیره می شود )5. هدایت کاربر به سمت کلاینت (Client-side Redirect) :سرور بر اساس وضعیت پرداخت شما را به صفحه مربوطه در کلاینت هدایت می کند و اینجا دیگه کاربر در درگاه پرداخت نیست و به پنل خودش در سایت یا اپلیکیشن (صفحه مربوطه) هدایت می شوداین فرآیند اصلی کار در ارتباط با درگاه های پرداخت هست ساختار اصلی همه درگاه های پرداخت به این صورت هست فقط در جزئیات آنها تفاوت هایی وجود داردنکته :اگه به عنوان یک توسعه دهنده می خواهید از درگاه پرداخت در اپ خودتون استفاده کنید حتما سعی کنید مستندات مربوط به درگاه مربوطه را با دقت بخوانید و به جزئیات کامل دقت کنید چون اشتباه در محاسبات میتواند ضرر های بزرگی را به شما بزند این بخش قلب تپنده سایت شما محسوب می شود و خیلی حساس هست.اگر به یادگیری گیت هم علاقمند هستید این دو مقاله من تفاوت merge و rebase و چطور با Git Squash تاریخچه پروژه راتمیز نگه داریم هم در این مورد شاید بتواند کمکی به شما بکند Ali Ebrahimnezhad Ali Ebrahimnezhad Wed, 06 May 2026 11:11:06 +0330 https://virgool.io/@aliebrahimnezhad/%D8%AA%D9%81%D8%A7%D9%88%D8%AA-merge-%D9%88-rebase-%DA%86%DB%8C%D8%B3%D8%AA-rnhjoyrqwvfa برای اضافه کردن یک feature جدید یا رفع یک باگ (bug) ، برنامه نویس ها معمولا از برنچ (branch) استفاده میکنند و باگ یا feature رو در این برنچ فرعی انجام میدهند تا برنچ اصلی تا زمانی که اصلاح و تست ها انجام نشده تغییر نکند و بعد از تموم شدن کار باید برنچ فرعی رو داخل برنچ اصلی( main یا master )اضافه کنیمبرای این کار دو روش وجود دارد : merge و rebasegit rebase vs mergeچگونه دو برنچ را merge کنیم :با استفاده از merge میتونیم دو تا برنچ را با هم ادغام کنیم یعنی تمام تغییرات داخل برنچ فرعی را داخل برنچ اصلی اضافه میکنیم.برای این کار به برنچ اصلی میرویم و دستور زیر را وارد میکنیم :git checkout main #برای کسانی که برنچ اصلی با نام master هست از این به جای main استفاده میکنیم git merge chapter3 #براساس نام برنچ فرعی chapter3 تغییر میکند زمانی که برنچ اصلی ما همزمان با برنچ فرعی تغییر نکرده است (یعنی تمام تغییرات ما در برنچ فرعی اتفاق افتاده) این قضیه مشکلی ایجاد نمیکنه ولی برای زمانی که برنچ اصلی هم همزمان با برنچ فرعی تغییر کرده برای ادغام این دو برنچ یک مشکل وجود دارهعکس مربوط به لاگ merge کردنمشکل merge کردن برنچ :مشکل اصلی اینه که هنگامی که میخواهیم برنچ رو merge کنیم گیت نمیتونه کامیت به کامیت رو دقیق در جای خودش قرار بده و نحوه قرار گیری کامیت های قبلی رو تغییر بده پس میاد یک کامیت جدید درست میکنه برای اضافه کردن برنچ فرعی به برنچ اصلی و یک ساختار درختی درست میکند یعنی از یه قسمت لاگ های پروژه دو شاخه میشه و با برنچ به هم متصل میشوند (همانند تصویر بالا که به دو شاخه تبدیل شده و در نهایت با هم merge شدن) این برای مدیر های پروژه اصلا خوب نیست چون ساختار تمیز پروژه خراب میشود (مثلا داخل یک پروژه بزرگ اگر بخواهیم چند برنامه نویس همزمان جداگانه هر کدام یک فیچر برای برنامه بنویسند و یک برنچ برای آن درست کنند یک ساختار درختی خیلی کثیف درست میشود)برای اینکه این مشکل حل شود از rebase استفاده میکنیمچگونه دو برنچ را rebase کنیم :با استفاده از rebase میتوانیم مشکل merge کردن را حل کنیم با rebase تمام تغییرات را دوباره در بالای آخرین کامیت (commit) برنچ اصلی اضافه میکنیمبرای این کار به برنچ فرعی میرویم و دستور زیر را وارد میکنیم :git checkout chapter3 // براساس نام برنچ فرعی chapter3 تغییر میکند git merge main //برای کسانی که برنچ اصلی با نام master هست از این به جای main استفاده میکنیماین کار با عث میشود به جای اضافه کردن کامیت جدید و ساختار درختی تمام کامیت ها برنچ فرعی رو به داخل برنچ اصلی بریزد و دیگر کامیت اضافه تری نمیزارد و هم ساختار نا مرتب و درختی ایجاد نمی کندتصویر مربوط به لاگ های rebase قسمت سبز از chapter3 بوده و قسمت قرمز از masterدر اینجا کامیت c31d33b51406 بعد از کامیت abd4840f34d33 نوشته شده است ولی بعد از rebase کردن کامل تاریخچه مربوط به برنچ فرعی در بالا کامیت های برنچ اصلی قرار میگیرد و بازنویسی میشودنکته : با rebase تمام کامیت های شما دوباره از اول باز نویسی میشود که میتواند برای شما مشکلاتی ایجاد کند چون تاریخ کامیت ها را به طور کامل تغییر پیدا میکند و دوباره نویسی می شود به این نکته هم باید توجه داشت.تفاوت rebase و merge :تاریخچه (History) :در merge تاریخچه پروژه به صورت درختی و غیر خطی هست ولی در rebase تاریخچه مرتب و خطی می ماندتغییرات :در merge تغییرات پروژه دست نخورده باقی میماند و یک کامیت برای اتصال دو برنچ به هم استفاده میکنیم و غیر خطی هست ولی در rebase تغییرات پروژه از قسمت برنچ فرعی به طور کامل بازنویسی میشودترتیب کامیت ها :در merge ترتیب کامیت ها دست نخورده باقی میماند و با همان ترتیب ایجاد شده باقی میماند ولی در rebase ترتیب کامیت ها ممکن تغییر کند و کامیت های برنچ فرعی کامل در بالا آخرین کامیت برنچ اصلی بازنویسی میشود .نکته مهم : برای merge کردن باید داخل برنچ اصلی نام برنچ فرعی رو بنویسید ولی برای rebase کردن باید در برنچ فرعی نام برنچ اصلی را بنویسید (این نکته را خیلی از مواقع اشتباه میشود) این مقاله هم برای تمیز کردن تاریخچه گیت با Git squash هست اگر دوست داشتین میتونید این مقاله را هم مطالعه کنیدامیدوارم این مقاله ها بتواند در یادگیری مفاهیم گیت کمک شما کند. Ali Ebrahimnezhad Ali Ebrahimnezhad Thu, 23 Apr 2026 07:10:30 +0330 https://virgool.io/@aliebrahimnezhad/%DA%86%D8%B7%D9%88%D8%B1-%D8%A8%D8%A7-git-squash-%D8%AA%D8%A7%D8%B1%DB%8C%D8%AE%DA%86%D9%87-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D8%B1%D8%A7%D8%AA%D9%85%DB%8C%D8%B2-%D9%86%DA%AF%D9%87-%D8%AF%D8%A7%D8%B1%DB%8C%D9%85-k2mx2qx2osjd سلام به همگی !احتمالاً موقع کار روی یک پروژه تیمی یا وقتی می‌خواستید برای یک پروژه Open-source یک Pull Request یا Merge Request باز کنید، به اصطلاح Squash برخورد کرده‌اید.​ماجرا از این قرار است که گاهی برای اعمال یک تغییر ساده در پروژه چندین کامیت مختلف ثبت می‌کنیم (که هر کدام تغییرات خیلی کوچکی دارند) این موضوع اصلاً برای مدیران پروژه خوب نیست چون بررسی کدها و دیباگ کردن را سخت می‌کنه و تاریخچه (History) پروژه را برای یک تغییر کوچک، بیش از حد طولانی و شلوغ می‌کنه.گیت برای این مشکل یک راه‌حل ساده داره: Squash.​Squashing در واقع به معنی فشرده‌سازی چندین کامیت و تبدیل آن‌ها به یک کامیت واحد است. این کار باعث می‌شود تاریخچه گیت شما همیشه تمیز و مرتب باقی بمونه.​روش کار:به عنوان مثال، برای Squashing سه کامیت آخر از HEAD می‌توانید از دستور Interactive Rebase استفاده کنید:git rebase -i HEAD~3با اجرای این دستور، یک ویرایشگر باز می‌شود که لیست کامیت‌ها را با برچسب pick نشان می‌دهد. کافیست اولین کامیت را روی حالت pick باقی بگذارید و بقیه را به squash (یا به اختصار s) تغییر دهید. در نهایت، هر سه کامیت با هم ادغام شده و تبدیل به یک کامیت واحد می‌شوند.​اسکرین‌شات‌هایی از لاگِ گیت (قبل و بعد از Squashing) و نحوه squash کردنتغییر pick ها به squashتصویر سمت چپ قبل از Squashing و تصویر سمت راست بعد از Squashing هستنکات مهم:استفاده از Squash بسیار کاربردی است، اما چون باعث بازنویسی تاریخچه (Rewriting History) می‌شود نباید در استفاده از آن زیاده‌روی کنید به‌خصوص اگر آن تغییرات را قبلاً Push کرده‌اید و با هم‌تیمی‌هایتان به اشتراک گذاشته‌اید.Squashing روی شاخه‌های مشترک می‌تواند باعث ایجاد Conflict یا به هم ریختن تاریخچه برای دیگران شود. پس بهتره فقط روی کامیت‌های خودتان (قبل از انتشار نهایی) این کار را انجام دهید.امیدوارم این مطلب برایتان مفید بوده باشد. اگر سوالی داشتید یا پیشنهادی برای کامل‌تر شدن این بحث دارید خوشحال میشم بهم بگین . Ali Ebrahimnezhad Ali Ebrahimnezhad Tue, 21 Apr 2026 12:32:29 +0330 https://virgool.io/@aliebrahimnezhad/resume-building-to-interview-and-networking-cpwgfop1rfbc پیدا کردن شغل مناسب صرفاً به معنای داشتن مهارت فنی نیست. بعد از ماه‌ها یادگیری و تمرین چالش اصلی تازه شروع می‌شود: پیدا کردن محیطی که با ارزش‌های شما، یک محیط کاری خوب می‌تواند سکوی پرتاب شما باشد و یک محیط نامناسب، شما را میتواند از آینده حرفه‌ای‌تان دور کند.​۱. ساختن رزومه​رزومه اولین نقطه تماس شما با شرکت است. با رزومه میتوانی مهارت های خودت رو به دیگران نشون بدی . ساختار یک رزومه حرفه ای در ادامه نشون داده میشه:​ساختار هوشمندانه: اطلاعات تماس، خلاصه‌ای از تجربیات، مهارت‌های کلیدی و تحصیلات را در همان ابتدا بیاورید.​دستاوردها را کمی کنید: به جای اینکه بگویید روی پرفورمنس سایت کار کردم ، بنویسید سرعت بارگذاری صفحات را تا ۴۰٪ بهبود دادم. اعداد بسیار تاثیرگذارتر از کلمات هستند.​رزومه سفارشی: برای هر موقعیت شغلی، رزومه را بازنویسی کنید. از کلمات کلیدی و ترندهای همان حوزه استفاده کنید، اما در استفاده از آن‌ها زیاده‌روی نکنید.​نامه‌ همراه (Cover Letter):​نوشتن Cover Letter اختیاری است، اما نشان‌دهنده اشتیاق شماست. اگر رزومه‌تان تمام ابعاد شخصیتی شما را پوشش نمی‌دهد یا پروژه‌ای دقیقا مرتبط با آن شرکت انجام داده‌اید، حتما یک نامه کوتاه و جذاب پیوست کنید.​۲. قبل از مصاحبه:​بهترین مصاحبه، یک مکالمه دوطرفه است. برای اینکه دست پر بروید:​تحقیق درباره شرکت: ماموریت، اهداف و فرهنگ شرکت را از طریق سایت و لینکدین بررسی کنید. حتی سوابق مدیر فنی یا مصاحبه‌کننده را چک کنید.​تحلیل نقش شغلی: از خودتان بپرسید چرا این شغل؟ و چرا این شرکت؟ پاسخ شفاف به این سوال مصاحبه‌کننده را متقاعد می‌کند که شما با انگیزه هستید.​آمادگی فنی: برای تسک‌های احتمالی، روزانه در پلتفرم‌هایی مثل LeetCode، HackerRank, CodeSignal یا Quera تمرین کنید.​تمرکز بر الگوریتم و Edge Caseها: صرفاً نوشتن کد مهم نیست؛ مصاحبه‌کننده می‌خواهد ببیند آیا مواردی مثل قطع اتصال دیتابیس یا مقادیر Null را هندل کرده‌اید یا خیر.​طراحی سیستم (System Design): مفاهیمی مثل Scalability، سرویس‌ نوتیفیکیشن ،URL shortener ،search engine و social media feed را مرور کنید.​۳. مهارت‌های نرم​مهارت فنی شما را به مصاحبه می‌رساند اما مهارت‌های نرم هستند که باعث می‌شوند آن شغل را به‌دست آورید.​تکنیک STAR برای پاسخ به سوالات رفتاری:​Situation : شرایط را توضیح دهید.​Task : مسئولیت شما چه بود؟​Action : دقیقا چه کاری انجام دادید؟​Result : خروجی کار چه شد؟​در مصاحبه چه کنیم؟​صداقت در ندانستن: اگر پاسخی را نمی‌دانید، صادقانه بگویید و اشتیاق‌تان را برای یادگیری آن نشان دهید. می‌توانید بگویید: در این مورد خاص تجربه ندارم، اما برای حل فلان مشکل از این روش مشابه استفاده کردم...​زبان بدن و انرژی: در مصاحبه حضوری، تماس چشمی برقرار کنید و سطح انرژی‌تان را با مصاحبه‌کننده هماهنگ کنید. در مصاحبه مجازی، نور و صدا را از قبل تست کنید.​۴. مذاکره و چانه‌زنی کی و کجا؟​شرکت را با هر شرایطی قبول نکنید. چانه‌زنی روی حقوق و مزایا زمانی منطقی است که:​پیشنهاد آن‌ها از نرخ بازار کمتر است.​شما پیشنهادات شغلی دیگری هم دارید.​مهارت شما دقیقاً همان چیزی است که شرکت به آن نیاز حیاتی دارد.​نکته مهم: فقط به پول نگاه نکنید ،فرهنگ شرکت و فرصت رشد گاهی از چند میلیون حقوق بیشتر، ارزشمندتر است.​۵. بعد از مصاحبه: کار هنوز تمام نشده!​پیام تشکر: حداکثر تا ۲۴ ساعت بعد، یک پیام تشکر بفرستید. اگر در مصاحبه در مورد موضوع خاصی بحث شد بگویید که در موردش تحقیق کردید. این نشان‌دهنده اشتیاق یادگیری و پیگیری شماست.​در صورت رد شدن: شخصی‌سازی نکنید! شاید در آن مقطع زمانی مسیر شما و شرکت همسو نبوده است. بازخورد بخواهید و از آن برای یادگیری و تقویت نقاط ضعفتان استفاده کنید.​۶. ساختن شبکه ارتباطی​موفق‌ترین افراد کسانی نیستند که در هر مصاحبه‌ای شرکت می‌کنند، بلکه کسانی هستند که شبکه ارتباطی (Network) قوی دارند:​مصاحبه‌کننده‌ها را در لینکدین دنبال کنید.​در گروه‌های تخصصی فعال باشید و به سوالات دیگران پاسخ دهید.​در سمینارها و دورهمی‌های فنی شرکت کنید.​سخن پایانی:هر مصاحبه، حتی اگر به استخدام ختم نشود، یک کلاس درس است. از تجربیات خود یاد بگیرید و به ساختن ارتباطات حرفه‌ای ادامه دهید.​شما چه تجربه‌ای از مصاحبه‌های شغلی دارید؟ Ali Ebrahimnezhad Ali Ebrahimnezhad Tue, 21 Apr 2026 12:24:09 +0330