sherif_shawky

وعليكم السلام ورحمة الله وبركاته،

أولًا، اسأل نفسك بصدق: لمن هذا التطبيق؟

كثير من تطبيقات سطح المكتب تُبنى لأننا “نستطيع” بناؤها، لا لأن هناك شخصًا مستعدًا للدفع مقابلها. حاول أن تجيب عن هذه الأسئلة:

من المستخدم الحقيقي؟

ما المشكلة التي يحلّها التطبيق؟

هل هذه المشكلة مؤلمة بما يكفي ليدفع المستخدم مالًا لحلّها؟

هل المستخدم أصلًا معتاد على الدفع مقابل برامج سطح المكتب أم يفضل الويب؟

إن لم تجد إجابة واضحة، فهذه أول نقطة تحتاج إصلاحها.

ثانيًا، طريقة البيع نفسها

كثير من المطورين يتوقعون أن “يرفعوا التطبيق” وسيأتي المشترون وحدهم، وهذا نادر الحدوث.

تطبيقات سطح المكتب تُباع عادة بإحدى الطرق التالية:

بيع مباشر لشركات أو محلات أو عيادات (B2B)

اشتراك شهري بدل شراء مرة واحدة

نسخة مجانية محدودة + نسخة مدفوعة (Freemium)

بيع تراخيص (License) مع دعم فني

إن كنت تحاول بيع التطبيق للأفراد بدون اسم معروف أو مشكلة واضحة، فالأمر سيكون صعبًا.

ثالثًا، الثقة عامل أساسي

المستخدم اليوم يخاف من:

الفيروسات

سرقة البيانات

البرامج المقرصنة

لذلك تحتاج إلى:

موقع رسمي بسيط يشرح التطبيق

فيديو يوضح الاستخدام

سياسة خصوصية واضحة

توقيع رقمي للتطبيق إن أمكن

وسيلة تواصل حقيقية (إيميل، واتساب، إلخ)

بدون هذه الأشياء، حتى لو كان التطبيق ممتازًا، لن يشتريه أحد.

رابعًا، ربما نوع التطبيق نفسه هو المشكلة

تطبيقات سطح المكتب أصبحت أصعب بيعًا من:

تطبيقات الويب

تطبيقات SaaS

الإضافات (Plugins)

الأدوات المتخصصة جدًا (Niche Tools)

أحيانًا الحل ليس “كيف أبيع التطبيق”، بل:

هل أحوّله إلى Web App؟

هل أقدّمه كخدمة شهرية؟

هل أبيعه لشريحة صغيرة جدًا ولكن بسعر أعلى؟

خامسًا، جرّب البيع المباشر بدل الانتظار

لا تنتظر أن يأتيك العميل.

اذهب أنت إليه:

تواصل مع محلات، مكاتب، مدارس، عيادات

اعرض نسخة تجريبية

اطلب ملاحظاتهم

عدّل التطبيق بناءً على احتياجهم

ثم اعرض سعرًا مناسبًا لهم

بيع نسخة واحدة بهذه الطريقة قد يكون أسهل من بيع 100 نسخة أونلاين.

سادسًا، إن كان هدفك الدخل لا البيع

أحيانًا التطبيق لا يُباع، لكن:

يُستخدم كمعرض أعمال قوي

يفتح لك باب عمل حر

يجلب لك وظيفة

يجعلك تبني نسخة ثانية أفضل موجهة للسوق

وهذا ليس فشلًا، بل مرحلة طبيعية.

هذا سؤال واقعي جدًا، والمشكلة شائعة أكثر مما تتخيل. سأجاوبك بشكل عملي وبصراحة، بدون تنظير.

أولًا: لماذا غالبًا لا يُباع تطبيق سطح المكتب؟

قبل الحل لازم نفهم السبب، لأن الحل يختلف حسب السبب الحقيقي:

1. السوق تغيّر
2. معظم الناس والشركات تفضّل:
3. تطبيق ويب
4. أو SaaS
5. أو تطبيق موبايل
6. لأن:
7. لا يحتاج تثبيت
8. يعمل من أي جهاز
9. أسهل في التحديث والدعم
10. المشكلة ليست في التطبيق… بل في “من يحتاجه”
11. كثير تطبيقات سطح المكتب:
12. تحل مشكلة غير مؤلمة
13. أو مشكلة موجودة لكن المستخدم متعايش معها
14. أو جمهورها صغير جدًا
15. طريقة البيع خاطئة
16. حتى لو التطبيق ممتاز:
17. لا يوجد تسويق
18. لا يوجد توضيح للقيمة
19. لا يوجد Target واضح
20. الناس لا تشتري “برنامج”، تشتري “حل مشكلة”.

ثانيًا: حلول عملية (اختر حسب وضعك)

أعطيك حلولًا مرتبة من الأسرع إلى الأعمق:

الحل 1: حوّله من “منتج عام” إلى “حل لفئة محددة”

بدل:

برنامج إدارة ملفات

قل:

• برنامج إدارة ملفات لمكاتب المحاماة
• برنامج فواتير لورش الصيانة
• برنامج أرشفة لعيادات صغيرة
• التخصص يبيع أكثر من العمومية ×10.

اسأل نفسك:

من الشخص الذي سيتألم لو لم يستخدم برنامجي؟

الحل 2: بعْه كخدمة وليس كبرنامج

بدل:

ادفع مرة وخذ البرنامج

جرّب:

• اشتراك شهري بسيط
• أو دعم + تحديثات مدفوعة
• أو تخصيص حسب الطلب

كثير ناس لا تمانع الدفع مقابل:

• دعم
• حل مشاكل
• تعديلات خاصة

الحل 3: أضف طبقة بسيطة “أونلاين”

حتى لو بقي Desktop:

مثلاً:

• مزامنة بيانات
• نسخ احتياطي سحابي
• ترخيص أونلاين
• تحديثات تلقائية
• هذا يرفع الثقة ويُسهّل البيع.

الحل 4: لا تبيعه… اعرضه مجانًا واجذب عملاء

حل ذكي جدًا:

اعرض التطبيق:

Free / Open Source / Free Trial

ثم:

• تبيع تخصيص
• تبيع نسخة خاصة لشركات
• تبيع تدريب
• تبيع دعم

كثير مطورين يربحون من “الخدمة حول البرنامج” وليس من البرنامج نفسه.

الحل 5: إن كان لا يصلح للبيع → استعمله كأداة تسويق لك

وهذا مهم جدًا:

استعمله كـ:

• Portfolio قوي
• دليل خبرة
• سبب لجلب عملاء
• كثير عملاء يدفعون لك آلاف لأنهم رأوا أنك بنيت شيئًا حقيقيًا.

ثالثًا: أسئلة حاسمة لازم تجاوبها الآن

جاوب بصراحة:

• من المستخدم الحقيقي؟
• ما المشكلة المؤلمة التي يحلها؟
• هل هو مستعد يدفع الآن؟
• كم سيدفع؟
• كيف سيعرف بوجود التطبيق؟

لو لا تستطيع الإجابة بوضوح اذا المشكلة ليست تقنية.

رابعًا: متى تترك التطبيق بدون ندم؟

اتركه إذا:

• لا يحل مشكلة حقيقية
• لا يوجد جمهور واضح
• التسويق أصعب من بناءه
• أو السوق انتقل بالكامل للويب

وصدقني: ترك منتج غير قابل للبيع ليس فشلًا، بل توفير وقت.

سأشرح لك الفكرة أولًا، ثم الطرق العملية.

الفكرة الأساسية

لا يمكنك تقنيًا “منع المتصفح تمامًا” من الوصول للـ API،

لأن أي طلب API هو في النهاية طلب HTTP ويمكن تنفيذه من المتصفح أو أي أداة أخرى.

لكن ما يمكنك فعله هو:

جعل الـ API لا يستجيب إلا لطلبات صحيحة ومصرّح بها

وأي محاولة فتح الرابط مباشرة في المتصفح تكون عديمة الفائدة.

1. التحقق من الهوية (Authentication)

أهم خطوة.

استخدم:

• JWT
• Session + Cookies
• API Keys (لخدمات داخلية فقط)

الفكرة:

أي endpoint حساس:

GET /api/profile

لا يُرجع شيئًا إلا إذا أُرسل معه Token صالح.

مثال:

Authorization: Bearer <JWT_TOKEN>

بدون التوكن:

• يرجع 401 Unauthorized
• حتى لو فتحه المستخدم من المتصفح

2. تحديد من يُسمح له بالوصول (Authorization)

ليس كل مستخدم له نفس الصلاحيات.

مثال:

• مستخدم عادي
• طبيب
• Admin

تتحقق داخل السيرفر:

if (user.role !== 'admin') {
  return res.status(403).json({ error: 'Forbidden' })
}

3. تقييد CORS (مهم جدًا)

CORS لا يمنع الهجمات، لكنه يمنع الاستخدام غير الشرعي من المتصفحات.

في Express:

app.use(cors({
  origin: 'https://your-frontend.com',
  credentials: true
}))

هذا يسمح فقط لواجهة موقعك بالوصول للـ API من المتصفح.

4. منع عرض البيانات عند الطلب المباشر

لا تُرجع HTML أبدًا.

الـ API يجب أن يُرجع:

• JSON فقط
• Status Codes واضحة

مثال:

res.json({ data })

وعند فتح الرابط مباشرة:

سيظهر JSON بلا معنى للمستخدم العادي.

5. استخدام Middleware للحماية

مثال:

function authMiddleware(req, res, next) {
  const token = req.headers.authorization
  if (!token) return res.status(401).json({ error: 'Unauthorized' })
  next()
}

app.get('/api/profile', authMiddleware, controller)

6. Rate Limiting

لمنع:

• التجريب العشوائي
• Brute Force
• Scraping

import rateLimit from 'express-rate-limit'

app.use('/api', rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100
}))

7. حماية متقدمة (اختياري)

• HTTPS فقط
• CSRF Token (إن كنت تستخدم Cookies)
• Validation لكل Input
• عدم كشف رسائل الخطأ التفصيلية

الحقيقة المهمة

لا تحاول منع:

http://example.com/api/users

من الفتح في المتصفح

بل اجعل:

• فتحه بلا توكن = لا قيمة له
• فتحه بدون صلاحية = مرفوض
• أي طلب غير شرعي = مرفوض

وهكذا يصبح الـ API:

مفتوح شكليًا، مغلق فعليًا.

عفوا لا شكر على واجب :)

وعليكم السلام ورحمة الله وبركاته

حاضر، سأعطيك خطّة واضحة + حل مشكلة عدم الرصانة في كتابة الكود بشكل مفصل وبطريقة عملية يمكنك تطبيقها فورًا.

أولًا نحل مشكلة عدم الرصانة في الكود، وبعدها نضع خطة تعلم مناسبة لك.

أولا: كيف تحل مشكلة “عدم الرصانة” في الشغل والكود؟

هذه المشكلة يعاني منها كل مبتدئ، وحلّها يكون بخمس خطوات عملية:

1) اكتب كودًا بسيطًا قبل أن تكتب كودًا جميلًا

المبتدئ يحاول يقلّد الكود الاحترافي مباشرة، فيضيع.

الطريقة الصحيحة:

• اكتب الحل بطريقة بسيطة
• تأكّد أنه يعمل
• بعدها حسّن الشكل والتنظيم
• ثم حسّن الأداء إذا احتجت

هذه أفضل طريقة لتطوير نفسك تدريجيًا.

2) تعلّم معايير كتابة الكود (Coding Style)

لا يمكنك كتابة كود رصين دون اتباع قواعد واضحة مثل:

• ترتيب الأكواد
• تسمية المتغيرات بشكل مفهوم
• تجنب تكرار الكود
• تقسيم المشروع لملفات منظمة
• التعليق فقط عند الضرورة

يوجد شيء اسمه Clean Code، ابدأ بالبحث عن مبادئه.

3) اقرأ الكود أكثر مما تكتب

أهم خطوة على الإطلاق.

شوف مشاريع ناس محترفين على GitHub:

• كيف يرتبون الملفات
• كيف يسمون المتغيرات
• كيف يبنون المكونات (في React مثلاً)
• كيف يكتبون CSS بدون فوضى

مع الوقت، دماغك سيبدأ يتعلّم “الشكل الصحيح للكود”.

4) اعمل على مشاريع حقيقية مهما كانت صغيرة

التطبيق العملي هو اللي يصنع الرصانة.

مثال:

لو عملت 10 مشاريع بسيطة، ستصل إلى مستوى أفضل بكثير من الذي شاهد 100 درس ولم يطبّق شيئًا.

ابدأ بمشاريع واقعية جدًا:

• صفحة هبوط
• موقع شخصي
• مدونة بسيطة
• لوحة تحكم Dashboard
• موقع متجر بسيط

كل مشروع يزيد رصانتك 20%.

5) لا تتعلم وحدك – اطلب مراجعة كودك (Code Review)

ابحث عن شخص محترف أكثر منك يراجع الكود، أو اطلب من مجتمع برمجي أن:

• يقيم الكود
• يقترح تحسينات
• ينبهك للأخطاء
• يقارن كودك بالمعايير الصحيحة

هذا يرفع مستواك بسرعة كبيرة.

ثانيًا: الخطة التي وعدتك بها

حسب كلامك أنت:

• عندك أساس HTML/CSS/JS
• تعرف WordPress
• تفكر في MERN
• طالب جامعي ووقتك محدود

إليك خطة واضحة لمدة 3 أشهر، بدون تشتت.

خطة 3 أشهر لتصبح مطوّر ويب “رصين”

الشهر الأول: تثبيت أساس الواجهة الأمامية

الهدف: الاحتراف في الأساسيات.

أسبوع 1

HTML احترافي:

• semantic tags
• forms
• structure

أسبوع 2

CSS بعمق:

• flexbox
• grid
• responsiveness
• animations البسيطة

أسبوع 3

JavaScript أساسيات قوية:

• DOM
• events
• functions
• arrays
• loops

أسبوع 4

JavaScript مستوى أعلى:

• fetch API
• promises
• ES6
• modules

مشروع نهاية الشهر:

بناء موقع Portfolio كامل + صفحة خدمات + صفحة تواصل.

الشهر الثاني: WordPress احترافي (ربح سريع)

أسبوع 1

العمل على القوالب Child Themes

الفرق بين page – post – custom post type

أسبوع 2

تحسين السرعة

(الـ caching – الصور – minify)

أسبوع 3

تحسين الأمان

(حماية لوحة التحكم – صلاحيات – plugins مهمة)

أسبوع 4

SEO الأساسي للمواقع

مشروع نهاية الشهر:

إنشاء موقع حقيقي كامل (كما لو كان لعميل).

الشهر الثالث: دخول MERN بدون ضغط

أسبوع 1

أساسيات React

(useState – props – components)

أسبوع 2

React مرحلة متقدمة

(useEffect – routing – API)

أسبوع 3

NodeJS أساسيات

(express – routes – JSON)

أسبوع 4

MongoDB

CRUD عمليات أساسية

مشروع نهاية الشهر:

بناء API بسيطة + واجهة React تستهلك البيانات.

عند دخول أي موقع إلكتروني، هناك عدة عناصر قد تجذب الانتباه فورًا. بالنسبة لكثير من المستخدمين، العناصر المرئية مثل الصور عالية الجودة أو الفيديوهات تكون الأكثر تأثيرًا في تكوين الانطباع الأول، لأنها توصل الفكرة بسرعة وبجاذبية أكبر من النص وحده. كذلك فإن تنسيق الصفحات وسهولة التنقل يساهمان في بقاء الزائر لفترة أطول.

ومن الجانب البرمجي، فإن الانطباع الأول يتأثر أيضًا بعوامل تقنية مثل:

• سرعة تحميل الصفحة (Page Load Time):
• تُقاس غالبًا عبر تحسين الـ Caching, الـ Minification للملفات، وضغط الصور (Image Compression).
• تحسين الأداء الأمامي (Front-End Performance):
• مثل استخدام Lazy Loading للصور والفيديوهات حتى لا تبطئ الصفحة.
• توافق الموقع مع الأجهزة (Responsive Web Design):
• باستخدام CSS Flexbox / Grid و Media Queries.
• تحسين تجربة المستخدم (UX):
• عبر تنظيم العناصر باستخدام UI frameworks مثل Tailwind أو Bootstrap.
• تهيئة السيو التقني (Technical SEO):
• مثل استخدام alt attributes للصور، و structured data.

أما بالنسبة لي: أول ما يجذبني عند زيارة موقع هو سرعة التحميل و شكل الواجهة إذا كانت سريعة وواضحة، فهذا يعطيني انطباعًا أن الموقع احترافي، ثم تأتي بعدها جودة المحتوى.

التحذير من وضع ملف .env داخل public_html صحيح تمامًا، لأن هذا المجلد مخصّص للملفات التي يمكن الوصول إليها مباشرة عبر المتصفح.

حتى إن لم تستطع الوصول إليه الآن، فهذا لا يعني أنه آمن دائمًا، فمجرد خطأ بسيط في إعداد السيرفر قد يجعل الملف مكشوفًا.

لماذا لا يجب وضع .env في public_html؟

لأن بعض الخوادم عند سوء الإعداد لا تتعامل مع الملف كملف غير قابل للعرض، فيتم عرض محتواه كنص عادي لو كتب أحدهم:

https://example.com/.env

ووقتها سيظهر:

• معلومات قاعدة البيانات
• مفاتيح API
• مفاتيح البريد
• إعدادات التطبيق

وكلها معلومات كارثية لو تسربت.

لماذا لا تستطيع الوصول إليه الآن؟

لأنك على الأغلب تضع مشروع Laravel بالطريقة الصحيحة:

public_html/
    └── public/     ← هذا فقط يجب أن يكون ظاهرًا للويب
laravel_project_files ← تبقى خارج public_html

وملف .env موجود خارج مجلد public، وبالتالي لا يمكن الوصول له عبر المتصفح.

إذًا كيف “يبحث” الهاكر عنه؟

سهل جداً:

يحاول الدخول إلى:

/.env
/.env.bak
/.env.old
/.env.save
/.env.example

وفي حال كان الملف داخل public_html أو هناك خطأ في إعداد الخادم، سيظهر محتواه مباشرة بدون حماية.

كيف تحمي موقع Laravel كما يجب؟

1. ضع مشروع Laravel خارج public_html

هي أهم خطوة.

الوحيد الذي يجب أن يكون داخل public_html هو مجلد public فقط.

2. أعد كتابة المسارات (Document Root)

اجعل document root يشير إلى:

public_html/public

وليس إلى public_html نفسه.

3. استخدم ملف .htaccess لحجب أي ملفات حساسة

Laravel يضع حماية جاهزة في ملف:

public/.htaccess

لكن تأكد من وجود الحماية التالية:

<Files .env>
    Order allow,deny
    Deny from all
</Files>

4. تحديثات + أذونات الملفات

• لا تجعل صلاحيات الملفات 777 مهما كان السبب.
• استخدم 644 للملفات و755 للمجلدات غالبًا.
• حدّث Laravel والباكدجات أولًا بأول.

5. استخدام HTTPS

التشفير ضروري لحماية الترافيك من الـ MITM.

الخلاصة

إذا كان مشروع Laravel موجودًا بالشكل الصحيح (جميع الملفات خارج public_html وداخلها فقط مجلد public)، فملف .env غير قابل للوصول من المتصفح أصلًا وهذا هو الوضع الآمن.

أما وضع المشروع كاملًا داخل public_html فهو خطأ خطير وقد يؤدي لتسريب بيانات حساسة بدون أن تشعر.

من الواضح أنك تمتلك أساسًا جيدًا في تطوير الويب؛ تعلمت HTML وCSS وJavaScript وBootstrap، وتستطيع بناء مواقع باستخدام ووردبريس، بل وتمكنت من بيع موقع بالفعل، وهذا بحد ذاته خطوة ممتازة. المشكلة ليست في ما تعلمته، بل في ترتيب الطريق ووضوح الهدف.

نصيحتي لك : ركّز أولًا بدل أن تتشتت

التنقل بين WordPress و Front-End ثم محاولة دخول MERN في الوقت نفسه سيجعلك تبذل الكثير من الجهد دون نتائج واضحة. الأفضل أن تختار مسارًا واحدًا وتطوّر نفسك فيه بعمق قبل الانتقال لشيء آخر.

أي المسارات مناسبة لك؟

الخيار 1: أن تتخصص في WordPress (عملي وربحي بسرعة)

ووردبريس مناسب جدًا إن كنت تبحث عن عمل حر سريع لأن:

• الطلب عليه كبير خصوصًا للعرب والشركات الصغيرة.
• يمكنك إنهاء المشاريع خلال أيام لا أسابيع.
• يمكنك تطوير مهارات إضافية مطلوبة بشدة مثل:
• الأمان – تحسين السرعة – SEO – بناء قوالب مخصصة – بناء إضافات بسيطة.
• هذه المهارات وحدها ترفع سعر مشروعك من 150$ إلى 400–800$ بسهولة.

الخيار 2: أن تكمّل في Front-End ثم تتجه لـ MERN

هذا المسار أقوى على المدى البعيد، لكن يحتاج وقتًا وصبرًا.

قبل أن تبدأ MERN يجب أن تكون متمكّنًا من:

• JavaScript بعمق
• ES6
• التعامل مع API
• أساسيات React

بعدها يمكنك تعلم NodeJS وExpress وMongoDB.

لماذا يجب أن تختار مسارًا واحدًا الآن؟

لأنك:

• طالب جامعي، ووقتك محدود.
• لا تزال في بداية الطريق.
• تحتاج لنتائج واضحة كي لا تشعر بالإحباط.
• التشتت بين 3 مسارات سيجعلك تتعلم كثيرًا لكن دون إنتاج فعلي.

نصيحتي النهائية

إن كان هدفك العمل الحر والربح القريب ركّز على WordPress وتخصص فيه بعمق.

إن كان هدفك أن تصبح مطوّر ويب احترافي متكامل ثبّت أساس الـ Front-End ثم انتقل إلى MERN خطوة بخطوة.

كلا الطريقين صحيح، لكن الخطأ هو محاولة المشي في الطريقين معًا.

إذا أردت، أستطيع تحديد خطة تعلم واضحة لمدة شهر أو ثلاثة أشهر حسب المسار الذي تختاره.