یه ابزار کاربردی برای وقتی که می‌خواید localhost رو موقتاً روی اینترنت در دسترس قرار بدید.

با ngrok می‌تونید پروژه‌تون رو با یه Public URL در اختیار بقیه قرار بدید؛ بدون نیاز به Deploy یا تغییر تنظیمات پروژه.

برای تست Webhook هم می تونه کاربردی باشه.

🔗 https://ngrok.com

@programming_codiing

یه سایت خیلی خفن برای یادگیری Git.

گیت رو به شکل Interactive یاد می‌گیرید و می‌تونید Branch، Merge، Rebase و بقیه دستورات رو با محیط گرافیکی تمرین کنید.
به‌جای اینکه فقط دستورها رو حفظ کنید، نتیجه‌شون رو می‌بینید و می تونه براتون جالب باشه برای یادگیری.

🔗 Link

@programming_codiing

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

@programming_codiing

اگه یه JSON شلوغ دارید و می‌خواید سریع Format / Validate / Minifyش کنید:

🔗 https://jsonformatter.org

برای کارهای سریع خیلی راحت‌تر از اینه که بخواید هر بار یه ابزار نصب کنید.

@programming_codiing

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

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

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

پ.ن : سعی می کنم این پست رو ادامه بدم. "تولید محتوا"

@programming_codiing

قبل از کدنویسی، ساختار پروژه رو بچین.

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

project/
├── app/
│   ├── _components/
│   ├── _constants/
│   ├── _hooks/
│   ├── _lib/
│   ├── _services/
│   ├── _types/
│   ├── _utils/
│   │
│   └── test/
│       ├── _components/
│       │   ├── TestHeader.tsx
│       │   └── TestCard.tsx
│       ├── _constants/
│       │   └── test.constants.ts
│       ├── _hooks/
│       │   └── useTest.ts
│       ├── _lib/
│       │   └── test.lib.ts
│       ├── _services/
│       │   └── test.service.ts
│       ├── _types/
│       │   └── test.types.ts
│       ├── _utils/
│       │   └── test.utils.ts
│       └── page.tsx
│
├── public/
│   ├── fonts/
│   └── images/
│

این فقط یک الگوئه ابتدایی هست و می تونه برای خیلی از پروژه ها اوکی باشه ولی ساختار مناسب هر پروژه به اندازه و نوع پروژه بستگی داره.

و برای اینکه هر بار این پوشه‌ها رو دستی نسازید، از AI بخواید دستور ساختش رو براتون بنویسه:

«برای ساخت این ساختار پروژه، دستور ترمینالی مناسب ویندوز / لینوکس / مک رو بنویس.»

@programming_codiing

ساختار مناسب، خودش جزوی از تمیزی کدِ.

ساختار کامل پروژه‌ی Backend.

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

وقتی پروژه بزرگ می‌شه، پوشه‌هایی مثل controllers و services کم‌کم پر از فایل‌های بی‌ربط می‌شن. راه‌حل‌ اینه هر Feature، یک ماژول مستقل داشته باشه و همه‌ی کدهای مرتبط با خودش رو همون‌جا نگه داره.

backend/
├── src/
│   ├── modules/
│   │
│   ├── shared/
│   │   ├── middlewares/
│   │   ├── errors/
│   │   ├── utils/
│   │   ├── constants/
│   │   └── types/
│   │
│   ├── infrastructure/
│   │   ├── database/
│   │   │   ├── migrations/
│   │   │   └── seeds/
│   │   ├── cache/
│   │   ├── queue/
│   │   ├── storage/
│   │   └── mailer/
│   │
│   ├── config/
│   │
│   ├── routes.ts
│   ├── app.ts
│   └── server.ts
│
├── tests/
│   ├── integration/
│   └── e2e/
│
├── scripts/

modules/
هر Feature، ماژول خودش رو داره و کدهای مربوط به اون Feature کنار هم قرار می‌گیرن.

shared/
کدهایی که بین چند ماژول استفاده می‌شن؛ مثل Middlewareها، Errorها، Utilityها و Typeهای مشترک.

infrastructure/
مسئول ارتباط با زیرساخت‌ها و سرویس‌های بیرونی؛ مثل Database، Cache، Queue، Storage و Mailer.

config/
تنظیمات پروژه و متغیرهای "env" در یک نقطه مدیریت می‌شن.

tests/
تست‌های Integration و E2E از کد اصلی پروژه جدا نگه داشته می‌شن.


در نهایت، هدف این ساختار ساده‌ست:
ماژول بیشتر، نه شلوغی بیشتر.

@programming_codiing

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

6000 هم تقریبا کامیت ثبت شده براش.

@programming_codiing

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

چیزی که پروژه رو سنگین می‌کنه، استفاده‌ی نادرست و غیربهینه از اون‌هاست.

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

پس قرار نیست برای سبک‌تر شدن پروژه، از امکانات و ظاهر خوبش بگذریم و راه درستش، بهینه‌سازی درستشه.

البته که بعضی کتابخونه ها دیگه با توجه به کاری می کنن طبیعیه سنگین کنن پروژه رو.

@programming_codiing

اگه رزومه‌ت پر از ایناست:

React Next.js Node.js MongoDB JS TS ...

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

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

@programming_codiing

یکی از مثال‌هایی که می‌تونم بزنم، همین چنل یوتیوبه.

اگه ویدیوهاش رو ببینید، واقعاً مفید و باکیفیته؛ ولی فعلاً کاری به ویدیوها نداریم، خودِ چنل رو بررسی کنیم.

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

لازم نیست همیشه عجیب‌ترین یا خفن‌ترین باشیم، مهم اینه که هویت خودمون رو داشته باشیم، هویت خودمون هویتی هست که دوست داشتنیه و ایشون هم اگه ببینید چیزی که هست بهش باور داره. (باور داشتن فقط یکی از دلایل هست). کسایی که موفقن رو راز موفقیتشون رو مثل بقیه نگردید شما خودشون رو برسی کنید رفتارشون و.. .

@programming_codiing

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

و براتون فقط یه ارتقا هست، نه یه زبان جدید اما نه ارتقای عادی.

@programming_codiing

اینجور سایت های باحال :
فقط ویدیو و عکس هست ولی با منطق درست برای نمایش، چیز سختی هم نیست.
البته سه بعدی هم می شه همچین چیزایی با Three.js زد.

خلاقیت؛

@programming_codiing

پیشرفت، همیشه قابل دیدن نیست..

@programming_codiing

«هر احمقی می‌تواند کدی بنویسد که کامپیوتر بفهمد؛ برنامه‌نویس خوب کدی می‌نویسد که انسان‌ها هم بفهمند.»

— مارتین فاولر

@programming_codiing

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

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

نفر اول، هر روز چندتا تابع رو معرفی می‌کنه و مثال می‌زنه.

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

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

اطلاعات به‌تنهایی همیشه کافی نیستن؛ نحوه‌ی ارائه، تجربه‌ی پشت محتوا و مشکلی که حل می‌کنه هم اهمیت دارن.

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

پس دوباره می‌رسیم به همون اصل:
متفاوت بودن، مزیت رقابتی توئه.

قبل از انتشار هر محتوا از خودتون بپرسید:

مخاطب بعد از دیدن این محتوا چه چیزی به دست میاره که قبل از دیدنش نداشت؟

اگه جواب مشخصی دارید، احتمالاً مسیر درستی رو انتخاب کردید.

این موضوع توی برنامه‌نویسی هم صدق می‌کنه.

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

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

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

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

@programming_codiing

بعضی موقع یه چیزی که اسمش رو کمال‌گرایی می‌ذاریم، در واقع ترس از قضاوت شدنه.

پروژه رو تموم کردی، اما منتشرش نمی‌کنی.

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

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

گاهی چیزی که برای پیشرفت کم داریم، دانش بیشتر نیست، جرئت ارائه دادن چیزیه که تا امروز یاد گرفتیم.

دلشو داشته باش، آخرش هر چی می شه بشه؛

@programming_codiing